You wish to understand how a program works, it comes with 100s of pages of API-level documentation, all on glossy paper and nicely ring-bound. It also has a >80% coverage rate in unit testing.
So where do you go to understand this thing? Do you RTFM or do you use the source? On 13 September 2010 00:04, Liam Knox <[email protected]> wrote: > 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]<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]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
