Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Java 8 Lambdas

datumedge.blogspot.co.uk

Post reply on HN
Print view View original

71–80 of 144 posts

Re: Java 8 Lambdas

#71

Post by mccoyst »

mbel wrote: post #69

The idea of 'default methods' looks quite disturbing. It seems to allow implementation of some methods inside interfaces. Which is against the basic idea of interface, isn't it? Correct me if I'm wrong, but multiple inheritance problems form C++ are now going to be a brand new feature in Java.

There's no difference between implementing method dispatch with multiple inheritance versus multiple interfaces. What do you think C++'s multiple inheritance problems are? As long as Oracle doesn't add data members to interfaces, Java won't get any new problems.

Re: Java 8 Lambdas

#72

Post by bsg75 »

diego_moita wrote: post #23
flatline3 wrote: post #22

Earlier quoted context omitted.

Java is still widely used. I'm looking forward to this -- there are some projects we can't take to Scala due to client concerns around a less mainstream language.

> Java is still widely used. I'm looking forward to this -- there are some projects we can't take to Scala due to client concerns around a less mainstream language. I hope I am wrong but I smell a trap here. Some time ago I implemented a solution (for .Net, that is) that employed some more modern techniques ( reflection, recursive lambdas, etc). Unfortunately many of the programmers in charge of maintaining my code w…

Programming by the lowest bidder rarely results in quality.

Re: Java 8 Lambdas

#73

Post by gouranga »

jmcqk6 wrote: post #63
gouranga wrote: post #54

Earlier quoted context omitted.

I don't think that they reduce bugs at all - that's a bit of a wired assertion to make. Its not about the programmers but the architecture. To be honest, the primary use case for lambda expressions in .net is LINQ and possibly container configuration. If you use NHibernate and do not expose IEnumerable anywhere (which is required across network boundaries and encapsulation boundaries) then you just don't see it anywh…

I think the implication here is that if they require fewer lines of code, they are going to reduce the number of bugs. Regarding LINQ: is there any .NET app out there that isn't using IEnumerable at some point? I can't recall every writing an app that didn't use it, unless it was an extremely simple app. Besides that, Lambdas are very useful in event subscription.

Not necessarily.

   collection.Where(s => s.Property.Name == "Blah!").Single();
4 hand grenades waiting to go off in that expression. Try and spot them.

We have a 670kloc platform that doesn't have a single one in it (it's still .Net 2.0). 450 domain objects, 1000+ NH criteria queries and about 650 aspx pages...

Re: Java 8 Lambdas

#74

Post by gouranga »

Retric wrote: post #43
gouranga wrote: post #34

Earlier quoted context omitted.

I think you are mistaken. For 99%+ of business level code which wires up pre-built J2EE components and builds domain models, then you simply don't need them. Even in C# for example, I've seen huge systems written in .Net 4.0 without a single lambda being required.

There is a difference between required and useful, I can build a house without using a hammer, but that does not mean there useless.

Also just because I have a hammer, it doesn't mean every problem is a nail.

Re: Java 8 Lambdas

#75

Post by gouranga »

kmontrose wrote: post #66
gouranga wrote: post #37

Earlier quoted context omitted.

Agreed and it's an order of magnitude better than extension methods which .Net uses for the same functionality!

C# extension methods are used for considerably more than adding new methods to existing interfaces, though that is a valid use of them. They also don't require you have access to the source (anybody can write an extension method on System.Collections.IEnumerable, not just the BCL team). That they work on any type (not just interfaces) also makes them considerably more general than default implementations. I also find…

The problem I have with extension methods is semantics and determinism, particularly in the collections framework (if you can call it that - it's a mess). Great example:

Look at System.Core's Count() inside reflector. Using pseudo code:

  def count(ref):
      if ref is ICollection:
          return (ref As ICollection).Count
      else
          n = 0
          for each item in ref:
              n++
          return n
That hurts badly if you are not careful. Enumerables will be iterated and collections will return length so when you call it you don't know for certain if it's O(N) or O(1). If someone has downcast ICollection to IEnumerable then you really don't know where you stand.

It's shit like that which is hard to debug and brings your system to its knees.

Re: Java 8 Lambdas

#76

Post by diego_moita »

bad_user wrote: post #29
diego_moita wrote: post #23

Earlier quoted context omitted.

> Java is still widely used. I'm looking forward to this -- there are some projects we can't take to Scala due to client concerns around a less mainstream language. I hope I am wrong but I smell a trap here. Some time ago I implemented a solution (for .Net, that is) that employed some more modern techniques ( reflection, recursive lambdas, etc). Unfortunately many of the programmers in charge of maintaining my code w…

I smell trolling, however considering this anecdote is genuine: (1) interns should never be allowed to commit code in the master branch without a code review from a senior developer (2) there are many competent developers in India, or around the world, so if your company needs to outsource, it can do so by being a little careful about who they employ (3) if the above 2 are not possible, simply look for another job, b…

No, I was not trolling. The key to understand the whole thing is that it was not a software company, but a construction company and I was there as a consultant.

For them, software is a cost, not a source of revenue. That's why they didn't implement rigorous practices such as code reviews. That's why they'd prefer the cheaper against the better coders. That's why I already followed your 3rd advice.

Re: Java 8 Lambdas

#77

Post by henrikschroder »

gouranga wrote: post #54
batista wrote: post #39

Earlier quoted context omitted.

In your sense, you don't need them for 100% of the code. Lambdas are NEVER required, as tons of other syntactic features are never required. They are nice to have though, because they make the code more concise and reduce bugs but reducing boilerplate and repetition. Working without them when you have them at your disposal is idiotic. That huge .Net 4.0 systems have been written without a single lambda probably speak…

I don't think that they reduce bugs at all - that's a bit of a wired assertion to make. Its not about the programmers but the architecture. To be honest, the primary use case for lambda expressions in .net is LINQ and possibly container configuration. If you use NHibernate and do not expose IEnumerable anywhere (which is required across network boundaries and encapsulation boundaries) then you just don't see it anywh…

> To be honest, the primary use case for lambda expressions in .net is LINQ

Uhm, yes, if you're incapable of using delegates and writing functions that take delegates as parameters, then you'll only use lambda expressions where other people have written such functions, for example in LINQ or the generic collections in the framework.

But if you can use delegates, and if you can use lambda expressions, they're a wonderful tool to make your code more readable, and that in turn reduces bugs.

Re: Java 8 Lambdas

#78

Post by henrikschroder »

gouranga wrote: post #73
jmcqk6 wrote: post #63

Earlier quoted context omitted.

I think the implication here is that if they require fewer lines of code, they are going to reduce the number of bugs. Regarding LINQ: is there any .NET app out there that isn't using IEnumerable at some point? I can't recall every writing an app that didn't use it, unless it was an extremely simple app. Besides that, Lambdas are very useful in event subscription.

Not necessarily. collection.Where(s => s.Property.Name == "Blah!").Single(); 4 hand grenades waiting to go off in that expression. Try and spot them. We have a 670kloc platform that doesn't have a single one in it (it's still .Net 2.0). 450 domain objects, 1000+ NH criteria queries and about 650 aspx pages...

It's sad that .Net doesn't have nullsafe properties, that would be a fantastic way to reduce boilerplate nullchecks everywhere.

Re: Java 8 Lambdas

#79

Post by adrusi »

btilly wrote: post #30
krunaldo wrote: post #18

Earlier quoted context omitted.

You can't have statements in pythons gimped versions of anon functions :/

I call BS. def return_closure (value): def closure (): return value return closure foo = return_closure(5) print foo() # prints 5 If you look closely, foo is an anonymous function, and it could have anything you bloody well please inside of it. What you can't do is put statements in an anonymous function that you are declaring inline. But the full syntax I just demonstrated is only marginally longer. UPDATE Modify th…

it's a closure, but it's not an anonymous function; it has a name!

"anonymous function" is a syntactic feature but "lexical closure" is a language feature. In python "anonymous functions" can comprise only one expression: `lambda x: x * 2`, but that's not the only way to make a lexical closure, you can also do:

   def foo(x):
       return x * 2
and then use `foo` in place of the anonymous function literal.

Re: Java 8 Lambdas

#80

Post by kmontrose »

gouranga wrote: post #75
kmontrose wrote: post #66

Earlier quoted context omitted.

C# extension methods are used for considerably more than adding new methods to existing interfaces, though that is a valid use of them. They also don't require you have access to the source (anybody can write an extension method on System.Collections.IEnumerable, not just the BCL team). That they work on any type (not just interfaces) also makes them considerably more general than default implementations. I also find…

The problem I have with extension methods is semantics and determinism, particularly in the collections framework (if you can call it that - it's a mess). Great example: Look at System.Core's Count() inside reflector. Using pseudo code: def count(ref): if ref is ICollection: return (ref As ICollection).Count else n = 0 for each item in ref: n++ return n That hurts badly if you are not careful. Enumerables will be ite…

What about interface defaults prevents or precludes that hack/optimization? You have exactly the same information after all.

For example (disclaimer, it's been a bit since I've touched these classes; but you should get the idea), an extension of Iterator that adds a longSize() method would probably want to make use of ArrayList's size() rather than iterating over the whole thing too.

As an aside, if your code absolutely and utterly depends on a certain operation's runtime performance you had better be using a type that actually guarantees that performance. List guarantees Count is O(1) ( http://msdn.microsoft.com/en-us/library/27b47ht3.aspx ) , IEnumerable doesn't ( http://msdn.microsoft.com/en-us/library/bb338038 ); that's your bug.

Post reply on HN