41–50 of 91 posts
One way I find traditional Lisp style more painful for functional code than Ruby is that fully functional-style Lisp pushes me to read and write code the opposite way from how I think about it. In the author's example: orders .select { |o| o.placed_at > 1.week.ago } .group_by(&:customer_id) .transform_values { |group| group.sum(&:total) } the equivalent Lisp code would either be written in imperative style as multipl…
Threading macros are nice, though, right? https://docs.racket-lang.org/threading/introduction.html
Earlier quoted context omitted.
Funny enough Lisp was originally meant to be written in a higher level syntax (with infix operators and everything). But yeah, macros and S-expressions make it easier to write your own DSLs.
With decades later, Dylan and Julia becoming the only ones that kind of managed to get some adoption doing it. For better or worse, parenthesis aren't that bad with the proper IDE tooling.
Hell, even without [0], you can at least count the parenthesis by hand in a pinch. I remember seeing lots of crazy-awesome stuff done in AutoLisp by 'non-programmers', versus 'structure as spacing' in Python which really sucks if the Editor was designed to use the system default (probably non-monospaced, cause other products in the industry had dialogs that broke if you switched to a monospaced) font. [1]
[0] - but real talk parenthesis matching in an editor is a lifesaver
[1] - oooooold version of a very popular GIS product.
Earlier quoted context omitted.
Threading macros are nice, though, right? https://docs.racket-lang.org/threading/introduction.html
They're nice, but they're not the same thing. The threading macros are (as I understand it) pure sugar. Turning (-> (gather my-list) uppercase-list sort) into (sort (uppercase-list (gather my-list))). In contrast to, say, Java (I can't speak to the code above): List things = thingIds.stream() .map(model::findThing) .filter(Objects::nonNull) .toList(); These are streamed. This is pretty much a pipe structure, whereas…
The version with a threading macro, will create a lazy-sequence for each step in the pipeline. It will not instantiate the entire list, so it's O(1) memory overhead in terms of peak memory, but it churns O(N) extra garbage.
(->> things
(map model/find-thing)
(filter some?))
(sequence (comp (map model/find-thing)
(filter some?))
things)
> He’s described Ruby’s design as starting from a simple Lisp, stripping out macros and s-expressions Put the macros back! It would be so cool!
That is actually Lisp influence on Smalltalk, and Perl, that eventually influenced Ruby.
I love Ruby, use it for most of my projects that don't require performance. Nothing I would love more than a Ruby with a Common-Lisp like compiler and runtime. Unboxed types, native compilation, partial compilation, live image (Ruby has this but "faster Rubies" like Crystal don't), etc...
I still believe you could do pretty well there with a few basic "tricks" that could still also remain real/valid Ruby, by recognising the most common patterns, documenting them, and providing a way of marking exceptions. Combine that with freezing system classes after startup as an enabler for various optimization, and a compiler could do a pretty good job. But it's a massive piece of work to get it right for Ruby.
Earlier quoted context omitted.
Which Lisp, out of interest?
Does it really matter? There's a point in every Lisper's life, a threshold after which the question becomes immaterial - you'd stop thinking about intricacies of whatever Lisp and focus on the platform specifics instead. Any given day I might program in three-four different Lisp dialects, e.g. Clojure/Clourescript, Fennel, Elisp, Janet, etc. and it practically feels like I'm using the same PL. While switching between…
not philosophically, but certainly practically. To double down, if all lisps are roughly equivalent from a language POV, then you'd want to pick the one or two that will give you the most practical advantage (libraries, documentation, dev environment, etc.)
> He’s described Ruby’s design as starting from a simple Lisp, stripping out macros and s-expressions Put the macros back! It would be so cool!
Macros depend on homoiconicity which Ruby sacrificed in order to have familiar syntax.