Liam,
That depends in which direction the verbosity goes. If it serves to
explain your code better, like explaining variables do, then fine. If
it's just pointless verbosity, like new Runnable() { public void run()
{ then it harms the readability.
In a different context, imagine you're marking mathematics examination
papers. One student shows their working in a long multiplication, in
the usual way. The other prepends 00000000 to every number, or
converts everything to hex for the calculation and back to decimal at
the end. It will probably take you longer to tell whether the second
student's working is correct.
(I suppose converting to hex would be pointless brevity as hex tends
to need fewer digits, but I'm sure you get the point)
} }
Ricky.
--
Ricky Clarkson
Java and Scala Programmer, AD Holdings
+44 1928 706373
Skype: ricky_clarkson
On Mon, Sep 13, 2010 at 12:04 AM, 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].
>>>>> > 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.
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> 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.
>>>
>>> --
>>> 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.
>>
>>
>>
>> --
>> 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.
>
> --
> 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.
>
--
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.
