Scala == Effective Java?
grahamhackingscala.blogspot.com
grahamhackingscala.blogspot.com
Compare IoC (Spring setter injection), with J2EE+EJB2.x - it's night and day - and I know which I would prefer to code using. Spring introduced POJO programming and explicitly called out the crappy J2EE design patterns in favour of simplicity.
Now, Spring has accumulated so much cruft (and become much more commercial with the vmware buyout), that it is becoming the new J2EE.
I've been doing some android programming recently, and working with Java without IoC is simply unbearable.
Agree. J2EE is an even worse example of "Java the culture". For a much better alternative, see Guice. I personally prefer "it's okay to call new sometimes" Design Pattern to IoC containers (but occasionally I find myself using Guice).
Can't you use Guice with Android? I'd be surprised if you can't.
Java the language is at least 8 years older than Scala the language. Scala had the benefit of learning from previous language's mistakes.
No, because it's not like Java was the first language to ponder about these, and it did not learn from previous languages (mistakes or successes). Pretty much all of Scala's improvements over Java predate Java itself by decades.
Java simply refused to learn from previous language's mistakes.
To some extent, C# did as well by starting out as a slightly improved Java instead of an actually good language, which means even with all the improvement they're doing since they're not deprecating and removing old crud the language is now chock-full of crap and far more complex than it could (and used to) be.
Since C# 1.1 they've only added features that are mostly orthogonal to the existing ones. Secondly, the features they've added aren't half-baked. Sure there's room for improvement, but they behave as you expect them to, and the designers specifically leave room for improvement all the time.
Sure, I hate that everything I want to do still has to be specified within a class / static method; that's Java-related legacy done probably because of marketing reasons, but C# has 2 things I wish for whenever I'm working with Scala ...
- the ability to get the expression tree of a closure. There was a plugin for Scala at some point, but it's dead.
- dynamic typing, which structural typing cannot really replace.
You say chock-full of crap, but IMHO language designers should learn from its evolution, because it was a good one.
Yes. Like delegates (1.0), anonymous delegates (2.0) and lambdas (3.0). Or `for`, `foreach` and List.ForEach. Orthogonalith, schmortogonality.
> Secondly, the features they've added aren't half-baked.
Though I disagree with your statement (C#'s properties are crummy, its Nullables are half-assed if even that, the collections are a mess, the enumeration suck goats, arrays are covariant, implicit conversions are terrible ideas, extension methods are a half-assing of open classes, tuples are painfully awful, out parameters everywhere is a gigantic joke, and I'm not even actually looking for these things), I didn't state they were half-baked. Me thinks the lady protests too much.
> Sure there's room for improvement, but they behave as you expect them to
Which is irrelevant to the point and completely uninteresting.
> IMHO language designers should learn from its evolution, because it was a good one.
There was nothing good about it. Trying to make a small but crappy language into a good language by accretion is not "good evolution".
edit: let's make this clear: I understand the constraints of the C# team (at least some of them) and I understand they weren't (and aren't) out to create a good language, let alone a revolutionary one. Doesn't mean I have to agree with that.
"for" is different than "foreach", and "for" is there because the language being named "C#" it had to have some heritage from C. Also all ForEach methods are built on top of IEnumerable.
I.e. features are built on top of each other.
For the record I think implicit conversions are a great idea, that properties are OK, and extension methods are cleaner than open classes.
Not to mention, there's stuff you can do with extension methods / implicit conversions that you cannot do with open classes (and viceversa).
Delegates are references to code blocks, anonymous delegates are references to code blocks, lambdas are references to code blocks. They're three features which do the same thing, meaning they are not orthogonal (and they could have been build from lambdas up and I'd have said the same thing).
> "for" is different than "foreach"
Yes, one has 3 more letter than the other one. Any usage pattern of `for` can be replicated by `foreach` and the right enumerables, and vice versa. Not only are they not orthogonal, they're fully redundant.
> and "for" is there because the language being named "C#" it had to have some heritage from C. Also all ForEach methods are built on top of IEnumerable.
This is completely irrelevant to my point and absolutely uninteresting.
> I.e. features are built on top of each other.
These features also fundamentally do the same thing i.e. they're not orthogonal. Your original claim was the following:
> Since C# 1.1 they've only added features that are mostly orthogonal to the existing ones
I gave you 4 features which are anything but orthogonal to preexisting features.
> that properties are OK
Goodness gracious, stockholm syndrome much?
http://news.ycombinator.com/item?id=1942859
http://www.reddit.com/r/programming/comments/ec95s/jon_skeet...
Compare Java to C++, for example -- the top 5 things that annoy me about C++ are mostly fixed in Java (#ifdef, STL inconsistency, .h and .cpp files for one class, destructors, bounds checking..)
No. It only "learned" from C++'s mistakes, if even that, and threw out the baby with the bathwater (threw out templates but tamer generics as well, threw out non-nullable references, threw out context management — RAII or other)
> The fact that it's ubiquitous, not perfect, has traditionally been slow/judicious to adopt new features (good), and hasn't had a release in the better part of a decade (bad) , amplify the perception of it's flaws.
No, the fact that it's full of flaws that have been criticized from the start does that.
> bounds checking..
Java didn't fix bounds checking, they only fixed the memory unsafety of it, because Java is a GC'd language and therefore memory safe by default.
Personally, I think throwing out templates is exactly what should have been done. And Java has generics.
What other lessons were they supposed to learn according to you, exactly?
Sure, if his goal was to create a super popular enterprisey language, to create the son of Cobol and to bring mainstream language improvements to a shrieking halt for a decade, he succeeded admirably on all counts.
> Personally, I think throwing out templates is exactly what should have been done. And Java has generics.
If you can't even be arsed to read what you reply to, I don't think there's any point in me continuing.
I addressed templates, which to the extent I've seen them, are a confusing nightmare. You can say that's because I'm not smart enough, but I'd retort that I don't want to debug something that smart.
Non-nullable references you can make a case for, but but it's minor and you can also say 2 types of references complicates things much more than one type of reference. Java dodges all kinds of confusion by only having one kind. And context management, which is such a relic that I had to google it, seems to be a hack to make memory management easier to deal with. Again, clever, but I'm not sure I want to debug it. How about avoiding static state and dodging the whole problem.
Java has 50 keywords total, including "void" and all primitive types, and it can do almost all of what C++ can. Yes, the OO model is a product of 1995. See smalltalk. EJB is "enterprisey", Java is not. And all organizations, regardless of hipness, need maintainable code.
Anyways, certainly nothing is perfect, so I'd love to hear more thought-out reasons why Java sucks.
You probably never programmed in C++ before. Trust me on that, Java was a breath of fresh air and it was obvious to everyone that it learned a lot from past languages.
> No, because it's not like Java was the first language to ponder about these, and it did not learn from previous languages (mistakes or successes). Pretty much all of Scala's improvements over Java predate Java itself by decades.
Maybe, but if these features had been put in Java in 1995, it's very unlikely it would have met the success it knows today.
Sometimes, the hard part in language design is knowing what feature not to add. Java did great in that respect.
Scala... not so much, if the language complexity is any indication.
Very small parts, and very badly implemented. Apart from C++ which is definitely the major influence on Java. The rest boils down to "hey smalltalk is object-oriented and java is object-oriented, so java is based on smalltalk amirite?"
And the answer is no.
An LLVM front-end would make it much more appealing for general use. Perhaps as a sane (?) alternative to C++ in the high performance computing arena.
GCJ attempted to do this for straight Java; I don't believe many people consider it a success.
val newFoo = oldFoo.copy(bar = someBar)
Another issue is using scala code from java. As long as the code implements a plain java interface, everything is fine, but if you try to use something impemented with some of the features that java doesn't have, you will soon see some very stange mangled names. trö_%¿ is not a valid java fuction name, after all.
This is not entirely dissimilar from the way that JSP gets converted into a Servlet.
Scala/AlternateLanguageRunningOnJVM fans please provide corrections as appropriate, but be gentle, I'm making some broad generalisations here with all the flaws implied by that methodology. :D
You can easily use any Java libraries from Scala and Scala provides a number of tools including JavaConversions and JavaConverters to automatically convert to and from Scala and Java collection objects for easy interop.
I am always deeply suspicious of any appeal for using a language that uses as it's initial premise that the language is shorter or saves keystrokes.
Personally, I'd take one of his examples and make it 'worserer' by enbiggening it.
new RunningReporter();
public class RunningReporter extends Thread {
public void run() {
System.out.println("Running");
}
}
public class RunningReporter extends Thread {
public void run() {
System.out.println("Running");
doSomething();
}
public void doSomething() {}
}
But even that isn't as useful as it could be, it should really be something like:
public class RunningReporter extends Thread {
String message = "";
public RunningReporter(String s) {
super();
message = s;
}
public void run() {
System.out.println(message);
doSomething();
}
public void doSomething() {}
}
e.g.
new BluetoothRunningReporter("Spp fix");
I find that upon examination, in a properly and well designed Java system almost all of the anonymity disappears... which makes me uncomfortable with that example of how Scala is better than Java, because in the real world, if you were doing it properly, you wouldn't do it that way in Java anyway.
As an example, the Java Collections API (one of the most well-designed Java APIs, imho) uses Comparators extensively. It's pretty common to define the Comparator as an anonymous inner class when you need to do a one-off sort() or max() call.
Scala just makes it easier to use this pattern. There's no need to go through the effort of wrapping the function in class if you're only going to use it once.
class Kitty {
val purrVolume: Int;
}
public class Kitty {
private int purrVolume;
public void setPurrVolume(int purrVolume) {
this.purrVolume = purrVolume;
}
public int getPurrVolume() { return purrVolume; }
}
If you were using val you would do:
class Kitty(val purrVolue: Int)
public class Kitty {
private final int purrVolume;
public Kitty(final int purrVolume) {
this.purrVolume = purrVolume;
}
public int getPurrVolume() { return purrVolume; }
}You can trivially replace the auto-generated methods by manually crafted ones, keeping the same types (since they're a direct consequence of the original object's type: a String member will have an accessor of type `() => String` and one of type `String => ()`). If the compiler sees the "public" member already has accessors defined, it doesn't generate them. Could hardly be simpler.
http://groovy.dzone.com/articles/why-scala-actors-15-20-time...
These days I use mostly ruby and have started on node.js. Ruby programmers don't seem to understand the importance of encapsulation and typing, which is quite frustrating and leads to much head banging. I yearn for the day Scala or something similar is broadly adopted.
Interestingly, many of the best features of scala mentioned here are veey new to the language. Named parameters and built in copy for case classes were not available until a year ago. It's great to see a language implementing prudent improvements quickly - here's looking at you Java.
Interesting juxtaposition. I wonder if it's a concrete benefit of static typing to make you more aware of encapsulation: that does resonate with my experience. Because functions and object methods have to have types that fit together, you're forced to think about what goes into and comes out of a given component, so you're thinking about component boundaries more often.
I know when writing a Ruby method it's all too easy to just return the first intermediate result that makes sense, subconsciously thinking "let the caller process this result, and if it's messy I'll refactor it later". In Java, I have to write the return type and also return something, and if I planned to return an Iterable<String> but I'm tempted to return a List<Object>, the redundancy catches me out. I have to consciously make the decision: should I change the contract of this method by changing the return type, or should I instead massage the results into the form I planned to return?
(I think the same holds for Scala, where I might not have to write the return type because it's inferred: if anything actually calls my method, the compiler will still remind me that the assumptions made at the call site don't line up with the assumptions made in the method. In Ruby, although I'll still have to change the caller if I change the return type, I'm more likely to do it mechanically, in a "I changed that so I have to change this" mindset, rather than stepping back a level and thinking "which one of these is actually right?".)
Regarding Scala, I don't think type inference means that you stop thinking about types, particularly when writing in a functional style where the returned value is the only thing that matters.
I didn't mean to imply that it did - quite the opposite in fact (that even if you didn't write the type, you'd still be encouraged to think about it, because of the compile-time checking).