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

201–210 of 333 posts

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

#201

Post by arethuza »

otto-edgar wrote: post #196
rgbgraph wrote: post #141

Earlier quoted context omitted.

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…

What do you find insane about the C# `List` source code? I'm not a C# programmer, but the public API looks sound, and the entire thing is like 1K LOC including docstrings (I guess the inherited code would add to that).

I don't think it's even using inheritance - List implements a few interfaces though?

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

#202

Post by hardware2win »

wly_cdgr wrote: post #19

It doesn't help that C# has a much, much better name for the purposes of appealing to Pragmatists (in the article's terminology). Every Pragmatist knows that C is a trusted and proven language. So, something that is an improvement or iteration on C is probably fine, too. But what is F? No one knows.

C being trusted?

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

#203

Post by colanderman »

jackmott42 wrote: post #189
momentoftop wrote: post #151

Earlier quoted context omitted.

You're thinking of Haskell. F# was modelled after OCaml, which doesn't attract monad transformer stacks, and doesn't have a zoo of compiler extensions.

You have to add extra syntax to do very normal things like have more than one expression in a function.

As someone who's coded OCaml for 20 years, I have no idea what you're referring to. `let x in y`? `x; y`? `x, y`? Those are all in the base language.

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

#204

Post by sph »

lambdaxymox wrote: post #96
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# 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 their weekends. The corporate world runs on Java and C#.

If F# had been released in the open-source, flashy and bustling world of Linux and macOS developers, it would have had a much greater success.

I know you can run F# on Linux, but just like running Swift, it feels like outsiders I wouldn't want to bet my business on if I were a Linux-only shop (which I am), however nice it feels. Also a decade ago when it had a chance to take root, Microsoft was still the Embrace Extend Extinguish company. It's not good enough to risk it, just like I'm not gonna use SQL Server for anything.

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

#206

Post by thesz »

c00lio wrote: post #199
thesz wrote: post #191

Earlier quoted context omitted.

You can use eventlog traces, from Debug.Trace [1]. You can (traceEvent $ "look: " ++show bazinga) everywhere you need and then stare at the log to your heart content. [1] https://hackage.haskell.org/package/base-4.18.0.0/docs/Debug... No need for extensions, just compile and run your program slightly differently. That's the power of declarative languages.

Not everything is tracing and debugging, sometimes you really need to output intermediate results for "normal", "production" purposes. One could still abuse Debug::Trace, but that would really be ugly. I also object to that "everywhere". It is far easier to just dump an extra 'print' line somewhere inside a for-loop than into a `foldl (*) 1 $ map (+ 3) [17, 11, 19, 23]`. And that is an easy one...

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 QuickCheck [1], mother of all other quickchecks. Usually, the trace will be outside of the foldl application, but you can have it there in the foldl argument, of course.

[1] https://hackage.haskell.org/package/QuickCheck

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

#208

Post by c00lio »

thesz wrote: post #206
c00lio wrote: post #199

Earlier quoted context omitted.

Not everything is tracing and debugging, sometimes you really need to output intermediate results for "normal", "production" purposes. One could still abuse Debug::Trace, but that would really be ugly. I also object to that "everywhere". It is far easier to just dump an extra 'print' line somewhere inside a for-loop than into a `foldl (*) 1 $ map (+ 3) [17, 11, 19, 23]`. And that is an easy one...

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…

> I develop with Haskell professionally. That foldl example of yours is pretty rare and usually dealt with the QuickCheck [1], mother of all other quickchecks. Usually, the trace will be outside of the foldl application, but you can have it there in the foldl argument, of course.

So actually not everywhere. And QuickCheck does something else entirely.

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

#209

Post by tombert »

momentoftop wrote: post #151
c00lio wrote: post #128

Earlier quoted context omitted.

"Oh, you _also_ need to print something? Lets stack a few monad transformers..." "But remember that you need the TemplateExplicative and NullUnderstanding compiler extensions!"

You're thinking of Haskell. F# was modelled after OCaml, which doesn't attract monad transformer stacks, and doesn't have a zoo of compiler extensions.

I'm pretty sure F# was modeled on both. There are some definite "Haskell-isms" in F#; if nothing else, monads are typically done in something more or less equivalent to the `do` notation (an `async` or `seq` block), for example.

The syntax superficially looks a lot like OCaml, but it doesn't do the cool stuff with OCaml functors and modules; you write it a lot more like Haskell most of the time.

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

#210

Post by xmcqdpt2 »

tombert wrote: post #188
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.

Totally agree; F# really feels like a language designed by someone who really does understand the theory, why it's important, but also wanted to make the language realistic to use in industry. When I was at Jet and Walmart, I never really felt "limited" by F#. The the language was extremely pleasant to work with, and I think most importantly, it was opinionated . Yeah, you can write Java/C#-style OOP in F# if you rea…

Martin Odersky is just a very nice guy and I get the impression that he isn't keen on saying "no", which is how you end up with a language that allows you to use xml tags inline (no longer supported in Scala 3),

https://github.com/scala/scala-xml/wiki/Getting-started

The "opinionated" Scala are the Typelevel and Zio stacks, which are very cool.

The problem with the "better Java" approach is that although it has helped Scala's growth a lot, it has also made it susceptible to Kotlin. The Scala code that doesn't use the advanced type magic can be straightforwardly rewritten in Kotlin instead. Kotlin also stops your bored developers from building neat type abstractions that no one else understands.

People who use Scala only has a "better Java" can now use Kotlin has a "better "better Java"".

Post reply on HN