7 ms·
State of the Lambda
- rat87 14y agoState of the Lambda December 2011 4th edition
- eranation 14y agoYes, why old news make front page? I guess not everyone is aware of it yet.
- CervezaPorFavor 14y agoFortunately for us, the programming language world isn't as litigious as the smartphone world.
- simgidacav 14y agoI cannot see how to apply the lambda-calculus to smartphones…
- eblackburn 14y agoLamdas are not orignal.
- rat87 14y agoConsidering every other very high level language(gc'd) language has them(and even c++/obj-c to some extent) there is plenty of prior art.
- pacala 14y ago> Default methods provide a more object-oriented solution for this problem: people.sort(comparing(Person::getLastName)); Yay function pointers.
- rforax 14y agoand default methods are traits but it's a secret.
- henrikschroder 14y ago> An alternative (or complementary) approach to function types, suggested by some early proposals, would have been to introduce a new, structural function type. A type like "function from a String and an Object to an int" might be expressed as (String,Object)->int. This idea was considered and rejected, at least for now, due to several disadvantages: Too bad they didn't, C# originally had delegates that you had to declare, but with the addition of generics and lambdas, that system got prettier and easier. The generic delegate types Func and Action are just that, so I can have a method that looks like this: private Foo MyMethod(string str, Func<Bar, string, int> func) { //... } ...which means that MyMethod is a method that takes two arguments, the first is a string, and the second is a method that takes two arguments, a string and an int, and returns a Bar object. But when I call it, I can use a lambda expression, like this: var result = MyMethod("hey hey", (s, i) => new Bar(s, i)); ...which is far from unwieldy. But I can see how checked exceptions would make it horrible, and I'm glad C# doesn't have those.
- jfager 14y agoUsing lambdas in Java 8 looks pretty much exactly like your example. The line you quote from the article is about a proposed way of declaring lambda types, where instead of private Foo MyMethod(string str, Func<Bar, string, int> func) { //... } you could write something like private Foo MyMethod(string str, (string,int)->Bar func) { //... }
- jmcdonald-ut 14y agoIf this helps replace functors I'm all for it.
- batgaijin 14y agoHey, it's only been 17 years.
- rforax 14y agoyes, for a long time, anonymous classes was enough, verbose but enough.
- factorizer 14y agoIn which Java basically has taken over the world of enterprise programming. Contrary to fringe languages like Haskell and the like.
- karterk 14y agoNot everything that grows like weed is necessarily awesome. Just saying.
- batgaijin 14y agoJava forces you to write code in a pretty readable/static manner. Of course you can write 'bad' Java, but the point is that Java limits expressiveness so that YOU are replaceable/won't introduce memory issues. That's the whole point of using Java in the enterprise. To be clear, I'm not saying anything bad about the JVM.
- mikeash 14y agoKind of like how Windows basically took over the world of PC computing?
- mbell 14y agoI'm surprised more people aren't just using Groovy. The performance of Groovy 2.0 on JVM 7 is greatly improved to the point where its a non-issue in 95% of situations (and you can just drop to java for those portions with no penalties).
- mgkimsal 14y agoI tend to agree with you, but Groovy 2 is still pretty new. In my experience, most of the hardcode Java shops and devs that rejected Groovy (primarily?) because of speed are generally slow-adopters, and wouldn't be using Groovy 2 just because it was released a few months ago. As to speed, I've not benchmarked it on JDK7, so I'm not sure what effect the InvokeDynamic stuff has yet, but @CompileStatic annotation helps a lot. My fibonacci stuff at https://github.com/mgkimsal/newgroovy2 https://github.com/mgkimsal/newgroovy2 (did a presentation on groovy2 last week) showed: fibonacci run of 30: * pure java (not in the github) - 12ms * groovy2 compilestatic - 18ms * groovy2 dynamic with typedefs - 30ms * groovy2 no typedefs - 500ms So yes, while @CompileStatic groovy2 is technically approx 40-50% 'slower' in these tests, the noticeable diff for a lot of projects (especially considering file and db access will be constants regardless) will be likely negligible.
- rforax 14y ago@CompileStatic is a great idea even if I prefer approach like Dart or ActionScript partial typing. Groovy closure used dynamic scoping rules not unlike 'this' in JS which makes Closure a corner case for the static analysis performed by @CompileStatic.
- mbell 14y agoJust for the sake of comparison, I ran your groovy code vs a similarly styled ruby version of fib. Groovy 2.0.1 (simply ran with 'groovy fib.groovy') JVM 1.7.0_06_64-b24 ~520ms Ruby 1.9.3p194 ~475ms Obviously this is well into micro-benchmark territory but it seems even worse case is on the order of ruby's performance which is perfectly acceptable for a large number of tasks.
- 14y ago
- spullara 14y agoMost of the effort around Lambda in the JVM has now shifted to implementing the collection libraries. You can follow along here: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-observers/2012-September/thread.html http://mail.openjdk.java.net/pipermail/lambda-libs-spec-obse...
- ScottBurson 14y ago> It is our intent to prohibit capture of mutable local variables. The reason is that idioms like this: int sum = 0; list.forEach(e -> { sum += e.size(); }); > are fundamentally serial An unfortunate decision. Yes, updating such a variable from multiple threads can cause race conditions. But there are many ways to run into race conditions when writing multithreaded code, and this doesn't really add a new one. Furthermore, most code is mostly serial, and the ability to modify captured variables is a very useful one in serial code. (I've written code like that in Lisp for decades.) And finally, the restriction is, of course, easily worked around -- just store the value you want to update in a 1-element array. So the restriction doesn't really protect anyone from anything -- it just forces them to use an ugly workaround in order to write their algorithms in a natural way.
- seanmcdirmid 14y agoIronically, "sum += e.size()" is conceptually not serial at all; the order that each iteration runs is not relevant while you could restructure the computation into a tree of partial aggregations. The work around in Java, using a Cell<T>, is a hack that gives you the updatable mutable variable you need without too much ugly overhead. so something like... cell = new Cell<T>(); ... { ... cell.Value = ... } })
- kevinpet 14y agoThe motivation is that the question of whether list.forEach (or maybe better, iterable.forEach) is serial or parallel is to be left up to the implementation of the collection. Everything related to multi-threaded code since about Java 5 has been about hiding the details of concurrency and allowing programmers to think about code in a serial fashion, but still get the gains from multi threaded code. It's not necessarily about parallelism either -- you could just as easily pass in a function as some sort of callback that gets called far in the future, for example, String error = null; return createClientWithErrorHandler(e -> { error = e; }); What does that even mean? Does the execution context need to be kept hanging around? Java already provides good atomic references if you need to have a sum variable or anything similar.
- 14y ago
- ww520 14y agoIt actually looks pretty good. I can see they spend a lot of effort to make sure it fits into the existing system, keeping new syntax or new form to the minimum.