Show HN: Using Common Lisp from Inside the Browser (opens in new tab)

Well, that world would also have CLOS - maybe the AMOP would be treated with the same reverence as the GoF design patterns book... ;-)

this article discussing how closure creation is disguised OO (and vice versa) might interest you.

https://wiki.c2.com/?ClosuresAndObjectsAreEquivalent

I kind of agree, but in the interest of discussion: even if CL isn't necessarily a more functional language in practice, culturally it's got a long history of being more functional. It took something like a decade at least for people to widely recognize to how elegant (in its quirky way) JavaScript could be. Just as a point of comparison (I'm sure the idea goes further back) PAIP - one of the definitive CL books - was first published in 1991 and encourages pure functions and immutability wherever possible.

Devs in the 90s were handed a language that looked like a weird Java and so they programmed it like a weird Java. If they were handed a language that looked like Lisp instead, maybe they would have made their way to SICP that much sooner.

CL is the Ditto (pokemon) of programming langauges. It commits to nothing and does everything better than you'd expect. The problem is its very much a lone warrior type of language. you can attain great productivity due to macros and just how maleable it is but it makes it near impossible to get a team to work together on it without very extensive styling and conventions strictly adhered to by the team. In a way, you could say its a direct influence to go, in that the go team saw everything common lisp did and decided to do the opposite.

Both CL and Elisp are arguably more functional than Javascript in several key ways - Immutable data by convention, First-class function from the start (js added this later), powerful higher-order function are more idiomatic, lexical closures, FP culture that goes back decades. JS has caught up in some aspects - arrow functions, array methods, const, libs like Rambda.

I think, Lisp in general is very flexible - you can write imperatively, or you can do more FP; if you need object-orientation - you have it, polymorphic dispatch - sure why not?, etc., etc.

As the sibling says, CL can be written in most any style. Which, I think it is fair to say for any general programming language? The book Exercises in Programming Style highlights that. That said, CL feels far friendlier to the various styles than other languages, to me.

Link to book on Amazon: https://www.amazon.com/dp/0367350203

CL enables many paradigms of programming, including functional one and imperative. Currently the most popular way of programming among CL programmers is OOP with CLOS.

CL is pretty multi-paradigm. To give the boring 'double all numbers in a list' example:

  (defun double-numbers (numbers)
    "Doubles a list of NUMBERS.
  Docstring and type declarations are optional."
    (declare (type List numbers))
    (mapcar (lambda (x)
              (declare (type Number x))
              (* x 2))
            numbers))

  (defun double-numbers (numbers)
    (labels ((accumulate-loop (nums acc)
                (if (null nums)
                    (funcall acc nums)
                    (destructuring-bind (first-number &rest other-numbers)
                        nums
                      (accumulate-loop other-numbers
                                       (lambda (result)
                                         (funcall acc
                                                  (cons (* first-number 2)
                                                        result))))))))
      (accumulate-loop numbers (lambda (result) result))))

  (defun double-numbers (numbers)
    (if (null numbers)
        numbers
        (cons (* (first numbers) 2)
              (double-numbers (rest numbers))))

  (defun double-numbers (numbers)
    (loop :for number :in numbers
          :collect (* number 2)))

  (defun double-numbers (numbers)
    (if (null numbers)
        numbers
        (prog ((remaining-numbers (rest numbers))
               (first-pair (list (* (first numbers) 2)))
               last-pair)
          (setf last-pair first-pair)
        :start-loop
          (when (null remaining-numbers)
            (return first-pair))
          (setf (rest last-pair)
                (list (* (pop remaining-numbers) 2)))
          (setf last-pair (rest last-pair))
          (go :start-loop))))

And that's before going into libraries like SERIES or iterate. There are, of course, benefits and disadvantages (readability, performance, some CL implementations don't do TCO,...) to every option, but generally CL lets you code in any way you want (you could even write some macros to let you write it using more infix or postfix style syntax, but I don't see the appeal of doing so).

There's also Guile Hoots compiling directly to WASM.

FP is principally about function composition, folds and zippers. I still find myself thinking in terms of iteration, it's just not expressed as a for-loop. Instead, the iteration conditions are expressed by the composed function which builds a list, and the body of the for-loop is expressed by the composed function applied to the members of the list.

  for(int i = 0; i < N; ++i) { ... }

becomes

  foldl (fn (i, acc) => ...) 0 (range N)

It's technically recursion, but I don't really see any of it, and I don't really think about it that way.

Fair point! Programming paradigms aren't objectively superior - they're tools, and different people's brains work differently. Many problems are naturally iterative, and forcing them into recursive patterns can feel awkward. That said, some problems become much cleaner with FP approaches - data transformations, avoiding shared state bugs, or mathematical computations. It's worth having both tools available. use imperative when you think in steps, use functional when you think in transformations. Don't force one paradigm everywhere just because it's trendy or "pure."

But do give yourself this gift - even if you end up preferring imperative style for day-to-day work, learning Haskell or Clojure can be genuinely eye-opening.

It's like learning a foreign language - even if you never become fluent, it changes how you think about your native language. You'll start seeing patterns and abstractions you missed before, even in imperative code.

upd: sorry, only after posting it I noticed your "as someone who's done both". Just wanted to point out that here my suggestion is aimed not to you directly, but to a "proverbial" programmer, I used "you" in more general sense.