11–20 of 146 posts
When working with functional languages (my current choice is Scala), I do feel that they require a level of mastery that "traditional" imperative languages do not. I also feel that if computer science/software engineering is ever going to gain any sort of repeatability it will be through functional design. That said, functional programming is incredibly difficult to do well without years of practice and the languages…
"Copyright Fantasyland Institute of Learning" - I think that says it all ... in case you missed the big unicorn logo at the top.
Earlier quoted context omitted.
HaskellBook.com will teach you quite a number of them. :) The Reddits for the different functional programming languages are a good place to hangout (and a frequent source of blogs and videos on these topics), and for FP in non-FP languages, there are good Github communities (e.g. http://github.com/fantasyland/ , no association with FIOL). I'd also humbly suggest that LambdaConf 2017 (May 25-27) is a great place to l…
Is there anywhere to preview some content from HaskellBook.com ? Its a little pricey for to just take a chance without seeing any same content. The TOC looks good but that's not much indication of writing style.
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…
Hopefully the smarter bits van be factored out as easier-to-use libraries.
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 different ideas about how to program, and this list doesn't reflect that.
2. Some of the 'skill hierarchy' choices feel a bit confused and arbitrary. For example, 'Use lenses & prisms to manipulate data' appears as a Competent skill, but 'Use optics to manipulate state' appears as a Proficient skill, despite being slightly different ways to refer to an effectively identical skill. (I assume the latter means "…use lenses & prisms to manipulate data, but in a state monad," which is only a tiny difference.)
3. While I like the idea of a list of a road-map to learning, I feel like this gives the unfortunate impression that many of these are obligatory skills. It calls itself a "standard" hierarchy (which makes it sound like a consensus, rather than just a single person/group's opinion) and has language like "…skills that developers must master on their journey…" (emphasis mine), but the list includes a lot of things that are far from necessary for deeply understanding functional programming. You could lead a long (academic or industry) career in functional programming without a deep understanding of many concepts listed: things like comonads, recursion schemes, finally tagless interpreters, higher-order abstract syntax, and so forth. All of them are useful concepts and deserve study, but you can definitely be a functional programming expert without ever having seen a comonad.
In many ways, I wish this list took a cue from Benjamin Pierce's Types and Programming Languages which features not an ordered list but a graph of the concepts related in the book, and how they relate to other concepts. It would be more complicated, true, but also a lot more honest about the academic and intellectual path you might want to take through functional programming, and without giving the idea that you need to master the vagaries of dozens of Oleg Kiselyov's papers just to be "competent" in functional programming.
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…
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 is used to a certain level of abstraction, then the higher levels might seem unnecessary until they invest the time into learning them. 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.
[0] https://github.com/tomjaguarpaw/haskell-opaleye
[1] https://www.haskell.org/arrows/
Earlier quoted context omitted.
HaskellBook.com will teach you quite a number of them. :) The Reddits for the different functional programming languages are a good place to hangout (and a frequent source of blogs and videos on these topics), and for FP in non-FP languages, there are good Github communities (e.g. http://github.com/fantasyland/ , no association with FIOL). I'd also humbly suggest that LambdaConf 2017 (May 25-27) is a great place to l…
Is there anywhere to preview some content from HaskellBook.com ? Its a little pricey for to just take a chance without seeing any same content. The TOC looks good but that's not much indication of writing style.
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…
DSLs are a great example of this long-term dynamic. Compared to throwing together an ad-hoc library, a DSL approach takes a lot more design effort but, ultimately results in a system that's more coherent, elegant and expressive.
I've worked on both kinds of projects and the difference is palpable: 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 know which style I prefer, and it's definitely not because I "fetishize challenging knowledge for challenge sake"—it's because I'm willing to put effort up front for a long-term reward. And it's not even that long-term—I've found these things pay off over weeks or months, not years, so I'd take the same deliberate approach unless my deadlines were literally days away.
It's funny to see that singleton types are within the highest level: 'expert'. While in Typescript they're, together with union types, the most intuïtive thing ever. I guess that's because to express them in a language that doesn't have native support requires advanced deftness in typelevel programming. Like f.i. implementing them yourself in Scala 2.x. So I expect the coolness factor of singleton types and union typ…
http://stackoverflow.com/questions/16017294/singleton-types-...
Singletons are a way to emulate dependent types with typeclasses, datakinds, and GADTs