Comment by samus | Hacker News Reader

Comment by samus | Hacker News Reader

Parent Full thread

> a mess of functions returning functions that return functions.

That is just a curried function with three arguments. The bigger problem is that programmers still have to understand how Hindley-Milner type inference works to figure out type errors. This gets worse when you add in type classes, dependent types and (Yog-Sothoth help you) lenses.

Your point is still true. For any language, it is important to have an IDE ecosystem in place. The tooling must enable developers to move beyond fighting the unruly or boring parts of the language and instead leverage it to work on the domain.

No, not necessarily. Curried functions have their own problems because they are missing the vital parameter names. But that's not what I meant. Think of the classic memoization example (written without a compiler at hand...)

    let createMemoizer f =
        let cache = Dictionary<_,_>()
        let f' = fun x ->
            match cache.TryGetValue(x) with
            | (true,value) -> value
            | (false, _) ->
                let result = f x
                do cache.[x] <- result
                result
        f'

The signature is ```createMemoizer (f:'a->'b) -> 'a->'b```, which is not very telling, especially if it is returned by yet another function, so that even the createMemoizer name is lost. In classic OO, I'd just get a Memoizer object that carries vital documenation and what not with itself, as it is passed around. It's no even that much longer, it's just not as elegant to use.

    class Memoizer<TINPUT,TOUTPUT> {
        Dictionary<T,TOUTPUT> cache = new Dictionary<T,TOUTPUT>();
        Func<TINPUT,TOUTPUT> f; 

        /* ... */

        public TOUTPUT Invoke(TINPUT parameter) {
            if (!cache.TryGetValue(parameter, out var result)) {
                result = f(parameter);
                cache[parameter] = result;
            }
            return result;
        }
    }

Reply on news.ycombinator.com