Live data from Hacker News

Standardized Ladder of Functional Programming [pdf]

lambdaconf.us

91–100 of 146 posts

Re: Standardized Ladder of Functional Programming [pdf]

#91
post #85

Earlier quoted context omitted.

I would surmise from what I've heard that Standard Chartered easily on their own break this rule.

What I heard is that all of their Haskell software combined is about ~1MLOC (and they don't comprise a single system), and a huge chunk of that (a couple 100KLOCs at least) is the Haskell compiler itself, which they've modified and consider a part of their codebase. The Haskell compiler is still the largest Haskell program, and if it isn't, there are no more than a couple programs that are larger.

> a huge chunk of that (a couple 100KLOCs at least) is the Haskell compiler itself, which they've modified and consider a part of their codebase

Please don't talk about what you don't know. Standard Chartered's Haskell compiler is written completely from scratch and is not based on any existing compiler.

Re: Standardized Ladder of Functional Programming [pdf]

#92
post #76
post #57

Earlier quoted context omitted.

The fact that it's meaningless to you doesn't mean it doesn't have any meaning :) Your "hideously complicated type theory" is many peoples' "hideously horrible paren-based syntax" - i.e. Lisp. So, how many people don't learn Lisp only because of its syntax? I'd say a lot. Many of the concepts make sense when having an explicit type system, so if you want types you may want to learn them. Others I suspect you are alre…

> "hideously horrible paren-based syntax" - i.e. Lisp. So, how many people don't learn Lisp only because of its syntax? I'd say a lot. But the point is that nobody's putting 'S-expression syntax languages' in a Lisp-centric list of essential functional programming skills. The idea that half this stuff is supposedly mandatory is a skewed perspective. > Others I suspect you are already using, even if you don't know the…

> But the point is that nobody's putting 'S-expression syntax languages' in a Lisp-centric list of essential functional programming skills.

They should've probably said "FP-only" (i.e. pure) languages to exclude imperative languages that merely support functional programming constructs, like Clojure, Erlang, etc.

I agree, many of the concepts that are useful in pure languages (i.e. monads) are not that practical in imperative/impure or dynamic languages (at the cost of reduced ability to reason about your program.)

> And if the list is comprised of Haskell-centric jargon for more generic notions, that's obviously grounds for criticism.

It's the other way around - the items on this list are the more generic concepts [0]. Less expressive languages lack the (practical) ability to reason about those concepts generically, hence the need for more specialized constructs, like i.e. streams, transducers, etc.

[0] https://en.wikipedia.org/wiki/Coinduction#Codata

Re: Standardized Ladder of Functional Programming [pdf]

#93
post #85

Earlier quoted context omitted.

What I heard is that all of their Haskell software combined is about ~1MLOC (and they don't comprise a single system), and a huge chunk of that (a couple 100KLOCs at least) is the Haskell compiler itself, which they've modified and consider a part of their codebase. The Haskell compiler is still the largest Haskell program, and if it isn't, there are no more than a couple programs that are larger.

So in that case, what's important about your 1MLOC requirement? I can't even begin to imagine that much Haskell code versus a similar line count in say C.

Modern programming languages do not vary in their line-count by too much. If you want to compare to C, you may be able to get a 1 order-of-magnitude reduction in size if you're lucky, but 10MLOC C programs are common (Linux kernel is >15MLOC; MS Office is 30MLOC; LibreOffice is 12.5MLOC), as are 1MLOC programs in more modern programming languages.

Re: Standardized Ladder of Functional Programming [pdf]

#94
post #91
post #85

Earlier quoted context omitted.

What I heard is that all of their Haskell software combined is about ~1MLOC (and they don't comprise a single system), and a huge chunk of that (a couple 100KLOCs at least) is the Haskell compiler itself, which they've modified and consider a part of their codebase. The Haskell compiler is still the largest Haskell program, and if it isn't, there are no more than a couple programs that are larger.

> a huge chunk of that (a couple 100KLOCs at least) is the Haskell compiler itself, which they've modified and consider a part of their codebase Please don't talk about what you don't know. Standard Chartered's Haskell compiler is written completely from scratch and is not based on any existing compiler.

Sorry, that's what I'd heard (or I may have misinterpreted "a variant of Haskell" as "a variant of the Haskell compiler" all on my own); thank you for correcting me. So what you're saying is that biggest Haskell program isn't the Haskell compiler, but that the two biggest[1] Haskell programs are two completely different Haskell compilers.

(Also, while it has little to do with my point, I've also heard that the person behind SC's Haskell compiler is the one who'd written the first ever Haskell compiler, long before he started working for SC; is that true?)

[1]: Please don't take this too literally. In the two decades that have passed since Haskell was declared the language to end world hunger, someone may have written a bigger program. Maybe even two.

Re: Standardized Ladder of Functional Programming [pdf]

#95

Looking forward to Chris Allen (@bitemyapp) opining on this over on lobsters.

I don't really want to though.

Here's a couple threads: https://twitter.com/bitemyapp/status/803720075702255616

https://twitter.com/jdegoes/status/803721209439514624

Re: Standardized Ladder of Functional Programming [pdf]

#96
post #92
post #76

Earlier quoted context omitted.

> "hideously horrible paren-based syntax" - i.e. Lisp. So, how many people don't learn Lisp only because of its syntax? I'd say a lot. But the point is that nobody's putting 'S-expression syntax languages' in a Lisp-centric list of essential functional programming skills. The idea that half this stuff is supposedly mandatory is a skewed perspective. > Others I suspect you are already using, even if you don't know the…

> But the point is that nobody's putting 'S-expression syntax languages' in a Lisp-centric list of essential functional programming skills. They should've probably said "FP-only" (i.e. pure) languages to exclude imperative languages that merely support functional programming constructs, like Clojure, Erlang, etc. I agree, many of the concepts that are useful in pure languages (i.e. monads) are not that practical in i…

They should've probably said "FP-only" (i.e. pure) languages to exclude imperative languages that merely support functional programming constructs, like Clojure, Erlang, etc.

Ahh, and there would be that definition again, the one at the root of the problem.

Please find your nearest whiteboard and write the following 100 times or until it sinks in: "Haskell is not the only Functional Programming language."

FFS, the languages that invented functional programming are not Haskell, and predate it by some time. Lisp dates back to 1958. Scheme first appeared in 1970. ML dates to 1973. Haskell didn't even exist until 1990.

This weird ahistorical definition of "functional programming" is both useless and inaccurate. Strict typing and purity are not the sole measure of whether a programming language is functional and never have been. It's only been in the last few years that there seems to be this desperate push to define FP as "Haskell", which as far as I can tell is the product more of a desperate kind of evangelism than any sound argument for such a limited definition.

We get it, you like Haskell. But some of us also like Clojure, and Erlang, and Elixir, and F#, and OCaml, etc. etc., and you don't get to just redefine terms to cut out languages you don't like. Reality doesn't work that way.

Re: Standardized Ladder of Functional Programming [pdf]

#97
post #21

Most useless thing ever created for functional programming anything. It's not even biased towards Haskell; it's biased towards working at Slamdata, where they abuse free monads for everything. When you write Javascript and use first class functions (ideally without side-effects, but who the fuck really cares), that's functional programming. Tired of this elitism.

I agree, tired of elitism but

> When you write Javascript and use first class functions (ideally without side-effects, but who the fuck really cares), that's functional programming.

Sorry but no. Functional programming requires a whole set of new skills that most programmers don't have.

Learning the basics, pure functions, higher order components, immutability, second order functions, first class functions, lambdas, partial application, currying and point-free style. That's functional programming.

Re: Standardized Ladder of Functional Programming [pdf]

#98
post #21

Most useless thing ever created for functional programming anything. It's not even biased towards Haskell; it's biased towards working at Slamdata, where they abuse free monads for everything. When you write Javascript and use first class functions (ideally without side-effects, but who the fuck really cares), that's functional programming. Tired of this elitism.

I agree, tired of elitism but

> When you write Javascript and use first class functions (ideally without side-effects, but who the fuck really cares), that's functional programming.

Sorry but no. Functional programming requires a whole set of new skills that most programmers don't have.

Learning the basics, pure functions, higher order components, immutability, second order functions, first class functions, lambdas, partial application, currying and point-free style. That's functional programming.

Re: Standardized Ladder of Functional Programming [pdf]

#99
post #24

Some complaints about this list: 1. This list is very Haskell-focused: it includes lots of features which only make sense in Haskell or very Haskell-like languages, and lacks mention of many interesting functional programming concepts which don't appear in Haskell (like ML-style modules and functors, row types, macro systems and homoiconicity, and so forth.) There are a lot of functional languages which have very dif…

> not an ordered list but a graph of the concepts I like this idea a lot

I feel like this should be part of dbpedia.

Re: Standardized Ladder of Functional Programming [pdf]

#100
post #39

Earlier quoted context omitted.

> a rigorous and proven paradigm I'll give you rigorous, but how is it proven? I think it is a fair guess that the number of non-tiny programs (>100KLOC) making use of the "expert" concepts and skills is ~0. The number of large programs (>1MLOC) at the proficient level is also ~0.

I would surmise from what I've heard that Standard Chartered easily on their own break this rule.

How what proportion of the entire global population of functional programmers who qualify as proficient or better on this scale are employed by Standard Chartered?

(This is intended as a serious question, not a troll. It often seems that in discussions of FP, and particularly of Haskell, someone will suggest that there are few widely-known, large-scale projects written in this style that can be used to evaluate its effectiveness, and someone else will then reply with one or more of the same very small collection of larger projects or high profile organisations using FP/Haskell that are publicly known.)

Post reply on HN