Line noise

older
Trouble with FFI on Windows2000...

Andrew Coppin

21 Sep 2008 21 Sep '08

2:14 p.m.

I hang out on another forum that is populated by various kinds of computer geeks. There's a fair few programmers in there, as well as nerds of every degree. And yet, every time I post anything written in Haskell, everybody complains that it "looks like line noise". What do "normal" programmers find so puzzling about Haskell? You might guess some of the following: - High-order functions. - Lambda functions. - Algebraic data types. - Lazy evaluation. - Recursion. - Monads. Actually, none of these things were mentioned. The things people have *actually* complained to me about are: - Haskell expressions are difficult to parse. - Several standard library elements have unhelpful names such as "elem", "Eq" and "fst". (My favourite has to be "Ix". I mean, WTH?) - Several standard library functions have names which clash badly with the usual meanings of those names - e.g., "break", "return", "id". - Variable names such as "x" and "f" aren't fabulously helpful to lost programmers trying to find their way. If you take a "typical" lump of C or Java code, there's so much redundancy and noise in it that you can *usually* figure out vaguely what's going on, even if it doesn't completely make sense. When presented with a typical Haskell fragment... uh... well, good luck with that. Let's take Haskell's most celebrated example: qsort [] = [] qsort (x:xs) = qsort (filter (x <) xs) ++ [x] ++ qsort (filter (x >=) xs) To a novice, it's not actually real clear what the arguments to qsort are. You and I know that function application binds much more tightly than (++), but a novice isn't going to know that. You might also not immediately realise that "xs" is also an argument to filter, not just (x <) or whatever. The people I spoke to also seemed pretty confused about the usage of (.) and ($), even after I explained it a few times. Several people also voiced being puzzled about Haskell's layout rules. I'm not sure what we *do* with all this data, but I found it interesting so I thought I'd share. ;-) I've spent the last few years trying to convert a few people to The Haskell Way(tm), but so far I haven't succeeded in the slightest. I just get yelled at for pointing white noise. Heh. Oh well!

Show replies by date

Philippa Cowderoy

21 Sep 21 Sep

2:52 p.m.

On Sun, 21 Sep 2008, Andrew Coppin wrote:

...

Actually, none of these things were mentioned. The things people have *actually* complained to me about are: - Haskell expressions are difficult to parse.

This is partly an "it's not braces, semicolons and function(application)" complaint, though not entirely.

...

- Several standard library elements have unhelpful names such as "elem", "Eq" and "fst". (My favourite has to be "Ix". I mean, WTH?)

...

- Several standard library functions have names which clash badly with the usual meanings of those names - e.g., "break", "return", "id".

For this one, I'm inclined to say "welcome to a new paradigm". Though having to tell my dad briefly that do isn't a loop construct was odd for a moment.

...

- Variable names such as "x" and "f" aren't fabulously helpful to lost programmers trying to find their way.

So don't use them? Though I think f in particular has its place in higher order functions.

...

The people I spoke to also seemed pretty confused about the usage of (.) and ($), even after I explained it a few times. Several people also voiced being puzzled about Haskell's layout rules.

Pointless style is definitely newbie-unfriendly. I can understand being puzzled by layout: ultimately I had to go read the description in the Report to be happy.

...

I'm not sure what we *do* with all this data, but I found it interesting so I thought I'd share. ;-) I've spent the last few years trying to convert a few people to The Haskell Way(tm), but so far I haven't succeeded in the slightest. I just get yelled at for pointing white noise. Heh. Oh well!

Have you tried showing people code that's been syntax highlighted? It's likely to help, especially with things like "does function application bind tighter?" where the highlighting is something of a cue. So is marking out = as important! Btw, (> x) reads much more easily as a predicate to most people than (x <=). -- flippa@flippac.org Sometimes you gotta fight fire with fire. Most of the time you just get burnt worse though.

Andrew Coppin

3:10 p.m.

Philippa Cowderoy wrote:

...

On Sun, 21 Sep 2008, Andrew Coppin wrote:

...
Actually, none of these things were mentioned. The things people have *actually* complained to me about are: - Haskell expressions are difficult to parse.

This is partly an "it's not braces, semicolons and function(application)" complaint, though not entirely.

One person complained that "case compare guess target of" was unclear. Of course, you and I know that "case" and "of" are actually language keywords, and hence this is really "case (compare guess target) of", which makes far more sense. (Your suggestion about syntax hilighting is relevant here!)

...

...
- Several standard library functions have names which clash badly with the usual meanings of those names - e.g., "break", "return", "id".

For this one, I'm inclined to say "welcome to a new paradigm". Though having to tell my dad briefly that do isn't a loop construct was odd for a moment.

Haha! Nice... I think "return" is a rather bad choice of name. But on the other hand, I can't think of a better one. And let's face it, anything has to be better than (>>=). (Most cryptic name ever?)

...

...
- Variable names such as "x" and "f" aren't fabulously helpful to lost programmers trying to find their way.

So don't use them? Though I think f in particular has its place in higher order functions.

Idiomatic Haskell seems to consist *only* of single-letter variable names. When did you last see a pattern like (customer:customers)? No, it'd be (c:cs), which isn't very self-documenting. Ditto for type variables by the way. (Map k v, anyone?) It also seems to be Haskell convention to use "a" as a type variable; personally I always use "x". I guess that's the algebra in my blood or something...

...

...
The people I spoke to also seemed pretty confused about the usage of (.) and ($), even after I explained it a few times. Several people also voiced being puzzled about Haskell's layout rules

Pointless style is definitely newbie-unfriendly. I can understand being puzzled by layout: ultimately I had to go read the description in the Report to be happy.

I posted a snippet of code which included the phrase mapM_ (\(n,v) -> putStrLn $ "[" ++ show n ++ "] = " ++ show v) (zip [0..] vs) To somebody familiar with Haskell, that is as clear as day. But to a newbie... well *you* try explaining that you start at the left end, take the thing in brackets, process it from left to right, then take the other thing in brackets, process the right side of it, then pass that to putStrLn, oh, but that thing right at the left edge is the argument list, and then pass the whole lot to mapM_, which is... are you still with me?? As one experienced C++ programmer put it, "there is no clear flow from left to right or right to left". Personally I found that a little ironic comming from the language that gave us while (*x++ = *y++) { } which is every bit as non-linear! ;-)

...

Have you tried showing people code that's been syntax highlighted? It's likely to help, especially with things like "does function application bind tighter?" where the highlighting is something of a cue. So is marking out = as important!

I'd just like to mention that HPaste is invaluable here! ;-) Oddly, nobody seemed to take much notice when I did this though. (I guess most people had seen "oh look, another Haskell thread" and hit the thread-kill button by that point...)

...

Btw, (> x) reads much more easily as a predicate to most people than (x <=).

Er, yeah, you're probably right. IIRC, (> x) is actually implemented as (flip (>) x), whereas (x <) isn't. I doubt there's any efficiency difference though. (Surely GHC would inline such a trivial function...)

Claus Reinke

4:04 p.m.

...

I posted a snippet of code which included the phrase

mapM_ (\(n,v) -> putStrLn $ "[" ++ show n ++ "] = " ++ show v) (zip [0..] vs)

"Don't do that, then"?-) mapM_ putStrLn $ map (\(n,v) -> "[" ++ show n ++ "] = " ++ show v) (zip [0..] vs) -> mapM_ putStrLn $ map (\(n,v) -> "[" ++ show n ++ "] = " ++ show v) (addIndices vs) where addIndices vs = zip [0..] vs -> mapM_ putStrLn (map formatPair (addIndices vs)) where { addIndices vs = zip [0..] vs; formatPair (n,v) = "[" ++ show n ++ "] = " ++ show v } -> ... printList (map formatPair (addIndices vs)) where { foreach :: [i] -> (i->IO ()) -> IO (); foreach list action = mapM_ action list; printList :: [String] -> IO (); printList strings = foreach strings (\string->putStrLn string); addIndices :: [x] -> [(Integer,x)]; addIndices vs = zip [0..] vs; formatPair :: Show x => (Integer,x) -> String formatPair (n,v) = "[" ++ show n ++ "] = " ++ show v } Add comments (or replace types with comments, if you don't want to explain type classes), perhaps use an explicit loop instead of mapM_, add salt and pepper (or some more parens), check for correctness, etc. Not as cute as the one-liner, but quite possibly easier to read and explain. Haskell isn't APL - boldly break the line barrier, if you want to be understood by non-Haskellers. Breaking stuff up into digestible pieces, and going more slowly than necessary, might also help. Once your readers understand your code, you can add the one-liner and ask for applause (or show how to derive the one-liner from the long-hand version if you want to motivate people to read about Haskell). Just another opinion, Claus "Dr., it hurts when I do that."

david48

22 Sep 22 Sep

11:36 a.m.

On Sun, Sep 21, 2008 at 10:04 PM, Claus Reinke wrote:

...

Once your readers understand your code, you can add the one-liner and ask for applause

This should make it HWN's quotes of the week !

Mads Lindstrøm

21 Sep 21 Sep

4:30 p.m.

Andrew Coppin wrote:

...

Idiomatic Haskell seems to consist *only* of single-letter variable names. When did you last see a pattern like (customer:customers)? No, it'd be (c:cs), which isn't very self-documenting. Ditto for type variables by the way. (Map k v, anyone?) It also seems to be Haskell convention to use "a" as a type variable; personally I always use "x". I guess that's the algebra in my blood or something...

The more abstract (generic) thing gets, the less likely you will be able to find a telling name. And if you cannot find a telling name, you can just as well make it short. And as Haskell is more abstract, we get more short identifiers. E.g. in your earlier sorting function: qsort (x:xs) = ... what would you propose to call the elements? Yes, if it sorted customers, you call 'em (customer:customers). But you have made a very abstract sorting function, which sorts a lot besides customers. And then you are bound to end up with a non-telling name. However, I will grant you that Map k v, could have used longer type variables. But we are not alone with using one letter type variable names http://java.sun.com/javase/6/docs/api/java/util/HashMap.html . And frankly, in this specific case, I think most programmers (Haskell or non-Haskell) will be able to guess what k and v means, when they are standing right after Map. Greetings, Mads

Andrew Coppin

22 Sep 22 Sep

2:32 a.m.

Mads Lindstrøm wrote:

...

Andrew Coppin wrote:

...
Idiomatic Haskell seems to consist *only* of single-letter variable names.

The more abstract (generic) thing gets, the less likely you will be able to find a telling name. And if you cannot find a telling name, you can just as well make it short. And as Haskell is more abstract, we get more short identifiers. E.g. in your earlier sorting function:

qsort (x:xs) = ...

what would you propose to call the elements?

Well, qsort (element : list) would be maximally intuitive, but who's going to implement it like that? ;-) Now of course in C, you'd be forced to write something like list qsort(int x, list xs) which makes it completely unambiguous what these things are - what their type is. But in Haskell, even if you add a type signature: qsort:: (Ord x) => [x] -> [x] Nobody is going to realise that "[x]" means a list. And it's still not clear where ":" comes from, or... well you can see why people are getting lost! ;-)

...

However, I will grant you that Map k v, could have used longer type variables. But we are not alone with using one letter type variable names http://java.sun.com/javase/6/docs/api/java/util/HashMap.html . And frankly, in this specific case, I think most programmers (Haskell or non-Haskell) will be able to guess what k and v means, when they are standing right after Map.

Only if you can figure out that "Map" means what every other programming language on the face of the Earth calls a "dictionary". (This took me a while!)

Ketil Malde

6:46 a.m.

Andrew Coppin writes:

...

...
...
Idiomatic Haskell seems to consist *only* of single-letter variable names.

Good thing, too.

...

Well, qsort (element : list) would be maximally intuitive, but who's going to implement it like that? ;-)

Why not listElement : restOfList ? The rationale for having long names is that you have too many names, and too large a scope to keep track of them all in your head. Needing long names is a symptom that your code is too complex, and that you should refactor it. The other problem with "descriptive" names is that it is not automatically checked by the compiler, and thus it often ends up being misleading. Incorrect documentation is worse than no documentation.

...

qsort:: (Ord x) => [x] -> [x]

Nobody is going to realise that "[x]" means a list.

And C is utterly incomprehensible, since from my Pascal background, I just *know* that curly braces denote comments. Come on, expecting somebody to understand a language without an extremely basic understanding of fundamental syntactical constructs is futile.

...

well you can see why people are getting lost! ;-)

Yes, by refusing to adapt to any syntax but the single one they know.

...

Only if you can figure out that "Map" means what every other programming language on the face of the Earth calls a "dictionary". (This took me a while!)

Except for where it is called an "associative array" or "hash table"? Terminology is inconsistent, Haskell happens to draw more of it from math than from other programming languages. -k -- If I haven't seen further, it is by standing in the footprints of giants

Andrew Coppin

4:53 p.m.

Ketil Malde wrote:

...

The rationale for having long names is that you have too many names, and too large a scope to keep track of them all in your head. Needing long names is a symptom that your code is too complex, and that you should refactor it.

Well, yeah. In Haskell, functions tend to be rather shorter than in procedural languages, so there's less call for dissambiguation because there are fewer variables in scope.

...

The other problem with "descriptive" names is that it is not automatically checked by the compiler, and thus it often ends up being misleading. Incorrect documentation is worse than no documentation.

That's true enough.

...

...
Nobody is going to realise that "[x]" means a list.

And C is utterly incomprehensible, since from my Pascal background, I just *know* that curly braces denote comments. Come on, expecting somebody to understand a language without an extremely basic understanding of fundamental syntactical constructs is futile.

Point taken. I still think "List x" would have been clearer, but nobody is going to change the Haskell Report now...

...

...
well you can see why people are getting lost! ;-)

Yes, by refusing to adapt to any syntax but the single one they know.

Some people will glance at Haskell and think "hey, that doesn't look like source code, I can't read that". But given the number of times I've explained all this stuff, you'd think one or two people would have got it by now...

...

...
Only if you can figure out that "Map" means what every other programming language on the face of the Earth calls a "dictionary". (This took me a while!)

Except for where it is called an "associative array" or "hash table"? Terminology is inconsistent, Haskell happens to draw more of it from math than from other programming languages.

Heh, let's not argue over technical terms... ;-) Most people seem far more confused by what a "fold" might be.

Jake Mcarthur

5:52 p.m.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

...

Most people seem far more confused by what a "fold" might be.

A fold by any other name would smell as sweet. ;) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjYE7kACgkQTkPEVFd3yxh7HwCfVzopoOCgg49YI0Y88g9rjXqI DvcAn3Buv4FmqcYrK5pDLr1iUc7XRpO5 =CKiH -----END PGP SIGNATURE-----

Daniel Fischer

8:50 a.m.

Am Montag, 22. September 2008 08:32 schrieb Andrew Coppin:

...

...
However, I will grant you that Map k v, could have used longer type variables. But we are not alone with using one letter type variable names http://java.sun.com/javase/6/docs/api/java/util/HashMap.html . And frankly, in this specific case, I think most programmers (Haskell or non-Haskell) will be able to guess what k and v means, when they are standing right after Map.

Only if you can figure out that "Map" means what every other programming language on the face of the Earth calls a "dictionary". (This took me a while!)

So, when did Java leave the face of the earth? Seriously, I find Map a far clearer term than dictionary and would've had problems grokking the latter. I guess you've just been exposed to the wrong languages for too long.

Sebastian Sylvan

12:53 p.m.

On Mon, Sep 22, 2008 at 1:50 PM, Daniel Fischer wrote:

...

Am Montag, 22. September 2008 08:32 schrieb Andrew Coppin:

...
...
However, I will grant you that Map k v, could have used longer type variables. But we are not alone with using one letter type variable names http://java.sun.com/javase/6/docs/api/java/util/HashMap.html . And frankly, in this specific case, I think most programmers (Haskell or non-Haskell) will be able to guess what k and v means, when they are standing right after Map.

Only if you can figure out that "Map" means what every other programming language on the face of the Earth calls a "dictionary". (This took me a while!)

So, when did Java leave the face of the earth?

At the same time as C++ presumably. I hadn't really noticed, but I'll be the first to say: Good riddance! -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862

Achim Schneider

24 Sep 24 Sep

1:50 p.m.

Mads Lindstrøm wrote:

...

qsort (x:xs) = ...

what would you propose to call the elements?

(car:cdar:cddar:cdddr) no discussion. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or broadcasting of this signature prohibited.

donn cave

22 Sep 22 Sep

1:05 a.m.

Quoth Andrew Coppin : ... | As one experienced C++ programmer put it, "there is no clear flow from | left to right or right to left". Personally I found that a little ironic | comming from the language that gave us | | while (*x++ = *y++) { } | | which is every bit as non-linear! ;-) Well, to be precise, C++ got that from C. What C++ adds to it: fy(a.fx(b), c) (in Haskell, fy (fx a b) c) I wouldn't worry too much about one letter identifiers and so forth. Many programmers will secretly be rather attracted to this kind of thing. Donn Cave, donn@avvanta.com

Achim Schneider

24 Sep 24 Sep

2:06 p.m.

"donn cave" wrote:

...

Quoth Andrew Coppin : ... | As one experienced C++ programmer put it, "there is no clear flow from | left to right or right to left". Personally I found that a little ironic | comming from the language that gave us | | while (*x++ = *y++) { } | | which is every bit as non-linear! ;-)

Well, to be precise, C++ got that from C. What C++ adds to it:

fy(a.fx(b), c) (in Haskell, fy (fx a b) c)

fy( a->fx( a, b ), c )? Typeclasses are something to advertise, and C++ didn't at all enrich C with OO. It polluted it with an extremely badly designed macro system. That is, I'd rather dig through ten layers of wizardly monad- transforming abstraction than even consider to look at a thousand lines of console buffer displaying the last ten percent of a type error involving more < and > than you need in a lifetime. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or broadcasting of this signature prohibited.

Luke Palmer

22 Sep 22 Sep

3 p.m.

On Sun, Sep 21, 2008 at 1:10 PM, Andrew Coppin wrote:

...

I posted a snippet of code which included the phrase

mapM_ (\(n,v) -> putStrLn $ "[" ++ show n ++ "] = " ++ show v) (zip [0..] vs)

To somebody familiar with Haskell, that is as clear as day. But to a newbie... well *you* try explaining that you start at the left end, take the thing in brackets, process it from left to right, then take the other thing in brackets, process the right side of it, then pass that to putStrLn, oh, but that thing right at the left edge is the argument list, and then pass the whole lot to mapM_, which is... are you still with me??

As one experienced C++ programmer put it, "there is no clear flow from left to right or right to left".

This is actually one of the two main metrics I use when I'm writing code -- I try to keep the information content in my code local, so you don't have to scan across the screen to see what n corresponds to. This is equivalent to maintaining a left-to-right or right-to-left flow (and really which direction it is depends more on reading style than writing style). The other one I picked up from Perl of all places, and that is end weight. In English we tend to put the important parts (the "essence") of the sentence at the front, and leave the details for the end. So I like to emulate that in Haskell when I can. There is little I loathe more than the style: map (\x -> ... ... ... ... ...) xs As such, the probability that I would have written the mapM_ line above is very low, since it violates both of these. In this case, switching to forM_ brings it much closer to my style: forM_ (zip [0..] vs) $ \(n,v) -> putStrLn $ "[" ++ show n ++ "] = " ++ show v That is because the details of this sentence are in the function, so I put it at the end. Also the corresponding [0..] and n are close together, as are the corresponding vs and v. Luke

Bulat Ziganshin

3:12 p.m.

New subject: Re[2]: Line noise

Hello Luke, Monday, September 22, 2008, 11:00:12 PM, you wrote:

...

...
mapM_ (\(n,v) -> putStrLn $ "[" ++ show n ++ "] = " ++ show v) (zip [0..] vs)

...

forM_ (zip [0..] vs) $ \(n,v) -> putStrLn $ "[" ++ show n ++ "] = " ++ show v

for (zip [0..] vs) $ \(n,v) -> do putStrLn $ "[" ++ show n ++ "] = " ++ show v ... it's rather close to C/Pascal/... loops although it will be great to have more sugar here -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Brandon S. Allbery KF8NH

24 Sep 24 Sep

12:46 a.m.

On 2008 Sep 21, at 15:10, Andrew Coppin wrote:

...

Philippa Cowderoy wrote:

...
On Sun, 21 Sep 2008, Andrew Coppin wrote:

...
- Several standard library functions have names which clash badly with the usual meanings of those names - e.g., "break", "return", "id".

For this one, I'm inclined to say "welcome to a new paradigm". Though having to tell my dad briefly that do isn't a loop construct was odd for a moment.

I think "return" is a rather bad choice of name. But on the other hand, I can't think of a better one. And let's face it, anything has to be better than (>>=). (Most cryptic name ever?)

Applicative and Arrow have the replacement for "return" right: "pure". No argumnt about (>>=), but on the other hand I remember (>>=) but never remember the arrow or Applicative operators.

...

Idiomatic Haskell seems to consist *only* of single-letter variable names. When did you last see a pattern like (customer:customers)? No, it'd be (c:cs), which isn't very self-

I tend to use something like cust:custs; I prefer to be able to read it. If the code is generic then I'll use generic names --- which alerts me to its genericness. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

Albert Y. C. Lai

21 Sep 21 Sep

5:19 p.m.

I read from many reviews and shootouts that cell phones sold in Japan are more diverse, advanced, and user-friendly than cell phones sold in the US. So I bought one, but to my dismay, both the offline manual and the on-screen menu are line noise. Then I found a web dictionary to translate them word-for-word. The result is still unparsible, like "water submerge in don't ever". Are we supposed to be human beings or are we supposed to be all Master Yoda's? Why and how the whole Japanese population put up with this epic fail is beyond me. Everyone should use exclusively ancient Egyptian iconography. It is the only universally readable language.

wren ng thornton

10:49 p.m.

Andrew Coppin wrote:

...

I hang out on another forum that is populated by various kinds of computer geeks. There's a fair few programmers in there, as well as nerds of every degree. And yet, every time I post anything written in Haskell, everybody complains that it "looks like line noise".

Actually, none of these things were mentioned. The things people have *actually* complained to me about are: - Haskell expressions are difficult to parse.

To anyone who doesn't know the language, this seems quite true. Haskell was designed with a hyper-minimalist syntax, whereas C/C++/Java are very heavy with syntactic boilerplate. I am a devout fan of the minimalism, but it is something of a barrier to entry for those unwilling to consider anything that doesn't look familiar. We inherited our use of spaces for function application from Lisp and friends, so "foo bar baz" looks perfectly natural to functionalists. But to those used to seeing "foo(bar, baz)" the meaning attached to the spaces is alien. The 'difference' in meaning for the two spaces only drives the alienness home, since (ubiquitous) currying is not well known or practiced outside of Haskell. Even with functionalists ---of the OCaml and SML ilk--- this use of spaces can be confusing if noone explains that function application binds tighter than all operators. Similarly, we use linebreaks to denote various things whereas the syntax-heavy languages require a semicolon or similar delimiter. We are in fortuitous arms here since we can use the redundant {;} notation to sell new folks. Though it is wise to use the notation with the semicolon trailing on the previous line: do { foo; bar; baz; } rather than the more idiomatic leading version: do { foo ; bar ; baz } Again, the minimalist version that omits the {;} which lends a meaning to whitespace that syntax-heavy users are not familiar with. Here I think is largely a question of knowing your audience; the explicit version is better for any audience with many non-Haskell folks, even if it's a functional audience. We also allow for omitting parentheses in many places required by other languages. In particular, the case...of construct mentioned previously. The if...then...else construct can have similar problems, though they are more easily overlooked by foreigners. Again this is easy to correct for when talking with outsiders: just add redundant parentheses. The meaning of = and how it differs from -> are also quite subtle. Pattern matching and guards, like currying, are concepts that are quite alien to users of most other languages. The simplicity of their syntax in Haskell probably serves to further confuse questions of the syntax associated with =. I know from experience that these simple ideas can be a tough sale. Few languages have the notion that defining a function is the same as any other 'assignment' and so most languages have radically different syntaxes for the two. This trait of treating functions as first-class citizens tends to have large brain-breaking capabilities-- moreso than passing functions as arguments, it seems. All of these are just basic things about Haskell's syntax and have nothing to do with all the interesting higher-order stuff which is really novel. It is unfortunate that there are so many people, intelligent people even, who are so hidebound as to be unwilling to gloss over syntax, but sadly it is the way of things. To be fair to them, the meanings assigned to whitespaces are not the sort of thing which is trivial to intuit. Perhaps we need a _Guide to Reading Haskell (for non-Haskell Programmers)_? -- Live well, ~wren

Dan Piponi

11 p.m.

On Sun, Sep 21, 2008 at 7:49 PM, wren ng thornton wrote:

...

We inherited our use of spaces for function application from Lisp and friends, so "foo bar baz" looks perfectly natural to functionalists. But to those used to seeing "foo(bar, baz)" the meaning attached to the spaces is alien.

I have to admit, it took me a long time to be able to parse the ML-style function notation in Haskell. I found it the biggest "barrier to entry". I suspect that most of the complaints about line noise stem from this - to beginners Haskell expressions just look like sequences of identifiers with no apparent grammar to "bind" them together. -- Dan

Andrew Coppin

22 Sep 22 Sep

2:27 a.m.

Dan Piponi wrote:

...

I suspect that most of the complaints about line noise stem from this - to beginners Haskell expressions just look like sequences of identifiers with no apparent grammar to "bind" them together.

This was the exact complaint that some people voiced, yes. (The (.) and ($) operators just compound the problem.) Somebody else then came to my rescue and pointed out that "everybody says Lisp is unreadable because it has too many brackets - despite the fact that those brackets theoretically make parsing utterly trivial". ;-)

Brian Hurt

9:27 p.m.

On Sun, 21 Sep 2008, wren ng thornton wrote:

...

Even with functionalists ---of the OCaml and SML ilk--- this use of spaces can be confusing if noone explains that function application binds tighter than all operators.

Bwuh? Ocaml programmers certainly know that application binds tighter than operators. And as: let f x y = ... in f a b is more efficient (in Ocaml) than: let f (x, y) = ... in f (a, b) (Ocaml doesn't optimize away the tuple allocation), the former (Haskell-like) is generally preferred by Ocaml programmers. SML programmers do use the second form, I'll grant you. Brian

Jason Dagit

9:24 p.m.

On Mon, Sep 22, 2008 at 6:27 PM, Brian Hurt wrote:

...

On Sun, 21 Sep 2008, wren ng thornton wrote:

...
Even with functionalists ---of the OCaml and SML ilk--- this use of spaces can be confusing if noone explains that function application binds tighter than all operators.

Bwuh? Ocaml programmers certainly know that application binds tighter than operators. And as:

let f x y = ... in f a b

is more efficient (in Ocaml) than:

let f (x, y) = ... in f (a, b)

(Ocaml doesn't optimize away the tuple allocation), the former (Haskell-like) is generally preferred by Ocaml programmers.

That's odd. My experience from trying to learn ocaml at one point was that the tuple notation is preferable because you can do pattern matching on every value in the tuple whereas with the other one you can match on either the first or second parameter but not both without nesting ocaml's version of 'case ... of' (match ... with?). One of the things I really like about Haskell syntax is that you can pattern match on any number of parameters without having to nest 'case ... of' expressions. Jason

wren ng thornton

23 Sep 23 Sep

10:37 p.m.

Brian Hurt wrote:

...

On Sun, 21 Sep 2008, wren ng thornton wrote:

...
Even with functionalists ---of the OCaml and SML ilk--- this use of spaces can be confusing if noone explains that function application binds tighter than all operators.

Bwuh? Ocaml programmers certainly know that application binds tighter than operators. And as:

Not being of either ilk, perhaps I mis-relayed the confusions of a friend recently converted to Haskell :) The issue I was raising had not so much to do with un/currying of functions but rather whether something like "foo bar %^& baz" means "(foo bar) %^& baz" or "foo (bar %^& baz)". I believe this was voiced as an SML issue more than an OCaml issue, though honestly I don't know enough of the differences to distinguish them. Before I mentioned that function/prefix application always binds tighter than operator/infix application, he was using many redundant parentheses, thanks to defensive programming against whichever dialect was at fault. -- Live well, ~wren

Stefan Monnier

24 Sep 24 Sep

12:06 p.m.

...

I believe this was voiced as an SML issue more than an OCaml issue, though honestly I don't know enough of the differences to distinguish them. Before I mentioned that function/prefix application always binds tighter than operator/infix application, he was using many redundant parentheses, thanks to defensive programming against whichever dialect was at fault.

It was apparently a programmer issue rather than a language issue: SML's precedence rules are pretty much identical to Haskell's in this regard. Stefan

Jon Harrop

21 Dec 21 Dec

3:54 a.m.

On Tuesday 23 September 2008 02:27:17 Brian Hurt wrote:

...

On Sun, 21 Sep 2008, wren ng thornton wrote:

...
Even with functionalists ---of the OCaml and SML ilk--- this use of spaces can be confusing if noone explains that function application binds tighter than all operators.

Bwuh? Ocaml programmers certainly know that application binds tighter than operators. And as:

let f x y = ... in f a b

is more efficient (in Ocaml) than:

let f (x, y) = ... in f (a, b)

(Ocaml doesn't optimize away the tuple allocation)...

That is incorrect. OCaml does optimize away that tuple: both forms compile to the same 2-argument function. OCaml does not optimize away this tuple: let a, b = 1, 2 So, when efficiency is important, you write: let a = 1 and b = 2 -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e

Stephan Friedrichs

22 Sep 22 Sep

4:46 a.m.

Andrew Coppin wrote:

...

[...] - Variable names such as "x" and "f" aren't fabulously helpful to lost programmers trying to find their way.

I'm not a fan of cryptic variable names, either, and I try to use descriptive names wherever I can. But in Haskell... - ... you often have variables, which have a scope of far less than a line such as in "map (\(x, (_, y)) -> (x, y) ..." (cleaning intermediate results from a list). - ... things often get very abstract, so that it just feels wrong matching on, say, (socket:sockets) instead of (x:xs).

...

[...]

//Stephan -- Früher hieß es ja: Ich denke, also bin ich. Heute weiß man: Es geht auch so. - Dieter Nuhr

Andrew Coppin

4:50 p.m.

Stephan Friedrichs wrote:

...

Andrew Coppin wrote:

...
[...] - Variable names such as "x" and "f" aren't fabulously helpful to lost programmers trying to find their way.

I'm not a fan of cryptic variable names, either, and I try to use descriptive names wherever I can. But in Haskell...

- ... you often have variables, which have a scope of far less than a line such as in "map (\(x, (_, y)) -> (x, y) ..." (cleaning intermediate results from a list).

- ... things often get very abstract, so that it just feels wrong matching on, say, (socket:sockets) instead of (x:xs).

...so, more or less the reason why mathematical formulas usually end up with non-descriptive variable names then. ;-)

Mauricio

9:07 a.m.

...

I hang out on another forum that is populated by various kinds of computer geeks. There's a fair few programmers in there, as well as nerds of every degree. And yet, every time I post anything written in Haskell, everybody complains that it "looks like line noise". (...)

I have to say we haskellers are guilt of that too. Many messages in this list says C looks line noise. There are many arguments we can use to say Haskell is better than other languages. The only one I take seriously is: it fits our way of thinking. Other people like to think in other ways. I'm an engineer, and the only way I can deal with engineering is through abstract math. Many engineers better than me refuse to use math at all. I see so many people advocating Haskell and functional programming. I would like to sugest: why don't we advocate against "monocultures"? An environment where anyone can use whatever language they like is so easy to get this days, and would have far better results. IMHO. Best, Maurício

Stefan Monnier

24 Sep 24 Sep

12:04 p.m.

...

qsort [] = [] qsort (x:xs) = qsort (filter (x <) xs) ++ [x] ++ qsort (filter (x >=) xs)

Note that you can help the reader by making the precedence a bit more obvious: qsort [] = [] qsort (x:xs) = qsort (filter (x <) xs) ++ [x] ++ qsort (filter (x >=) xs) I find that my students can understand this much better than the 1½ liner. Regarding the mapM_ example:

...

mapM_ (\(n,v) -> putStrLn $ "[" ++ show n ++ "] = " ++ show v) (zip [0..] vs)

To somebody familiar with Haskell, that is as clear as day.

I guess I'm not familiar with Haskell, because I find the paren-counting to be difficult to do in my head (and god knows that I'm familiar with parenthese). Also, I tend to shy away from ($) and (.) and to only use them when I have a list of functions to compose/apply and want to avoid growing the depth of my AST with the length of the list. So I'd probably write the mapM_ example as: mapM_ (\(n,v) -> putStrLn ("[" ++ show n ++ "] = " ++ show v)) (zip [0..] vs) which I find a lot easier to read. Stefan

5995

Age (days ago)

6086

Last active (days ago)

List overview

Download

30 comments

23 participants

participants (23)

Achim Schneider
Albert Y. C. Lai
Andrew Coppin
Brandon S. Allbery KF8NH
Brian Hurt
Bulat Ziganshin
Claus Reinke
Dan Piponi
Daniel Fischer
david48
donn cave
Jake Mcarthur
Jason Dagit
Jon Harrop
Ketil Malde
Luke Palmer
Mads Lindstrøm
Mauricio
Philippa Cowderoy
Sebastian Sylvan
Stefan Monnier
Stephan Friedrichs
wren ng thornton

Line noise

Andrew Coppin

Andrew Coppin

Mads Lindstrøm

Andrew Coppin

Andrew Coppin

Achim Schneider

Achim Schneider

Bulat Ziganshin

wren ng thornton

Dan Piponi

Andrew Coppin

wren ng thornton

Jon Harrop

Stephan Friedrichs

Andrew Coppin

tags

participants (23)