/US/ computer science dept rankings. The USA is not the centre of the universe. Itâs not even the centre of the Computer Science universe :)
I guess what @pja is trying to say is something along the lines of
The title should have read computer science open rankings in the USA
It would be quite interresting to see a world ranking, indeed. Given that it isnât explicit, it does seem a little clickbaity - I fell for it.
Itâs not even the centre of the Computer Science universe :)
Remind me, I forget, which country are Google, Microsoft, Apple, Mozilla, Tesla, the Linux Foundation, and the FSF headquartered in again?
Where was the World Wide Web born? Where was Linux written?
I donât see the point with this exercise.
I think itâs going to be the year (and decade) of shell scripts written in YAML ⌠Github Actions, Gitlab runners, Kubernetes config, sourcehut, etc. :)
I have a few blog posts coming up about that âŚ
This is excellent news for those of us whoâve been writing bash scripts for a long time. We have decades of experience with an idiosyncratic, designed-by-oh-fuck-it language that barely has a syntax and performs in all sorts of surprising ways! This is practically the same thing, itâs a new flavour, there are fewer people who know it, so the consulting rates are higherâŚ
Thatâs about how I feel ⌠There are a lot of useful platforms locked behind YAML.
But it looks like there is a way out: JSON is a subset of YAML, so I changed my .travis.yml
and sourcehut YAML to be generated. So I have .travis.yml.in
, and .travis.yml
, the latter of which is just JSON. [1]
So I can change the source language to be something else, but I didnât yet. My configs are like 30 lines now, so it may not be worth it. But I have worked on big services that are thousands of lines of config (e.g. when I used to work Google) . I would say thatâs the norm there, and tens of thousands of lines is pretty common too.
I remember someone saying that Facebook is written with like hundreds of thousands of configuration like this? https://research.fb.com/wp-content/uploads/2016/11/holistic-configuration-management-at-facebook.pdf
Iâd be curious if people like it or dislike it.
So it looks like you can already replace YAML with Jsonnet, Cue, probably Dhall, etc. Does anyone actually do it? Anecdotally, it does seem like templating YAML is more popular? I wonder why that is. I only work with a handful of services that accept YAML now.
https://leebriggs.co.uk/blog/2019/02/07/why-are-we-templating-yaml.html
I think the functional languages are a little unfamiliar. Oil will use Ruby-like blocks for configuration, sort of like Vagrant or Chef but more succinct.
Oil should will be more familiar to people who know shell / Python / Ruby. If you know those languages, I donât expect that Jsonnet, Cue, or Dhall is very familiar. They feel like an âextraâ thing. And the last thing we want in infrastructure management is yet another config language. (Thatâs why I think it makes sense to bundle into a shell.)
Ditto for Nix. Nix is very similar to these languages â itâs basically an expression language over dynamically typed JSON-like records, but in this thread there is some negative feedback about that.
Anyway I want to fix this problem with Oil, but Iâm not sure in which cases people would actually accept the extra âcompilerâ. It seems like people are very eager to template YAML, and embed shell in YAML, which is weird to me. I wonder why that is.
[1] https://github.com/oilshell/oil/blob/master/.travis.yml.in
Iâve actually been working on my own CI system (not yet finished/released) because I got so fed up with this. After I ran out of the Travis credit thing I looked at GitHub Actions, and I just couldnât get PostgreSQL to work: it just fails (after waiting 5 to 10 minutes, of course) and itâs pretty much impossible to inspect anything to see whatâs going on. I already did this song and dance years ago with Travis, and it was painful then, and even more painful now.
It just sets up an image and starts /run-ci
(or another program) from your repo in a container with runc
. The script can be written in $anything supported on the container, and thatâs it. While this wonât cover 100% of the CI usage cases, itâs probably suitable for half or more of them, and you can, you know, actually debug it.
Iâve thought about writing a language that uses YAML syntax but in the style of LISP or XSLT. It would be a total troll language, but I could see some projects actually using it.
Github almost beat you to it, except:
if: ${{ github.event.label.name == 'publish' }}
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
clearly needs to be
if:
cond:
op: ==
left:
op: .
left: github
right:
op: .
left: event
right: ...
right: publish
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
:-)
from:
https://lobste.rs/s/oeelem/using_github_issues_as_hugo_frontend_with
https://github.com/shazow/shazow.net/blob/master/.github/workflows/publish.yml
Boring prediction: TypeScript. By the end of 2021 TypeScript will broadly be seen as an essential tool for front-end teams that want to move faster without breaking stuff.
The alternatives which launched around the same time (Reason, Elm, Flow, etcâŚ) have all fallen by the wayside, and at this point TS is the clear winner. The investment is there, the ecosystem is there, the engineers (increasingly) are there. The broad consensus isnât quite there in wider world of all Javascript engineers, but I think itâs coming.
Eventually good engineers will leave teams that wonât switch to TypeScript, ultimately hobbling those companies. Their lunch will be eaten by the competitors whoâre using TypeScript. But thereâll be money to made dealing with legacy messes of JS / Coffeescript, Backbone, jQuery etc, for the people whoâre willing to do it. Itâll be a long-lived niche.
Knock-on effects will include decreased use of Python in an application / API server role (I know thereâs MyPy, but I think TypeScript is ahead) except where itâs coupled to data-sciency stuff. I think something similar will be seen with Go. I donât know how big these effects will be.
Unrelated prediction: Mongo will make a comeback. Iâve really disliked working with Mongo, but I was completely wrong about the price of Bitcoin this year so I assume Mongoâs comeback is inevitable.
Eventually good engineers will leave teams that wonât switch to TypeScript, ultimately hobbling those companies. Their lunch will be eaten by the competitors whoâre using TypeScript. But thereâll be money to made dealing with legacy messes of JS / Coffeescript, Backbone, jQuery etc, for the people whoâre willing to do it. Itâll be a long-lived niche.
This is quite the prediction. I think I can see it happening. Working with a large, untyped JS codebase is a nightmare and can eat through morale quickly.
I work in a place with a lot of Node JS, but itâs not my day to day. I quickly went from enjoying javascript to hating it. Recently I have been enjoying doing some small stuff on my own again. I think Iâve decided that hell is other peopleâs javascript.
Iâve decided that most new JS code I write actually should be TypeScript these days. The tooling around the language is too nice.
As a hobby I write Ableton plugins in Max MSP. It has JS support, but only ES5, thatâs from 2009, and gross. Turns out the best modern transpiler to target that is TS! I was so happy when I found out.
I should probably give TypeScript a go. I was pretty annoyed with JS for a while so I didnât want to spend my spare time learning TypeScript. Unfortunately, the bits of Javascript that I tend to touch are largely agreed to be the worst in the org and there isnât a lot of energy to move them over to TypeScript. Câest la vie.
yep. Iâm in the midst of a large feature-add to an angular 1.5.5 site. Iâm a bit envious of other teams working with new angular and Typescript.
I think vosper is right - thereâs going to be plenty of work available to those who are willing to maintain older frontend tech.
Eventually good engineers will leave teams that wonât switch to TypeScript
Any engineer who will leave purely because the company doesnât switch to $my_favourite_tech_choice
is, by definition, not a good engineer. Weâre supposed to professionals for crying out loud, not children insisting on our favourite flavour of ice cream.
Iâd argue switching companies in order to use better tech is what a professional engineer does. Strong type systems are equivalent to constraints in CAD for mechanical engineering or ECAD for electrical engineering. They are absolutely crucial for proper engineering.
A mechanical engineer that wants to use something like Solidworks or Onshape at a company using TinkerCAD would not be looked down upon. Engineers need to use the right tools to actually engineer things.
So yes, switching companies to use and practice with proper tooling is a damn good engineer.
I interviewed a bunch of professional engineers a couple years back. Most of them were stuck on using Excel spreadsheets. One was yelled at by his boss for using python scripts.
I mean, Excel is a battle-tested functional programming environment which has intermediate states easily visualized and debugged! It has its faults, but Iâd imagine it was being used for something like BOM inventory management? In that case it is definitely the right tool compared to Python.
In any case, yes there are many engineering jobs like that in other engineering fields, but there are also many software engineering jobs which deal exclusively with k8s yaml files, which Iâd argue is similar but worse.
They [Strong type systems] are absolutely crucial for proper engineering.
Says you. The rigor and engineering approaches âcrucialâ to systems depends HEAVILY on the domain, but Iâm not sure I can identify ANY domain that ârequiresâ strong typing (which is how I interpret âcrucialâ). Plenty of critical software has been and is being built outside of strong type guarantees. Iâm not prepared to dismiss them all as bad or improper engineering. There may be a weak correlation, or just plain orthogonal - hard to say, but your staked position seems to leave no room for nuance.
I think your analogy muddles the conversation, as most software engineers are not familiar enough with those fields to be able to evaluate and understand the comparison beyond taking your statement as true (maybe it is, maybe it isnât).
Defining âa good engineerâ and âproper engineeringâ seems heavily rooted in opinion and personal experience here. Thatâs not to say itâs fundamentally un-study-able or anything, but Iâm not sure how to make any headway in a conversation like this as it stands.
Says you. The rigor and engineering approaches âcrucialâ to systems depends HEAVILY on the domain, but Iâm not sure I can identify ANY domain that ârequiresâ strong typing (which is how I interpret âcrucialâ). Plenty of critical software has been and is being built outside of strong type guarantees. Iâm not prepared to dismiss them all as bad or improper engineering. There may be a weak correlation, or just plain orthogonal - hard to say, but your staked position seems to leave no room for nuance.
Sure, no domain ârequiresâ strong typing. No domain ârequiresâ a language above raw assembly either. We use higher level languages because it makes it significantly easier to write correct software, compared to assembly. A strong type system is a significant step above that, making it much easier to write correct software compared to languages without it.
Having worked at companies using languages such as Python, Javascript and Ruby for their backends, and having worked at companies that have used C++, Java, and Rust for their backends (even given the faults and issues with Java and C++âs type systems) the difference between the two types of companies is night and day. Drastic differences in quality, speed of development, and the types of bugs that occur. Strong type systems, especially the ones derived from ML languages, make a massive difference in software quality. And sure, few domains really âneedâ good software, but shouldnât we strive for it anyway?
I think your analogy muddles the conversation, as most software engineers are not familiar enough with those fields to be able to evaluate and understand the comparison beyond taking your statement as true (maybe it is, maybe it isnât).
I mean, if we canât pull lessons from other engineering fields what is the point of calling it software engineering? I donât really know how to respond to this point, because clearly we have different opinions on this topic, each derived from our past experiences. My point is no less strong because you or others are unfamiliar with a domain.
I encourage you to try out various CAD tools, TinkerCAD and Onshape are both free to use and online available, so there isnât even a need to download software. I think you will very quickly see the difference between the two, TinkerCAD you will master in a few minutes, and Onshape will likely be unapproachable without tutorials. But if you look at the examples, Onshape is used to produce production, intricately designed mechanical parts. And simply without the tools and constraints that Onshape provides you canât do proper mechanical engineering.
And I really want to highlight that I donât mean to say that TinkerCAD is bad, or worse in any way. It is incredible for what it is and for opening the door to the world of mechanical design to those who arenât familiar with it. It is simply not an engineering tool, while Onshape is.
My analogy really stems from how each tool is used. TinkerCAD you just build the thing you want, using the shapes and manipulation tools it provides. Onshape is different, everything has to be specified. You have to set lengths of everything. You have to specify what the angles of things are. Certain things are really hard to do, especially organic shapes, because everything has to parameterized. I hope youâll agree this is nearly identical to programming languages with and without strong type systems!
Defining âa good engineerâ and âproper engineeringâ seems heavily rooted in opinion and personal experience here. Thatâs not to say itâs fundamentally un-study-able or anything, but Iâm not sure how to make any headway in a conversation like this as it stands.
Of course it is rooted in opinion, at least in the US. I believe some other countries have licensed engineering which makes it more of a distinction. Personally I think it is extremely unfortunate that engineering is not a protected term, because I genuinely really think it should be. The state of software engineering feels very similar to the situation of doctors before modern medicine, where the majority were hacks and frauds besmirching the industry as a whole.
I mean, if we canât pull lessons from other engineering fields what is the point of calling it software engineering? I donât really know how to respond to this point, because clearly we have different opinions on this topic, each derived from our past experiences. My point is no less strong because you or others are unfamiliar with a domain.
Thatâs the thing: we shouldnât be pulling lessons until we learn what those lessons are. I had very strong opinions about what software engineering was supposed to look like, then I started interviewing other engineers. Most of what we think âengineeringâ looks like is really just an ultra-idealized version that doesnât match the reality. In some ways they are better, true, but in some ways they are much worse.
EDIT: I just checked and it looks like you used to be a professional electrical engineer? If so then my point about âmost people talk about engineering donât understand engineeringâ doesnât apply here.
Of course it is rooted in opinion, at least in the US. I believe some other countries have licensed engineering which makes it more of a distinction. Personally I think it is extremely unfortunate that engineering is not a protected term, because I genuinely really think it should be. The state of software engineering feels very similar to the situation of doctors before modern medicine, where the majority were hacks and frauds besmirching the industry as a whole.
Several of the people I interviewed called out the US system as being much better than the European, a sort of âgrass is always greener thingâ. The only country I know of with ultra-strict requirements on who can be called an engineer is âCanadaâ. In pretty much all other countries, you can call yourself whatever you want, but only a licensed engineer can sign off on an engineering project. This means that most professional engineers donât need to be licensed, and many arenât.
Do you have a write-up of your interviews anywhere? I would be really interested in reading it! You are right I used to be an electrical engineer, and still tinker on the side, but went into software simply because the jobs in electrical engineering are not very interesting. I think there is a lot that software does better than other engineering fields (although I wonder if that is simply due to how new the field is, and that it will inevitably end up with the more bureaucratic rules eventually), but the extreme resistance to strong typing by so many software engineers feels extremely misguided in my opinion and not something you see in other engineering fields.
Canada was the primary place I was thinking of, but Iâm not particularly familiar with the details of it all. I know the US has some licensing requirements for civil engineering projects (and most of those requirements are written in blood unfortunately). It is almost certainly a âgrass is greener,â and I should certainly educate myself on some of the downsides of other countries systems. If you have any resources here Iâd appreciate it.
Working on it! Iâm in the middle of draft 3, which will hopefully be the final draft. Aiming to have this done by end of February.
if we canât pull lessons from other engineering fields what is the point of calling it software engineering? [âŚ] My point is no less strong because you or others are unfamiliar with a domain.
Fair. Your expanded explanation here helped clarify a lot, I appreciate that. One point of interest in your explanation was
Certain things are really hard to do, especially organic shapes, because everything has to parameterized
Doesnât this seem an admission of there existing domains where - according to analogy - strong type systems might be less suitable? Or would you consider this a breakdown in the analogy?
As far as the meaning of âengineerâ I take that as a very different conversation. I do think thatâs murky territory and personally would be in favor of that being a more-regulated term.
Iâve been doing software development myself for 20 years, and have worked in both strong typed and duck typed. I think theyâre both good - thereâs trade offs. Rather than wholesale dismissing either, I think discussing those trade offs is more interesting.
Drastic differences in quality, speed of development, and the types of bugs that occur
I agree with this statement. I donât think it implies a clear winner for all development though. While a strong type system guarantees a certain kind of error is not possible, in my practice those kinds of errors are rarely a significant factor, and in fact the âloosenessâ is a feature that can be leveraged at times. I donât think thatâs always the right trade off to make either, but sometimes creating imperfect organic shapes is ok.
I would also offer that there can be approaches that give us âboth waysâ - ruby now has the beginnings of an optional type system.
Iâm tapped out for this thread.
Fair. Your expanded explanation here helped clarify a lot, I appreciate that.
Yes, sorry about not expanding in my original comment. As you can probably tell, Iâm extremely passionate about this idea, and my original comment was made in a bit of haste. Iâm glad my expansion was helpful in clarifying my points!
Doesnât this seem an admission of there existing domains where - according to analogy - strong type systems might be less suitable? Or would you consider this a breakdown in the analogy?
I completely agree there are domains where strong type systems are less suitable. Especially the more exploratory areas, such as data exploration and data science (although Julia is showing that types can be valuable there as well). I think my distinction is that there is a difference between domains where strong types are not as suitable, like prototyping, and production engineering systems where I think strong types are extremely important.
As far as the meaning of âengineerâ I take that as a very different conversation. I do think thatâs murky territory and personally would be in favor of that being a more-regulated term.
Iâve been doing software development myself for 20 years, and have worked in both strong typed and duck typed. I think theyâre both good - thereâs trade offs. Rather than wholesale dismissing either, I think discussing those trade offs is more interesting.
It is truly a murky term, which I think leads to a lot of the communication issues in this area of discussion. I should probably start future conversations like this with a clear definition of what I mean in terms of âengineering,â because I mean it more in terms of production engineering, rather than prototyping engineering. (Unfortunately not a distinction in software, but is in all of the other engineering fields. Prototyping engineering values malleable materials, like 3D printing, while production engineering is what is shipped to users and its very particular about materials used which minimize cost and maximize strength. Different fields, different requirements, and oftentimes different tools used to even CAD/design).
So using the production engineering vs prototyping engineering distinction, I would completely agree that there are trade-offs between strong typed and duck typed languages. I think one is fantastic for prototyping, while the other is fantastic for production. And similar to say 3D printing and injection-modling processes, the two can bleed into each otherâs fields given the right opportunity. I should not have used âproper engineeringâ in my original comment, and I should have clarified I meant âproduction engineering.â
However, the number of companies that Iâve been at that have actually treated the two types of languages as different parts of the development life-cycle is exactly one, my current company, and that was after fighting to use Python for a prototype project. (Of course, when the prototype was successful, there was then reluctance to rewrite it in a strongly typed language because âits already built!â)
Similar to how you would feel frustrated if the new computer you bought had all of its internals built with 3D printed parts and breadboards, even if it worked identically to a computer with injection molded parts and PCBs, that is how I feel about using duck typed languages in production systems used by real users. Sure it works, but they are inherently less reliable and I think its poor engineering to ship a system like that (although, of course, there are situations where it is applicable, but not to the extent of the software world today).
I agree with this statement. I donât think it implies a clear winner for all development though. While a strong type system guarantees a certain kind of error is not possible, in my practice those kinds of errors are rarely a significant factor, and in fact the âloosenessâ is a feature that can be leveraged at times. I donât think thatâs always the right trade off to make either, but sometimes creating imperfect organic shapes is ok.
I would also offer that there can be approaches that give us âboth waysâ - ruby now has the beginnings of an optional type system.
Fair enough, although my experience with errors in duck typed languages is certainly different! The jury is still out on the optional type systems, and Iâm certainly curious how that effects things. I have a hard time believing they will make a significant difference, simply because the style of coding varies so drastically between the two. With strong types I design type-first, whereas with optional/incremental type systems its the other way (unless started from the get-go, but at that point what is the purpose of using a duck-typed language?).
Iâm tapped out for this thread.
I completely agree here. This is an exhausting topic to talk about, probably because everyone has strong opinions on it and so many of the arguments are based on anecdotal data (of which I am definitely guilty sometimes!). In any case, I appreciate you taking the time to go back and forth with me here for a bit. Iâve certainly learned that in order to properly discuss this topic its important to be very careful with language and definitions, otherwise its just a mess. I guess the English language could use some strong typing, but then poetry would suck huh? :)
Start caring about that when everything else about the company makes you happy. Your happiness is more important than being a âgood engineerâ.
TS has evolved from a flavor to simply being a better version. The switch to TS is so easy thereâs no reason not to. Thereâs a difference between a challenge and intentionally handicapping yourself.
I was under the impression that my job is to solve problems for customers, not to âbe happyâ. And of all the things that make me happy or unhappy at the workplace, something like this is pretty far down the list; using JavaScript is hardly some sort of insufferable burden.
TypeScript may very well be better; but the last time I used it I found it came with some downsides too, such as the code in your browser not being the same as what youâre writing so the REPL/debugger is a lot less useful, hard to inspect Typescript-specific attributes (such as types) since the browser has no knowledge of any of that, a vastly more complicated build pipeline, and I found working with it somewhat cumbersome with all the type casting you need to do for the DOM API (i.e. this kind of stuff). And while the wind has been blowing in the statically typed languages in the last few years, letâs not pretend like the good olâ âdynamic vs. static languagesâ debate is a done and solved deal. I like typing, but dynamic languages do come with advantages too (and TypeScriptâs typing may be optional, but if youâre not using it much then thereâs little reason to use it at all).
Perhaps there are some solutions to these kind of issues now (or will be soon), but about a year and a half ago I found it all pretty convoluted and decided to just stick with JS for the time being.
In the end, I understand why it exists and why itâs popular, but like much of todayâs frontend I find it hacky, cludgy, and a very suboptimal solution.
Youâre more than your job, you are a human being first. As engineers we have the huge privilege of being able to quit a job and find a new one easily. Happiness is a completely valid reason to do this.
JS vs TS is a minor point, too small compared to other unknowns in switching companies. But OP said âleave teamsâ. I actually did just that, we have multiple teams at my company and one started using TS, so I switched. A year later the JS team now solely does bug fixes and no-one is willing to write new JS code. At first management thought it was like when Coffeescript happened but dev response was so much bigger that even they understand it is different this time.
Youâre more than your job, you are a human being first. As engineers we have the huge privilege of being able to quit a job and find a new one easily. Happiness is a completely valid reason to do this.
Sure, but if youâre made deeply unhappy because you have to write JavaScript instead of TypeScript then you are either in a position of extreme luxury if thatâs a problem that even rates in your life, or there seem to be some rather curious priorities going on. I think all of this is classic programming self-indulgent navel-gazing.
Is TypeScript a better tool? Probably. Would it be a good idea to start a reasonable percentage of new projects in TypeScript? Also probably (depending on various factors). Should we drop all JavaScript projects ASAP just so that we rewrite everything to TypeScript? Ehh, probably not.
I donât have any predictions for 2021, but Iâll have one for 2026: weâll be having the same discussion about WhatNotScript replacing boring old TypeScript and we should all switch to that. And thus the cycle continues.
âno-one is willing to write new JS code.â
until something goes very wrong. Not taking a side here, just âno-one is willingâ struck me as an odd statement. Who has the unhappy chore of taking care of all that old boring JS?
We still do bug fixes. But even then itâs often an opportunity to write TS. The nature of TS makes it so that you gradually port your application. Lots of JS is valid TS and if it isnât then thatâs usually easy to split up or refactor to become valid TS, and TS will help with that refactoring even. JS IDEs provide hints by pretending itâs TS anyways.
Weâre supposed to professionals for crying out loud, not children insisting on our favourite flavour of ice cream.
I was under the impression that my job is to solve problems for customers, not to âbe happyâ.
This is a red herring. You are an economic agent making decisions about your employment to maximize your own utility function, and trying to get what you can out of the market. Some try simply to maximize earnings. Some maximize some combo of earnings and hours worked/stress. Others care about finding meaning in their work. And others care about working with specific technologies, or at least not working with ones they hate.
All of these things are orthogonal to the concept of âbeing a professional.â
I generally strongly agree with your sentiment, and am not a fan of the degree to which developers place their identity in one particular technology over another.
But in this specific case I imagine OP is associating untyped JS projects with tech debt and difficulty of maintenance that all too often can contribute to low morale. Iâve definitely been there before when it comes to large codebases with foundational technical debt and no type system to help one find their way around. Thereâs something uniquely frustrating about e.g. a poorly formatted stack trace coming back from a bug monitoring tool due to broken or buggily-implemented sourcemaps. We can definitely debate whether language choice vs other factors (bad processes, low technical budget) contribute more to system quality. My guess is that language is not one of the largest factors, but itâs probably nonetheless significant. Otherwise we wouldnât hear about stories where people left their jobs due to being sick of the shop tooling.
Agreed. Although TypeScript is a bit OO for my taste, JavaScript libraries have grown sufficiently complex as to warrant strong typing. The adoption rate is undeniable. Vue, Deno, Babylon⌠When your stack is written in TypeScript, the cost/benefit scale tips in favor of adopting it downstream.
Also, Cosmos is heating up, so you could make a case for Mongoâs revival by extension.
At Notion we have some OO-as-state-encapsulation Typescript on the front end, but we have even more functional Typescript, and plenty of code somewhere in-between. We use the advanced Typescript types like as const
inference, mapped types, and conditional types much more than we use inheritance or implements interface
.
Honestly writing a large from-scratch codebase in Typescript focused on type correctness and make-invalid-states-unrepresentable has been very fun and productive. Our biggest issue with the language is error handling - dealing with all the errors from external libraries, the DOM, exceptions vs Result<S, F>, etc is the most annoying and error-prone aspect of our codebase. Shoehorning optionals into our style has left me paining for Rustâs try
features⌠and Iâve never really written rust eitherâŚ
Some stuff weâve done:
InvalidatedResult
style thingânever
I think itâs actually pretty easy to wrap third-party libs for the most part, and itâs basically the âreal wayâ to do most of this. Too many people hem at this idea but it resolves a lot of stuff come âoh no this lib is actually totally bustedâ oâclock.
That sounds amazing! Have you or Notion written any articles describing this setup in more detail? Are there any by others you recommend?
Unfortunately when I go looking for Typescript advice on the internet, I find mostly shallow blogspam tutorials. I have an idea to take notes whenever I use an advanced TS feature and write an article called âApplying Advanced Typescript Typesâ â but thatâs remained just an idea for a couple of years.
Although TypeScript is a bit OO for my taste
My limited experience with TypeScript is that itâs only as OO as it would be if you were writing plain JavaScript. Not sure if that makes sense - another way of saying it would be: JS has adopted some OO trappings, like class
, but if you arenât using them in your JS then TypeScript isnât going to push you in that direction - you can write functional TS to the extent that you could write functional JS; and OO TS to the extent that you could write OO JS.
Unless youâre refering more to the naming of new keywords, like interface
? I see how those could be associated with popular OO languages, but really thereâs nothing making you write actual OO code.
My limited experience with TypeScript is that itâs only as OO as it would be if you were writing plain JavaScript.
Anecdotally, after working at a Java and C# shop that picked up TypeScript, everyoneâs happy having things work more like those languages (well, mostly C# ;) than like JS. I just wish TypeScript would get typed exceptions already.
Yes, it is possible to write non-OO TypeScript. And yes, Iâm pointing out its emphasis on interfaces and other OO features like class property modifiers.
I realize that the choice to make TypeScript a superset of JavaScript means that its roots in Scheme are still present. I also realize that typing a Scheme-ish language makes it (if one squints hard enough) an ML-ish language. Nevertheless, we should not be surprised if most TypeScript in the wild looks a lot more like C# and a lot less like fp-ts.
Nevertheless, we should not be surprised if most TypeScript in the wild looks a lot more like C# and a lot less like fp-ts.
Makes sense. Perhaps some of this is also due to TypeScript being palatable to people who are comfortable in languages like C# and Java; maybe theyâd have stayed away from vanilla JS before (especially if they were exposed in the pre-ES6 days) but might be willing to write TypeScript today? Thatâs total speculation, though, and Iâve no idea how many people like that there are.
Thanks for writing your post. I donât like how much power Google has over the web. And you make a good point that Mozillaâs rhetoric âuse our browser if you love freedomâ is kind of abusive! I also agree that it was a tragedy to fire the MDN and Servo team. I love MDN and use it just about every day at work. I consider it the âGold Standardâ of technical documentation and I worry that it will now be withering away.
But I do agree that we are long past the point-of-no-return with Google/Alphabet âtaking over the webâ. Iâm going to keep using Firefox as a habit for now, but I donât think anything Mozilla could do - even if they ran a tigher ship - could help. Web Standards are just huge and to build a browser to support it would require serious investment that no entity is likely to make.
And even if someone does make that investment in a new implementation, Google/Alphabet/Microsoft/Mozilla would all notice quickly and probably not be excited about anyone coming to âeat their lunchâ.
But you also mentioned making âtoyâ things like gopher servers. I think that has some potential to make things nice where thereâs the âmainstreamâ WWW that Google owns and then thereâs a decentralized web where users can put up a resistance against the monopoly.
Again I think your post is great, thanks for writing.
P.S. I think brutalism on the web is pretty fun!
Thanks for the kind words â Iâm actually surprised how vehemently some people agree or disagree with the post.
P.S. I think brutalism on the web is pretty fun!
I agree, the âplayfulâ or âhobbyistâ web, that contains the web-brutalism movement, is one of the nicest, most refreshing and creative parts of the web.
Thatâs a fun comparison, but this is 417 words to make the point âdonât write bad codeâ :/
The point is a bit more subtle than âdonât write bad codeâ. Itâs âmake less mistakes than your competitionâ, which is actually a very different place to come from, and implies almost a sense of just keeping above the game, and that one might be able to get a lot out of focusing on a handful of things that are causing most of your mistakes, rather than just Not Writing Any Bad Code.
I would extend that to âmake fewer basic mistakes than your competition.â
Youâre more likely to kill your business by screwing up a database backup or password storage than you are to double your revenue with a 10% more efficient application.
Of course, what the basic mistakes are and how to avoid them is an exercise left to the reader!
Maybe Iâm getting old but this story didnât seem all that compelling. Can you imagine⌠an internal system for running code? IDK.
But wait, youâre forgetting the part where it continued to work for twelve whole years. Pure freaking magic!
(In seriousness, 12 years may be seen as long-lived for a Silicon-Valley-fueled company that sells a webstie. But a bank? Our standards should be a little higher than that.)
Yeah. I mean itâs âthe most remarkable legacy systemâ and itâs written about banking software. I was expecting a literal dust-closet server from like the 70s or some old guyâs PC in the backwoods of appalachia.
From the submission guidelines:
When the story being submitted is more than a year or so old, please add the year the story was written to the post title in parentheses.
Ah, thanks for pointing that out. This particular story is from 2002. I still love reading it every time.
âhistoricalâ might apply. I had no idea this was published that long ago, and I had never seen it before!
Iâm gonna be âthat personâ - relevant XKCD
I wonât buy a DRMâd eBook, thatâs for sure. Iâve bought one or two DRM-free ebooks before. A few weeks ago I had a similar experience. I wanted to read a particular book and I bought it knowing it was DRMâd. I couldnât get the thing to work after spending two hours with tech support. I ended up cancelling the order.
My wife recently bought a kindle and reads lots of stuff on it, and she understands that she doesnât really âownâ the books, but the value is just to tear through lots of content, not to keep the pages forever. I suppose if you understand what youâre buying, and it works, itâs fine.
But really, DRM sucks. I thought we nailed this down several years ago?
I wanted to read a particular book and I bought it knowing it was DRMâd. I couldnât get the thing to work after spending two hours with tech support. I ended up cancelling the order.
Iâm impressed that you managed to cancel the order. Most e-book stores Iâve seen have a policy along the lines of, âyouâve downloaded it, you canât âreturnâ it or prove you havenât kept a copy, so we wonât refund you, regardless of whether you are actually able to access the content you supposedly âboughtââ. I guess maybe devoting two hours of your time to the issue convinced them that it really didnât work.
Like you, I never buy drm-encumbered e-books. I donât think I have the necessary devices capable of running the stuff required to open them (As I understand it, the calibre workaround referred to in the article requires windows or OS X). By contrast, I happily buy drm-free e-books from publishers such as Manning.
I am new to rss feeds, but recently Iâve been using feedly, it feels like I have discovered a new way to use the internet
The best general advice I can give is just this: make sure performance is part of the foundation of your app. Make sure itâs part of every decision every day.
Make sure, in other words, that performance isnât just a topping â itâs the pizza.
I think this is an interesting way to put it. Performance is a âcore principalâ of NetNewsWire. What other things might be core values of a software project? Some I can think of:
Then there are some other more âquestionableâ values Iâve seen
I thought of a few more
These map onto software architecture âquality attributesâ which are discussed in detail in the SEI book Software Architecture in Practice. The ones in the book are:
Of course certain domains or projects will have different quality attributes than these, but these ones are fairly universal so they get discussed in detail in architecture.
Part of the purpose of software architecture is to get people thinking about these quality attributes and prioritizing them early in the design process because there are usually tradeoffs between them (e.g. performance often comes at a cost of modifiability) and architecture is to some extent about making sure that everyone is on the same page about what the priorities are, so the decisions donât get made on-the-fly by developers based on their own preferences.
Yes protobufs require a schema to use, while MessagePack and JSON are schemaless (or optional schema).
After using protobufs for a long time, and seeing how people use them now, an optional schema seems attractive. They have apparently evolved awkwardly into dynamic / reflective use⌠Apparently gRPC has a reflection service which seems like an awkward workaround for the âschema distribution problemâ.
The schema distribution has been pretty much solved, for us, by using a shared protobuf git repo. Go can load that as a dependency without much ceremony, and other langs with a submodule.
Yeah thatâs basically how they were designed to be used originally. Theyâre good for internal use, when you control both sides of the wire.
When you donât control both sides of the wire it doesnât really make sense IMO. Thatâs especially true when youâre talking between two different organizations, but sometimes it happens within the same company / org.
You might consider writing to them and expressing your displeasure about this as a recent customer.
Hey, if you want to migrate to Office 365 from GSuite, my company SkyKick offers that: https://www.skykick.com/migrate/google-apps-to-office-365/
From Reddit:
ability to automatically follow back other instances, statistics in about page, a new âMost liked videosâ page, ability to autoplay next recommended video, better search functionality and much more!
I really enjoyed watching this talk. Iâve worked in enterprise software for a decade now and itâs become pretty clear that ideas are recycled pretty regularly. It seems to me like software engineering has a marketing problem.
My two cents: keep it minimal, focus on content and not on fancy themes.
For my personal website I keep it as simple as I can and Iâm quite satisfied. https://github.com/dacav/App-PFT/blob/master/share/templates/terminal.html rendering as https://dacav.roundhousecode.com/
I agree with this. Itâs roughly what Iâve done with my site as well: https://c.har.li/e/
I also tried to keep it minimal: https://soc.github.io/
I really like that you have things organized into a grid, it makes it so that I donât have to do a separate search once Iâm already on the site.
Neat, my university shows up on this list. Nowehere near the top, but on the list đ
e: Also, I only did undergrad.
Same, although I left in â92, so I doubt my experiences have much to say about their current rating.