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

I still Lisp (2021)

betterprogramming.pub

Post reply on HN
Print view View original

101–110 of 119 posts

Re: I still Lisp (2021)

#101

Post by floren »

aidenn0 wrote: post #100
winrid wrote: post #65

Earlier quoted context omitted.

Reading an 80mb JSON file in Node wouldn't be an issue either, so that's surprising.

Also there's no problem reading an 80MB JSON file in CL. I suspect gp was using cl:load which is for loading source files. SBCL definitely struggles with very large source files; I never bothered debugging that since I don't need 80mb source files.

I was calling read. I suspect the real problem is explained by another commenter, who points out that 80 MB of ASCII text will become 240MB of UTF32 in the hands of SBCL, not to mention all the additional words of memory required for cons cells.

Re: I still Lisp (2021)

#102

Post by packetlost »

kazinator wrote: post #96
packetlost wrote: post #87

Earlier quoted context omitted.

Agreed. Metaprogramming does have it's place in languages like Lisp where it removes boilerplate or hides details that other programmers likely don't need/want to think about. However it's easy to go too far , which is really what I'm talking about. I think as long as you have first-class and variadic functions you can probably live without macros for like 98% of cases without compromising on readability (as is the c…

Python acquires new macros in its parser. For instance, it now has pattern-matching macros which weren't there before. A few years ago it got a f'...' reader macro which wasn't there before.

Sure, but Python doesn't let users write their own macros

Re: I still Lisp (2021)

#103

Post by kazinator »

packetlost wrote: post #102
kazinator wrote: post #96

Earlier quoted context omitted.

Python acquires new macros in its parser. For instance, it now has pattern-matching macros which weren't there before. A few years ago it got a f'...' reader macro which wasn't there before.

Sure, but Python doesn't let users write their own macros

So if you're on an older Python, you can't backport the new syntax; you're forced to upgrade if you have some code which depends on it. In Lisp, if some code we would like to use depends on some newer macros offered by the Lisp dialect we are using, but we cannot move to a newer installation yet, we may be able to backport just the macros into our program.

You're stuck with the ill-designed crap that Python puts out. For instance, I don't agree with pattern matching that assigns to existing variables; from where I'm sitting, it looks like an incompetent clusterfuck. If someone did that in one Lisp program, the entire language would be blamed for allowing that sort of "curse".

Re: I still Lisp (2021)

#104

Post by tmtvl »

aidenn0 wrote: post #99
butterisgood wrote: post #76

Earlier quoted context omitted.

I think it would help the conversation along a bit if those who are against static type checking could articulate exactly how type checking gets in the way of writing correct programs. Isn't making sure the types flowing in and out of your functions match, at some point, something you will eventually need to do anyway? Or are we trying to say the type system doesn't allow for perfectly safe things that should be allo…

Type checkers make it harder to modify code in a way that changes types. While you are discovering the correct way to solve a problem, you may desire to make such changes. Therefore types can make it harder to discover the correct solution.

That is indeed an argument against static typing and in favour of dynamic typing, although the demerits can be mitigated through some extent through a combination of organisation and tooling.

For example, if our customer IDs used to simply be increasing integers but then we decide to change to a UUID variant it would be a pain if I had something like:

  (declaim (ftype (function (integer) (option customer)) get-customer-by-id))
And then had a bunch of functions calling out to that which all require integers and I had to change all the declarations from integer to UUID. However, I could save myself some future headaches by doing something like:

  (deftype customer-id nil 'integer)
And using the customer-id type everywhere. Of course, this is a very trivial example and a real problem would be harder to manage. That said, with optional type checking like SBCL has it is entirely possible to fly by the seat of your pants until things start to take shape.

Not that it matters too much if you go with the tried and true method of tossing out the first two prototypes, but that's another discussion.

Re: I still Lisp (2021)

#105

Post by nathants »

avindroth wrote: post #77
nathants wrote: post #46

for clojure/jvm, there are a lot of good competitors and not an obvious winner. for js/react, there is nothing even close to reagent/shadowcljs. lisp is thriving on frontend, and doing just fine on backend.

+1 to re-frame

the water cycle. more important than ever.

Re: I still Lisp (2021)

#106

Post by askonomm »

jimbokun wrote: post #56
askonomm wrote: post #19

Earlier quoted context omitted.

Yeah, for Emacs users I'm sure Clojure is great. For the other 99% of us who use VS Code or IntelliJ or something else entirely, it really isn't. Though IntelliJ + Cursive I'd say is probably the best, it still pales in comparison to say Rust or TypeScript support in editors.

“The tools for Lisp aren’t very good because I don’t use those tools.”

Are you suggesting that one has to forgo their favourite code editors, and learn what is arguably the most complex editor, in order to use Clojure? That's the kind of attitude that makes all beginners run away.

Re: I still Lisp (2021)

#107

Post by askonomm »

robertfw wrote: post #26
askonomm wrote: post #19

Earlier quoted context omitted.

Yeah, for Emacs users I'm sure Clojure is great. For the other 99% of us who use VS Code or IntelliJ or something else entirely, it really isn't. Though IntelliJ + Cursive I'd say is probably the best, it still pales in comparison to say Rust or TypeScript support in editors.

I've found Calva for VS Code to be excellent, what do you think is missing there?

No parinfer support.

Re: I still Lisp (2021)

#108

Post by Qem »

jimbokun wrote: post #56
askonomm wrote: post #19

Earlier quoted context omitted.

Yeah, for Emacs users I'm sure Clojure is great. For the other 99% of us who use VS Code or IntelliJ or something else entirely, it really isn't. Though IntelliJ + Cursive I'd say is probably the best, it still pales in comparison to say Rust or TypeScript support in editors.

“The tools for Lisp aren’t very good because I don’t use those tools.”

You must agree that if the first step in learning a language is "Learn Emacs first", a lot of potential learners are shooed away before they even start. The language has high ceiling, but high floor as well.

Re: I still Lisp (2021)

#109

Post by ahefner »

erik_seaberg wrote: post #50
bsder wrote: post #25

Earlier quoted context omitted.

Lisp was probably the first widely available language to use garbage collection as well as generate an ecosystem. As such, it damn near was a superpower compared to everything else available at the time in about 1984--think Assembly, C, Pascal, etc. Garbage collection meant that all the effort everybody else spent on memory management could be spent on your problem. And the ecosystem meant that you had actual data st…

Lisp debuted powerful features (GC, lexical scope, closures, destructuring, reflection) back when they were still wildly expensive. Over the decades most of these filtered into everything we use. But I still haven’t seen any rivals for its convenience in providing domain-specific languages via macros.

...and it did take decades.

Re: I still Lisp (2021)

#110

Post by throw009 »

danuker wrote: post #74
throw009 wrote: post #73

Earlier quoted context omitted.

>Here, `_from_source` goes from a plain array of tokens to a nested one (tree), depending on their arity: You're 90% there. Lisp notation obviates the need for arity tracking, which is why in lisp + and sum are the same function: scheme@(guile-user)> (+) $416 = 0 scheme@(guile-user)> (+ 1) $417 = 1 scheme@(guile-user)> (+ 1 2) $418 = 3 scheme@(guile-user)> (+ 1 2 3) $419 = 6 Add higher order functions, e.g. (λ (x) (x…

Well, thank you for your feedback. I don't know why I bothered with the flat list in the first place. I might rewrite this library in Clojure. And I might blog about my findings. Cheers!

Some advice: move to emacs regardless of what editor you use. Evil mode is the best vi clone there is. Use paredit for any lisp like language, you are editing the sexpression tree directly, not it's incidental textual representation. Use the mode for the dialect of your choice. You will never need to exit emacs and will be able to experience the repl as it was it was meant to be.
Post reply on HN