Because I am planning to start new round of posts in the community, so I do a little tweaking to the blog. I do a update to that blog entry in that several readers asked the status of my SEED project[1] in its release-following period. Unfortunately I must say it has been dead for many reasons.
After the SEED project M0, I have done a more deep investigation and reflection to the current languages on JVM. Like Scala, Kotlin(Ceylon, althoug I've forgot it, but not including the Groovy and Xtend), the basic conclusion is that the complexity much outweights the advantages of the language after the advanced features coming right before your eyes. Some adopters likes to keep to use a subset of the language to keep a good taste. But, if we only limits us to a subset, why we choose this language?
For example, recently, our Xtender Sebastian addressed an exception checking codes in Xtend v.s. Java 8[2]. His favorate Xtend codes like this:
"
import static extension Throwables.*
val uri = [| new URI(requestURI) ].onException [
new IllegalArgumentException(it)
]
"
This codes, IMHO, just uncovers one big problem(or fault) which is much popular in the current mainstreaming JVM languages: that is, "Symbol Hell".
Who knows what " [| new URI(requestURI) ]" stands for when one man meets these codes firstly? In some language, the operator could be mostly arbitrarily customized(to encourage the flow controlling). The result is that, you would regularly sees the in “clever” coders 's DSL library or framework:
~[...] ... ^ ... -|| ... <- -="-" ...="..."> ...
Are this codes happy to see by us?... I am afraid that, it is not the right direction that for the future of language...
Now, back to the topic of this post:)
Recently, IDEA 12 re-introduce a darkula theme[3], which makes our community a little nervous. The chronon boy posted one solution in the planet[3].
Recently, I start to migrate to the Eclipse 4.3 from old 3.8 platform. As I point out in my preious post[1] , the biggest problem to Eclipse Juno is that, the UI is ugly. The color is not harmony with native platform. The default Sash separation is too large. The worst thing is that, we always hate the round-corner tab[4]!
Not it is the time to eat our dog food!
In the weekend, I hack a simplest dark theme implemenation for the community: eclipse.themes.darker[5], which is based the style schema of eclipse-color-theme[6].
As you can see, the dark theme still has some not-dark elements in fact. Some of these is from the limitation of the SWT, like the button background color. But the css style engine still leaves the contribution space for us. After a little more work, I got this:
Yes, it is darker than that of the dark:)
The big fun is that, the codes are minimized by using Eclipse4 platform technologies like dependency injection[7]. It proves that again, the concise codes and advanced features could be achieved by contributing or extending with the external form(like library, framework). New language is not necessary just for this kind of purpose.
"Java Is Dead, Long Live Java!"
[1] https://github.com/jinmingjian/seed
[2] http://zarnekow.blogspot.jp/2012/12/fixed-checked-exceptions-xtend-way.html
[3] http://eblog.chrononsystems.com/dark-eclipse-theme
[4] https://bugs.eclipse.org/bugs/show_bug.cgi?id=367691
[5] https://github.com/jinmingjian/eclipse.themes.darker
[6] https://github.com/eclipse-color-theme
[7] http://wiki.eclipse.org/Eclipse4/RCP/Dependency_Injection
