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

131–140 of 333 posts

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

#131

Post by pharmakom »

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.

I used to write lots of C#, but now I consider it a bad ecosystem. The problem is the amount of ceremony, silly OOP abstractions, dependency injection, etc. Just look at building a simple HTTP endpoint in C# compared to Node or even F#!

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

#132

Post by pharmakom »

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.

The big difference between C# and F# styles (yes you can do either style in both languages, but with varying degrees of friction) is if that tree is mutable or immutable.

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

#133

Post by pharmakom »

Turskarama wrote: post #114
CrimsonCape wrote: post #93

Earlier quoted context omitted.

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.

Yep, Linq could be replaced by the more general Computation Expressions in F#

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

#134

Post by ykonstant »

c00lio wrote: post #128
epgui wrote: post #102

Earlier quoted context omitted.

> without being prone to floating off into abstraction orbit What do you mean by this?

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

>NullUnderstanding compiler extension

brilliant! lol

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

#135

Post by epgui »

ykonstant wrote: post #134
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!"

>NullUnderstanding compiler extension brilliant! lol

Is brilliant the best word? :P

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

#136

Post by el_oni »

tcfhgj wrote: post #116
CrimsonCape wrote: post #91

Earlier quoted context omitted.

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

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?

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

#137

Post by pharmakom »

waffletower wrote: post #60
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…

There is much naïveté among the strongly typed herd. When tasked to create glue code translating between two opposing type systems, which is a very common data engineering task, reaching for a strongly typed language is never the best option for code complexity and speed of development. Yet the hammer will often succeed if you hit hard enough and club the nail back to shape when you invariably bend it.

I have found that types are a benefit when it comes to debugging complex data systems because it moves component failures closer to the root cause.

Relevant blog post is Parse don't Verify

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

#138

Post by pharmakom »

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…

No, it's not.

You can write code in a statically typed language that treats the data as strings. The domain modelling is optional, just choose the level of detail that you need:

1. String

2. JSON

3. MyDTO

If you do choose 3, then you can avoid serde errors using property based testing

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

#139

Post by abstractcontrol »

ta-run wrote: post #59
local_crmdgeon wrote: post #35

Earlier quoted context omitted.

Agreed. Tweaks: I don't think C++ is going to be relevant for much longer, Rust solves the problem space better. Python ... maybe? It's so different than the rest, I can see it going the way of Ruby once AI bindings improve in other languages. I can also see Julia dominating the AI space. The "better than X" languages though? C#, F#, Scala? Done. I don't even hear about Kotlin that much anymore, Java is starting to a…

There's also MojoLang[0] that brands itself as a alternative to Python, and Google will look to release Carbon soon as well. It'll be interesting to see how these two grow. There's also Odin[1] that looks promising. I don't think C# is going anywhere, F# on the other hand :shrug: is at the mercy of MS - they always seem to be on the fence about it. [0] - https://www.modular.com/mojo [1] - http://odin-lang.org/

Mojo is a language that thinks it will impress the Python programmers with its ability to implement matrix multiplies directly in it. I don't think it will be that easy, but it might replace Cython.

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

#140

Post by rawling »

pharmakom wrote: post #131
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.

I used to write lots of C#, but now I consider it a bad ecosystem. The problem is the amount of ceremony, silly OOP abstractions, dependency injection, etc. Just look at building a simple HTTP endpoint in C# compared to Node or even F#!

> Just look at building a simple HTTP endpoint in C# compared to Node or even F#!

It's... basically the same? Include library, create server object, tell server object what request to handle and what to return, start server object.

https://learn.microsoft.com/en-us/aspnet/core/fundamentals/m...

Post reply on HN