21–30 of 91 posts
Now that I'm out of the corporate tyranny and have my own company, I use lisp for everything. There's certain satisfaction in writing config files and persisting data directly in s-expressions. Any json requirements are triggered by exports to foreign systems.
orders
.select { |o| o.placed_at > 1.week.ago }
.group_by(&:customer_id)
.transform_values { |group| group.sum(&:total) }
(reduce #'+
(map (lambda (o) (getf o 'total))
; this group_by replacement function
; might be written as hash-table code
(my-group-by 'customer-id
(remove-if-not
(lambda (o)
(>
(getf o 'placed-at)
(- (my-now) (* 60 60 24 7))))
orders))))
Other imperative languages that support functional code either make you do things imperatively to get the "logical" ordering of functional operations like I feel Lisp pushes you to do, or they do something like Ruby where things can be chained left to right in a "single" statement even for operations that were not thought of ahead of time by the creators of opaque data structures you later need to operate on. (Everything is a user-extensible object like Ruby, unified function call syntax in D, extension methods in C#, or pipelines of structured objects in PowerShell.)
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…
Earlier quoted context omitted.
... or just use Common Lisp.
Which is what I do. One can dream though right? Of a world where Ruby stayed just a tad more Lisp-y and less Perl/C/Smalltalk/Unix-y. Also I'm working on a DSL/Macros that give me more Ruby-esque quality of life things in Lisp.
As a last resort look at Racket's "Rhombus" language, it's basically an infix, Python-like syntax on top of Racket. You can use that or see how they pull it off and add Ruby constructs to it.
Now that I'm out of the corporate tyranny and have my own company, I use lisp for everything. There's certain satisfaction in writing config files and persisting data directly in s-expressions. Any json requirements are triggered by exports to foreign systems.
I also like how in Haskell:
something =
{ element
, element1
, element2
, element3
}
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…
|>
()
For a variadic language you'd need something more involved though. But some kind of syntax can probably be invented in some language.
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'm Ruby or Lean 4.
Now that I'm out of the corporate tyranny and have my own company, I use lisp for everything. There's certain satisfaction in writing config files and persisting data directly in s-expressions. Any json requirements are triggered by exports to foreign systems.
That JSON prohibits trailing commata makes it an absolute pain to work with in practice. I also like how in Haskell: something = { element , element1 , element2 , element3 } Is an actually idiomatic way to deal with the lack of trailing commata.
MyClass::MyClass(foo bar, int arg1, int arg2)
: Base(bar)
, member1(arg1)
, member2(arg2)
{
}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…
I feel languages should just have some kind of sugar or operator for this, in fact in Ocaml the |> operator exists where |> ( ) Are just one and the same For a variadic language you'd need something more involved though. But some kind of syntax can probably be invented in some language.
[0] https://github.com/dtenny/clj-arrows
> 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!
You kind of don't need them in Ruby, because everything is a method or an object or a closure and you can dynamically create and alter those at runtime. That's why Ruby is really good for ad-hoc DSLs in ways that Rust and Swift really are not.