111–120 of 121 posts
What would be the best IDE/editor for Haskell?
Add in ghcid for continuous builds and it's almost ideal.
So, I know literally nothing about Haskell, and I would rate my knowledge of functional programming theory as 'beginner' at best, but I still get baffled every time when reading Haskell code that implements anything other than something trivial like a fibonacci sequence. The poker server code looks extremely tidy and well engineered, so that can't be the problem, but to me it's utterly incomprehensible. It seems like…
I'd say 50% of the reason it's hard to read is you are not familiar and 50 hours of learning Haskell would sort that out. Training your visual memory to get used to (f a b) rather than f(a,b) etc. I liked to add redundant parens in my play code just to help me with this.
The other 50% is those damn library authors and their love of funny operators and advanced GHC extensions. And also some people like to play code golf with "point-free" style where instead of the x -> f x you'd just use f.
Which if taken to the extreme produces hard to read code that is lovingly called "pointless".
Code golf in Haskell is rife. I really prefer longAndMeaningfulVariableNamesThatErrOnTheSideOfBeingTooLong, but the Haskell culture isn't that way, and they prefer names like: s'.
For once again, thank you mate! +1
What would be the best IDE/editor for Haskell?
From time to time a web browser to search a function in hoogle [1] and ghci (the interpreter console) to interactively try something out.
Honestly, I come to the conclusion, that at least for Haskell I do NOT need an IDE. I would need it for Java and other imperative languages that have huge libraries.
Haskell is one of the languages where it is a better investment of learning the language that spending time searching a good IDE.
Earlier quoted context omitted.
Has it ever occurred to you that Haskell programmers prefer single-letter variable names in some contexts because it makes the code better? Perhaps it is not the children who are wrong.
By the comment, the GP is not a Haskell developer and those people are not programming in Haskell. So, even though it is well known that short named variables and point free syntax often improve the readability of Haskell code, it probably does not improve the readability of his code.
Earlier quoted context omitted.
Unfortunately, a lot of work there is done by the Haskell community having utterly absurd standards for those things. I work in a different functional programming language, and you would not believe the amount of time I spend convincing new hires with Haskell backgrounds to spend the extra few characters to expand out the unreadable point-free/single-character-names style that Haskell folks prefer.
Has it ever occurred to you that Haskell programmers prefer single-letter variable names in some contexts because it makes the code better? Perhaps it is not the children who are wrong.
Earlier quoted context omitted.
Has it ever occurred to you that Haskell programmers prefer single-letter variable names in some contexts because it makes the code better? Perhaps it is not the children who are wrong.
I have spent quite a bit of time in both styles, and there's a pretty clear winner in my experience. I don't work in Haskell, but in another statically-typed FP language - maybe type classes are the feature that flip everything we know about readability from other languages?
merge :: Ord a => [a] -> [a] -> [a]
merge (x:xs) (y:ys) | x This is what I mean - there are a lot of cases when writing Haskell code that you write generic polymorphic combinators. Using long variable names is negative utility. Haskell programmers know this, and so they don't use long names when short ones convey identical information in a more readable manner.
This is where most other languages fall down, and why most programmers don't understand the concept. It's common in Haskell to write code that applies to so many different situations that any "descriptive" name you give to a local variable is just plain incorrect in many use cases.
In the other direction though, Haskell programmers also appreciate the value of a well-chosen name when one applies. Note that the function being discussed elsewhere in this thread isn't polymorphic. It has descriptive local variable names. No one suggested renaming them x or a.
In other words, choose names well, not according to dogma that says short is bad.
Earlier quoted context omitted.
I have spent quite a bit of time in both styles, and there's a pretty clear winner in my experience. I don't work in Haskell, but in another statically-typed FP language - maybe type classes are the feature that flip everything we know about readability from other languages?
No, the problem is giving names that are too specific to things. Like if you're implementing a merge sort for some reason, and go to write merge: merge :: Ord a => [a] -> [a] -> [a] merge (x:xs) (y:ys) | x Those are the ideal variable names. Clarity is only hurt by making the names "descriptive" by naming the type variable elementOfListsToMerge or the parameters things like theHeadOfTheFirstList and so on. It's usele…
Since you like sorts, have you seen a Haskell implementation of quicksort that spells out the word "pivot"? This seems like a small ask. Surely someone has done it. Before typing this, I assumed it couldn't possibly be as bad as I remembered and that I was falling prey to confirmation bias, but in fact 9 out of the top 9 results (one is a dead link, which is why there aren't 10) for "haskell quicksort" on Google use a single-character variable name for it (n, p, or x). As a side note, 7 out of 9 of them exhibit neither the time nor space complexity promised by quicksort. (I admit that two of them appeared to be the same code - call it 8/8 and 6/8, respectively, if that seems unfair.)
Finally, one of the two that does attempt to perform it in place (which is far more complicated) contains variables named lb, ub, mub, ma, and, my favorite, iLTj. Good luck figuring out how that code works. This is the thing I'm talking about, and it is not an isolated example.
I like Haskell as a language! It has a lot of cool ideas. But people who learn it are often made into much worse programmers for having been exposed to it, and it is because of stuff like this. It's some weird community standards problem.
Earlier quoted context omitted.
A general-purpose library able to hide the necessarily specific logic of how network events and a poker game should interact seems... unlikely?
Sure, but the original argument was: > raw connection state, timers, transient and long-term persistent state Much of this surely can be abstracted away to 3rd party libraries/frameworks. Haskell, even though a higher level language than most out there, lacks the ecosystem support for a lot of things that are handled by some library in lower level languages.
Earlier quoted context omitted.
I used Haskell on Emacs a few weeks ago and there still seems to be some issues with regards indentation.
Ouch, it has been so long that I have forgot about this. Add this to your emacs init script somewhere: (add-hook 'haskell-mode-hook 'turn-on-haskell-indentation) It is also not compatible with older versions of intero and haskell-mode, so if you have old configuration there, you may want to remove it. Honestly, it's even weird this isn't on by default.