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 2 of 2 — ← Prev page 1 [2]

#28946

On Thu, 03 Jul 2014 10:25:47 -0700, markspace
<markspace@nospam.nospam> wrote:

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

     I have done that occasionally, too.  Most notably, when I want to
restrict how the data is being accessed.

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

     Quite.

Sincerely,

Gene Wirchenko

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

#28914

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

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

You say that until you see an application with about 15 different 
implementations of a date comparator, some of them plain wrong, some of 
them without a proper way to handle null values (as the Comparator 
above, I'd like to add) and you feel urged to fix them all (checking all 
usages if there is not one case that really needs it the way that looks 
wrong).

Apart from that I find a it more readable by a large margin - and that's 
even more important in my humble opinion.

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]

#28874

On Fri, 27 Jun 2014 20:23:16 -0400, Arne Vajhøj <arne@vajhoej.dk>
wrote, quoted or indirectly quoted someone who said :

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

How does the compiler know that s1 and s2 are strings?  I gather it
must somehow figure it out from the type of lst.

I looked for a new lambda version of Collections.sort, but found
nothing.  I gather there is no special lambda version of
Collections.sort.

If that is all there is to it, how do people write entire books about
this?

-- 
Roedy Green Canadian Mind Products http://mindprod.com
A program is only as good as its worst piece of code.
~ Joshua Cramer

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

#28896

On 6/30/2014 12:08 PM, Roedy Green wrote:
> On Fri, 27 Jun 2014 20:23:16 -0400, Arne Vajhøj <arne@vajhoej.dk>
> wrote, quoted or indirectly quoted someone who said :
>
>> Java 8 code:
>>
>> Collections.sort(lst, (s1,s2) -> s1.length() - s2.length());
>
> How does the compiler know that s1 and s2 are strings?  I gather it
> must somehow figure it out from the type of lst.

Correct.

> I looked for a new lambda version of Collections.sort, but found
> nothing.  I gather there is no special lambda version of
> Collections.sort.

Correct.

But Comparator<> got a new annotation in Java 8.

See:

http://docs.oracle.com/javase/7/docs/api/java/util/Comparator.html

http://docs.oracle.com/javase/8/docs/api/java/util/Comparator.html

> If that is all there is to it, how do people write entire books about
> this?

It is not all there is to it.

But it is a practical example.

Arne

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

#28862

On Fri, 27 Jun 2014 16:50:44 -0700 (PDT), 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?

You feel that this:

new Thread(new Runnable(){
       @Override
       public void run(){
         System.out.println("Hello world one!");
       }
     }).start();
     
isn't more readable than this:

new Thread(() -> System.out.println("Hello world two!")).start();

?

There is no speed advantage to lamdas.

Liebe Gruesse,
		Joerg

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

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

#28873

On Sat, 28 Jun 2014 12:11:43 +0200, Joerg Meier <joergmmeier@arcor.de>
wrote, quoted or indirectly quoted someone who said :

>There is no speed advantage to lamdas.

Would it be a reasonable thing to say that a lambda is just a terser
way to implement an instance of a one-use anonymous class that has a
single method?

-- 
Roedy Green Canadian Mind Products http://mindprod.com
A program is only as good as its worst piece of code.
~ Joshua Cramer

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

#28875

On 6/30/2014 8:50 AM, Roedy Green wrote:
> On Sat, 28 Jun 2014 12:11:43 +0200, Joerg Meier <joergmmeier@arcor.de>
> wrote, quoted or indirectly quoted someone who said :
>
>> There is no speed advantage to lamdas.
>
> Would it be a reasonable thing to say that a lambda is just a terser
> way to implement an instance of a one-use anonymous class that has a
> single method?
>

I think lambdas have some additional restrictions over anonymous 
classes.  You could say that one can think of them that way as a kind of 
introductory description.  But you probably should try to explain the 
differences too.

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

#28887

In article <ch13r992v98u5tqu88i2banltkpsgvhjkr@4ax.com>, Roedy Green 
(see_website@mindprod.com.invalid) says...
> 
> On Sat, 28 Jun 2014 12:11:43 +0200, Joerg Meier <joergmmeier@arcor.de>
> wrote, quoted or indirectly quoted someone who said :
> 
> >There is no speed advantage to lamdas.
> 
> Would it be a reasonable thing to say that a lambda is just a terser
> way to implement an instance of a one-use anonymous class that has a
> single method?

Not quite, even though it looks a lot like it was.
Lambdas don't hold a reference to the enclosing class for example, and 
they open up some new possibilities to find performance compared to 
classes. The current implementation is pretty basic though (first make 
it work, that make it fast). You may have a look at Sergey Kuksenkos 
presentation, he's from the Oracle performance team and he has to know:
http://medianetwork.oracle.com/video/player/2623576348001
I found it pretty interesting.

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]

#28889

In article <MPG.2e1d0dba27ee4d221@202.177.16.121>, Wanja Gayk 
(brixomatic@yahoo.com) says...

[..]
> > Would it be a reasonable thing to say that a lambda is just a terser
> > way to implement an instance of a one-use anonymous class that has a
> > single method?
> 
> Not quite, even though it looks a lot like it was.
[..]
> http://medianetwork.oracle.com/video/player/2623576348001
> I found it pretty interesting.

Sorry, that rather focussed on today's Lambda performance.
This one gives a better overview over the differences to anonymous 
classes:
http://medianetwork.oracle.com/video/player/1785479333001

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]

#28890

Am 01.07.2014 20:46, schrieb Wanja Gayk:
> In article <MPG.2e1d0dba27ee4d221@202.177.16.121>, Wanja Gayk
> (brixomatic@yahoo.com) says...
>
> [..]
>>> Would it be a reasonable thing to say that a lambda is just a terser
>>> way to implement an instance of a one-use anonymous class that has a
>>> single method?
>>
>> Not quite, even though it looks a lot like it was.
> [..]
>> http://medianetwork.oracle.com/video/player/2623576348001
>> I found it pretty interesting.
>
> Sorry, that rather focussed on today's Lambda performance.
> This one gives a better overview over the differences to anonymous
> classes:
> http://medianetwork.oracle.com/video/player/1785479333001
>
> Kind regards,
> Wanja
>

Thanks for the pointer. It appears one way that lambdas differ from 
inner classes is that you are actively discouraged from thinking of 
lambdas as instances of classes (objects). In particular, lambdas seem 
to have no well-defined identity, which is to say among other things one 
cannot meaningfully compare them with equals.

Here‘s a source for this claim: Stuart Marks answer at
http://stackoverflow.com/questions/15221659/java-8-lambda-expression-and-first-class-values
from which I quote:

<quote>
Given that lambdas are converted into objects, they inherit (literally) 
all the characteristics of objects. In particular, objects:

- have various methods like equals, getClass, hashCode, notify, 
toString, and wait
- have an identity hash code
- can be locked by a synchronized block
- can be compared using the == and != and instanceof operators

and so forth. In fact, all of these are irrelevant to the intended usage 
of lambdas. Their behavior is essentially undefined. You can write a 
program that uses any of these, and you will get some result, but the 
result may differ from release to release (or even run to run!).
</quote>

You might also want to see the page „Are lambda expressions objects?“ 
from the Lambda FAQ at
http://www.lambdafaq.org/are-lambda-expressions-objects/

As Brian Goetz has memorably put it (on lambda-dev): 
"Lambdas-are-functions opens doors. Lambdas-are-objects closes them."

So, as far as the intention behind lambdas goes, and also with respect 
to semantics and some technical differences (byte-code, optimization 
potential), it is not reasonable to say that "a lambda is just a terser
way to implement an instance of a one-use anonymous class" - except as a 
first approximation that will serve you well in many circumstances.

-- Sebastian

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

#28892

On 7/1/2014 12:52 PM, Sebastian wrote:

 > it is not reasonable to say that "a lambda is just a terser
 > way to implement an instance of a one-use anonymous class" - except as a
 > first approximation that will serve you well in many circumstances.

Right.  It's often useful to think of them that way, but it isn't 
accurate.  I think it also might be a bad way to introduce lambdas for 
new programmers.  Old timers know what an anonymous inner class is. 
Newbies probably won't.  (Hint for Roedy and his website.)

 > Here‘s a source for this claim: Stuart Marks answer at
 > 
http://stackoverflow.com/questions/15221659/java-8-lambda-expression-and-first-class-values 

 >
 > from which I quote:
 >
 > <quote>
 > SNIP
 > ...Their behavior is essentially undefined...

This is rather inaccurate.  The *behavior* of lambdas is well defined. 
The *implementation* is left to the JVM.

According to the video that Wanja posted, a lambda is just a single 
invoke-dynamic byte code, plus all the types and arguments captured 
thereby.  That's both really well defined, and also not an inner class 
at all.

If I understand that same video correctly, the guts of the example 
lambda presented were implemented by a private static method on the 
"parent" class, not a separate inner class, and so would have no 
distinct type at all.


> As Brian Goetz has memorably put it (on lambda-dev):
> "Lambdas-are-functions opens doors. Lambdas-are-objects closes them."

Yeah, Brian Goetz has been emphasizing that the peculiarities of a 
lambda are for our benefit in the long run, in spite of criticism to the 
contrary.  That goes for the lambdas-aren't-classes thing as well as 
lambdas-aren't-closures as well.

I think people see something weird in Java that they don't understand, 
and they immediately think "it's generics again."  Generics had some 
really unfortunate consequences, especially in the long run, that I 
don't think the expert group foresaw or completely understood.  (In 
their defense, I'm sure they did as good as a job as possible at the time.)

I don't blame folks for being nervous about new stuff introduced into 
Java, but I'm hopeful that the lambda expert group did a more thorough 
job researching possible consequences than what we got with generics.

BTW, reifiable classes/types are on the list of things being looked at 
for Java 9.  Keep your fingers crossed.

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

#29189

markspace schrieb:
>
> I think people see something weird in Java that they don't understand,
> and they immediately think "it's generics again."  Generics had some
> really unfortunate consequences, especially in the long run, that I
> don't think the expert group foresaw or completely understood.  (In
> their defense, I'm sure they did as good as a job as possible at the time.)

Small question: What unfortunate consequence in respect to
generics are people usually refering to? I hear something
similar yesterday.

Bye

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

#29199

On 7/22/2014 5:37 AM, Jan Burse wrote:
> markspace schrieb:
>>
>> I think people see something weird in Java that they don't understand,
>> and they immediately think "it's generics again."  Generics had some
>> really unfortunate consequences, especially in the long run, that I
>> don't think the expert group foresaw or completely understood.  (In
>> their defense, I'm sure they did as good as a job as possible at the
>> time.)
>
> Small question: What unfortunate consequence in respect to
> generics are people usually refering to? I hear something
> similar yesterday.


Oh god, where's my list?

The main issue, for me, is that generics are non-reifiable.  The entire 
generics system is a fiction maintained by the compiler only, and not 
accessible to the runtime JVM.

Creating generic arrays does not work.  This can be a problem when 
writing the guts of a generic class.

Due to erasure, you can't actually cast/type check a generic object. 
The compiler basically throws up its hands and says "sure I guess." 
Then you have to suppress the warning the compiler generates.

It can be extremely complicated to get the parametrized type of an object.

Basically you can look through the section on generics of Effective Java 
2nd ed and see a long list of complications.  The integration into Java 
wasn't (and isn't) really smooth.

Generics are also invariant, which is actually ok, just really confusing 
for folks who are used to covariant type systems.

Project Vahalla (OpenJDK, led by Brian Goetz) is looking at making 
generics reifiable.  It's a huge problem to do, but they're working on 
it just because the current implementation has enough weird corners that 
they want to fix it up.  That Oracle is going to spend the time and 
money to fix it tells you something about the current state of generics.

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

#29202 — Sidetrack on generics (WAS: Re: are lambdas a way to bring functional programming to java?)

On 2014-07-22 19:39, markspace allegedly wrote:
> On 7/22/2014 5:37 AM, Jan Burse wrote:
>> markspace schrieb:
>>>
>>> I think people see something weird in Java that they don't understand,
>>> and they immediately think "it's generics again."  Generics had some
>>> really unfortunate consequences, especially in the long run, that I
>>> don't think the expert group foresaw or completely understood.  (In
>>> their defense, I'm sure they did as good as a job as possible at the
>>> time.)
>>
>> Small question: What unfortunate consequence in respect to
>> generics are people usually refering to? I hear something
>> similar yesterday.
> 
> 
> Oh god, where's my list?
> 
> The main issue, for me, is that generics are non-reifiable.  The entire
> generics system is a fiction maintained by the compiler only, and not
> accessible to the runtime JVM.
> 
> Creating generic arrays does not work.  This can be a problem when
> writing the guts of a generic class.
> 
> Due to erasure, you can't actually cast/type check a generic object. The
> compiler basically throws up its hands and says "sure I guess." Then you
> have to suppress the warning the compiler generates.
> 
> It can be extremely complicated to get the parametrized type of an object.
> 
> Basically you can look through the section on generics of Effective Java
> 2nd ed and see a long list of complications.  The integration into Java
> wasn't (and isn't) really smooth.
> 
> Generics are also invariant, which is actually ok, just really confusing
> for folks who are used to covariant type systems.
> 
> Project Vahalla (OpenJDK, led by Brian Goetz) is looking at making
> generics reifiable.  It's a huge problem to do, but they're working on
> it just because the current implementation has enough weird corners that
> they want to fix it up.  That Oracle is going to spend the time and
> money to fix it tells you something about the current state of generics.

This is all very true. But it being said, I don't think it's a bad thing
it went down like this. I appreciate the restraint with which they
introduced them in the Java language; a restraint which arguably is the
cause of many of the problems you cite. I appreciate the conservatism
and caring caution with which they treat the towering edifice that is
the Java world in general. It is difficult to express exactly why, but
to me at least it makes me more trusting with regards to the things they
actually do introduce.

As far as I could tell, there was some significant resistance to
generics being added to the language altogether in the first place. I
believe the tip-toed first iteration has gone a long way to convincing
critics that it was indeed a beneficial addition to the toolset
(speaking at the very least for myself). And even for those who had been
convinced from the get-go, the half-hearted first iteration might have
provided crucial insights that they might have missed otherwise.

The situation right now is much more promising for a good and "reified"
implementation of generics than it was before. It was a bumpy road, and
it will take a lot of effort and investment to go further, some of it
arguably duplicate. If it even goes further. But I don't think that's a
bad thing. If it even goes further -- the need is less acute than it was
before.

-- 
D.F.

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

#29240 — Re: Sidetrack on generics (WAS: Re: are lambdas a way to bring functional programming to java?)

On 7/22/2014 1:48 PM, Daniele Futtorovic wrote:
> On 2014-07-22 19:39, markspace allegedly wrote:
>> On 7/22/2014 5:37 AM, Jan Burse wrote:
>>> markspace schrieb:
>>>>
>>>> I think people see something weird in Java that they don't understand,
>>>> and they immediately think "it's generics again."  Generics had some
>>>> really unfortunate consequences, especially in the long run, that I
>>>> don't think the expert group foresaw or completely understood.  (In
>>>> their defense, I'm sure they did as good as a job as possible at the
>>>> time.)
>>>
>>> Small question: What unfortunate consequence in respect to
>>> generics are people usually refering to? I hear something
>>> similar yesterday.
>>
>>
>> Oh god, where's my list?
>>
>> The main issue, for me, is that generics are non-reifiable.  The entire
>> generics system is a fiction maintained by the compiler only, and not
>> accessible to the runtime JVM....
>
> This is all very true. But it being said, I don't think it's a bad thing
> it went down like this. I appreciate the restraint with which they
> introduced them in the Java language; a restraint which arguably is the
> cause of many of the problems you cite. I appreciate the conservatism
> and caring caution with which they treat the towering edifice that is
> the Java world in general....

My feelings as well. Java with generics has problems but it's better 
than Java without generics, and better than an incompatible Java with 
better generics.

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

#28895

On 6/30/2014 11:50 AM, Roedy Green wrote:
> On Sat, 28 Jun 2014 12:11:43 +0200, Joerg Meier <joergmmeier@arcor.de>
> wrote, quoted or indirectly quoted someone who said :
>
>> There is no speed advantage to lamdas.
>
> Would it be a reasonable thing to say that a lambda is just a terser
> way to implement an instance of a one-use anonymous class that has a
> single method?

 From 10000 feet: yes.

Arne

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

#29187

On Fri, 27 Jun 2014 16:50:44 -0700 (PDT), gdotone@gmail.com wrote,
quoted or indirectly quoted someone who said :

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

I bought an eBook copy of Java 8 Lambdas: Pragmatic Functional
Programming. I would describe it as lambda immersion.
http://mindprod.com/jgloss/lambda.html
-- 
Roedy Green Canadian Mind Products http://mindprod.com
Science is what we understand well enough to explain to a computer.
Art is everything else we do. 
~ Donald Ervin Knuth (born: 1938-01-10 age: 76)

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

#29398

On Fri, 27 Jun 2014 16:50:44 -0700 (PDT), gdotone@gmail.com wrote,
quoted or indirectly quoted someone who said :

> how does it make the program more readable?


        // create a new HashMap
        final Map<String, Integer> h = new HashMap<>( 149 /* capacity
*/, 0.75f /* loadfactor */ );
        {
        // add some key/value pairs about English measure to the
HashMap
        h.put( "inch", 1 );
        h.put( "foot", 12 );
        h.put( "yard", 36 );
        h.put( "mile", 3760 * 36 );
        }

Compare old style enumerating a HashMap

 out.println( "enumerate all the key/value Entries in the HashMap" );
        for ( Map.Entry<String, Integer> entry : h.entrySet() )
            {
            // prints lines of the form foot=12
            // in effectively random order.
            // this does not require an expensive get lookup to find
the value 
            String key = entry.getKey();
            int value = entry.getValue();
            out.println( "separately: " + key + " " + value );
            }

Lambda style:

 out.println( "enumerate all the key/value Entries in the HashMap
using Java 1.8 lambda dual foreach" );
            h.forEach( ( unit, measure ) -> {
            out.println( unit + " -> " + measure );
            // this effectively creates an anonymous class with an
anonymous method that prints two values.
            // h.forEach traverses the hasMap and calls that method
for each key/value pair.
            // Javac automatically infers the types from the
declaration for h.
  
-- 
Roedy Green Canadian Mind Products http://mindprod.com
The art of strongly-typed language design is largely arranging 
that errors are automatically detected as soon as possible
in the compose, compile, run cycle.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web