111–120 of 208 posts
Can I encourage everybody to classify their complaints according to the following scheme? http://h2.jaguarpaw.co.uk/posts/complaining-about-languages/ I believe it would help everybody understand how we can improve people's experience around Haskell.
Haven't seen it listed neither here nor there, so not sure if I'm the only one, but: for me, the first and currently blocking obstacle is of "graphical" syntax. I'm of the kind of people who hear the words they read as a voice in their head, so when every line is interspersed with multiple "random" >>= -,-'-- and whatnot other ascii-art I can't verbalise, I distictly feel my brain stumble, mumble, and grind to a halt…
I felt the same way (and still do in general, with notable exceptions). I.e. to put this first: I think a lot of the Haskell community is obsessed with mathematical "cuteness", which basically they take to mean "infix-operator-heavy" notation. Nevertheless, I have learned to like some operators, , *>, are ones that come to my mind. The operator is basically fmap as infix notation, so `fmap f [1,2,3]` would be `f [1,2…
I guess the solution is just to put parentheses everywhere, but why is it that, whenever I show people code where I'm doing that, they always point out "Oh, you don't need parentheses there." I feel like that just goes to show that the community underestimates the confusion most people feel when they encounter a jumble of custom operators and have to recall to themselves which parts of an expression are evaluated first or even in what direction. This language feature feels more like an antipattern.
I really think the benefits of making operators so easy to define are quickly outweighed by the drawbacks for most programmers. The infix culture seems like one of the biggest barriers for this language.
Mine is that it's built on a lie. A nobel lie, but a lie none the less. In order to be pure it has "stop the world and record it" with monads to do any IO. It pretends that the world can be snapped shotted and immutable. In reality the monad is only an extra box with a belief that the world stops. The world in fact does not.
The IO monad doesn't involve actually recording anything...it's not like MVCC. What are you actually trying to say here?
Mine is that it's built on a lie. A nobel lie, but a lie none the less. In order to be pure it has "stop the world and record it" with monads to do any IO. It pretends that the world can be snapped shotted and immutable. In reality the monad is only an extra box with a belief that the world stops. The world in fact does not.
That's not how IO in Haskell works, you're basically describing what Haskell would be if it literally had no side-effects ever.
Haven't seen it listed neither here nor there, so not sure if I'm the only one, but: for me, the first and currently blocking obstacle is of "graphical" syntax. I'm of the kind of people who hear the words they read as a voice in their head, so when every line is interspersed with multiple "random" >>= -,-'-- and whatnot other ascii-art I can't verbalise, I distictly feel my brain stumble, mumble, and grind to a halt…
I'm of the kind of people who hear the words they read as a voice in their head, so when every line is interspersed with multiple "random" >>= -,-'-- and whatnot other ascii-art I can't verbalise, I distictly feel my brain stumble, mumble, and grind to a halt and sad emptiness. Incidentally, this is why prefix notation seems so foreign. (+ 1 2) reads as "plus one two." It's possible to overcome this, with dedication.…
To everyone complaining about laziness, the new GHC 8.0 compiler (due to be released any day now) has a ['Strict' pragma option][1]. [1]: https://ghc.haskell.org/trac/ghc/wiki/StrictPragma
My reason is that there are eight different folding functions: foldl, foldr, foldl1, foldr1, foldl', foldr', foldl1', and foldr1'. There are twelve if you count: scanl, scanr, scanl1, scanr1. Also, the implementation of monad transformers is disgusting. It requires O(n^2) code generation where n is the number of monads.
I just prefer to use languages without a Garbage Collector.
Any experience doing functional programming without garbage collector? I'm doing a lot of Clojure, and can't really see how it would be a pleasant experience without GC but curious to hear any interesting thoughts.
Can I encourage everybody to classify their complaints according to the following scheme? http://h2.jaguarpaw.co.uk/posts/complaining-about-languages/ I believe it would help everybody understand how we can improve people's experience around Haskell.
These are all interacting parts which make up a system. You can't separate the parts out so cleanly when they have so many interactions.
Some examples which from my point of view seem pretty clear cut:
Laziness and purity fall squarely under "language specification". There's no way of seeing them as a problem with libraries or community.
'I think a lot of the Haskell community is obsessed with mathematical "cuteness", which basically they take to mean "infix-operator-heavy" notation.' is a problem of community (and arguably language specification), certainly not of tooling or infrastructure.
"String should not be [Char]" is a problem with libraries (and arguably specification). Certainly not community or tooling.
Earlier quoted context omitted.
Wolf fencing is new to me too. It seems to be used only in the context of debugging. While with git bisect, we are also repeatedly ~halving the remaining search space, the list of commits isn't "sorted" like the precondition for binary search. You could argue that commits are sorted against time. But I would say that's different because we don't know which commit hash we're looking for -- we just want to find the poi…
*> the list of commits isn't "sorted" like the precondition for binary search. Good point. One may think that in some sense, it is sorted: The history is sorted into "good" commits (before the bug was introduced), which are followed by "bad" commits (after the bug was introduced). However, the bisection algorithm also works if "good" and "bad" commits are mixed. Even then it will find one commit where the bug was int…
I don't understand this comment. Need for sorting the list is essentially the same in both cases, because "the bug was reintroduced" is essentially equivalent to "a lower number showed up later". A binary search makes the assumption of sorting because it's premised on the idea, "Whatever number I find, every number that comes after it will be larger". Same with bug-finding in a git history, it assumes "If I find a point in the history where the problematic behavior exists, it exists at all points after that for the same reason."
If you had an "unsorted" history where a bug was fixed and then reintroduced in another way, your binary search may fail to find the immediate cause of your problems in the same way that an "unsorted" binary search would fail to find what it's looking for.