DEV Community

Discussion on: Programming Language Dictatorship

macsikora profile image
Pragmatic Maciej • Edited on

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.

There’s always something simple missing - lambda functions, tagged unions, custom primitive types.

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.

Consider the lambda function feature which allows to filter a collection in one line. Lack of lambda functions leads to a bloated codebase.

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.

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.

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.

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.

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.

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

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.

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.

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.

vsapronov profile image
Vladimir Sapronov Author • Edited on

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