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

111–120 of 333 posts

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

#111

Post by epgui »

topkai22 wrote: post #94
Hasnep wrote: post #77

Earlier quoted context omitted.

I'm a data engineer, it's a fairly new role so it's not well defined yet, but most data engineers write data pipelines to ingest data into a data warehouse and then transform it for the business to use. I'm not sure why using a static language would make translating data types difficult, but I add as many typehints as possible to my Python so I rarely do anything with dynamic types. I guess they're saying for small t…

A major problem with doing data transformation in statically typed languages is that its easy to introduce issues during serialization and deserialization. If you have an object [{ name:”ex obj” value:”a sample value” extraProperty:”I’m important” }] And the code class myDTO{ string name; string value; } var myObjs= DerserializeFromFile (filepath) SerializeToFile(myObjs, filePath2) filepath2 would end up with without…

I think whether your comment is essentially true or not depends on the language and technology.

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

#112

Post by makeitdouble »

ideasman42 wrote: post #58

This article misses that there are pragmatists are not the kind of technology-disinterested "normal" people. An individual may have the same values as an early adopter, while having to make the decision to used tried and true systems for various reasons out of their control - one of which might be that you depend heavily on the continued development & support of surrounding ecosystems. Or that large code-bases can't…

I read both your examples as instances of "following the herd". The expression has negative connotations in litterature and net circles, but that's exactly a pragmatic behavior most of the time.

I'm also "following the herd" when choosing a platform that will make it easier/cheaper to hire (there is an existing "herd" of developpers), or has wide support by multiple vendors etc .

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

#113

Post by systems »

CrimsonCape wrote: post #91
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…

I empathize with your characterization of "a tree of object/classes" and I yearn for an example of how else to model a complex, domain-specific system not using the aforementioned tree.

relational model, like we always did and do everyday (in the db realm)

i am not saying we should not use trees ever, i am mainly saying, when the model is a very deep tree (or several deep trees and trees everywhere), its becomes overly complex

data models should be as flat as possible , and only nested when absolutely necessary

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

#114

Post by Turskarama »

CrimsonCape wrote: post #93
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.

If you had to chose right now and abandon the other, would you pick LINQ or discriminated unions?

Not OP but I would choose discriminated unions.

Why? because Linq is basically just syntactic sugar for regular IEnumerable methods, while discriminated unions have no equivalent at all.

Even if you wanted to claim that those IEnumerable methods ARE linq, then it would still be possible to implement them with a library while discriminated unions have to be a compiler feature.

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

#115

Post by heywhatupboys »

epgui wrote: post #109
heywhatupboys wrote: post #103

Earlier quoted context omitted.

well you see! What we can do is to namespace our functions, e.g. by naming them component_create, component_add_button, etc. We then create a plain dictionary with key value pairs that gets passed onto these functions! The functions then possibly return a new map, which is a modified map! This allows us to write code like dog = dog_create({name: "foo", age: 12}) dog = dod_add_friend(dog2) print(dog["friends"]) and we…

This comment shows a total misunderstanding of what functional programming is…

While tongue in cheek, this is one if the OP in non-OP patterns that is used heavily for large projects in FP alike.

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

#116

Post by tcfhgj »

CrimsonCape wrote: post #91
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…

I empathize with your characterization of "a tree of object/classes" and I yearn for an example of how else to model a complex, domain-specific system not using the aforementioned tree.

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

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

#117

Post by galaxyLogic »

fulafel wrote: post #88
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…

Languages are so fundamental, it's philosophy, and tools of expression. Debating better ways of doing these things is something that naturally happens in our heads and by extension in discours - the motivations aren't necessarily extrinsic. Even if your suspicion is right - since so many new programmers enter the field, absolute community sizes can still easily grow and hence we get more real-world viable languages.…

The thing about AI generated code is it may do what you want or it may do something else. It's hard to know which is the case. That means you the human programmer must verify the AI generated code. And to be able to do that, you must understand the code written by AI. That suggests that languages which are easy to read )i.e. to understand) will have an advantage in the AI era.

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

#118

Post by xupybd »

bmitc wrote: post #82
xupybd wrote: post #78

Earlier quoted context omitted.

You could have out of order function declarations.

Forcing linear dependence of files and definitions is considered a feature of F#. In codebases that allow out of order definitions, things get wild real quick.

Yeah I don't mind it. It forces a structure on you. I'm a fan of having common structures in a language.

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

#119

Post by belmont_sup »

chowells wrote: post #97
waffletower wrote: post #85

Earlier quoted context omitted.

Using a static language to manipulate complex types, particularly those sourced from a different type system (say complex nested Avro, SQL, or even complex JSON) is much more awkward when the types cannot be normalized into the language automatically as can be done with dynamic languages. Static languages require more a priori knowledge of data types, and are very awkward at handling collections with diverse type mem…

You realize every single thing that dynamically-typed languages can do with data types, statically-typed languages can do too? Except when it matters, they can also choose to do things dynamically-typed languages can't. Lots of people assume static typing means creating domain types for the semantics of every single thing, and then complain that those types contain far more information than they need. Well, stop doin…

Reminds me of https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-typ.... Always a fun revisit.

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

#120

Post by epgui »

xupybd wrote: post #41
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…

>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 don’t think you have any good reason to think you’re inherently less competent.

The most important thing is to always be learning. You’ll never be done, embrace that and rejoice in it. Most people more or less stop learning in early adulthood: don’t do that, and you’ll eventually be ahead of the pack.

Post reply on HN