61–70 of 70 posts
am I the only one who isn't a little disappointed that this wasn't a library to model the physics of physical lenses?
By "isn't a little disappointed" do you mean very disappointed or not disappointed at all? Although that may not be an important distinction as I think the two groups are roughly the same size.
I'm still trying to reason what the value proposition of Scala is in a business sense. Developer are more expensive and harder to find, the tooling is weaker, the ecosystem less deep, performance suspect, and the overall XP feels clunky. Plus our hardware is procedural, and contains/manages state within the instruction pipeline. I strongly believe it doesn't belong as a core business technology.
Poor Scala devs output complete junk, however high performers produce incredibly elegant and concise code.
Earlier quoted context omitted.
The small pool of experienced developers is actually awesome. I waste a lot less time screening candidates and they're usually above average. Moreover, despite what people claim I've had no issues mentoring juniors or people coming from other paradigms but willing to learn. Tooling isn't as good as plain Java but good enough, and certainly better than that of more niche FP languages. The ecosystem is pretty rich in s…
You have a lot fewer candidates to pull from too, which is often a more limiting factor for a business. Business don't need everyone to be a rockstar who's also a FP whiz. But FP languages need that.
It's true you need some level of expertise and seniority, but that doesn't mean you need to hire only FP wizards, far from it. I believe most modern hybrid languages can be dangerous without supervision.
Earlier quoted context omitted.
You have a lot fewer candidates to pull from too, which is often a more limiting factor for a business. Business don't need everyone to be a rockstar who's also a FP whiz. But FP languages need that.
For what it's worth, Scala is a multi-paradigm language and can be used as a pure OO language. This is a great way to start for programmers with an OO background
Earlier quoted context omitted.
Does it offer creating a mutable view on top of the immutable structure that can be used to accumulate a whole set of changes to later be materialized into a copy with the changes? (or to be used directly, at whatever cost would be required) That's something I've been wondering why it's not more of an established thing. It would basically be docker, but for in-memory reference graphs instead of filesystems.
You can compose together a bunch of edit operations (an edit command, if you like) and apply them at once at the end, is that what you mean?
Earlier quoted context omitted.
Performance is in the same space as java or go, but it's a much higher level language, so easier to write, easier to read, and easier to review. The language prevents many classes of errors without cluttering the written logic, so it's easier to understand what it's doing in terms of business domain. The jvm ecosystem is also massive. If developers are more expensive, presumably there's a reason they're able to ask t…
> Performance is in the same space as java or go, but it's a much higher level language, so easier to write, easier to read, and easier to review. What metrics are you using to make the claim that it's "easier" than more widely known, better tooled, and easier to search languages? >The language prevents many classes of errors without cluttering the written logic, so it's easier to understand what it's doing in terms…
So if you ask such a question, do you really expect anything more than people's firsthand experiences?
But I'll tell you my own side as well: doing anything with concurrency in any other language (yes, including Go and Rust) is just much much harder in comparison to Scala.
No wait, that's not true. There are languages that are better suited for that. But they are either academic or extremely niche and come with other problems (such as lack of ecosystem or much worse performance).
> The fact is there a fewer FP devs. Why is that if FP is "better"?
The fact is also that the number of FP devs has been and is growing. And so has the number of languages with those features.
> There's fewer Scala devs, because Scala isn't better.
What metrics are you using to make the claim that it "isn't better"?
Earlier quoted context omitted.
You can compose together a bunch of edit operations (an edit command, if you like) and apply them at once at the end, is that what you mean?
Kind of. Can you use the interim state fork (original plus changes, not yet committed into a new immutable) as a "readable" type, the union of mutable and immutable variants? That would resolve choice dilemmas like the decision between mutable and immutable builders: keep the mutable where it is only used by the creating thread, materialise into an immutable when it needs to cross thread boundaries, fork where a thre…
Not really, not at a language semantics level - although in practice if you applied your current mutation to the original object, did something with the result, and then threw the "partially edited object" away, the JVM's escape analysis might catch that and never fully materialise the "partially edited object". Note that nothing is really mutable, not even your edit operations - you form your combined edit by composing together a bunch of smaller edits, but all those edits are immutable.
Earlier quoted context omitted.
Kind of. Can you use the interim state fork (original plus changes, not yet committed into a new immutable) as a "readable" type, the union of mutable and immutable variants? That would resolve choice dilemmas like the decision between mutable and immutable builders: keep the mutable where it is only used by the creating thread, materialise into an immutable when it needs to cross thread boundaries, fork where a thre…
> Can you use the interim state fork (original plus changes, not yet committed into a new immutable) as a "readable" type, the union of mutable and immutable variants? Not really, not at a language semantics level - although in practice if you applied your current mutation to the original object, did something with the result, and then threw the "partially edited object" away, the JVM's escape analysis might catch th…
Earlier quoted context omitted.
> Performance is in the same space as java or go, but it's a much higher level language, so easier to write, easier to read, and easier to review. What metrics are you using to make the claim that it's "easier" than more widely known, better tooled, and easier to search languages? >The language prevents many classes of errors without cluttering the written logic, so it's easier to understand what it's doing in terms…
There are no studies for anything, and if there were, they would be outdated by the time they are published. So if you ask such a question, do you really expect anything more than people's firsthand experiences? But I'll tell you my own side as well: doing anything with concurrency in any other language (yes, including Go and Rust) is just much much harder in comparison to Scala. No wait, that's not true. There are l…
Those are all quantified with out a research study.
Earlier quoted context omitted.
> Performance is in the same space as java or go, but it's a much higher level language, so easier to write, easier to read, and easier to review. What metrics are you using to make the claim that it's "easier" than more widely known, better tooled, and easier to search languages? >The language prevents many classes of errors without cluttering the written logic, so it's easier to understand what it's doing in terms…
My claim is backed by years of direct experience with C, C++, Java, Go, Scala, PHP, and Python. I can tell you that Scala has been the easiest to write, read, and review by far. I'm not sure why you'd expect "easier to read and review" to be metrizable. Nor do I see the connection between those things and wide use, tooling, or searchability. If you need to search something to understand what you're reading, I suppose…
That makes it worse as a language overall because of the reduced devex.
You may personally find it great, but as a business language, it isn't.