For those skipping to comments based on title alone, this isn’t really much discussion about a trade off. It starts that way and then goes “but with my favorite language you can have both!” And spends 3/4 of the article telling you about it.
The most value from this article is the clickbait title yielding some interesting discussion from people on that question outside of the actual article contents.
This article isn’t bad but the name is terrible and a bit clickbaity
Ha, funny, because I thought: "Both, of course. Like for example Schemes." and while Racket is not a Scheme according to the maintainers, it certainly shows the similar safety and power that other languages like it show.
I would say more convenient than Scheme. I can't think of any Scheme implementations that come with as much stuff as a standard Racket installation (before adding in extra third party libraries). Gauche, maybe, or Guile.
The biggest difference is that in Racket, cons cells, and thus lists, are immutable (the Scheme #langs like r5rs use a different incompatible type for their conses). There's other more subtle changes but that's the one most likely to bite people used to Scheme. Well, that and `if` taking exactly 3 arguments.
The literature on programming languages contains an abundance of informal claims on the relative expressive power of programming languages, but there is no framework for formalizing such statements nor for deriving interesting consequences. As a first step in this direction, we develop a formal notion of expressiveness and investigate its properties. To validate the theory, we analyze some widely held beliefs about the expressive power of several extensions of functional languages. Based on these results, we believe that our system correctly captures many of the informal ideas on expressiveness, and that it constitutes a foundation for further research in this direction.
in practice, turing complete doesn't necessarily mean powerful or equivalent. brainfuck and minecraft are turing complete but no one is trying to write business software in it. ergonomics matter
If I was to interpret that "strictly more powerful" statement, I would interpret it to be about how Racket's macro system works and what information its syntax objects carry. Or interpret it to mean the different languages it provides, like Typed Racket for example.
On the other hand I found using multiple cores much easier in GNU Guile.
I agree the title is a bit clickbaity but I don't think it's justified to dismiss the entire article on that basis. The author makes some very good points and while I had heard of Racket, I wasn't aware of how its macro system differed from Lisp & Scheme. Moreover, discovering you can implement type systems as macros[0] alone made reading the blog post worth my while. But as always YMMV.
Haha, yeah it’s a little clickbaity. Less clickbaity might have been “Safety and power needn’t be a trade-off”.
I wrote this out of some frustrations I had from a conversation with a user on this site about macros, actually. This is why I spend so much time on Racket. I’m also a PL researcher and I work with Racket a bunch.
It’s not just Racket where the trade-off shouldn’t be necessary, but Racket is a good example because it’s like one big exercise in making some powerful language features safe.
The thesis that safety and power are incompatible seems mostly a straw man, because there are very few cases when a tradeoff between them may be necessary.
For example adding to a programming language array operations in the APL style greatly increases its power while simultaneously increasing its safety by eliminating all bugs that can occur due to mishandling of indices a.k.a. subscripts that would be needed otherwise to access array elements.
There are a lot of other such examples where adding high-level operations increases the power of a programming language while also eliminating some classes of bugs.
The only kind of "power" that can conflict with safety is the necessity of implementing various kinds of low-level operations whose functionality is not provided by any high-level operation of that programming language, e.g. some that may need to access various data types as bit strings or to use directly certain features of the CPU that are normally ignored by that programming language.
In this case it is not actually "power" that is in conflict with safety, but the desire of portability, i.e. of independence on the architecture of the target CPU, which prevents the addition to the programming language of features corresponding to everything that a CPU can do.
For most features that are unsafe in practice, it might have been possible to define safer higher-level methods to use them, but the obstacle has been the lack of standardization, i.e. the fact that they may be implemented differently in every computing system, so it may be hard to design an equivalent feature included in a general-purpose programming language that could be mapped in an efficient way to what a certain hardware does.
Much of the lack of safety of some modern programming languages is not caused by too much power, but by too little power, because they have inherited the lack of power of the minicomputers and microcomputers of 50 years ago, where the restricted programming languages available for them had abandoned many of the powerful and safe features of the older programming languages, from 60 to 70 years ago, where it had been inconceivable to have a program where any computation error, like integer overflow, would not generate an exception, or where it would be possible to access memory through indices or pointers in areas not intended, also without generating an exception.
The lack of runtime error checks for a program is a lack of power, not a sign of power (while I use frequently languages like C or C++, I always compile them in the right way, enabling all runtime checks).
Many people care more about shipping (perhaps buggy) software rather than the theoretics of programming languages. I used to despise that, these days I think I understand it.
Still, I'm sad the industry is stuck with languages such as Python and Java, rather than say Racket and Idris...
The most value from this article is the clickbait title yielding some interesting discussion from people on that question outside of the actual article contents.
This article isn’t bad but the name is terrible and a bit clickbaity