I have been coding for 16 years and tried many technical stacks. Learning new languages is a lot of fun. In the beginning new languages are always like new toys, until somewhere in the third month you hit problems.
There’s always something simple missing - lambda functions, tagged unions, custom primitive types. I see how other developers complain on StackOverflow and Github desperately looking for the same features. These complaints always have the same end: the much wanted feature won’t be implemented because language designers do not think that the feature is needed.
I used to think that I was not competent enough and didn’t fully understand the reasoning of language creators. I thought they were beyond criticism by developers like me. They are smart, forward-looking, full of wisdom and their ways are beyond tracing.
Lately I work as a platform engineer. I provide tools, libraries and develop example architectures for other developers. I have a specific plan for the current sprint and a roadmap that covers half a year of work at least. I have to coordinate features and directions with other engineers.
The biggest estimate that I have given in the last three years was two months. It was a large feature that I was able to deliver along with two dozens of other smaller features.
As a software engineer I can’t say: “my users want that feature, but I personally don’t like it - so it won’t be developed”. I can’t do as Rob Pike, who said that much-wanted generics will be in Go 2, and Go 2 will be “ready when it is ready”. You see, in his opinion generics are adding complexity and he does not like complexity.
Real reasons for missing generics always were in the technical field. If you take a look at Go compiler’s code you will have no doubts - the quality of the codebase is so poor that adding generics is just not possible without rewriting the compiler.
Language compiler and tools are just software and language designers are no better than any other software developers. However, they often ignore basic practices of development. Developers are to blame if the code base is so poor that it has to be rewritten. Developers have not done great work with architecture.
Language development should be as simple as: study users requests (i.e. developers requests), create work items, estimate and schedule work, deliver new features.
Language designers do not use their own language as much as you do, they do not solve the same problems as you do. However they put their own opinions regarding language features higher than yours. Even if they stoop so low to agree that some feature is useful and should be implemented, it’s not over yet. It looks like they don’t care when the feature will be implemented: this month or in 10 years.
Features that I miss are not simple syntax sugar. All these things: enums, records, tagged unions - they are important industrial programming features, they allow me to automate more. They were introduced to some languages because they solve very specific problems which could not be solved well enough without them.
Consider the lambda function feature which allows to filter a collection in one line. Lack of lambda functions leads to a bloated codebase. When your code base is twice of what it could be you know you are in deep trouble and it grows as a snowball. The more extra code you have - the harder it is to maintain code base - the faster quality deteriorates.
I know there are no perfect engineers. Everyone makes mistakes. I’ve done it many times. What really bothers me: how these purely technical mistakes grow to become absurd.
When I write code I feel that I do it by someone else's rules. I can’t influence those rules. I basically throw myself on the mercy of Gosling, Hejlsberg, Odersky, Breslav, Syme.
If you are familiar with the latest studies on modern dictatorships you know that autocrats of a new wave strive to represent themselves as democratic leaders. The attempt to pretend that programming language design is controlled or influenced by the “community” is just hilarious. Committees and forums that are meant to work on design of the language are just covers for the dictatorship of the main language development team. For example I have checked contributors to the KEEP repository (Kotlin Evaluation and Enhancement Process) - top 10 developers are members of the main Kotlin team. They suggest changes and they implement changes.
A dictatorship is always followed by the cult. Developers using specific programming language are devoting wholeheartedly to the language. They have everything: literature, conferences, meetups, Reddit forums, Instagram accounts (who would think!?) and of course lectures by the language creators. After the language designer has given such a speech, developers have the opportunity to ask them questions. Usually they ask the simplest questions that could be googled in 5 seconds. They do not need answers, they want to feel participation. “Here’s my leader and he/she listens to me, we are moving forward together!”
The language cult is aggressive most of the time. I still remember how in the end of 200x I tried to explain to Java-programmers that Java is far behind C# in terms of language design. Instead of some reasonable discussion on whether the language needs lambda functions (introduced in C# 3.5 in 2007) there was hatred, smirks, and condescending comments about how “Microsoft has stolen everything from Gods”.
In questions like “How to do X in Java?” on Stackoverflow, veterans of the community are explaining that X is harmful and not needed and the fact that Java does not have X is greatest good since it protects developers. Such comments are usually liked off limits and vice versa disliked those suggestions that X might be useful in Java.
Have you ever seen some book at the level of “Thinking in Java” (by Bruce Eckel) suggesting at least on one or two pages what improvements could be made to the language? Wouldn’t it be interesting to briefly peek what could be done or even should be done in the design of the language? Was the concept of lambda functions such a revolutionary idea that it was absolutely unpredictable that it would appear in Java one day? Or, to turn to a more modern example, how null-safety might hypothetically look like in Java?
Dictatorship always looks firm and unwavering. In fact ideology will eventually change and cult followers will do a 180.
A long time ago Oak language was pulled out from a trash can, named “Java” and got unprecedented marketing budgets with materials in Wall Street Journal. After that what we saw was 10 years of denial towards making any improvements in the language (somewhere 2002-2012). Finally, most of the normal features are being added to Java. There weren’t any good reasons for this idling (like compiler rewrite) outside of Sun’s and Oracle’s preference for hiring lawyers instead of developers.
The record type just has been added to C#. It took only 9 years counting from 2010 when they were introduced in F#. Both languages were developed under Microsoft roof and it seems impossible that C# designers did not notice how record types are useful. They just decided not to rush with this. Maybe in 3-4 years we can get tagged unions in C#. Why would it take so long? There’s no answer to that - the C# designers wanted it this way.
Scala 3 (aka Dotty) is getting a new keyword “enum”. There have been multiple releases of Scala in the last fourteen years since 2.0 (2006), but in none of them did the designers feel compelled to add normal enumeration types. There is enumeratum and some other “options” but the fact of adding the new keyword “enum” tells us that these “options” are not working. It would be nice if we wouldn’t have to wait for Dotty for 3 years.
I filter out “ideology” in programming. Ideology is used mostly to cover flaws of the language. There are specific problems in the language and they should be solved. If they are not solved in a reasonable timeline it would mean that language is not so good for now and language designers are not doing a great job. Instead they are trying to cover it with propaganda and by growing a cult. It’s a cheap stunt, do not believe them. You will thank me when they do another 180.