I think, most importantly, we haven’t even seen anything like the one language to rule them all. I expect that language to be in the direction of Conal Elliott’s work compiling to categories.

A language that is built around category theory from the start, like you have many different syntactic constructs and the ones you use in a given expression determines the properties of the category that the expression lives in. Such a language could locally have the properties of all the current languages and could provide optimal interoperation.

BTW, I think we won’t be calling the ultimate language a “programming language” because it’ll be as good for describing electrical circuits, mechanical designs and biological systems as for describing programs. So I guess it’ll be called something like a specification language.

I think one major difference between math and computer science, and why we’re not going to see a lot of consolidation for a while (not even in 30 years, I don’t think), is that code that’s on the internet has a way of sticking around, since it’s doing more than just sitting in research papers, or providing a tool for a single person.

I doubt we’ll see 100% consolidation any time soon, if for no reason than that it’s too easy to create a new programming language for that to be the case.

Hardware changes might shake up this list, but I think it’ll take 30 years for that to be realized, but there will be a lot of programming languages that fall out of that.

We’re definitely still going to have COBOL in 30 years, and Java, and C. The rest, I’m unsure of, but I’ll bet that we’ll be able to recognize the lineage of a lot of the top 30 when we look in 30 years.

R seems like a write-and-forget language. But it roots to Iverson’s notation.

Did you mean to write J or APL? I understand R as the statistics language.

It is desirable that the combinator A | B recognises the same language as B | A as it is more declarative. Otherwise this can introduce hard to detect problems. For an implementation of parser combinators this is difficult to guarantee if efficiency is a concern. Yacc has a global view of a grammar and therefore it is easier to guarantee in a Yacc-generated parser than a combinator-based parser because each combinator has typically only a local perspective.

It’s definitely hard to produce good error messages from a parser generator. Especially from a parser combinator library because it’s built up dynamically and there’s no preprocessing stage.

The system in this paper does have a first class ADT representation of grammars though. Which is translated into executable code via staging (similar to my PEG library)

I believe your point about swapping A | B for B | A is exactly the problem the authors describe with parser combinators; for most parser generators, the resulting code should behave exactly the same. For any tool, the problem only arises if there’s ambiguity; if all strings are recognized by at most one of A and B, then clearly A | B and B | A will behave the same. Parser combinators have a tough time detecting ambiguity, and so will often just take the first one that matches, so in the case where there’s a set of strings recognized by both A and B, A | B and B | A will be treated differently by most parser combinator libraries. Tools like yacc and bison tend to not tolerate ambiguity, which means for each string, only one of A or B will recognize it, so A | B and B | A will behave the same way.

There’s also Nils M Holm’s books: http://t3x.org/

There are a lot of books on compilers, but not as much for interpreters (i.e. the bytecode compiler + dynamic runtime combo that many languages use).

Not a book, but you still might find this paper interesting: Engineering Definitional Interpreters:

Abstract: A definitional interpreter should be clear and easy to write, but it may run 4–10 times slower than a well-crafted bytecode interpreter. In a case study focused on implementation choices, we explore ways of making definitional interpreters faster without expending much programming effort. We implement, in OCaml, interpreters based on three semantics for a simple subset of Lua. We compile the OCaml to x86 native code, and we systematically investigate hundreds of combinations of algorithms and data structures. In this experimental context, our fastest interpreters are based on natural semantics; good algorithms and data structures make them 2–3 times faster than interpreters. Our best interpreter, created using only modest effort, runs only times slower than a mature bytecode interpreter implemented in C.

A rebase can force you to resolve many conflicts, each of which has a chance of introducing a bug. A merge can result in fewer conflict resolution and be preferable for that reason.

This is part of many Linux distributions - so easy to install. Latest commit f574668 on 20 Sep 2013 on the GitHub repository does not instil confidence that this is maintained.

I recently switched to Enpass, which is a conceptual clone of 1Password. Reason for switching was Linux support.

Interesting. My impression was that in the beginning Slack was getting popular among designers (UX, graphical) that still had fond memories of Stewart Butterfield’s Flickr and could get tech crowd to go along because they could keep using their existing IRC/XMPP clients. But like I said in my other comment, I don’t actually know.

As I see it, usability is all about the clients available. IRC does not mean glass tty at all.

And I wonder why would technical users run away from technical tools.

Rust’s macros currently don’t really work nicely with the module system - they all live in a global namespace and you have to use the odd #[macro_use] and #[macro_export] attributes to import and export them. It’s quite ugly. This will be fixed in Macros 2.0 though - from what I understand they are learning from Racket - I think it might be called ‘staged macro compilation’ or something… it is a non-trivial problem to solve though. Also, macros at the top level are not hygenic, I think this will also be fixed in Macros 2.0.

Another annoyance is the APIs surrounding procedural macros - it’s not as nice as working with Racket-style reader macros. You’re more working with a token stream, rather than an AST. Also, the API does not enforce hygiene as far as I know. Again, this should also be fixed in Macros 2.0.

Another frustration is that they don’t work nicely with rustfmt - because rustfmt doesn’t really know how the original macro author wanted to format them.

Other issue is that they have a restricted syntax that doesn’t allow you to create really nice looking language extensions. So a match! replacement would have to look like:

my_match!{ expr;
    pattern1 => expr1,
    pattern2 => expr2,
}

Rather than:

my_match! expr {
    pattern1 => expr1,
    pattern2 => expr2,
}

This is because we want tooling to have to understand macros in order to parse Rust code. I don’t think there is any solution for this.

All in all, I think macros a a nice addition to Rust, but they still feel a little ‘bolted on’ to the language, and could do with some improvement in the future. The Rust team knows this, and they are working hard to make those improvements!

This comment is a pretty good rundown of issues with the current macro approach.

The list is pretty good, I’d only add the call-site syntax (!) to the list of problems.

Just something I’ve observed, some of the popular languages are either strongly typed but have macros, or loosly typed and don’t have macros. ie. C/C++ vs Javascript. However, Java is strongly typed but doesn’t have macros, so take my observation with a grain of salt :)

The hash of the auto-generated tar files is not stable. I assume the compression level changes or the tar implementation to create them.

I imagine people made a similar arguments against objects in the early 80s. When languages did not natively provide support for objects, it was so inconvenient that people hardly ever used them, so they necessarily felt “we have extended the hierarchy upwards but I am not yet convinced”. Now we can’t get them out of our languages even if we try. (-:

Where languages make it — by design or by accident — easy to extend the language, language extension is rife. The paper mentions the case of JavaScript. Though JS was not invented with any meaningful metaprogramming capabilities, it left enough hooks that people have gone off and created all sorts of sub- and super-languages around it. This is also true in Ruby (“Ruby DSL” is a whole thing in itself), because Ruby also provides such hacks.

Furthermore, a growing number of new languages have been adding macros: Scala, Julia, etc. You can view what has happened in Racket as a natural destination of where macros end up. We’re just ahead of the curve by about 20 years; there’s a good chance that as people start to use macros more in those other languages, they will slowly recapitulate all the lessons that we’ve learned, and end up creating similar solutions.

It sounds like metaprogramming with DSL’s just with a new method. Language-oriented programming might be a more approachable term for that, though. If I heard it, the first things I’d think of were tools such as Rascal and Ometa that let one arbitrarily define, operate on, or use languages. That covers language part. Far as integration, a number of techs supporting DSL’s… probably a lot of LISP’s and REBOL… had a powerful language underneath one could drop into.

So, this seems like a new instance of old ideas they’re giving a new name. I do like how they’ve integrated it into a general-purpose, GUI-based, programming environment instead of it being it’s own thing like Rascal. An old idea I had was researchers should do more experiments in building things like Rascal or Ometa alternatives in Racket leveraging what they already have to see how far one can stretch and improve it.

1. Henk: A Typed Intermediate Language by Erik Meijer and Simon Peyton Jones contains a tutorial covering the Lambda Cube and can serve as a brief introduction to Pure Type Systems.
2. Lambda Pi: A Tutorial Implementation of a Dependently Typed Lambda Calculus by Andres Löh, Conor McBride and Wouter Swierstra is a worked introduction to implementing a dependently-typed lambda calculus, and has the resulting implementation available in Haskell which can be useful to follow along.

I’d recommend reading those in order. The Henk paper in particular is great, and despite being from 1997 I haven’t personally found any better introduction to the topic.

(That is, I recommend reading Henk before the actual link regarding LambdaPi or the reorganisation.)

It’s funny, I think that, too. But what is this adding beyond that? I’d like to read better ideas. I believe people are trying a lot ideas like staging, containers, reproducable builds, … We also have to consider what kind of software a ompany is creating: software that ships to customers or software that is pushed to a server.j

I really feel that many problems are solved, but not well documented, or at least the books and articles are still very obscure.

We’re thinking about most of those questions. I personally think multiple cursors are very powerful and useful, but recognize this is a question of user preference. Rich text (including variable width) is high on the roadmap, and support for Language Server not far behind. I’m not sure about equations, that seems possibly beyond the scope of the project, but it might be interesting to see how far that could go as a plugin.

And yes, how fast you can get your work done is ultimately the proper measure. It’s just a little harder to quantify, even with an Arduino :)