Thursday, October 18, 2007

Streams for Incremental and Tail-Recoursive Computing

Programming in Scala is a lot of fun for me, but I really love Streams. Their laziness allows really nice implementations of incremental algorithms and tail-recursive functions. the best thing is they can be used efficiently under different requirements: no matter if you are interested in each intermediate result or only the final one, you'll only need one implementations. =)

I hope the following example computing the factorial(s) using Streams explains it well:

Wednesday, October 17, 2007

Building Scala from the Sources

As I noticed that the actual Scala sources include a great enhancement for all RandomAccessSeq.Mutables, such as Array or ArrayBuffer: Now, the methods drop, take, slice and reverse return a RandomAccessSeq.MutableProjection, which allows cool things to be done in O(1), e.g. Array(1,2,3) reverse(0) = 10.

Unable to hold mysself back waiting, I decided try the latest version. All I had to do was to follow these instruction: Building Scala 2 from the sources. Et viola, one can already taste some of the features/fixes scheduled for Scala 2.6.1. =)

Saturday, October 06, 2007

11 Amazingly Simple Tricks To Turn Your Brain Into A Powerful Thinking Machine

Today, I enjoyed reading the article 10 Amazingly Simple Tricks To Turn Your Brain Into A Powerful Thinking Machine. Actually, my life includes most of the them since quite a time, except for points 4 and 9. Ok and the first "trick" I only do partly, because I don't focus that much on varying the the subjects - but who's perfect. ;-)

However one important thing is left on the list, maybe because it is not so simple as the others:

0. Exercise every 1 or 2 days

It has been shown recently, that for adults the only way to create new brain cells is exercise. Especially these greatly improve learning and memory, if combined with the daily brain training like described in 1-10. The reason is that the new cells get instantly inserted into the neural network where needed, which is a faster process than optimizing by transforming/rebuilding it.
So this is really step zero, since without challenging the mind (brain training, learning), the new cells will not be linked strong enough and therefore will die within a few weeks.

Regularly sport and fitness exercises are great, but I believe not using the elevator for changing only 1-3 floors and going small distances by foot or bike are nice additions.


[1] First Proof that Exercise Creates New Cells in Brain Area Affecting Age-Related Memory Loss
[2] Das Wundermittel namens Bewegung - Hirnforscher revidieren alte Lehrmeinungen (german)

Wednesday, August 15, 2007

Named Arguments - Pure Danger (Tech) for Java 7?

On his blog, Alex Miller is has put up Some comments on D&R’s Java 7 wishlist. One is about Named Arguments:

I have seen no one propose this, but I’ve been thinking for a while that it would be really helpful in situations where you have lots of optional parameters. It would be great for constructor injection, argument passing on a program interface, embedded DSLs/fluent interfaces, etc.


I really like the idea of named arguments, although I'm not sure if they are the best solution for all the things mentioned above: DSLs in Java? Without operator overloading?.


Anyway, it believe they would make Java Code (even more) readable and the usage could prevent mistakes:



Documentation and parameter re-ordering are nice, but it would be really cool to have default values along with them:



However, when does it end? Imagine indexed varargs:



And did I hear critics say "But named methods can simulated with a dedicated bean (having a corresponding property for each method parameter)!"
Well, that would leads to lots of grabage of code (and objects inside the jvm):


Summing up, I think this would be a minor but not less worth language change to consider for Java 7 (or 8). Especially since everything above should be 100% backward compatible and YOU DON'T HAVE TO USE EM!

What do you think: Take it or leave it?

Tuesday, July 17, 2007

Re: How to write Iterators really REALLY fast (in Java)

Browsing through the last week entries of my subscriptions, I stumbled across an interesting post entitled "How to write Iterators really REALLY fast". It is about simulating the yield functionality available in C# iterator blocks as of .NET 2.0 - as you might have guessed: it allows to write iterators really fast. =)

The author presents an example featuring a utility class Yielder, which provides the same ease-of-use completely without pre-compilers and keyword overrides/additions. However, the implementation details were not published with it - but promised for next week (as of now 'this' week). Feeling eager how this can be done, I tried implementing the interface based on the descriptions in the text and the mentioned examples (one repeated here for convenience):

public Iterator iterator() {
return new Yielder() {
public void yieldNextCore()
{
for (Object nextItem : coll) {
if (pred.evaluate(nextItem)) {
yieldReturn(nextItem);
}
}
}
};
}

However, it turned out that the task was not as easy as I thought. Actually, it took me over one hour to write one and I didn't succeed in making it as efficient as a true "yield".


Probably, the author will soon present a smart solution to the two challenges I encountered:

1. How to create more than one Iterator from a single Yielder instance?

Obviously, yieldReturn is a method of the Yielder class, so it is not (automatically) aware of the a specific Iterator instance. Therefore, I moved the method (along with a yieldBreak equivalent) to an interface which will be passed to the iterator-block (yieldNextCore).


2. How to avoid multiple iterations without an additional collection as storage?

Maybe my intuition is wrong, but the Next in yieldNextCore implies to me that the method will be called repeatedly. Probably until it exits after a yieldBreak call or without one to yieldReturn. Hence, in the example above it would be the number of elements the predicate pred evaluates to true. Taking the worst case: One call for each of the n elements in the collection coll. Ergo the time scale rises from O(n) to O(n^2)!

Anyway, I might be wrong and it is only called once. Thus however, an element passed to yieldReturn has be stored until the corresponding Iterator.next call releases it. In a single threaded environment, the means all of the (predicated) elements since there is no way to suspend the for-loop. This may be practicable for iterations over a few elements. But again, the worst cast the complexity rises from O(n) to O(n^2) - this time in memory consumption!

As a result, the only possible implementation idea I got was utilizing a dedicated thread to execute the iterator-block (yieldNextCore). This can block the iteration while the iterators' method can return. However, it turned out one thread is not enough, since it could "wait forever", if the iteration is not completed. Another had to monitor a weak reference to it. But again, the the problem is that the loop will always be executed, which leads to O(n) even if the iteration is not continued after retrieving the first element.

Saturday, July 07, 2007

Inline-Methods and Closure-Blocks

Yesterday, I browsed once again through Neal Gafter's Blog... It turned out to be a great mistake, as I got an idea which kept floating in my mind almost the whole night and day: A way to abstract loops or other code blocks without closures, but by inlining special methods around them (seems like the inverse of a closure to me).
Still not being 100% convinced by function types, especially their syntax, I tried to write myself: A proposal for extending the Java Language Specification

Actually, I think the idea behind it is great, although the proposal itself might not - I didn't sleep much last night and have/had plenty other things to work, so please forgive the small mistakes in the pseudo code and text. However, if there is interest, I'll try to find the time to revise it. So please let me know what you think about it!
[ Collaborators are welcome - its on Google Docs you know ;-) ]


Abstract:
This proposal shows that it is not necessary to add full blown closures or function types to the Java programming language in order to allow control abstraction.
The main motivation behind it is the agreement, that control abstraction cannot be implement with the current language constructs, such as anonymous classes - only syntactic improvements won't help. On the other side however, there is the fear that the introduction of nameless functions will remove one of the languages strongest points: its readability - raw type sequences everywhere. The proposed solution is to reuse existing syntax and add a single new semantic, which is simple-to-use, (relatively-)simple-to-implement, but yet very powerful. In short, the main idea is to inline special methods surrounding a (closure-)block, which remains in the lexical scope where is called.

Please have a look at the full document.



Usage-Example: Map enhanced for-loop.
(see document for the declaration of 'forEach')


Usage-Example: with a.k.a. closeAfter.
(see document for the declaration of 'with')


Usage-Example: blocked asynchronous reading.
(see document for the declaration of 'readFully')

Saturday, April 21, 2007

The Java Memory Model & Concurrency

I just watched the presentation Advanced Topics in Programming Languages: The Java Memory Model given by Jeremy Manson (Google Tech Talks March 21, 2007). Although I was familiar with most, I really enjoyed watching the complete video (I rarely do this for those longer than 15min). If didn't see it already:



Monday, April 02, 2007

Extended Type-Cast vs. Closures vs. Current Java

Although I'm not a fan of messing up the Java language, I had another idea, I'd like to share:

An extended type-cast for single-method interfaces, which succeeds if the signatures are compitable. More precise, the target's method could be overridden by the one of the source interface, the syntax could be: (A as B)
(Note: contravariant arguments would be also possible)

I guess it's is highly related to the ongoing debate if and how to integrate closures (CICE, FCM and BGGA). Although, I think the last one has its pros and I really like the idea of first-class methods (place my vote here), the remaining one really has a mighty ally: simplicity.

However, the absense of method/functions type, which can be assigned only depending on their signature types, makes it look a bit clumsy. With the proposed extended type-cast, things would be more balanced as this example shows.



Just, for those who didn't have noticed yet, the main thing is (Bar as Foo), but it looks nicer within the other syntax sugar as well:
  • calling the single method of an interface, its name can be omitted
  • simplifyedcreation of anonymous classes, which implement single-method interfaces
  • usage of var/final instead of specifying the reference type


EDIT: Modified the source to match the BGGA proposal accoringly to Neal Gafter's comment.

Saturday, March 31, 2007

A new usage of this() !

All Java developers know the this()-method, which is used to call a constructor of a class within another one. It is the only Java-method with a return value constrained to the actual class (a.k.a. self-type).

Imagine if we could use the parameterless version (even if there is no such constructor) within a method. As this, it would return a reference of the class, but virtually typed.

What about the benefits?
This simple, but powerful language extension would allow virtual calls to static methods!


Let's take a look at this example.



Without the new this()-method, one would have to override every method calling the static method, which we want to be virtual. Here, one would have to remove all comment to maintain the output:

One: static(0) - virtual(1)
Two: static(0) - virtual(2)


What do you think, is it worth to submit a RFE?
At least no new keyword or anything else have to introduced and the meaning is widely consistent with the constructor.

Friday, February 23, 2007

Car Surfing Advertisement

Nissan Qashqai looks like a great car, but the advertisement is really awesome:



I guess this kind of recreational sport can get very expensive without a sponsor, remembering my wastage of skateboards in the good old days. :-)

Obvious Facts and the 3 Types of Virgins

A recent blog entry about a video called Le Grand Content, which examines the omnipresent Powerpoint-culture in search for its philosophical potential, brought me to the website of the creator. Beside that these pages are a great online portfolio IMO, the whole videos there are so f%#$%ing incredibly entertaining - in short: watch'em, now!



obvious facts (Le Grand Content by Clemens Kogler)


the 3 types of virgins (Le Grand Content by Clemens Kogler)

Sunday, February 04, 2007

Transmediale.07 and Reactable

Finally, I made myself attending to the transmediale.07 exhibition at the very last day..

It began great, because two french girls gave me 2 tickets for free :-)
(o.k. I only needed one and that would have cost me 2 bucks, but very nice anyway!)

Afterwards, I found myself waiting in row for almost 25 minutes to see not more than 10 installations. Although I must confess, that I was a bit disappointed in the beginning because of the quantity, but it turned out, I liked more than half. This is is a very good rate IMO, though none was really super spectacular,

The best thing however was later on and beneath: a live demo of another multi-touch and marker sensing table called reactable. Sure not only a great interface for DJing, but the performance was very nice to watch and use (at least the 45 sec I tried)..