Hacker News Reader

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

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

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

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

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

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

Boehm violates ISO C. There is no such thing as retrofitting "after-market" garbage collection into a C implementation, without violating ISO C.

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.

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

French is very much a centrally planned language.

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.

Parent means that there isn't a long term strategy for which languages needs to be developed.

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