Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Standardized Ladder of Functional Programming [pdf]

lambdaconf.us

Post reply on HN
Print view View original

31–40 of 146 posts

Re: Standardized Ladder of Functional Programming [pdf]

#31

Post by brianberns »

andolanra wrote: post #15

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…

> This list is very Haskell-focused

I agree. My preferred language (F#) doesn't even support many of the listed concepts beyond "Advanced Beginner".

Re: Standardized Ladder of Functional Programming [pdf]

#32

Post by brianberns »

alexandercrohde wrote: post #9

I get the sense that most engineers would almost never use, and never need to use, most things beyond advanced-beginner in this sheet. It may be fun to brag about knowing how to use "embedded DSL with combinators," but is that really the best thing to help your startup succeed? I suppose I'm slightly bothered by the fetishizing of challenging knowledge for challenge sake. Most of the people I know who learn about "Em…

> "embedded DSL with combinators,"

I agree that this wording makes it sound pretentious, but combinators are actually a very useful, practical technique. Parser combinators, in particular, are awesome.

Re: Standardized Ladder of Functional Programming [pdf]

#34

Post by bjz_ »

andolanra wrote: post #15

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…

> In many ways, I wish this list took a cue from Benjamin Pierce's Types and Programming Languages which features not an ordered list but a graph of the concepts related in the book

His dependency graph for Software Foundations is even cooler, and clickable! http://www.cis.upenn.edu/~bcpierce/sf/current/deps.html

Re: Standardized Ladder of Functional Programming [pdf]

#35

Post by a_imho »

runT1ME wrote: post #30
alexandercrohde wrote: post #29

Earlier quoted context omitted.

Well, I can't speak to your career experience, but I can speak to mine. My experience has been (31, SF) that companies are fundamentally disorganized, frequently reinvent things (a behavior seen at all levels), are skewed by politics, and ultimately are rarely successful due to the code. The fact is, that for most startups it's not the code that's make-or-break (twitter, snapchat, facebook, airbnb, uber), it's the bu…

>So when I see a list like this, I find it hard to imagine how "Profunctor Optics" is what Zynga (or any company I've worked at) needed to be successful. I mean, by that criteria, why learn anything? The world is not just startups btw, I work on products that have very very defined requirements. Hell, sometimes I'm implementing an RFC. FP is a huge win for us, and yes i've used profunctor optics in a high performance…

>I mean, by that criteria, why learn anything?

This might be tongue in cheek, but I agree with the parent. Engineering excellence will not further your career much, companies tend to oversell meritocracy. Salaries flat out quickly, and there is a huge supply of good enough developers, if you step out of the line too much.

Re: Standardized Ladder of Functional Programming [pdf]

#36

Post by jarcane »

andolanra wrote: post #15

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…

This is ... much more politely and detailedly stated than I managed on Twitter.

I work in FP, programming Clojure for real-world web applications every single day, and 90% of this list is completely meaningless to me.

It's nothing less than more of the Haskellite strain of "everything must be hideously complicated type theory or it's not 'real' FP."

And that shit can fuck right off. It's incredibly hostile and disrespectful both to new programmers and existing ones. It's even harmful to Haskell itself as a language, because this persistent attitude that you have to learn advanced type theory just to get anything done in Haskell is one of the biggest barriers to adoption and learning of the language, especially when even most of the material supposedly for "beginners" insists on thrusting this attitude on the reader.

Once again, just as they did by platforming an open fascist, LC demonstrates a complete cluelessness both of the community it claims to represent, and of the impact their "representation" has on said community.

Re: Standardized Ladder of Functional Programming [pdf]

#37

Post by [deleted] »

andolanra wrote: post #15

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…

[deleted]

Re: Standardized Ladder of Functional Programming [pdf]

#38

Post by pron »

Actual ladder:

1. Writes simple programs

2. Writes more complex programs

3. Writes programs that are maintainable

4. Writes programs that are maintainable by others, and communicate module intent clearly to team members who interact with it

5. Writes programs that are maintainable etc., and also make good use of resources, both computational and human

The emphasis on language concepts seems so distracting that I wander how much time people have left to make their program externally better (better functionality, better performance, more maintainable by others) rather than internally better (make use of clever abstractions). That the two are related is a hypothesis which doesn't seem to be supported by evidence, and is believed by those who enjoy thinking about the latter more than about the former and want to justify their focus.

Re: Standardized Ladder of Functional Programming [pdf]

#39

Post by pron »

llambda wrote: post #8
pulisse wrote: post #5

It says something slightly worrisome about the functional paradigm that "profile, debug, and optimize purely functional code with minimal sacrifice" is considered an expert-level skill.

Oh come on. Please do not troll. That says absolutely nothing about functional programming in general and absolutely everything about the publisher. Not only could this not be further from the truth, but it's a cheap and lazy attack on a rigorous and proven paradigm. Give it a try. You might just surprise yourself.

> 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.

Re: Standardized Ladder of Functional Programming [pdf]

#40

Post by Veen »

jarcane wrote: post #36
andolanra wrote: post #15

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…

This is ... much more politely and detailedly stated than I managed on Twitter. I work in FP, programming Clojure for real-world web applications every single day, and 90% of this list is completely meaningless to me. It's nothing less than more of the Haskellite strain of "everything must be hideously complicated type theory or it's not 'real' FP." And that shit can fuck right off. It's incredibly hostile and disres…

Was with you all the way to the end, where you chose to insert a bit of entirely irrelevant politicking.
Post reply on HN