jpedrosa

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 gotta go have lunch!

Be well.

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+.

Good luck.

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; ;-)

Over produce according to one's own standards. ;-)

Keep pushing.

Software developer is a broad term as well. ;-)

And the last bastion of respect, the software engineer is not without its enterprise-ish feel.

Researcher seems cooler, but it's all about feeling good and self-esteem in the end. :-)

What about the designers, web designers, front-end engineers? Does it piss them off being called a programmer every now and then?

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?

For every other type of error, hah, rely on what I said then?

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".

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:

  dewd@senna:~/in_motion/ruby$ ls -l
  total 32
  drwxr-xr-x  5 dewd dewd 4096 2009-03-29 15:44 ironruby
  drwxr-xr-x 18 dewd dewd 4096 2009-04-05 15:23 jruby
  drwxr-xr-x 20 dewd dewd 4096 2009-04-05 03:05 macruby-experimental
  drwxr-xr-x 16 dewd dewd 4096 2009-03-25 12:13 rubinius
  drwxr-xr-x 25 dewd dewd 4096 2009-04-05 16:18 ruby
  drwxr-xr-x 18 dewd dewd 4096 2009-04-05 16:27 ruby-1.8.6
  drwxr-xr-x 18 dewd dewd 4096 2009-04-05 16:27 ruby-1.8.7
  drwxr-xr-x 24 dewd dewd 4096 2009-03-06 02:58 ruby-1.9.1

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

In celebrities wars, we are just fans really...

Let us see how PHP and Ruby compare out of the box versus Java:

First PHP vs Java: http://shootout.alioth.debian.org/u32q/benchmark.php?test=al...

Now Ruby 1.9 vs Java: http://shootout.alioth.debian.org/u32q/benchmark.php?test=al...

And finally Ruby 1.9 vs PHP: http://shootout.alioth.debian.org/u32q/benchmark.php?test=al...

So, both PHP and Ruby 1.9 have a hard time when trying to keep up with Java and in these tests Ruby seems to have an edge over PHP. Not to mention that Yahoo one of the biggest enterprises on the web uses a lot of PHP for their services, but there are ways to further optimize PHP so who knows what each user can do to improve performance.

My point in bringing PHP into the spotlight is just to show that there are other languages that a priori were just as slow as Ruby but given their niche have had enough success to endure "slowness" criticisms.

The languages that are considered fast have often to face potent competitors which make for an immersive experience seeing them develop in the marketplace. Ocaml what, I hear you say?

Sure... Nice write-up.

From the Hacker News site I have been following the recent controversy and even participated in some discussions. :-) Your Honor, I plead guilty! :-)

I cannot blame them (Twitter) when they seek their goals for a better business with higher quality and performance. I even respect their creative skills. So I don't have a beef with them even when Ruby gets caught in the polemic.

Ruby to this day continues to be an open source project put together by a community that for better or for worse has most core developers being Japanese.

But since about 3 or 4 years ago, Ruby has had other developers seeking to implement compatible Ruby versions... That is, Ruby has outgrown itself and continues to do so. JRuby, MacRuby, Rubinius, IronRuby...

At the end of it, though, Ruby continues being relatively slow when compared to other kinds of languages. But first read the following article to see some reasons why is that: http://blog.headius.com/2009/04/how-jruby-makes-ruby-fast.ht...

Since Ruby's beginning, it was not out to reach C level performance. And JRuby for one improves upon some of the shortcomings of the main C implementation of Ruby quite well, not without its own shortcomings though. :-)

So, what do we have in the controversy? Twitter is a little sick of complaints of it letting the ball fall when much more is required of their services, so they go overboard when defining a solid platform for it with Scala. Not to mention that they simply can't go converting their entire system to Scala just yet and they are still happy with the Ruby part of the equation at creating the web interface the users see.

What do we have then? More options of development. Instead of C, C++, Ruby and Java, include Scala there as well. Each with their own pros and cons. We know that, right? But if it were simple to use each one of those languages and more when providing a set of services, we would not have a beef with who chooses what when developing. Nature has it that while it's possible, it's much tougher to get it working. That's partly why big companies like Google try to minimize their options of tools and in doing so help to set standards throughout the industry.

Such standards, fortunately, don't apply for everyone, otherwise Twitter might have started with something other than Ruby on Rails.

For the most part, several Javascript libraries have solved the basics of cross-platform browser support quite well and entire ecosystems were built using them.

I regard Ext Core to being quite similar to other libraries even though it could pack more quality features into just a relatively small file. That is, If I were looking for something "current" I would look into Ext Core as well. But I have high hopes for YUI 3 which will have dynamic loading of features and contextual programming with both CSS and Javascript to let folks create relatively safe and packaged Javascript programs that could then be embedded in other sites without disrupting their looks or functions.

Perhaps YUI 3 is a little bit on the "over-engineering" side, but so long as it works as a stable foundation down the road it could well be the future.

To take the article in the right light, consider that in Ruby-land, syntax is important, it matters. For example, optional parentheses. Spaces are mostly disregarded unless they aren't in a few cases. Switches that support almost any type, even though when folks play with entire Hashes as keys things can fail to work even more during the 1.8 to 1.9 transition...

Multiple ways to create literal strings so you can save escaping things inside of them or save some other action.

Closures with one block shortcut per method so you can save a little more characters there.

These things encourage the developer to revisit their implementations and cut the redundancies much more.

The p method coupled with the inspect feature that gives you the description of a certain object so you can debug it or at least see its content very easily.

No use comparing Ruby to LISP and Smalltalk in some "power subjectivity"... Ruby is hackish and used by "hackers" alike. It's not perfect of course...

And I liked this article for it put into better words what I wrote in some comments on the original article.

I agree that the Ruby 1.8 to 1.9 transition has caused headaches. But the 1.9 version does have some interesting features that have been long being cooked to get to this point, and perhaps more interesting is that the 1.9 version has motivated even more developments in Ruby-land as found in MacRuby that uses the 1.9 version or in yarv2llvm that recompiles the bytecode to llvm or something.

Let's say that many folks might have had higher expectations that have been hard to meet given the reality of it all.

The Merb guys helped with further explorations themselves which probably helped with making Rails advance more decisively, given the promissed "merging" of the Merb ideals with Rails.

Also, with things like Passenger, the deployment of Ruby met an all-time high in features.

I use JRuby to run a web application that I first coded in Ruby and it works pretty well even though it reserves and consumes more memory. Having a dedicated server for JRuby applications instead of running such applications on your own desktop alongside other applications slightly helps with the feeling of speed of the JRuby application, as it does not compete for CPU time with the other desktop applications you have like the browser, when you can feel that JRuby requires more work than Ruby for doing similar workloads. :-)

I know that the pros of JRuby for running Ruby applications mean things like being able to run multiple instances of Ruby from the same process, being able to run JRuby applications in a standard Java web-server be it as Servlet or a more high-level installation, and so on.

Also, Java has had a lot experience in running server applications so Java does help with maximizing the use of the resources available, be it 100% of CPU time, gigs of memory, multiple CPUs, and so on. Java has those famous garbage collectors and HotSpot technologies. JRuby can enjoy all of that so it does improve things over pure Ruby. Let's say, Java doesn't break a sweat under heavy load, or at least it shouldn't. Whereas with pure Ruby all bets are off.

Seeing the April 1st date of the article it was just a little bit harder to believe they would write it like that. As folks have taken it seriously...

The Ruby community was formed without being forced into it necessarily. Academics did not force people into Ruby. Businesses did not force people into Ruby. Even Ruby on Rails was created because DHH was not forced to use PHP and instead tried to make things work in this new called Ruby.

Scala has its followers but Academics push it and business types can push it as well even though many business types still prefer Java and C#. Also, Scala is being primarily used for server-side stuff which is a very crowded market already and many developers are just a little bit too tired of having to interface with complex server-side stuff while trying to innovate on the client-side.

Thing is, as a guy who really digs Ruby, Scala does not worry me one bit. I could always try and use a hyper-advanced Scala implementation or application in the future given I can make choices at one point and then have to revisit said choices in the future given the changes brought by new developments.

Let me tell you a little story. When C# was being first introduced in its very early versions, I was very much playing Ultima Online on pirate servers. A new pirate server was being coded in C# and it was becoming rather popular quite fast and the single developer (or was it?) was having quite a lot of fun with it. Nobody told him to use C# for that kind of thing I am sure, it was just him putting his passion forward with the means he had at the time. C# has grown since then, and many pros and hobbyists use it to create all kinds of little programs on Windows.

Scala? Scala has an uphill battle, and many other languages have had their own uphill battles throughout the years. It's tough.

He tested Ruby 1.8.7 on Ubuntu and Ruby 1.8.6 on Windows.

Ruby 1.8.7 has added some features found in Ruby 1.9.1 in order to provide a forward path for those wishing to start adopting the new Ruby 1.9.1 features. For whatever reason, Ruby 1.8.7 has become a little slower when compared to Ruby 1.8.6, in general, at least during some testing I have done. So there's more than reaches the eyes in those numbers of the benchmarks.

Also, while Microsoft's C and C++ compiler provide lots of cool optimizations, Ruby is often compiled with just -O2 on Unix compatible systems because it's often fast enough, because Ruby is not known for trying to extract maximum performance from the bare metal anyway, so at the end of the day, things tend to a certain normalization which kills performance.

For that reason, MinGW and even Cygwin can work way too well on Windows machines with GCC, with Ruby tasks in mind. Though there might be little incompatibilities here and there with things like threading, sockets and so on.

I personally regard JRuby a great Ruby for Windows machines, because Java has great support there. More than that, though, I am excited with the work of the IronRuby guys because during my tests IronRuby has started performing within decent expectations, though it lags behind other Ruby implementations and has stability problems at this point.

I am reminded of how the folks who do most of the work almost never are the ones who appear the most (speak, write, show up)...

Speaking of which... :-)

Fairly awesome! Thanks for the unique resource. If I could I probably would like to put most of these links in my personal bookmark. Nice interface. Nice change. It's good to hear that Arc is coming along also. :-)