I've never run into anyone that is holding off on Fantom because it lacks 'true' generics.
Scala's problem is that it tries to change too much, but Fantom's problem is that it doesn't change enough; no matter what people tell you, its fairly obvious (to me anyway, YMMV) that changing something as fundamental as the programming language, especially if that language prefers use of alternative (fantom / scala versions of) crucial java runtime classes such as ArrayList, is a gigantic step that will never be taken lightly. So, you need a lot of convincers, but at the same time, the _vast_ majority of programmers do not want to learn more than 1 language so have to feel like another language can make a new home for them based on some simplistic snippets and without knowing much about said language. So, the language has to be both filled with convincing arguments that it feels like real, meaningful progress, whilst at the same time looking like it'll be such a minor change that they'll know for sure they'll adapt easily to this new language. Screwed if you do, screwed if you don't. I've said it before, but if any contender to java's throne is to show up, it needs to come up with "leightweight" convincers, just like java did to C: Java took just about the entire C syntax, warts and all, and imported that part wholesale to lower the bar (i.e. to 'be like fantom'). It then added things that were worth a lot but didn't have a high impact on the language itself in order to convince C programmers to switch to it (i.e. to 'be like scala'): A garbage collector, write-once-run-anywhere, threading, networking, and many other fairly standard tasks all supplied by a universal standard library thus truly delivering on the 'platform independent' promise. As an encore, java simplified a number of things, including removing the preprocessor. Not sure if that made a real difference in the end, but keeping things simple (in fact, now we might argue java was a little _too_ simple) never hurt language uptake, unlike the reverse of course. Something as simple as looking at scala's collections API makes people run for the hills even though in practice those crazy type variables do work fine (.toMap(implicit) on the other hand....) So, high impact stuff that doesn't complicate the language, that's what'll make java.next. What should this look like? Don't know - but I guess at least one of these will be involved: - A language that caters to DSLs not by making the syntax flexible but by standardizing the AST and Parser and making these pluggable, with a meta-notation to define which plugins are to be used for the sources itself. May or may not be paired by the notion that AST editing is the basic form (instead of 'stream of characters' like 99.99% of all programming today), and most likely will require adapting these plugins to be written with IDEs in mind. - A marriage between OSGi (i.e. runtime modularity), maven central (i.e. module repository), and gradle/ivy/maven (i.e. buildtime modularity) and better than all 3 combined, built into the language syntax. i.e. all you need to do is write "import guava.* from jigsaw://guava.google.com/guava/r8;" at the top of the file and the IDE will use one of the basic commands of the language's toolkit (just as basic as 'java' and 'jar') to resolve and download this dependency, and link it all up, sources included, in your IDE. - Be quite close at least at-a-glance to java syntax, just like java syntax looked virtually 100% the same as C code if you didn't look too close and picked examples that fit well, such as algorithms. - Yes, most likely this language _will_ have closures, even if only because excluding them means all the discussion will be about a perceived negative. Personally I do think java 1.1's anonymous inner classes were a mistake and should have been closures instead. It'll most likely also have collection literals and do away with a few annoyances. - A solution for sharing objects/structs provided by one library, between 2 libraries that each are dependent on a different version of that library. i.e. you want to share a guava ImmutableList between 2 libraries, but library one is at r7, the other is at r8. May involve some sort of nifty 'view' concept where an API can also export a bunch of wrapper methods that make it look like different API, while being represented 'under the hood' by the same batch of fields/struct so it can be transferred. Could be used to fix collections API while remaining compatible with that same API well enough to be able to pass (java.next) lists around to methods that want java.util.Lists without hassle. - Possibly will ship WITHOUT most of what we now consider a standard library, instead embracing the modularity concept fully and shipping instead with the knowledge that there's boatloads of libraries out there for you to import.... though I wonder if this will hit the right notes of trivially understood simplicity and power that are needed to become a new great language. I'm sure this part IS typically simple+powerful to fit, but it might not be obvious enough. Same goes for features to sanely upgrade libraries. If anything annoys me personally about the search for a new language is that the vast majority of them are blaming java for things that will happen to them in 10 years time too: Libraries that looked good then don't look so great now but changing it won't work because you really can NOT break backwards compatibility when you're that established. I can point at many scala libraries that seem like fine candidates to look downright "what the heck were they thinking". Not now, but in 10 years time. Just like java.util.Date, and the implicit mutability of java.util's collections, etc. Again a point which definitely leads to a simple+powerful language but might not be obvious enough. Would at least require some serious campaigning to make this point stick in the minds of the masses. (Probably with placations of "The only language ready for the future!" or some such). - I _really_ doubt this is in practice simple+powerful, but it might look like it: parallelism and other fine-grained concurrency control built straight in the language. Some mix of parallel-by-default loops and Software Transactional Memory perhaps. It'll certainly look like a lightweight convincer even if it isn't, and looks is worth a lot. - Ships out of the box with full IDE support. The vast majority of rank and file java programmers use Eclipse, IDEA, Oracle's builderwhatsit thing, or netbeans (in that order). Shows people you understand how they work. Looking at that list, Gosu is a lot closer than fantom or scala... though probably not good enough either. -- 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.
