Viktor Klang wrote: > Here are my suggestions: I'm not sure how feasible all of these are via source re-writing -- I'll honestly say I just didn't ponder that question long for each of these. Some strike me as less than amenable to this approach (e.g. #8 in particular).
Of these I have to say I'd personally only get excited about #5. Multiple inheritance of method implementation via interfaces would be really helpful in cases. [I think you end up needing non-public methods in interfaces to pull this off well, though -- as you need something to provide unvarnished get/set access to the implementing class' properties and you almost certainly don't want this public. You want the "varnished" get/set access to be public, i.e. that with validation whose default algorithm is specified by the interface, etc.] Actually I don't really buy #8 at all -- classes can be unloaded today. There are restrictions on when, but changing those vs. working with them is a JVM spec change, not a source rewrite or even JVM implementation issue. -- Jess Holle > 1) Remove checked exceptions > Why: Loiters the code without actually adding anything > 2) Add type aliases > Why: To avoid repeating yourself > 3) Add Scala case class (autogeneration of hashCode, equals and toString) > Why: Removes about 90% of all javabean code > 4) Add non-nullability without the retarded annotations (<typename>? = > type or null, not nullable being default) > 5) Add the possibility to have method definitions in interfaces > Why: this makes it possible to add methods to interfaces without > breaking everything apart > 6) Add CICE > Why: Because anonymous inner classes as closures is 80% boilerplate > 7) Add tailcalls to the JVM > Why: Because torturing the stack is not kind > 8) Remove PermGenSpace and place the classes into the regular heap > Why: Because closures add alot to permGenSpace, and unloading > classes is not a bad idea > 9) Add message-based concurrency (actor based perhaps?) > Why: Because empirically, very few programmers are competent > enough to write shared-memory-based concurrent software.) > > > Sorry for the negative attitude earlier, I'm just kind of pissed off > at Sun for letting the language deteriorate into slush. > > Cheers, > Viktor > > > > You also seem to misunderstand the concept of 'gradual change', and > you missed an earlier point I made: Scala is NOT going to become a > popular language. It's too much at once for the mainstream, so they > wont go to it. Java.next might at some future date be more like Scala > than real Java, but it'll get there in baby steps, gaining converts > every step of the way. It might help to explain a key benefit of this > scheme: > > Because everything is stored in vanilla java, you can actually make > breaking changes between versions without actually breaking anything; > you update your plugins, and the next time you open source files, > voila, you all of a sudden have a slightly different syntax for some > boilerplate or other. If, at some point, java.next is popular enough > that the 'convert to vanilla java' step is eliminated in a significant > number of code shops, you still don't lose the benefit. Every > java.next file on disk has a source flag so that future versions > (with, maybe, breaking changes in it) can apply the same read-and- > rewrite trick to update all code as it gets read in. > > Back to the topic of Scala for a moment: I really don't think it'll > happen, but if you have faith, you may want to join the project. The > compiler's recovery needs a heck of a lot of work before scala is > ready for the mainstream. Right now, scalac will pretty much bite your > head off if you make one typo. Also, those people who immediately > flock to the immutable collections and make the natural assumption > that they can safely use these in multi-threaded apps put these in > production and then see their project fail utterly, because Scala's > immutable collections aren't thread safe. There's plenty of nagging > problems there for you to look at and fix - assuming you want the > world to change and allow Scala to become mainstream. > > On Oct 11, 12:11 pm, "Viktor Klang" <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > Reinier, > > > > my point (although somewhat between the lines) was that doing things > > suboptimally is bad in the long run. > > > > Software development is my passion and profession, and I ain't > gonna touch > > Java as soon as people wll start to pay me to code in languages > that I > > actually enjoy using (read: Scala). > > > > I'm not talking about Java Joe, I'm talking star developers > leaving the > > sinking Java-ship, and putting some lipstick on the pig ain't > gonna have > > them staying onboard. > > > > Sorry for the rough attitude, but the Java boilerplate is bad > for one's > > mental health. > > > > Cheers, > > Viktor > > > > On Fri, Oct 10, 2008 at 3:17 PM, Reinier Zwitserloot > <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>wrote: > > > > > > > > > > > > > Answers inline. > > > > > On Oct 10, 9:44 am, "Viktor Klang" <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > > > > > Why not: > > > > > > Thread({/*Code*/}) ? > > > > > Because that's not CICE. The concept of 'auto-boxing' a lone > codeblock > > > is enticing, but you at the very least need 'long > returns/breaks' (the > > > concept where a return, break, or continue statement inside a > closure > > > is capable of escaping the closure. That's part of BGGA but > not CICE, > > > and you get issues, like, for example, for a thread that makes no > > > sense, you can only use that if the closure is discarded after the > > > command you fed it to is done), and you probably need some sort of > > > shorthand syntax for feeding parameters into the codeblock. > The above > > > so happens to work because Runnable's one method has zero > parameters. > > > > > CICE is easy to translate back and forth for all possible usage > > > scenarios, without having to add -any- extra libraries. This is > > > utterly impossible with BGGA; you need the Throwable-based > classes to > > > support long returns/breaks, the Function classes to support > > > structural typing, and more. > > > > > > The need for the "new" keyword is gone. > > > > > CICE is a significant improvement to syntax. Cutting the 'new' > off of > > > constructor calls is a minor change that doesn't seem to improve > > > readability much, primarily relying on the convention that > classes are > > > capitalized to make it obvious that its a constructor call > instead of > > > a normal call. You also have to drop the split in constructor > call / > > > method call that is currently part of the AST generation process, > > > which is a big step that this project will not be taking any time > > > soon. So, yeah, part of this effort is thinking it through, > not just > > > for the syntax, but for the side-effects of how it would > translate and > > > how complicated the javac patch is going to be. > > > > > > > which translates forwards and backwards, no problem. > > > > > Problems: long returns/breaks, lack of 'new' is enforced; you > can't > > > have two different equally valid translations, so whatever > syntax you > > > go with, has to be the -only- syntax. > > > > > > case class Person(var firstname, var surname) > > > > > As I said, the list wasn't complete. scala-style case classes > are part > > > of the deal, and will also auto-generate equals and hashCode, a > > > constructor, getters, and if you like, setters (though I'm edging > > > towards just allowing immutables. Keeps it simple, and > immutables are > > > good). That doesn't remove the need to have getters and perhaps > > > setters for classes that fundamentally aren't value based. For > > > example, properties are popular in GUI classes (see Cocoa, > which is a > > > big part of Joe's tireless campaigning for them), and it would be > > > really strange to build, say, a 'Slider' widget class with a case > > > class system. Yet, they most very very definitely have > properties. The > > > value of the slider has to be a complete property, with getters, > > > setters, and add/removeValueChangeListener. > > > > > > ...and remove arrays from the language... (they are a primitive > > > optimization > > > > construct, the language should only expose ArrayList, and > then the VM can > > > > use arrays under the hood) > > > > > Arrays will indeed be removed from the language, so that [] can be > > > recycled without making the parsing step more complicated than the > > > current infrastructure can handle (again, the infrastructure > of the > > > parser, such as its LL(1) nature, will _NOT_ be changed, at > least not > > > for v1.0, because that makes everything far too complicated). > You can > > > still use arrays (I have to translate mention of arrays in a > vanilla > > > java source file to something, not to mention that they still have > > > their uses; a byte[1024] is ~ 1032 bytes in memory, a > List<Byte> with > > > 1024 entries is ~16448 bytes in memory (on 64-bit, divide by half, > > > roughly, on 32 bit), so, no arrays can't go away until the > compiler is > > > smart enough to store a List<Byte!> as a raw byte stream in > memory, > > > where '!' is a shorthand for 'cannot be null' - a feature that > might > > > make it in, especially if the JSR that adds @NonNull to java core > > > libraries goes through). I'll probably make 'Array' (with a > capital) a > > > keyword, and have some sort of syntax to use it to create > arrays and > > > declare array types. Yes, shamelessly ripped from scala. > > > > > > > - default parameter values. > > > > > > Praise the Lord! > > > > > It's not as thorough as e.g. python, but it should be enough, > > > especially if you do the coding in java.next, instead of > relying on > > > automatic translation of vanilla java. > > > > > > or like: map.foreach( (K key, V value) { /*Code*/} ) > > > > > That's not how far java.next can reasonably go, assuming that is > > > syntactic sugar for calling: > > > > > public void foreach(closure {K key, V value => void}). > > > > > 1) Adding methods cannot be done in a way that is sanely > translatable > > > unless I hardcode the list of extra methods, along with the > patterns > > > in vanilla java. > > > > > 2) The type of syntax sugar going on for translating > > > (formalParameterList) { codeblock}) into a method is considerable. > > > Definitely not one of the patterns that'll go in anytime soon, > as its > > > rather contenious. There are plenty of changes that everyone > wants, > > > but for whatever reason Sun isn't planning to add anytime soon. > > > > > If you are suggesting that the above syntax is just the way > the map > > > foreach pattern works, then, I don't agree; it LOOKS like > foreach is a > > > method, while it really isn't and that's just how the syntax is > > > written. Not to mention that it would be a major hassle to > make the > > > parser understand this without making foreach a keyword, which > kinda > > > defeats the purpose. > > > > > 3) Clearly it would have to be forEach :) > > > > > > > - infer type for local final variables (just 'final foo = > "hello"; is > > > > > valid). > > > > > > Or simply make "final" the default. > > > > > No, java is not ready for that change. Try it, go program > using only > > > 'final', everywhere. You'll go nuts. Java needs more basic > glue that > > > is designed to work with immutables properly before you can > make that > > > kind of change. > > > > > You're also entirely missing the point of this exercise, so I'll > > > explain that in the next comment. > > > > -- > > Viktor Klang > > Senior Systems Analyst > > > > > -- > Viktor Klang > Senior Systems Analyst > > > --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
