Sneak Peak at Java's New Makeover 114
SadatChowdhury writes "Aside from templates as already reported in a past slashdot article , a little snooping around revealed the details of the following newly revealed features in the upcoming release of Java 1.5 (codenamed: Tiger) : Autoboxing , Enhanced-For-Loop, Enumerations and Static Imports . Must read for Java fans."
In related news: jdkane writes "Sun Microsystems delays a much-anticipated Java specification by three months to comply with guidelines designed to keep Web services interoperable. Says Ralph Galantine, group marketing manager for Java Web services at Sun: "We thought that this change was important for the industry, so that there was no conflict between J2EE 1.4 and the WS-I, "We thought it was worth taking out to the summer." It's very refreshing to hear that a big software company is looking out for the industry, instead of just their own."
Yay! (Score:2)
At least *I* think it's reason to rejoice...
Re:Yay! (Score:2)
s/Python/C++/g
Re:Yay! (Score:1)
After all, both Java and C# are proprietary languages owned by large corporations and granted to the big wide world on sufferance (tho' it looks like Java's currently being taken over by an even larger corporation at the moment). Python and C++, OTOH, belong to Guido and the ANSI/ISO committee respectively, and to their user communities.
Re:Yay! (Score:2)
Of course, I'd prefer the revers. I'd rather have python become more Java-like in terms of its standard library... like, say, a GUI library?
Re:Yay! (Score:2)
Actually Python is already a feature of Java and Java is already a feature of Python. It's called Jython and you can code against any java package, including SWING or the Eclipse SWT, in Jython.
Re:Yay! (Score:2)
I sure as hell wouldn't use python to call Swing...
No what I meant was that I would like to see some (very thin!) wrappers in python for native OS widgets, sorta like SWT. wxWindows just doesn't cut it, IMO.
Don't forget Generic Types (Score:2, Interesting)
I'm not too sure I like them, as they do add a completely new and different and more cryptic syntax to Java, but I can definitely see the use for them. No more clumsy casting when you retrieve something from a List.
Daniel
Re:Don't forget Generic Types (Score:1)
Yes, although generics != templates (Score:5, Insightful)
Templates were C++'s way of simulating generic types. The difference is that templates are essentially macros in fancy clothing, and generate a different flavor of the class for every combination of type parameters, while generics are a much cleaner, more abstract construct, better grounded in the theory of types, which use polymorphism to achieve their genericity.
Don't know if that made any sense....
In any case, this will be a fantastic feature, and they're done a much better job with it than C++ did with templates.
Re:Yes, although generics != templates (Score:3, Informative)
That's one definition of generics, but hardly the only one in use in the programming world. "Polymorphism" is one of those fantastic words that has had so many meanings attached to it that it no longer means anything useful without further qualification. Templates in C++ can do a little more than boring old macros these days, too.
If you're going to troll, could you please at least provide some sort of supporting evidence? On paper, the Java implementation is similar to C++ templates but with the usual Java trade-off that some of the power is sacrificed to improve the simplicity. However, in this case, that leaves Java generics without several useful features, and consequently without the ability to do most of the useful tricks that leading edge C++ can do. How do you see Java's generics as better than C++ templates, other than being simpler, and using OO-style polymorphism (which isn't really a generics issue, it's a C++ type system vs. Java type system issue)?
Re:Yes, although generics != templates (Score:2)
"Generics" in this case means "type abstraction," which has been well-known to type theorists (the people who invent advanced type systems for programming languages and prove things about them) for some time. Type abstraction refers to the ability for a function to be "abstracted over types" by making the type depend on some input type in the same way normal functions are abstracted over values by making the function's return value depend on input values. There's a huge body of literature on this topic.
Maybe more than boring old macros, but not more than exciting new macros! Seriously, if by "macros" you mean "C preprocessor macros" then you're right, but to a real Programming Languages Weenie the term "macro" means something much cooler. Some languages, most notably Common Lisp and Scheme, allow source rewriting in a much more powerful and less gawdawful way. The standard example of how powerful true macros can be is that in Lisp, you can implement an entire object-oriented programming system that appears every bit as built-in as Java's object-oriented programming system using just a user-written library of functions and macros. New class syntax, appropriate error messages, everything.
It turns out that templates are kind of a 'Vogon liver' phenomenon: in the same way Vogons had a mutated liver that evolved to serve brain-like capacities, C++ templates are a bad solution to the problem of type abstraction that mutated and became a bad macro system. Seriously, download a copy of DrScheme, read up in the help files about 'syntax-case', and watch yourself be amazed as you realize the power of macros done right.
Re:Yes, although generics != templates (Score:2)
Nah. The parent post was written by a standard, mark I "Java-biased C++-bashing weenie", a particularly tedious subtype of Programming Language Weenie whose sole purpose in life seems to be to post not-quite-accurate comments about C++ and Java with the sole aim of slagging off C++, whether or not said comments are actually relevant to the conversation at hand.
But thanks for the tip. :-)
By the way, I too am something of a programming language weenie, and quite familiar with the literature on formal type systems and such. However, I question the merit of even raising such issues in relation to languages such as C++ and Java. Neither language has a particularly pure type system, and it makes much more sense to compare and contrast corresponding features of those two (such as C++ templates and Java generics) than it does to have a dig at the fact that other languages have a theoretically sounder basis.
New and Improved for()! (Score:3, Interesting)
Re:New and Improved for()! (Score:5, Insightful)
I am in awe of the new for() statement. Java was designed to be logical and readable, but unfortunately for (String s : c) means nothing to most developers.
The JCP is a classic case of committee design: everyone has their own ideas based on their experience, and doesn't really understand the purpose or path of the Java language. Most JCP suggestions are calls for Java to look more like C++ or Python.
Re:New and Improved for()! (Score:1)
Which is no way keeps backwards compatibility: the syntax change in the for() construct means that you can't compile the source on older compilers, just as for foreach. I'm not the first poster to point this out.
Either syntax can be compiled to a byte code representation that is backwards compatible.
Re:New and Improved for()! (Score:4, Insightful)
Re:New and Improved for()! (Score:1)
Re:New and Improved for()! (Score:5, Insightful)
Re:New and Improved for()! (Score:1)
Re:New and Improved for()! (Score:1)
hmmm.... coincidence?
Re:New and Improved for()! (Score:1, Flamebait)
If only Java had anonymous functions, it would be easier to make it a tolerable language. One could always use anonymous classes, but who would rather type 5 lines instead of one to achieve the same thing with the new for? It would be a lot more conceptually consistent, but I guess the JCP doesn't want to give in and make Java a good language.
Re:New and Improved for()! (Score:3, Insightful)
The fact of the matter is that it's a show of the weakness of Java that to add any feature- however small- the syntax has to be extended. More mature languages in the same/similar class as Java can achieve this without adding a new syntactical element everytime some little feature is requested. Smalltalk and Lisp manage fine. Hell, even languages that may be arguable as less mature as Java like Python and Perl can manage to add features without adding new syntax.
Re:New and Improved for()! BAD IDEA (Score:2)
One of the most important things in coding is readability. Frankly,
for ( String blah : bleh)
doesn't really say anything on it's own, the reason they call it a programming "language" is because it reads like a language.
"for , string c colon f " means shit.
"for string s equals c iterator
Please god don't butcher this language.
--noodle
Re:New and Improved for()! (Score:1)
while (iterator.next()) {
}
Changing the syntact of a language to make it quicker to type is not so important with IDEs such as Eclipse that the while/iterator combo with a few key strokes.
Also Concurrency/Memory/Threads/Isolation (Score:5, Informative)
There are some other interesting changes coming to provide a more coherent memory model [jcp.org], vastly improved concurrency support [jcp.org], and intra-JVM application isolation [jcp.org]. Java is getting much better at providing access to the capabilities of the underlying OS, and the JVM working more like a little multi-process OS itself...
Larry
Re:Also Concurrency/Memory/Threads/Isolation (Score:2)
Re:Also Concurrency/Memory/Threads/Isolation (Score:2)
Autoboxing (Score:3, Insightful)
Hmm... extremeley Microsoftesque. Much like VB5 and 6's variant data type and C#'s boxing rules.
Seriously, with a language like C you can feel like you actually know ALL the rules, and it makes you feel safe. With the beasts that are VB.net/VB6 and C#, and the one that Java is becoming, you always have that lingering "What If" in the back of your head. Seriously, you end up programming with the idea "Nah, they wouldn't let me make that mistake" constantly in the back of your head.
Re:Autoboxing (Score:5, Interesting)
I agree with you fully when it comes to VB and Java, but C# does not deserve to be lumped into this category. Everybody knows VB wasn't really "designed", it just sort of "happened" over the years. Java had a lot more design work behind it, but it still suffers from weird evolutionary lumps that always "feel wrong" when you're using it. However, C# went through a very long and intensive design period, with more well-defined goals than Java (the set-top-box language), and I believe with a LOT more R&D-phase input from the real world (as anybody who participated in Don Box's .NET listserv discussions can tell you).
C# is a lot like C in that the language itself is limited and well-defined, although not to the extreme basics of a 12-keyword universe like C, owing primarily to the additional keyword overhead needed to express certain modern concepts, many (most?) of which are OOP-related. In that sense it's a little like C++.
For an experienced programmer, the trick is to first understand the .NET class hierarchy (hint: avoid books that harp too heavily on web services buzzwords; web services are just a few pieces of the very large .NET puzzle). Next, understand the C# language on it's own. Most of the books out there seek to tackle both of them simultaneously, and that's a big hinderance to learning, and probably what causes people to make statements like that made by vandel405, above.
Don't judge the subject matter by the quality of instruction...
Re:Any recommendations? (Score:2)
Re:Any recommendations? (Score:1)
Re:Autoboxing (Score:4, Insightful)
The price you pay is that you have to write a lot more rules yourself, which takes a lot of time (and hence money). The "beasts" as you refer to them (not that I think VB is a serious development language) do not require you to reinvent the wheel every time.
Yes, in C you can use libraries, but the more libraries you use, the more rules you have to know and the less you feel like you can know them all. Let's face it, programming is a complex task. Either you get the complexity out of a can or you provide it yourself.
Re:Autoboxing (Score:2)
Happy to see Java gain features. (Score:3, Informative)
I for one will like the new features Java is gaining. All too often when programming in Java for school (the main place I use Java), I often find myself wishing and wanting some of the features of C++. I've even gone so far as to write a perl script to allow me to create my own templates and have it convert the template to a proper .java file. Has anyone else resorted to this hack?
On the other hand, Java still is not my preferred language. C\C++ will probably always be my language of choice. They are what I learned first, what I enjoy programming in most, and which I plan to never quit using. Being able to use several design paradigm's is extremely nice, which is why my other favorite language is OCaml. However, I am still picking up its nuisances so things are subject to changing.
I would like to know, however, why the professors at my school bash C and C++. I for one can see the weaknesses of the languages, yet I can also find weaknesses in many other languages including the languages of functional and declarative paradigms. I think a lot of their disdain for C and C++ are due to memory management. However, manual memory management has never really been a huge problem with the way I write my code. Anyone else care to respond on if this is an academia thing to hate C and C++ or just my school? Perhaps all my teachers have their heads on tripods just like the people they complain about. Especially since, they do not work to try and improve the current programming languages.
Re:Happy to see Java gain features. (Score:4, Interesting)
Personal biases are, imho, always a good thing, as long as it's not BASIC. (sorry, couldn't resist)
The view here is that Java is by far *enforced* on most courses, although most lecturers I personally speak to seem to prefer Lisp/Scheme and C/C++ over Java. For instance, we had a course on data abstraction where the labs were in Java, but the lecturer taught in pseudo-code (claimed he didn't know any language other than C). Worked fine for me; I aced a project on image manipulation using only pseudo-code! B-)
Re:Happy to see Java gain features. (Score:2)
Color me goofy, but is the joke the whole line, or just the BASIC part? I thought it was just the BASIC part, in which case: how do you figure that personal biases are a good thing? I always thought of them as slightly-negative or possibly neutral, something which simply is.
Re:Happy to see Java gain features. (Score:2)
To take a natural language metaphor, I speak five languages, but prefer writing poetry in only two. I hope I'm making my point clear.
Re:Happy to see Java gain features. (Score:2)
Hitler killed people of many religion, races, creeds and sexual orientations, but he preferred killing Jews. I don't see how that illustrates the idea that strong personal prefs are good than your natural language example does.
Re:Happy to see Java gain features. (Score:1, Informative)
Try the Java Syntactic Extender (Score:1)
Re:Happy to see Java gain features. (Score:2)
It does seem to be a popular academic past-time. I suspect it's similar to the slashbot groupthink effect. Most of these people have the luxury of working in a theoretical world, where the sorts of practical issues that make C, C++ and their ilk so useful are not relevant. They then reinforce each other's beliefs and preconceptions when they discuss things, without outside influence to put the opposite point of view.
A couple of the researchers at the computer lab where I did my diploma were like this. (The lab has several well-known names from the ML world there, BTW, and functional programming is very much their thing.) I also saw a few lectures given by others in the department that touched on C and C++, and they were pretty similar to what you see in bad books and uninformed comments around here: based on the languages of 10-20 years ago, and with no effort made to even investigate how things might have changed since then.
It's the old problem: academia produces some potentially very useful theory, but never does anything practical with it, while industry labours along using pragmatic techniques that are decades behind the times, because it's too scared to move away from known safe ground and investigate the applications of academic theory for itself...
Exactly. The question is simply whether the weaknesses are actually important to how you're using the language. The answer is very different for an academic researcher and a full-time professional software developer.
Re:Happy to see Java gain features. (Score:1)
Re:Happy to see Java gain features. (Score:1)
-Mmm.... m4 on linux.
Re:Happy to see Java gain features. (Score:1)
Allow me to respond to this. One of the biggest problems with languages that force you to focus on handling things like memory allocation and deallocation is that it detracts from the time you can spend actually working on solving the problem at hand. In academia, there seems to be a strong bias towards languages which let the machine do the "dirty," uninteresting work, and allow the programmer to focus on writing a correct solution. Only reason I hate C++ is that I have to use it at work :-)
Silly Java... (Score:1, Interesting)
1) C-style enums, because Java is too weak to support a true symbol type.
2) Enhanced for-loop for iterations.
So:
for (String s : c) {
}
Is now shorthand for:
for (Iterator i = c.iterator(); i.hasNext(); ) {
String s = i.next();
}
They did this, of course, because it was the least obvious, most ugly way possible to add this to the language.
They said that it seemed "too late" to add a new keyboard to the language, but apparently not too late to add new syntax.
The principle of least surprise tells me that something along the lines of:
foreach (String s, myStringCollection) { }
might be a bit easier to read than their seemingly random for( : ) syntax.
3) Autoboxing to automate the wrapping of Java primitives in classes.
This seems to be because Java didn't want to go pure OO. They wanted to keep their primitives, and yet be mostly OO, which turns out to just be a pain in the ass and gives rise to classes like Integer and Double.
4) C++-Style Templates, because Java would now like to get even closer to their goal of being "Almost all the power of C++, without any of the speed." Templates are pretty much a bad idea in any language. They are a work-around for a bad type system.
But then, what the hell do I know. I'm just a Lisp junky.
For the curious, the Lisp solutions to these problems are, in order:
1) Symbols.
2) Too numerous to count. First, the (loop
3) What? Variables with types? I don't understand! Variables don't have types, values have types!
4) See #3, plus true generics in CLOS.
Justin
Re:Silly Java... (Score:1)
How does this effect static testing? I am a lisp proponent but I find this to be a difficult target to tackle, especially in the corner cases.
Re:Silly Java... (Score:2)
There are two reasons off-hand that I can think of for autoboxing or whatever the hell name they gave it.
1) So you can pass-by-reference.
You can't pass primitives by reference in Java so the function:
void increment(int i) { }
is impossible to write. This is solved by wrapping the int in an Integer, because all objects are automatically passed by reference.
This feature is, of course, free in Lisp since everything is, in effect, passed by reference.
(defun increment (i) (setf i (+1 i)))
That works just fine in Lisp.
2) Autoboxing for collections, as they only take Objects.
This, however much I dislike it, will be solved by templates.
The variables and values with types stuff should have been listed under number 4, I believe, as it does apply with regard to templates and Collections.
In C++ and Java, crap like templates are necessary because the language will just take your word that a value has whatever type you say it has.
So, without templates, you have a LinkedList of what? void pointers?
So, now, whenever you iterate a collection you are getting void pointers. What type are they for real? Who knows. You'll just have to either guess, assume, or do lots of typeid() checks, because the language won't figure it out for you.
Given:
void foo(Object o);
void foo(Integer o);
Iterator i = c.iterator();
foo( i.next() );
It will call the first foo, because regardless of what value you put in the Collection, the Variable inside the collection that is holding it is of type Object. So, rather than the value specifying the type, it's the variable.
With templates this is "fixed" because it "remembers" what type your values were, assuming a homogeneous collection.
With real generics, like CLOS, this was never a problem to begin with as:
(defmethod foo (i) 'Unknown)
(defmethod foo ((i integer)) 'Integer)
(mapcar #'foo '(3 4.2)) => ('Integer 'Unknown)
This is because in Lisp a list is just a list. They could be anything. The list doesn't specify what type's the values are. The value's have their own types.
This is probably a poor explanation. I can try and do better when I wake up tomorrow if this made no sense.
Have a good night/day/morning/whatever,
Justin Dubs
Re:Silly Java... (Score:1)
public void increment(Integer i) {
won't work either since java.lang.Integer objects are immutable. You have to write your own Integer class.
Re:Silly Java... (Score:2)
I was familiar with incf, but just never realized that it had to be implemented as a macro. Your reasoning makes sense, and I tested it and you are right.
Thanks again, I love learning new things.
Justin
Re:Silly Java... (Score:2)
But the (unfortunately zero-modded) AC I'm replying too is correct that many people seem to confuse assignment to variables with binding of values.
Re:Silly Java... (Score:3, Funny)
Wait, LISP programmer?
Ah yes. You can always spot them from far. May the Lambda be with you, brother!
(Btw, I completely agree with you. Always a challenge to move to bracy languages from LISP)
Re:Silly Java... (Score:5, Insightful)
The colon syntax is not random. It's well-known and well-understood mathematical notation, namely Zermelo-Frankel set comprehension notation:
Re:Silly Java... (Score:1)
Well, yes, almost; there's just a slight little difference: It substitutes \in by a colon, and the colon by a closing bracket. Otherwise, yeah...
Re:Silly Java... (Score:1)
N = {x:x>10}
meaning, N is the set of all x such that x>10. In this context the colon means "such that", so using it like this:
for (String s: c){...}
does not seem very apt to me. Seems kinda random actually. But I'm in a bad mood, so whatever.
Quit yer trollin'. (Score:3)
OK, OK, I'm just griping -- and I actually, I really like Lisp quite a lot -- but I do think that sometimes it's easy to judge by familiarity, and Lisp pundits seem especially guilty of that.
There's rarely a single One True Right Way of implementing a language feature; we really need to judge each implementation in the context of the language it's implemented in, and look for a clean, consistent, orthogonal, well-closed meshing of the feature into the language's feature set.
With that in mind, to your items:
(1) The new Java enums are not C-style enums at all (nor are they Lisp's symbols). They are a special variant of classes with a stronger class-level contract than normal classes (a fixed instance pool being the big one), an approach which works very well in an OO language with strong static typing. (For those of you following at home, Lisp is, for the most part, a dynamically typed language.)
(2) Lighten up. The for(x : c) syntax is lovely to a Java programmer's eyes, and fits the existing constructs well. Lisp's approaches, unsurprisingly, fit Lisp well, but wouldn't make much sense grafted into Java. I am glad, however, that Lisp also solves this problem. That is good to hear. Thank you for sharing.
(3) Java's original designers had two concerns: first, primitives are a potential performance gain; second, the semantics of arithmetic get sticky when integers can be null. Other language (e.g. Smalltalk) have addressed these problems reasonably well, but it's still a very debatable issue.
If I had it to do myself, I'd probably not have introduced primitive types. However, as a Java programmer, what really matters to me is that they pick an approach and make it consistent. The autoboxing JSR does a good job of adding convenience without breaking this consistency, IMO.
(4) The only similarity between Java's generics and C++'s is in the syntax. Java's generics are "true" generics in the sense that they spawn new types, and rest on polymorphism instead of a sort of specialized macro expansion. (C++'s more macro-like templates make sense for C++, where static binding would preclude many aspects of Java's approach.)
I'm not quite sure what your complaint about them not being "true" is supposed to mean. Perhaps you're worried about the runtime typing semantics of generics? If so, I'd like to see you hold your own in an argument with Gilad on the subject.
But then, what the hell do I know. I'm just a Lisp junky.
I think the answer is fairly obvious: you know a lot about Lisp, and not enough about Java to be as opinionated as you are. I know much more about Java than Lisp, and I'm sure I'm guilty of the reverse.
But I don't think I need to be an expert in either language to say that we should judge each in its own context. Does C suck because it doesn't have lambda expressions? (If you are tempted to answer yes, I hereby sentence you to writing device drivers for three years.)
Re:Quit yer trollin'. (Score:2)
Yes! Damn you Perl types and your "There's More Than One Way To Do It" heresy!!!!
One day, the great god S-expression will catch up with you and you'll get your comeuppance, mark my words...
I think a very cool feature would be.. (Score:3, Interesting)
anonoymous inner classes can be used a little bit like blocks in ruby, only the syntax for anonymous inner classes is so verbose. Imagine this:
ArrayList list = new ArrayList();
ArrayList list2 = list.map(new UnaryOperation() {
public object call(object o) {
});
ArrayList list2 = list.map({ |object o|
It may not be possible because the exact interface to implement in the anonymous inner class would have to be derived from the method being called, which might be overloaded.
Anyway, I'd love to be able to use the terse rubyesque style in java, it feels a lot more declarative and communicates much better than all the explicit looping in java, c, C++, C#, VB, VB.net etc.
Re:I think a very cool feature would be.. (Score:2)
Re:I think a very cool feature would be.. (Score:1)
-austin
Thanks to C# (Score:4, Insightful)
C# comes out with a better language, and suddenly for the first time since inner classes were added in the mid-90's, the language starts evolving useful C#-looking features....
What I want next from Java is for Sun to invent delegates and properties.
Competition is a wonderful thing, and it's good to finally have some in the Java space.
Re:Thanks to C# (Score:1)
Re:Thanks to C# (Score:2)
Actually I've heard quite often how Sun's people would admit that some language features were cut out from 1.0 to make the language less complex and have implementations finished earlier.
Java# (Score:5, Interesting)
Autoboxing
the for-iterator [for(Sting s: Collection)] statement is actually "nicer" (in that intent is clearer from the code) in C# [foreach(String s in Collection)]
Generics
Enumerations
I propose they go full how and add the extremely powerful attributes from C# as well
In short
Re:Java# (Score:3, Interesting)
also, i don't think java is really "copying" C# features. you could say the same thing about most of C#'s features. in reality, both environments borrow heavily from years of computer science precedent.
Re:Java# (Score:1)
The last time Sun ever criticized any Microsoft language feature was when Microsoft added the "delegates" keyword to their (broken) Java implementation.
P.S. - Attributes suck. Big time.
Re:Java# (Score:2)
And using gcc instead of javac.
And writing in C++ instead of Java!
Yuck. (Score:5, Insightful)
- templates from C++;
- a new style of emun that does everything the Pascal enum does with a syntax that looks like a C enum except that it can have methods, AND MORE;
- a whole new foreach syntax that has the stellar advantage that the syntax doesn't resemble anything on God's green earth except Smalltalk, which is a pure prefix language like Lisp instead of an algol block language like C, C++, Java, C-hash, pascal or Ada (where the other features come from);
- generics using the template model from C++, which was a horrible hack on top of C++ because it was hard to make a backward compatible syntax (so instead we got ANOTHER class of macro to add to the #define) when C++ was a horrible hack on top of C so that at least C++ could compile C programs (except now it can't);
- a grammar that is going to be about LL(497) (doesn't anyone remember how ugly parsing C++ got to do templates, and how long it was before it worked?);
- and a whole wonderful new term ("autoboxing") for the notion that primitive types and class types ought to both have all the properties of types.
I know I'm probably just getting old, but Jesus!, why do we need to repeat all the mistakes of the past?Re:Yuck. (Score:2, Insightful)
Re:Yuck. (Score:1)
Re:Yuck. (Score:1)
On thing that Java has been good at doing, up until now, is focusing the enhancements on the SDK classes, making "compile-compatibility" relatively straightforward (i.e. download the latest/appropiate JAR and add it to your classpath).
Changing syntax is a bad idea, esspecially since the majority of Java syntax is elegent. Java is not broken, and does not need to be bullied by other languages into being something it's not.
Didn't their parents tell them peer-pressure is bad!
Re:Yuck. (Score:2)
Re:Yuck. (Score:1)
Definitely not. If Smalltalk's syntax pure anything, it's infix.
Re:Yuck. (Score:1)
anObject -- the target eats up the next argument
getsMessage: -- is the message
-- which then eats the next two atoms
withArgument
andAnother
-- getsMessage is full
. -- means we're done.
Compare that to a LISP version, say(Of course you end up needing to have sort sort of selector on the CAR of the second argument -- don't bother, CLOOPS is easier.)
To be fair, though, it's true that there is some infix syntactic sugar in SmallTalk: for example
a + b
is an alias of
a add: b
Re:Yuck. (Score:2)
anObject getsMessage: withArgument andAnother
is parsed purely left to right --
True, but irrelevant. A prefix syntax is one in which the operator precedes the operands. Smalltalk, like most OO languages, places the first operand, the subject of the method call, before the operator, and the remainder of the operands after, making it infix.
Compare that to a LISP version, say
Common Lisp's method call syntax is identical to the function call syntax, roughly (method arg0 arg1
To be fair, though, it's true that there is some infix syntactic sugar in SmallTalk: for example
a + b
is an alias of
a add: b
I fail to see why 'a add: b' is less infix than 'a + b'.
Re:Yuck. (Score:1)
Or you could think about it purely in terms of the grammar. My mind goes blank on the exact terminology for SmallTalk (it seems they named a couple of things oddly) but basically, the grammar comes out to be simply left to right, which is the same as prefix, which is the same as Polish, etc.
One of the rather brilliant things about McKay's (et al) original insight with OO was that by treating the things that look like operators as message selectors on the left-hand object, you get something that parses purely left-right -- ie, prefix -- but still reads infix. (Or almost -- like APL in the Old Days, you can occasionally get into trouble by forgetting there's really no precedence.)
(PS. Sorry for the delayed response -- was away for a while.)
Re:Yuck. (Score:1)
Covariant return types instead of full Generics (Score:3, Insightful)
overall, I'd rather have this than nothing...
Re:Covariant return types instead of full Generics (Score:1)
public class Sub {
public void Object clone() {
}
so when you call
Sub s =
Sub s2;
s2 = s.clone();
you get a compile error. Ugh.
Covariant return types aren't a feature, lack of them is a bug.
Re:Covariant return types instead of full Generics (Score:1)
mmmm perlish... (Score:1)
}
foreach $c (@i) {
#blah blah blah
}
I can't wait! Next thing I want:
System.out.println("YES!") if (a==b);
Re:mmmm perlish... (Score:1)
# blah blah blah
Seems to be nicer than both examples you gave
Re:mmmm perlish... (Score:1)
for @i -> $c { print "$c\n" }
Re:mmmm perlish... (Score:1)
System.out.println("YES!") if (a==b);
if (that==pointless) System.out.println("forget it");
Re:mmmm perlish... (Score:1)
a == b or die "a is broken";
JSR 201 (Score:1, Informative)
http://jcp.org/en/jsr/detail?id=201
GCJ (Score:1)
Re:GCJ (Score:1)
The Eclipse live compiler is related to Jikes [freeroller.net].
What's wrong with a while loop? (Score:3, Informative)
Iterator i = obj.iterator();
while (i.hasNext()) {
}
If you need a count, then add it at the top or bottom (depending on need) -- This just seems like syntactic sugar gone awry.
Re:What's wrong with a while loop? (Score:1)
"enhanced" loop.
In general, these changes may offer limited benefits but will make the code harder to read,
harder to maintain, and in the end, may hurt Java more than they help. I had *prayed* that we would never have to deal with templates/generics in Java. But sadly:
Re:What's wrong with a while loop? (Score:2, Informative)
The problem is that i is outside the scope of the loop. However, it is only needed within the loop. If you don't have any other loops in the vicinity, then you are okay, but consider this:
Iterator i = obj.iterator(); ...
... ...
while (i.hasNext()) {
}
Iterator i = obj.iterator();
while (i.hasNext()) {
}
Whoops, this doesn't compile. There's a few ways out of this:
Iterator i = obj.iterator(); ...
... ...
while (i.hasNext()) {
}
i = obj.iterator();
while (i.hasNext()) {
}
The problem with this is that if you delete the first loop, you have the remember to change the second loop. (This is why reusing variables to do different things is not a good idea.) Here's another approach:
Iterator i = obj.iterator(); ...
... ...
while (i.hasNext()) {
}
Iterator i2 = obj.iterator();
while (i2.hasNext()) {
}
The problem with this is that you might forget to change all references from i to i2. Now consider the "standard" solution:
for(Iterator i = obj.iterator(); i.hasNext();) { ...
... ...
}
for(Iterator i = obj.iterator(); i.hasNext();) {
}
Here, each Iterator is in its own scope and you can easily refactor one loop without dealing with the other.
Is Java becomming a good scripting language? (Score:1)
Generics make sense, and they look a lot easier than C++ templates.
The new for construct, also make a lot sense (very python like).
As well as the new auto boxing feature. (Why should I have to worry about this..... let the compiler do the work for me!)
My opinion is that if the compiler can figure it out, then why bother me with it.
Make the compiler smarter so I have to type less.
Less code that I write means less code I have to maintain!
Back before Java became popular, I was a C++ bigot. I programmed in nothing but C++. I lived, ate and breathed C++. If it wasn't C++, it was rubbish. I thought C++ was the alpha and omega of object-oriented programming. I had "operator overloading" for breakfast, "templates" for lunch and "multiple inheritance" for dinner, and I always went back for seconds.
Then a funny thing happened. I got a new job at another company as a C++ programmer. But they pulled the old bait and switch. Once I started working, someone suggested writing a good portion of a large project in a scripting language. I protested - I would not condescend to program in any other language but C++.
Shortly after I started at this new company the following edict was put forth: "Thou shall use a scripting language." Thus I was forced by management to write a good portion of the project in a high-level scripting language. They told us to glue components written in C++ together with this scripting language (in addition to writing components in C++). At first I hated it, as any self-respecting C++ bigot would. Then, gradually, the productivity of my team - and me - skyrocketed!
The higher level you can make Java, the more productive it will be. These features they are adding make so much sense to me.
I hate purity for the sake of purity. I dogmatically dislike development dogma. Life is full of compromises. There is no pure Java langauge... Let Java grow! Let it become higher level. Heck, there are a few features from Ruby that I'd like to see Java adopt.
I am not saying that Java should one day be like Perl. I think things have to be added judiciously, but let the language evolve!