Slashdot Mirror
Is Ruby Dying?
New submitter John Moses writes "I have been working with node.js a lot lately, and have been discussing with co-workers if node.js is taking steam away from Ruby at all. I think the popularity of the language is an important talking point when selecting a language and framework for a new project. A graph on the release date of gems over time could help determine an answer. The front page of RubyGems only shows data on the most popular, but I am really interested in seeing recent activity. My theory is that if developers' contributions to different gems is slowing down, then so is the popularity of the language."
Nice try (intentionally spelling "java script" is not cute, dude!).
Here, I fixed it to you.
Not a surprise, anyway.
Lisias@Earth.SolarSystem.OrionArm.MilkyWay.Local.Virgo.Universe.org
No. Next question, is Slashdot dying?
Slashdot will be dead as soon as the new "design" comes out.
For quick and dirty scripts, you can just define your methods and variables and not deal with classes. They're added to the main object, much like javascript globals and functions are added to the window object.
Do you even lift?
These aren't the 'roids you're looking for.
No, more like: http://pastie.org/private/ij3rdcgtkgteefgwj57mfg
I realize that's just an example of simple inheritance, but not bad for using nothing more than functions and prototypes. Yes, it's a little verbose. You can also do prototypal inheritance, etc. The point is that with just a couple of constructs, JavaScript can do things that most languages must separate into many more statements, expressions, etc. But to clarify, I am *not* saying JavaScript is awesome; it clearly has limitations. But it is pretty amazing what all can be done with such a simple language. It is misunderstood.
the compiler is free to rearrange the order of the fields as it sees fit.
No, it is not. ISO/IEC 9899:1999, 6.7.2.1 "Structure and union specifiers", paragraph 13:
"Within a structure object, the non-bit-field members and the units in which bit-fields reside have addresses that increase in the order in which they are declared. A pointer to a structure object, suitably converted, points to its initial member (or if that member is a bit-field, then to the unit in which it resides), and vice versa. There may be unnamed padding within a structure object, but not at its beginning."
The C++ standard has a similar provision. What's unspecified is whether there is any padding between the fields.