[dead]
A road to Lisp: Why Lisp
301–310 of 322 posts
Re: A road to Lisp: Why Lisp
#302[dead]
Re: A road to Lisp: Why Lisp
#303[dead]
Re: A road to Lisp: Why Lisp
#304Earlier quoted context omitted.
> don’t change anything significant about the REPL user’s experience Perhaps you have never tried/heard of nextjournal/clerk, scicloj/clay, djblue/portal, vlaaad/reveal or just simply tried building a simple web scraper with Playwright running on nbb. Oh, and hyperfiddle/electric - something like that would not be very trivial without homoiconicity.
Lol equivalents to all those exist in at least half a dozen non-Lisp languages.
Lol, how are you so smart and figured just everything out, so already? I'd be so bored to ever touch the keyboard again. Bless Turing I'm so stupid and simple and keep trying different things just to see how they differ.
Re: A road to Lisp: Why Lisp
#305Earlier quoted context omitted.
TLDR, but you are (probably) describing somekind of builtin property. I am just saying that the end-user do not need macros for much anything, unless she has some specific optimization in mind. Bloody annoying when they start making cryptic macros to "extend the language".
"Need" is a very tenuous word, because most of any tool stack consists of benefits. End users benefit from things that they don't strictly need . Once you start talking about what people don't need, it's hard to do it in a way such that they need Lisp but don't need macros. Sometimes "need" is about dependencies; i.e. things you "need" are provided by upstreams; you stop needing things that you made yourself. E.g. "I…
I really do not understand this whining and downvoting.
In so-called real life somebody has to live with the malformed macro, whose only purpose is to beautify the code.
I even made un-macrofier, which deleted all macros and replaced instances with macroexpand, because slight adjustement of code resulted mysterious errors cause by nasty macroes.
And lets not talk about Common Lisp loop macro, which was probably scooped up from latrine of hell by the Devil himself.
Re: A road to Lisp: Why Lisp
#306Earlier quoted context omitted.
> I would like to see some articles that have a level-headed criticisms or critique of Lisp, it's ideas and it's place in the ecosystem of languages. Standardized Concurrency is basic table-stakes for a language today. CL does not have a standardized async/await or concurrency model. The standard hasn't been updated since 1995 so it will never happen.
> The standard hasn't been updated since 1995 The latest finalised submission to the Common Lisp Document Repository (confusingly called CDR instead of CLDR) dates from August 4, 2013. CDRs are the equivalent to the SRFIs from the Scheme world. You could argue that they are not THE standard, but they are A standard. And considering the original standardization supposedly cost 400,000 USD (about 900,000 USD in today's…
I see. Wasn't aware of this. However, it does not appear that an official standard for concurrency exists within the Common Lisp Document Repository (CDR). To be honest, CL implementers should just solicit donations for producing a standard.
There are also other basic things needed for adoption - standard APIs for database providers, etc
Re: A road to Lisp: Why Lisp
#307Earlier quoted context omitted.
GUI: MCClim, but it's a bit rusty/Motif like/Tk Life. Deploy: SBCL can build standalone binaries I think.
If SBCL can build stand-alone binaries using MCClim, I know what my next personal project will be.
Get Quicklisp and after that, Ultralisp because the last CLX library it's much faster even on shitty computers las my n270 netbook. Under ECL it almost ran without lag (just a slight one), and with SBCL
it was almost as fast as Tk under TCL.
Re: A road to Lisp: Why Lisp
#308Earlier quoted context omitted.
I'll paraphrase someone who commented on HN once (about dynamic vs static typing, IIRC): permissive languages are enablers for solo programmers, but you need more restrictive languages for team programming. This matches my experience because you don't chose who you work with. Skill level is uneven among the team. Less skilled co-workers will make mistakes that will have more consequences when the language is more per…
> Less skilled co-workers will make mistakes that will have more consequences when the language is more permissive. Even the most skilled engineers are going to make these mistakes sometimes. That's the whole point of more restrictive tooling, and why Rust has exploded. Don't get me wrong. I love Lisp, and use it in some personal projects. But I wouldn't want to use it in must not fail scenarios unless those situatio…
Yes. I'm moving the goal post a bit here, but I was actually thinking about design mistakes and dangerous constructs - the kind of thing you do when you write in a "hacky" way - either deliberately or because you don't know better. Although these are not directly under the scope of type checking, a more restrictive language can have a positive influence.
Re: A road to Lisp: Why Lisp
#309Earlier quoted context omitted.
You've been able to do this in Ruby since I can remember. Not a lot of editors take advantage of it though...
No. There is real, palpable, practical, functional difference between working a Lisp REPL and a REPL in a non-homoiconic languages - Ruby, Python, Haskell, etc. Every single stage there in Read-Eval-Print-Loop differs. Man, it gets so exhausting trying to convince every PL critic who grabs a single (or a couple) of axis of any language and tries to dispute the value of a language without ever understanding the holist…
I wish someone would just write a clear description of that magic version of REPL that isn't a REPL. Maybe also a demo. And how to get the actual pristine source out once you've done development on a running image. Maybe we could be enlightened. The complaining clearly isn't doing it. Articles like this one didn't succeed either. Pointing at Slack surely isn't going to do it.
Re: A road to Lisp: Why Lisp
#310Earlier quoted context omitted.
What has Lisp ever done for us?
"We were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp." - Guy Steele, Java spec co-author "35 years of Lisping at SISCOG" https://www.siscog.pt/en-us/blog/35-years-of-lisping-at-sisc... https://en.wikipedia.org/wiki/Emacs https://help.autodesk.com/view/OARX/2024/ENU/?guid=GUID-A0E9... https://en.wikipedia.org/wiki/Game_Oriented_Ass…
I respect Guy Steele immensely, but his view of Java as being halfway to Lisp is sign that he had jumped the shark by that point, and find it hard to take the rest of his work seriously.