Getting Ruby approved

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

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

Joao Pedrosa ha scritto:

Hi,




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]

Hi,

Joao Pedrosa ha scritto:

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

 

[Mark Roseman]

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.

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]

Hi,

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.

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

Hi,

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]

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?

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]

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]

Joao Pedrosa ha scritto:


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]

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.

 

[Phil Tomson]

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