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

121–130 of 146 posts

Re: Standardized Ladder of Functional Programming [pdf]

#121

Post by grumpyprole »

pron wrote: post #119
grumpyprole wrote: post #114

Earlier quoted context omitted.

You said: "I would like to challenge that by pointing out that not a single piece of large software ... has ever been written using the skills/concepts of the higher levels of this chart." To which I gave two counterexamples (today and on other occasions). All software systems should be modular to some degree, so I am not clear exactly what your criteria for a large software system is. In both my examples, the Haskel…

> I am not clear exactly what your criteria for a large software system is. Let a "software system" mean any assembly of processes that communicate to provide some shared functionality, with the components being coupled to one another in some non-trivial way (i.e., there are correctness conditions that cross processes boundaries, so that changes to one program may necessitate changes in others). Excluding the compile…

You just described the entire bank! I prefer my single codebase/single build definition. I forget the current figure, but StanChart has at least 3M lines of (dense) Haskell. More details here: https://skillsmatter.com/skillscasts/9098-haskell-in-the-lar...

Re: Standardized Ladder of Functional Programming [pdf]

#122

Post by tome »

pron wrote: post #94
tome wrote: post #91

Earlier quoted context omitted.

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

AFAIR the Mu compiler is not even the biggest program written in Haskell inside Standard Chartered.

Re: Standardized Ladder of Functional Programming [pdf]

#123

Post by a_imho »

runT1ME wrote: post #105
a_imho wrote: post #35

Earlier quoted context omitted.

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

In addition to those? Actors, musicians, sport people. In the office? Managers. Hence the advice, focus on soft skills. I would wager the top 1% on the developer track earn nowhere near to the top 10% on the managerial track. And your best bet is to regularly change jobs otherwise good luck getting anything more than a 5-10% increase, while managerial salaries and bonuses scale with the size of the organization. Also, there is a lot to be said about the difficulty of the work.

Re: Standardized Ladder of Functional Programming [pdf]

#124

Post by pka »

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…

If your language is not purely functional it is imperative. There is really no conceptual difference between Clojure and Python, except for syntax/macros and that Clojure has immutable data structures in clojure.core.

You could use mutable arrays in Clojure the same way you could use immutable arrays in Python (yet nobody is calling Python a functional language.)

Still, I agree that functional mostly means "language with closures and immutable data" in the mainstream, but in the context of this post I'd say it's not that hard to guess that the authors meant purely functional.

Re: Standardized Ladder of Functional Programming [pdf]

#125

Post by tempodox »

pron wrote: post #38

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

+1.

Also, s/wander/wonder/.

Re: Standardized Ladder of Functional Programming [pdf]

#126

Post by tome »

pron wrote: post #75
loup-vaillant wrote: post #70

Earlier quoted context omitted.

> No one, AFAIK, even claims a reduction of even a single order of magnitude in code size. http://vpri.org claims about 3, though most of it is not because of the languages, but because of the removed redundancies. The languages do seem to be responsible for at least 1 order of magnitude. About the rest, of what you say, I won't claim anything. It just make me feel… uneasy . Okay, those specs are that big. Do they ha…

> The languages do seem to be responsible for at least 1 order of magnitude. Compared to what? C? I'm not talking about C, but about any modern language. > Do they have to, though? Yes. Or, at least, everybody (including me when I first saw them) says "this cannot possibly be this complicated", and after understanding them, everybody says, "oh, OK". But let me put it another way: if the modern world really only requi…

> if the largest software system needs to be ~100KLOC, then none of it matters too much. Writing such a piece of software isn't hard regardless of what language you use

I think this is absolutely the difference between you and proponents of Haskell. Personally I have found working on 100k LOC codebases very hard in Python and easy in Haskell.

Re: Standardized Ladder of Functional Programming [pdf]

#127

Post by runT1ME »

coolsunglasses wrote: post #101
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 usel…

I'm not sure I would have called it a 'ladder', and the fine grained tiering into buckets seems overly ambitious, but I'm guessing you'd end up agreeing that there are topics that most beginners will find confusing/unfamiliar. If the end goal is to make it easier to sort talks into tracks for conferences, what's the issue? Do you really think Profunctor Optics should be a beginner level talk, or that using "functors" should be advanced? I'm sure you could argue specifics or make a good case for mistakes made in this chart, but to say "I don't know why John does stuff like this" seems unnecessarily harsh.

Re: Standardized Ladder of Functional Programming [pdf]

#128

Post by sclv »

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…

I think this list is not reflective of a general Haskell outlook. Its reflective of an outlook of people standing _outside_ Haskell (LC is historically a scala-heavy conference) and projecting onto it a certain sort of structure of expectations that isn't actually how Haskellers in general view things. I agree that this misperception isn't a good thing for Haskell -- but its a misperception imposed from the _outside_.

Re: Standardized Ladder of Functional Programming [pdf]

#129

Post by runT1ME »

pron wrote: post #43
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…

> with the first style, productivity is constant at best—getting things together in the first place is a struggle, and then adding features or fixing bugs continues to be a struggle. On the other hand, the second style of project is even more of a struggle at first, but once it works it's like magic: new features are easier to add than you'd expect, and I've had way more things work after my first attempt than anyone…

>out that not a single piece of large software

What are you talking about? I know for a fact this is untrue. How do you continually justify making up things and passing them off as facts?

Re: Standardized Ladder of Functional Programming [pdf]

#130

Post by pron »

runT1ME wrote: post #129
pron wrote: post #43

Earlier quoted context omitted.

> with the first style, productivity is constant at best—getting things together in the first place is a struggle, and then adding features or fixing bugs continues to be a struggle. On the other hand, the second style of project is even more of a struggle at first, but once it works it's like magic: new features are easier to add than you'd expect, and I've had way more things work after my first attempt than anyone…

>out that not a single piece of large software What are you talking about? I know for a fact this is untrue. How do you continually justify making up things and passing them off as facts?

> I know for a fact this is untrue.

Why, because I missed a point of data in the ocean of hype and there is one? Two? Please, set the record straight, and provide us with some facts. Maybe in Haskell's 20 year history as the world's most hyped language there was one or two or maybe three non-compiler programs written in it that aren't very small. Maybe there is even one anecdote out there with some actual information in it, although I've looked for one -- a lot -- and couldn't find any. So right now, the people who are making stuff up and passing them off as fact are those who claim significant impact over and over and over without a shred of even the tiniest of anecdotal data. How is that justified?

I have absolutely no problem saying that Haskell works better for large interactive software than other languages, once there are a couple of anecdotes around, but the fact is that currently there aren't any (at least none that I could find). What we have at the moment is a lot of vague claims with zero metrics.

But perhaps I should explain the source of my skepticism. First, it stems from the almost unprecedented gap between hype and evidence. I would imagine that after so many years, given the grand claims there would at least be some good anecdotes. That there aren't any, inspires skepticism. Someone here likened Haskell's abstractions to load bearing materials as opposed to other language's mud. If that were true, the reasonable prediction would be to see Haskell skyscrapers towering over a sea of mud hats; that we actually observe the opposite, inspires skepticism. Second, it stems from my general skepticism (based on CS theory and 20 years of experience) towards the impact any language can make. I.e., I have not encountered a case where the choice of language was the determining factor. Haskell is perhaps the most notable example of a language that claims to make a significant difference by virtue of language-level features (as opposed to runtime features, like GC). I would very much like to see how big that contribution is, if it exists at all.

Post reply on HN