I have really fallen in love with LISP recently, specifically clojure. A strong type system is really needed for it to make me feel like I can confidently develop with it.
Are those compile-time type checks or runtime assertions?
rjsw · 7h ago
Your eli looks clunky to me.
codr7 · 6h ago
Well, use something else.
And maybe ask yourself why you felt saying so was important to you.
dokyun · 6h ago
(the number (+ 35 7))
is a lot less clunky than
(+ 35 7)@Numeric
codr7 · 6h ago
That's your opinion, I don't agree.
And the other reason is I can use the same syntax wherever I want type checking.
epgui · 2h ago
Opinions aside, it is objectively an increase in syntactical complexity, and many people who love lisp enjoy its relative syntactical simplicity.
Whatever is gained in exchange for this additional syntactical complexity may not be valued in the same way by everyone.
So that almost certainly explains that reaction.
HexDecOctBin · 5h ago
One problem with Lisp is everything, including variable bindings, increases the nesting level making the code illegible. Last thing you want is for the type declaration to have their own nesting.
Aside from the points that others have raised already, this sort of deep nesting can be seen as a feature instead of as a bug, since it can force you to think about refactoring the code into being less nested.
epgui · 2h ago
The nesting level doesn’t necessarily impair legibility, it depends how it’s done. Nesting levels in homoiconic & referentially transparent languages have an impact more comparable to nesting levels in yaml or json than nesting levels in a language like python or javascript. The tradeoff weighs in a completely different way.
First you will usually want to write small chunks of code, instead of a large soup.
Second, you can make intentional decisions with your use of newlines in order to highlight specific aspects of the code.
I find clojure more readable than most other languages… However, bad code stands out horribly (which is actually great if you have at least one experienced engineer in the team- I’d argue there’s nothing worse than bad code that looks normal). Just like anything else, writing good lisp takes some skill.
Your specific editor and its configuration will also have a big impact on your experience.
dokyun · 2h ago
If you hate nesting, just do this
(defun foo (&aux bar baz)
(setq bar (quux)
baz (xyzzy))
...)
zarathustreal · 4h ago
This is not necessarily true, you can pretty easily implement just about any syntax you want
gitroom · 5h ago
honestly i kinda love when deep dives like this pop up, makes me rethink stuff i thought i'd settled on - you think things ever get simple with lisp or it always stays quirky no matter how you do it
NikkiA · 7h ago
praising 'loop' in the same post as describing lisp as 'elegant' shakes head
codr7 · 7h ago
Some people seem to like it, and be very effective using it.
The problem is it's a walled garden, with its own quirky syntax; nothing that happens inside of loop is applicable outside, and the other way around.
kagevf · 6h ago
My opinion of LOOP started to change when I read (the much maligned) "Land of Lisp" and went over that "periodic" diagram in TFA. Seeing the elements of LOOP broken down like that went a long way to get me to overcome my original aversion to it.
Huh, didn't realize that beach didn't like it so strongly. Still, hardly "much maligned"... My impression was that most people enjoyed it, even though it definitely has some weaknesses and could (especially now 15 years later) use a second edition, if for no other reason than to move off CLISP to SBCL. This seems supported by its high reviews on Amazon and GoodReads. (Of course overall I liked it too, and we got the best music video about lisp out of it.) FWIW my own criticisms were largely style-based: too much of it felt like Scheme code rather than Lisp code, even outside of emphasizing/educating about the more primitive features, with lots of things like inner functions, recursion where looping would have IMO been clearer, and so much use of raw car/cdr/caadr/caddr/whatdr instead of more clearly structured structs or classes or just helper functions called intuitive things like get-foo. (The book Calendrical Calculations: The Ultimate Edition uses lists for all its data structures but helpfully creates many functions to both construct and access their parts. e.g. generic dates are a (year month day) list, but the definition and exclusive use of standard-year, standard-month, and standard-day for getting at them would let one refactor it into a class. There are also functions like gregorian-date, julian-date, and egyptian-date that have exactly the same implementation (making a list of the 3 passed params) but serve as 'typed' list constructors, and indeed could be refactored into something that carried along type information without changing other code.)
kagevf · 23m ago
I like LoL alright too. I was only maybe a year or so into CL when I read it, so I didn't really notice a lot of what it's criticized for. On the one hand, I'm a little sad that I see it bagged on so much (that link from beach's site, IRC, reddit) since I felt I got decent enough value out of it, but OTOH it's good and healthy to point out problems.
The abstractions used in Calendrical Calculations sound good - and echo what I've seen elsewhere - so, based on your comment I'm now more likely to read it, so thank you for that.
shawn_w · 6h ago
I feel bad for people who haven't discovered ITERATE yet.
Jach · 2h ago
I'll never understand the love for iterate. Look at these comparisons: https://github.com/sabracrolleton/sabracrolleton.github.io/b... For almost all of them, it's the same guy, just more parens. Nothing to love/hate for one or the other, it's just preference, though one is built-in.
Jtsummers · 6h ago
ITERATE still breaks when you use `count` inside it, the built-in CL function. If they ever address that problem I'll get back to use it but having a time bomb in my programs isn't something I like.
Trivial example of breakage:
(iter (for i from 1 to 10)
(print (count i some-sequence)))
shawn_w · 5h ago
Breaks how? I'm on my phone, not a computer right now and can't test, but that should call the CL function - ITERATE uses `counting` for that particular operation to avoid conflicts; see https://iterate.common-lisp.dev/doc/Gathering-Clauses.html
Or is the documentation wrong?
Jtsummers · 5h ago
Apparently this is a quicklisp problem, they haven't updated the release since 2021 when it was still broken.
shawn_w · 4h ago
I just grabbed the latest ITERATE source off of its gitlab repository, and, yeah, that bit is still giving an error:
Iterate, in (COUNT I SOME-SEQUENCE): Missing value for SOME-SEQUENCE keyword
as well as
WARNING:
COUNT appears to be used as an ITERATE clause keyword, in this sexpression: (COUNT I SOME-SEQUENCE).
This use is now deprecated and will cease to be supported in a future version. Please use the alternative keyword COUNTING instead. If you intended COUNT to be interpreted as a function call, instead of an ITERATE clause, you must find an alternative way of calling it, at present, perhaps by using FUNCALL or APPLY.
Have to use
(iter (for i from 1 to 10)
(print (funcall #'count i some-sequence)))
Guess the documentation /is/ wrong (for now, until the code finishes catching up)
Jtsummers · 4h ago
Well, some-sequence was obviously an example, you'd have to fill it in with an actual sequence. Put in '(1 2 3) instead or assign something to it.
But yeah, that's still not something I intend to use if they make you work around what should be plain Common Lisp.
shawn_w · 3h ago
I had a some-sequence variable defined.
(Using a literal list or vector gives a different error)
I made an attempt to fix that for eli: https://github.com/codr7/eli#type-checking
And maybe ask yourself why you felt saying so was important to you.
Whatever is gained in exchange for this additional syntactical complexity may not be valued in the same way by everyone.
So that almost certainly explains that reaction.
It's like Unix pipes for functions:
First you will usually want to write small chunks of code, instead of a large soup.
Second, you can make intentional decisions with your use of newlines in order to highlight specific aspects of the code.
I find clojure more readable than most other languages… However, bad code stands out horribly (which is actually great if you have at least one experienced engineer in the team- I’d argue there’s nothing worse than bad code that looks normal). Just like anything else, writing good lisp takes some skill.
Your specific editor and its configuration will also have a big impact on your experience.
The problem is it's a walled garden, with its own quirky syntax; nothing that happens inside of loop is applicable outside, and the other way around.
The abstractions used in Calendrical Calculations sound good - and echo what I've seen elsewhere - so, based on your comment I'm now more likely to read it, so thank you for that.
Trivial example of breakage:
Or is the documentation wrong?
But yeah, that's still not something I intend to use if they make you work around what should be plain Common Lisp.
(Using a literal list or vector gives a different error)