6 ms·

I really enjoyed this. Just wanted to comment on the author's brief comments on Elm. > As of yet, there is no rich polymorphism or higher-kinded types. As such

by dcre 11y ago

I really enjoyed this. Just wanted to comment on the author's brief comments on Elm. > As of yet, there is no rich polymorphism or higher-kinded types. As such a whole family of the usual functional constructions (monoids, functors, applicatives, monads) are inexpressible. I completely understand that this make Elm quite limited compared to Haskell as the author uses it, but these limitations are precisely what makes Elm accessible to newcomers. I think it's a great way to get people into Haskell syntax like partial application and into the functional way of thinking in general. I have learned Haskell very gradually over the past 6 years, and I still find advanced Haskell with all the language extensions very daunting to get into.

deleted 11y ago
[deleted]
- vvanders 11y ago
  Yikes, anyone coming from a non-FP background to Elm is very much going to learn new ways of programming. Elm is quite different than most front-end UI and I think your last sentence does it a great disservice.
baldfat 11y ago
For learning functional programming I find Racket to be the best for teaching functional programming. I think I took 4 tries at teaching myself Haskell and then learning Racket really helped me to get over the learning curve of Haskell though i still consider myself a beginner.
- PopsiclePete 11y ago
  I've tried Haskell 4 times. No joke. I have no problem with currying, higher-order functions, foldl, etc., but Monads. Get. Me. Every. Time. My brain just refuses to fully "grok" them. I still don't see why they're so awesome. I know I use them day-to-day - LINQ, the "List" abstraction (supposedly also a monad??) but I just don't see why it's important to understand them on this whole new fundamentally different level. It's like - loops. I use loops every day. But if someone were to say - "Hey, did you know that loops are just the Andifuncsplursx abstraction applied on Crazofors?? This is why Crazofors in Haskell are so awesome" I still wouldn't "get" Crazofors or why I should care enough to attempt to "get" them. I've just given up at this point.
  - platz 11y ago
    What things/path did you attempt while trying to learn haskell? Also, i dont think you need to understand crazofors, ot even monads in full generality, unless youre a hardcore library implementor. What people blog about and whats req'd to write an app are very different things
  - Verdex 11y ago
    I took me several years to grok monads. I even learned some category theory to try and get there (it didn't really help, but I do think it was useful for some other almost programming related things). The nice thing about monads with respect to the haskell programming thing is that you don't have to know why they work to get their benefit. However, if you wanted to build your own you probably do need to grok them. However, I'm not convinced that monads are the best way to proceed on the most part in programming advancements. The immutable/mutable tracking, affine types, and borrow checker in Rust seems like it would help prevent a lot of the same types of bugs that pure FP does, but without the cost of needing to have a monadic effect system (and Rust is a more familiar style of programming than the State monad with a host of monad transformers). I'm hoping for optional affine types and more immutable data structures to become the norm more than I am monad usage.
  - chriswarbo 11y ago
    > I've just given up at this point. Given up trying to understand Monads, or given up Haskell? I'm still confused by many monads, after years of Haskell programming; it hasn't stopped me getting stuff done.
  - louthy 11y ago
    This [1] might help 'get it' with regards to monads. Very easy to digest. You mention LINQ and the List abstraction. Yes IEnumerable<T> is a monad (LINQ isn't in itself - it [the grammar] is the equivalent of 'do' notation in Haskell). Monads are simply 'wrapper types' that follow a couple of rules: 1. You must be able to construct one from the un-wrapped value (return in Haskell, new List<T>(...) in C#) 2. It must implement the bind function. If you understand 'map' (or Select in LINQ) then bind is very similar, except instead of returning a mapped version of the wrapped value, it returns a mapped version of the wrapped value, re-wrapped. So in C# parlance (because I assume from your comment you use this daily): IEnumerable<R> Map<T, R>(this IEnumerable<T> self, Func<T, R> mapper) { foreach(var x in self) { yield return mapper(x); } } IEnumerable<R> Bind<T, R>(this IEnumerable<T> self, Func<T, IEnumerable<R>> binder) { foreach(var x in self) { foreach(var y in binder(x)) { yield return y; } } } You may recognise that as SelectMany in LINQ. Select and SelectMany are special case function names in C# that allow the formation of LINQ expressions: var res = from x in list select x + 1; Equates to: var res = list.Select( x => x + 1); And: var res = from x in list1 from y in list2 select x + y; Equates to: var res = list1.SelectMany(x => list2.Select(y => x + y)); The result is a 'flattened' IEnumerable<T> - and that's why this is also known as flat-map. It's been a while since I've done any Haskell, so forgive me if I get some of the syntax wrong here. But the LINQ statement above translates very similarly: do x <- list1 y <- list2 return x + y (I know there's a list comprehension syntax in Haskell, but I assume this is still right, Haskellers?) The syntax is saying 'get the value out of its wrapper (the list) for me, so I can use it as-is (the add operation), then put the result back in a new wrapper'. So why do we do all of this? It's so you can write the functions once that behave on the wrapped types, whether they're integers, strings or any type. The monad concept allows you to create a 'chain' of behaviour that from the outside is opaque, but internally it's operating on the raw wrapped values, as-is; and that makes all of the existing functions available. This is one of the key benefits. A good analogy is to call them 'programmable semi-colons', because what makes each monad type what it is, is the behaviour of bind and return. So a list monad (as seen above) knows how to iterate the collection - so you don't have to write a for loop every time, an option monad knows when to not invoke the bind function if it's in a None state - so you don't have to test it yourself with an 'if' every time, the state monad knows how to propagate state changes - so you don't have to have extra context arguments on every function down the hierarchy, etc. They remove boilerplate and capture common patterns. That is the other key benefit. At its core is an abstract idea, and I think that's why it's sometimes quite hard to grasp; but it's just a design pattern. Forget the category theory side of it, you don't need to know any of that to use use them or write new ones. If you're more used to C# than Haskell, then you may want to check out my 'C# functional language extensions' library [2] that has C# implementations of the following monads: Option Either State Reader Writer And a few others, but that should be enough to get started. It may help you get your head around it in a language you're more familiar with? [1] http://adit.io/posts/2013-04-17-functors,_applicatives,_and_monads_in_pictures.html http://adit.io/posts/2013-04-17-functors,_applicatives,_and_... [2] https://github.com/louthy/language-ext https://github.com/louthy/language-ext
- sotojuan 11y ago
  Racket is really underrated for some reason. I rarely see it mentioned even though not only is it friendly to beginners (both programming beginners and FP beginners) but has a decent ecosystem.
  - jonwot 11y ago
    i very much agree it's really sad that such a high quality language is held under the radar. Maybe poor marketing? The community is pretty good though.
  - vu3rdd 11y ago
    I played with Racket and used to lurk on their mailing lists for many years! I haven't seen a friendlier community than the Racket community anywhere else. DrRacket is a great environment to learn programming and play with various concepts, both for beginners and advanced users alike.

by dcre 11y ago

deleted 11y ago

[deleted]

vvanders 11y ago
Yikes, anyone coming from a non-FP background to Elm is very much going to learn new ways of programming. Elm is quite different than most front-end UI and I think your last sentence does it a great disservice.

baldfat 11y ago

For learning functional programming I find Racket to be the best for teaching functional programming. I think I took 4 tries at teaching myself Haskell and then learning Racket really helped me to get over the learning curve of Haskell though i still consider myself a beginner.

PopsiclePete 11y ago
I've tried Haskell 4 times. No joke. I have no problem with currying, higher-order functions, foldl, etc., but Monads. Get. Me. Every. Time. My brain just refuses to fully "grok" them. I still don't see why they're so awesome. I know I use them day-to-day - LINQ, the "List" abstraction (supposedly also a monad??) but I just don't see why it's important to understand them on this whole new fundamentally different level. It's like - loops. I use loops every day. But if someone were to say - "Hey, did you know that loops are just the Andifuncsplursx abstraction applied on Crazofors?? This is why Crazofors in Haskell are so awesome" I still wouldn't "get" Crazofors or why I should care enough to attempt to "get" them. I've just given up at this point.
- platz 11y ago
  What things/path did you attempt while trying to learn haskell? Also, i dont think you need to understand crazofors, ot even monads in full generality, unless youre a hardcore library implementor. What people blog about and whats req'd to write an app are very different things
- Verdex 11y ago
  I took me several years to grok monads. I even learned some category theory to try and get there (it didn't really help, but I do think it was useful for some other almost programming related things). The nice thing about monads with respect to the haskell programming thing is that you don't have to know why they work to get their benefit. However, if you wanted to build your own you probably do need to grok them. However, I'm not convinced that monads are the best way to proceed on the most part in programming advancements. The immutable/mutable tracking, affine types, and borrow checker in Rust seems like it would help prevent a lot of the same types of bugs that pure FP does, but without the cost of needing to have a monadic effect system (and Rust is a more familiar style of programming than the State monad with a host of monad transformers). I'm hoping for optional affine types and more immutable data structures to become the norm more than I am monad usage.
- chriswarbo 11y ago
  > I've just given up at this point. Given up trying to understand Monads, or given up Haskell? I'm still confused by many monads, after years of Haskell programming; it hasn't stopped me getting stuff done.
- louthy 11y ago
  This [1] might help 'get it' with regards to monads. Very easy to digest. You mention LINQ and the List abstraction. Yes IEnumerable<T> is a monad (LINQ isn't in itself - it [the grammar] is the equivalent of 'do' notation in Haskell). Monads are simply 'wrapper types' that follow a couple of rules: 1. You must be able to construct one from the un-wrapped value (return in Haskell, new List<T>(...) in C#) 2. It must implement the bind function. If you understand 'map' (or Select in LINQ) then bind is very similar, except instead of returning a mapped version of the wrapped value, it returns a mapped version of the wrapped value, re-wrapped. So in C# parlance (because I assume from your comment you use this daily): IEnumerable<R> Map<T, R>(this IEnumerable<T> self, Func<T, R> mapper) { foreach(var x in self) { yield return mapper(x); } } IEnumerable<R> Bind<T, R>(this IEnumerable<T> self, Func<T, IEnumerable<R>> binder) { foreach(var x in self) { foreach(var y in binder(x)) { yield return y; } } } You may recognise that as SelectMany in LINQ. Select and SelectMany are special case function names in C# that allow the formation of LINQ expressions: var res = from x in list select x + 1; Equates to: var res = list.Select( x => x + 1); And: var res = from x in list1 from y in list2 select x + y; Equates to: var res = list1.SelectMany(x => list2.Select(y => x + y)); The result is a 'flattened' IEnumerable<T> - and that's why this is also known as flat-map. It's been a while since I've done any Haskell, so forgive me if I get some of the syntax wrong here. But the LINQ statement above translates very similarly: do x <- list1 y <- list2 return x + y (I know there's a list comprehension syntax in Haskell, but I assume this is still right, Haskellers?) The syntax is saying 'get the value out of its wrapper (the list) for me, so I can use it as-is (the add operation), then put the result back in a new wrapper'. So why do we do all of this? It's so you can write the functions once that behave on the wrapped types, whether they're integers, strings or any type. The monad concept allows you to create a 'chain' of behaviour that from the outside is opaque, but internally it's operating on the raw wrapped values, as-is; and that makes all of the existing functions available. This is one of the key benefits. A good analogy is to call them 'programmable semi-colons', because what makes each monad type what it is, is the behaviour of bind and return. So a list monad (as seen above) knows how to iterate the collection - so you don't have to write a for loop every time, an option monad knows when to not invoke the bind function if it's in a None state - so you don't have to test it yourself with an 'if' every time, the state monad knows how to propagate state changes - so you don't have to have extra context arguments on every function down the hierarchy, etc. They remove boilerplate and capture common patterns. That is the other key benefit. At its core is an abstract idea, and I think that's why it's sometimes quite hard to grasp; but it's just a design pattern. Forget the category theory side of it, you don't need to know any of that to use use them or write new ones. If you're more used to C# than Haskell, then you may want to check out my 'C# functional language extensions' library [2] that has C# implementations of the following monads: Option Either State Reader Writer And a few others, but that should be enough to get started. It may help you get your head around it in a language you're more familiar with? [1] http://adit.io/posts/2013-04-17-functors,_applicatives,_and_monads_in_pictures.html http://adit.io/posts/2013-04-17-functors,_applicatives,_and_... [2] https://github.com/louthy/language-ext https://github.com/louthy/language-ext
sotojuan 11y ago
Racket is really underrated for some reason. I rarely see it mentioned even though not only is it friendly to beginners (both programming beginners and FP beginners) but has a decent ecosystem.
- jonwot 11y ago
  i very much agree it's really sad that such a high quality language is held under the radar. Maybe poor marketing? The community is pretty good though.
- vu3rdd 11y ago
  I played with Racket and used to lurk on their mailing lists for many years! I haven't seen a friendlier community than the Racket community anywhere else. DrRacket is a great environment to learn programming and play with various concepts, both for beginners and advanced users alike.