11–20 of 36 posts
I still can't believe how many people are unaware of C#. Coming from a java background, C# is a far better route than Scala. The Scala syntax, I must say is not as readable: def apply() = l map (_())
def apply() = l.map((f) => f())
I still can't believe how many people are unaware of C#. Coming from a java background, C# is a far better route than Scala. The Scala syntax, I must say is not as readable: def apply() = l map (_())
That is only one way of writing that snippet. Another would be: def apply() = l.map((f) => f()) Is that more clear?
However, it is also incredibly confusing to learn/use at times because it is still maturing and such. The tooling isn't as good as Java.
The web frameworks for Scala are actually both awful and awesome. Lift is beautiful, but designed by a nerd and won't ever get Rails-like traction. Play is fantastic, but it's just as fantastic for Java, so it almost negates the desire for Scala... almost.
Ultimately, Scala is a breath of fresh air largely because most of modern Java focuses so heavily on Java EE. Scala provides a clean break from that (if that is what you're looking for).
Scala is going to be a niche JVM language. It will never reach the usage levels of Java/C#. It might hit Groovy levels of usage, maybe. I doubt it will ever be as big of a hit as Ruby/Python.
I knew I felt some unease with Scala's abbreviated lambda syntax, but couldn't pin down what it was that bothered me. Seeing these examples clarified it: def apply() = l map (_()) println (users filter (_.age The first two uses of () are anonymous functions, the last is a tuple. The only way to tell them apart, best I can tell, is the use of _ turns the scope of the surrounding parens into a lambda. Clojure uses the…
Scala has a lot of utility and I hope that people don't completely discount the platform entirely just because of these examples. Hopefully in time as the platform matures we'll see a better solution to the above.
The problem is that then you'll have both the old way and the new way, which will be even more confusing to read and keep straight.
There is no doubt in my mind that if Java had added just a few features of these languages we wouldn't be having this discussion. My MVP would be lambdas, type inference, properties and extension methods and that would probably have been enough to make explorations outside of Java mere curiosities. In the mean time, I'll keep helping out on JDK8 to get 2/4 in there.
It's a Java-compatible JVM language that doesn't change stuff up too much, just addresses some shortcomings of Java.
Earlier quoted context omitted.
Scala has a lot of utility and I hope that people don't completely discount the platform entirely just because of these examples. Hopefully in time as the platform matures we'll see a better solution to the above.
" Hopefully in time as the platform matures we'll see a better solution to the above." The problem is that then you'll have both the old way and the new way, which will be even more confusing to read and keep straight.
Earlier quoted context omitted.
That is only one way of writing that snippet. Another would be: def apply() = l.map((f) => f()) Is that more clear?
This actually is one of my frustrations with Scala, too many right ways to do the same thing. Makes it easier to write but harder to read especially when people have drastically differing styles. One of the advantages of Java is how easy it is to read and use someone else's code since the base language is so limited.
The result is a Java++ that's worse than C++. It slows down compilation 10x and makes proper tooling (IDE support) 10x hard, while providing no performance advantages. In C++, you can often get nice abstraction idioms (mostly due to template (partial) specialization, SFINAE) with zero performance penalty.
Java folks should just enjoy the superb IDEs (not just 1 but 3) and look forward to Java 8 or something like that (pending the Oracle issues), which will have a reasonable closure implementation ((JSR-335 looks OK to me), which would make much of the user (vs library/framework writer) side verbosity go away.
People use Java because its stability, compatibility and ecosystem, so C# wouldn't be a viable choice for them but an interesting thing to watch and learn lessons from.
Obviously there are no silver bullets that make software development easy. But after having written a handful of high performance, high availability systems in Scala, the benefits over the other alternatives on the JVM are so evident to me, it's easy for me to get frustrated that they aren't obvious to everyone. Of course we still have occasional bugs, and sometimes they are hard to diagnose. Just exactly like Java, and any other language you care to choose. Bugs are inevitable. But there are a couple of things that make Scala stand out, and I'm a bit surprised at how fickle the community is about this language. One day everybody loves it, the next day, everybody seems to hate it because it didn't make programming easy. Both are extreme; as engineers and scientists we should approach cautiously and methodically; doing so, in my view, makes a few truths unescapable:
1. Scala is far less code than any statically typed language on the JVM. Less code means fewer bugs.
2. The Scala collection framework is a tour de force. If you can't see that, you should keep looking. Seriously, it is quite simply amazing for anyone coming from Java -- there is nothing like it. Not since I first got a taste of STL have I enjoyed the hybrid sensation of aesthetic awe with the 120M volts of power. It is just so clean, so orthogonal, and such a pleasure to work with. It is hard to go back after you have gotten used to this thing.
3. Scalacheck takes testing to another level. When I take the care to properly use a tool like Scalacheck to cover what I'm working on, the number of bugs goes as low as I've seen on any platform, anywhere. I have live code which I am pretty damn sure doesn't have any bugs. The only code I've written in 20 years of doing this that doesn't have any "not critical enough to fix" bugs, is written in Scala. I cannot tell you how satisfied that makes me feel -- it's a long time since I considered that possible.
It is difficult to argue against the idea that there are too many ways to do things in Scala. There is more than one way to do a lot of things, and I personally find the right way for me to be fairly evident after writing a few thousand lines of code. As an engineer, I'm all for constraints to make my job easier. But at the same time, since writing code is a very indirect way to express ideas, it can be nice to have an expressive, fastidiously symmetric, means to do so. The symmetry in Scala is breathtaking ... the edge cases in Scala are an order of magnitude less bizarre than the edge cases in Java. After a few months of Scala, the pathological examples touted in these comments look completely obvious. They are doing a powerful thing. Learning to think in the language is required if you want to be fluent. And what I love about learning to think in Scala, is the extremely intelligent hand of its creator is evident everywhere.
Earlier quoted context omitted.
I can definitely relate to that. I was in a discussion a while ago with 2 friends, and I was "the Java guy". After that chat, I decided to go back to C# and give it a second chance, despite my Microsoft allergy ;) It is clearly a better designed language, which of course "borrowed" a lot (90%?) from Java - and then improved it.
More to the point, Microsoft is continuously improving C# I was at a conference back in 1997 where we came up with a wish list of features we'd like in Java for high performance computing. We all knew it was useless to ask this from Sun, but we did anyway. The first version of C# had everything we asked for in it, and even early versions of C# had a 'delegate' mechanism that was, more or less, method pointers. C# 3.0…
Offtopic but interesting tangent: that's comparing declined languages ( with nominative, accusative, dative etc cases) to languages that use prepositions and other particles instead. Kind of like comparing static type languages vs. clojure and erlang.