4 ms·

I've recently begun digging into Haskell; it has a lot of interesting and novel features. However, I can't get over it's syntax. It often uses non-alphanumeric

I've recently begun digging into Haskell; it has a lot of interesting and novel features. However, I can't get over it's syntax. It often uses non-alphanumeric characters in place of function names. Many functions are poorly named, e.g., `elem` vs Python's `in`. I strongly prefer the more natural English style syntax; even when you know a language well, it reads faster. That being said, Haskell is awesome for numerous other reasons. 500 line functions are the devil, they're harder to read, test, modify, and reason about. They tend to encourage code that isn't DRY, or reusable. The only benefit they have is an almost always insignificant performance boost, at the cost of everything else. Also magic isn't terrible if it's used in moderation, and it's well documented. Though it usually results in things being substantially harder to GREP.

arethuza 12y ago
"I can't get over it's syntax" I think there is a syntactical pain barrier for a lot of languages. However, once you are through that barrier you stop noticing the syntax. e.g. When I first looked at Python I remember thinking "significant white-space - that is evil". However, I forced myself to write some Python and after a fairly short time I didn't notice that aspect anymore and now I think significant white-space is actually pretty sensible. I've had similar experiences when starting out with Common Lisp, PostScript and a variety of other things that don't look like a variation on C. I would agree that Haskell does look a bit weird - but everything looks weird the first time you see it. Indeed, I can remember seeing C for the first time when I was 16 or so (early 80s) and thinking that looked weird compared to the Basic I was used to...
- seanmcdirmid 12y ago
  > I think there is a syntactical pain barrier for a lot of languages. However, once you are through that barrier you stop noticing the syntax. No, not always. Some languages are intrinsically worse with terseness than others; for example: APL, Perl, and Haskell. The association fallacy is so useful :)
  - arethuza 12y ago
    Not sure I would agree about Perl - personally I found it pretty easy to pick up. That was Perl 4 though. I don't think terseness is always a problem in the same way that verbosity isn't always a feature - look at COBOL or the various graphical "programming" systems (oddly popular in the world of integration products).
  - lucian1900 12y ago
    Haskell is a bit of an odd one out there. Its syntax is extremely simple and the major source of peculiar symbols is various functions, which are much easier to reason about than syntax.
    - seanmcdirmid 12y ago
      Simple doesn't mean easy. I believe APL has a simpler syntax than Haskell (if we just look at grammar complexity): all of its complexity is in the various functions it supports.
      - kd0amg 12y ago
        APL's syntax is only simple if you consider parsing as a language acceptance check. Getting the actual syntax tree requires knowing what will be assigned to what names during run time.
- rectangletangle 12y ago
  I agree for the most part; with persistence it can be overcome. But why make anything harder to learn than it has to be? `long_descriptive_variable_name` gives you a lot more useful information than `:++-`. What's the benefit of making a language look like runes? For this reason alone, I find LISP to be easier to read.
  - arethuza 12y ago
    I did terrible things with reader macros back in my Common Lisp days so I probably can't comment on how readable my code was to other people. Certainly the people I acquired the reader macro abuse habit from produced some files that when I first opened them I didn't think they were Lisp at all.... :-) NB I'm glad to have got those tendencies out of my system in academia where it did relatively little harm to others.
- cousin_it 12y ago
  I think line noise operators and single character names are bad in any language. Haskell is among the worst offenders, but C++ isn't much better. At some point this frustrated me so much that I started making my own language. Semantically it was pretty much a dialect of ML, a statically typed, eagerly evaluated language with mostly immutable data, but syntactically it aimed for extreme readability: 1) All keywords and standard functions have full English names, no abbreviations. 2) Keywords are UPPERCASE, types are Capitalized, values and functions are camelCase. Easy to tell the difference at a glance. 3) Mandatory type declarations everywhere. Limited type inference within expressions, but that's it. 4) Only one kind of syntactically significant parentheses, instead of () [] {} <> as in C++ or Java. 5) No two-character operators. Instead of x != y you have to write NOT (x = y). Sorry! 6) Significant whitespace. The code looked something like this: GENERIC(Type) FUNCTION identity(value: Type): Type RETURN value I have a lot of code written in that dialect, just for my own amusement. It's pretty verbose and boring, but extremely easy to write, impossible to misunderstand, and sticks to memory like nothing else I've ever tried. I still want to finish an implementation someday.
  - tormeh 12y ago
    That sounds awesome. Keep it up!
  - mamcx 12y ago
    That is a bit close to pascal. I have think in something similar, but extend the idea: #Naming conventions. ENFORCED BY THE COMPILER by default #For type/class/interface Str #Title-case mean public _Str #private ___Str #protected #For functions, properties isPublic #Camel-Case mean public. _isPrivate #private ___isProtected #protected PI = 3.1416 #All CAPS means CONSTANT I wonder how do mutable vs. inmutable. I have think in: thisIsInmutable thisIsMutable* Because if is only a declaration point (using for example let vs var) but not the rest of the use of the name, you lost the ability to know if the thing mutate or not. The other idea is doing this only for functions: fun List.Add(self*, values:Array) Or like in other languages fun List.Add!(values:Array) The other idea (derived from the fact the Lexer/AST give far more info than the text) is color-mark the vars and differentiate by color and/or font style between mut/inmutable, functions, types, vars, etc
yogsototh 12y ago
For the syntax, this article might help you: http://blog.ezyang.com/2011/11/how-to-read-haskell/ http://blog.ezyang.com/2011/11/how-to-read-haskell/ I personally continue to find many Haskell library code hard to read. But if you make some effort you own code can be quite readable. Unfortunately I don't know if there is any guideline to make your Haskell code more readable. For example, I'll be glad to get some advices regarding the following questions: - When to use type synonyms/data/records/tuples/lists for containers? - How to name your variables, type variables? - When to split your code between a long one-line or many small named functions? - When to split your code in many different modules? - etc...

arethuza 12y ago

"I can't get over it's syntax" I think there is a syntactical pain barrier for a lot of languages. However, once you are through that barrier you stop noticing the syntax. e.g. When I first looked at Python I remember thinking "significant white-space - that is evil". However, I forced myself to write some Python and after a fairly short time I didn't notice that aspect anymore and now I think significant white-space is actually pretty sensible. I've had similar experiences when starting out with Common Lisp, PostScript and a variety of other things that don't look like a variation on C. I would agree that Haskell does look a bit weird - but everything looks weird the first time you see it. Indeed, I can remember seeing C for the first time when I was 16 or so (early 80s) and thinking that looked weird compared to the Basic I was used to...

seanmcdirmid 12y ago
> I think there is a syntactical pain barrier for a lot of languages. However, once you are through that barrier you stop noticing the syntax. No, not always. Some languages are intrinsically worse with terseness than others; for example: APL, Perl, and Haskell. The association fallacy is so useful :)
- arethuza 12y ago
  Not sure I would agree about Perl - personally I found it pretty easy to pick up. That was Perl 4 though. I don't think terseness is always a problem in the same way that verbosity isn't always a feature - look at COBOL or the various graphical "programming" systems (oddly popular in the world of integration products).
- lucian1900 12y ago
  Haskell is a bit of an odd one out there. Its syntax is extremely simple and the major source of peculiar symbols is various functions, which are much easier to reason about than syntax.
  - seanmcdirmid 12y ago
    Simple doesn't mean easy. I believe APL has a simpler syntax than Haskell (if we just look at grammar complexity): all of its complexity is in the various functions it supports.
    - kd0amg 12y ago
      APL's syntax is only simple if you consider parsing as a language acceptance check. Getting the actual syntax tree requires knowing what will be assigned to what names during run time.
rectangletangle 12y ago
I agree for the most part; with persistence it can be overcome. But why make anything harder to learn than it has to be? `long_descriptive_variable_name` gives you a lot more useful information than `:++-`. What's the benefit of making a language look like runes? For this reason alone, I find LISP to be easier to read.
- arethuza 12y ago
  I did terrible things with reader macros back in my Common Lisp days so I probably can't comment on how readable my code was to other people. Certainly the people I acquired the reader macro abuse habit from produced some files that when I first opened them I didn't think they were Lisp at all.... :-) NB I'm glad to have got those tendencies out of my system in academia where it did relatively little harm to others.
cousin_it 12y ago
I think line noise operators and single character names are bad in any language. Haskell is among the worst offenders, but C++ isn't much better. At some point this frustrated me so much that I started making my own language. Semantically it was pretty much a dialect of ML, a statically typed, eagerly evaluated language with mostly immutable data, but syntactically it aimed for extreme readability: 1) All keywords and standard functions have full English names, no abbreviations. 2) Keywords are UPPERCASE, types are Capitalized, values and functions are camelCase. Easy to tell the difference at a glance. 3) Mandatory type declarations everywhere. Limited type inference within expressions, but that's it. 4) Only one kind of syntactically significant parentheses, instead of () [] {} <> as in C++ or Java. 5) No two-character operators. Instead of x != y you have to write NOT (x = y). Sorry! 6) Significant whitespace. The code looked something like this: GENERIC(Type) FUNCTION identity(value: Type): Type RETURN value I have a lot of code written in that dialect, just for my own amusement. It's pretty verbose and boring, but extremely easy to write, impossible to misunderstand, and sticks to memory like nothing else I've ever tried. I still want to finish an implementation someday.
- tormeh 12y ago
  That sounds awesome. Keep it up!
- mamcx 12y ago
  That is a bit close to pascal. I have think in something similar, but extend the idea: #Naming conventions. ENFORCED BY THE COMPILER by default #For type/class/interface Str #Title-case mean public _Str #private ___Str #protected #For functions, properties isPublic #Camel-Case mean public. _isPrivate #private ___isProtected #protected PI = 3.1416 #All CAPS means CONSTANT I wonder how do mutable vs. inmutable. I have think in: thisIsInmutable thisIsMutable* Because if is only a declaration point (using for example let vs var) but not the rest of the use of the name, you lost the ability to know if the thing mutate or not. The other idea is doing this only for functions: fun List.Add(self*, values:Array) Or like in other languages fun List.Add!(values:Array) The other idea (derived from the fact the Lexer/AST give far more info than the text) is color-mark the vars and differentiate by color and/or font style between mut/inmutable, functions, types, vars, etc

yogsototh 12y ago

For the syntax, this article might help you: http://blog.ezyang.com/2011/11/how-to-read-haskell/ http://blog.ezyang.com/2011/11/how-to-read-haskell/ I personally continue to find many Haskell library code hard to read. But if you make some effort you own code can be quite readable. Unfortunately I don't know if there is any guideline to make your Haskell code more readable. For example, I'll be glad to get some advices regarding the following questions: - When to use type synonyms/data/records/tuples/lists for containers? - How to name your variables, type variables? - When to split your code between a long one-line or many small named functions? - When to split your code in many different modules? - etc...