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

221–230 of 333 posts

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

#221

Post by thesz »

ReleaseCandidat wrote: post #213
thesz wrote: post #206

Earlier quoted context omitted.

With eventlog you have lightweight profiling and logging tool for "normal", "production" purposes. You can correlate different metrics of your program with your messages. This is not an abuse of Debug.Trace (notice the dot), it is normal state of affairs, regularly used and RTS is optimized for that use case. I develop with Haskell professionally. That foldl example of yours is pretty rare and usually dealt with the…

Eventlog is just `unsafePerfemIO*`, so you could just use that instead and not "hide" it and feel better about that. The "correct" answer to `foldl` would be `scanl` and printing the result of it. https://hackage.haskell.org/package/base-4.18.0.0/docs/Prelu...

Eventlog traces are RTS calls wrapped into unsafePerformIO, you are right. The trace part of eventlog is optimized for, well, tracing and is very, very lightweight. It is also safe from races, whereas simple unsafePerformIO (putStrLn $ "did you meant that? " ++ show (a,b,c)) is not.

In my opinion, eventlog traces make much better logging than almost anything I've seen.

Right now, developing with C++, I miss the power of Haskell's RTS.

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

#222

Post by pc86 »

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…

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 first 10k lines of code was in F# as opposed to Go, or Java, or Python, or TypeScript? These are also all languages I've been paid to use, and have used in anger, and with the exception of Java were all learned on the job. This comment in general has big "M$ bad" vibes and if you take those pieces out I'm not sure what the actual criticism is (maybe there is none)?

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

#223

Post by pmontra »

xmcqdpt2 wrote: post #211
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'.

One might say that Real OOP has never been tried.

Erlang and Elixir with spawn processes (objects with their own CPU) and send / receive message passing? But they do their best to hide it in OTP behind all that handle_* boilerplate.

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

#224

Post by BiteCode_dev »

FrustratedMonky wrote: post #205

Still crossing fingers that F# takes off. Love it, but not many jobs with it. I'm still surprised how much more can be done and better in F#, but nobody uses it. After switching brain over to that way of thinking, have trouble going back.

Don't hold your breath.

The stigma of the MS touch and the fear of getting bitten in the future is a strong deterrent.

You can easily migrate from github or vscode, but not your programming language.

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

#225

Post by pmontra »

devmunchies wrote: post #129
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…

The worst part of OOP is that all the properties of an object can be a mishmash of values and are mutable. In any method, you never know if the object is in some undesirable state without checking properties within the method itself. Multiply that headache across all methods and all other classes and it becomes a mutable mess. It makes it weird that we pass around objects as types when they encapsulate so much state…

Erlang and Elixir store state in arguments of recursively called functions, usually running in their own processes separate from the rest of the application. There is nothing in the language to enforce correctness of the state. They are generally regarded as functional languages even if they are somewhat object oriented if one thinks about their message passing as method calls to the object / process storing the state.

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

#226

Post by lostmsu »

pjmlp wrote: post #172
lostmsu wrote: post #49

Earlier quoted context omitted.

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

Good luck having the whole .NET Windows ecosystem rewritten in Rust.

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

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

#227

Post by FrustratedMonky »

cjbgkagh wrote: post #31
gemstones wrote: post #3

This is a nicely written essay and, I think, completely wrong. (One person's experience here, just as a disclaimer.) I've interviewed a lot of functional candidates in a decade-long stint of functional programming professionally. My interview approach is always the same. All practical exercises, no leetcode here. You can do the exercises in the language you're most comfortable in. If I had to pick a language that pre…

I think F# programmers lack that gamut because they get comfortable in the eager execution type safe world and stay there with no particular reason to learn dynamic programming techniques. There is also the effect that it allows less advanced functional programmers to be productive so that in randomly sampling currently active functional programmers the F# programmer is less likely to be advanced. Scala developers we…

This seems to be implying that F# programmers do 'poorly' because the language 'protects' them. But, isn't that good? Why have a language that purposely tries to trip you(dynamic), and you are a 'good' programmer if you don't get tripped. This seems to be rewarding people that are good at using a bad language. Since if you are using F# you don't learn the techniques for using other bad languages, doesn't make that programmer bad, it just means F# is more seamless.

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

#228

Post by ReleaseCandidat »

thesz wrote: post #221
ReleaseCandidat wrote: post #213

Earlier quoted context omitted.

Eventlog is just `unsafePerfemIO*`, so you could just use that instead and not "hide" it and feel better about that. The "correct" answer to `foldl` would be `scanl` and printing the result of it. https://hackage.haskell.org/package/base-4.18.0.0/docs/Prelu...

Eventlog traces are RTS calls wrapped into unsafePerformIO, you are right. The trace part of eventlog is optimized for, well, tracing and is very, very lightweight. It is also safe from races, whereas simple unsafePerformIO (putStrLn $ "did you meant that? " ++ show (a,b,c)) is not. In my opinion, eventlog traces make much better logging than almost anything I've seen. Right now, developing with C++, I miss the power…

The point I was trying to make was, that if all you want/need is a `putStr`, just use `unsafePerformIO`.

Haskell's (GHC's) Eventlog is nice, but a binary format and not comparable to text output.

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

#229

Post by rami3l »

xupybd wrote: post #53
slfjw____ wrote: post #14

Likely will never use again * two async models present: task (C#) & async (f#) * horrible async performance: perhaps fixed by native task & FSM transformation * two error handling models: Result (monadic but without do notation) & C# style Exceptions * not rich in community libraries, like a desert & abandonware

> not rich in community libraries, like a desert & abandonware You have access to the entire .net ecosystem?

The last time I gave F# a shot, I tried to write a simple Telegram bot in it.

Just to test how much I would actually benefit from the .NET ecosystem, I chose to use a C# wrapper for the Telegram API. Suddenly I had to handle null references and exceptions everywhere (it's in this regard even worse than Rust, where I'm guaranteed to get Options and Results).

I know proper support for C# T? type interop is in the works (https://github.com/dotnet/fsharp/pull/15181), but really it seemed to me that too few cared about F# to get it landed in a reasonable timeframe.

I'd really love to see a pragmatic FP language with a reasonable amount of libs to choose from (both natively and via interop without much effort), but F# was a bit far from that description IMO.

Post reply on HN