Why F# evangelism isn't working (2015) • Hacker News Board

Re: Why F# evangelism isn't working (2015)

#141

Post by rgbgraph » Wed, May 31, 2023, 7:18 AM UTC

ThinkBeat wrote: post #126

systems wrote: post #84

Earlier quoted context omitted.

I don't think it matters how good or bad C# is, Object Oriented Programming is a mess Learning, how to use an Object System (a tree of objects/classes) is inherently hard The current problem with F# is that it doesnt do enough to shield you from objects, it does what it can, but still to use F# effectively, you still need to learn some C# and a lot of API that basically Objects inside Objects inside Objects calling O…

Every system if allowed to become too complex. No single paradigm of programming is perfect for all cases. OO is one way to structure and model a system. No matter what language you use will end up with some form of a struct, a set of values that belong together Then you will have list of some structs and trees of some structs You will almost certainly have to create list/collections/groupings of structs. Because tho…

Just like every language is able to be slow/non-performant -- but OO in this case would be Python in a web context; it doesn't invalidate that a good amount of OO codebases in the wild devolve into incomprehensible black boxes, where no one has any idea what anything does or how to make meaningful changes that fulfill the intent of (compare that to iterative programming, where you can atleast read it)

A list: I give you a vector. Plain and simple. Not this insanity: https://referencesource.microsoft.com/#mscorlib/system/colle... [0] You do not need OO to create a vector (or even an array -- god forbid!)

As for trees: roll your own. They're simple enough, yet tightly-coupled with context that no generic implementation exists that is flexible enough. You do not need OO to create a tree. C has been working with trees long before the current Frankensteination of OO was even a twinkle in Gosling's eye.[1]

Data structures do not need inheritance -- they might need delegation (message passing that requires you to actually think about your system).

Data structures do not need encapsulation -- they most likely need namespaces. Realistically, most classes will be used as namespaces.

Data structures do not need polymorphism -- just implement the members you need, and name them appropriately (no 5+ word phrases, please. Please!)

What modern OO does is lower the barrier to productivity in the present, and then pays for it in the future. It's no different than writing your "planet scale" backend system in JS.

[0] Compare to: https://gcc.gnu.org/onlinedocs/gcc-4.6.3/libstdc++/api/a0111...

[1] If you want to know why we have Java: some guys that didn't have the time to think about low-level (memory management specifically) things for their embedded applications, got sick of trying to learn C++, decided to make their own language. That's it. There was no grand plan or thoughtful design -- it's just a mismash of personal preference. The same people that described C++ as "being too complex" (fair) and using "too much memory" (lol)

Re: Why F# evangelism isn't working (2015)

#142

Post by chromoblob » Wed, May 31, 2023, 7:21 AM UTC

2h wrote: post #42

xupybd wrote: post #37

I love F#, I use it professionally. But I agree with everything written in this post. I hate that F# is not a safe choice yet. I wish that it were but it doesn't have the critical mass. That means hiring others is not going to be as easy as finding an existing F# developer. Functional programing is different. I don't think it's hard but it's not what most developers have spent years practicing. So there is a learning…

> Functional programing is different. I think the problem with this line of thinking is that some people insist on using functional tactics EVERYWHERE, even when it doesn't make sense. I get that its ugly to mix functional and imperative code, and maybe some languages dont even allow that. but they should. thats why I like Go, because sometimes a simple for/while loop IS the correct answer.

Loops aren't inherently imperative or functional, they can be easily expressed in both imperative and functional paradigms, with or without side effects. Although using map (loops without dependencies between iterations) is more easily parallelizable.

Re: Why F# evangelism isn't working (2015)

#143

Post by KingMob » Wed, May 31, 2023, 7:25 AM UTC

waffletower wrote: post #90

throwaway2037 wrote: post #67

Earlier quoted context omitted.

There is much naïveté among the strongly typed herd. Is exactly the reverse also true? Let me try: "There is much naïveté among the weakly typed herd." For every person who thinks Python or Ruby can be used for everything, there is another person who thinks the same for C++ or Rust. Also, the example that you gave is incredibly specific: When tasked to create glue code translating between two opposing type systems, w…

If you are truly interested in understanding my point of view -- a great way to do it would be to learn how to use this Clojure DSL: https://github.com/redplanetlabs/specter You could also think about why Nathan Marz may have bothered to create it. As for data engineering, I think ChatGPT could tell you a lot , and its training is dated from 2021.

As someone who tried very hard to incorporate specter into their speech-to-text pipeline, I feel compelled to point out, it gave me a lot of NullPointerExceptions while learning. I don't think it's a great example of the value of dynamically-typed langs.

In retrospect, Marz's hope that specter might get incorporated in clj core was wildly optimistic (even if the core team wasn't hostile to outsider contributions), because it feels like he built it to his own satisfaction, and never got around to removing the sharp edges that newcomers cut themselves on.

It's a shame, because I think specter is a cool idea, and would love to see a language based on its ideas.

Re: Why F# evangelism isn't working (2015)

#144

Post by michielr » Wed, May 31, 2023, 7:26 AM UTC

pharmakom wrote: post #131

ericsink wrote: post #68

(Author here) Well this is a blast from the past. Back when I wrote this, I kinda hoped F# would surprise me and gain more traction than I expected. But 8 years later, if anything, it seems like the dominance of C# in the .NET ecosystem has grown. F# is still a great language, but the main fact hasn't changed: C# isn't bad enough for F# to thrive.

I used to write lots of C#, but now I consider it a bad ecosystem. The problem is the amount of ceremony, silly OOP abstractions, dependency injection, etc. Just look at building a simple HTTP endpoint in C# compared to Node or even F#!

I agree this was a problem, but with the current Minimal API's, there is no boilerplate, looks a lot like Express to me!

  var builder = WebApplication.CreateBuilder(args);
  var app = builder.Build();
  app.MapGet("/", () => "Hello World!");
  app.Run();

Re: Why F# evangelism isn't working (2015)

#145

Post by whizzter » Wed, May 31, 2023, 7:29 AM UTC

rawling wrote: post #140

pharmakom wrote: post #131

Earlier quoted context omitted.

I used to write lots of C#, but now I consider it a bad ecosystem. The problem is the amount of ceremony, silly OOP abstractions, dependency injection, etc. Just look at building a simple HTTP endpoint in C# compared to Node or even F#!

> Just look at building a simple HTTP endpoint in C# compared to Node or even F#! It's... basically the same? Include library, create server object, tell server object what request to handle and what to return, start server object. https://learn.microsoft.com/en-us/aspnet/core/fundamentals/m...

Yeah, you can get away with minimal C# stuff if you want. Mind you minimal API's is a relatively new thing as of NetCore 6 so GP might not have had the chance to touch these new things yet.

Much of the older overdesigned pain of C# is that it used to be tied to how IIS wanted things to work, NetCore initially pivoted more to DI stuff before pivoting again to these minimal API's but the DI stuff is definitely available(and used) still.

For pragmatic choices it's all there, you can start off with minimal API's and get far with it and once you start feeling pain-points as you want to re-implement things it might be time to add in the more "frameworky" parts.

Re: Why F# evangelism isn't working (2015)

#146

Post by lelanthran » Wed, May 31, 2023, 7:31 AM UTC

systems wrote: post #84

ericsink wrote: post #68

(Author here) Well this is a blast from the past. Back when I wrote this, I kinda hoped F# would surprise me and gain more traction than I expected. But 8 years later, if anything, it seems like the dominance of C# in the .NET ecosystem has grown. F# is still a great language, but the main fact hasn't changed: C# isn't bad enough for F# to thrive.

I don't think it matters how good or bad C# is, Object Oriented Programming is a mess Learning, how to use an Object System (a tree of objects/classes) is inherently hard The current problem with F# is that it doesnt do enough to shield you from objects, it does what it can, but still to use F# effectively, you still need to learn some C# and a lot of API that basically Objects inside Objects inside Objects calling O…

> OOP is bad because eventually OO systems becomes too complex, OO API is intimidation

This strikes me as a sort of ... reverse of survivorship bias.

You look around and see all complex systems are in OO, then you conclude that it is OO that is the cause of the complexity.

Have you considered that the non-OO designs are deficient in some way that prevents them from being used for the type of systems that you find to be examples of OO being bad?

Not that I am defending OO, I just want to know how you are differentiating between "OO produces complex systems" and "OO is used for complex systems".

Re: Why F# evangelism isn't working (2015)

#147

Post by arwhatever » Wed, May 31, 2023, 7:34 AM UTC

Fervicus wrote: post #44

I love C# and it keeps getting better and better, but I don't get the same level of satisfaction with it that I do with F#

Im pretty fond of C# as well, but pretty often the type system feels like it leaks like a sieve compared to F#.

Re: Why F# evangelism isn't working (2015)

#148

Post by tigershark » Wed, May 31, 2023, 7:39 AM UTC

heywhatupboys wrote: post #103

CrimsonCape wrote: post #91

Earlier quoted context omitted.

I empathize with your characterization of "a tree of object/classes" and I yearn for an example of how else to model a complex, domain-specific system not using the aforementioned tree.

well you see! What we can do is to namespace our functions, e.g. by naming them component_create, component_add_button, etc. We then create a plain dictionary with key value pairs that gets passed onto these functions! The functions then possibly return a new map, which is a modified map! This allows us to write code like dog = dog_create({name: "foo", age: 12}) dog = dod_add_friend(dog2) print(dog["friends"]) and we…

This tells me that you never really looked at functional languages, not even used them. The power of ADT, especially when using a comprehensive pattern matching expression, is pretty difficult to emulate in the OOP world without a ton of code. But in this extremely simple case you just need a record.

    let dogBar = {Name = “bar”; Age = 11; Friends = []}
    let dogFoo = {Name = “foo”; Age = 12; Friends = [dogBar]}
    printfn “%A” dogFoo.Friends

The advantage is that it’s immutable and it’s guaranteed to don’t have null in any fields. C# only introduced records recently, while F# was born with them. And C# still hasn’t got ADT because it’s missing the Union types as far as I remember.

Re: Why F# evangelism isn't working (2015)

#149

Post by KingMob » Wed, May 31, 2023, 7:40 AM UTC

throwaway2037 wrote: post #72

lostmsu wrote: post #49

Earlier quoted context omitted.

Rust might take its place if the tooling would be on par. Personally I'd jump.

You are the first person I have heard mention the desire to transition from C# to Rust. Usually, it is C++ to Rust, or Java to C#. if the tooling would be on par I am betting person, and I say: "It never will be." It is easy to overlook the importance of better developer tooling. It directly translates into higher developer productivity. Every time I am forced to use a language with worse developer tooling, I am remi…

Agreed, I think people are sleeping on the relative disparities in tooling between langs, and it will only get worse.

I feel this daily as a Clojure programmer. I've been playing with Copilot, and it's astonishing how much worse Copilot is at generating Clojure code, than say, Js. The difference is probably due to training volume, and if AI-assisted coding is worth it at all, the benefits will primarily accrue to the largest languages.

Re: Why F# evangelism isn't working (2015)

#150

Post by Zecc » Wed, May 31, 2023, 7:42 AM UTC

systems wrote: post #84

ericsink wrote: post #68

(Author here) Well this is a blast from the past. Back when I wrote this, I kinda hoped F# would surprise me and gain more traction than I expected. But 8 years later, if anything, it seems like the dominance of C# in the .NET ecosystem has grown. F# is still a great language, but the main fact hasn't changed: C# isn't bad enough for F# to thrive.

I don't think it matters how good or bad C# is, Object Oriented Programming is a mess Learning, how to use an Object System (a tree of objects/classes) is inherently hard The current problem with F# is that it doesnt do enough to shield you from objects, it does what it can, but still to use F# effectively, you still need to learn some C# and a lot of API that basically Objects inside Objects inside Objects calling O…

>If the only flaw in C# is knowing which method calls requires the new keyword because its a constructor, and which dont because its a factory, that is bad enough to want to avoid it

I'm sure this is just an example popping first out of your mind, but it seems like an oddly specific thing to mention. Specially since the answer is obvious if you know C#: the name of the method matches that of the type if and only if it is a constructor.

I won't comment on the rest of your post as my experience with F# is minimal; but I think I understand where you're coming from.

> Separating Data from Behavior manages complexity better

There's a sweet spot, and it varies. Sometimes it is difficult to find. API design can be difficult. Managing complexity is sometimes itself a complex process.