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

81–90 of 101 posts

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

#81

Post by junke »

KirinDave wrote: post #79
junke wrote: post #77

Earlier quoted context omitted.

Looking at Python: https://wiki.python.org/moin/PythonImplementations There is a reference implementation, no standard, and a bunch of implementations and/or extensions. Is it really better? What guarantees do you have? If you need to provide an extension, you have to discuss about extensions and push patches to CPython, just like you could push patches to SBCL or ABCL. But at least (which I do not consider "undeniab…

You can't use compiler-macros to build cross-platform higher order abstractions, so I don't get why they come up. They're exactly as useful as any indirection facility. So why are they relevant here? Not that I like Python, mind you. I miss CL, but I wouldn't go back to it. My experience is that way too many of these beloved libraries have an audience of 1 or 2, sometimes a single company. If I'm going to engage with…

Not sure what you count as higher order abstractions, but lparallel, fset, cl-ppcre and other libraries make use of compiler macros; this is relevant w.r.t. efficiency.

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

#82

Post by flavio81 »

moomin wrote: post #59
jackdaniel wrote: post #44

Earlier quoted context omitted.

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.

> but has huge gaps by the standards of modern language

Please detail, because i'm sure that the Lisp community would love to fill those gaps. After all, Lisp is addictive to the point of resembling a hard drug.

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

#83

Post by KirinDave »

flavio81 wrote: post #80
KirinDave wrote: post #74

Earlier quoted context omitted.

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

> though. CLs are inconsistent on how they can distribute base images and executables There is only one Common Lisp, the 1994 ANSI Standard. There are many implementations and they give you diverse options of delivering. For example if you want good options to package an executable, I think LispWorks has lots of options for specifically this need.

You know exactly what I meant, flavio81. Obviously.

> For example if you want good options to package an executable, I think LispWorks has lots of features.

It had 2 alternatives. I know, because I shipped some stuff to prod for Powerset on LW back in like 2009? We ultimately stopped using it precisely because we shipped less bytes more quickly with Java and Ruby.

> As for Java, to execute a Java class you need a JRE (java runtime environment), which is not small at all, so I am not sure if it gives you a big advantage.

I'm surprised to hear you say this, but in the interests of completeness I'll give you a handy way to compute the difference in bytes saved.

    (defun bytes-saved (num-deploys stdenv-size)
      (* (-1 num-deploys) stdenv-size))
A similar trivial function could help you see the amount of time saved by not compiling on site, should you respond to just ship and produce images onsite.

This requirement is even more important in the world of diverse deployment techniques that expect modularized executables as a space and performance optimization. Docker, Nim, deployments around FreeBSD jails, and even package managers have dramatically improved performance if you can offer that kind of segmentation.

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

#84

Post by junke »

KirinDave wrote: post #74
flavio81 wrote: post #58

Earlier quoted context omitted.

> 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, comp…

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

You did install a JVM to run Java, didn't you? If you want to develop in Java, you need a JDK. According to this page, it amounts to 132MB:

http://www.oracle.com/technetwork/java/javase/windows-disksp...

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

#85

Post by KirinDave »

junke wrote: post #84
KirinDave wrote: post #74

Earlier quoted context omitted.

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

You did install a JVM to run Java, didn't you? If you want to develop in Java, you need a JDK. According to this page, it amounts to 132MB: http://www.oracle.com/technetwork/java/javase/windows-disksp...

Please see: https://news.ycombinator.com/item?id=15082806

ONE installation is inevitable. It's that very few CL-offering environments give you anything better than an image.

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

#86

Post by KirinDave »

junke wrote: post #81
KirinDave wrote: post #79

Earlier quoted context omitted.

You can't use compiler-macros to build cross-platform higher order abstractions, so I don't get why they come up. They're exactly as useful as any indirection facility. So why are they relevant here? Not that I like Python, mind you. I miss CL, but I wouldn't go back to it. My experience is that way too many of these beloved libraries have an audience of 1 or 2, sometimes a single company. If I'm going to engage with…

Not sure what you count as higher order abstractions, but lparallel, fset, cl-ppcre and other libraries make use of compiler macros; this is relevant w.r.t. efficiency.

Haxl is modern. Ponylang's concurrency is modern. Rust's concurrency is modern.

lparallel and fset's affordances are not. I'm not sure why a single threaded regular expression compiler is mentioned here.

I'd have to check. Is fset even using the current standard (not the newest stuff) for immutable-friendly data structures? Last time I checked they had used a lot of older stuff from Okasaki's work and much of that has been improved upon substantially now.

Even Clojure is out of date, compared to this year's innovations!

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

#87

Post by flavio81 »

systems wrote: post #76
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…

one of the perceived (by outsiders) CL drawbacks, is the eco system if CL have a lot of libraries, it is not because CL have a large or active community, it is more because it existed for a long time so, what is honestly the reality of CL ecosystem, is quicklisp a solid part of this ecosystem, is it easy to find and install packaged compared to perl and python for example? do you think racket have a more reliable eco…

> is quicklisp a solid part of this ecosystem,

Yes, it is very popular. You can also, without Quicklisp, download manually the project and let ASDF do the rest of steps.

> is it easy to find and install packaged compared to perl and python for example?

There is this CL environment, Portacle (The Portable CL Environment) which you just download and immediately gives you (no more steps needed):

   - SBCL lisp implementation/compiler
   - Quicklisp
   - SLIME environment
   - Customized EMACS
   - and other nice tools.
In any case, Quicklisp is easy to install as long as you have a modern ASDF version.

Quicklisp is really easy to use, as easy as, say, PIP for Python.

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

#88

Post by moomin »

flavio81 wrote: post #82
moomin wrote: post #59

Earlier quoted context omitted.

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.

> but has huge gaps by the standards of modern language Please detail, because i'm sure that the Lisp community would love to fill those gaps. After all, Lisp is addictive to the point of resembling a hard drug.

Well, start with the stuff that OP's just been arguing doesn't need a standard implementation. :)

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

#89

Post by mikelevins »

maxiepoo wrote: post #65
mjmein wrote: post #3

Racket is a really exciting language, especially with its focus on building small languages to solve problems. However, where it fails for me is in its lack of interactive development. When I investigated it, there seemed to be no way to actually connect a repl to a running program. Unlike with common lisp or clojure, with racket if you make changes to your code you have to restart the REPL, which destroys your state…

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 that support me in building things by modifying programs as they run. I'm just happier and more productive that way.

So one of my axes of optimization is selecting projects that enable me to work that way.

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

#90

Post by mjmein »

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…

My thoughts exactly. Once you are used to this way of developing, it is really difficult to be happy with less.
Post reply on HN