TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Twitter, Ruby on Rails, Scala and people who don’t RTFA

85 pointsby mileszsabout 16 years ago

10 comments

wheelsabout 16 years ago
I think one thing especially for people coming to web development from other angles in programming is getting used to the fact that you have to know so many technologies / languages to get the job done.<p>In the early days of web apps, you could mostly get by with Perl, SQL, HTML and a little bit of Javascript for mouseovers and whatnot. Framework? CGI.pm, baby.<p>Now you generally need HTML, CSS, Javascript, a Javascript framework, a backend language of choice, a framework of choice in that language, a high-performance backend language of choice for the critical bits, and SQL.<p>I did web apps from 1997 to 2001 and then picked back up in early 2008. It was pretty dizzying at first just knowing where to start. In the systems / multimedia world where I lived in the 7 years between it was C or C++ and a framework.<p>So what's the connection to the story? I think it's in the web world, perhaps as a result of its relative infancy, we apparently have to get used to the fact that the right solution to a problem is often using mixed-mode programming where individual tools are selected for individual tasks -- that development abilities in the web world is as much a question of breadth as depth. We shouldn't be so disenfranchised that our tools aren't general purpose.
评论 #544964 未加载
评论 #546277 未加载
pcabout 16 years ago
<i>This power does not come without a price. Ruby is slow. Ruby is generally recognized as being twice as slow as Python, and at least an order of magnitude slower than C++ or Java.</i><p>The last two statements don't mean the first is true. Ruby's power is <i>not</i> the reason it's slow. Smalltalk VMs are proof by existence that the Ruby model can be fast. (See: Self, Strongtalk, Gemstone.) MagLev showed that Ruby is basically just an alternative Smalltalk syntax.<p><i>Charles Nutter, one of the creators of the JRuby VM for the Ruby language, recently posted an article about optimizations that could be made to the VM, and he improves Ruby performance by as much as twenty times by removing much of Ruby’s power and breaking compatibility.</i><p>"Remove much of Ruby's power"? Around 0.2% of Charles's speed-up came from removing the ability to override the primitive math operations. Other than that, his speedups removed <i>none</i> of Ruby's power.<p>(And nit-picking: <i>Ruby is probably the most powerful programming language on the planet for creating DSLs, or domain specific languages. It can do this because any class or object can be extended, any method overridden, any constant undefined and redefined, and so on, and so forth.</i><p>Not true:<p><pre><code> &#62;&#62; class StrangeArray &#60; Array; def [](x); x; end; end nil a = StrangeArray.new(10) =&#62; [nil, nil, nil, nil, nil, nil, nil, nil, nil, nil] &#62;&#62; a.map{|x| x} =&#62; [nil, nil, nil, nil, nil, nil, nil, nil, nil, nil] # wrong &#62;&#62; (0..(a.size - 1)).map{|x| a[x]} =&#62; [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] # right</code></pre> I.e., the built-in implementation of Array#map statically refers to the built-in implementation of Array#[].)<p>(Edited to correct example, as pointed out by hjdivad)
评论 #545012 未加载
评论 #544954 未加载
评论 #544902 未加载
评论 #545193 未加载
Hexstreamabout 16 years ago
Ok, that was painful to read by moments.<p>"Ruby is probably the most powerful programming language on the planet for creating DSLs, or domain specific languages."<p>If Ruby has anything over Lisp in the DSL domain (besides popularity), I'd love to know.<p>"A web development platform as powerful and syntactically concise as Rails could only have been done in Ruby."<p>Idem.<p>"This power does not come without a price. Ruby is slow. Ruby is generally recognized as being twice as slow as Python, and at least an order of magnitude slower than C++ or Java. Charles Nutter, one of the creators of the JRuby VM for the Ruby language, recently posted an article about optimizations that could be made to the VM, and he improves Ruby performance by as much as twenty times by removing much of Ruby’s power and breaking compatibility. If anything, it shows us skeptics that there is no such thing as a free lunch."<p>Lisp has all (?) the crazy features you love so much about Ruby and more, yet it's very fast (try SBCL, it compiles to native x86).
评论 #545113 未加载
评论 #545526 未加载
评论 #545288 未加载
jimbokunabout 16 years ago
This linked article:<p><a href="http://blog.headius.com/2009/04/how-jruby-makes-ruby-fast.html" rel="nofollow">http://blog.headius.com/2009/04/how-jruby-makes-ruby-fast.ht...</a><p>is really outstanding. It shows you exactly why a language like Ruby is inherently slower than a language like Java. Mainly, because Ruby does a lot more work to give you the cool, dynamic capabilities that make people like Ruby in the first place. Of course, much of the cool work on speeding up dynamic languages like Javascript and Ruby is all about analyzing code to find places where you can safely make assumptions about the code (+ is not overridden here, so I can use the built in integer addition operator, etc.).<p>(I probably oversimplified that, but I hope it captures the general idea.)<p>The "Duby" language at the end makes me think of Common Lisp and how you can optionally declare types the compiler can use to compile faster code. Would it be worthwhile to add optional typing to Ruby?
mrduncanabout 16 years ago
<i>Ruby is generally recognized as being twice as slow as Python</i><p>Am I the only one who has never heard of this? I'd definitely be curious to see some relevant benchmarks if anyone has any.
评论 #544978 未加载
评论 #544992 未加载
jpedrosaabout 16 years ago
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...<p>Multiple ways to create literal strings so you can save escaping things inside of them or save some other action.<p>Closures with one block shortcut per method so you can save a little more characters there.<p>These things encourage the developer to revisit their implementations and cut the redundancies much more.<p>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.<p>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...<p>And I liked this article for it put into better words what I wrote in some comments on the original article.
Tichyabout 16 years ago
Yes, Ruby is OK - buuut: I would like a language that is good for everything. I don't really understand the argument that "Ruby was only replaced for stuff it wasn't appropriate for". Some languages are good for everything, so why make the effort to learn languages that can not do everything? Yes, there is the DSL stuff, but atm I am not sure if I really care so much for it.<p>For example, yesterday I caused an infinite loop in my Rails controller because I forgot the "@" in front of a variable that had the same name as the action - so Ruby interpreted it as a method call, not a variable reference. Being able to call methods without "()" is part of the Ruby-DSL stuff, but I wonder if typing "()" would not actually be the lesser pain in the end. I probably lose much more time to hunting such bugs than I lose time typing ().
评论 #545040 未加载
评论 #544957 未加载
评论 #546777 未加载
评论 #545358 未加载
评论 #544977 未加载
grandalfabout 16 years ago
uh I was using Starlng in production and switched to Kestrel expecting a massive speedup.<p>It actually slowed down the queue by about a factor of 10.<p>Maybe the jvm offers GC benefits on massive hardware, but I have not been pleased at all so far.
评论 #545527 未加载
longintabout 16 years ago
I really liked this article, and remember reading the original article and thinking that it does a good job of explaining an engineering approach that invariably needs the ability to skillfully use many technologies.
MaysonLabout 16 years ago
Languages are neither slow nor fast, only implementations are.