Saturday, April 12, 2008

Shell History Meme

Reading YC's post about the meme happening at the Fedora Planet, I also gave it a try:

history | awk '{a[$2]++ } END{for(i in a){print a[i] " " i}}'|sort -rn|head

113 cd
88 ls
53 hg
38 ant
28 fsc
23 ln
17 ssh
13 java
10 ../../../bin/java
9 scala

In words:
I am guy who likes to be at many places [cd] and to know the surroundings [ls] - I try to keep record of everything [hg]. Further, I don't want to bother with annoying repetitive tasks: things should be done automatically [ant] and fast [fsc]. Mental links [ln] help me not to get lost while my mind is far away [ssh]. Finally, you know I used to program in Java [java,../../../bin/java] but nothing can stop the rise of Scala [scala]. ;-)

Labels: , ,

Saturday, February 02, 2008

A *new* Scala Bundle for Textmate

No doubt, the upcoming Scala Module will make Netbeans the No.1 Scala IDE. I use the current pre-release version on my linux box at work without any difficulties. Unfortunately, I have encountered problems running the recommended daily development builds of Netbeans on my private macbook pro. I hoped that I could at least use my favorite editor for MacOS X, Textmate, but the bundle shipped with Scala 2.6.1 still seems to be a dummy/placeholder. Well, instead of falling into a deep depression, I invested half a day to create a new bundle myself.

For those interested, please find the download below:

- The Scala Bundle
- An Example Project (with some sources ripped from scala-lang.org)

The main goal was to have simple syntax highlighting, which actually looks quite good using the 'Cobalt Theme'. (I'm not 100% sure that value:Type is always displayed correctly, but it seemed to work with the samples.)

Further, there is a template for an Ant-Script which includes a compile, run & deploy task. These can be executed as bundle commands (menu or shortcuts), if the file is called 'build.xml'. Customization should be easy with a few properties at the top of the file.

Finally, there are a few snippets to write new code quickly. E.g. typing

trait ->| Adder ->| def ->| add ->| Int ->| 2 ->| left ->| Int ->| right ->| Int

results in
/**
* Adder
*/
trait Adder
{
def add ( left : Int, right : Int ) : Int
}
without pressing two keys at the same time (no SHIFT)!

But of course you can sketch your own (and share them with me =) ) !

Labels: ,

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:

Labels:

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

Labels:

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)

Labels: ,

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?

Labels: ,

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.

Labels: