>Yes and no. Curried-by-default is the source of a lot of Haskell's power, and that requires a certain amount of unusual ordering. The terseness of pointfree style is worth some learning time.
Correct me if I'm wrong, but you don't need Haskell's syntax to have automatically curried functions or a pointfree style. Using a JS-like syntax as an example:
function add(a, b) {
return a + b;
}
// functions could be automatically curried,
// so you could do this:
let add5 = add(5);
add5(10) // => 15
// "Normal" sum definition
function sum(list) {
return reduce(add, 0, list);
}
// Pointfree version
function sum() {
// returns a function that takes
// 1 argument (the list)
return reduce(add, 0);
}You can do that up to a point, but you pay a cost for it. It means functions are taking up a big chunk of your available syntax space, and it can make things ambiguous if something might be seen as both a function and a value. Look at how it works in Scala: much of the time you can call a function partially, but in an unsatisfyingly random-feeling set of cases you need to explicitly use "_" expansion.
Agreed; Idris is strict by default and I expect other post-Haskell languages will be too.
> The next problem is that complete immutability is also wrong, because controlled mutable aliasing with linear types (like the system available in Rust) is what you really want since it's more general, efficient and expressive (allows mutable data structures), and complete immutability is just a special case of controlled mutable aliasing.
Disagree. Mutability is so rarely what you want that it's better to have immutability by default, and a clunkier syntax for mutable is ok.
> The third problem of Haskell is the weird syntax, that doesn't follow the common C/Java/JS or Python syntaxes for no good reason, making it hard to read and learn the language.
Yes and no. Curried-by-default is the source of a lot of Haskell's power, and that requires a certain amount of unusual ordering. The terseness of pointfree style is worth some learning time. $ is a big ergonomic advantage, though I'm not entirely convinced it's worth the cost. There are a few cheap wins, some of which Idris has (e.g. single colon for type annotations, standardised syntax highlighting) but you don't want to throw away the good stuff.
> And if one were to change these things in Haskell, the result would essentially be Rust (or more precisely, a future version of Rust once all the missing abstractions like HKT, specialization, etc. are added), so I think that's what one should use instead.
Agreed, but that thing doesn't exist yet, and the Rust that exists today isn't an acceptable substitute (it's 2017, I shouldn't have to use a language without HKT). For the moment I'd say Idris is as close as you can get.