RatJava
Old Fortran weenies like me still remember with fondness (or loathing) RatFor. For those who don’t remember Fortran, you have to understand that it was the first compiled programming language. Consequently it made a lot of mistakes and had major design flaws. For instance, you couldn’t put anything except a line number or a comment marker in the first six characters of each line. That was a relic of its design for punched cards. (Remember those? Probably not if you’re under 40.) These design flaws weren’t trivial or academic problems. Spaceships could crash when you replaced a comma with a period, though the program would still compile.
RatFor was a 1970s era effort to clean up the language. It was an alternate syntax designed around the then hot-idea of structured programming. (OOP hadn’t escaped academia yet.) For instance, it added while loops and got rid of GOTO. It cleaned up the syntax by letting you write >= instead of .GE.. (Some of the early computers that Fortran ran on didn’t have lower case letters, much less angle brackets in their native character sets.) However, RatFor was compiled (more accurately preprocessed) to standard Fortran code, after which it used the same optimizers and libraries that standard Fortran did. That meant it was fully interoperable and could play in a world where not everyone was rational.
Fortran’s not the only language where this happens. For instance, JRuby is a way of writing Java code the Java VM in Ruby. That’s great if you like Ruby, but what if you actually like Java and just want to make it a little more rational? Well, as it so happens I just got an invitation to a Sun event on Monday where I expect Sun to finally pull the trigger and open source Java. Great. Let’s fork!
Well, not quite; but maybe we can finally clean up some of the little annoyances in the Java language, while still maintaining full compatibility with the Java VM and Java libraries; simply by making a few modifications to javac. (Of course, if I was really on the ball I would have suggested doing this with jikes years ago.)
Now remember. What follows are purely syntax sugar changes. We’re not going to change the libraries, and we’re not going to change the VM. We’re going to compile to real Java byte code that’s fully interoperable with existing programs without adding any extra classes that aren’t part of the standard library. That severely limits what we can do. Nonetheless there are some interesting possibilities here.
No semicolons
Why put semicolons at the end of every line? How many statements do you actually write that extend across multiple lines. Wouldn’t it make sense to make the unusual case (a multiline statement) require the special character? I suggest a backslash.
Downside: this will be tricky to integrate with for loops
Require braces for multiline statements
Smart developers have known for years that braceless multiline statements are bug prone. The problem is that the indentation can be actively misleading and cause bugs during code evolution and maintenance. For example, suppose you start with this if statement:
if (x > 3)
doSomething(x);
// continue with rest of program...The problem is sooner or later you or someone else is going to need add a line to that if statement, and you’ll end up with something like this:
if (x > 3)
y = x - 3;
doSomething(x);
More often that you’d think, they forget to add the braces. The code will still compile, and on some paths it may even work correctly, but there’s a real bug here and it’s one that’s hard to spot because the indentation is actively contrary to what the code is really doing.
In fact, this was known well before Java was invented, including inside Sun. Consequently, it’s a bit of a shock that Java still allows this. It’s time to get rid of these.
switch-case statements
Have you ever written a switch statement that didn’t break after every case? I mean, one that wasn’t a bug? I actually have, but only when returning from each case. In practice, almost every other kind of breakless case is a bug, and those that aren’t are confusing. In particular, any algorithm that depends on case fall through is very surprising and hard to understand. Let’s make breaking after each case the default.
switch types
The switch statement is also too closely tied to the underlying representation. Because it compiles to one of two types of byte code instructions, it can only switch on ints or types castable to int. But why? Very often I find myself writing a big if–else block like this one just to pull out one case from a String, or other non-int type:
if (s.equals("foo")) {
//...
}
else if (s.equals("bar") {
//...
}
else if (s.equals("baz") {
//...
}
else if (s.equals("yum") {
//...
}
else {
//...
}This could be more obviously written as a switch statement. We’d just need to recognize the different type, and compile it to different byte code instructions.
Ban tabs
Tab characters are evil. They consistently much up source code and make it look awful as it’s moved from platform to platform, machine to machine, editor to editor, and even from editor to printer. They are a technology designed for typewriters. Is it any surprise they cause problems for computers?
The solution’s simple: forbid them. Any tab character appearing in a RatJava file will be a syntax error.
Multiline string literals
One of the most annoying things about writing HTML and XML code from a Java program is the constant need to use \n and + to create multiline string literals. For example, here’s a chunk of code that writes some HTML:
out.write("<html>\n");
out.write("<head>\n");
out.write("<title>Mesathelioma</title>\n");
out.write("</head><body>\n");
out.write("<h1>Mesathelioma</h1>\n");
Let’s write it like this instead:
out.write("<html>
<head>
<title>Mesathelioma</title>
</head>
<body>
<h1>Mesathelioma</h1>";
Much cleaner. Much simpler. Much easier to read and maintain.
Make final the default
As John Ousterhout wrote in 1998:
Implementation inheritance causes the same intertwining and brittleness that have been observed when goto statements are overused. As a result, OO systems often suffer from complexity and lack of reuse.
Inheritance is a powerful tool, but it takes extra work. Most estimates are that it takes about three times as much work to design a class for inheritance as one that’s not extensible. It requires a lot more thought and a lot more documentation as to exactly what subclasses can and cannot change. Given that most programmers don’t ever think about inheritance when designing classes, extensibility shouldn’t be the default.
Methods should only be allowed to be overridden if explicitly marked as such. This would indicate that the class designer has thought about what it means to override that method, and explicitly chosen to allow it.
Make UTF-8 the default and only encoding
In 2006, there’s little-to-no reason to choose any other encoding besides UTF-8. I’ve previously explained why this is true in the context of XML. However, unlike XML, Java doesn’t have embedded encoding identifiers. That makes it even more important to pick a standard encoding and stick to it. UTF-8 is the only sensible choice.
Anyway, that’s my fork plan. What do you want to change?
November 13th, 2006 at 2:30 pm
You’ll take away my hard tabs over my cold, dead copy of the “ex” editor.
I think multiline strings are too error-prone. I’d rather have XML literals (compiled into code that sets up XOM objects, probably through a factory interface) instead.
I think you will get howls from everywhere outside North America (and some places inside) if you don’t allow native encodings as well as UTF-8.
Otherwise it all sounds good, if a bit too conservative. “Make no little plans; they have no power to fire men’s blood.”
November 13th, 2006 at 3:33 pm
It’s easy to come up with lots of really useful Java “skins”:
1) defaults of “final” and “private”
2) simple closures
3) explicit boxing
4) array notation for maps and lists
5) operator overloading
6) property support
7) mathematical notation
8) scientific notation (units)
9) financial notation (currency)
10) keywords in other languages
11) EVIL instead of tab
http://groups.google.com/group/javaposse/browse_frm/thread/38f92a3dd7eb2b01/0cd8c5552c4b0951?lnk=gst&q=theta&rnum=1&hl=en#0cd8c5552c4b0951
November 13th, 2006 at 4:32 pm
Your string switch is typoed:
if (s.equals(“foo”) {
…
}
needs a second close parenthesis after the “foo”. Unfortunately, this switch on a command string really should be done using something like a Map. It’s too bad that building simple operator objects is so clumsy in Java:
Map commands = new HashMap();
commands.put(“foo”, new FooCommand());
commands.put(“bar”, new BarCommand());
…
// Later…
commands.get(commandString).execute();
November 13th, 2006 at 4:48 pm
Consider toolset compatability. Put in some kind of a header so that it’s easy for tools to recongnize which version of Java is being used.
I think you’re going to get a lot of pushback on tabs versus spaces, just from the experiance of the Python community where significant indentation makes it a much more sensitive issue. The plan for Python 3.0 (as far as I understand it) is for the compiler to accept one or the other, but not both in the same file. That fixes the indentation problem in a way that doesn’t raise quite so many screams of rage.
I like multi-line strings, but your example doesn’t hack it. Consider how Python does it: two strings in a row are concatinated by the compiler without the need for an operator. There’s also a special pair of brackets that encloses a multi-line string.
John Roth
November 13th, 2006 at 4:55 pm
Now, now: I’m not even 39 and even *I* can remember punch cards, ol’ timer. Mom used to bring them home from work and we’d color on the backs! 😉
Amen to the curly-braces, though! We just had that issue over the weekend while I was trying to debug someone else’s code. (I was thoroughly brainwashed in school, the other developer is self-taught.)
November 13th, 2006 at 10:57 pm
Semicolons: Semis actually make parsing a heckuvalot easier. Without semis, you have to make all sorts of ugly guesses for multiline statements, like ensuring that the + comes on the first line of a break, not the second. The backslash…maybe. It kinda smells.
Multiline strings: They’re not bad…maybe the backslash should be used here? It’s already used to escape special characters…why not newlines (like for shell scripts and the like)?
Braces required: GOOD. I make this official policy all the time. I would be willing to bend if there was the capability of using Ruby’s statement modifiers, as in “do something if (x == 5);” which is much more explicit than the single-line if we have now.
switch with no fallthrough: probably good…I have a tendency to use it, though I probably shouldn’t.
switch on other types: there certainly could be a “slow switch” that allows switching on other types, but the primary point of a switch is that it’s using numeric types to create a fast jump table.
Tabs out: GOOD
Final by default: C# went that way…but I think they’re wrong. I think we should be trending toward languages that are MORE open, not less. We need to trust our programmers rather than rap them on the knuckles 50 times in a day for doing the wrong thing.
I’m also very interested in adding dynlang capabilities, but that’s outside the scope of this discussion 🙂
November 14th, 2006 at 7:13 am
I would include the possibility to reference methods and fields, e.g as in javadoc
Method sizeMethod = ArrayList#size();
Today many frameworks using reflection and often in testcases we need access to fields. It is anoying to go through String names which cannot refactored easy and cannot expanded by IDE.
November 14th, 2006 at 8:13 am
Instead of multi-line string literals as the default, how about literals as currently used in Java plus extra support for “here documents” as in Perl, bash etc.
November 14th, 2006 at 9:18 am
I hate NullPointerException, so a “nonnull” keyword would be nice for variables, parameters and return signatures.
November 14th, 2006 at 9:37 am
There’s a JSR (305) for adding a non null annotation (@NonNull) that seems to do the trick;
http://jcp.org/en/jsr/detail?id=305
November 14th, 2006 at 10:09 am
Semicolons are fine in my book. They give you a visual clue that a statement has ended. I’m ok with that.
No TABs? I think this problem was solved once and for all with Ctrl-Shift-F on Eclipse platforms (and a similar keystroke on Netbeans).
I’d like to see methods being treated as first-class-citizens.
It would be nice if you could reference them with a special syntax and, for example, use them wherever an interface type is needed. Behind the scenes an interface adapter is created which delegates the interface methods to the given method. This could work out-of-the-box for interfaces with one defined method.
This change would simplify various code segments:
button.addActionListener(this.getClass().okPressed(ActionEvent)); which would translate to button.addActionListener(new ActionListeners() { public void actionPerformed(ActionEvent ae) { this.okPressed(ae); } }); // or a generic helper class in side com.sun.Proposed Syntax for addressing methods:
.getClass().(*)
Other uses:
new Thread(this.getClass().runIt()).start();
instead of
new Thead(new Runnable() { public void run() { runIt(); }}).start();
November 14th, 2006 at 10:13 am
Darn, all my > and < have been stripped away.
Proposed syntax was:
[reference].getClass().([Formal parameters]*)
November 14th, 2006 at 10:40 am
Spaceships could crash when you replaced a comma with a period:
How about an overloaded function which takes one or two parameters?
Complex f = new Complex(3.14159);
Complex f = new Complex(3,14159);
First creates a complex with a zero imaginary part as the author
probably intended. Second creates a rather unlikely complex number.
Easy mistake for a non-English European language speaker to make.
Maybe RatJava should insist on a space after commas as list
separators.
November 14th, 2006 at 10:41 am
Require braces for multiline statements:
I’d rather get rid of all braces and rely on the indentation to
indicate the structure. As you point out, the indentation is a
very strong cue to the program structure. Braces are just
clutter – something Java’s not entirely short of.
My concern with this is the muddle over the size of tabs, 4 or
8 positions or whatever. (Personally, I think the tab size
should be a parameter to the text MIME types, like the character
encoding but that’s another discussion). Then you go on to
ban tabs, so that’s OK.
November 14th, 2006 at 1:52 pm
Anybody download javac yet?
Compiles fairly quick, which was surprising to me. Here’s a tutorial to get it to build easily from netbeans;
http://nb-openjdk.netbeans.org/get-and-build.html
I also tried compiling it with make under cygwin, but that’s not working for me. Ant works of course.
November 14th, 2006 at 6:18 pm
I love these discussions – it’s amazing how if many of them were implemented (one statement per line as default), lose braces, switch on non integral data types then you’ve reinvented Visual Basic!
November 15th, 2006 at 8:49 am
1) In a heartbeat, introduce a new primitive type… date! Java has long ignored the foul-up that is the Calendar object for too long. In the interim I’d fix both Date and Calendar, they are both responsible for many heartaches (though I’ll acknowledge sometimes introduced by junior programmers)
2) Fix generics. Type Erasure is nice and all, but you do need its meta information in the class file.
November 16th, 2006 at 5:15 am
Sorry Franky, your first suggestion breaks the rules: “What follows are purely syntax sugar changes. We’re not going to change the libraries, and we’re not going to change the VM.”
OTOH, yes; Java date handling is a complete catastrophe and desperately needs fixing.
November 16th, 2006 at 6:58 am
Some zillion years ago I implemented a primitive type “complex” …
by just working on the compiler side. So, something similiar might
be possible with “date”.
go and see
http://www.ipd.uka.de/JavaParty/cj/
wow, the web site is still there …
November 19th, 2006 at 5:54 pm
The
delegate/eventkeywords in C# do just this (the compiler generates a full-blown Observer designpattern underneath). It’s a nice feature; basically a compiler-checked function pointer.I’d definately like to have multiline strings.
Date/time maths is way too complex for a primitive type (by that I mean there are far more desirable operations than there are operators). Besides, why re-invent the wheel? Joda-Time is truly excellent and could be made a mandatory replacement for the java.util.Calendar mess. Java would instantly go from having one of the worst date/time libraries in computing, to having one of the best.
November 23rd, 2006 at 10:25 am
Getting rid of semicolons good. Why not braces too? This is one case where Python makes an awful lot of sense.
November 23rd, 2006 at 10:48 am
The real good thing about open sourcing java is that now everyone can roll their own and will hopefully not trigger Sun anymore to pollute a clean design with mostly bad ideas like these.
November 23rd, 2006 at 11:02 am
What would the EOL character for multiline strings be? \\r ? \\n ? \\r\\n ? Why? I’d rather see the EOL character explicitly.
wrt final: That would make creating mock objects for testing much harder! See http://blogs.objectmentor.com/ArticleS.MichaelFeathers.ItsTimeToDeprecateFinal
November 23rd, 2006 at 1:22 pm
It’s funny but I actually disagree with every single one of the your points, except two. It’s funnier still because I agree Java could use cleanup as you mention. My objections to your suggestions are as follows:
1) While multi-line Java statements are the exception to the rule, I hate the *nix style of placing slashes at the end of a line to mean it spans to the next line. They simply make the code harder to read. I feel semicolons are actually the lesser evil here.
2) People who require braces for one-line for statements and other one-liners piss me off 🙂 If you use an IDE (and most people do) there is absolutely no way you will make this mistake because IDEs provide code auto-format and brace matching to avoid this very problem. Requiring braces reduces readability in my view. If you really want to fix this problem on the compiler level, force users to indent for single-line for statements.
3) Making “break” default for switch statements… I actually agree with this point.
4) switch types… I agree with this point.
5) I disagree with baning tabs because many people on my team use indentation of size 4 and some even of size 8 which makes it impossible for me to read. If we were forced to use spaces we’d all have to agree on a single value. If, on the other hand, we all use tabs, each one of us can map the tab to a different number of spaces. If anything the problem with tabs is that most editors default to an indent of 8 which is just insane.
6) Multi-line string literals seem nice on the surface but I bet you will run into silly problems whereby you have an invisible character at the end of a line which gets sent to the screen or file and you won’t notice it because you don’t have a quote delimiting the end of the line. Still, I would agree with this suggestion if IDEs make sure to highlight invisible characters at the end of each line for a multiline string (to avoid the aforementioned problem).
7) I disagree that extensibility shouldn’t be the default. If anything I hate having to ask the original developer for permission to extend a given method because the turn-around time between my request and his next release usually ranges into months. I think making extensibility the default is the lesser evil here. Making final the default makes a lot of sense if you’re developing an operating system or a JDK where you absolutely cannot break backwards compatibility, but the vast majority of programmers simply do not work on such mammoth projects so why the exception to the rule the default behavior?
8) Making UTF-8 the default is a baaaaaaaaaaaaaaaaaaaad idea. Why? Ever share code with a Japanese or Indian team? There is nothing worse than variables names and comments written in characters you can’t even type on your keyboard! It is just insane 🙂 Readability goes right out the window.
November 23rd, 2006 at 2:23 pm
Require braces: Argh! I’ll rather copy Haskell and Python, where indentation == scope, and braces are never required. It’s more elegant, much cleaner, and forces developers to take care with formatting and indentation. Besides, modern IDEs/editors are so good in automating and validating code that you gotta be a vi/notepad-diehard to make the kinds of mistakes that are prevented by mandatory braces.
Banning tabs: Disagree too. Tabs are great because they make indentation flexible. I like indentation to be 4 spaces, I hate it both shorter (messes up code) or longer (wastes spaces, I don’t have a 30″ monitor). With tabs I can see the code they way I like it, and all other developers in my team too. Indenting with spaces produces either a mess (each developer uses his preferred spacing) or dictatorship (the team leader mandates the size he likes). The arguments against tabs are also a relic from the era of primitive code editors. BTW, I wrote a simple but very neat utility that processes any text file and fixes its usage of tabs, forcing use of tabs at indentation positions (before first non-blank) but forbiding tabs elsewhere (after first non-blank). I’m trying to find some time to convert this into plugins for NetBeans and Eclipse, since none of the auto-formatters out there (including IDEs’ and even Jalopy) does exactly what I want.
November 24th, 2006 at 2:50 am
Isn’t it nice to know that now we can play with Java we can all have some fun changing the language to suite our personal tastes.
It’s funny but I actually disagree with every single one of the your points, except two. It’s funnier still because I agree Java could use cleanup as you mention. My objections to your suggestions are as follows:
1) The multi-line suggestion is interesting and while Charles has pointed out that this would make the job of the compiler more difficult…. I don’t really care all that much. On code readability I’m just not convinced that it would help all that much. The detractor is that just as the semi-colon is helpful to the compiler, it is just as helpful to the reader and that I do care about.
2) I’m neutral on the brace issue. I personally don’t add them but when I do add stuff to an if statement I automatically add braces so it doesn’t seem like it should be that big a deal. However going to an indentation scheme sounds both interesting and potentially fragile. Maybe a nice one to experiement with.
3) Making “break†default for switch statements… I think you’d want to do a code survey to see what the usual case is. If the majority of case statements end with break than +1 and lets add a fallthrough keyword. Otherwise -1.
4) Switch and if are functional replacements for polymorphisum. We need to use them in Java because we have functional artifacts left-over from the C crowd (that couldn’t live without them for some unknown reason ;-)). The suggestion is; if you are finding a need for switch when using objects than there is most likely some polymorphic behavior that you’ve missed out on in your design. Unfortunately Swing forces this if (action.equals(“somestring”)) …. type of coding on you and if you really look at it, there could be a more effective use of polymorphisum (in most cases using a double dispatch) to ease the pain. Just as it was a much better solution to educate rather than continue to teach people how to use goto, it would be much better to educate with better design patterns than continue to teach people how to use switch (and to a lessor degree if-then-else).
5) Tabs are a pain and lets face it, a relic of typewritters. Unless I’m word processing….. I don’t want to see them cos yeah.. sometimes I do perform quick edits in VI.
6) Multi-line string literals seem ok.
7) I echo the view of others that extensibility shouldn’t be the default. In fact I would argue that you could have your UTF-8 Strings and other implementations of String very very easily if java.lang.String wasn’t final. In this regards, the use of private is also damaging. IMHO protected should be the default and I’d almost consider removing the keyword final from the langauge. Things should be extensible and to use final and private for purposes of preventing others from extending is simply mothering.
Some changes that I’d like to see. Autoboxing is either confusing (your code does unexpected things) or broken (eg == may or may not work as expected depending on which numbers you are using and we don’t have a reverse mapping from or 0 and null). Lets get rid of it. Smalltalk uses something known as immediate direct objects. These things look like objects in the langauge but are actually compiled to primitives. This goes a long way to normalizing and simplfying the language. It is also a great example of how information hiding allows us to easily change the implementation. You can’t overflow a number in Smalltalk because one it does get to big, the primitive gets replaced with the equivelent of a BigInteger (mutable of course). For those that may consider this to be a potential performance problem, I will always argue for correctness over performance. In this case I would argue that it is actually helpful to performance as it allows the underlying system to choose the most appropriate type for me. Currently I am forced to use BigInteger if I’m worried about overflow *even if it doesn’t occur*.
Isn’t it odd how are different programming backgrounds have left us wanting those things that we are familiar with put into Java wither or not they belong.
November 24th, 2006 at 3:36 am
Just a thought:
Why not building Python 3000 on top of the JVM? Why not starting a debate with the Python-community about that? If Python 3000 will use the JVM instead of its own Python-VM there would be an alternative program-language that has lots of the demanded features that Java (TM) should have.
November 24th, 2006 at 7:22 am
you mean: ignore the culture of millions of programmers and force them to re-learn to type. I guess it could become a TYPO festival :))
November 24th, 2006 at 7:47 am
Some I agree with (require braces) and some I don’t (no semicolons, final by default).
Switch on Strings may be gaining ground (Josh Bloch mentioned it recently). It can be achieved efficiently too by a compiler. The human codes a switch based on strings, the compiler creates an int-based bytecode switch based on the hashCode of the strings. Simple and fast. But requires that the strings are constants (which seems reasonable).
Multiline string literals are better with a dedicated syntax:
String multiline = “””
first line
second line
“””;
November 26th, 2006 at 5:52 pm
I have made a blog entry about multi-line string literals:
http://peter-reilly.blogspot.com/2006/11/multiline-strings-in-java-part-2.html
To sum up.
python’s multiline “”” and raw string handling is great and it
is *very* *very* easy to add this to javac. – the diff file
is only 205 lines long.
November 26th, 2006 at 11:38 pm
This could be an interesting project as a full pre-processor for Java. As many people have mentioned, I like some of your suggestions, and dislike others.
As far as implementation, it may be possible to define certain preprocessing steps that would be used by a custom javac. For example, I may like muti-line literals, but not the lack of semi-colons. So, I could have a javac.properties file (or something) that would define what syntactic-sugar I want. The default would be to have nothing different from main-line java.
I like the idea of multi-line strings, but I agree with Stephen Colebourne above that multi-line string should have their own syntax. For example, C# uses @”multi-line
string
goes here”;
The only downside to this type of project is the lack of support you’d get from IDE’s that are so important in the java world… but it would be nice to see some sort of “blessed” preprocessing.
November 27th, 2006 at 3:25 pm
>> Require braces for multiline statements
OMG…absolutely!! People that are too lazy to put a brace for a single line block after a control structure or at least set up their IDE to automatically put one in annoy the hell out of me.
As soon as you don’t put that brace at some point in the future a bug will occur because someone won’t notice that they need to add one when they add to the code.
I actually have IntelliJ setup so it will add the braces around a single line block after a control structure during a code reformat…so a ctrl-alt-l defeats all the evil doers that didn’t add them originally!
November 28th, 2006 at 4:52 am
I agree with some statements, not with others, of course…
– I often break my lines in two or more, because I like (and people at my job too…) long identifiers, but I don’t like having lines longer than 80 chars (or make it 120, 132, whatever).
– I have the personal policy to add almost systematically braces, although sometime I omit them when I do a simple break or return. But sometime I regret these exceptions (adding debug code, for example…).
– switch: I find it obsolete… It was good in C times were it was optimized by compilers, but it is probably not very useful in other languages. I mean, as somebody else pointed out, your switch type example calls for replacing it with a Map or similar structure. Of course, having functions (or methods) as first class citizens would help a lot, and would avoid aberrations like anonymous classes.
Beside, even if I agree that break being more often used, it should be the default, you forgot a quite common case of fall-through: case ‘A’: case ‘B’: case ‘C’: doSomething(); break;
In a redesign of a switch, one should extend the syntax to multiple values (as in Pascal): case ‘A’, ‘B’, ‘C’: and case ‘A’-‘Z’:
– Tabs. I disagree, I use only them, except at job where they chose spaces (by 3). Spaces are prone to error (if people type them all (!), they can miscount them). And I find annoying to have to move space by space where I can skip n char pos at once. And as somebody else pointed out, they are far more flexible.
The worse case is the mix of tabs and spaces, of course (a tab to skip 8 chars, 4 spaces otherwise…).
– Multiline strings: agree, the best syntax is Perl’s Here-Doc (also used in PHP). No ambiguity with regular strings.
Strings are a kludge in Java: that’s a class with special status, the only one allowed to overload an operator, but in a shy way: why didn’t they overloaded the ==, instead of using the ugly equals? At least for the most common case of case-sensitive comparison.
And the choice of \ as escape char is an horror when writing Windows paths (OK, should avoid it…) and regular expressions! At least, when designing the latest, they could have replaced backslash with another symbol.
– UTF-8: I agree that’s a more sensible choice than UTF-16.
November 28th, 2006 at 4:54 pm
Elliotte – some quick comments
1)I love it!!! – especially the multi-line strings. This is by far my biggest pet peeve w/ the Java syntax. Creating long string literals in java feels like I’m trudging through mud.
2)I’m all for UTF-8, But let’s actually *use* unicode. Take multi-line strings for example. Why not delimit them w/ the  ¶Pilcrow Sign (aka “paragraph” symbol). That would be more succinct and also save programmers from escaping double quotes all the time.
That’s just the tip of the iceberg. How about using the actual math glyphs instead of the operator literals we use now? Or using the box-printing characters for formatting comments? There’s tons of opportunities to improve readability by using symbols that are more descriptive and tie to real-world concepts.
November 28th, 2006 at 7:55 pm
[…] I have a number of pet peeves that I wish sun would just put straight into java, and a couple of others that can’t easily be done because they’d break backwards compatibility. Certainly not enough to warrant a fork, but while we’re procrastinating, let’s certainly NOT implement the ideas set forth here. […]
December 1st, 2006 at 5:20 pm
I want OUT params.
December 4th, 2006 at 1:25 pm
[RANT ON]
I say fork Java and it can’t happen soon enough, listed in order of least horriblility:
The VM:
Since the JVM is now a multi-language thing, lets call it VM. In general it has gotten up to a good speed by now, but it is still a memmory hawk beyond anything else in the industry. SUN must have half a dusin marketing departments, consistancy please, now you adopted JSE 6.0 do not refer to it as java.version 1.6.0 – and no, you can not call it Java 2.
The Syntax:
As proposed by this blog entry, there are so many nifty things that could be done by thinking a little rather than copying the construct from C++. A lot less verbosity thanks, and more dynamic/flexible such that we can program into the language (idioms), not just on the language (patterns).
The API:
By far the worst. Date is broken, Calandar which was suppose to fix this is also broken and so are 100+ more general purpose classes. There’s really too much wrong here that I get a headache from thinking about it.
[/RANT ON]
December 14th, 2006 at 10:00 am
Sometimes I want to handle a few exceptions the same way, so I would like this syntax added:
try {
blah
}
catch(ThisException, ThatException, MyException, YourException as Exception){
blah;
}
catch(Exception e) {
}
January 3rd, 2007 at 7:16 am
I agree with:
1. Multi-line string literals. What is the problem with implementing “if you find an unescaped-double-quote-character then everything up to the next unescaped-double-quote-character is one String literal”? Graphical IDEs will color the text appropriately so that you can see what is in your string literal.
2. Allowing any Object to work as a switch case. There could be two variants:
a) the current int-based version for ints and enums, and
b) a generified Object-based version using equals for Objects.
3. Making “final” the default extensibility option. I pair this with making “private” the default visibilty. In other words, you cannot see it or alter it unless I explicitly allow it. This is at odds with Gili (“turn-around time between my request and his next release usually ranges into months”) but the other developer has to maintain the integrity of their code for all users and “just say no” is the most conservative default.
January 5th, 2007 at 1:16 pm
No semicolons — thumbs down on this one. Long statements are a fact of life with long descriptive names, casts, and nestings. I see many statements that become more readable broken across multiple lines. I particularly like multi-line method calls, e.g.,
SomeLongClassName output = someLongObjectName.methodCall(argument1,
argument2,
argument3);
Backslashing multi-line statements? Insanely less readable.
Require braces for multiline statements — Braces create compound statements by grouping the contained staements. You want to require them in cases where there is only one contained statement? Trivially helpful as a coding style but the existing definition of a “statement” is consistent. Emacs auto-indent catches any such coding errors easily.
switch-case statements — I disagree. A trivial change, but it would undermine a lot of existing, well-thought-out code.
switch types — I’m neutral on this one. (But how about allowing non-booleans as if-arguments? What’s wrong with C-style rules?)
Ban tabs — I agree. Emacs auto-tabs for the java-mode, but allows untabification for saved code.
Multiline string literals — Does this dovetail with your multiline issue? I think the current way (literal “\n”) is clearer. Perhaps it would help to introduce some new kind of bracketing for your multi-line Strings. BTW you seem to be missing some backslashes and a closing parenthesis in your examples.
January 5th, 2007 at 1:20 pm
Hey! My multi-line method call got mucked by wraparound. Should be like:
Myclass output = obj. methcall(arg1,
arg2,
arg3);
That is, args alligned vertically.
January 5th, 2007 at 1:23 pm
Hey again! Killed by whitespace suppression! Oh well, as described; not as rendered.
March 5th, 2007 at 3:16 pm
C# implements everything you just described plus much more. If you could just use C# compiler…
Btw, Java bytecodes and Java VM are both misnomers. There are no Java VM but just VM produced by Sun, IBM, MSFT, Mono or whatever vendor, plus multiple compilers targeting particular VMs. Naming everything (language and VM) “Java” was just a marketing ploy by Sun.
In .NET universe, there are virtual machines (produced by MSFT or Mono), there are core libraries, and there are multiple (20+ last time I checked) compilers produced by various vendors. Everything from Assembly to Perl.