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

291–300 of 333 posts

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

#291

Post by pjmlp »

WorldMaker wrote: post #277
pjmlp wrote: post #248

Earlier quoted context omitted.

Kill in the sense that from WinDev point of view, the less .NET ships on Windows the better. In case you aren't aware, WinRT basically marks the turning point started with Longhorn ideas being rewriten into COM. With WinRT, they basically went back to the drawing board of Ext-VOS, a COM based runtime for all Microsoft languages, hence why .NET on WinRT/UWP isn't quite the same as classical .NET and is AOT compiled, w…

UWP never required AOT, it was an opt-in performance boost (that has since been rebuilt to support all of .NET in ".NET Native"). Today's post-UWP C#/WinRT bindings don't require AOT either. Beyond WinRT, .NET (Core) has supported all the raw COM, including COM component hosting since at least .NET Core 3.0. It's Windows-Only, of course, to use that, but that should go without saying. It's mostly backwards compatible…

UWP always deployed via AOT on the store.

.NET Core doesn't do COM type libraries like the Framework does, you are supposed to manually write IDL files like in the old days.

Additionally CCW/RCW infrastructure is considered outdated and you should use the new, more boilerplate based COM APIs introduced for COM and CsWinRT support.

Lots of changes, with more work, for little value.

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

#292

Post by progmetaldev »

whizzter wrote: post #145
rawling wrote: post #140

Earlier quoted context omitted.

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

You can also use DI without having to use interfaces for everything. It's easy and possible to inject straight dependencies from concrete classes into constructors, without all the abstraction (beyond allowing constructors being called for your dependencies and injected into your controllers). I'm a big fan of using services with an unabstracted database context from EF Core, rather than ever making use of repositories. I can still go from a MVC project with concrete views, over to Web API with a completely JavaScript frontend framework, without needing to change any of my business logic. Approximately 10 years ago, I was lost in all the abstraction you'd find in tutorials and any book on ASP.NET MVC, but experience has taught me a LOT, as well as working with other languages and seeing the (lack) of ceremony needed to get things done.

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

#293

Post by ThinkBeat »

progmetaldev wrote: post #287
ThinkBeat wrote: post #127

Earlier quoted context omitted.

C# in its current state has IMHO acquired many features from F#. You can get close to writing purely functional code in C# now. I think with all the changes and extensions over time to add ever more features to C# so you can write whatever paradigm you want in it is a bad idea. I would much have preferred to keep C# OO and use F# when you want to go functional. Or just create G# which is the everything mashed togethe…

I don't dispute your claims, as they are subjective. I do know that I enjoy a lot of the functional aspects to C#, but I think it's something where you need to have a real discussion with your team and decide a coding style and feature implementation for your code. If your team can't all speak the same dialect, you're going to have issues. Having seniors able to work with juniors and discuss the functional aspects, a…

You bring up good points.

I often think about C.

I learned C a long time ago, I still have the KR book, and if I look at C code I can get a good idea of what is happening, even though I haven't kept up with all the changes.

In C# now, two developers can write code that accomplishes the same but might not be able to read each other's code. I dont think that is healthy.

It is somewhat the Microsoft Office / Word approach to programming languages. Just Keep adding features on top of features.

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

#294

Post by progmetaldev »

_gabe_ wrote: post #285
michielr wrote: post #144

Earlier quoted context omitted.

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();

>> The problem is the amount of ceremony, silly OOP abstractions, dependency injection, etc. Your code snippet certainly has a lot of unnecessary ceremony. Why use a builder object at all? Why use a static class with a function to build the builder object? var builder = createBuilder(args); // etc... Would be better. But var app = createWebApp(args); // etc... Is even better. No ceremony at all!

There is a lot that gets done behind the scenes in createBuilder(). I understand where you're coming from, but this allows you to override any defaults that you don't like, in order to provide your own. I personally still stick to the standard MVC pattern, and don't go crazy with abstractions. I place my business logic within services and inject those in my controllers, but if you were to run a debugger, you would not have to jump through interfaces and other useless abstractions that were a thing of the past (and present if you follow current tutorials and books). I have used Node.JS, and still use it to provide my frontend developers with an environment using Express to build out templates using Gulp for minification/transpilation/compression for use in Umbraco (a .NET Core CMS). My frontend developers don't need to know C#, and can work in standard EJS templates and HTML, but benefit from SCSS and modern JavaScript. I can then build out the Razor syntax for views, and just drop their CSS and JS files directly into the CMS projects.

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

#295

Post by paddim8 »

sph wrote: post #204
lambdaxymox wrote: post #96

Earlier quoted context omitted.

F# always struck me as one of the most terribly underrated languages. I'm a lover of MLs in general, but F# lands on one of the sweet spots in PL space with ample expressive power without being prone to floating off into abstraction orbit ("pragmatic functional" is the term I believe). It is basically feature complete to boot.

I agree on the underrated part. My theory as an outsider: F# is strongly tied to the Windows world, the corporate world, where a conservative approach is always preferable, on your tech stack and if you need to hire peons coding all day. The corporate world isn't leaving OOP anytime soon, because it's what 95% of engineers focus on, the silent majority which do not frequent HN or play with functional languages in the…

.NET has great Linux support nowadays though. I only use Linux and use .NET extensively and have no complaints

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

#296

Post by pharmakom »

WorldMaker wrote: post #275
pharmakom wrote: post #133

Earlier quoted context omitted.

Yep, Linq could be replaced by the more general Computation Expressions in F#

F# has a query { } expression for LINQ already.

I'm talking about improving C# by replacing LINQ with the more general Computation Expressions.

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

#297

Post by progmetaldev »

pyrale wrote: post #177
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…

> 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? Having shipped both significant non-OO projects and significant OO projects, their drawbacks were usually related to low adoption. In terms of code and architectural complexity, they were either comparable to OO projects (in specific situation…

Absolutely! It is the misunderstanding and use of heavy abstraction, with "a class per file" that blows these systems into liabilities rather than solutions. Start with a low number of abstractions, as few as you can get away with given your requirements, and then only expand when the requirements change. It really doesn't matter the paradigm, it's possible to heavily abstract a functional system with various transformative functions that aren't truly needed until the data becomes more complex.

There is a whole industry peddling OO systems that are extremely abstracted for the benefit of filling chapters in a book, or producing extra pages of content in a website. I fell victim to both early on in my knowledge and even professional world, but somehow managed to follow what "felt right" and broke away from that to find an easy path forward that allowed me to use the tools I was given in the easiest way possible, and only introduce complexity when the solution was complex (not for the sake of complexity for complexity's sake).

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

#298

Post by WorldMaker »

pharmakom wrote: post #296
WorldMaker wrote: post #275

Earlier quoted context omitted.

F# has a query { } expression for LINQ already.

I'm talking about improving C# by replacing LINQ with the more general Computation Expressions.

Ah.

The C# compiler "duck types" LINQ so you can already (ab)use LINQ for general computation in C#. You can use nearly any Monad you want with LINQ syntax. It isn't always a strong fit for some types of Monads, but it is more capable than it seems. You might get some funny looks if you do, though.

(Similar with async/await: it is "duck typed" at compile time so you can write other Monads for that, if they make more sense in that form of transformer than LINQ. Or support both LINQ and async/await together.)

There's definitely some more interesting power in F#'s Computation Expressions that can't easily be done even with (ab)using the tools that already exist like that, but it is still interesting what can be done with the existing tools.

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

#299

Post by xupybd »

naasking wrote: post #235
bmitc wrote: post #82

Earlier quoted context omitted.

Forcing linear dependence of files and definitions is considered a feature of F#. In codebases that allow out of order definitions, things get wild real quick.

> In codebases that allow out of order definitions, things get wild real quick. Not an issue in C# at all. Get wild in what way?

I think wild real quick might be a bit extreme but cyclomatic complexity[1] is a source of unnecessary complexity in software. While not a problem per se, all unnecessary complexity adds up. Leading to the eventual death of the project[2]

  [1] https://en.wikipedia.org/wiki/Cyclomatic_complexity
  [2] https://en.wikipedia.org/wiki/Software_Peter_principle

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

#300

Post by 7thaccount »

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 really wanted to learn it, but I wanted to learn F# & not C#. The problem is...you can't really learn F# without knowing .NET and how it does all the OO stuff. Even the most basic things that require one easily googleable line in Python would return no results for F#. You just have to figure it out in C# and then you can apply to F#.
Post reply on HN