I've yet to watch the presentations but colour me surprised at the vaporware nature, too. Spending a lot of time hashing out a language "on paper" is, if you ask me, very much the wrong way to go about it. The basics are relatively trivial, especially for someone who has been secretly thinking of language features most of the time during the past 10 years (how else do you channel frustrations with your main language if not by imagining a way that would be less frustrating)?
Thus, I would have expected a basic language parser and compiler with a few of the interesting edge cases explicitly not filled in at all yet, possibly with some command line switches to enable a few different experimental ways to tackle the interesting edge cases.This way the language authors and fellow interested can give a few different ways of doing things a whirl and come to some sort of consensus. I've yet to see a language where everything just falls into place; there are always use cases that aren't catered to yet but where implementing a solution is complicated, either because its hard to come up with a natural syntax that doesn't clash anywhere else (natural = obvious and easy to remember for the programmers and relatively readable), or where what the implementation is supposed to do is just plain complicated (i.e. the iteration variable of a for loop's behaviour in closures). I also admit I'm not particularly charmed of pre-announcing a programming language in the first place. I don't think its healthy for the community _AT ALL_, because the new language can make as many claims as it wants to without an easy way to check if the hype is justified. The focus naturally drifts towards pointing at flaws in the purported language-to-be-replaced (i.e. java, the language), instead of the benefits this new language brings to the table (or, in other words, the 'benefits this new language brings to the table' is simply framed as: Fixes all of java's faults, which doesn't mean much, as some of those faults are JVM-related, most are in the eye of the beholder, and many are intrinsically related to java's strengths, so any attempt to fix them will most likely introduce new faults and/or its not at all obvious how one would go about fixing such things). Perhaps this is an attempt to generate more eyeballs and contributors, but doesn't that effectively amount to design-by-committee programming if you actually manage to get the contributors? I doubt you'll find people willing to meekly just implement your vision, no questions asked, on their own free time. Not if the language is no more than a dream on paper. I'm hoping I'll be seeing some actual innovations and not just a loose collection of 'lets fix java things'. This notion of offering a structural way to store hierarchical data in the language itself in order to ditch the frequent need for XML(-esque) config files is interesting though it sounds a bit familiar (GoSu has something similar as does JavaFXScript). -- 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.
