Monocle: Optics Library for Scala
41–50 of 70 posts
Re: Monocle: Optics Library for Scala
#42Developer 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.
Re: Monocle: Optics Library for Scala
#43am I the only one who isn't a little disappointed that this wasn't a library to model the physics of physical lenses?
Re: Monocle: Optics Library for Scala
#44I'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.
* Complaints about tooling and ecosystem were valid maybe 10 years ago, but not now.
* You don't say what your point of comparison is. (weaker than what?)
* Performance has never been an issue for general programming tasks
* You disregard the value that language brings
* Running functional programs on a CPU has not been an issue since, roughly, the 1970s when the basics of compiling FP languages were worked out.
Re: Monocle: Optics Library for Scala
#45I'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.
I don't think this comment reflects reality. A few issues: * Complaints about tooling and ecosystem were valid maybe 10 years ago, but not now. * You don't say what your point of comparison is. (weaker than what?) * Performance has never been an issue for general programming tasks * You disregard the value that language brings * Running functional programs on a CPU has not been an issue since, roughly, the 1970s when…
Re: Monocle: Optics Library for Scala
#46Earlier quoted context omitted.
I don't think this comment reflects reality. A few issues: * Complaints about tooling and ecosystem were valid maybe 10 years ago, but not now. * You don't say what your point of comparison is. (weaker than what?) * Performance has never been an issue for general programming tasks * You disregard the value that language brings * Running functional programs on a CPU has not been an issue since, roughly, the 1970s when…
None of that answered the question of what's the value proposition is, while also missing the point of several criticism.
Given your comment about stateful CPUs I imagine you don't think programming languages are particularly important. Not everyone does, but opinions do differ on that.
> also missing the point of several criticism
I can't correct my misunderstandings if you don't state what they are.
Re: Monocle: Optics Library for Scala
#47I'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.
https://cwiki.apache.org/confluence/display/FLINK/FLIP-265+D...
An aggregation engine like that was otherwise a good fit for a functional-ish language like Scala.
That said - it is a nice language. Native support for simple functional language constructs (map / flatmap, Option, Try), without having to go all-in on functional style.
Re: Monocle: Optics Library for Scala
#48I'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.
Re: Monocle: Optics Library for Scala
#49I'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.
If developers are more expensive, presumably there's a reason they're able to ask those rates besides "they know scala".
Re: Monocle: Optics Library for Scala
#50I'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.
From there you have Java, Scala, and Kotlin as primary choices.
Up until 2020 java didn't have pattern matching or records, and kotlin still doesn't have a full implementation.
Scala offers an ecosystem where its very easy to build a robust type system, supporting clear co and contravariance and clear control flow due to pattern matching.
On top of that scala's compiler plugin ecosystem is quite good and it allows large organizations to abstract away a lot of busy work to dedicated internal teams. This is used extensively in large scala codebases I have seen.
Scala is a fantastic language for core business technology, in fact thats probably the single thing its best at. Its why the largest code bases I know of are in financial institutions.
DX/tooling is a valid point, but the large scala codebases that exist within orgs have their own tooling that solves this, at least old twitter and the financial institutions do.
So to answer your question, why would someone choose scala in a business sense. Any JVM project built between like 2009-2019 had a compelling reason to choose scala over the other options and maintains those advantages though other languages have implemented most of the key features so the gap is much smaller.