1. 1

    Neat, my university shows up on this list. Nowehere near the top, but on the list 🙂

    e: Also, I only did undergrad.

    1. 1

      Same, although I left in ’92, so I doubt my experiences have much to say about their current rating.

    1. 27

      /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 :)

      1. 6

        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.

        1. 5

          As an American, I’m offended by this statement!

          1. 4

            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?

            1. 12

              Applied computing != computer science

              1. 9

                Where was the World Wide Web born? Where was Linux written?

                I don’t see the point with this exercise.

            1. 10

              The Arch Wiki is the gold standard of wikis 🙂

              1. 24

                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

                1. 12

                  Oh. Well, as my grandmother would say, rats.

                  1. 9

                    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…

                    1. 2

                      designed-by-oh-fuck-it language

                      😂

                    2. 3

                      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

                      https://github.com/oilshell/oil/blob/master/.travis.yml

                    3. 8

                      I already spend too much time being a YAMLgineer.

                      1. 3

                        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.

                        1. 3

                          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.

                          1. 7

                            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

                          2. 1
                          1. 42

                            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.

                            1. 10

                              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.

                              1. 10

                                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.

                                1. 6

                                  I’ve decided that most new JS code I write actually should be TypeScript these days. The tooling around the language is too nice.

                                  1. 5

                                    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.

                                    1. 2

                                      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.

                                  2. 1

                                    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.

                                  3. 7

                                    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.

                                    1. 14

                                      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.

                                      1. 4

                                        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.

                                        1. 1

                                          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.

                                          1. 2

                                            In that specific interview it was for finite element analysis.

                                        2. 2

                                          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.

                                          1. 1

                                            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.

                                            1. 3

                                              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.

                                              1. 1

                                                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.

                                                1. 2

                                                  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.

                                              2. 1

                                                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.

                                                1. 2

                                                  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? :)

                                          2. 4

                                            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.

                                            1. 6

                                              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.

                                              1. 5

                                                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.

                                                1. 4

                                                  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.

                                                  1. 2

                                                    “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?

                                                    1. 2

                                                      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.

                                                  2. 4

                                                    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.”

                                                2. 2

                                                  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.

                                                3. 4

                                                  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.

                                                  1. 6

                                                    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…

                                                    1. 6

                                                      Some stuff we’ve done:

                                                      • write third-party types that basically force you to pass values through validators by saying “this actually returns an opaque InvalidatedResult style thing”
                                                      • remove functions we deem “bad” from the type signatures
                                                      • codegen definition files
                                                      • heavy usage of stuff like 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.

                                                      1. 1

                                                        That sounds amazing! Have you or Notion written any articles describing this setup in more detail? Are there any by others you recommend?

                                                        1. 1

                                                          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.

                                                          1. 1

                                                            I’ll keep an eye out for your article in the lobste.rs feed 😉.

                                                      2. 2

                                                        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.

                                                        1. 3

                                                          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.

                                                          1. 2

                                                            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.

                                                            1. 1

                                                              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.

                                                      1. 3

                                                        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!

                                                        1. 3

                                                          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.

                                                        1. 2

                                                          That’s a fun comparison, but this is 417 words to make the point “don’t write bad code” :/

                                                          1. 15

                                                            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.

                                                            1. 2

                                                              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!

                                                              1. 1

                                                                That’s a good point - re-reading the article, I get what you and the author are saying here.

                                                            1. 4

                                                              Maybe I’m getting old but this story didn’t seem all that compelling. Can you imagine… an internal system for running code? IDK.

                                                              1. 2

                                                                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.)

                                                                1. 4

                                                                  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.

                                                              1. 28

                                                                Proposed tag: ‘classic’

                                                                1. 9

                                                                  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.

                                                                  1. 8

                                                                    Ah, thanks for pointing that out. This particular story is from 2002. I still love reading it every time.

                                                                    1. 7

                                                                      “historical” might apply. I had no idea this was published that long ago, and I had never seen it before!

                                                                  2. 1

                                                                    The very word in my mind as I clicked comments.

                                                                  1. 1

                                                                    I’m gonna be ‘that person’ - relevant XKCD

                                                                    1. 13

                                                                      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?

                                                                      1. 3

                                                                        Calibre is a godsend for us Kindle owners.

                                                                        1. 2

                                                                          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.

                                                                        1. 3

                                                                          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

                                                                          1. 1

                                                                            Same, I started using feedly about a year ago. It works and it’s free, but I don’t love it.

                                                                          1. 2

                                                                            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:

                                                                            • Feature-completeness
                                                                            • UX
                                                                            • Security
                                                                            • Testability
                                                                            • Good developer experience

                                                                            Then there are some other more ‘questionable’ values I’ve seen

                                                                            • Defects are hidden from users, blame users
                                                                            • Tricks users into spending money/making mistakes
                                                                            1. 1

                                                                              I thought of a few more

                                                                              • Metrics (performance)
                                                                              • Analytics (usage)
                                                                              • Tracability (are there logs for when something goes wrong?)
                                                                              1. 2
                                                                                • Accessibility
                                                                                • Composability(heavily related to a couple of others)
                                                                                1. 2

                                                                                  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:

                                                                                  • Availability
                                                                                  • Interoperability
                                                                                  • Modifiability
                                                                                  • Performance
                                                                                  • Security
                                                                                  • Testability
                                                                                  • Usability

                                                                                  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.

                                                                              1. 5

                                                                                Possibly dumb question: is this different from the serialization that gRPC uses?

                                                                                1. 8

                                                                                  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”.

                                                                                  1. 4

                                                                                    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.

                                                                                    1. 4

                                                                                      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.

                                                                                  2. 2

                                                                                    Yes, gRPC uses Protobuf’s. Broadly similar idea, different system.

                                                                                  1. 3

                                                                                    Sweet… I just got a Wacom tablet a few weeks ago and I’ve been really enjoying using it :(

                                                                                    1. 1

                                                                                      You might consider writing to them and expressing your displeasure about this as a recent customer.

                                                                                    1. -2

                                                                                      😂

                                                                                      1. -7

                                                                                        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/

                                                                                        1. 2

                                                                                          Extremely relevant and he disclosed his employment. Why the downvotes?

                                                                                          1. 2

                                                                                            Shameless.

                                                                                          1. 1

                                                                                            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!

                                                                                            1. 2

                                                                                              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.

                                                                                              1. 14

                                                                                                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/

                                                                                                1. 1

                                                                                                  I also tried to keep it minimal: https://soc.github.io/

                                                                                                  1. 1

                                                                                                    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.

                                                                                                    1. 1

                                                                                                      Thanks! It took a substantial amount of time to get the dimensions to 2. :-)

                                                                                                  2. 1

                                                                                                    I agree with this. It’s roughly what I’ve done with my site as well: https://c.har.li/e/

                                                                                                    1. 1

                                                                                                      I really like the look of your site!