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.
Latest comments (12)
Great points all around! Especially your conclusions on the dictator/cult dynamics of many "communities" (which are quite reflective of society as a whole) are spot-on.
One thing of course that is a hard problem, is to decide which features "fit" into a language's paradigm and which do not. If you take in any and all suggestions and wishes -- which is likely not what you're suggesting here, but I'm going to say it anyway -- your language design will deteriorate because it will be "design by committee".
And some features just need time to ripen. If you take a look at the Go generics process for example, you are looking at literally years of discussion on how to do this in a way that doesn't compromise the "keep it simple" paradigm of Go. Yes sure, Mr Pike might play a bit of a dictator role, catering to his own tastes and beliefs, and yes, the Go compiler code might just be low quality. But there's other considerations at play too. :-)
Adding generics after the fact is how you end up with the awful erasure-based implementation in Java, though hopefully Go avoided some of the other mistakes of Java and wouldn't be quite as bad off. It's hard for me to see how a language that intends to be used for large project development wouldn't have some way to do generic programming early in its life.
Good read. But the problem which I see in your way of thinking, you think any stackoverflow complain about lacking language feature is valid, or sorry any popular complain. The problem with this way of thinking is that there will be thousands of developers with contrary opinion. If we take into consideration lets say TypeScript, there are ton of feature requests, where most of them have no sense, or are just bad for the language (yes features can be bad for overall language quality). TS is maybe one of the most community driven language out there, even though team which maintain it is fully Microsoft. Even though it is community driven, the final decision is made by the core team, for example feature X can look good at first, but taking other language syntax can be in conflict which is not solvable in O(n) compilation time, you cannot just implement such feature.
Lamda functions maybe look simple, but in language like Java there were implemented as one method classes as I recall, so it is a syntax sugar for that. Tagged unions are a typical feature of static FP languages like Haskell, they don't fit to Java well, as Java has different core principals based on OOP. And having tagged unions means you need to have next feature - pattern matching. These both are in contrary with main principles of Java design. Yes that is my opinion, but take a look that it is in contrary to yours, and if I see things in different light it does mean that your feature which everybody needs, really is a feature which some needs, and others don't want. Also you are abusing word "simple" here.
Ten of years we were doing for loops, you can write loops and don't have bloated codebase, bloated codebase in most cases is not related to language syntax but the code you write in it. Also for example Python has comprehensions which are far better than filter and map with lambda. Comprehensions are more declarative and readable, those it mean all languages should have comprehensions? No, languages based on HOFs like Haskell have different way of doing staff.
I am not sure you are right here, or maybe you are pointing fingers only, but if you are right, and the feature needs to rewrite the compiler from the scratch, then this is not like a feature only, this changes the whole language never made for that. I don't think you are taking into consideration the effort, and taking that Go was to be simple language. You are throwing accusations like - I need X, Y, Z, make me that! That is poor attitude.
You are still mentioning the same staff from static FP. Languages like Java, C#, Python has different origins, they solve the same problems differently. I will give you an example, Haskell uses IO Monad for its IO operations, and has "do" syntax sugar for working with Monads. The thing is that such solution has only sense in languages without side-effects, there is no, totally no need to take this language feature and put it in other, because this problem only exists in Haskell. Above languages solve the same problems but differently.
Again I think you don't see the full picture. I want tagged unions you say, but language designer, maintainers need to analyze pros/cons, how it will work with other language features, what will be the impact for the existing codebases, how to fit that in current schedule.
You have language used by millions of developers, thousands of companies, they rely on stability, they rely that new features will be implemented carefully, and breaking changes are hard to accept. You cannot just add to such language a feature in a week.
How I see your article is one big complain and saying that language maintainers just don't want to add feature you want, and they really have no valid reason for that. But you see very narrowed spectrum of the problem. There cannot be reliable language which just implements whatever developers need in the current moment, or whatever trend it is. Even though I agree that static FP language features are nice, languages like Java or C# was able to solve these problems previously in different way. Both are very mainstream and corporation based, both are used in companies with millions of dollars, it is not easy to just implement "simple" feature, you need to really have all sides on your side, it is like politics. And you cannot say - I don't care that my feature will be a breaking change and will cost millions of dollars of work of all developers which need to update they codebases.
I will give you an example of language which is very not community driven - Elm. Elm is fully maintained by Evan Czaplicki, Evan is widely criticized because of not implementing features which people want, or even he has take out features from the language already which made a big community break. He is stating that language needs time to see in which path it will evolve, it needs to see the usage to make decisions. But part of the community was and is flaming him for not adding for example type classes. But why people want type classes? There is one reason, they know them from Haskell, and they just are use to them. I think if Evan would implement all these requests from the community, Elm would be just Haskell. Like one to one. If you need Haskell just use it, and don't make other language to transform into it. And to be clear I am not a fan of also such centralized language maintaining, as Elm is very not predictable, there is no roadmap, there is no really knowledge what Evan will do. I am just pointing that implementing everything people demand will end poorly.
Such developers attitude (demanding everything from languages they already know) is very common, they come from one language, like I have from JS to Python. And I said - where are my map, filter, and why it is so cumbersome here?! And after that I have learned list comprehensions and understood that I don't need map and filter in Python, as Python has different way to solve my problems.
JS is a language which is also driven by community, and in the end it is one big features trash can. They add and add and add new syntax to the language making it bigger and bigger, harder, more complex. Who cares that language syntax will need to be described in 1000 pages documentation, you want more features, and this is the only thing you care about.
Thank you for thorough comment! I agree with most of statements.
Though I don't think you argue with main premise of the article: dictatorship+cult. It sounds more like you are trying to defend it as the best of way of designing a language.
I have mentioned specific cases where dictatorship laughably failed. I picked those specific cases (out of many) because they are hard to argue with. If someone thinks those features were not needed because they are contrary to the main language design then why they are being added now? Isn't it even worse then - spoiling holistic design with alien concepts?
I would like to apply this argument to your thought regarding FP VS OOP design. I think you would agree that lately hybrid language design is taking the world. May be it is just latest trend and it's reasonably taking time for languages designs to pickup on this? The idea of hybrid FP-OOP is not innovative. Somewhere in 2002-2003 teachers at university were telling us (potentially future programmers) that "you will see more and more FP features in all languages" and then they were able to substantiate this prediction. If only some of Java core team could attend these lectures!
Finally, my selection of examples has another pattern. It's always referring to feature that is already implemented in competing (in some sense) language. When something appears in one of them isn't it natural and worth to (at least) consider same improvement for another one? You don't need to guess, you can experiment with it, try to use it in the other language see if it's worthy or not. In fact good software projects are doing it all the time - checking what competitors are doing. Somehow lambda functions weren't making sense for Java designers even years after they were implemented in C#. They are both OOP by nature, no FP VS OOP drama here.
"you need to really have all sides on your side, it is like politics" - well, there are some big differences with politics. If you make big mistakes as a decision maker (personally or in a group) you will be voted out. Unless, you know, you are a dictator...
I hope you understand that this article is to entertain reader. It's not one big complain, though you are free to view it the way you want. I'm happy as long as you read it and said "good read".
If only Python would have switch statement...
This has always been a weird one for me. I get why maybe you wouldn't bother doing it up front, since you can just use if/else, but it's such a common pattern that pops up...
Definitely a good example of your point in Python, though to be fair until recently they always admitted it was a dictatorship. And I think most of us Pythonistas will readily admit that it's kind of a cult, but it's a nice cult to be in! 😁
Hi! Interesting point about ECMA. Isn't that language that introduced classes on 18th year of language existence (1997-2015)? I remember people were complaining on JavaScript not having classes around 2005.
If it's that simple then make a language that isn't dictated by the creators. A democratic language where member developers decide on language features if you will.
I think you'll quickly find that some feature requests are antithetical to other features. To borrow from a title on one of my recent articles Σ(Reasonable Requirements) != Reasonable System.
When the language eventually gets conflicting feature requests, who chooses which features are added and which are not? And how do they choose? And who chooses who chooses?
I'm starting to personally believe that the best languages are those that allow extending the language with syntax that makes those libraries/frameworks feel like part of the native language. Anything else and, like you said, I'm locked in the cult of the language creators; however good that cult may be.
Don't get me wrong - it's not a call for revolution neither for democratic system of controlling languages design. This article is to entertain reader and to present some interesting (at least to me) thoughts. Also I would be glad to see less of a cult in programming.
I have chosen specific cases where decision to implement a feature at some point was no brainer. I don't think we can use argument that those mentioned features are antithetical to the language main design. If that would be the case then why they are being added now? Have they suddenly become not antithetical? Let's ask Rob not to add generics to Go before he makes this huge mistake :)
Great post, this one ->"I basically throw myself on the mercy of Gosling, Hejlsberg, Odersky, Breslav, Syme." xD
Amazing post, I laughed and cried equally, all true and one of the most objective posts I read those days 😅
Good content! I enjoyed