Earlier quoted context omitted.
Am I guessing correctly that Scala is "getting in the way of getting things done"?
That's a Texas sized 10-4
What's so bad about Scala? I've only used it for hobby projects myself.
Why F# evangelism isn't working (2015)
321–330 of 333 posts
Re: Why F# evangelism isn't working (2015)
#322Earlier 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…
Would agree with this. I don't think the language choice, is as massive bet on the business as people think. I've seen much more niche and ancient langs without an ecosystem (no libraries, no SDK's to popular products, etc) build very profitable products. I would see these languages as a much greater risk.
As long as it has a base capability (libraries, maturity) and when people join they can be productive with it in a month or so then the risk is pretty low. For F# most .NET developers, even Node developers IMO will get used to F# relatively quickly. From my anecdotal experience with a number of languages its probably one of the easiest to onboard out of the FP langs balancing the FP methodology while trying to be practical/pragmatic. It has a large ecosystem via the .NET platform and supplements it with FP specific F# libraries where pragmatic to do so.
Re: Why F# evangelism isn't working (2015)
#323Earlier quoted context omitted.
I'm talking about improving C# by replacing LINQ with the more general Computation Expressions.
Ah. The C# compiler "duck types" LINQ so you can already (ab)use LINQ for general computation in C#. You can use nearly any Monad you want with LINQ syntax. It isn't always a strong fit for some types of Monads, but it is more capable than it seems. You might get some funny looks if you do, though. (Similar with async/await: it is "duck typed" at compile time so you can write other Monads for that, if they make more…
I don't think that LINQ has support for appicatives or custom operators. Although yes, it can be abused in impressive ways :)
Re: Why F# evangelism isn't working (2015)
#324Earlier quoted context omitted.
> In codebases that allow out of order definitions, things get wild real quick. Not an issue in C# at all. Get wild in what way?
It can be an issue in C#. I've seen some mad circular dependencies between files. The file hierarchy doesn't always reflect the namespace hierarchy which sometimes doesn't reflect the actual code dependencies hardly at all and untangling the messes that result from that can be a big deal. I'm not sure a project gets into that state "real quick", but it remains something that projects can do over time, sometimes witho…
I'm not sure why those things are necessarily a problem, particularly when with IDEs or at least editors that can parse a language's symbols. We're not programming the dark ages. Do you have a specific example of why these are an issue?
Re: Why F# evangelism isn't working (2015)
#325Earlier quoted context omitted.
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.
because you mentioned it 3 times
Re: Why F# evangelism isn't working (2015)
#326Earlier quoted context omitted.
You can’t do monkeypatching or dynamically modify the inheritance chain of an object in a statically typed language. But yes, you can have a JsonNode type, which is still better than having every type being “object”.
> You can’t do monkeypatching or dynamically modify the inheritance chain of an object in a statically typed language. There's no theoretical reason you can't. No languages that I know of provide that combination features, because monkey-patching is a terrible idea for software engineering... But there's no theoretical reason you couldn't make it happen. I think you've conflated static typing with a static language.…
So how would a statically typed language support conditionally adding methods at runtime? Lets say the code adds a method with name and parameters specified by user input at runtime. How could this possibly be checked at compile time?
Re: Why F# evangelism isn't working (2015)
#327Earlier quoted context omitted.
> You can’t do monkeypatching or dynamically modify the inheritance chain of an object in a statically typed language. There's no theoretical reason you can't. No languages that I know of provide that combination features, because monkey-patching is a terrible idea for software engineering... But there's no theoretical reason you couldn't make it happen. I think you've conflated static typing with a static language.…
So how would a statically typed language support conditionally adding methods at runtime? Lets say the code adds a method with name and parameters specified by user input at runtime. How could this possibly be checked at compile time?
You could add methods that nothing could call, sure. It would be like replacing the value with an instance of an anonymous subclass with additional methods. Not useful, but fully possible. Ok, it would be slightly useful if those methods were available to other things patched in at the same time. So yeah, exactly like introducing an anonymous subclass.
But monkey-patching is also often used to alter behaviors of existing things, and that could be done without needing new types.
Re: Why F# evangelism isn't working (2015)
#328Earlier quoted context omitted.
So how would a statically typed language support conditionally adding methods at runtime? Lets say the code adds a method with name and parameters specified by user input at runtime. How could this possibly be checked at compile time?
You could add methods that nothing could call, sure. It would be like replacing the value with an instance of an anonymous subclass with additional methods. Not useful, but fully possible. Ok, it would be slightly useful if those methods were available to other things patched in at the same time. So yeah, exactly like introducing an anonymous subclass. But monkey-patching is also often used to alter behaviors of exis…
How would you emulate monkeypatching with anonymous subclasses?
Re: Why F# evangelism isn't working (2015)
#329Earlier quoted context omitted.
You could add methods that nothing could call, sure. It would be like replacing the value with an instance of an anonymous subclass with additional methods. Not useful, but fully possible. Ok, it would be slightly useful if those methods were available to other things patched in at the same time. So yeah, exactly like introducing an anonymous subclass. But monkey-patching is also often used to alter behaviors of exis…
How would you emulate monkeypatching with anonymous subclasses?
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 anonymous.
In another dimension, you could use that feature in combination with something rather like Ruby's metaclasses to change definitions globally in a statically-typed language.
I can't think of a language that works this way currently out there, but there's nothing impossible about the design. It's just that no one wants it.
Re: Why F# evangelism isn't working (2015)
#330Earlier quoted context omitted.
How would you emulate monkeypatching with anonymous subclasses?
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?