6 ms·

It boils down to the choice between these two alternatives: 1) If it's simple to imagine the computer doing something, it should be easy to program. 2) If it'

It boils down to the choice between these two alternatives: 1) If it's simple to imagine the computer doing something, it should be easy to program. 2) If it's simple to analyze something mathematically, it should be easy to program. The first path leads to C-style programming with pointers and loops. The second path leads to lazy pure functional programming and beyond. Personally, I'm in the first camp. Small functional programs are often shorter and more beautiful than their imperative and OO counterparts, but large functional programs quickly accumulate so many abstractions that they become incomprehensible to me, more so than large imperative or OO programs. Maybe that just says something about my intelligence, or maybe the functional camp hasn't yet figured out how to write large programs in a readable way. Case in point, see the list of operators defined by the popular Lens library in Haskell: http://hackage.haskell.org/package/lens-3.8.5/docs/Control-Lens-Operators.html http://hackage.haskell.org/package/lens-3.8.5/docs/Control-L...

deleted 13y ago
[deleted]
tel 13y ago
Eh, the list of operators is a weird artifact of the design of lens. The fundamental abstractions at the core are fairly simple, although they're exposed in a scary way. Most of that has to do with optimizing for reuse and proper type inference. It's a cheat to expose the Haskell subtyping relation for more leverage. A better way to understand lenses should be to consider a package like lens-family-core which keeps to its roots.
- platz 13y ago
  Scala had/has an issue with user-defined operators; there was a proposal that all operators should also be able to be called with an english word i.e. provide a named function. I wouldn't mind if haskell library designers took that practice to heart.
  - tel 13y ago
    To that end, the lens library exposes named verbs for most of the core operators and both the verbs and operators are chosen with great discretion toward consistency... if not great discretion toward not clobbering related libraries.
dons 13y ago
Lens is one guy's pathological abstraction. It's a library, and it's idiosyncratic. It isn't want large Haskell systems "look like". Cf http://ro-che.info/articles/2014-04-24-lens-unidiomatic.html http://ro-che.info/articles/2014-04-24-lens-unidiomatic.html
- cousin_it 13y ago
  I agree that Lens is extreme, that's why I picked it as an example. However, most Haskell code I've seen also has line-noise problems, though not as extreme as Lens. Maybe I just haven't been lucky. Can you point to some good examples of readable Haskell code?
  - deleted 13y ago
    [deleted]
  - freyrs3 13y ago
    If you work with Java/C/C++ then the way you structure, compose, and think about programs is mostly entirely different from Haskell. Any of the examples I might point to as idiomatic Haskell are going to be "unreadable" ( if that words means anything ) within that worldview, because they come with an entirely different set of constraints and culture than the Java/C++ world.
    - nhaehnle 13y ago
      It would still be nice if you (or somebody else) pointed at those examples. That would open new avenues for learning and communication.
      - freyrs3 13y ago
        What kind of examples are you interested in?
    - deleted 13y ago
      [deleted]
  - 13y ago
samnardoni 13y ago
> Maybe that just says something about my intelligence, or maybe the functional camp hasn't yet figured out how to write large programs in a readable way. You make it sound like we've figured out how to write imperative large programs in a readable way.
- cousin_it 13y ago
  Well, it's not too bad. I work at Google and spend a significant part of every workday reading other people's code, written in imperative/OO languages. That's not too difficult, if the code uses few abstractions and if you have good tools for reading it, like cross-referencing, version control history and code review history. But the "few abstractions" part is actually important, I can't imagine reading typical Haskell code at the same speed. When you're tracking down a bug or trying to implement a feature that touches several projects, you really need to read fast.
  - collyw 13y ago
    It really comes down to who's code you are reading.
- deleted 13y ago
  [deleted]
chongli 13y ago
Maybe that just says something about my intelligence, or maybe the functional camp hasn't yet figured out how to write large programs in a readable way. Haskell programmers tend not to write large programs, period. Instead, we build lots of libraries until our problem is trivial to solve. Case in point, see the list of operators defined by the popular Lens library Not really a fair example. Lens is not a program (large or otherwise), it is a new programming language embedded within Haskell. Viewed within that context, its bevy of operators is somewhat justified. The other thing to note about it is that lens was designed specifically to avoid clashing with variable and operator names defined in other popular libraries so that users could import it unqualified.
- AnimalMuppet 13y ago
  > Haskell programmers tend not to write large programs, period. Instead, we build lots of libraries until our problem is trivial to solve. But if the libraries that you write, taken together, are large, then you are in fact writing a large program. Calling part of it "libraries" doesn't change that. (So far as I can see, that's no different than a C programmer writing lower-level functions, or an assembly language programmer writing subroutines. Everybody does that - at least, everybody sane.)
  - chongli 13y ago
    I wanted to avoid getting into a discussion about the merits of Haskell vs other languages. I was merely making a statement about what I perceive is the common practice of Haskell programmers. Do I believe that Haskell as a language provides features which allow for greater modularity, reusability, composability and generality than most other languages? Yes. However, to explain it all in great detail would take far too long. Besides that, others have already laid much of the groundwork for explaining these advantages in a much better format than I can muster here. Here's one simple example (which happens to describe the advantages of laziness): http://augustss.blogspot.ca/2011/05/more-points-for-lazy-evaluation-in.html http://augustss.blogspot.ca/2011/05/more-points-for-lazy-eva...
- dragonwriter 13y ago
nnq 13y ago
Is anyone not freaked out by Lens? Really, that "thing" is scarry... you realize you need something like `^.` from it because it can make life easier, but then you look at the whole jungle of what it really is and your mind explodes.
- freyrs3 13y ago
  (^.) is a really simple function actually, I'd argue it's even simpler than fmap. If we look at `lens-family-core` all the machinery to derive everything you need to make lenses is very concise and would fit on a index card. http://hackage.haskell.org/package/lens-family-core-1.0.0/docs/src/Lens-Family.html#line-263 http://hackage.haskell.org/package/lens-family-core-1.0.0/do...

deleted 13y ago

[deleted]

tel 13y ago

Eh, the list of operators is a weird artifact of the design of lens. The fundamental abstractions at the core are fairly simple, although they're exposed in a scary way. Most of that has to do with optimizing for reuse and proper type inference. It's a cheat to expose the Haskell subtyping relation for more leverage. A better way to understand lenses should be to consider a package like lens-family-core which keeps to its roots.

platz 13y ago
Scala had/has an issue with user-defined operators; there was a proposal that all operators should also be able to be called with an english word i.e. provide a named function. I wouldn't mind if haskell library designers took that practice to heart.
- tel 13y ago
  To that end, the lens library exposes named verbs for most of the core operators and both the verbs and operators are chosen with great discretion toward consistency... if not great discretion toward not clobbering related libraries.

dons 13y ago

Lens is one guy's pathological abstraction. It's a library, and it's idiosyncratic. It isn't want large Haskell systems "look like". Cf http://ro-che.info/articles/2014-04-24-lens-unidiomatic.html http://ro-che.info/articles/2014-04-24-lens-unidiomatic.html

cousin_it 13y ago
I agree that Lens is extreme, that's why I picked it as an example. However, most Haskell code I've seen also has line-noise problems, though not as extreme as Lens. Maybe I just haven't been lucky. Can you point to some good examples of readable Haskell code?
- deleted 13y ago
  [deleted]
- freyrs3 13y ago
  If you work with Java/C/C++ then the way you structure, compose, and think about programs is mostly entirely different from Haskell. Any of the examples I might point to as idiomatic Haskell are going to be "unreadable" ( if that words means anything ) within that worldview, because they come with an entirely different set of constraints and culture than the Java/C++ world.
  - nhaehnle 13y ago
    It would still be nice if you (or somebody else) pointed at those examples. That would open new avenues for learning and communication.
    - freyrs3 13y ago
      What kind of examples are you interested in?
  - deleted 13y ago
    [deleted]
- 13y ago

samnardoni 13y ago

> Maybe that just says something about my intelligence, or maybe the functional camp hasn't yet figured out how to write large programs in a readable way. You make it sound like we've figured out how to write imperative large programs in a readable way.

cousin_it 13y ago
Well, it's not too bad. I work at Google and spend a significant part of every workday reading other people's code, written in imperative/OO languages. That's not too difficult, if the code uses few abstractions and if you have good tools for reading it, like cross-referencing, version control history and code review history. But the "few abstractions" part is actually important, I can't imagine reading typical Haskell code at the same speed. When you're tracking down a bug or trying to implement a feature that touches several projects, you really need to read fast.
- collyw 13y ago
  It really comes down to who's code you are reading.
deleted 13y ago
[deleted]

chongli 13y ago

Maybe that just says something about my intelligence, or maybe the functional camp hasn't yet figured out how to write large programs in a readable way. Haskell programmers tend not to write large programs, period. Instead, we build lots of libraries until our problem is trivial to solve. Case in point, see the list of operators defined by the popular Lens library Not really a fair example. Lens is not a program (large or otherwise), it is a new programming language embedded within Haskell. Viewed within that context, its bevy of operators is somewhat justified. The other thing to note about it is that lens was designed specifically to avoid clashing with variable and operator names defined in other popular libraries so that users could import it unqualified.

AnimalMuppet 13y ago
> Haskell programmers tend not to write large programs, period. Instead, we build lots of libraries until our problem is trivial to solve. But if the libraries that you write, taken together, are large, then you are in fact writing a large program. Calling part of it "libraries" doesn't change that. (So far as I can see, that's no different than a C programmer writing lower-level functions, or an assembly language programmer writing subroutines. Everybody does that - at least, everybody sane.)
- chongli 13y ago
  I wanted to avoid getting into a discussion about the merits of Haskell vs other languages. I was merely making a statement about what I perceive is the common practice of Haskell programmers. Do I believe that Haskell as a language provides features which allow for greater modularity, reusability, composability and generality than most other languages? Yes. However, to explain it all in great detail would take far too long. Besides that, others have already laid much of the groundwork for explaining these advantages in a much better format than I can muster here. Here's one simple example (which happens to describe the advantages of laziness): http://augustss.blogspot.ca/2011/05/more-points-for-lazy-evaluation-in.html http://augustss.blogspot.ca/2011/05/more-points-for-lazy-eva...
dragonwriter 13y ago

nnq 13y ago

Is anyone not freaked out by Lens? Really, that "thing" is scarry... you realize you need something like `^.` from it because it can make life easier, but then you look at the whole jungle of what it really is and your mind explodes.

freyrs3 13y ago
(^.) is a really simple function actually, I'd argue it's even simpler than fmap. If we look at `lens-family-core` all the machinery to derive everything you need to make lenses is very concise and would fit on a index card. http://hackage.haskell.org/package/lens-family-core-1.0.0/docs/src/Lens-Family.html#line-263 http://hackage.haskell.org/package/lens-family-core-1.0.0/do...