Re: [Haskell-cafe] Line noise
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Line noise
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Line noise
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] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Line noise
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. ;-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Line noise
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!) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Line noise
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Line noise
Andrew Coppin [EMAIL PROTECTED] 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Line noise
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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Line noise
On Sun, Sep 21, 2008 at 10:04 PM, Claus Reinke [EMAIL PROTECTED] 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 ! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Line noise
On Mon, Sep 22, 2008 at 1:50 PM, Daniel Fischer [EMAIL PROTECTED]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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Line noise
On Sun, Sep 21, 2008 at 1:10 PM, Andrew Coppin [EMAIL PROTECTED] 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Line noise
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. ;-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Line noise
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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Line noise
-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- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Line noise
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Line noise
On Mon, Sep 22, 2008 at 6:27 PM, Brian Hurt [EMAIL PROTECTED] 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Line noise
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 =). -- [EMAIL PROTECTED] Sometimes you gotta fight fire with fire. Most of the time you just get burnt worse though. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Line noise
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...)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Line noise
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.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Line noise
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Line noise
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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Line noise
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
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Line noise
On Sun, Sep 21, 2008 at 7:49 PM, wren ng thornton [EMAIL PROTECTED] 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Line noise
Quoth Andrew Coppin [EMAIL PROTECTED]:
...
| 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, [EMAIL PROTECTED]
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
