This content originally appeared on DEV Community and was authored by EronAlves1996
There are really hard things to discuss in general circles. In programming communities in general is idiomatism, specially in javascript community where we have some young minds with great ideas and boldness to present these ideas to the public and language designers.
I have to admit that if a language is discussed so often, with an engaged community, it paves the way for the evolution of the language faster, but sometimes some discussions and sugestions are non-sense.
These minds normally get in touch with another languages, like LISP and Ocaml and language design theory and they think that some of these concepts should be incorporated to the main language, thinking that, by the time they are included, will hapilly accepted and used actively by the community, and I think that we should separate some variables here that should be considered when we talk about language design.
Language Philosophy
The first item is the language philosophy. Companies in general have a Mission, Vision and Values declaration for the company, that describe what the company aim to be. The philosophy of the language describes how the language is intended to be used, and often, it's not explicited.
The rare case where the language philosophy is clearly explicited is Python, which aims for simplicity and explicitness, and I think that all programmers should read it's philosophy, because has great programming guidelines in general.
The other languages philosophy can be found on it's homepage, except for the languages that don't have homepage, like javascript. But for this language, we found in history that javascript is aimed for browser scripting. Today, it's not true anymore, and the community ressignified the philosophy to aim ergonomics.
Idiomatic Use
I think this topic is highly controversial because the idiommatic use isn't any thing craved in stone, but it's the organic use of the language: how the people is using?
The idiomatic code conveys better communication of the intents and an uniform usage, that other programmers can read this same code and understand the flow. Because of that, some ideas have high probability to not be used.
I found this page of idiomatic javascript and I see that the codes and guidelines don't mirror how javascript is written today. Formatting today is given by Prettier rules, no-one (except senior dinossaurs) uses var and prefer const or let, many prefer function expressions than declarations, types are typechecked with typescript in conjunction with runtime schema validators, and now, we have React, which is the standard front-end framework and adds many rules for what we know as idiomatic code.
Language Contracts
Javascript, Golang and Java are great examples of backward compatibility contract, and this thing is very difficult, because you can't remove features, nor modify hardly them. The language should exibit the same contract for the features that exists now, so language designers should only add new features or refactor existent features without modifying it's contract.
Python don't have this, so we see the breaking changes from Python 2 to Python 3. The same happened in Scala, from Scala 2 to Scala 3.
Risks of new features
Adding new feature to a language is very difficult.
As a language designer, I should think that this feature will be useful for a good portion of the community, in a hope that it will found some adoption, and maybe be incorporated in the organic institution of language idiomatic usage.
Also, I should think: is this feature consistent with the actual philosophy of the language? Philosophies can change, just like Java that are going to a direction for Data Oriented Design, and trying to have some drive into stateless services (not good yet for it, but really good in enterprise monoliths).
I should think too: this feature will break any existing contract? Even if I don't have the backward compatibility contract, changing API's very often indicates the language is not stable, and anything unstable don't go to production.
What I learned and think about it
- Languages don't evolve as fast as we like, and this is good, because stability is a very important factor for the community and all the ecosystem that evolves around the language;
- Some portion of idiomatism is built around language concepts, but not everything. Java getters and setters is idiomatic, but it's not a Java language concept, but a Java beans concept and it paved it own way to the community preferences;
- The majority of sugestions for a language should not have been proposed to start, because they don't take in consideration philosophy or if the feature brings benefits for a great portion of language users, increasing the probability of not being idiomatic and relegating the feature to ostracism;
- Backward Compatiblity is hard.
This content originally appeared on DEV Community and was authored by EronAlves1996
EronAlves1996 | Sciencx (2025-02-27T03:23:44+00:00) Language design and Idiomatism. Retrieved from https://www.scien.cx/2025/02/27/language-design-and-idiomatism/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.