I am writing some elm now and I'm not extremely happy. How does elmish compare in practice? Elm has very good error messages and is mostly fast but it's also annoyingly limited.
F# is gaining independence from .NET
161–170 of 181 posts
Re: F# is gaining independence from .NET
#162Complaining about bad docs isn’t really fair IMHO. Compared to Swift F# has excellent documentation. Would be interesting to know what F# is compared with in this case. Is there a language thats known for excellent docs ? One thing you can’t pass on when talking about fsharp in the community. If you have a question just ask on twitter or slack. You’ll get an answer in minutes.
> Is there a language that's known for excellent docs ?
Mathematica's documentation is extremely good (reference.wolfram.com).
Re: F# is gaining independence from .NET
#163Okay. I don't want to go too far off topic here but the OP is about F# so I'm certain many enthusiasts will be here, and I have been waiting for this moment to get an answer to a very specific question regarding Elmish: What is the point of the Elm architecture? I cannot figure out why the `model`, `view`, `update` architecture is preferable to its OOP counterpart. That is, simply defining an interface for each of th…
To the extent that I understand your complaint, there is a functional architecture that alleviates this concern: arrowized functional reactive programming. https://blog.jle.im/entry/intro-to-machines-arrows-part-1-st... talks about it.
Does this solve the problem though? I'll be honest, I'm not very familiar with Haskell (and frankly only casually use FP in general), but I don't see how the pattern in your link alleviates my concern.
The problem (truly the problem) is about _where_ one defines behavior. It's the expression problem (EP) at its core. A FP approach separates data and behavior in a way that makes adding new behaviors to the same data types easy and OOP combines them in a way to make adding new data types to the same behaviors easy. It's literally the difference between:
let model' = update model msg
let model' = model.update msg
Re: F# is gaining independence from .NET
#164Related from 2 months ago: https://news.ycombinator.com/item?id=25305650
Re: F# is gaining independence from .NET
#165Earlier quoted context omitted.
You do it in the .fsproj. I wish Microsoft would add a warning to explain that, instead of just saying the modules can't be found. Really confused me for a good few hours.
My general feeling is that, if you can generate a warning that tells you the right thing to do, then the compiler should just do the right thing.
That's wrong on two levels:
1. The compiler doesn't usually exactly know the right thing to do. E.g. in this case presumably the error should be something like "You need to order the files so that each file doesn't depend on anything further down the list." The compiler doesn't know what that order should be (maybe in this case it could figure it out, but the point is more general than just this instance).
2. Sometimes the compiler might be able to figure out what you meant but you still did it wrong. If you accept wrong code then pretty soon people will start thinking that it is right, and then you have to support it forever. This is closely related to the thoroughly disproven "Robustness Principle", which actually leads to systems that are really not robust. HTML parsing is a good example (though mostly fixed today).
Re: F# is gaining independence from .NET
#166Is their a good F# book that will teach functional programing. Every F# book i see are trying to teach the syntax.
I am the author of the post and author of this https://www.udemy.com/course/learning-functional-programming... Don't be deceived by low rating. It's low because people expected a course on syntax. Also other continuations are as below: https://www.udemy.com/course/functional-application-designin... https://www.udemy.com/course/end-to-end-real-world-applicati... And if you have any questions find me from @OnurGumusDev…
Thanks. Bought the course. Looking forward to learning.
Re: F# is gaining independence from .NET
#167How does this compare to BuckleScript or Reason?
The equivalent is fable [1].
The major difference I would say, is that you are required to use botnet alongside of node. (dotnet to compile to JS, then node to bundle with wepback or anything else)
Also, you can use the same language to build high performance backend with giraffe [2] (better than node). And build performant native application with fabulous [3].
There is an experimental typescript compilation. Which will be great, because it will make using F# less hostile in an environment where the winner takes all.
[1] https://fable.io
Re: F# is gaining independence from .NET
#168Earlier quoted context omitted.
I also value F# for reasons that have very little to do with functional programming. I like the sum types, I like the generics, I like the syntax, but when I make things with it I do not get very functional, in fact I find the more aggressively functional approaches to be extremely confusing to reason about. Where functions take in partially applied functions and so on, it is very hard to read. Maybe thats fundamenta…
I mean, `List.map` is often used in a partially applied manner and, used in conjunction with the pipe operator, results in, imho, readable code: [1;2;3;4] |> List.map ((*) 2) |> List.reduce (+)
what would the equivalent code without partial application look like here?
Also, this is another pet peeve about 'functional style' F#, the use of actual Linked Lists, which is a huge performance pitfall to accept on modern hardware.
And also that F# Seq are not well optimized.
Re: F# is gaining independence from .NET
#169Earlier quoted context omitted.
I mean, `List.map` is often used in a partially applied manner and, used in conjunction with the pipe operator, results in, imho, readable code: [1;2;3;4] |> List.map ((*) 2) |> List.reduce (+)
what would the equivalent code without partial application look like here? Also, this is another pet peeve about 'functional style' F#, the use of actual Linked Lists, which is a huge performance pitfall to accept on modern hardware. And also that F# Seq are not well optimized.
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.map ((*) 2) [1;2;3;4])
Re: F# is gaining independence from .NET
#170Earlier quoted context omitted.
what would the equivalent code without partial application look like here? Also, this is another pet peeve about 'functional style' F#, the use of actual Linked Lists, which is a huge performance pitfall to accept on modern hardware. And also that F# Seq are not well optimized.
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 structures, but they are often used when that isn't happening.