9 ms·

I had a startup that went all in on scala. By the time we realized we chose the wrong language it was too late. Complexity is the primary issue with the scala

I had a startup that went all in on scala. By the time we realized we chose the wrong language it was too late. Complexity is the primary issue with the scala language... when the whole goal is to have a scalable language which in itself is diametrically opposed to simplicity, your language is dead on arrival. After using Scala, Go seemed like a dream come true. We really loved the integration of OO and FP, really miss the FP awesomeness honestly... but simplicity trumps doing either of those things well.

KingOfCoders 6y ago
We chose Scala, had so many problems with the eco system and compiler and community, still love the language, it's the programming language I've enjoyed most, but glad we sold the startup.
tootie 6y ago
I only witnessed from the outside, but saw a similar story play out. A client had bet on Scala for a new platform and made it about 6 months in before throwing in the towel and rewriting the whole thing in in Java. It's too hard to recruit and the tooling isn't mature enough.
- mumblemumble 6y ago
  I didn't run into problems with recruiting in general being too difficult. Plenty of people are interested in FP and are eager to do it professionally. But recruiting the right mix of people can be a challenge. Scala tends to attract people with an experimental temperament, and scare away more conservative developers. A team needs a healthy mix of both, though. It's the creative tension among different attitudes about how to write code that yields the best work in the long run.
  - worldsayshi 6y ago
    In contrast I think that going all in on Java scares away people who like to experiment.
    - eternalban 6y ago
      Be honest and give a short list of experimental approaches that you wanted to do and couldn't be done on Java. What did you want to do and couldn't? And, let's ask Rich Hickey. What language was it he used to experiment with a new s-expression language? Why wasn't RH scared away? You want the brutal honest answer? Because he is smart and can grok the complexity of the Java in toto. What sort of experiments can you not do on a virtual machine based language, with open byte code/vm spec, open class loaders, and compile and runtime instrumentation and meta- capabilities? I used to do the switch the superclass at loadtime to experiment with adaptable programs. This was circa late 90s. Loads of fun (npi). What scares many away from Java is that it is now a very huge mental object. But not wanting to admit this, they simply pass along FUD.
      - fctorial 6y ago
        > I used to do the switch the superclass at loadtime to experiment with adaptable programs. This probably falls in undefined behavior territory. What kind of errors did you get when something went wrong?
        eternalban 6y ago
        It is not undefined behavior. Bytecodes are modified via custom CL and superclass was swapped from e.g. Object to something else. As for errors, honestly its been 23+ years so don’t really remember. Naturally you can’t just swap any random class - it has to be correct e.g. can’t have an override method in the child that has no corresponding method in the super. And if memory serves, you can also play this trick using classpaths. Assume a stub package com.foo.Context which is simply an extension of Object, and derive components from com.foo.Context.SuperClass. You simply need to provide a different eponymous package for the adapted instance of the code. https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.ht...
        hderms 6y ago
        I've definitely experienced some scary bugs caused by runtime bytecode injection (from a tracing library). I didn't bother tracking it down further than identifying it was at the intersection of some slightly strange type and the tracing. Caused VM errors when this method was called but only when the tracing was configured. Not saying it's not interesting to experiment with things like that, but there are non-trivial associated, if you ask me, to depending on it in production.
  - rednum 6y ago
    Yeah, good luck when someone with experimental temperament decides to implement some of your crucial functionality with semialgebras. (that's what happened in my previous job where we run Scala). I'm happy I didn't have to debug any customer issues around that module. Also, I didn't enjoy constant bickering with my reviewers what makes a beautiful code or not. Apparently there are five ways to do everything in Scala and I always ended up picking not the one my teammates would like the most.
    - mumblemumble 6y ago
      Yes. That's pretty much how the Scala project I was working on ran itself aground. Everyone got so caught up in flexing at each other that solving actual business problems became a secondary priority.
      - nowherebeen 6y ago
        This points to a culture problem more than the language itself though.
        mumblemumble 6y ago
        Interestingly, when we were working on the Java code, we didn't have this problem. Same people, same time, same git repository, different modules.
        milesvp 6y ago
        This doesn’t terribly surprise me. Community isn’t just the people but also the customs and idioms within the community. It’s probably similar to ‘code switching’ in verbal languages. People talk (and act) differently depending on who thay’re talking to.
      - randmeerkat 6y ago
        This is why I think the community is way more important than the language. In Python people are like, hmm, this is a hack, but it works for now, in Scala it’s, what have you done you savage?!?
- closeparen 6y ago
  I thought it was understood that choosing a less popular language meant hiring people for fundamentals and then letting them ramp on on your language. Did the client choose Scala thinking they would just hire "Scala people"?
  - hderms 6y ago
    If you stick to a reasonable middle-ground of scala it really shouldn't be hard to teach. I do like the FP community but that style has gone a long way towards mythologizing scala as an impossible language to teach. In my experience it's clearly considerably simpler than Rust or C++ to become productive in.
amitport 6y ago
Scala has its place... it's just not one that requires fast on-boarding (like a small startup where people constantly come and go). The success stories usually involve companies that are mature enough to spend time on design, training, and supervision (wix, for example)
dwhitney 6y ago
I think mixing the OO and FP is the crux of the problem. Type inference and subtyping (class based inheritance) don't mix well, and often require type annotations to help the compiler when types get somewhat complex. Eventually you develop an instinct for it, and it's not a problem, but the road to developing that instinct is littered with torn out hair. (edit: spelling)
- joshuapassos 6y ago
  Maybe the best approach is using a language with dynamic types ? (e.g: cloujure)
- weatherlight 6y ago
  I have found that languages that support both FP and OO paradigms its best to do things like data manipulation in FP, and use OO to encapsulate those processes and be limited to just passing messages to other objects. Avoid inheritance. Once an object is instantiated, don't change its internal state. etc.
  - jdmichal 6y ago
    This is my philosophy: Data types are object-oriented. They are responsible for ensuring that their internal state is consistent, and nothing more. They may inherit if it makes sense, but it usually doesn't and most of the time aggregation is more appropriate. Business rules are functional. There's just a bag of composable, pure functions that take the various data types and perform validations, transformations, etc. External services, such as a database, are contractual. This would be an interface in Java or C# defining the required operations of the service. This allows manipulation of these external services during testing. Unit testing would mock them; integration testing would not. Workflows or services are procedural. They combine everything else into an actual use-case. They read in a linear flow of what needs to happen when to meet the use-case.
    - hderms 6y ago
      Great breakdown. Seriously, I've had very similar ideas but never tried to build a coherent mapping like this. Thanks for writing it out!
blacktriangle 6y ago
I wouldn't blame the language, I'd blame the people who chose Scala. The impression I always had was that Scala was a research project into how various programming language features could live together and interact, hence their everything and the kitchen sink approach. From an academic point of view I think Scala was a huge success. That people chose to use Scala in production speaks more to how badly people hate Java and want an alternative, not to Scala's failings.
- foobarian 6y ago
  Recent Javas made many QoL improvements to remove some of the complaints IMO. And there are more neat improvements coming (already there?) with 15 and 17.
  - nine_k 6y ago
    Also, Kotlin is a rather nice and much less radical "better Java", well-supported, but mostly popular on mobile.
    - The_rationalist 6y ago
      Kotlin on the server is growing though and has the biggest library ecosystem to exist
      - dehrmann 6y ago
        Glad to hear this. There's really no reason it for it not to do well on the server.
    - gher-shyu3i 6y ago
      Pattern matching is (will be) better implemented in Java. It's fully fledged compared to Kotlin's implementation.
      - nine_k 6y ago
Akronymus 6y ago
Pretty much a noob at FP in general: Wouldn't f# solve the FP and OO integration?
- hurril 6y ago
  I did Scala for ten years and've been at it with F# for a year and a half now. I do miss some very powerful features of Scala such as HKT and "typeclasses" occasionally but overall it works very well. Sure, Scala is complex but I find that there are a few misunderstandings here. Java, for instance, _requires_ that you use a number of supporting tools for it to be useful these days. You need a container, you need quite extensive testing and you need quite the advanced build tools. Sure, these have all been around long enough these days to not be what we think about when we compare Java to other things, but they're implicitly also Java. I can't speak for Go because I've not looked at it. But Scala has strengths that means that you don't need to have _external_ tools and libraries for those things. That strength is types which means that the compilers is going to want to "pick a fight" with you to a very much higher frequency. That is a pain. The reason that we're here talking about that pain with Scala is that you don't think about that in your Java project anymore because you use heuristics and sandy heads instead. Another thing is that I think that Scala gives you a big fat revolver to shoot yourself in the foot with. Java has a bb-gun so no matter where you aim it, you're not going to accomplish a lot. Over to F#: I'm going to claim that the .NET toolchain is superior to the JVM ones. The CLI tools and paket runs circles around the POS that is SBT.
  - thu2111 6y ago
    Huh, I use Java all the time without containers. You definitely don't need them.
spaced-out 6y ago
>We really loved the integration of OO and FP, really miss the FP awesomeness honestly... but simplicity trumps doing either of those things well. Agreed. I like the Scala language, but I can't imagine a scenario where I would recommend it for a project over Java.
cmrdporcupine 6y ago
I think Scala needs to be treated something like how smart shops treat C++: there's so much there you can hang yourself with, so you need to define a subset/dialect and create a style guide and stick with it. This is how C++ has been successful at Google, and it's how I'd approach something like Scala if I were to go back to doing it now.
- a4isms 6y ago
  An evergreen conversation: "I love C++." —Alice "Oh? Which C++?" —Bob Every successful C++ team defines its own C++ subset.
  - the_only_law 6y ago
    This is why I can't figure out how for the life of me to learn C++ effectively for professional use.
    - aninteger 6y ago
      In reality it's not really like that. Yes different shops are going to be using different C++ features in different ways but they usually share some common "core" of the language.
    - Jeff_Brown 6y ago
      One approach is to get a sample of code from the domain you want to inhabit, preferably including some from the very people you want to work with, and learn the subset of the language they use.
  - agumonkey 6y ago
    Also Stroustrup thinks that is the way to use cpp, his talks are all about 'do not use all of cpp, pick your features'. Makes senses in a way but it does lead to various notion of what cpp is.
- AzzieElbab 6y ago
  That is exactly it. A company wide style and coding guide is a must with scala
foobarian 6y ago
There is a tendency I observed in engineers to not want to appear dumb. This is a recipe for disaster when coupled with a deep language like Scala, because nobody wants to solve problems the simple way, and Scala gives a tremendous amount of rope. That's why I think it's only a suitable choice for very experienced or disciplined teams, with a strong consensus on style or any DSLs. I can see average enterprise shops lacking these things and ending up with suboptimal results if Scala is used.
- rednum 6y ago
  > to not want to appear dumb Few production incidents are enough to change this mentality. I'd rather write more verbose but "obvious" code than "clever one liners". I feel sorry for anyone who has to understand someone's DSL on the fly when there's an outage and your business is burning through X$ per minute of downtime. (On the other hand, you probably want to structure your production changes in the way that they are easy to roll back without understanding everything, but that's other conversation. Either way, the thought that someone may want to chase me after work because my code broke and they can't understand it is enough for me to stop being clever).
PopsiclePete 6y ago
> but simplicity trumps doing either of those things well. That's the genius (?) of Go. They gave us what we didn't know we needed. Software people love the "manliness" that comes with "serious", "real" programming languages. Maybe it's the desire to impress our peers with our intelligence? But in the end the only thing that matters is whether you can get your shit done and on time in at least a semi-working state.
- hderms 6y ago
  I appreciate what you're getting at, but is Go really the epitome of a "get things done" language? It seems to suffer from some serious boilerplate issues even compared to something like Java. As far as it being driven my machismo, I think that's part of it, but I'd be more inclined to blame it on the following: * complex languages/mental frameworks function as an "intellectual trap" where people more inclined to be interested in intellectual things for their own sake start to lose site of the forest for the trees. * FOMO that one must keep up to speed with all the coolest new developments in programming or face mounting irrelevance * Elitism/self promotion where specializing in something difficult (and potentially keeping newcomers out) either provides internal or external motivation I think some of these traits seem somewhat correlated with the "nerd machismo" archetype but I think the actual causes are multifaceted. .
fctorial 6y ago
> integration of OO and FP OO and FP are paradigms. You can use any of them, or both of them, in any language.
- scarmig 6y ago
  You can use FP in Java, or OO in Haskell. That doesn't mean that they're equally usable paradigms. I believe Scala had the goal of offering a high level of usability for both FP and OO. It failed despite an admirable effort, because of an incredible amount of language complexity.
hintymad 6y ago
I may have a contrarian opinion: a new language, beyond certain level, does not increase productivity tangibly for a large enough team. Specifically, Scala does not necessarily offer more productivity than Java. It is a pleasure to write program in a language with more powerful features, for sure. It's just that bottlenecks of project are usually not language features, but core algorithms, system designs, meticulous testing, conflicting requirements that demand careful trade-offs, availability of robust libraries and frameworks, maintainability of the most complex part of the system, and availability of qualified engineers. Few of such bottlenecks can be removed by switching to a language like Scala.
- eeperson 6y ago
  Can't language features help solve some of those problems though? Improvements in static typing can help with algorithm implementations, reduce the amount of testing required, and make conflicting requirements more obvious.

KingOfCoders 6y ago

We chose Scala, had so many problems with the eco system and compiler and community, still love the language, it's the programming language I've enjoyed most, but glad we sold the startup.

tootie 6y ago

I only witnessed from the outside, but saw a similar story play out. A client had bet on Scala for a new platform and made it about 6 months in before throwing in the towel and rewriting the whole thing in in Java. It's too hard to recruit and the tooling isn't mature enough.

mumblemumble 6y ago
I didn't run into problems with recruiting in general being too difficult. Plenty of people are interested in FP and are eager to do it professionally. But recruiting the right mix of people can be a challenge. Scala tends to attract people with an experimental temperament, and scare away more conservative developers. A team needs a healthy mix of both, though. It's the creative tension among different attitudes about how to write code that yields the best work in the long run.
- worldsayshi 6y ago
  In contrast I think that going all in on Java scares away people who like to experiment.
  - eternalban 6y ago
    Be honest and give a short list of experimental approaches that you wanted to do and couldn't be done on Java. What did you want to do and couldn't? And, let's ask Rich Hickey. What language was it he used to experiment with a new s-expression language? Why wasn't RH scared away? You want the brutal honest answer? Because he is smart and can grok the complexity of the Java in toto. What sort of experiments can you not do on a virtual machine based language, with open byte code/vm spec, open class loaders, and compile and runtime instrumentation and meta- capabilities? I used to do the switch the superclass at loadtime to experiment with adaptable programs. This was circa late 90s. Loads of fun (npi). What scares many away from Java is that it is now a very huge mental object. But not wanting to admit this, they simply pass along FUD.
    - fctorial 6y ago
      > I used to do the switch the superclass at loadtime to experiment with adaptable programs. This probably falls in undefined behavior territory. What kind of errors did you get when something went wrong?
      - eternalban 6y ago
        It is not undefined behavior. Bytecodes are modified via custom CL and superclass was swapped from e.g. Object to something else. As for errors, honestly its been 23+ years so don’t really remember. Naturally you can’t just swap any random class - it has to be correct e.g. can’t have an override method in the child that has no corresponding method in the super. And if memory serves, you can also play this trick using classpaths. Assume a stub package com.foo.Context which is simply an extension of Object, and derive components from com.foo.Context.SuperClass. You simply need to provide a different eponymous package for the adapted instance of the code. https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.ht...
        hderms 6y ago
        I've definitely experienced some scary bugs caused by runtime bytecode injection (from a tracing library). I didn't bother tracking it down further than identifying it was at the intersection of some slightly strange type and the tracing. Caused VM errors when this method was called but only when the tracing was configured. Not saying it's not interesting to experiment with things like that, but there are non-trivial associated, if you ask me, to depending on it in production.
- rednum 6y ago
  Yeah, good luck when someone with experimental temperament decides to implement some of your crucial functionality with semialgebras. (that's what happened in my previous job where we run Scala). I'm happy I didn't have to debug any customer issues around that module. Also, I didn't enjoy constant bickering with my reviewers what makes a beautiful code or not. Apparently there are five ways to do everything in Scala and I always ended up picking not the one my teammates would like the most.
  - mumblemumble 6y ago
    Yes. That's pretty much how the Scala project I was working on ran itself aground. Everyone got so caught up in flexing at each other that solving actual business problems became a secondary priority.
    - nowherebeen 6y ago
      This points to a culture problem more than the language itself though.
      - mumblemumble 6y ago
        Interestingly, when we were working on the Java code, we didn't have this problem. Same people, same time, same git repository, different modules.
        milesvp 6y ago
        This doesn’t terribly surprise me. Community isn’t just the people but also the customs and idioms within the community. It’s probably similar to ‘code switching’ in verbal languages. People talk (and act) differently depending on who thay’re talking to.
    - randmeerkat 6y ago
      This is why I think the community is way more important than the language. In Python people are like, hmm, this is a hack, but it works for now, in Scala it’s, what have you done you savage?!?
closeparen 6y ago
I thought it was understood that choosing a less popular language meant hiring people for fundamentals and then letting them ramp on on your language. Did the client choose Scala thinking they would just hire "Scala people"?
- hderms 6y ago
  If you stick to a reasonable middle-ground of scala it really shouldn't be hard to teach. I do like the FP community but that style has gone a long way towards mythologizing scala as an impossible language to teach. In my experience it's clearly considerably simpler than Rust or C++ to become productive in.

amitport 6y ago

Scala has its place... it's just not one that requires fast on-boarding (like a small startup where people constantly come and go). The success stories usually involve companies that are mature enough to spend time on design, training, and supervision (wix, for example)

dwhitney 6y ago

I think mixing the OO and FP is the crux of the problem. Type inference and subtyping (class based inheritance) don't mix well, and often require type annotations to help the compiler when types get somewhat complex. Eventually you develop an instinct for it, and it's not a problem, but the road to developing that instinct is littered with torn out hair. (edit: spelling)

joshuapassos 6y ago
Maybe the best approach is using a language with dynamic types ? (e.g: cloujure)
weatherlight 6y ago
I have found that languages that support both FP and OO paradigms its best to do things like data manipulation in FP, and use OO to encapsulate those processes and be limited to just passing messages to other objects. Avoid inheritance. Once an object is instantiated, don't change its internal state. etc.
- jdmichal 6y ago
  This is my philosophy: Data types are object-oriented. They are responsible for ensuring that their internal state is consistent, and nothing more. They may inherit if it makes sense, but it usually doesn't and most of the time aggregation is more appropriate. Business rules are functional. There's just a bag of composable, pure functions that take the various data types and perform validations, transformations, etc. External services, such as a database, are contractual. This would be an interface in Java or C# defining the required operations of the service. This allows manipulation of these external services during testing. Unit testing would mock them; integration testing would not. Workflows or services are procedural. They combine everything else into an actual use-case. They read in a linear flow of what needs to happen when to meet the use-case.
  - hderms 6y ago
    Great breakdown. Seriously, I've had very similar ideas but never tried to build a coherent mapping like this. Thanks for writing it out!

blacktriangle 6y ago

I wouldn't blame the language, I'd blame the people who chose Scala. The impression I always had was that Scala was a research project into how various programming language features could live together and interact, hence their everything and the kitchen sink approach. From an academic point of view I think Scala was a huge success. That people chose to use Scala in production speaks more to how badly people hate Java and want an alternative, not to Scala's failings.

foobarian 6y ago
Recent Javas made many QoL improvements to remove some of the complaints IMO. And there are more neat improvements coming (already there?) with 15 and 17.
- nine_k 6y ago
  Also, Kotlin is a rather nice and much less radical "better Java", well-supported, but mostly popular on mobile.
  - The_rationalist 6y ago
    Kotlin on the server is growing though and has the biggest library ecosystem to exist
    - dehrmann 6y ago
      Glad to hear this. There's really no reason it for it not to do well on the server.
  - gher-shyu3i 6y ago
    Pattern matching is (will be) better implemented in Java. It's fully fledged compared to Kotlin's implementation.
    - nine_k 6y ago

Akronymus 6y ago

Pretty much a noob at FP in general: Wouldn't f# solve the FP and OO integration?

hurril 6y ago
I did Scala for ten years and've been at it with F# for a year and a half now. I do miss some very powerful features of Scala such as HKT and "typeclasses" occasionally but overall it works very well. Sure, Scala is complex but I find that there are a few misunderstandings here. Java, for instance, _requires_ that you use a number of supporting tools for it to be useful these days. You need a container, you need quite extensive testing and you need quite the advanced build tools. Sure, these have all been around long enough these days to not be what we think about when we compare Java to other things, but they're implicitly also Java. I can't speak for Go because I've not looked at it. But Scala has strengths that means that you don't need to have _external_ tools and libraries for those things. That strength is types which means that the compilers is going to want to "pick a fight" with you to a very much higher frequency. That is a pain. The reason that we're here talking about that pain with Scala is that you don't think about that in your Java project anymore because you use heuristics and sandy heads instead. Another thing is that I think that Scala gives you a big fat revolver to shoot yourself in the foot with. Java has a bb-gun so no matter where you aim it, you're not going to accomplish a lot. Over to F#: I'm going to claim that the .NET toolchain is superior to the JVM ones. The CLI tools and paket runs circles around the POS that is SBT.
- thu2111 6y ago
  Huh, I use Java all the time without containers. You definitely don't need them.

spaced-out 6y ago

>We really loved the integration of OO and FP, really miss the FP awesomeness honestly... but simplicity trumps doing either of those things well. Agreed. I like the Scala language, but I can't imagine a scenario where I would recommend it for a project over Java.

cmrdporcupine 6y ago

I think Scala needs to be treated something like how smart shops treat C++: there's so much there you can hang yourself with, so you need to define a subset/dialect and create a style guide and stick with it. This is how C++ has been successful at Google, and it's how I'd approach something like Scala if I were to go back to doing it now.

a4isms 6y ago
An evergreen conversation: "I love C++." —Alice "Oh? Which C++?" —Bob Every successful C++ team defines its own C++ subset.
- the_only_law 6y ago
  This is why I can't figure out how for the life of me to learn C++ effectively for professional use.
  - aninteger 6y ago
    In reality it's not really like that. Yes different shops are going to be using different C++ features in different ways but they usually share some common "core" of the language.
  - Jeff_Brown 6y ago
    One approach is to get a sample of code from the domain you want to inhabit, preferably including some from the very people you want to work with, and learn the subset of the language they use.
- agumonkey 6y ago
  Also Stroustrup thinks that is the way to use cpp, his talks are all about 'do not use all of cpp, pick your features'. Makes senses in a way but it does lead to various notion of what cpp is.
AzzieElbab 6y ago
That is exactly it. A company wide style and coding guide is a must with scala

foobarian 6y ago

There is a tendency I observed in engineers to not want to appear dumb. This is a recipe for disaster when coupled with a deep language like Scala, because nobody wants to solve problems the simple way, and Scala gives a tremendous amount of rope. That's why I think it's only a suitable choice for very experienced or disciplined teams, with a strong consensus on style or any DSLs. I can see average enterprise shops lacking these things and ending up with suboptimal results if Scala is used.

rednum 6y ago
> to not want to appear dumb Few production incidents are enough to change this mentality. I'd rather write more verbose but "obvious" code than "clever one liners". I feel sorry for anyone who has to understand someone's DSL on the fly when there's an outage and your business is burning through X$ per minute of downtime. (On the other hand, you probably want to structure your production changes in the way that they are easy to roll back without understanding everything, but that's other conversation. Either way, the thought that someone may want to chase me after work because my code broke and they can't understand it is enough for me to stop being clever).

PopsiclePete 6y ago

> but simplicity trumps doing either of those things well. That's the genius (?) of Go. They gave us what we didn't know we needed. Software people love the "manliness" that comes with "serious", "real" programming languages. Maybe it's the desire to impress our peers with our intelligence? But in the end the only thing that matters is whether you can get your shit done and on time in at least a semi-working state.

hderms 6y ago
I appreciate what you're getting at, but is Go really the epitome of a "get things done" language? It seems to suffer from some serious boilerplate issues even compared to something like Java. As far as it being driven my machismo, I think that's part of it, but I'd be more inclined to blame it on the following: * complex languages/mental frameworks function as an "intellectual trap" where people more inclined to be interested in intellectual things for their own sake start to lose site of the forest for the trees. * FOMO that one must keep up to speed with all the coolest new developments in programming or face mounting irrelevance * Elitism/self promotion where specializing in something difficult (and potentially keeping newcomers out) either provides internal or external motivation I think some of these traits seem somewhat correlated with the "nerd machismo" archetype but I think the actual causes are multifaceted. .

fctorial 6y ago

> integration of OO and FP OO and FP are paradigms. You can use any of them, or both of them, in any language.

scarmig 6y ago
You can use FP in Java, or OO in Haskell. That doesn't mean that they're equally usable paradigms. I believe Scala had the goal of offering a high level of usability for both FP and OO. It failed despite an admirable effort, because of an incredible amount of language complexity.

hintymad 6y ago

I may have a contrarian opinion: a new language, beyond certain level, does not increase productivity tangibly for a large enough team. Specifically, Scala does not necessarily offer more productivity than Java. It is a pleasure to write program in a language with more powerful features, for sure. It's just that bottlenecks of project are usually not language features, but core algorithms, system designs, meticulous testing, conflicting requirements that demand careful trade-offs, availability of robust libraries and frameworks, maintainability of the most complex part of the system, and availability of qualified engineers. Few of such bottlenecks can be removed by switching to a language like Scala.

eeperson 6y ago
Can't language features help solve some of those problems though? Improvements in static typing can help with algorithm implementations, reduce the amount of testing required, and make conflicting requirements more obvious.