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

A Road to Lisp: Which Lisp

scotto.me

Post reply on HN
Print view View original

151–160 of 180 posts

Re: A Road to Lisp: Which Lisp

#151

Post by jasonm23 »

jiehong wrote: post #147
jasonm23 wrote: post #139

Really should include Emacs lisp, as it's a something many in academia happen upon for LaTeX or some other side use. While Emacs Lisp is confined to the editor, it also shows that the Editor is not that, and much has been said of it as an OS, an Application Platform, and so on. Since about 1992, I've used it as platform for many things as well as a general purpose text editor I couldn't initially figure out how to qu…

It does, calling it Elisp

That'll teach me not to scan the article before posting.

again.

Re: A Road to Lisp: Which Lisp

#152

Post by guenthert »

pjmlp wrote: post #78
PaulHoule wrote: post #64

I'm going to take the opposite position that there is much less special about Lisp than people think. Like I have met so many programmers that travel around like itinerant martial artists looking for true functional programming and they never find it. To be specific, you can work all of the examples in Graham's On Lisp in Python except for one of the last chapters where he implements continuations that really need ma…

Except that CPython still misses on (compile .....) part, indeed holding the industry back.

Not sure about that. I rather think it's the very dynamic nature of Python (e.g. at run time one can add members to classes) which limits performance gains achievable by compilation. Iirc PyPy got to some five fold performance gain against CPython.

Common Lisp, as an example, makes some deliberate flexibility (and elegance) vs. performance trade-offs. I'd think to speed Python up more than PyPy could, one would have to sacrifice some of its features (some of those might not be all that popular or even desirable).

Nah, Python has its place. If its performance isn't adequate for the problem at hand, rewrite the bottlenecks in C++ and be done. LLMs should make that easy, no?

Re: A Road to Lisp: Which Lisp

#153

Post by tmtvl »

QuadmasterXLII wrote: post #56

The funny thing about Lisp is that writing a Lisp interpreter is significantly fewer keystrokes than correctly installing Common Lisp and its tooling. The ratio of lisps to lisp programmers may actually be above 1.

Depends on how much tooling you want to install and where you want to be on the spectrum from:

  (loop :do (print (eval (read))))
to implementing all of Common Lisp in RISC-V assembly:

  pacman -Syu sbcl emacs
  M-x package-install slime RET
isn't a lot of keystrokes.

Re: A Road to Lisp: Which Lisp

#154

Post by guenthert »

jwr wrote: post #43
iFire wrote: post #38

Since this is the largest gathering of LISP users I have seen, I have a question. Why prefer lisp-1 over lisp-2 or vice-versa?

As someone who has used both kinds over many, many years: it really doesn't matter.

How about the distinction between the boolean value false, the empty list and whether an empty list ought to be true or false? ]:->

Re: A Road to Lisp: Which Lisp

#155

Post by tmtvl »

xigoi wrote: post #149
tmtvl wrote: post #122

Earlier quoted context omitted.

The usual argument I've seen in favour of Lisp-2 (I personally don't care as much about the function namespace as I do about the type namespace, which I find much more important) is that you can name an argument a conflicting name with a function without the conflict interfering with the code you would write: (defun merge-sort (list before?) (declare (type List list) (type Function before?)) (flet ((merge-2 (a b) (de…

Isn’t this only a problem if the language is case-insensitive?

Okay, let me give a simpler example:

  (defun first-two (list)
    (assert (>= (length list)
                2))
    (list (first list)
          (second list)))
In a language which doesn't normalise the case of symbols you could in theory work around that by capitalising or upper-casing either the function or the variable, but that's still not a particularly elegant solution.

Re: A Road to Lisp: Which Lisp

#156

Post by pjmlp »

guenthert wrote: post #152
pjmlp wrote: post #78

Earlier quoted context omitted.

Except that CPython still misses on (compile .....) part, indeed holding the industry back.

Not sure about that. I rather think it's the very dynamic nature of Python (e.g. at run time one can add members to classes) which limits performance gains achievable by compilation. Iirc PyPy got to some five fold performance gain against CPython. Common Lisp, as an example, makes some deliberate flexibility (and elegance) vs. performance trade-offs. I'd think to speed Python up more than PyPy could, one would have…

The dynamic excuse always misses out fully dynamic languages like Smalltalk, Self, among others have achieved, and how it got further exploited into JavaScript engines.

However CPython isn't even half way there to either Papyrus or GraalPy.

The community attitude to rewrite into C, C++, Rust, Zig, whatever, is exactly why Python will never be like other dynamic languages, and the dynamism excuse will always be used.

Thankfully at least GPU vendors see it otherwise, so if nothing else at least it will get JITs that speak GPU machine code.

Re: A Road to Lisp: Which Lisp

#157

Post by phtrivier »

tmtvl wrote: post #150
phtrivier wrote: post #143

Earlier quoted context omitted.

- a single, canonical, sanctified toolchain for "all the things that are require but don't matter" What's the "cargo xxx" of lisp ? It depends. Maybe it's "quicklisp something". Maybe it's "ASDF something". Maybe it's a mixture of three different things and you ask a dumb question on SO that should be in the first page of the manual, and you get 10k views : https://emacs.stackexchange.com/questions/83200/given-a-bran…

I think OCICL will meet your expectations more readily than Quicklisp. QL does things more the CPAN way (think Gems if you're more into Ruby than Perl). > a baked in way to run some sort of unit test suite. Have dozens of options if you want, but what is the "cargo test"? That actually is ASDF, to be more specific: (asdf:test-system system &rest keys &key force force-not verbose version &allow-other-keys) Although if…

That actually seems great ! My understanding is that it has to wrap ASDF package, so is there a risk of trying to find a well known lib, but not finding it because the authors refuse to create a ocicl package for some complex political reason (or sheer lazyness ?)

Re: A Road to Lisp: Which Lisp

#158

Post by BoingBoomTschak »

guenthert wrote: post #152
pjmlp wrote: post #78

Earlier quoted context omitted.

Except that CPython still misses on (compile .....) part, indeed holding the industry back.

Not sure about that. I rather think it's the very dynamic nature of Python (e.g. at run time one can add members to classes) which limits performance gains achievable by compilation. Iirc PyPy got to some five fold performance gain against CPython. Common Lisp, as an example, makes some deliberate flexibility (and elegance) vs. performance trade-offs. I'd think to speed Python up more than PyPy could, one would have…

> e.g. at run time one can add members to classes

Which is something that can be done in CLOS, though. And in a much more thought out fashion, as usual with the CLOS/MOP, cf https://www.lispworks.com/documentation/HyperSpec/Body/04_cf...

Re: A Road to Lisp: Which Lisp

#159

Post by fuzztester »

adamddev1 wrote: post #55

How to Design Programs with Racket was life changing. https://htdp.org That helped me to think about recursion, functional programming, and type driven development. After going through HTDP I was able to breeze through complex problems that were unsolvable before.

>After going through HTDP I was able to breeze through complex problems that were unsolvable before.

examples?

Re: A Road to Lisp: Which Lisp

#160

Post by spopejoy »

phtrivier wrote: post #143
SomeHacker44 wrote: post #109

Earlier quoted context omitted.

Please say more about the "dev experience of rust." As a long time Lisper and not much of a Ruster, I found the dev experience very painful. Granted, I expect had I continued using Rust that would have abated in tjme. I also disliked Clojure at first until I became comfortable with it and productive, before coming to like and appreciate it.

- a single, canonical, sanctified toolchain for "all the things that are require but don't matter" What's the "cargo xxx" of lisp ? It depends. Maybe it's "quicklisp something". Maybe it's "ASDF something". Maybe it's a mixture of three different things and you ask a dumb question on SO that should be in the first page of the manual, and you get 10k views : https://emacs.stackexchange.com/questions/83200/given-a-bran…

Is cargo really a reason to love rust? I'm not a full-on rustacean but in my limited experience cargo certainly had its flaws and warts like any other build system.

I find it a little puzzling when a language ships the one build system to rule them all. I get that it saves some decision stress but it also is a monoculture. Gradle vs Maven in Java at least puts competitive pressure on each; c/c++ obviously have many options; even Haskell had/has stack vs cabal.

Post reply on HN