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.
Actually, that is a very good question and probably caused by the general immaturity of software engineering. Languages are not created in a planned, thought-through manner. Instead they are designed by human beings.
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.
> Actually, that is a very good question and probably caused by the general immaturity of software engineering. Languages are not created in a planned, thought-through manner. Instead they are designed by human beings.
> 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.
> the Le Corbusier Problem: A language has to be livable in order to be used
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".
> It sometimes feels like functional programming is the High Modernism of today, with the same issues.
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.
Just want to add Haskell, that was planned and thought-through for a very long time, and the purpose of it being planned was especially to slow down the proliferation of too many (research) programming languages, by providing a base/platform language that will be used for future research:
> 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).
I meant languages as a whole. To my knowledge no one has ever looked at the market and said: "Well, we obviously lack an interpreted functional language with a polymorphic type system, call-by-value evaluation and manual memory management. Let's make one."
Well, their first versions were, when they were initially introduced. Just consider how much legacy cruft C# has accumulated over the years, though. (Does anyone remember delegate?) If C# 9 was re-designed from the ground up, it would drop a lot of nonsense from the early days.
Interpreted vs. compiled vs. JIT-compiled is usually not part of a language definition, and can easily change without it being considered a new language.
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.
In some cases interpreted gives you more flexibility/possibilities.
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.
> those are implementation details of the library itself.
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.
Your assertion was that using (linking/calling) Boehm GC causes the C program to violate ISO C and thus in some sense stop being a GC'd C program. This is then a property of the interface of libgc. If you're relying on an implementation detail of a library that's not visible from outside the library to make an argument about the actual language of any program that calls into it, you're violating the library abstraction.
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?
My assertion was exactly this: "Boehm violates ISO C". A C program stops being an ISO C defined program when it calls into a translation unit that invokes ISO C undefined behavior, even if the call takes place through a good interface. If you call a library for loading a JPEG image, through a nice interface, but that library segfaults, your entire program has undefined behavior.
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 tend to be untyped for some reason, for instance
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.
The term "dynamically typed" is meaningless in the context of type systems. As you say yourself, a type system proves the absence of certain errors. A "dynamic" type system tells you precisely where and when such an error occurred. As such, these languages are untyped (or uni-typed which is just a more fancy way of saying that they are untyped).
I am aware that some type theorists insist on this distinction and it does have some some merits, but (afaik) type theorists didn't invent the word "type" and "runtime tags" are commonly and widely known as "dynamic types", even if they do work quite differently from static ones, so I always feel that insisting on this distinction is somewhat pedantic.
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.
> Languages are not created in a planned, thought-through manner. Instead they are designed by human beings.
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?
Central planning for languages is unstable. In fact, that's how we ended up with french in the first place. Roman Latin was tought and formally used in a "correct" way that slowly drifted from how normal people actually used the language. A few hundred years of this we get the fossilized academic/church latin and actually every day useful living languages like french and italian.
Yeah. Maybe it’s another way of saying that language is one example of an emergent phenomena or system.[1] In other words, it’s something that evolves, with new things arising, that emerges organically from experimentation and practice, due to certain environmental factors/conditions. Where practice and experimentation come before theory.
I have always thought that the hardware was responsible for the creation of each programming language. Well, not entirely, but a large part of the reason was the hardware and the new or different capabilities of the moment.
Hardware was certainly the reason for the development of new assembly languages, and for the creation of niche languages for niche hardware (such as CUDA and OpenCL for GPUs).
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?
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.
What I've meant it was my bias. I thought it were mainly the hardware components who drived the creation of most languages, but, well, Javascript wasn't created using this criteria :)
C was explicitly created as a portable assembly language to avoid re-porting the Unix kernel in assembly yet again. C++ was intended to be hardware-independent. Java is even more intentionally and explicitly hardware-independent. Early Python was POSIX-centric, but not hardware-centric.
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've seen several definitions of functional languages, but I presume you're talking about languages that encourage the use of pure functions and immutable data structures.
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.)
> Not sure though we can categorize blockchain as hardware or not.
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.
I'd say the two biggest factors are:
1. Change of resources / hardware / performance
2. Change of business requirements
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.
One reason is that programming languages generally try to provide backwards compatibility and doing so limits their ability to fix design problems.
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.
One reason that is often forgotten, although slightly touched upon via the ecosystem mention, programming languages are software packages, like anything else.
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.
I find the question really odd. It is like asking why people create new recipes or new music or whatever else - because they can. These are some of the best ways to introspect and think about patterns one might have been struck by and put forward a way to deal with them in their own ways.
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.
So you think "why create music" is an odd question too? I dont, but that's another discussion.
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.
No, that is your thought process that programming languages are meant to be productive. The person who creates, does so in many instances because they feel they want to create.
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.
Read again, I'm not disputing the fact that languages are created for fun. However when you start promoting a language and lure other people in contributing into your community, that (should) stops. Unless you specifically say smt like "this is a programming language for goofing around nothing serious", which is no PL author's pitch ever.
Making a new language is more like making a new instrument or a new cooking tool though. You've got quite a mountain to climb in getting people to use it, to the level where there's enough usage to to be worth the effort. Sure, you can make a new language as an exercise in creativity, but there's more than a few "serious" languages that all seem to have a mix of the same set of ideas (types, immutability, lambdas, etc).
I totally agree it is a climb, but only if that was the intention of the creator. We constantly forget that engineers can also be creators for their own sake.
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.
> I find the question really odd. It is like asking why people create new recipes
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?
Very good points here, but you have to keep in mind this is not a small group of people pushing ideas down the throat of others. There are perhaps 10+ million programmers in the wild if you include those who are not professional or full-time.
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?
This is kind of like wondering why there are so many fighter jet models. They are very expensive to make yet there is still such a huge variety. It's because there are a lot of humans on this planet.
However, we seem to have developed a special hell for declarative languages:
> 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.) ;-)
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.
Correct me but isn't that how innovation also works? Maybe there's some great idea hiding in these 10%. Following your logic: we shouldn't have Redis, Rust, Go... Making something new is sometimes also about allowing yourself to _remove_ things from the original inspiration, see Vue.js which was initially a lightweight Angular.
the problem is new sw also didn't fix the last 10%,
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
"You wanted a banana but what you got was a gorilla holding the banana and the entire jungle."
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.
"You can create a web site using Ruby, Java, Python, C#, Go or JavaScript" ... "and I swear I totally didn't forget the most used web programming language in my list here"
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.