12 ms·

> Hard to win technical arguments with Scala geniuses that like using complicated language features. I was on a team building good old crud apps using monads,

> Hard to win technical arguments with Scala geniuses that like using complicated language features. I was on a team building good old crud apps using monads, monoids, categories, combinators, effects cats, seamless and bunch of other nonsense that i've now purged from my brain. You could've easily mistaken our team for a programming language research group at a university. This is literally the number one reason i would never choose scala. There is no upper bound to amount of stupidity one can indulge in. Our code was so convoluted that even intellij had trouble understanding what the hell was going on and would spit out compilation errors when there were none. I now work with clojure team and i feel a sense of relief and weight taken off of my head from all the useless stuff i had to learn and use.

Cthulhu_ 6y ago
This is my biggest gripe with Scala as well. I'm sure it's a great language, but I've often seen it used to add complexity where none is necessary. It's abused to give developers a sense of accomplishment and intellectual superiority. In fact, in one project my former employer was involved in, one main reason they picked Scala was to, on the one hand, weed out the chaff from their existing team of .net developers (in a "shape up or ship out" kind of fashion), and on the other to weed out the 95% of mediocre Java developers.
- dominotw 6y ago
  > weed out the chaff from their existing team of .net developers This is scala equivalent of HN/pg lisp folklore.
- dboreham 6y ago
  > sense of accomplishment and intellectual superiority This, I feel, is underneath a very large proportion of everything in our industry.
- dmux 6y ago
  >...I've often seen it used to add complexity where none is necessary. This reminded me of a great blurb about Niklaus Wirth's approach to languages: >Wirth’s philosophy of programming languages is that a complex language is not required to solve a complex problem. On the contrary, he believes that l languages containing complex features whose purposes are to solve complex problems actually hinder the problem solving effort. The idea is that it is difficult enough for a programmer to solve a complex problem without having to also cope with the complexity of the language. Having a simple programming language as a tool reduces the total complexity of the problem to be solved. [0] [0] Pg.2 http://www.cslab.pepperdine.edu/warford/ComputingFundamentals/PboxCh01.pdf http://www.cslab.pepperdine.edu/warford/ComputingFundamental...
  - augustk 6y ago
    Niklaus Wirth designed and implemented the languages Pascal, Modula-2 and Oberon of which the last one is the smallest. https://miasap.se/obnc/oberon-report.html https://miasap.se/obnc/oberon-report.html
  - abhgh 6y ago
    What makes this quote really interesting is that Wirth was Martin Odersky's (guy who designed Scala) PhD advisor!
    - lmm 6y ago
      Scala is a very simple language at its heart. Unfortunately that empowers developers to write really complicated libraries, leaving application developers in much the same place as if they were using a language with complicated features. (Most application developers can't even tell the difference - most complaints about "Scala is a complex language" turn out to be "I was using a complex library in Scala")
      - cutler 6y ago
        Implicits are responsible for most of Scala's complexity whether you grok them or not.
MrPowers 6y ago
In the Spark world, you can use a tiny subset of the Scala features and enjoy huge productivity gains over the other language APIs (Java & Python). Those productivity gains are wiped out as more crazy language features get used. I don't think the super complex language features should be removed. Li's libs do some crazy stuff under the hood, but provide a clean, Python-like public interface. Most devs aren't that good and complex underlying implementations leak and yield complex public interfaces. Lots of folks would love Scala codebases that only use 10% of the available language features and none of the complex frameworks. But, like you mentioned, it's a hard language to use responsibly.
- deleted 6y ago
  [deleted]
- bcrosby95 6y ago
  > Lots of folks would love Scala codebases that only use 10% of the available language features and none of the complex frameworks. But, like you mentioned, it's a hard language to use responsibly. Does this have the same problem in large languages such as C++ though? Where everyone thinks there's an optimal subset of the language, but no one agrees on what that optimal subset is?
  - MrPowers 6y ago
    Yep, there is even a talk on the Scala Infinity War which argues for one subset version of Scala that it needs in order to survive: https://www.youtube.com/watch?v=v8IQ-X2HkGE&ab_channel=Scalape%C3%B1o https://www.youtube.com/watch?v=v8IQ-X2HkGE&ab_channel=Scala... For me, Scala is a multi-paradigm language with tons of features. The community just needs different types of style guides for different apps. vars are horrifying for the functional crowd, but cool with me for example.
  - deleted 6y ago
    [deleted]
- noisy_boy 6y ago
  I think the trick to using Scala is to read the high level/key features of the language (case classes/pattern matching/using Option/Some/None, type aliases etc) and basically stick to them. A good yardstick for what are those features is the Scala Book[0]. This is what I read before I started to actually code in Scala. That coupled with side-effect free functional style (as much possible without overstretching) uses the power of Scala and keeps the code concise and readable. That is how I use it and find it very pleasurable to write in Scala compared to Java. [0]: https://docs.scala-lang.org/overviews/scala-book/introduction.html https://docs.scala-lang.org/overviews/scala-book/introductio...
meowzero 6y ago
I love Scala. But arguing with intellectuals who HAVE to use these feature just because they can is a struggle I hate dealing with.
dkarl 6y ago
I'm on exactly that kind of team now. They've been working on a very simple problem for several years now and have an enormous, sophisticated, but still buggy and unstable solution. They're really smart people, and they had to be extremely capable programmers to get this far, but the embarrassing question is, how would a team of mediocre developers have tackled this problem? They would have picked a mediocre language and probably written a naive, straightforward solution, and after a few months of squashing bugs and developing production workarounds, it would have been a workable, tolerable system. They would have spent the last year working on something else. The naive solution would have more inherent unreliability, but our vast and intricate solution, designed to scale to the moon and be more self-healing than the T2000, is never going to approach the same reliability as a naive solution, because it's too complex (and the code is too hard for mortals to read and reason about) for us ever to iron out the bugs. They make a huge deal out of how much safer and easier to reason about our code is thanks to the FP discipline, but why do we have just as many concurrency-related production issues as a typical team using blocking operations and threadpools? Why do we have _more_ incorrectness caused by swallowed errors than I came to expect in projects that relied on exceptions? I'm still keen on mastering this style of Scala, because I think the benefits can be had, but it annoys me that some of my teammates are happy to use those stated benefits to justify their programming adventures without seeming to care if they actually materialize.
- yw3410 6y ago
  I am continually perplexed at the swallowing of exceptions in certain FP communities. Result types, Either et cetera make it extremely easy to swallow errors by flatMapping thoughtlessly losing the context of where they were - you typically /want/ the call stack when you hit into an exceptional flow.
  - Kototama 6y ago
    It makes the code impure (that is with side-effects). One can also argue that if you can encode the potential errors in the type they are not exceptional. It's not that bad though, because you get much less of these kind of errors than in a typical Java program (for example).
brainzap 6y ago
Clojure still sounds like research group to me.
- deleted 6y ago
  [deleted]
- Kototama 6y ago
  Tell that to Amazon, Apple, Netflix, Cognitect and all enterprises that produce reliable and performant software with it everyday.
  - randmeerkat 6y ago
    I don’t know of anyone at those companies using clojure and I haven’t seen any tech blogposts by those companies about using clojure. If clojure exists at those companies I imagine it’s a small very niche team.
    - yawaramin 6y ago
      And Walmart: https://news.ycombinator.com/item?id=19728502 https://news.ycombinator.com/item?id=19728502
    - joshlemer 6y ago
      One very public example of a Clojure shop through and through is NuBank out of Brazil, who employs some 700 "Clojure developers" according to them. In fact they are so committed to Clojure they bought Cognitect last year.
      - Kototama 6y ago
        Don't bother, I have the feeling randmeerkat will argue that if the team is so big, the language must be not expressive!
        randmeerkat 6y ago
runT1ME 6y ago
>I was on a team building good old crud apps using monads, monoids, categories Here's the thing, if you look at a basic Spring crud app, you are also using Monads, Monoids, Categories, Traverse, etc. but you aren't expressing it in the type system. Seriously go look at modern Spring's flux stuff, it's all there minus the type classes. I've seen teams that tried to over engineer Spring, teams that tried to over engineer Node applications, and yes there are teams that over engineer Functional style Scala. All the teams I worked with (and managed) at Verizon leaned pretty heavily into FP style Scala without much over engineering and the experience was extremely pleasant. The only production issues in my three years there I remember were performance related, finding out how to get more throughput or lower latency out of FP Scala. I literally can't remember any 'bugs' that made it to production.
- yw3410 6y ago
  Verizon's Scala projects are very cool - I wish that they got more limelight and documentation/support.
- wtetzner 6y ago
  Yeah, I'd say that Spring is the Java equivalent of the same problem (over-engineering), just using reflection and runtime bytecode generation instead. I agree that using Monads, Monoids, etc. isn't necessarily indicative of over engineering in itself. If used well they can make the code clearer/simpler.
- dominotw 6y ago
  > Seriously go look at modern Spring's flux stuff, it's all there minus the type classes. I don't use spring or plan to use it. Not quite sure why it needs to be looked up. What are you trying to say?
  - runT1ME 6y ago
    I'm postulating that any modern CRUD app framework has Monads, Monoids, and other categorically inspired structure, even if they don't call it that or have a way to abstract over it.
dionian 6y ago
Just because you don't like it doesn't mean you should be a good fit for their team.
phendrenad2 6y ago
> I was on a team building good old crud apps using monads, monoids, categories, combinators, effects cats, seamless and bunch of other nonsense that i've now purged from my brain. Ah I had the same experience. That this is allowed to happen just shows that putting naive non-technical managers in charge of coders is a disaster.
jjav 6y ago
> You could've easily mistaken our team for a programming language research group at a university. I had the misfortune of working with basically this same team, on scala (of course). I argued for maintainable simple technology but scala was too hip to pass, for many. Still remember one meeting trying to decipher a bug and while reviewing the code in question the lead scala fan said "It is not reasonable to expect to understand what code does by looking at it. I'll need to go research this for a few days." I hope to never see scala (or its ilk) ever again. Give me the most stable language and environment, where every question is a FAQ and every odd behavior is documented in every book and I never need to fall into the rabbit hole of language traps. Then I can just work on building the product, which is the whole point.

Cthulhu_ 6y ago

This is my biggest gripe with Scala as well. I'm sure it's a great language, but I've often seen it used to add complexity where none is necessary. It's abused to give developers a sense of accomplishment and intellectual superiority. In fact, in one project my former employer was involved in, one main reason they picked Scala was to, on the one hand, weed out the chaff from their existing team of .net developers (in a "shape up or ship out" kind of fashion), and on the other to weed out the 95% of mediocre Java developers.

dominotw 6y ago
> weed out the chaff from their existing team of .net developers This is scala equivalent of HN/pg lisp folklore.
dboreham 6y ago
> sense of accomplishment and intellectual superiority This, I feel, is underneath a very large proportion of everything in our industry.
dmux 6y ago
>...I've often seen it used to add complexity where none is necessary. This reminded me of a great blurb about Niklaus Wirth's approach to languages: >Wirth’s philosophy of programming languages is that a complex language is not required to solve a complex problem. On the contrary, he believes that l languages containing complex features whose purposes are to solve complex problems actually hinder the problem solving effort. The idea is that it is difficult enough for a programmer to solve a complex problem without having to also cope with the complexity of the language. Having a simple programming language as a tool reduces the total complexity of the problem to be solved. [0] [0] Pg.2 http://www.cslab.pepperdine.edu/warford/ComputingFundamentals/PboxCh01.pdf http://www.cslab.pepperdine.edu/warford/ComputingFundamental...
- augustk 6y ago
  Niklaus Wirth designed and implemented the languages Pascal, Modula-2 and Oberon of which the last one is the smallest. https://miasap.se/obnc/oberon-report.html https://miasap.se/obnc/oberon-report.html
- abhgh 6y ago
  What makes this quote really interesting is that Wirth was Martin Odersky's (guy who designed Scala) PhD advisor!
  - lmm 6y ago
    Scala is a very simple language at its heart. Unfortunately that empowers developers to write really complicated libraries, leaving application developers in much the same place as if they were using a language with complicated features. (Most application developers can't even tell the difference - most complaints about "Scala is a complex language" turn out to be "I was using a complex library in Scala")
    - cutler 6y ago
      Implicits are responsible for most of Scala's complexity whether you grok them or not.

MrPowers 6y ago

In the Spark world, you can use a tiny subset of the Scala features and enjoy huge productivity gains over the other language APIs (Java & Python). Those productivity gains are wiped out as more crazy language features get used. I don't think the super complex language features should be removed. Li's libs do some crazy stuff under the hood, but provide a clean, Python-like public interface. Most devs aren't that good and complex underlying implementations leak and yield complex public interfaces. Lots of folks would love Scala codebases that only use 10% of the available language features and none of the complex frameworks. But, like you mentioned, it's a hard language to use responsibly.

deleted 6y ago
[deleted]
bcrosby95 6y ago
> Lots of folks would love Scala codebases that only use 10% of the available language features and none of the complex frameworks. But, like you mentioned, it's a hard language to use responsibly. Does this have the same problem in large languages such as C++ though? Where everyone thinks there's an optimal subset of the language, but no one agrees on what that optimal subset is?
- MrPowers 6y ago
  Yep, there is even a talk on the Scala Infinity War which argues for one subset version of Scala that it needs in order to survive: https://www.youtube.com/watch?v=v8IQ-X2HkGE&ab_channel=Scalape%C3%B1o https://www.youtube.com/watch?v=v8IQ-X2HkGE&ab_channel=Scala... For me, Scala is a multi-paradigm language with tons of features. The community just needs different types of style guides for different apps. vars are horrifying for the functional crowd, but cool with me for example.
- deleted 6y ago
  [deleted]
noisy_boy 6y ago
I think the trick to using Scala is to read the high level/key features of the language (case classes/pattern matching/using Option/Some/None, type aliases etc) and basically stick to them. A good yardstick for what are those features is the Scala Book[0]. This is what I read before I started to actually code in Scala. That coupled with side-effect free functional style (as much possible without overstretching) uses the power of Scala and keeps the code concise and readable. That is how I use it and find it very pleasurable to write in Scala compared to Java. [0]: https://docs.scala-lang.org/overviews/scala-book/introduction.html https://docs.scala-lang.org/overviews/scala-book/introductio...

meowzero 6y ago

I love Scala. But arguing with intellectuals who HAVE to use these feature just because they can is a struggle I hate dealing with.

dkarl 6y ago

I'm on exactly that kind of team now. They've been working on a very simple problem for several years now and have an enormous, sophisticated, but still buggy and unstable solution. They're really smart people, and they had to be extremely capable programmers to get this far, but the embarrassing question is, how would a team of mediocre developers have tackled this problem? They would have picked a mediocre language and probably written a naive, straightforward solution, and after a few months of squashing bugs and developing production workarounds, it would have been a workable, tolerable system. They would have spent the last year working on something else. The naive solution would have more inherent unreliability, but our vast and intricate solution, designed to scale to the moon and be more self-healing than the T2000, is never going to approach the same reliability as a naive solution, because it's too complex (and the code is too hard for mortals to read and reason about) for us ever to iron out the bugs. They make a huge deal out of how much safer and easier to reason about our code is thanks to the FP discipline, but why do we have just as many concurrency-related production issues as a typical team using blocking operations and threadpools? Why do we have _more_ incorrectness caused by swallowed errors than I came to expect in projects that relied on exceptions? I'm still keen on mastering this style of Scala, because I think the benefits can be had, but it annoys me that some of my teammates are happy to use those stated benefits to justify their programming adventures without seeming to care if they actually materialize.

yw3410 6y ago
I am continually perplexed at the swallowing of exceptions in certain FP communities. Result types, Either et cetera make it extremely easy to swallow errors by flatMapping thoughtlessly losing the context of where they were - you typically /want/ the call stack when you hit into an exceptional flow.
- Kototama 6y ago
  It makes the code impure (that is with side-effects). One can also argue that if you can encode the potential errors in the type they are not exceptional. It's not that bad though, because you get much less of these kind of errors than in a typical Java program (for example).

brainzap 6y ago

Clojure still sounds like research group to me.

deleted 6y ago
[deleted]
Kototama 6y ago
Tell that to Amazon, Apple, Netflix, Cognitect and all enterprises that produce reliable and performant software with it everyday.
- randmeerkat 6y ago
  I don’t know of anyone at those companies using clojure and I haven’t seen any tech blogposts by those companies about using clojure. If clojure exists at those companies I imagine it’s a small very niche team.
  - yawaramin 6y ago
    And Walmart: https://news.ycombinator.com/item?id=19728502 https://news.ycombinator.com/item?id=19728502
  - joshlemer 6y ago
    One very public example of a Clojure shop through and through is NuBank out of Brazil, who employs some 700 "Clojure developers" according to them. In fact they are so committed to Clojure they bought Cognitect last year.
    - Kototama 6y ago
      Don't bother, I have the feeling randmeerkat will argue that if the team is so big, the language must be not expressive!
      - randmeerkat 6y ago

runT1ME 6y ago

>I was on a team building good old crud apps using monads, monoids, categories Here's the thing, if you look at a basic Spring crud app, you are also using Monads, Monoids, Categories, Traverse, etc. but you aren't expressing it in the type system. Seriously go look at modern Spring's flux stuff, it's all there minus the type classes. I've seen teams that tried to over engineer Spring, teams that tried to over engineer Node applications, and yes there are teams that over engineer Functional style Scala. All the teams I worked with (and managed) at Verizon leaned pretty heavily into FP style Scala without much over engineering and the experience was extremely pleasant. The only production issues in my three years there I remember were performance related, finding out how to get more throughput or lower latency out of FP Scala. I literally can't remember any 'bugs' that made it to production.

yw3410 6y ago
Verizon's Scala projects are very cool - I wish that they got more limelight and documentation/support.
wtetzner 6y ago
Yeah, I'd say that Spring is the Java equivalent of the same problem (over-engineering), just using reflection and runtime bytecode generation instead. I agree that using Monads, Monoids, etc. isn't necessarily indicative of over engineering in itself. If used well they can make the code clearer/simpler.
dominotw 6y ago
> Seriously go look at modern Spring's flux stuff, it's all there minus the type classes. I don't use spring or plan to use it. Not quite sure why it needs to be looked up. What are you trying to say?
- runT1ME 6y ago
  I'm postulating that any modern CRUD app framework has Monads, Monoids, and other categorically inspired structure, even if they don't call it that or have a way to abstract over it.

dionian 6y ago

Just because you don't like it doesn't mean you should be a good fit for their team.

phendrenad2 6y ago

> I was on a team building good old crud apps using monads, monoids, categories, combinators, effects cats, seamless and bunch of other nonsense that i've now purged from my brain. Ah I had the same experience. That this is allowed to happen just shows that putting naive non-technical managers in charge of coders is a disaster.

jjav 6y ago

> You could've easily mistaken our team for a programming language research group at a university. I had the misfortune of working with basically this same team, on scala (of course). I argued for maintainable simple technology but scala was too hip to pass, for many. Still remember one meeting trying to decipher a bug and while reviewing the code in question the lead scala fan said "It is not reasonable to expect to understand what code does by looking at it. I'll need to go research this for a few days." I hope to never see scala (or its ilk) ever again. Give me the most stable language and environment, where every question is a FAQ and every odd behavior is documented in every book and I never need to fall into the rabbit hole of language traps. Then I can just work on building the product, which is the whole point.