A better language would be something with the simplicity and power of python, but with good performance.Groovy could be one such language.
Android needs a statically typed language, but Groovy's dynamically typed, and the statically typed portions available via annotations since version 2.0 isn't really used much. Groovy's still usable for its original use case of manipulating and testing Java objects, and with Grails, but the more recently promoted stuff isn't being used in favor of other options, and even Gradle seems to have been totally rewritten in Java for Gradle 2.0. I suspect Gradle will soon open its configuration as an API so any language can be used with it.
I think that's what's so great about Scala, Python and other languages that mix OO and functional elements; you don't have to throw away Java and pick up Haskell, you can start experimenting with other styles as you go.
> Scala, as a programming language, tries to incorporate too many concepts
Too many concepts? Says who? How many concepts is too many? You don't have to use them all, and you can pick them up fairly easily as you go along; that's exactly how I learned the language.
> while still trying to be typesafe.
Not sure why that's contentious.
> This makes the language complex, and not an ideal candidate.
Says who? Why? Should all complex things be abandoned? I find the Android framework itself complex, personally, so should we throw that out?
This is the same Scala FUD that's always prevalent on Hacker News. "The language does too much." So what? You don't need to know all the concepts to be proficient. The language's beauty is that you can write simple code and pick up the concepts as you go along. Library modularity generally means that you don't need to get into the deep end of the language unless you want to. Scala is an expressive language. That's an intentional design decision that makes it flexible. It is not a drawback. It does not make it overcomplicated for a beginner.
Says at least me and the OP, and probably others... I haven't put a ton of time into learning Scala and only occasionally interact with it, but in that capacity I'd definitely say I find it a bit intimidating and someone hard to read. Certainly there are many ways to write Scala, and a Java-like style is doable, but idiomatic Scala, as far as I've seen, encourages terseness and the use of opaque punctuation-laden operators that aren't immediately interpretable by people not familiar with the language.
Whether legibility from non-experts is important is absolutely a matter of opinion and personal taste (it's a clear source of disagreement between the Python and Ruby communities as well), but if you're someone who thinks it's an important property for languages that get widespread adoption to have (and I am), looking at Scala code as it seems to typically be written would give you (or at least gives me) pause. I can look at Swift without having ever written any and know roughly what it's doing. I can't with Scala. I don't think they fill the same niche, as the poster seems to be advocating that they could.
Gut feeling, Scala is the new Perl. At least with respect to 'idiomatic' Scala/Perl encouraging a terseness, as well as a fairly deep/loyal (if small) fan base. Also, many of the use cases where the language shines tend to be non-mainstream - usually other languages handle mundane 'every day' use cases differently, perhaps more verbosely, but also with a lot more developers on board.
Just a thought that popped in to my head. I've no doubt I've offended the very core of many Scala and Perl devs out there just now. ;)
This is not idiomatic Scala.
http://docs.scala-lang.org/style/naming-conventions.html#sym...
> Avoid! [...] As a general rule, symbolic method names should be well-understood and self documenting in nature. The rule of thumb is as follows: if you need to explain what the method does, then it should have a real, descriptive name rather than a symbols. There are some very rare cases where it is acceptable to invent new symbolic method names. Odds are, your API is not one of those cases!
Looking at the major Scala libraries and frameworks today, I don't see a ton of symbolic operators in use. Akka just has ! and ? (both of which have very obvious uses once you understand actors), Play only uses them for iteratees (which most devs will never have to think about, plus it provides named equivalents for all of them), SBT has been cutting back. Outside of scalaz, the problem seems to be under control.
You realize that Swift not only resembles Scala syntax closely, but also adopts many of the same concepts?
Yes, you do. We heard this kind of argument with C++ twenty years ago. You can choose to ignore huge portions of the language for your personal use, but once you start working on a team, you will have to know the entire language.
That's not a fact -- its not even a fact claim -- its a value judgement. "Too many", except as sloppy terminology for exceeding an objective criteria, is inherently a value-judgement qualifier.
But usually it's like:
"so which concept do you think is superfluous?"
"crickets"
It gives tools to those who need it in a simple and elegant way, why is this a problem?
Use the features you find useful, don't use what you don't want to.
(Of course you can do more complex things in Scala, taking advantage of the powerful type system. But you don't have to if you don't want to)
For something like Android, running Groovy with CompileStatic enabled by default would make a lot of sense.
In theory, but in practise virtually everyone uses the dynamic typing only. Groovy's really only used with Grails and for testing Java classes.
> Android, running Groovy with CompileStatic enabled by default would make a lot of sense
Unlike other statically-typed languages, Groovy's CompileStatic code was written by only one person and having it be the default would expose all the bugs.
Why ? is it a social thing? or a technical thing?
And shortly after that, he became a full time contributor to the Kotlin language.
Though, I doubt it is much worse than Java these days.
Not to say this is bad, it just means you need greater discipline when writing software in Scala. A bit like C++ (yes, I went there! :-)).