11–20 of 77 posts
Is there even a meaningful definition of 'powerful'? I guess C# 4 is strictly more powerful than C# 2 since it only adds features, but how to compare the power of Haskell versus Rust? They are designed for different domains.
If I had to venture a guess about future development in PLs, there would only be one pattern that I find reliable enough: In a rough birds eye perspective, PLs have moved from hardware-specific things handling mutable state to more formally defined beasts fed by mathematical concepts. That's one trend I expect to continue, but then also not ad infinitum. In my view, Haskell is a good example of how you can overdo it, with the best intentions: concepts that are beautiful and frictionless in pure math become a cumbersome burden and an impractical cognitive load when translated too directly into a PL. I want more math in PLs, but I feel we haven't found a good balance yet. Maybe this turns out to be a moving target, too.
There are two languages I expect to keep their (niche) places for the foreseeable future: C and Lisp. Both are such a peculiar mix of properties that they are incredibly hard to beat in their respective domains. Maybe the same goes for Ada and Java, I wouldn't want to do any injustice :)
> Is BASIC more powerful than Assembly? I doubt it, you can do anything in assembly, and BASIC is deliberately limited [4]. Doesn't this definition make the "power" of all Turing-complete languages equal? > In other words, Lisp was the Flub of its day. A few years ago Flub was Haskell, and recently the new contender appears to be Rust, judging from the buzz. If the author thinks Haskell and, of all languages, Rust ar…
Earlier quoted context omitted.
> Doesn't then follow that JS is good Of course not, and, sure, Flash was a better alternative for a lot of time (but mostly for things outside of JS like HTML5 capabilities) C is not great as well, but between something good that doesn't do what is needed and a bad one that does guess what is used in the end.
I knew C; C was a friend of mine. Javascript, you're no C! When it appeared, C was a revolution in programming languages. It offered a combination of performance and expressiveness that simply outclassed anything else available (still true today, 43 years later, if more narrowly). It instantly became the most popular and held that position to this day, becoming a major influence on virtually every other popular progr…
Python existed in 1995, but I doubt it was very known at the time.
Ruby was created in 1995
Lisp is older, sure, but maybe there were concerns about the syntax and interpreter requirements?
"But, all things considered, it was as close to perfection"
Pascal didn't have a braindead way of dealing with strings. C's syntax is weird and prone to bugs, "if (a = 1)" being one example.
1. Compile times aren't great right now, but 20s for 2400loc is a real anomaly, and improving compile time is a focus of the team now that the language is stable. This is the only specific painpoint the blog post mentions with Rust, and its just a single anecdote.
2. The idea that Rust is a premature optimization is a weird meme. Faster, safer, more expressive. Rust is at least 2/3 for pretty much every 'mainstream' language. I would rather write Rust than any other language I know, and I would be more productive in it.
3. Rust is not a Flub language struggling to overcome a niche - not yet. Rust is a language that became stable 3 weeks ago and time has not yet told whether it will be 'mainstream' or not.
Rust has a memory model that includes some degree of manual management, like C (instead of malloc/free and pointer arithmetic, you have ownership and references). This makes it a poor first language, like C. But no one says C is a language for the 'elite' because you have to think about the memory model.
> Is BASIC more powerful than Assembly? I doubt it, you can do anything in assembly, and BASIC is deliberately limited [4]. Doesn't this definition make the "power" of all Turing-complete languages equal? > In other words, Lisp was the Flub of its day. A few years ago Flub was Haskell, and recently the new contender appears to be Rust, judging from the buzz. If the author thinks Haskell and, of all languages, Rust ar…
That's it, right there. One crucial point is that the elegant simplicity of the 'programming language power' rating is in fact full of messy bits and a multitude of dimensions.
Is the idea of a single language that's clearly better than anything else, for everything, a common one? If one thinks of languages as tools, it seems pretty obvious that different languages will be the best tool for different kinds of tasks. Are you writing a REST wrapper around an existing java toolset? Clojure's your friend. A cryptographic, secure communication library? Rust is probably (going to be? in a couple…
There's a lot of value in adopting one general purpose language as a company-wide standard, like Java. It doesn't have to be an excellent fit for every task, but it has to be adequate and not have any major flaws. That's harder than it sounds. I like the Rust approach (memory safety without GC), though Rust itself might not be the best possible realization of that approach.
The essay fluidly rotates between two points of view best expressed by two direct quotes: "Note: this is about tracking fashion, not a comment on the actual virtues of these languages." and "getting things done". I don't think those are synonyms or have much to do with each other so the close intermixing is a bit jarring. Often enough they oppose each other. They don't get along so its hard to use them as supporting arguments even if true.
Another observation is hard to quote but boils down to languages and paradigms are synonyms, which I disagree with. A language is a pile of paradigms wrapped up in some syntax to formalize it. You can write FORTRAN or perl in any language. Or functional, at least somewhat. Its easier to write worse programs than the language and very hard to write better programs than the level of the language. In that way LISP is the master language above all the others because it can express seemingly anything therefore if everything is beneath it, its above everything. The third paragraph is closest to what I'm trying to express and it comes very close to hitting the mark.
It would be interesting to see logic programming in a safety critical embedded space. I'm not sure if it would be "good" interesting or "train wreck" interesting. That would be an interesting suggestion for the second to last paragraph. If you define safety as solving a full set of safety constraints, then automating it would look like ...
Those are very keen observations and not commonly voiced in that combination. I can't remember the last time I read an article about the development of PLs that I agreed so much with. If I had to venture a guess about future development in PLs, there would only be one pattern that I find reliable enough: In a rough birds eye perspective, PLs have moved from hardware-specific things handling mutable state to more form…
First, you are lumping together trends in academia with trends in the industry, and the two are not always in tandem, though they certainly influence one another. For example, Go, a language that certainly goes against this trend, is gaining popularity much faster than any academic or academically-influenced languages (of course, it's easy to grow fast when you're small, but it's more academically inspired languages are just as small). This mixing of the domains which in reality is quite complex is also apparent in your examples. C is one of the most popular languages in use, and has been for a few decades; Lisps have been around even longer and has never broken beyond around, say 1% of production projects (except maybe for a very short while in the eighties).
Second, you say "I want more math in PLs" when referencing Haskell. While it is true that pure-FP, because of its relationship to some types of logic, lets you prove some properties about your code in the code itself, that does not make it any more mathematical than other languages and other approaches. For example (and I give this example often, but only because I'm really impressed by that language), Esterel, a language designed in the eighties is an imperative language with lots and lots of global side effects, yet it allows you to verify its correctness absolutely, and you don't even need to write the proof yourself (it verifies temporal properties that are especially hard to prove using PFP). Esterel and languages (mostly graphical languages) inspired by it have been used by the industry orders of magnitude more than PFP languages for domains where correctness is crucial. That PFP allows you to write some proofs in code does not mean that there aren't better ways to verify programs mathematically. PFP is the answer if what you're asking for is more second-order logic in your PL; it's just one of many if you're just asking for more math (in fact, it's just one of many even if you want more interesting type systems).
Also, it's hard to trace influences, but I believe that the focus on immutability that is finding its way into more and more languages is actually inspired by Erlang and later Clojure, two languages that have little to do with PFP, and a lot to do with the design of multi-core and distributed systems. It was not the current academic trend of pursuing the Curry-Howard correspondence as a software verification technique, but an industry solution for the problem of handling concurrency.