Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

cancel ×

191 comments

That's because it's spiked with assembly (5, Funny)

Anonymous Coward | more than 5 years ago | (#27381789)

I heard it made a guy in Michigan's head explode! That's why I stay away from the experimental stuff, man.

Hackers. (0, Offtopic)

Anonymous Coward | more than 5 years ago | (#27381911)

Was the best movie of all time.

Painted red (2, Funny)

EdZ (755139) | more than 5 years ago | (#27382049)

Those new code contributions by Mr Aznable made all the difference.

Re:Painted red (1)

PixetaledPikachu (1007305) | more than 5 years ago | (#27382831)

Those new code contributions by Mr Aznable made all the difference.

Funny, I didn't recognize him. Maybe because of the shade

Damn it apple (-1, Flamebait)

Anonymous Coward | more than 5 years ago | (#27381797)

Stay on the desktop of gay people.
Don't want this Mac shit on servers.

All right! (0, Troll)

MillionthMonkey (240664) | more than 5 years ago | (#27381803)

My wife's 17" macbook is now my dev machine! She can surf on my old XP box that takes a half hour to boot. All I have to do now is learn Ruby.

Re:All right! (1)

postmortem (906676) | more than 5 years ago | (#27383365)

you made it boot half hour, originally before you put crap on, it would take less than minute even on abysmal hardware.

Why MacRuby Matters? (4, Insightful)

Anonymous Coward | more than 5 years ago | (#27381821)

Why MacRuby Matters (Present & Future)?

Apparently because an experimental incomplete version of Ruby is fast. Colour me unimpressed.

Re:Why MacRuby Matters? (4, Insightful)

NoTheory (580275) | more than 5 years ago | (#27381945)

MacRuby matters for a lot of reasons. Early benchmarks aren't one of them. http://blog.headius.com/2009/03/on-benchmarking.html [headius.com]

MacRuby's potential for Cocoa integration is fantastic and great, and something i very very much want to see.

It's not clear however what relationship benchmarks at this stage (with an incomplete implementation) will actually correspond to in the future. They are a total red herring for discussion.

Look at MacRuby on the merits! not the benchmarks!

Re:Why MacRuby Matters? (5, Funny)

Artuir (1226648) | more than 5 years ago | (#27382211)

Whenever I read posts like these I start to wonder if I accidentally walked into a Starbucks.

Re:Why MacRuby Matters? (2, Insightful)

Anonymous Coward | more than 5 years ago | (#27382925)

Whenever I read posts like these I start to wonder if I accidentally walked into a Starbucks.

Yea, these Mac snobs need to get with the program. If they put half the effort they put into MacRuby into CocoOnPunchCards, perhaps the rest of us might take them a little more seriously.

Re:Why MacRuby Matters? (0, Troll)

Anonymous Coward | more than 5 years ago | (#27382805)

The least used scripting language on the least used platform. Yes indeed, that matters - not.

Re:Why MacRuby Matters? (1)

ToasterMonkey (467067) | more than 5 years ago | (#27383507)

Right, because the most used scripting language on the most used platform matters? What's that, VBScript?

I don't think this was thought all the way through.

Re:Why MacRuby Matters? (2, Funny)

Anonymous Coward | more than 5 years ago | (#27382951)

This is slashdot. Benchmarks are all that matters.

Re:Why MacRuby Matters? (1)

Malevolyn (776946) | more than 5 years ago | (#27383501)

Well that, and whether or not said subject will blend and/or run Linux.

Re:Why MacRuby Matters? (1)

bonch (38532) | more than 5 years ago | (#27382413)

Well, if you ask me, I suspect that someday in a future version of the Mac OS, Ruby will be a first-class language for application development alongside or perhaps replacing Objective-C. I think Apple likes Ruby and its aesthetic. A lot of the Rails devs are Mac developers, and I think that's where it sparked.

Re:Why MacRuby Matters? (4, Funny)

thePowerOfGrayskull (905905) | more than 5 years ago | (#27382581)

I suspect that someday in a future version of the Mac OS, Ruby will be a first-class language for application development alongside or perhaps replacing Objective-C.

Wouldn't that require Ruby being a first-class development language in the first place? ;)

Yeah, yeah, go on and mod me troll, I can handle it.

Re:Why MacRuby Matters? (5, Funny)

Macthorpe (960048) | more than 5 years ago | (#27382727)

Yeah, yeah, go on and mod me troll, I can handle it.

Alright then!

Wait a minute...

Shit.

Re:Why MacRuby Matters? (5, Insightful)

tyrione (134248) | more than 5 years ago | (#27382663)

Well, if you ask me, I suspect that someday in a future version of the Mac OS, Ruby will be a first-class language for application development alongside or perhaps replacing Objective-C. I think Apple likes Ruby and its aesthetic. A lot of the Rails devs are Mac developers, and I think that's where it sparked.

First Class, maybe. Replacing ObjC? You're prediction makes LSD trips seem dull.

Re:Why MacRuby Matters? (1)

nicolas.kassis (875270) | more than 5 years ago | (#27382815)

I don't see why it couldn't be a first choice for many developers. Objective-C might be used for more complex task while ruby is the main language used to develop applications.

Re:Why MacRuby Matters? (3, Funny)

Malevolyn (776946) | more than 5 years ago | (#27383513)

Don't forget the possibility of ObjC extensions for Ruby.

Re:Why MacRuby Matters? (-1, Troll)

Anonymous Coward | more than 5 years ago | (#27383065)

A lot of Mac users are fags too.

Re:Why MacRuby Matters? (1)

M. Baranczak (726671) | more than 5 years ago | (#27383305)

The latest Mac OS already has Ruby bindings for Cocoa, and Ruby-Cocoa templates in XCode. I haven't used this yet, so I've no idea how well it works, but it seems like it might have potential.

And... (2, Informative)

Creepy Crawler (680178) | more than 5 years ago | (#27381841)

Of course, Slashdot is a dime short and days late on the real news.

JavaScript 3-10x Faster On iPhone OS 3.0 [theappleblog.com]

Well, for a better, no BS news aggregator, try The Hacker News [ycombinator.com] . Then after seeing it there for a few days, come to slashdot to see a regurgitated discussion.

Your sig (1)

i.of.the.storm (907783) | more than 5 years ago | (#27381923)

Your sig is pure evil. Nicely done!

Re:Your sig (2, Informative)

Creepy Crawler (680178) | more than 5 years ago | (#27382397)

Thanks ;)

You'd be surprised of the multitudes of comments I get on me and my bastardly signature... Well, you could always look at my freaks list to get an inking.

I thought it was rather dryly funny.

Re:Your sig (1, Informative)

Anonymous Coward | more than 5 years ago | (#27382901)

I thought it was rather dryly funny.

It was mildly funny a long time ago. It's boring and irritating now.

Re:And... (2)

iamhigh (1252742) | more than 5 years ago | (#27381983)

Yeah, a site of links really compares to the discussion system here on /.. The discusssion and moderation system are what make this site good. Everyone but the dumbest of fucks knows that.

LLVM strikes again. (2, Interesting)

jcr (53032) | more than 5 years ago | (#27381897)

This is great news. The work that Apple's doing on LLVM [llvm.org] is a renaissance in compilers.

-jcr

Yeah , a true renaissance (4, Insightful)

Viol8 (599362) | more than 5 years ago | (#27381955)

"LLVM supports effective optimization at compile time, link-time (particularly interprocedural), run-time"

Amazing, truly unique ideas. If only someone had thought of doing this 30 years ago... oh wait...

Re:Yeah , a true renaissance (1)

RAMMS+EIN (578166) | more than 5 years ago | (#27382005)

``"LLVM supports effective optimization at compile time, link-time (particularly interprocedural), run-time"

Amazing, truly unique ideas. If only someone had thought of doing this 30 years ago... oh wait...''

Well? That doesn't make it any less of a renaissance. If anything, it makes it more like the renaissance. After all, that also started with the idea of "hey, let's go do something with all this great stuff we had a long time ago".

Re:Yeah , a true renaissance (1)

Viol8 (599362) | more than 5 years ago | (#27382285)

Well what? They've been standard compiler techniques for as long as I can remember. Isn't a renaissance supposed to be forgotten ideas coming back to life?

GCC avoids high level interprocedural optimization (2, Interesting)

Pinky's Brain (1158667) | more than 5 years ago | (#27382411)

Because they don't want to expose high level intermediary code (too easy to hijack part of the compiler into a closed source project). Or at least that was one of the reasons LLVM was rejected for next generation GCC at the time.

They might have changed their mind now LLVM is bearing down on them ...

Please don't start you sentences in the subject... (2, Informative)

Tubal-Cain (1289912) | more than 5 years ago | (#27382797)

...line. It is disorienting for the people that don't always read the subject line (almost everybody). And capitalizing the first word of the body text when the word takes place in the middle of the sentence doesn't help, either.

Re:GCC avoids high level interprocedural optimizat (3, Insightful)

jcr (53032) | more than 5 years ago | (#27383111)

So, GCC is making what should be technical decisions on a political basis?

Good to know. That's one more reason to be glad when GCC fades away.

-jcr

Re:GCC avoids high level interprocedural optimizat (0)

Anonymous Coward | more than 5 years ago | (#27383465)

Given that the entire reason for the existence of gcc is political, your surprise at the reason for its design decisions merely highlights your ignorance. Now go play in your closed source world and leave the grownups alone.

Re:Yeah , a true renaissance (2, Interesting)

bonch (38532) | more than 5 years ago | (#27382507)

The greatness of LLVM and Clang is that they replace the slow, rigid, crumbling GCC codebase. When the BSD-licensed Clang hits ready status, expect a massive switchover.

Re:Yeah , a true renaissance (1)

tyrione (134248) | more than 5 years ago | (#27382685)

The greatness of LLVM and Clang is that they replace the slow, rigid, crumbling GCC codebase. When the BSD-licensed Clang hits ready status, expect a massive switchover.

Precisely.

Re:LLVM strikes again. (5, Interesting)

samkass (174571) | more than 5 years ago | (#27381965)

Of course, the results don't exactly show a "3x speedup"... they show between a 0.08x speedup and a 7.8x speedup, with a high variability. Which is really great for such an early build, but it's not an instant panacea for everything.

Re:LLVM strikes again. (1, Insightful)

Anonymous Coward | more than 5 years ago | (#27382013)

Not really, it's neat but hardly new. You want to see a renaissance in compilers, look at TraceMonkey, LuaJIT, V8 and whatever the WebKit engine is called this week.

Re:LLVM strikes again. (1)

tyrione (134248) | more than 5 years ago | (#27382693)

Not really, it's neat but hardly new. You want to see a renaissance in compilers, look at TraceMonkey, LuaJIT, V8 and whatever the WebKit engine is called this week.

What the hell do you think WebKit will use to be built? LLVM.

Qt 4.5 already builds with LLVM. Same for the FreeBSD kernel.

Apple's work on LLVM (-1, Troll)

Anonymous Coward | more than 5 years ago | (#27382073)

Apple should be enormously grateful to the LLVM project. They must've been shitting their pants about having their entire O/S dependant on a GNU project.

Apple is not Microsoft ... (2, Insightful)

Pinky's Brain (1158667) | more than 5 years ago | (#27382633)

They don't have any particular antipathy to the GPL ... Chriss Lattner proposed LLVM as a GCC successor after starting work at Apple. The FSF kicked him to the curb. I don't know if they underestimated his and Apple's commitment into turning the compiler into a true competitor or if they are simply stupid.

As LLVM gets better GCC will lose developers, this is unavoidable, it's EGCS all over again ... but this time a merge doesn't seem on the cards. It wasn't LLVM but the FSF themselves who torpedoed one of the GPL flagships ... and for very very poor reasons.

Re:Apple is not Microsoft ... (1)

tyrione (134248) | more than 5 years ago | (#27382713)

They don't have any particular antipathy to the GPL ... Chriss Lattner proposed LLVM as a GCC successor after starting work at Apple. The FSF kicked him to the curb. I don't know if they underestimated his and Apple's commitment into turning the compiler into a true competitor or if they are simply stupid.

As LLVM gets better GCC will lose developers, this is unavoidable, it's EGCS all over again ... but this time a merge doesn't seem on the cards. It wasn't LLVM but the FSF themselves who torpedoed one of the GPL flagships ... and for very very poor reasons.

They kicked him proposal to the curb because certain devs in GCC, like all businesses [for profit or otherwise] don't like to lose the power of control.

It shows how truly dense the GCC group always was of NeXT and now of Apple Engineering.

Re:Apple's work on LLVM (1, Insightful)

jcr (53032) | more than 5 years ago | (#27383093)

Apple should be enormously grateful to the LLVM project.

So should everyone else who's been living through the dark ages of GCC. The main effect of GCC for the last 20 years has been to suck all of the air out of the room for anyone else who wanted to develop compilers.

-jcr

Re:LLVM strikes again. (2, Interesting)

TheRealMindChild (743925) | more than 5 years ago | (#27382131)

You know. It was bad enough when we had multitudes of acronym collisions with 3-letter acronyms... but did anyone else associate LLVM with Linux Logical Volume Manager?

*sigh*

Re:LLVM strikes again. (1, Insightful)

Anonymous Coward | more than 5 years ago | (#27382669)

no.

Re:LLVM strikes again. (1)

tyrione (134248) | more than 5 years ago | (#27382741)

You know. It was bad enough when we had multitudes of acronym collisions with 3-letter acronyms... but did anyone else associate LLVM with Linux Logical Volume Manager? *sigh*

No.

Re:LLVM strikes again. (1)

earthbound kid (859282) | more than 5 years ago | (#27382557)

See also the Unladen swallow [google.com] project, which is using LLVM to speed up Python. They're still in the very early stages, but it looks promising.

Ruby? (0, Offtopic)

edivad (1186799) | more than 5 years ago | (#27381937)

One question. WHY?!?

Re:Ruby? (0, Flamebait)

moniker127 (1290002) | more than 5 years ago | (#27382033)

Because puts { "I like beans" } is 9000% better than just typing I like beans.
In reality though, I dont know. Ruby is a language that attempts to simplify something that is already perfectly simple, and in the process of trying it really does not introduce much of anything useful.
I'm not sure why layers upon layers of complexity if preferable to some people.

Re:Ruby? (0)

Anonymous Coward | more than 5 years ago | (#27382077)

Those layers upon layers were a result of decades and several agreed upon standards.

If they are too complex for you simply, make them easier [grails.org] . The complexity isn't an excuse to throw out everything achieved so far and recreate the wheel, the transmition, engine, driving interface, etc...

Re:Ruby? (1)

moniker127 (1290002) | more than 5 years ago | (#27382203)

Yes but any sort of layering in a computer system is a major cause of bugs/slowdown. If you dont have to translate between four different languages, then you have a better experience and fewer things lost in translation.
Obviously we cant all write in machine code, so a limited about of layering is acceptable, but really, what does it help in this case?

Re:Ruby? (0)

Anonymous Coward | more than 5 years ago | (#27382239)

While you make a good point. It's obvious that in the future programming is gonna keep evolving into higher and higher abstraction. Layering is just a means of reaching this objective.

If we could, we would develop everything as straight forward as possible, but because we are flawed and bug-prone, using layers of abstractions as step-stones is probably the best way.

Re:Ruby? (3, Insightful)

anegg (1390659) | more than 5 years ago | (#27382443)

Any sort of layering is a major cause of bugs/slowdown? Quick, throw out TCP/IP. Everyone start using Ethernet frames directly from their apps, even if what you really want to use is SOAP over HTTP over SSL over TCP over IP... I'm not sure how you will get your Ethernet frames past the first router, but I'm sure you will think of something. Damn layering just gets in the way!

Re:Ruby? (2, Insightful)

rgravina (520410) | more than 5 years ago | (#27382731)

So you're suggesting that instead of creating languages like Ruby, we should create libraries to more complex environments like Java to make them faster to develop with? Variety is the spice of programming :). Personally, I'm glad languages like Python and Ruby exist and they are not only great and productive languages, they have both made me rethink the way I write software. I'm not sure just adding on top of Java would have achieved the same thing.

Re:Ruby? (0)

Anonymous Coward | more than 5 years ago | (#27383317)

I can't understand your argument. Ruby wasn't created as a response to Java, it predates it.

Re:Ruby? (4, Insightful)

NoTheory (580275) | more than 5 years ago | (#27382083)

Er, way to troll? If you'd like to do your ridiculous hello world you can stick to:

puts "i like beans"

And it's really unclear what "it" you're referring to. Because Ruby, for me, is a good blend of the things i wanted from Perl and Lisp with a side of Object Orientation. I get all the laziness and conveniences of Perl, and i can do all the crazy stuff i'd want to do with Lisp. So imo, you're way off base.

Re:Ruby? (1)

Vectronic (1221470) | more than 5 years ago | (#27382187)

Because binary is incredibly boring and tedious.

Same reason why all of our spoken/written languages aren't just sequences of "Yes" and "No". The same reasons why we no longer live in caves, is the same reason why programming languages will continue to evolve, and become more abstract. There are numerous variables, but the main one being that the original version is never all-encompassing and generally flawed, wood rollers are quicker to make than rubber on metal rims, but the latter is far more adaptable.

Binary = Wood Rollers
Stone Wheel = Assembly
Wood Wheel = Fortran
Steel Wheel = C
Steel + Solid Rubber = C++
Magnesium + Air Filled Rubber C#
Aluminum + Air Filled = Scripting or something
Magnetic Levitation = ????

Or something like that...

Re:Ruby? (0)

Anonymous Coward | more than 5 years ago | (#27382613)

Steel Wheel = C
Steel + Solid Rubber = C++
Magnesium + Air Filled Rubber C#
Aluminum + Air Filled = Scripting or something

Further supporting your analogy, these four are all "built on top of a rollers layer": the bearings and races.

The questions remains... (1, Flamebait)

dvh.tosomja (1235032) | more than 5 years ago | (#27381961)

What is 3x faster than super uber ultra slow? Is ruby now just plain slow instead?

Re:The questions remains... (1)

Peter Cooper (660482) | more than 5 years ago | (#27382047)

All dynamic scripting languages are "uber ultra slow" then, by your measure. Ruby 1.9 betters or equals the performance PHP, Perl and Python 3 in the latest Alioth Shootout.

true, but seems unnecessary (2, Informative)

Trepidity (597) | more than 5 years ago | (#27382127)

Common Lisp is ultra-dynamic and whatnot and still compiles to machine code, which in some implementations (SBCL/CMUCL) is quite respectable in performance. Is there something inherently less-compilable about Python, Ruby, Perl, etc., or have they just not had the same engineering work put into them?

Re:true, but seems unnecessary (0)

Anonymous Coward | more than 5 years ago | (#27382145)

Probably the dynamic typing.

Re:true, but seems unnecessary (2, Informative)

cryptoluddite (658517) | more than 5 years ago | (#27382269)

Common Lisp scores really well on benchmarks because they turn off all the safety protections that are most of the reason to use a dynamic language in the first place.

All scripting/dynamic languages are slow, and they always will be because nobody wants a really high level language that crashes.

Re:true, but seems unnecessary (2, Interesting)

Trepidity (597) | more than 5 years ago | (#27382339)

It scores pretty well even if you don't turn them off, because the good compilers (mainly CMUCL/SBCL) have type inference that can determine at compile time a large subset of the cases where it's safe to elide the runtime checks.

Re:true, but seems unnecessary (2, Interesting)

Cyberax (705495) | more than 5 years ago | (#27382323)

LISP compilers are not magical. They just try to:
1) Infere types and then compile typed code.
2) Do inlined threaded interpreter for everything else.

I.e. if you want fast LISP code - you have to write it like you would write it in C/Java/C++/another_static_language.

Re:true, but seems unnecessary (1)

Trepidity (597) | more than 5 years ago | (#27382373)

They're still orders of magnitude faster for generic code, though. You don't get C-like speed, but you get 10x+ better speed than you get in Python, especially on loop-heavy code.

Re:true, but seems unnecessary (1)

Cyberax (705495) | more than 5 years ago | (#27382493)

Python has some brain-dead design issues in its interpreter, so it's not that great a feat.

"Unladen Swallow" will probably fix a lot of these issues (and maybe, just maybe, we'll get rid of GIL in Python).

CMU and SBCL are nice, but if you want the current state-of-the-art in virtual machine development, you should check Sun JVM.

Re:true, but seems unnecessary (1, Flamebait)

Tumbleweed (3706) | more than 5 years ago | (#27383165)

if you want the current state-of-the-art in virtual machine development, you should check Sun JVM.

Yeah, but then you run into the problem where you have to write in Java, and let's be honest -- fuck that.

If you're going to write in something as butt-ugly as Java, you might as well write in C++, and really, if you're going to write in something as nasty as C++ for performance reasons, you might as well just go all the way and write in asm.

Then again, there is always D to consider, if you don't want to go down that path.

Re:true, but seems unnecessary (0, Troll)

Cyberax (705495) | more than 5 years ago | (#27383199)

You can write in Scala, it's very nice. Although, I'd like to see better support for its type system in the JVM.

It's the unofficial 'next Java' for JVM.

PS: Do you want me to punch you in face? You see, C++ is one of my favorite languages :)

Re:true, but seems unnecessary (4, Funny)

Tumbleweed (3706) | more than 5 years ago | (#27383325)

PS: Do you want me to punch you in face? You see, C++ is one of my favorite languages :)

I don't like the feeling of being punched in the face, which is one of the big reasons I don't code in C++ or Java. But if that's your thing, you should keep at it! :)

Re:true, but seems unnecessary (1)

Trepidity (597) | more than 5 years ago | (#27383243)

The JVM seems to have advanced to the point where other languages besides Java are targeting it as well. Two of the more popular seem to be Clojure [clojure.org] and Jython [jython.org] . I suspect more will start appearing if JRE 7 adds better built-in support for compiling dynamic languages, as has been long discussed.

Re:true, but seems unnecessary (2, Informative)

ChunderDownunder (709234) | more than 5 years ago | (#27383391)

Who mentioned programming Java? Only your fouled-mouthed troll.

Cyberax was talking about running languages such as Python [jython.org] , Ruby [codehaus.org] or Lisp [clojure.org] on the Java Virtual Machine. In turns out that many of the runtime techniques within HotSpot to speed Java can also be used to optimise the performance of others. Where not the case, special mechanisms are being added to bytecode to create a truly language independant VM [java.net] .

Thanks to Red Hat, there's also an LLVM based backend for HotSpot in development, Shark [classpath.org] .

Re:true, but seems unnecessary (1)

644bd346996 (1012333) | more than 5 years ago | (#27383177)

The JVM architecture is still too restrictive to cleanly run truly dynamic languages, so the fact that it is fast isn't really useful.

Re:true, but seems unnecessary (1)

maxume (22995) | more than 5 years ago | (#27382553)

There isn't any type inference (Psyco helps with that) and there aren't any declarations. It is a bit of a copout, but the often recommended strategy is to rewrite the slow parts in C (which for the people writing the Python interpreter in C was probably a lot easier and more effective than building an advanced compiler...).

Re:true, but seems unnecessary (1)

Anonymous Coward | more than 5 years ago | (#27382363)

Simple. The so-called "Scripting Languages" simply aren't designed for the same type of work as languages like C.

If you're using Ruby in an environment where its relative slowness is actually a problem, then Ruby probably isn't the right tool.

you are thinking of scheme not clisp (0)

Anonymous Coward | more than 5 years ago | (#27382921)

Scheme is "ultra-dynamic and whatnot", but it is an interpreted language.

Clisp has dynamic scoping, which is an unrelated concept, but as far as I know it does not have ruby/python/javascript style runtime dynamic typing... I think you may be confusing the issue.

Objective-c is a better example of a compiled language that supports dynamic types... that's why ruby and python plug into the Cocoa libraries so well.

no I'm not (1)

Trepidity (597) | more than 5 years ago | (#27382957)

Common Lisp is every bit as dynamic as Scheme, and yes it has fully dynamic runtime typing. It also has optional declarations, but you need not use them, and idiomatic Lisp style doesn't, except when attempting to optimize performance-critical code. Indeed Common Lisp is so dynamic that function calls can't even be resolved at compile time, because functions can redefine other functions (or themselves) at runtime.

Scheme is also not generally interpreted; there are both compilers and interpreters available.

Re:true, but seems unnecessary (1)

the_one(2) (1117139) | more than 5 years ago | (#27382941)

From what i understand you can compile python code to x86 with psyco [wikipedia.org] for a pretty nice speedup.
from wikipedia:

Psyco can noticeably speed up CPU-bound applications. The actual performance depends greatly on the application and varies from a slight slowdown to a 40x speedup.

Re:The questions remains... (5, Insightful)

FooBarWidget (556006) | more than 5 years ago | (#27382053)

Every time a story is posted about Ruby performance improvements, someone will post something along the lines of "x times faster than super ultra duper slow is still slow". Even if Ruby is 1000 times faster, there will still be people complaining. My guess is that none of these people actually use Ruby in production to be able to tell how much interpreter performance actually matters in the grand scheme of things.

Re:The questions remains... (5, Interesting)

wrook (134116) | more than 5 years ago | (#27382171)

I agree with this totally. These days I'm writing exclusively in Ruby and it is "fast enough" (even with 1.8.X). In fact, this speed issue is such a big red herring for me. I hardly ever have any issues with speed. Instead I spend most of my optimization time trying to cut down on memory usage.

For me, even an order of magnitude difference in speed (i.e., 10X) isn't going to mean too much. There are certainly places where I'd like my code to be faster, but they are very, very small places. I can easily code them in C if I have to (C/Ruby bindings are *very* easy to write). But honestly, I've never gotten to the point where a speed improvement is more important than a functionality improvement. Every program is different, of course. So not every problem is suited to Ruby.

Code signing requirements that vary per language (1)

tepples (727027) | more than 5 years ago | (#27382629)

There are certainly places where I'd like my code to be faster, but they are very, very small places. I can easily code them in C if I have to (C/Ruby bindings are *very* easy to write).

Until you try to execute your code on someone else's computer, and your Ruby code works but the C code fails to start because unlike the Ruby interpreter, your code hasn't been digitally signed by the platform maintainer. This is already the case for JavaScript: Windows allows parts of a JScript program to be coded in C as "ActiveX" objects, but they have to be signed with a valid Authenticode certificate issued by a trusted CA first.

Re:The questions remains... (4, Insightful)

Otterley (29945) | more than 5 years ago | (#27382811)

These days I'm writing exclusively in Ruby and it is "fast enough" (even with 1.8.X).

I suspect that's because your website doesn't receive thousands of dynamic requests per second.

Re:The questions remains... (1, Flamebait)

raisin (30710) | more than 5 years ago | (#27383205)

Thanks, Captain Anecdote, but you've left out even the anecdotal evidence. What's all this exclusive writing you're doing with Ruby? I've been doing all my grocery list work in Ruby too, and it's *totally* fast enough.

I think Ruby is a fantastic language, but then I see comments like this modded up to 5 that are completely nonsensical. This makes Ruby fandom seem more like Java 1999, which makes me think twice about my positive opinion of it.

Re:The questions remains... (3, Informative)

33degrees (683256) | more than 5 years ago | (#27382197)

While the Ruby 1.8 VM is quite slow, the YARV VM used in 1.9 is much faster, resulting in similar performance to most other dynamic languages. These tests are showing MacRuby being 3x faster than 1.9, which puts it in "quite fast" territory.

What's so special about it? (1, Informative)

Anonymous Coward | more than 5 years ago | (#27382099)

What's so special about this implementation? It runs on an intel x86 running a modified bsd kernel. I suppose that this was spiked with a healthy dose of reality distortion field, (remember how RISC processors were X times faster than chips that fell prey to the dreaded "megahertz myth") right up until they switched, and the new systems were 4-6x faster than the old ones?

Re:What's so special about it? (1)

mini me (132455) | more than 5 years ago | (#27382209)

What is different is that it uses the Foundation library for the underlying implementation. i.e. a Ruby array maps to a NSArray, a Ruby string maps to a NSString, etc.

GNUstep? (1)

tepples (727027) | more than 5 years ago | (#27382647)

What is different is that it uses the Foundation library for the underlying implementation. i.e. a Ruby array maps to a NSArray, a Ruby string maps to a NSString, etc.

Would a Linux port be possible using GNUstep, the Free implementation of the same API that Cocoa is based on?

Re:GNUstep? (0)

Anonymous Coward | more than 5 years ago | (#27382883)

it would take some work as MacRuby makes Ruby objects Objective-C objects and vice/versa. GNUStep uses the GNU Objective-C runtime rather than Apple's- mainly because Steve Jobs tried to rip off gcc back in the NEXT days, and when he found all the shit he'd get into he handed over the compiler but not the runtime. It's a somewhat different object model between the runtimes.

Also GNUStep doesn't use Apple's Objective-C2.0 garbage collector which MacRuby relies on.

Re:What's so special about it? (1)

larry bagina (561269) | more than 5 years ago | (#27382289)

it gives direct access to the Cocoa framework. And the experimental version uses LLVM for code generation, so it could be optimized close to native (objective c) speeds.

Nitro AKA Squirrelfish (3, Interesting)

stefaanh (189270) | more than 5 years ago | (#27382125)

I wonder if this has any connection to what they learned creating the optimized javascript "interpreter" they made for their next generation rendering engine Webkit.

How they did it (5, Funny)

Anonymous Coward | more than 5 years ago | (#27382179)

Sleep(30); /* used to be 90 */

The Future (1)

Narpak (961733) | more than 5 years ago | (#27382219)

Experts predict Computers to get faster with time! News at eleven.

Re:The Future (1)

bonch (38532) | more than 5 years ago | (#27382511)

Do you know what a benchmark is and how it's made?

This sounds great! (2, Funny)

Anonymous Coward | more than 5 years ago | (#27382335)

But I'm a heterosexual so I will not be able to take advantage.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...