3 ms·
Just to give a different pov I find Haskell very intuitive, and particularly I find that code written by other people is very easy to understand (compared to Ja
by jiiam 2y ago
Just to give a different pov I find Haskell very intuitive, and particularly I find that code written by other people is very easy to understand (compared to Java or TypeScript at least).
And by the way x and x' are totally fine names for a value of a very generic type (or even a very specific type depending on the circumstances), as long as the types and the functions are decently named. I mean, how else would you call the arguments of
splitAt :: Eq a => a -> [a] -> [[a]]
?
There is no need for anything more complex than
splitAt x xs = ...
- whytevuhuni 2y ago> I mean, how else would you call the arguments of > splitAt :: Eq a => a -> [a] -> [[a]] Those don't seem to be names of parameters, but rather of types. It's missing parameter names entirely. I spent a good 2 minutes looking at that signature trying to figure it out (and I've read some Haskell tutorials so I'm at least familiar with the syntax). This would've helped: def split_by<T>(separator: T, list: List[T]) -> List[List[T]] `sep`, `separator`, `delim`, `delimiter` would've been good names.
- jiiam 2y ago> Those don't seem to be names of parameters, but rather of types. It's missing parameter names entirely. The rest of the definition is at the end, to see it as a whole: splitAt :: Eq a => a -> [a] -> [[a]] splitAt x xs = ... To clarify, I assumed that by using the constraint `Eq a` and the name splitAt there was no need for extra clarification in the names of the parameters but apparently I was wrong.
- gmfawcett 2y agoI think some of the confusion is because you're referring to the type variables as parameters. Parameters and type variables are not the same thing. A is a type variable, X is a parameter in your example.
- theCodeStig 2y agoNo, you're right. It is perfectly clear from the type signature