>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. >>>> 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. >> >> >> >> -- >> 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. >> 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. > -- 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.
