3 ms·

> I don't like the metaphor or idea behind "you make the simple complicated". When I say simple things I mean what's obvious for someone who programs primarily

> I don't like the metaphor or idea behind "you make the simple complicated". When I say simple things I mean what's obvious for someone who programs primarily in imperative languages, like top-down, line by line execution in functions or local variables in functions. If you can take the same functions and understand them as operations on lists of things then both ways of looking at the problem are valid, though the latter won't be obvious without having the relevant experience. > But when you see a possible fit for Haskell (I would hesitate to make 'obvious' be the bar), have you tried to persuade or demonstrate the advantages? I have yet to. Again, I work primarily with Obj-C. Integrating Haskell would mean complicating a fairly elegant collection of tools and libraries. "Hey I like FP" isn't something I'm willing to sell to clients nor do I think it's the responsible thing to do. I go to great lengths to ensure that I'm delivering a product that could be understood by and maintained by developers with a wide range of experience / skill. Integrating a second language / paradigm into that without any clear gain would be counter to that. > Why not find customers/areas that would be open to using Haskell? For me it's really a chicken and egg thing. It's not easy for me to bring Haskell into my professional or even personal projects so I'm not experienced enough to go after primarily Haskell projects. What would make me consider it would be significant downtime caused by a lack of projects in the language(s) I'm already familiar with. Until that happens I'm not sure I'll make the jump. I could possibly see writing libraries in Haskell but again it's hard for me to make that jump when I know I could write it faster in C/Obj-C because of my familiarity. What I like about Haskell (the type system, how succinct it is, functional purity) I can get most of the benefits of in Obj-C. I rarely if ever use dynamic types and I tend to write Obj-C (well, more and more these days) in a functional style by leveraging the relatively new addition of blocks.

loup-vaillant 12y ago
> obvious for someone who programs primarily in imperative languages, like top-down, line by line execution in functions or local variables in functions. This makes me angry at "ordinary" programmers. They think it's obvious, but they never rigorously modelled the sequential execution in the first place. Instead, they use their instinct. Instinct is efficient, but when it's wrong, tough luck. This is probably why proving the correctness of a program is so difficult: you have to pin everything down mathematically, including sequences of side effects. For most people, that's much more difficult than merely relying on their guts. As a result, no one proves their programs. Maybe they test them. With Haskell, you can't even program without pinning it all down mathematically. As a result, no one uses Haskell… OK, not no one, but still that's a significant barrier to entry. I wish programmers were more mathematically aware. I wish they realised they're doing applied math, whether they like "math" or not. I'm tempted to blame our education, but I'm not sure it's the only culprit.
- nathan7 12y ago
  The best guess I've come up with is that anyone who is sufficiently mathematically inclined becomes a mathematician. I'm curious if anyone has any points/counterpoints in that direction.
  - loup-vaillant 12y ago
    Well, we do have computer scientists who have worked on program proof, cryptography, and type inference. Haskell (and earlier Miranda, and ML) where invented somehow.
    - nathan7 12y ago
      Accepted, but they seem to be on either side of a dividing line — I'm doing my best to straddle it, but I'm still held back by a wall of language that is too often entirely impenetrable to me. I'm a very functionally-minded programmer, and I'm rapidly adapting to Clojure now (coming from rather functional JS, and having spent a rainy week on Haskell, which taught me basic type theory and such) — but I still often hit the wall of impenetrably abstract things too :(
      - loup-vaillant 12y ago
        It takes time. I used to read many Haskell related papers, and many things were impenetrable. Then, from time to time, one of them was suddenly obvious. Then another. And another. The best advice I can give is, don't be content with words and labels. Search for the underlying structure. Take monads for instance. Lots of tutorials, lots of examples. But I didn't really got them until I read the Typeclassopedia: when you get to read the word "monad" you realize it was explaining the monadic structure in depth from the very start. Practice also helps. Implementing a Parsec clone in Ocaml helped me understand applicative functors and monads. (I also experienced some of the disadvantages of strict evaluation.) You may want to try that in Clojure. Finally, when something seems impenetrably abstract or obscure, that may be because you lack some basic vocabulary. For instance, you can't understand a paper on type inference if you don't know how to read type rules: https://en.wikipedia.org/wiki/Type_rules https://en.wikipedia.org/wiki/Type_rules Which you can't read if you don't know what's an environment… As I said, it takes time.

loup-vaillant 12y ago

> obvious for someone who programs primarily in imperative languages, like top-down, line by line execution in functions or local variables in functions. This makes me angry at "ordinary" programmers. They think it's obvious, but they never rigorously modelled the sequential execution in the first place. Instead, they use their instinct. Instinct is efficient, but when it's wrong, tough luck. This is probably why proving the correctness of a program is so difficult: you have to pin everything down mathematically, including sequences of side effects. For most people, that's much more difficult than merely relying on their guts. As a result, no one proves their programs. Maybe they test them. With Haskell, you can't even program without pinning it all down mathematically. As a result, no one uses Haskell… OK, not no one, but still that's a significant barrier to entry. I wish programmers were more mathematically aware. I wish they realised they're doing applied math, whether they like "math" or not. I'm tempted to blame our education, but I'm not sure it's the only culprit.

nathan7 12y ago
The best guess I've come up with is that anyone who is sufficiently mathematically inclined becomes a mathematician. I'm curious if anyone has any points/counterpoints in that direction.
- loup-vaillant 12y ago
  Well, we do have computer scientists who have worked on program proof, cryptography, and type inference. Haskell (and earlier Miranda, and ML) where invented somehow.
  - nathan7 12y ago
    Accepted, but they seem to be on either side of a dividing line — I'm doing my best to straddle it, but I'm still held back by a wall of language that is too often entirely impenetrable to me. I'm a very functionally-minded programmer, and I'm rapidly adapting to Clojure now (coming from rather functional JS, and having spent a rainy week on Haskell, which taught me basic type theory and such) — but I still often hit the wall of impenetrably abstract things too :(
    - loup-vaillant 12y ago
      It takes time. I used to read many Haskell related papers, and many things were impenetrable. Then, from time to time, one of them was suddenly obvious. Then another. And another. The best advice I can give is, don't be content with words and labels. Search for the underlying structure. Take monads for instance. Lots of tutorials, lots of examples. But I didn't really got them until I read the Typeclassopedia: when you get to read the word "monad" you realize it was explaining the monadic structure in depth from the very start. Practice also helps. Implementing a Parsec clone in Ocaml helped me understand applicative functors and monads. (I also experienced some of the disadvantages of strict evaluation.) You may want to try that in Clojure. Finally, when something seems impenetrably abstract or obscure, that may be because you lack some basic vocabulary. For instance, you can't understand a paper on type inference if you don't know how to read type rules: https://en.wikipedia.org/wiki/Type_rules https://en.wikipedia.org/wiki/Type_rules Which you can't read if you don't know what's an environment… As I said, it takes time.