Statistical Analysis with Lisp-Stat
lisp-stat.dev
lisp-stat.dev
Now that we've got super awesome FOSS implementations the party has gotten started and immediately there are so many crazy cool things coming out. I think common lisp is basically a better rust for a lot of the things rust is being used for.. Although of course rust is way better for many things also. It's not really an apples-to-apples comparison but the point is that common lisp is quite fast and good for application development (which rust is too but often with more complexity than necessary).
Another thing to remember is this rule of thumb where 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. Something exists for a week, probably it will be around for another week. Something exists for a decade, probably it will be around for another decade. Of course this is not a very detailed assessment but SICL and CIEL are respectively efforts at minimizing the bootstrap and modernizing the final product. There will be more of these efforts and eventually lisp will become a totally different language (as we approach the energy minimum for the vocabulary)... Essentially what I am trying to say is that right now; lisp code is the code that I have the most confidence in w.r.t. longevity.
Rust still needs to grow up quite a bit before it can assert to be (C++)++ specially in anything that involves a GPU.
AKA Lindy's effect.
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.
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.
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.
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)
(Typed on phone...)
(defmacro itr (&rest rest)
`(iterate:iterate ,@rest))
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))
(defmacro-clause (FOR var = init-value THEN form)
`(progn (with ,var = ,init-value)
(after-each (setf ,var ,form))))
(itr (repeat 8)
(for a = 0 then b)
(for b = 1 then c)
(for c = 1 then (+ a b))
(collect a))
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...
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.
> 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.
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)
(loop for c in '(#\h #\e #\l #\l #\o)
collect c)
Again, though, looks neat and I'm excited to dive more into it.
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.
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.
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.
And yet C likes get praise with their {[(;*&^| stuff...
Lisp-Stat is maybe not as full-featured as its analogues in the python ecosystem, but it's still quite good. I recently developed an algorithmic trading bot in Common Lisp using statistical arbitrage methods and I used lisp-stat quite a bit in the development process, and while I enjoyed vega-lite (the plotting library that lisp-stat uses) I will say that I despite JSON as a format and found exporting to gnuplot scripts more flexible and useful.
It is nice to have a common lisp version to use in statistical area, for those who does not hinder by it.
Here they advertise jupyter notebooks.
Does that give that lisp repl experience I’ve heard so much about or is it just like my familiar r and Python repl experience?
In this regards, the notebook approach is very different. I am still learning from this site about this under common lisp. Based on python notebook (and R), I think it helps after you build your system you can use this to help others to understand what you have build.
Jupiter notebooks are the poor man's experience of what using a Symbolics or Interlisp-D workstation used to be like.
Still I think it is lovely they restart this path. Love Common Lisp.