Earlier quoted context omitted.
To me, being able to make changes to your code while keeping the current state in the REPL is key to interactive development. My workflow is generally to build up state, and then experiment with functions on that state until I get the correct output. This workflow is very natural in Clojure, Common Lisp and even Python (with IPython and autoreload). However, in Racket you have to restart everything on every change. T…
I'm surprised no one has mentioned geiser. It sounds like exactly what you want for racket. http://nongnu.org/geiser/geiser_3.html
Why I haven't jumped ship from Common Lisp to Racket just yet
11–20 of 101 posts
Re: Why I haven't jumped ship from Common Lisp to Racket just yet
#12That Racket module functionality where you can add unit tests right with your code ("module+"), but will get stripped when compiled - that thing is quite magical. Is there another system that has this?
Re: Why I haven't jumped ship from Common Lisp to Racket just yet
#13Even the article's list of areas where Racket is "vastly superior" is questionable, IME. Granted, the author wrote ASDF, so he has a very different perspective than I do on the module system, but in practice nothing on that list has been a problem for me, and a few of them I'd actually consider to be anti-features (like a built-in GUI library).
Re: Why I haven't jumped ship from Common Lisp to Racket just yet
#14Also, related to that point: There are many different CL implementations out there that satisfy different use cases, like for example JVM deployment (ABCL), embedded systems (ECL), speed(SBCL), fast compile times (Clozure), pro-level support (LispWorks, ACL), etc. So the same code has a huge amount of options for deployment. It really makes Common Lisp be "write once, run anywhere".
Then speed is also never mentioned. Lisp can be seriously fast; under SBCL it is generally 0.3x to 1x C speed; LispWorks might be faster, and there's a PDF out there called "How to make Lisp go faster than C", so that should give an idea of Lisp speed potential.
CL wasn't created by philosophing about what a programming language should be for many years; CL was basically created by merging Lisps that were already proven in the industry (Maclisp, Zetalisp, etc), already proven to be good for AI, heavy computation, symbolic computation, launching rockets, writing full operating systems, etc.
CL is a "you want it, you got it" programming language. You want to circumvent the garbage collector? need to use GOTOs for a particular function? want to produce better assembly out? need side effects? Multiple inheritance? Want to write an OS? CL will deliver the goods.
In short, i would guess that from a computer scientist or reseacher point of view, Racket is certainly more atttactive, but for the engineer or start-up owner that wants to have killer production systems done in short time, or to create really complex, innovative systems that can be deployed to the real world, Common Lisp ought to be the weapon of choice!
Re: Why I haven't jumped ship from Common Lisp to Racket just yet
#15That Racket module functionality where you can add unit tests right with your code ("module+"), but will get stripped when compiled - that thing is quite magical. Is there another system that has this?
Re: Why I haven't jumped ship from Common Lisp to Racket just yet
#16The author, a famous and well-liked lisper, is not consider ing portability features. CL is an ANSI standard and code often runs with no changes in many distinct CL implementations/compilers/interpreters. Also, related to that point: There are many different CL implementations out there that satisfy different use cases, like for example JVM deployment (ABCL), embedded systems (ECL), speed(SBCL), fast compile times (C…
What? There's five points on the numbered list, #4 is entirely about speed.
Re: Why I haven't jumped ship from Common Lisp to Racket just yet
#17The author, a famous and well-liked lisper, is not consider ing portability features. CL is an ANSI standard and code often runs with no changes in many distinct CL implementations/compilers/interpreters. Also, related to that point: There are many different CL implementations out there that satisfy different use cases, like for example JVM deployment (ABCL), embedded systems (ECL), speed(SBCL), fast compile times (C…
> Then speed is also never mentioned. What? There's five points on the numbered list, #4 is entirely about speed.
Re: Why I haven't jumped ship from Common Lisp to Racket just yet
#18The author, a famous and well-liked lisper, is not consider ing portability features. CL is an ANSI standard and code often runs with no changes in many distinct CL implementations/compilers/interpreters. Also, related to that point: There are many different CL implementations out there that satisfy different use cases, like for example JVM deployment (ABCL), embedded systems (ECL), speed(SBCL), fast compile times (C…
Re: Why I haven't jumped ship from Common Lisp to Racket just yet
#19That Racket module functionality where you can add unit tests right with your code ("module+"), but will get stripped when compiled - that thing is quite magical. Is there another system that has this?
Re: Why I haven't jumped ship from Common Lisp to Racket just yet
#20That Racket module functionality where you can add unit tests right with your code ("module+"), but will get stripped when compiled - that thing is quite magical. Is there another system that has this?
I don't think it is an official part of the language but the Pragmatic Programmers Elixir book does this in one of their examples code sections.