can you beat this with your stack? ;-) http://www.rubyinside.com/obie-fernandezs-hashrocket-builds-your-web-app-in-3-days-698.html
On 7 September 2010 13:12, 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" > 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 ♔ <ced...@beust.com> > >>>> > >>>> > >>>> On Sun, Aug 29, 2010 at 12:29 AM, Liam Knox <liamjk...@gmail.com> > 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 javapo...@googlegroups.com. > >>>> To unsubscribe from this group, send email to > >>>> javaposse+unsubscr...@googlegroups.com<javaposse%2bunsubscr...@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<javaposse%2bunsubscr...@googlegroups.com> > . > >>> For more options, visit this group at > >>> http://groups.google.com/group/javaposse?hl=en. > >> > >> > >> > >> -- > >> Kevin Wright > >> > >> mail/google talk: kev.lee.wri...@gmail.com > >> wave: kev.lee.wri...@googlewave.com > >> 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<javaposse%2bunsubscr...@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<javaposse%2bunsubscr...@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<javaposse%2bunsubscr...@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.
