Live data from Hacker News

Why I haven't jumped ship from Common Lisp to Racket just yet

fare.livejournal.com

11–20 of 101 posts

Re: Why I haven't jumped ship from Common Lisp to Racket just yet

#11
post #5

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

There is also racket-mode (available on MELPA): https://github.com/greghendershott/racket-mode

Re: Why I haven't jumped ship from Common Lisp to Racket just yet

#12

That 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.

Re: Why I haven't jumped ship from Common Lisp to Racket just yet

#13
I use Common Lisp quite a bit, and I'm just not interested in switching to another Lisp. I've looked at most of them, and haven't seen anything compelling. CL still wins on everything that I care about (performance, portability, libraries, ease of use, books/documentation, etc.).

Even 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

#14
The 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 (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

#15

That 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?

Rust. https://doc.rust-lang.org/book/second-edition/ch11-03-test-o...

Re: Why I haven't jumped ship from Common Lisp to Racket just yet

#16

The 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

#17
post #16

The 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.

Sorry. Speed is mentioned but overlooked, because the figures are not mentioned. It should be 2x-8x speed increase in favor of CL. For some people this truly doesn't matter (after all, Ruby is successful and loved), for other applications, it does matter a lot.

Re: Why I haven't jumped ship from Common Lisp to Racket just yet

#18

The 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…

Looking at ECL, it doesn't seem to have a bare metal port? Or am I missing something? I take it "embedded" in this case means "links with your C code", not "runs on bare metal micro-controller."

Re: Why I haven't jumped ship from Common Lisp to Racket just yet

#19

That 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?

From thescribe's parallel comment it sounds like you're describing doctests which is a built in feature in Elixir, and I believe in Python also. Many languages have doctest libraries available, though not many support it being part of canonical documentation... I've been meaning to try the ruby-rspec doctest library https://github.com/doctest/doctest-rspec though there's several others besides that one

Re: Why I haven't jumped ship from Common Lisp to Racket just yet

#20

That 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.

It is an official part of the language, and is automatically part of the compiled docs, which are also an official part of the language! https://elixir-lang.org/getting-started/mix-otp/docs-tests-a...
Post reply on HN