Hacker News Reader

SBCL was adopted in production in Lisp shops like ITA circa 2005 or so? So even if you consider production-grade, open source Common Lisp only, it's still older than Go or Rust. Common Lisp is not "super new" by any means, but it is still exciting. It's like the redwoods of California: ancient, but evergreen.

And SBCL is fork of long mainstay of open source Common Lisp, CMUCL (pretty sure ITA moved from CMUCL to SBCL)

I don't have exact dates, but I definitely used cmucl on linux/x86 before 2000 (though not much before; 1999 maybe?).

IMO Common Lisp is extremely unlike Rust, which is basically (C++)++, and I would not use them for the same things

CL is quite unlike Rust, but I've actually found lots of similarities between CL and C++: religiously stressing backwards compatibility and the ability to run very old software, providing the ability to hook and customize as many things as possible while providing default implementations, being unopiniated with regards to programming paradigms...

Symbolics and Xerox PARC beg to differ, and their products failed to establish themselves more due to their mismanagement than technical.

Rust still needs to grow up quite a bit before it can assert to be (C++)++ specially in anything that involves a GPU.

> I think common lisp is basically a better rust for a lot of the things rust is being used for..

More like a superior python with an awkward syntax and some crazy legacy (loop macro being the worst offender perhaps).

Just the other day, my ipython interpreter killed itself after having an uptime of 8 hours. No reason, just got tired of living. In such occasions, I hope I would've spent more time assimilating my brain to some common lisp craziness so I wouldn't have to deal with shit like that.

LOOP gets weird flack from some purist mindset. There's no issue with it in practice.

Yeah, the other, possibly worse, problem is that experienced common lisp programmers think that LOOP is ok ;)

purist? no, it's a very practical mindset. if you are into lisp, you should already appreciate the power of parenthesis. i literally have to spend time parsing the barren (longish) loop macros to understand wth is going on and what keyword is suppossed to stick to where. in other, totally unrelated news, forget about customizability and embrace the ever-crappy indentation (especially with aggressive-indent) and the awful non-sexp-based editing. what looks like purism is in fact guided by simple pain avoidance.

no, fren, iterate all the way. it is regular common lisp code and doesn't make you context switch due to some _obviously_ misguided DSL design.

i don't understand why some lispers are so adamantly supportive of LOOP. what's more, some of them _despise_ iterate (because reasons). i just don't get it.

PS As a bonus, iterate has an actually usable manual [1]. For LOOP, i have to go to gigamonkeys and whatnot.

[1] https://iterate.common-lisp.dev/doc/index.html#Top

To each their own. I'm a huge fan of LOOP. Is very easy to read, feeling much more natural to how I think about those sections of code.

Yes, I was a fan of LOOP too, until I found iterate.

I mean, we are discussing the two things comparatively here, aren't we? So, how is loop better than iterate? Iterate has nearly the same semanitcs as LOOP. It's basically LOOP on s-exprs, with some handy idioms sprinkled in. But often times the match is 1-1. So, how is the absence of sexprs making anything easiers to read or write? It makes it harder for me in both cases.

I'll try iterate. For me it is just that loop is already very easy to read. Moving all things to s exprs doesn't seem like it would be that big of a deal.

And I should say that the construct that I find easiest is the "then" clause.

    (Loop repeat 8
          For a = 0 then b
          For b = 1 then c
          For c = 1 then (+ a b)
          Collect a)

That just reads very easily to me.

(Typed on phone...)

First of all, if you are going to try it out, I recommend using this macro:

   (defmacro itr (&rest rest)
     `(iterate:iterate ,@rest))

because it keeps all the clauses on the same indentation level.

Now, to the translation: iterate has previous clause. https://iterate.common-lisp.dev/doc/Previous-Values-of-Drive... which may help translate the loop form you provided into this:

   (itr (repeat 8)
        (for a previous b initially 0)
        (for b previous c initially 1)
        (for c = (+ a b))
        (collect a))

However, if you wanted that exact syntax, you could try:

   (defmacro-clause (FOR var = init-value THEN form)
     `(progn (with ,var = ,init-value)
             (after-each (setf ,var ,form))))

to get a direct translation:

   (itr (repeat 8)
        (for a = 0 then b)
        (for b = 1 then c)
        (for c = 1 then (+ a b))
        (collect a))

> Moving all things to s exprs doesn't seem like it would be that big of a deal.

One of the biggest things you will "miss" from LOOP is the do keyword. The control structures is just regular lisp code. Also, I found generators to be pretty handy (not often, but I am glad I had them when it was called for).

I mean, it's not exactly groundbreaking, but it does make a difference especially that a looping construct is probably the heaviest-used macro. You can certainly get away with LOOP, but I see iterate as more or less how LOOP should've been done.

I also recommend reading this short discussion in the manual https://iterate.common-lisp.dev/doc/Don_0027t-Loop-Iterate.h...

Previous doesn't have the same flow, so does feel more cumbersome than I'd like. (That is, I specifically like the left to right flow of "this then that" for variables.)

I do have a softspot for how this is embracing the parens. :D

This is funny in that it seems to dodge the biggest complaint of loop, that it has different syntax for lists and vectors/hashtables.

It has in-sequence, however it uses elt I think. For efficiency reasons, there's a separation. Otherwise how should it work? In any case, you could probably write a macro that does the right thing based on type.

> Previous doesn't have the same flow,

I have provided a clause macro that uses the exact syntax you showed, you don't have to use previous.

Apologies, I was agreeing with your macro on why I like "then" over "previous". I did not intend mine as a correction or challenge.

My point on "in-sequence" and such was more that the main complaint I ever hear regarding LOOP is that:

    (loop for c across "hello"
          collect c)

is not the same as

    (loop for c in '(#\h #\e #\l #\l #\o)
          collect c)

Specifically, "in" versus "across" seems to upset a lot of folks. I don't recall ever hearing too many complaints about the syntax not being more nested.

Again, though, looks neat and I'm excited to dive more into it.

Okay, gotcha.

Yeah, I can see how having distinct keywords may be seen as inconvenient. I think if there were a general container-keyword that wouldn't introduce any cost based on a type declaration, that would be cool, but it's not something I have encountered a real need for.

LOOP is better than ITERATE because I don't have to load a library to use it, and I don't have to tell my colleagues learning Lisp to "please ignore the built in iteration construct and instead use the one that has more parentheses from this library."

Also note that LOOP is an S-expression. Just because there are more sub-lists doesn't make it more or less of an S-expression.

> Also note that LOOP is an S-expression.

Well, it's body doesn't look like s-expressions to me, that's the point. And there's 0 reasons why they shouldn't be. But, conversely, there are real benefits to them being sexps. Coherency, for one.

It's not the first time I hear this defense: "it's part of CL standard therefore it's lispy", "it's just a DSL". But these are qualities, aren't they? Some things will look lispier that other things. Some DSLs are better designed.

Look at the DO keyword. Why exactly do I need it? Why do I need :when or :if when I have cl:when and cl:if?

> don't have to load a library to use it, and I don't have to tell my colleagues

That's a valid point, this is the price you would have to pay (and don't forget importing the symbols!). But you just might have to gain more in the long term, if you switch. I for one, don't mind, but It Depends TM.

If I had a large project nearing its completion that uses LOOP, i wouldn't switch to iterate, sure. But on a new project? I might as well convince everybody else just to try it out for the hell of it.

Why does this crazy macro exist for one part of the language but not others? It feels obviously out of place and gives you the feeling that you're using a legacy language with historical oddities rather than a coherently designed system.

Me thinks you just haven't looked at more parts. FORMAT, in particular, is just as dense.

Is there an alternative to FORMAT?

I mean. Not really, though I have seen folks make a herculean effort with print and friends.

> an awkward syntax

And yet C likes get praise with their {[(;*&^| stuff...

- "if you want to make a neutral prior for how long a technology will be around you should basically just look at how long it has already existed"

AKA Lindy's effect.

https://en.wikipedia.org/wiki/Lindy_effect

Static for 25+ years, but "super new"?? Of implementations, CMUCL even predates Common Lisp, but I don't know when it implemented CL. GNU Common Lisp was available GPL'd around the time of the standard and, I think Clisp.

While FOSS implementations are great, their tooling is still missing the whole stack experience as offered by Allegro and Lispworks.