I recently started looking at https://github.com/elle-lisp/elle . It's made with AI but has an interesting feature set.
[dead]
A Road to Lisp: Which Lisp
161–170 of 180 posts
Re: A Road to Lisp: Which Lisp
#162How to Design Programs with Racket was life changing. https://htdp.org That helped me to think about recursion, functional programming, and type driven development. After going through HTDP I was able to breeze through complex problems that were unsolvable before.
>After going through HTDP I was able to breeze through complex problems that were unsolvable before. examples?
Natural language phrase generation in a very complex foreign language that follows recursive syntax trees. And making a GUI to handle and edit these syntax trees visually.
Re: A Road to Lisp: Which Lisp
#163Earlier quoted context omitted.
There's nothing "special" about Lisp and Lisp dialects, yes. Similar features can be or already have been implemented in other languages. Yet, after touching, using and experiencing working with a bunch of different stacks, I cannot simply ignore the enormous pragmatic level of Lisps. Working with Clojure is an absolute delight. It strips down all the dogma and let's you deal with the "business logic" as if you're co…
I've got really mixed feelings about Clojure. Like when I read Graham's book I went through a phase of "he wouldn't be fighting with nconc if he was using Clojure!" I find some algorithms to be easy and fun to write using persistent data structures and others maddening though if I did it more I'd get better at it. zippers are weirdly unergonomic because of some little bad choices. I badly wanted to do a project with…
I'm a longtime emacs head and partisan ... but I learned vi to compose emails in the Berkeley computer lab in 1989 and somehow have never forgotten vi key commands ever since. Emacs is my preferred sw dev editor for most things but I feel like not knowing vi is almost professional negligence if you are on the terminal.
Re: A Road to Lisp: Which Lisp
#164Earlier quoted context omitted.
>After going through HTDP I was able to breeze through complex problems that were unsolvable before. examples?
Natural language phrase generation in a very complex foreign language that follows recursive syntax trees. And making a GUI to handle and edit these syntax trees visually.
thanks.
Re: A Road to Lisp: Which Lisp
#165I'm going to take the opposite position that there is much less special about Lisp than people think. Like I have met so many programmers that travel around like itinerant martial artists looking for true functional programming and they never find it. To be specific, you can work all of the examples in Graham's On Lisp in Python except for one of the last chapters where he implements continuations that really need ma…
I might buy this if those languages were actually faster. Instead, implementations of scheme with no commercial backers run circles around scripting languages with huge budgets.
Common Lisp can match and exceed languages like Java without the backing of a megacorp.
Carp Lisp is basically identical to C in performance and old PS games were shipped in a proprietary dialect (GOAL) and had very good performance.
Lisp has proven itself capable great performance at every abstraction level.
Re: A Road to Lisp: Which Lisp
#166Earlier quoted context omitted.
Natural language phrase generation in a very complex foreign language that follows recursive syntax trees. And making a GUI to handle and edit these syntax trees visually.
thanks.
The book takes you through simpler examples, but I found that the exercises did an excellent job of drilling a kind of recursive problem solving skill into your head. You represent the data in types, and then keep breaking the problem down into smaller functions until it is solved. It's almost magic. After being armed with this way of thinking (through lots of practice with the many exercises) I found that problems I didn't know where to begin with just melted away.
Re: A Road to Lisp: Which Lisp
#167I just wish a good IDE existed so I don't have to use Emacs. That's what made me drop lisp in the past. I would be happy with (neo)Vim setup as well, but that was way behind Emacs and broken when I tried.
> so I don't have to use Emacs
While there are many reasons to perhaps stay away from Emacs, realistically, for any serious Lisper, there's just no other alternative - sadly or otherwise.
I think, collectively, as the industry force, we software developers having now to pay imperceptible price for disregarding the pragmaticism we had/have in systems like Lisp and Smalltalk. We standardized on dead artifacts: text files compiled into opaque binaries, restarted on every change. We rebuilt weaker versions of what those systems had, piecemeal, decades later, and call them innovations.
You don't notice the cost because it's spread out. Nobody ever gets handed the bill. Instead it shows up as little bits of friction across millions of hours of work: slow feedback, extra steps, tools that treat a running program like you can't touch it. We took the accidental limits of file-based, restart-everything development and assumed that's just how programming works. And quietly, all together, we paid a huge price for giving up the live, flexible systems we already had.
Emacs is one of the last mainstream artifacts that still embodies that old ethos. For serious Lisp work the alternatives are pale because they still treat code as text to be sent elsewhere, rather than a live system you live inside. This lock-in isn't some kind of nostalgia, it's just nothing else preserves that property.
I wish there were more Emacs-like systems, instead of dozens of tools that all trying to solve same or similar problems - how many different tools are there for Python alone just to unmess its cascaded dependency woes? Or look at the whole containerization tower - Docker, Compose, k8s, Helm, Nix - all because we've "forgotten" how to reliably reconstruct a running program's state.
TLDR: Don't ignore Lisp - it's not archaic, it's not "theoretical", it's practical, it works and it works well. And once you get some serious footing with Lisp, you'll sooner or later come to appreciate Emacs, and then will be forever frustrated that we don't build Emacs-like systems anymore. You'll hate Emacs and whenever you do, you'd be reminded that there's no better alternative in existence. Sadly or otherwise.
Re: A Road to Lisp: Which Lisp
#168Earlier quoted context omitted.
There's nothing "special" about Lisp and Lisp dialects, yes. Similar features can be or already have been implemented in other languages. Yet, after touching, using and experiencing working with a bunch of different stacks, I cannot simply ignore the enormous pragmatic level of Lisps. Working with Clojure is an absolute delight. It strips down all the dogma and let's you deal with the "business logic" as if you're co…
I've got really mixed feelings about Clojure. Like when I read Graham's book I went through a phase of "he wouldn't be fighting with nconc if he was using Clojure!" I find some algorithms to be easy and fun to write using persistent data structures and others maddening though if I did it more I'd get better at it. zippers are weirdly unergonomic because of some little bad choices. I badly wanted to do a project with…
> when I use Slack at work
Years ago I stopped typing anything longer than three words in anything but my editor, I just don't even understand why every programmer doesn't do that - it just makes perfect sense. The idea of automating copy+paste from any program into your editor and back is such an obvious thing, it feels stupid if you're not doing that.
> there are lots of little things that make vim live more comfortably side by side with modern GUI life than emacs does.
No disrespect, but honestly it sounds like you have never experienced the practical side of a Lisp system that permeates your OS. You just can't meaningfully compare Vim (or pretty much any other text editor) and Emacs, because Emacs is not a text editor, it's rather a text orchestrator. I for example easily build such workflows like "grab the url from one of my browser tabs and insert it", or I can get it from my browser history, or "retrive current thread I see in Slack and search for specific piece of text". Or placing the cursor to the plain text like "FOO-4142" immediately gets pattern matched and I see the popup with the Jira ticket description. That all I do in the middle of typing any text, like for example this very comment. I don't have to leave my editor, I'm not forced to do things how they dictated by other apps.
I use Neovim almost daily, it comes in handy for quick text editing in the terminal, and I love the idea of Vim in general - it's a beautiful, practical, amazing model and I use it everywhere, it permeates my OS - my WM, all my editors, my terminal and my browsers. But Neovim just can't be like Emacs, because fundamentally they are categorically incomparable. In practice that means that the "comfortably side by side" reach you're trying to describe goes further, because of affordances - building specific workflows that affect things on your local and remote machines is cheaper, quicker and simpler. I would grab any area of my screen and it gets immediately OCRed and extracted text pops in an Emacs buffer. It took me fifteen minutes to build that workflow. Getting done anything similar in pretty much any other editor wouldn't even occur to me - I wouldn't even bother seeing it as a problem that needs solving. Affordances shape the way you do things: https://news.ycombinator.com/item?id=48876315
Re: A Road to Lisp: Which Lisp
#169CL also has pretty much arbitrarily extensible syntax: - https://sr.ht/~dieggsy/whisper/ - https://dieggsy.com/json-literals.html And could also be used to build languages, supporting more modern programming paradigms (though yes, I believe Racket does make this easier): - https://coalton-lang.github.io/ I also might have written the Common Lisp example using reduce as well, which is in the standard library, but that…
I'd have used (funcall (ecase operation (:add '+) (:subtract '-) (:multiply '*)) result value) instead, looks funkier =)
Did you know CL allows keywords to be function names?
[1]> (setf (symbol-function :add) (function +))
#
[2]> (setf (symbol-function :subtract) (function -))
#
[3]> (setf (symbol-function :multiply) (function *))
#
[4]> (setf (symbol-function :divide) (function /))
#
[5]> (reduce (lambda (x y) (funcall (car y) x (cadr y))) '((:add 5) (:multiply 3) (:subtract 4)) :initial-value 0)
11
Re: A Road to Lisp: Which Lisp
#170Earlier quoted context omitted.
I think OCICL will meet your expectations more readily than Quicklisp. QL does things more the CPAN way (think Gems if you're more into Ruby than Perl). > a baked in way to run some sort of unit test suite. Have dozens of options if you want, but what is the "cargo test"? That actually is ASDF, to be more specific: (asdf:test-system system &rest keys &key force force-not verbose version &allow-other-keys) Although if…
That actually seems great ! My understanding is that it has to wrap ASDF package, so is there a risk of trying to find a well known lib, but not finding it because the authors refuse to create a ocicl package for some complex political reason (or sheer lazyness ?)
That doesn't seem likely, the packages are part of OCICL, so it's more likely to have the opposite problem: finding some obscure package you want to try out but which isn't in OCICL.