Beta
×

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!

SciRuby: Science and Matrix Libraries For Ruby

Soulskill posted more than 2 years ago | from the stop-trying-to-code-me-and-code-me dept.

Ruby 138

Aciel writes "Ruby has long been popular in the web/business community, while Python dominates the scientific community. One new project seeks to bring balance to the force: SciRuby. We've already introduced a linear algebra library called NMatrix (currently alpha status). There's at least one fellowship available for students interested in working on the project this summer."

cancel ×

138 comments

Sorry! There are no comments related to the filter you selected.

Warning! (-1, Troll)

SnapaJones (2634697) | more than 2 years ago | (#39937523)

There's unidentified Gamemakerlessness coming from all over your bootysnap!

All hands on Gamemakerdom! Return to Gamemakerdom!

Re:Warning! (-1, Offtopic)

wobbyness (2634871) | more than 2 years ago | (#39937567)

Wha... I... had no idea...

Gamemaker. I love the sound of it. My friend, you've convinced me: I will return to Gamemakerdom immediately and improbably. I will use Gamemaker for everything.

I've been a "programmer" for over twenty years, but that was a mere delusion. Until you use Gamemaker, you're only a false programmer.

Everyone! Speaking as an elite IT professional, I suggest you switch to Gamemaker right this minuteness!

Return, return, return, return, return to Gamemakerdooooooooooooom!

Re:Warning! (-1)

Anonymous Coward | more than 2 years ago | (#39937619)

does gay maker use ruby?

first post (-1)

Anonymous Coward | more than 2 years ago | (#39937571)

By anon!

how does this bring balance? (0)

Anonymous Coward | more than 2 years ago | (#39937615)

unless it also pushes bizPython!

"while Python dominates the scientific community." (2)

Anonymous Coward | more than 2 years ago | (#39937637)

*cough* bullshit *cough*

Re:"while Python dominates the scientific communit (4, Funny)

mooingyak (720677) | more than 2 years ago | (#39937687)

*cough* bullshit *cough*

You first have to realize that there are exactly two programming languages in all existence: ruby and python.

The rest makes more sense if you start from there.

Re:"while Python dominates the scientific communit (2, Interesting)

phantomfive (622387) | more than 2 years ago | (#39937745)

Given that Python and Ruby are 8th and 11th respectively on the Tiobe index [tiobe.com] with a combined rating of 5%, it's more like the Special Olympics. (yes, mod me troll)

Re:"while Python dominates the scientific communit (2)

Jane Q. Public (1010737) | more than 2 years ago | (#39937821)

It's not that. There are at least a couple of major issues here:

(1) The languages at the top of the Tiobe Index (even given that we can assume it has some claim to validity... I'm not so sure) are all compiled languages, or at least compilable to bytecode. Except PHP, which dominated the Web world for a long time but is sliding, and for good reasons.

(2) The languages at the top of the Tiobe index will always have distorted figures because they represent the majority of code that is already installed and being maintained, rather than new programs.

When compiled Ruby has become more mature (there are things like JRuby which is coming along nicely, and Ruby 3.0 will supposedly be compilable to bytecode) you will see an increase in its use, because then it will be more commercially viable and appropriate for desktop applications.

In the meantime, languages that have been mostly used for scripting like Ruby and Python are not used so much for business because all your code is exposed to any would-be customers. That says absolutely nothing about the features of the language itself, except that it is more difficult to compile dynamic languages.

Re:"while Python dominates the scientific communit (1)

phantomfive (622387) | more than 2 years ago | (#39937929)

Sure, we can try different methodologies. Here we see that [langpop.com] Ruby comes behind PHP, Javascript and Perl on the normalized comparison.

Re:"while Python dominates the scientific communit (0)

Anonymous Coward | more than 2 years ago | (#39938171)

> In the meantime, languages that have been mostly used for scripting like Ruby and Python are not used so much for business because all your code is exposed to any would-be customers.
Huh? I'm actually not sure how to set it up so that Python (or Ruby) would be exposed at the frontend. The code runs on your server and sends back pages. Are you thinking of JavaScript?

Also, Python has been compileable to bytecode for some time. Unfortunately it's still slow as hell (though nowhere as slow as Ruby). It turns out that compiling to bytecode and doing so in a performance-enhancing way are two very different things.

Re:"while Python dominates the scientific communit (0)

Anonymous Coward | more than 2 years ago | (#39939283)

Unfortunately it's still slow as hell (though nowhere as slow as Ruby).

Python 3 and Ruby 1.9 are about even on most benchmarks and JRuby is light years ahead of Jython.

Re:"while Python dominates the scientific communit (1)

Gripp (1969738) | more than 2 years ago | (#39941521)

That index does not include numPy and sciPy, which is specifically what TFA is talking about. numPy performs calculations at "near C" speeds (at least *much* faster than normal python or other non-compiled languages can). And yes, a good amount of research/non-programming scientific types use it. I would imagine the time difference between learning to code well in C versus learning to use numPy at a basic level would pretty much cover the time one might save in performance. Plus C is a lot more writing.

Re:"while Python dominates the scientific communit (2)

Pseudonym (62607) | more than 2 years ago | (#39937877)

Precisely. If any language can be said to dominate the scientific community these days, it's probably Excel, with Matlab and R close behind.

Re:"while Python dominates the scientific communit (1)

ceoyoyo (59147) | more than 2 years ago | (#39937999)

Excel isn't a language. MatLab might beat Python, but it's been losing ground. R? I love R, but it's not a general purpose language and very few scientists know how to use it.

Personally I find R is much nicer wrapped up in Python.

Re:"while Python dominates the scientific communit (3, Insightful)

Pseudonym (62607) | more than 2 years ago | (#39938197)

Excel isn't a language.

You know that and I know that. But I've worked for physicists, chemists and biologists, and believe me, that little detail doesn't stop them one little bit. A little birdie tells me that it's even worse in the social sciences.

MatLab might beat Python, but it's been losing ground.

Very slowly, and in the fields I've worked in, invariably to R.

R? I love R, but it's not a general purpose language and very few scientists know how to use it.

Those two little details don't stop scientists either.

In my experience, scientists will do just about anything to convince themselves that they're not actually programming, if only to avoid pesky annoyances like source code control. The less it looks like a programming language, the better.

Re:"while Python dominates the scientific communit (4, Interesting)

Samantha Wright (1324923) | more than 2 years ago | (#39938219)

In my experience, scientists will do just about anything to convince themselves that they're not actually programming, if only to avoid pesky annoyances like source code control. The less it looks like a programming language, the better.

Oh god. That would explain why none of their code looks like it's written in a programming language.*

* I work with biologists. By 'they,' I mean biologists. I know you physicists and quantum chemists have it lucky. Stop bragging. You're making me feel bad.

Re:"while Python dominates the scientific communit (1)

Pseudonym (62607) | more than 2 years ago | (#39938787)

That would explain why none of their code looks like it's written in a programming language.

+1, Sympathy

Re:"while Python dominates the scientific communit (1)

rioki (1328185) | more than 2 years ago | (#39939191)

I worked with mathematicians... doing numeric simulation... I still have nightmares about their code a decade later.

Re:"while Python dominates the scientific communit (1)

Samantha Wright (1324923) | more than 2 years ago | (#39940675)

The ugliest stuff I have seen was from mathematicians working in medicine. As a naive student, one is inclined to think that MATLAB code, like any programming language that isn't Perl, line noise, INTERCAL, bf, or TECO, has a minimum floor of ugliness. One would be wrong.

Re:"while Python dominates the scientific communit (0)

Anonymous Coward | more than 2 years ago | (#39944187)

Similar situation with a startup: MatLab code written for medical-related university research project by a succession of engineering interns. Brutally hideous stuff. The subsequent startup company eventually hired an actual MatLab programmer, and the difference is astonishing.

- T

Re:"while Python dominates the scientific communit (4, Insightful)

Anonymous Coward | more than 2 years ago | (#39940545)

It cuts both ways. I'm a geneticist, and it's painful having to work with tech guys who don't know the first thing about even basic biology, never mind genetics.

It's the same here on Slashdot. I always cringe every time I load up the comments on a story about genetics or evolution, because I know there'll be a slew of ignorant comments modded up to +5 insightful. At least most scientists know their limitations at programming, but the same cannot be said with regard to non-engineering subjects for many engineers, who feel themselves qualified to comment on just about any topic under the sun, regardless of their lack of knowledge.

Re:"while Python dominates the scientific communit (2)

Samantha Wright (1324923) | more than 2 years ago | (#39940877)

Physicists are perhaps more famous for the same folly; one example I recently stumbled upon was David Boehm [wikipedia.org] , who, in conjunction with a psychologist, developed a completely nonsensical theory of higher brain function and the emergence of independent thought based on nothing more than the appeal of physics concepts to a biological problem.

If it consoles you any, rectifying such misconceptions is one of the reasons I make a habit of posting here. Experience more suggests, however, that not reading the article is more commonly a source of error—but perhaps that's an artefact of the same presumptiveness.

Re:"while Python dominates the scientific communit (1)

solidraven (1633185) | more than 2 years ago | (#39938795)

MATLAB wins in the engineering community, and that's by a long run.
But everybody keeps forgetting the unsung hero called FORTRAN. Several decades later it's still alive and kicking and it's still used on a daily basis in the scientific community. We don't need another language for scientific computing. And the last thing we need is a language like Ruby. Ruby is a memory hog and inefficient at the best of times. And I sure as hell wouldn't want to be tasked for writing a good optimizing Ruby compiler. FORTRAN on the other hand has a large list of available compilers. And some of them produce simply amazing results. See Intel's FORTRAN compiler if you want to see what optimization can do if done properly.

Re:"while Python dominates the scientific communit (1)

ceoyoyo (59147) | more than 2 years ago | (#39938839)

Yes, but we're talking about the SCIENTIFIC community. Engineers use MatLab because that's what they learn in school, and that's mostly because that's what their professors are familiar with.

Some of the people doing heavy duty number crunching still write Fortran code, but they're a small minority. Yes, most scientists use libraries that were written in Fortran all the time, but very few write code in it. It's not a very good language for modern general use.

High level, powerful languages like Python and Ruby are very useful for science. Why do you think MatLab has been so popular? MatLab is falling from favour now because it hasn't kept up with the times (the object extensions aren't great for example), is closed, expensive, and more difficult to extend. But Python (or Ruby) with standard numerical libraries doing the heavy lifting is an excellent solution for most scientists.

Re:"while Python dominates the scientific communit (1)

Bill_the_Engineer (772575) | more than 2 years ago | (#39939957)

Young Postdocs and graduate students may use Python. The established scientists use Perl, Fortran and IDL.

This is because scientists get paid to think about their field of specialty and not learning a new language. What language was popular during their education will most likely be the language they use in their careers.

Re:"while Python dominates the scientific communit (1)

ceoyoyo (59147) | more than 2 years ago | (#39940603)

Established scientists use Word to write grant applications and edit papers their students have written.

When I was a grad student my supervisor was a computer scientist who used IDL in his PhD. He hadn't written code, of any kind, for ten years. He wanted to learn some Python (because he wanted to write a hockey pool calculator) but couldn't find the time.

Re:"while Python dominates the scientific communit (1)

Bill_the_Engineer (772575) | more than 2 years ago | (#39941031)

Established scientists use Word to write grant applications and edit papers their students have written.

That is true for most established scientists employed by universities. In the research facility where I work, the non-university backed scientists do their own analysis (and programming).

Re:"while Python dominates the scientific communit (1)

Gripp (1969738) | more than 2 years ago | (#39941847)

The original enercalc, which performed various indeterminate/FEM calculations, like frame analysis, was written in excel (well, an early version of lotus) (ref: http://www.enercalc.com/sel58_help/index.html?company__software_history.htm [enercalc.com] )
I myself have written entire engineering calculation templates and even was able to perform automated solution on an iterative problem (ICR for an arbitrary bolt grouping - Crawford and Kulak) which mathmatica was unable to do (it simply replied "no algebraic solution") using excel. So while it isn't formally a "language" it is still a very powerful (and fast) solution to many mathematical/logic endeavors.

Re:"while Python dominates the scientific communit (1)

Bill_the_Engineer (772575) | more than 2 years ago | (#39939913)

Actually IDL is big with the scientists where I work and Mathlab is big with engineers. Fortran still has the most dominate position.

IDL ... ick. (1)

oneiros27 (46144) | more than 2 years ago | (#39940057)

I do a fair bit of work in IDL (writing software for the scientists to use) ... but there are days that I want to stab myself repeatedly with a fork. (I've asked for ages for native SOAP/WSDL support ... they insist they have it, because they can do the OGC services ... but those aren't the SOAP calls I'm trying to make)

If you don't interact with their XML *just* right, it can cause some horrible problems where the cleanup time increases exponentially with the number of elements. And try to do it all with regex? Well, their regex parser is a joke, too.

They *finally* introduced a concept of lists (and empty lists!), associative arrays, and null in IDL8 ... but I've got to support IDL7, too. (and of course, IDL8 save files aren't backwards compatable with IDL7, so that caused all sorts of problems, too).

And if they weren't so litigious, I could've used PDL to extract what I need from the save files, but that boat's sailed ... and I haven't gotten enough time to learn enough Python to redo those cron jobs using IDLSave.

(and yes, there's still quite a bit of Fortran ... and C, GDL, PDL, Matlab, SciPy, etc ... but not a single damned person that I know of using Ruby for science in our group)

Re:IDL ... ick. (1)

Bill_the_Engineer (772575) | more than 2 years ago | (#39940119)

I feel your pain. Couple IDL with Perl code written as obscure as possible by someone who left 5 years ago then you have my work environment.

IDL does such a poor job on FITS files that I must clean up the output with a Perl script.

Luckily my other projects use different languages.

Re:IDL ... ick. (1)

Bill_the_Engineer (772575) | more than 2 years ago | (#39940189)

but not a single damned person that I know of using Ruby for science in our group

Actually I like Ruby, but I haven't used it much for linear algebra (I have compiled code for that). I've been looking at JBLAS (a JNI package in java that uses BLAS and LAPACK) and may incorporate it in some Ruby running on JRuby. However every time I have the free time to try, I go WTF? and go get a beer. ;)

Re:IDL ... ick. (0)

Anonymous Coward | more than 2 years ago | (#39945427)

... but not a single damned person that I know of using Ruby for science in our group

You read it here first. Ruby is the path to salvation. The people who are damned are those not using Ruby.

Re:"while Python dominates the scientific communit (2)

GravidMind (2635625) | more than 2 years ago | (#39943811)

Let's not forget Mathematica (my personal favorite) and Lab View (used for programming National Instruments cards, but soms people start using it as a general programming language because that's what they know -- visual interface, more like circuit design, quite interesting actually).

Re:"while Python dominates the scientific communit (0)

Anonymous Coward | more than 2 years ago | (#39938625)

Why is this modded as troll? Did he lie?

Re:"while Python dominates the scientific communit (1)

rioki (1328185) | more than 2 years ago | (#39939169)

And I thought that Fortran 70 was still dominating in the scientific community...

Wrapped C lib, I hope (0)

Anonymous Coward | more than 2 years ago | (#39937731)

Either they wrapped a C library for this, or you'll get to wait extra long for that sim to run. But developer productivity is more important. While the developer is having a cup of coffee, he might even be able to persuade a girl to have it with him, which might lead to some production. Carry on, boys...

Re:Wrapped C lib, I hope (1)

Aardpig (622459) | more than 2 years ago | (#39937803)

C library? But LAPACK is written in Fortran, you insensitive clod!

Re:Wrapped C lib, I hope (2)

seanzig (834642) | more than 2 years ago | (#39937837)

Funny you should mention Fortran. Actually, this Ruby thing might actually work, but only if numerical analysts, scientists, engineers, etc. (non-CS types) like it better than Python. Many such domain experts seem to prefer Fortran or C/C++, perhaps because they learned it in school and/or because everyone in their field before them used it to build the existing code bases. Python does have a hell of a head start, though.

Re:Wrapped C lib, I hope (3, Funny)

busyqth (2566075) | more than 2 years ago | (#39938005)

This is why I'm developing "FORTRUBY".

FORTRUBY is an all new implemenation of Fortran on top of Ruby.

With FORTRUBY, scientists and engineers can jump right in and start programming in what they're most comfortable with, Fortran, but the Fortran code isn't actually compiled,it's interpreted by a Fortran interpreter written in Ruby.

This allows scientists and engineers to transition gracefully to a modern language like Ruby. At first, they can just write in Fortran and insert calls to the Ruby library. When they're ready to move on, they can actually insert Ruby code into their Fortran programs that gracefully accomodates Fortran data types and arrays by using the special 'RUBY' statement like this:

DIMENSION M(10)
RUBY(FORMAT (5HSUM=0))
RUBY(FORMAT (27HM.EACH DO /X/ SUM=SUM+X END))

Finally, they can transition to full fledged Ruby by just writing the whole program inside RUBY statements. Finally scientists and engineers can move into the 21st century without leaving all their current hard-earned skills behind.

Re:Wrapped C lib, I hope (0)

Anonymous Coward | more than 2 years ago | (#39938247)

Who's Truby? LOL

Re:Wrapped C lib, I hope (1)

rioki (1328185) | more than 2 years ago | (#39939213)

RIIIGHT... You know that in most cases that this FORTRAN code runs for days on clusters composed of tens, if not thousands of nodes? You know that they try to shave each little bit of performance out of it and that is the reason why they use FORTRAN, instead of the nicer C. (Yes, it might not be 100% true that FORTRAN is faster.) And then you want to interpret exactly this code... You can argue as much as you like about languages and semantic... but unless an efficient executable falls out at the end, it is not of much use. All scientists I knew where either using special domain applications or knew how to program in more languages than FORTRAN.

I always thought (2)

outsider007 (115534) | more than 2 years ago | (#39937733)

That Python is for C programmers who want to take a break from semicolons. And ruby is the same but for Java programmers.

Re:I always thought (1)

seanzig (834642) | more than 2 years ago | (#39937859)

That Python is for C programmers who want to take a break from semicolons.

And braces, and no rules for whitespace, and strong typing, ... and ... C. ;-)

Re:I always thought (0)

Anonymous Coward | more than 2 years ago | (#39937905)

I never understood the whitespace complaints about Python. It forces you to indent on nesting. So what? You are not a special and unique snowflake, and even in languages where the compiler doesn't care about your whitespace, if you don't indent on nesting, you are wrong.

Re:I always thought (3, Interesting)

phantomfive (622387) | more than 2 years ago | (#39937957)

Because people like using different indentation styles, which sometimes can be clearer. For example, something like this:

//ensure all sides are checked
if(!checkedUp() ) checkUp();
if(!checkedDown() ) checkDown();
if(!checkedLeft() ) checkLeft();
if(!checkedRight() ) checkRight();

can be a lot more concise and readable than a forced indentation method. Flexibility is a good thing. It is ok if you don't like the style I just demonstrated, but you should be able to understand that other people do.

Re:I always thought (3, Interesting)

seanzig (834642) | more than 2 years ago | (#39938011)

Nothin' wrong with that, my friend. To translate to Python:

# ensure all sides are checked
if not checkedUp(): checkUp()
if not checkedDown(): checkDown()
if not checkedLeft(): checkLeft()
if not checkedRight(): checkRight()

Re:I always thought (1)

ceoyoyo (59147) | more than 2 years ago | (#39938015)

That's fine in Python.

Re:I always thought (1)

phantomfive (622387) | more than 2 years ago | (#39938045)

lol ok, let me try again. Here's another one I did today, in C:

acquireLock();

code();
moreCode();
yetMoreCode();

releaseLock();


I found it more readable to go an extra indent level, even though it wasn't necessary.

Re:I always thought (1)

ceoyoyo (59147) | more than 2 years ago | (#39938081)

Better, and in Python:

if acquireLock():
        code()
        moreCode()
        yetMoreCode()
        releaseLock()

or

try:
        acquireLock()
        code()
        moreCode()
        yetMoreCode()
        releaseLock()
except:
        panic()

Even your way, I'd happily surround the locked block with a couple of comments to indicate it, in return for getting rid of curly braces and yahoos who DON'T use indentation to make things clearer.

Re:I always thought (0)

Anonymous Coward | more than 2 years ago | (#39938151)

Or:

with acquirelock():
                code()
                moreCode()
                yetMoreCode()

Re:I always thought (0)

Anonymous Coward | more than 2 years ago | (#39938507)

Or (py2.5+):

with lock:
        code()
        moreCode()
        yetMoreCode()

Re:I always thought (0)

Anonymous Coward | more than 2 years ago | (#39938103)

Of course there is a way to do what you just mentioned in python: write it as a function. Because anything that requires so many lines of code that they need to be specified as a unique block, should probably be written as a function in case you need to call it later or in a different context.

def doSomething( parameter ):
        acquireLock()
        lotsOfCode()
        releaseLock()

Re:I always thought (1)

hey (83763) | more than 2 years ago | (#39939453)

acquireLock();
code_moreCode_yetMoreCode();
releaseLock();

Re:I always thought (1)

phantomfive (622387) | more than 2 years ago | (#39941151)

I'm not sure that's more readable.....

Re:I always thought (2)

Riskable (19437) | more than 2 years ago | (#39939845)

The most "Pythonic" way to handle your scenario is both efficient and chimes well with your readability standards:

# Assuming you've got a threading.Lock or multiprocessing.Lock object called 'my_lock'...
with my_lock:
        code()
        moreCode()
        yetMoreCode()
# ...and that's it!

Note that there's no need to call something like releaseLock() since Lock() objects support the 'with statement' (aka context manager). The indentation rules mean that the lock is released at the end of the 'with' block. Another advantage of this solution ('with statements') is that if one of those functions causes an exception the lock will be released in an orderly fashion. This is very effective at:

1) Preventing deadlock situations.
2) Making code concise and easy-to-read.

Also, thanks to Python's dynamic nature you can extend your lock objects to make them perform additional actions in the event of an exception (among other things).

Re:I always thought (2)

FrootLoops (1817694) | more than 2 years ago | (#39938027)

Python already has a single-line if:

if (not checkedUp()): checkUp()
if (not checkedDown()): checkDown()

is valid Python. I've never felt constrained by Python's indentation style. My experience isn't extensive, though; maybe a few thousand lines.

Re:I always thought (0)

Anonymous Coward | more than 2 years ago | (#39942107)

I've never felt constrained by Python's indentation style.

Then you've never had to write a lambda requiring more than one line of logic.

Re:I always thought (1)

sourcerror (1718066) | more than 2 years ago | (#39938543)

1, Because it'll break code when copypasting from a website.
2, Because you can't use matching braces feature of your IDE if you don't have braces, and it's harder to see when blocks start or end when you have a method that's longer than your screen height.
3, Because your IDE could autoindent your code if you used braces.

Re:I always thought (1)

gd2shoe (747932) | more than 2 years ago | (#39938763)

1, Because it'll break code when copypasting from a website.

A valid issue. This presupposes that either the poster was an idiot who couldn't be bothered to use a code block, or the website is overly limited. It does happen, but coders worth listening to will usually cushion their code well.

2, Because you can't use matching braces feature of your IDE if you don't have braces, and it's harder to see when blocks start or end when you have a method that's longer than your screen height.

Try using more than 2 spaces to equal a tab. Yeah, that's sacrilege, I know. Other benefits of brace matching (such as collapsing code blocks) are still entirely feasible, and some editors will do it for you. Besides, without the brace clutter, it's easier to see where blocks start and stop anyway. You scroll up or down until it's no longer indented. I really hope you're not reading code blocks that are pages upon pages upon pages. Python might be harder to write unreadable code, but only a little.

3, Because your IDE could autoindent your code if you used braces.

Um... Every IDE (and text editor) I've used has auto-indented python for me. Yeah, I have to hit tab on the first indented line, but that's easier than hitting an open bracket. From there, they all keep the indent until I backspace one, which is easier than a close bracket.

Re:I always thought (1)

Riskable (19437) | more than 2 years ago | (#39939989)

1, Because it'll break code when copypasting from a website.

This is pretty rare these days since everyone uses code pasting sites like codepad.org and github's gist but it is a valid point.

2, Because you can't use matching braces feature of your IDE if you don't have braces, and it's harder to see when blocks start or end when you have a method that's longer than your screen height.

What the heck?!? You've obviously never coded Python in an IDE that supports Python. Python has braces, parens, and brackets for a lot of things (dicts, tuples, and lists, respectively) and the matching braces feature works fine. Why would it be different? Not only that but most editors that support Python also offer code collapsing and indentation works better for this purpose since you don't need matching brackets features to find the end of a function or object.

3, Because your IDE could autoindent your code if you used braces.

Citation needed. Every IDE I've ever used to code Python auto-indents my code blocks just fine. Real simple rules too: If there's a colon that's not already inside braces, indent the next line. Compare this to other languages where a brace could indicate any number of things. Figuring out when to indent is a lot more complicated.

Re:I always thought (1)

mzs (595629) | more than 2 years ago | (#39946173)

1. vim s///g
2. vim folding
3. vim >, <, or =

I guess vim isn't an ide though, thankfully.

Re:I always thought (1)

Bill_the_Engineer (772575) | more than 2 years ago | (#39940023)

The 1970's called and they want their whitespace dependencies back. Everything is cyclical. Freeform languages become the rage after years of being shackled to languages based on punchcards where position is everything (e.g.. Fortran 77). Fast forward to today and we have people singing the praises of whitespace significance within Python.

Next thing you know, we'll be talking about the merits of running applications on a centralized machine and having the users accessing their applications with thin clients. Oh Wait....

Re:I always thought (0)

Anonymous Coward | more than 2 years ago | (#39940855)

It violates the principle of separation of semantics and presentation.

Indenting lines to make code readable is the job of the IDE/text editor. By making white space a part of the syntax of the language, you don't add readability and any well designed development environment, and you instead make me police any code I write for stray white space. It's also a bitch for new coders (or experienced coders learning a new library) who do a lot of copy/pasting from tutorials while they're learning.

Re:I always thought (1)

mzs (595629) | more than 2 years ago | (#39946405)

That principle allows you to have line noise that parses in other languages, make is harder to do that in python, so I don't know really if it should be followed to such dogmatic ends. There still is a lot of freedom in presentation in python after all. The cstyle and later astyle commands are a taste thing, some C coders liked it, others didn't. I always like to use whitespace to help me and others understand code and have it in a consistent style from the get go, not have a script or program munge it for me. I can have my editor auto indent python code too though, I use that a lot like when moving a block of code into a function, its moves over to the left on paste. Also about the new coders and pasting from examples on the web, having your editor change tabs to spaces always including (especially?) on paste seems to do the trick pretty well for those that do not want to deal with that headache.

Re:I always thought (1)

lucian1900 (1698922) | more than 2 years ago | (#39940385)

You may be confusing strong typing with static typing. C is statically, weakly typed and Python is strongly, dynamically typed. PHP is weakly, dynamically typed.

Re:I always thought (1)

Bill_the_Engineer (772575) | more than 2 years ago | (#39939975)

Python and Ruby both are for Perl programmers who haven't lost their sanity yet.

Tell me one thing this brings to the table (4, Insightful)

ubergeek (91912) | more than 2 years ago | (#39937935)

This seems like a terrible idea. What could scientific computing with Ruby possibly offer that SciPy doesn't already? Way to split the potential work force guys. If you want to develop a scientific computing library for a rich dynamic language, then contribute to SciPy. What a wasted effort.

Re:Tell me one thing this brings to the table (1)

Anonymous Coward | more than 2 years ago | (#39938055)

1. ruby - it is quite awkward using scipy from within ruby code.

Re:Tell me one thing this brings to the table (1)

ubergeek (91912) | more than 2 years ago | (#39938153)

Har har. Thanks genius.

Re:Tell me one thing this brings to the table (3, Interesting)

Anonymous Coward | more than 2 years ago | (#39938557)

No, seriously, that's the most significant thing it brings to the table. With a minimal amount of functionality implemented, far more scientific problems can be addressed in ruby and integrated into a larger, thriving ecosystem (>38,000 ruby gems and counting). Ruby already has strong web applications; complemented with better science libraries a lot of great science can be accomplished (opentox [opentox.org] is an interesting example of this kind of integration)

Sciruby brings ruby to the scientific programming table. Anything else sciruby accomplishes is icing on the cake.

Re:Tell me one thing this brings to the table (3, Informative)

FrootLoops (1817694) | more than 2 years ago | (#39938185)

The SciRuby Manifesto [github.com] does discuss the question, "Why Ruby?"

Why Ruby?

First and least, Ruby is a language with a sense of humor.

But more importantly, numerical computation and visualization can be done much better in Ruby, for a number of reasons:

        ''Everything returns a value.'' Ruby's better object model means better chaining of computation.
        ''Iterators'' are way better than ''for'' loops (each_slice, each_cons, etc.).
        ''Readability.'' Ruby is incredibly readable, which makes it uber-maintainable.
        ''Metaprogramming.'' Sometimes the simplest solution is to write a [http://github.com/wycats/thor code generator]. Sometimes, eigenclasses are the cleanest.
        ''Integration into Rails.'' The influence of Rails on Ruby is undeniable. Web-based visualization for scientific projects is the future.
        ''R is nice but clunky.'' The learning curve is enormous. It does some things very well, and others not very well at all (try doing a multi-line plot in R).

Unfortunately it ignores the alternative of just using Python.

There's also a (I'll be charitable) silly discussion in this vein on the same page:

Ruby has no equivalent to the beautifully constructed numpy, scipy, and matplotlib libraries for Python. We believe that the time for a Ruby science and visualization package has come and gone. Sometimes when a solution of sugar and water becomes super-saturated, from it precipitates a pure, delicious, and diabetes-inducing crystal of sweetness, induced by no more than the tap of a finger. So it is, we believe, with the need for numeric and visualization libraries in Ruby.

IMO, this is a misguided waste of time and it's nearly inactive anyway.

Re:Tell me one thing this brings to the table (4, Interesting)

bwv549 (1730430) | more than 2 years ago | (#39938465)

Unfortunately it ignores the alternative of just using Python

The option of using python is implicitly rejected. Why would the contributors spend time on sciruby when they clearly know scipy exists? Speaking for myself, I've used python and scipy (both numpy and matplotlib) for several projects, but I much prefer coding in ruby to python. All the functionality of scipy isn't going to be duplicated with sciruby, but if the most common use cases are implemented, then I can use ruby for most projects.

this is a misguided waste of time

why? It's easier to re-implement (i.e., borrow from scipy) than implement in the first place, so it doesn't take all that much time. And, as pointed out, this is currently a minor project compared to scipy, so if it is a waste of time then it's not a lot of it.

Python has a "there is only one true way" mentality, so there isn't a lot of room to try and innovate within scipy. Perhaps sciruby will innovate in significant ways and scipy will draw a little from it one day.

and it's nearly inactive anyway

The fellowship and nmatrix commit history [github.com] would suggest otherwise.

Re:Tell me one thing this brings to the table (1)

FrootLoops (1817694) | more than 2 years ago | (#39938651)

I agree that since this doesn't have a lot of contributors it isn't a huge waste of time, though that's not a good argument. The question is if it's worth the resources to reinvent the wheel (even just porting entails a lot of work, and I'm not sure that's what they're after here) just so people can use their preferred language. I would say no since the difference between the languages isn't enormous. It's unfortunate, but tradeoffs need to be made and not every language can have nice numerical and algebraic libraries. Oh well.

As for (in)activity, the fellowship is quite small ($1500 stipend) and the nmatrix commits you mention have essentially one contributor. That's also the current most active SciRuby repo with the others being essentially flatlined for months.

If you actually like the project, perhaps you should contribute. It seems they could use people badly. You may be right about innovation; one never knows.

Re:Tell me one thing this brings to the table (1)

gd2shoe (747932) | more than 2 years ago | (#39938809)

Python has a "there is only one true way" mentality...

I think "had" would be a better way of putting it. Python set out to be the anti-Perl. This required making sure there was no bizarre behavior that coders could exploit to make their code more unreadable, and easier to break. There are a few kinks that are more limiting than I would like, but the language has gained a lot more flexibility over the years.

Re:Tell me one thing this brings to the table (1)

BlackPignouf (1017012) | more than 2 years ago | (#39938865)

Well, Ruby & Python are just like islam & Judaism or vim & Emacs.
They're very similar, yet distinct, and once you've chosen one path, it's hard to take another.

I'm really good at using Ruby, know the inner workings, wrote many plug-ins and applications, and contributed to the project.
There are many cool projects for Python that I'd love to understand, use and contribute to.

I tried some tutorials for Python, but it feels like a waste of time when I already know a OO high-level scripting language.

A common compiler would be really cool, but I don't know if it is even possible.

Re:Tell me one thing this brings to the table (0)

Anonymous Coward | more than 2 years ago | (#39941009)

Well, Ruby & Python are just like islam & Judaism or vim & Emacs.
They're very similar, yet distinct, and once you've chosen one path, it's hard to take another.

I'm really good at using Ruby, know the inner workings, wrote many plug-ins and applications, and contributed to the project.
There are many cool projects for Python that I'd love to understand, use and contribute to.

I tried some tutorials for Python, but it feels like a waste of time when I already know a OO high-level scripting language.

A common compiler would be really cool, but I don't know if it is even possible.

Its hard to get executed for converting from vim to Emacs.

Re:Tell me one thing this brings to the table (0)

Anonymous Coward | more than 2 years ago | (#39941949)

Its hard to get executed for converting from vim to Emacs.

Yeah? Then why do they call it an executable?

Do we really need this? (1)

tronbradia (961235) | more than 2 years ago | (#39938057)

This Ruby/Python thing has gone on long enough. Here we have two languages with identical use cases, identical advantages/disadvantages, and (in the grand scheme of things) almost identical properties in every way. The practical differences between them stem almost entirely from the fact that they happen to be used by different communities, so certain modules in each are much better developed than in the other.

The fact that they both exist has split development effort to the detriment of both. For example, the people that made this package for Ruby are just reimplementing NumPy, providing no advantage whatsoever over NumPy except for the ability to import Ruby packages. Which Ruby packages these people want to import for their scientific computing project that don't have Python equivalents, I have no idea, but maybe they should have implemented or improved those in Python?

Likewise, mod me troll, but I'm guessing Django wouldn't exist if Rails was a Python module. Tons of effort was duplicated there.

Can we just friggin' pick one and leave the other one to die? I don't care which, I'm not taking sides, it just seems to be a really silly duopoly.

Re:Do we really need this? (1)

Anonymous Coward | more than 2 years ago | (#39938175)

ruby and python are sufficiently distinct in syntax and philosophy that they diverge in interesting ways. They are also sufficiently similar that when a really good idea emerges from one the other one tends to adopt it in some form. This weird genetic recombination keeps both languages innovating and fresh. It may actually be a net gain.

maybe parrot will save us all...if not, I vote for ruby ;)

Re:Do we really need this? (1)

outsider007 (115534) | more than 2 years ago | (#39938237)

Can we just friggin' pick one and leave the other one to die? Yes, as long as it's Ruby :)

Re:Do we really need this? (0, Troll)

Greyfox (87712) | more than 2 years ago | (#39938271)

Better yet, can we leave them both to die? The only reason python didn't completely dominate the entire scripting and rapid prototyping arenas was because of that whitespace thing. They could have changed that at any time, but they refuse to even admit it's a problem. Fuck those guys. And Ruby... it actually tries and in the hands of a decent programmer it can actually be good. But I've suffered far too much at the hands of bad Ruby programmers to like Ruby anymore. I know that you shouldn't blame a language for its bad programmers, but its syntax is quirky enough that it makes bad programming particularly intolerable. So fuck those guys too.

I'd say I'd rather they just wrote it all in Java but... Oracle... fuck those guys. And C++ is a little too... esoteric... for many people to be all that good at it. So I guess that leaves us with Perl and C, pretty much where we were 20 years ago.

Re:Do we really need this? (0)

Anonymous Coward | more than 2 years ago | (#39938341)

Maybe I'm using Ruby too much to realize it's quirky, would you mind giving an example?

Re:Do we really need this? (1)

outsider007 (115534) | more than 2 years ago | (#39938633)

It's quirky compared to Perl because Perl programmers are 50 year old men who all know each other.

Re:Do we really need this? (1)

rioki (1328185) | more than 2 years ago | (#39939419)

return statement?

Re:Do we really need this? (1)

pmontra (738736) | more than 2 years ago | (#39939489)

A Ruby method either explicitly "return expression" or just returns the last expression it evaluates. That's similar to a number of other languages. There are many languages that return the value assigned to the name of the function (Matlab, almost, in a slightly more bizarre way ; Pascal, if I remember well). Ruby gives a choice.

Re:Do we really need this? (1)

Greyfox (87712) | more than 2 years ago | (#39941293)

I'll give you an example

My biggest complaint with the language is that it does not remain consistent across even minor language versions. You haven't really lived until you've had to make two libraries that require two different and incompatible versions of Ruby work together. I've been burned a few times in the gem system around object versions. New library required by some program introduces an incompatibility with some other library that other things depend on, makes a huge mess.

Monkey patching is a cool and powerful and far too dangerous to put in the hands of a novice programmer. Or most programmers, for that matter. On a production environment you want your objects to be stable and predictable. Being able to change the behavior of your nicely designed objects by including a new library is just dangerous. You can also add new code to existing instances of existing objects. Or build a massive "include" object with circular dependencies. It was common to see that with bad C++ programmers back in the day (All objects end up inheriting from all other objects.)

A lot of type safety problems could be caught with stronger typing. I'm a bit spoiled by C++ though. It's really hard to make a type error in C++. I often find myself wishing for perl's "using strict" in Ruby.

unless I decide not to give you an example.

Re:Do we really need this? (1)

Bill_the_Engineer (772575) | more than 2 years ago | (#39941605)

My biggest complaint with the language is that it does not remain consistent across even minor language versions.

Amen! Nothing gets my goat like all the revisions of code I have to do between the versions of Python... wait we are talking about Ruby? Sorry.

I find this a little hard to swallow since I haven't experienced too much inconvenience between minor versions of Ruby. Of course both Python and Ruby are relatively young and prone to these minor inconveniences.

Re:Do we really need this? (3, Insightful)

Zapotek (1032314) | more than 2 years ago | (#39938473)

I've been writing Ruby for a couple of years now and a couple of weeks ago I went for an interview about a position with heavy Ruby coding.
During one of the interviews, the guy hit the nail on the head:

A lot of people don't write Ruby when they're coding in Ruby.

In reality, Ruby practices make a lot of sense under the context of the language and when you get comfortable with them then you've reached a position when you can take advantage of what Ruby has to offer -- mainly brevity (without sacrificing clarity) and flexibility (crazy introspection and meta-programming capabilities).

There are a lot of things in the Ruby universe that suck (the interpreter can be quirky, gem management can bit flaky, documentation could be better), the language proper is not one of them.
However, (surprise, surprise) like with anything else in life, you've got to weigh the pros and cons and find something that suits you and/or your needs.
Ruby suits a lot of people's needs, that's why it exists, obviously -- so no, we're not where we were 20 years ago, not by a looong shot.

Re:Do we really need this? (0)

Anonymous Coward | more than 2 years ago | (#39941771)

The problem is that both these languages are way over-hyped and touted for use in domains way beyond what they are suited for. They both also have more than their fair share of zealots who loudly and continuously proclaim their languages' total superiority every chance they get. This behaviour is no doubt quite off-putting to many people who would otherwise be interested in learning these languages.

At this point, only Python has gained any real traction (although not nearly as much as the hype machine suggests), so despite its many quirks it is probably correct to shift resources towards it and away from Ruby. Having said that, I still use Perl much more than either of the other two, as Perl is still the best of these languages at what it was designed for: text processing. For serious projects, I wouldn't consider using any dynamic language, due to issues of speed, scalability, maintainability, etc.

Keep scripting languages where they belong, for quick, one-off programs/proofs-of-concept and/or gluing other programs together!

Non-story (3, Insightful)

FrootLoops (1817694) | more than 2 years ago | (#39938133)

The fellowship is a summer long with only a $1,500 stipend. The most recent commit [github.com] is from December 1st, 2011. The wiki and issue tracker appear to be similarly inactive. Even if the project does something, it probably won't do much; contrast it with numpy commits [github.com] which are recent and numerous.

This story should never have been accepted. There are a million minor projects like this that similarly aren't newsworthy enough to discuss.

Re:Non-story (3, Interesting)

bwv549 (1730430) | more than 2 years ago | (#39938303)

The slowdown in commits to sciruby proper is due to the recent efforts on nmatrix (the subject of the story). The github commit history [github.com] is easily accessible and shows a flurry of activity. Many projects associated with sciruby are also not housed directly under the sciruby name (e.g., rubyvis [rubyforge.org] )

There are a million minor projects like this that similarly aren't newsworthy enough to discuss

... yet here we are...

The lack of comparable scientific libraries is the primary reason many folks choose python over ruby. It's true that sciruby is young and doesn't yet compete with scipy/numpy, but the point is that it continues to pick up steam. A lot of folks who would rather code in ruby think this matters.

Re:Non-story (1)

FrootLoops (1817694) | more than 2 years ago | (#39938711)

but the point is that it continues to pick up steam

Really? I see one active contributor on these five SciRuby repos [github.com] (who is responsible for the "flurry of activity" you describe) with an overall trend downwards. The port you linked is also essentially inactive, though it may simply be complete. By contrast there's half a dozen different contributors on the first numpy commit page I linked alone.

OT: Nice Bach piece by the way. Why did you pick it?

Re:Non-story (0)

Anonymous Coward | more than 2 years ago | (#39939499)

>>The fellowship is a summer long with only a $1,500 stipend.
What did you expect, a Ring?

Matlab (and possibly R) vs any other language (2)

pmontra (738736) | more than 2 years ago | (#39938547)

I've been using Octave (an open source version of Matlab) in Stanford's online PGM course [coursera.org] . My first reaction was "great matrix manipulation library, extremely bad language". It's like time travelling to the 70's and discarding every progress CS made in the last forty years. Actually Matlab has object oriented classes now but somebody commented in the PGM forums that it's not so good. (Octave uses an older Matlab OO syntax I'll be merciful not to comment about.) I don't have any direct experience with R but on the PGM forum I read that its status is not so different.

My suggestion to the scientific community is to work on replacing those old languages with something modern, even Python which I cordially hate because of that white space thing. Obviously you need a fast (written in C) scientific library and an interactive prompt is extremely handy. Python and Ruby are sensible choices IMHO. Matlab and R won't disappear, Cobol didn't go away, but there is no reason why a 20 years old student shouldn't start coding with a modern language, if it's on par with the old ones (a big if, I know).

Re:Matlab (and possibly R) vs any other language (3, Insightful)

loufoque (1400831) | more than 2 years ago | (#39939017)

What people fail to understand is that OOP is a bad paradigm for numerical computing. It's ill-suited to vectorization and parallelization.

Re:Matlab (and possibly R) vs any other language (0)

Anonymous Coward | more than 2 years ago | (#39939173)

doesn't change how much matlab sucks. The expression rules are pretty stupid and they try to stick to a c api for things like strings... Stuctures also suck mainly because they're slow and dynamically composed. Lack of good meta programming as well... Matlab truely sucks as a general purpose language and the tragedy in industry is that it is used as a general purpose language and simulation platform. Otoh scipy etc haven't gotten anywhere close to feature or api parity.

Mingw support (1)

FithisUX (855293) | more than 2 years ago | (#39938685)

I hope they support mingw via devkit tdm. Julia tries to use libuv to be cross-platform.

Why not Lisp ? (0)

Anonymous Coward | more than 2 years ago | (#39940623)

It is an awesome language; is reasonably fast, with some compiling implementations (SBCL, CCL, Allegro.. ).
The FFI is so much easier to use, and Macros make the task of writing dreary wrappers (I'm looking at you Python\{Scipy weave, Cython ...} ).
The community is sparse as always; but there are some projects like Matlisp which are reasonably complete.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?