July 1, 2014 at 15:12OMG Scala is a complex language!
- Transfer
I always notice that , "Oh, good heavens, Scala - it's tough!" . You know, maybe it's true. Let's try to look at this complexity and walk through the main differences between Scala and other object-oriented languages (for example, Java or C ++).
In most cases, the compiler is capable of inferring a type, which allows developers to write less duplicate information that they are so used to writing in Java and C ++.
For example, it’s clear that “john” is a string, so the compiler can infer the type on its own, and I don’t have to specify the type explicitly. I can simply write:
I met both approval and criticism regarding type inference, so I don’t even know what to say. Personally, I like to write less and feel a little less stupid whenever I declare a value or variable.
Since OOP is built on the basis of class definitions, in Scala it is implemented as simple as possible. All my domain models are extremely simple .
I must say that the same thing in Java or C ++ would take almost a page of code with all sorts of constructors, getters, setters, etc. Scala developers realized that people should not write a whole page of code just to tell a stupid compiler that they need a Person class that has two fields: first and last name. So, in Scala, the definition of such a class takes only one line, just like a table would look in SQL.
Does it add complexity?
Well ... I only need to worry if I need to override the generated getters and setters. So I don’t even know if it really complicates life ...
I?! Personally, I am so delighted with this opportunity that, frankly, I absolutely do not care what you think there.
All programming languages that I know draw a hard line between methods with a name such as "append" and operations such as "+ =" . Some languages prohibit redefinition of existing operators (Java). Other languages only allow infix notation for operators (C ++). Scala does not have all of these limitations. You can use any names to name methods, and infix notation is allowed for any calls:
The only difference will be in the rules of priority. Of course, someone will say that it is “more complicated” than in Java or C ++, because it is “free hands” and allows you to do whatever you want. However, I believe that this is simpler than in the languages mentioned. In the end, this makes Scala the perfect framework for creating natural DSL:
In both Java and C ++, templates have certain wired, limited behavior (i.e. covariance ) and allow only a few constructs (like List
Scala has a default behavior in which List [Person] is invariant, but everything can be customized. If you need covariance, just tell the compiler List [+ Person] or List [-Person] for contravariance. Similar to Java, there is a List [T <: Person] and List [T>: Person] construct . Since Scala has a mechanism for implicit conversions (implicits), another construction is also available, just for such cases: List [T <% Person] .
Is it harder?
As with operators, this mechanism gives rise to some limitations, however, on the other hand, it provides new opportunities. Personally, I like this type control. Did I use this? Not in everyday development, most often the usual default type control behavior is enough.
Most languages only allow you to construct objects. Scala also allows you to deconstruct objects, but I'm not talking about freeing up the memory occupied by the object. Consider:
Here you can see what I mean by “deconstructing” an object. Take an already created object and deconstruct it into the first and last components . I know this looks alien and unusual for most OO supporters, but believe me, this is insanely cool and comfortable! Imagine what you would have to do in order to implement this in Java or C ++ ... Check for type (instanceof), assign two variables to these values and much more ...
Remember about string interpolation in Scala:
Is it more complicated? Well ... This is a completely new feature. I like! Believe me, you will like it too!
By the way, match / case provides a wider range of possibilities than the usual switch / case , which can only work with constants. With match / case, you can deconstruct objects, match constants, match types, and much, much more! Yes, see for yourself:
It's complicated? I don’t know ... in Java or C ++ this would take from one to two pages of code. For me personally, in Scala it looks simple and intuitive.
Of course, these are just some aspects of the language. If you have something to add, write a post, I will be glad.
I did not touch on functional programming in Scala, for this you need to compare Scala with other functional languages, it is not FP'shnik ( FP guy ). C ++ now allows you to pass function pointers to other functions, and lambda constructs are introduced in Java 8.
Is all this complicated? Well ... You can look at it all from two sides:
Yes ,
No ,
What I think? I really don't care. Personally, I am very glad that I met with these opportunities. This allows me to solve problems in just a few lines of code, while my friends still write these getters and setters ...
There are still a few things that I did not like, for a little more than six years of experience with Scala. Here are some of them:
PS A more detailed discussion about complexity: Simple or Complicated?
Type inference
In most cases, the compiler is capable of inferring a type, which allows developers to write less duplicate information that they are so used to writing in Java and C ++.
For example, it’s clear that “john” is a string, so the compiler can infer the type on its own, and I don’t have to specify the type explicitly. I can simply write:
val aGuy = "John"
I met both approval and criticism regarding type inference, so I don’t even know what to say. Personally, I like to write less and feel a little less stupid whenever I declare a value or variable.
Simplified class definition
Since OOP is built on the basis of class definitions, in Scala it is implemented as simple as possible. All my domain models are extremely simple .
class Person (val firstName:String, val lastName:String)
I must say that the same thing in Java or C ++ would take almost a page of code with all sorts of constructors, getters, setters, etc. Scala developers realized that people should not write a whole page of code just to tell a stupid compiler that they need a Person class that has two fields: first and last name. So, in Scala, the definition of such a class takes only one line, just like a table would look in SQL.
Does it add complexity?
Well ... I only need to worry if I need to override the generated getters and setters. So I don’t even know if it really complicates life ...
I?! Personally, I am so delighted with this opportunity that, frankly, I absolutely do not care what you think there.
Combining Methods and Operators
All programming languages that I know draw a hard line between methods with a name such as "append" and operations such as "+ =" . Some languages prohibit redefinition of existing operators (Java). Other languages only allow infix notation for operators (C ++). Scala does not have all of these limitations. You can use any names to name methods, and infix notation is allowed for any calls:
ListBuffer(1,2,3) append 4
// И так тоже можно
ListBuffer(1,2,3) += 4
The only difference will be in the rules of priority. Of course, someone will say that it is “more complicated” than in Java or C ++, because it is “free hands” and allows you to do whatever you want. However, I believe that this is simpler than in the languages mentioned. In the end, this makes Scala the perfect framework for creating natural DSL:
"Mary" with "a purse" and "red shoes" should look "nice"
Types
In both Java and C ++, templates have certain wired, limited behavior (i.e. covariance ) and allow only a few constructs (like List
Scala has a default behavior in which List [Person] is invariant, but everything can be customized. If you need covariance, just tell the compiler List [+ Person] or List [-Person] for contravariance. Similar to Java, there is a List [T <: Person] and List [T>: Person] construct . Since Scala has a mechanism for implicit conversions (implicits), another construction is also available, just for such cases: List [T <% Person] .
Is it harder?
As with operators, this mechanism gives rise to some limitations, however, on the other hand, it provides new opportunities. Personally, I like this type control. Did I use this? Not in everyday development, most often the usual default type control behavior is enough.
Only designers?
Most languages only allow you to construct objects. Scala also allows you to deconstruct objects, but I'm not talking about freeing up the memory occupied by the object. Consider:
someone match {
case Person(first,last) => println (s" name is $first $last")
}
Here you can see what I mean by “deconstructing” an object. Take an already created object and deconstruct it into the first and last components . I know this looks alien and unusual for most OO supporters, but believe me, this is insanely cool and comfortable! Imagine what you would have to do in order to implement this in Java or C ++ ... Check for type (instanceof), assign two variables to these values and much more ...
Remember about string interpolation in Scala:
"$first $last"
Is it more complicated? Well ... This is a completely new feature. I like! Believe me, you will like it too!
By the way, match / case provides a wider range of possibilities than the usual switch / case , which can only work with constants. With match / case, you can deconstruct objects, match constants, match types, and much, much more! Yes, see for yourself:
someone match {
case Person(first,last) => println (" name is " + first + " " + last)
case "John" | "Mary" => println ("hello, " + someone.toString)
case s:String => println ("name is " + s)
case _ => println ("don’t know what this is…")
}
It's complicated? I don’t know ... in Java or C ++ this would take from one to two pages of code. For me personally, in Scala it looks simple and intuitive.
Conclusion
Of course, these are just some aspects of the language. If you have something to add, write a post, I will be glad.
I did not touch on functional programming in Scala, for this you need to compare Scala with other functional languages, it is not FP'shnik ( FP guy ). C ++ now allows you to pass function pointers to other functions, and lambda constructs are introduced in Java 8.
Is all this complicated? Well ... You can look at it all from two sides:
Yes ,
- More Symbols and Features You Can Use
- It is necessary to learn some additional terms and concepts from the field of computer science (contraception, pattern matching, lambdas, closures, etc.)
No ,
- Real problems can be solved
- The same constructions in Java or C ++ cannot be made in principle, or it will take much more code ... and ... the code will look awful.
What I think? I really don't care. Personally, I am very glad that I met with these opportunities. This allows me to solve problems in just a few lines of code, while my friends still write these getters and setters ...
Negative
There are still a few things that I did not like, for a little more than six years of experience with Scala. Here are some of them:
- Slow compilation. Not that annoyingly slow, but still much slower than the rest.
- Implicit conversions. I do not like how they implemented this mechanism. You can accidentally import a conversion from Any into MyCoolThing , which was defined in some imported block.
- Collection library. For most people, this is not so important, but ... All this looks much more complicated than I would like.
- SBT . It is always difficult. Seriously, if you need to do something beyond the typical SBT experience, then you are. There are so many different non-obvious DSLs that Google will go crazy trying to find for you how to do what you need. They needed to make either some separate syntax, like JSON or some kind of internal DSL, which the compiler / IDE could understand and help when working with SBT.
PS A more detailed discussion about complexity: Simple or Complicated?