> This is hardly a new argument! >Thankfully, there a people around who *are* willing to take risks and >believe in the potential for improvement.
I assume you were refering to my argument :-) I believe in adopting something new when it fixes a problem, or add value. Not because it's new. to get the benefits you have to try out new things, but not swap the entire stack, or huge portions of it, each time you start a new project. But, Everything in moderation I guess. Software projects should be about creating software, not fiddling around with frameworks. At least that's my opinion. On Tue, Sep 7, 2010 at 2:03 PM, Kevin Wright <kev.lee.wri...@gmail.com> wrote: > This is hardly a new argument! > > Thankfully, there a people around who *are* willing to take risks and > believe in the potential for improvement. > > The world is littered with stories of technologies that were ahead of > their time. Just look at the history of aviation, and how Frank > Whittle had to develop the jet engine despite a lack of military > funding. The people who could have helped found it impossible to > imagine that you could improve on something like the Spitfire. > > Thankfully for us, they were wrong. > > > On Tuesday, September 7, 2010, Glenn Bech <glenn.b...@gmail.com> wrote: >>>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. >> >> Amen! The best thing for producitivity is to stick in one technology, >> get to know it well, and use it project after project. >> I often see no, or little cost/benefit analysis when adopting new >> frameworks or technology. >> >> I've never seen a team deliver value faster than on a stack of Struts >> 1, Hibernate 3 and Jetty/Tomcat. >> >> On Thu, Sep 2, 2010 at 2:36 PM, Liam Knox <liamjk...@gmail.com> wrote: >>> 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 <kev.lee.wri...@gmail.com> >>> wrote: >>>> >>>> >>>> On 29 August 2010 13:19, Liam Knox <liamjk...@gmail.com> 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 > > -- > Kevin Wright > > mail / gtalk / msn : kev.lee.wri...@gmail.com > pulse / 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 javapo...@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. > > -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javapo...@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.
