https://news.ycombinator.com/item?id=37164243

Many languages in the Lisp/Scheme family have some kind of inheritance or interfaces, including Common Lisp, Dylan, Racket, Kawa, and many more. However, this hasn't been standardized for Scheme. R7RS-small has a mechanism to define new data types (records), but they were limited in functionality to C-like structs.

I (and others in the community) felt (and feel) that it is premature and unwise to add a bunch of new libraries for new data types until or unless we have some kind of framework for inheritance or interfaces. Others in the community (including the former chair) felt this was unnecessary and perhaps inappropriate for a language with the goals and history of Scheme.

There is no clear right answer or consensus for how to go forward, which is part of what caused things to bog down.

I just want a language with S-expression syntax and a proper numeric tower (like Scheme), with modern HAMT-based immutable collection types (like Clojure), and a native JIT so I don't have to mess with Java or JavaScript.

Does Racket fit the bill now?[1][2] Coming from Indiana, I was happy when they announced the move to Chez.

I was heartened by a post here yesterday about implementing a numeric tower on WASM.[3]

[1] https://docs.racket-lang.org/hamt/

[2] https://docs.racket-lang.org/guide/performance.html

[3] https://news.ycombinator.com/item?id=37158821

https://www.graalvm.org/latest/reference-manual/native-image...

I loved playing with scheme in my university days 20 years ago, and loved how one can make up any fancy programming concept using call/cc and dynamic-wind. Except if you want to have multiple implementation of some protocol or collection. Hand roll your own object model or dynamic dispatch mechanism? Hard to make it scalable, composable and compatible with other projects.

The Achilles' heel of every Lisp is dealing with any data structure that isn't a linked list. I'm talking aref, setf+aref, vector-ref, vector-set!, char, etc. It's all just a huge pain when compared to any other language (Python, Ruby, JavaScript, Java) that has syntax for arrays, hash maps, strings. Solving the generalized "map" or "length" is really only solving one side of the problem. The other side can't be solved because the language is s-exps and "everything is a function." It would fundamentally cease to be Scheme at that point.

It gives you protocols to define a set of related methods, without any restriction on the underlying data structure.

It gives you defrecord & deftype to define composite associative data structures, which the fields in an object are.

Then you can combine these in various ways, giving you all sorts of polymorphic code.

Clojure even has multimethods for cases, when a single operation should happen different ways, depending on some aspect of an arbitrary data structure. Someone defines a transformation function from arbitrary data to some other data to dispatch behavior over, then anyone can add define behavior for new dispatch values.

Why not copy these approaches?

I think is the whole point of Scheme community always having been a different set of folks.

In a way, it is like the C versus C++ communities of parenthesis based languages.

http://dpk.io/moderncomputers

Here's an index of articles:

http://dpk.io/articles

> § Indeed, the small language doesn’t even enforce bounds checking, even though almost all implementations do it. Such are the sacrifices for a language which might be expected to work on a tiny microcontroller. ↑

Okay but nobody in their right mind is writing Scheme for microcontrollers. I don't mean that nobody is doing that, but that the people who are are fringe weirdos whose desires should not be allowed to disrupt the evolution of the language for the rest of its users!

But it's maybe worth noting that using Scheme metalanguage abilities to generate non-GC target code for a microcontroller could be very sensible.

For example, you have nontrivial control behavior, and there's a short lead time on the controller or device. So, you could define a macro/minilanguage to support modeling the behavior in terms of Harel Statecharts, and initially (for very quick development) have that expand to executable normal Scheme code, for development/testing/simulation. Then, once you've gotten the behavior you want, you tweak the macro/minilanguage a little, to also expand to non-GC target assembly, for the microcontroller dev board or device that you ordered when you started.

(Racket syntax extension and submodules are especially nice for doing something like this, but you can also do it with more basic Scheme.)

Nyxt browser is written in Common Lisp and is going from strength to strength. Think of an attempt to provide the power of Emacs, but built on Common Lisp, and obviously with the graphics and video support browsers have.

https://packages.guix.gnu.org/

GNU Guix has 24,207 packages available and is written in Guile Scheme. The name comes from "Guile Nix", as it's based on Nix, so functional packaging, roll-backs, reproducible builds, etc. That might not be your thing, but it's definitely a very active and "successful" operating system.

https://shinmera.itch.io/kandria

And a last one just for fun, I haven't played it yet but Kandria was written entirely in Common Lisp, and looks very cool.

I think this is Conways law in action: See W3C, Whatwg and C++ standards committees. The work of specification difficult and the work is complicated and hard. I've never written a standard but I imagine it's very difficult.

I've thought how we can use Conway's law directly to engineer technical and social systems that are robust and meet people's needs.

One of my ideas is that for a group of different individuals and differing interests and priorities to collaborate, you need to recursively define collaborations and treat them as portfolios where the traversal of those collaborations/interactions is a standard, like Git.

What do I mean?

I want X, so I announce I'm doing X and how I'm going to do it and I do X. Then I publish X. Then someone says I want that, can I import it. X isn't to their tastes, so they announce they're going to change it to do Y. Or they negotiate with the author of X to change it to do Y. This is a collaboration between those two entities, it's a portfolio of collaborations. That's a standard right there.

The doing X is the important part.

In other words, the collaboration between parties is reified communication and agreement that is actually imported and used.

Otherwise you get this https://xkcd.com/927/

Attempting to do the thing and doing the thing (implementation) are inseparable from standard work I think.

This can be much, much worse if it involves anything that is not purely software, you can't adapt older hardware using a standard (let's call it notUSB) to iterate over an improved notUSB-with-appendages, and if notUSB-with-appendages required modifications incompatible with notUSB you just created 2 standards that don't solve a general problem.

Standards is something that a lot of people have thought about over centuries, any improvement on the process has probably already been considered by many smart folks so I don't think there's a simple coordination solution to it.

I've tried thinking about the interactions of features and permutations from a programming language perspective.

For example, targeting windows, mac, linux with the same code or the interactions between garbage collection, async, multithreading.

If I import a library in a package manager and the library is updated, my code breaks. Or if there's a dependency to a dependency.

Or if someone does an exception in a loop or switch statement and uses "break".

It reminds me of the expression problem.

How do you prevent all these cases leading to spaghetti code?

What was the Kurt Vonnegut reference?

[0] In the beginning, Scheme was created. This made a lot of people very happy and has widely been regarded as an excellent idea.

[1] https://www.goodreads.com/quotes/660696-so-it-goes-unlike-ma...

Think of it this way: "So long, and thanks for all the fish" is a Douglas Adams reference, but mentioning a dolphin isn't.

I do agree "So it goes" is more of a stretch here especially since dpk seems to live in Germany and it's a common translation of "So geht's" which may be more common in Germany than "So it goes" in primarily English speaking countries. I.e., how "perfectly ordinary" may be reader-dependent. I think it's a stretch supported by the Adams adaptation two paragraphs earlier, though. In primarily English speaking countries it is "signature enough" that they use it for the Vonnegut Library: https://www.vonnegutlibrary.org/so-it-goes/ , but sure it comes up a lot more than "thanks for all the fish". I think these are disputes of degree more than kind.

TL;DR - I stand by my guess, but you'd have to ask dpk to be sure.

EDIT: and Vonnegut's parents were German - so, this may also just be V being an "ambassador" making the more "perfectly ordinary" in one domain more "signature" in another domain. It happens.

It seems like the 'small' profile matches what I expect from Scheme's brand: useful minimalism.

The 'large' profile seems off-brand. I get why it would be useful to have a Python-like experience (where 80% of problems can be solved with the stdlib), but doesn't that describe Racket?

I'm not suggesting that a batteries included standard Scheme would be a bad thing. It's just that it pretty much already exists (Racket started as a Scheme).

It was commissioned by the Parliament of England to settle theological disagreements between the Church of England and the Church of Scotland ( the progenitors of the Anglican and Presbyterian denominations respectively ) which were a major component of the English Civil War.

super short version - the Presbyterians wrote most of what came of the documents and ratified it completely, the Church of England red-lined it heavily and they never adopted it in full.

[0] https://en.wikipedia.org/wiki/Westminster_Confession_of_Fait...

Wouldn't there be some middle ground where you have a tiny language and a unifying library/plugin system that would allow libraries to work across implementations (given some API/restrictions). So much like we have C++ and Boost or C and various C standard libraries, it would be possible to have any number of small Scheme implementation that could, if the developers wanted to, pull in a larger standard library, of which there could be many. Each Scheme implementation could then opt to develop and distribute a standard library with their compiler or simply refer to any number of third party standard libraries.

I've noticed this trend in a lot of technology fields of late.

I hear a ton about tech layoffs, and yet highly competent people still seem rare.

Why not support old features of the language in the new version of the compiler/interpreter? This seems to be particularly feasible in Lisp/Scheme family of languages due to the fact that ASTs are edited directly in source code.

For example, each library declares its target version of the compiler, then newer compiler first translates the library to new syntax, then integrates it with other dependencies.

What's wrong with this line of thought?

So let's assume there was wide spread consensus that it's a terrible idea and it should work like every other programming language. There is really no obvious way to simply "convert to the new syntax"? And trying to have "go with nil interfaces" library interact with "go with normal type system" would be it's own can of worms.

Like in this case, the only realistic path I could see would be you deprecate it, then you start warning, and then in like 10 years or something you fully remove it?

For the "more": you can do it not only for other dialects of the same language, but also for very different languages. And often to make them interoperable between languages.

(For one simple example, long ago I made a fairly simple `#lang sicp` that translates the old dialect of MIT Scheme used by the SICP book, to Racket, using some simple syntax transformation and the module system.)

Sometimes there is really no substitute for getting things right from the start.

I thought it would be possible to deterministically translate R^(n-1)RS to R^(n)RS

R6RS was decided by the majority.

What if we just did something where R7RS was decided by 2/3 vote?

If you have multiple adversarial commercial implementers for something, a standard makes perfect sense. It's still a lot of work, but necessary because otherwise, you wouldn't get things to interoperate at all. That's true for things like HTTP, or Bluetooth, or JavaScript, or C++.

But for a community project, having one blessed implementation and iterating quickly has proven to be the most successful model, in my opinion. I can point towards Python, Rust, even PHP for examples. Even Haskell, which started out with a written specification, has at this point de facto been forked into the much richer language called "whatever GHC understands".

I think having r7rs large would eventually make the language more interoperable.

That's not how Scheme works, and I think it's important for both Scheme and PL research/design groups in general that they move the way they do.

Each Scheme implementation is in fact its own language, with its own goals, focus, community, etc. E.g. Racket has very different goals (like PL research, education) from Stalin (aggressive optimization), Guile (ease of embedding), or Chicken ("real world" usage). Both the RnRS and SRFI processes are more like guidelines for the implementations to follow, to enable at least some of the code (usually libraries) to be portable.

When you're writing your Scheme program, you're usually not targeting "R7RS" or "R5RS + SRFI-1" or whatnot; you're writing and running your program using Chicken, it's a Chicken program much more often than it is a R5RS program. If you later decide to port it to Racket, you will usually have much less porting work to do, but you'll still need to figure out how to do many of the mundane things omitted by the standard, like OS threads or FFI.

It's much more useful to think of Scheme as a loosely-tied family of languages, pretty much the same way you can think of UNIX-like OS's. Your average UNIX will surely give you a /bin/sh and a printf and a malloc, but the really interesting stuff (like kqueue, io_uring, DTrace, etc) is why you choose to stick with one over the other, and what motivates different groups to experiment / innovate / contribute.

Why?

> the really interesting stuff

To me, the common standard is what is really interesting.

It's exactly what I meant ;) Scheme is different things to different people, I've shared my PoV and (to me) it doesn't seem like it disagrees with yours.

> All of the members of the Steering Committee have become somewhat less active in the Scheme community in recent years. Though we’ve seen occasional input from individual members, the Steering Committee as a body hasn’t taken any action since 2013 when the small language report was ratified. When the changes made in 2022 were being discussed, we got no guidance from the Committee at all. In short, we’re not sure the Steering Committee exists as a single, functioning entity any more.

How significant is this? Is there an actual process for forming a steering committee? From where does it derive its authority? If the current one is defunct, can they just form yet another one?

"Scheme has an outsized importance in the world of programming languages compared to its actual use in industry, because it has so often pioneered features that later broke into the mainstream.".

is doubtless true.

Scheme belongs to a list of at least two dozen historical programming languages that have introduced very important innovations and anyone who has the ambition of creating or improving any programming language should be familiar with all of them.

I consider sad the fact that all more recent attempts of introducing new programming languages appear to have been made by people who happened to have some brilliant idea about how to improve some feature of programming languages, but otherwise they seem to have little knowledge about past programming languages, so they combine their new good feature with various bad features from a few languages that happen to be popular now, due to various historic accidents, even if already many decades ago better alternatives were known.

Because of this continuous reinventing of the wheel, all the available programming languages include various combinations of good features with bad features, so none is completely satisfactory.

A "programming language features" wiki cataloging such features (and their pros/cons) would be amazing.

In C, the escape character for literal strings, as interpreted by the C compiler, is the backslash. ("\")

Also in C, the escape character for format strings, as interpreted by the printf function, is the percentage sign. ("%")

This is the correct way to do things, for the very obvious reason that neither the compiler nor printf can get confused by the input the programmer provides. Directions to the compiler look nothing like directions to printf.

But for some reason, this knowledge of how to define formats was completely forgotten, and so regular expression parsers were all defined to use a backslash as their escape character. There is no earthly reason you would want to do this. It causes many, many problems, and has no benefits, to use the same escape character for the compiler/interpreter and for the regex engine. But we're doing it anyway.

There are a few books about the history of programming languages, but they are mostly descriptive and contain little comparative analysis of the value of various features. Moreover because due to space limitations they have to mention only a part of the features of the languages that are described, the choice of what to mention and what to ignore in the description of a language may be not the most appropriate from the POV of an experienced programmer.

Therefore I have found more useful the original manuals of various programming languages, from when they have been launched, during the fifties, sixties and seventies of the 20th century. After 1980 the pace of innovations has slowed a lot and most of the languages that introduced those innovations are still used today, so finding documentation about them is no longer difficult.

While C was itself an innovative language, the fact that it included very few of the features of the languages contemporaneous with it ensured that many of those features are not available even today in mainstream languages, while other features have become widely used only after decades after their invention, for instance iterators have already been introduced in 1974, in the same year with C, but they have been revived only a quarter of a century later.

Fortunately now there are a handful of Internet sites dedicated to the preservation of the history of computers and programming languages, from where it is easy to download most of the old documentation.

Program language design is also:

   - Performant compiler design
   - CPU/GPU hardware optimization
   - Programmer ergonomics
   - Large software project organization
   - Source code hygiene
   - Evolutionary flexibility
   - Platform management and organization

I agree! Those things you listed all interact with eachother.

I am still trying to get my head around orthogonality in design and how to design permutations/combinations that work together well and are flexible.

Start by listing out programming language qualities that are good/bad/intolerable for each of those other interaction categories, then work that backwards into a set of required features for a desired language.

E.g. X makes writing a Y compiler optimization impossible

Structured Interaction Programming: https://github.com/samsquire/ideas5#350-structured-interacti...

Knowledgegraph programming language: https://github.com/samsquire/ideas4#334-knowledgegraph-progr...

On structured iteration programming, it might be a valuable first step/prototype to see if you can generate a fact/association graph from historical discussions about programming language qualities.

Much has been written (and continues to be!) in many high signal:noise sources. And some lower ones.

(1) extracting a relationship graph between all mentioned qualities and (2) generating sentiment analysis on those relationships (even if positive/neutral/negative/unknown) might help bootstrap a more comprehensively-populated version that can then be refined.

While it has some very nice features, they are combined with ugly mistakes inherited from languages such as C.

For instance the need of using the address-of operator for function parameters passed by reference is ugly and pointless.

Moreover, the distinction between parameters passed by value and parameters passed by reference is a big mistake in the design of a programming language.

Already in July 1977, the DoD Ironman requirements for computer programming languages have shown the only right way of classifying function parameters, i.e. in 3 kinds, in, out and in-out (this had been inspired by the language Jovial, previously used in some DoD projects, but Ironman has improved upon the Jovial version of parameter specification).

When any function parameter is specified as belonging to one of these three kinds, then it is irrelevant whether they are passed by value or by reference. That is an implementation choice that belongs to the compiler and which is completely transparent for the programmer (e.g. the programmer does not care whether an in-out parameter is passed by reference, i.e. the function receives a pointer which it uses to modify directly the parameter, or it is passed by value, when the function receives a copy of the initial value of the parameter and at function exit the final value of the copy is copied back to the caller).

Besides the burden imposed on the programmer to care about how parameter passing is implemented, the failure to adhere to the Ironman requirements may cause serious performance degradation.

The ugliest parts of C++, which, especially before 2011, were frequent causes of confusions, bugs and low performance, derive from the failure of C++ (inherited from C) to distinguish the out parameters from the in-out parameters.

To work around this misfeature, which is especially important for an object-oriented language, C++ had to invent some kinds of constructors that would not have been needed otherwise, it also had to handle constructors in some special ways, different from the other kinds of functions, and then it had to continue to invent new tricks for fixing performance problems, like move semantics.

The inappropriate way of classifying function parameters is just one example of many programming language defects that are still widespread even if the right solutions were known fifty years ago.

It would take more space to explain the implications for OOP of distinguishing out parameters from in-out parameters, but the main result is that many redundant operations are avoided automatically and effortlessly, while the C++ compilers have needed several decades of improvements until they have become sophisticated enough to avoid such redundant operations when handling big objects, like in libraries that implement operations with matrices and vectors, and the compilers still need considerable help from the programmer, who has to specify details that should not have been his or her concern.

100% of your examples are things that you seem to think have exactly one correct answer, but which people actually have different preferences on and different reasons for choosing different approaches. I promise you that Graydon Hoare was familiar with the concept of in, out, and in-out parameters when he started working on rust.

None of this means that any language is perfect, it's just that you're ascribing things to ignorance that are far more likely to reflect differences of opinion on subjective questions.

Nevertheless, I have been careful to not choose an example of this kind, but one where there is no doubt about what is right and what is wrong.

I am curious how do you justify that it is a good thing for a programmer to waste time to think whether a function should be invoked as f(x) or f(&x) and to waste time and page space with writing and reading "&" symbols, when this wasted time cannot bring any contribution to solving whatever problem needs to be solved.

Choosing whether to pass parameters by value or by reference is a problem of the same nature as the allocation of the hardware registers, which does not belong to a high-level language. The C keyword "register" is now obsolete, but the parameter-passing method should have become obsolete at the same time. Of course, for this to become possible, the direction of the parameters must be specified, to allow a correct compiler decision. When the direction of the parameters is specified, "const" no longer needs to be specified, because it is implied by "in".

Moreover, like I have said, any language that does not distinguish out parameters from in-out parameters, but which nonetheless allows the definition of new data types, together with mechanisms for their allocation, initialization, and deallocation, becomes excessively complicated, because it must add a special kind of functions that support one "out" parameter, i.e. the constructors, despite the fact that normal functions do not support such parameters, and then for each new type several kinds of distinct constructors and operators are needed, e.g. copy constructor, move constructor, assignment, which would not have been needed otherwise. When out and in-out are distinguished, assignment is not an operator, like in C++, but only a syntactic separator. In languages like C++, the programmer also needs to annotate some operations, so that they will use the kinds of implicit constructors that will be efficient in that context.

So if the defined data types can be used in any ways in which primitive types are used, then the mess of C++ is unavoidable. If there are restrictions on how the defined types are used, e.g. when operators cannot be overloaded or when various other such restrictions are enforced, then some of the complications of C++ can be avoided but such restrictions are even less desirable.

So between a single super simple rule of specifying in all function prototypes whether the parameters are in, out or in-out and having to keep in mind a great number of rules of how to deal with constructors in general and with several kinds of special constructors, in order to achieve acceptable performance when handling large objects, I do not see how there can be alternative views about which is right and which is wrong, except when they are based on lack of familiarity with the right solution.

When out and in-out parameters are distinguished, there are no constructors as a special category and no worries about them. An object can be initialized with any function that has an out parameter of the correct type. The only constructor is the default constructor, which is an ordinary function that needs to be specified only so that the compiler will invoke it implicitly when there is no explicit initializer.

Well, I understand that you struggle to see how it's possible, but it just is the case that people disagree with you about this stuff, not out of ignorance, but simply by coming to different conclusions than you. I certainly understand that it's frustrating; I have tons of views of all kinds that I think people should see are objective truths, but maddeningly they do not. But that's just how it is!

For what it's worth, if I designed a programming language, you would be a bigger fan of its parameter passing solution. But there would probably be ten other things you wouldn't like! There just isn't a universal truth about this stuff, people have all sorts of different preferences along every axis of language design.

What are they? Or, where can I go read something more about this? Any tip-offs greatly and sincerely appreciated.

I'm relatively new to programming, and have been focused mostly on Lispy ones (Emacs Lisp, GNU Guile, and most of all Common Lisp), so in browsing the propaganda around these languages, I'm constantly running into things that were allegedly pioneered in Common Lisp in particular.

Would love to read about the 20+ other languages with similar histories of innovation.

Heinz Rutishauser (1951; the first form of the "for" loop); IBM Preliminary FORTRAN (1954-11-10); IBM FORTRAN (1956-10-15); IBM FORTRAN II (1958); John McCarthy, AIM-001 (1958-09); John McCarthy, AIM-003 (1958-10); John McCarthy, AIM-004 (1958-10); IAL (1958-12); John McCarthy, AIM-008 (1959-03-13); LISP I (1960-03-01); COBOL 60 (1960-04); ALGOL 60 (1960-05, 1960-06-28); Edsger Wybe Dijkstra, "Recursive Programming" (1960-05-11); JOVIAL; "A Programming Language" (Kenneth E. Iverson, 1962-05); IBM FORTRAN IV (1963); CPL (1963-08, 1965-10, 1965-11-29, 1965-12-20); SNOBOL (1964-01); BASIC (1964-10-01); "Definition of new data types in ALGOL x", John McCarthy (1964-10); IBM NPL (1964-12); "Record Handling", C. A. R. Hoare (1965-11); EULER (1966-01); SNOBOL3 (1966-03-04); Algol W (1966-06, 1968-03); IBM PL/I (1966-07); BCPL (1967-07-21); PL360 (1968-01); SIMULA 67 (1968-05); IBM APL\360 (1968-08); SNOBOL4 Version 2.0 (1968-10-07); ALGOL 68 (1968-12-20); BLISS (1970-01-15; 1971-12); MACLISP (1970-03-01); Pascal (1970-11); B (1972-01-07); C (1974-01-15); Alphard (William A. Wulf, 1974-04-30); SCHEME (1975-12); Modula (1976-03); Mesa (1976-10); IRONMAN (1977-07); ALGOL 68RS (1977-08); Alphard (1977-08); CLU (1977-08); Mesa Version 3.0 (1977-10); "Communicating Sequential Processes", C.A.R. Hoare (1978-08); Icon (1978-09-29, 1979-04); Ada (1979-06); Bjarne Stroustrup C with Classes (1980-04, 1982-01); Modula-2 (1982); C++ (1984-01-01); Occam (1985); ANSI X3.159-1989 "Programming Language C" (which introduced "enum");

Also the language ML and its derivatives are important.

By innovation I mean either a new feature that could not be expressed directly at all in previous languages, for instance CPL has introduced "break", or a new kind of syntax format for expressing a feature that already existed in previous languages, for instance MACLISP has replaced "(QUOTE X)" by "'X". The dates correspond to language versions that introduced innovations, not necessarily to the first version of those languages.

And yet the list of features given to illustrate that point in the article consists entirely of stuff which is not in fact mainstream:

> Proper tail calls as the fundamental means of iteration is now standard in functional programming. Transformation to continuation-passing style as the basis of compilation likewise. Hygienic macros — now part of Rust and even being considered in Python — were pioneered by researchers who used Scheme as their test bed. That research became part of the Scheme standard in R5RS and R6RS. In functional programming, a lot of research is being done at the moment in algebraic effects, which might revolutionize how side-effects like I/O are done in languages like Haskell — and all this work is based on research into delimited control operators, research which was done by Schemers.

The lack of tail-calls in "mainstream" systems (i.e. the ones I get paid to use) is certainly very frustrating. Functional programming ideas are getting more popular, but some of them can be hampered by lack of tail-calls (e.g. using abstractions like Monad is reasonably common in Scala; but naive implementations will cause stack overflows due to the JVM's lack of tail-calls).

Hygenic macros and algebraic effects aren't common in existing languages (although the latter is often provided by libraries; again, I've noticed this creeping into the Scala world), but I've noticed that many (possibly even most) new programming languages have one or both of these. Indeed, regarding algebraic effects: about 10-15 years ago it was common to see languages created for algebraic effects (i.e. someone wanted algebraic effects, so they made a language which has them); whilst these days it's common to see languages "default" to algebraic effects (i.e. someone wants to explore an idea, so they make a language for that; their language does I/O using algebraic effects, because what else are they gonna do‽). I see that as a sort of consensus, that those are the "correct" way to go; if backwards-compatibility isn't an issue.

"Delimited control" is definitely mainstream. Unfortunately most languages seem to implement some weak, ad-hoc form (try/throw, async/await, for/yield, early return); then later have to add more; then more; rather than just implementing the full thing to begin with (e.g. shift/reset, or equivalent).

It now appears like many programming languages (Java, Dart, Swift, etc.) are gradually evolving into ML, e.g. introducing "modern features" like sum types, ADTs, pattern-matching, module systems, etc. (I'm less familiar with C#, but it seems like that's being dragged into the "modern" era by F#)

It was a time when computers were outrageously compute and memory limited, and it was the only language that didn’t have huge (at the time) compute and/or memory costs associated with using it. We weren’t ready for higher level languages at the time.

What lead to C dominating was the spread of Unix driven by Bell's legal constraints and then the BSD sockets implementation.

There were several similar languages that could have filled the same ecological niche.

C was widely available and de facto standardized (with an existing body of code as a forcing function + the existence of pcc). The others were not.

I hate return errors and I think that exceptions is the best thing ever (not checked, though).

Many people have the opposite opinion.

"WTF" reads petulantly and doesn't suit the subsequent piece at all. I had the strange experience of seeing the title and saying to myself, uh-oh, this will be some gossipy thing, I'll read it anyway just in case it also has some good information on the situation, and maybe I'll be proven wrong too.

Which I very happily was! The tone was mature, considered, informative, witty, etc. So I was thrilled to have read it, and more perplexed as to why/how the title ended up there.

Now, this is obviously in the purely-subjective category. Perhaps it reads very normally to others, and I just haven't managed to accept how normal "WTF" has become. Just thought I'd share my personal reaction, because the piece was otherwise outstanding, and honest feedback is presumably hard to get.

I was thrilled/appalled to learn about the ".io" domain too from perusing further the author's site; great to learn that. Hats off.

It's more like people are addicted to drama. Following something like this when you don't use Scheme is like watching reality TV. It's human nature.

Is this an currently escalating tendency or has it always been like this? I mean the human nature has always been there but is our current social media landscape amplifying it to 11?

Seeing this happen to scheme whose whole purpose is the ability to create languages is bizarre. I can understand a fight like this over gcc or Linux,a fork there isn't something a single person can do as a weekend job. Scheme on the other had is absolutely something a single dev can design and implement in a few months worth of weekends.

I could believe that society has changed the way it approaches conflict. But, I'd think social media stuff changes the shape of traffic/attention.

I would think people are not inclined to be curious to hear both sides of some conflict.

Committees don’t lend themselves to coherent and consistent overall vision

  > After the release of Miranda by Research Software Ltd. in 1985, interest in lazy functional languages grew. By 1987, more than a dozen non-strict, purely functional programming languages existed. Miranda was the most widely used, but it was proprietary software. At the conference on Functional Programming Languages and Computer Architecture (FPCA '87) in Portland, Oregon, there was a strong consensus that a committee be formed to define an open standard for such languages. The committee's purpose was to consolidate existing functional languages into a common one to serve as a basis for future research in functional-language design. [...]

In my experience, real-world Haskell requires enabling half a dozen language extensions, most of which have only been implemented for GHC and some of which are mutually incompatible.

Over the years Haskell has evolved from a well-defined language into "anything people managed to get merged into Haskell". Learning it is now an absolute nightmare as you are basically required to understand a dozen poorly-documented extensions to use even very basic libraries.

I don't know of any. Could you please name some?

> Learning it is now an absolute nightmare as you are basically required to understand a dozen poorly-documented extensions to use even very basic libraries

Many extensions make Haskell easier to learn since they remove unnecessary restrictions imposed by the standard.

Until the introduction of DerivingVia in 8.6.1 it was impossible to tell Haskell which deriving strategy to use - which is extremely annoying when one library requires the one, another library requires the other, and due to issues with orphan instances you have to use them in the same file.

> Many extensions make Haskell easier to learn since they remove unnecessary restrictions imposed by the standard.

I completely agree, and Haskell 2010 is obviously lacking. Unfortunately, there are also a lot of extensions which people have abused to their fullest extent to create completely unreadable code.

Things like UnicodeSyntax and all the syntax overloading are heavily overused, and you simply can't expect a beginner to immediately grok phrases like "if OverloadedLabels and MagicHash are both enabled then x#y means x# y, but if only OverloadedLabels is enabled then it means x #y".

And of course there's the whole cuckoo's egg of Template Haskell just waiting to blow up in your face...

I have to nitpick a bit though. You said "real-world Haskell requires enabling half a dozen language extensions ... some of which are mutually incompatible". 8.6.1 is 5 years old at this point, so the conflict between DeriveAnyClass and GeneralizedNewtypeDeriving is hardly a pertinent example. The conflict between OverloadedLabels and MagicHash is even less of an example, because the average real world Haskeller never uses MagicHash (and rarely OverloadedLabels: I've never used it once in 10 years of professional real world Haskelling).

Sometimes what an established language needs is mostly "write things down, keep all the implementations moving in the same direction, don't make big changes or break compatibility", and in that situation a committee can be a good approach. I think the C standards committee have overall done a reasonable job within that kind of remit.

A BDFL would attract a certain following, but some people are not interested in following anyone in particular - and Scheme is there for them.

I'm 100% certain that if a single Scheme implementation emerged as dominant, and appointed a single BDFL in charge of producing all blessed RnRSs & SRFIs, the remaining Scheme implementations/community would continue to do their own thing, because that's what Scheme is about. (See the general response to R6RS as an example.)

- R^nRS is short for Revised^n Report on the Algorithmic Language Scheme

- Algol60 was defined in a document called Revised Report on the Algorithmic Language ALGOL 60

- Revised^n is mathematical notation for Revised Revised ... Revised n-times.

The prose is a bit iffy, but I'm just happy it managed to find the link between RnRS and Algol 60. It's something I didn't manage to find with just google.

> The title is surely a reference to the AlgolSixty report ("Revised Report on the Algorithmic Language Algol 60")

First page of Google results for "rnrs scheme meaning". No quotes, just those three terms. Also the Algol connection can be found in R3RS:

> Dedicated to the Memory of ALGOL 60

-- https://standards.scheme.org/official/r3rs.pdf