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
2 comments:
Hi, thanks for the reference to [2]. Please note that my 'favorite' Xtend code would be new URI(requestURI) which will already take care of the checked exception. The other example does only illustrate that you could use the other pattern, too.
Regarding the Symbol hell: As with any programming language you have to learn the syntax and the sematics: [| .. ] is just a literal for a lambda expression without any arguments. If it would accept two args, it would read [ a, b | .. ] thus the bar just separates the parameter list from the lambda body.
Best regards,
Sebastian
Yeah, Sebastian, thanks for your infos! Xtend is still cool like some JVM languages. The complexity goes with the goodness for these languages:) It leaves the users to think what they like to choose. I highly agree with you on the words - "with any programming language you have to learn the syntax". My personal 'favorite' syntax is human-readable syntax especially for using in the large engineering field. The symbolism should be limited to the conservative scope(like for language syntax disambiguity and common-accepted math operator).
like for "literal for a lambda expression without any arguments",
It can be design to [| .. ]. as you pointing out.
It can be design to ()->... . as you seen in Java 8(()=>..in Scala).
Or something like ->..., #->,...
Personally, I think, ()->... is more common-accepted for all the crowds althougt it may be more lengthy than others.
Your exmaple is not much symbolical itself in fact. I just hope to comment that the trend among the new language designers is not recommended，at least in my understanding. IMHO, it is very harmful to convert the meanful identities to kinds of wired symbols in the design of the language for just decreasing several typings(yeah, Eclipse always helps this!).
Post a Comment