Saying that scala is complex is like saying lisp is complex just because you cant read it.
Scala has very little syntactic rules. Of course if you dont take the time to learn them , you are not going to understand the language.
Scala has very little syntactic rules. Of course if you dont take the time to learn them , you are not going to understand the language.
EDIT: Scala does have an incredible compiler, though, and it is interesting from a PL research POV (which is to be expected, given its origins). The JVM community will forever be indebted to Scala. But it is not a language that many will feel comfortable using, and most of those that do, use a subset of it (which is basically Kotlin), and ignore the fact that they can't understand how the linked list is implemented. Kotlin takes a lot of inspiration from Scala, obviously, and learns from its mistakes. It takes that subset of Scala that gives people 99.9% of what they want and need with only 10% of the complexity.
ADTs/pattern matching are not "a complete type system". Structural types are not "a complete type system". Scala unifies the different concepts by expressing them through Java-style classes and inheritance.
Even if they were incompatible non-orthogonal type systems sitting side by side (they aren't), it is immensely useful to have both dynamic dispatch and ADTs/pattern matching in the toolset; they are often useful for different problems.
Why not? Can you not write any program using either? Haskell uses just the former, and JS the latter (though without type safety).
> Scala unifies the different concepts by expressing them through Java-style classes and inheritance.
I think it "unifies" them only in the sense that the (single) compiler can compile all three. But case classes cannot be part of an inheritance hierarchy nor structural types (or inheritance types) be used as ADTs. The three certainly intersect, but they're not really unified.
> It is immensely useful to have both dynamic dispatch and ADTs/pattern matching in the toolset; they are often useful for different problems.
Obviously, and that is why some languages employ the one or the other. The question is, how useful is it (from a cost/benefit perspective) to have all three (plus macros!) in the same language? After all, while each has its benefits sometimes, they also overlap a lot, as most programs are about as easily implemented in all three. As I've said elsewhere, in language design, as in most things, one must choose. A pizza, a steak and ice-cream all have their place, but may lose much of their flavor if mixed into the same dish. In the JVM ecosystem we are lucky enough to have easy interoperability between languages. The JVM is a restaurant with a varied menu, and you can have a meal of several courses. The best way to go, IMO, is to pick one simple language you're comfortable with and use it for most tasks, and for those tasks that require specialized skills outside your chosen language's strengths – use another.
While you can make do with either, they have complementary strengths and weaknesses, which are useful in different situations. See "Expression Problem", and "Visitor Pattern".
> Why not?
"Single Dispatch Polymorphism" is a language feature. ADTs/pattern matching are a language feature. Subtyping is a type-system feature. "Structural Typing" is a type-system feature. Guaranteeing exhaustive pattern matching is a type-system feature. They are not "type systems", and different languages pick them and combine them a la carte.
> But case classes cannot be part of an inheritance hierarchy nor structural types (or inheritance types) be used as ADTs
Yes they can, and they do. You just can't extend case classes from other case classes. You can use any class as an ADT-like structure if you want, leaving the hierarchy open or closed, and defining pattern matching extractors as you please. It's all part of the same system; whether you call it an "ADT" or a "class hierarchy" is a design pattern thing more than a rigid systemic property.
> Obviously, and that is why some languages employ the one or the other
Er... that doesn't follow. What I said is that it's very useful having both together. If you don't think that's valuable, that's fine; Scala's not for you.
> It's all part of the same system; whether you call it an "ADT" or a "class hierarchy" is a design pattern thing more than a rigid systemic property.
Obviously it's part of the same system, which just happens to be a superset of three type systems. A type system is not how its implemented but what it does.
Verbatim even.. a copy paste :p
Learning Scala's type system takes time, yes; it quite possibly takes longer to learn Scala than most languages. But it's still going to be less effort than learning two different languages.
I think that most organizations are already using a lot of code that they don't understand. The JVM itself is many thousands of lines of not especially clear code; I suspect very few java-based organizations really understand it (and I've hit bugs in the JVM in real life, so it's not that there's no need to understand it). Likewise large, popular Java libraries like Spring and Hibernate (particularly given that they do bytecode manipulation, so you can't always even assume that the normal rules of the language apply).
I think standard library implementations are rarely read in any language, so the complexity of the standard library implementation in scala isn't a concern. I think the interfaces are important, and if users are unable to understand the method signatures then that's a problem. But documenting what a method does is often seen as adequate (e.g. in Python or Ruby the documentation is the only interface signature you get), so I don't see a fundamental problem with the "simplified signature in the documentation" approach (though it would be better to have some way of automatedly ensuring these were correct).
(The only alternative would be to give up the power entirely, or to have two distinct collection libraries; neither of those seems like a good answer. If you don't see having Haskell-level language power as an advantage, then yes the complex library interface is not worth it and you'd be better with a less powerful language. But if you see value in writing parts of your system in something like Haskell, I think it's a big win to be able to use the same language for the haskell-like parts and the kotlin-like parts, and learning a complex library is less overhead than learning a second language).
I think not, and here's why: we're talking about large organizations here, right? Because if you're a single developer or a small team, then anything from assembly to VisualBasic goes and it all pretty much boils down to personal preference. But in a large team (say 50 people and up), only one or two would need to master the "Haskell part" (assuming there was a real need for one), and the rest would use Kotlin. So there is no overhead in learning two languages. The developers would learn one simple language that they can understand, and the single star developer (there is usually one in any team) could probably master five different languages if the need arises. Throwing everything in a single powerful-yet-very-complex does not fit with how complex software is actually developed. This is one of the reasons many huge organizations abandoned C++ and flocked to Java pretty much on the day it was released (I'm exaggerating, but in a software-timeframe terms that's pretty much what happened).
The worst company I worked for was the one where the dev team was split into three - the frontend guys working in PHP, the backend guys doing mapreduce stuff, and the middle team in Java. No-one understood what the others were doing, so there was no sense of the overall product, and bugs or features would get thrown over the wall to another team and then come back weeks later, by which time everyone had forgotten about them.
My last job worked in Scala, and had what was essentially a transactional framework using monads. I reckon at most three of the developers there actually understood the transaction library, and probably only two would actually have added new features to it. But everyone was able to write code that used it, and being able to see the code in the repository and their IDE, at least some of the other developers were able to pick it up gradually, from the outside in, learning more and more, starting to fix bugs that were similar to problems they'd seem elsewhere, and eventually reaching a full understanding. If that code had been written in a different language I think they would never have taken the first step.
Of course (as long as those responsible for maintaining that portion understand their libraries)! Since we agree that some parts of the code are specialized and reserved for experts anyway, what difference does it make if it's written in a different language?
This is not like your story at all about PHP, Java and mapreduce. In my scenario, everyone is using the same language except for the "expert portion", which comprises maybe 2% of the code. I think it is far better than having everyone use a complex language which they don't fully understand, just so that the experts working on that 2% will be nominally using the same language (I say nominally, because in the Scala case it would hardly be the same language – only the same compiler). I don't want to pay the complexity price for everyone for the power needed only for the 2%.
So yeah, if it takes several paragraphs to explain why something that can be as straightforward as this (Haskell)
(a -> b) -> [a] -> [b]
is actually not that complicated when it looks like this
def map[B, That](f: (A) ⇒ B)(implicit bf: CanBuildFrom[List[A], B, That]): That
it is clearly the stupid infidels that don't get it. This doesn't mean that Scala is a bad language in general, just that it is ridiculous to state that it isn't complex, especially compared to Lisp.
It's debatable whether the complexity of the API is worth the additional functionality, but the basic version of map (Data.List.map :: (a -> b) -> [a] -> [b]) is utterly trivial in either language.
Eh? No language extensions necessary.
fmap :: Functor f => (a -> b) -> f a -> f b
There are a lot of counter examples to this claim but just to keep this short, I'll go along with your claim.
A downside of this is heavy overload of keywords/symbols. For example, last time I checked, the underscore (_) has six different meanings depending on where it's used.
The number of syntactic rules is not a good way to judge whether a language is difficult to read, otherwise, Brainfuck would be the most readable language on the planet.
no it has not ,it always express some kind of default behavior. just like ! in ruby method means mutation or ? means it returns a boolean.
> The number of syntactic rules is not a good way to judge whether a language is difficult to read, otherwise, Brainfuck would be the most readable language on the planet.
But we are not talking about Brainfuck.
> no it has not ,it always express some kind of default parameter.
You might want to refrain from commenting on a topic you don't seem to know much about.
I was wrong when I said "six", it looks like the number is up to eleven today. Here is a short list:
- Existential types
- Higher kinded type parameters
- Ignored variables
- Ignored parameters
- Wildcard patterns
- Wildcard imports
- Hiding imports
- Joining letters to punctuation
- Assignment operators
- Placeholder syntax
- Partially applied functions
More details: http://stackoverflow.com/questions/8000903/what-are-all-the-...
the underscore is not an operator.that's why you are listing random stuffs that are not related. It express an intent, see my previous message.
You might want to stop patronizing people you dont know. Or your head is too big for that.
Actually, it can express eleven intents, depending on where it's being used.
The bang (!) does not mean "destructive" nor lack of it mean non
destructive either. The bang sign means "the bang version is more
dangerous than its non bang counterpart; handle with care". Since
Ruby has a lot of "destructive" methods, if bang signs follow your
opinion, every Ruby program would be full of bangs, thus ugly.
_ has only one meaning => "unspecified"
http://www.reddit.com/r/programming/comments/uk015/kotlin_m2...
Are you sure this is true? Compared to what?