On Sat, Oct 11, 2008 at 3:22 PM, Reinier Zwitserloot <[EMAIL PROTECTED]>wrote:
>
> That kind of attitude is not useful to this project, unfortunately.
> Your insinuation that e.g. inference of everything is clearly superior
> to java will for example instantly lose Jess Holle; he'll never join
> your side until you've become very mainstream. A lot of language
> nuts / scala converts forget this point.
Ok, I'll stop negging the java.next idea and actually hop aboard here for a
second.
What we're talking about here is to seamlessly get rid of some of the crappy
language design of Java, using source rewriting (bytecode rewriting as
well?) to update existing Java code to newer, not-so-boilerplatey java.next
code.
Everything's good so far.
And I agree that there are lots of low-hanging fruit to pick here.
Here are my suggestions:
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]> 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]
> >wrote:
> >
> >
> >
> >
> >
> > > Answers inline.
> >
> > > On Oct 10, 9:44 am, "Viktor Klang" <[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
-~----------~----~----~----~------~----~------~--~---
