SciRuby: Science and Matrix Libraries For Ruby

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."

Comments

how does this bring balance?

[Anonymous Coward]

unless it also pushes bizPython!

"while Python dominates the scientific community."

[Anonymous Coward]

*cough* bullshit *cough*

Re:"while Python dominates the scientific communit

[mooingyak]

*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.

Wrapped C lib, I hope

[Anonymous Coward]

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

[Aardpig]

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

Re:Wrapped C lib, I hope

[seanzig]

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

[busyqth]

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

[Anonymous Coward]

Who's Truby? LOL

Re:Wrapped C lib, I hope

[rioki]

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

[outsider007]

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

[seanzig]

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

[Anonymous Coward]

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

[phantomfive]

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

[seanzig]

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

[ceoyoyo]

That's fine in Python.

Re:I always thought

[FrootLoops]

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

[phantomfive]

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

[ceoyoyo]

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

[Anonymous Coward]

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

[Anonymous Coward]

Or:

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

Re:I always thought

[Anonymous Coward]

Or (py2.5+):

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

Re:I always thought

[sourcerror]

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

[gd2shoe]

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

[hey]

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

Re:I always thought

[Riskable]

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

[Bill_the_Engineer]

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

Re:I always thought

[Riskable]

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

[Bill_the_Engineer]

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

[lucian1900]

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

[Anonymous Coward]

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

[phantomfive]

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

Re:I always thought

[Anonymous Coward]

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

[mzs]

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

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

Re:I always thought

[mzs]

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

[khipu]

Well, that's extremely bad code in any language with exceptions, and it can fail even in C with signals or longjmp.

In Python, you should use "with lock:" or "try: ... finally: ..." which automatically give you the indentation.

If you really want an extra level of indentation for no good reason, you can use "if 1:" before the block.

Re:I always thought

[khipu]

That's not a problem with indentation; Python just doesn't have a full lambda construct.

As far as I'm concerned, that's fine. Python has a number of alternative constructs (iterators, with, explicitly nested functions, list comprehensions, etc.) that are individually more limited, but end up encouraging people to write clearer code. Functionally, it's not a limitation.

Re:I always thought

[Anonymous Coward]

hooray! get rid of those old crusty semi-colons and replace them with cool new colons! I bet you just love inserting [into] colons... :)

Re:I always thought

[phantomfive]

I don't think there is a problem with signals, http://linux.die.net/man/3/pthread_mutex_lock: "If a signal is delivered to a thread waiting for a mutex, upon return from the signal handler the thread shall resume waiting for the mutex as if it was not interrupted."

And you've given an example of why exceptions suck. There are good things about exceptions, but that's one of the bad things.

Re:I always thought

[khipu]

I don't think there is a problem with signals, http://linux.die.net/man/3/pthread_mutex_lock [die.net]: "If a signal is delivered to a thread waiting for a mutex, upon return from the signal handler the thread shall resume waiting for the mutex as if it was not interrupted."

I don't know what acquireLock() is, but the function to acquire a pthread mutex is called pthread_mutex_lock().

And you've given an example of why exceptions suck. There are good things about exceptions, but that's one of the bad things.

The control flow implemented by exceptions occurs in C programs as well, it is simply not made explicit. By making it explicit, constructs like with: and try:finally: can then ensure cleanup in a consistent, lexically apparent way. In C, there is no consistent or lexically apparent way in which non-local exits happen, and there is no consistent or lexically apparent way in which resources are released on those cases.

Re:I always thought

[phantomfive]

I don't know what acquireLock() is, but the function to acquire a pthread mutex is called pthread_mutex_lock().

Yes it is, which is why I linked to the manpage of pthread_mutex_lock(). You were wrong, are you going to keep digging deeper, arguing that you weren't? Or are you ready to accept that pthread_mutex_lock() is not going to return on an interrupt?

The control flow implemented by exceptions occurs in C programs as well, it is simply not made explicit. By making it explicit, constructs like with: and try:finally: can then ensure cleanup in a consistent, lexically apparent way. In C, there is no consistent or lexically apparent way in which non-local exits happen, and there is no consistent or lexically apparent way in which resources are released on those cases.

Oh my friend, let me introduce you to if statements. They are quite ingenious, and allow you to handle conditions, like error states. You may not be familiar with them.

Re:I always thought

[khipu]

Yes it is, which is why I linked to the manpage of pthread_mutex_lock().

You can link to whatever you want to, the example didn't use pthread_mutex_lock(), hence whatever that function does with signals was and is totally irrelevant.

And, actually, if you think that pthread mutex lock's automatic release of resources is a good thing and you rely on it, you are endorsing exception handling, because that's the kind of thing exception handling does for you.

Oh my friend, let me introduce you to if statements. They are quite ingenious, and allow you to handle conditions, like error states. You may not be familiar with them.

Oh, I'm familiar with them, like when shitty programmers produce reams of code in which many errors go unhandled and adding code to recover from errors often requires modifying hundreds of lines in dozens of source files. That's why almost all modern programming languages have exceptions. Of course, if you primarily write code for yourself and by yourself, then you might think that exceptions don't matter.

Re:I always thought

[phantomfive]

You can link to whatever you want to, the example didn't use pthread_mutex_lock(), hence whatever that function does with signals was and is totally irrelevant.

Oh, so you are incapable of reading documentation?

Oh, I'm familiar with them, like when shitty programmers produce reams of code

The shitty programmer is you, dude. A good programmer learns when he is wrong, he doesn't keep arguing like some arrogant guy who thinks the argument actually matters. You've lost, you're wrong, and your coding style reflects the fact that you can't read documentation.

Re:I always thought

[khipu]

Here is the code example you gave:

acquireLock();
code();
moreCode();
yetMoreCode();
releaseLock();

Does that use pthread_mutex_lock() anywhere? No. From your code, one can't tell what kind of resource is being acquired, what non-local exits are possible, or how they are handled. It's code like yours that led to the introduction of exceptions and handlers.

A good programmer learns when he is wrong, he doesn't keep arguing like some arrogant guy who thinks the argument actually matters. You've lost, you're wrong, and your coding style reflects the fact that you can't read documentation.

Look in the mirror, dude, you're talking to yourself.

Re:I always thought

[phantomfive]

I seriously hope you're not this stupid and argumentative in real life.

Re:I always thought

[Anonymous Coward]

You obviously are as stupid and argumentative.

Re:"while Python dominates the scientific communit

[phantomfive]

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

Re:"while Python dominates the scientific communit

[Jane Q. Public]

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

[Pseudonym]

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

[phantomfive]

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

Tell me one thing this brings to the table

[ubergeek]

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

[Anonymous Coward]

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

Re:Tell me one thing this brings to the table

[ubergeek]

Har har. Thanks genius.

Re:Tell me one thing this brings to the table

[FrootLoops]

The SciRuby Manifesto 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

[bwv549]

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 would suggest otherwise.

Re:Tell me one thing this brings to the table

[Anonymous Coward]

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 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

[FrootLoops]

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

[gd2shoe]

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

[BlackPignouf]

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

[Anonymous Coward]

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

[Anonymous Coward]

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

Yeah? Then why do they call it an executable?

Re:Tell me one thing this brings to the table

[mzs]

Wow that's pretty bad, the only reason in that list that makes any sense is the rails one. But there have been lots of visualization packages for science for decades. It's just that it's a brand new group of people, not familiar with what is there, only familiar with what they know already or what there is buzz about, and they want to use that. These are ruby coders after all.

Re:Tell me one thing this brings to the table

[Anonymous Coward]

It's just that it's a brand new group of people, not familiar with what is there, only familiar with what they know already or what there is buzz about, and they want to use that. These are ruby coders after all.

So you know these guys? Perhaps we are referring to a different group of individuals.

I know 3 of the sciruby developers well. I'd say each knows at least 3 languages fairly well (some combination of ruby, R, java, C/C++), and all are familiar with some range of scientific visualization packages. If you look at a lot of the sciruby packages, (say, statsample) most of the routines are implemented in java, C, and ruby. Speaking for myself (I work on sciruby), I've done significant projects in AVS, matlab, scipy/numpy, R, and PDL and worked with other ad-hoc visualization systems, and I've designed my own simple C++ numerical toolkit. I've done projects in ruby, java, C/C++, perl, and python (several of which are published), played around with a dozen programming languages, and I've done real work with another dozen visualization/science toolkits. We recognize that more experienced science/vis programmers exist and acknowledge the great toolkits already in existence--we just think ruby should have one, too.

These are ruby coders after all.

Most of the ruby programmers I know arrived at ruby after sampling a fair number of languages, and the ruby programmers I know stack up well against coders from any other language. Maybe that's just the domain I'm in.

only familiar with what they know already

doesn't this apply to everyone? [If we equate knowledge and familiarity]

Re:Tell me one thing this brings to the table

[mzs]

Sorry if I caused any offense. I don't know them, I'm sure they are great. I was just replying in regards to the list of reasons, which I thought was weak in my opinion. Sometimes I get cynical and snarky, again I apologize. I should have stopped at before all that you quoted, it was a reasonable response the words I wrote before that. Basically that not much has kept-up with visualization, especially in a browser. I worked (wow now more than fifteen years ago) on that as my first job after graduation, it sort of depresses me the state of scientific visualization to this day, hence why I got so grumpy in my reply. Cheers

Re:"while Python dominates the scientific communit

[ceoyoyo]

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.

Do we really need this?

[tronbradia]

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?

[Anonymous Coward]

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?

[outsider007]

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?

[Greyfox]

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?

[Anonymous Coward]

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

Re:Do we really need this?

[Zapotek]

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?

[outsider007]

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?

[rioki]

return statement?

Re:Do we really need this?

[pmontra]

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?

[Greyfox]

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?

[Bill_the_Engineer]

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?

[Anonymous Coward]

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

[FrootLoops]

The fellowship is a summer long with only a $1,500 stipend. The most recent commit 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 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

[bwv549]

The slowdown in commits to sciruby proper is due to the recent efforts on nmatrix (the subject of the story). The github commit history 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)

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

[FrootLoops]

but the point is that it continues to pick up steam

Really? I see one active contributor on these five SciRuby repos (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

[Anonymous Coward]

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

Re:Non-story

[bwv549]

I haven't done the calculations, but I'm guessing that there have been more lines of code committed to sciruby in the past few months than to scipy.

OT: It's one of the great little pieces he wrote when he was younger and a little more reckless with his style. When we stumbled on it a while back it inspired my brothers and I to write a string of compositions with a little of the same panache.

Re:Non-story

[FrootLoops]

Glancing at the commits for both projects, I would be extremely surprised if that were true. But oh well, I don't really care at this point :).

Re:"while Python dominates the scientific communit

[Anonymous Coward]

> 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

[Pseudonym]

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

[Samantha Wright]

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.

Matlab (and possibly R) vs any other language

[pmontra]

I've been using Octave (an open source version of Matlab) in Stanford's online PGM course. 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

[loufoque]

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

[Anonymous Coward]

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.

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

[khipu]

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

What people fail to understand is that >95% of any big scientific code is not performance critical, parallel, or vectorized. It's that code that needs to be written in OOP. That's why a good scientific language needs both good OOP support and good vectorization/parallelization support these days.

Re:"while Python dominates the scientific communit

[Anonymous Coward]

Why is this modded as troll? Did he lie?

Mingw support

[FithisUX]

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

Re:"while Python dominates the scientific communit

[Pseudonym]

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

[solidraven]

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

[ceoyoyo]

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

[rioki]

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

Re:"while Python dominates the scientific communit

[rioki]

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

Re:"while Python dominates the scientific communit

[Anonymous Coward]

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

[Bill_the_Engineer]

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

Re:"while Python dominates the scientific communit

[Bill_the_Engineer]

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.

IDL ... ick.

[oneiros27]

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.

[Bill_the_Engineer]

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.

[Bill_the_Engineer]

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.

[Anonymous Coward]

... 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

[Anonymous Coward]

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

[ceoyoyo]

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.

Why not Lisp ?

[Anonymous Coward]

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.

Re:"while Python dominates the scientific communit

[Samantha Wright]

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

[Samantha Wright]

Physicists are perhaps more famous for the same folly; one example I recently stumbled upon was David Boehm, 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

[Bill_the_Engineer]

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

[Gripp]

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

[Gripp]

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 )
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

[GravidMind]

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

[Anonymous Coward]

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

[Jane Q. Public]

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

Not really. First, it's a Web survey of discussions, not a measure of how popular these languages are in actual use. One might infer a relationship, but it ain't necessarily so, and even if there is one, who knows how strong that correlation is?

Second, being a web survey, web-oriented languages (like JavaScript; a rather glaring example) are over-represented. Perl (another good example) is a legacy language that was very popular in its day, although it is almost universally rejected (with a good deal of disgust) by new programmers today in favor of more modern scripts. Perl is in fact an excellent example of my second point.

Re:"while Python dominates the scientific communit

[phantomfive]

lol ok fine, no doubt you are right, and Ruby is much more popular than any metric we can think of indicates.

Re:"while Python dominates the scientific communit

[Pseudonym]

When I was an undergrad, biology was the science you did if you liked science but didn't like maths. That's the reason why I was turned off biology back in the day. Boy how things have changed.

Having said that, it's my experience that it's easier to teach a computer scientist (not just a "tech guy") enough biology than it is to teach a biologist enough software engineering, where "enough" means sufficient to form a productive working partnership. There are, of course, notable exceptions in both directions. But that generally seems to be the case.

Re:"while Python dominates the scientific communit

[Pseudonym]

To be fair, there are a few notable physicists who have made major contributions to other fields. Dijkstra is the one that most computer scientists know. They are, of course, notable because they're the exceptions.

Re:"while Python dominates the scientific communit

[solidraven]

First of all. Believe it or not, engineers make up a large part of the scientific community. And you're very mistaken in that though. MATLAB is often the best tool for the job. Go and try to prototype any form of digital signal processing system or algorithm in anything else than MATLAB and they'll point and laugh at you. If you do any of that in python or another language you'll find yourself reinventing the wheel simply cause all those functions already exist in MATLAB. And at least you can be certain those will work compared to your own writings.
Actually, it's not a small minority. FORTRAN is still the tool of choice in many fields. Especially where massive parallel computing comes into play (think weather forecasting). Another largely unknown language that is used in large systems world wide is Ada. Again it's not very well known. But it's one of the few languages reliable enough to deal with systems like weapon systems, flight traffic control systems, autopilots, ... It's not cause you didn't run into it yourself that it's never used. FORTRAN still makes its daily appearance in most research facilities. And the older researchers will often teach the younger ones about the wonderful language it is.
High level languages are slow and inefficient. You don't need objects for scientific calculations, what you need is a good mathematical library that is capable of handling large vectors/matrices quickly with efficient memory usage. Neither Python nor Ruby are capable of those feats (their libraries are crappy at best compared to the established values). For FORTRAN and MATLAB that's a walk in the park actually. Side bonus is that MATLAB code can be translated into C meaning it can be compiled resulting in near native performance as well. Again something Python and Ruby can't hope to achieve properly cause of their dynamic workings.

Re:"while Python dominates the scientific communit

[ceoyoyo]

You might want to take a bit of a break from Fortran. You seem to be a bit personally attached. Kind of a Slashdot stereotype and all that.

Re:"while Python dominates the scientific communit

[solidraven]

How does this relate to the subject? It's all about using the best tool for the job. And FORTRAN and MATLAB are the best tools.

Re:"while Python dominates the scientific communit

[Jane Q. Public]

"lol ok fine, no doubt you are right, and Ruby is much more popular than any metric we can think of indicates."

That isn't what I was saying at all. What I was saying is that it all depends on what you mean by "popular".

"Legacy languages" (like Perl, and even Java to some extent) remain popular for a long time for several reasons, among those reasons the sheer size of the established code base. I mean, sheesh... there is still a demand, although a small one, for COBOL programmers, and that was the first "high-level language" ever invented!

I'm not saying that Ruby is more popular than the charts indicate. What I was claiming were basically 2 different things entirely: (1) there is a reason for the popularity of some of the other languages that has nothing to do with how popular they are with NEW programmers (which means they are actually in slow decline), and (2) scripting languages like Ruby will become more popular if and when compilers for them reach a certain level of maturity.

Re:"while Python dominates the scientific communit

[phantomfive]

lol we can look at something like github, which has mainly new projects. That has Ruby as the #2 language for projects.

Predicting that a language will become popular in the future is tenuous at best. Ruby doesn't deal with multi-threading as well as some other languages. Will it matter? I don't know, but lack of a compiler isn't the only thing involved in a language's popularity.

Re:"while Python dominates the scientific communit

[Jane Q. Public]

"Predicting that a language will become popular in the future is tenuous at best."

Will you get off the Ruby kick? I was referring to a class of languages, not necessarily a language itself:

"... scripting languages like Ruby ..."

And all I said was that will make them more popular. And that stands to reason, because then they will be useful for a wider range of applications. It hardly takes a Nostradamus to make that prediction.

Re:"while Python dominates the scientific communit

[phantomfive]

lol apparently you think Perl is not a scripting language like Ruby. And ok, I'll agree PHP isn't a scripting language like Ruby.

Re:"while Python dominates the scientific communit

[Jane Q. Public]

"lol apparently you think Perl is not a scripting language like Ruby. And ok, I'll agree PHP isn't a scripting language like Ruby."

Where do you get this stuff? That's not what I said, either.

Tell me: do you know of anybody working on compilers for Perl or PHP? When you do, let me know...

Re:"while Python dominates the scientific communit

[phantomfive]

Tell me: do you know of anybody working on compilers for Perl or PHP? When you do, let me know...

lol your Google-fu needs to improve. There is perlcc, available for a while although I have no clue if anyone is using it, but I do know Facebook is quite proud of their PHP compiler and they definitely use it. Yet another reason to not work at Facebook.

Also, it's not like compiling your code hopelessly obfuscates it. Several times over the last year I've had to disassemble C or C++ source code from an Android system to figure out how something works.

Re:"while Python dominates the scientific communit

[Jane Q. Public]

"Also, it's not like compiling your code hopelessly obfuscates it."

Okay, I knew there was a Perl compiler, but I wasn't aware that anybody actually used it. I was not aware of the PHP compiler.

But you don't need code to be "hopelessly" obfuscated. Even bytecode-compiled code is obfuscated enough for it to be commercially useful. Decompiled code is much harder to read and decipher than plain source code. Another example is the obfuscator that Microsoft used to supply (and maybe still does, I don't know) with Visual Studio, without which many people would not have used it to build commercial products.

Arguing absolutes (like "hopelessly obfuscated") isn't going to get you very far. I am beginning to think you are arguing just to be a troll.

Re:"while Python dominates the scientific communit

[phantomfive]

lol be nice!! You're the one who can't use Google, and I'm the troll??

I guess I can agree that having the code obfuscated makes it harder for a competitor to steal your code completely and wrap it up as their own product. If you're trying to hide your super-secret algorithm, or keep people from cracking your DRM, having the code compiled is a false sense of security. Although I admit some people are afraid of reading assembly.

Re:"while Python dominates the scientific communit

[Jane Q. Public]

I didn't bother to look at Google. I didn't feel my basic argument needed that to support it. And I still don't.

"I guess I can agree that having the code obfuscated makes it harder for a competitor to steal your code completely and wrap it up as their own product."

Which in turn makes the language more popular. That was the essence of what I was saying. Java would not have enjoyed anywhere near the popularity it has had if everybody could see all the source code. Even though decompiling is still possible. And the lack of same has been the deciding factor in my not distributing a couple of programs written in Ruby.

"If you're trying to hide your super-secret algorithm, or keep people from cracking your DRM, having the code compiled is a false sense of security."

Agreed. I think the basic idea is that you are preventing all but the determined from "borrowing" your code.

While I generally agree that "security through obscurity", as a concept, doesn't work very well, it is usually sufficient to block only the casual potential thieves, not the experts. If that were not so, they would not be able to sell all those shitty door locks to people. Which is 95% of them or probably more. Most of them are ridiculously easy to defeat, if you know what you are doing.

Those with skill are going to get in anyway, if they are determined.

Re:"while Python dominates the scientific communit

[phantomfive]

Sounds good.

I'm not so sure that many companies are actually so worried about people looking at their source code, especially for a language such as Ruby which is mainly used on the backend of websites, but I could be wrong.

Re:"while Python dominates the scientific communit

[Jane Q. Public]

"I'm not so sure that many companies are actually so worried about people looking at their source code, especially for a language such as Ruby which is mainly used on the backend of websites, but I could be wrong."

Then you've missed my whole point.

Java is used on the back-end of some websites too. And that is probably where it would have stayed, if it were not compilable to bytecode.

It makes a BIG difference to a LOT of people. Repeat: that's the whole reason why Microsoft included an obfuscator with Visual Studio: because (a) their CLR bytecode compiler did not sufficiently obfuscate the source, and (b) without that, nobody wanted to distribute desktop apps. It wasn't just an extra, it was considered to be essential.

Re:"while Python dominates the scientific communit

[Jane Q. Public]

I should add that Ruby is used for a lot more than just websites. You are probably thinking about Rails. Ruby is suitable (and is used for) all the same kinds of things as Python. It's just that Ruby got a later start, because it wasn't really known outside of Japan until some years after it was created.

Re:"while Python dominates the scientific communit

[phantomfive]

Yeah, Ruby is a fine language. I have nothing against it.

Re:"while Python dominates the scientific communit

[phantomfive]

Maybe. Java isn't very common on the desktop, still. My company uses it though, and we don't use an obfuscator. Do you know if Visual Studio's is commonly used, or are you just guessing again?