What your are describing is still a mix and match suite of technologies that when meshed together you can sort of solve some things in a painful way. No attempt has really been made to provide a concise expression of these concerns and therefore base a better platform to cover these
That is my point. No SQL, WebServices, REST, SOAP etc, etc, ok what new acronyms shall we have next year? Lets have another one for persistence, another one for remoting , blah, blah, bloody blah. Its all very disparate and desperate This has been going on since the 70's and have we really made a lot of progress? Really are WebServices so fantastic compared to Corba? A technical revolution that makes even Einstein seem kind thick doesn't it ? As for you contention on concurrency. I would much rather a platform that could utilize concurrency intelligently, as with other resource I kind of think GC's are good so now why not invest more in proving more seemless concurrency utilization And no I don't see an overall business benefit for a large team moving to Scala from Java at this point. Given reasons previously stated you need to look at macro benefits not 'I am a developer and I like it' mentality. On Sun, Aug 29, 2010 at 10:06 PM, Kevin Wright <[email protected]>wrote: > > > 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]<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]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
