A Functional Programming Influence Graph | Hacker News Reader

A Functional Programming Influence Graph

blog.fogus.me

89 pointsolauzon41 comments

Nice. I was under the impression that ALGOL's IF-THEN-ELSE statement was inspired by LISP (but I can't seem to find any references more reliable than some wikis). Also, if System F is going to get a line into Haskell, why not give the untyped lambda calculus a line into LISP?

I'm having trouble finding a detailed history of Clean, but I believe it predates Haskell. My understanding is that Miranda prompted a handful of lazy, pure functional languages. Haskell was an attempt to unify them. In Coders at Work, SPJ mentions that a few of those implementors were not interested in participating with the Haskell group. Is Clean one of those languages? (Of course, that doesn't mean they haven't influenced each other over the years, what I'm trying to suggest is that maybe an edge belongs from Miranda to Clean as well.)

It'd be interesting to see a graph of the influence of functional languages on other languages, too. Things like Python's list comprehensions borrowed from Haskell, and JavaScript borrowing lots of things from Scheme. I can only imagine that such a graph would be larger and less comprehensible than the present one!

All amazing questions -- you've managed to identify many gray areas of the graph. This graph is the seed to a large research project and will likely change as the research proceeds.

What sort of research project? I'm also curious where you draw the line regarding "traditionally functional" languages with respect to multiparadigmatic languages.

Perhaps there ought to be a single square to represent all languages that aren't traditionally considered functional languages, to represent the influence that functional languages have had on the rest of the language ecosystem. For example, I'd say Erlang's concurrency model influenced both Go and Rust (and Rust would inherit from both SML and Haskell as well).

Python borrowed list-comprehensions from Haskell et al.

Lexically scoped closures are from Scheme* and virtually all modern languages have them now. (Well, C++ and Java are late on the lambda boat, but C++11 and it seems Java 8 are getting them.) That's a huge influence.

* Scheme was the first Lisp to gain lexical scope, and C of course has lexical scope but not closures, but what's the full history here? It's also part of the lambda calculus.

You might argue that Erlang has influenced Haskell. (E.g. Erlang -> Haskell exists).

In two respects:

* the view patterns syntax was built to enable bit level parsing, inspired by the Erlang support (I wrote the binary library to emulate Erlang support for IP header parsing).

More recently,

* Cloud Haskell

http://hackage.haskell.org/trac/ghc/wiki/ErlangInHaskell

There's also an example of Erlang-style actors in Haskell in this video: http://yow.eventer.com/events/1004/talks/1055

What reference do you have for Clojure influencing the language Scala? Scala is older, so that seems surprising to me.

Odersky himself has implied that Scala was prompted by Clojure in its recent persistent structure implementations. However, this influence is motivational rather than via copied code (as stated at http://stackoverflow.com/a/3108380). Although Odersky does mention the word "copied" in an interview that I had with him, but that state of affairs may have changed (http://blog.fogus.me/2010/08/06/martinodersky-take5-tolist/).

My guess was that it was going to be the container library, rather than the language itself. If libraries are included, then Clojure-inspired HAMTs are in Haskell as well. But really, Clojure, Haskell and Scala are all just implementing Bagwell's ideas, http://lampwww.epfl.ch/papers/idealhashtrees.pdf whose feasibility was shown in Clojure.

See e.g. for Haskell, originally as http://www.haskell.org/pipermail/haskell-cafe/2010-February/... and now as http://www.haskell.org/wikiupload/6/65/HIW2011-Talk-Tibell.p...

However, your graph will be much more complicated if libraries are allowed to influence each other, rather than strictly considering language features.

> My guess was that it was going to be the > container library, rather than the language itself.

This walks a thin line for sure and in Scala the line is almost microscopic. I'll keep it for now since my reasoning was the same as the Erlang->Scala influence. A core language library that is rarely viewed as other than a core feature.

I disagree with that. There is great attention between language features and functionality shipped in the standard library. This http://clojure.com/blog/2012/04/19/take5-daniel-spiewak.html might also be of interest.

Also, Coq is an OCaml derivative and Agda was influenced by Coq.

Add somewhere near the bottom Pure http://code.google.com/p/pure-lang/

They have a really neat programming influence graph on the wall at the Computer History Museum in Mountain View. It's displayed in relation to date, so it gives you a bit of a historical reference point.

A presentation by SPJ left me with the impression that FP should be pointing to Miranda and several other languages that became Haskell, rather than to Haskell itself.

Eiffel wasn't strictly functional but it heavily influences Racket (including current development). See [1].

[1] http://www.eecs.northwestern.edu/~robby/pubs/papers/ho-contr...

I think www.classes.cs.uchicago.edu/current/22300-1/lectures/FP_history.pdf is a better graph because it focuses more on functional languages and the layout is easier to navigate.

a) it focuses /less/ on functional languages, since it includes many fewer.

The nice one about this graph is that it is relatively complete.

That is a very nice graph. I was shooting for a more comprehensive graph, but as you see at the cost of comprehension.

Why did you include Fortran and Algol? I'm curious what warrants their inclusion, but not BASIC or ADA or a variety of other languages... they certainly don't meet the textbook definition of "functional."

The big surprise for me: Why does this graph show Scala as a descendent of Clojure? I was not aware of that at all. What features or ideas does Scala get from Clojure?

Discussed below. The Scala containers library contains an implementation of Bagwell's HAMT type; which first gained fame in its Clojure implementation. HAMTs have since appeared in many language library suites.

I did something similar, sometime back, where I used the influences from the information boxes on the programming language pages on wikipedia to generate a global lineage graph. I used SVG as the output format though, since it is much more searchable, zoomable, and linkable. You can see here:

http://jaisharma.info/static/choice/images/projects/lineage.... .

It would be neat if, say, dashed lines were used for all the descendants of LISP that are Lisps.

I'm definitely open for display ideas. DOT source is located at https://gist.github.com/2576547 and is forkable.

That'd may be hard, because there's no canonical 'original' Lisp (there were a few similar, but incomplete/incompatible versions), and more importantly, there's no clear definition of what even is a Lisp.

I mean, from the ones shown, it's sort of obvious, but I'm thinking in general. Also, Common Lisp, Racket, and Clojure are different enough that they count as separate languages in their own right, rather than 'variations', which a dotted line might imply.

> more importantly, there's no clear definition of what even is a Lisp.

How about: If you program in it using s-expressions, it’s a Lisp.

Qi uses S-Expressions but it's got strong typing, pattern matching, and optional lazy evaluation. Sounds a lot more like Haskell than Scheme to me.

I'm not sure there is such a thing as a "Lisp." If you mean S-expression language, just say s-expression language. Wedging in Lisp as a substitute conflates the issue.

Logo is a Lisp and yet does not really use s-expressions, and even has infix operators.

Now, you might argue that means Logo is not a Lisp, but it is actually extremely similar to basic Scheme. You could turn an interpreter for one into an interpreter for the other with mostly minor tweaks. It's also a dialect of Lisp historically.

Anyone here use Qi, Mercury, or Agda? I’m interested in what people think of those languages.

Agda is a proof assistant. I've used Coq, but not Agda -- I imagine they're similar. You wouldn't use it for general development.

Qi is interesting but the development community is much smaller than its competitors (mainly Haskell). You probably want to look into Shen, not Qi. Qi development has mostly stalled.

Why wouldn’t you use it Agda/Coq for general development? (Looking for reasons other than a presumed lack of libraries.)

It's very slow and every function must have formal properties, e.g. all functions are total and must formally be proved to terminate.

(As far as I know. I've only worked through Pierce's book.)

In the dependently typed family of languages it's a little bit arbitrary to divide between programming languages and proof assistants since everyone in this space can be made to play both roles in a pinch. I think most people think of Coq as more on the proof assistant side and Agda more on the programming language side.

Sort of. Dependent types doesn't explain Coq's requirement for pure, total functions. Unless this restriction is weakened I cannot see it as being useful in any general-purpose domain. Agda may be looser.

> Dependent types doesn't explain Coq's requirement for pure, total functions.

That's where you are wrong. Partial functions introduce the bottom value and then you can 'prove' arbitrary incorrect things.

I'm not sure what you're saying. I was saying that simply being dependently typed doesn't necessitate pure total functions. Obviously, these features can be considered either highly suggested or necessary for ITPs. There are a number of ways you can get around totality with dependent types.

I have tried Mercury a few times. Prolog sans REPL is no use to me. I'm interested in Agda but haven't put much effort into it.

Mathematica influencing Clojure really surprised me. Any references?

http://grokbase.com/t/gg/clojure/122nctdz9c/notes-on-mathema...

Cf. D. Nolen's fantastic work in this field

Reply on news.ycombinator.com