tag:blogger.com,1999:blog-6655746112052720933.post6937605973616191755..comments2022-03-30T18:43:33.525-05:00Comments on Notes on Haskell: Does Syntax Matter?Adam Turoffhttp://www.blogger.com/profile/11941071792943377879noreply@blogger.comBlogger11125tag:blogger.com,1999:blog-6655746112052720933.post-51756339018674443332007-12-26T09:58:00.000-05:002007-12-26T09:58:00.000-05:00Slightly aside from the main point;3:[M]onads enfo...Slightly aside from the main point;<BR/><BR/><I>3:[M]onads enforce an order of execution on their statements. ... With monadic functions, the order of execution is very important.</I><BR/><BR/>Actually, this isn't true about monads in general. But it is a side effect of what you think you see...with most monads you use, there is an order of execution enforced on their statements - but this comes through data dependence - Failure (Maybe/Either), State transformation, IO etc all use data dependence to ensure the ordering. <BR/><BR/>However this isn't something fundamental about monads. The (lazy) Reader and (->)) monad (and maybe Cont) don't enforce any orderings on their statements other than by what is forced as per normal haskell.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6655746112052720933.post-53354729808970409722007-08-30T19:57:00.000-05:002007-08-30T19:57:00.000-05:00Complaining about haskell's expressive operator ov...Complaining about haskell's expressive operator overloading model, sounds like you're from a Java background or mindset.<BR/><BR/>The whole point of haskell's flexiablity of operator overloading is for aiding in the development of <B><I>Domain Specific Embedded Languages</I></B> (DSELs), getting as close to the ideal abstraction as you could possible get without the need of a macro syntax extension systems.<BR/><BR/>You should try to understand the significance of this.<BR/><BR/>Modern C++ generic libraries try there best to achieve this but C++'s operator overloading model is limited and rigid. Do you understand it's an absolute pain thus library authors have to resort to discusting hackery to achieve what haskell does elegantly and effortlessly.<BR/><BR/>So basically you asking the haskell community to "discourage" the writing of DSELs that makes a lot of sense...<BR/><BR/>About memorizing associativity & precedence your point is moot for a number of reasons.<BR/><BR/>Lets start with the obvious reason, if somebody really can't remember or doesn't know the associativity and/or precedence of a particular operator overload they can look at the <I>type signature</I> of that operator/function, there are various ways of getting the type signature even when none are explicitly provided/defined (haskell is type inferred language).<BR/><BR/>DSELs are typically used by people who have domain knowledge or even are domain expects in that field/subject and hence will instantly recognize what the symbol means and what it's associativity & precedence is/should be.<BR/><BR/>Furthermore if there are no such direct mappings with the problem domain, symbols/operators and there associativity & precedence are choosen with common sense and intuition applied.<BR/><BR/>No one is silly enough to overload an operator typically left-associative with right associativity if they can avoid it, that wouldn't very intuitive would it.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6655746112052720933.post-83063509837193398832007-08-29T02:02:00.000-05:002007-08-29T02:02:00.000-05:00I agree with the anon above. Operator overloading ...I agree with the anon above. Operator overloading is nice, but it should be used with extreme hesitation. Operators are harder to read because they both obscure function name and order of operation (off the top of your head, what is the precedence of +++?)<BR/><BR/>I also have issues with people spelling out lists like<BR/>[ 1<BR/>, 2<BR/>, 3 ].<BR/><BR/>It just looks gross! (I do mostly Python btw, can you tell?) <BR/><BR/>I think Haskell could use a well thought-out style guide in the near future.Tac-Ticshttps://www.blogger.com/profile/14070765709653635739noreply@blogger.comtag:blogger.com,1999:blog-6655746112052720933.post-38884695756755177322007-08-21T05:20:00.000-05:002007-08-21T05:20:00.000-05:00I agree with everything you say about syntax and i...I agree with everything you say about syntax and it's importance to a language. Yet, I still think you're wrong when it comes to the adoption of a new language. As you say C, Java and Javascript are three very different languages and just because their syntax is similar doesn't mean that programming in them is the same. But the point is *Joe Programmer doesn't understand this*. When he sees C like syntax he think "Oh, I know that". There are many programmers who don't think further than the level of syntax, even I was at that level once. Hence when they see Haskell they think "Weird". That is the importance of syntax. I'm sad to say.<BR/><BR/>Of course there are also quite a few programmers who understand the difference between syntax and semantics and these are typically the good programmers. Hopefully they can help educate those who understand less.Josefhttps://www.blogger.com/profile/13272830598221833253noreply@blogger.comtag:blogger.com,1999:blog-6655746112052720933.post-20203705634293372232007-08-17T19:37:00.000-05:002007-08-17T19:37:00.000-05:00Personally, while I love its semantics, I do have ...Personally, while I love its semantics, I do have some deeper issues with Haskell's syntax other than the trivial "oh but it doesn't look like C" kind.<BR/><BR/>Part of it's syntax, but part of it is the common usage patterns encouraged by the syntax:<BR/><BR/>* Firstly, the ability to create custom operators with custom precendences can make haskell code quite daunting to read.<BR/><BR/>Increasingly haskell code I see turns to creating its own three-or-four-ascii-symbol-long operators - which are frankly horrible, cryptic and ugly to read.<BR/>>>>, <<<, .==., -->, <<-, etc. Line noise!<BR/><BR/>One's then often required to remember their associativity and precedence when mentally parsing the code - which again is hard.<BR/><BR/>It makes haskell look like poorly-typeset and cryptic mathematical expressions, rather than program code.<BR/><BR/>I totally recognise that this is a matter of coding style - but I feel haskell's syntax encourages it and the haskell community does too little to discourage this kind of use.<BR/><BR/>* The tendency towards a plethora of short, cryptic variable names, and to some extend function names too.<BR/><BR/>Again a matter of coding style, but again something I feel is encouraged by haskell's syntax and where too little is done by the community to discourage it.<BR/><BR/>* The fact that, in most other languages, common ascii symbols are reserved for "punctuation" style use to clarify the structure of the program in a helpful and standard way. Especially the structure of function calls. While haskell's straightforward applicative style has a certain elegance, it doesn't in my opinion contain enough 'punctuation'-type syntactic elements to be easily readable in many cases.<BR/><BR/>* Haskell code is frequently just too dense to be easily readable. In a way this is an advantage - you can say an awful lot in just a few lines - but unpacking those few lines mentally later on can be hard work, and I think this is a trade-off which many Haskellers make poor choices on.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6655746112052720933.post-6139380570471925872007-08-16T19:37:00.000-05:002007-08-16T19:37:00.000-05:00@vagif: I'd also prefer the Lisp, but because of s...@vagif: I'd also prefer the Lisp, but because of semantics, not syntax. Besides, Java's syntax is bletcherous enough..<BR/><BR/>@igouy: AFAICT the only reason to have binary messages at all is for their half-ass imitation of infix math. But if a language is going to do such a lousy job, why bother at all? I'd rather see them left out entirely than setting a trap for the unwary by less-than-half-solving some problem. (Full disclosure: Smalltalk strikes me as one of the most dogmatic single-paradigm languages around, and I find that tooth-grindingly painful.)<BR/><BR/>-- (same anonymous)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6655746112052720933.post-38728723443459984862007-08-16T15:05:00.000-05:002007-08-16T15:05:00.000-05:00Syntax matters of course - just look at Perl :))If...Syntax matters of course - just look at Perl :))<BR/>If seriously - look at all the rave over DSLs - were syntax matters most.<BR/><BR/>And haskell has much better syntax than any "mainstream" language.<BR/>So why downplay such an advantage ?<BR/>I think it is time to realize - haskell is past defense stage. It gained enough popularity amongst programmers, to stop being so shy about its advantages.<BR/><BR/>To anonymous: i'd rather spend a year writing-reading lisp than a day writing-reading java.Anonymoushttps://www.blogger.com/profile/16990997255414980224noreply@blogger.comtag:blogger.com,1999:blog-6655746112052720933.post-12504841742741337092007-08-16T12:02:00.000-05:002007-08-16T12:02:00.000-05:00anonymous said Syntax "... doesn't matter" in the ...anonymous said <EM>Syntax "... doesn't matter" in the sense that it's easy to parse something relatively unsurprising. ... and really annoying to refuse to do so because of some personal dogma.</EM><BR/><BR/>The easiest way not to be surprised is to not look at anything new.<BR/><BR/>Smalltalk unary, binary and keyword method precedence is utterly consistent and trivial to learn. <BR/><BR/>The problems newbies had with Smalltalk were firstly problems understanding basic OO, and then understanding the structure of programs expressed as a bundle of cooperating objects - "where's the program?"Isaac Gouyhttps://www.blogger.com/profile/00226627985460018169noreply@blogger.comtag:blogger.com,1999:blog-6655746112052720933.post-10783709703321487262007-08-16T11:02:00.000-05:002007-08-16T11:02:00.000-05:00I tend to judge syntaxes not by how they look but ...I tend to judge syntaxes not by how they look but by how much they charge me to write my code. So, for me at least, syntax does matter: each syntax implies a programming cost (one might call it a tax).<BR/><BR/>XML, for example, is a rather "expensive" way of representing serialized data structures and configuration files (but it's fine for text). JSON and YAML are alternative syntaxes that offer much lower costs for these applications.<BR/><BR/>Fortunately, Haskell's syntax tax is impressively low. Even people who initially don't like the look of Haskell tend to warm up to the syntax after working with it on a project or two.<BR/><BR/>Cheers! --TomAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-6655746112052720933.post-72835663749722121412007-08-16T03:42:00.000-05:002007-08-16T03:42:00.000-05:00I used to code in Haskell at the university and li...I used to code in Haskell at the university and liked it very much... <BR/><BR/>IMHO <B>readable</B> code one of the most important things and a reason why pure C and Java are still that popular.<BR/><BR/>Lately, I gave erlang a try* and I believe it is even easier to learn than haskell - the syntax it feels easier to read... <BR/><BR/>anyway, any functional language without a shared memory model would be a great improvement.<BR/><BR/>*you know, with all the hype, who can resist ;-)Anonymoushttps://www.blogger.com/profile/07488126278314276322noreply@blogger.comtag:blogger.com,1999:blog-6655746112052720933.post-62248038277969635832007-08-16T02:22:00.000-05:002007-08-16T02:22:00.000-05:00Here's the thing you're missing: Syntax "doesn't ...Here's the thing you're missing: Syntax "doesn't matter" in the sense that it's easy to parse something relatively unsurprising. Lisp ("everything must be prefix parenthesized") and Smalltalk ("precedence? for the not-1337!") get this wrong by being dogmatic. Haskell gets it right by being more pragmatic.<BR/><BR/>Syntax *does* matter in the sense that it's easy to make it a non-issue, and really annoying to refuse to do so because of some personal dogma.Anonymousnoreply@blogger.com