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

91–100 of 101 posts

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

#91

Post by ebzzry »

sillysaurus3 wrote: post #7
mjmein wrote: 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

Geiser is fine. However, we can’t compare it with SLIME. The integration of the latter is much better.

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

#92

Post by jackdaniel »

KirinDave wrote: post #72
jackdaniel wrote: post #36

Earlier quoted context omitted.

I think it is a pretty shallow view at standard. CL implementations grow and have agreed interfaces (or portability layers). A few examples: - sockets via usocket - threading via bordeaux-threads - metaobject protocol via closer-mop - foreign function interface via cffi all these are not mentioned in the standard at all, but are implemented and used in production environment. Having base standard and extensions which…

> Having base standard and extensions which may be used portably (via portability layers) is better situation than having no standard (for instance python or ruby) and a reference implementation. Is it though? I agree CL has (after slightly over 2 decades) worked out a standardization path for some core features that you simply cannot live without (e.g., usocket). But all these variants are noticeably dated abstracti…

Good example of what you're talking about is lparallel library (check out lparallel.org) - it is modern concurrency library build on top bordeaux-threads. lfarm is example of another library workinng on top of usocket which does the same for distributed computing.

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

#93

Post by jlarocco »

criddell wrote: post #52
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.

At work I mainly write C++, but I have a little library in CL that I've been working on for a while that can call our REST API, access and filter our log files, connect to our test infrastructure, and some other miscellaneous stuff. It started because I wanted to call our product's REST API from inside Emacs (in the Slime REPL) to make debugging and testing easier, but over time it's grown to about 1500 lines of CL to automate common tasks.

Outside of work it's my go-to language for learning new stuff. I use it for a bunch of little programming projects that I put on Github (https://github.com/jl2?tab=repositories). They're mostly just playing around with whatever topic I'm interested in at a given time. Lots of animations and (simple) computer graphics, some simple games, one or two libraries for the Raspberry Pi, etc. Nothing too exciting.

I want to start contributing to some of the open source libraries and projects (like stumpwm and sbcl) that I use a lot, but so far the few commits I've made to other projects have been really small bug fixes or trivial documentation fixes.

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

#94

Post by CaptObvious2 »

aerique wrote: post #31
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.

You are correct, but why is this a problem in the case mentioned by the author? $ cat > hello-world.lisp (defun main () (format t "Hello, World!~%")) $ sbcl * (load "hello-world.lisp") T * (save-lisp-and-die "hello-world" :toplevel #'main :executable t) [undoing binding stack and other enclosing state... done] [defragmenting immobile space... 1110+19908+28500+22601 objects... done] [saving current Lisp image into hel…

It's still too big, too slow [compared to gerbil] and uses a lot more memory. Gambit GC is amazingly fast, and never tenures garbage to a gen where it will collect like SBCL tends to do on many workloads. [acl/ccl/lw do not have this issue, although they are slower than sbcl]

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

#95

Post by ebzzry »

juki wrote: post #33
lottin wrote: post #32

Earlier quoted context omitted.

It's not necessarily a problem, but personally for small utilities I much prefer something that supports #!-style scripts, like Guile or Racket, or that can be compiled into small, efficient executables. Let's say it's a matter of personal preference.

You can use CL for #!-scripts too. SBCL has a `--script` option for running scripts. You'll probably want to create a core with whatever libraries you need for scrips, so that the start-up time will be fast. The core will be big, but it can be shared for all scripts, so that's not much of a problem.

I wrote a short introduction to a more portable Common Lisp scripting system—made by Fare, himself—at https://ebzzry.io/en/script-lisp/

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

#96

Post by kazinator »

lottin wrote: post #32
aerique wrote: post #31

Earlier quoted context omitted.

You are correct, but why is this a problem in the case mentioned by the author? $ cat > hello-world.lisp (defun main () (format t "Hello, World!~%")) $ sbcl * (load "hello-world.lisp") T * (save-lisp-and-die "hello-world" :toplevel #'main :executable t) [undoing binding stack and other enclosing state... done] [defragmenting immobile space... 1110+19908+28500+22601 objects... done] [saving current Lisp image into hel…

It's not necessarily a problem, but personally for small utilities I much prefer something that supports #!-style scripts, like Guile or Racket, or that can be compiled into small, efficient executables. Let's say it's a matter of personal preference.

If you do scripting and like Lisp, you definitely should take a look at TXR.

I wrote TXR to basically be the "acceptable {awk, perl, ruby, Python, ...}" for Lisp-minded people. Well, for me, that is; but anyone else too.

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

#97

Post by kazinator »

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.

Small with CLISP. 15 years ago I developed a version control system/layer called Meta-CVS using CLISP. It compiled a custom CLISP linking set to adds some C functions, and then dropped an image (custom lispinit.mem) launched via a #! mechanism which invoked the custom CLISP executable with code linked in, and the memory image via the -M lispinit.mem option. It was small and fast enough for 2002.

I have experience deploying with Clozure on Windows. The raw memory images are large-ish, but they compress extremely well into the installer (such as NSIS). I think there is a lot of wasted space in there. Lisp images are not unlike Unix core dumps in may respects. It's similar to checkpointing a process to disk. There is a time versus speed tradeoff there; if you compress it, then you can't just map it into memory as-is.

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

#98

Post by ClFromEmacs »

jlarocco wrote: post #93
criddell wrote: post #52

Earlier quoted context omitted.

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

At work I mainly write C++, but I have a little library in CL that I've been working on for a while that can call our REST API, access and filter our log files, connect to our test infrastructure, and some other miscellaneous stuff. It started because I wanted to call our product's REST API from inside Emacs (in the Slime REPL) to make debugging and testing easier, but over time it's grown to about 1500 lines of CL t…

Do you run items in CL that return to an emacs buffer? Like say, slime-eval/run? Or are these just run in the repl itself and displayed there? Been toying with making some async stuff run via swank/slime and then display in emacs in a custom mode and buffer.

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

#99

Post by maxiepoo »

mikelevins wrote: post #89
maxiepoo wrote: post #65

Earlier quoted context omitted.

I believe this is a design decision, because relying on some enormous implicit repl state and updating the code in place is a good way to get yourself into states that are impossible to reach in an actual running program. Racket is a functional language and it is their belief that you should just make predictable ways to startup your interactive development than rely on the entire state of some repl image.

You're right; it's a conscious decision. I had a little discussion with Eli Barzilay and Matthew Flatt about some related matters a little while back. It was a nice discussion, but image-based or live programming is just not something they found particularly compelling. It pretty much keeps me from using Racket, and a bunch of other things that are otherwise very nice. Given a choice, I will always choose the tools t…

Ah yes, I remember seeing an interaction that was probably yours, tried to find it for my comment, but never did.

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

#100

Post by elibarzilay »

maxiepoo wrote: post #99
mikelevins wrote: post #89

Earlier quoted context omitted.

You're right; it's a conscious decision. I had a little discussion with Eli Barzilay and Matthew Flatt about some related matters a little while back. It was a nice discussion, but image-based or live programming is just not something they found particularly compelling. It pretty much keeps me from using Racket, and a bunch of other things that are otherwise very nice. Given a choice, I will always choose the tools t…

Ah yes, I remember seeing an interaction that was probably yours, tried to find it for my comment, but never did.

I don't know what this refers to, but it doesn't ring a bell. The most I might have said is that the community in general is not too interested; but personally, this kind of dynamic interaction is something that I very much appreciate. In fact, when I implemented xrepl (which is now the default when you start racket) being able to modify code inside modules was one of the main goals. The only reason I didn't do something like that for Emacs is that my own use of CL/Scheme variants in Emacs was always very simple, but I actively encouraged people to do something similar for Emacs -- and Geiser/Racket-mode are two serious Emacs packages that actually do that kind of interactive use.
Post reply on HN