Live data from Hacker News

Why F# evangelism isn't working (2015)

ericsink.com

251–260 of 333 posts

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

#251
post #222
post #204

Earlier quoted context omitted.

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…

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.

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

#252
post #41

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…

>If I had to pick a language that predicted you'll do poorly on a practical interview exercise, I would pick F# every time As someone that has just spent a while learning F# and really enjoys it, this makes me sad. I hope that I don't have some trait that drew me to F# that also causes me to be less competent.

I took this post about F# talent to really imply -> F# has language features that protect or handle 'some concept', and then when the programmer was asked to do something else, they had trouble because they wouldn't normally have had to deal with it in F#. It isn't necessarily the F# programmers skill level, if dealing with other languages and needing more code to cover gaps, and knowing the gaps.

Can be a great Java programmer, now go do something in assembly, doesn't reflect on the Java skills.

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

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

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

Chicken and egg, perhaps? OOO lives and breathes state, so complexity (defined as an excess of state consideration) seems a natural pairing, yet the overhead and complexity is increased by each in response to the necessity of the other? That is, when complexity of the problem shifts, there is a parallel increase in the complexity of the OOO solution.

The general anxiety of the movement towards functional or procedural programming in general might also be a feature of age: a young programmer eager to impress that they can juggle 8 balls effortlessly, but called upon to do the same 15 years later might admit 3 balls sufficed to begin with, and is closer to an attainable sustainable solution.

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

#254
post #5

Earlier quoted context omitted.

Are you implying this is a F# problem? What language do candidates do well in? Is F# too approachable due to its closeness to C#, popular with C# professionals, and therefore not approached as a functional programming language as much as a C# extension?

I've seen Elixir, Python, Javascript, Java, Scala, Clojure, C#, Go, and more; not sure who is at the top, but F# is 100% at the bottom (just in my personal experience.) I wouldn't chalk it up to being too approachable.

I did think F# had a pretty steep learning curve. So, not approachable. But how did it compare to Scala/Clojure? Those seem to have similar problem with being approachable, and adapted.

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

#255

(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.

[dead]

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

#256
post #173

Earlier quoted context omitted.

To be clear I wasn't referring 'dynamic programming' but as you say, the use of a dynamic language, or programming without types, mimicking what I assumed the original poster I replied to meant. My guess is that interviewees wishing to return to the typed world they are comfortable with would first try to type the JSON they are working with. Given that the JSON is messy this could be an unbounded amount of work that…

I'm curious about what context would require an untyped language

By untyped I assume you mean dynamic languages? I’m some contexts it’s not convenient to lug around a type checker, embedded languages for example. Other times if doing macro heavy programming (lisp, forth) it’s hard to build a type system that can properly type check the code or resolve the implicit types in a reasonable amount of time.

In the context of JSON you can work on it without types from a typed language. It’s just that as a force of habit coders may chose to spend time adding types to things when they shouldn’t.

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

#257

(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.

[dead]

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

#258

Earlier quoted context omitted.

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

Indeed, I’m suggesting an alternative explanation for the given observations based around the absence of a strong selection criteria bias. I’m of the strong opinion that F# is a great language and that people of different levels of skills can be productive in it. As opposed to a C++/lisp combo where only the most careful programmers get to keep both of their feet.

F# is a slice through the language design space that optimizes for developer productivity, other languages with different design choices are optimized and are indeed better for other things.

I think there is a benefit to learning learning ‘bad’ languages as they teach you about the different design trade offs that are available. A person with dynamic programming language experience would have known that the given JSON task was tractable without types and not started the task with a ‘type all the things’ mentality.

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

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

Aside from the EEE quip, I didn't catch any "M$ bad" vide in GP's post. I think the situation is clear-cut: until recently, you couldn't really run .net on anything else than Windows, so the only people using it were those already invested in the ecosystem. Among the people invested in the windows ecosystem, many (most ?) are large "non-tech" companies who hire people who mostly see their jobs as a meal ticket. These…

That's for coming in my defense. You are right. I'm not a big fan of Microsoft, but I also don't hate them.

It's pretty simple, really. I am a Linux engineer, and it is not a great investment of time and money for me to get into .NET. I knew F# was cool, but 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? It makes no business sense at all.

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

#260

Earlier quoted context omitted.

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

Yeah, and I think that's why a language like Clojure, which is substantially more opinionated than Scala, has been relatively unphased by Kotlin. Clojure is much more niche than Scala, and the adoption has been much more of the "slow and steady" kind. People who are writing Clojure likely aren't looking at Kotlin as an "alternative"; while they superficially occupy a similar space, I don't think Clojure has any ambit…

Yep, Scala got a lot of attention because you could kinda write it like Java, and Java hadn't changed much in a very long time - people were looking for a "better Java" - and Clojure obviously isn't that.

Kotlin's whole point is a "better Java", so it's going to grab people who went to Scala for a "better Java". Also Java actually has a sane roadmap and methodology to get better too, so there's that now too - with the preview/incubating JEPs, people can see what is coming down the pipeline.

Post reply on HN