As I said, look at perl, joncfoo. The thinking "It's just syntactic sugar, what harm could it do" isn't the proper mindset when evaluating new languages. These are the problems all language changes must face, syntax sugar or no:
1 - complexity It would be nice if the language spec is grokkable by your average programmer. It should basically never be that a programmer that's used a language for quite a while, gets surprised by a rarely used feature. Java certainly has its evils in this regard (few people know what 'strictfp' does, for example, and many people don't know about instance initializers). The problem with adding syntax sugar for so many things is that at some point you'll get features that are no longer very useful, but, because they were language additions (and not library additions), there isn't a way to get them out of the language at some point. C# is -far- worse at this, where even a seasoned C# programmer can easily be surprised. A 'C# puzzlers' book, if anyone would make one, would probably come in 26 volumes and take up half a bookshelf. 2 - parseability People make syntax errors. It happens. Sometimes it really is a typo, other times a programmer doesn't remember a certain syntax correctly and writes something slightly different. The more different valid expression forms a language has, the lower the distance between any two different but legal code representations, which is bad for when people make typos. Let me elaborate: If you typo (or otherwise screw up), the compiler will basically attempt to figure out what you might have meant. It does this by finding something that would be legal and that is a lot like what you wrote. Certain syntax suggestions that tend to be advocated for with the usual 'it's just syntax sugar, what could happen?' arguments will make this task harder. It then becomes feasible for a typo to get ambiguous error messages (because the compiler can't figure out which of many possibly interpretations that are syntactically close to what you typed was meant). Or, possibly, even the situation where a syntax error results in valid code anyway, but code that doesn't do what you think its supposed to. In addition to this, though this is far less important, javac is based on an LL(1) parser architecture with context-free keywords. This can be changed, but if you do so, it'll take a long time for all the various java source reading tools out there to adapt to such a massive change (you'd essentially force a complete refactor to every tool out there that reads java code). The temporary fragmentation and bad blood is a cost. It's a relatively minor one in the larger scheme of things, but its a cost nonetheless, and it could easily tilt the scales against a syntax sugar proposal. Also, C#, and Casper Bang, are great proponents of context sensitive keywords: The idea that a certain identifier is a keyword in some contexts, but not in others. Java currently does not have context sensitive keywords - any keyword that java has, is always a keyword. For example, even though the parser could easily support using the word 'import' as a variable name (because import statements are only legal at the very top of a file, only a package statement and comments are allowed to precede it) it would be absolutely no problem for the parser to stop considering 'import' a keyword the moment it hits the first non-import/package/comment in a java file. However, there is a significant cost associated with making your keywords context sensitive: It obscures the meaning of code snippets, is very hard on syntax colouring editors (full blown IDEs can handle it, but stuff like jedit and emacs can't, and screwing over java coders who use those editors is a cost, and that's what this post is about, really: You 'it's just syntax sugar, java is sooo slow and bureaucratic and stoopid!' folks act as if there aren't any). Without context sensitivity, keywords are also great anchors for the parser. If it sees 'public' for example, the parser knows a great deal about what the code was meant to be at. (It knows that you aren't inside a method body anymore). This allows the parser to be at least semi-sensible when you omit a closing brace in a for loop for example. 3 - comprehensiveness Oftentimes a language change isn't hard for the parser, doesn't break backwards compatibility, and is very simple to understand. It still might not be a slam dunk if the language change takes the language into a direction that either isn't envisioned by the language stewards, or is actively clashing with how the language is supposed to work. This often boils down to political, vehement flamewars. Anything that results in so much flame is all by itself a big reason to just leave it be for now - again, there's a cost involved in riling up the community, even if you strongly feel the language change is 'right'. For example, there is some discussion in allowing you to omit the type entirely when declaring a method-local variable final. So: final foo = "foobar"; //legal, and 'foo' is of type String. This is easy to understand (low complexity), perfectly backwards compatible, relatively hard for the parser to get confused about, but some consider this anti-thetical to java's adherence to a 'manifest nominal typing system'. The problem with adopting this change is thus solely if the community even wants it. 4 - Utility - a.k.a. gets in the way of future expansion Because of all previous arguments, the ease at which you can add a new language feature to a language is inversely proportional to the current complexity of that language. Every language feature you add now makes it harder to add new ones later on. For example, the only easily typeable symbols that have no meaning whatsoever in java code are: the backtick and the hash. If for example FCM (First Class Methods - a closure proposal) is added to java7 or java8, the hash is no longer usable. That means that a future proposal to add something entirely different, say, properties, can no longer use the hash as an easy marking device that couldn't possibly confuse the parser and is entirely backwards compatible. Therefore, even if a syntax sugar proposal is backwards compatible, doesn't add much complexity, fits with the language (comprehensive), and is easy to add to the parser, that STILL isn't a good enough reason to add it. The addition needs to meet a minimum treshold of utility before it should be considered. Post saved for the future because I just know Casper Bang is going to ignore it all over again the next time he suggests java should adopt more language changes. On Feb 7, 2:17 am, joncfoo <jonc...@gmail.com> wrote: > What's wrong with syntactic sugar and how is it holding it back? The > properties that C# sports are simple, concise, and easy on the eyes. > Why isn't the Java language picking up at least these basic features? > > On Feb 6, 1:16 pm, Reinier Zwitserloot <reini...@gmail.com> wrote: > > > "It is just syntactic sugar" gets you perl. > > > That's what's holding it back. > > > On Feb 6, 7:24 pm, joncfoo <jonc...@gmail.com> wrote: > > > > Regarding properties: > > > What is holding them back from implementing properties like they are > > > in C# since it could be implemented as syntactic sugar. > > > > Plenty of examples > > > here:http://www.csharp-station.com/Tutorials/Lesson10.aspx > > > > It would be nice to traverse large object graphs w/o having the ugly > > > getters. > > > > E.g. > > > > // before > > > obj1.getObject2().getObject3().getObject4().setSomeProperty(1234); > > > > // after > > > obj1.object2.object3.object4.someProperty = 1234; > > > > It is just syntactic sugar... > > > > Jonathan > > > > On Feb 5, 9:47 pm, Bill Robertson <billrobertso...@gmail.com> wrote: > > > > > On Feb 4, 11:58 am, gafter <neal.gaf...@gmail.com> wrote: > > > > > > Although I believe the syntax is not ideal in its current form, I'm > > > > > not going to spend more time on it until Sun formally decides they > > > > > want to move forward with it, and that's not going to happen in JDK7. > > > > > I certainly understand that position, but I think its worth > > > > considering syntax, even if only in a passive manner (i.e. just think > > > > about it). I've been dealing with C++ recently, and man oh man* I > > > > forgot what a pain that was after not having touched it in so long. > > > > Generics nudged Java syntax in this direction, and the little bits and > > > > bobs of closure syntax that I've seen so far (no specific proposal > > > > mind you), have left me with that same feeling. I hate to try to > > > > suggest answers when I don't believe I have good ones, but I also hate > > > > to just complain w/o offering suggestions. So I would like to offer > > > > up the suggestion of considering keywords rather than oddball > > > > symbols. e.g. lambda v.s. => > > > > > Thanks. > > > > > *Not to be confused with, "OhmanOh Man," a lesser known super hero. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
