Common Lisp vs Racket

https://gist.github.com/vindarel/c1ef5e043773921e3b11d8f4fe1ca7ac

by ducktective • 4 years ago

250 190 4 years ago

gist.github.com

amitprayal• 4 years ago

I think I would be better to compare CL with Clojure rather than Racket...since Clojure has found some usage outside academia

pjmlp14• 4 years ago

Industrial use of Common Lisp,

https://franz.com/success/

http://www.lispworks.com/success-stories/

ctrlmeta3• 4 years ago

I think the parent comment is suggesting that a comparison of CL vs. Clojure is more useful than the current comparison of CL vs. Racket.

fredrikholm• 4 years ago

OP questioned Rackets use in industry, not CL.

AFAIK, the only (more known) uses of Racket is as a scripting language for Naughty Dogs PS3-era games, and it was made to make Arc (which runs HN).

simongray• 4 years ago

Or how about all three + Java: https://clojure.org/reference/lisps

Syzygies2• 4 years ago

A document that puts these differences in context is Rich Hickey's "A History of Clojure"

https://download.clojure.org/papers/clojure-hopl-iv-final.pd...

The design decisions in this paper strongly resonate with me. It helped me to overcome my aversion to JVM-hosted languages, and settle down to learn Clojure.

I'm a research mathematician, at one extreme where code is steps up a mountain. I don't need to summit twice, so productivity is far more important than speed. Nevertheless, the fastest Clojure time trials use GraalVM:

https://www.graalvm.org/

medo-bear8• 4 years ago

from the same person ... https://gist.github.com/vindarel/3484a4bcc944a5be143e74bfae1...

jmeister• 4 years ago

Thanks.

nextos• 4 years ago

I've written quite a lot of Clojure and some Racket, but never really settled down on CL aside from reading PCL and most of PAIP.

In other words, I never coded something sufficiently big to understand the pros of CL.

Hence, I'm curious. What stuff I'm missing out in terms of language features and libraries?

medo-bear8• 4 years ago

for me the following things stand out

use common lisp (sbcl) if you want c-level performance

use common lisp if you want to make optimizing compilers

use common lisp if you want smalltalk type repl driven interactive development

abudabi123• 4 years ago

I'm curious to know what was lost to the Lisp users in the change on Apple's Newton device going from the early Ralph implementation in Lisp to cplusplus.

On r/lisp there was a rant that included a reflection that things would be done in a third the time. There was an ask for $60M to apply Lisp to know a different world. Apple can easily afford a $180M experiment to see Ralph/Dylan implementation of iOS/macOS. If proved successful would the software platform leap how the hardware has done across multiple architectures? The ARM M series devices are a there and back again move given Apple Newton was on ARM and Apple invested which kept the idea alive.

pjmlp14• 4 years ago

A Common Lisp example that leaves out Lispworks and Allegro Common Lisp focusing only on SBCL + emacs, as usual.

medo-bear8• 4 years ago

but sbcl is far more common than those two. its also free, unlike those two. i think this is ok as long as its stated cleary (and it is)

pjmlp14• 4 years ago

And so the knowledge of a poor development experience for Common Lisp keeps spreading.

abrax314112• 4 years ago

I’ve used all of these semi-extensively (slightly less so LW). The environments you get with FL and LW are useful if you aren’t an experienced Emacs user, and each of the pro ones comes with a lot of useful support (and FL’s amazing but expensive gdb), but these days, if all you want to do is get programming done, and don’t need, or don’t want to pay for a highly supported world-class engineering platform, you can do pretty much everything you want at a lot less cost and weight with sbcl, emacs, amd some calling to python. Libraries. If some multi-millionaire wanted to do the world a solid, they’d buy and open source (and pay for continuing support) for FL.

phoe-krk2• 4 years ago

Care to pay the author for an Allegro CL and/or LispWorks license so they can broaden their article?

pjmlp14• 4 years ago

Community licenses are available, I don't need to pay anything.

e3bc54b23• 4 years ago

SBCL is de-facto most popular implementation of Common Lisp, if I dare say. It is free, it is well maintained, it is easily available, and it is fast. As a student/enthusiast, it doesn't get much better.

Lispworks/Allegro is better if specialized requirements or actual money is on the table. Lispworks supports mobile platforms IIRC which SBCL does not, for ex. But if all one needs is server side deployments or personal projects, there is no need, nor any use of commercial implementations, as good as they might be.

pjmlp14• 4 years ago

Basically like GCC with VI, or using Clion or Visual Studio kind of difference.

avodonosov• 4 years ago

My choice is CCL

_ph_7• 4 years ago

One has to stress: SBCL is probably by far the best Lisp compiler out there. So it is not only free, but also good. Might require a few type annotations to get the best performance though. And the diagnostic messages can sometimes be annoying, but they are right :)

Shorel• 4 years ago

Wasn't the price of these implementations one of the factors for the (symbolic) AI winter?

I would say it's just karma.

lispm7• 4 years ago

These implementations survived the AI Winter, despite their high prices.

A lot of the cheaper commercial implementations did not survive or did not thrive: Corman Lisp (now open source, but not used much), Golden Common Lisp, Exper Common Lisp, Procycon Common Lisp (got bought by Franz), MuLisp, Macintosh Common Lisp, ...

forgotpwd16• 4 years ago

Not at all. Both of those projects started inside the second AI winter. They can even be seen as an attempt to save Lisp after the market collapse for Lisp-specialized hardware. That said tooling for other contemporary languages was high as well back then. Won't be surprised if relatively to the total costs for them LispWorks and ACL were cheaper.

kasajian• 4 years ago

I just can't get past referring Scheme as "schemes". Forcing myself to read the rest of the article. Am I getting punk'ed?

thaumasiotes• 4 years ago

I just can't get past referring Scheme as "schemes".

That isn't something that happens in the article. Compare this sentence:

> Now if you still want to use Scheme, Racket blows the other Schemes out of the water with what you get out of the box. […] But it is not without its problems.
Am I getting punk'ed?

Only by yourself.

kbutler• 4 years ago

  I prefer _schemes_ over _Common_Lisps_, and I prefer Racket of the Schemes.

The author is just using the plural to acknowledge there are multiple variants of the scheme and common list languages and environments.

This is not uncommon.

greymalik• 4 years ago

Am I missing the part where it says the specific use cases the author is speaking about? It sounds like their arguments are based on ”real-world” development, while my guess is that Racket might fare better when you’re looking strictly at a tool for learning.

dj_mc_merlin• 4 years ago

At the beginner (high school / undergrad) level all Lisps are more or less the same. The finer points of Lisp-1 vs 2, CLOS, etc. are not comprehensible without a lot of prior work.. and by that point you should optimize for real world practice anyway IMO (something which many university courses do not do).

If we're talking middle school then there are some arguments to be made that Racket's easy-to-use graphics libraries are more conductive to learning. It will never be Flash though.

abrax314112• 4 years ago

Scheme diverges from lisp pretty fast.

rscho6• 4 years ago

I am surprised to hear that multiple namespaces with identical symbols is not a source of confusion for learners. IMO, in high school I would've been lost.

atemerev• 4 years ago

Common Lisp is awesome. SBCL is fast, there are a lot of decent libraries (https://awesome-cl.com/), and you can use it immediately in production. Lisp REPL-centric development requires some adjustment, and basically* you don't have other IDE options besides Emacs with Slime or Sly, but Common Lisp was the reason I finally learned how to live with Emacs.

* — there are also Slyblime for Sublime Text and ALIVE for VS Code, but they are very beta-quality.

klipt3• 4 years ago

For someone who's never used Emacs properly, what's a good tutorial for using Emacs together with CL in the synergizing ways that people claim are so amazing?

Jach6• 4 years ago

Maybe start with https://lispcookbook.github.io/cl-cookbook/emacs-ide.html The 'magic' though isn't really that emacs dependent; if you like vim (like I do) you can use vim and still get that amazing experience. https://lispcookbook.github.io/cl-cookbook/editor-support.ht... has some details on alternatives. Anyway, the magic or synergy is really a combination of: CL itself being designed to support interactive development, a little server you embed (typically automatically if starting from an editor) in a running CL program called Swank, and a standard set of commands to talk to that server (and the underlying Lisp) and interface with your editor called SLIME (https://slime.common-lisp.dev/doc/html/).

The basics of the commands do things like send code over for compilation and redefining things, running things, responding to errors, debugging things, jumping to definition locations.. things you'd normally expect an IDE to do, except because of CL itself so much of that is part of the language and not a separate IDE. Some more editor-specific things come into play that some people really love, and while they may be best done in emacs they're not unique to emacs either. (Example: suppose you messed up the order of your arguments to a function, so it's written like (my-func (list something) some-other-arg) -- editors have support to swap those two arguments in one go, rather than having to backspace and retype or whatever. I personally don't find such features that magical, and are table-stakes even for things like Eclipse editing Java. Meanwhile even emacs is still weak for some things like large-scale automated semantics-aware refactoring...)

I'm fond of this short 5-part blog series https://malisper.me/debugging-lisp-part-1-recompilation/ (has some emacs gifs) that shows some of these features. But notably again, the experience isn't limited to emacs.

whartung2• 4 years ago

Honestly, watch some of this series.

Kaveh's Common Lisp Lesson 01 https://www.youtube.com/watch?v=nSJcuOLmkl8

He doesn't take you by the hand to setup an environment, but it's a neat exposure (introduction isn't quite the right word) to someone using CL to do interesting things.

Mind its a bit Mac and Clozure CL specific if you wanted to follow along, but it's still a good watch of just seeing someone doing stuff without explicitly telling you what they're doing. Sometimes you just want to get stuff through osmosis, and he does interesting, basic things with CL at all sorts of levels.

mark_l_watson2• 4 years ago

Depends on what you are working on. I happen to like Racket a lot but no one has ever paid me money for Racket development. In the last 40 years, lots of paid Common Lisp work.

Racket’s portable GUI and app builder are very good, as is LispWorks’.

mhaberl• 4 years ago

How do you find CL gigs? What kind of companies/apps use CL? Are they all legacy systems? How does it pay in relation to projects using "mainstream" languages?

reikonomusha9• 4 years ago

HRL Laboratories writes new code in Common Lisp for quantum computing. They have internships and full-time positions.

Google employs Common Lisp programmers as well for their flight search product.

RavenPack, SISCOG, GrammaTech, Grammarly, SRI (?), MIND.AI, and others as well (or at least used to). Check out [1].

[1] https://github.com/azzamsa/awesome-lisp-companies

mark_l_watson2• 4 years ago

I have written two Common Lisp books, one for Springer Verlag and one self published- that helps.

MichaelCollins• 4 years ago

Racket’s portable GUI and app builder are very good,

Ehh.. they're pretty good and I'm thankful for them. I don't think I'd go as far as 'very good' though; the selection of widgets provided is basic. My rule of thumb is that if your application only needs the sort of functionality you can find somewhere in DrRacket, then racket/gui will be pretty good. But if you need a widget you can't find in DrRacket, then you'll probably have to implement that widget yourself.

reikonomusha9• 4 years ago

I'm a heavy user of Common Lisp, and I only dabble in Racket from time to time. While Common Lisp is my tool of choice for a lot of reasons stated in the post, since the post largely skews favorably toward Common Lisp, I'll offer two things that Racket shines at:

1. Documentation

Racket has a beautiful documentation system called Scribble [0]. Almost all documentation written for Common Lisp is ugly, inconsistent, and doesn't follow any sort of standard. Common Lisp has a gazillion "documentation generators" which do little more than slurp up all the documentation strings and barf them back out as e.g. HTML. Common Lisp users tend to just rely on READMEs + jump-to-definition to learn how a project works. A few Lisp programmers (e.g., Shinmera, Edi Weitz) have made their own documentation systems that look better than average, but are still at least an order of magnitude less capable than Racket's offering.

Racket's documentation system is aesthetically pleasing, very well organized, and makes the programmer want to write long-form documentation. Moreover, Racket (the language) sets a superlative example of what its users can strive for in terms of quality of clear, no-nonsense writing.

2. Languages and DSLs

One of Lisp's (any dialect) defining features is the ability to build domain-specific languages, syntactic extensions, and the like by way of a special kind of function that can run prior to the code's execution. These special functions are called "macros", and across Lisp dialects, there are lots of different takes on them.

Common Lisp gives you a grab bag of facilities for writing code that lets you change syntax at different levels: DEFMACRO (scoped variant: MACROLET), DEFINE-COMPILER-MACRO, DEFINE-SYMBOL-MACRO (scoped variant: SYMBOL-MACROLET), SET-MACRO-CHARACTER, and a few others. At best, I'd consider these only loosely related, and they all work on really "raw" data representations (parsed S-expressions and character streams). In part because of this, ANSI Common Lisp doesn't provide access to any notion of environment, source location, etc. when writing new macros.

Macros defined by the above operators "live" in different places and are compartmentalized in different ways. There are some Lisp libraries that help you tame definitions and keep them fenced in, like NAMED-READTABLES which helps you organize where reader macros (macros which change how Lisp is parsed at the character-level) live and how to turn them off and on in a sane way.

Contrast with Racket which has explicit documentation on how to write macros [1,2], how to debug them [3], and how to encapsulate them a new DSL embedded in the system [4]. Racket—as a technical system—clearly defined the phases of compilation, what objects are manipulated during the phases (e.g., "syntax objects"), how to provide debugging information, and so on.

In the end, Common Lisp's system for making DSLs feels a little runny. It's supremely hacker-friendly, but it's a bit more difficult to deliver, in one fell swoop, a language as a library. Racket, on the other hand, at the expense of having increased rigidity and needing to read two or three complete chapters of a manual, you get a way to neatly bundle up a language. This is why Racket had nice DSLs like Typed Racket, Hackett, Scheme RnRS, etc.

I use Common Lisp and I develop relatively large DSLs in the language, and even if I want to, it's hard—if not impossible—to write large DSLs that have nice error messages, source locations, etc. without writing an entirely new "reader" (lisp's term for a code parser) myself every time. Smaller DSLs where user code doesn't exceed more than a few lines? Examples like:

- regex syntax

- string interpolation syntax

- a pattern matching feature

Common Lisp is great, and you get a ton of mileage out of the facilities it provides. But larger ones? Examples like:

- an embedded language for writing documentation with markup

- a complete language with lazy evaluation semantics

- a language for non-deterministic programming (like SCREAMER, Prolog)

- a language for strictly typed functional programming (like Coalton, Hackett)

Tackling these in Common Lisp requires ambition and a very steady hand, whereas Racket's overall system (language, implementation, documentation) makes that a comparatively painless exercise.

[0] https://docs.racket-lang.org/scribble/

[1] https://docs.racket-lang.org/guide/macros.html

[2] https://www.greghendershott.com/fear-of-macros/

[3] https://docs.racket-lang.org/macro-debugger/index.html

[4] https://docs.racket-lang.org/guide/languages.html

db48x5• 4 years ago

I’ve never used Racket, but reading your description of the documentation (and Scribble) makes me want to check out that aspect of it. I wonder how it compares with rustdoc? I do mostly Rust these days and its generated documentation is usually really good.

db48x5• 4 years ago

Oh, I see. Scribble looks a little like TeX, but actually it’s an alternate read syntax/dsl. The first example where they show off the real utility of it is:

    @tabular[#:sep @hspace[1]
             (list (list @bold{Animal} @bold{Food})
                   (list "mouse"       "cookie")
                   (list "moose"       "muffin"))]

which really drops it in your lap. “tabular” isn’t from some fixed list of keywords, it is an ordinary racket function that you can call, with ordinary arguments that can be strings, lists, etc. Presumably there will be an example in the next page or two with @define[…] in it to close the loop.

And the table of contents promises literate programming as well. Someone was really thinking when they put this together; I really like it.

The documentation generated for individual functions (such as <https://docs.racket-lang.org/scribble/base.html#(def._((lib....>) is fairly nice as well. Readable, linked together by hyperlinks on the type predicates as well as hyperlinks in the body of the documentation itself; it’s pretty good. Rustdoc puts links to the source code for each one though, and I would soon miss that.

sph3• 4 years ago

The generated Rust docs... are not very good. And on more complex types you have a ton of traits, with methods and all their lifetimes and generic parameters which are really hard to follow if you're unfamiliar with a library or Rust in general. Also, even the biggest libraries (clap for example) reserve a couple paragraphs for the front page prose and leave the type docs to speak for themselves... which is just not good enough.

I would go as far as to say that a non-negligible part of why people are intimidated by Rust is the rustdoc format and layout. Thankfully it makes up for it with an incredible Rust Book.

To me the gold standard of docs is Elixir followed by Racket. Even Go's docs are better than Rust, but that's mostly because of a much simpler type system, so simpler autogenerated docs for structs and their methods.

djhaskin987• 4 years ago

The only other equal I've seen to scribble around is Python's Sphinx. I use Sphinx for all my projects no matter what language they're in because it's so good.

adamddev1• 4 years ago

I've loved using Racket docs while working through HTDP. Very clear pleasant to search/look through. Great definitions both with formal specification as well as practical examples, and all the types etc are nicely hperlinked together.

abrax314112• 4 years ago

https://lisp-journey.gitlab.io/blog/overview-of-documentatio...

pyb2• 4 years ago

Unfortunately, I think perhaps might have come to a different conclusion if you'd tried Racket's so-called "hygienic" macros in anger. I've found them difficult to properly understand, not very usable in practice, and overly complex for non-trivial cases.

This is not what you'll usually read in forums, I think DEFMACRO is the better design here.

reikonomusha9• 4 years ago

Racket's macro system is quite baroque and supports a lot of things. You don't need to use hygienic "syntax-rules" at all. Consider writing your own transformer [1], which can be an arbitrary lambda function without restriction.

Or, import defmacro [2] and use that.

As can be seen, Racket actually provides more power and choice in this regard, including support for Common Lisp's way.

In any case, I make no claim to either being better or worse. I just think Racket is more principled in its mechanisms for defining and delivering a DSL to a user.

[1] https://docs.racket-lang.org/guide/proc-macros.html

[2] https://docs.racket-lang.org/compatibility/defmacro.html

soegaard4• 4 years ago

You are hanging out in the wrong forums :-)

The `defmacro` model is "simpler", true - but it is fragile and breaks down when you want to do complicated things.

Check this blog post written by someone, who knows hos Common Lisp.

EVAL-WHEN considered harmful to your mental health https://fare.livejournal.com/146698.html

nathan_compton• 4 years ago

To each his own, obviously, but I've programmed a fair amount in CL and Scheme and vastly prefer syntax-case to defmacro. There is a little more cognitive overhead, but it all makes sense. Syntax-case macros are easier to write and read, from my point of view.

And Racket has syntax-parse, which is even nicer, I seem to recall.

klipt3• 4 years ago

I use Common Lisp and I develop relatively large DSLs in the language, and even if I want to, it's hard—if not impossible—to write large DSLs that have nice error messages, source locations, etc. without writing an entirely new "reader" (lisp's term for a code parser) myself every time.

We have to go deeper! Could you write a DSL in CL to help you write new DSLs as easily as in Racket?

zelphirkalt4• 4 years ago

This is what Racket people have done to write Typed Racket in it. I think it is called Turnstile: https://docs.racket-lang.org/turnstile/.

ruricolist• 4 years ago

I have a project to do that, https://github.com/ruricolist/vernacular, although I'm not working on it right now.

bmitc• 4 years ago

What about package management? I feel Racket’s is more standardized. I get pretty confused trying to install some requested Common Lisp packages. Browsing to the package websites, there’s no commonality, and there’s even usually no information on how to install them.

Jtsummers5• 4 years ago

https://www.quicklisp.org/beta/

Quicklisp has become the main way many (most?) people handle installing a library for Common Lisp. Under the hood, ASDF is used for defining the system and specifying how it should be compiled and such as has also been standard in the community for a very long time.

michaelwww4• 4 years ago

As someone trying to understand what people find special about Lisp, this was helpful. I get it now about macros, but doesn't modifying the language in the compiler phase just complicate solving the actual runtime problem? I feel I would get distracted into writing my own DSL. I've never wanted to modify the language as I was writing in it. Now I'm curious.

reikonomusha9• 4 years ago

Don't think of it as modifying the language. Think of it as adding new ways of expressing ideas in the existing language.

These sorts of languages/language extensions pop up all the time in "ordinary" programming. For example, common DSLs we see often.

- regex is a language for string patterns

- JSON is a language for simple nested data

- SQL is a language for expressing DB queries

- OpenMP contains (essentially) a language for parallelizing loops

- (this might sound crazy because it's so common and basically built in standard in almost all programming languages:) infix notation for math

The problem is that many of these are absolute kludges in existing languages. Anybody who has had the displeasure of trying to interpolate DB table names into SQL SELECT strings knows this. Most languages try to make it a bit better by adding preprocessors, using builder-patterns, abusing reflection, or otherwise. Looking under the hood of some languages' implementations of these ideas will often lead you to see the most cursed of programmer things in existence.

Each of those languages (or close syntactic cousins of them) can be written directly in Lisp, as a library, without shoving them into strings, or using external tools, or making custom file formats. They call can exist as a part of the Lisp language as a syntax extension.

Making DSLs requires exercising that muscle a bit; it's non-trivial to design a new and useful language that fits orthogonally into an existing system.

It's like being introduced to OO programming where, at least for me, it made sense but it wasn't immediately obvious what a good object model for a problem might be. It took me lots and trial and error to understand how OO works in "the real world", where it's good, and where it falls short.

Once you get they hang of making DSLs—or even just small but powerful syntax extensions—it's an amazing tool to have at your disposal.

srcreigh• 4 years ago

I don't know how this exactly fits, but you can do crazy stuff like query a SQL db in the compiler to check your Racket program for auto generated variable names. This extends the editor tooling to highlight names which don't match to columns in the DB tables.

I wrote a post about this here[1]

[1] http://tech.perpetua.io/2022/01/generating-sqlite-bindings-w...

yyyk24• 4 years ago

The GUI situation in Common Lisp is pretty pitiful. AFAIK the best you get is ECL+QT5 or cffi-cl-gtk (which is GTK 3). I don't see a very favorable comparison for Racket at all in anything else though. When people talk about the benefits of Lisp, they are usually talking about the benefits of /Common/ Lisp. Other languages often misunderstand what makes Common Lisp so great, like in the case of Scheme's overly complex pseudo-macro system.

rscho6• 4 years ago

I'd argue that the brightest minds in computer science understand what makes lisp great perfectly.

In the lisp tradition, they made a lisp geared towards their use case, specifically. It's called Scheme... which sports much more than 'a pseudo-macro system'.

yyyk24• 4 years ago

I'd argue that the brightest minds in computer science understand what makes lisp great perfectly.

That is your personal opinion. Personally, I consider the design of Common Lisp to be much superior.

In the lisp tradition, they made a lisp geared towards their use case, specifically. It's called Scheme...

If by "their use case" you mean teaching CS, then I would agree.

which sports much more than 'a pseudo-macro system'.

Well, Scheme doesn't really have many features. It's meant to be a simple (and by extension limited) language. I mentioned their pseudo-macro system since it's one of the parts where Scheme (badly) disconnects from its Lisp lineage.

_ph_7• 4 years ago

There are also TK bindindings https://github.com/herth/ltk

lispm7• 4 years ago

The best GUI support for Common Lisp one gets from the commercial implementations Allegro CL and LispWorks. Both have cross-platform GUI libraries (ACL for Windows and Gtk, LispWorks for Windows, Gtk, macOS and Motif). Both have their IDE implemented with their respective GUI library. If one would wants to write a substantial GUI application in Common Lisp, that's one of the reasons people pay quite a bit money for those implementations and for commercial support.

There have been very substantial GUI applications implemented with both systems.

vindarel• 4 years ago

yeah… there are good IUP bindings, and embedding a CL web app into Electron (or Neutralino) is easy, once you have your standalone binary (I'll blog about that). https://github.com/CodyReichert/awesome-cl#gui

pdimitar5• 4 years ago

All of that barely matters to me. Where's the transparent parallelization? 2022 is going to be over soon, no language has any excuse to lack an easy way to do message passing and automatic thread pool management like Erlang and Rust's `tokio` do.

SighMagi• 4 years ago

Lparallel is typical employed for transparent parallelization, thread management etc. https://lparallel.org/cognates/

reikonomusha9• 4 years ago

There is a good excuse: Not having multi-{m,b,t}illion-dollar corporate entities working on the language full-time is a good reason for something to not exist.

Not having a corporation back the development of a language has tons of downstream effects, including:

- lack of support opportunities

- lack of employment opportunities

- lack of evolution and development of an ecosystem

- higher churn and/or attrition

- fewer opportunity to do long-term design and implementation projects

Yes, sometimes there are FOSS miracle workers who are so extraordinarily productive without being paid, but they're few and far between.

(Aside from that, not all users need such functionality.)

Zambyte• 4 years ago

tillion :D

pdimitar5• 4 years ago

Honestly, there are way too many programming languages already. Even though a chunk of them are interesting as thought experiments and potential future investments (like that one that content-addresses its own AST; forgot the name), I believe it's high time we all focus on more practical aspects.

Parallelism is one of those. Only microcontrollers are single-core these days, and not even all of them.

I sympathize with the people who have fallen in love with their own idea and are sad that others "don't see the light" and don't support them -- but our world is an imperfect system and that's a fact of life.

F.ex. I'd kill for a LISP with strong(er) static typing plus Erlang's transparent parallelism and runtime but yeah, we don't have that. So Elixir and Rust it is for me.

Syzygies2• 4 years ago

Wow, I did a double take, you sound like me. When I said something similar praising Haskell's effortless parallelism, someone made a reply that lead to my learning Clojure.

pdimitar5• 4 years ago

That Haskell has a transparent parallelism is news to me. Does it do the things that Erlang does? Or at least Rust's `tokio` async runtime?

fulafel2• 4 years ago

Transparent parallelization needs a new generation of languages that are designed to let compiler do parallelization transformations. Like Futhark. Hopefully we can get better integration than in the procedural language side where the parallel languages are completely separate from host app languages and are called via FFI.

pdimitar5• 4 years ago

Well, I am likely misguided since I never wrote a compiler in my life -- but to me it feels the "purer" a language is, the easier it is to make automated analysis on how to parallelize its code fragments? Hence FP languages are better candidates, I'd think?

neilv• 4 years ago

Some of these objections are the author taking well-known properties of CL as must-haves, and evaluating other languages against them.

Considering them must-haves is perfectly reasonable for a programmer who wants to work in that style. For example, being able to (put roughly) modify any part of the system at any time, and let the semantics decide what happens.

Scheme/Racket absolutely is not CL, and Racket has been moving further away from CL than Scheme already was. I've worked on critical production systems in both Scheme/Racket and CL professionally, and they are very different languages, and people wouldn't confuse them if they didn't both use S-exp syntax. (Individual Lisp family developers are also different. There are some shared memes, but you don't end a Lisp family language expert today, and shunning that $500K Python job, without being stubbornly self-motivated and/or self-destructive.)

One of the keys to learning Scheme originally was to put aside my biases about what was important, try to use and then understand the idiomatic way, so that you can then decide what makes sense.

(Examples: My own first bias when learning Scheme was trying to micro-optimize for runtime as I coded, like I would in C, but I didn't know what cost model I should reason about. If you look at the first Scheme code I wrote, https://pkgs.racket-lang.org/package/html-parsing , it's a little like a C programmer with some non-Scheme Lisp experience.) One of the next barriers was learning to avoid mutations and premature exits, and to leverage tail recursion. Before I learned that, I couldn't have told you that can make code easier to read.)

When we were first learning computer things, there was an implicit suspension of disbelief or acknowledgement of not knowing. As we grow more knowledgeable, we have to be careful not to plateau or become rigid, assuming we know the right way, and dismissing things that are nonintuitive. Sometimes we will be right to dismiss them (and often will be, in corners of "tech"), but sometimes we will miss out. It's even not necessarily a net loss if we invest in understanding a perspective, and then determine its flaws, because we may still have added some new useful ideas to our mental toolkit.

joppy• 4 years ago

Where are you finding $500k python jobs?

eru6• 4 years ago

Finance is one of those areas.

discardable_dan2• 4 years ago

This analysis is spot on. The author is annoyed about the absence of many things that, in most programming languages, would be seen as outright absurd. People have come to realize multi-methods, monkey-patching, and mutable interfaces break down when writing code at scale, across a large team. It's no surprise that Racket has internalized these lessons, and someone in love with Common Lisp would see these as shortcomings. A Haskell programmer could similarly rant about Python's lack of closures, a C++ programmer about JavaScript's lack of templates, and so on. There are many reasons to hate many languages, but "that language isn't this language" is a rather petty one.

eru6• 4 years ago

Minor nitpick: Python actually has closure as far as I can tell.

But, no worries: Haskell programmers still have plenty to rant about Python. And vice versa.

amyjess2• 4 years ago

A better developer experience. Emacs + Slime is way better development and debugging experience than either Emacs + Geiser, or Emacs + Racket-Mode or Drracket.

I've thought about learning a Lisp in the past, but the Lisp community's insistence on using Emacs has completely put me off of it. I will not use Emacs under any circumstances, and you couldn't pay me enough money to change. And this had lead me to conclude that Lisp is simply not for me.

Jtsummers5• 4 years ago

You can always use a commercial Lisp vendor's solution or vim + slimv for CL or Dr. Racket for Racket. There are other comments in this thread about the vim + slimv alternative to emacs + slime (I don't use it myself since I learned emacs as a freshman in college and stuck with it, so check out their comments to get an idea of how its done).

boohoohoo123• 4 years ago

I don't think anyone insists that you use Emacs?

Anyway, not sure why anyone but you should care about you learning something?

Everyone have to deal with their own psychological barriers somehow.

dr-neptune• 4 years ago

Is it because you are used to vim bindings? Emacs offers an "evil mode" that implements modal bindings

amyjess2• 4 years ago

I have multiple reasons for not wanting to use Emacs. I detest every facet of the UI, among other things.

Also I don't care about Vim bindings. I use Kate for writing code about 75% of the time anyway and would prefer to continue doing so.

Labo333• 4 years ago

Those days I'm really rooting for PicoLisp (https://picolisp.com/wiki/?home)

dunefox• 4 years ago

I don't use either and both languages are on my todo list, but I think I would have already used Racket if I liked the editing experience more - DrRacket is just not going to cut it, if I'm completely honest. CL with Spacemacs is pretty good.

Common Lisp vs Racket

Related Stories