What I wish I knew when learning F#

https://danielbachler.de/2020/12/23/what-i-wish-i-knew-when-learning-fsharp.html

by DeathArrow • 5 years ago

233 147 5 years ago

7thaccount5• 5 years ago

The biggest for me is needing to understand the .NET ecosystem without knowing C#. Then there's the lack of beginner information. I own several F# books and none of them assume you're coming from a scripting language background. I eventually gave up for good. OCaml doesn't have the .NET problem, but I found it to be unergonomic in a lot of ways.

Make no mistake, it's a cool language that I'd love to be good at. The code always looks elegant, I'm just terrible at writing it.

orra2• 5 years ago

Ah, that's interesting.

I'm a huge fan of F#, but I had the advantage of knowing .NET first.

Decabytes• 5 years ago

This was my issue when trying to learn clojure as well

billfruit• 5 years ago

Yes, my experience as well. Clojure is more "lisp for java programmers" than "java for lisp programmers".

Most of introductory material I found was good in explaining functional concepts, lisp approach to solving problems etc, but I thought assumed a working knowledge of the JVM ecosystem.

For someone utterly unfamiliar to Java/JVM world would find clojure extremely baffling, cryptic error messages, needing to be familiar with the rather large java standard library, etc.

7thaccount5• 5 years ago

Same. F#, Clojure, Scala, & Kotlin have all been the same for me. Python's VM is written in C, but I have no reason to know C. In Clojure they have you call out to Java libraries a ton. Someone always tells me that this isn't true on here, but it was my experience as well. Having to learn so many tools like emacs or CIDRE or Leinegen was also a turn off.

pjmlp2• 5 years ago

That is the issue with any guest language, because it is impossible to hide the platform, unless the language is so constrainted that is practically useless.

It is a hard to swallow truth, but guest languages really require understanding of the underlying platform.

Another example, no matter one's opinion on C or JavaScript, mastering them is a much more confortable life on UNIX/POSIX platforms and browsers than trying to pretend they aren't there.

rixkys• 5 years ago

I'm surprised, I found clojure even while I was a pretty much total beginner programmer fairly easy to get into, via clojure for the brave and true at least was very good for getting the basics.

DeathArrow12• 5 years ago

There are several good books like: https://www.amazon.com/Stylish-Crafting-Elegant-Functional-C... and https://www.amazon.com/Get-Programming-guide-NET-developers/... and also some courses on Udemy like: https://www.udemy.com/course/fsharp-from-the-ground-up/ and https://www.udemy.com/course/hands-on-f-application-developm...

Also there are lots of learning resources here: https://fsharp.org/learn/ some for guys coming from scripting languages like Python. As a matter of fact, F# can be used for scripting, too.

7thaccount5• 5 years ago

I'm not saying that you can't write an F# script, but that the path to getting one written is not obvious to those coming from scripting languages that are much simpler than the VAST .NET & JVM ecosystems. There is always some bizarre .NET arcana that gets in the way.

barrenko4• 5 years ago

Kinda agree, but F# works much better for me with my knowledge of .NET than e.g. Clojure with my understanding of Java.

It's a cliche saying, but for me F# just works! (tm)

phillipcarter5• 5 years ago

There's definitely room for a book or blog series along the lines of "F# for python programmers" or something.

Unfortunately there's some level of .NET tooling you need to understand before you can do much today, and several .NET concepts creep in with that.

The good news is that .NET Interactive is shaping up to be a great way to avoid most of that. At least so far all you need to do is install the .NET SDK, then install a VSCode plugin and you're good to go - just write code like you would in a python notebook, and acquiring packages is even easier than in Python: https://github.com/dotnet/interactive#notebooks-with-net

dharmaturtle• 5 years ago

Linking your demo of VS Code Notebooks cause it was great: https://youtu.be/_QnbV6CAWXc?t=1298

devmunchies4• 5 years ago

I had the exact same problem. Even all the http servers had a lot of .net boilerplate to get started. A lot of that should be abstracted. I built an http server library that abstracts the .net parts. https://wiz.run/

The hello world server:

  open Wiz.Server
  open Wiz.Context
  open Wiz.Route

  let myHandler ctx =
    ctx |> sendText "Abra Kadabra Kalamazoo!"

  let myRoutes = [
    get "/" myHandler
  ]

  genServer()
  |> setRoutes myRoutes
  |> run

devmunchies4• 5 years ago

thinking more about it, F# needs to appeal to non-dotnet developers and other developers looking for a functional language for real workloads.

F# currently seems easiest for c# dev to get started, but c# devs have almost no incentive to do so.

Multicomp• 5 years ago

I am building a tabletop game trainer for Star Wars FFG as the RPG Sessions app is incomplete and trying to do all of the things manually or remember every rule + every modifier to the rule + what all of my NPCs stats are is impossible, and thus when one looks things up, it slows down gameplay a lot, especially during battles. Since the whole point of the system is to make battles feel fast and cinematic, and we want to strictly adhere to the rules as written so we are not constantly re-adjudicating (read: bickering over) house rules, we need something more.

Enter F#. I've been working on (yet not releasing a usable version yet bc I'm bad) this program entirely in F#, using Giraffe as the web layer, following the general architecture defined in Domain Modelling Made Functional, and using Dapper to write to a Sqlite database.

F# is amazing. I'm able to fully understand the codebase and follow exactly what happens from HTML Form request, through input validation, through the business logic, down to the database and back to the domain, then rendering out to a JS-free webpage via Giraffe.

It gets tedious doing the marshalling/unmarshalling from HTML form to input DTO to domain type to output DTO to database records to input DTO etc. and I need to learn both how to create DSLs (so users can type in rules from the book and the system will extract the keywords and compose them into the closest equivalent set of conditions and effects the system supports) and lock down my bounded contexts so I'm developing them in order of least to most entity dependencies rather than in order of where I feel I need them most, but I can't see a way where I would be able to build this in plain old C# without all of my above challenges + lots of boilerplate code to ensure my expected invariants are met and someone (me) hasn't changed an invariant out from under me somewhere else without realizing it.

2mol3• 5 years ago

Yeah, those boundaries between beautiful domain type <-> DTO <-> database is also something my team and I struggle with. In the end we're happy with just writing it out, but there is this nagging feeling that it could be more ergonomic.

I'd be interested to hear about other approaches. You could in theory just dump (automatically generated) JSON to the database and evolve your types with tagged versions, but then you have to write some boilerplatey converters between TypeV1, TypeV2, TypeV3, ...

I guess that's the price for staying away from full-blown ORMs?

It reminds me a bit of how in Elm you just suck it up and write the JSON en-/decoders by hand. Annoying at first, but then you get super obvious and maintainable code out of it, which is quite a joy.

de_keyboard4• 5 years ago

It reminds me a bit of how in Elm you just suck it up and write the JSON en-/decoders by hand. Annoying at first, but then you get super obvious and maintainable code out of it, which is quite a joy.

The F# take on Elm coders (Thoth.Json) can use reflection to generate them automatically. This is really useful at the prototyping stage.

iudqnolq• 5 years ago

I kind of like the Elixir Ecto approach where your "DTO"s are mostly plain old data with a single hidden attribute identifying the database table and some other db metadata. They're not live/active, you have to manually pass them to functions to update, but you avoid having two nearly identical types.

muglug• 5 years ago

It has a scripting mode where compilation is done on the fly. This makes it look and feel very similar to python but you still get type checking and much better performance.

This is a really wonderful quality in a compiled language. I wish there were more languages with this attribute (but it’s a lot to ask for).

nestorD• 5 years ago

That feature was actually inherited from Ocaml. Both have a REPL and type inference powerful enough to insure that you never indicate types in Ocaml and rarely in F#.

The experience is close to having an elegant Python with types, definitely worth becoming more popular.

DeathArrow12• 5 years ago

The only thing F# has in common with Python is that it is a simple language. Other than that they are different paradigms.

ur-whale5• 5 years ago

Is there a FOSS compiler for F#?

gameswithgo• 5 years ago

the Microsoft .net core compiler is FOSS, but if that doesn't count there is also mono.

BBC-vs-neolibs• 5 years ago

... to be clear, Mono does not provide F#. Microsoft releases F# for Mono.

ur-whale5• 5 years ago

the Microsoft .net core compiler is FOSS

Oh, I didn't know that.

Very cool.

Can I apt-get the toolchain?

[EDIT]: and for those interested, here's the github repo:

https://github.com/dotnet/fsharp/

Smaug1233• 5 years ago

You can simply contribute to https://github.com/dotnet/fsharp/, the maintainers are very friendly to new contributors in my experience (though the codebase is old and often quite hard to understand).

phillipcarter5• 5 years ago

though the codebase is old and often quite hard to understand

Even some new stuff is like that - and partially my fault, depending on the area :)

That said, some stuff that was REALLY tough to understand was ripped out recently, the "reactor queue" and incremental build system. They were central to how editor tooling works and utterly incomprehensible since they were working around the lack of a free-threaded compiler service. Now the entire compiler is free-threaded, so all the complex machinery to coordinate work is mostly deleted and/or reduced to like 50 lines of straightforward code.

mickjagger• 5 years ago

What does F# do that other languages don’t? What it’s unique benefit?

Smaug1233• 5 years ago

It's just really pragmatic about the upsides of functional programming. It describes itself as "functional-first", but isn't afraid to fall back on OOP in situations where OOP really does model the situation better.

In my mind, it's taken the easiest 80% of the features of a true functional language, but then picked a pragmatic point at which to stop; the result is a language which is easy to learn and also makes it easy to use "most" of the good things you want from a functional language.

brightball• 5 years ago

I believe it's the functional language option on top of .NET. From what I understand, it's a pretty well designed one too.

I don't work in the .NET ecosystem, but I know if came up a lot when I was getting into Erlang/Elixir.

mjul• 5 years ago

Type providers are novel.

It is a mechanism to provide type safe access to structured data and data services with almost no code. It feels like magic.

Like other ML-derived languages (F# is an OCaml dialect) it has algebraic data types and pattern matching to make code simple and complete without missing edge cases.

Also, it is arguably the best functional language on .NET, so it has a great platform with a large ecosystem to build on. And the tooling is great (Jetbrains, Microsoft IDEs).

runevault• 5 years ago

I haven't done as much as I would like with them, but I feel like until someone tries type providers they don't get just how powerful they are. Being able to point to an example .csv file and have it generate the classes for you, and update them if you change said format, in a way that it ensures the types still work, is amazing. And you can do it for ANYTHING as long as you have a way to extract the data to feed it to the compiler.

I still need to learn how to write a type provider just so I can.

aloisdg3• 5 years ago

it is arguably the best functional language on .NET,

it is also the only real one. On .NET we have C#, C++ and vb.net then there are some other fringe langs like IronPython or IronRuby and I think there is a PHP one too.

de_keyboard4• 5 years ago

It's the combination of features which is killer. I don't know of another language that offers all of these:

- Expression orientated

- Lightweight syntax

- Emphasis on immutable data and pure functions

- do-notation (in F# these are called Computation Expressions)

- Type-safety without too many annotations (global type-inference)

- Mainstream ecosystem of libraries (in this case .NET)

- Compile to JavaScript

KurtMueller• 5 years ago

Units of measure is also very cool!

DeathArrow12• 5 years ago

Functional, readable, easy to learn, as performant as C#, has the benefit of huge .NET ecosystem of libraries.

enricosada4• 5 years ago

For me is that pratically every time, if compile, it works.

It's really easy to express a domain (with discriminated union and type) and the defaults (immutability, option, removal of boilerplate, high order function to manipulate data, structural comparison not reference) allow me to write correct code, who is readable without too much friction.

Support a repl as first class, so that works too if you like repl driven development

Community is also nice

bob10292• 5 years ago

If you want to dabble in functional, C# is actually a compelling option now. Switch expressions and LINQ can take you a long way.

I strongly believe that functional programming is not a good fit for 100% of software architecture. The best is some sort of hybrid. Generally, the closer you get to the business logic, the more functional you would want to be. The serializers, http servers, etc. are probably not worth the squeeze to force into a functional domain.

Koshkin• 5 years ago

Sure - C# is the best functional language, while Haskell has already been the best imperative language for a while now [0].

[0] https://stackoverflow.com/questions/6622524/why-is-haskell-s...

GuuD• 5 years ago

I would have to respectfully disagree with you on the serializers part here. For me, after decades of fighting with “magic” stuff, simplicity is the key feature. So, everything that is a simple map function in disguise I tend to stick with functional languages and approaches.

_v7gu• 5 years ago

I think serializers would be better off as railways, allowing you to combine small serializers while also collecting the errors so you end up with a conclusive outcome. Haskell's parser combinators are quite fun for example.

Also I've only used node/elixir serverside, but aren't http servers just a huge pipeline? It fits quite well into functional programming.

bob10292• 5 years ago

aren't http servers just a huge pipeline

Absolutely. At a certain level of abstraction they can be viewed in this way.

How do HTTP servers actually get packets to and from the machine? At some point you have to interact with the operating system. This is not a realm where functional programming is very feasible today.

de_keyboard4• 5 years ago

The serializers, http servers, etc. are probably not worth the squeeze to force into a functional domain.

I used to think the same, but having now tried FP-style libraries for serializers (Thoth.Json) and HTTP servers (Suave), I think they are far superior to imperative or OOP alternatives. The ability to design these things in a declarative style makes the code much more robust and easier to read.

JaggerJo• 5 years ago

dustingetz• 5 years ago

FP is better on a 30 year timeframe but on a next-quarter timeframe probably still has not "crossed the chasm" – you need not just something accessible like ZIO but you need to figure out what it's killer app is, which the FP community currently doesn't have a clue. "HTTP server but more declarative and made with monads" is not something people cannot live without

ghostwriter2• 5 years ago

I strongly believe that functional programming is not a good fit for 100% of software architecture. The best is some sort of hybrid.

Haskell would be a better language in every domain where C# is applicable. That is from a language perspective, abundance of libraries is a different question, as it's a matter of the community size and attention.

dboreham4• 5 years ago

I think enforced purity is problematic (although obviously useful for some purposes such as program correctness proofs). I still want to be able to write:

doThing1();

// thing1 has finished

doThing2();

Where the functions block. Async and Monads and Futures and all are useful for some things, but mostly I just want to do stuff sequentially, blocking, and not confuse myself.

Scala allows this, although the widespread Future-ification of libraries makes it hard to actually practice.

grumpyprole3• 5 years ago

The creator of LINQ, Erik Meijer, wrote a fun article "The curse of the excluded middle: Mostly functional programming does not work". Yes it's tongue-in-cheek and highly provocative, but many of his points are true. There is a lot more yet to be learned from functional programming than LINQ and switch expressions.

https://queue.acm.org/detail.cfm?ref=rss&id=2611829

aranchelk• 5 years ago

Is it meant to be tongue and cheek? I personally didn’t get that impression. I assumed he was using the non-religious meaning of “fundamentalist”: strict and literal adherence to a set of principles.

feoren• 5 years ago

This is such a weird article. All of his examples are insane strawman non-idomatic C# code, and then he complains when they don't do whatever he decides "an average programmer" would expect them to do. Huh? They were all either doing exactly what I expected them to do (silly things), or were so strange and alien that even Visual Studio has no idea what to do with them! I've never seen anything like that Cell<T> example and it doesn't come close to compiling. What a weird, weird thing to do: write code that literally does not compile and then complain about it!?

wyager• 5 years ago

The serializers, http servers, etc. are probably not worth the squeeze to force into a functional domain.

These are two examples I would probably come up with if you asked me “where does FP thoroughly beat imperative?”

(De)Serializers - parser combinator libraries like attoparsec absolutely BTFO imperative parser libraries in most dimensions. Bidirectional codec libraries like haskell’s Binary, Serial, Aeson[1] are top-tier. Functional formatters like Blaze are top-tier as well.

Haskell’s HTTP ecosystem is massively better than anything else I’ve used, and I went on a binge of trying a ton of HTTP servers like 6 years ago (in python, ruby, C++, Go, and finally Haskell).

[1] https://github.com/lovasoa/bad_json_parsers

mumblemumble3• 5 years ago

I agree that 100% functional is not necessarily the way to go. That said, I am a big fan of F#'s "functional first" ethos, which drives you toward that sweet spot of a functional core inside of an imperative shell.

With C#, when I'm trying to use functional design, I often feel like I'm swimming against the current. The language has functional features, and it will certainly let you use them, but, LINQ aside, the path of least resistance is mostly imperative and object-oriented.

In F#, it's the other way around. It has a full suite of object-oriented features - still, after all these years, quite a bit more complete than C#'s suite of functional features - but the path of least resistance is mostly functional.

I don't want to say that's a universal best way to have things. But it suits my taste, because it makes the easiest way to do things correspond very closely with the way I like to see things done: distinct and well-distinguished layers of functional and object-oriented code, sorted according to where each is of the most utility. C#, by contrast, tends to guide you toward a foamy lather of functional and object-oriented code with no identifiable organizing principle.

barrenko4• 5 years ago

This is the same issue I have with Javascript. If you don't have to use something, you just won't, or maybe I'm just lazy.

kevinmgranger• 5 years ago

I think it's really hard to properly define "functional programming" concretely, but I'll partially agree. If all a language takes from FP is:

- make composition ergonomic, idiomatic, and easy (including the usual iterator map/reduce, etc.)

- let the type system protect you (including nullability)

Then you've already got the most important strengths, in my opinion.

grumpyprole3• 5 years ago

Functional programming is not just programming with closures. It's about "referential transparency". Referential transparency permits higher-level mathematical reasoning, which leads to safer/better program composition, optimisations, caching/reuse and parallelisation/concurrency. If you are willing to concede mutable-state and other uncontrolled effects, there is much to be gained.

JoelMcCracken4• 5 years ago

I initially believed this, but I have come to realize that pure functional programming is transformative for both business logic and infrastructure. Its a lot easier to get started in the business logic side; dealing with effects in the context of pure functions is a lot to figure out, I don't even know if you really can do it in not-haskell. But, via Haskell I have been able to achieve far greater levels of producitivty in these tasks than ever before.

The main downside is that its a lot to learn, and it takes a good while before you get productive. But I am absolutely more productive now in Haskell than just about anything else, save perhaps ad-hoc text munging task; the shell DSL is just so handy for random one off stuff.

enricosada4• 5 years ago

C# switch are just syntactic sugar. nice for sure.

But if you compare F# with C#, is not just LINQ .Select vs List.map

And i am not speaking about function, who is just a part of why i like F#, not the best one

Is the different defaults who matter, who guide you to an easier code who highlight the domain

- structural comparison vs reference comparison - expression vs statement based - immutability

C# will catchup with some features for sure.

Lot of new C# feature remove boilerplate (file scoped namespace, etc) and is a good trend

But the core defaults will be the same.

That will not push to a single direction (if fact you have LOTS of way to write the thing in C#) while F# try to push to the same way

To do so, C# continue to add thing to the LANGUAGE. Now is a lot more complicated than .NET 2.0

While F# try to do the same, but the language doesnt change.

An example: the async/task.

C# added the async as keyword, plus all needed to make it work, and the compiler generate special code.

F# has built that from the general computation expression feature and (recently) the state machine support.

DeathArrow12• 5 years ago

If they keep adding features to C# I hope it won't become the Frankenstein monster C++ is.

73313• 5 years ago

I really wish they put more priority on bringing discriminated unions into C#.

Seems like the most significant thing they could do.

I've spent so much time looking into using languages like Rust, Haskell, F# pretty much just because I want a compiled language with DUs. But always lose interest due to more practical requirements like tooling and package ecosystem.

If C# had them, I could stop looking. I would basically use it for pretty much everything except web stuff. And that's coming from someone who used to be very anti-MS. To me C# does everything I want in a language, except for lacking native simple DUs.

There's lots of cool things I've learnt about in FP languages. But discriminated unions are really the only feature that I feel like I'm really missing out on in other languages.

I strongly believe that functional programming is not a good fit for 100% of software architecture. The best is some sort of hybrid.

And yeah I agree with you. FP is awesome at many things, but not everything. I went down the FP rabbit-hole, it was a and I had many revelations. But once the excitement wears off, I realised that I still like using classes for some things that are just inherently mutable... e.g. GUIs, and progress bars, SQL transactions etc.

Not to mention that being able to type `someObject.` and then get autocomplete for all its methods is a huge time saver, and something that is quite a lot more painful with pure FP where you're much more reliant on your memory and looking things up to find all the functions for something.

I think Rust did really well in balancing the two. I just want Rust's simple struct instantiation and enums in C#, and I could stop wasting time looking for the mythical "perfect language".

JoelMcCracken4• 5 years ago

You may be interested in (for example) the approach taken with Halogen, the PureScript web framework. Every widget on the screen has its own state and actions, widgets send each other messages, etc. It ends up being very "object oriented" in a way that you're suggesting, but it also is very principled, i.e. components send each other messages, do not have access to each others internal states, etc. This gives you a really good way to separate concerns, while having each "widget" have its own state/not having to have a single global state a la elm.

u2c4m6• 5 years ago

Lack of discriminated unions and single case unions make C# a no go if you want to fully scratch the functional itch

codingclaws• 5 years ago

This is off topic. I can't resist - that's the thickest sticky header I've seen from a developer.

gorgoiler2• 5 years ago

Yes, hah, I too was impressed with the chutzpah of having…

“DANIEL”

…on a substantial amount of my screen throughout the whole read.

infogulch• 5 years ago

There was a recent thread about Algebraic Effects in OCaml [0]. Does F# have something similar?

[0] https://news.ycombinator.com/item?id=28838099

Smaug1233• 5 years ago

No. It has lightweight syntax ("computation expressions") you can use to sugar monads, but no effects system.

xvilka• 5 years ago

It lacks many things that OCaml has. On the other hands, units support is awesome, I wish there would have been more attention to that, and more popular in other languages as well.

eatonphil• 5 years ago

I've had good experiences running F# on Linux. I used it to build an API generator from database schemas [0]. Similar to Go you can get a single static binary you can copy anywhere.

It's very convenient and you've got a massive number of .NET APIs to fall back on.

The language is a little complex though. That you cannot call interface methods on an object implementing the interface without explicitly casting to the interface [1] is pretty weird. And getters/setters are a little complex.

If you want an easy introduction to the ML family for educational/historic sake I'd always recommend Standard ML. But if you want a highly pragmatic, mature, strictly typed, compiled, cross-platform language F# is pretty compelling.

[0] https://github.com/eatonphil/dbcore

[1] https://docs.microsoft.com/en-us/dotnet/fsharp/language-refe...

phillipcarter5• 5 years ago

The language, in general, wants you to be explicit about what you're working with. So implicit access to interface members isn't a thing, you need to say that "x is this interface type" or cast.

In F# 6 things are changing a bit, and may possibly change in the future. There are various classes of cases where the type information is known, but the compiler still required you to explicitly cast things to be happy. That's no longer case. This link[0] has 3 examples that don't compile with F# 5 but will compile with F# 6.

[0] https://sharplab.io/#v2:DYLgZgzgNALiBOBXAdgHwPToAQFMAeAhgLYA...

Dayshine• 5 years ago

Implicit upcast? That's amazing, I feel like that's going to help a lot with many branched functions.

TravHatesMe• 5 years ago

implicit access to interface members isn't a thing, you need to say that "x is this interface type" or cast.

If the compiler already knows that it implements interface X Y and Z, it seems unnecessary to require it (unless those interfaces have conflicting names, in which case you would have to be explicit due to ambiguity).

I feel like many languages are walking away from being so explicit, in particular I've noticed C# becoming more implicit over the years.

nextos• 5 years ago

It's also important to add F# is an inspiration for an amazing MS Research effort, F* [1].

Furthermore, it is also worth checking Dafny [2] (Spec#'s successor). The relationship between Dafny and C# is equivalent to the relationship between F* and F#. Both languages try to refine their predecessors semantics and augment them with practical constructs to prove program correctness.

Some of the largest software artifacts ever verified have been implemented in Dafny [3], and F* is also looking quite promising.

[1] https://www.fstar-lang.org

[2] https://dafny-lang.github.io/dafny/

[3] https://www.cs.columbia.edu/~junfeng/17sp-e6121/papers/ironf...

amw-zero• 5 years ago

What makes you say that F# is an inspiration for F? I recently went through the F tutorial and saw no mention of that. Obviously F* is an ML, but it seems more like Ocaml than F#.

73313• 5 years ago

Why oh why are people still putting special characters in the names of programming language?

# . + are bad enough... but * ?!? It can't even be used in filenames at all.

And while Google might be ok at indexing it... pretty much every other fulltext search engine will be useless. Not to mention it can't be used in package names, domain names, filenames, and a heap of other things.

Even an emoji (while still terrible) would be better under some circumstances.

"Go" was ridiculous enough, ironically from somebody who works at Google. But these people still putting special characters in the names must really not care about findability/disambiguation at all.

PHP might have got a lot wrong... but the name is great... it's just "PHP" everywhere, even the filename extension.

alexvoda• 5 years ago

How does Dafny compare to M#, the unreleased language used for project Midori?

beecafe• 5 years ago

at least they picked cute bird face emoji for it :>

foepys• 5 years ago

That you cannot call interface methods on an object implementing the interface without explicitly casting to the interface [1] is pretty weird.

That's probably because in C#/.NET you can specify methods that are only valid when being used as this exact interface. Those are called explicit interface implementations and can contain completely different code than the class method.

https://docs.microsoft.com/en-us/dotnet/csharp/programming-g...

JayGuerette• 5 years ago

His claimed inspiration, Hillel Wayne’s post “Why Python is my Favorite Language”, is a piece of fluff that basically says "I only like the things I already know". I was so uninspired, I couldn't read further.

loic-sharma• 5 years ago

You fault an article for being superficial while yourself only giving a superficial read? I hope you see the irony and reconsider.

StreamBright• 5 years ago

F# has become my default goto language. It is absolutely amazing to create cloud services in it an I have a small ETL tool as well. I would not trade it for anything else.

AtNightWeCode• 5 years ago

In my area there was a huge push for functional programming and F# some years ago. A long time ago since I heard anybody working with F#. Clojure is somewhat popular though in fintech.

Functional programming is something I think one should learn cause the concepts are useful in other programming languages too. Over time what is useful in functional programming languages will be available in other languages. In fact, a lot already is. Functional programming is not an USP in my world.

When I started with C#, code bases were full of GoF patterns, if and switch statements were banned, there were hierarchies of inheritance, there were states spread out and encapsulated everywhere, static functions were banned. Today, code bases are mostly stateless except for things that needs to be reused, there are pure functions everywhere, inheritance is mostly used in libraries and where interfaces can’t be used (yet), switch is ok and pattern matching is around the corner in several languages.

More unpopular opinions. Immutability is overrated. In some programming styles, in some old languages there was a high risk of changing something by accident. Typical cause people did not know if they were working on a reference or a copy. Also, it was common to change fields on purpose. This problem does not really exist in a lot of programming languages today. But I do wonder if Go coders code benefit from some more immutability.

I think the future of F# looks very dark but the functional style of programming will for sure have its place. What could change this is if F# really excels in some area like Go have done.

DeathArrow12• 5 years ago

After null, the worst calamities that hit the software world are Uncle Bob's principles and GoF patterns.

I mean what is more exciting than having to deal with FactoryFactoryFactory and AbsteactFactoryVisitorBuilderProxy written by others?

Having forced OOP is bad enough by itself but people found ways to make software development even worse.

jgwil2• 5 years ago

Link to What I wish I knew when learning Haskell is broken because it has https. The correct link is http://dev.stephendiehl.com/hask/ in case anyone was looking for it.

barrenko4• 5 years ago

When I learn Haskell, I'll be lot closer to God.

DeathArrow12• 5 years ago

God uses assembly.

psd12• 5 years ago

Molecular biology is implemented in perl.

steve76• 5 years ago

Scott Wlaschin’s fsharp for fun and profit is one of the best functional programming resources I know across all functional programming languages.

Hey! Someone else saw this. Very underrated resource. Also Professor Frisby's Mostly Adequate Guide to Functional Programming needs more attention too.

Things I would add:

1. Start off with what types you need, not functions. Creating your types like the tools you need to do the job. Then build combinators. Convert one complex type to a primitive. Then a primitive to your type.

2. Once you have your types, it's not that difficult to make them functional. You just make methods for "of", or "chain", or "map", or "ap". Now you have monadic and applicative interface.

3. The functional part is just like when a shell drops to a program's prompt, like >ftp and >mysql. You setup a series of commands like that, with Either or Task or Fold. Provide input, prepare a list of commands, and then run them when everything is valid and ready.

4. Bundle size is a problem for web. Until tech improves and bandwidth prices lower, 100 KB on a high volume website is a problem. Nothing wrong with taking a proven solution, like wordpress, and caching it.

5. Property based testing is for under the hood, your types and combinators. It's not something you do with Cypress or units. All that input is type unknown, and needs validation before going to what's coverage under property based testing.

6. One fault that always occurs is trying to use Runtime encoding to build some extensible modular program. Don't do that. Types are for build. Validation is for runtime. If it doesn't validate, show a user a message. Don't try to build some hot swappable modular program, where types are read from input. If they want to program the computer, they can install the IDE.

rcarmo• 5 years ago

Pretty much on point. I've been building a .NET, bootstrapped webapp (i.e., no Razor, no "cargo culting" so I can actually understand things from the ground up) piecemeal, every other weekend, in both C# and F#, and, like Java before it, _understanding the ecosystem and libraries_ is critical.

I can read OCaml and dabbled in it, but that doesn't help me write substantially better .NET because I will be iterating over lists or graphs in a different way, handling IO (and sockets) differently, etc.

But I can see how someone conversant with C# and the .NET ecosystem would really like F# since the barrier to entry is substantially lowered, and the code is just so much nicer and tidier.

Shame there isn't a proper AOT-compiled LISP for .NET (no, Clojure doesn't count, I never managed to get the .NET version to work for me).

AlbertCory• 5 years ago

That it's the same as Gb (on a piano or fretted instrument)?

(Sorry. Couldn't resist.)

chalst• 5 years ago

The main thing I found strange about F# was that, having prior familiarity with Ocaml and SML/NJ, was that what F# calls modules are completely unlike the module system of any other ML-inspired language, being instead an adaption of C# classes to serve F#'s namespacing needs. Since the module system is of similar importance to code reuse to Haskell's typeclasses,the relative deficiencies of F#'s module system hurt.

vasergen• 5 years ago

I wish I have Elixir with types like in F#

Rapzid2• 5 years ago

I wish F# had a project comparable to Phoenix to boost its visibility.

DeathArrow12• 5 years ago

It has Giraffe, SAFE stack, Fable, Bolero.

gorgoiler2• 5 years ago

What’s the best way to play with F# that feels natural for a Python programmer?

I really like having my screen split down the middle (tmux), with code on the left (“vim code/“) and program output on the right (“watch-exec code/ — python -mcode”).

Every time I change a file in code/, watch-exec runs the program again.

Doing this with dotnet run seems to take a full 2 to 4 seconds to run though, which seems pretty heavyweight. It’s obviously not the best way to interactively edit a file of code. What is?

2mol3• 5 years ago

Yes! Those couple of seconds wait-time are a big bummer for that style of fast-feedback coding (for which there is the built-in `dotnet watch run` by the way).

Made me sad when I was playing around with generative art, where you would really want to see the result of your changes in a split-second.

You can check out ".NET Interactive Notebooks" in VSCode, that executes much faster, but it doesn't do this live watch.

dunefox2• 5 years ago

The obvious solution is not to compile your project with every change. See F# interactive: https://www.jetbrains.com/help/rider/FSharp_interactive.html

akra2• 5 years ago

Yeah I think 'dotnet fsi {fileName}' with a script file works. Also Ionide with VS Code using Alt+Enter (similar to other language VS Code repl's) inside a *.fsx script file to run the highlighted code in a F# REPL. F# Interactive has doco online as well that isn't that long but covers most things (single commands, script files, loading packages, etc).

dunefox2• 5 years ago

I like F# quite a bit, but the main selling point for me besides my algorithm stuff would be data science/ML. Sadly, the F# libraries like the R Type Provider, JSON Provider, etc. don't seem to work.

What I wish I knew when learning F#

Related Stories