Before I got into software development, I worked at a company doing technology-adjacent things. Nothing too fancy, but I got to improve a lot of things just by knowing a little powershell.
One day, a senior developer there - a guy very fond of music - was showing me his process for converting a text file into SML. His process consisted of opening two notepads: one with an SML template block, and one with the text file to be converted. He then proceeded to convert each line into SML by copying the prefix tags and postfix tags and pasting them around each line.
I wrote a powershell script in front of him to automatically do that and save an entire days worth of work, and he just stared at me. I had removed the one really mindless part of his job that he could use as an excuse to listen to a TON of music. Needless to say, he never used the script.
Reflecting on this, I feel fortunate to have had this experience early on - it really helps put things into perspective - perceived improvements to anything depend entirely on the workflow of the people impacted.
1. I do that once in a while. There is only so much thinking you can do in a day or a week that you need some mindless activity
2. Today morning, fresh in the new year after a break -- I took a day off on the 2nd, and I last worked on December 19th, I am not able to get into the zone, and luckily a training email popped up -- spent an hour doing that. Normally my manager would have had to remind me.
Rust is an unergonomic language that slows development in the general case (because it has lots of arcane syntax and rules, and people generally don't know it). Suggesting it as the "obvious" choice ignores the tradeoffs that come with adopting it for a project.
You can just hire people who know Rust. One Rust developer would likely end up more productive than ten Cursor baby sitters in the long run, and you would actually get a high quality app.
Not parent comment, but TS is generally safe if you have types correct at system borders, but very scary when you don't. Some of the most impactful bugs I've seen are because a type for an HTTP call did not match the structure of real data.
Also, many built in functions do not have sufficient typesafey like Object.entries() for instance
That is an issue with how TS works, but it can be significantly improved upon by using a library to verify the structure of deserialized data. zod is one example, or you could use protobufs. Fundamentally, this is an issue with any programming language. But having your base "struct"-like type be a hashmap leads to more mistakes as it will accept any keys and any values.
I disagree that this is an issue in every language - the problem is that in other languages the validation against some schema is more or less required for unmarshalling, and it's optional in TS.
Seeing a deserialization error immediately clues you in that your borders are not safe. Contrast that with TypeScript, where this kind of issue can lead to an insidious downstream runtime issue that might seem completely unrelated. This second scenario is very rare in other languages.
I don't know Rust, and I'm genuinely curious: How does it improve over that problem?
When you call a REST API (or SQL query for that matter), how does it ensure that the data coming back matches the types?
TS allows you to do parse the JSON, cast it into your target type, done (hiding correctness bugs, unless using runtime verification of the object shape, see sibling comment). Does Rust enforce this?
It validates the object shape at runtime, much like you can do in Typescript with a library like Zod. The key difference in this case is that Rust makes it scary to not validate data while Typescript will gladly let you YOLO it and blow your legs off, even in strict mode.
It’s not. And trying to just be a transformation of the source to JS without its own standard library (mostly, some old stuff doesn’t follow this) means it really isn’t possible with just TS alone.
That’s OK with me. I use TS because I like it and hate the total lack of safety in JS. I have to use JS on the web, so TS it is.
If I don’t need it to run on a webpage, I wouldn’t be writing it in TS. I like other languages more overall.
If you type correctly at border of your system, then TS will be very close to a formal verification of your code. This won't catch all bugs, but even broad categories for you data is helpful. If you know your input is a non-null string. Then it will warn you of every non string usage. It won't catch whether it's a name or an email, but knowing someone tries to divide it by zero is helpful.
I think the point was that they are contradictory, yet "data" was shown to indicate they were each sound decisions, implying an inherent dishonesty and willingness to bend data to support an already drawn conclusion.
No, I'm stating that those aren't contradictory. Perhaps they were inaccurate paraphrases of statements that were contradictory, I have no idea. But taking what's written at face value, they are not hard to reconcile. E.g., being productive doesn't necessarily imply innovating.
Not sure if it's just me, as I'm relatively new to the field, but I notice a surprising amount of people assume that the details in programming have already been made intuitive to them, and they use this "experience" to push ideas that are at odds with other domain specific details. To me, maybe this is what the author means by "stuck"?
Wouldn't this complicate variable binding? I'm unsure how to think about this kinda of syntax if either D or E are expected to return some kind of data instead of "fire and forget" processes.
There are usually flights from hub to spoke, and spoke to hub, and each one will have the same number. This is within a 24 hour period. 3934 is one such flight between PHX and SEA.
The misconception here is that Flight numbers are not treated as IDs. A unique key to any flight is the composite of number/origin/departure date.
And it's mostly a holdover from legacy systems airlines are entrenched in, so there isn't much else anyone can do here short of completely reinventing the mainframe reservation systems and heavily refactoring all the pieces that depend on it.
> isn't much else anyone can do here short of completely reinventing the mainframe reservation systems and heavily refactoring all the pieces that depend on it.
This is commonly called "software maintenance". I believe that most places have contracts to keep software up to date for changing specifications/operating systems.
One day, a senior developer there - a guy very fond of music - was showing me his process for converting a text file into SML. His process consisted of opening two notepads: one with an SML template block, and one with the text file to be converted. He then proceeded to convert each line into SML by copying the prefix tags and postfix tags and pasting them around each line.
I wrote a powershell script in front of him to automatically do that and save an entire days worth of work, and he just stared at me. I had removed the one really mindless part of his job that he could use as an excuse to listen to a TON of music. Needless to say, he never used the script.
Reflecting on this, I feel fortunate to have had this experience early on - it really helps put things into perspective - perceived improvements to anything depend entirely on the workflow of the people impacted.