71–80 of 91 posts
I've never been more thoroughly convinced that I would like ruby more than from this article. I'm currently stuck reaching for python a lot of the time (absolutely love it tbc), but maybe it's worth changing things up and trying to give ruby a shot. It was one of the first programming languages I was introduced to at 16 or so, but an older person that I looked up to told me it would get me stuck in "hobby coder land"…
Tbc?
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…
Earlier quoted context omitted.
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…
Even the Lisps have Lisps. Like Clojure with ClojureScript, CLR, ClojureDart, Jank... etc.
I do love that I learnt Clojure once like 5-7 years ago and more and more dialects keep expanding the choice of runtime I can target
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.
[1,2,3]
|> Enum.map(&square/1)
|> Enum.filter(&odd?/1)
Where Ruby's lisp lineage really shows is the fact that it's got Kernel#callcc, aka call with current continuation. It doesn't get any lispier than that!
Earlier quoted context omitted.
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…
I don't want to be a gatekeeper, but Clojure, Janet and similars doesn't even have cons cells; that's hardly 'the same programming language'.
Earlier quoted context omitted.
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.
Elixir has it. To make it worthwhile, the entire standard library has to be designed to have the ‘object’ of the function as first argument. [1,2,3] |> Enum.map(&square/1) |> Enum.filter(&odd?/1) Using a threading operator where there is no such consistency is painful. This is why I dislike CL’s or Python’s map function, taking the list to operate on as second argument, instead of first. A threading operator wouldn’t…
Earlier quoted context omitted.
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…
I don't want to be a gatekeeper, but Clojure, Janet and similars doesn't even have cons cells; that's hardly 'the same programming language'.
Earlier quoted context omitted.
> If the difference didn't matter, we wouldn't have so many different lisps Literally the opposite. We can make and use so many, because writing them is more or less the same. We can quickly throw together a new lisp for a new platform or such and use it without problem.
Why is it necessary to throw together a new lisp and not just use an existing one?