Things I Was Wrong About: Types

The "oh wow I'm never doing static typing again" bit happened entirely as a hobbyist, maybe working on a project with a friend or two. My early professional life was dominated by Ruby, mostly in smallish teams, that is, like, under 30 people. Then I got into working in Ruby open source, where the teams are much bigger, and aren't all working for the same org...

> occasionally start writing some C++ logic in an elegant functional way and realize that C++'s boilerplate makes it less readable

Not to be That Guy, but you should give Rust a try if you haven't yet. You may not like it, but it will make writing that style of code feel more like Python, often.

> I wonder whether I've just set a standard so high for the health of a system that many of those who dismiss typing's value don't understand that those benefits are possible

I think the issue isn't about possibility, but about realization. That is, I also did know that more robust static typing existed, but in 2008 I wasn't going to be writing a web app in Haskell, but in PHP or Rails. So it felt pretty academic. And even knowing that it's possible in theory isn't the same as experiencing it in practice. One of the things that frustrates me about this particular Discourse (static vs dynamic types) is that many dynamic language proponents (myself included historically) will understand that testing is a skill that they need to practice with in order to succeed, but don't perceive types the same way. It takes practice! You won't just magically see benefits immediately. They're a tool. But in order to justify doing that work, you have to be able to see a real benefit. I don't begrudge people that don't see the connections here and so don't want to put in the time or effort to realize the benefits.

As someone that likes to keep his editor simple (to an extent--I'm using VIM after all), I always get frustrated when people try to introduce policies or procedures that work for them and their preferred setup, and who look at me as an obstacle because I prefer a different setup.

I'm of the opinion that code should be written independent of the tools used to understand and modify that code. If there's anything about the code that needs to be communicated, it should be communicated via the code itself, whether through naming patterns, comments, types, or any other methodology that can be encapsulated in a text file.

Other than letting each developer have their own preferred processes and coding environment, it also makes it easier to SSH into a remote box and know what's going on. A quick google shows that VS Code does allow for SSHing and browsing the remote files via VSCode. That's nice, but I don't know how well it works, and how much I like the idea of allowing another program to run commands on the remote box. I like that I can SSH into a box and use the tools natively available there to read and modify the code, and that the code is prepared in a way that makes it as easy as possible.

Not always. If you examine history not everything is a cycle, depending on what you look at human efficiency improves as well.

Society goes through natural selection. The cultures, methods and behaviors that help us survive live on while methodologies that aren't as good tend to get eliminated.

The cycles in the process occur in areas not under selection pressure. It's called genetic drift and mutations in this area can occur willy nilly in random steps or even cycles if it doesn't have an effect on survival. The pressure in this case is survival of a business.

There's not enough cultural data on dynamics types vs. static types, but I feel in general the dynamic type thing was a mutation. Dynamic types were natures trial at a baby born with one kidney instead of two because one kidney is more energy efficient to maintain. Now it's being naturally selected out.

We'll never know for sure unless you live long enough to see what happens to programming in the far future. For something to be truly called cyclical it must be adopted by huge amount of businesses and eliminated and recreated multiple times.

I've never used Rust but I was a (low-confidence) big fan the moment I saw it, and everything I've seen since has only strengthened this impression. I don't exactly _love_ C++ and all its janky weirdness, and Rust seems like it improves ergonomics while allowing even more powerful control over memory and type safety.

Unfortunately, there are a couple of computer science subspecialties that I prioritize when looking for roles, so I lose some degrees of freedom in the ability to pick jobs or side projects that would expose me to Rust.