Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

fare.livejournal.com

Post reply on HN
Print view View original

51–60 of 101 posts

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

#51

Post by bad_login »

mjmein wrote: post #8
stonemetal wrote: post #6

Earlier quoted context omitted.

It isn't in DrRacket by default but it is a common enough requested feature that they keep an example of how to add it in the documentation. https://docs.racket-lang.org/drracket/Keyboard_Shortcuts.htm...

Thanks. Do you know if it works with the module system - for example, if I edit function definition in a module, and then send that module definition to the REPL, would any code using that module start using the new definition?

It works in geiser-mode, i don't know if it works with drracket or racket-mode.

http://docs.racket-lang.org/guide/eval.html?q=namespace#%28p...

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

#52

Post by criddell »

jlarocco wrote: post #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 d…

What domains are you using CL in? The last time I used a Lisp was inside AutoCAD and it was a lot of fun.

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

#54

Post by flavio81 »

pjmlp wrote: post #35
flavio81 wrote: post #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 (C…

The biggest issue I see with Common Lisp is that the standard is stuck in time, lacking stuff like database providers, a common FFI or threading. It needs a review of the CL environments that survived to modern days and adopt the common extensions.

> is that the standard is stuck in time, lacking stuff like database providers, a common FFI or threading.

You don't need database providers to be integrated in the language spec. Not in CL and not in many other successful languages.

We already have a de facto common, portable FFI: CFFI.

We already have more than one library to do threading in a portable way. Also, threading has been left out of the CL standard on purpose, so each implementation can offer different capabilities and you can choose whatever fits best to your problem.

> The biggest issue I see with Common Lisp is that the standard is stuck in time,

The standard is from 1994 and Lisp is still pretty much one of the most modern and advanced languages around; i would say it's the other languages, like Java, that historically get new 'versions' each few years because they can't be extended using the very same language, unlike in Lisp or other modern languages like Julia or Racket.

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

#56

Post by farray »

bad_login wrote: post #53
farray wrote: post #10

Interestingly, I just added a section on Gerbil, the Lisp dialect I have adopted instead of PLT, for many personal reasons.

What is your setup working with gerbil compared to emacs/slime?

My current setup does not compare favorably with Emacs/slime at this point. I use screen, I call a build script in one shell REPL, I use gerbil-mode in Emacs in the other, reload'ing things that I rebuild, or restarting the M-x run-scheme when too much has changed, copy-pasting from a gerbil-scratch.ss file, or repeatedly loading a .ss file with on-going tests. This is less than satisfactory. We hope to improve the situation this year so we can use geiser or slime or something similar.

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

#58

Post by flavio81 »

lottin wrote: post #30

> trivial utilities for interactive use from the shell command-line with an "instantaneous" feel Last time I checked CL images were huge though. Something like 24MB for a "hello world" executable, even bigger with some compilers.

> Last time I checked CL images were huge though. Something like 24MB for a "hello world" executable, even bigger with some compilers.

You need to consider that Common Lisp includes a runtime, and this is a essential part of the goods of Common Lisp. Whenever you create a Common Lisp program, you also "embed" the runtime, and the runtime allows you to do wonderful stuff within the running code, like for example, compile code on the fly, replace function with new version (while the program is running), replace class instances with new versions of the class (while the program is running), all sorts of enforcements of the required data type for actual data* (while the program is running),

and,

it has the wonderful "conditions/restart" system. The combination of the latter with all the former, allows you to 'correct' or 'patch' a running program without really needing to recompile the whole program or even restart the running program. Famous story of usage of this feature is using it to patch a bug on the Common Lisp program for the autopilot of the NASA Deep Space One spaceship. The NASA engineers were able to debug and then fix the program while having the DS1 in space with the code running.

So, the FASL (fast load) file is basically similar to the memory file created whenever you put a laptop into "hibernation" mode; it allows you to quickly load the whole runtime, plus your code, *plus the instances of your objects or data, if needed, just straight into memory. This is how "fast load" is achieved.

Actual RAM usage of Lisp will vary with implementations; again, as I mentioned in another post, you pick the implementation that suits your particular needs.

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

#59

Post by moomin »

jackdaniel wrote: post #44
pjmlp wrote: post #39

Earlier quoted context omitted.

Which usually is what leads to feature expressions spaghetti. Also, it means that a Lisp newbie won't be aware of what are the best libraries that are portable across Lisps for such features. EDIT: typo correction (missing are)

Feature expressions shouldn't be used in normal applications, only in portability libraries. To use threads on any implementation which supports them (given it's supported by the recommended portability layer): > (ql:quickload 'bordeaux-threads) > (bt:make-thread (lambda () (sleep 1) (print "hijack"))) that's all, no feature expressions whatsoever. Quicklisp is a system manager (something similar to npm in sense that…

I think the point is you can't really have it both ways. CL prides itself on its extensive and portable standard library, but has huge gaps by the standards of modern languages.

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

#60

Post by pjmlp »

flavio81 wrote: post #54
pjmlp wrote: post #35

Earlier quoted context omitted.

The biggest issue I see with Common Lisp is that the standard is stuck in time, lacking stuff like database providers, a common FFI or threading. It needs a review of the CL environments that survived to modern days and adopt the common extensions.

> is that the standard is stuck in time, lacking stuff like database providers, a common FFI or threading. You don't need database providers to be integrated in the language spec. Not in CL and not in many other successful languages. We already have a de facto common, portable FFI: CFFI. We already have more than one library to do threading in a portable way. Also, threading has been left out of the CL standard on pu…

> You don't need database providers to be integrated in the language spec. Not in CL and not in many other successful languages.

Many people underestimate how useful Perl DBI, JDBC, ODBC, Python DB-API, ADO.NET are.

Which is why, in spite of all design flaws, even Go has a database interface defined on their core library.

> Lisp is still pretty much one of the most modern and advanced languages around

I agree with this part, and we are still far from the whole Symbolics experience.

Yet using threading as an example, since it is left for each implementation, it means one cannot guarantee portable semantics across implementations.

Exactly the issue we had with writing threads in C before p_threads came to be, and even as portable library there are semantic issues (e.g. signal handling) until C11 finally defined what threads in C are supposed to look like.

Post reply on HN