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

171–180 of 333 posts

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

#171

Post by pjmlp »

jayd16 wrote: post #89
muglug wrote: post #32

Progamming language evangelism is basically a zero-sum game. Some languages don't really intrude on one another's territory — e.g. not that many people are rewriting Ruby programs in Rust — but some very directly compete. So if you want to convince someone to use F#, you have to convince them it's significantly better than some other closely-related language. And that's hard! I have a strong suspicion that the next d…

C# will stay because Microsoft will push it. Honestly what makes Go so special? I could see another language or even Java or C# get their AOT story together and retake what was lost to Go.

> Honestly what makes Go so special?

Google branding, and yet another language from UNIX creators.

None of its direct influences, Oberon-2 and Limbo, achieved market success when ETHZ or Bell Labs were pushing them.

Docker and Kubernetes successes made Go unavoidable on DevOps space.

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

#172

Post by pjmlp »

lostmsu wrote: post #49
Semaphor wrote: post #34

Earlier quoted context omitted.

> JavaScript/TypeScript and Python will become even more popular, to the detriment of everything but Go, C++, and Rust. Why do you see the popularity of C# waning?

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.

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

#173

Post by sakex »

cjbgkagh wrote: post #48
JoeyJoJoJr wrote: post #43

Earlier quoted context omitted.

I have been programming for 20 years, and yet despite having used dynamic languages I don’t actually know what it means to leverage dynamic programming techniques. For instance, I’ve never encountered a JavaScript codebase that I have thought couldn’t benefit from just being statically typed with Typescript. I get the impression that dynamic programming, besides the odd untyped line of code, is best used only for ext…

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

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

#174

Post by pjmlp »

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?

Right, but like the curse of guest languages (which F# isn't one), they decided to create their own ecosystem.

So using .NET libraries directly is frowned upon, while some of them like GUI frameworks, expect C# features (like Roslyn and Code Generators) not available in F#.

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

#175

Post by gemstones »

listenallyall wrote: post #107
gemstones wrote: post #27

Earlier quoted context omitted.

It is, but I’m very forgiving of scripts/services that don’t run right the first time if it’s clear the logic is on the right track. If your logic is sound and you’re stuck on an esoteric error, I usually count that the same as completing the exercise. (There have been cases where the person shows no debugging ability at all, which I do treat as a problem. But if you’re reading the error and there’s just not enough t…

jacamera is on point. Perhaps it's not "leetcode" but it's a seemingly one-dimensional, time-constrained quiz on a specific skill, parsing messy JSON (your words), with you as the sole judge. Personally from experience, when I approach a new API, I recognize it's likely to take a few iterations, based on how that API's data integrates with the rest of my program, to determine the best way to deserialize the API's res…

Why did you take from my comment that parsing messy JSON is the only part of the exercise? It’s just the part that we seem to get stuck on with F# candidates, not the only thing I ask about.

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

#176

Post by pjmlp »

banashark wrote: post #69

I find it interesting to compare F# with Kotlin. F# had Jet as the one large success story of a full f# shop, but outside of that there weren't many large companies using a lot of F# (except microsoft internally, and they didn't blog about it _too_ much). Kotlin on the other hand is seeing server-side adoption in quite a few large companies. Google is recommending it as the server-side JVM language for new services g…

Kotlin is only succeeding on Android thanks to godfather Google, it is hardly used on the JVM.

On the JVM is as much as F# on the CLR, as any google trend analytics and similar will show.

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

#177

Post by pyrale »

lelanthran wrote: post #146
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…

> 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 situations), or better.

That being said, in most situations, language/paradigm choice were not the main drivers of project success. At worst, a bad OO codebase is a drag, not a killer, and the same is true with non-OO projects.

> Not that I am defending OO, I just want to know how you are differentiating between "OO produces complex systems" and "OO is used for complex systems".

OO definitely produces complex systems. And, let me be clear, by OO I mean the social consensus in OO circles, not the paradigm itself or the technical tools. My take is that OO circles host a cottage industry of consultancies and gurus peddling a stream of design patterns, advices, etc. which end up layering in any long-lived OO codebase and create unnecessary complexity.

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

#178

Post by tcfhgj »

el_oni wrote: post #136
tcfhgj wrote: post #116

Earlier quoted context omitted.

It's not a tree though. A tree doesn't have connected leaves and branches. This is, however, common with classes that might get injected the same dependency

Sounds like missing the tree for the forest. Im not from a pure cs background (so forgive my mangling of terms) but isnt a tree essentially an acyclic graph with constraints, 1 parent 2 children for example? What you're describing is adding some cycles into that graph no?

The number of children can be anything, it's two children for a binary tree. Each node except one node must only have one parent, which isn't true if two or more nodes share one or more children.

And, yes, in theory this adds cycles which aren't allowed. However, since class dependencies are better represented as directed connections (which aren't usually used for trees in CS terms), it isn't a true cycle.

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

#179

Post by ReleaseCandidat »

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.

Well, they aren't actually compiler extensions but pre processor extensions (PPX).

And I would really like if OCaml would have had the possibility to add the needed PPXs names to the source file (like Haskell's compiler extensions). So as to not have to read the Dune (or whatever build system is used) file to get to know where `foo%bar` or `[@@foo]` is coming from and what is doing. But at least the usage of `ppxlib` nowadays should make PPXs "compose" aka. not stamping on each other's feet.

https://ocaml.org/docs/metaprogramming http://ocamlverse.net/content/metaprogramming.html

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

#180

Post by freilanzer »

jayd16 wrote: post #89
muglug wrote: post #32

Progamming language evangelism is basically a zero-sum game. Some languages don't really intrude on one another's territory — e.g. not that many people are rewriting Ruby programs in Rust — but some very directly compete. So if you want to convince someone to use F#, you have to convince them it's significantly better than some other closely-related language. And that's hard! I have a strong suspicion that the next d…

C# will stay because Microsoft will push it. Honestly what makes Go so special? I could see another language or even Java or C# get their AOT story together and retake what was lost to Go.

Crystal, for example, would be a better Go for me.
Post reply on HN