I have been using Google Chrome on Linux since about a month ago. I installed it so I could test JavaScript programming with it as well. As Google Chrome was still a very work-in-progress (it still is though has improved a lot) at the time I also built a WebKit nightly to test JavaScript with a WebKit process. Since about two weeks ago I have stopped using the WebKit standalone process to test things as Google Chrome is not crashing and considering its roughness it is working well enough for testing JavaScript at least. ;-)
It is super important to have Google Chrome supported on Linux as well as it is going to make it all the more cross-platform and help with getting WebKit quality installs everywhere so we all can share some common ground.
That said, when I am on Windows, Google Chrome is my preferred browser. Despite being unfinished, the Linux version is coming along nicely and it's always open right beside Firefox for me. Opera never enjoyed that status for me however many features it came with. As a matter of fact, programming JavaScript with Opera has been a little awkward when comparing the same code that works OK with Firefox and WebKit and does not quite work with Opera.
I appreciate the Linux version, Google! Thanks! :-)
Hi. My experience lies in Ruby and in JavaScript (these days) so I can see these worlds however close, differently. In Ruby I have all kinds of gimmicks that help with cutting the chase when that's what I want, but I also can make it a little harder when I am interested in something else, in experimenting with some other approach.
What I find a little disgusting is when my "meta-programming" in Ruby starts doing things like when an exception occurs, it points to a line number slightly different than where it really is, or when the backtrace becomes all the more "hacked" with harder to understand things thrown in there. It serves to remind us that there are tradeoffs involved. Also there is the issue creating shareable modules and when you start hacking it away it can make it all the more harder to share. But it's more than fun, it does work, it's just that one can have mixed feelings because for ever cool finding or development, there can exist a little nuisance as well or something that you cannot quite do anymore because you deviated from mainstream...
I came up with my own technique for developing "GUI" without any fancier tool than standard programming languages and their frameworks.
I create a launcher called "weboot" that gets parameters like directory and URL resource to start on. It launches an http server process and sends a command to the browser via command-line (but could use other means) with a generated URL (because you don't want to be stuck on an already used port). Browser goes to: http://127.0.0.1:8066/some_resource
Now you have HTML+JavaScript for the frontend and your preferred web framework and tools on the backend. It all costs just as much as you use, so don't launch Apache, just a small http server will do. ;-)
The secret comes next. The frontend needs to ping the backend every several seconds to keep it from shutting down on purpose. The reason is that after the user closes the browser or the tab, the server process has done its job and should close automatically. It all works very well on Linux. I have created a small calculator and a tetris game to test this already and I pompously called them widgets. ;-)
I also have my own ideas for creating an IRC client based on this technique as I have created several versions of IRC clients over the years and even though XChat works great for me on Linux so I don't have a real urge to do that again, it's a trivial exercise in the same way the tetris game was. When I get my bugs list under control I might give it a go again.
So, the JavaScript side loops with something like:
setInterval(function(){ new AjaxRequest('/ping'); }, 5000);
These values are all tunable. I started with a ping every 5 seconds and the server closes in 12 seconds (two pings + some extra time), but I pulled those numbers out of thin air and in 12 seconds I can even reopen a tab fast enough to avoid the server dieing in case of trouble. ;-)
I like Ruby rather than Python, and I have used GTK+ with Ruby for a while myself, but the GTK+ development in Ruby has been a little under trouble as it seems as if no one who is good enough at C and Ruby has it as a high priority on their list of things to maintain, with more and more things moving to the web and so on...
Also, even the development of GTK+ itself and Gnome in general seem to be under a little trouble as more developers seek greener pasture elsewhere and new blood is rarer to come by to replace them. Things like QT, Swing, SWT (Eclipse's UI toolkit?), and even Gtk# (Mono) are generally on another planet than low level C required by GTK+.
Lots of things interest me so it's hard to pick just one. So I am going to list a few.
* WebKit - decidedly the web brick that should help with introducing new developments faster in order to keep things open and modern;
* IronRuby - might take a while, but eventually it should make programming for the .net world much more pleasurable and help folks with bridging different worlds with the same interface, thing that's quite difficult to plan out;
* Google JavaScript Engine, v8 - it's quite a beast of technology that deserves to take off outside of the browser as well. If Ruby is going to get its ass kicked, I hope it will be by Javascript that's quite dynamic and has closures and so on;
* Canvas on the browser - graphics, widgets and games, all fully printable by the browser, all starting instantaneously;
* Javascript on the browser - programming the dynamic way without having to compile, recompile, deploy, to test things... no, just a small change and a refresh and you get to develop the feature!
* Misc: YUI 3, Bazaar VCS, Ubuntu, computer hardware, broadband, Google Chrome, Ruby implementations, Flash (I just tried to see some videos on Microsoft using Moonlight the Silverlight clone and it made me feel little sympathy for Microsoft and their technologies again)...
* Wishful thinking: Microsoft coming to terms and creating their Windows on top of a Unix-like infrastructure; ;-)
The 10 reasons why PHP is still better than Ruby was a funny piece as seen from the viewpoint of a Rubyist who was just waking up for the day yet. When I clicked to read it, it had 3 vote points. The content was not what I was expecting and yet I wanted to congratulate the author on coming up with it so I up voted it and went on with my life. Upon a second consideration perhaps I should have skipped voting on it and I do appreciate the moderators tendering to keep some quality on this forum.
So, do you use this "DbC" in all of your Ruby code nowadays, like 95% of it, or in just where you think it's really important? And with this "DbC" do you think you could grow the Ruby code to 500,000 lines of code or more?
I think it's just wrong to test for the type of the variable, unless it's really needed. Such checking detracts from what you are trying to accomplish and from relying on the exception backtrace to give you a clue of what went wrong when an error occurred. Also relevant is that if you are trying to pass in a new object that should work despite not being a direct descendent of a certain object, by checking for a certain type you restrict the usefulness of the API. Even "mocking" a certain object can be more troublesome then.
That said, whereas many Rubyists can make more use of respond_to?(), I can make a few uses of is_a?() every now and then. They usually make use of more idiomatic Ruby that way than me.
On the Spec/Test side, I hope everyone is testing more functionality than types as I am sure the type checking is just redundant in Ruby. Speaking of redundancies, a famous motto is all you need to follow to keep it cool: "don't repeat yourself".
Functions only work for a very specific set of input types. On all other inputs, something goes wrong, but that 'something' can take quite a bit of investigating to figure out. Therefore, an assertion that verifies that the input is indeed part of that specific set of input types is valuable: it catches the problem at the earliest possible moment and it pinpoints the exact problem.
Meanwhile, the C# developers go all the way laughing to the bank. ;-)
Here's hoping that Scala will help to fix the Java issues. However, given the similar way such languages work, I fear many developers will prefer to use something else, really, like PHP, C#, Python, JavaScript, ActionScript...
If Scala means more open source developments, there are many ways to go about that.
Celebrities and their audiences, huh? Both the Scala guy and the JRuby guy are celebrities in their own rights.
Here's how worried Ruby is that Scala is gaining traction:
As the Ruby community has grown throughout the years, there have been some controversies among Ruby users every now and again. For example, now that there are many Specs and Tests to run when testing a Ruby implementation, there has been the implementation of a minimalistic and fast runner for them which was not meant to be fully compatible with RSpec and Test/Unit, which has caused some discontentment at times... :-)
JRuby too is not without its own love/hate feedbacks among potential users. ;-)
That said, Ruby and its ecosystem is not "too big to fail" yet. Other languages and systems like Java and C# are "too big to fail" and it can be hard to compete against them with other less-supported tools. Scala builds on top of Java and to some extent it works great that way, right? Ruby "loves" the Java world in the JRuby form and it works quite OK that way, without the static typing and absolute performance of Scala.
Scala and Ruby belong to different typing systems, static and dynamic, and may well be extremes on each end of that spectrum. Ruby has had a "motto" of encouraging "duck-typing" as in "if it walks like a duck, quacks like duck, then it's a duck", so no need to check the is_a?(Duck) with Ruby. It kind of betrays the way Ruby is "meant to be" to do stuff like that. If big systems weren't to be built in Ruby, Ruby on Rails is that exception, that wonder of a miracle, really. Ruby on Rails with all kinds of plugins and stuff can be quite a featureful framework... And yet, it's constantly under development and the (lack of) typing system hasn't killed it just yet...
It is super important to have Google Chrome supported on Linux as well as it is going to make it all the more cross-platform and help with getting WebKit quality installs everywhere so we all can share some common ground.
That said, when I am on Windows, Google Chrome is my preferred browser. Despite being unfinished, the Linux version is coming along nicely and it's always open right beside Firefox for me. Opera never enjoyed that status for me however many features it came with. As a matter of fact, programming JavaScript with Opera has been a little awkward when comparing the same code that works OK with Firefox and WebKit and does not quite work with Opera.
I appreciate the Linux version, Google! Thanks! :-)