61–70 of 84 posts
Earlier quoted context omitted.
The Register source has this comment: // Registers can't be a record type because the values need to be truncated to 8 bits when writing, so setters are needed // This is for the web renderer as Fable transpiles uint8 to Number (more than 8 bits) in JS and doesn't apply any truncation // Known non-standard behaviour in Fable (https://fable.io/docs/javascript/compatibility.html#numeric-types) So, I think, it's just co…
Oof, thanks for pointing that out, I hadn't noticed and I've only ever used F# on .NET. That's terrible on Fable's part, the least they could do is truncate. I wasn't aware Fable's translation is so naive.
This kind of thing is why Roc compiles to WASM but not JS.
F# is a good language, but I feel like it's forever stuck in C#'s shadow. A lot of the library code is C# and .NET handmedowns. Not interfaces or libraries crafted with F# in mind, often having no explicit documentation for use with F# either.
The larger issue is the C# community loves OOP so you often have to wrap these libraries into something more “FP” if that’s how you want to work.
Overall it’s far better than having nothing (looking at Haskell, OCaml as much as I enjoy them!)
Earlier quoted context omitted.
Out of curiosity when did you write that interpreter? The entire dotnet ecosystem has seen massive speed improvements over the years, particularly for anyone who last tried them during the Framework era. Hell they even put work in to improving tail calls which the c# compiler doesn't even take advantage of (also either in the dotnet 9 or 10 timeframe f# added an attribute to make it so a recursive call that isn't a t…
It's .NET 10 lol. It's not so slow you can't write stuff for it, I have implementations of Conway's game of life, Huffman compression, and a minimal TUI. The main problem is doing almost anything in it involves a method lookup. And there are almost certainly places I could have done things more smartly. One thing I do want to try out is publishing it with native AOT. I had a lot of luck with that on one of my other F…
Earlier quoted context omitted.
The Register source has this comment: // Registers can't be a record type because the values need to be truncated to 8 bits when writing, so setters are needed // This is for the web renderer as Fable transpiles uint8 to Number (more than 8 bits) in JS and doesn't apply any truncation // Known non-standard behaviour in Fable (https://fable.io/docs/javascript/compatibility.html#numeric-types) So, I think, it's just co…
Oof, thanks for pointing that out, I hadn't noticed and I've only ever used F# on .NET. That's terrible on Fable's part, the least they could do is truncate. I wasn't aware Fable's translation is so naive.
F# is a good language, but I feel like it's forever stuck in C#'s shadow. A lot of the library code is C# and .NET handmedowns. Not interfaces or libraries crafted with F# in mind, often having no explicit documentation for use with F# either.
C# interoperability loosens guarantees (particularly immutability) that F# code normally relies on. There are surprising limits that come up in generics because of how they map to C#.
Ah F#, my greatest love. How I wish the C# guys and girls would see this instead of further bastardizing (don't hate me) C# into being everything but poorly. Don't you see that if you would use F# instead, creating projects with C# and F#, that you would get what is being added to C# but actually working and ergonomically? Interop is great!
Earlier quoted context omitted.
It's always going to exist. People still build things with hand tools in the year 2026. Let's call it Artisanal Coding.
Even if you use AI, there's a certain point where it's not clear that an AI would make you faster. F# is my favorite language, and I've been programming in it so long (since 2012) that I feel like I think in F#. Asking an AI for something can be faster if I can state my requirements informally; but if I need to specify many things precisely to an AI... why not just write the code in F#? Part of the beauty of good fun…
One reason I realized recently - when you work it through with an LLM you get full process history linearly serialized, the back and forth, thinking traces, web lookups.
When I need to get back into the task it's much easier to get back in to "the flow".
I think it'll be common practice to start commiting agent logs with the code pretty soon.