On 22 March 2011 11:02, Reinier Zwitserloot <[email protected]> wrote:
> 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....) > I have to disagree with this evaluation of Java, it most certainly DID remove a lot from C/C++ instead of simply porting the syntax wholesale. Pointers and reference types spring immediately to mind, as do macros and templates. C++ pointers allow you to create higher-kinded functions and write in a much more functional style, Java abandoned this ability. You'll also find that Scala's collections are far more interoperable and closer to Java's than Java's are to collections in the STL. So why did Scala not simply adopt Java's collections (which it can happily use, by the way). Simple, to drop the inherent mutability that pervades the Java collections API, to allow for declaration-site variance (instead of wildcards throughout your code), and to make it easy to add all the juicy higher-kinded methods that make the library so damned powerful 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. > Scala. It has a standard ASL, and all the IDE plugins are migrating to use the presentation compiler (written with IDEs in mind) following the 2.9 release. The meta-notation is annotations; for an example of this, look at the @BeanProperty annotation which automatically generates getters and setters on fields, and is recognised by all current Scala IDE plugins. - 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. > Take a look at Scala-Modules, this is all very doable via standard DSL approaches. There are also ongoing efforts to modularise the language and core libraries. - 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. > Scala. Though most algorithms change significantly in appearance once you have closures available. This will be true of any Java successor. > - 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. > Make the syntax clean enough, and you don't need collection literals. This also makes it far, far easier to write new collection types that look natural. History is littered with examples of things being standardised in syntax and later discovered to be a bad practice, but impossible to then remove from the language. Such as checked exceptions... - 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. > Interesting... How would you propose such a mechanism should work? Sounds more like a requirement for library authors to me. - 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). > Scala again :) - 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. > Scala: Parallel collections in 2.9 (soon to be released) But this is all done as part of the standard library and not the core language syntax (as per your previous point...) > - 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. > The 2.9 Eclipse plugin for Scala is looking very sexy, and IntelliJ is already at full production strength. I can't comment on Netbeans. > > Looking at that list, Gosu is a lot closer than fantom or scala... though > probably not good enough either. > Gosu certainly looks interesting and lightweight, offering many of Scala's nicer qualities. I think, though, that the killer feature in the future is going to be parallelism, given current trends in core counts. Scala's support for default immutability, delimited continuations, parallel collections, and (following work funded by the EU grant) library-driven AST transformations absolutely give it the edge here. > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > 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. > -- Kevin Wright gtalk / msn : [email protected] <[email protected]>mail: [email protected] vibe / skype: kev.lee.wright quora: http://www.quora.com/Kevin-Wright twitter: @thecoda "My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. 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.
