> I have met a lot of people who said that they could do things with Lisp 20, 30 years ago that languages either cannot do today, or could only do recently.
> It looks to me like the Lisp community knows something the rest of the world does not. They are not searching for the next hot thing. They seem to understand things on a deeper level than other communities. Perhaps “enlightenment” is not an overwrought term to use.
For those that haven't read this before. For me, any article making claims like this simply brings to mind the Lisp Curse:
(Not currently available... Last snapshot is from June, so unsure whether this is permanent or just temporary.)
Lisp is extremely flexible as a language. The core is very small, especially if you look at something like Scheme. But it lets you easily create and extend the language into what practically becomes a domain-specific language (DSL) for whatever problem you're working on.
Except what this really does is push things from being technical issues to being social issues. Sure, maybe I know Lisp. But how long is it going to take me to learn what your ultra-customized, macro-laden particular flavor of Lisp? And one has to do that for every single new project requiring coordination...
Lisp is not one language, but a wide variety of personal languages that happen to share a common core and syntax.
I read a lot of these articles early on and then bought a few lisp books and read them cover to cover. My observations were as follows:
1.) If I needed to do some really crazy stuff (like I imagine what grammerly does) then lisp might be the right tool. I know it is far more performant than the scripting languages (really closer to the C end of the spectrum), but I seldom need raw performance (your mileage may vary widely).
2.) 99.99% of my own work or hobby projects were better served by more mainstream tools like Python, Bash, PowerShell, C++...etc as all those tools either had built-in data structures that were easier to use, or better integrated with the OS, or they had massive ecosystems of scientific, plotting, GUI...etc, far in advance of anything that the lisp ecosystem has. You can talk about blub languages all you want, but when I can write a short little script with Python to remotely control an application using the only API they provide (Python) and then start doing something else, there is a clear winner from a software tool choice even if the lisp language itself is a better design in a multitude of ways.
The tool I have where I feel like I have an insane amount of power that isn't widely known is Wolfram Mathematica. It shares a bit with lisp in that all computing has a REPL, you can see the AST & intermediate calculations, all the command names use a pretty consistent notation like GraphPlot[]. Documentation is really good and there are primitives for pretty much everything from graph networks to matrices to neural networks to GUIs and 3D plotting ...audio, Blockchain....the list goes on and on. It's a commercial tool which sucks, but doing R&D with it is like using secret alien tech. I could literally copy paste an image of certain things I wanted to use in my network (node diagram) as vertices, build that graph, start doing computations on it like max flow or traveling salesman. I could then just grab the graphs output picture and feed it as an input into some other command and get the AdjacencyMatrix and then do other computations on that. I still love Python for code I need to share with coworkers who don't have a Mathematica license, but it is truly some amazing technology.
> The tool I have where I feel like I have an insane amount of power that isn't widely known is Wolfram Mathematica
I’m pretty sure I’ve heard that the Wolfram Language is in fact considered a Lisp, albeit one using M-expressions rather than S-expressions [0]. But I can’t seem to find a source for this though.
Since I can't edit my comments, here is the link to the video explaining how it evaluates. It really picks up at 21 minutes in, but the first 20 minutes is also kinda important.
Lisp was actually developed for research and development of symbolic computation systems. Early on Lisp was applied to mathematics problems like integration and other manipulation of mathematical expressions.
Thus term rewriting systems and similar (-> rule-based systems) have been early on implemented in Lisp, but Lisp itself is based on a functional&imperative expression evaluation.
I appreciate the history. It doesn't make much of a difference from an ignorant end user such as myself, but this information is at least pretty interesting to me.
I've normally categorized languages into imperative (, Fortran, C, Basic), functional (Haskell, Scheme, F#...etc), object oriented (Java, Python, Ruby, C#, JS...etc), concatenative (Forth, Factor, 8th), logic (Prolong, MiniKanren), array (APL, J, K). I guess TRS in entirely its own thing?
There are many paradigms. Rule-based languages like OPS5. Multiparadigm-languages like Common Lisp (imperative, functional, object-oriented, meta-programming, ...). Relational languages. Visual languages (Labview). Data-flow languages. ... more...
TRS looks like it is a different paradigm. The system takes a term and rewrites it based on a rule set. In some ways this is similar to rule-based systems, but those tend to manipulate not terms but facts in a database of facts.
Thanks for the explanation. I'm familiar with relational languages (SQL), multi of course, things that are hard to classify like Rebol, and a little Simulink (no LabVIEW though). I had completely forgotten about those....I wonder how many exist in practice?
I appreciate you drawing the distinction between TRS operating on rules and things like Prolog being a rules based system using facts. TBH, I only understand much of this at a very superficial level (as in I've played with Prolog several times and even read a short book, but I'd never choose it for a production application if I can get away with using SQL and some procedural code lol).
It's the old 'I wanna make something, gimme libs! vs 'I wanna make something completely new, gimme lisp' dichotomy.
BTW the Wolfram language isn't 'a bit like lisp'. It _is_ a lisp with an alternate syntax. This becomes extremely apparent in any kind of symbolic manipulation.
Funny, because the impetus for Mathematica was Stephen Wolfram's expert opinion that Lisp was too slow by a factor of 100 to implement a performant symbolic algebra system.
Only a galaxybrain like Wolfram could devise such an elaborate implementation of Greenspun's Tenth.
Lol. It might have been true in the 1980s when Mathematica 1.0 came out (on version 12.3 now).
Now I think Mathematica is a combination of C, C++, Java, and of course Mathematica code. C and C/C++ libraries are used for the symbolic stuff and some libraries, Java is used for database connections and so forth, and I think they do eat their own dog food by implementing new functionality using existing Mathematica code. That's a little bit yucky, but no different than many ecosystems today. At least everything seems pretty seamless to me.
It wasn't true. Maclisp was competitive with Fortran in the 1970s. Wolfram didn't know enough about Lisp -- or computing in general -- to make such a claim.
Thanks for linking (I remember reading this on here a few years ago, but couldn't remember enough to Google for it). It seems the author's claims of 2.5 to 5 seem to match a lot of the current benchmarks out there for GCC vs SBCL, so that seems to have remained consistent over time. I'm not sure if they'd be in better shape if they had stuck to an approach such as Macsyma or not. Perhaps a lot of effort could have been avoided, perhaps not.
The usual reasons to not develop or even reimplement custom languages (like the language for a computer algebra system) was/is performance and memory. Plus the limited availability of compilers for certain computer types.
Even during the 80s memory was very expensive (workstations) and limited (PCs). Thus it could have made sense to implement a language such that it runs in smaller space to save a lot of money on the user side. Still, there were Lisp-based computer algebra systems on small (Derive, MuMath/MuSimp, ...) and large computers (REDUCE, Macsyma, Scratchpad)...
Also depending on the availability of a certain Lisp system was problematic, when a C or later a C++ compiler was usually provided... -> but then one was responsible for the maintenance of the implemented.
That was kinda what I would've guessed. Even if lisp was just fine doing symbolics, it would've been a bigger resource hog than something custom done well. I wasn't aware of the lisp CAS on smaller systems. I figured when Mathematica first came out, lisp was mainly running on things like symbolics lisp machines. Is that incorrect?
When Mathematica came out (1988) there were already Lisps for PCs and Macs. Lisp at that time made the switch to Common Lisp. Symbolics Lisp Machines were used for higher-end AI, CAD, etc. domains. There was a bunch of very different options across many platforms (PCs, Macs, UNIX Workstations, ...). Macsyma itself ran on various platforms, incl. Lisp Machines, UNIX, VAX/VMS, and then also on Windows.
Derive even ran on some TI calculators. It was written in muLISP.
Lisp is the lambda calculus + AST as syntax. The Wolfram language is a symbolic reduction engine without AST as syntax. In other words, nope they are not the same at all.
I stand corrected. Although lambda calculus is apparently considered by some to be a term rewriting system, apparently. So I'm not sure the connexion is so distant after all.
> But how long is it going to take me to learn what your ultra-customized, macro-laden particular flavor of Lisp?
I think that the big thing to recognize about Racket is that its approach is not really to do that. It's to implement complete, well-specified domain-specific languages that live on top of Racket.
What's unique about it is that they've put a lot of thought into how to set you up for success in doing this, so that your DSL retains a high level of compatibility with the core language and other DSLs, without any particularly special effort on your part.
The other thing to keep in mind is that Lisp, particularly the Racket community, tends to favor stratified design (https://dspace.mit.edu/handle/1721.1/6064). So when you think about the level of coordination involved, don't think in terms of a tangle of DSLs and macros all vying for control of the same conceptual space. Think of it in terms of layers. The goal is usually something more like a lower-friction version of the relationship between Lua and C, or Python and C++, or even TypeScript and JavaScript.
There's an online book, Beautiful Racket (https://beautifulracket.com/) that serves as a really great illustration of how it all comes together.
> Except what this really does is push things from being technical issues to being social issues. Sure, maybe I know Lisp. But how long is it going to take me to learn what your ultra-customized, macro-laden particular flavor of Lisp? And one has to do that for every single new project requiring coordination...
This happens in every language though. You just get to this point more efficiently with lisp.
A rigid language doesn’t protect you from having to understand the local terms e.g. ConcurrencyGeneratorObserverFactory.
Maybe the reason people prefer Java + Design Patterns to Lisp is the same reason people prefer writing monstrous macro-driven spreadsheets to writing "real" programs: lower barrier to entry.
Once people are off the ground with an MVP that is delivering value, they are willing to invest virtually unlimited effort into scaling up their pre-existing solution, even as the limitations and absurdities of their chosen framework become increasingly obvious.
Any language is preferable to a language you don't feel confident developing in. So whatever gets people off the ground is what wins, regardless of what would be better in the long run.
What does ‘low barrier to entry’ mean in this case? Java was low barrier to entry in the early days, but now it seems completely impenetrable to me having not used it for a decade.
On the other hand something like Racket seems very easy to get going with.
So if I understand correctly, even though when you submit a story with a link it does not include the text if you write one, it seems that it's still stored on the HN server and returned from the HN API that Algolia gets its data from.
Just found this interesting.
And I wonder how many other stories have a "hidden text" like this.
If the Google BigQuery or what it's called dataset includes this same data it should be a simple thing to find all such stories.
First, number of stories where url begins with "http".
SELECT COUNT(*) FROM `bigquery-public-data.hacker_news.stories` WHERE INSTR(url, "http") = 1;
Output:
1729544
Then, number of stories with non-zero length text:
SELECT COUNT(*) FROM `bigquery-public-data.hacker_news.stories` WHERE CHAR_LENGTH(text) > 0;
Output:
218726
And then, this should be the number of stories that has both.
SELECT COUNT(*) FROM `bigquery-public-data.hacker_news.stories` WHERE INSTR(url, "http") = 1 AND CHAR_LENGTH(text) > 0;
Output:
113550
Seemed like an awfully high number though.
SELECT * FROM `bigquery-public-data.hacker_news.stories` WHERE INSTR(url, "http") = 1 AND CHAR_LENGTH(text) > 0 LIMIT 3;
Ah. I see then that there's a lot of spam posts. (Note: The order of the rows may be different from run to run I think, and I didn't feel like adding "order by" stuff. So it could be that you don't see the spam from issuing this one query above.)
Anyways, let's require score > 0.
SELECT COUNT(*) FROM `bigquery-public-data.hacker_news.stories` WHERE score > 0 AND INSTR(url, "http") = 1 AND CHAR_LENGTH(text) > 0;
Output:
113322
Still really high. Let's limit ourselves to score > 25.
SELECT COUNT(*) FROM `bigquery-public-data.hacker_news.stories` WHERE score > 25 AND INSTR(url, "http") = 1 AND CHAR_LENGTH(text) > 0;
Output:
1677
Ah, that's better.
And somewhere between? Say, with score > 8.
SELECT COUNT(*) FROM `bigquery-public-data.hacker_news.stories` WHERE score > 8 AND INSTR(url, "http") = 1 AND CHAR_LENGTH(text) > 0;
Output:
3458
And let's look at some of them.
SELECT * FROM `bigquery-public-data.hacker_news.stories` WHERE score > 8 AND INSTR(url, "http") = 1 AND CHAR_LENGTH(text) > 0 LIMIT 5;
Here's one of the ones I get:
Title: Calling the NSA: "I accidentally deleted an e-mail, can you help me recover it?".
Text: A nice thought and practically the same thing that Google does. You hand in your privacy, but you get services back in return.
Seems pretty clear that this is an example of a comment to go along with the submission. And it was preserved, although not shown in the thread as we know.
So this also makes me realize that third-party HN clients could use this to offer users the ability to write and to see story texts that don't display on HN itself due to there being an URL attached to the story, but which are still stored on the HN servers and returned by the HN API. That's pretty neat :)
So, a language that excels when used by small teams and lone hackers... which BTW describes academic research perfectly. Of course if you have an army of programmers working in parallel on a 1M loc codebase, you won't want something too flexible. Right tool for the right environment!
Try to make something like MediKanren in a mainstream language, and the advantage of lisp languages will become immediately apparent.
If you have an army of programmers working on 1M LOC, there's a very good chance you're working on something overcomplicated for the problem it's trying to solve. Padding out your CV by inflating your budget/team size numbers, eh? :)
Lisp gets a single programmer leverage over large, complicated problems, and puts even complex projects within the reach of small teams. In the 80s, Symbolics had the stated goal of making very large projects feasible by a small team, and anything smaller within the reach of a single developer.
Ambitious, to be sure, but given the CF that is enterprise development, it shouldn't be ruled out as something to reach for.
> So, a language that excels when used by small teams and lone hackers...
When you're trying to do something that hasn't been already done programming-wise. For most other cases you would be better served by a language with a healthy and large ecosystem.
I agree, and this translates into the real world. That's exactly what lisp has been and is used for (research in quantum computing, for a current example).
Still, it's not a bad thing to try to extend the user base as it translates to more libs and better implementations. Many new things are mostly same-old same-old with a sprinkle of 'new' glitter on top!
DSL's have been proliferating as of late in the dev ops / IT space, such as with Kubernetes, Ansible, Terraform, etc. On the frontend we also have Vue.
I personally would've rather them use Lisp than tack on their own conditionals and loops and such.
Your criticism seems to apply to every DSL, which in my mind makes it too generic and therefore invalid. It also reminds me of the argument which was used to push Java in the corporate world. "We need a language which protects us from the dumb programmers we hired to save money"
Understanding someone elses code is always a challenge. Outlawing custom abstractions in favour of a few very shallow ones doesnt seem like a convincing thechnical argument.
> Your criticism seems to apply to every DSL, which in my mind makes it too generic and therefore invalid
The problem is that LISP macros are extremely powerful. The DSLs you can design don't always neatly fit into a box and integrate seamlessly. They're leaky abstractions. You don't necessarily know what's a function or a macro. You don't necessarily know that a macro isn't doing lazy evaluation or redefining some operators you're familiar with.
Programming languages aren't just about coding, they're also about having a shared language that other people can understand. If you introduce 500 new syntactic forms that you designed yourself into your code, and newcomers have to look them all up to really understand what's going on, that makes it much harder for new people to onboard.
LISP loops minimalistic on the surface, but it's kind of a lie. In practice it's easy for it to become exactly the opposite of that.
This is the popular narrative. But it is talked about more than it happens.
In most lisps, few stray from the basic data structures, such that the data you can get is usable basically everywhere.
Contrasted with many Java libraries, where coding a library locks you in to said library.
Yes, a few have tried to keep interface compatibility with the core collections. I'd hope most do, nowadays. But that really just highlights that we are both talking of previous year's mistakes.
My hypothesis is it comes from novice attitudes in building everything as a masterpiece. As the community matures, things tend to stabilize.
I believe a DSL-done-right doesnt care about the issues you mention. The important thing about DSLs is the DS, Domain-specific. The domain experts care about a nice language fitted for their specific domain. But they dont care about evaluation order, macros, lazyness, and whatnot. If the DSL fits the domain, these are non-issues.
> Outlawing custom abstractions in favour of a few very shallow ones doesnt seem like a convincing thechnical argument.
The entire point of the Lisp Curse is that this is a social issue! Not a technical one. And, furthermore, what is a technical issue in another language can be pushed into being a social issue in a Lisp. And social issues are a lot more difficult to solve.
Compare this to something like Java + Spring Boot or Ruby on Rails or any other framework favoring configuration and convention over code. Where the explicit point is a social agreement on what a program looks like, which in turn allows everyone to hopefully focus on the actual business logic.
(Also: Sibling commenter already addressed the differences in abstraction power better than I would have.)
He had a good idea there with the concept of a social problem in one culture being merely technical in another one which has the right technical wherewithal that is relevant to the problem.
For instance, suppose that cheap and 100% effective sound-proofing were available and installed into every apartment by default (an example of (practically nonexistent) technology). Then unwanted noise from neighboring units wouldn't be a social problem.
Creating good languages is hard. Let's not encourage it e.g., It is good that Python enforces a few constraints on the syntax and many abstraction can be used as is between various unrelated projects.
>But how long is it going to take me to learn what your ultra-customized, macro-laden particular flavor of Lisp? And one has to do that for every single new project requiring coordination...
This is also one of the two major problems that Forth has. The other is the lack of types and non-stack data structures.
It is about "social contracts" and seems to kind of address some of what you are saying here. Basically, the community comes to an agreement on what some good common contracts should be. I wonder if there are any other social problems in the lisp languages that we could think of that can be developed by consensus this way.
Yep the core is very small but also useless if you want to write real software. You need a lot of additional code to have a useful language. With the core you can’t even add two numbers. Unless you encode numbers as cons lists (Peano style). The core for Haskell is also super small (just 1 page). But it takes a lot of additional code to make Lisp and Haskell useful/practical.
It’s funny how Lisp proponents have been promoting Lisp for 60+ years and are still completely fail to get developer mindshare. While “inferior” languages like C/C++/Java/… are successfully used by millions of developers to create the software that runs the world. And it is especially funny when a number of Lisp proponents keep going on about how much smarter they are than the rest of the world. While failing to use their smarts to achieve any successful outcomes. Perhaps those Lisp proponents should use their “superior” intelligent more productively? Maybe by questioning their deep held assumptions about the superiority of Lisp vs. languages that are actually successful in the real world? Now that would be real progress.
Don't complex python programs end up doing the same thing? I am looking at Django and there is definitely a lot of introspection, code generation and half-assed DSL stuff going on.
This 2019 article is a bit out of date; what it calls racket2 is now Rhombus, and (as predicted in the article) does not seem to have really taken off.
I have a feeling it's on hiatus due to the switch to Chez Scheme, which probably took more time and effort than anticipated.
The major reason given for that was easier maintenance in the future so now that's completed, I wonder whether the effort will now will be re-directed back to Rhombus.
Racket's fork of Chez Scheme now runs native on Apple M1 silicon. That's a remarkable feat; GHC Haskell for instance doesn't yet, and their blogs explain the difficulties.
I keep a zoo of exotic languages, many of which must be build from source. I took a plunge buying an M1 Mac mini, imagining that emulation would hide the transition. Not so for the zoo. At least I have other machines.
For actually using a language, one wants there to be a critical mass of sophisticated support. Racket has long had best-of-class documentation, but this technical feat of native M1 support is a serious feather in their cap.
I believe you are right. I think Matthew Flatt mentioned it in one of his more recent talks. Chez scheme didn’t become the default implementation until Racket 8.0 which released Feb 2021 so it took awhile to iron out all the bugs.
I'm always a bit skeptic when I see relatively obscure programming languages trying to bring in new users. Are there any examples of something like this working in the last 10/20 years?
As I've said to a sibling comment, I probably wasn't clear enough. What I meant is something like a language that's not well known, that does some work to appeal to more people, and then become more used. Both Ruby and Python seem to be made to appeal to people originally.
When you end your comment with, "Both Ruby and Python seem to be made to appeal to people originally," that comes across as a statement by implication that Racket was not made to appeal to people originally. Otherwise, why say it?
I guess my point was that Python and Ruby didn't really try to be more popular, people just used them. Racket seems the same, but for a smaller number of people. I'm wondering if marketing/trying to appeal to new people has ever been effective for an established programming language. I'm not aware of any examples where that worked.
> I'm wondering if marketing/trying to appeal to new people has ever been effective for an established programming language.
I'm not sure if this counts as "trying to appeal to new people" (or "an established language", for that matter) but the Rust community has made a big push towards creating more teaching materials that make the language more broadly accessible for the past ~5 years, and I think that's been effective.
I'd say that for Rust, being accessible was always in the DNA of the language, at least since it went public. It totally counts as "trying to appeal to new people", as lots of people that didn't use languages like C or C++ use Rust. However I don't think it works for the "established language" part. I'd say Rust is a good example of what to do if you're starting a new language.
This makes me wonder what did cause Python's / Ruby's rise in popularity if there weren't any huge changes to the languages themselves in that time. I guess maybe the emergence of Rails in Ruby's case? And for Python, I don't know, Django? Numpy?
I think major libraries like Django or Rails are what push a language forward. Look at Go as a big example of this, it had a web server that was production ready built-in. People went with it and are still going with it. It's one of the things that attracts me to Racket above all other Lisp (or lisp like languages) because I can: make a server, make a gui, do front-end web styling all in Racket all out of the box. I also kind of like Clojure cause of Lein (a package manager that will install Clojure for you as long as you have the JVM setup, making your life stupidly easier).
I think the stronger the standard library, the more likely your language will be adopted. If anyone out there is building a language and has strong funding, invest in database drivers and a strong web framework that compliments your language and showcases its capabilities. I would love for D's Vibe.d to be more polished, seems they got as far as they wanted to and stopped, I havent seen much new in half a decade compared to other web frameworks.
- progressive learning (you can start with very little knowledge and add later)
- strongly encouraging a single way to do things, promoting readability
- minimal scalfolding
- write once, run everywhere (in theory)
- many included libraries + a large ecosystem
I used to write in Perl and had to constantly go back to the book to get the syntax right, and one day tried Python, and cut my time to write stuff in half, was able to reread and understand my code, and so were others.
Python was well established long before Django came around. Although Numpy existed for a while, most Python developers did not use it till the late 2000's.
Python's rise in popularity is probably because it was a much nicer alternative to Perl. The percentage of non-programmers I would encounter using Python was significantly higher than those using Perl.
And then there was its "batteries included" philosophy.
And, of course, it came preinstalled with most Linux distributions.
Python got a huge uptake as developers tried dodging system requirements.
That is, it was not uncommon to have a requirement that you cannot install new languages. But you could pip install dependencies, as that did not necessarily change the full system.
So, since Python was already installed, it had a toe in the door that the likes of Ruby did not.
Granted... Dependency management in Python has revealed itself to be a minefield...
This kind of answer really ignores almost all of why these languages have done well. They are easy to learn. Relatively speaking, especially at the time they were gaining popularity, they were far easier to learn gradually and still be productive than almost everything else available.
Their communities adopted explicit "this language is for DOING shit understandably, not golfing, not squeezing cpu cycles, not researching type systems, not timtowtdi, etc." That helped tremendously.
In pythons case, it was very easy to wrap up C and C++ code and lift it into a nice environment with a repl and everything else you need to experiment. This put it in an excellent position to grow along with the scientific community. Numpy was a huge asset here.
The rise of rails, Django, heroku, MacBooks as the dominant coding environment etc all fostered an environment where coding went from being nerd shit to being fashionable. This ushered in the era of "people who code for reasons other than being huge fucking computer nerds," in which the benefits of Python and Ruby mentioned above became even more relevant.
I balk heavily at the idea that python is truly easier to learn. In large because it is actually quite hard for me to pick up some random python and really be able to follow it.
Most of the claim of what the community in successful languages did, is so steeped in confirmation and survivor bias that it is hard to see it as more than just popular marketing.
So. No. I am not ignoring these claims. But nor will I assume their truth. If you have actual studies showing they are easier, I'm interested. Enthusiastic claims from members of the community don't count, sadly.
My earliest exposure for Python was from Linux distros. Originally Perl was used for stringing together a Linux distribution, but then Python took over the role, slowly. Batteries included stdlib helped a lot there, and also because there wasn't much else like it back then (remember, Python is older than Java). And then since it was already there, everybody suggested it and used it as introduction to programming. Incidentally (or not) it was also intended for and suitable for first time programmers with ridiculously simple syntax and so it became the lingua franca of programming lessons everywhere. I suspect that (along with excellent C/C++ interop) had a chance in getting it picked up as front end for ML frameworks, and then here we are.
I'd say Elm is a decent example. Released 2012. Historically, the ML family has been fairly unpopular, with a little bit of ocaml in the wild and not much else. Elm is certainly also niche, but I think it meets some definition of "working".
Apologies if that looks like moving the goalposts, but what I meant was a language that wasn't well known, did some serious efforts to acquire new users, and now is relatively well-known. Elm seem to have been made from the start to be accessible.
I don’t think that the DrRacket UI deserves the criticism in this article. I usually use Emacs for lisp languages (Common Lisp, various Schemes, and Haskell) but DrRacket is good enough.
The beautiful thing is that we all get to decide what programming languages we want to use. It is true that sometimes our jobs force a language on us, but we have freedom to peruse jobs using tools that we prefer. For a personal project, I recently used Swift and SwiftUI. Swift is a great modern language as is Rust.
Racket is amazing, great community around it. I started writing a Racket AI book a year ago, but shelved the project because of other commitments. I hope to get back to that someday.
> Focus more on libraries, frameworks, and applications
I think this is the most important thing. Say I'm writing a web app -- I want a language that can run on both the server and browser and that has a web framework.
Or say I have a database -- I want a language that can talk to it.
Or say I have to interface with some data format, such as .png -- I want a language that has libraries that can read and write it.
> > Focus more on libraries, frameworks, and applications
> I think this is the most important thing. Say I'm writing a web app -- I want a language that can run on both the server and browser and that has a web framework.
One of the things that bugged me initially about Racket (and still kind of does) is the implicit typing of some of the functions. Take `length` for example:
If I wanted to get the length of the string, I have to use `string-length` instead. (Same with vectors and other sequences.)
I personally favor default abstract protocols over explicit type:
$ sbcl
* (length "asdf")
4
I know that Racket's `sequence-length` will do the same thing, but it feels like a misnomer to have `length` really mean `list-length`. It introduces cognitive load where it's not desired, usually, and tends to make my code longer (slower to read, slower to type, etc.).
Maybe this is a silly peccadillo, but as I wrestled with Racket over time I found myself frustrated by this in a way that Python, say, didn't. It's these sort of bits that I'd like to see sanded away, and not the parentheses, to make for cleaner, easier-to-read, easier-to-write code. More concise syntax for indexing and other such things could be nice, too! Standard means for accessing nested hash tables (here's looking at you, deeply nested JSON! Who wants to `(hash-ref (hash-ref some-hash key1) key2)`? Yes, the language can accommodate more concise idioms through macros, but it seems reasonable to have standards around this access.
I really, really want to use Racket: I'm attracted to DSLs (maybe moth to flame) and boilerplate reduction, but it's been a challenge to get over these humps.
You're critique is valid. `length` `vector-length` and `string-length` are from the very monomorphic old Scheme libraries.
The Racket module system does provide ways to use the names you want without having to change the core language. The `collections` package (https://pkgs.racket-lang.org/package/collections) also smooths over some of these issues.
Thanks for the tip! I'll look over the collections package for sure. It looks like some of the things of interest to me are there already.
I knew there were historical reasons behind some of these things (just like the old complaints about car and cdr not being called first and rest). Sometimes it feels like this hewing to history comes with some baggage that makes adoption a little more challenging.
I find myself writing the following in some of my projects, for example:
I feel a little silly each time because it seems like the sort of thing that should just "be there," in the way you can do something like hsh['a']['b'] in Python. Of course there are ways to make it a bit more like Clojure--I think Greg Hendershott created a Clojure-like layer called rackjure--so that you can access using the variable name, etc. It would be nice to have something standardized to make the ergonomics nicer.
It is maybe unfair to Racket, since it seems to have a lot of batteries included: it can produce stand-alone executables out of the box, has a working cross-platform UI toolkit, a packet manager, good documentation and an IDE... All this while being, strictly speaking, an academic research language.
It's maybe also speaking past what Racket really is?
It's first and foremost an academic project. It's not really the job of the core team - mostly academics - to implement a all those utilitarian bits on top of the language. Their job is to work on ideas in the design of the language itself.
Ideally, then, that work enables whatever wider community of non-academics it can attract to build web frameworks and database bindings and whatnot.
That said, I do get the impression that Racket hasn't done anywhere near as good a job of carrying things through to that second step as comparable communities such as Haskell and Pharo have. The rumor mill would seem to suggest that the project's leadership engenders an ivory tower culture; and perhaps there's something to that? By contrast, even as someone who still hasn't finished learning Pharo and isn't really active in its community, I've still managed to have some direct (if small) interactions with Stéphane Ducasse, and that does, in some subtle way, leave me feeling more personally motivated to contribute to the project.
Matthew Flatt and most of the core team are readily available through slack or the mailing list and often answer themselves, even to newbies. Being a hobbyist myself, I think this ivory tower reputation is undeserved. Few people really understand racket under the hood because it's the product of the greatest minds in scheme. That makes the pool of 'experts' people can query very small, and I think it's honestly too much to ask from the core team to answer to everyone. Racket teaches humility and perseverance, which I find to be a very good thing.
> No other language has people claiming what the Lisp people claim. Many langs claim to be influenced by Lisp, or try to do things that Lisp can do, or do things that started in Lisp (which is just about everything but OOP). But the Lisp crowd doesn’t see a need to be like other languages. It’s like fat people want to date fit people, but fit people do not want to date fat people.
Considering the whole article is about how to get more users for Racket, maybe they're not doing so well in the dating pool? The author also seems to have forgotten static typing. Isn't Typed Racket precisely the Lisp crowd seeing a need to be like other languages?
I'd say that typed Racket is a perfect showcase of what is interesting about lisp. Miss something? Extend the language and you'll have your cake and eat it too! Typed Racket stems from a research interest and a bunch of great minds, not a need for ML and certainly not the need to be "mainstream".
> Typed Racket stems from a research interest and a bunch of great minds, not a need for ML and certainly not the need to be "mainstream".
You could argue the same point about language "becoming more than Lisp" though, they add features because they are good features, not to be "mainstream". That doesn't change the fact that Lisp is far from a pioneer in static typing compared to other languages.
Typed Racket has been at the bleeding edge of gradual typing research since a long time now, and the 'types as macros' papers made quite a splash, I think. Idris is also built on scheme. This fits the 'pioneering' aspect, I think. The point being that making new things, including new type systems, is much easier in lisp.
Much easier compared to what though? Agda is made in Haskell which recently got linear types. If you mean much easier than mainstream languages like JS, Python or Java you're right. If you mean much easier than everything, I think you're wrong.
I see you are moderately downvoted, which means I’ll be at risk too, but I also came to say it seems incredibly condescending of the author to analogize lisp/racket to “fit people” and literally every other language as “fat people”.
I'm probably downvoted because I was a bit snarky, in response to the author condescendence. I agree with you, when you think you're better than everyone and then wonder why no one will date you, often that's a sign that you're not as good as you think you are.
Racket was the first Lisp I got. And because of that I will always be a schemer/lisp 1 person at heart. The only reason I moved away from it was because I was working in a more memory constrained environment and I needed something that was a little lighter on resources
I usually prefer Emacs, but I still sometimes use VSCode for Common Lisp, Racket, and Haskell (and of course for Python). Try, for example, the Magic Racket VSCode plugin.
The only thing you have to configure is your entire brain. Seriously, for anyone under 40, pressing Ctrl-Z should undo, not hide the window. I say this as a fanatical emacs user. There is nothing straightforward about vanilla emacs for someone whose software expectations have been shaped by the conventions of the last three decades!
I can't speak to its completeness as I haven't used it personally, but Emacs does ship with cua-mode which enables a lot of those keybindings. It's just not enabled by default, as most existing users wouldn't use it.
Am under 40. Regularity get annoyed by new windows opening when I just wanted to go down one line (and yes, I have found the gnome emacs input mode setting).
i hated emacs at first for this reason. ctrl-v should be paste, ctrl-c should be copy, right !? now though i have emacs bindings system wide
what brought me to emacs first was intrigue - why do people keep saying that this little shitty-looking weird editor is the most powerful program on my computer :) they weren't wrong
or something preconfigured like spacemacs or prelude.
I think the biggest problem of emacs is that it's an entire universe by itself: everything is there in a zillion flavours (which always ALMOST work out of the box) and I don't know which one to pick.
As a VSCode user, no spacemacs isn't really attractive. What's good about VSCode is that it works really well for all skill level and require almost no learning to start with. Spacemacs (and vanilla emacs) don't really fit that description. To be fair, most IDEs also don't fit that description.
Plain old Common Lisp has similar issues on the Mac. (And possibly Windows too - I haven't looked.)
There's supposed a one click dev system installer, but it hasn't been updated for a while. There's a many click recommended collection of tools, but it looks like half a day of work to get it all installed and then you're supposed to use Emacs.
You can add a REPL to something like Sublime Text. Or install Atom and go through another convoluted process which launches a Lisp server and etc etc etc.
I gave up and got back to work at that point. It might work smoothly if I worked through it all. Then again... it might not.
Which is a shame, because I like the look of Lisp very much and I really would like to play with it.
Also, I have shared https://github.com/susam/emacs4cl which provides a quick starter file to set up Emacs for Common Lisp development pretty quickly. Additionally, it explains every line of the quick starter file, in case one is willing to learn how it is setup and customise it for their needs.
Try just installing SBCL using Homebrew and then setup either VSCode or Emacs (or Vi, my last manager lived in Vi when doing Common Lisp and Clojure development).
Yep installing any major (and even some of the minor) Common Lisp implementation(s) is very straightforward.
Emacs is my regular editor so I do use it when coding lisp but I don't use any extensions other than syntax highlighting (so no REPL or SLIME).
I sort of get the desire to use the "one click installers" like portacle but in reality they don't add very much and now you're dependent on a third-party system with less support than the language itself. It does not make sense to say Common Lisp on Mac is broken because a third-party installer isn't great.
For Mac at least it shouldn't be that hard if you already have a development environment setup.
brew install sbcl.
If you want to use Sublime Text, then you can go and install this plugin called Slyblime, and the only change you need to make after that is to edit the preferences to select SBCL as the lisp command in the plugin settings.
FWIW I use vim with the slimv plugin for CL, it works great. Of course for many systems vim can be a bit of a pain to install for the first-timer, too, though I think less so than emacs or one of its many flavors.
For the price of an email address, you can download one of the proprietary CL IDEs https://franz.com/downloads/clp/survey and try it out, maybe by following their instructional videos/slides https://franz.com/services/classes/ Then after that you can be better informed if you want to pay for their IDE (or check out the other proprietary competition) or invest effort in emacs/vim/the atom plugin/something else.
I'm curious what languages do you use, or have used, that have shaped your expectations of setup? Do you remember what the first time setup was like for them? For me, I first started learning PHP in 2004, and over the next few years learned or played with JavaScript/Java/Python/Perl/Ruby/C/C++/Scheme (Java and "C with classes" C++ mostly in highschool). My "setup" for most of them was the same, just EditPad Lite, which was better than Notepad only in two ways: you could have multiple files open in tabs, and you could just save-as blah.ext without having to first select "all file types" so you didn't end up with blah.ext.txt. No syntax highlighting or indentation, I didn't appreciate those until after I had made the switch to vim sometime in 2007, though even my vim usage was pretty bare-bones for a while.
But still, for the longest time I just edited files, saved (and maybe FTP'd or compiled), and executed either in the command line or by pointing my browser at the files. When I played with Scheme (by following some of SICP), I changed things up a bit to also match what I had started doing with Python, which was I'd still edit/save/run most things, but occasionally I'd copy-paste from the editor to the REPL and play in the REPL directly for a while, copying stuff back out if it was useful. This was fine, and still is fine! You can have this bare-bones experience with CL, too. If you've installed SBCL, you just have to run `sbcl --script file.lisp`. If you launch SBCL by itself (it's even better with rlwrap), you can just play in the REPL. If you were doing an intro-to-programming course for highschoolers, would you have them setup much beyond any random text editor and telling them how to execute stuff?
On the other hand if you want a more "professional" environment, is it really reasonable to expect to not have to spend some time setting things up? Especially with CL where if you want more than the bare-bones experience, i.e. developing with the REPL, you.. need to have something that can talk to a REPL, and not just a pure text editor. One of these days I should try out https://microsoft.github.io/language-server-protocol/ and maybe I can just recommend it, I know someone made a server for CL that just wraps the classic one, which should let any editor with an LSP client have a good experience. But taking from my own experience again, when I took my second job writing professional Java, Eclipse was basically mandatory, which I hadn't needed really before, plus there were some company-specific extensions you had to install to make it work better, and anyway it took me a while to get used to Eclipse itself and learn the shortcuts. I never thought this was unreasonable...
I wrote way more than I planned... all I really wanted to say after the Allegro recommend was I think if you really want to try CL, just go for it, the bare-bones experience can give you a taste just fine, and maybe encourage you to take the pains of setup for a more professional environment (for which emacs, while popular, is not the only choice). If you want to follow along a book like PCL (https://gigamonkeys.com/book/) or Land of Lisp (http://landoflisp.com/), you don't even need an editor, you can just type things in.
Hey, since you specifically asked for it: did you try Magic Racket? [1] It’s a VS Code extension for Racket based on the Racket language server. We don’t have feature-parity with DrRacket yet, but many people are contributing to the language server, adding new features continually.
Racket (CS) produces machine code. Yes, it packs the runtime along but that's certainly not your 'vanilla' interpreter. For example, it compiles a parallel GC profiled to your app along too. That's pretty hardcore, IMO! In fact, Racket is very similar in spirit to the GraalVM.
Does anyone here know how to get a good dev env. setup for Racket/Scheme in Windows 10 and VSC? I've tried the Magic-Racket LSP but it doesn't work with WSL2 because of some GTK dependency.
> It looks to me like the Lisp community knows something the rest of the world does not. They are not searching for the next hot thing. They seem to understand things on a deeper level than other communities. Perhaps “enlightenment” is not an overwrought term to use.
For those that haven't read this before. For me, any article making claims like this simply brings to mind the Lisp Curse:
http://web.archive.org/web/20210617140457/http://www.winesto...
(Not currently available... Last snapshot is from June, so unsure whether this is permanent or just temporary.)
Lisp is extremely flexible as a language. The core is very small, especially if you look at something like Scheme. But it lets you easily create and extend the language into what practically becomes a domain-specific language (DSL) for whatever problem you're working on.
Except what this really does is push things from being technical issues to being social issues. Sure, maybe I know Lisp. But how long is it going to take me to learn what your ultra-customized, macro-laden particular flavor of Lisp? And one has to do that for every single new project requiring coordination...
Lisp is not one language, but a wide variety of personal languages that happen to share a common core and syntax.