Hacker News Reader

Comment by substation13 | Hacker News Reader

> You can adopt the techniques of functional programming right now in your favorite language (such as Python, used above).

No tail call optimization, no expression orientation, mutability by default, no variable shadowing, single expression lambdas, no do-notation, reference semantics everywhere, dog slow function calls... functional programming in Python doesn't work in my experience.

Now, there is a great case for functional lisps, like Clojure, since they support all the fancy patterns in cutting-edge Haskell etc. but without an extremely complex compiler. Of course you sacrifice some type-safety.

View on HN

Like the strict MLs (ocaml, Standard ML, F#, ...), while Lisp and Scheme can express the Haskell idioms it lacks the pervasive laziness that makes them (somewhat) efficient. For instance one might write `zip [0..] xs` to number the list `xs` in a single pass. This lack of laziness (even on code that does notionally work without it) manifests in blowing stacks, in Scala at least. Also the lack of types (type classes) precludes at least some things such as the `deriving` mechanism.

For all that you're dead right about Python.

> This lack of laziness (even on code that does notionally work without it) manifests in blowing stacks, in Scala at least.

Please don't spread FUD.

The std. lib functions in Scala are stack safe. (Simple, fast while loops under the hood when it comes to collections).

To pick up the `zip` example:

  val r = (1 to 100_000_000).zip(1 to 100_000_000)

won't blow up with a stack overflow.

https://scastie.scala-lang.org/a4v5w1bKTeadQaPtK9CC5A

Also custom recursive functions can be made safe (for example by using trampolining).

You blow stack in Scala only when you explicitly ask for it by writing unsafe code. (Which is BTW something that applies to more or less all languages as almost nobody ever repeated the mistake to build a lazy by default language).

https://news.ycombinator.com/item?id=1924061

With SRFI 41 (streams) this can be expressed lazily in Scheme, but it is more verbose than Haskell:

    (import (srfi srfi-41))
    (define xs '(a b c))
    (stream-zip (stream-from 0) (list->stream xs))

This returns a lazy stream whose values can be evaluated later.

Sounds irrational, but it looks much more beautiful for me. My brain says, you should like Haskell, mirroring my experience that static languages with a strong type system are much better for big projects. But my heart knows, I would always prefer Lisp.

The strict MLs often have a `lazy` keyword, but it's definitely not as tidy as Haskell for this use-case. I'm sure a clever Clojure macro could be devised for the same!

Functions like map and range return lazy lists in Clojure. This is how I'd implement zip:

   (def zip (partial map vector))

   ;;Usage:
   (zip (range) [:a :b :c])
   ;;=> ([0 :a] [1 :b] [2 :c])

Hell, even JS is a better functional language than Python.

Author here: I agree that another dynamic language with all of those attributes would be great.

Elixir. Lets you do stateful declarative stuff (talking to databases, communication, disk) with no fuss. No mutability, single line lambdas, fast function calls.

Plus, rediculously easy concurrency, customizable failure domains, first class concurrent testing...

Might as well use Erlang?

No? The syntax and standard library is vastly different in terms of ergonomics. You could argue whether its better but it's undeniably more familiar to non-erlangers.

(Alternatively, you already are using Erlang anyway.)

Well, Erlang has slightly nicer syntax, IMHO.

I would have assumed you can use the same library functions?

(Sorry, I mostly only used Erlang and only briefly looked into Elixir and didn't find anything useful compared to just plain Erlang.)

"didnt find anything useful"

Better documentation, better package management, testing framework, consistent function calls, opinionated standards on how to name things (get vs fetch, ! suffix for crashables, is vs ?, size vs length), Protocols, not having lexical macros, not needing make, Testing Framework, compile environments (test, dev, prod), $callers, custom guards, Task, Registry, DynamicSupervisor, IO.inspect (now dbg), mix tasks, TESTING FRAMEWORK...

Or former Prolog users.

Could Google adopt such a language? They were early on Python, which was great! Perhaps they could "bless" Clojure - or more likely build their own.

https://github.com/baruchel/tco

Reply on news.ycombinator.com