Don't buy it. You are saying Java is bad because it is too verbose. What I am saying verbosity or conciseness is not the real reason code is understandable or not, there a lot more to it than that.
On Sun, Sep 12, 2010 at 5:04 PM, Kevin Wright <[email protected]>wrote: > If anything, I thing the misunderstanding goes the other direction. > > There's a belief that all concise code will automatically be as unreadable > as badly-written perl, and that the extra boilerplate somehow acts as a > safety-net. > I've seem opinions on this list believing that you're bound to do something > wrong if you don't re-iterate every 2 lines that you're working with lists > of Ints. > > I'll also offer the counter-argument that verbosity doesn't imply > readability, understandably or maintainability either. Often burying these > ideals in spaghetti code and duplication. > > One common technique to remove boilerplate is to throw away types entirely, > in the process also losing information that's very valuable to helping you > understand the code. > Perhaps the problem is not conciseness as such, but the fact that languages > described as concise also tend to be dynamically typed. > Other than maybe C# (since v3), I imagine that most developers on this list > won't have been exposed to a language that uses inference instead of dynamic > typing. > > > > On 12 September 2010 02:41, Liam Knox <[email protected]> wrote: > >> There is a massive misunderstanding in the verbose vs conciseness >> argument. Conciseness does not naturally imply readability, >> understandability or maintainability, and these are the real important >> aspects in software development. I have equally seen verbose and concise >> code that has succeeded and failed in these areas and that has been down to >> the developer not the language. I would also argue against the DSL's to a >> point. Again if you look at the larger picture DSL's can exponentially >> increase the surface areas in projects, yet another mini language to >> understand and often implemented by people who have little experience in >> this area. >> >> When you are looking at macro levels I think developers need to be >> pragmatic in their choices, in what works best for team/firm, the existing >> technologies in use and what the impact of adoption a new technology is. >> >> We can all play God and compare languages based on our personal aesthetics >> but that, in many ways, is missing the point completely. >> >> >> On Tue, Sep 7, 2010 at 10:34 PM, Kevin Wright >> <[email protected]>wrote: >> >>> And therein lies the crux of the debate. :) >>> >>> The problem is that Java is too verbose, laden with boilerplate, and >>> poorly suited to a natural expression of several concepts that we find >>> incredibly easy to think about. >>> One of these two examples is easier to comprehend: >>> >>> //Java >>> List newList = new ArrayList<Integer> >>> for(Integer item : oldList) { >>> newList.add(item * 2) >>> } >>> >>> //Scala >>> val newList = oldList map {_ * 2} >>> >>> The concept is "double every item in a list", and I believe the Scala >>> example comes far closer to expressing the underlying idea. >>> Java can do some of this, through google collections or lambdaJ, but >>> neither solution is as elegant as Scala's, or as easy to combine with other >>> language features. >>> >>> I want to create software that more closely matches how I'm thinking >>> about that software. That's a benefit, it makes it easier to write and, >>> crucially, much easier to read. >>> Developers who come after me will be able to read what I *meant*, not >>> what I was forced to write so that I might satisfy the compiler. >>> >>> I'll happily go to the extra effort of writing rich Scala APIs/DSLs, with >>> operator overloading, type classes, implicits, etc. If that means that code >>> using such a library them becomes easier to read/write/maintain. >>> >>> To me "just creating software" is about using tools that are as >>> natural-feeling as possible, not about struggling with >>> complicated/nonintuitive frameworks, regardless of how well I may have >>> memorised them. >>> >>> >>> On 7 September 2010 14:18, Glenn Bech <[email protected]> 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. >>>> >>>> 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 <[email protected]> >>>> 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 <[email protected]> >>>> 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 <[email protected]> >>>> 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 < >>>> [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 >>>> > >>>> > -- >>>> > Kevin Wright >>>> > >>>> > mail / gtalk / msn : [email protected] >>>> > 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 [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 / gtalk / msn : [email protected] >>> 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 [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 / gtalk / msn : [email protected] > 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 [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.
