I think one of the most amazing parts of Racket, and one of the reasons someone should try it out if they haven't, is that the source code and evaluator support images and not just text. The following link shows one aspect of this:<p><a href="https://docs.racket-lang.org/quick/" rel="nofollow">https://docs.racket-lang.org/quick/</a><p>Just being able to put an image in a comment explaining your algorithm into your code would be huge improvement over the traditional syntax colored ascii you get with most languages and editors. There are many times I've written an algorithm which is difficult to understand without the associated diagram I drew on the whiteboard or in an image editor. Racket lets you insert that image or photo directly into your source, and I think this is a significant improvement over putting a link to that image in a comment.<p>Racket also goes a step beyond that by letting images be values which can be assigned to variables or returned from functions. The link above shows this clearly. I'm sure there is some value in this as a teaching aid, and I think that's why they did it, but you can also return mathematical plots from your functions and so on. This feature is similar to the various interactive notebooks people use for Mathematica or Python, so it's not really specific to Racket, but it is interesting to play with.<p>Obviously there are downsides to putting images in your source. After you do that, your code is no longer ascii, and it won't be something you can edit with vi, emacs, or any non-Racket IDE. Also I doubt it will play nicely with git any time soon. However, it's a neat feature of Racket whereas many of the other benefits in the article apply to any Scheme (Chez, Gambit, Chicken, Guile, etc...) or lisp.<p>I wish there was some reasonable standard (like a better version of Rich Text) that was commonly adopted so other languages could put graphical pictures in the source code.
I have written books on Common Lisp and Scheme. Their power feature to me is the combination of functional programming (functions without side effects) and how these small functions can be built bottom-up in an interactive repl. Other languages like Python and Ruby also support repl style development, but aren't sufficiently functional. A little off topic, but I am working on a commercial product (KGcreator, a tool for generating graph data for knowledge graphs) and started prototyping in both Racket and Haskell. It was a tough call but I chose Haskell. I think of Haskell as being another Lisp language that also supports repl style development.
> If __ are so great, then it should be possible to summarize their benefits in concise, practical terms. It should be possible to demonstrate the power of __ in one hour, not 100. If __ advocates refuse to do this, then we shouldn’t be surprised when __ remain stuck near the bottom of the charts.<p>This paragraph seems like it would be equally true for almost any subject you filled in the blanks with.<p>As someone who had to learn a foreign (natural) language in school, I can see the benefit now, but there's no way I could explain it, and certainly not in an hour. It's a type of learning which causes a change in how you organize things you already know. How do you sell that?<p>(No, I don't believe "so you can talk to people in that language" is a realistic benefit. I don't think even my school thought that. The selection of languages offered is simply not useful. I've never met anyone this side of Stuttgart with which to use my German. Of the top 10 non-English languages spoken in my state, only 1 was offered as a class at my school. It almost looked like they went out of their way to find teachers in less common languages.)<p>(BTW, that's also the same answer as "If Lisp is so great why isn't anyone using it?" It works for any subject. If trig is so great, why aren't you using it? If music is so great, why did you stop playing after you graduated, and were no longer required?)<p>I'm not trying to downplay the importance. It's a real problem, for many fields. As a Lisp programmer, it's my nature to try to sell everyone on learning Lisp even if they won't use it, and also to over-generalize problems to nearly the point of absurdity.<p>How do you get someone to want to learn something when it may have no immediate and apparent practical value to them? Especially today when their whole "learning" slice is competing with Netflix and Facebook and all the rest. I guess the trendy answer right now is something in the neighborhood of "freemium gamification" and for reasons I can't explain that makes me sad.
In my mind there is one killer feature in Lisp, and that is Compile-Time-Computing.<p>You have a macro system that isn't some lameass additional language with severe limitations like the C preprocessor or C++ templates. You have <i>all</i> the language available both at compile time and at run time. You can even use functions you already have (and tested) in both places.<p>This allows you to leave every single assumption you make during programming in one place. You don't have to splatter uncertainty about what the program is supposed to do into multiple places because you language isn't expressive enough, e.g. you cannot just redefine control structures to express an assumption. That is what leads to "changeable software", not just "readable software".<p>My writings on the subject:
<a href="https://medium.com/@MartinCracauer/a-gentle-introduction-to-compile-time-computing-part-1-d4d96099cea0" rel="nofollow">https://medium.com/@MartinCracauer/a-gentle-introduction-to-...</a><p><a href="https://medium.com/@MartinCracauer/a-gentle-introduction-to-compile-time-computing-part-2-cb0a46f6cfe8" rel="nofollow">https://medium.com/@MartinCracauer/a-gentle-introduction-to-...</a><p>Example - using scientific units attached to literals in source code, but keep them at compile time and don't slow down runtime with unit checking:
<a href="https://medium.com/@MartinCracauer/a-gentle-introduction-to-compile-time-computing-part-3-scientific-units-8e41d8a727ca" rel="nofollow">https://medium.com/@MartinCracauer/a-gentle-introduction-to-...</a><p>And speaking about early or late (static/dynamic) type checking. If you have compile-time computing you don't have to choose. How silly would it be to make a programming language that can only do one or the other.
<a href="https://medium.com/@MartinCracauer/static-type-checking-in-the-programmable-programming-language-lisp-79bb79eb068a" rel="nofollow">https://medium.com/@MartinCracauer/static-type-checking-in-t...</a><p>Finally, there is turnaround time during development:
<a href="https://hackernoon.com/software-development-at-1-hz-5530bb58fc0e" rel="nofollow">https://hackernoon.com/software-development-at-1-hz-5530bb58...</a>
I've done some elisp (and a tiny bit of racket) and some Clojure and honestly I struggle to see why I would ever pick a racket/scheme/elisp over Clojure unless I desperately needed to do a ton of C ffi. Clojure is much more opinionated but I never find myself feeling like it's constraining or a straightjacket<p>When do people say to themselves "screw this, I need a more flexible tool like Racket"? Is it when you get super deep in the macro magic? (I'm not reallt sure how the Clojure macro system compares to the Scheme one)
That’s a longer read than I expected but there are some good, frank points like non programmers seeing some of the praise for Lisp called “unsubstantiated hoodoo”.<p>I like that the author addresses the “what’s in it for me” head on as well. Makes it a bit more clear what some of the immediate benefits are.
I've been using Racket for a few years now as my main "fun" toy language and I can't stop using it or trying to come up with new ideas for it. I'm currently writing my new website's publishing code in Racket, using Racket programs to create my static pages.<p>For anyone who enjoys programming language dives, I recommend Racket fully. It's simple and powerful in various ways.
I've read this article a few times and every time he takes beef with Python:<p><pre><code> x + (if is_true(): 1 else: 2)
</code></pre>
I think he just got he syntax wrong, it's supposed to be:<p><pre><code> x + (1 if is_true() else 2)
</code></pre>
And basically can't follow the rest of the argument. I have yet to learn a Lisp. Honestly, what am I missing?
More lines of prose praising lisp are being written than lines of lisp these days it seems.<p>I recently asked how to write a tree shaker in #sbcl because I thought it’d be cool. All I got was a “why would you do that?” and “ok fine your time to waste” and no substantial answers. The Common Lisp community is small and curmudgeonly. Who needs this?
One of the benefits of Lisp based languages is that they usually come with powerful macro based meta-programming facilities.<p>I've use macro systems quite often in more or less complicated ways: as a professional assembly language programmer, in school when studying Lisp DSLs, when using my favorite editor Emacs and its elisp, in systems I've built similar to Moores TRAC programming language, M4, my extensive use of TeX and LaTeX for decades, C++ STL, sendmail configurations, etc.<p>Over the years, I've lost my enthusiasm for powerful meta-programming facilities like Lisp macros. The underlying languages are Turing complete and don't strictly need meta-programming, and most modern languages aren't lacking in abstraction mechanisms available to programming without meta-linguistic alterations.<p>Like operator overloading, sophisticated macro systems change the semantics of program source code in ways that are not obvious. They allow new variants of the programming language to be created willy nilly placing demands on me the reader, maintainer, or user of a programming language package to fully understand the implementation of the meta-linguistic features. Powerful macro systems encourage a thick frosting of magic to be applied on the implementation of complex systems.<p>Some systems, like Lisp or Scheme or TeX, would be difficult to use without macro extensions, but it seems to me that identifying a good set of built-in abstractions for writing programs and building the language around them is a better approach. I am so grateful for the TicZ graphics package for LaTeX, it's all built out of TeX's crazy flexible macro system, but I'm even more grateful that I've never had to touch the source for it. Take a peek at: [1].<p>[1] <a href="https://github.com/pgf-tikz" rel="nofollow">https://github.com/pgf-tikz</a>
I only learn new languages to be able to do something new. I learned BASIC to make my atari do what I want. Then 6502 assembler and ACTION to make it do it faster. Then Pascal to have complete flexibility of data structures. I learned C++ as a Pascal with dumb syntax but never used it before Pascal went completely out of style because there was nothing new C++ could do for me. Then I learned Java because you could do applets with that. Then HTML because you could make the browser display what you want. Then PHP and SQL because you could build websites with that. Then Python because PHP sucked for console programs and JS because you could make things happen without bothering the server. Then some XML and XSLT because that could process a lot of data fast on client side. Then C# because that was the comfiest way to make desktop apps since Delphi kicked the bucket. Then I learned Ruby because I was assigned to project written in it, but promptly forgot it since then because it could do only the things Python could already do. Then I got back to Java since you could make your phone do what you want with that but Java is (was then?) worst language I know so it was short lived. I still retain it though for occasional utiliy, like extrnding Solr or playing with Apache NiFi.<p>The only language that kind of breaks away from this pattern of necessary imediate empowerment was CoffeeScript. It just exactly mirrors my way of thinking and was just an inch away from pseudo code I used for my notes since primary school. But then ES6 came and gave me enough CoffeeScript to almost be fine without it. Final nail was TypeScript that gave me stuff I wanted, smart, fast code completion and typechecking for places where I wanted types. Now if I could just have an editor that could display curly braces as indented blocks (python and coffee style) I'd be perfectly happy with state of browser coding.<p>I tried Go, Elm, Haskel, Scala but nothing stuck or even went beyond simple programs. Nim was interesting because allowed you to run code at compile time to transform code (like Racket macros). I might use it for console programs that need speed (although I'll probably just dust off C++).<p>Rust so far has the biggest potential because it allows you to have code running concurently without crazy bugs by forcing you to specifically track who owns what and for how long. That might be useful for me to make programs faster
at some point since multicore is now firmly a thing.
I love Scheme and Racket. Personally, I prefer Scheme over Clojure and Common Lisp. It supports multiple paradigms well but not too bloated as Common Lisp, having a really good optional gradual type system, really easy to use reader macro system, etc.<p>I always wanted to use Racket in a bigger project to have a deeper understanding of macro/language creating. I always believe to achieve real 'domain driven design' is to create a layer of real business language which could interpret to a software system.<p>However, every time I want to do this I found Clojure is actually a much better choice. I guess to be fully practical is not #1 priority for Racket right now. But I really hope Racket can improve some of the following:<p>1. Encourage efficient data structures by default. I know lists are the soul of lisp but it's not good to use lists for everything. Clojure by default let you use highly optimized persistent data structures -- namely vectors and hash maps. These two data structures are highly practical, performant in most of the cases.<p>On the other hand, lists are more like write-heavy data structure, with really bad reading performance. This is like, a plain file system writes faster than databases, but most of the websites use a database because most of the business has much more reads than writes.<p>2. ClojureScript. JavaScript is a big thing until WASM fully arrives. Clojure has several really solid ClojureScript workflow, which makes me feel ClojureScript is really a first-class citizen.<p>3. IDE and debugging. I use Emacs + Geiser for editing, but Drracket for debugging. Drracket is really good, but still not great for editing hundreds of files. For Clojure, Cider and Cursive are IDEs makes me feel solid and complete.<p>4. Frameworks. I guess if the other 3 points are really good there would be many good frameworks come out every day.
I really recommend that book, not just this section. I really enjoyed it and it was crucial for me in creating a talk I gave after reading it about the fun in creating little languages.
As i understand, the beauty of languages like LISP and Racket, is that, you can easily compose functions. Basically, as i read source code, i'm reading a "programming composition sheet", just like music sheet.<p>The only annoying thing, is how to reduce brackets ( and ) from distracting content from its layout.<p>Of course Python is not the answer (due to its strict identation on space/tabs)<p>If i could teach newscomer about programming, i would say: Programming = composition of functions.
> 1. Everything is an expression.<p>I am not sure this argument is given.<p>Immediately, I see there is a mismatch between what I want to program -- an objective, an algorithm, a procedure, a series of side effects that is outside the axioms of the programming language can support -- a mismatch between these objectives and this confinement of everything being an expression. An expression is a value. So to program in a language where everything is an expression is to map our idea into a (list of) value. This may be natural for programs that is seeking a value, but often not so. Even for programs that is seeking a value, the bulk of the program is to control the process of finding this value. There is no easy way or even correct way to map a process and side effects into a value. Math is logic or equivalency. To establish equivalency is to discard the effect of path or side effects. Therefore, to map the desired process and side effects into value, we have to add back the implicit knowledge of how these values are actually transformed. In stead of directly stating the transformation of values -- an imperative programming style -- we express that with dependency and relying on the understanding how these dependency is being resolved. The latter is very hard.<p>Of course, in practice, we have to give up on the fine control of our program to some extent and relying on the compiler implementation giving us desired result (the path and its side effects), then we only need worry about the value. When it works, it works great; when it does not work, we need either lower our expectations or give up the language, or transfer the burden/blame to compilers.<p>The argument for everything being an expression is the composability(although I thought the reason was ease and flexibility of writing compilers for it). This is similar to the argument that: if every object is a lego piece, then building something is easy. Well, it depends. First we need accept that lego pieces are all what we have. Second, we have to contend that what lego pieces can build is good for our needs. There are amazing lego projects, but they are nowhere I would find easy.
Racket is great and fun. I find it truly amazing that after all these many years people are still trying to justify Lisp. Frankly - if it was going to be adopted in mass it would have happened by now and no amount of explaining is going to change that. There are many reasons why languages get adopted and "logic" is not the primary one. Take JS for example - it would have been in the dust bin if not for the fact it is the only language that runs in browsers.
Does Racket have a nice DSL for wrapping web APIs? I have a hard time believing it doesn't, but I can't find it. I'm thinking of something like API-Wrap.el (<a href="https://github.com/vermiculus/apiwrap.el" rel="nofollow">https://github.com/vermiculus/apiwrap.el</a>), but any approach that drastically reduces the boilerplate is fine by me.
This guy makes some statements about python that are completely and utterly wrong.<p>He implies python doesn't have an "if" expression. It does.<p>He specifically claims this is invalid in python implying that "if" expressions don't exist in python:<p><pre><code> x + (if is_true(): 1 else: 2)
</code></pre>
The following is written in python and is correct syntax:<p><pre><code> x + (1 if is_true() else 2)
</code></pre>
Although it's not "pythonic" to use python functionally, Python is a multi-paradigm language and has the facilities to be used as a very powerful functional language. It's not just a "functional" library. Functional is built into python syntax. The following is correct python syntax that will pass a type checker process as well.<p><pre><code> #List comprehensions using map and filter:
x: List[int] = [i+2 for i in range(100) if i%2 == 0]
#anonymous functions:
x: Callable[[int], int] = lambda a: a + 2
</code></pre>
With mypy, type annotations or any other external type checker, python approaches the power and correctness of typed functional programming languages like haskell or Ocaml, though it is missing many features.
I've long stayed away from Lisps, precisely because of what the author describes in the first section, that there is a huge amount of praise over all of it's wonders, without ever specifying what those wonders are or how they are actually good things. I've had similar issues with the cargo-cult following of Rust; yes I have heard it is great, but WHY!? Great article, it de-mystifies these vague praises and addresses them clearly and specifically. I'm gonna try Racket this afternoon =D