61–70 of 146 posts
Even being a Haskell enthusiast and loving playing with stuff in the list, this does not reflect well on Lambda conf and, unfortunately, on Haskell. The smugness and self-importance displayed in there is quite the opposite of the virtue of code simplicity put forward by e.g. Don Stewart at HX this year.
> e.g. Don Stewart at HX this year Can you give some link? I wasn't able to google it.
Requires registration.
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…
> not a single piece of large software (except maybe a compiler or two) has ever been written using the skills/concepts of the higher levels of this chart. I wonder: to what extent this is because those higher level concept tend to shrink programs in the first place? I mean, big is bad, there's no debating this. Big programs can only arise from necessity or stupidity. And if those fancy features are any use, they mus…
None at all. No one, AFAIK, even claims a reduction of even a single order of magnitude in code size.
> I would ask myself a slightly different question: what kind of program still have to be big, even if you have all these fine concepts at your disposal?
All those that are big now. I'm not talking about a single executable, but about an entire system (specification, development and debugging have always been done modularly, regardless of whether there's a single process or a distributed system). I see no way to implement the requirements of, say, an air-traffic control system, complex avionics or a banking system in software that isn't very big.
> 100KLOC is already big
A mid-sized enterprise software system is ~5MLOC. Google and Facebook have codebases that are measured in the hundreds of millions LOC. You can use whatever definitions, but if you look at software actually being constructed, much (if not most) of development effort in the industry is systems that are about ~5MLOC.
> What kind of specification is so complex that it cannot even fit in 50 books?
My guess? The majority of software written today is part of such specifications. I once worked on a medium-sized air-traffic control system designed for a relatively small area and number of planes, whose informal functional specification was ~10 books. The specifications for the avionics software of a fighter jet developed in the 80s were ~2000 pages of structured natural language (source: http://www.wisdom.weizmann.ac.il/~harel/papers/Statecharts.H...)
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…
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…
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 some point the cost of more abstraction would outweigh the benefit. We just don't know where that point is. Finding out is not a matter of faith or even personal feeling, but of actual results.
Now, I know that collecting meaningful productivity data is hard, but that evidence of a claim is hard to come by doesn't make that evidence any less necessary for the claim. You're free to say that you like FP because you enjoy it more, or even that it makes you feel more productive. But you can't make actual empirical claims without actual evidence.
> The only thing unique to functional programming is that it has inherited a lot of terms from theory (profunctor, monad, algebra) rather than inventing friendlier ones.
I'm not entirely sure that's the case. FP is often its own theory. I'm not sure many of those concepts were studied heavily outside the context of FP, but I could be wrong about that.
It is also clear that there is not just one FP.
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 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!
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.
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…
The strain you're referring seems like this perception that is somehow self perpetuating. My experience is that of an incredibly helpful community that gives up its time to help and educate people.
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.
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…
Earlier quoted context omitted.
> not a single piece of large software (except maybe a compiler or two) has ever been written using the skills/concepts of the higher levels of this chart. I wonder: to what extent this is because those higher level concept tend to shrink programs in the first place? I mean, big is bad, there's no debating this. Big programs can only arise from necessity or stupidity. And if those fancy features are any use, they mus…
> to what extent this is because those higher level concept tend to shrink programs in the first place? None at all. No one, AFAIK, even claims a reduction of even a single order of magnitude in code size. > I would ask myself a slightly different question: what kind of program still have to be big, even if you have all these fine concepts at your disposal? All those that are big now. I'm not talking about a single e…
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 have to, though? I've seen a big fat list of requirements in my last gig, and many were duplicated into 2 slightly different versions. As were some pieces of the code. And that's the obvious stuff. There were more subtle waste, where simpler alternatives would have fit the bill, but weren't applied because of historical reasons (I asked the architect, there was a reason for everything).
Almost everywhere I look, I see a wasteland of useless code, and even the specs aren't that clean to begin with. It feels like proper DRY alone would have reduced the size of this stuff by 2 or 3. Maybe I was unlucky enough to work in especially crappy environments. But from what I hear, that's the norm. So far, you're the only one I met that challenges that perception.