Re:Thoughts on Haskell
by mercurial on Saturday October 17, 2015 @05:45PM
(#10406260)
Stuff I would have mentioned:
- some_code... where vs let... in some_code: these two constructs play a fairly similar role in Haskell. The problem with where is that it lets you introduce the value of a binding AFTER using said binding. Ugh.
- functions defined over several lines using pattern matching: I'm still not sure if it's a good idea or not, but I think overall a shorthand syntax like OCaml's "function" keyword (except less unfortunate) is better
- pattern matching and guards are separated (try going back to Haskell after trying a language which combines the two..)
-the absence of named and default arguments is an issue in a language like Haskell. This leads to many instances of "guess what the fourth argument here means"/"let's create a record type just for the arguments of this function" and elegant APIs such as function1, function1' and function2'' (good luck figuring out from the name only which function you need)
- a much stronger focus on brevity (single-name variables all over the place, horrible ASCII DSL galore) than on legibility
- I think the record situation situation improved since I stopped doing Haskell, but when I did, it was really a trainwreck (having to prefix the field names of all your records to prevent collisions is not a feature).
- some_code... where vs let... in some_code: these two constructs play a fairly similar role in Haskell. The problem with where is that it lets you introduce the value of a binding AFTER using said binding. Ugh.
- functions defined over several lines using pattern matching: I'm still not sure if it's a good idea or not, but I think overall a shorthand syntax like OCaml's "function" keyword (except less unfortunate) is better
- pattern matching and guards are separated (try going back to Haskell after trying a language which combines the two..)
-the absence of named and default arguments is an issue in a language like Haskell. This leads to many instances of "guess what the fourth argument here means"/"let's create a record type just for the arguments of this function" and elegant APIs such as function1, function1' and function2'' (good luck figuring out from the name only which function you need)
- a much stronger focus on brevity (single-name variables all over the place, horrible ASCII DSL galore) than on legibility
- I think the record situation situation improved since I stopped doing Haskell, but when I did, it was really a trainwreck (having to prefix the field names of all your records to prevent collisions is not a feature).