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

41–50 of 146 posts

Re: Standardized Ladder of Functional Programming [pdf]

#41

Post by Veen »

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.

I'm glad that's the general attitude. I've been learning Elixir for a couple of months now and my first though was: "crap! I've never even heard of most of this stuff, never mind understanding it."

I know I have a long way to go before I'm a competent with functional programming, but I thought I at least understood the basic landscape, even if I don't know how to apply it properly yet.

Re: Standardized Ladder of Functional Programming [pdf]

#43

Post by pron »

tikhonj wrote: post #18
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…

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 has a right to expect.

I would like to challenge that by pointing out that 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. What you say may be true if generalized to better upfront design etc., but there's also no evidence that this is better done using the approaches discussed. It's not even about measuring productivity; it's about arguing over the properties of an empty set. When it comes to small (> it's because I'm willing to put effort up front for a long-term reward.

You're equating upfront effort with a particular choice of technique, and one that has never been put to the test.

Re: Standardized Ladder of Functional Programming [pdf]

#44

Post by [deleted] »

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…

[deleted]

Re: Standardized Ladder of Functional Programming [pdf]

#46

Post by pyrale »

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.

Re: Standardized Ladder of Functional Programming [pdf]

#48

Post by wlk »

There was something similar suggested by Martin Odersky for scala few years back: http://www.scala-lang.org/old/node/8610

It didn't get much traction back then.

But overall I like the idea as a roadmap for learning particular language or skill set. I'd like to something like that but with references to material where particular skill can be learned, etc

Re: Standardized Ladder of Functional Programming [pdf]

#49

Post by premium-concern »

brianberns wrote: post #31
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".

That says more about your preferred language than the listed concepts.

A language limited to a level of advanced beginners is not necessarily bad, though.

Re: Standardized Ladder of Functional Programming [pdf]

#50

Post by js8 »

pyrale wrote: post #46

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.

Post reply on HN