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

81–90 of 146 posts

Re: Standardized Ladder of Functional Programming [pdf]

#81

Post by gb »

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 don't think it's mentioned anywhere in the poster, but it's also perhaps worth noting that this came out of a survey, it wasn't just dreamed up by one person / a few people.

(A tweet thanking survey respondents: https://twitter.com/lambda_conf/status/803695274896093184)

Re: Standardized Ladder of Functional Programming [pdf]

#82

Post by loup-vaillant »

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…

> Compared to what? C? I'm not talking about C, but about any modern language.

The domain they tackle is personal computing, which means Kernel, Windowing system, remote communication (web/mail), multimedia… So, yeah: mostly C and C++, by the look of currently popular programs.

That said, much of the (apparently) needlessly complex stuff I have seen was written in C++, and it did look like they didn't have the real-time requirements or resources constraints that would justify the use of such a monster of a language.

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

I have yet to reach the second stage. And on one occasion, I did reach a reasonable understanding of the whole system. It definitely had to be very complex to match the specification, but the specifications themselves didn't match the end user's needs.

> (or that, alternatively, waste is unavoidable)

That's the alternative I'm most scared of. I cannot comprehend unavoidable waste, but I can't rule it out either.

Alternatively, I've came across the idea of not solving some problems¹, because the return on investment is just crap. Okay, when safety is involved, you probably cannot do that. Still, the idea that the 80/20 rule is sometimes more like 99.9/0.1 is enticing. Sometimes, full automation is not best. For instance last I checked, the best Chess player ever is a human-computer team, not a computer.

[1] Stop Over-Engineering https://www.youtube.com/watch?v=GRr4xeMn1uU

Re: Standardized Ladder of Functional Programming [pdf]

#83

Post by tel »

pron wrote: post #63
thelambentonion wrote: post #16

Earlier quoted context omitted.

Two potential counter-examples to your productive software claim: Opaleye [0], an Arrow-based [1] DSL for Postgres SQL that allows the user to create type-safe, composable, and (generally) optimally fast SQL queries. Halogen [2], a type-safe frontend framework for PureScript [3] that models view component interaction as an algebraic datatype containing query actions (among other fairly advanced concepts). If someone…

> Two potential counter-examples to your productive software claim How are those counterexamples? Do they provide benefits that significantly outweigh their cost? > the higher levels might seem unnecessary until they invest the time into learning them Except that this can't go on forever. Because we know that programming productivity has a theoretical upper bound, therefore there must be diminishing returns, and at s…

Profunctor and Monad are heavily studied in CT and many related mathematical fields that use category theory. For instance, algebraic geometry and logic. Algebra is incredibly well studied under the name "abstract algebra" and is one of the core concepts in modern mathematics since Bourbaki.

But this is just a side point to what you're saying.

Re: Standardized Ladder of Functional Programming [pdf]

#85

Post by pron »

seanparsons wrote: post #71
pron wrote: 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.

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.

Re: Standardized Ladder of Functional Programming [pdf]

#86

Post by the_af »

chriswarbo wrote: post #74

I agree with others that there's far too much Hasochism in this list. I do think of FP as being like a ladder or spectrum, but rather than progressing towards some elitist niche, I see it as more empowering and anti elitist. In my opinion, if you refactor a Java class to change a setter into something which returns an altered copy, you've just made your code a little bit 'more functional'; if you use a list comprehen…

I agree with you about the gradual refactoring. I love FP and according to that list, I'm mostly an "advanced beginner"... and I see nothing wrong with that.

Even "just" refactoring Java or Python code to be more functional is a huge win. Even "just" using Scala in a more or less FP way is a huge win. I don't fret being unfamiliar with Lenses or whatnot yet.

Re: Standardized Ladder of Functional Programming [pdf]

#88

Post by the_af »

bbotond wrote: post #47

Best way to convince someone that they will never, ever have any chance of understanding functional programming and therefore should not even bother trying it.

Why? Even at the level of Advanced Beginner (which is pretty concrete and easily attainable), FP is already hugely useful. Everything at that level is both useful and relatively easy to understand. It's going to improve your code even if you use a language not particularly tailored for FP.

The rest is just icing on the cake, and you don't have to deal with it if you don't find it interesting.

Re: Standardized Ladder of Functional Programming [pdf]

#89

Post by pron »

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

Earlier quoted context omitted.

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

> Compared to what? C? I'm not talking about C, but about any modern language. The domain they tackle is personal computing, which means Kernel, Windowing system, remote communication (web/mail), multimedia… So, yeah: mostly C and C++, by the look of currently popular programs. That said, much of the (apparently) needlessly complex stuff I have seen was written in C++, and it did look like they didn't have the real-t…

> I've came across the idea of not solving some problems

That, too, cannot be solved by a programming language :)

But much of complex software deals with things that could not possibly have been solved more efficiently (or even efficiently enough) by humans (like sensor fusion, package tracking, manufacturing control etc.). Also, we're pretty far from full automation. Nobody trusts computers to make the decisions in air-traffic control systems, power plant control software, or even in ERP systems.

The reason we keep building large software is that -- in spite of many problems -- they really do work (in the sense of achieving their goal of higher-throughput; whether or not a higher throughput of flights or of business deals is good or bad for humanity is an entirely separate question).

Re: Standardized Ladder of Functional Programming [pdf]

#90

Post by seanparsons »

pron wrote: post #85
seanparsons wrote: post #71

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.

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.
Post reply on HN