John Twelve Hawks, "The Fourth Realm" triology. John Twelve Hawks writes fiction with all the technical accuracy of Dan Brown, but even less entertainment value.
Hawks likes to lecture about privacy in his books, but has little idea how surveilance and privacy technology actually work. This would be forgivable if the story made up for Hawk's lack of knowledge about the subject matter, but the characters are dreary and the story dragged-out and dull.
You missed out Merb and all the other Ruby frameworks, which are arguably the closest alternatives to Rails.
Zope Web Application Server. To date unmatched. What Rails wants to be when it grows up. A little less bias would help, too. I mean, "unmatched"? Unmatched in what areas?
Actually, interceptors are not specific to EJB 3.0, but nice try to divert attention from the main issue: Java has access to a feature that earlier was asserted it did not. That's not the main issue. Or at least, it's not the point I was trying to make. But that wasn't my point. You can implement any complex functionality in Java through reflection and bytecode generation. My point is that it's much more difficult to implement functionality in Java than in more expressive languages.
That Ruby developer is taking advantage of many developer hours to make Ruby available, and Ruby also had the benefit of hindsight, being a younger language. If Ruby were older than Java and yet showed sufficient foresight to implement this feature, I'd be far more impressed. Java 1.0 came out in 1995, Ruby 1.0 came out in 1996. A year's difference does not really leave much room for hindsight.
And Java isn't just limited by today's standards, it was limited even when it was first designed. Lisp is 50 years old, yet even McCarthy's original paper, back in 1958 described a language more expressive than Java. And the first Lisps could implement the same observer function as in Ruby.
Today, since before we even started this debate, both languages would allow the same approach to development. If they both have the feature, why keep on arguing about who got it first or how long it took for either to get it? What's the point? Because you'll eventually come across a problem that hasn't be solved with a library. If you can produce a solution for method observer faster in Ruby than you can in Java, then what does that say about the speed with which other problems can be solved? If you can implement a solution to a problem faster in Ruby than in Java, isn't that a solid reason to use Ruby?
Can you download code from an external source, execute it, and still be assured that, for example, that code cannot write to a particular directory on the server's filesystem?...
Java can. But Java can't. The JVM and the standard libraries can, but that's not inherently a property of the language, but a property of the environment.
All those advantages apply equally to any other JVM-based language, such as Scala or JRuby.
Just be warned that if you do so, others will be tempted to point out that no matter how new and shiny your hammer is, it's still a hammer like everyone else's. Ruby isn't a hammer; compared to Java it's a nailgun. It's more dangerous, certainly, but in the right hands and in the right situation, you can produce results in a fraction the time your hammer can.
My intention is not to piss on anyone's parade, but Java is a language that artificially restricts the number of solutions open to a programmer; some would say deliberately so. But it's hard to see these restrictions if you don't have experience with other languages. It's the Blub paradox.
It basically makes it impossible to find whole (huge) classes of errors at design/compile time. To make things worse, you could have a conditional mixin. The result is that its IMPOSSIBLE for the IDE or compiler or static analysis tool to know whether a method exists, or I've passed the right number/type of parameters in. That's a disadvantage, but not a huge one. I've worked with Java and C# more than Ruby, but I can't say that I've been particularly bothered by the lack of compile-time errors.
Also, compared to a language like Haskell, Java's type system is little better at catching errors at compile time than Ruby's. There's a huge class of errors that can be caught at compile time, and Java only deals with a very small proportion of those.
Frankly, I'd LOVE to have the Ruby syntactical sugar, closures, and expressiveness in a statically typed flavor of it with interfaces. I miss my interfaces when playing with Ruby. Design by contract is such a useful thing, its terrible when you miss it. Maybe Scala is the language for you, then?
Java can do this *without class extension* with what are called interceptors. These can be invoked either just before a method is called, just after, or both. You can log, perform timing measurements, or just about anything else. Interceptors are part of the EJB 3.0 specification, correct? How long did it take that specification to be finalized and implemented? How many people were involved? What was the total cost in manpower?
EJB 3.0 looks to have been in the works for over 2 years, with numerous expert groups involved in the process. Even if only 1% of the effort was spent on developing interceptors, that's still a significant amount of time and effort.
In Ruby, it takes one person 10 minutes and a dozen lines of code to produce the equivalent functionality.
The Java libraries, extensive though they are, can't account for every situation. More flexible languages, like Ruby, can introduce new functionality much faster than Java. When it takes 10 minutes to implement a feature, that's time worth spending. When it takes 10 days or more, that's probably not worth it, unless the feature is going to be used extensively.
Further, I'd argue that there's a crippling information cost in Java's approach. It's much better to have a small set of core rules that result in a flexible language, than to try and compensate for an inflexible language with hundreds of libraries and frameworks.
I don't think that Ruby is bad, not by a long shot. It's seems fairly decent and it doesn't seem to be lacking anything necessary. I'm just curious as to why someone would pick Ruby over some other language. I'm not quite understanding what the "killer app" of Ruby is. If you're used to languages like Java, it's very difficult to see the advantage in languages like Ruby, because they solve problems that you may not have even considered were problems.
For instance, let's say you want to log when a specific piece of data is changed on a class. In Java, you'd inherit from the base class, override the setters, and add your logging code in:
class FooLog extends Foo {
void setBar(String bar)
{
super(bar);
Logger.debug("Called bar with " + bar);
}
void setBang(String bang)
{
super(bang);
Logger.debug("Called bang with " + bang);
} }
In Ruby, you don't need such redundancy. You could create a function that automatically overrides the setters for a list of variables.
class Foo
log_changes:bar,:baz,:bang end
Frameworks like Rails make extensive use of features like this, cramming a huge amount of functionality in a very succinct form. For instance:
class Post < ActiveRecord::Base
acts_as_tree
belongs_to:forum
belongs_to:user
validates_presence_of:subject
validates_length_of:body,:maximum => 5.kilobytes end
What the Mythical Man Month points out is that adding people to *an already delayed project* will usually delay it even more (due to the need to bring to speed the new resource). Quite a different thing. From what I recall it was more general than that. The MMM points out that it's hard to scale teams that have heavy intercommunication. Assembly lines can be scaled well, because each worker doesn't really need to talk to the next. Software projects require a great deal of intercommunication, so scaling them is hard.
The MMM further postulates that there is a point at which the disadvantages of communicating with a large team outweighs the advantages of having more people. So a team of 20 might be able to outperform a team of 60.
No, I'm not trolling, I trying to clear the misconception. Linux just isn't ready. Not ready for your desktop, perhaps. I can understand not reading the article, but didn't you even read the summary?
Let me offer a counterpoint. Linux is not only "ready" for my desktop, it surpassed Windows some years back. Should I claim that Windows isn't ready for the desktop? Of course not, because some people clearly find it the best OS for their needs. Likewise, Linux is the best OS for my needs. As the summary said:
"ready for the desktop" is in the eye of the beholder.
Irrelevant. Firstly, we're talking whether Ruby can scale, not whether a particular application or framework can. Ruby processes are independent of one another; they don't magically communicate unless the developer explicitly specifies a common communications channel, such as a database.
Can you scale a set of independent processes? Obviously you can. Barring a faulty OS, independent processes scale linearly. Ruby scales perfectly because there is no implicit interaction between Ruby processes.
It doesn't matter whether Ruby is threaded or not. You can use fork() to create a new child process, and even if you didn't have that, you could still just start the interpreter twice.
If I want to scale Ruby, I can just create another Ruby process. I can create a hundred independent Ruby processes if I want, on several different machines, all talking to the same database. Ruby is easy to scale; the database is not.
Saying Ruby doesn't scale implies that you believe that only a fixed number of machines on earth can ever run Ruby.
I hope that you're just trolling, because the alternative is that you're just a very stupid person.
I have + 5, Insightful Yes, but hopefully some mods who know something about programming will mod that initial comment down.
Of course Ruby can scale. You can have as many Ruby interpreters running as you like. The problem is that they all have to access the same database, and there is your bottleneck.
"Ruby can't scale" - I mean seriously, how can you call yourself a programmer and come up with nonsense like that?
Any language with fork() can scale. Claiming that Ruby can't is ridiculous.
Whether Rails can scale or not is another matter, but the bottleneck in Twitter was not Ruby, but the MySQL database.
This should, I hope, be common sense. It doesn't matter how slow your web server is, because you can always add more web servers. The point of failure is always going to be the database, because distributing writes is really tricky.
Now, I do realise that the internet is full of people who don't consider ignorance of a subject as a handycap to talking about it. However, can we not mod up people who make claims without the remotest bit of logic or evidence to back them up?
I don't think the problem is Ruby. Whilst I'm not associated with Twitter, I have seen some of their presentations on subject of performance, and the major bottleneck seemed to be the database, and ActiveRecord's unoptimized querying of it.
MatzRuby 1.8 is somewhat slow, but it does proportionality very little work compared to the MySQL and Memcached back end. Quite frankly, I've never seen a performance profile of a Rails site where Ruby was the problem; it's almost always the database, or too many AR queries.
Eventually more and more individuals obtain that power through biotechnology, nanotechnology, etc. At some point in the next few hundred years, that capability will probably be about as common or as easy to obtain as an automatic pistol is now. This doesn't necessarily follow. Nuclear technology has been around for over half a century, and nuclear bombs are still rather uncommon.
If a civilization gets to that point and hasn't figured out how to deal with excessive economic inequalities, tribal or national rivalries, mental illness, even bullying, then the result of a Columbine-style freak-out (let alone the stuff going on in Africa and the Middle-East) can be the end of the human race. Again, this isn't necessarily the case. The most likely form of self-destruction is self-replicating devices, and nature has managed to work with such things for billions of years without imploding. It could be that by the time individuals get the power to easily create virilent strains of deadly bacteria, we'll have sophisticated counter-measures.
Further, if we're talking hundreds of years, we start to get into the territory of solar system colonisation and mind uploads. I suspect it would be hard to kill a civilization spread across several light-hours, or to kill individuals who can create cheap backups of themselves.
If it exists, Great Filter would have to happen before we gain the capability to simulate human minds on commoditory hardware.
The government is never going to allow a method of communication it can't eavesdrop upon. Welcome! Welcome to the year 2008! Park your De Lorean over there, good sir, and let me fill you in on communications technology in the 21st century.
1024 bit asymmetric encryption is the norm in 2008. The governments of the world can't eavesdrop on Joe Average's web browser, let alone Freenet. The encryption battle was lost in 1993, and a good thing too, or internet commerce would be impossible.
So you can put away that tin-foil hat, and relax in the knowledge that the internet has not become a panopticon, and likely never will be.
Iron python is not worth considering since it's windows only. Iron Python works on Mono, as well.
Yes you want implicit parallelism. I don't believe Scala or Clojure has any capability to handle concurrency implicitly. But they do have much better tools available to handle it explicitly.
Moreover you want a language in widespread use with good libs and lots of programmers. Scala and Clojure are JVM based, so they have all the same libraries as Java has.
As for programmers, I can't see Java getting much more popular than it already is. It has a very primitive and restrictive syntax, a flawed type system, and its concurrency model doesn't scale well. If we're looking long term, I can't see a language like Java being the face of the future.
In other words, I think we've seen Java's peak usage.
The big achilles heel of python is that it currently truly sucks for multi-core programming and it would appear that attempts to solve this are not coming quickly. Jython? Iron Python? These Python implementations don't have the same global interpreter lock issues that CPython has.
JAVA was written with threading in mind from the beginging. So it can potentially embrace the multi-core revolution that is coming more quickly than other languages. Java was written with a lot of things in mind, but in my opinion, it didn't fully achieve many of them. Locks and explicit threads are increasingly regarded as not a very good model for handling concurrency.
Fortunately, whilst Java may have problems, other JVM based languages like Scala and Clojure handle concurrency extremely well in comparison.
Planets don't have much resources. If you want fuel, there are plenty of gas giants. Materials are better gathered from moons and asteroids with low gravity.
The only thing the Earth could offer a species capable of traveling between stars is information, and the most efficient way of gaining that is through trade.
For instance if a micro black hole was generated in the LHC but didn't evaporate, it would eventually drift into the sidewall of the collision chamber, and whatever matter it 'touched' (atoms pass beyond the event horizon) would not be able to escape and would add to the mass of the black hole. Slowly by slowly it would grow in size. Because matter is never lost out of the black hole, it would eventually accumulate a huge amount of matter. How exactly the scenario would play (in terms of rate of expansion, etc.) would be interesting to calculate (would it sink down into the earth? would it slowly consume the atmosphere?): but I think it would grow exponentially and ultimately consume the entire Earth. Even without Hawking radiation, micro black holes are entirely harmless, as they consume matter at too slow a rate to do any damage. Matter is mostly empty space, and gravity is an extremely weak force. Atoms are on the order of 10^-10m apart, whilst the event horizon of your postulated nanogram black hole would be 10^-25m, if I've done my sums right. That's a huge difference in scale, and a black hole so small isn't going to run into other particles with any significant frequency. The Earth would be long gone before a microscopic black hole made any impact.
remember I started writing my own programming language when the only programming language I knew was BASIC. Sure enough, it worked around some of the shortcomings I perceived in BASIC. For example, the syntax was more consistent. However, for the most part, it was very much like BASIC. And it used the most ridiculous algorithms and data structures, because BASIC had never taught me to do those right. I'll echo this. The first programming languages I designed were mired in the conventions of the few languages I already knew.
The first interpreter I wrote wasn't for a BASIC replacement, but not far off: it was a replacement for the Bash shell. It had some nice features, was a little cleaner and quite a bit faster, but nothing particularly interesting. I wrote it in C++, which in retrospect was a really stupid move, but I guess one learns best through one's mistakes.
Writing that shell took me several months of work. Now I know vaguely what I'm doing, the task is considerably easier. Coincidentally I recently just built a small interpreter in Python for a stack based language of my design, and it took me all of a couple of hours to get working. Thinking back to all the trouble I had with my Bash replacement... experience really counts for a lot in programming.
I am convinced that the key to improving programmer productivity is to get them to write the software correct, first time. It does not lie in a language or programming style. Are you familiar with Haskell? Haskell has a very sophisticated and strict typing system that catches a lot of errors at compile time, so I'd disagree with your implication that a programming language cannot help a programmer make less mistakes.
For instance, in Ruby, this will run fine, up until the NoMethodError when the user inputs an invalid name.
def print_address(customers, name)
puts customers[name].address end
On the contrary, if I try to compile the equivalent Haskell code, it throws an error.
findAddress customers name = putStrLn (address (lookup name customers))
I have to explicitly account for what happens when the lookup fails, otherwise my compiler will refuse to have anything to do with it.
findAddress customers name = case (lookup name customers) of
Nothing -> putStrLn "Customer not found"
Just customer -> putStrLn (address customer)
In a language like Ruby, or even Java or C, it's rare to have a program work the first time I successfully compile it. In Haskell, if I manage to satisfy the compiler, I find that my program tends to work nine times out of ten.
Slashdot Mirror
Hawks likes to lecture about privacy in his books, but has little idea how surveilance and privacy technology actually work. This would be forgivable if the story made up for Hawk's lack of knowledge about the subject matter, but the characters are dreary and the story dragged-out and dull.
And Java isn't just limited by today's standards, it was limited even when it was first designed. Lisp is 50 years old, yet even McCarthy's original paper, back in 1958 described a language more expressive than Java. And the first Lisps could implement the same observer function as in Ruby. Today, since before we even started this debate, both languages would allow the same approach to development. If they both have the feature, why keep on arguing about who got it first or how long it took for either to get it? What's the point? Because you'll eventually come across a problem that hasn't be solved with a library. If you can produce a solution for method observer faster in Ruby than you can in Java, then what does that say about the speed with which other problems can be solved? If you can implement a solution to a problem faster in Ruby than in Java, isn't that a solid reason to use Ruby? Can you download code from an external source, execute it, and still be assured that, for example, that code cannot write to a particular directory on the server's filesystem?
Java can. But Java can't. The JVM and the standard libraries can, but that's not inherently a property of the language, but a property of the environment.
All those advantages apply equally to any other JVM-based language, such as Scala or JRuby. Just be warned that if you do so, others will be tempted to point out that no matter how new and shiny your hammer is, it's still a hammer like everyone else's. Ruby isn't a hammer; compared to Java it's a nailgun. It's more dangerous, certainly, but in the right hands and in the right situation, you can produce results in a fraction the time your hammer can.
My intention is not to piss on anyone's parade, but Java is a language that artificially restricts the number of solutions open to a programmer; some would say deliberately so. But it's hard to see these restrictions if you don't have experience with other languages. It's the Blub paradox.
Also, compared to a language like Haskell, Java's type system is little better at catching errors at compile time than Ruby's. There's a huge class of errors that can be caught at compile time, and Java only deals with a very small proportion of those. Frankly, I'd LOVE to have the Ruby syntactical sugar, closures, and expressiveness in a statically typed flavor of it with interfaces. I miss my interfaces when playing with Ruby. Design by contract is such a useful thing, its terrible when you miss it. Maybe Scala is the language for you, then?
EJB 3.0 looks to have been in the works for over 2 years, with numerous expert groups involved in the process. Even if only 1% of the effort was spent on developing interceptors, that's still a significant amount of time and effort.
In Ruby, it takes one person 10 minutes and a dozen lines of code to produce the equivalent functionality.
The Java libraries, extensive though they are, can't account for every situation. More flexible languages, like Ruby, can introduce new functionality much faster than Java. When it takes 10 minutes to implement a feature, that's time worth spending. When it takes 10 days or more, that's probably not worth it, unless the feature is going to be used extensively.
Further, I'd argue that there's a crippling information cost in Java's approach. It's much better to have a small set of core rules that result in a flexible language, than to try and compensate for an inflexible language with hundreds of libraries and frameworks.
For instance, let's say you want to log when a specific piece of data is changed on a class. In Java, you'd inherit from the base class, override the setters, and add your logging code in: In Ruby, you don't need such redundancy. You could create a function that automatically overrides the setters for a list of variables. Frameworks like Rails make extensive use of features like this, cramming a huge amount of functionality in a very succinct form. For instance:
The MMM further postulates that there is a point at which the disadvantages of communicating with a large team outweighs the advantages of having more people. So a team of 20 might be able to outperform a team of 60.
Let me offer a counterpoint. Linux is not only "ready" for my desktop, it surpassed Windows some years back. Should I claim that Windows isn't ready for the desktop? Of course not, because some people clearly find it the best OS for their needs. Likewise, Linux is the best OS for my needs. As the summary said: "ready for the desktop" is in the eye of the beholder.
Irrelevant. Firstly, we're talking whether Ruby can scale, not whether a particular application or framework can. Ruby processes are independent of one another; they don't magically communicate unless the developer explicitly specifies a common communications channel, such as a database.
Can you scale a set of independent processes? Obviously you can. Barring a faulty OS, independent processes scale linearly. Ruby scales perfectly because there is no implicit interaction between Ruby processes.
It doesn't matter whether Ruby is threaded or not. You can use fork() to create a new child process, and even if you didn't have that, you could still just start the interpreter twice.
If I want to scale Ruby, I can just create another Ruby process. I can create a hundred independent Ruby processes if I want, on several different machines, all talking to the same database. Ruby is easy to scale; the database is not.
Saying Ruby doesn't scale implies that you believe that only a fixed number of machines on earth can ever run Ruby.
I hope that you're just trolling, because the alternative is that you're just a very stupid person.
Of course Ruby can scale. You can have as many Ruby interpreters running as you like. The problem is that they all have to access the same database, and there is your bottleneck.
"Ruby can't scale" - I mean seriously, how can you call yourself a programmer and come up with nonsense like that?
Any language with fork() can scale. Claiming that Ruby can't is ridiculous.
Whether Rails can scale or not is another matter, but the bottleneck in Twitter was not Ruby, but the MySQL database.
This should, I hope, be common sense. It doesn't matter how slow your web server is, because you can always add more web servers. The point of failure is always going to be the database, because distributing writes is really tricky.
Now, I do realise that the internet is full of people who don't consider ignorance of a subject as a handycap to talking about it. However, can we not mod up people who make claims without the remotest bit of logic or evidence to back them up?
I don't think the problem is Ruby. Whilst I'm not associated with Twitter, I have seen some of their presentations on subject of performance, and the major bottleneck seemed to be the database, and ActiveRecord's unoptimized querying of it.
MatzRuby 1.8 is somewhat slow, but it does proportionality very little work compared to the MySQL and Memcached back end. Quite frankly, I've never seen a performance profile of a Rails site where Ruby was the problem; it's almost always the database, or too many AR queries.
KDE 4.0 is allegedly meant to use less memory and processing power than KDE 3.5, so I'm not sure what you mean by following Vista.
The 4.0 desktop effects did seem sluggish though, but hopefully they'll have sorted that out by 4.1.
Further, if we're talking hundreds of years, we start to get into the territory of solar system colonisation and mind uploads. I suspect it would be hard to kill a civilization spread across several light-hours, or to kill individuals who can create cheap backups of themselves.
If it exists, Great Filter would have to happen before we gain the capability to simulate human minds on commoditory hardware.
1024 bit asymmetric encryption is the norm in 2008. The governments of the world can't eavesdrop on Joe Average's web browser, let alone Freenet. The encryption battle was lost in 1993, and a good thing too, or internet commerce would be impossible.
So you can put away that tin-foil hat, and relax in the knowledge that the internet has not become a panopticon, and likely never will be.
As for programmers, I can't see Java getting much more popular than it already is. It has a very primitive and restrictive syntax, a flawed type system, and its concurrency model doesn't scale well. If we're looking long term, I can't see a language like Java being the face of the future.
In other words, I think we've seen Java's peak usage.
Fortunately, whilst Java may have problems, other JVM based languages like Scala and Clojure handle concurrency extremely well in comparison.
KDE4 is essentially still a beta release. Expect instability, at least until they get 4.1 or even 4.2 out the door.
Planets don't have much resources. If you want fuel, there are plenty of gas giants. Materials are better gathered from moons and asteroids with low gravity.
The only thing the Earth could offer a species capable of traveling between stars is information, and the most efficient way of gaining that is through trade.
Whether a programming language is compiled or interpreted is an implementation detail, not a feature of the language itself.
The first interpreter I wrote wasn't for a BASIC replacement, but not far off: it was a replacement for the Bash shell. It had some nice features, was a little cleaner and quite a bit faster, but nothing particularly interesting. I wrote it in C++, which in retrospect was a really stupid move, but I guess one learns best through one's mistakes.
Writing that shell took me several months of work. Now I know vaguely what I'm doing, the task is considerably easier. Coincidentally I recently just built a small interpreter in Python for a stack based language of my design, and it took me all of a couple of hours to get working. Thinking back to all the trouble I had with my Bash replacement... experience really counts for a lot in programming.
For instance, in Ruby, this will run fine, up until the NoMethodError when the user inputs an invalid name. On the contrary, if I try to compile the equivalent Haskell code, it throws an error. I have to explicitly account for what happens when the lookup fails, otherwise my compiler will refuse to have anything to do with it. In a language like Ruby, or even Java or C, it's rare to have a program work the first time I successfully compile it. In Haskell, if I manage to satisfy the compiler, I find that my program tends to work nine times out of ten.