F# is gaining independence from .NET

Post by jackfoxy » Tue, Feb 02, 2021, 1:03 AM UTC

gameswithgo wrote: post #133

jackfoxy wrote: post #117

Earlier quoted context omitted.

>functional messes are an order-of-magnitude worse than imperative/OO ones I find them an order of magnitude easier and safer to refactor. And I have done it a few times with production messes I was not familiar with. Immutable values instead of variables and idempotent functions (those not having side effects) makes refactoring a joy and the if it builds it works mantra is pretty much true.

There is pretty broad agreement that pure functions and immutable variables are good to strive for. And since F# doesn't force you to do that even when it is a bad idea, things are quite nice. When mutating state is the simpler thing to do, you can do it. Where things can get weird is when you start passing partially applied functions to other functions, and then you use type inference on function signatures on top o…

Post by phillipcarter » Tue, Feb 02, 2021, 1:40 AM UTC

gameswithgo wrote: post #170

jolux wrote: post #169

Earlier quoted context omitted.

F# Seqs are .NET IEnumerables, which is to say they are iterators. They're lazy, and you can do things with them that you can't do with "strict" collections. In some ways they are faster than strict collections, in others they are slower. If you plan to be iterating over a Seq multiple times, you should probably turn it into a list or array first, just like in C#. That example without pipes is List.reduce (+) (List.m…

I know what Seq is. C# IEnumerables already have more overhead than iterators in C++/Rust due to historical reasons that can't easily be unwound now, and F# Seq adds a bit more on top, it isn't horrible it is just too bad. The ergonomics of LinkedLists really aren't any different than could be achieved with an array backed List, it just isn't done. I realize part of that is because it facilities immutable data struct…

Post by Scramblejams » Tue, Feb 02, 2021, 4:05 AM UTC

Post by thomasz » Tue, Feb 02, 2021, 9:09 AM UTC

samus wrote: post #93

thomasz wrote: post #61

Earlier quoted context omitted.

IMHO it's tooling. The industry has spend decades to help you to deal with the kind of mess OO tends to produce. The tooling isn't anywhere close when you have to deal with a mess of functions returning functions that return functions.

> 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 ID…

    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] 

    class Memoizer {
        Dictionary cache = new Dictionary();
        Func f; 

        /* ... */

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