6 ms·

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-th

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.

bergstromm466 6y ago
> 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?
- wodenokoto 6y ago
  Parent means that there isn't a long term strategy for which languages needs to be developed.
  - bergstromm466 6y ago
    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. [1] https://youtube.com/watch?v=eh7qvXfGQho https://youtube.com/watch?v=eh7qvXfGQho
- pjc50 6y ago
  French is very much a centrally planned language.
  - progre 6y ago
    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.
msla 6y ago
> 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.
- pjc50 6y ago
  > 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".
  - msla 6y ago
    > 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.
coldtea 6y ago
>Languages are not created in a planned, thought-through manner 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.
- walkingolof 6y ago
  Scala 3, it has even its own calculus (DOT) to formally prove the soundness of its type system. https://www.scala-lang.org/blog/2016/02/03/essence-of-scala.html https://www.scala-lang.org/blog/2016/02/03/essence-of-scala....
- progre 6y ago
  > 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).
- indigo945 6y ago
  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.
- reirob 6y ago
  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: https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/history.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/...
- 6y ago
KMag 6y ago
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.
- Talinx 6y ago
  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.)
- kazinator 6y ago
  Boehm violates ISO C. There is no such thing as retrofitting "after-market" garbage collection into a C implementation, without violating ISO C.
  - KMag 6y ago
    Citation needed 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.
Tainnor 6y ago
> 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.
- choeger 6y ago
  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).
  - Tainnor 6y ago
    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.

bergstromm466 6y ago

> 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?

wodenokoto 6y ago
Parent means that there isn't a long term strategy for which languages needs to be developed.
- bergstromm466 6y ago
  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. [1] https://youtube.com/watch?v=eh7qvXfGQho https://youtube.com/watch?v=eh7qvXfGQho
pjc50 6y ago
French is very much a centrally planned language.
- progre 6y ago
  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.

msla 6y ago

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

pjc50 6y ago
> 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".
- msla 6y ago
  > 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.

coldtea 6y ago

>Languages are not created in a planned, thought-through manner 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.

walkingolof 6y ago
Scala 3, it has even its own calculus (DOT) to formally prove the soundness of its type system. https://www.scala-lang.org/blog/2016/02/03/essence-of-scala.html https://www.scala-lang.org/blog/2016/02/03/essence-of-scala....
progre 6y ago
> 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).
indigo945 6y ago
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.
reirob 6y ago
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: https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/history.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/...
6y ago

KMag 6y ago

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.

Talinx 6y ago
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.)
kazinator 6y ago
Boehm violates ISO C. There is no such thing as retrofitting "after-market" garbage collection into a C implementation, without violating ISO C.
- KMag 6y ago
  Citation needed 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.

Tainnor 6y ago

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

choeger 6y ago
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).
- Tainnor 6y ago
  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.