Building a business case for Ruby
Joe Van Dyk
I asked this question a little bit ago, but wanted to bring it back up.
I work for <insert huge company that makes really big expensive things
here>. We have "computing standards" that define what's allowable for
usage internally and externally. Technology evaluation boards, etc.
Here's an evaluation of Ruby:
"XXXX already has Product Standards for Python and Perl as
Scripting/Dynamic languages. And for Java as a full programming
language.
Ruby offer nothing significant not found in these XXXXX Standard
languages, and an addition language just adds variation."
Boo, I say! Boo!
We've got mountains of unmaintainable perl stuff here, and I haven't
really seen much in Python. I'm in charge of developing some new
software and would like to use Ruby. Actually, the software is
finished (very quickly) and I just need to get Ruby on the allowed
list. :(
I don't need arguments about Perl vs Python vs Ruby. I would like to
see a discussion of:
1) Why one additional language isn't a bad thing
2) Examples of existing Ruby usages in large scale applications
3) How Ruby can benefit this place
Off the top of my head:
1) C extensions allow us to easily integrate with external existing
software, but I don't know how Perl or Python does in that respect.
2) Built-in support for unit testing.
3) Extendability / maintainability, but I can't think of anything
objective to say here
4) DRb is very useful in developing distributed applications. I'd
imagine Perl and Python have similar features, but don't know anything
about them.
5) ???
Help me out here guys!
Ben Giddings
> 1) Why one additional language isn't a bad thing
"We don't need a Philips screwdriver, we already have a flathead".
More tools can be a better thing (until your toolbelt gets so heavy that it
pulls your pants down and starts showing butt-crack).
> 2) Examples of existing Ruby usages in large scale applications
http://www.rubygarden.org/ruby?RealWorldRuby
I think the NASA and NOAA stuff are some of the best sources for real
world, large-scale stuff. I'm sure Ara will tell you more about what he's
doing.
You might also want to mention Rails, and some of the e-commerce sites (and
other stuff) it powers. Perl, Python and PHP could all do something
similar... but as yet haven't.
> 3) How Ruby can benefit this place
It can begin to replace Perl. It can also make employees happier. :)
> Off the top of my head:
>
> 1) C extensions allow us to easily integrate with external existing
> software, but I don't know how Perl or Python does in that respect.
Both can do it, but from what I hear Ruby's C interface is cleaner and
easier to use.
> 2) Built-in support for unit testing.
Python and Perl have this too, nothing too special here. Ruby's unit-test
framework may be better in some ways, I wouldn't know.
> 3) Extendability / maintainability, but I can't think of anything
> objective to say here
Well comparing OO Perl to OO Ruby you'll have a huge win here in terms of
maintainability. If people are already comfortable with Perl then it
might be a hard sell, but I think it's easier to convert someone who isn't
a Pearl zealot from Perl to Ruby than it is from Python to Ruby.
Aside from the ones you came up with, maybe Ruby's license is better for
your business? I don't know.
Also, is there any Ruby library that you really like that doesn't have a
good Perl/Python equivalent?
Do you have any idea how Python got accepted, and when? Surely the
programming languages in use at that time could do everything Python could
do, though perhaps not as easily.
Good luck! It sounds like you'll need it.
Ben
P.S. Java is a "full programming language" but Python/Perl/Ruby are only
"Dynamic/Scripting" languages?
Joe Van Dyk
On 6/3/05, Ben Giddings <bg-ru...@infofiend.com> wrote:
> On Friday 03 June 2005 16:33, Joe Van Dyk wrote:
> > 1) Why one additional language isn't a bad thing
>
> "We don't need a Philips screwdriver, we already have a flathead".
Good point. :-)
>
> More tools can be a better thing (until your toolbelt gets so heavy that it
> pulls your pants down and starts showing butt-crack).
>
> > 2) Examples of existing Ruby usages in large scale applications
>
> http://www.rubygarden.org/ruby?RealWorldRuby
>
> I think the NASA and NOAA stuff are some of the best sources for real
> world, large-scale stuff. I'm sure Ara will tell you more about what he's
> doing.
>
> You might also want to mention Rails, and some of the e-commerce sites (and
> other stuff) it powers. Perl, Python and PHP could all do something
> similar... but as yet haven't.
I was thinking that. It's completely a different field of work than
what we do though.
>
> > 3) How Ruby can benefit this place
>
> It can begin to replace Perl. It can also make employees happier. :)
>
> > Off the top of my head:
> >
> > 1) C extensions allow us to easily integrate with external existing
> > software, but I don't know how Perl or Python does in that respect.
>
> Both can do it, but from what I hear Ruby's C interface is cleaner and
> easier to use.
Does Perl or Python have DL import functionality?
>
> > 2) Built-in support for unit testing.
>
> Python and Perl have this too, nothing too special here. Ruby's unit-test
> framework may be better in some ways, I wouldn't know.
>
> > 3) Extendability / maintainability, but I can't think of anything
> > objective to say here
>
> Well comparing OO Perl to OO Ruby you'll have a huge win here in terms of
> maintainability. If people are already comfortable with Perl then it
> might be a hard sell, but I think it's easier to convert someone who isn't
> a Pearl zealot from Perl to Ruby than it is from Python to Ruby.
>
> Aside from the ones you came up with, maybe Ruby's license is better for
> your business? I don't know.
I don't know anything about licenses, but this is a very good point.
Are there any functional differences between the three languages'
licenses?
>
> Also, is there any Ruby library that you really like that doesn't have a
> good Perl/Python equivalent?
>
> Do you have any idea how Python got accepted, and when? Surely the
> programming languages in use at that time could do everything Python could
> do, though perhaps not as easily.
No idea yet.
>
> Good luck! It sounds like you'll need it.
>
> Ben
>
> P.S. Java is a "full programming language" but Python/Perl/Ruby are only
> "Dynamic/Scripting" languages?
Yeah, I dunno about that... :-)
James Britt
> Hi,
>
> I asked this question a little bit ago, but wanted to bring it back up.
>
> I work for <insert huge company that makes really big expensive things
> here>. We have "computing standards" that define what's allowable for
> usage internally and externally. Technology evaluation boards, etc.
>
> Here's an evaluation of Ruby:
>
> "XXXX already has Product Standards for Python and Perl as
> Scripting/Dynamic languages. And for Java as a full programming
> language.
Mmmm. Bias. Not good.
>
> Ruby offer nothing significant not found in these XXXXX Standard
> languages, and an addition language just adds variation."
>
> Boo, I say! Boo!
Boo, perhaps, but try turning this around. Suppose Ruby, not Python,
were already on The List, and someone comes to you to make a case for
adding Python.
What do want to hear to convince you? What are you tossing back when
told of Zope, or Twister, or the extensive Python XML tools, or the
amount of documentation, or how it's a great beginners' language, or
whatever Pythonistas think makes a compelling case?
>
> We've got mountains of unmaintainable perl stuff here, and I haven't
> really seen much in Python. I'm in charge of developing some new
> software and would like to use Ruby. Actually, the software is
> finished (very quickly) and I just need to get Ruby on the allowed
> list. :(
Isn't this, then, the best argument? Use Ruby and have code finished
yesterday, or use P* and either never really finish, or never really start?
>
> I don't need arguments about Perl vs Python vs Ruby. I would like to
> see a discussion of:
>
> 1) Why one additional language isn't a bad thing
But it is, all things being equal. It just adds complexity and risk,
unless the new language has a compelling use-case.
I would argue that, if indeed there is little to no Python, that Ruby
should be added *in place of* Python. (This works especially well if
there are no Python developers to argue back.)
You'll need to present a money case; if adding Ruby means making more
money, or saving more money, or both, then you're (probably) golden.
James
--
http://www.ruby-doc.org - The Ruby Documentation Site
http://www.rubyxml.com - News, Articles, and Listings for Ruby & XML
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com - Playing with Better Toys
Joe Van Dyk
> Joe Van Dyk wrote:
> > We've got mountains of unmaintainable perl stuff here, and I haven't
> > really seen much in Python. I'm in charge of developing some new
> > software and would like to use Ruby. Actually, the software is
> > finished (very quickly) and I just need to get Ruby on the allowed
> > list. :(
>
> Isn't this, then, the best argument? Use Ruby and have code finished
> yesterday, or use P* and either never really finish, or never really start?
That would be fine, in my group. And it would be one example when
trying to push this as a company standard, but I doubt it would be
sufficient.
> >
> > I don't need arguments about Perl vs Python vs Ruby. I would like to
> > see a discussion of:
> >
> > 1) Why one additional language isn't a bad thing
>
> But it is, all things being equal. It just adds complexity and risk,
> unless the new language has a compelling use-case.
>
> I would argue that, if indeed there is little to no Python, that Ruby
> should be added *in place of* Python. (This works especially well if
> there are no Python developers to argue back.)
There aren't many Python coders in my group, but I think there are
more through out the company.
> You'll need to present a money case; if adding Ruby means making more
> money, or saving more money, or both, then you're (probably) golden.
Yes. I'm trying to do that now! :-)
James Britt
> On Friday 03 June 2005 16:33, Joe Van Dyk wrote:
>
>>1) Why one additional language isn't a bad thing
>
>
> "We don't need a Philips screwdriver, we already have a flathead".
Not to be difficult, but this sort amounts to arguing that the
difference between [Perl|Python] and Ruby is the difference between a
flathead and a Phillips screwdriver. I think that case could be made
against Perl, but not so much with Python.
> ...>
> You might also want to mention Rails, and some of the e-commerce sites (and
> other stuff) it powers. Perl, Python and PHP could all do something
> similar... but as yet haven't.
Amazon, del.icio.us, slashdot, craigslist: aren't these all P* sites?
Is it that they don't offer their own Rails-like framework? That
apparently hasn't stopped people from building robust, high-volume
sites, so as a business owner I'd be skeptical.
Jim Freeze
> I asked this question a little bit ago, but wanted to bring it back up.
>
> I work for <insert huge company that makes really big expensive things
> here>. We have "computing standards" that define what's allowable for
> usage internally and externally. Technology evaluation boards, etc.
>
> Here's an evaluation of Ruby:
>
> "XXXX already has Product Standards for Python and Perl as
> Scripting/Dynamic languages. And for Java as a full programming
> language.
>
> Ruby offer nothing significant not found in these XXXXX Standard
> languages, and an addition language just adds variation."
So, you're saying they are making judgements about Ruby without actually
even investigating it yet? ;)
> We've got mountains of unmaintainable perl stuff here, and I haven't
> really seen much in Python. I'm in charge of developing some new
> software and would like to use Ruby. Actually, the software is
> finished (very quickly) and I just need to get Ruby on the allowed
> list. :(
> I don't need arguments about Perl vs Python vs Ruby. I would like to
> see a discussion of:
>
> 1) Why one additional language isn't a bad thing
> 2) Examples of existing Ruby usages in large scale applications
> 3) How Ruby can benefit this place
This language stuff reminds me of religious conversion activities.
If you aren't the king and can't make declarations like: "Ala or die!"
(read "Ruby or your fired!") then you are forced to play the part
of the humble wizard who has develops a method for alchemy and
uses it to build up his portion of the kingdom along with anyone
else who will join in.
But, in the case of Perl, you probably feel more like Noah, knowing that
Perl usage is going to bring (financial) destruction to the company and
using the direct approach you will probably be as successful as Noah. ;)
I just wrote a long message to a friend about this issue. I quote
here what I can:
> Why would I want to switch from PERL to Ruby?
Short Answer:
Because Ruby is better and Perl is harmful. Or better
yet, because Perl cannot match what Ruby has to offer.
But, this needs more explanation.
Long Answer:
No amount of physical evidence (or particular
attribute of the language) is going to make or break the
decision. You make the decision by your gut and then find
evidence to support that decision. The only trick is to
get others to make that same 'gut' decision. :)
Most everyone I know using Ruby is doing so because
they were looking for a good scripting language or
one better than Perl. If a person is happy with Perl,
then it would be interesting to know why, but I would
not try to convince them to use Ruby, they have much
bigger problems. ;) However, because an organization
uses Perl, that doesn't mean that the organization is
happy with the outcome. It usually is because that is
all it knows.
However, there are definite reasons why Ruby is an optimal
language for the type of scripting work that is done
in the XYZ industry. But, I don't think that just
listing these here is going to help you make a case
of why to switch.
At YYYY, I have been asking myself questions similar
to your original question[1]:
"If I were my boss (or anyone at YYYY), why would I
use Ruby (over Perl)."
and
"Why should I listen/believe this Jim Freeze guy about
Ruby being better than Perl or Python?"
Well, my current belief is that I can only answer this
question by action. Words alone won't do it. So, in an
effort to do this, I have been translating some existing
code from perl to Ruby. My experiences, I believe, are
equivalent to what you will find. Let me itemize a few:
1) Perl scripts (PS) are not centralized in their location
2) PS are not uniform in handling command line arguments
3) The PS use one primary data structure, the Hash (the array is second)
4) Converting the Perl code to Ruby without thinking reduces code size
by about 30%
5) Refactoring the converted code usually yields a 50-60% reduction in
file size with an increase in readability.
6) The PS's have no unit tests
7) It is difficult to debug the PS's, even with printfs. (Perl doesn't have
the Ruby's equivalent of inspect)
8) The Object Oriented system of Perl is primitive - all methods are class methods.
9) The concept of IP library as we had at YYY has never occurred
to anyone I have talked to at ZZZZ.
10) Code sharing has never occured to anyone at YYYY. This is a direct
result of using Perl. Yes you can share packages with perl, but it is
not usually done in a corp environment. The language does not
encourage it. For some reason, pointing this out is not a strong
convincing point. For most, the response seems to be, well we can
do better and we should. But, they never do.
11) Only one Perl package was being used that did not exist in Ruby, the
GDS parser. I am in the process of porting it to Ruby now.
In the process of converting the Perl code and adding unit tests,
I have found bugs (some innocuous, some not) and design flaws and
weaknesses. The design flaws and weaknesses are mainly related to
the Hash centric nature of the Perl code and the lack of a true OO
system in Perl.
The logic bugs are mainly due to lack of tests. The scary part is
that some of these apps have been around for a while and are considered
to be working bug free.
The best way to convince someone (to at least listen to you) is to port
some code and look at the results.
Before the port I can say:
Your Perl code most likely has bugs, you should switch
to Ruby which is easier to debug and maintain. (not very convincing)
After the port:
Your perl code has bugs. The Ruby port has fixed those bugs and has
unit tests to ensure the correctness of the application. Which would
you rather use and maintain? (more motivation now to listen and
see the benefits of Ruby with a testing and IP sharing framework.)
> We have a large base of PERL code already.
> I need good reason to overcome the inertia.
The important thing to realize is that a large amount of Perl
code does not mean there is any inertia in the corporate
development or runtime environemnt. We have a lot of perl code
at YYYY, but it is scattered and often teeters between
being broken and running without any issues. I personally would
not describe this as having inertia, more like a house of cards. :)
Stepping up to a better language and phasing in a better way of
doing things does not take away existing value.[2]
So, even if some inertia exists, the only inefficiency is in not
adopting the better method. So, possibly, the better question
to pose is, Can Perl meet what Ruby offers? For a number of
issues important in a corporate setting, the answer is clearly no.
- support for unit testing and unit-test framework exists
- code is easy to read
- code is easy to maintain
- code is readily sharable
- code is scalable to multiple developers
- code is scalable in speed - easy to drop down to C code
BTW, I have created OptionParser, Application and project_config
and am releasing them open source. These will definitetly help
you in your deployment efforts.
Footnotes:
[1] At YYYY, I was told they had a recent experience with Python
where they tried to get it installed throughout the company
and replace Perl, and that effort failed. I was asked how is
Ruby different than Python and why would it succeed. The question
at the time was mostly rhetorical, but the point here is that
successful deployment is more based on user support than language
features. You just need to make sure that you have a language
that does not irritate the users (both Perl and Python have
proven themselves capable of irritating the majority).
But the reason Python failed at YYYY was not because of the
language but because of the deployment strategy and user support.
Consider that John Doe and others tried for a total of three times
to get a scripting repository deployed at ZZZZ and failed, whereas
Ruby and the IP library has succeeded. I knew we would succeed
because we gave the engineers what they wanted.
[2] Only a few organizations understand the imperfection of humanity.
There is probably not a single line of text in this email that
I have not had to use the backspace key to correct a mistake.
The same goes for code. It is unlikely that there exists a single script
greater than 100 lines of code that does not have an undiscovered
logic bug.
> Off the top of my head:
>
> 1) C extensions allow us to easily integrate with external existing
> software, but I don't know how Perl or Python does in that respect.
Perl is difficult. I have heard the same for Python, maybe more so.
>
> 2) Built-in support for unit testing.
>
> 3) Extendability / maintainability, but I can't think of anything
> objective to say here
Depends upon the hostility of the person you are talking to.
Take two programs - one in Perl and one in Ruby - create a
five question quiz of various aspects of each program and
have non-programmers take the quiz. This will give you some
numbers of readability.
> 4) DRb is very useful in developing distributed applications. I'd
> imagine Perl and Python have similar features, but don't know anything
> about them.
Good luck. Let me know if I can be of more help.
--
Jim Freeze
Theory and practice are the same, in theory. -- Ryan Davis
Jim Freeze
James, you seem to be right on.
> >Ruby offer nothing significant not found in these XXXXX Standard
> >languages, and an addition language just adds variation."
> >
> Boo, perhaps, but try turning this around. Suppose Ruby, not Python,
> were already on The List, and someone comes to you to make a case for
> adding Python.
>
> What do want to hear to convince you? What are you tossing back when
> told of Zope, or Twister, or the extensive Python XML tools, or the
> amount of documentation, or how it's a great beginners' language, or
> whatever Pythonistas think makes a compelling case?
Yes. Very good point!
> >We've got mountains of unmaintainable perl stuff here, and I haven't
> >really seen much in Python. I'm in charge of developing some new
> >software and would like to use Ruby. Actually, the software is
> >finished (very quickly) and I just need to get Ruby on the allowed
> >list. :(
>
> Isn't this, then, the best argument? Use Ruby and have code finished
> yesterday, or use P* and either never really finish, or never really start?
Ding ding ding ding, we have a winner!
Lothar Scholz
BG> I think the NASA and NOAA stuff are some of the best sources for real
BG> world, large-scale stuff. I'm sure Ara will tell you more about what he's
BG> doing.
You can add BMW here. Sorry if i tell you more i must shoot you.
--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's
Lothar Scholz
>> Well comparing OO Perl to OO Ruby you'll have a huge win here in terms of
>> maintainability. If people are already comfortable with Perl then it
>> might be a hard sell, but I think it's easier to convert someone who isn't
>> a Pearl zealot from Perl to Ruby than it is from Python to Ruby.
>>
>> Aside from the ones you came up with, maybe Ruby's license is better for
>> your business? I don't know.
JVD> I don't know anything about licenses, but this is a very good point.
JVD> Are there any functional differences between the three languages'
JVD> licenses?
They are almost the same.
There are just two exceptions and this makes look Ruby less
functional. No native threads and not very good if you want to embedd
Ruby inside a C application. But otherwise from the core language
functionality they are all the same.
Dan Fitzpatrick
> 1) Why one additional language isn't a bad thing
Because if we never had one additional language we would still be using
Cobol. Ruby is just the next step you take after Perl and Python.
> 2) Examples of existing Ruby usages in large scale applications
We build large applications for "huge companies that [fly] really big
expensive things". We switched to Ruby in January of this year and have
not looked back since. Ruby is an excellent platform for large-scale
application development in my opinion because of the excellent namespace
system, speed of development, code maintainability, and speed of
execution. Our Ruby system currently services over 200 airlines (all 10
of the top 10), 800 aircraft part manufacturers and repair facilities,
and more than a thousand part suppliers. We deliver data on 350,000,000
inventory items and 2 million repair capabilities to 8,000 users.
> 3) How Ruby can benefit this place
Ruby will save money because development and maintenance are faster and
easier. You need less experience to use Ruby than Perl or Python. People
can become productive more quickly.
My 3 cents
Dan
dave
> Ruby will save money because development and maintenance are faster and
> easier.
like this one and a little test project:
Language Evaluation Table for a Test Project
-------------------------------------------------
Time:
Performance:
Line of Codes:
Bugs after 1m of Production:
Time spent in Debug per bug:
Developing Problems:
..
and compare these tables after the test projects are finished.
good luck.
--
>here are more things in heaven and earth,
horatio, than are dreamt of in your philosophy.
"Peña, Botp"
#-------------------------------------------------
#Time:
#Performance:
#Line of Codes:
#Bugs after 1m of Production:
#Time spent in Debug per bug:
#Developing Problems:
#...
and if you want ruby to win hands down, create a project code mgt in ruby
for the above that provides code/project tracking/tracing of code
changes/additions/deletions, providing statistical trending of
lines/classes/methods/module/file per day, bugs per day/wk/month, milestone
achievement rate, key performance indicators, etc... (Remember, mgrs will
certainly doubt you if you just put magic numbers in there).. You've got to
show... The world is a stage..
kind regards -botp
Robert Klemme
> I work for <insert huge company that makes really big expensive things
> here>. We have "computing standards" that define what's allowable for
> usage internally and externally. Technology evaluation boards, etc.
>
> Here's an evaluation of Ruby:
>
> "XXXX already has Product Standards for Python and Perl as
> Scripting/Dynamic languages. And for Java as a full programming
> language.
This indicates that for every supported technology there's quite some
overhead in this company. That might eventually be the reason that will
prevent introduction of Ruby unless you can suggest huge benefits with Ruby
on board.
> Ruby offer nothing significant not found in these XXXXX Standard
> languages, and an addition language just adds variation."
>
> Boo, I say! Boo!
I'd be sorry, too.
> We've got mountains of unmaintainable perl stuff here, and I haven't
> really seen much in Python. I'm in charge of developing some new
> software and would like to use Ruby. Actually, the software is
> finished (very quickly) and I just need to get Ruby on the allowed
> list. :(
This reminds me of the Dilbert catoon where boss wants a plan for some
change to do. Dilbert does it clickedyclick while they are talking. In the
end boss says, "now all I need is the plan".
> Help me out here guys!
Others have posted a lot good arguments in favor of Ruby. Although I too
would certainly do Ruby rather than Perl there might be good reasons for the
company to not introduce Ruby. The time it takes to write a program in any
given language is just one factor. These might be show stoppers
- cost to train people for the new language
- maintenance of an infrastructure for this new language (updates,
development environments...)
- cost to integrate legacy code / applications.
IMHO you can increase your chances of introducing Ruby by
- providing a sound strategy for intregration (and maybe later phase out)
of existing stuff
- demonstrate the easy of access to documentation (ruby-doc) and existing
code (RAA, rubyforge...)
- presenting examples of unmaintainable legacy code that would have to be
rewritten anyway (and that ideally would benefit from being rewritten in
Ruby)
- generally if you not loose sight of the environment where you want to
plant Ruby and considering the fincancial effects.
I wish you luck nevertheless.
Kind regards
robert
Stephan Kämper
> 1) Why one additional language isn't a bad thing
With one more language you have one more choice - which can be a good
thing. Especially if this additional language makes solving the task at
hand easier than another language. If you only know Perl & Java, then
you'll end up using Perl and Java. But if, say, you need a device driver
written? In this case you better also know C, perhaps.
So, to me it seems that you'll in fact 'need' several languages for
different purposes. Administration tools, Numerical modelling, Web
applications, desktop programs, device drivers... Whatever your task is,
you better use an appropriate language for it. And a large company will
very likely need more than 3 languages, I'm pretty sure. After all,
there's a reason why there are thousands of languages (and language
dialects) out there.
But using several languages to solve the same problems isn't a good idea
either. And Ruby, Python and Perl do (try to) solve the same problems -
at least to a certain amount.
So this is where the discussion really starts...
> 2) Examples of existing Ruby usages in large scale applications
http://www.rubygarden.org/ruby?RealWorldRuby
might help you...
> 3) How Ruby can benefit this place
Personally, I need to write less code (compared to Java, C++ and
others), do write more unit tests (or actually write them for that
matter) and get the job (mostly automated testing of other software, but
developing 'real' software too) done.
Happy rubying
Stephan
Stephen Kellett
<joev...@gmail.com> writes
>1) C extensions allow us to easily integrate with external existing
>software, but I don't know how Perl or Python does in that respect.
Having recently written some Ruby and Python extensions I'd say they are
about the same level of complexity. The extensions I wrote did the same
thing for each language and took roughly the same amount of time. The
Python extension used a bit less code and was easier to write, but the
differences are trivial and not worth arguing over.
Perl? I haven't written an extension for it, so no comment.
Stephen
--
Stephen Kellett
Object Media Limited http://www.objmedia.demon.co.uk/software.html
Computer Consultancy, Software Development
Windows C++, Java, Assembler, Performance Analysis, Troubleshooting
Glenn Parker
>
> Perl? I haven't written an extension for it, so no comment.
I have, and it was rather painful. Getting the reference-counting of
results to come out right was the trickiest part. IMO, the Perl (4 & 5)
internals were not designed to be very friendly for those not intimate
with the full source base.
--
Glenn Parker | glenn.parker-AT-comcast.net | <http://www.tetrafoil.com/>
Curt Hibbs
> In message <c715e6405060...@mail.gmail.com>, Joe Van Dyk
> <joev...@gmail.com> writes
>
>> 1) C extensions allow us to easily integrate with external existing
>> software, but I don't know how Perl or Python does in that respect.
>
>
> Having recently written some Ruby and Python extensions I'd say they are
> about the same level of complexity. The extensions I wrote did the same
> thing for each language and took roughly the same amount of time. The
> Python extension used a bit less code and was easier to write, but the
> differences are trivial and not worth arguing over.
I like the way that Ruby extensions appear (to a Ruby program) to be a
*real* Ruby object/class, no different than if I had coded it in Ruby.
I'm interested to know if the same thing true of Python extensions?
Thanks,
Curt
Stephen Kellett
writes
>I like the way that Ruby extensions appear (to a Ruby program) to be a
>*real* Ruby object/class, no different than if I had coded it in Ruby.
>
>I'm interested to know if the same thing true of Python extensions?
For the work I was doing, Python had the same qualities you describe. It
was amazing how similar the process was. But what I was doing wasn't a
huge extension, just some wrappers to calls written in C++.
If I get to do something more complex for both languages I'll provide
more feedback.
Lyndon Samson
James Britt
> You could, er, load ruby as a python extension...
Or sneak it in with JRuby.
James
Xeno Campanoli
rescue SystemCallError
print "parse failed on #{line}" + $!
raise
end
and it doesn't compile:
/validateMenuSpecs.rb:135: syntax error
rescue SystemCallError
^
/validateMenuSpecs.rb:135: warning: useless use of a constant in void
context
/validateMenuSpecs.rb:173: syntax error
--
Xeno Campanoli, xe...@eskimo.com, http://www.eskimo.com/~xeno
Pride before justice equals destabilization.
Power before truth equals destruction.
Profit before environment equals death.
Ghislain Mary
Xeno Campanoli a écrit :
> I can't figure out Rescue. I have the following:
>
> rescue SystemCallError
> print "parse failed on #{line}" + $!
> raise
> end
>
> and it doesn't compile:
>
> /validateMenuSpecs.rb:135: syntax error
> rescue SystemCallError
> ^
> ./validateMenuSpecs.rb:135: warning: useless use of a constant in void
> context
> ./validateMenuSpecs.rb:173: syntax error
>
You must have a context has the warning message tells you. So you must
have something like
begin
# do something here
rescue SystemCallError
print "parse failed on #{ line}" + $!
raise
end
You should then put the code that you expect to get an exception from
after the begin clause.
HTH
Ghislain
Xeno Campanoli
> Hi,
>
> Xeno Campanoli a écrit :
>
>> I can't figure out Rescue. I have the following:
>>
>> rescue SystemCallError
>> print "parse failed on #{line}" + $!
>> raise
>> end
>>
>> and it doesn't compile:
>>
>> /validateMenuSpecs.rb:135: syntax error
>> rescue SystemCallError
>> ^
>> ./validateMenuSpecs.rb:135: warning: useless use of a constant in
>> void context
>> ./validateMenuSpecs.rb:173: syntax error
>>
>
> You must have a context has the warning message tells you. So you must
> have something like
>
> begin
> # do something here
> rescue SystemCallError
> print "parse failed on #{ line}" + $!
> raise
> end
I tried this:
TargetsCategoriesFH.each_line do |line|
begin
target, catlist = line.chomp.strip.split(/\s*:\s*/)
rescue NoMethodError
#print "parse failed on #{line}" + $!
print "parse failed " + $!
raise
end
Xeno Campanoli
> Ghislain Mary wrote:
Okay. I got it. The raise was repeating the error.
xc
> .
> .
> .
> end
>
> and I get
>
> ./validateMenuSpecs.rb:152: private method `chomp' called for
> nil:NilClass (NoMethodError)
> from ./validateMenuSpecs.rb:132:in `each_line'
> from ./validateMenuSpecs.rb:132
>
> with the rescue code commented out, I get:
>
> ./validateMenuSpecs.rb:153: private method `chomp' called for
> nil:NilClass (NoMethodError)
> from ./validateMenuSpecs.rb:132:in `each_line'
> from ./validateMenuSpecs.rb:132
>
> Again.
>
>>
>> You should then put the code that you expect to get an exception from
>> after the begin clause.
>>
>> HTH
>>
>> Ghislain
>>
>>
>>
>
>
gabriele renzi
> In message <42A5E046...@hibbs.com>, Curt Hibbs <cu...@hibbs.com> writes
>
>> I like the way that Ruby extensions appear (to a Ruby program) to be a
>> *real* Ruby object/class, no different than if I had coded it in Ruby.
>>
>> I'm interested to know if the same thing true of Python extensions?
>
>
> For the work I was doing, Python had the same qualities you describe. It
> was amazing how similar the process was. But what I was doing wasn't a
> huge extension, just some wrappers to calls written in C++.
>
> If I get to do something more complex for both languages I'll provide
> more feedback.
well, but IIRC python's extensions have this bad thing that you have to
handle the refcounting by yourself instead of relying on a real gc, am I
wrong?
Stephen Kellett
<surren...@remove-yahoo.it> writes
>> For the work I was doing, Python had the same qualities you
>>describe. It was amazing how similar the process was. But what I was
>>doing wasn't a huge extension, just some wrappers to calls written in >>C++.
>> If I get to do something more complex for both languages I'll
>>provide more feedback.
>
>well, but IIRC python's extensions have this bad thing that you have to
>handle the refcounting by yourself instead of relying on a real gc, am
>I wrong?
I think you may be right, but for the work I was doing, the process was
very similar for both languages. Thats why I made the comment about
doing something more complex. Not all extensions involve creating
objects.
Rick Nooner
>
> I think you may be right, but for the work I was doing, the process was
> very similar for both languages. Thats why I made the comment about
> doing something more complex. Not all extensions involve creating
> objects.
>
I have written complex extensions for both Ruby and Python in both C and
C++. C is pretty straightforward to wrap for both languages. They are
similar enough that the process can be somewhat automated (SWIG).
Complex C++ is another matter entirely. Generally a translation layer
needs to be written to handle at least the C++/Ruby exception translation
or you'll end up with severe memory leaks or core dumps. The process
is non-trivial for both Ruby and Python but it can be done. SWIG can
help here but there is still alot of manual work that has to be done.
Rick
--
Rick Nooner
ri...@nooner.net
http://www.nooner.net
Gyoung-Yoon Noh
much boring work. Actually, PyTypeObject is just a huge struct which owns
about 30 fields. It would explains why Python has no base class diagram.
Most Python classes just inherit root 'object'. In a deeper sense, Python's
type system would be much closer to 'Duck Typing' than Ruby, I think.
Anyway, it would be a pain in the ass to make a python class in C without
tools such as SWIG, pyrex and BoostPython.
I like Ruby way. Creating C extensions in Ruby seems much like OOP in C,
and so much like programming Ruby itself.
John W. Long
>
> . . .
>
> I just wrote a long message to a friend about this issue. I quote
> here what I can:
>
>
>>Why would I want to switch from PERL to Ruby?
>
>
> Short Answer:
> Because Ruby is better and Perl is harmful. Or better
> yet, because Perl cannot match what Ruby has to offer.
> But, this needs more explanation.
>
> Long Answer:
>
> No amount of physical evidence (or particular
> attribute of the language) is going to make or break the
> decision. You make the decision by your gut and then find
> evidence to support that decision. The only trick is to
> get others to make that same 'gut' decision. :)
>
>
Jim, this is a wonderful case for Ruby. Could you write it up somewhere
as an article? It would be helpful for others in the same situation as Joe.
--
John Long
http://wiseheartdesign.com