Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why F# evangelism isn't working (2015)

ericsink.com

Post reply on HN
Print view View original

311–320 of 333 posts

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

#311

Post by jstimpfle »

magicalhippo wrote: post #307
jstimpfle wrote: post #302

Earlier quoted context omitted.

IMHO that is of such little help and the drawbacks weigh much heavier: const-correctness spreads like a cancer (try making one thing const without having to fix a hundred other things), and often requires annoying boilerplate -- I'm no C++ expert but if these are still the best available solutions...: https://stackoverflow.com/a/123995/1073695 Sometimes I want to add one little extra thing that gets mutated in an oth…

Perhaps it depends on the code-base. I worked on a medium complexity C++ project (~300kLOC) but which used multi-threading quite heavily with shared data structures, and there was only a couple of instances where I felt it got in the way. In the vast majority of cases it reduced my cognitive load significantly because I could just look at the method declaration and see that my code would be fine.

Yes, as always it all depends on the context and how features are used. Maybe I was just bitten too often in situation where const is particular gnarly to use. I know for sure that in many cases, such as when calling small helper functions for copying a shallow array and such, one can easily pass pointer as pointers-to-const.

However, IME there is a big problem with const for more database-y, more stationary in-memory data. This is the kind of data that is almost always going to be mutated by at least some part of the code at some point in time. There is a fundamental problem of communication between mutating code and non-mutating code (the "strstr()" function, that has to apply a const-cast hack internally to implement its interface, is a trivial example here).

As said there are certainly situations where such "communication" isn't needed, but I'm anxious about precluding the possibility in the name of const-correctness.

I feel that instead of const (or whatever static formalized description of what a function is doing), good naming is most helpful to intuit broadly what that one function was doing again.

In C at least, I've ended up leaving const almost exclusively for the cases where the data is truly const - i.e. in the .ro section of the binary, and I know for sure it won't ever have to be modified, and basically I have to apply the const qualifier lest it puts the data in the wrong section / it needs an awful cast to remove the const. The majority of those are string literals typed as "const char *".

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

#312

Post by jacquesm »

tombert wrote: post #214
jacquesm wrote: post #170

Earlier quoted context omitted.

One of the main issues with this is that OO as practiced in C# and Java is only a very thin extract from the real OO as provided by for instance Smalltalk. And without that kind of environment you end up with the worst of both worlds, where you have an OO like interface layered on top of things that aren't really objects to begin with, because they aren't 'alive'.

I feel this kind of argument is a bit pedantic though; when people complain about OOP, they're generally complaining about the mainstream implementations of OOP. I don't think that people people are really considering Smalltalk's OOP style when they complain about Java OOP.

This is far from pedantic. Calling something OOP when it isn't is a huge part of the problem.

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

#313

Post by aksss »

jacquesm wrote: post #170
lelanthran wrote: post #146

Earlier quoted context omitted.

> 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…

One of the main issues with this is that OO as practiced in C# and Java is only a very thin extract from the real OO as provided by for instance Smalltalk. And without that kind of environment you end up with the worst of both worlds, where you have an OO like interface layered on top of things that aren't really objects to begin with, because they aren't 'alive'.

Very good observation but I do wonder whether it’s the worst of both worlds or the best of both worlds - more the “eat the meat and spit out the bones” approach?

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

#314

Post by aksss »

pharmakom wrote: post #137
waffletower wrote: post #60

Earlier quoted context omitted.

There is much naïveté among the strongly typed herd. When tasked to create glue code translating between two opposing type systems, which is a very common data engineering task, reaching for a strongly typed language is never the best option for code complexity and speed of development. Yet the hammer will often succeed if you hit hard enough and club the nail back to shape when you invariably bend it.

I have found that types are a benefit when it comes to debugging complex data systems because it moves component failures closer to the root cause. Relevant blog post is Parse don't Verify

Parse Don’t Validate? https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...

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

#315

Post by aaronmu »

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.

> F# is still a great language, but the main fact hasn't changed: C# isn't bad enough for F# to thrive.

C# will always be more popular because it easier to learn. Why? Because it looks familiar to most developers. Why would you learn this unfamiliar thing called F# if C# is right there and you basically already know it? On top of that, C# almost has feature parity with F#.

However, F# is a simpler language than C#. That is a fact. It has less concepts that you need to learn. I've found that onboarding someone in an F# codebase takes a lot less time compared to onboarding someone in a typescript,C#,... codebase. A lot less time. I've found that new people can start contributing after a single introduction. The things they build often just work.

I think that an F# code base costs a lot less money to maintain over longer periods of time. Can't prove it but I think that the difference is huge.

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

#316

Post by vladvasiliu »

sph wrote: post #310
vladvasiliu wrote: post #305

Earlier quoted context omitted.

> is it cool enough to want to feel a second class citizen, running it on the OS and platform it is not intended to run on? I'm not a software engineer myself, nor a Windows person, so I don't know the specifics, but FWIW, my client runs production .Net code of the C# variety on Linux, connected to pgsql. It's some kind of web service for checking people's tickets (think airport gates where you scan your ticket to en…

I do get it. .NET now works pretty well on Linux. But it never was a tier 1 platform during its growth. So most non-Windows devs put their focus on other platforms. There is nothing wrong with that. I could learn .NET now , but I don't really have an interest to do so at this point; Also, the devs you talk about are on Windows, using their tier 1 IDE (Visual Studio) that only runs on Windows, which is my point exactl…

That's a fair point. Tooling is an important aspect of a language, at least for me. I don't know what the VS Code on Linux experience is like for .net.

I tried to dip my toes into F# out of curiosity, and it worked by following some tutorial and VS Code. But it did seem somewhat bare bones. Although I'll admit I'm spoiled by Rust and IntelliJ.

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

#317

Post by bazoom42 »

throwaway2037 wrote: post #304
bazoom42 wrote: post #245

Earlier quoted context omitted.

You can’t do monkeypatching or dynamically modify the inheritance chain of an object in a statically typed language. But yes, you can have a JsonNode type, which is still better than having every type being “object”.

About monkeypatching, perhaps we have difference definitions. From time to time, I need to modify a Java class from a dependency that I do not own/control. I copy the decompiled class into my project with the same package name. I make changes, then run. To me, this is monkeypatching for Java. Do you agree? If not, how is it different? I would like to learn. Honestly, I discovered that Java technique years ago by acci…

Monkeypatching is programatically adding a method to a class at runtime.

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

#318

Post by lostmsu »

pjmlp wrote: post #244
lostmsu wrote: post #226

Earlier quoted context omitted.

Eh. It is vast, but the tide is shifting. Non-UI components were never that good. WPF is in maintenance mode. And there is a growing need for deep learning which is currently a total lackluster in .NET

Still, more likely to be Python and C++ than Rust. See ONYX, DirectML and ML.NET announcements at BUILD.

Python and C++ aren't replacements for C# due to different issues with them (which are not present in Rust).

Neither ONNX, nor DirectML, nor ML.NET excel at deep learning. TorchSharp is the closest to what is needed for the modern ML work, and there is almost no investment in it - I believe there's just one person working on it, and even that is part time.

The only thing that keeps me on C# is lack of Rust debuggers that would be able to evaluate arbitrary Rust expressions including full support for traits.

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

#319

Post by chowells »

bazoom42 wrote: post #245
chowells wrote: post #97

Earlier quoted context omitted.

You realize every single thing that dynamically-typed languages can do with data types, statically-typed languages can do too? Except when it matters, they can also choose to do things dynamically-typed languages can't. Lots of people assume static typing means creating domain types for the semantics of every single thing, and then complain that those types contain far more information than they need. Well, stop doin…

You can’t do monkeypatching or dynamically modify the inheritance chain of an object in a statically typed language. But yes, you can have a JsonNode type, which is still better than having every type being “object”.

> You can’t do monkeypatching or dynamically modify the inheritance chain of an object in a statically typed language.

There's no theoretical reason you can't. No languages that I know of provide that combination features, because monkey-patching is a terrible idea for software engineering... But there's no theoretical reason you couldn't make it happen.

I think you've conflated static typing with a static language. They're not the same thing and can be analyzed separately.

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

#320

Post by mnsc »

btreecat wrote: post #251
pc86 wrote: post #222

Earlier quoted context omitted.

I am admittedly biased, because although I started programming recreationally in the LAMP-stack world of mid-aughts fame, a huge portion of my professional career has been in C# and the .NET stack. I think you are grossly overestimating the degree to which the programming language you choose to use to solve a business problem constitutes "betting your business on." How would your business fundamentally change if your…

Working for an org who bet on a mix of scala, python, and typescript, I can tell you which languages are being bet on for the rewritten services, and which language is getting in the way of getting things done.

Care to elaborate? Are there any big frameworks in the mix that might have gone from oss to commercial?
Post reply on HN