4 ms·

Complexity of Scala has been debated many times. Just because a language adds some new concepts and is different than other mainstream languages, is not enough

Complexity of Scala has been debated many times. Just because a language adds some new concepts and is different than other mainstream languages, is not enough to call it "complex". Before you answer question about whether Scala is complex, try to answer the following questions first: Is JEE complex? Is Spring Framework complex? Is Maven complex? Are webservices complex? Is C# complex? They are, they introduce new concepts and in many ways they have much more rough edges than Scala (remember JEE 2.1?). Somehow all of them have been widely used in enterprise software development in many successful projects. I'm surprised by how much flexibility Scala offers with so few simple concepts. Ok, you have to take some time to learn them. But this is the same as learning just any new API.

Ygg2 14y ago
Just because something is complex doesn't mean it is bad, but something being really really complex (or feature rich), doesn't mean it is good either. Now I might be mistaken, but Scala is one of rare languages that actually has compiler commands that disable parts of it syntax (or there was a plan to do so). To me that yells - Too complex. I'm quite sure it is powerful. But it doesn't look like something I'd enjoy using. My main gripes about Scala is that the trait system is way less elegant than the Smalltalk variant [1], there seems to be a hundred different ways to do a thing (as opposed to a more unified way of doing things) and the overall "automagical" implicit. Not to mention the overall verbosity and ways the different features mesh together. [1]http://www.cs.cmu.edu/~aldrich/courses/819/Scha03aTraits.pdf http://www.cs.cmu.edu/~aldrich/courses/819/Scha03aTraits.pdf
- pkolaczk 14y ago
  As far as I know they haven't implemented disabling parts of the syntax in the compiler, yet. There were plans to do it, due to the fact, that for application coding there, the most controversial features are not used very often, and because of the posts like yours, that Scala is too complex. However, these features are essential for library / framework type of code. Scala collections library could not be that easy to use, powerful and clean if these powerful features like implicits were not in the language. Things like Squeryl could not be implemented, without adding special support in language (like in C#). Scala is pretty simple - just a few, very generic, powerful features, instead of thousands of special cases and compiler quirks. As for verbosity: I coded a lot in Python, in Perl and then in Scala, and found Scala code to be sometimes even shorter. Note Scala is statically typed, it is harder for statically typed language to be terse. It does pretty well in this area, for a statically typed language. As for doing things in different ways: in Python they say there should be one obvious way to do it. But it really isn't. Lots of things in Python could be done in different ways. This is inherent to programming, and it is a good thing, making programming more art than craft.
eta_carinae 14y ago
> Complexity of Scala has been debated many times. Just because a language adds some new concepts and is different than other mainstream languages, is not enough to call it "complex". It seems to me that the JVM community has moved on from Scala and is actively looking for a language that offers most of the benefits that Scala offers without the downsides. Kotlin (from JetBrains) and Ceylon (from RedHat) seem to be the first two languages with a really interesting take on this problem. Gosu and Fantom are similar attempts, although I think these two already failed to gain traction.
- pkolaczk 14y ago
  To be honest, by the time they are ready for production, Java 8 will provide the most of the features they are promising. So for developers who only want to have lambdas and slightly better libraries (like ability to call filter on a collection), there is no need to move. Just wait for Java 8. On the other hand, for programmers doing some more serious stuff than just moving data from database to the website, they offer too little to be attractive, and they actually haven't solved any problem that Scala hasn't solved (Ceylon's generics reification - a good joke, man). They are nowhere near Scala in expressiveness and flexibility and being only slightly better than Java is not enough for power-coders. There were some languages targeted as "better Java", e.g. Nice long time ago and they also failed. From the alternative languages for JVM, currently only Clojure and Scala (and probably Groovy too) got some serious usage in industry. All others are still in kindergarden.
edwinnathaniel 14y ago
Let's take a look at it from a different angle. Say, I have a group of developers who have been trained to use Java (both best-practices, idioms, tools, etc). Let's say that JEE 6 shows up (no, I don't remember JEE 2.1, what is that? is that thing even exist?). JEE 5/6 introduces a few things on top of my head (please pardon me of the syntaxes): 1) Dependency Injection via annotation (CDI in JEE6, EntityManager in JEE5) Introduction: annotate the instance property you'd like to inject and GlassFish will magically give the class to you. Example: @Inject AccountService accountService; 2) JAX-RS Introduction: A class, that works like servlet, but without doGet() or doPost(), instead you have methods that maps to the request-path based on the annotation. Example: @Path("/account/{id}") public Account get(@PathParam("id") final long id) 3) Transaction (in EJB3 which appears in JEE5) Introduction: Sprinkle annotation in your class or method, you get transaction magically. Example: @TransactionAttribute(REQUIRED) public class AccountRepository or @TransactionAttribute(REQUIRED) public Account updateAccount(final Account toUpdate) {...} So I'm not sure how complex all of these to grok, granted if you need to do something out of the ballpark, you may have to learn a bit more of each individual component but to get started and be productive seems quite easy for me. Now let's compare that with picking up Scala from zero (given that you know Java already) and get comfortable and productive with Scala, its tools, and its libraries to build web-application with the similar setting of that in JEE (web-service, REST, persistence/db/orm/transaction layer, unit-test, integration-test, etc). No cheating though: no calling/utilizing JEE. Has to use all-things Scala libraries.
- pkolaczk 14y ago
  "So I'm not sure how complex all of these to grok, granted if you need to do something out of the ballpark, you may have to learn a bit more of each individual component but to get started and be productive seems quite easy for me." It is so easy only if you don't try to write some serious production level stuff using it. You must be insane to start a project in JEE knowing only some basic tutorials and without deep understanding how the full stack works. I worked for a company that do JEE trainings. It was near impossible to teach a team using full JEE stack in 5 days (7 hour / day) - no, actually each single component is like 1-2 days of training, given that everything is preconfigured and ready to go. And after training they usually ask for consulting, because they still have some technical problems with it. This is similar to Scala. You have to probably have someone on the team with deep understanding, but most of the coders just need to know how to do basic things in it. We used Scala for a project in the company, and the only concern then was poor tooling (that was 2 years ago - it is much much better now), not the language itself. Most programmers just jumped right into it as a Java with slightly simplified syntax - "oh, I don't need to know when to use Integer and int, cool!". // Errata: I meant EJB 2.1, not JEE 2.1, sorry for the mistake.

Ygg2 14y ago

Just because something is complex doesn't mean it is bad, but something being really really complex (or feature rich), doesn't mean it is good either. Now I might be mistaken, but Scala is one of rare languages that actually has compiler commands that disable parts of it syntax (or there was a plan to do so). To me that yells - Too complex. I'm quite sure it is powerful. But it doesn't look like something I'd enjoy using. My main gripes about Scala is that the trait system is way less elegant than the Smalltalk variant [1], there seems to be a hundred different ways to do a thing (as opposed to a more unified way of doing things) and the overall "automagical" implicit. Not to mention the overall verbosity and ways the different features mesh together. [1]http://www.cs.cmu.edu/~aldrich/courses/819/Scha03aTraits.pdf http://www.cs.cmu.edu/~aldrich/courses/819/Scha03aTraits.pdf

pkolaczk 14y ago
As far as I know they haven't implemented disabling parts of the syntax in the compiler, yet. There were plans to do it, due to the fact, that for application coding there, the most controversial features are not used very often, and because of the posts like yours, that Scala is too complex. However, these features are essential for library / framework type of code. Scala collections library could not be that easy to use, powerful and clean if these powerful features like implicits were not in the language. Things like Squeryl could not be implemented, without adding special support in language (like in C#). Scala is pretty simple - just a few, very generic, powerful features, instead of thousands of special cases and compiler quirks. As for verbosity: I coded a lot in Python, in Perl and then in Scala, and found Scala code to be sometimes even shorter. Note Scala is statically typed, it is harder for statically typed language to be terse. It does pretty well in this area, for a statically typed language. As for doing things in different ways: in Python they say there should be one obvious way to do it. But it really isn't. Lots of things in Python could be done in different ways. This is inherent to programming, and it is a good thing, making programming more art than craft.

eta_carinae 14y ago

> Complexity of Scala has been debated many times. Just because a language adds some new concepts and is different than other mainstream languages, is not enough to call it "complex". It seems to me that the JVM community has moved on from Scala and is actively looking for a language that offers most of the benefits that Scala offers without the downsides. Kotlin (from JetBrains) and Ceylon (from RedHat) seem to be the first two languages with a really interesting take on this problem. Gosu and Fantom are similar attempts, although I think these two already failed to gain traction.

pkolaczk 14y ago
To be honest, by the time they are ready for production, Java 8 will provide the most of the features they are promising. So for developers who only want to have lambdas and slightly better libraries (like ability to call filter on a collection), there is no need to move. Just wait for Java 8. On the other hand, for programmers doing some more serious stuff than just moving data from database to the website, they offer too little to be attractive, and they actually haven't solved any problem that Scala hasn't solved (Ceylon's generics reification - a good joke, man). They are nowhere near Scala in expressiveness and flexibility and being only slightly better than Java is not enough for power-coders. There were some languages targeted as "better Java", e.g. Nice long time ago and they also failed. From the alternative languages for JVM, currently only Clojure and Scala (and probably Groovy too) got some serious usage in industry. All others are still in kindergarden.

edwinnathaniel 14y ago

Let's take a look at it from a different angle. Say, I have a group of developers who have been trained to use Java (both best-practices, idioms, tools, etc). Let's say that JEE 6 shows up (no, I don't remember JEE 2.1, what is that? is that thing even exist?). JEE 5/6 introduces a few things on top of my head (please pardon me of the syntaxes): 1) Dependency Injection via annotation (CDI in JEE6, EntityManager in JEE5) Introduction: annotate the instance property you'd like to inject and GlassFish will magically give the class to you. Example: @Inject AccountService accountService; 2) JAX-RS Introduction: A class, that works like servlet, but without doGet() or doPost(), instead you have methods that maps to the request-path based on the annotation. Example: @Path("/account/{id}") public Account get(@PathParam("id") final long id) 3) Transaction (in EJB3 which appears in JEE5) Introduction: Sprinkle annotation in your class or method, you get transaction magically. Example: @TransactionAttribute(REQUIRED) public class AccountRepository or @TransactionAttribute(REQUIRED) public Account updateAccount(final Account toUpdate) {...} So I'm not sure how complex all of these to grok, granted if you need to do something out of the ballpark, you may have to learn a bit more of each individual component but to get started and be productive seems quite easy for me. Now let's compare that with picking up Scala from zero (given that you know Java already) and get comfortable and productive with Scala, its tools, and its libraries to build web-application with the similar setting of that in JEE (web-service, REST, persistence/db/orm/transaction layer, unit-test, integration-test, etc). No cheating though: no calling/utilizing JEE. Has to use all-things Scala libraries.

pkolaczk 14y ago
"So I'm not sure how complex all of these to grok, granted if you need to do something out of the ballpark, you may have to learn a bit more of each individual component but to get started and be productive seems quite easy for me." It is so easy only if you don't try to write some serious production level stuff using it. You must be insane to start a project in JEE knowing only some basic tutorials and without deep understanding how the full stack works. I worked for a company that do JEE trainings. It was near impossible to teach a team using full JEE stack in 5 days (7 hour / day) - no, actually each single component is like 1-2 days of training, given that everything is preconfigured and ready to go. And after training they usually ask for consulting, because they still have some technical problems with it. This is similar to Scala. You have to probably have someone on the team with deep understanding, but most of the coders just need to know how to do basic things in it. We used Scala for a project in the company, and the only concern then was poor tooling (that was 2 years ago - it is much much better now), not the language itself. Most programmers just jumped right into it as a Java with slightly simplified syntax - "oh, I don't need to know when to use Integer and int, cool!". // Errata: I meant EJB 2.1, not JEE 2.1, sorry for the mistake.