Getting Ruby approved
Joe Van Dyk
I'm trying to get Ruby added to one of the "supported" OSS tools at Boeing.
I was asked this question: "The question is, is Ruby bringing
something extra to the table, that we can't do with Perl, Python, Tcl,
Guile? E.g., are there OSS packages that we want to use which need
Ruby?"
I mentioned Rails and DRb as being the most useful applications of
Ruby to me. But can someone help me out with more?
Thanks,
Joe Van Dyk
Hal Fulton
On the one hand, all Turing-complete languages are equivalent.
In a more practical vein, sometimes there are libraries/packages
with which you need to interface, making some language a more
natural choice than others.
Neither of these points sells Ruby. What sells Ruby is the
productivity that programmers have when they use it.
This is only my opinion: I don't consider Perl as being on a level
with Ruby in this respect, and Tcl is not even close. Python, I
think, is very similar to Ruby in terms of productivity. I am not
familiar with Guile.
In case it helps any, you can refer to my article on devsource.com --
it was written partly to sell the idea that Ruby is now mainstream.
Hal
Pat Maddox
shows that you can increase productivity by three-fold, you'll have no
trouble selling it to them.
Bill Guindon
To save you the search:
http://www.devsource.com/article2/0,1759,1778695,00.asp
I'll 2nd Hal's comment, it's the ease of use, and more importantly
"readability" that sold me. Having done quite a bit of perl in the
past, I love Ruby's clean look and the fact that I can read code that
I haven't looked at for a month or more (especially since I only use
it occassionally).
--
Bill Guindon (aka aGorilla)
Robert Klemme
"Joe Van Dyk" <joev...@gmail.com> schrieb im Newsbeitrag
news:c715e6405033...@mail.gmail.com...
Not exactly a package... But reuse is more likely with Ruby than with
Perl simply because in a year from now you'll be still able to read and
understand the code you write today quickly.
Kind regards
robert
Joao Pedrosa
Ruby has closures, better low level support (Ruby/C), better OO
support, better core developers and better community, along with the
better libraries and overall language. :-) Tell them that they can
dump all the other languages and use only Ruby. :-)
Cheers,
Joao
Adriano Ferreira
> Ruby has closures, better low level support (Ruby/C), better OO
> support, better core developers and better community, along with the
> better libraries and overall language. :-) Tell them that they can
> dump all the other languages and use only Ruby. :-)
And you have forgotten about bf or even better Intercal. They are
funnier, more useless, but lays less claims than you did above.
Regards,
Adriano.
P.S. "Thou shall not be arrogant", unless thou want people very far from you.
Adriano Ferreira
> support, better core developers and better community, along with the
> better libraries and overall language. :-) Tell them that they can
> dump all the other languages and use only Ruby. :-)
Sorry for being ironic at first. But it would be better to rephrase
as: "Tell them to give Ruby a try and soon they can dump all the other
languages."
Adriano.
tony summerfelt
>Neither of these points sells Ruby. What sells Ruby is the
>productivity that programmers have when they use it.
>This is only my opinion: I don't consider Perl as being on a level
>with Ruby in this respect, and Tcl is not even close.
interesting. i see a lot of messages here along the lines of 'which
gui kit should i use with ruby'...and then everyone pipes up with
their favorite...
of course by then in tcl/tk land, we've already finished coding up our
interfaces :)
i had a client tender for a very specific one-time utility. they asked
in house c++ and java programmers, and externally my name came up
because of the local perl work i've done...
when i read the specs for the program they wanted i told them they
could have it in an hour if they didn't care about which language it
was (they were expecting perl from me at that point).
i used tcl/tk...the interface, which needed a certain arraignment of
widgets, took maybe 5 minutes to code up (a RAD tool at this point
would have slowed me down). the rest of the code was trivial.
so the language that was 'not even close' brought me over $1000 in
less than an hour. tcl/tk really is a sleeper language. i'm amazed
that it's not more popular than it is outside of comp.lang.tcl
i'm still deciding on a permanent gui api for ruby :)
http://home.cogeco.ca/~tsummerfelt1
telnet://ventedspleen.dyndns.org
Lyle Johnson
Though it's not a direct answer to your question, I tend to agree with
some of the other replies that if you try to "sell" Ruby to your
co-workers (or the higher-ups) by comparing it to other languages'
features and applications, you're fighting a losing battle. I for one
would love to be there when you try to explain to your boss that
Boeing should adopt Ruby because it has closures. ;)
Having said that, if you haven't seen it already, you might want to
take a look at Andy Hunt's presentation on "Ruby Insurgency"
(presented at the first Ruby Conference back in 2001):
http://www.pragmaticprogrammer.com/talks/Ruby/RubyInsurgency.pps.zip
This is sort-of the approach that I'm using here at work (where most
of our development work is done in Java), in an attempt to introduce
people to Ruby. I use Ruby for a lot of little maintenance tasks
involved in building our code, and when someone asks "How did you do
that?" or, "Can I get a copy of that program?", it gives me an
opportunity to tell them a little bit about Ruby.
Hope this helps,
Lyle
Phlip
> Though it's not a direct answer to your question, I tend to agree with
> some of the other replies that if you try to "sell" Ruby to your
> co-workers (or the higher-ups) by comparing it to other languages'
> features and applications, you're fighting a losing battle. I for one
> would love to be there when you try to explain to your boss that
> Boeing should adopt Ruby because it has closures. ;)
Boss; "So does Perl!"
--
Phlip
http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
Booker C. Bense
In article <c715e6405033...@mail.gmail.com>,
Joe Van Dyk <joev...@gmail.com> wrote:
_ For me the biggest productivity gain between ruby and perl is
when you need to write modules to interface with existing
libraries. This is about a 1000 times simpler in Ruby than perl.
_ Booker C. Bense
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBQk1syWTWTAjn5N/lAQFnLgQAlVxcU1dpCxmZutprfjJHiyEihYicaqYd
3BED8cPmw1Dxv5Kn34CYpHDkjueqp6YeLnNd6Pt+0TcHa7JAY//osqrWwnV/SioE
tGDTJWfGLSyJ5hmAHym8/Dxy819xJ96VrwvdKqEovThvq9e0Pd+Ay0l95Z2J406q
4UIHSnUzDkU=
=vuCT
-----END PGP SIGNATURE-----
Lyle Johnson
<bbense+comp.lan...@telemark.slac.stanford.edu> wrote:
> _ For me the biggest productivity gain between ruby and perl is
> when you need to write modules to interface with existing
> libraries. This is about a 1000 times simpler in Ruby than perl.
Combine this with the 10x productivity gain you'd get by throwing
Rails into the mix, and that boosts one person's productivity up to a
staggering 10,000x. With that kind of horsepower you'd only have to
work, what, one day every 27 years or so?
Jim Freeze
> I'm trying to get Ruby added to one of the "supported" OSS tools at Boeing.
>
> I was asked this question: "The question is, is Ruby bringing
> something extra to the table, that we can't do with Perl, Python, Tcl,
> Guile? E.g., are there OSS packages that we want to use which need
> Ruby?"
Having introduced Ruby at a company and having been successful in
having it replace Perl, I can tell you that the process may take
some time. Most of the comments in this thread have been right on.
As mentioned earlier, Andy's Insurgency talk gives good advice about
how to procede as an individual, but eventually, you need 'mind share'.
The 'mind share' can come in several ways.
1) From a boss who mandates Ruby.
2) From a group of respected developers who prefer to use Ruby.
3) From a kick-but application (or two) that is written in Ruby
(accompanied with a pleased manager).
4) From a good app that is written in near zero time
(also accompanied with a pleased manager).
#1 can be affective for moving a political agenda forward, but it
doesn't do anything for internal committment from developers.
#2 takes time, but is where you eventually want to go. #3 and #4
can be done by yourself.
It was interesting to see, in the beginning, that I got some of
the same questions, "How does Ruby differ from Perl", or
"What does Ruby offer that Perl doesn't?". Now, the questions
are reversed. For the occasional person that doesn't use Ruby,
he is bombarded with "Why didn't you use Ruby for that project?"
My main approach to management was on concepts. These concepts,
interestingly, have not changed over time:
1. Scalable
2. Readable/Maintainable
3. Reusable
I would suggest some seminars where you demonstrate/teach Ruby,
and include a segment on these items as motivators for Ruby.
And I often tell people, yes, there are thousands of languages
out there that one could use, and I would suggest that one always
use the best language for the job. It just so happens, that for
the kind of work that we do, Ruby is the best language. This will
bear itself out over the course of time. In addition, Ruby plays
very nicely in a corporate environment.
Of course, it doesn't hurt to have a sense of humor. When I went
before the VP to present an abstract on a Ruby course I developed,
I got the question, "What is Ruby?". I knew that a technical description
would be lost. So I had to use something he was familar with.
So, my reply was, "It is a fully object-oriented scripting language.
Some describe it as Perl's prettier, younger sister." That got a good
chuckle. And, it didnt' hurt that the abstract had almost every
conceivable topic for what we use scripting languages for.
It was readily approved, and after several people had taken the
course and began using the language, many of the old Perl die hards
came to me in private and declared that they were never going to
program in Perl again. You can't buy or mandate that kind of allegiance.
--
Jim Freeze
Code Red. Code Ruby
Joe Van Dyk
<bbense+comp.lan...@telemark.slac.stanford.edu> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
>
> In article <c715e6405033...@mail.gmail.com>,
> Joe Van Dyk <joev...@gmail.com> wrote:
> >Hi,
> >
> >I'm trying to get Ruby added to one of the "supported" OSS tools at Boeing.
> >
> >I was asked this question: "The question is, is Ruby bringing
> >something extra to the table, that we can't do with Perl, Python, Tcl,
> >Guile? E.g., are there OSS packages that we want to use which need
> >Ruby?"
> >
> >I mentioned Rails and DRb as being the most useful applications of
> >Ruby to me. But can someone help me out with more?
> >
>
> _ For me the biggest productivity gain between ruby and perl is
> when you need to write modules to interface with existing
> libraries. This is about a 1000 times simpler in Ruby than perl.
>
I've not written C modules in Perl or Python. How does Ruby compare
to them in that respect?
Phil Tomson
tony summerfelt <snow...@hotmail.com> wrote:
>On Fri, 1 Apr 2005 11:56:17 +0900, you wrote:
>
>
>>Neither of these points sells Ruby. What sells Ruby is the
>>productivity that programmers have when they use it.
>
>>This is only my opinion: I don't consider Perl as being on a level
>>with Ruby in this respect, and Tcl is not even close.
>
>interesting. i see a lot of messages here along the lines of 'which
>gui kit should i use with ruby'...and then everyone pipes up with
>their favorite...
>
>of course by then in tcl/tk land, we've already finished coding up our
>interfaces :)
>
>i had a client tender for a very specific one-time utility. they asked
>in house c++ and java programmers, and externally my name came up
>because of the local perl work i've done...
>
>when i read the specs for the program they wanted i told them they
>could have it in an hour if they didn't care about which language it
>was (they were expecting perl from me at that point).
>
>i used tcl/tk...the interface, which needed a certain arraignment of
>widgets, took maybe 5 minutes to code up (a RAD tool at this point
>would have slowed me down). the rest of the code was trivial.
>
>so the language that was 'not even close' brought me over $1000 in
>less than an hour. tcl/tk really is a sleeper language.
It's been sleeping for quite a while, don't wake it up ;-)
Atually, I know that EDA companies use Tcl/Tk for many of their GUI
needs. We're talking about software that sells for up to $200,000/seat
in some cases. It's still pretty widely used in EDA because Ousterhout
initially developed it for use with chip layout software.
>i'm amazed
>that it's not more popular than it is outside of comp.lang.tcl
But would you really want to do soemthing substantial in Tcl?
Phil
leon breedt
> I've not written C modules in Perl or Python. How does Ruby compare
> to them in that respect?
You're never quite sure when you should or should not reference
something in Perl, for example. They've invented concepts for the
hacks you have to do to work around the crap architecture of the
system. Its far too low-level. Extension documentation is all over the
place, in disparate man pages, and requires reading of *all* of them
and understanding *all* of them to get something to build and run
reliably. Ruby is infinitely better than Perl in this regard.
I haven't much experience with Python extensions, although, Pyrex
looks like it makes Python extensions quite painless.
Leon
gga
Against the basic C apis of the languages...
Compared to Perl: no point of comparison. Perl uses a pseudo C
language wrapper called XS that is plain and simply a nightmare to
learn, code for and maintain.
Compared to Python: very similar to ruby, but I prefer ruby. The ruby
api is much simpler as there is no need for reference counting (albeit
marking your own classes for the GC is also kind of a big pain in
ruby). The ruby macros used are also a tad shorter and probably a tad
easier to learn and memorize than all the Py* methods. Python,
however, is infinitely better if you ever need to wrap a library that
uses multiple inheritance, as the lack of MI in ruby may prove to be
too much of a headache in that case.
Against SWIG...
Perl is the most mature SWIG api, albeit SWIG's python support has more
or less now become the predominant implementation. SWIG's ruby is
still rather new and still has a couple of gotchas here and there
(mainly with C++ and overloaded functions, for example). That being
said, the fact that SWIG's ruby can throw away all the shadow classes
that are needed to have stuff be swigged in those other languages makes
it a) much nicer, and b) potentially faster in the future than other
SWIGs.
Ruby SWIG is also trying hard to support multiple inheritance thru
modules, albeit the feature is still in development.
Against Boost Python:
Ruby has nothing equivalent. I consider this a good thing. Boost
Python is a good idea, but it just pushes the limit of what C++
compilers can handle with templates and this, imo, currently leads to
both inefficient and hard to maintain/debug code.
Against Pyrex:
Ruby has nothing equivalent. Pyrex is somewhat akin to a slightly more
high-level version of ruby's DL module, but nowhere near as good as
SWIG. Still not clear to me why would you use it at all, other than
you prefer the cleaner python syntax wrapping to writing pseudo C files
as you do with swig.
Phlip
> Perl's XS is arcane, inconsistent and easy to cause segfaults in.
> You're never quite sure when you should or should not reference
> something in Perl, for example. They've invented concepts for the
> hacks you have to do to work around the crap architecture of the
> system. Its far too low-level. Extension documentation is all over the
> place, in disparate man pages, and requires reading of *all* of them
> and understanding *all* of them to get something to build and run
> reliably. Ruby is infinitely better than Perl in this regard.
>
> I haven't much experience with Python extensions, although, Pyrex
> looks like it makes Python extensions quite painless.
I have extended Python. It's about mid-way between Perl and Ruby. The
extension libs, such as Boost's C++ Python wrapper, make it relatively
painless.
Ruby just _starts_ in the painless zone, despite using pure C.
Click here:
http://www.c2.com/cgi/wiki?BroadbandFeedback
That shows a Wiki written in Ruby hosting test cases written in XML
containing Ruby sample code. The tester pushes the code into a C++ Qt
application built to respond to a suite of Ruby commands to draw fractals.
(Without the tests, you can write the Ruby directly into the Qt interface.)
The tester takes screenshots of Qt's OpenGL widget rendering the fractals,
and the Wiki renders these.
All of that works with tiny snips of _exemplary_ Ruby and C bonding, without
any excessive adapter layer.
--
Phlip
http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
Mark Roseman
> >>Neither of these points sells Ruby. What sells Ruby is the
> >>productivity that programmers have when they use it.
> >
> >>This is only my opinion: I don't consider Perl as being on a level
> >>with Ruby in this respect, and Tcl is not even close.
> >that it's not more popular than it is outside of comp.lang.tcl
>
> But would you really want to do soemthing substantial in Tcl?
Phil,
I can tell you that for a lot of people the answer has been and
continues to be "yes", they would want to do something substantial
in Tcl. And yes, they have been quite successful at it.
Effective evangelism of Ruby would be better served if it was not
about implying that people who choose other tools are crazy or
misguided (or just missing out) but about trumpeting the great
things that Ruby has going for it, while at the same time
acknowledging it's still got its rough spots.
FYI, there are a lot of things in language like Tcl (and others)
that Ruby could learn from and benefit from; because its been
around substantially longer, its reached a level of maturity in
many areas that provides real benefits to developers. That's not
to slag Ruby, but just to suggest its not perfect (yet). But
knowing where other tools might be better today can only help Ruby
tomorrow, and that is something that would be good for everyone.
Mark
(http://www.markroseman.com)
p.s. incidentally, I see many parallels in this community in
terms of energy, enthusiasm, attitudes, etc. with what the
Tcl/Tk community was like 10-15 years ago, when it was first
emerging. Ditto Python several years back...
Douglas Livingstone
>
> p.s. incidentally, I see many parallels in this community in
> terms of energy, enthusiasm, attitudes, etc. with what the
> Tcl/Tk community was like 10-15 years ago, when it was first
> emerging. Ditto Python several years back...
>
Hay, hopefully each iteration gets better!
Joao Pedrosa
> I can tell you that for a lot of people the answer has been and
> continues to be "yes", they would want to do something substantial
> in Tcl. And yes, they have been quite successful at it.
I'm curious about what you consider strong points for Tcl in
comparison with Ruby. See, we are open to ideas and other languages.
Many of us have been using many languages since a long time ago. :-)
The main "drawback" that I see in Ruby in comparison to other
languages is that Ruby is OO and this leads to some indirections when
reading someone else's code. Other desktop programming languages may
use less indirections (OO), which is good as it may simplify the first
impact of understanding a code listing. Visual development tools may
use an OO programming language, though I think it's too hard to
develop such tools for free. :-)
Cheers,
Joao
Dido Sevilla
> On the one hand, all Turing-complete languages are equivalent.
>
To a computer, yes. To a computer programmer no. Languages like
unlambda and BF exist partly to prove this point.
> In a more practical vein, sometimes there are libraries/packages
> with which you need to interface, making some language a more
> natural choice than others.
>
A few years ago this was what made me (reluctantly) write a bit of
code in Java rather than in Ruby. Three years ago there did not exist
a Ruby library for Jabber as full-featured as the one for Java.
Looking back I think perhaps it might have been a better strategy to
have written that library for Ruby myself, now that the Java code has
evolved into something of an unmaintainable morass...
> Neither of these points sells Ruby. What sells Ruby is the
> productivity that programmers have when they use it.
>
Amen. To add fuel to the flames, I've recently been asked by a client
to justify the use of Ruby for our project development, and I've
written some of the arguments that I mentioned to them (and a few
more) in my blog here:
http://stormwyrm.blogspot.com/2004/12/why-ruby.html
Well, they were convinced, and we're gonna slowly convince them to
move from Perl little by little... ;)
gabriele renzi
> Hi,
>
>
>>I can tell you that for a lot of people the answer has been and
>>continues to be "yes", they would want to do something substantial
>>in Tcl. And yes, they have been quite successful at it.
>
>
> I'm curious about what you consider strong points for Tcl in
> comparison with Ruby. See, we are open to ideas and other languages.
I may be wrong, but as a "wannabe Tcler" I can think of some things in
tclland:
- the builtin in event loop
- the tcl vfs
- starkit/starpack/tclkit
- they seem to have a great care on version compatibility/interoperability
- the ability to trace variable seem very interesting :)
Joao Pedrosa
On Apr 2, 2005 10:09 AM, gabriele renzi <surren...@remove-yahoo.it> wrote:
> Joao Pedrosa ha scritto:
> > Hi,
> >
> >
> >>I can tell you that for a lot of people the answer has been and
> >>continues to be "yes", they would want to do something substantial
> >>in Tcl. And yes, they have been quite successful at it.
> >
> >
> > I'm curious about what you consider strong points for Tcl in
> > comparison with Ruby. See, we are open to ideas and other languages.
>
> I may be wrong, but as a "wannabe Tcler" I can think of some things in
> tclland:
> - the builtin in event loop
Is this, it?
http://tcl.activestate.com/man/tcl8.4/TclCmd/after.htm
Ruby-GTK+ has the Gtk.timeout_add method which is handy. And a use of
threading and sleep may help in other cases.
> - the tcl vfs
This one looks simple and powerful when it's enough, according to this
description:
http://www.ruby-talk.org/cgi-bin/scat.rb/ruby/ruby-talk/61086
> - starkit/starpack/tclkit
Is this, it?
http://www.equi4.com/starkit.html
It's good as a general purpose deployment tool. This demands a
combination of tools in Ruby.
> - they seem to have a great care on version compatibility/interoperability
That's nice. :-)
> - the ability to trace variable seem very interesting :)
This one is interesting, also:
http://www.wellho.net/forum/The-Tcl-programming-language/Tracing-a-variable-in-Tcl.html
I believe that self-contained languages are useful, but their reach or
goals can't be compared to more general purpose languages like Ruby,
though other languages like Tcl are very nice in their niche. It's
like JavaScript: how to replace them in their niche?
People can use general purpose languages and obtain as much as a good
result as the self-contained ones, but it takes some extra work, which
may pay-off in the next project.
When general purpose languages evolve, it means that their easiness
and reach may increase with the time, while the self-contained
languages may have a harder time embracing other goals (like becoming
cross-platform, supporting OO, etc).
Cheers,
Joao
Phlip
> Against Boost Python:
> Ruby has nothing equivalent. I consider this a good thing. Boost
> Python is a good idea, but it just pushes the limit of what C++
> compilers can handle with templates and this, imo, currently leads to
> both inefficient and hard to maintain/debug code.
That's why Boost is the leader: Compilers must implement it because it obeys
the Standard that they must get around to.
A Boost Ruby would lend Ruby this credibility (in some eyes).
--
Phlip
http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
Mark Roseman
a single easy model for all I/O and UI stuff), virtual file systems,
mature end user deployment solutions like Starkits, code protection,
excellent performance tuning, etc. are a few examples of things that
evolve over time, and are more likely to be in the more mature languages
- hence the appeal. As I said, I hope some of these types of things
migrate to Ruby over time; I'm sure you can get most of the way there
now by cobbling pieces together, but the edges are quite rough.
You mentioned OO being a drawback of Ruby in another message, but I
don't think that's a drawback at all. (Yes, coming from someone who
does a lot of Tcl for small and large programs, both with and without
using some of the established OO extensions for Tcl).
> I believe that self-contained languages are useful, but their reach or
> goals can't be compared to more general purpose languages like Ruby,
> though other languages like Tcl are very nice in their niche. It's
> like JavaScript: how to replace them in their niche?
>
> People can use general purpose languages and obtain as much as a good
> result as the self-contained ones, but it takes some extra work, which
> may pay-off in the next project.
>
> When general purpose languages evolve, it means that their easiness
> and reach may increase with the time, while the self-contained
> languages may have a harder time embracing other goals (like becoming
> cross-platform, supporting OO, etc).
I'm probably just missing something, but what do you mean by the
distinction between "self-contained" languages vs. general purpose ones?
(If you have somewhere to point me to, that'd be fine too).
Also, what would you see as Tcl's niche? (I've always felt it's use was
fairly broad-based, with small pockets here and there, but a lack of
concentration... not necessarily a good thing).
I think Ruby has a great foundation, and I'd love to see it evolve
quickly to smooth out some of the rough edges that are a natural part of
every newer language.
Thanks
Mark
Joao Pedrosa
On Apr 2, 2005 12:19 PM, Mark Roseman <ma...@markroseman.com> wrote:
> Things like a rich event loop (much more than just after/timeouts, it's
> a single easy model for all I/O and UI stuff), virtual file systems,
> mature end user deployment solutions like Starkits, code protection,
> excellent performance tuning, etc. are a few examples of things that
> evolve over time, and are more likely to be in the more mature languages
> - hence the appeal. As I said, I hope some of these types of things
> migrate to Ruby over time; I'm sure you can get most of the way there
> now by cobbling pieces together, but the edges are quite rough.
If only people wanted to have what has been missing. :-) Desktop
technologies have less appeal nowadays than they used to have in the
past, for instance.
> You mentioned OO being a drawback of Ruby in another message, but I
> don't think that's a drawback at all. (Yes, coming from someone who
> does a lot of Tcl for small and large programs, both with and without
> using some of the established OO extensions for Tcl).
Once one becomes proficient in OO (and Ruby helps one to become
proficient in it, by lowering the barriers and the needs for more
complex solutions), it's not a drawback anymore, because one knows
that it doesn't need to be more complex than he needs.
> > When general purpose languages evolve, it means that their easiness
> > and reach may increase with the time, while the self-contained
> > languages may have a harder time embracing other goals (like becoming
> > cross-platform, supporting OO, etc).
>
> I'm probably just missing something, but what do you mean by the
> distinction between "self-contained" languages vs. general purpose ones?
> (If you have somewhere to point me to, that'd be fine too).
For example, a language that supports its own GUI toolkit is much more
"self-contained" than one that supports the native GUI and other GUI
libraries. A language that uses Apache, Lighttpd, etc, as web-servers
is much less "self-contained" than one that supports its own
"web-server". A language that supports databases like SQLite, MySQL,
etc is much less "self-contained" than one that supports its own
database (OODBMS, RDBMS, etc). By using what's available in a given
platform, a language becomes much less "self-contained". This is a
theory of mine, by the way. :-) I began using the "self-contained"
term two weeks ago.
> Also, what would you see as Tcl's niche? (I've always felt it's use was
> fairly broad-based, with small pockets here and there, but a lack of
> concentration... not necessarily a good thing).
The combination Tcl/Tk for desktop applications seems like the main
use of Tcl. It's not a bad use of it, is it? :-) I understand that Tcl
can be used for other tasks, too. One of the Tcl/Tk applications that
I used to use was Scid:
http://scid.sourceforge.net/
But then I created something similar in Ruby which was good enough for me:
http://ruby.com.br/~pedrosa/chess.png
> I think Ruby has a great foundation, and I'd love to see it evolve
> quickly to smooth out some of the rough edges that are a natural part of
> every newer language.
Ruby is newer than a lot of languages, but after 13 years, it has
become a very sweet tool. :-)
Cheers,
Joao
tony summerfelt
>But would you really want to do soemthing substantial in Tcl?
http://phaseit.net/claird/comp.lang.tcl/commercial-tcl.html
looks like some people thought about doing something substantial in
tcl...
so far i've had no complaints on the tcl/tk programs i've delivered.
for time expended coding vs payment i can't really complain...
http://home.cogeco.ca/~tsummerfelt1
telnet://ventedspleen.dyndns.org
tony summerfelt
>> I can tell you that for a lot of people the answer has been and
>> continues to be "yes", they would want to do something substantial
>> in Tcl. And yes, they have been quite successful at it.
>I'm curious about what you consider strong points for Tcl in
>comparison with Ruby.
gui. hands down. imho, it's quickest quickest way to code up a gui.
i've put tcl/tk frontends to my cmd line ruby programs because it was
quicker than doing it in ruby...
http://home.cogeco.ca/~tsummerfelt1
telnet://ventedspleen.dyndns.org
Joao Pedrosa
On Apr 2, 2005 3:20 PM, tony summerfelt <snow...@hotmail.com> wrote:
> On Sat, 2 Apr 2005 21:52:23 +0900, you wrote:
>
> >> I can tell you that for a lot of people the answer has been and
> >> continues to be "yes", they would want to do something substantial
> >> in Tcl. And yes, they have been quite successful at it.
>
> >I'm curious about what you consider strong points for Tcl in
> >comparison with Ruby.
>
> gui. hands down. imho, it's quickest quickest way to code up a gui.
>
> i've put tcl/tk frontends to my cmd line ruby programs because it was
> quicker than doing it in ruby...
I see. What do you consider the most difficult (GUI-wise) to do in
Ruby that is easy in Tcl/Tk? Maybe a little list with 3 items? :-)
Thanks,
Joao
Kristof Bastiaensen
> <snip> One of the Tcl/Tk applications that
> I used to use was Scid:
> http://scid.sourceforge.net/
>
> But then I created something similar in Ruby which was good enough for me:
> http://ruby.com.br/~pedrosa/chess.png
>
Interesting, do you have sources for that?
By the way, I implemented a gameboard api for chess in Ruby-Gtk
(http://gcboard.sourceforge.net/), that you might find interesting.
Regards,
KB
vruz
> something extra to the table, that we can't do with Perl, Python, Tcl,
> Guile? E.g., are there OSS packages that we want to use which need
> Ruby?"
> I mentioned Rails and DRb as being the most useful applications of
> Ruby to me. But can someone help me out with more?
Sneaking Ruby in to the office wasn't a big deal for me.
When they asked me to do something impossible whilst also meeting an
insane deadline, I told them that I would do it, but I would use my
own toolset.
I migrated poorly designed database schemas and all the data in them
from different sources (including old dbase tables), enforced
integrity in the target database and created a user interface for them
to query and review the new database.
Tools: Ruby, Debian Linux, Postgres
They were thinking from a VC++ or Java mindset, they just couldn't do
that in less than a week using those tools. (heck, not in less than 4
weeks)
Common sense and having a good toolset (instead of THE hammer) always helps.
I could have probably accomplished the same results using a Mac, but
at a much higher cost and less attractive ROI (the sort of thing
marketing types like to babble about).
I just used a spare PIII machine that was otherwise showing a 3d screensaver.
Doing what's otherwise impossible will always work.
cheers and good luck,
vruz
Phil Tomson
Mark Roseman <ma...@markroseman.com> wrote:
> pt...@aracnet.com (Phil Tomson) wrote:
>> >>Neither of these points sells Ruby. What sells Ruby is the
>> >>productivity that programmers have when they use it.
>> >
>> >>This is only my opinion: I don't consider Perl as being on a level
>> >>with Ruby in this respect, and Tcl is not even close.
>> >i'm amazed
>> >that it's not more popular than it is outside of comp.lang.tcl
>>
>> But would you really want to do soemthing substantial in Tcl?
>
>
>Phil,
>
>I can tell you that for a lot of people the answer has been and
>continues to be "yes", they would want to do something substantial
>in Tcl. And yes, they have been quite successful at it.
>
>Effective evangelism of Ruby would be better served if it was not
>about implying that people who choose other tools are crazy or
>misguided (or just missing out) but about trumpeting the great
>things that Ruby has going for it, while at the same time
>acknowledging it's still got its rough spots.
I wasn't implying that people who chose to do substantial projects in Tcl
were crazy. I've used Tcl on and off over the years and personally, I
would not want to do a substantial project in it. It's been about six
months ago now that I was doing any Tcl, but I recall at the time it was
rather frustrating. I recall (and I could be slightly off on the
details) that I was trying to figure out how to add
an item to the beginning of an array/list instead of at the end and as I
recall there was no built-in way of doing this (maybe the book I was
using was lacking, but I couldn't find a way to do it without writing
another function to do it). Maybe that's not a big gripe, but that sort
of thing slows down development.
People choose Tcl for various (often valid) reasons:
1) they already know it
2) they don't know about alternatives
3) their employer mandates it's use
4) the existing codebase is already in Tcl
Personally, I wouldn't want to use Tcl for a substantial new project.
YMMV
>
>FYI, there are a lot of things in language like Tcl (and others)
>that Ruby could learn from and benefit from; because its been
>around substantially longer, its reached a level of maturity in
>many areas that provides real benefits to developers.
I'm sure this is the case. (BTW: examples?)
> That's not
>to slag Ruby, but just to suggest its not perfect (yet). But
>knowing where other tools might be better today can only help Ruby
>tomorrow, and that is something that would be good for everyone.
>
Agreed.
Phil
Phil Tomson
gabriele renzi <surren...@remove-yahoo.it> wrote:
>Joao Pedrosa ha scritto:
>> Hi,
>>
>>
>>>I can tell you that for a lot of people the answer has been and
>>>continues to be "yes", they would want to do something substantial
>>>in Tcl. And yes, they have been quite successful at it.
>>
>>
>> I'm curious about what you consider strong points for Tcl in
>> comparison with Ruby. See, we are open to ideas and other languages.
>
>
>I may be wrong, but as a "wannabe Tcler" I can think of some things in
>tclland:
>- the builtin in event loop
Yes this is a good thing. It probably developed so early in Tcl because
of the close marriage between Tcl and Tk.
>- the tcl vfs
But aren't we moving in that direction now that open can take URLs?
>- starkit/starpack/tclkit
Interesting. Ruby has projects which are moving in that direction (the
various 2exe modules), but probably nothing quite as mature. Certainly
worth a look.
>- they seem to have a great care on version compatibility/interoperability
>- the ability to trace variable seem very interesting :)
Can you elaborate?
None of the items you mentioned are core language features per se (except
maybe the last one). They are more like add-ons. Some of them are
'cultural'. Certainly we can learn from something like starkit. But as
far as the language I'd rather develop in goes - I definately prefer
developing in Ruby as opposed to Tcl.
...but YMMV.
Phil
jm
On 03/04/2005, at 7:39 AM, vruz wrote:
>
> I could have probably accomplished the same results using a Mac, but
> at a much higher cost and less attractive ROI (the sort of thing
> marketing types like to babble about).
> I just used a spare PIII machine that was otherwise showing a 3d
> screensaver.
>
If your company's ROI is that sensitive to ROI it's time to leave :-).
Mind you there's no point in spending more money than you have to, nor
buying new hardware if you have it lying around.
J.
Jeremy Henty
> ... I've used Tcl on and off over the years and personally, I
> would not want to do a substantial project in it.
Having done a fair amount of Tcl programming both at home and at work,
I completely agree. There are two reasons why I would overwhelming
prefer to do such a thing in Ruby (or even in Perl 5):
1. Tcl doesn't have first class data structures. I can't create an
associative array, populate it, and pass the result to another bit of
code. I have to fake it with call-by-name and upvar. Yeuch!
2. Tcl doesn't have lexical scoping. If I pass a block of code
around I have to uplevel it to run it in the right context. Worse, I
have to uplevel it by exactly the number of stack frames between the
proc that supplies the block and the proc that executes it, which puts
a burden on refactoring. Double Yeuch! In Ruby this just works; it
doesn't get in the way.
That said, Tcl's embedding API design is superb. I really hope Rite
copies it. When I learned that the Ruby API forces a single global
interpreter instance I felt a bizarre and unfamiliar emotion:
disapointment with Ruby.
Cheers,
Jeremy Henty
Phlip
> Sneaking Ruby in to the office wasn't a big deal for me.
Before releasing MiniRubyWiki, I got a gig using it. [Un]fortunately, the
shop had a "more is better" policy - they already used Lua, Perl, C#, MFC,
etc. Their other thought leaders were using Python as the Smarter Perl.
> When they asked me to do something impossible whilst also meeting an
> insane deadline, I told them that I would do it, but I would use my
> own toolset.
> I migrated poorly designed database schemas and all the data in them
> from different sources (including old dbase tables), enforced
> integrity in the target database and created a user interface for them
> to query and review the new database.
>
> Tools: Ruby, Debian Linux, Postgres
>
> They were thinking from a VC++ or Java mindset, they just couldn't do
> that in less than a week using those tools. (heck, not in less than 4
> weeks)
Same experience. They gave me a legacy Perl test-runner, and I installed MRW
as its GUI almost instantly:
http://flea.sourceforge.net/gameTestServer.pdf
Then, whenever I worked in Ruby my velocity was super-high, and working in
the Perl test-runner was super slow.
The Perl was written by a total newb. But even after I refactored the snot
out of it, and got it under test, it was still the boat anchor in my daily
workflow. I could have rewritten it in Ruby in a few days, but they were
days I could not ask for.
--
Phlip
http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
Phil Tomson
Jeremy Henty <jer...@chaos.org.uk> wrote:
>In article <d2n6e...@enews2.newsguy.com>, Phil Tomson wrote:
>
>> ... I've used Tcl on and off over the years and personally, I
>> would not want to do a substantial project in it.
>
>Having done a fair amount of Tcl programming both at home and at work,
>I completely agree. There are two reasons why I would overwhelming
>prefer to do such a thing in Ruby (or even in Perl 5):
>
>1. Tcl doesn't have first class data structures. I can't create an
>associative array, populate it, and pass the result to another bit of
>code. I have to fake it with call-by-name and upvar. Yeuch!
>
>2. Tcl doesn't have lexical scoping. If I pass a block of code
>around I have to uplevel it to run it in the right context. Worse, I
>have to uplevel it by exactly the number of stack frames between the
>proc that supplies the block and the proc that executes it, which puts
>a burden on refactoring. Double Yeuch! In Ruby this just works; it
>doesn't get in the way.
OMG! I forgot about that upvar and uplevel stuff - I guess I blocked it
out of my memory. Triple Yuck!
>
>That said, Tcl's embedding API design is superb. I really hope Rite
>copies it.
Or at least learns a great deal from it.
Phil
tony summerfelt
>I see. What do you consider the most difficult (GUI-wise) to do in
>Ruby that is easy in Tcl/Tk? Maybe a little list with 3 items? :-)
i guess if you know the api in question nothing is 'difficult' in
ruby.
with tcl/tk it how little typing i have to do. the tkblog interface is
about 20 mostly short lines of code. which took me about two minutes
to type up.
with the example i posted before:
button .b -text "quit" -command{exit}
pack .b
it puts up a window, with one button. click on the button it exits.
what's the equivalent of that in the various ruby gui api's?
http://home.cogeco.ca/~tsummerfelt1
telnet://ventedspleen.dyndns.org
Joao Pedrosa
In my own library I use something like:
require 'gr/gtk_rules'
GR.app{|w| w.hpack GR::GRButton.new('quit').sc{ GR.quit } }
I think this could be reduced even further to
require 'gr/gr'
app{|w| w << button('quit'){ quit } }
Or something like that, but I'm not going to do it yet. I have a new
project starting tomorrow and after that I have so much to work on
still -- like developing one thing or two for the Wee Web-Framework...
Anyway, I think people would be better off by using their own custom
Ruby library for GUI programming. :-)
Cheers,
Joao
Douglas Livingstone
>
> Anyway, I think people would be better off by using their own custom
> Ruby library for GUI programming. :-)
I would love to make GUI in Ruby as easy as Rails :)
Richard Cole
>>>I see. What do you consider the most difficult (GUI-wise) to do in
>>>Ruby that is easy in Tcl/Tk? Maybe a little list with 3 items? :-)
>>>
>>>
>>i guess if you know the api in question nothing is 'difficult' in
>>ruby.
>>
>>with tcl/tk it how little typing i have to do. the tkblog interface is
>>about 20 mostly short lines of code. which took me about two minutes
>>to type up.
>>
>>with the example i posted before:
>>
>>button .b -text "quit" -command{exit}
>>pack .b
>>
>>it puts up a window, with one button. click on the button it exits.
>>what's the equivalent of that in the various ruby gui api's?
>>
>>
>
>In my own library I use something like:
>
>require 'gr/gtk_rules'
>GR.app{|w| w.hpack GR::GRButton.new('quit').sc{ GR.quit } }
>
>I think this could be reduced even further to
>
>require 'gr/gr'
>app{|w| w << button('quit'){ quit } }
>
>Or something like that, but I'm not going to do it yet. I have a new
>project starting tomorrow and after that I have so much to work on
>still -- like developing one thing or two for the Wee Web-Framework...
>Anyway, I think people would be better off by using their own custom
>Ruby library for GUI programming. :-)
>
>
I don't quite understand that last point. Do you mean that everyone
would be better off writing their own GUI library because currently the
current public offerings are unlikely to match application requirements?
I've found Ruby Qt pretty good, although it often produces a segfault if
you have bugs, and I hadn't seen the GR/Gtk example before :)
That's a nice couple of examples. Both examples show the use of
blocks/lambda expressions/closures (whatever those funky things are are
in Tcl) for GUI programming. Once you've seen blocks you can't live
without them. They make writing GUI's using Java and SWT painfull by
reflection on how much easier it could be if you didn't have to make
anonymous innner classes just to create a block.
I sometimes end up coding in TclTk because that's the library that I
know better and there's a great book by Matt Welch that explains the API
in details.
What are the best books for Ruby GUI programming?
Many programming environments, e.g. TclTk and Ocaml create man pages
to document the core library. Has anyone done this Ruby?
But I must admit that I prefer Ruby to Tcl because Ruby has more
powerful abstractions (the whole smalltalk thing it has going) while Tcl
is largely a really cool trick involving string manipulation. I regard
them as both pretty clean languages (Ruby's going to get better with
Ruby 2.0 isn't it), but they are also both pretty expensive in terms of
execution time. Ruby is so nice that I'd like to code matrix stuff in
it, but its just way too slow, so you have to use a C-wrapper for matrix
manipulation :(
regards,
Richard.
Richard Dale
> I've found Ruby Qt pretty good, although it often produces a segfault if
> you have bugs,
Do you mean QtRuby, and which version have you tried? I fixed quite a few
bugs relating to programming errors giving seg faults some months ago.
-- Richard
gabriele renzi
>>- the tcl vfs
>
>
> But aren't we moving in that direction now that open can take URLs?
sure, but, say, how do we add support for new stuff?
I'd like to avoid overriding Kernel::open every time?
Possibly just using URI#open, but then, how do I expand it?
And what about Dir ? (not great problems, but the more the merrier :)
>>- they seem to have a great care on version compatibility/interoperability
>>- the ability to trace variable seem very interesting :)
>
>
> Can you elaborate?
well, some times ago I stumbled upon
http://wiki.tcl.tk/285
and I also noticed that tcl has something built-in akin to rubygems:
http://www.astro.princeton.edu/~rhl/Tcl-Tk_docs/tcl8.0a1/package.n.html
> None of the items you mentioned are core language features per se (except
> maybe the last one). They are more like add-ons. Some of them are
> 'cultural'. Certainly we can learn from something like starkit. But as
> far as the language I'd rather develop in goes - I definately prefer
> developing in Ruby as opposed to Tcl.
>
> ...but YMMV.
oh, no, I definitely agree with you on the whole line :)
Booker C. Bense
In article <ca24287805040...@mail.gmail.com>,
Joao Pedrosa <joaop...@gmail.com> wrote:
>
>
>The combination Tcl/Tk for desktop applications seems like the main
>use of Tcl. It's not a bad use of it, is it? :-) I understand that Tcl
>can be used for other tasks, too.
_ I'd say that's the least of TCL's usage. It's great strength
is actually embedded in the name
Tool Command Language
_ It's a kind of simple minded lisp[1] that non-CS types can easily
grok to provide a power scripting language for specialized
applications. This kind of thing is impracticable in perl and
becoming more common in Python. It's at least possible in
Ruby, but not as easy as it might be.
_ IMHO, it works best as a scripting framework for larger
applications, and works least as a general purpose scripting
language. In particular, the only implementation of general
purpose remote scripting I've seen done "right" from a security
point of view was done in tcl.
_ Booker C. Bense
[1]- instead of everything being a list, everything is a string.
This is both TCL's strength and weakness.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBQlG6UmTWTAjn5N/lAQGSUQP+NHAYl41qTM9N3N/gQn78BRymR9W8Ph2O
pNk/zbUzW54KNkjnyMeSNJZKHj0dSuH7e10//RrUsZ4GyjzjQsm61dKRXL7ImMLb
Oir4TKdSnZgWZHWYd8jOwM8/u8E6bZVu88YWmaBioFgskGXUyRZhsAV9h8Gzsiy6
dIiJwPs7a40=
=N6eP
-----END PGP SIGNATURE-----
tony summerfelt
>[1]- instead of everything being a list, everything is a string.
>This is both TCL's strength and weakness.
cameron laird can correct me if i'm wrong but i think the 'everything
is a string' description hasn't applied to tcl for awhile now...(v8.0+
?)
http://home.cogeco.ca/~tsummerfelt1
telnet://ventedspleen.dyndns.org
Booker C. Bense
_ That's true and I really haven't bothered to keep current with
tcl. Mea Culpa...
_ Booker C. Bense