 |
Code Complete Nonsense: More Language Proposals
Posted by chet on August 23, 2007 at 06:16 AM | Comments (48)
There's been a lot of talk recently about the various language proposals that
people have made, or debated, or agree with, or detest more than their mother
using spit to wipe something off their mouth when they were kids. But I think
that some very important language features have been under-represented in all
of the discussion, and I'd like to make sure that they make it into the
language change death match.
Here are my pet language proposals. You may recognize some of these as
features from other languages whose absence from Java has long been a mystery.
Line Numbers
How many times have you wanted to refer to a line or block of code, in a
presentation or a review, or just a conversation in a bar (otherwise known as a
"pickup line"), and you end up saying something like: "in the line that starts
with "if (ventedCelebrium == MAX_VENTAL_SIZE)" or "in the for() loop ... no,
the other for() loop ... no, the one before that, right after the call to the
creakleFrantic() method"?
Isn't it time that we had line numbers in Java? Then you could simply say, "On
line 42" or "in lines 8709-8752" and be done with it.
Obviously, time has moved on since line numbers were first used in other
computer languages, back in the 16th century or so, and we're all a lot smarter
now. So I would like to propose a small tweak to this proposal and demand that
the line numbers be in floating-point units. Besides having all of the
additional power of floating-point processing over the more typical, and
therefore much dumber, integers, think of the utility of being able to insert
code without changing the surrounding line numbers. Imagine:
Original:
1 for (int i = 0; i < 100; ++i) {
2 System.out.println("fart");
3 }
Improved:
1 for (int i = 0; i < 100; ++i) {
2 System.out.println("fart");
2.5 System.out.println("Oops! Excuse me!");
3 }
An alternate proposal on the table is to allow imaginary numbers as well, but I
find that idea irrational.
Goto considered harmless
Once we have line numbers, it's an obvious step to go ahead and shovel in the
keyword "goto", which has been waiting in the wings lo these many years, like
the scrawny, bespectacled youth waiting to be picked for a kickball team. After
all, wouldn't we goto justification;
justification:
love to have teleportation in our own lives? Why should we deny our
code that very capability when it's just lying there like a goto metaphor;
metaphor:
Twinkie under the bleachers, waiting for us to pick it up and cram it in
our mouths? goto end;
end:
Line Spacing
Whatever happened to that great capability in older languages of
having meaning embedded in the spaces? You couldn't just type code willy-nilly
wherever you wanted, but instead had to start the code in certain
columns. Sure, we get this fantastic capability from Makefiles, but today's
make systems are hidden behind IDE interfaces, and we rarely get to work
directly with the beauty and elegance of Makefile directly.
Isn't the significance of space just a metaphor for life (at least when you're
brain is chemically altered) where it's really the space and silence that count
the most? It's the silence in scary movies that really build the
suspense. It's the quiet times that you spend with your kids that make you
forget the screaming matches. It's the geographical space between
relatives that makes family relationships function at all. And it's the space
characters in code that really give the code meaning and quality.
I would like to introduce column significance into Java, and make us all think
more about where we put our code. I've had enough of the code style wars of
indentation amounts, tabs-vs-spaces, and wide-vs-narrow line lengths. Let's
start enforcing code style by making the compiler puke when it finds code in
the wrong place.
Capital Idea
Have you ever noticed when you get an email from someone in ALL CAPITAL
LETTERS that the case actually changes the way you interpret the information?
For one thing, you feel confident that the sender is an idiot who
isn't aware of the caps-lock key. But more importantly, you feel as though
they are SHOUTING AT YOU through the computer (a real need in society
which has since been addressed by Skype).
I think that the code that we write is cool enough, powerful enough, and
significant enough that it should be screaming itself at the readers. How else
will they understand how awesome the code is? Did Martin Luther King just
casually mention "Oh, by the way, I have a dream" to
whoever happened to be nearby? No: he used a microphone to
proclaim this great speech to as wide an audience as possible. Did Black
Sabbath speak their lyrics to the audience, like a folk singing
group in a coffee shop? Of course not: they screamed them out through bat
entrails to an audience so deaf from the amplifiers that nothing less than an
ear-splitting banshee wail would penetrate the din. Did Prince Charles proclaim
his love for Camilla in a quiet manner, over a private telephone call?
Actually, yes: it was the press that illegally tapped the call and then
relayed the sordid content through huge headlines, in a way that only
the British tabloids could do.
Of course, we are free use capital letters in our code today. But this
approach is mixed at best, with various keywords expected in lower case and a
lack of convention and consistency defeating the system overall. We need
compiler-enforced capitalization to make sure that our code intention comes
through LOUD AND CLEAR.
break;
There are many more classic language features out there, dying to resurface in a
modern language. They worked well for previous generations of programmers, I'm
sure they would work for us too. Ignoring all of these features would be a sin
tax.
Bookmark blog post:  del.icio.us  Digg  DZone  Furl  Reddit
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
-
I want all of these features for Java 7 !
Very funny :D
Posted by: adiguba on August 23, 2007 at 06:51 AM
-
Chet, you have a real talent to make something useful sound like a complete nonsense.
Posted by: euxx on August 23, 2007 at 07:18 AM
-
continue;
Posted by: francisdb on August 23, 2007 at 08:05 AM
-
Re: line numbers.
I would go further and suggest using irrational numbers, too. Don't you want to have a line with sqrt(2), or Pi.. Now line sorting might become an issue with lines like 'e pow pi' and 'pi pow e'..
Dmitri
Posted by: trembovetski on August 23, 2007 at 09:54 AM
-
No, Dmitri, you're thinking to much in the box.
By allowing floats, you can already have irrational line numbers.
But the leap that needs to be made is allowing static constants within your code. Then it's easy, and Very Java.
1 public static void main(String args[]) {
Math.E System.out.println("eeeeee!");
Math.PI System.out.println("I like pi!");
4 }
See, it's so intuitive. And with Static Imports, it's even BETTER!
Think of the flexibility! By using static constants, you can change the implementing class and reorder your code without have to actually change it in the source file!
Imagine this:
CodeSequence.java:
public class CodeSequence {
public static final int MAINSTART = 1
public static final int FIRST = 10;
public static final int SECOND = 20;
public static final int MAINEND = 100
}
LineNumberzR00L.java:
import static CodeSequence.*;
public class LineNumberzR00L {
MAINSTART public static void main(String args[]) {
FIRST System.out.println("I'm first!");
SECOND System.out.println("I'm second!");
MAINEND }
Just think -- change CodeSequence.java setting FIRST to 20 and SECOND to 10, and rebuild. Voila! Resequenced code!
This is some powerful stuff -- groundbreaking even I think. Only Java can take something as mundane as line numbers to a new level.
Posted by: whartung on August 23, 2007 at 10:29 AM
-
Since when did this become a C++ standards discussion board?
Oh, whoops, sorry.
Rgds
Damon
Posted by: damonhd on August 23, 2007 at 12:52 PM
-
A constant war between developers: where should the braces go? Same line? New line?
How about this new language feature: require TWO braces, one on the same line AND one on the next line.
Everybody wins!
Posted by: prunge on August 23, 2007 at 03:40 PM
-
"An alternate proposal on the table is to allow imaginary numbers as well, but I find that idea irrational." :D Good one.
I don't agree with your view chet. Yeah, they're making too much fuss about adding more and more language features and blah blah blah, but I think that closures are THE language proposal that should be taken into consideration. Just see how much time and clarity you gain by using them. Neal Gafter is really doing a great job.
For you out there that are still not convinced, I suggest that we should go back to Java 1.1. Oh wait, it supports inner classes... OK then let's stick with 1.0 !
Posted by: jaxer on August 23, 2007 at 04:13 PM
-
Chet this gave me a good laugh, but on a serious note the one thing that I miss from C++ is multiple inheritance. Just curious, but does anyone else miss this feature? Sometimes interfaces just are not enough to avoid code duplication, when what you really want is to inherit from to different classes. Maybe this could be allowed only when inheriting from an abstract class and a concrete class? This would still leave the ability to implement any needed interfaces. Would you say this is a reasonable proposal or just more nonsense?
Posted by: badapple on August 23, 2007 at 08:47 PM
-
hello badapple,
Remeber that Object oriented Lanaguage designted for reallworld purpose.
The Java is mainly designed for really world purpose.
As you told your missing Multiple inheritence in Java .
The reason is as good as we cannot have a child with parents Dog and Cat.
Class itself defines particular cateogery
Dog is on one cateogery
Cat is on one cateogery
now I two classes Dog and Cat.
But In really I cannot have Child from DOG and Cat as parents
This means my class cannot inherit more than one class.
If java Designers provide Mutliple inheritence in Java then it will be like this.
public class Child extends DOG,CAT{
}
do you feel this would be good.
So now the word Interface comes into account.
where you can put certain properties .
and your class which implements these interfaces can use it.
Posted by: dhilshuk on August 23, 2007 at 11:16 PM
-
You have forgotten one important keyword - assembly followed by the sequence of bytecode ... because everybody knows that we are much smarter then compiler ever can be ... ;)
Posted by: rah003 on August 24, 2007 at 12:35 AM
-
What about native assembly and then we can wrap up our platform-specific asm in a Java wrapper giving the illusion of portabilty and security while having neither! Way to go!
Posted by: damonhd on August 24, 2007 at 12:40 AM
-
Absolutely. These great ideas will certainly add clarity to Java source code. Any chance of squeezing them into Java 6 u4, along with the Consumer JRE stuff?
Another thing I think it's important to consider is that, currently, it can be very confusing when lines of code spill over to more than one line of text. For example, consider the following line of java:
i = j + k + l + m +
n + o + p + q + r +
s + t + u + v + w;
That is almost totally unreadable. However, if Java were to borrow the idea of "statement continuation" from FORTAN, then code would be much more readable when statements span multiple lines. As with your line numbers idea, we could use the power of modern CPUs to expand on the concept to also say how many lines the statement is spread over. For example, the following code shows explicitly that the statement is spread over three lines, and shows which is the first line, and which is the second line.
i = j + k + l + m + $$1/3
n + o + p + q + r + $$2/3
s + t + u + v + w;
Much more readable. Another advantage of this idea is that the specific tagging of line continuations will significantly speed up compilation because of the extra hints given to the compiler. Obviously, with Java's reputation for slowness, this could be a useful performance boost.
Obviously, the "$$X/Y" syntax is only a suggestion. The idea could work equally well by embedding fragments of XML to describe the continuation.
Posted by: psynixis on August 24, 2007 at 06:06 AM
-
CHET,
LINE NUMBERS ARE TOTALLY IRRELEVENT NOW THAT WE HAVE xml.... WE CAN ACCOMPLISH YOUR OBJECTIVE BY DELINEATING ANY DESIRED BLOCK OF CODE WITH A LABEL.
<LABEL id="first">for (i =0; i<100; i++) { <g;/LABEL>
system.out.println("XML rules");
}
ISN'T THAT MUCH BETTER?
-JohnR
Posted by: johnreynolds on August 24, 2007 at 06:49 AM
-
I wonder why he did not mention the $ before Strings that is used for example in PHP
Sorry Chet, but goto, break, continue were long time considered to be error provocating - and thats why most developers dont useit!
And using complex numbers in a for loop, who on earth came up with this? A loop is used to do multiple instructions at a time and integers are considered as the fastest way to perform loops!
This cannot really be the future of Java programming because its going backwards to the age of FORTRAN, COBOL, and these things.
Posted by: alexanderschunk on August 24, 2007 at 07:19 AM
-
Another good suggestion used i.g. in BASIC or MAPLE. The step keyword in for loops. This is clearly a great innovation for professional developers.
Anyway, i dont see any groud breaking innovations concerning the language here at least at this low-level of the language.
Rather i would improve high-level featuers and getting rid of some OOP stuff a few people only use.
Posted by: alexanderschunk on August 24, 2007 at 07:26 AM
-
I want the noreturn keyword from languages like DATABUS. For those unfamiliar with of the concept, it means.
"don't return to the method that called me, return to the method that called the method that called me".
This way I can just call noreturn when I get an exception and want to cancel the method that called it. It would allow for all sorts of nice optimizations!
Oh yeah and a native jump table syntax!
int x = 4;
invoke x with callMethod1(), callMethod2(), callMethod3();
Isn't that just the coooolest!
Posted by: aberrant on August 24, 2007 at 07:50 AM
-
OMG... What are you smoking?
Line numbers...Check your IDE I'm sure you can turn those on.
Goto... Are you kidding!?! You want spaghetti code!?! Use AOP, or Byte code 167.
Line Spacing.. Well if you would line up your braces you wouldn't need that!!
Putting a brace at the end of the line instead of lining them up was done to save
space in books. Everyone thinks that it's a good way to format code. WRONG.
CAPITALS... EVER HEARD OF COMMENTING YOUR CODE!!!
We have enough PHP/Ruby programmers flying by the seat of their pants. Honestly I never liked the idea of making the java compiler smarter so that it could allow more poorly constructed code. Microsoft cut VB for a reason, why do we need to pickup developers that have no sense of code design and style.
There are reasons we don't have GOTO, there are reasons why there are no line numbers, there are reasons why syntax is not based on whitespace. Have we not learned from history, or did schools stop teaching these lessons.
If you want to program like a then use a willy-nilly language and suffer the consequences, but don't mess up a perfectly good language. Just because there are more fly-by-seat programmers doesn't mean that the masses have the best ideas.
-Sfitz
Posted by: sfitzjava on August 24, 2007 at 08:02 AM
-
Oh, man, it took me a while, but now I realize that Jonathan Schwartz must be picking your brain for ideas for taking Java to the next level. It's all starting to make nonsense.
Posted by: detorres on August 24, 2007 at 08:48 AM
-
When you were talking about line numbers.. I couldn't actually believe you were reintroducing the BASIC way of doing things.
I thought you were talking about having a __LINE__ preprocessor constant that would allow you to pinpoint where an error happened (a good feature for debugging).
While I have no use for line numbers a la BASIC, C's feature of allowing you to specify the exact line and file name of where an error happened is good for debugging. Java' s exceptions don't always get you the correct information.
Posted by: dog on August 24, 2007 at 09:06 AM
-
I think the ternary operator is just a tiny step in the right direction. After all, why waste keystrokes typing long words like "if" and "else" when you can save several keystrokes with "?" and ":"?
I'd love to see a quaternary operator (and not just because "quaternary" is fun to say), in place of the for loop:
int i=0 ? i<10 : i++ ! System.out.println(i);
Isn't that much more readable than:
for (int i=0; i<10; i++)
System.out.println(i);
Posted by: atripp on August 24, 2007 at 09:09 AM
-
I'd also like an IDE that ignores everything after the first less-than symbol, as most web posting software seems to do. It tends to cut way down on the amount of code that people have to read.
Posted by: atripp on August 24, 2007 at 09:11 AM
-
I love the comments that think you are being serious. It just goes to show how crazy the language proposals have become where people actually believe that these are actual suggestions. I would love to see whitespace have meaning in programming languages again. Maybe we can take some tips from the programming language Whitespace
Posted by: mtnsurfer on August 24, 2007 at 09:30 AM
-
ahahahah.. for the ones looking for such advanced features, just check it out. ahahahahaha
Posted by: felipegaucho on August 24, 2007 at 09:40 AM
-
You forgot the most important language addition: Getting rid of those superfluous semicolons to terminate a statement. A statement latest ends at the end of the punch card. Ups, that is, at the EOL for those modern kids with interactive terminals.
Imagine how many semicolon lifes could have been saved wouldn't it have been for such eggheads like Nicklaus Wirth. Eggheads who didn't understand that it's over when it's over.
There is also an imminent need to add more control constructs. if, for, while are nice, but only for professionals. The proposed goto? Blah, to complex. until? Useless. Those whining beginners who don't know what to code badly need maybe, otherwise, sometimes, never and often.
And don't forget that FORTRAN had the greatest if ever. arithmetic IF. That combined with computed GOTO ist a must-have for every language.
IF (X*Y-Z) 100,200,300
C NOTHING HAPPENS HERE
C CALCULATION RESULT IS LOWER THAN 0
100 I=4
J=1
GOTO 400
C CALCULATION RESULT IS EQUAL 0
200 I=2
J=2
GOTO 400
C CALCULATION RESULT IS GREATER THAN 0
300 I=1
J=1
400 GOTO(500,400,200,300) I*J
500 STOP
END
And guess what? Any of these is better than closures.
Posted by: ewin on August 24, 2007 at 09:48 AM
-
Now, i actually get what he is trying to say:
This code is complete nonse.
Hopefully Chet is not working on the OpenJDK compiler :).
Posted by: alexanderschunk on August 24, 2007 at 10:43 AM
-
Chet,
Nice!
I wonder if these things have been implemented in the kitchen sink project?
It seems scripting languages solve things too (rhino, jython, etc), therefore maybe there should be a proposal for JAppleSoftBasic where they accept line numbers. or JFortran.
-Carl
Posted by: carldea on August 24, 2007 at 11:43 AM
-
What about the IMP language th at al lo ws sp aces with in token s? So useful!
Posted by: damonhd on August 24, 2007 at 01:33 PM
-
I'm surprised that all of you brilliant guys are so low level and none of you has suggested the *right* thing to bring Java to become a 6-th generation language! Why stick with plain text? Java 1.0 introduced sources in UTF-8. But this was ten years ago. We live now in the XXI century! We need a powerfull language exploiting the whole power a graphical UI in source code!
The first step in the right direction is to use multiple fonts. For instance, class names must use Arial 14 Bold. Why use extra characteres to delimit comments? Comments in Java 7 should be written in italic. Font size can be used to provide hints to the compiler: a small font means that HotSpot must not spend a lot of time trying to optimize this part of the code because that it's not really that important... Colors could be used too. Code in red means that it is buggy, so the compiler could try to find the bugs...
Combined with XML and imaginary line numbers, I feel we start to have a really usefull language...
Posted by: genepi on August 24, 2007 at 02:18 PM
-
Chet, I would like you to seriously consider the concept of openures. These would require the new uhh keyword and would be block-level constructs, but would also helpfully reuse varargs syntax and preserve the best of the myriad closure proposal syntax out there:
int numberOfBlogPostingsDevotedToClosureProposals = [{#@!? ( ( ( { | x | ...uhh...;
Another strong language enhancement consideration should IMHO be indeterminate class completion, denoted by the keyword yada:
public class DefaultAbstractNotifyingFactoryMechanizationHandlerBrokerPersistenceFactory {
yada
}
A weaker assert statement, perhaps?
pray x != null;
And finally, while strictly speaking not a language change, I do believe we could use some standardization in the annotation camp. Forthwith I submit the @Enterprise annotation, which can be particularly powerful when used with indeterminate class completion:
@Enterprise
public class D6501 {
// XXX why doesn't this work? ask jerry
// comented out bc amir said to -- cjw 11/2/97
// public Object brillant = "paula";
yada
}
Cheers,
Laird
Posted by: ljnelson on August 24, 2007 at 07:02 PM
-
Following on from the above @Enterprise, I think we need a MakeItSo operator, to be used in a vaguely regal manner to fill in specification gaps.
Posted by: damonhd on August 25, 2007 at 04:50 AM
-
And continuing the obscure Star Trek references punning on @Enterprise...
I think we need a new access modifier:
outtherethataway void doSomeObscureCommandInAnExternalLibrary();
The new access modifier is to be used in the same way as "extern" in C - specifying that there's a method "out there thataway" but that we really don't know the implementation of so the program can barf at runtime when the library containing it is not found! Obviously a vast improvement on the NoSuchMethodException, since we actually take the time to prototype the method, right?
(The MakeItSo WAS a Star Trek reference, right? ;-))
Posted by: ekolis on August 25, 2007 at 06:26 AM
-
Yes to StarTrek allusions, but also to Dilbertian PHB management-by-fiat! Two meanings for the price of one keyword: can't say fairer than that...
Posted by: damonhd on August 25, 2007 at 07:49 AM
-
we want REAL XML syntax for Java. Everyone knows XML is easy to read, so by adopting XML syntax Java becomes easy for everyone... Just think of it:
Posted by: jwenting on August 25, 2007 at 11:11 AM
-
That should be:
<class name="NullPointerException" package="java.lang">
<extends class="RuntimeException" package="java.lang">
<constructor>
<![CDATA[super();]]>
</constructor>
</class>
Posted by: jwenting on August 25, 2007 at 12:21 PM
-
The CDATA is genius!
Posted by: damonhd on August 26, 2007 at 11:34 AM
-
Don't laugh but I know a guy the religiously uses break and goto labels in the existing java! I didn't even know that they were in the language and had to verify how they functioned. It's shameful that they remain there!
Posted by: alski on August 27, 2007 at 03:55 AM
-
@jwenting: I actually have worked before at a place where there ARE Java + XML files, and they look exactly like you've satirized above (I mean exactly--down to the CDATA section). I wish I were joking.
Posted by: ljnelson on August 27, 2007 at 07:17 AM
-
The only thing funnier than this post are the replies from people taking it literally. This is genius, Chet!
@ljnelson: I wish you were kidding.
Posted by: coffeejolts on August 28, 2007 at 05:49 AM
-
It is very difficult to contain my contempt for the omission of unsigned integers and longs in Java. The decision was obviously made by computer scientists who don’t understand hardware and the occasional need for unsigned arithmetic. I’m sorry if adding it would be “hard” because of the lack of bytecodes to support it. But it was a very poor decision to leave it out. I would like to request that future versions of Java include native support for unsigned. All modern computer processors have support for unsigned. Java should too. And since all processors support it, it won’t even break Java’s mantra of “run anywhere.” Take a quick look on google about unsigned and Java and you’ll find lots of “what a stupid idea” opinions and frustrated programmers and nowhere “what a brilliant idea” comments. I’m sure Java developers are having a wonderful time with new projects. But it would be hugely beneficial if they added some of the low-level support that is so lacking in the language.
Posted by: biggunzclub on August 29, 2007 at 03:10 PM
-
Chet, do you do a book on humo[u]r bypasses?
Posted by: damonhd on August 31, 2007 at 02:47 PM
-
This is, without a doubt, the best discussion yet on future language features.
It seems to me that the time wasted discussing closures in Java is probably several orders of magnitude greater than the time that would be saved if we actually had closures.
Line numbers, on the other hand, would speed all kinds of things up, not least of which would be the pickup process described.
Posted by: grlea on September 16, 2007 at 07:28 PM
-
Nobody here got the point. Next Java features will all be inspired by GOTO++. Here is the GOTO++doc. Javadoc is only a pale copycat of this.
Posted by: syrion on October 17, 2007 at 05:03 AM
-
Our web is Wholesale Jewelry|Jewelry Designer |
precious stone jewelry|
body jewelry|
costume jewelry|
silver jewelry|
beaded jewelry|
swarovski crystal jewelry|
glass jewelry|
pearl jewelry|
turquoise jewelry|
wire jewelry|
fashion jewelry|
unique handcrafted jewelry|
bridal jewelry|
tour jewelry|
discount jewelry|
vintage jewelry|
jewelry scales|
jewelry boxes|
imitation jewelry supplies|
Material ofjewelry supplies and etc. Our
Jewelry|
Wholesale Jewelry Blog
Jewelry stores|
Blog.To know more details about
Jewelry Wholesale|, please enter our web:
www.aypearl.com
水晶|饰品批发
pasing oicq:80810487
Our Email: Tangjewelry_001#yahoo.com
Posted by: pasing3 on June 12, 2008 at 06:10 PM
-
Thanks so much for this! This is exactly what I was looking for.
///////////////////////////
phone sex phone sex phone sex phone sex phone sex phone sex phone sex phone sex phone sex phone sex phone sex phone sex mootzie
and other video to SWF, FLV ecoded by Java.
May it Gadgets helpful To your lifestyle... Enjoy！！
Posted by: cgspender on June 19, 2008 at 10:03 PM
-
_
Posted by: cgspender on June 19, 2008 at 10:04 PM
-
Thanks so much for this! This is exactly what I was looking for.
///////////////////////////
phone sex phone sex phone sex phone sex phone sex phone sex phone sex phone sex phone sex phone sex phone sex phone sex mootzie
and other video to SWF, FLV ecoded by Java.
May it Gadgets helpful To your lifestyle... Enjoy！！
Posted by: cgspender on June 19, 2008 at 10:04 PM
-
_
Posted by: cgspender on June 19, 2008 at 10:04 PM
|
java.net RSS Feeds
