141–150 of 179 posts
Earlier quoted context omitted.
I really need to make time to look into F# some time, it sounds like it has the things I like in C# but more so.
You can try it out quickly and cheaply, at https://fable.io/repl/ There's no setup required, just start typing some F# code into the online playground and see it run immediately.
Earlier quoted context omitted.
After being deeply burned by the .NET framework, I consider OCaml significantly superior to F# just because it doesn't depend on .NET or Microsoft. And yes, somehow the OCaml guys have managed to implement generics and AOT compilation to optimized machine code long before the .NET framework existed, but now this is something "truly hard" on .NET.
My problem with OCaml that while the semantics are top notch, everything else is stuck in the past. The syntax is quirky, there's a bunch of legacy baggage (does anyone use the OO stuff?), there's no SMP support (though I know this is being worked on), the toolchain feels antiquated (the REPL still, to this day, doesn't come with Readline support built in; rlwrap is required!), etc. Not to mention the lack of modern…
OCaml's object and class systems are excellent; I prefer them to just about anything else. They rarely get used for the simple reason that algebraic types, functors, and first-class modules are better suited to modeling almost any kind of domain logic.
Also, I like OCaml's extremely simple and direct syntax. I'm fine with F#'s implicit `in`, though it requires whitespace-sensitivity. I think ReasonML went in the wrong direction, cluttering it up with curly braces and ubiquitous tuple-like syntax for function arguments.
OCaml actually has excellent tooling — among the best — and some (but not many) great libraries. What it lacks most is great documentation...
Earlier quoted context omitted.
My problem with OCaml that while the semantics are top notch, everything else is stuck in the past. The syntax is quirky, there's a bunch of legacy baggage (does anyone use the OO stuff?), there's no SMP support (though I know this is being worked on), the toolchain feels antiquated (the REPL still, to this day, doesn't come with Readline support built in; rlwrap is required!), etc. Not to mention the lack of modern…
Example of OCaml's object system in use by the creator of OCaml: https://github.com/xavierleroy/cryptokit/blob/master/src/cry... OCaml's object and class systems are excellent; I prefer them to just about anything else. They rarely get used for the simple reason that algebraic types, functors, and first-class modules are better suited to modeling almost any kind of domain logic. Also, I like OCaml's extremely simple…
I don't think even the core OCaml devs would claim this. Rust (and Java and Microsoft) toolchains are examples of excellent tooling. OCaml, not so much.
That said, the tooling situation today in OCaml is much better than it was a few years ago, which is real progress.
"No matter if you are already a functional developer from a different community (Haskell, Clojure, Scala, etc.) or you are a complete newbie to functional programming (like I was 3 years ago) I think F# can equally impress you" -> "For this task and for the rest of this blog post I'll be comparing F# with C# in order to show some of the benefits." F# is neat, and I see why it's useful if you have a big .NET program a…
Earlier quoted context omitted.
For a while, yes. I know from experience that going the other way is a struggle as well. Habits die hard and change takes effort. There's nothing superior about these type systems, they're simply two of the most static and rigid systems in circulation right now. Try writing C, Lisp and Forth until it clicks. Then we can sit down and have an informed discussion about missing features.
I think a lot of it could be personality based. With C, Lisp and Forth you bash out code and run it, see if it works and then make changes. You get much faster visual feedback. With Haskell, you need to put in a lot more up front thought. Then stuff doesn't compile and you spend ages working out why.. You can go for hours without having anything running. The cause of the errors can be quite abstract and obtuse and ma…
Earlier quoted context omitted.
My problem with OCaml that while the semantics are top notch, everything else is stuck in the past. The syntax is quirky, there's a bunch of legacy baggage (does anyone use the OO stuff?), there's no SMP support (though I know this is being worked on), the toolchain feels antiquated (the REPL still, to this day, doesn't come with Readline support built in; rlwrap is required!), etc. Not to mention the lack of modern…
Example of OCaml's object system in use by the creator of OCaml: https://github.com/xavierleroy/cryptokit/blob/master/src/cry... OCaml's object and class systems are excellent; I prefer them to just about anything else. They rarely get used for the simple reason that algebraic types, functors, and first-class modules are better suited to modeling almost any kind of domain logic. Also, I like OCaml's extremely simple…
Earlier quoted context omitted.
AOT not supporting generics? that's a pretty bad reading/summary of the webpage you link to (not to mention, that page may be a bit outdates, and more cases are supported by AOT now; take in account this is the mode that iOS apps developed with Xamarin need to use).
"As of Mono 2.0, AOT compilation is only supported for non-generic methods. support for generics is currently under development."
Earlier quoted context omitted.
AOT not supporting generics? that's a pretty bad reading/summary of the webpage you link to (not to mention, that page may be a bit outdates, and more cases are supported by AOT now; take in account this is the mode that iOS apps developed with Xamarin need to use).
In dotnet land generics are JITted on demand at runtime when you first execute a specific instance of that generic type. So List doesn't necessarily get JItted even though List has been. This poses a bit of a problem for AOT compilation. You would essentially have to either A) Trace all possible execution paths and determine every needed generic instantiation and precompile and ship them all. This ain't easy, and it…
It does, if the AOT compiler is advanced enough to examine all code and determine that `int` is a possible type being used with List. Mono has had a lot of advancements on these techniques over the years, as it's the only way for them to let Xamarin devs deploy apps on the iPhone.
Earlier quoted context omitted.
"As of Mono 2.0, AOT compilation is only supported for non-generic methods. support for generics is currently under development."
Mono 2.0 is ancient, nowadays the version is 5.16. That webpage is not worth looking at.
[1] https://mattwarren.org/2018/06/07/CoreRT-.NET-Runtime-for-AO...
Earlier quoted context omitted.
Mono 2.0 is ancient, nowadays the version is 5.16. That webpage is not worth looking at.
So where should I look? It doesn't seem to be a particularly popular or well-documented topic. The best I've found is this [1]. [1] https://mattwarren.org/2018/06/07/CoreRT-.NET-Runtime-for-AO...