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

The Problem with F# Evangelism

thomasbandt.com

Post reply on HN
Print view View original

111–120 of 203 posts

Re: The Problem with F# Evangelism

#111

Post by wtetzner »

DeepRote wrote: post #18
KirinDave wrote: post #15

Earlier quoted context omitted.

This is very true, and Purescript and Eta are making big strides here precisely because they expose access to NPM and the world of Java, respectively.

Neither are making "big strides". They both are barely able to exist. Eta will never even approach Scala in terms of adoption, and I had only heard about Purescript a few weeks ago reading about Elm. Typescript will dominate functional JS-world (already is, tbh) and Scala is still crushing function JVM-world, and if Dotty ever actually materializes, adoption will get even better. Additionally, Scala-Native and ScalaJ…

> edit: I'll concede that Clojure matters a bit in JVM-world, but it's dying quickly.

Is it? Do you have evidence of this?

Re: The Problem with F# Evangelism

#112

Post by runT1ME »

phillipcarter wrote: post #17

I actually work on F# at Microsoft. I've had success and some failures when it comes to evangelizing F# through Microsoft (but mostly success if my measures are accurate). I strongly believe that it can be boiled down to one major thing: Programmers learn how to program with C-style languages. C, C++, Java, C#, JavaScript, Python (sorta) . . . they're all in the same family. People, especially while learning, associa…

My previous job was working for a .NET shop that powered tons of automotive search engines etc. across the web. We moved to more and more functional concepts using C# as the team learned about them and had a lot of success with them. At a certain point, we explored using F#, but the lack of type classes & HKTs meant we kept having to repeat ourselves.

We ended up choosing Scala for some new projects despite having an inferior IDE experience and being unable to use some of our other libraries. I don't think I can emphasize how much not having type classes and HKTs hurts productivity once you buy into the fully functional mindset. We were extremely productive in Scala because the language was a bit more powerful.

I would love to use F# again, but not until the language adds those features.

Re: The Problem with F# Evangelism

#113

Post by hellofunk »

DeepRote wrote: post #107
rlander wrote: post #100

Earlier quoted context omitted.

What's with the "Clojure is dying" meme? In the last few months I've seen an uptake in Clojure jobs.

The fallacy there is that Clojure development is drastically slowing in favor cljs. Because there's jobs doesn't mean anything with regards to dev status. My dad has been writing COBOL for 30+ years, but I think we could both agree that it's a dead language in a certain sense. My first language was Scheme. I wrote some stupid BATCH scripts at school and decided I wanted to learn to program. I worked my way through ha…

Clojure.spec has spread like wildfire and is offering tools to combat some of what you say. Goes further than type systems on some things. Is also amazing for generative testing.

Re: The Problem with F# Evangelism

#114

Post by maxxxxx »

Boothroid wrote: post #61
rubber_duck wrote: post #32

Earlier quoted context omitted.

I disagree with this, you can sell F# to C# developers - things like type providers for SQL checking their query strings in compile time and no extra build step to produce SQL type definitions vs monstrosities such as Entity Framework... if they've been burned by ORMs to drop to stuff like Dapper they'll love F# type providers. Immutable data is also becoming a common pattern even in C# but it's tedious as hell to wr…

I'm interested to know why you describe EF as a monstrosity? Genuine interest, I just started using EF for the first time a few weeks ago for a work project so I've only scratched the surface but it didn't seem terrible, although I did find that only being able to update all tables after a change to the database as opposed to a single table to be a bit of a limitation.

In all the EF projects I have been on it caused weird issues after a while. Code first projects don't upgrade anymore or the order of saving is wrong or performance is bad.

In pretty much all of them we ended up writing a simple wrapper around the database that was much easier to control.

Re: The Problem with F# Evangelism

#115

Post by TensorMetric »

MrBuddyCasino wrote: post #104
rubber_duck wrote: post #32

Earlier quoted context omitted.

I disagree with this, you can sell F# to C# developers - things like type providers for SQL checking their query strings in compile time and no extra build step to produce SQL type definitions vs monstrosities such as Entity Framework... if they've been burned by ORMs to drop to stuff like Dapper they'll love F# type providers. Immutable data is also becoming a common pattern even in C# but it's tedious as hell to wr…

You don't increase adoption by making the learning curve steeper. Rust does its best given the circumstances, but people's top complaint is that its hard to learn. Scala never went Mainstream because you can't hire developers, and training them takes many months. F# should not repeat that mistake.

Adoption of F# would not be a problem if it had .NET Native support and proper tooling

https://news.ycombinator.com/item?id=15026396

Re: The Problem with F# Evangelism

#116

Post by alkonaut »

Businesses and developers generally won't switch languages. Evangelism makes people curious which means new businesses and new projects some times picks a new language.

I'm a C# dev since 14 years (single project) hoping my next project will be an F# one. That might mean I have to switch jobs - and I hope there are enough F# shops when I need one.

Re: The Problem with F# Evangelism

#117

Post by louthy »

com2kid wrote: post #40
rubber_duck wrote: post #32

Earlier quoted context omitted.

I disagree with this, you can sell F# to C# developers - things like type providers for SQL checking their query strings in compile time and no extra build step to produce SQL type definitions vs monstrosities such as Entity Framework... if they've been burned by ORMs to drop to stuff like Dapper they'll love F# type providers. Immutable data is also becoming a common pattern even in C# but it's tedious as hell to wr…

> Functional programming is also seeping in but again tons of boiler plate. The bar has moved so much on this one. I remember when C#'s wonderful lambda syntax, along with all the extension methods that LINQ added, qualified it as having pretty good functional programming support. Now that other languages have gone out and copied sane lambdas, and "Map" is in libraries left and right, C# has to keep reaching for that…

What does the higher bar look like to you? For me, the major missing features of C# are:

* Immutable record types

* ADTs with completeness pattern matching

* Higher-kinds

F# is also missing higher kinds, but can do the others. Did you have something else in mind?

Re: The Problem with F# Evangelism

#118

Post by tcard »

A great take on this topic is a talk by Evan Czaplicki, creator of Elm, another functional language: Let's be mainstream! [1] The conclusions are more or less the same than the article, but Evan goes into a lot more depth. And in my opinion, as a result, Elm does very good in this regard.

[1] https://www.youtube.com/watch?v=oYk8CKH7OhE

Re: The Problem with F# Evangelism

#119

Post by leshow »

DeepRote wrote: post #18
KirinDave wrote: post #15

Earlier quoted context omitted.

This is very true, and Purescript and Eta are making big strides here precisely because they expose access to NPM and the world of Java, respectively.

Neither are making "big strides". They both are barely able to exist. Eta will never even approach Scala in terms of adoption, and I had only heard about Purescript a few weeks ago reading about Elm. Typescript will dominate functional JS-world (already is, tbh) and Scala is still crushing function JVM-world, and if Dotty ever actually materializes, adoption will get even better. Additionally, Scala-Native and ScalaJ…

> ScalaJS are making progress and could eventually be real players.

So ScalaJS could be a "real player" but PureScript is barely able to exist? Forgive me if I don't just take your word for it.

Re: The Problem with F# Evangelism

#120

Post by KirinDave »

sitkack wrote: post #31
KirinDave wrote: post #13

Earlier quoted context omitted.

It's unfortunate tho, because for example what word do I have for the generalization that we call "profunctor" other than a profunctor. Even the words we use to describe a profunctor are "contravariant and covariant" and these words OUGHT to be more applicable to programmers but are not. For many programmers, the axioms of what a function are (a calling point to code which is contravariant in a product and covaraint…

We can sell the vision without sound like a Pythagorean-cult of mathematics (functional programming). Hell, once I showed some of Python programming brethren pure functions they were hooked, HOOKED I tell you! When I showed how to make an object system using closures, they were like, "Cool!" Some people start with the math, some people finish with the math and others deny the math. But we can all be better programmer…

I think a disagreement about didactic methods and ordering is not what I was addressing. I just think at some point calling it a "Pythagorean cult" (and what, I wonder, are we murdering people over uttering?) is counter-productive.

I'm slowly recording several sessions, and I think about 2 hours in enough to introduce Purescript, explain the basics of Functors, Applicative Functors (which come nearly for free), and even explain, motivate, and use monadic functions. But I don't know how to do this without at least giving folks some words (Functor is a name as good as any, and every other name for Monad is at last as if not more intimidating

It's just at some point if we observe the shape of what we're doing, we can generalize in a useful way further (e.g., the lenses-banannas-parethesis approach).

Post reply on HN