Comment by dvdkon | Hacker News Reader

Comment by dvdkon | Hacker News Reader

Parent Full thread

Yes. F# has solidified my belief that syntax and the "feel" of a language matter a lot. You might think just a few extra lines of boilerplate or a few keywords in C# are not a big deal, just like Java programmers may think multiple classes per file are just a gimmick, but those things really matter to how I perceive and use a language.

Extra keywords and extra files are annoyances that I try to instinctively minimise. I don't want to say I take the path of "least annoyance", but it's definitely one of the factors that strongly influence how I write code. F#'s lean tagged union type syntax is functionally inferior to Scala 2's case classes, but I use sum types more in F#, because they're less annoying. In C#, I might as well use classes, because I can't declare free functions.

I often hear that Java is good for teams, because it railroads programmers into writing maintainable, pure OOP code. Well, F# railroads you into writing data-driven, mostly functional, multi-paradigm code, and I think the result is much nicer code than what you'd get when trying that in most other languages.

I think information density per visible page of code in the IDE matters. It relieves you of a lot of mental overhead. By visible density I include mouse-over tooltips. For this reason I don't like code lenses because IMO they waste lines in the visible reagion. When I want to look at a signature I mouse over it.

I think from the syntax, strong typing, and algebraic type signatures F# is the most information dense language I have come across, while still allowing for readability. Maybe something like brainfuck is more information dense.

Thanks, but I still can't see it from where I am. The problem isn't that I can't see the use of (to take your example) sum types. I've coded around C#'s lack of them before, and sure, it was clunky and painful. But I've needed them like < 1% of the time.

If I had them as a first-class language feature, would I use them more? What for?

I think you would. It's hard to see from the perspective of using another language, because you don't think of the code you write as emulating sum types.

For example, in my biggest F# project I parse a local standard for public transport timetables. In that format a trip can either drive through a stop, drive around it or stop there at a particular time. With a sum type, I can represent all three of these cases without worrying about a value of that type having both "driving through" and a time set. When you've got a language that effortlessly allows something like this, you'll find uses for these paradigms.

Okay, that makes sense. I appreciate the concrete example.

You would absolutely use them more, provided that the mechanism for working with them (pattern matching) is also in place. In F# coding you not only model your domain with sum types, but you operate on instances of them with pattern matching that gives you completeness checking. This does two things:

1. Allows you to make failure scenarios intrinsic to your domain, and the compiler then is a tool for domain correctness.

2. It provides a beautiful symmetry between how you define your domain and how you operate on it. The syntax is even almost identical. The features "fit" incredibly well because of that.

Beyond that, with optionals and results defined as sum types you find that any time you're in a "It may explicitly give me nothing" or "It may explicitly give me an error" scenario these types are the first your reach for in your toolbag.

Sum types don't completely obviate classes, but they are a better tool than classes for several scenarios.

You can have multiple public classes in a file in Java. You just have to wrap them in an outer class, that acts like a module, and declare them “public static”. You can then “import static” the module class in other files, and you can use all these classes simply by name (without having to write OuterC.InnerClass everywhere).

Reply on news.ycombinator.com