Re:Why ML/OCaml are good for writing compilers (1998)
by continuational on Sunday April 16, 2017 @05:23AM
(#14125050)
I'll just leave [Control.Lens.Operators](http://hackage.haskell.org/package/lens-4.15.1/docs/Control-...) here...
In defense of Haskell, the situation is similar in Scala. I think some people just prefer inventing their own operators instead of using descriptive names.
Re:Why ML/OCaml are good for writing compilers (1998)
by name_for_now on Sunday April 16, 2017 @01:49PM
(#14126625)
To be fair, a number of those operators are
> This is an infix alias for cons. > This is an infix alias for snoc. > A convenient infix (flipped) version of toListOf. > An infix version of itoListOf.
And a lot of them are (<+~) and friends.
Re:Why ML/OCaml are good for writing compilers (1998)
by dleslie on Sunday April 16, 2017 @10:31AM
(#14125927)
shrug When I look at Haskell code I see overly terse expressions and nothing resembling the concept of self-documentation.
Re:Why ML/OCaml are good for writing compilers (1998)
by cies on Sunday April 16, 2017 @03:37PM
(#14127120)
Are you fluent in Haskell?
Re:Why ML/OCaml are good for writing compilers (1998)
by dleslie on Sunday April 16, 2017 @07:39PM
(#14128239)
I was some years ago, before I gave up on the language; but one shouldn't have to be fluent in a language for it to satisfy the concepts of self-documentation and readability.
Requiring domain-specific knowledge of symbolic notation is not a trait of self-documenting languages. Recommending that the API search engine be open alongside or within your editor is likewise not a trait of self-documenting languages.
Self-documenting languages are coherent at-a-glance to average programmers with little to no knowledge of the language. Haskell is not this.
> it suffers from the Perl-ish woe of write-once and read-never.
My experience with Haskell is opposite, I think Haskell yields very maintainable code that is largely self documenting and allows me to confidently hack around old code bases.
My experience with Perl is the same. Very hard to read back, maintain or get productive on old code bases.