Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #28858 > unrolled thread

are lambdas a way to bring functional programming to java?

Back to article view | Back to comp.lang.java.programmer

Contents

  are lambdas a way to bring functional programming to java? gdotone@gmail.com - 2014-06-27 16:50 -0700
    Re: are lambdas a way to bring functional programming to java? Arne Vajhøj <arne@vajhoej.dk> - 2014-06-27 20:14 -0400
      Re: are lambdas a way to bring functional programming to java? Arne Vajhøj <arne@vajhoej.dk> - 2014-06-27 20:23 -0400
        Re: are lambdas a way to bring functional programming to java? Wanja Gayk <brixomatic@yahoo.com> - 2014-06-28 14:43 +0200
          Re: are lambdas a way to bring functional programming to java? markspace <markspace@nospam.nospam> - 2014-07-01 14:34 -0700
            Re: are lambdas a way to bring functional programming to java? Arne Vajhøj <arne@vajhoej.dk> - 2014-07-01 22:01 -0400
            Re: are lambdas a way to bring functional programming to java? Wanja Gayk <brixomatic@yahoo.com> - 2014-07-02 20:52 +0200
              Re: are lambdas a way to bring functional programming to java? markspace <markspace@nospam.nospam> - 2014-07-02 13:08 -0700
                Re: are lambdas a way to bring functional programming to java? Wanja Gayk <brixomatic@yahoo.com> - 2014-07-03 03:13 +0200
                Re: are lambdas a way to bring functional programming to java? Joerg Meier <joergmmeier@arcor.de> - 2014-07-06 14:42 +0200
          Re: are lambdas a way to bring functional programming to java? Arne Vajhøj <arne@vajhoej.dk> - 2014-07-01 22:27 -0400
            Re: are lambdas a way to bring functional programming to java? Arne Vajhøj <arne@vajhoej.dk> - 2014-07-01 22:32 -0400
              Re: are lambdas a way to bring functional programming to java? markspace <markspace@nospam.nospam> - 2014-07-01 19:58 -0700
              Re: are lambdas a way to bring functional programming to java? Wanja Gayk <brixomatic@yahoo.com> - 2014-07-02 22:55 +0200
                Re: are lambdas a way to bring functional programming to java? markspace <markspace@nospam.nospam> - 2014-07-02 15:32 -0700
                  Re: are lambdas a way to bring functional programming to java? Gene Wirchenko <genew@telus.net> - 2014-07-03 09:45 -0700
            Re: are lambdas a way to bring functional programming to java? leif.roar@invalid.com (Leif Roar Moldskred) - 2014-07-01 23:48 -0500
              Re: are lambdas a way to bring functional programming to java? Wanja Gayk <brixomatic@yahoo.com> - 2014-07-02 22:55 +0200
                Re: are lambdas a way to bring functional programming to java? Gene Wirchenko <genew@telus.net> - 2014-07-03 09:49 -0700
                  Re: are lambdas a way to bring functional programming to java? markspace <markspace@nospam.nospam> - 2014-07-03 10:25 -0700
                    Re: are lambdas a way to bring functional programming to java? Gene Wirchenko <genew@telus.net> - 2014-07-04 11:03 -0700
            Re: are lambdas a way to bring functional programming to java? Wanja Gayk <brixomatic@yahoo.com> - 2014-07-02 21:23 +0200
        Re: are lambdas a way to bring functional programming to java? Roedy Green <see_website@mindprod.com.invalid> - 2014-06-30 09:08 -0700
          Re: are lambdas a way to bring functional programming to java? Arne Vajhøj <arne@vajhoej.dk> - 2014-07-01 21:56 -0400
    Re: are lambdas a way to bring functional programming to java? Joerg Meier <joergmmeier@arcor.de> - 2014-06-28 12:11 +0200
      Re: are lambdas a way to bring functional programming to java? Roedy Green <see_website@mindprod.com.invalid> - 2014-06-30 08:50 -0700
        Re: are lambdas a way to bring functional programming to java? markspace <markspace@nospam.nospam> - 2014-06-30 09:09 -0700
        Re: are lambdas a way to bring functional programming to java? Wanja Gayk <brixomatic@yahoo.com> - 2014-07-01 19:27 +0200
          Re: are lambdas a way to bring functional programming to java? Wanja Gayk <brixomatic@yahoo.com> - 2014-07-01 20:46 +0200
            Re: are lambdas a way to bring functional programming to java? Sebastian <news@seyweiler.dyndns.org> - 2014-07-01 21:52 +0200
              Re: are lambdas a way to bring functional programming to java? markspace <markspace@nospam.nospam> - 2014-07-01 14:11 -0700
                Re: are lambdas a way to bring functional programming to java? Jan Burse <janburse@fastmail.fm> - 2014-07-22 14:37 +0200
                  Re: are lambdas a way to bring functional programming to java? markspace <markspace@nospam.nospam> - 2014-07-22 10:39 -0700
                    Sidetrack on generics (WAS: Re: are lambdas a way to bring functional programming to java?) Daniele Futtorovic <da.futt.news@laposte.net> - 2014-07-22 20:48 +0200
                      Re: Sidetrack on generics (WAS: Re: are lambdas a way to bring functional   programming to java?) Chris Riesbeck <Chris.Riesbeck@gmail.com> - 2014-07-23 12:01 -0500
        Re: are lambdas a way to bring functional programming to java? Arne Vajhøj <arne@vajhoej.dk> - 2014-07-01 21:50 -0400
    Re: are lambdas a way to bring functional programming to java? Roedy Green <see_website@mindprod.com.invalid> - 2014-07-22 04:40 -0700
    Re: are lambdas a way to bring functional programming to java? Roedy Green <see_website@mindprod.com.invalid> - 2014-07-28 09:45 -0700

Page 1 of 2  [1] 2  Next page →

#28858 — are lambdas a way to bring functional programming to java?

lambdas: why would you want a function that has no name? how does it make the program more readable? couldn't the speed obtain from lambdas be handle in the compiler?

[toc] | [next] | [standalone]

#28859

On 6/27/2014 7:50 PM, gdotone@gmail.com wrote:
> lambdas: why would you want a function that has no name? how does it make the program more readable? couldn't the speed obtain from lambdas be handle in the compiler?

Lambdas are not about speed but about a more compact and in some
cases also more natural syntax.

Arne

[toc] | [prev] | [next] | [standalone]

#28860

On 6/27/2014 8:14 PM, Arne Vajhøj wrote:
> On 6/27/2014 7:50 PM, gdotone@gmail.com wrote:
>> lambdas: why would you want a function that has no name? how does it
>> make the program more readable? couldn't the speed obtain from lambdas
>> be handle in the compiler?
>
> Lambdas are not about speed but about a more compact and in some
> cases also more natural syntax.

In general I do not subscribe to the shorter code = better
code paradigm. Not at all.

But there are cases where the old way just added boilerplate that
made the code less readable.

Here is a simple example.

Java 7 code:

Collections.sort(lst, new Comparator<String>() {
     public int compare(String s1, String s2) {
         return s1.length() - s2.length();
     }
});

Java 8 code:

Collections.sort(lst, (s1,s2) -> s1.length() - s2.length());

I do not see any value in the extra code in the 7 version.

Arne

[toc] | [prev] | [next] | [standalone]

#28863

In article <53ae0af4$0$302$14726298@news.sunsite.dk>, Arne Vajhøj 
(arne@vajhoej.dk) says...

> Here is a simple example.
> 
> Java 7 code:
> 
> Collections.sort(lst, new Comparator<String>() {
>      public int compare(String s1, String s2) {
>          return s1.length() - s2.length();
>      }
> });
> 
> Java 8 code:
> 
> Collections.sort(lst, (s1,s2) -> s1.length() - s2.length());
> 
> I do not see any value in the extra code in the 7 version.

I fear Java8's Lambdas may not encourage reuse so much as the Java 7 
way. This does seem to be a pretty standard comparator, so I would 
probably code it this way:

static final Comparator<String> COMPARE_BY_LENGTH = new Comparator<>{
      public int compare(String s1, String s2) {
          return s1.length() - s2.length();
      }
 });

Collections.sort(lst, COMPARE_BY_LENGTH);

Just because using it looks better.
Of course in Java 8 it could look like this (sorry for the bad line 
breaks:

static final Comparator<String> COMPARE_BY_LENGTH 
              = (s1,s2) -> s1.length() - s2.length()

Collections.sort(lst, COMPARE_BY_LENGTH);

..or even implementing a more general interface.
But would people do that very often, if the original expression is so 
concise? Hmm..

Kind regards,
Wanja

-- 
..Alesi's problem was that the back of the car was jumping up and down 
dangerously - and I can assure you from having been teammate to 
Jean Alesi and knowing what kind of cars that he can pull up with, 
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#28893

On 6/28/2014 5:43 AM, Wanja Gayk wrote:
 >
 > static final Comparator<String> COMPARE_BY_LENGTH
 >                = (s1,s2) -> s1.length() - s2.length()
 >
 > Collections.sort(lst, COMPARE_BY_LENGTH);

In that video you just posted featuring Brian Goetz talking about 
lambdas, Mr. Goetz says this is a bad idea.  This costs a static field 
and the time it takes to initialize the field during startup.  And you 
may never use that field, so you just spent time initializing unnecessarily.

> In article <53ae0af4$0$302$14726298@news.sunsite.dk>, Arne Vajhøj

 >> Java 8 code:
 >>
 >> Collections.sort(lst, (s1,s2) -> s1.length() - s2.length());
 >>

Whereas this code above seems to be "better" because the runtime 
compiler can hoist the lambda out of the method call and cache it, just 
like you did manually, but the compiler can do it lazily at runtime, and 
won't do it at all if it's never needed.

If you must have a named variable, I think this might be as good as the 
single line technique.

{
   ...
   final Comparator<String> byLength = (s1,s2) -> s1.length()
     - s2.length();
   Collections.sort( lst, byLength );
}

(Not compiled or tested.)

100% speculation by me, but a bit informed by just having watched Mr. 
Goetz on video.

[toc] | [prev] | [next] | [standalone]

#28897

On 7/1/2014 5:34 PM, markspace wrote:
> On 6/28/2014 5:43 AM, Wanja Gayk wrote:
>  >
>  > static final Comparator<String> COMPARE_BY_LENGTH
>  >                = (s1,s2) -> s1.length() - s2.length()
>  >
>  > Collections.sort(lst, COMPARE_BY_LENGTH);
>
> In that video you just posted featuring Brian Goetz talking about
> lambdas, Mr. Goetz says this is a bad idea.  This costs a static field
> and the time it takes to initialize the field during startup.  And you
> may never use that field, so you just spent time initializing
> unnecessarily.

Not likely to be significant in my very humble opinion.

>> In article <53ae0af4$0$302$14726298@news.sunsite.dk>, Arne Vajhøj
>
>  >> Java 8 code:
>  >>
>  >> Collections.sort(lst, (s1,s2) -> s1.length() - s2.length());
>  >>
>
> Whereas this code above seems to be "better" because the runtime
> compiler can hoist the lambda out of the method call and cache it, just
> like you did manually, but the compiler can do it lazily at runtime, and
> won't do it at all if it's never needed.

I like it because it is simple - it only contains the core
logic - no extra "unnecessary" boilerplate code.

I think most people will consider that more readable - at least
after getting used to the syntax.

It happened in the C# world - I expect it to happen in the Java world
as well.

Arne

[toc] | [prev] | [next] | [standalone]

#28913

In article <lov9gd$9ri$1@dont-email.me>, markspace 
(markspace@nospam.nospam) says...
> 
> On 6/28/2014 5:43 AM, Wanja Gayk wrote:
>  >
>  > static final Comparator<String> COMPARE_BY_LENGTH
>  >                = (s1,s2) -> s1.length() - s2.length()
>  >
>  > Collections.sort(lst, COMPARE_BY_LENGTH);
> 
> In that video you just posted featuring Brian Goetz talking about 
> lambdas, Mr. Goetz says this is a bad idea.  This costs a static field 
> and the time it takes to initialize the field during startup.  And you 
> may never use that field, so you just spent time initializing unnecessarily.

I don't care for some few bytes and nanoseconds wasted, if not wasting 
them means "bad to read" and "bad to reuse". If my profiler tells me 
that this little extra causes a problem, then I'd be happy to go another 
route, until them I'm happy to waste some on maintainance costs that 
usually trump runtime costs my a large margin.

Kind regards,
Wanja

-- 
..Alesi's problem was that the back of the car was jumping up and down 
dangerously - and I can assure you from having been teammate to 
Jean Alesi and knowing what kind of cars that he can pull up with, 
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#28915

On 7/2/2014 11:52 AM, Wanja Gayk wrote:

> If my profiler tells me
> that this little extra causes a problem, then I'd be happy to go another
> route, until them I'm happy to waste some on maintainance costs that
> usually trump runtime costs my a large margin.


Just to continue some discussion, and not trying to be argumentative 
here, but I think the idea is that a lot of static initializes will 
eventually added up to a problem.

Obviously your profiler will tell you that one line of code is not a 
problem.  One line of code never is.  It's poor planning, lack of 
standards and the huge ball of mud that results when "non-problems" are 
spread throughout a large code base.

I think I'd call this idea "micro-profiling," similar to 
micro-benchmarking.  You have to consider the system as a whole, as a 
long range project.  Complicated static initializers are a known issue; 
  we've definitely bumped into that problem before (I think mainly with 
too many { static Logger log = Logger.getLogger("fubar"); }).  I'm just 
trying emphasize best practice, which to avoid static initializers where 
not needed.

[toc] | [prev] | [next] | [standalone]

#28926

In article <lp1osi$87h$1@dont-email.me>, markspace 
(markspace@nospam.nospam) says...

> I think I'd call this idea "micro-profiling," similar to 
> micro-benchmarking.  You have to consider the system as a whole, as a 
> long range project.  Complicated static initializers are a known issue; 
>   we've definitely bumped into that problem before (I think mainly with 
> too many { static Logger log = Logger.getLogger("fubar"); }).  I'm just 
> trying emphasize best practice, which to avoid static initializers where 
> not needed.

I'm not desperately in love with static initializers, so I wouldn't mind 
if one used a factory method instead. The point is sharing and naming an 
implementation.

Kind regards,
Wanja

-- 
..Alesi's problem was that the back of the car was jumping up and down 
dangerously - and I can assure you from having been teammate to 
Jean Alesi and knowing what kind of cars that he can pull up with, 
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#28960

On Wed, 02 Jul 2014 13:08:46 -0700, markspace wrote:

> I think the idea is that a lot of static initializes will 
> eventually added up to a problem.

> Obviously your profiler will tell you that one line of code is not a 
> problem.  One line of code never is.  It's poor planning, lack of 
> standards and the huge ball of mud that results when "non-problems" are 
> spread throughout a large code base.

> I think I'd call this idea "micro-profiling," similar to 
> micro-benchmarking.  You have to consider the system as a whole, as a 
> long range project.

That reminds me of discussions of boot time optimizations - 'very smart'
people used to rant about how they were pointless, because every little
piece only shaved off half a second each, which nobody could possibly
notice, ignoring that when you add up a dozen things that shave off half
seconds, you end up with a bunch of whole seconds.

Liebe Gruesse,
		Joerg

-- 
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

[toc] | [prev] | [next] | [standalone]

#28898

On 6/28/2014 8:43 AM, Wanja Gayk wrote:
> In article <53ae0af4$0$302$14726298@news.sunsite.dk>, Arne Vajhøj
> (arne@vajhoej.dk) says...
>
>> Here is a simple example.
>>
>> Java 7 code:
>>
>> Collections.sort(lst, new Comparator<String>() {
>>       public int compare(String s1, String s2) {
>>           return s1.length() - s2.length();
>>       }
>> });
>>
>> Java 8 code:
>>
>> Collections.sort(lst, (s1,s2) -> s1.length() - s2.length());
>>
>> I do not see any value in the extra code in the 7 version.
>
> I fear Java8's Lambdas may not encourage reuse so much as the Java 7
> way. This does seem to be a pretty standard comparator, so I would
> probably code it this way:
>
> static final Comparator<String> COMPARE_BY_LENGTH = new Comparator<>{
>        public int compare(String s1, String s2) {
>            return s1.length() - s2.length();
>        }
>   });
>
> Collections.sort(lst, COMPARE_BY_LENGTH);
>
> Just because using it looks better.
> Of course in Java 8 it could look like this (sorry for the bad line
> breaks:
>
> static final Comparator<String> COMPARE_BY_LENGTH
>                = (s1,s2) -> s1.length() - s2.length()
>
> Collections.sort(lst, COMPARE_BY_LENGTH);
>
> ..or even implementing a more general interface.
> But would people do that very often, if the original expression is so
> concise? Hmm..

I look at it a bit differently: the introduction of lambda
makes the benefits of reusing close to zero and we only like
reuse when it actually has benefits, so I do not see it as
a problem.

Arne

[toc] | [prev] | [next] | [standalone]

#28899

On 7/1/2014 10:27 PM, Arne Vajhøj wrote:
> On 6/28/2014 8:43 AM, Wanja Gayk wrote:
>> In article <53ae0af4$0$302$14726298@news.sunsite.dk>, Arne Vajhøj
>> (arne@vajhoej.dk) says...
>>
>>> Here is a simple example.
>>>
>>> Java 7 code:
>>>
>>> Collections.sort(lst, new Comparator<String>() {
>>>       public int compare(String s1, String s2) {
>>>           return s1.length() - s2.length();
>>>       }
>>> });
>>>
>>> Java 8 code:
>>>
>>> Collections.sort(lst, (s1,s2) -> s1.length() - s2.length());
>>>
>>> I do not see any value in the extra code in the 7 version.
>>
>> I fear Java8's Lambdas may not encourage reuse so much as the Java 7
>> way. This does seem to be a pretty standard comparator, so I would
>> probably code it this way:
>>
>> static final Comparator<String> COMPARE_BY_LENGTH = new Comparator<>{
>>        public int compare(String s1, String s2) {
>>            return s1.length() - s2.length();
>>        }
>>   });
>>
>> Collections.sort(lst, COMPARE_BY_LENGTH);
>>
>> Just because using it looks better.
>> Of course in Java 8 it could look like this (sorry for the bad line
>> breaks:
>>
>> static final Comparator<String> COMPARE_BY_LENGTH
>>                = (s1,s2) -> s1.length() - s2.length()
>>
>> Collections.sort(lst, COMPARE_BY_LENGTH);
>>
>> ..or even implementing a more general interface.
>> But would people do that very often, if the original expression is so
>> concise? Hmm..
>
> I look at it a bit differently: the introduction of lambda
> makes the benefits of reusing close to zero and we only like
> reuse when it actually has benefits, so I do not see it as
> a problem.

BTW somewhat off-topic, I do not like the COMPARE_BY_LENGTH thingy.

It is almost like:

public static final int TWO = 2;

* The name does not really explain more than the value
* The value is given by the name so the value can never be changed
   without changing the name

The paradigm actually creates more work when something has to be
changed without improving readability.

Obviously we could have COMPARE_BY_XYZ where XYZ is something
business logic related - that we may want to change the semantics
for.

Arne

[toc] | [prev] | [next] | [standalone]

#28902

On 7/1/2014 7:32 PM, Arne Vajhøj wrote:

>> On 6/28/2014 8:43 AM, Wanja Gayk wrote:
>>>
>>> static final Comparator<String> COMPARE_BY_LENGTH
>>>                = (s1,s2) -> s1.length() - s2.length()
>>>
>>> Collections.sort(lst, COMPARE_BY_LENGTH);

> BTW somewhat off-topic, I do not like the COMPARE_BY_LENGTH thingy.
>
> It is almost like:
>
> public static final int TWO = 2;

Just my two bits (heh):  This is a refactoring called Introduce 
Explaining Variable.

http://refactoring.com/catalog/extractVariable.html

(The bottom of that page explains that Martin Fowler has changed the 
name of his refactoring pattern to Extract Variable.)

The idea is to make the code easier to read by naming explicitly what is 
being done.  It isn't always obvious that length() - length() compares 
two values in ascending order ("natural order", I guess).  So by making 
it explicit you avoid adding a short comment like:

   // sort by natural order by lengths

It's "literate code" vs. "lots o' comments."  Depends which you like I 
suppose.  The refactored approach has some advantages.  Shorter line 
lengths is often one of them.  Easier to add more code, add debugging 
code or view the value in a debugger are others.

[toc] | [prev] | [next] | [standalone]

#28916

In article <53b36f49$0$293$14726298@news.sunsite.dk>, Arne Vajhøj 
(arne@vajhoej.dk) says...

> BTW somewhat off-topic, I do not like the COMPARE_BY_LENGTH thingy.
> 
> It is almost like:
> 
> public static final int TWO = 2;

> * The name does not really explain more than the value
> * The value is given by the name so the value can never be changed
>    without changing the name

That argument applies to every method you're writing: 
* A method's name cannot explain than the code it encapsulates
* If you change what a method does, you need to change the name of the 
method.
So should we stop writing methods and just copy-paste the code to every 
corner of the program that would call it to get rid of that "problem" 
then? Of course not.
But that's exactly what you're asking for. 
Lambdas are essentially blocks of code, and the DRY principle should 
apply to them like for every other block of code.

> The paradigm actually creates more work when something has to be
> changed without improving readability.

That example is not very good in my opinion, and it doesn't compare 
well, as the right hand side in your "TWO" example doesn't do a thing 
and there is no margin for error and no benefit of reuse, ever.

No margin for error? But the other code was so simple it had none 
either.. sure, not in a string (well, there's always an NPE waiting, but 
let's ignore that), but what if your comparator looked like this:

(Amount a, Amount b) -> a.value() - b.value();

which you might think is simple enough to copy-paste everywhere...

Now imagine a.value() happened to be Integer.MIN_VALUE and b.value() 
happened to be 10 then the result would be positive, thus indiciating a 
was larger than b, which is obviously wrong. So this code, as simple as 
it is, and as obvious as it looks, has a bug. Bummer.

Now, if that block of code would have been re-used from a single 
location (like a lambda or class in a static field, a method, or so), 
then you would correct that exactly once and every code that used it 
would be happy and fixed.
If, however, you copy-pasted it everywhere, as it was "too simple to be 
beneficial", as you might say, you'd have to check every Amount#value() 
call and see if it was used in this fashion, which is a PITA and you 
don't want that.

Kind regards,
Wanja

-- 
..Alesi's problem was that the back of the car was jumping up and down 
dangerously - and I can assure you from having been teammate to 
Jean Alesi and knowing what kind of cars that he can pull up with, 
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#28920

On 7/2/2014 1:55 PM, Wanja Gayk wrote:

> (Amount a, Amount b) -> a.value() - b.value();
>
> which you might think is simple enough to copy-paste everywhere...
   SNIP
> If, however, you copy-pasted it everywhere, as it was "too simple to be
> beneficial", as you might say, you'd have to check every Amount#value()
> call and see if it was used in this fashion, which is a PITA and you
> don't want that.

This is a slippery slope however.  The actual expression you are 
referring to, a simple binary operation, gets used throughout programs 
all the time.  Should I decide that every simple use of a built-in 
operator is in need of its own method, which must be reused by every 
class in an entire codebase?  Surely this is over-engineering, and just 
as bad practice as "copy-and-paste everything" was.

(I realize you may not mean that we should encapsulate all built-in 
operators, but based on what your wrote above, well, that's literally 
what you said.)

I think what is best practice here is unit testing.  Given that you 
naively compare two integers by subtracting them, then you should be in 
the habit of testing your code by verifying it's correct with a variety 
of values.  Experience says that the corner cases/end points (MIN, MAX, 
-1, 0, 1) should certainly be tested against each other.

Also, if you often compare two Amounts by value, an instance method is 
probably best practice:

   @Override
   int compareTo( Amount other ) {
     return Integer.compare( this.value, other.value );
   }

But lambdas tend to be local, ad hoc expressions that shouldn't be 
generally applicable to the larger codebase (else they possibly should 
be considered for reuse).

[toc] | [prev] | [next] | [standalone]

#28935

On Wed, 02 Jul 2014 15:32:32 -0700, markspace
<markspace@nospam.nospam> wrote:

[snip]

>I think what is best practice here is unit testing.  Given that you 
>naively compare two integers by subtracting them, then you should be in 
>the habit of testing your code by verifying it's correct with a variety 
>of values.  Experience says that the corner cases/end points (MIN, MAX, 
>-1, 0, 1) should certainly be tested against each other.

     Sure.  And consider Wanja Gayk's example adjusted just a bit:

Now imagine a.value() happened to be Integer.MIN_VALUE + 1 and
b.value() happened to be 10 then the result would be positive, thus
indiciating a was larger than b, which is obviously wrong. So this
code, as simple as it is, and as obvious as it looks, has a bug.
Bummer.

     (My only change was adding the "+ 1".)

     There are a lot more cases that can bite.

[snip]

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#28904

Arne Vajhøj <arne@vajhoej.dk> wrote:
> 
> I look at it a bit differently: the introduction of lambda
> makes the benefits of reusing close to zero and we only like
> reuse when it actually has benefits, so I do not see it as
> a problem.
> 

Personally, I've reached the point where I often consciously _avoid_
reusing code in some instances, both to avoid adding more dependencies
to a project but also in order to keep the program logic "close"
instead of spread throughout umpteen files and over multiple levels of
abstraction.

-- 
Leif Roar Moldskred

[toc] | [prev] | [next] | [standalone]

#28917

In article <ZrOdnS5GKZ-PEi7OnZ2dnUVZ8hudnZ2d@giganews.com>, Leif Roar 
Moldskred (leif.roar@invalid.com) says...
> 
> Arne Vajhøj <arne@vajhoej.dk> wrote:
> > 
> > I look at it a bit differently: the introduction of lambda
> > makes the benefits of reusing close to zero and we only like
> > reuse when it actually has benefits, so I do not see it as
> > a problem.
> > 
> 
> Personally, I've reached the point where I often consciously _avoid_
> reusing code in some instances, both to avoid adding more dependencies
> to a project but also in order to keep the program logic "close"
> instead of spread throughout umpteen files and over multiple levels of
> abstraction.

I happened to work for a project where the architect urged us to copy 
and paste the code for every view, as he said: "if something breaks in 
one view, then it won't affect the others" and he had stability in mind, 
obviously. Wanted to keep everything seperated as much as possible.
I told him that was a wrong approach, but he wouldn't listen. He had to 
learn it the hard way: Whenever something failed in one view, we had to 
find the same patterns in all the other views and fix them too - and 
ocasionally we forgot one, which causes more havoc than necessary (the 
customer was not amused).

And of course as code evolved all of these views drifted apart, so 
finding and fixing these bugs was becoming ever more difficult.
It took some time to him to see that I was right and why I was right: 
The parts where I (ignoring him) made heavy reuse were better to 
maintain. Sure, a bug in a resused part affected every view, but that 
meant the bug also surfaced faster, so it could be fixed. And fixing it 
once instead of 30 times was reasonably faster as well. 

When he finally changed his mind and started embracing heavy code reuse, 
it was practically too late for comfort. Refactoring became 
unnecessarily hard and while I was there, we never arrived at a point 
that I thought was halfway where we wanted to be.

Of course I do tend to copy-paste-modify too, but only until I see a 
clear pattern emerge and I'm confident enough I won't not missing 
something important or lock myself in, when I start weeding out the 
duplications. You must not wait too long, or it'll be too late.

Kind regards,
Wanja

-- 
..Alesi's problem was that the back of the car was jumping up and down 
dangerously - and I can assure you from having been teammate to 
Jean Alesi and knowing what kind of cars that he can pull up with, 
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#28936

On Wed, 2 Jul 2014 22:55:42 +0200, Wanja Gayk <brixomatic@yahoo.com>
wrote:

[snip]

>Of course I do tend to copy-paste-modify too, but only until I see a 
>clear pattern emerge and I'm confident enough I won't not missing 
>something important or lock myself in, when I start weeding out the 
>duplications. You must not wait too long, or it'll be too late.

     A fine line at times.

     In the client billing system that I wrote and maintain, I have a
lot of what most would call cut-and-paste code.  They are very short
segments.  In some cases, calling a properly parameterised subroutine
would take more code than the section of code that would be replaced.

     The segments are obvious (well, so far) and execute in a larger
context (which is why setting up calls for equivalent subroutine
functionality would bloat the code).

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#28937

On 7/3/2014 9:49 AM, Gene Wirchenko wrote:
>
>       A fine line at times.
>
>       In the client billing system that I wrote and maintain, I have a
> lot of what most would call cut-and-paste code.  They are very short
> segments.  In some cases, calling a properly parameterised subroutine
> would take more code than the section of code that would be replaced.


And I have taken short expressions with only a couple of operators, and 
given them their own method call, arguably taking more code (or at least 
line width) than the expression itself.  I did it because the little 
buggers confused me, and giving them their own named method made the 
code easier to follow, not because it made the code shorter.  But in the 
end I felt the change to a method call was totally correct.

It's a fine line, and judgement and experience are important.  Not to 
mention flexibility;  Wanja's example of a shop that refused to modify 
its coding policy until it was obviously counterproductive (and far too 
late to matter) is a great example of institutional inflexibility.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web