Standardized Ladder of Functional Programming [pdf] • Hacker News Board

Re: Standardized Ladder of Functional Programming [pdf]

#101

Post by coolsunglasses » Wed, Nov 30, 2016, 4:38 PM UTC

plinkplonk wrote: post #22

One way to process this list is to see it as an elitist construct intended to put you down or degrade you or extract money from you for training etc.(which might even be true, but generally it is better, ime, to assume that people are genuinely trying to provide what they see as value) The other is to ignore any insult, intended, perceived, or a mix of both, ignore all the hierarchy labeling - 'beginner', 'advanced b…

I have offered paid training at Lambda Conf in the past with my coauthor Julie and I am opposed to this ladder for _many_ reasons.

I think the class (as in hierarchy) and topic-chasing anxiety it will induce in many is counter-productive. It's extremely flawed as a guide for what to learn or what in order to learn things as well. One of the worst attempts I've seen on that front in fact. And yeah, the labels are useless anyway. It doesn't really matter what one thinks a "beginner" is.

It's also just bad optics. I don't know why John does stuff like this.

Re: Standardized Ladder of Functional Programming [pdf]

#102

Post by sitkack » Wed, Nov 30, 2016, 4:47 PM UTC

alexandercrohde wrote: post #29

tikhonj wrote: post #18

Earlier quoted context omitted.

A lot of these techniques are things that take a bit more up-front effort but pay off over the long (or even medium) term. I think that's why it might make people seem less productive—although of course a lot depends on your perspective and experience. Measuring productivity is an open problem in software engineering and, in my experience, people's intuitions about it are all over the board, which means that nobody's…

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…

I have had a number of projects that were absolutely successful from a technical standpoint because of FP methods. No one knew except team members that were unfamiliar with the techniques. While they were not full converts, many "saw the light" and reduced mutation and wrote purer functions after that.

The business itself was oblivious to why the project was successful. Or how we were able to extend it so quickly and retain stability.

Even on that project, 90% of the difficulty was social/political. Just as Java allowed average programmers to write above average code, the same thing can be said of FP.

Re: Standardized Ladder of Functional Programming [pdf]

#103

Post by pron » Wed, Nov 30, 2016, 5:49 PM UTC

seanparsons wrote: post #68

sleexyz wrote: 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.

Elitism is learning more powerful constructs? There's a lot of elitism in the construction industry then with people checking the load bearing of materials rather than building everything from mud.

Load bearing materials actually carry significantly higher loads than mud; those Haskell constructs have not even been used to build software as intricate as common industry practice, let alone break new ground. Are they truly more powerful? That's a popular hypothesis among those who are aesthetically drawn to those concepts.

Re: Standardized Ladder of Functional Programming [pdf]

#104

Post by willtim » Wed, Nov 30, 2016, 6:13 PM UTC

jarcane wrote: post #96

pka wrote: post #92

Earlier quoted context omitted.

> 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 la…

But Haskell does stand out among your list as being a pure functional programming language (it is not the only example of course). Whether this is a good or bad thing, I will not get into. When programming in a pure language you typically have to use some quite recent/advanced ideas such as monads and lenses, just to get practical work done. This is not the case with Clojure, F#, Scala, Erlang etc, where side-effects are idiomatic. In fact, if you tried to go fully pure with these languages, you would run into problems with performance.

To avoid confusion, they should have used the term "pure functional programming" or even "typed pure functional programming".

Re: Standardized Ladder of Functional Programming [pdf]

#105

Post by runT1ME » Wed, Nov 30, 2016, 6:23 PM UTC

a_imho wrote: post #35

runT1ME wrote: post #30

Earlier quoted context omitted.

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

> Salaries flat out quickly

What other professions besides lawyers or doctors regularly have a 3 or 4x range for salaries of people more or less with the same job description?

Re: Standardized Ladder of Functional Programming [pdf]

#106

Post by willtim » Wed, Nov 30, 2016, 6:26 PM UTC

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…

> And that shit can fuck right off

This is Anti-intellectualism.

FP is often a sliding scale. You can program with as much or as little type safety, purity or totality as you want. Some folks like to push the boundaries of what is possible without shortcuts, taking inspiration from recent research. Many Haskell, OCaml, Scala and F# libraries will require some of the concepts in this list to understand. I do agree that the list is somewhat Haskell centric though.

Re: Standardized Ladder of Functional Programming [pdf]

#107

Post by agentultra » Wed, Nov 30, 2016, 6:32 PM UTC

alexandercrohde wrote: post #29

tikhonj wrote: post #18

Earlier quoted context omitted.

A lot of these techniques are things that take a bit more up-front effort but pay off over the long (or even medium) term. I think that's why it might make people seem less productive—although of course a lot depends on your perspective and experience. Measuring productivity is an open problem in software engineering and, in my experience, people's intuitions about it are all over the board, which means that nobody's…

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…

My experience has been (34, Earth) that companies fail to succeed for a variety of reasons. Some of those reasons are poor technical choices. And some companies succeed in spite of said choices.

What functional programming brings to the table, aside from dense jargon, is the tools to build systems that are _correct by design_ and have certain, provable properties. For businesses this means they can spend less money fixing errors in their software and avoid losing revenue if they gain a reputation for releasing unreliable software. For programmers it means focusing on delivering instead of fussing around with runtime type errors, deadlocks, and the like.

Where this is useful is reducing the risks associated with failure: _when_ your software fails, what is the worst that could happen to your users or your business? If the answer is, "well some people might see the wrong blog article or have to re-submit their comment" then you have your answer. If your system is handling orders on a trading platform where an error could cost someone a few hundred million dollars... well it might be worth the effort to eliminate the possibility of as many errors as possible by using a better tool to help you with that.

The success of some companies in spite of not using _strict_ functional programming languages doesn't disprove anything the FP zealots have been saying for years. It only demonstrates how much money and time we invest in absorbing the cost of developing and operating software with innumerable, unknown errors.

Re: Standardized Ladder of Functional Programming [pdf]

#108

Post by willtim » Wed, Nov 30, 2016, 6:43 PM UTC

pron wrote: post #103

seanparsons wrote: post #68

Earlier quoted context omitted.

Elitism is learning more powerful constructs? There's a lot of elitism in the construction industry then with people checking the load bearing of materials rather than building everything from mud.

Load bearing materials actually carry significantly higher loads than mud; those Haskell constructs have not even been used to build software as intricate as common industry practice, let alone break new ground. Are they truly more powerful? That's a popular hypothesis among those who are aesthetically drawn to those concepts.

I gave you an example last week, which you are conveniently ignoring. We have millions of lines of Haskell code at Standard Chartered bank. The type safety and purity have helped us build a more reliable and maintainable codebase compared to previous efforts. Ultimately the language is just a tool. If you are not interested in type safety, purity or expressivity then it isn't the tool for you.

Re: Standardized Ladder of Functional Programming [pdf]

#109

Post by crystalPalace » Wed, Nov 30, 2016, 6:46 PM UTC

nikojn wrote: post #65

JackMorgan wrote: post #51

Earlier quoted context omitted.

I saw this pdf before all the angry comments, and was very excited to see a list of fun topics to explore and learn. I love skill trees in Skyrim etc, and to me this looked like a real life version! Time to level up!

Yeah, not sure what all the fervour is about. I've found the biggest hurdle to advancing is knowing what to study next; this helps solve that.

I definitely agree that the most difficult part of learning something new especially something as esoteric as FP is knowing where to start and then where to go from there. I also benefited from and highly recommend functional-programming-jargon(https://github.com/hemanth/functional-programming-jargon).

Re: Standardized Ladder of Functional Programming [pdf]

#110

Post by jarcane » Wed, Nov 30, 2016, 7:01 PM UTC

willtim wrote: post #104

jarcane wrote: post #96

Earlier quoted context omitted.

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 la…

But Haskell does stand out among your list as being a pure functional programming language (it is not the only example of course). Whether this is a good or bad thing, I will not get into. When programming in a pure language you typically have to use some quite recent/advanced ideas such as monads and lenses, just to get practical work done. This is not the case with Clojure, F#, Scala, Erlang etc, where side-effects…

To avoid confusion, they should have used the term "pure functional programming" or even "typed pure functional programming".

That's what was used when I started learning FP, which was maybe three or four years ago. There was FP, and then purity was a secondary characteristic. Haskell was pure and typed, but that didn't make other languages not FP, when they still had all the same basic tools and the same idiomatic focus on composition of functions over mutable state and imperative logic. No, you didn't need a special magic word to allow you to have side-effects like I/O, and most also allowed for mutability (even Scheme had set! after all), but they are first and foremost functional languages. In many ways, Haskell was and still kind of is the odd one out, not counting experiemental academic languages like Idris and Coq.

This wasn't even a controversial statement just a few years ago. But as Haskell has been more and more in vogue, there's this weird fixation on redefining the window of what "FP" is to only refer to, well, Haskell. And it's very clearly what the LC list is all about, because so many of the concepts described are both largely unique to Haskell and it's closest relatives, and unnecessary to do practical, everyday work in a vast majority of FP languages.

And ultimately, attitudes like that hurt the whole field. In trying to fix Haskell's image problem by brute force, they wind up damning the larger domain in the process.