On 29 August 2010 13:19, Liam Knox <[email protected]> wrote: > I did not define any problem. > > Look at the history here. Gosling etc. made it very, very clear, > definitive, decisions in inventing Java. OS neutrality, pointers, memory, > what to leave out. I maybe wrong also but I remember a key employee > resigning based on supporting C++ on N Unix variants also played a part. > > And this basically states why Java was successful. Java took 2 problems, > OS dependence and Memory(pointer) management. > These were massive. Java is also more easy/less complex the C++. > > So whats next ? > > Define the issues we still have. > > 1. Persistence has not evolved for the last 30 years. The mentality is > still some loose binding that is not easy to develop to. SQL vs OO mess >
Although... grid computing and "application fabrics" (e.g. terracotta) have offered ways no neatly sidestep persistence in many cases. The NoSQL movement also has a great deal to offer. In the sense that systems like MUMPS have exposed similar concepts for years then, yes, it hasn't evolved all that much! > 2. Remoting. We are in no better shape than with Corba. Look at the > WebServices spec, is that better than Corba? > WebServices, as in SOAP? Totally, just as with Corba, the standard has been pushed around and abuse by corporations hoping to turn it into anything but a commodity. Margins are so much higher if you can arrange for vendor lock-in. REST, on the other hand, I think is really showing some promise as an open standard. > 3. Concurrency. Actors in Scala? Fantastic. But why cant a VM understand a > loop that can be executed in parallel? > In a word: "purity" While it's possible for a function to have side-effects (i.e. it does something other that transform its input to its output), then the compiler can never be certain that one iteration of a loop isn't somehow dependant on the side effects of a previous iteration, and so cannot optimise. Consider one such classic side effect, logging to the console. Given a list of integers, how could you possibly `println` them all in parallel? This is *the* issue that myself and other Scala/FP advocates have been tearing our hair out to explain, and is the reason why "FP is better for concurrency". Only if you have pure (without side-effects) first-class functions and work with immutable objects can you be sure that a "loop" is 100% safe to execute in parallel. Only it's not a loop any more, it's just a mapping from one collection to another collection, and you've shifted from an imperative paradigm to a declarative one. > I don't think we are talking about noddy improvements in semantics or > conciseness like Scala promotes. > Scala adds nothing to Java in the real world, compared to a better > persistence idiom. > Scala adds FP to Java, and does it more completely and more effectively than the JDK7 closures proposal. Mostly because it doesn't have to drag the cumbersome weight of backward compatibility. This is absolutely *not* a noddy improvement, it's critical! There are other languages that take steps in this direction, but they all demand a significant shift in convention and syntax, and/or are dynamically typed. This puts Scala in the unique position of being a true statically-typed FP language with near-Java syntax and conventions. If you really can't see the genuine benefits that Scala has to offer, then you clearly haven't looked at it for long enough or in enough depth. Of course there are some very valid criticisms that can rightly be aimed at Scala, but that list most certainly does *not* include "only offering noddy improvements in syntax" and "adding nothing to the real world"! The next evolution needs to be more realistic in what actually systems do > right now. > Agreed, on the understanding that evolutions take place in developers, far more so than in programming languages. > 2010/8/29 Cédric Beust ♔ <[email protected]> > >> >> >> On Sun, Aug 29, 2010 at 12:29 AM, Liam Knox <[email protected]> wrote: >> >>> First define the problem you want to solve. >> >> >> You already did that: >> >> >> All look rehashes and mutations of one another without providing any real >> benefit from walking a way from Java with its standards, footprint, >> community etc, etc. >> >> So, what language do you have to offer? >> >> -- >> Cédric >> >> >> -- >> 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]<javaposse%[email protected]> >> . >> For more options, visit this group at >> http://groups.google.com/group/javaposse?hl=en. >> > > -- > 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]<javaposse%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > -- Kevin Wright mail/google talk: [email protected] wave: [email protected] skype: kev.lee.wright twitter: @thecoda -- 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.
