Live data from Hacker News

Why F# evangelism isn't working (2015)

ericsink.com

331–333 of 333 posts

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

#331

Earlier quoted context omitted.

That's a Texas sized 10-4

What's so bad about Scala? I've only used it for hobby projects myself.

Using it in a context where you need to make money, it's a bad bet. Fine for academic ideas and such things, but really hard to build a business around. And the tooling, community, libs, and docs show how it just can't punch the same weight as other languages when at the end of the day you need to get shit done.

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

#332
post #320

Earlier quoted context omitted.

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.

Care to elaborate? Are there any big frameworks in the mix that might have gone from oss to commercial?

We have both Akka and http4s in use, and are migrating to http4s for those services. We need to do more things more quickly with fewer hands. TS and Python are just easier and better tooled for the majority of our (CRUD) work.

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

#333

Earlier quoted context omitted.

You would need another feature in addition: the ability to change the runtime type tag of a value. Then monkey-patching would be changing the type of a value to a subclass that has overridden methods as you request. The subclasses could be named, but it wouldn't have much value. As you could repeatedly override methods on the same value, the names wouldn't be of much use, so you might as well make the subclass anonym…

So how would you compile code which contains a call to a method which is only defined at runtime?

In a dynamic language, everything is only defined at runtime.

Given that, a sketch of a statically-typed system would be something like... At the time a definition is added to the environment, you type check against known definitions. Future code can change implementations, as long as types remain compatible. (Probably invariantly, unless you want to include covariant/invariant annotations in your type system...)

This doesn't change that much about a correct program in a dynamic language, except that it may provide some additional ordering requirements in code execution - all the various method definitions must be loaded before code using them is loaded. That's a bit more strict than the current requirement they the methods must be loaded before code using them is run. But the difference would be pretty tractable to code around.

And in exchange, you'd get immediate feedback on typos. Or even more complex cases, like failing to generate some method you had expected to create dynamically.

Ok, I can actually see some appeal here, though it's got nothing to do with monkey-patching.

Post reply on HN