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

41–50 of 101 posts

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

#41

Post by agumonkey »

bjoli wrote: post #25

One thing that makes racket shine is it's macro facilities. Syntax case is nice and all that, but Jesus Christ in a chicken basket I wish scheme would have standardised on syntax-parse. Syntax case vs. syntax parse isn't and will never be close to a fair comparison. Not only is it more powerful, it also provides the users of your macros with proper error messages. It blows both unhygienic and other hygienic macro sys…

Here's the doc for the curious http://docs.racket-lang.org/syntax/stxparse-intro.html

Interesting system indeed

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

#42

Post by farray »

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…

Executing fasls is cool, but they will start from a new empty image, and loading fasls is actually kind of slow, so if you use lots of libraries rather than write a trivial example, that may consume hundreds of milliseconds before the program actually starts. Then again, this supposes you compiled everything into a single .fasl (which ASDF makes easy). But that will be a big fasl for each program; if you want to load from libraries, then there's also the overhead of setting up and using ASDF itself, which can also be in the hundreds of milliseconds. I can imagine many ways to improve the situation, but none are cheap (e.g. implement a background daemon to serve ready executables and/or watch the source registry for modified source; or break compatibility with the entire ASDF setup, angrying the entire community).

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

#44

Post by jackdaniel »

pjmlp wrote: post #39
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…

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 it helps you to download dependencies).

Regarding best libraries: isn't that true for any language? Newbie doesn't know good libraries, because he is a newbie. He has to learn which libraries are good and which are bad.

edit: and by each supported implementation I mean in fact all active complete Common Lisp implementations: ArmedBear, Allegro, clisp, Clozure, Corman, Embeddable, Man-Kai, LispWorks, Steel-Bank and Scieener.

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

#45

Post by baldfat »

mjmein wrote: post #5
sigstoat wrote: post #4

Earlier quoted context omitted.

> When I investigated it, there seemed to be no way to actually connect a repl to a running program. i (poorly) implemented conditions for racket once, including the ability to drop into a repl at the point of error. so i think you could put in place some macros that would let you get at a repl wherever you wanted. probably not the sort of thing to leave in place all the time, though > Unlike with common lisp or cloj…

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 use Visual Studio Code for Racket. https://marketplace.visualstudio.com/items?itemName=karyfoun...

Before that I would use VIM with a tiled window manager that worked really well.

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

#46

Post by baldfat »

zerr wrote: post #22

Anyone using Racket in the wild? (Besides the Racket team)

I use it for a ton of pieces at work. I use R for the most part but for everything else I run Racket. I make reports with Scribble and make it into a scripting language for my file management. I also use it for making Reports and documentation with Scribble. https://plt.eecs.northwestern.edu/pkg-build/doc/scribble/ind...

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

#47

Post by kgwgk »

pjmlp wrote: post #39
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…

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)

Only if portability is a goal. One can stick to one implementation and use the extensions provided. There are also portability isssues when people wants to use different python implementations!

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

#48

Post by [deleted] »

kgwgk wrote: post #47
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)

Only if portability is a goal. One can stick to one implementation and use the extensions provided. There are also portability isssues when people wants to use different python implementations!

[deleted]

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

#49

Post by pjmlp »

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 kind of agree with you, however the beauty of a language standard is being the point of reference for libraries and language semantics.

In any case, the Lisp like languages I use aren't Common Lisp (Clojure, Emacs Lisp, Script-Fu), so that was just an idea.

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

#50

Post by peatmoss »

pera wrote: post #11
sillysaurus3 wrote: post #7

Earlier quoted context omitted.

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

This is what I use. I find it quite comfortable / very easy to get going.
Post reply on HN