Why Are There So Many Programming Languages? (2015)
stackoverflow.blog
stackoverflow.blog
When someone who knows a lot about programming languages has a task tn do, they probably already know a language well suited to it. They also know how many person-years of work are required to turn a new language from a toy into something others would want to use. So, it's unlikely that such a person, needing to write a program, would create a language to write it in. There would have to be some use case that no extant language handles well.
On the other hand, when someone who doesn't know all that needs to write a program, they're much more likely to say, I know! I'll create a new language!
Therefore, most new languages are created by people who don't know what they're doing.
Also, I'm going to start all my HN comments with "Teeselink's observation on $topic" from now on.
But what if they were, in fact, planned?
Let us quickly come up with some obviously orthogonal properties of a PL: evaluation strategy (by value, by name, by need) memory safety (manual, automatic), type system (none, nominal, structural), and implementation choice (compiled, interpreted). That alone gives us 3x2x3x2=36 possible languages and there are a) many more orthogonal choices to be made and b) several subchoices (e.g., which garbage collector, or which kind of polymorphism in the type system, what kind of macros, etc.) - also some of these choics are not truly orthogonal to complicate matters even more (interpreted languages tend to be untyped for some reason, for instance).
All in all, it seems there should be hundreds if not thousands of languages even if we would design them like we design wrenches or screwdrivers.
What the heck does that mean?
Programming languages, like languages (English, French, Chinese), evolve organically to solve new problems, no?
Anyways maybe I misread it, and underlying it is your desire for the next version or iteration, because you’ve bounced up against some limits or boundaries with the current iterations?
> But what if they were, in fact, planned?
[snip good post]
There's also the Le Corbusier Problem: A language has to be livable in order to be used, and everyone's conception of livability is different, but few people desire to live in what could be defined as the logical minimum required.
Even mathematical notation is inconsistent and luxuriant sometimes; for example, we have sine, cosine, tangent, and so on, when we all know that complex exponentiation would suffice. That's a multitude of functions which are all non-orthogonal variations on a theme! What wastage! What profligacy! A truly austere system would have very few, if any, named functions.
But, of course, humans can't live like that, and few desire to try.
Very good phrase, thank you. It sometimes feels like functional programming is the High Modernism of today, with the same issues.
I've also tried to coin the "left handed scissors" analogy: not all developers are identical Promethean beings of pure intellect, they have different adaptation needs. The left-handed scissors are more convenient for left-handed people and less for right-handed people. Which ruins attempts to put all languages in a strict total ordering from "best" to "worst".
I find it rather natural, myself; maybe that's because I spend so much time making pipelines in the shell. As I said, different languages fit into different minds.
Well, some are. Namely, Algol, Scheme, Smalltalk, Java, C#, and famously Ada (And I've missed some, like Oberon, etc).
Those were planned, and thought-through quite well. And their later updates were also planned and thought out quite thorougly.
Other languages were more idiosyncratically designed by some (often single) person, and accrued features haphazardly over time.
Some of those are quite successful. Top examples, and very fitting of your description are javascript and php. Interestingly, both of those made nearly the same (in my opinion wrong) descission about comparison operators and "type juggling" (php parlance).
https://www.microsoft.com/en-us/research/wp-content/uploads/...
Many Lisp dialects include both compilers and interpreters. There was gcj and now Oracle's AoT for Java, etc. In the late 1990s, MIT's 6.270 robotics competition used an interpreted implementation of C. I haven't heard anyone claim that these implementation details should cause the implementation to be "not really Lisp", "not really Java", or "not really C".
Also, if you link in Boehm's libgc and start allocating via libgc, you've got (conservatively) garbage-collected C without violating any of the C standards.
For example in Julia you can define a function and compile it for all possible types. But what if you import a package with a new type? You have to recompile the function for parameters of that type or can't use it. Or if a function has 3 parameters and there are, say, 20 different types. That's a lot of combinations, compiling them all would be wasteful.
(I don't know how Julia handles these things internally so I might be wrong.)
The interface to Boehm GC is that you call GC_INIT(), then you get some pointers from GC_MALLOC() and GC_REALLOC(). Nothing in ISO C requires that a function returning a pointer must guarantee that pointer remains valid forever. Which section number of any of the ISO C standards do you think Boehm GC violates?
The implementation details of the Boehm GC certainly exploit implementation-defined behavior and there's likely some undefined behavior there, too. However, those are implementation details of the library itself. If Boehm GC were written in assembly, then it could function exactly the same and ISO C would be irrelevant to its implementation.
By this reasoning, though, any behavior is defined as long as we box it off into a library.
(By "defined" here, I mean "ISO C defined" not "declared to be working, and maintained in that order by a library vendor").
> If Boehm GC were written in assembly
Every instance of undefined behavior that doesn't prevent translation results in machine code. We can infer its behavior from the instruction manual, and write assembly source which produces the same code. Therefore, there is no such thing as undefined behavior.
A C program doesn't stop being a C program because it calls into a BLAS library that happens to be implemented in Fortran or some low-level library implemented in assembly.
Again: what property of the interface of Boehm GC breaks any revision of the ISO C standard?
A C program also stops being an ISO C program when it calls a function that is not in the standard C library and that is written in Fortran. However, that Fortran code can be well-defined Fortran, and the call can be taking place through a C-Fortran calling mechanism documented by the compiler suite. So that even though we don't have a definition of behavior entirely coming from ISO C (so that the program is undefined as far as ISO C is concerned), we can piece together a definition of behavior from ISO C and additional sources, like the Fortran standard and the reference manual for the toolchain.
We don't have any such definition of behavior with Boehm GC. The behavior is empirically validated. No compiler document says that it's okay to scan memory looking for pointers, as a documented extension.
Interpreted languages are dynamically typed because, in the general case, there is no compilation stage at which the type checking can happen. Of course, you can introduce extra static checks ahead-of-time (e.g. mypy for Python). Static typing is meant as a proof that a program is well-formed in some sense and that proof does need to be checked at some point before the program executes. (This is extremely simplified, of course.)
The use of runtime-types for other purposes, e.g. dynamic dispatch, id quite a different story. If I'm not mistaken, Julia makes heavy use of this, but it's still interpreted.
But yes, arguing about semantics never got anyone anywhere, what I wanted to highlight was that it's not just coincidence that interpreted languages are by and large dynamically typed.
However, I don't see new hardware as being the impetus for the creation of any of the most popular languages of today.
Do you mind elaborating on which languages you think arose due to which hardware capabilities?
There were Lisp machines by Symbolics, LMI, and others, but in these cases the hardware was bent to the language instead of the language to the hardware. Common Lisp and Scheme are intentionally hardware-independent.
I think Cray had a Fortran dialect that exposed vector operations, but I'm not sure how many people would consider that a new language.
I think programmer ergonomics/productivity and program correctness/safety are the two most common drivers for new (non-hobby) language creation, where the former is often expressed as a matter of taste/preference. (I suspect personal hobby languages far outnumber other languages, but we have no way of knowing how many of these exist.)
I think the driver there is that it's much easier to reason about (and prove properties of) pure functions. At first glance, that seems pretty clearly a correctness driver. Some strong proponents of functional languages would argue that bugs are a huge detriment to programmer ergonomics, so correctness also ends up being an ergonomic issue. On the other hand, people with lots of experience programming in imperative styles that encourage mutable state (such as many classical object oriented styles) find it uncomfortable to switch over to a functional style.
(I realize some languages, such as Scala, encourage a fusion of OO and functional styles, but mutable state played a big role in classical OO languages. For instance, Java missed a big opportunity by having the Map and List interfaces expose mutator methods instead of having MutableMap and MutableList interfaces that extend mutator-less base interfaces. In Java, immutable maps and lists usually end up implementing the Map and List interfaces, but having the mutators always throw exceptions. If you find implementors of your interfaces regularly subvert the contract you try to establish in this way, you've probably made a mistake in defining your interface.)
https://queue.acm.org/detail.cfm?id=3212479
https://en.wikipedia.org/wiki/CAR_and_CDR
Then Java was created as a way to waive C++ cumbersome dynamic dispatch, because high end hardware of that time could handle it performance wise. Then a huge number of scripting languages appeared basically saying: "let's do everything at runtime!".
There is another trend where correctness is the driving factor (Haskell, Rust). Proving correctness on large programs tends to be CPU/memory intensive, so in a sense that trend is also enabled by hardware.
I think in this sense, blockchains would be VMs, not hardware. Though, like the JVM, it would be possible to make a hardware (and presumably firmware) implementation of the VM.
The first one should be clear. E.g. why does Java has arrays and primitives? Because they were needed for better performance. As hardware gets better and better, we can use slower techniques that give us other benefits, for instance development speed.
The second one is trickier. For example scalability. It just wasn't an issue for most people some time ago, but now it has reached many more businesses. This means new problems occur, such as concurrency issues or failures that where negligible before. These need to be considered now and many newer languages offer techniques that deal with these problems better than languages before.
There's an interesting dynamic here; it is hard to see the design flaws of a language until it is widely used and common practices are established. Once that happens it is too late to change the design.
People occasionally try to fork languages to so they can break the backwards compatibility requirement, but I haven't seen many of those gain wide adoption (maybe you could say Python 3 is an example?). Instead there seems to be more success for languages that attempt to create a better version of an existing language but move far enough away from it to be an obviously different beast. I'm not sure why.
What companies that sell developer tools are after is building ecosystems and languages are the product to achieve that goal.
Like any product, differentiation comes into play, which is why even with standards in place, everyone ends up building their own extensions, which eventually grew up into other languages/products, where everything will be done better from the start.
People should always try new ways to deal with problems they see around them. Or generally be creative. I can not fathom what makes the author even ask this question.
Back to the original question, making programing language and making music are nothing alike in there purposes. Music are specifically made to be consumed while proraming languages or any kind of software/protocol/standard are meant to be productive.
You can argue that people make languages for their own amusement, those exist. However if a language rises to some sort of adoption there was definitely some amount of effort put into promoting it and convincing other people to use it. At that point a language ceases to exist for amusement purpose and become an investment that cost individuals and the whole industry a lot. It better has a good pitch.
Which is why there is an order of magnitude more super-little-known programming languages out there than the ones that dominate the professional world of programming.
A few languages get traction and grow. Rest are just creations from someone.
There are many many many little know programming languages. Only a tiny % get traction. This is the natural pattern to everything around us. Newtown developed Infinitesimal Calculus in the same period that most students study the subject. We cherish these as accomplishments because they become famous, but most do not become famous or even useful. It does not mean people should stop experimenting or creating.
We "can" do all kinds of things we aren't nonetheless doing. So the question is still valid.
Heck, even for recipes it would be a good question.
This analogy missed the point. It's about recipes written in a new language barely spoken by anyone, like elvish or klingon. Writing Romulan ale recipes in klingon is totally fine if you are targeting people on a star-trek convention, and want to start a romulan-klingon fight. But writing the only one documentation of a critical system in klingon at a public company sounds crazy, even if you can reduce the LOC (lines written) by 10% due to the nice and unique grammar of klingon (I mad this one up, I have no clue about klingon). Guess what, no sane person would want to work with that documentation, unique klingon grammar or not.
You just have to take a look at Esperanto, the "an easy and flexible language - created by Zamenhof - that would serve as a universal second language to foster world peace and international understanding, and to build a 'community of speakers', as he believed that one could not have a language without such a community." After 130 years still no one speaks it, and English is the common language in the western world. Which - considering its shortcomings - is like if everyone of us would mainly code in COBOL, just because everyone can code in COBOL.
tl,dr: normal human beings don't want to learn 2 new languages every year, just because [put a random argument here]. Why should we?
[edit: typos]
Someone creates a language because they might simply want to learn. Their friend picks it up, has fun, spreads the word. It either dies after a few months or becomes an edge case language in the stack of a company. Someone writes a blog and then it gets more traction.
No one actually intends that everyone should learn 2 new languages. But we live on a large planet, people forget that frequently. The social consciousness that is easily accessible from within US might not be in India. So people here might create a language for some issues that already have a language in the US. What is wrong in that?
> You can create a web site using Ruby, Java, Python, C#, Go or JavaScript. You can use C or C++ or Haskell or Rust. Or COBOL or Pascal or Perl.
So HTML has finally become the machine language of the web, a somewhat wasteful kind of byte code. (And JSX is probably like inline assembly in BBC BASIC.) ;-)
We have too many artificial barriers.
Developers end up using something and it does about 90% of the job. They say to themselves, "I will write my own software that does 100% and offer it to the world when I am done." And now we have another program on the junk pile of software. Rinse, repeat.
solution? add the last 10% to the existing solution (possible with open source) without reinventing the wheel completely, just to be able to stick a flag in the mud
Sometimes, it is better to have something that solves the 10% of the problem you are facing than something that solves 9 other problems you don't have but forces a cognitive overload on you because of the more general abstraction for dealing with those problems. Usually, you cannot solve all problems for all people and you need to make trade offs.
Reinventing the wheel is really a bad analogy for this. A car wheel is not a substitute for a bicycle wheel, a bicycle wheel isn't much good on a wheelbarrow, a wheel barrow doesn't help out much on a skateboard, on and on and on. The act of inventing the wheel defined its parameters and necessary characteristics so that (mechanical) engineers could have them manufactured to their specifications as needed for the thing they were designing. If I design a new wheel it isn't invention.
The similar "fit for purpose" notion in software is not widespread. Many of us somehow feel that implementation is more invention than manufacturing or design. The goodness of fit criteria are not often discussed or are difficult to define or measure. The things that sqlite can do that postgresql cannot and vice versa are important. They each leave some problems unsolved so that they can solve their chosen problems.
Unless you count all the Wordpress installs (where most webmasters don't write a line of PHP) it's not that popular nowadays. We're in 2020.
Anyway, it's besides the point. He's giving examples of languages you can use to write a website, not making a list of the most popular languages.
Way ahead Ruby.
>Unless you count all the Wordpress installs (where most webmasters don't write a line of PHP) it's not that popular nowadays. We're in 2020.
You'd be surprised. Outside of startup-land there are tons of PHP shops... And not just for Wordpress either...
Ruby, on the other hand, rose and fell along with Rails popularity...