More than 10 years ago, the boom of the Internet rescued a research project named "the Oak programming language" which in turn rescued the company behind it. At that very era when most websites were static, the Oak language served as the backbone of the first generation of highly dynamic internet and became a great success. The Oak language then seized a lot of backend server market, and became the standard of "Enterprise Computing".
The success of Oak even convinced the guys at Netscape to give LiveScript, their embedded language for Navigator, a new name. Thus JavaScript was born, and overlooked for many years.
All right, above is about the first days of Sun's Oak project, now called JAVA because of legal issues.
However, the so called applets, i.e. browser plugin based applications had serious flaws on performance and deployment, and soon lost the ground to Flash. (According to ESR, the virtual machine wars between Microsoft and Sun also "contributed" to the fall of applets.)
But the hot term RIA, as in Rich Internet Applications, coined by Adobe, the owner of Flash after the acquisition of Macromedia, has no much fundamental difference from the ideas behind applets, which is from the stone age.
So it seems Sun does have a point that they built the first generation RIA platform, and then (sort of) ruined it.
In a world with too many new "concepts", people are buzy reinventing things.
-------------------------------------------------------
Now there is an Ajax vs RIA war, which is said to redefine our view of the internet.
Just as Sun promised us in the mid-90's.
Ajax is exactly a technology from the past, combined with JavaScript (the long-term overlooked), XMLHttpRequest (originally a Microsoft "cheat" for IE to support Outlook), and XML (the shiny-and-all-mighty markup language that can, and should be used to do, everything). This movement also turns the browsers into something they never intended to be, violating the "Do one thing and do it right" principle. The whole (X)HTML + CSS + JavaScript thing, along with subtle differences between browsers, creates a mess.
Yet it is well received, and the web is now walking towards an application platform, accompanyed by a new standard called HTML5, or "Web Applications 1.0", more percisely.
JavaScript finally had its own Renaissance, in a way no one could have imagined.
It may, or may not, also be a case for Java Applets.
Sun has finally made up its mind to return to the battlefield, and now the satuation is somewhat like the one in 1995, that Sun is having financial problems and needs something to boost itself. Will this time JavaFX rescue Sun again and start the Renaissance of client-side java?
Let's wait and see.
And my two cents is that, Sun should really pay more attention to the open source community as we do not have a truly open RIA platform yet and JavaFX would help a lot if we are to reach the critical mass, so I believe many are willing to help. Without the extensive experience of Adobe and vast amount of resources of Microsoft, it is the power of the community that Sun could, should, and maybe has to trust.
Then, is it true that Sun is still NOT willing to release a Linux version of JavaFX on Dec 4, even though the nighty builds have been available for a long time?
You need confidence and crystal-clear vision, Sun.
So that we can have crystal-clear confidence in you.
Best wishes.
Sunday, November 30, 2008
Friday, November 28, 2008
Planning On Using JavaFX ......
Java is a verbose language, and creating inner classes to serve as poor man's lambdas also creates space-time discontinuities for somebody who had explosure to functional programming languages. So I begin to wonder if I could plug in some "lightweight" language for rapid development today, especially for the GUI staff, where callbacks (with countless lovely little classes) are a norm.
Clojure, Scala and Groovy are all on my list. While personally I would prefer a language like Clojure for playing with (as it is a modern lisp!), it is not a valid option because in the REAL WORLD (tm) not too many people love endless parentheses. And both Scala and Groovy has pros and cons, so it's a bit hard to deside.
Then I found a page mentioning JavaFX. I remember coming across the very name months ago, and all that "RIA war" stuff. I was not a GUI guy and not interested in RIA much, but as long as I could see I also didn't believe JavaFX can beat its opponents. Then for a long time the JavaFX thing was not mentioned often, I almost thought it was dead.
After all, Sun is great on inventing but not on marketing, as many say. But then why is Java itself a big success? There are people who hate the "Java brings GC and bytecode to the world" hype just as they hate the "Microsoft invents everything" one, no?
And the good (or bad?) news is, JavaFX isn't dead.
The first release version will be shipped on Dec 4, that is a week from now.
It is said to be a DSL for RIA, or an evolution of the Java Platform towards its future. Anyway, the most important thing is, JavaFX is a lightweight declarative wrapper for Swing and a functional-style wrapper for Java the language, which is exactly the thing I am looking for. Syntax sugars aren't always sweet but it greatly helps when you have just enough.
I cannot comment on the heavy SQL-like syntex regarding JavaFX's collection operations as I have not actually used them already, but considering the C# clowds seem rather excited with LINQ, it may be an interesting way to write applications.
I will check it out and hope the lovely little classes are no more.
Closures, not the poor man's one.
Clojure, Scala and Groovy are all on my list. While personally I would prefer a language like Clojure for playing with (as it is a modern lisp!), it is not a valid option because in the REAL WORLD (tm) not too many people love endless parentheses. And both Scala and Groovy has pros and cons, so it's a bit hard to deside.
Then I found a page mentioning JavaFX. I remember coming across the very name months ago, and all that "RIA war" stuff. I was not a GUI guy and not interested in RIA much, but as long as I could see I also didn't believe JavaFX can beat its opponents. Then for a long time the JavaFX thing was not mentioned often, I almost thought it was dead.
After all, Sun is great on inventing but not on marketing, as many say. But then why is Java itself a big success? There are people who hate the "Java brings GC and bytecode to the world" hype just as they hate the "Microsoft invents everything" one, no?
And the good (or bad?) news is, JavaFX isn't dead.
The first release version will be shipped on Dec 4, that is a week from now.
It is said to be a DSL for RIA, or an evolution of the Java Platform towards its future. Anyway, the most important thing is, JavaFX is a lightweight declarative wrapper for Swing and a functional-style wrapper for Java the language, which is exactly the thing I am looking for. Syntax sugars aren't always sweet but it greatly helps when you have just enough.
I cannot comment on the heavy SQL-like syntex regarding JavaFX's collection operations as I have not actually used them already, but considering the C# clowds seem rather excited with LINQ, it may be an interesting way to write applications.
I will check it out and hope the lovely little classes are no more.
Closures, not the poor man's one.
Tuesday, November 25, 2008
Some Thoughts On My Graduation Project
So .... well, now it's high time to prepare for my graduation, and I know I still have a lot to learn.
My graduation project is basically a P2P file sharing system based entirely on a DHT, so it will be completely decentralized, unlike most existing systems which use a hybrid approach, for instance, recent versions of bittorrent and eMule.
My partner Wilson Huang and I are assigned to do some kind of "application level" development, according to our mentor, so it is not required to implement low level functionalities like DHT and file transferring support, theorically. But in practice, it is not so easy to find appropriate libraries that support such functionalities, while staying unbloated. Complete systems like Vuze (formally Azureus) and Limewire are great P2P applications with DHT support, but they are far too feature-rich for us to adopt, on the other hand, the other implementations of DHT are either mainly for research purposes or not production-ready, which results in an annoying problem.
Finally we find the Mojito DHT, the DHT implementation of Limewire, which is based on the kademlia algorithm. It seems quite independent from other modules of the Limewire system, and better documented than most others. So all right, we will give it a shoot.
Considering the file transfer protocol, there were two appealing choices, bittorrent and ed2k. Both of them have solid implementations but require a server, which should not exist in our system. So we decided to design and implement our own protocol, using the bittorrent protocol and a simple bittorrent client named snark as reference.
We are going to implement the system in Java. Of course I am not a big fan of the java language, but choosing a language is not only about the language itself, but also about its libraries and the team's familiarity with it. Nevertheless, the good news is that I could plug in some clojure code anytime I want to ...... or not, simply for everyone's sake? ;)
My graduation project is basically a P2P file sharing system based entirely on a DHT, so it will be completely decentralized, unlike most existing systems which use a hybrid approach, for instance, recent versions of bittorrent and eMule.
My partner Wilson Huang and I are assigned to do some kind of "application level" development, according to our mentor, so it is not required to implement low level functionalities like DHT and file transferring support, theorically. But in practice, it is not so easy to find appropriate libraries that support such functionalities, while staying unbloated. Complete systems like Vuze (formally Azureus) and Limewire are great P2P applications with DHT support, but they are far too feature-rich for us to adopt, on the other hand, the other implementations of DHT are either mainly for research purposes or not production-ready, which results in an annoying problem.
Finally we find the Mojito DHT, the DHT implementation of Limewire, which is based on the kademlia algorithm. It seems quite independent from other modules of the Limewire system, and better documented than most others. So all right, we will give it a shoot.
Considering the file transfer protocol, there were two appealing choices, bittorrent and ed2k. Both of them have solid implementations but require a server, which should not exist in our system. So we decided to design and implement our own protocol, using the bittorrent protocol and a simple bittorrent client named snark as reference.
We are going to implement the system in Java. Of course I am not a big fan of the java language, but choosing a language is not only about the language itself, but also about its libraries and the team's familiarity with it. Nevertheless, the good news is that I could plug in some clojure code anytime I want to ...... or not, simply for everyone's sake? ;)
Wednesday, November 19, 2008
Hello Blogger~
I registered this blog a long time ago, but never had anything posted. The reason is not so simple but now who cares. I know what I desire at this moment, a fresh restart.
This blog will be about Arch Linux, opensource development, scheme / common lisp / factor programming languages and many other things related.
Maybe it will still be a good idea to talk about animes here? :)
This blog will be about Arch Linux, opensource development, scheme / common lisp / factor programming languages and many other things related.
Maybe it will still be a good idea to talk about animes here? :)
Subscribe to:
Posts (Atom)