Bruce Eckel's opinion of Ruby
Rich Kilmer
Robert Feldt
> Ouch!
>
> http://www.mindview.net/Etc/FAQ.html#Ruby
>
> Thoughts?
>
You can check the thread starting with [ruby-talk:20135].
One (among many) notable post in this thread was matz in
[ruby-talk:20156]:
>Hi,
>
>In message "[ruby-talk:20135] Bruce Eckel's criticism of Ruby"
> on 01/08/23, Ned Konz <n...@bike-nomad.com> writes:
>
>|"Bruce Eckel thinks Ruby isn't worth learning...".
>
>Many people think Riding motorcycle isn't worth learning. They feel
>motorcycle are bad ripoff of cars (because of fewer tires). But others
>don't agree.
>
>Anyway, for me, it's pretty interesting to see Python people's
>reaction to Ruby. I'm glad Ruby has come to the state where Python
>people show reaction both positively and negatively.
>
> matz.
>
/R
Dave Thomas
> http://www.mindview.net/Etc/FAQ.html#Ruby
>
> Thoughts?
This was discussed a while back, if I remember correctly.
Personally, I'm happy Bruce took the time to look at the book, and
then to write something about Ruby. I'm surprised that he didn't
actually _try_ Ruby before writing, as some of Ruby's benefits are
subtle, and really only come out after you're got some code under your
belt. However, that's his choice.
His criteria seems to be that a language should make you twice as
productive before you switch. I'm not sure how I'd measure that, but
I'd guess that although Ruby is more productive than Python in some
areas (and less in others), you might not be looking at short-term
doubling of productivity.
However, my personal criteria are different. Yes, I want to be
productive. But I also want to enjoy what I'm doing. That happens for
me when the distance between what I'm thinking and what I'm typing is
small. For me (let me say that again: for me) the gap is smaller in
Ruby than in any other language I've tried (and like Bruce I've tried
a few... :) I'm glad Bruce is happy with Python: every developer needs
to find a language that makes them happy. I'll be sticking with Ruby.
Dave
Eric Lee Green
> My preliminary conclusion is that Python is a superior language for large
> projects....
> Ruby, on the other hand, is a much better scripting language...
Forgot one more thing: Strings and regular expressions. This is one area
where Ruby definitely does it in a more concise/easier to use fashion than
Python.
Eric Lee Green GnuPG public key at http://badtux.org/eric/eric.gpg
mailto:er...@badtux.org Web: http://www.badtux.org
You do not save freedom by destroying freedom
Eric Lee Green
> Ouch!
>
> http://www.mindview.net/Etc/FAQ.html#Ruby
>
> Thoughts?
Disclaimer: I have written approximately 100,000 lines of Python in the past
2 years, and approximately 10,000 lines of Ruby in the past 2 months. Thus I
am approximately 10 times more expert in Python than in Ruby. I don't,
however, have any particular axe to grind regarding languages, heck, I even
write my web pages in PHP (one of the most bletcherous excuses for a
programming language to come down the pike -- but excellent for quicky
one-off weblets).
Thoughts:
1. Python's namespace conventions (i.e., no "global" global variables, only
module-global variables) make it easier to partition a large project amongst
various programmers, especially projects that require configuration variables
of some sort (which are "global""), where you can divide them amongst several
programmers/several modules without worrying about conflicts.
2. DRB (Distributed Ruby) is *MUCH* simpler and easier than anything that the
Python folks have devised. The similarity to Java's distributed programming
model makes it a good prototyping mechanism for distributed Java programs.
3. I like being able to add methods to an already-existing class in Ruby.
This makes many things much easier.
4. I like being able to pass around a method in Python. This makes many
things much easier.
5. Multiple inheritance is good in Python.
6. I like the 'module' concept in Ruby, which works around many of the
problems with multiple inheritence, but not enough to consider it a full
replacement for multiple inheritance.
7. Access to object namespace in Python allows very easy self-referential
classes.
8. Ruby extension modules are *MUCH* easier to write than Python ones (and
I've written a few Python ones in my time).
9. Reference counting (Python) is more memory-efficient than garbage
collection (Ruby), since it frees up memory as references are destroyed
rather than waiting until a garbage collector runs. Python does need a
garbage collector to collect circularly-referenced objects though, so
Python's lack of garbage collection overhead has to be offset by the fact
that circular references currently hang around forever.
10. Reference counting works hand-in-hand with Python's destructors to handle
resource cleanups in a real-time manner that's difficult with Ruby (where you
can set up destructors of a sort but they only run at garbage collection
time, which may be some time later, in the meantime you still have some open
files and files on disk hanging around that are not getting cleaned up).
11. Iterators (Ruby) are good stuff.
12. Python is no speed demon, but is faster than Ruby for the things I do.
13. Python has a nice GUI-based debugger, which makes many things easier.
14. Ruby has a nice shell-ish/perl-ish 'backtic' syntax which makes many
things much quicker to write than in Python, which is rather anal and
European in its treatment of Unix-y stuff.
15. Python has a much better Emacs mode than Ruby. I especially like the
class browser.
Final conclusions: I must agree with Bruce Eckel that I could not recommend
that a Python programmer move to Ruby except in very special circumstances,
because the two languages are so similar that there's no real advantage to
doing so. In my case I'm using Ruby because I needed to prototype a
distributed application and the various Python frameworks were too complex
and difficult to use compared to Distributed Ruby. There are also some legal
reasons stemming from past employment for not using Python in certain
applications, reasons that I won't discuss here.
My preliminary conclusion is that Python is a superior language for large
projects. It is virtually impossible to make a difficult-to-read Python
program due to its indentation-based syntax, the namespace partitioning makes
large projects easier to partition amongst multiple programmers or multiple
programming groups, and there is a large number of enterprise-oriented
libraries for access to various proprietary and non-proprietary external
systems. It is also portable to more architectures than Ruby, which is
important for some large multi-platform applications. Python's syntax is also
more regular and consistent than Ruby's, which again is important for large
multi-programmer projects.
Ruby, on the other hand, is a much better scripting language (as vs.
general-purpose programming language) than Python. It is much easier to chain
pieces together, especially for distributed applications. It also makes a
superior language for prototyping Java applications, since many aspects
(iterators, rinda, single inheritance only, etc.) are similar to Java. I
would not, however, relish attempting to manage 100K+ lines of Ruby code for
a project, while Python proved to be quite usable for 100K+ lines of code.
--
Pixel
> Ouch!
>
> http://www.mindview.net/Etc/FAQ.html#Ruby
>
> Thoughts?
what i find quite funny is:
# Perhaps the real question to ask, which is usually what I ask myself when I'm
# looking at a language, is "what does this language do/accomplish/improve that
# is better than the language it is competing with (in this case, Python)."
Well, quite easy, just have a look at what's new in python 2.x [1,2]
- "PEP 234: Iterators" with "PEP 255: Simple Generators", even using the
"yield" name
- "PEP 227: Nested Scopes", the {|i| ... } can be seen as an anonymous
function introducing nested scopes. Aka closures are already there in ruby,
whereas python 2.0 didn't have it. And Python still have no way to restrict a
variable scope from being function-wide (think "for i in ..." then using i)
- manipulating builtin objects via methods, not functions
(eg: String methods[2])
- f(*args, **kw) to flatten args
- Augmented Assignment (+=, *= ...)
- Garbage Collection of Cycles (python is still using refcount, but at least
do not leak)
- subclassing of builtin types (i don't remember if it's available yet in 2.2
or should come soon?)
Now of course, the arguments above were in favour of Ruby vs Python, but are
no more :) Except for saying Ruby guided Python in the right direction.
[1] http://www.amk.ca/python/2.2/
[2] http://www.amk.ca/python/2.0/
--
Pixel
Michael Neumann
> Thoughts:
>
> 4. I like being able to pass around a method in Python. This makes many
> things much easier.
You can do the same in Ruby. Either use lambda (as in Python) or proc
(Proc.new).
You can also pass methods around in Ruby:
class A
def b
p "b"
end
end
a = A.new
meth_b = a.method(:b)
meth_b.call() # => "b"
# or convert it to a Proc
meth_b.to_proc
> 10. Reference counting works hand-in-hand with Python's destructors to handle
> resource cleanups in a real-time manner that's difficult with Ruby (where you
> can set up destructors of a sort but they only run at garbage collection
> time, which may be some time later, in the meantime you still have some open
> files and files on disk hanging around that are not getting cleaned up).
Use the block paradigm instead. E.g.
DBI.connect do | dbh |
# do something with dbh
end
or
File.open(fileName, "r") do | file |
# ...
end
Using this there is no need for destructors.
> 13. Python has a nice GUI-based debugger, which makes many things easier.
16. OOP in Ruby is very clean and much more fun.
17. irb and ri
The autocompletion mode of irb ("irb -r irb/completion") is a great
feature. ri is very useful, too. It can save you alot of time searching
around in the references.
> My preliminary conclusion is that Python is a superior language for large
> projects. It is virtually impossible to make a difficult-to-read Python
> program due to its indentation-based syntax, the namespace partitioning makes
This heavily depends on the programmer who wrote the code. Maybe it looks not that bad
in Python (due to forced indentation), but the code can be confusing in any language,
including Ruby. Luckily you can use e.g. Vim to automatically (re-)
indent you code.
Thereagainst I'd criticise Python's use of method names like _xxx or
__xxx (looks not that nice for me), and all the things that are for me
not that transparent and are IMHO better and easier solved in Ruby (e.g. mixin,
use of self as first parameter etc.). But I never worked with these
special features in Python, only had a look on it as non-Pythoneer.
> large projects easier to partition amongst multiple programmers or multiple
> programming groups, and there is a large number of enterprise-oriented
> libraries for access to various proprietary and non-proprietary external
> systems. It is also portable to more architectures than Ruby, which is
> important for some large multi-platform applications. Python's syntax is also
> more regular and consistent than Ruby's, which again is important for large
> multi-programmer projects.
>
> Ruby, on the other hand, is a much better scripting language (as vs.
> general-purpose programming language) than Python. It is much easier to chain
> pieces together, especially for distributed applications. It also makes a
> superior language for prototyping Java applications, since many aspects
> (iterators, rinda, single inheritance only, etc.) are similar to Java. I
> would not, however, relish attempting to manage 100K+ lines of Ruby code for
> a project, while Python proved to be quite usable for 100K+ lines of code.
I'd hold against your last sentence, but I never tried it out.
But maybe 100K lines in Python are just 50K in Ruby ;-)
--
Michael Neumann
merlin.zwo InfoDesign GmbH
http://www.merlin-zwo.de
Robert Feldt
I'm trying to understand them fully and have some questions. Would be
great if you have the time to answer them.
> 1. Python's namespace conventions (i.e., no "global" global variables, only
> module-global variables) make it easier to partition a large project amongst
> various programmers, especially projects that require configuration variables
> of some sort (which are "global""), where you can divide them amongst several
> programmers/several modules without worrying about conflicts.
>
Do you mean that if there is a (in some aspect) "bad" language construct
it will be used? Or is there something that can be done in Python here
that is not possible with Ruby (here: class vars in module)?
> 4. I like being able to pass around a method in Python. This makes many
> things much easier.
>
You know of Object#method? But I've heard Python has syntactic support
here? Are you after something like
[1,2].map(:succ) # => [2,3]
which I'd like (and can have by redefining map etc).
But there is a deeper difference here?
> 7. Access to object namespace in Python allows very easy self-referential
> classes.
>
Hmm, sounds interesting. Can you show example or point me to one?
> 15. Python has a much better Emacs mode than Ruby. I especially like the
> class browser.
>
Any one feel like extending Ruby mode by looking at Python's?
> Final conclusions: I must agree with Bruce Eckel that I could not recommend
> that a Python programmer move to Ruby except in very special circumstances,
> because the two languages are so similar that there's no real advantage to
> doing so.
>
Sounds reasonable if they are very similar.
> My preliminary conclusion is that Python is a superior language for large
> projects. It is virtually impossible to make a difficult-to-read Python
> program due to its indentation-based syntax,
>
IMHO, Python is hard to read. And passing self along hides the essence...
> the namespace partitioning makes
> large projects easier to partition amongst multiple programmers or multiple
> programming groups,
>
Could you give a concrete example of this?
> and there is a large number of enterprise-oriented
> libraries for access to various proprietary and non-proprietary external
> systems.
>
Ok.
> It is also portable to more architectures than Ruby, which is
> important for some large multi-platform applications.
>
Ok.
> Python's syntax is also
> more regular and consistent than Ruby's, which again is important for large
> multi-programmer projects.
>
Why is it more important? To enforce a certain coding format? Example?
> I
> would not, however, relish attempting to manage 100K+ lines of Ruby code for
> a project, while Python proved to be quite usable for 100K+ lines of code.
>
I don't agree with this but I haven't developed any 100K+ lines of Ruby
programs. Why will Ruby "break down"? My feeling has been quite the
opposite even though the difference to other languages might not be
revolutionary. I use Ruby more as a general programming language than as a
scripting language.
NOTE: I'm not into any language flaming here; just trying to understand
your points better.
Regards,
Robert
Emiliano
> > Ouch!
> >
> > http://www.mindview.net/Etc/FAQ.html#Ruby
> >In message "[ruby-talk:20135] Bruce Eckel's criticism of Ruby"
> > on 01/08/23, Ned Konz <n...@bike-nomad.com> writes:
> >
> >|"Bruce Eckel thinks Ruby isn't worth learning...".
> >
> >Many people think Riding motorcycle isn't worth learning. They feel
> >motorcycle are bad ripoff of cars (because of fewer tires). But others
> >don't agree.
The difference being that people that think like this about riding
motorcycles most prabably haven't actually tried riding one. Bruce
Eckel certainly does know a thing or two about OO.
Dismissing an opinion or observation is easy. Learning from it is hard
but beneficial in the long run.
Emile
Eric Lee Green
> Eric Lee Green wrote:
> > 10. Reference counting works hand-in-hand with Python's destructors to
> > handle resource cleanups in a real-time manner that's difficult with Ruby
> > (where you can set up destructors of a sort but they only run at garbage
> > collection time, which may be some time later, in the meantime you still
> > have some open files and files on disk hanging around that are not
> > getting cleaned up).
>
> Use the block paradigm instead. E.g.
>
> DBI.connect do | dbh |
> # do something with dbh
> end
>
While nice in its context, this does not work for many paradigms. For
(hypothetical) example, I have a class which maintains some state information
in a database. When an instance is destroyed, I want the corresponding state
deleted out of the database. But I don't know beforehand when an instance is
going to be destroyed, because I am one programmer on a team of 50
programmers working on this product. It is clear that a destructor is the
most useful way of handling this situation.
> > Java. I would not, however, relish attempting to manage 100K+ lines of
> > Ruby code for a project, while Python proved to be quite usable for 100K+
> > lines of code.
>
> I'd hold against your last sentence, but I never tried it out.
> But maybe 100K lines in Python are just 50K in Ruby ;-)
Destructors are just another one of those features of Python which are
oriented towards making 100K+ line programs with multiple programmers
managable in Python. I like Ruby for one-programmer projects, but I just
can't see how it could scale well to multi-programmer multi-100K-line
projects. I've used Python in such large projects and it works quite well.
The compartmented namespace in particular was extremely useful for
partitioning tasks between programmers -- I could give them total freedom
over how they were to implement their part of the program without worry about
whether they'd tromp over one of my global configuration variables or etc.
Finally, regarding verboseness of Python vs. Ruby, I haven't noticed any real
difference there. Both are fairly terse. There is at most a few percent
advantage to Ruby here, mostly because the backtick syntax and regular
expresson syntax is tighter. There just isn't anything compelling about the
verboseness issue that would make a Python programmer switch to Ruby. Other
issues (such as, e.g., the 1-1 mapping between many Ruby and Java features,
which makes prototyping Java programs in Ruby quite easy) are probably more
important here.
Robert Feldt
> > > Java. I would not, however, relish attempting to manage 100K+ lines of
> > > Ruby code for a project, while Python proved to be quite usable for 100K+
> > > lines of code.
> >
> > I'd hold against your last sentence, but I never tried it out.
> > But maybe 100K lines in Python are just 50K in Ruby ;-)
>
> Destructors are just another one of those features of Python which are
> oriented towards making 100K+ line programs with multiple programmers
> managable in Python. I like Ruby for one-programmer projects, but I just
> can't see how it could scale well to multi-programmer multi-100K-line
> projects. I've used Python in such large projects and it works quite well.
> The compartmented namespace in particular was extremely useful for
> partitioning tasks between programmers -- I could give them total freedom
> over how they were to implement their part of the program without worry about
> whether they'd tromp over one of my global configuration variables or etc.
>
Ok, I think I understand this better now.
In Ruby, if programmer A changes Array#[] it might affect other
programmers when system is integrated (;-)). I think this is solved in AOS
and a RubyOnAos solution may be in a position to address it. It would be a
problem with current Ruby solutions though...
In the Smalltalk community there has been a trend towards
namespaces. Maybe Ruby will have to follow?
Thanks,
Robert
Paul Brannan
> Use the block paradigm instead. E.g.
>
> DBI.connect do | dbh |
> # do something with dbh
> end
>
> or
This works fine for short-lived objects, but how can I use blocks for
objects that get passed around? I think that would be a case where I
would have to implement my own reference counting in Ruby. Not a common
case, imo, but still important to consider.
> > would not, however, relish attempting to manage 100K+ lines of Ruby code for
> > a project, while Python proved to be quite usable for 100K+ lines of code.
>
> I'd hold against your last sentence, but I never tried it out.
> But maybe 100K lines in Python are just 50K in Ruby ;-)
The problem is not the number of lines itself, but that projects that
large have certain needs, and Ruby makes it difficult to meet those needs.
For example, using inheritance in Ruby on a team with many programmers may
be difficult, because really is no such thing as private instance data in
Ruby. Nifty funtions like send() and method() allow the user to call
private/protected methods that they should not be allowed to call (at
least, not by accident). Ruby lets you define a public method in a
derived class that was private in the base class without so much as a
warning, so you need to have full knowledge of the base class's *private*
interface if you don't want to break something.
I also find myself reinventing the wheel in Ruby a lot, because some
library doesn't exist for Ruby or it doesn't work the way I want it to.
(Perhaps this is an advantage of Ruby, though, because it gives the Ruby
world a chance to get things done right, instead of having to maintain
compatibility with older versions).
I think it's very important that we keep in mind that as good as Ruby is,
it does have a long way to go.
Paul
Kevin Smith
> > > Java. I would not, however, relish attempting to
> manage 100K+ lines of
> > > Ruby code for a project, while Python proved to be
> quite usable for 100K+
> > > lines of code.
> >
> > I'd hold against your last sentence, but I never tried
> it out.
> > But maybe 100K lines in Python are just 50K in Ruby ;-)
>
> Destructors are just another one of those features of
> Python which are oriented towards making 100K+ line
> programs with multiple programmers managable in Python.
Shhhhh. Don't tell the Java programmers that destructors
are needed for big apps! [Ok, I'm a Java programmer, too]
Seriously, I haven't tried a really big app in Python or
Ruby, but based on what I've done so far in Ruby I would
have no qualms about trying one.
I use Ruby as an app language, not as a scripting language.
I suspect a large Ruby app would be less troublesome than a
large Java app.
Modules and full-on use of classes are great tools for
modularity. Global? What's a global?
I think the choice between Python and Ruby is largely a
matter of which syntax feels more comfortable to you.
The comparison of available libraries is like comparing
Python a couple years ago against Perl. Python continues to
grow, and Ruby will grow as well, closing that gap over
time. (Of course, both have a ways to go to approach Perl).
Kevin
__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com
Emiliano
> > Python's syntax is also
> > more regular and consistent than Ruby's, which again is important for
> > large multi-programmer projects.
>
> Why is it more important? To enforce a certain coding format? Example?
Yes, to enforce a certain coding format. I'm no great fan of python myself,
but one of the downsides (for me) of Perl & Ruby is the utterly
incomprehensible syntax they allow and which seems to be encouraged (things
like $_ come to mind as one of the more benign ones) that tends to bring out
the worst in creative users, passing on unmaintainable messes to unsuspecting
maintainers.
Emile
Emiliano
> While nice in its context, this does not work for many paradigms. For
> (hypothetical) example, I have a class which maintains some state
> information in a database. When an instance is destroyed, I want the
> corresponding state deleted out of the database. But I don't know
> beforehand when an instance is going to be destroyed, because I am one
> programmer on a team of 50 programmers working on this product. It is clear
> that a destructor is the most useful way of handling this situation.
No offence but I think that a good design up front would be the most useful
way of handling this situation.
Emile
Rich Kilmer
> -----Original Message-----
> From: Robert Feldt [mailto:fe...@ce.chalmers.se]
> Sent: Tuesday, October 23, 2001 4:50 PM
> To: ruby-talk ML
> Subject: [ruby-talk:23088] Re: Bruce Eckel's opinion of Ruby
>
> .
> .
> .
>
> In Ruby, if programmer A changes Array#[] it might affect other
> programmers when system is integrated (;-)). I think this is solved in AOS
> and a RubyOnAos solution may be in a position to address it. It would be a
> problem with current Ruby solutions though...
>
> In the Smalltalk community there has been a trend towards
> namespaces. Maybe Ruby will have to follow?
>
> Thanks,
>
> Robert
>
Question: Don't modules give you a namespace capability?
I realize it does not in the sense that overriding a method on class Array will effect the entire interpreter, but in the sense that it partitions symbols (variables, classes, modules, etc).
Are you speeking here of an ability to actually change Array, but have that change only be available to the originating "namespace" and classes (or modules) defined within a "namespace" are only visible to that "namespace"?
Eric Lee Green
> Hi Eric and thanks for your detailed comments,
>
> I'm trying to understand them fully and have some questions. Would be
> great if you have the time to answer them.
>
> > 1. Python's namespace conventions (i.e., no "global" global variables,
> > only module-global variables) make it easier to partition a large project
> > amongst various programmers, especially projects that require
> > configuration variables of some sort (which are "global""), where you can
> > divide them amongst several programmers/several modules without worrying
> > about conflicts.
>
> Do you mean that if there is a (in some aspect) "bad" language construct
> it will be used? Or is there something that can be done in Python here
> that is not possible with Ruby (here: class vars in module)?
More like something that can be done with Ruby (true global variables) that
cannot be done with Python. With Python, all "global" variables are
module-specific. This is similar to class variables, except not (Ruby doesn't
really have Python-style modules, what it has is, well, different).
Basically, what this means is that other programmers are less likely to
somehow tromp on important global data.
> > 7. Access to object namespace in Python allows very easy self-referential
> > classes.
>
> Hmm, sounds interesting. Can you show example or point me to one?
I can't show you example, but can describe one. In last large Python program
that I wrote, we had a 'dbaccess' class. This class encapsulated a generic
possible record type in the database. This class was subclassed by individual
classes for each record type in the database. Each record type instantiated
class variables in its declaration for table name, field names (list), and
field types (list). The initializer for the dbaccess class stuffed the field
names into the instance of the end class as variables. Thus if I have a
"Customer" table, with field names "Last", "First", "Middle", "CustNum", I
could do something like
l=Customer(5324) # get customer #5324
print "Name =",l.Last,",",l.First," ",l.Middle
And if I wanted to change his name, I could say something like
l.Last="Ferguson" # she married
l.Update() # and change it on disk.
and voila. All this was handled automagically behind the scenes via
self-referencing on the part of the base 'dbaccess' class.
> > My preliminary conclusion is that Python is a superior language for large
> > projects. It is virtually impossible to make a difficult-to-read Python
> > program due to its indentation-based syntax,
>
> IMHO, Python is hard to read. And passing self along hides the essence...
But you're not working on a large project with multiple programmers. A clear
and *CONSISTENT* style is important in such cases. Whether you personally
like that style or not is largely irrelevant. If the language largely
enforces such a style, this makes the code in large projects much easier to
read. I'll note that virtually every programmer eventually has to go into a
module written by some other programmer and add new features and/or fix it.
With Python, you guarantee that the coding style is reasonably consistent
(e.g. every if statement looks like this:
if condition :
clause
else:
clause
which eliminates fighting through if statements that look like this:
if (something) { this(); } else { that(); }
all piled on top of each other.
> > the namespace partitioning makes
> > large projects easier to partition amongst multiple programmers or
> > multiple programming groups,
>
> Could you give a concrete example of this?
Mostly lack of "true" global variables here. There is no common namespace for
programmers to stomp around in. Thus variables end up getting either
instantiated into an explicit module-specific namespace for their particular
module, or end up migrating into a class. It's hard to provide an example of
LACK of something :-}.
> > and there is a large number of enterprise-oriented
> > libraries for access to various proprietary and non-proprietary external
> > systems.
>
> Ok.
>
> > It is also portable to more architectures than Ruby, which is
> > important for some large multi-platform applications.
>
> Ok.
>
> > Python's syntax is also
> > more regular and consistent than Ruby's, which again is important for
> > large multi-programmer projects.
>
> Why is it more important? To enforce a certain coding format? Example?
Uhm, and you've worked on how many large multi-programmer projects? I once
worked on a project that had over 1,000,000 lines of code that had been
written by a dozen programmers over a 10 year period. One programmer in
particular irritated me to no end -- he did everything as if he were
programming in COBOL. Fixing his programs (or, more usually, updating them to
cope with new changes to accounting rules) was an exercise in decrypting
COBOL syntax written with "C" preprocessor macros. Tasks that should have
taken me minutes took hours instead. The point is that a clear, regular
syntax eases the task of future maintenance. Python has been criticized as
having a rigid and inflexible syntax, and to a certain extent that is true.
But for very large projects, that's a virtue.
> > I
> > would not, however, relish attempting to manage 100K+ lines of Ruby code
> > for a project, while Python proved to be quite usable for 100K+ lines of
> > code.
>
> I don't agree with this but I haven't developed any 100K+ lines of Ruby
> programs. Why will Ruby "break down"? My feeling has been quite the
Note that I have not developed very large programs in Ruby either, I'm to a
certain extent comparing it to what I've seen happen in very large Python,
C++ or Java programs. Large Java programs are managable because of the class
heirarchy. Python does not have a class heirarchy, but has modules which
handle some of the management issues. C++, prior to namespaces, could swiftly
become unmanageable, and Ruby's management issues seem to me to be similar to
those of C++. (Even with namespaces, C++ is not my favorite language... I
prefer Java whenever possible if I have to use a compiled language but don't
need the absolute performance of "C").
> opposite even though the difference to other languages might not be
> revolutionary. I use Ruby more as a general programming language than as a
> scripting language.
>
> NOTE: I'm not into any language flaming here; just trying to understand
> your points better.
I'm not sure that I understand all my points myself :-). Some of this is just
gut feel from close to 20 years of programming in everything from DBASE-II
(how debased!) and PL/1 to Python, Java, and Ruby. My "gut feel" here is that
Ruby is an excellent scripting language but that I wouldn't want to write a
large multi-programmer project with it. This, however, doesn't mean that YOU
would have difficulty writing a large multi-programmer project with it (after
all, some people have succeeded with *PERL*, of all things!), just that
Python has more "goodness" for that for my style of project management than
most other languages that I've encountered (for that matter, the much-derided
Java also has a lot of "goodness" for multi-programmer projects, which is
probably why IBM is pushing it everywhere). Quantifying "goodness" is a hard
thing to do, and I'm not sure I can successfully do so. After all, if us
experienced old hands could communicate everything we knew, there wouldn't be
much use for us, right? :-).
Robert Feldt
> Question: Don't modules give you a namespace capability?
>
Not in the sense below.
> I realize it does not in the sense that overriding a method on class
> Array will effect the entire interpreter, but in the sense that it
> partitions symbols (variables, classes, modules, etc).
>
> Are you speeking here of an ability to actually change Array, but have
> that change only be available to the originating "namespace" and classes
> (or modules) defined within a "namespace" are only visible to that
> "namespace"?
>
Yes, its a "namespace" in a different sense. From my understanding
Smallscript/AOS and recent Smalltalks have this latter thing. And it
seemed to have evolved because people were having problems with this. But
I'm not sure of this.
A sort-of scaled up Ruby/Behaviors à la David Black?!
Regards,
Robert
Paul Brannan
> I realize it does not in the sense that overriding a method on class
> Array will effect the entire interpreter, but in the sense that it
> partitions symbols (variables, classes, modules, etc).
>
> Are you speeking here of an ability to actually change Array, but have
> that change only be available to the originating "namespace" and
> classes (or modules) defined within a "namespace" are only visible to
> that "namespace"?
Someone brought this up at the conference. Does this give the desired
result?
module Foo
class Array < Array
def []=(foo, bar)
super(foo, bar)
puts 'foo'
end
end
def self.foo
a = Array.new
a[0] = 42
end
foo
end
a = Array.new
a[0] = 42
Paul
Tobias Reif
> I also find myself reinventing the wheel in Ruby a lot, because some
> library doesn't exist for Ruby
[...]
> I think it's very important that we keep in mind that as good as Ruby is,
> it does have a long way to go.
second that. I love Ruby, but often miss various libs.
Tobi
--
Tobias Reif
http://www.pinkjuice.com/myDigitalProfile.xhtml
go_to('www.ruby-lang.org').get(ruby).play.create.have_fun
http://www.pinkjuice.com/ruby/
Eric Lee Green
And you work in which mythical shop that does everything "right"? :-)
(Just thinking of one project I've worked on... I asked for the MRD so I
could do a functional spec, my manager said "I'll get you one but here's what
we want", so I prototyped a design, said "Will this work?", "Yes... no, the
customer says that's not what he wants..." I repeat request for MRD, manager
says "I'll get you one but here's what we want" .... sigh).
In the big project that I did in Python, we overlapped design and
implementation phases to great extent. The first thing I did was draw the
architecture on the whiteboard along with data flows within that
architecture, and listed the basic criteria and functionality of the program
(the latter was a massive document that I spent a week of meetings and a week
of writing to put together). Then we assigned boxes of that architecture to
various people, but the innards of chunks were not designed in detail by the
project architect and the team leads. Rather, those designs were assigned to
the people who "owned" various modules, who were required to document them
prior to implementing them (and yes this was enforced :-). People had wide
lattitude in how they designed and implemented their particular chunk, as
long as they got together with the people at the interfaces to properly
document the data being passed and make sure that it met the requirements of
all consumers. We managed to write a fairly large-scale enterprise-class
program in under six months with a manpower budget that was hilariously
undersized for the task we'd been assigned, and I don't know if we could have
done it in Ruby. It was doable -- barely -- in Python. I know we couldn't
have done it in C++, we'd still be tracking down memory leaks today :-).
Point: The "right" way is any way that gets things done in a reasonable way
in the least amount of time. Having destructors makes this easier in many
cases. A "good design up front" is one of those things that in my opinion is
utterly impossible -- designs are created via a process of successive
refinement (i.e., top-down), and there's no way up front that you can know
everything that's going to be necessary at the very bottom of the design
heirarchy. The most you can do is set up a good strong architecture up front
where the pieces can be isolated so that each individual piece can be
individually designed and etc., because no plan of battle survives contact
with the enemy^h^h^h^h^hactual customer. You can request MRD's and spew out
functional specs until you're blue in the face and this will still remain
true, though of course I do *NOT* recommend going into any project without
MRD's and functional specs! (For one thing, when marketing wants "one more
feature", it makes it that much easier to tell them "No, we've done
everything on our MRD and functional spec, put it on the wish list for
version 1.1").
In my opinion, this is why Unix is still with us 30 years later -- its
componetized design allowed it to move forward into different market niches
as the world changed, even though Unix was never really formally "designed".
All projects are organic in the end, and must be designed as such. Requiring
high-end consumers to know anything about low-level design of individual
modules is hardly something that will enhance future maintainability and
added functionality for the program.
Pixel
> > Use the block paradigm instead. E.g.
> >
> > DBI.connect do | dbh |
> > # do something with dbh
> > end
>
> This works fine for short-lived objects, but how can I use blocks for
> objects that get passed around? I think that would be a case where I
> would have to implement my own reference counting in Ruby.
Hey, ruby does have a memory management system, it just doesn't ensure
finalisation as soon as possible!
IMO block paradigm can take care of case when you want to ensure to destructor
to be called when out of scope. When the object outlive current scope, waiting
for GC is no such big deal.
--
Pixel
Robert Feldt
> > > 7. Access to object namespace in Python allows very easy self-referential
> > > classes.
> >
> > Hmm, sounds interesting. Can you show example or point me to one?
>
> I can't show you example, but can describe one. In last large Python program
> that I wrote, we had a 'dbaccess' class. This class encapsulated a generic
> possible record type in the database. This class was subclassed by individual
> classes for each record type in the database. Each record type instantiated
> class variables in its declaration for table name, field names (list), and
> field types (list). The initializer for the dbaccess class stuffed the field
> names into the instance of the end class as variables. Thus if I have a
> "Customer" table, with field names "Last", "First", "Middle", "CustNum", I
> could do something like
>
> l=Customer(5324) # get customer #5324
> print "Name =",l.Last,",",l.First," ",l.Middle
>
>
> And if I wanted to change his name, I could say something like
>
> l.Last="Ferguson" # she married
> l.Update() # and change it on disk.
>
> and voila. All this was handled automagically behind the scenes via
> self-referencing on the part of the base 'dbaccess' class.
>
I fail to see why this cannot be done easily in Ruby. But I probably don't
understand it ;-)
> > > My preliminary conclusion is that Python is a superior language for large
> > > projects. It is virtually impossible to make a difficult-to-read Python
> > > program due to its indentation-based syntax,
> >
> > IMHO, Python is hard to read. And passing self along hides the essence...
>
> But you're not working on a large project with multiple programmers. A clear
> and *CONSISTENT* style is important in such cases. Whether you personally
> like that style or not is largely irrelevant. If the language largely
> enforces such a style, this makes the code in large projects much easier to
> read. I'll note that virtually every programmer eventually has to go into a
> module written by some other programmer and add new features and/or fix it.
>
I agree with all of this. But coding standard and layout issues can be
handled outside of the language itself. Normalize and check style
conformance at check-in.
If one language had a more flexible syntax but allowed me to more clearly
express my intentions with the design and implementation one might
consider finding a way to restrict the syntax rather than dump the
language. I'm not saying that Ruby is more semantically powerful than
Python though (they're both Turing complete... ;-)).
> > Why is it more important? To enforce a certain coding format? Example?
>
> Uhm, and you've worked on how many large multi-programmer projects? I once
>
Some but not many. Only C and VB though.
> worked on a project that had over 1,000,000 lines of code that had been
> written by a dozen programmers over a 10 year period. One programmer in
> particular irritated me to no end -- he did everything as if he were
> programming in COBOL. Fixing his programs (or, more usually, updating them to
> cope with new changes to accounting rules) was an exercise in decrypting
> COBOL syntax written with "C" preprocessor macros. Tasks that should have
> taken me minutes took hours instead. The point is that a clear, regular
> syntax eases the task of future maintenance. Python has been criticized as
> having a rigid and inflexible syntax, and to a certain extent that is true.
> But for very large projects, that's a virtue.
>
I agree that clearness is key here. But syntax can be checked and
transformed. Maybe as part of the unit tests so you'd fail the
non-functional requirements of the coding standard? But ok, there
will be pedagogical issues in a language were there is more
freedom (In Python folks are used to one syntax so no reason to
discuss; may not be the case for Ruby).
Thanks for your interesting points.
Cheers,
Robert
Sean Russell
> Disclaimer: I have written approximately 100,000 lines of Python in the
> past 2 years, and approximately 10,000 lines of Ruby in the past 2 months.
> Thus I am approximately 10 times more expert in Python than in Ruby. I
> don't, however, have any particular axe to grind regarding languages,
> heck, I even write my web pages in PHP (one of the most bletcherous
> excuses for a programming language to come down the pike -- but excellent
> for quicky one-off weblets).
That was a good run-down.
> 9. Reference counting (Python) is more memory-efficient than garbage
> collection (Ruby), since it frees up memory as references are destroyed
I've never found Ruby to suffer from poor memory management.
> 10. Reference counting works hand-in-hand with Python's destructors to
> handle resource cleanups in a real-time manner that's difficult with Ruby
This (and 9) would be easily solved by a mechanism to force the garbage
collector to run; if Ruby doesn't have one, it should.
> 15. Python has a much better Emacs mode than Ruby. I especially like the
> class browser.
You can tell an emacs freak by the fact that they choose their programming
languages by how well supported they are by emacs ;-)
> Final conclusions: I must agree with Bruce Eckel that I could not
> recommend that a Python programmer move to Ruby except in very special
> circumstances, because the two languages are so similar that there's no
> real advantage to doing so. In my case I'm using Ruby because I needed to
Yeah, that's a tough call. *I'd* recommend them switching, because I hate
Python with something approaching passion, and the less of it I have to
encounter, the happier I am. For a beginner, though, I'd recommend Ruby.
I've been programming in one thing or another since 1983, and the syntax in
Python's "hello world" was enough to turn me off.
> aspects (iterators, rinda, single inheritance only, etc.) are similar to
> Java. I would not, however, relish attempting to manage 100K+ lines of
> Ruby code for a project, while Python proved to be quite usable for 100K+
> lines of code.
Apart from my dislike of Python syntax, I'd have no trouble accepting
maintenance of 100K+ lines of Ruby code, assuming the code was written by
someone sane; I'd prefer this to taking on, say, 100K+ lines of C code, or
even Java code. Ruby is so orthogonally OO that I can't imagine that it
wouldn't be noticeable on a large scale.
I agree that Ruby has a certain harmonic with Java; since I've been coding
almost exclusively in Java since 1995, I would imagine that the feeling of
similarity is why I prefer Ruby.
--- SER
Sean Russell
>> Why is it more important? To enforce a certain coding format? Example?
>
> Yes, to enforce a certain coding format. I'm no great fan of python
> myself, but one of the downsides (for me) of Perl & Ruby is the utterly
There is always a balance between maintainability and productivity. I
still believe that the source of Pascal's failure was the obnoxious
rigidity. Python drops the rigid typing, but keeps rigid syntax, which is
the my main pet peeve about Python. Perl is at the other end of the
spectrum, which is just as obnoxious. However, I'd choose Perl in all of
its obtuse obscifuscation that Python's draconian dogma any day. I think
Ruby struck a decent balance.
--- SER
Emiliano
> And you work in which mythical shop that does everything "right"? :-)
I don't. I don't even think I'd want to :) What I was (tersely) pointing
out that the particular example you gave probably needed a 'protocol'
for lifetime management anyway. But I know, not all issues are known up
front, and in such cases tricks like using garbage collection to manage
resources can be a big help. I just don't think it's the right solution
if you know going in that you're going to need it. As much as it is
convenient that things disappear when appropriate, I can imagine the
frustration when you notice that it doesn't disappear because someone,
somewhere is still holding a handle on your resource. Much fun.
> In the big project that I did in Python, we overlapped design and
> implementation phases to great extent. The first thing I did was draw the
> architecture on the whiteboard along with data flows within that
> architecture, and listed the basic criteria and functionality of the program
> (the latter was a massive document that I spent a week of meetings and a week
> of writing to put together). Then we assigned boxes of that architecture to
> various people, but the innards of chunks were not designed in detail by the
> project architect and the team leads. Rather, those designs were assigned to
> the people who "owned" various modules, who were required to document them
> prior to implementing them (and yes this was enforced :-). People had wide
> lattitude in how they designed and implemented their particular chunk, as
> long as they got together with the people at the interfaces to properly
> document the data being passed and make sure that it met the requirements of
> all consumers. We managed to write a fairly large-scale enterprise-class
> program in under six months with a manpower budget that was hilariously
> undersized for the task we'd been assigned, and I don't know if we could have
> done it in Ruby. It was doable -- barely -- in Python. I know we couldn't
I'm not saying I'd do it in Ruby either. I tend to agree that for
large projects, or even small projects where people drift in and out,
the flexibility the Ruby (or Perl) syntax allows has negative
benefits.
And yes, I know the short-path-between-thought-and-code-with-Ruby argument.
For larger projects I would want
short-path-between-reading-and-understanding instead. An entirely
different matter.
> have done it in C++, we'd still be tracking down memory leaks today :-).
Count your blessings you're allowed to use Python. The projected I
drifted into uses VB.
> Point: The "right" way is any way that gets things done in a reasonable way
> in the least amount of time. Having destructors makes this easier in many
> cases. A "good design up front" is one of those things that in my opinion is
> utterly impossible -- designs are created via a process of successive
> refinement (i.e., top-down), and there's no way up front that you can know
> everything that's going to be necessary at the very bottom of the design
> heirarchy. The most you can do is set up a good strong architecture up front
> where the pieces can be isolated so that each individual piece can be
> individually designed and etc.,
Right, but important data that's going to be passed around a lot has
the right characteristics to have a decent shot to be determined
early. Anyhow, given complex and fuzzy requirements (and you're
right, I haven't seen them any way else) it's a good way to handle the
chaos. Still, as noted above, I don't think it's the right strategy to
start out with. It's an excellent backup plan.
> because no plan of battle survives contact
> with the enemy^h^h^h^h^hactual customer. You can request MRD's and spew out
> functional specs until you're blue in the face and this will still remain
> true, though of course I do *NOT* recommend going into any project without
> MRD's and functional specs! (For one thing, when marketing wants "one more
> feature", it makes it that much easier to tell them "No, we've done
> everything on our MRD and functional spec, put it on the wish list for
> version 1.1").
We understand each other :)
Emile
Robert Feldt
> The difference being that people that think like this about riding
> motorcycles most prabably haven't actually tried riding one. Bruce
> Eckel certainly does know a thing or two about OO.
>
Agreed, but...
> Dismissing an opinion or observation is easy. Learning from it is hard
> but beneficial in the long run.
>
I don't think Matz dismissed the opinion of Eckel and it wasn't my
intention to do so either. On the contrary I think matz comment was more
along the lines of "love, peace and understanding".
When I "took on" Eckel's comments some notes were (this is long and rather
boring, you might want to skip it):
"Also note that I've looked at a fair number of languages, and learned
some of them in depth, so I like to think I know what I'm looking for). "
Fair enough, but he is probably also aware of the fact that he is
influential. So it is not only about what he wants but partly also about
"what an OO developer in general" wants and if he fails to act from such
understanding of his influence he is taking part in some kind of
We-better-than-you-simply-because game. Unless his comments are truly
objective.
"IMO, the Ruby syntax is worse and often annoying to me, based on my
knowledge of other languages and especially Python."
Ok, not for me.
>From this I learn that if you come to Ruby (or antoher language) from a
similar language with a different syntax you might not like what you
see. Probably because you have to translate into the mental model based on
concepts from your original comments. Not sure how general this is or if
its what is really happening here. But it might be worse the closer the
languages are.
"Ruby requires more typing for no particular reason, "
This can be tested and I doubt that it is true. From the little Python
experience I have I think it is the other way around. Ok, we have more
"end" stuff but they have "self" etc.
"and has an uninspired choice of syntax in many cases "
I don't understand what he means. Someone with Eckel-like programming
experience (ie. long and with many languages) do?
"Plus Python has 10 years behind it and a big, very smart, very active
community, a nice number of good books and more on the way, a large set of
libraries and a whole process and team in place for developing the
language. "
Ok, here are some objectively testable statements. He seem to be right
that there is a real difference:
Ruby has 8 years. The community is smaller and less "active". There are
more books on the way although I don't know if they're good (well one is
but... ;-)). The set of libraries is smaller. There is a "process". Maybe
Matz is more of a single leader/developer than is Guido; I don't know.
"Recent improvements to the language have outstripped whatever Ruby could
offer, I think, and there's currently lots of very good work going on to
further improve Python."
Ok, this sounds interesting. Could someone point to the recent
improvements that have outstripped whatever Ruby could offer? I note that
he says "could offer" which seems to be a pretty bold statement. I doubt
that it is true. There is currently good work on improving Ruby also.
"FWIW, I usually find that this question is asked by someone who is
considering learning to program, and was snagged by the fact that Ruby is
new, and perhaps thinks that it's going to be the next great thing like
Java. From everything I can see, it's not. For some reason, the creator of
the language saw Python and decided to do a clone, and people who had
never used Python thought it was a good idea. Harsh, maybe, but that's my
impression: if you've used Python at all, you wouldn't give Ruby a second
glance."
My feeling is that there are quite a few experienced programmers coming to
Ruby but I may be wrong. I doubt Matz have conssciously ripped off Python.
Eckel's comments about the productivity treshold seems to imply he
is doing a going-from-python-to-ruby analysis. Seems his conclusions are
reasonable from that viewpoint.
Regards,
Robert
Emiliano
> I agree with all of this. But coding standard and layout issues can be
> handled outside of the language itself. Normalize and check style
> conformance at check-in.
Not all source code management tools support this, and people will
have to spend extra time fixing it when it happens. Like Python or
not, these things are checked at compile time.
That's not to say you can't enforce coding standards for other
languages, but for Python it's been a clear decision to make it part
of the language, and many people appearantly see a benefit to this.
And you can't enforce a coding standard everywhere. Controlled
corporate environments could maybe get away with it (although I'll
leave you to convince our engineers to not tar-and-feather you for
bringing up the concept), many an open source project would not be
able to do so without losing contributers. People can get all hot and
bothered when someone 'attacks' their coding style. At least you get
to skip that discussion in Python projects.
Not that I'd subject myself to Pythons' coding mandates any time soon
:)
> If one language had a more flexible syntax but allowed me to more clearly
> express my intentions with the design and implementation one might
> consider finding a way to restrict the syntax rather than dump the
> language. I'm not saying that Ruby is more semantically powerful than
> Python though (they're both Turing complete... ;-)).
And there's the issue: what's more clear to you could well be utterly
unreadable to another.
> Some but not many. Only C and VB though.
I feel your pain.
> I agree that clearness is key here. But syntax can be checked and
> transformed.
I'd definately always vote down automated code transformations in any
of my projects. The tools (like gnu indent, for example) don't always produce
legible code layout, and it's a disaster waiting to happen. At some
point the tool will mangle your code.
Emile
Emiliano
> > Yes, to enforce a certain coding format. I'm no great fan of python
> > myself, but one of the downsides (for me) of Perl & Ruby is the utterly
>
> There is always a balance between maintainability and productivity. I
> still believe that the source of Pascal's failure was the obnoxious
> rigidity. Python drops the rigid typing, but keeps rigid syntax, which is
> the my main pet peeve about Python.
This is where we agree...
> Perl is at the other end of the
> spectrum, which is just as obnoxious. However, I'd choose Perl in all of
> its obtuse obscifuscation that Python's draconian dogma any day. I think
> Ruby struck a decent balance.
.. and this is where we disagree, a bit. Ruby certainly allows for
very elegant coding. It also allows for job-security coding. Python
makes that a lot harder.
Emile
vj...@path.berkeley.edu
> module Foo
> class Array < Array
> def []=(foo, bar)
> super(foo, bar)
> puts 'foo'
> end
> end
>
> def self.foo
> a = Array.new
> a[0] = 42
> end
>
> foo
> end
>
> a = Array.new
> a[0] = 42
I think I'm going to frame that and put it on my wall!
This trick can also be used to dynamically type-check/convert, as a way
of emulating parametric types:
class Float
class Array < Array
def []=(i, j)
super i, Float(j)
end
end
end
af = Float::Array.new
af[0] = 1
af[1] = 2.3
af[2] = "1.2e17"
p af
=> [1.0, 2.3, 1.2e+17]
af[3] = :foo
=> TypeError
You'd have to override a few other methods, such as <<. But it wouldn't
be too hard to automate generating x::Array for x in a list of classes.
Since the :: syntax accepts a variable on the left, you can choose the
"type parameter" dynamically:
x = 3.1
a = x.type::Array.new
a << x
Heartfelt thanks to the unnamed conference participant who came up with
this idea.
--
Joel VanderWerf California PATH, UC Berkeley
mailto:vj...@path.berkeley.edu Ph. (510) 231-9446
http://www.path.berkeley.edu FAX (510) 231-9512
Michael Neumann
> > > 7. Access to object namespace in Python allows very easy self-referential
> > > classes.
> >
> > Hmm, sounds interesting. Can you show example or point me to one?
>
> I can't show you example, but can describe one. In last large Python program
> that I wrote, we had a 'dbaccess' class. This class encapsulated a generic
> possible record type in the database. This class was subclassed by individual
> classes for each record type in the database. Each record type instantiated
> class variables in its declaration for table name, field names (list), and
> field types (list). The initializer for the dbaccess class stuffed the field
> names into the instance of the end class as variables. Thus if I have a
> "Customer" table, with field names "Last", "First", "Middle", "CustNum", I
> could do something like
>
> l=Customer(5324) # get customer #5324
> print "Name =",l.Last,",",l.First," ",l.Middle
>
>
> And if I wanted to change his name, I could say something like
>
> l.Last="Ferguson" # she married
> l.Update() # and change it on disk.
>
> and voila. All this was handled automagically behind the scenes via
> self-referencing on the part of the base 'dbaccess' class.
I didn't got your point, but I am sure this can be done very easy
in Ruby.
In Ruby you can create on-the-fly new classes, add methods, pass classes
around (classes are objects) etc...
> > IMHO, Python is hard to read. And passing self along hides the essence...
>
> But you're not working on a large project with multiple programmers. A clear
> and *CONSISTENT* style is important in such cases. Whether you personally
> like that style or not is largely irrelevant. If the language largely
> enforces such a style, this makes the code in large projects much easier to
> read. I'll note that virtually every programmer eventually has to go into a
> module written by some other programmer and add new features and/or fix it.
> With Python, you guarantee that the coding style is reasonably consistent
> (e.g. every if statement looks like this:
> if condition :
> clause
> else:
> clause
> which eliminates fighting through if statements that look like this:
> if (something) { this(); } else { that(); }
> all piled on top of each other.
You will rarely see such constructs in block-languages like Modula, Ada
or Ruby.
In Ruby you could write:
if something then this else that end
Instead I'd write this using the ? operator:
something ? this : that
But usually you'd write:
if something [then]
this
else
that
end
But this problem you have in almost any other language, too, be it
Java, C/C++ or Eiffel. And in those languages far more larger and more critical
application were written than there will ever be in Python.
I think this is just a matter of disciplin, or the right tools you use.
> > > the namespace partitioning makes
> > > large projects easier to partition amongst multiple programmers or
> > > multiple programming groups,
> >
> > Could you give a concrete example of this?
>
> Mostly lack of "true" global variables here. There is no common namespace for
> programmers to stomp around in. Thus variables end up getting either
> instantiated into an explicit module-specific namespace for their particular
> module, or end up migrating into a class. It's hard to provide an example of
> LACK of something :-}.
global variables will be depreciated in Ruby 2.0 ;-)
no, of course not.
> > > Python's syntax is also
> > > more regular and consistent than Ruby's, which again is important for
> > > large multi-programmer projects.
> >
> > Why is it more important? To enforce a certain coding format? Example?
>
> Uhm, and you've worked on how many large multi-programmer projects? I once
> worked on a project that had over 1,000,000 lines of code that had been
> written by a dozen programmers over a 10 year period. One programmer in
> particular irritated me to no end -- he did everything as if he were
> programming in COBOL. Fixing his programs (or, more usually, updating them to
> cope with new changes to accounting rules) was an exercise in decrypting
> COBOL syntax written with "C" preprocessor macros. Tasks that should have
> taken me minutes took hours instead. The point is that a clear, regular
> syntax eases the task of future maintenance. Python has been criticized as
> having a rigid and inflexible syntax, and to a certain extent that is true.
> But for very large projects, that's a virtue.
I think, this too is a matter of discipline.
Regards,
Michael
Emiliano
> When I "took on" Eckel's comments some notes were (this is long and rather
> boring, you might want to skip it):
>
> "Also note that I've looked at a fair number of languages, and learned
> some of them in depth, so I like to think I know what I'm looking for). "
>
> Fair enough, but he is probably also aware of the fact that he is
> influential. So it is not only about what he wants but partly also about
> "what an OO developer in general" wants and if he fails to act from such
> understanding of his influence he is taking part in some kind of
> We-better-than-you-simply-because game. Unless his comments are truly
> objective.
OK, point taken.
> "IMO, the Ruby syntax is worse and often annoying to me, based on my
> knowledge of other languages and especially Python."
>
> Ok, not for me.
>
> From this I learn that if you come to Ruby (or antoher language) from a
> similar language with a different syntax you might not like what you
> see. Probably because you have to translate into the mental model based on
> concepts from your original comments. Not sure how general this is or if
> its what is really happening here. But it might be worse the closer the
> languages are.
The odd thing is, I "come from" Perl. I find Ruby to be usuable as
long as all the things I routinely use in Perl are skipped. Could be
because I use perl for 'quickies', and the code tends to show it. I
use more OO languages for other types of projects.
> "Ruby requires more typing for no particular reason, "
>
> This can be tested and I doubt that it is true. From the little Python
> experience I have I think it is the other way around. Ok, we have more
> "end" stuff but they have "self" etc.
*shrug* Unless we're talking about Ada I don't think that saving a few
keystrokes is the right argument to choose a language and the
environment around it.
> "and has an uninspired choice of syntax in many cases "
>
> I don't understand what he means. Someone with Eckel-like programming
> experience (ie. long and with many languages) do?
I know C++ and Java, which I know Bruce is well versed in. I don't
think one should compare C++ with Ruby. They're too different. While I
can't speak for Bruce I can understand when, coming from a Java
background, this:
query("show fields from #{table}").sort.each {|x| ret << x[0]}
is a bit much to swallow.
> My feeling is that there are quite a few experienced programmers coming to
> Ruby but I may be wrong. I doubt Matz have conssciously ripped off Python.
And even if he did, no big deal. Such is open source.
Emile
Sean Russell
> More like something that can be done with Ruby (true global variables)
> that cannot be done with Python. With Python, all "global" variables are
> module-specific. This is similar to class variables, except not (Ruby
> doesn't really have Python-style modules, what it has is, well,
> different).
>
> Basically, what this means is that other programmers are less likely to
> somehow tromp on important global data.
Ummm... then don't use global data. At worst, you'd be no worse off than
if you had used Python.
> I can't show you example, but can describe one. In last large Python
> program that I wrote, we had a 'dbaccess' class. This class encapsulated a
> generic possible record type in the database. This class was subclassed by
> individual classes for each record type in the database. Each record type
> instantiated class variables in its declaration for table name, field
> names (list), and field types (list). The initializer for the dbaccess
> class stuffed the field names into the instance of the end class as
> variables. Thus if I have a "Customer" table, with field names "Last",
> "First", "Middle", "CustNum", I could do something like
>
> l=Customer(5324) # get customer #5324
> print "Name =",l.Last,",",l.First," ",l.Middle
>
>
> And if I wanted to change his name, I could say something like
>
> l.Last="Ferguson" # she married
> l.Update() # and change it on disk.
>
> and voila. All this was handled automagically behind the scenes via
> self-referencing on the part of the base 'dbaccess' class.
I can think of several ways of doing this in Ruby. The easiest would be
the method_missing method:
class DBAccess
# Define update(), etc
# ...
# Remember, they used this in the PickAxe book to generate
# roman numerals
def method_missing( *mname )
# if the method name ends in "=", then this is a set
if mname[0][-1] == ?=
row_values[mname[0].chop] = mname[1]
# otherwise, get
else
row_values[mname[0]]
end
end
end
You wouldn't even have to subclass the class to make this work. It sounds
more elegant and space efficient than the Python solution, but maybe I'm
missing something.
> But you're not working on a large project with multiple programmers. A
> clear and *CONSISTENT* style is important in such cases. Whether you
> personally like that style or not is largely irrelevant. If the language
> largely enforces such a style, this makes the code in large projects much
> easier to read. I'll note that virtually every programmer eventually has
> to go into a module written by some other programmer and add new features
> and/or fix it. With Python, you guarantee that the coding style is
> reasonably consistent (e.g. every if statement looks like this:
There is a truth in what you say. Where you are mistaken is in assuming
that it is neccessary that the programming language to enforce this. We
(collectively, as a society) have been using C, C++, and Java in commercial
environments for years, and coding standards are a common, and not
difficult, way of solving this sort of problem, without the limitations
imposed by a language-enforced coding style.
The main difference is that, with Python, Guido V.R. is determining how all
of you are going to style your source. I'd rather have local control over
that sort of thing.
> Mostly lack of "true" global variables here. There is no common namespace
> for programmers to stomp around in. Thus variables end up getting either
I'm increasingly getting the feeling that there isn't much structure in
your work environment. Again, I'd rather have local control, than leave
that sort of thing up to the language designer. IMO, if things are that
chaotic at your shop and you're trying to work on large, diverse projects,
you're going to have bigger problems than just whether or not your source
code is readable.
>> > It is also portable to more architectures than Ruby, which is
>> > important for some large multi-platform applications.
I'd say this is more of a momentum thing. Give it another year or two, and
the gap will be so small you won't notice it. Granted, that doesn't help
you /now/...
> Uhm, and you've worked on how many large multi-programmer projects? I once
> worked on a project that had over 1,000,000 lines of code that had been
> written by a dozen programmers over a 10 year period. One programmer in
> particular irritated me to no end -- he did everything as if he were
> programming in COBOL. Fixing his programs (or, more usually, updating them
Hmmm. Well, given that there is no such thing as a 10 year-old Python
project, proving that Python is superior in this case would be rather
difficult. Bad code is bad code. That said, I'll agree that any given
Python source has a better chance of being legible to other Python
programmers that Ruby.
>> > would not, however, relish attempting to manage 100K+ lines of Ruby
>> > code for a project, while Python proved to be quite usable for 100K+
>> > lines of code.
>>
>> I don't agree with this but I haven't developed any 100K+ lines of Ruby
>> programs. Why will Ruby "break down"? My feeling has been quite the
>
> Note that I have not developed very large programs in Ruby either, I'm to
> a certain extent comparing it to what I've seen happen in very large
> Python, C++ or Java programs. Large Java programs are managable because of
Just out of curiosity, what is the largest *Python* codebase (for a single
application) that you've worked with?
> I'm not sure that I understand all my points myself :-). Some of this is
> just gut feel from close to 20 years of programming in everything from
> DBASE-II (how debased!) and PL/1 to Python, Java, and Ruby. My "gut feel"
OMG! Another DBASE-II veteran!
--- SER
Avdi B. Grimm
> meth_b = a.method(:b)
>
> meth_b.call() # => "b"
Ditto this. I'm surprised by how often this feature gets overlooked.
Taking Python's (current) lack of real closures (I.E. lambda's don't
bind to local variables inside the scope in which they are created),
there's simply no comparison between Python and Ruby's functional
programming capabilities.
> > 10. Reference counting works hand-in-hand with Python's destructors to handle
> > resource cleanups in a real-time manner that's difficult with Ruby (where you
> > can set up destructors of a sort but they only run at garbage collection
> > time, which may be some time later, in the meantime you still have some open
> > files and files on disk hanging around that are not getting cleaned up).
>
> Use the block paradigm instead. E.g.
>
> DBI.connect do | dbh |
> # do something with dbh
> end
>
> or
>
> File.open(fileName, "r") do | file |
> # ...
> end
>
> Using this there is no need for destructors.
I have to disagree with this statement. There *are* cases where the
block paradigm is simply not appropriate, and destructors are.
Sometimes it's possible to kludge in a solution using the block
paradigm; but it's not pretty. It's not a terribly rare occurance to
have objects which (a) /must/ release resources before being
garbage-collected, and (b) have non-determinate lifetimes.
~Avdi
Robert Feldt
FYI,
The Eckel comments are linked from
http://www.python.org/doc/Comparisons.html
with the summary
"Bruce Eckel doesn't think Ruby is worth learning. "
/Robert
Michael Neumann
> > Using this there is no need for destructors.
>
> I have to disagree with this statement. There *are* cases where the
> block paradigm is simply not appropriate, and destructors are.
> Sometimes it's possible to kludge in a solution using the block
> paradigm; but it's not pretty. It's not a terribly rare occurance to
> have objects which (a) /must/ release resources before being
> garbage-collected, and (b) have non-determinate lifetimes.
True. You cannot do everything with blocks.
In Ruby you have class ObjectSpace that lets you define finalizer
methods. This is not very nice, but it works.
David Alan Black
On Wed, 24 Oct 2001, Paul Brannan wrote:
> I also find myself reinventing the wheel in Ruby a lot, because some
> library doesn't exist for Ruby or it doesn't work the way I want it to.
s/re// # in the circumstances you're describing :-)
David
--
David Alan Black
home: dbl...@candle.superlink.net
work: blac...@shu.edu
Web: http://pirate.shu.edu/~blackdav
Neil Hodgson
> I have to disagree with this statement. There *are* cases where the
> block paradigm is simply not appropriate, and destructors are.
> Sometimes it's possible to kludge in a solution using the block
> paradigm; but it's not pretty. It's not a terribly rare occurance to
> have objects which (a) /must/ release resources before being
> garbage-collected, and (b) have non-determinate lifetimes.
Deterministic finalization (DF) is a great feature but the Jython
implementation of Python on the JVM does not provide this as it is hard to
implement over the Java based semantics of the JVM. Even if Jython were to
implement this for objects it is totally responsible for it needs to
interoperate with Java based code by, for example, returning pointers (or
wrappers) to these objects to Java code.
It is unlikely that Python for .NET will have deterministic finalization
for the same reason. The lack of DF in .NET has caused a lot of angst among
us old COM developers since COM is based on reference counting with DF. The
safe portable route is currently garbage collection as that is used in the
most widely used / soon-to-be-used VMs and can also be implemented for
self-contained implementations like Ruby and standard Python.
The difficulty in providing DF on the JVM and .NET is an example of how
these environments require changes to the languages hosted on them. I'm sure
there will be Ruby features (possibly closures) that can not be implemented
reasonably on these VMs.
Neil
Alan Chen
> On Wed, 24 Oct 2001, Michael Neumann wrote:
>
> > Use the block paradigm instead. E.g.
> >
> > DBI.connect do | dbh |
> > # do something with dbh
> > end
> >
> > or
>
> objects that get passed around? I think that would be a case where I
> case, imo, but still important to consider.
You mean like this?
class SaveABlock
def initialize(&block); @block = block; end
def useablock; @block.call 1; end
end
a = SaveABlock.new { |i| puts "i: #{i}" }
a.useablock => i: 1
> >
> > I'd hold against your last sentence, but I never tried it out.
> > But maybe 100K lines in Python are just 50K in Ruby ;-)
>
> The problem is not the number of lines itself, but that projects that
> large have certain needs, and Ruby makes it difficult to meet those needs.
> For example, using inheritance in Ruby on a team with many programmers may
> be difficult, because really is no such thing as private instance data in
> Ruby. Nifty funtions like send() and method() allow the user to call
> private/protected methods that they should not be allowed to call (at
> least, not by accident). Ruby lets you define a public method in a
> derived class that was private in the base class without so much as a
> warning, so you need to have full knowledge of the base class's *private*
> interface if you don't want to break something.
My impression is that you may be mistaking lack of maturity in Ruby
for lack of "large scale development" features. The developer
methodologies to cleanly interface modules in large scale projects
haven't had as much time to mature in Ruby as in Python. I think its
premature to make assesments of Ruby's suitablility for large-scale
programming. Many of the "large-scale" features mentioned previously
on this thread are really nice-to-have items not have-to-have.
All large scale development languages allow access to private data,
its a matter of how much pain you want to put the developer through if
they elect to access a non-public interface. FWIW, I suspect that it
would be easy to write a module to disable the send and method
functions in a class. (or provide a warning if you'd prefer)
For me ruby as a language shows exceptional clarity and elegance at
many different levels. For example, I think the ease of interfacing
ruby with C will result in the language aquiring library bindings much
faster than Python or Perl in their early stages of maturity. Ruby's
tradeoff between design purity and expedience is pretty much perfect
for me.
--
Alan Chen
President and Lead Developer
Digikata LLC
al...@digikata.com
http://digikata.com
Avdi B. Grimm
> Avdi B. Grimm wrote:
> > > Using this there is no need for destructors.
> >
> > I have to disagree with this statement. There *are* cases where the
> > block paradigm is simply not appropriate, and destructors are.
> > Sometimes it's possible to kludge in a solution using the block
> > paradigm; but it's not pretty. It's not a terribly rare occurance to
> > have objects which (a) /must/ release resources before being
> > garbage-collected, and (b) have non-determinate lifetimes.
>
> True. You cannot do everything with blocks.
> In Ruby you have class ObjectSpace that lets you define finalizer
> methods. This is not very nice, but it works.
I would go so far as to say it doesn't work at all, unless I completely
failed to understand it. Once the ObjectSpace-defined constructor kicks
in, the object is *already gone*. All the destructor gets is (IIRC) the
ID of the object. I haven't yet figured out how this can be used to
free resources that only the now-deceased object posessed the keys to.
Perhaps one has to maintain some sort of global ID/Resource map, and the
destructor has to look up the resources to free via the ID...? Pardon
me but, yeeeecchhhhh! That's just horrid.
~Avdi
Sean Russell
>> Perl is at the other end of the
>> spectrum, which is just as obnoxious. However, I'd choose Perl in all of
>> its obtuse obfuscation that Python's draconian dogma any day. I think
>> Ruby struck a decent balance.
>
> .. and this is where we disagree, a bit. Ruby certainly allows for
> very elegant coding. It also allows for job-security coding. Python
> makes that a lot harder.
Agreed, although I think I could still obfuscate Python if I tried. I
haven't met a programming language yet that could defeat me! ;-)
--- SER
Kero van Gelder
programers of a team, partialy due to the fact that the majority is
no programmer at all.
> That's not to say you can't enforce coding standards for other
> languages, but for Python it's been a clear decision to make it part
> of the language, and many people appearantly see a benefit to this.
>
> And you can't enforce a coding standard everywhere.
hehe :)
I don't abide the rules (of C coding guidelines), but they can not
punish me for it. I'm too valuable.
In the very same project, I've seen code adhering to the guidelines
that was so subtly wrong, that you need to read it several times to
realize there might be something wrong. That was code by one of the
qualified programmers, not written by the majority.
In a similar spirit of the coding guidelines, we threw programming
abstractions at the majority, which they could not understand and
hence abused. We can not blame the majority, but only ourselves.
I know much more about software engineering now, then I knew before
the project started.
Otoh, we had hired ppl that should know more about SE than I did. They
couldn't even program. Coding guidelines don't help in that case.
Coding guidelines are some way of managers to get control. It seems to
me, at least. But controlling software is so much more. I've read so
many code from starters (as student assistant) and kernel and other
open source projects, that I hardly care about coding
standards. Consistency and naming are more important than a required
description of the second parameter of some function.
it feels good to read some other document (sbout guidelines) of my
company that states as first or second clause that guidelines should
be applied with wisdom; The guidelines AND exceptions are allowed, as
long as there is a reason.
> Controlled
> corporate environments could maybe get away with it (although I'll
> leave you to convince our engineers to not tar-and-feather you for
> bringing up the concept), many an open source project would not be
> able to do so without losing contributers. People can get all hot and
> bothered when someone 'attacks' their coding style. At least you get
> to skip that discussion in Python projects.
mayhap.
Somehow, there are lots of funny Ruby conventions that get enforced by
matz optimizations as well. Most of those are really good. There have
been a few discussion about this, recently.
In C:
if( myfunc (param))
I mean, get real. as if ``if'' is a function and (param) is a boolean
expression. C'mon. ``If'' can be a function (in certain languages!), param
can be a boolean expression, but (param) is a (set of) parameters to
the function myfunc. There should not be a space there. Period. Or am
I being obnoxious here?
if (myfunc(param)) /* talking C here */
> And there's the issue: what's more clear to you could well be utterly
> unreadable to another.
That's a huge part of the problem in Software Engineering.
It's psychological, not mathematical.
> > Some but not many. Only C and VB though.
>
> I feel your pain.
At least I convinced my colleagues to use linux.
+--- Kero ------------------------------ ke...@chello.nl ---+
| Don't split your mentality without thinking twice |
| Proud like a God -- Guano Apes |
+--- M38c ------- http://members.chello.nl/~k.vangelder ---+
Joseph Benik
Nigel S.Ball
> On Tuesday 23 October 2001 13:25, you wrote:
> > Eric Lee Green wrote:
> > > 10. Reference counting works hand-in-hand with Python's destructors to
> > > handle resource cleanups in a real-time manner that's difficult with
> > > Ruby (where you can set up destructors of a sort but they only run at
> > > garbage collection time, which may be some time later, in the meantime
> > > you still have some open files and files on disk hanging around that
> > > are not getting cleaned up).
> >
> >
> > DBI.connect do | dbh |
> > # do something with dbh
> > end
>
> (hypothetical) example, I have a class which maintains some state
> information in a database. When an instance is destroyed, I want the
> corresponding state deleted out of the database. But I don't know
> beforehand when an instance is going to be destroyed, because I am one
> programmer on a team of 50 programmers working on this product. It is clear
> that a destructor is the most useful way of handling this situation.
>
Library: observer
The Observer pattern, also known as Publish/Subscribe, provides a simple
mechanism for one object to inform a set of interested third-party objects
when its state changes. In the Ruby implementation, the notifying class mixes
in the Observable module, which provides the methods for managing the
associated observer objects.
> > > Java. I would not, however, relish attempting to manage 100K+ lines of
> > > Ruby code for a project, while Python proved to be quite usable for
> > > 100K+ lines of code.
> >
> > I'd hold against your last sentence, but I never tried it out.
> > But maybe 100K lines in Python are just 50K in Ruby ;-)
>
> Destructors are just another one of those features of Python which are
> oriented towards making 100K+ line programs with multiple programmers
> managable in Python. I like Ruby for one-programmer projects, but I just
> can't see how it could scale well to multi-programmer multi-100K-line
> projects. I've used Python in such large projects and it works quite well.
> The compartmented namespace in particular was extremely useful for
> partitioning tasks between programmers -- I could give them total freedom
> over how they were to implement their part of the program without worry
> about whether they'd tromp over one of my global configuration variables or
> etc.
>
> Finally, regarding verboseness of Python vs. Ruby, I haven't noticed any
> real difference there. Both are fairly terse. There is at most a few
> percent advantage to Ruby here, mostly because the backtick syntax and
> regular expresson syntax is tighter. There just isn't anything compelling
> about the verboseness issue that would make a Python programmer switch to
> Ruby. Other issues (such as, e.g., the 1-1 mapping between many Ruby and
> Java features, which makes prototyping Java programs in Ruby quite easy)
> are probably more important here.
--
Nigel S. Ball
Enesbe Sales Pty Ltd
Ph: 61 3 9909-7970
Fx: 61 3 9909-7971
Mob: 0417 341 300
Yukihiro Matsumoto
on 01/10/24, Sean Russell <s...@germane-software.com> writes:
|> 10. Reference counting works hand-in-hand with Python's destructors to
|> handle resource cleanups in a real-time manner that's difficult with Ruby
|
|This (and 9) would be easily solved by a mechanism to force the garbage
|collector to run; if Ruby doesn't have one, it should.
GC.start
Vivek Nallur
us who do.
Vivek
--
On Wed, 24 Oct 2001, Rich Kilmer wrote:
> Ouch!
>
> http://www.mindview.net/Etc/FAQ.html#Ruby
>
> Thoughts?
>
> -Rich
>
Emiliano
> > Basically, what this means is that other programmers are less likely to
> > somehow tromp on important global data.
>
> Ummm... then don't use global data. At worst, you'd be no worse off than
> if you had used Python.
You might not use it, but your i-know-better neighbour will.
> The main difference is that, with Python, Guido V.R. is determining how all
> of you are going to style your source. I'd rather have local control over
> that sort of thing.
While I agree with you, I have to ask: why? I feel the same way yet I
can't shake the feeling we're being childish for holding on to
something as insignificant to a particular coding style while we both
acknowledge that coding standards are good.
> I'm increasingly getting the feeling that there isn't much structure in
> your work environment.
On an individual level, that's what you're going to see. Unless you
work at NASA, maybe.
> Again, I'd rather have local control, than leave
> that sort of thing up to the language designer.
Which leaves you to police such matters.
> IMO, if things are that
> chaotic at your shop and you're trying to work on large, diverse projects,
> you're going to have bigger problems than just whether or not your source
> code is readable.
I don't think that was the point. His work environment may or may not
be as chaotic as you describe. The way I read his statements is that
in large projects, you need coding standards anyhow, in which case
it makes very little difference if you enforce them by policy or by
your compiler. I don't particularly like the coding standards I have
to use at work now, and still I have to use them. Same difference who
does the policing.
> Hmmm. Well, given that there is no such thing as a 10 year-old Python
> project, proving that Python is superior in this case would be rather
> difficult. Bad code is bad code. That said, I'll agree that any given
> Python source has a better chance of being legible to other Python
> programmers that Ruby.
Which was exactly his point I think.
Emile
Emiliano
> All large scale development languages allow access to private data,
> its a matter of how much pain you want to put the developer through if
> they elect to access a non-public interface. FWIW, I suspect that it
> would be easy to write a module to disable the send and method
> functions in a class. (or provide a warning if you'd prefer)
But it still wouldn't be the default behaviour. Having class-private
data available publicly by default isn't correct in my book. You have
to choose what to make part of your public interface. IMO, of course.
Emile
Martin Kahlert
>
> Ruby, on the other hand, is a much better scripting language (as vs.
> general-purpose programming language) than Python. It is much easier to chain
> pieces together, especially for distributed applications.
I would second this. I once took a quick look and tried Python (1.5) for
some small scripts. I found its syntax to be too C-ish for me, although i
liked the intendation idea.
I had the impression, that Python was like an interpreted C.
(I used no OO for these small scripts these days)
Ruby is more of the 'o.k. let's hack together a solution fast'-language and
i like the yield construction. Thus in my opinion Ruby feels more scriptish
than Python.
These are only opinions from a Ruby beginner though.
Regards
Martin.
--
assumption: electronic devices only work if the smoke stays inside.
proof : when smoke comes out they don't work anymore
David Simmons
"Robert Feldt" <fe...@ce.chalmers.se> wrote in message
news:Pine.GSO.4.21.011023...@ros.ce.chalmers.se...
> On Wed, 24 Oct 2001, Rich Kilmer wrote:
>
> >
> Not in the sense below.
>
> > I realize it does not in the sense that overriding a method on class
> > Array will effect the entire interpreter, but in the sense that it
> > partitions symbols (variables, classes, modules, etc).
> >
> > Are you speeking here of an ability to actually change Array, but have
> > that change only be available to the originating "namespace" and classes
> > (or modules) defined within a "namespace" are only visible to that
> > "namespace"?
> >
> Yes, its a "namespace" in a different sense. From my understanding
> Smallscript/AOS and recent Smalltalks have this latter thing. And it
> seemed to have evolved because people were having problems with this. But
> I'm not sure of this.
>
> A sort-of scaled up Ruby/Behaviors à la David Black?!
Background: The namespace concepts being discussed here regarding Smalltalk
were principally my work over the last ten years or so with QKS Smalltalk
and subsequently with the SmallScript language.
Modules and Namespaces are different concepts that often overlap because
both are units of organization. In many languages these concepts are not
distinguished and that ultimately leads to problems and unnecessary
complexity.
---
A module is a unit of deployment and packaging (distribution units). They
may also be thought of as a unit of "ownership".
A namespace is a unit of lexical binding/scoping. They should also be
thought of as a unit of "priviledge/permission".
A module may contain code that extends or changes the contents of one or
more namespaces. Two or more modules may extend or change the contents of
the same namespace within a given program. Modules may reference or depend
on other modules and have a variety of prequisite/versioning issues. Modules
are best thought of as generic self describing/reflective repositories of
"things" which include code. Modules may be combined into a deployment unit
that in Microsoft.NET terms is called an assembly, but which I have
generally viewed (prior to .NET) as a rich COFF/ELF/PE/etc file. Similar to
the form a Macintosh executable takes with its resource fork.
It may help to think of modules as being a first-class language
manifestation of projects within a classic IDE.
-----
I can illustrate the problem being solved as follows:
a) Assume person A has writen some class Foo. (It might help to think of
person A as the language vendor/provider/implementor).
b) Person B decides they want to use class Foo in their project.
c) Person C comes along an really likes Foo and wants to add some new
features to it rather than subclassing it. Why? Because from an OO design
viewpoint it makes more sense to extend the classes behavior than to rewrite
the module that class Foo came in. Also, looking to worlds like
Microsoft.NET, they may not have the source to assembly/module to make such
changes.
d) Person B also recognizes that it would be useful to extend Foo and make a
number of modifications.
-----
At this point we have a lot of potential problems that using
"selector/message-namespaces" [which I invented for dynamic languages] will
readily and safely solve.
Here are just a few of the obvious problems that are possible:
1) Person A adds new behavior to Foo which conflicts with work done by
person B or person C.
2) Person C decides they want to use person B's code within their program,
but the changes/extensions to Foo conflict. Or vice versa for person B using
person C's code.
-----
What we would like is a way to dynamically add "partitioned" behavior
(methods) to classes (or individual objects) that already exist and are
defined by someone else.
I.e., You gave me a "Foo", we all agree it is the same class. But, I would
like to have Foo objects within my project/code do things differently than
they might in your code. And, I want my code and your code to be able to
coexist in the same running program/scriptlet/applet.
So the example posted a few messages back where an inner-class was created
that "refined" a more general class will not work. We need the behavior to
be partitioned safely, and we need it work on all instances of the original
class.
-----
To solve our problem with modules and namespaces:
1) Person A defines moduleA which acts as both a class and namespace. They
then create class Foo inside it.
2) Person B defines moduleB which acts as both a class and a namespace. They
then create their modifications packaging them in moduleB and scoping their
Foo changes to moduleB.
3) Person C defines moduleC which acts as both a class and a namespace. They
then create their modifications packaging them in moduleC and scoping their
Foo changes to moduleC.
At this point everybodies work is segregated but also has the virtue they
can all be loaded at the same time within the same program.
ModuleB will depend on ModuleA.
ModuleC will depend on ModuleA.
When moduleB loads it will augment Foo. But since all the modifications are
"scoped" to moduleB they will not be visible to any code which does not have
access to moduleB as a namespace.
When moduleC loads it will augment Foo. But since all the modifications are
"scoped" to moduleC they will not be visible to any code which does not have
access to moduleC as a namespace.
So for code which does not have access to moduleB or moduleC, but which does
have access to moduleA the Foo class will look and behave as person A
intended.
For code that has access to moduleB the changes in moduleB will all be
accessible and will take affect accordingly.
For code that has access to moduleC the changes in moduleC will all be
accessible and will take affect accordingly.
For code that has access to both moduleB and moduleC, the order of importing
will determine which module's changes take precedence over the other.
However, the general component design scenario is that the changes made to
Foo will be private to the implementation of componentized/modularized
services that moduleB exposes.
Module name: A
{
Class name: Foo.
}
----
Module name: B
imports: A
default-scope: B
{
Class ref-name: Foo
{
Method [
myPrivateX
...
]
}
Function [
someCode(aFoo)
aFoo.myPrivateX /* invokes the #B.myPrivateX version */
]
}
----
Module name: C
imports: A
default-scope: C
{
Class ref-name: Foo
{
Method [
myPrivateX
...
]
}
Function [
someCode(aFoo)
aFoo.myPrivateX /* invokes the #C.myPrivateX version */
]
}
P.S., all the braces "{" and module declarations are actually optional if
these modules were defined in separate files. I just added them for clarity
in writing the code here.
I.e.,
"" Person C could have written their code as
Module name: C imports: A.
Method class: Foo scope: C [myPrivateX ...].
Function [someCode(aFoo) aFoo.myPrivateX ...].
-- Dave S. [www.smallscript.org]
>
> Regards,
>
> Robert
David Simmons
news:Pine.GSO.4.21.011023...@ros.ce.chalmers.se...
> On Wed, 24 Oct 2001, Rich Kilmer wrote:
>
> > Question: Don't modules give you a namespace capability?
> >
> Not in the sense below.
>
> > I realize it does not in the sense that overriding a method on class
> > Array will effect the entire interpreter, but in the sense that it
> > partitions symbols (variables, classes, modules, etc).
> >
> > Are you speeking here of an ability to actually change Array, but have
> > that change only be available to the originating "namespace" and classes
> > (or modules) defined within a "namespace" are only visible to that
> > "namespace"?
> >
> Yes, its a "namespace" in a different sense. From my understanding
> Smallscript/AOS and recent Smalltalks have this latter thing. And it
> seemed to have evolved because people were having problems with this. But
> I'm not sure of this.
>
> A sort-of scaled up Ruby/Behaviors à la David Black?!
-----------------
From Dave Simmons
-----------------
Rich Kilmer
In the following I am not trying to be anti-Python...just trying to set the record straight...
Regarding "private" class variables.
So...in Python you can use this:
obj.__dict__['attrName']=value
..to get direct access to (get/set) the values of every attribute on an object.
In Ruby every object attribute is private and can only be accessed through a method...period. Exposing the __dict__ "bag" on an object exposes the entire state of that object for public consumption.
Ruby and Python can both be easily "subverted" by default (Ruby through "instance_eval" and "send"), but in Ruby you can explicitly block your class/object from being effected by overriding those methods. The same is NOT true for Python. It provides "privacy" through obfuscation (name mangling) but its still easy to get around (because everything is still held in the __dict__).
>From the Python tutorial:
"Name mangling is intended to give classes an easy way to define ``private'' instance variables and methods, without having to worry about instance variables defined by derived classes, or mucking with instance variables by code outside the class. Note that the mangling rules are designed mostly to avoid accidents; it still is possible for a determined soul to access or modify a variable that is considered private. This can even be useful, e.g. for the debugger, and that's one reason why this loophole is not closed. "
OK...that's the end of my Python rant :-)
-Rich
Piers Cawley
> 9. Reference counting (Python) is more memory-efficient than garbage
> collection (Ruby), since it frees up memory as references are
> destroyed rather than waiting until a garbage collector runs.
> Python does need a garbage collector to collect circularly-
> referenced objects though, so Python's lack of garbage collection
> overhead has to be offset by the fact that circular references
> currently hang around forever.
You should also offset it by the fact that non reference counting
garbage collection is more computationally efficient than reference
counting, which requires housekeeping every time a reference is
created, and at the end of every scope. Short lived variables are
especially annoying. Over in Perl 6 land, Dan Sugalski is currently
reasonably confident that he's got a garbage collection scheme that
will allow for computation efficiency for most things, combined with
immediate destruction/resource cleanup for things that need it. Which
sounds too good to be true, but Dan is a clever man; if he gets this
working in Parrot I can see a lot of other people pinching it...
--
Piers
Piers Cawley
> On Tue, 2001-10-23 at 16:25, Michael Neumann wrote:
>> meth_b = a.method(:b)
>>
>> meth_b.call() # => "b"
>
> Ditto this. I'm surprised by how often this feature gets overlooked.
> Taking Python's (current) lack of real closures (I.E. lambda's don't
> bind to local variables inside the scope in which they are created),
Python *still* doesn't have real closures? Coo. One more reason for
this boy not switching yet.
> there's simply no comparison between Python and Ruby's functional
> programming capabilities.
Okay, so I've not started to seriously code in Ruby, but Ruby's
functional capabilities are what really get me excited about the
language. (And they're what Larry's busy stealing for Perl 6...)
--
Piers
Piers Cawley
> Sean Russell wrote:
>
>> > Yes, to enforce a certain coding format. I'm no great fan of
>> > python myself, but one of the downsides (for me) of Perl & Ruby
>> > is the utterly
>>
>> There is always a balance between maintainability and productivity.
>> I still believe that the source of Pascal's failure was the
>> obnoxious rigidity. Python drops the rigid typing, but keeps rigid
>> syntax, which is the my main pet peeve about Python.
>
> This is where we agree...
>
>> Perl is at the other end of the spectrum, which is just as
>> obnoxious. However, I'd choose Perl in all of its obtuse
>> obscifuscation that Python's draconian dogma any day. I think Ruby
>> struck a decent balance.
>
> ... and this is where we disagree, a bit. Ruby certainly allows for
> very elegant coding. It also allows for job-security coding. Python
> makes that a lot harder.
As does Perl. As does almost any programming language you care to
name. And if you aren't practicing Code Review on your large projects
then you deserve all the job security code you get.
--
Piers
Stephan Kämper
>
> Apart from my dislike of Python syntax, I'd have no trouble accepting
> maintenance of 100K+ lines of Ruby code, assuming the code was written by
> someone sane; I'd prefer this to taking on, say, 100K+ lines of C code, or
> even Java code. Ruby is so orthogonally OO that I can't imagine that it
> wouldn't be noticeable on a large scale.
>
I'd like to know how large the large projects are in Ruby (in LOC or
whatever measure).
Almost certainly shorter than (functionally) comparable projects in C, C++,
Java I'd guess...
Stephan
David Simmons
namespace segregation work using interfaces. That would make it a bit more
convenient for switching behavior on/off dynamically [in the same vein as
David Black's system demonstrated for Ruby at the Ruby conference].
As in:
Interface name: C.FooCMixin [
Method scope: C [myPrivateX ...].
]
OR for those non-smalltalkers who prefer braces
as per other languages (we can also write):
Interface name: C.FooCMixin {
Method scope: C {myPrivateX ...}.
}
Then anytime we want it turned on/off for clients of the C namespace we can
say:
Foo.addInterface(FooCMixin) "OR" Foo.removeInterface(FooCMixin)
"" For Smalltalkers that would be written identically in SmallScript as:
Foo addInterface: FooCMixin "OR" Foo removeInterface: FooCMixin
The performance cost for adding/removing an interface is minimal. But it
will force some aspect of the VM caches to be flushed so that binding
lookups will make use of the new information. I should also mention that [as
per the instance specific behavior features] interfaces can be added/removed
on individual objects (not just classes of objects).
---
Whether the interface mixin approach is used or not, the scoped methods will
still only be accessible for code with permission/access to the C namespace
defined by module C.
-- Dave S. [www.smallscript.org]
"David Simmons" <pul...@s-bit.net> wrote in message
news:nvLhJdFX...@minos.QKS.COM...
>
> "Robert Feldt" <fe...@ce.chalmers.se> wrote in message
> news:Pine.GSO.4.21.011023...@ros.ce.chalmers.se...
> > On Wed, 24 Oct 2001, Rich Kilmer wrote:
> >
> > > Question: Don't modules give you a namespace capability?
> > >
> > Not in the sense below.
> >
> > > I realize it does not in the sense that overriding a method on class
> > > Array will effect the entire interpreter, but in the sense that it
> > > partitions symbols (variables, classes, modules, etc).
> > >
> > > Are you speeking here of an ability to actually change Array, but have
> > > that change only be available to the originating "namespace" and
classes
> > > (or modules) defined within a "namespace" are only visible to that
> > > "namespace"?
> > >
>
> > Yes, its a "namespace" in a different sense. From my understanding
> > Smallscript/AOS and recent Smalltalks have this latter thing. And it
> > seemed to have evolved because people were having problems with this.
But
> > I'm not sure of this.
> >
> > A sort-of scaled up Ruby/Behaviors à la David Black?!
>
Bill Kelly
From: "Eric Lee Green" <er...@badtux.org>
>
[...]
> Uhm, and you've worked on how many large multi-programmer projects? I once
> worked on a project that had over 1,000,000 lines of code that had been
> written by a dozen programmers over a 10 year period. One programmer in
> particular irritated me to no end -- he did everything as if he were
> cope with new changes to accounting rules) was an exercise in decrypting
> COBOL syntax written with "C" preprocessor macros. Tasks that should have
> taken me minutes took hours instead. The point is that a clear, regular
> syntax eases the task of future maintenance. Python has been criticized as
> having a rigid and inflexible syntax, and to a certain extent that is true.
> But for very large projects, that's a virtue.
self.I've self.worked self.on self.more self.Python self.programs
self.than self.Ruby self.__ahem__.__er__.__pardon__.__me__ than
Ruby programs at this point.
And I agree that the lack of "namespaces" and global consequences
for extending/changing the behavior of some class in Ruby seem
daunting, especially for a non-pair-programmed non-test-first-
designed non-collective-code-ownership based project written by
a bunch of unrepentant ex-COBOL programmers working in separate
offices and communicating via the occasional email.
Hahah haah haha ahhaa hah ha yeah, I've on a couple occasions
had to fix bugs in and extend code like that too. :-)
But I refuse to let programmers like that influence my choice
in languages (maybe I'm just stubborn.) So, which language
might you consider for large projects if you knew everybody
involved was writing good code and was actually willing to
_learn_ the language? I know the Smalltalk folk have somehow
learned to manage cascading effects or clashes from extending
functionality in base classes (though from what I've read
they've learned to be careful/cautious about doing so, too?)
But the Smalltalk existence proof makes me less nervous about
Ruby's capabilities somehow [on a large project] - at least
with the stipulated good-programmers-working-on-it clause from
above in effect.
. . . I guess my point is, in thinking about it and trying to
figure it out myself :), is that it seems you've made a case
yourself for the language having little effect on someone
who is deliberately (or ignorantly) out to abuse it. At least,
for me, if I were to translate the bad 'C' code I've been
subjected to into Python, it wouldn't really help a bit!
Because I have/had no trouble 'tall parsing the 'C' language
statements these people were writing (had written). It's
just the larger context was one big horrific mess: what the
program was doing and how it was doing it.
Hmm, I was going to say, "... so it (the bad code) may as
well be in Ruby, or even Perl...", but, I've more Perl
experience than either Python or Ruby, and I'm not sure I'm
brave enough to make *that* assertion. ;-) Okay, so maybe
the 'abusability' of the syntax does matter somewhat where
bad-ol'-programmers are concerned (or bad new programmers -
not targeting age here;) . . . uh . . . still, with the
good-programmers-on-the-project deal stipulated above, I
don't think I can fathom any reason for choosing Python
*just* because of it's syntax.
Okay, . . . hope this made some sense, anyway. :)
Bill
Clemens Hintze
thanks for the fair statements you have made. I agree with many of
your points. But some not. Let me state that I was also coming from
Perl to Python, and some time (years) thereafter to Ruby. My main
reason was, that there were many points I would like Python to
improve, like others too. But much of them were dismissed by GvR or
moved to a mystical Python 2000 at that time.
When I detected Ruby (ironically lead by a Pythoner congratulate matz
for his nice language in c.l.python ;-) I have found all the nice
stuff, I would like to see in Python ... and more. So I was switching
at once to Ruby and have never regret it. Although, now I can see that
Python will get some of the nicer features I would liked to have seen
some years before :-(
Syntax is not a much hindrance for me, if language features are worth
a try. I like the syntax of Smalltalk, Ruby, Python, Forth and Lisp.
Heck! I even have programmed in Perl ;-)
Ideally I would like Ruby have some of the syntax of Python --
especially the fine block indentation syntax. But hey, its okay for me
that matz do not like it and so decide not to teach it to Ruby. Ruby
is still worth to work with, despite this 'lack' of syntax ;-)
Eric Lee Green wrote:
(...)
> 1. Python's namespace conventions (i.e., no "global" global variables, only
> module-global variables) make it easier to partition a large project amongst
> various programmers, especially projects that require configuration variables
> of some sort (which are "global""), where you can divide them amongst several
> programmers/several modules without worrying about conflicts.
In Ruby you can do the same thing except that explicit global
variables remain global, whereas Python does not offer global
variables. I am more a fan of freedom to do or to no do something. If
I want to mess around with global variables ... let me :-)
But I understand your point. Although I think, there is no way
(concerning the language) to hinder a fool to do some weired stuff in
whatever language he is using right now ... even in Python.
> 4. I like being able to pass around a method in Python. This makes many
> things much easier.
Others will have, for sure, pointed you to Object#method?
> 5. Multiple inheritance is good in Python.
Okay, but its lack is not bad in Ruby, IMHO. At least since all the
time I used Ruby I had not *one* opportunity where I ought to use MI.
SI was enough most of time and often modules were a cleaner choice.
But as I've said: I like freedom to decide to use MI or not. So ideal
would be a Ruby that supports MI, and if only to let me decide *not*
to use it ;-)
> 6. I like the 'module' concept in Ruby, which works around many of the
> problems with multiple inheritence, but not enough to consider it a full
> replacement for multiple inheritance.
:-/ I had never a problem with: only able to use modules but need more
than that, needs MI :-/
> 9. Reference counting (Python) is more memory-efficient than garbage
> collection (Ruby), since it frees up memory as references are destroyed
> rather than waiting until a garbage collector runs. Python does need a
> garbage collector to collect circularly-referenced objects though, so
> Python's lack of garbage collection overhead has to be offset by the fact
> that circular references currently hang around forever.
I second that. But I think it is also true, that often RC will have
more performance penalty as it has to adjust the refcount every time
an assignment will take place. Whereas Rubys GC will have that penalty
if GC actually takes places. And you can decide, when GC should take
place.
But I see your point and I think it is not wrong. There are different
strategies and I like true GC more than RC. But that's me :-)
> 10. Reference counting works hand-in-hand with Python's destructors to handle
> resource cleanups in a real-time manner that's difficult with Ruby (where you
> can set up destructors of a sort but they only run at garbage collection
> time, which may be some time later, in the meantime you still have some open
> files and files on disk hanging around that are not getting cleaned up).
That is true and this I find especially disturbing in Ruby then and
when! But I like true GC more than I hate this 'lack' of feature. So I
will not complain to loud here ;-)
On the other hand ... if I only free resources by accident -- cause no
one refer to it any longer -- it may also stay around for too long
time, if it is still held somewhere else. So only relying on freeing
of resource if nobody use it anymore, is also a bit, ehrm, unclean(?)!
> 12. Python is no speed demon, but is faster than Ruby for the things I do.
And for things I do, it is often vice versa ;-)
> 13. Python has a nice GUI-based debugger, which makes many things easier.
Yes, but Emacs and GUD are a good replacement.
> Final conclusions: I must agree with Bruce Eckel that I could not recommend
> that a Python programmer move to Ruby except in very special circumstances,
> because the two languages are so similar that there's no real advantage to
> doing so. In my case I'm using Ruby because I needed to prototype a
Ha ha ... to late, I already done so! ;-)
> My preliminary conclusion is that Python is a superior language for large
> projects. It is virtually impossible to make a difficult-to-read Python
> program due to its indentation-based syntax, the namespace partitioning makes
> large projects easier to partition amongst multiple programmers or multiple
> programming groups, and there is a large number of enterprise-oriented
> libraries for access to various proprietary and non-proprietary external
> systems. It is also portable to more architectures than Ruby, which is
> important for some large multi-platform applications. Python's syntax is also
> more regular and consistent than Ruby's, which again is important for large
> multi-programmer projects.
I half agree with your objections stated in that last part, and half I
do not agree. But I have to admit, I did not a real multiprogrammer
large project. But I do agree that Python make it difficult to write
read-only programs. But I've told you, I still like to have freedom to
chose to write difficult to read programs althoug I would trying not
to do so ;-)
> Ruby, on the other hand, is a much better scripting language (as vs.
> general-purpose programming language) than Python. It is much easier to chain
> pieces together, especially for distributed applications. It also makes a
> superior language for prototyping Java applications, since many aspects
> (iterators, rinda, single inheritance only, etc.) are similar to Java. I
> would not, however, relish attempting to manage 100K+ lines of Ruby code for
> a project, while Python proved to be quite usable for 100K+ lines of code.
Okay, here I do not agree with you. Although never done, I still very
believe I can do a large scaled Ruby project without difficulties.
Ruby is not self-enforcing to be readable, but it still is also not
self-enforcing to be unreadable. So it is a matter of discipline, I
feel.
And programmers need to have discipline. Especially if they work
together. If there is no discipline, a clean and nice language like
Python will not help the project either. The project is doomed to fail
then, I suppose!
But again let me thank you for you fair and valueable comments on that
thread. It was a joy to read them.
Ciao,
\cle.
Emiliano
> > But it still wouldn't be the default behaviour. Having class-private
> > data available publicly by default isn't correct in my book. You have
> > to choose what to make part of your public interface. IMO, of course.
>
> In the following I am not trying to be anti-Python...just trying to set the record straight...
>
> Regarding "private" class variables.
>
> So...in Python you can use this:
>
> obj.__dict__['attrName']=value
>
> ...to get direct access to (get/set) the values of every attribute on an object.
But reading this it is immediately clear to me you are violating the
'contract' the class provides.
> In Ruby every object attribute is private and can only be accessed
> through a method...period. Exposing the __dict__ "bag" on an object
> exposes the entire state of that object for public consumption.
Than I was mistaken in my believe that every attribute was publicly
accessible.
Emile
Rich Kilmer
> -----Original Message-----
> From: Emiliano [mailto:em...@iris-advies.com]
> Sent: Wednesday, October 24, 2001 4:17 AM
> To: ruby-talk ML
> Subject: [ruby-talk:23155] Re: Bruce Eckel's opinion of Ruby
>
>
> Rich Kilmer wrote:
>
> > > But it still wouldn't be the default behaviour. Having class-private
> > > data available publicly by default isn't correct in my book. You have
> > > to choose what to make part of your public interface. IMO, of course.
> >
> > In the following I am not trying to be anti-Python...just
> trying to set the record straight...
> >
> > Regarding "private" class variables.
> >
> > So...in Python you can use this:
> >
> > obj.__dict__['attrName']=value
> >
> > ...to get direct access to (get/set) the values of every
> attribute on an object.
>
> But reading this it is immediately clear to me you are violating the
> 'contract' the class provides.
And in Ruby:
obj.instance_eval("@attrName=value")
Would also be immediately clear :-)
Emiliano
> > That's not to say you can't enforce coding standards for other
> > languages, but for Python it's been a clear decision to make it part
> > of the language, and many people appearantly see a benefit to this.
> >
> > And you can't enforce a coding standard everywhere.
>
> hehe :)
> I don't abide the rules (of C coding guidelines), but they can not
> punish me for it. I'm too valuable.
IOW, a prime candidate for Python :)
> In the very same project, I've seen code adhering to the guidelines
> that was so subtly wrong, that you need to read it several times to
> realize there might be something wrong. That was code by one of the
> qualified programmers, not written by the majority.
Coding guidelines are no guarantee for code correctness. It's an aid
in readability.
> Coding guidelines are some way of managers to get control.
Nonsense. The managers won't care in the least. The poor bastard that
has to maintain other peoples code will.
> It seems to
> me, at least. But controlling software is so much more. I've read so
> many code from starters (as student assistant) and kernel and other
> open source projects, that I hardly care about coding
> standards. Consistency and naming are more important than a required
> description of the second parameter of some function.
They're not _alternatives_, they're _complimentary_.
> Somehow, there are lots of funny Ruby conventions that get enforced by
> matz optimizations as well. Most of those are really good. There have
> been a few discussion about this, recently.
>
> In C:
> if( myfunc (param))
>
> I mean, get real. as if ``if'' is a function and (param) is a boolean
> expression. C'mon. ``If'' can be a function (in certain languages!), param
> can be a boolean expression, but (param) is a (set of) parameters to
> the function myfunc. There should not be a space there. Period. Or am
> I being obnoxious here?
Not in my eyes, but the same will probably be argued by Python
enthousiasts.
> > And there's the issue: what's more clear to you could well be utterly
> > unreadable to another.
>
> That's a huge part of the problem in Software Engineering.
> It's psychological, not mathematical.
I don't understand this point. Coding standards aren't mathematical
either.
Emile
Rich Kilmer
> From: David Simmons [mailto:pul...@qks.com]
> Sent: Wednesday, October 24, 2001 3:09 AM
> To: ruby-talk ML; undisclosed-recipients:
> Subject: [ruby-talk:23145] Re: Bruce Eckel's opinion of Ruby
> [SmallScript/AOS Selector Namespaces]
>
> [deleted David's incredibly cool explanation]
>
so...in Ruby it could be explained as:
module A
class Foo
def bar
"The bar is for drinking"
end
def bar2
"More drinking!"
end
end
end
module B
include A
class Foo
def bar
"The bar is for beer nuts"
end
end
end
module C
include A
class Foo
def bar
"The bar is for picking up da' ladies"
end
end
end
#Now, if you enter the namespace of B
include B
#and build a Foo
f = Foo.new
print f.bar # => "The bar is for beer nuts"
print f.bar2 # => Exception...no method found
^--This does not work today!
TODAY: In the namespace identified by module B, f.bar2 does not exist because in B when you define class Foo you are not just replacing the module A Foo class method "bar", but creating a whole new class Foo in B.
TOMORROW: With David's selector namespaces, when in the scope of module B your definition of class Foo would modify Foo (from module A) in the context of module B, and module C would modify Foo (from module A) in the context of C and "bar2" would exist in all (three) namespace instances of Foo, but each would have a different "bar" method.
Whew!
Is that right David?
-Rich
Carlom
After reading his essay, Comparing Python to Other Languages at
http://www.python.org/doc/essays/comparisons.html
I am verry intrested in what he has to say. Where can I find his thoughts?
Carl
Bill Kelly
> MRD's and functional specs! (For one thing, when marketing wants "one more
> feature", it makes it that much easier to tell them "No, we've done
> everything on our MRD and functional spec, put it on the wish list for
> version 1.1").
We're finding it fun to tell them they can have whatever they want,
but they have to tell us what to work on [to completion] in the next
two weeks, every two weeks.
Bill
Tobias Reif
Ruby certainly allows for
> very elegant coding. It also allows for job-security coding.
What's "job-security coding"?
Tobi
--
Tobias Reif
http://www.pinkjuice.com/myDigitalProfile.xhtml
go_to('www.ruby-lang.org').get(ruby).play.create.have_fun
http://www.pinkjuice.com/ruby/
Robert Feldt
I can't compare to other languages but the ones of my projects I consider
"large" are in the 5K-10K LOC (comments included but I try to use Beck-
style intention revealing method names instead of extensive code comments
=> not much comments) range.
I'm sure there are much larger Ruby projects out there.
/Robert
Rich Kilmer
> -----Original Message-----
> From: Tobias Reif [mailto:tobia...@pinkjuice.com]
> Sent: Wednesday, October 24, 2001 4:52 AM
> To: ruby-talk ML
> Subject: [ruby-talk:23160] Re: Bruce Eckel's opinion of Ruby
>
>
> Emiliano wrote:
>
> Ruby certainly allows for
> > very elegant coding. It also allows for job-security coding.
>
>
> What's "job-security coding"?
Writing code in such a way that you are the only person on the planet who can support it (because nobody else can figure it out), thus ensuring you will always have a job...or..."job security".
-Rich
Christian Boos
Tobias Reif wrote:
> Emiliano wrote:
>
> Ruby certainly allows for
> > very elegant coding. It also allows for job-security coding.
>
> What's "job-security coding"?
It means that you write your code in such a way that you are the only
person that could
possibly read and maintain it, therefore securing your job ...
I've never heard that expression before, but it was so self-explaining
for me that
I shamely suspect I've practiced it at times :)
-- CB
Hal E. Fulton
From: Tobias Reif <tobia...@pinkjuice.com>
To: ruby-talk ML <ruby...@ruby-lang.org>
Sent: Wednesday, October 24, 2001 3:52 AM
Subject: [ruby-talk:23160] Re: Bruce Eckel's opinion of Ruby
> Emiliano wrote:
>
> Ruby certainly allows for
> > very elegant coding. It also allows for job-security coding.
>
>
> What's "job-security coding"?
>
Ha. That's code that is so obscure that
the company can't fire the person who
wrote it...
Hal
Michael Neumann
> On Tue, 2001-10-23 at 19:27, Michael Neumann wrote:
> > Avdi B. Grimm wrote:
> > > > Using this there is no need for destructors.
> > >
> > > I have to disagree with this statement. There *are* cases where the
> > > block paradigm is simply not appropriate, and destructors are.
> > > Sometimes it's possible to kludge in a solution using the block
> > > paradigm; but it's not pretty. It's not a terribly rare occurance to
> > > have objects which (a) /must/ release resources before being
> > > garbage-collected, and (b) have non-determinate lifetimes.
> >
> > True. You cannot do everything with blocks.
> > In Ruby you have class ObjectSpace that lets you define finalizer
> > methods. This is not very nice, but it works.
>
> I would go so far as to say it doesn't work at all, unless I completely
> failed to understand it. Once the ObjectSpace-defined constructor kicks
> in, the object is *already gone*. All the destructor gets is (IIRC) the
> ID of the object. I haven't yet figured out how this can be used to
> free resources that only the now-deceased object posessed the keys to.
> Perhaps one has to maintain some sort of global ID/Resource map, and the
> destructor has to look up the resources to free via the ID...? Pardon
> me but, yeeeecchhhhh! That's just horrid.
It is usable. Imagine you build a layer around a very low-level database
interface (e.g. ODBC or ISO/CLI). They work with handles (integers).
Now you want to call e.g. SQL_FreeHandle when an object of class
StatementHandle is garbage collected. All you have to do is to fill
a Hash-table with the object's id as key and the low-level database
handle as value. Then in the finalizer method you can lookup the hash
and get the handle to free it.
But again you're right. This is not very nice and clean, not to say
horrid.
Regards,
Michael
--
Michael Neumann
merlin.zwo InfoDesign GmbH
http://www.merlin-zwo.de
Tobias Reif
> Hello --
>
> On Wed, 24 Oct 2001, Paul Brannan wrote:
>
>
>>I also find myself reinventing the wheel in Ruby a lot, because some
>>library doesn't exist for Ruby or it doesn't work the way I want it to.
>>
>
> s/re// # in the circumstances you're describing :-)
I don't understand that. What's your point?
David Alan Black
> David Alan Black wrote:
>
> > Hello --
> >
> > On Wed, 24 Oct 2001, Paul Brannan wrote:
> >
> >
> >>I also find myself reinventing the wheel in Ruby a lot, because some
> >>library doesn't exist for Ruby or it doesn't work the way I want it to.
> >>
> >
> > s/re// # in the circumstances you're describing :-)
>
>
> I don't understand that. What's your point?
Simply that if Ruby doesn't already have a (working) library of a given type,
then Paul is *inventing* the wheel, not reinventing it.
David
--
David Alan Black
home: dbl...@candle.superlink.net
work: blac...@shu.edu
Web: http://pirate.shu.edu/~blackdav
Bil Kleb
>
> What's "job-security coding"?
Isn't that a coding without Unit Tests?
Pixel
[...]
> > Taking Python's (current) lack of real closures (I.E. lambda's don't
> > bind to local variables inside the scope in which they are created),
>
> Python *still* doesn't have real closures? Coo. One more reason for
> this boy not switching yet.
not true anymore since python 2.1
>
> > there's simply no comparison between Python and Ruby's functional
> > programming capabilities.
>
> Okay, so I've not started to seriously code in Ruby, but Ruby's
> functional capabilities are what really get me excited about the
> language. (And they're what Larry's busy stealing for Perl 6...)
apart from named parameter (which is not functional only), i don't find many
stuff missing in perl's functional programming... (apart from type inference
and partial application of course)
Emiliano
> Emiliano wrote:
>
> Ruby certainly allows for
> > very elegant coding. It also allows for job-security coding.
>
> What's "job-security coding"?
See http://www.ioccc.org/. There was also a IOPCC which was hosted at
itknowledge.com (IIRC) which has shut down early this year. Didn't
O'Reilly organize the IOPCC? I can't find anything about it on their
site.
Emile
Piers Cawley
> Piers Cawley <pdca...@bofh.org.uk> writes:
>
> [...]
>
>> > Taking Python's (current) lack of real closures (I.E. lambda's don't
>> > bind to local variables inside the scope in which they are created),
>>
>> Python *still* doesn't have real closures? Coo. One more reason for
>> this boy not switching yet.
>
> not true anymore since python 2.1
Phew.
>> > there's simply no comparison between Python and Ruby's functional
>> > programming capabilities.
>>
>> Okay, so I've not started to seriously code in Ruby, but Ruby's
>> functional capabilities are what really get me excited about the
>> language. (And they're what Larry's busy stealing for Perl 6...)
>
> apart from named parameter (which is not functional only), i don't
> find many stuff missing in perl's functional programming... (apart
> from type inference and partial application of course)
Function/operator equivalency, with names for all ops. Easy currying.
Lazy iteration. Pairs. Coroutines and Continuations. Lots of cool
functional stuff on its way in Perl 6. But this probably isn't the
right place for this discussion.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Nat Pryce
----- Original Message -----
From: "Avdi B. Grimm" <av...@avdi.org>
> On Tue, 2001-10-23 at 19:27, Michael Neumann wrote:
> > True. You cannot do everything with blocks.
> > In Ruby you have class ObjectSpace that lets you define finalizer
> > methods. This is not very nice, but it works.
> I would go so far as to say it doesn't work at all, unless I completely
> failed to understand it. Once the ObjectSpace-defined constructor kicks
> in, the object is *already gone*. All the destructor gets is (IIRC) the
> ID of the object. I haven't yet figured out how this can be used to
> free resources that only the now-deceased object posessed the keys to.
> Perhaps one has to maintain some sort of global ID/Resource map, and the
> destructor has to look up the resources to free via the ID...? Pardon
> me but, yeeeecchhhhh! That's just horrid.
The finaliser block is a *closure* and so can hold references to any
resources owned by the GC'd object that need to be cleaned up. Just be
careful that the closure doesn't hold a reference to the object itself, or
it will never be collected. This has been discussed before on this list, and
has been summarised on the Ruby Garden wiki at
http://www.rubygarden.org/ruby?DiscussionOnUsingFinalizers
Cheers,
Nat.
Mathieu Bouchard
On Wed, 24 Oct 2001, Rich Kilmer wrote:
> So...in Python you can use this:
> obj.__dict__['attrName']=value
> ...to get direct access to (get/set) the values of every attribute on
> an object.
>
> In Ruby every object attribute is private and can only be accessed
> through a method...period. Exposing the __dict__ "bag" on an object
> exposes the entire state of that object for public consumption.
Which reminds me that I wrote a Ruby emulation of obj.__dict__ 5 months
ago. I finally checked-in this nice sample of MétaRuby usage this morning.
(this is one-third of samples/ReflectionHashes.rb).
----------------8<----------------cut-here----------------8<----------------
class InstanceVariablesHash; include HollowHash, SimpleHashP
# victim is any object.
# it only works on Ruby-visible instance-variables,
# i.e. those accessible by "@" names.
def initialize(victim)
@victim = victim
end
def length
@victim.instance_variables.length
end
def canonize_name(k)
if Symbol===k; k=k.to_s; end
String===k && k =~ /^(@[A-Za-z_]\w*)$/ or
raise "Invalid Name"
k
end
def has_key?(k)
k = canonize_name k
!! @victim.instance_variables.index(k)
end
def get(k)
k = canonize_name k
@victim.instance_eval k
end
def put(k,v)
k = canonize_name k
@victim.instance_eval "#{k} = ObjectSpace._id2ref(#{v.id})"
end
def remove(k)
# the best I can do
put(k,nil)
end
def each_key(&proc)
@victim.instance_variables.each(&proc)
end
end
----------------8<--------------découpez-ici--------------8<----------------
> methods. The same is NOT true for Python. It provides "privacy"
> through obfuscation (name mangling) but its still easy to get around
> (because everything is still held in the __dict__).
Well, this may be interesting from a $SAFE perspective. If you are not
coming this way from a $SAFE perspective, chances are that I don't give
a...
________________________________________________________________
Mathieu Bouchard http://hostname.2y.net/~matju
Robert Feldt
> Function/operator equivalency, with names for all ops. Easy currying.
> Lazy iteration. Pairs. Coroutines and Continuations. Lots of cool
>
Lazy iteration? Do you mean "Lazy evaluation" or is this different?
> functional stuff on its way in Perl 6. But this probably isn't the
> right place for this discussion.
>
Interesting. Do you have pointers to discussion of these things in Perl 6?
Regards,
/Robert
Piers Cawley
> On Wed, 24 Oct 2001, Piers Cawley wrote:
>
>> Function/operator equivalency, with names for all ops. Easy currying.
>> Lazy iteration. Pairs. Coroutines and Continuations. Lots of cool
>>
> Lazy iteration? Do you mean "Lazy evaluation" or is this different?
Do you know, I think I'm confused. Take a look at Larry's apocalypses
and Damian's exegeses.
>
>> functional stuff on its way in Perl 6. But this probably isn't the
>> right place for this discussion.
>>
> Interesting. Do you have pointers to discussion of these things in
> Perl 6?
dev.perl.org is a decent starting point. Note that there's some
seriously barking suggestions in some of the mailing lists and RFCs...
David Simmons
news:NDBBKPEKEKOELOHK...@infoether.com...
Basically. But I probably should make sure we really are saying the same
thing.
It is important to recognize that the <Foo> described in all my prior
examples is and always remains (as these prior examples were written) a
member of the namespace A defined by module A.
What is happening is that methods are being added to <A.Foo>. These methods,
however, belong to module B and are scoped to module B [where ownership and
scoping are distinct notions of module and namespace].
When module B is loaded, the methods it owns will be registered within their
appropriate namespaces and behavior/class contexts. When code which has
access to moduleB is executed, it will then have access to the "set" of
available <A.Foo> methods that were defined in moduleB.
------
What I'm going to say next, upon first reading, may create more confusion
than it resolves. I want to be clear the <Foo> referred to in all the
examples is the <Foo> defined in the namespace A of module A. The B and/or C
modules are just defining additional/alternate methods on <A.Foo>.
It is still entirely possible for module B to define [within the B
namespace] a class it called <Foo>, as could module C within the C
namespace. Such a class would be entirely unrelated to the module A's <Foo>.
They could all be distinguished by explicit use of their full paths,
<A.Foo>, <B.Foo>, <C.Foo>. Obviously this would be confusing, and is not a
good idea. But the compiler and the underlying object model would not be
confused by these three distinct classes have the same name.
----
Here's a File System Analogy [assuming this analogy helps to clarify the
point]: To the compiler/object-model this is no different than (by analogy)
you as a human being examining three directories (\A, \B, \C) on your disk
drive, each of which happens to contain a file called "Foo.txt". In the file
example, we can readily understand that the three "Foo.txt" files within the
(\A, \B, \C) folders/directories do not have to have anything in common
[they may each contain entirely different text, written by different people
at different times].
----
Good names for things, are good names because they describe/fit the things
role. So it is realistic to assume that different people may well decide
(independently) to use the same name to describe unrelated classes. Thus, as
a language designer, planning for naming conflicts is an important issue. So
SmallScript (and its ancestor QKS Smalltalk) provide support for
renaming/importing explicit members of other namespaces.
In SmallScript, if we wanted to rename <A.Foo> to be <Bar> when referenced
from within module B's namespace, we could do so as follows.
"" w/other module attribute decls ignored for this example
Module name: B
shared-fields: alias[A.Foo] Bar.
This would allow us to write the modifications to A.Foo, using the name
<Bar>.
Method class: Bar scope: B [myPrivateX ...].
Which is really identical to writing:
Method class: A.Foo scope: B [myPrivateX ...].
Such capabilities can prove to be convenient/invaluable in the following
kind of scenario:
========
Module name: B
shared-fields: alias[A.Foo] Bar
default-scope: B.
Class name: Foo.
"" Some function or code defined within module B
Function [
someFn
^{Foo new, Bar new}.
].
=========
In the above example, we have used the renaming to allow us to avoid
prefixing the references to module A's <Foo> with "A.". Note: the {...}
brace operator returns a list containing its comma [or period] delimited
arguments.
"" This code is identical to the example using <Bar> shown above:
Function [someFn ^{Foo new, A.Foo new}].
There are actually far more things happening here (from a dynamic language
implementation viewpoint) than I am explaining. But for this example, I
think the surface explanation of straightforward import/renaming will
suffice. [If I've left you hanging, here is one clue: We could make a single
change to the definition of <Bar> in module B and not need to recompile any
code that referenced <Bar>].
-- Dave S. [www.smallscript.org]
>
> -Rich
Michael Neumann
> On Wed, 24 Oct 2001, Tobias Reif wrote:
>
> > David Alan Black wrote:
> >
> > > Hello --
> > >
> > > On Wed, 24 Oct 2001, Paul Brannan wrote:
> > >
> > >
> > >>I also find myself reinventing the wheel in Ruby a lot, because some
> > >>library doesn't exist for Ruby or it doesn't work the way I want it to.
> > >>
> > >
> > > s/re// # in the circumstances you're describing :-)
> >
> >
> > I don't understand that. What's your point?
>
>
> Simply that if Ruby doesn't already have a (working) library of a given type,
> then Paul is *inventing* the wheel, not reinventing it.
More technically:
s/re// is a Perl regular expression, substituting "re" with "".
In Ruby you would say instead:
# $_ = "...reinventing"
sub(/re/, //)
# puts
Paul Brannan
> More technically:
> s/re// is a Perl regular expression, substituting "re" with "".
I think sed and vi had this long before perl.
Paul
Robert Feldt
> Basically. But I probably should make sure we really are saying the same
> thing.
>
> It is important to recognize that the <Foo> described in all my prior
> examples is and always remains (as these prior examples were written) a
> member of the namespace A defined by module A.
>
> <snip>
>
This was very clear, thank you David. Sounds really useful if current
semantics is still allowed (changes are system-wide). Any comments
from matz, Dave and the other gurus?
/Robert
Tobias Reif
> More technically:
> s/re// is a Perl regular expression, substituting "re" with "".
> In Ruby you would say instead:
>
> # $_ = "...reinventing"
> sub(/re/, //)
> # puts
C:\>ruby -e 'print "reinventing".sub!(/re/,//)'
#<Regexp:0x459a880>inventing
C:\>ruby -e 'print "reinventing".sub!(/re/,"")'
inventing
;)
Alan Chen
> Alan Chen wrote:
>
> > All large scale development languages allow access to private data,
> > its a matter of how much pain you want to put the developer through if
> > they elect to access a non-public interface. FWIW, I suspect that it
> > would be easy to write a module to disable the send and method
> > functions in a class. (or provide a warning if you'd prefer)
>
> But it still wouldn't be the default behaviour. Having class-private
> data available publicly by default isn't correct in my book. You have
> to choose what to make part of your public interface. IMO, of course.
>
> Emile
The funny thing is that it's pretty easy to access private
variables in Python. They just get name mangled, but are still
accessible.
--
Alan Chen
President and Lead Developer
Digikata LLC
al...@digikata.com
http://digikata.com
Emiliano
> > But it still wouldn't be the default behaviour. Having class-private
> > data available publicly by default isn't correct in my book. You have
> > to choose what to make part of your public interface. IMO, of course.
> >
> > Emile
>
> The funny thing is that it's pretty easy to access private
> variables in Python. They just get name mangled, but are still
> accessible.
That doens't matter much to me. What does matter is that it's obvious
you're doing it, so I can come over and give you a good speaking-to.
Emile
Nathaniel Talbott
> Emiliano wrote:
>
> > Ruby certainly allows for
> > very elegant coding. It also allows for job-security coding.
>
>
> What's "job-security coding"?
http://www.web-hits.org/txt/codingunmaintainable.html gives a very good
explanation of it. Every time I *think* about this page I crack up.
Nathaniel
<:((><
+ - -
| RoleModel Software, Inc.
| EQUIP VI
Kero van Gelder
>
> Nonsense. The managers won't care in the least. The poor bastard that
> has to maintain other peoples code will.
The ppl in my project that set up the coding guidelines were of the
managerial type.
Those poor bastards will often be poor bastards, still, because other
ppl used different guidelines. The world is a big place.
> They're not _alternatives_, they're _complimentary_.
Definitely. Beware that the most important aspects do not get lost
because they're too obvious.
> > That's a huge part of the problem in Software Engineering.
> > It's psychological, not mathematical.
>
> I don't understand this point. Coding standards aren't mathematical
> either.
That's why we argue over them.
+--- Kero ------------------------------ ke...@chello.nl ---+
| Don't split your mentality without thinking twice |
| Proud like a God -- Guano Apes |
+--- M38c ------- http://members.chello.nl/~k.vangelder ---+
Emiliano
> The ppl in my project that set up the coding guidelines were of the
> managerial type.
I'd chalk that up to concidence rather than it being the standard.
> Those poor bastards will often be poor bastards, still, because other
> ppl used different guidelines. The world is a big place.
Not with Python it isn't :)
> > I don't understand this point. Coding standards aren't mathematical
> > either.
>
> That's why we argue over them.
And that one is saved for the fortune file! :)
Emile
Sean Russell
> I'd like to know how large the large projects are in Ruby (in LOC or
> whatever measure).
> Almost certainly shorter than (functionally) comparable projects in C,
> C++, Java I'd guess...
Oh, much smaller. REXML is has more features than Electric XML (Java), but
the codebase, not counting comments and blank lines, is less than half the
size: ~3,700 for EXML, and ~1,700 for REXML. Not quite an order of
magnitude, but a healthy fraction. REXML started as a straight port of
Electric XML, but there is almost no similarity in the code anymore.
--- SER
Yukihiro Matsumoto
In message "[ruby-talk:23198] Re: Bruce Eckel's opinion of Ruby [SmallScript/AOS Selector Namespaces]"
on 01/10/24, Robert Feldt <fe...@ce.chalmers.se> writes:
|This was very clear, thank you David. Sounds really useful if current
|semantics is still allowed (changes are system-wide). Any comments
|from matz, Dave and the other gurus?
This is too heavy topic for my dead-by-fever brain.
Let me think about it for a while.
matz.
Sean Russell
> Sean Russell wrote:
>> Ummm... then don't use global data. At worst, you'd be no worse off than
...
> You might not use it, but your i-know-better neighbour will.
Then it will be her variables that will be overwritten, not mine.
Really, using global variables is such a poor programming habit that I
believe that if you have someone on your team using them, you have more
problems than just global variables. I've had to work with poor
programmers enough to know that a little tutoring and some decent project
leadership can really help these people contribute good code. Lord knows
I'm not the best programmer in the world, and I learn from other people as
much as they, me. This is why you have unit tests and code reviews. This
is what "teamwork" is all about. Oops, now I'm drifting into XP advocacy.
Sorry.
>> The main difference is that, with Python, Guido V.R. is determining how
>> all
>> of you are going to style your source. I'd rather have local control
>> over that sort of thing.
>
> While I agree with you, I have to ask: why? I feel the same way yet I
> can't shake the feeling we're being childish for holding on to
> something as insignificant to a particular coding style while we both
> acknowledge that coding standards are good.
Ah. I can appreciate that. I'd rather have flexibility in choosing the
coding standards because coding styles should be dynamic. If someone has a
better idea about how to make code readable or more maintainable that
Python's rigid style doesn't allow, then too bad. While this is true of
any programming language to some extent, the flexibility allowed by Ruby
provides more wiggle room.
I feel that language-imposed style limitations are more restrictive of
creative freedom than those imposed on the project level. If you don't
have any ability to change, you'll never improve, and you'll never discover
a *better* way of doing things.
>> I'm increasingly getting the feeling that there isn't much structure in
>> your work environment.
>
> On an individual level, that's what you're going to see. Unless you
> work at NASA, maybe.
Well, my last project, which had a team of 5, and about 50k lines of code
in Java, had some coding standards that we uniformly adhered to. There
were only three ways to tell the difference in any of the code:
1) You knew which code you wrote because you remembered writing it
2) You looked at the comments
3) If there were any really long variable names, it was my code.
So I'd argue that Python would not have changed this in the least. In
fact, we used the "official" Java style guide with some minor changes to
the variable naming scheme. These changes were, in our opinions,
significant improvements on the "official" style guide. If the Java
compiler itself had imposed those style restrictions, we wouldn't have been
able to use our naming scheme. This is the core of my disagreement with
enforcing styles at the language level.
>> Again, I'd rather have local control, than leave
>> that sort of thing up to the language designer.
>
> Which leaves you to police such matters.
Yes, that's part of the team effort... everybody polices each other's code.
You can't afford to not have code review on a large, multi-programmer
project.
> I don't think that was the point. His work environment may or may not
> be as chaotic as you describe. The way I read his statements is that
... as I imagine :-)
> in large projects, you need coding standards anyhow, in which case
> it makes very little difference if you enforce them by policy or by
> your compiler. I don't particularly like the coding standards I have
> to use at work now, and still I have to use them. Same difference who
> does the policing.
I disagree. With Python, the coding standards are inflexible. Python is
not going to change; you have no chance to provide input; control of the
style is so far removed from you that you are, in effect, insignificant.
If control is local, you have input. It may be ignored; you may be
outvoted; it may be such a legacy standard that changing it would be
impossible. This is still at the *worst case* no worse off than if you
were using Python, and the opportunity for it being *better* is much, much
greater.
--- SER
Eric Lee Green
> I disagree. With Python, the coding standards are inflexible. Python is
> not going to change; you have no chance to provide input; control of the
> style is so far removed from you that you are, in effect, insignificant.
> If control is local, you have input. It may be ignored; you may be
> outvoted; it may be such a legacy standard that changing it would be
> impossible. This is still at the *worst case* no worse off than if you
> were using Python, and the opportunity for it being *better* is much, much
> greater.
In my experience, it doesn't matter what the coding standard is. What matters
is that it is consistently followed. In the 100K+ line Python project there
were a large number of things that we had as part of our coding standard that
were not enforced by the language, things such as naming conventions for
modules, classes, methods and attributes, use of spaces rather than tabs for
indentation, use of 'pass' to close blocks so Emacs's Python mode would not
obfuscate our code for us, etc... all that Python's stylistic limitations did
was remove a few things from that coding standard.
And yes, there were a few people flogged with limp spaghetti when they did
not follow the coding standard :-). As co-lead I was responsible for much of
the integration portion, meaning I ended up tracking bugs down into other
people's code... needless to say it irritated me when I had to re-format
somebody's code because he had not followed the coding standard!
--
Eric Lee Green GnuPG public key at http://badtux.org/eric/eric.gpg
mailto:er...@badtux.org Web: http://www.badtux.org
You do not save freedom by destroying freedom
Emiliano
> Emiliano wrote:
>
> > Sean Russell wrote:
> >> Ummm... then don't use global data. At worst, you'd be no worse off than
> ....
> > You might not use it, but your i-know-better neighbour will.
>
> Then it will be her variables that will be overwritten, not mine.
Which is great if you work in isolation and interface cleanly. It's
not so great if people work on one package where the separation is not
so clear.
> Really, using global variables is such a poor programming habit that I
> believe that if you have someone on your team using them, you have more
> problems than just global variables.
So why not make them impossible?
> Ah. I can appreciate that. I'd rather have flexibility in choosing the
> coding standards because coding styles should be dynamic. If someone has a
> better idea about how to make code readable or more maintainable that
> Python's rigid style doesn't allow, then too bad. While this is true of
> any programming language to some extent, the flexibility allowed by Ruby
> provides more wiggle room.
OK, so that means coding style can differ from year to year. I don't
see that as a plus. Where I work with C we work according to the safer
C guidelines. No deviations for whatever hype passes along or whatever
hotshot guru entered. I don't work in that project anymore but it
served us extremely well during its time; a project spanning multiple
years and people coming and leaving, it was well worth the grumbling
people would do about the anal/ugly/unreadable/<fill-in-excuse> we
took in the beginning.
> I feel that language-imposed style limitations are more restrictive of
> creative freedom than those imposed on the project level. If you don't
> have any ability to change, you'll never improve, and you'll never discover
> a *better* way of doing things.
Which is perfectly true for algorithmic work. I wouldn't count coding
guidelines the 'creative freedom'.
> Well, my last project, which had a team of 5, and about 50k lines of code
> in Java, had some coding standards that we uniformly adhered to. There
> were only three ways to tell the difference in any of the code:
>
> 1) You knew which code you wrote because you remembered writing it
> 2) You looked at the comments
> 3) If there were any really long variable names, it was my code.
>
> So I'd argue that Python would not have changed this in the least. In
So it wouldn't have hindered you either once you got past the initial
shock.
> fact, we used the "official" Java style guide with some minor changes to
> the variable naming scheme. These changes were, in our opinions,
> significant improvements on the "official" style guide. If the Java
> compiler itself had imposed those style restrictions, we wouldn't have been
> able to use our naming scheme. This is the core of my disagreement with
> enforcing styles at the language level.
Python doesn't enforce a naming scheme, and I wouldn't stand for a
compiler that would.
> I disagree. With Python, the coding standards are inflexible. Python is
> not going to change; you have no chance to provide input; control of the
> style is so far removed from you that you are, in effect, insignificant.
> If control is local, you have input. It may be ignored; you may be
> outvoted; it may be such a legacy standard that changing it would be
> impossible. This is still at the *worst case* no worse off than if you
> were using Python, and the opportunity for it being *better* is much, much
> greater.
I'll agree to disagree. Not all matters ned be democratic.
I can't believe I'm taking a stand for Python. Put it down to loving a
good discussion anytime.
Emile
Hal E. Fulton
From: Nathaniel Talbott <ntal...@rolemodelsoft.com>
To: ruby-talk ML <ruby...@ruby-lang.org>
Sent: Wednesday, October 24, 2001 10:54 AM
Subject: [ruby-talk:23203] Re: Bruce Eckel's opinion of Ruby
> Tobias Reif [mailto:tobia...@pinkjuice.com] wrote:
>
> > Emiliano wrote:
> >
> > > Ruby certainly allows for
> > > very elegant coding. It also allows for job-security coding.
> >
> >
> > What's "job-security coding"?
>
> http://www.web-hits.org/txt/codingunmaintainable.html gives a very good
> explanation of it. Every time I *think* about this page I crack up.
Thanks for that link, Nathaniel... I just read about a third of it,
and it went straight into my bookmarks.
In the words of Yogi Berra, "That was a real tour de France."
Hal
Peter Hickman
news:005401c15c6b$42b1f720$0200...@austin.rr.com...
> > Emiliano wrote:
> > What's "job-security coding"?
> >
>
> the company can't fire the person who
> wrote it...
But it better work!
There is a further degeneration; 'write once' or 'blackhole' code. Code so
obscure
that the programmer does not understand it even though it works. Welcome to
EPS/FCS
where even the compiler writers practiced blackhole code and found that they
were
unable to port the compiler off the IBM mainframe.
Wonder what became of them?
Peter Hickman
news:Pine.LNX.4.21-maildir.0...@cactus.intern.iris-advi
es.com...
> Sean Russell wrote:
> > The main difference is that, with Python, Guido V.R. is determining how
all
> > of you are going to style your source. I'd rather have local control
over
> > that sort of thing.
>
> While I agree with you, I have to ask: why? I feel the same way yet I
> can't shake the feeling we're being childish for holding on to
> something as insignificant to a particular coding style while we both
> acknowledge that coding standards are good.
I'm not sure that this is what is happening in Python. Python picked up the
program structuring from a language called ABC. This structuring was use in
ABC to trim down the syntactic sugar and included an interactive editor.
This meant that as you typed the code in such as IF the THEN would appear
after your cursor and your cursor would jump over the THEN once the
conditional part as completed.
Python has taken this structure over sugar approach but you don't
necessarily have the interactive editor that came with the ABC environment.
If I recall that was what ABC was all about, an experimental language to
explore this concept. I seem to recall a reference to ABC in some Python
book when discussing the code structure of the language.
Its not quite GVR being a pretty print freak but him buying into that
particular ABC feature. I seem to recall that maybe some other ABC features
have also crept out.
Emiliano
> I'm not sure that this is what is happening in Python. Python picked up the
> program structuring from a language called ABC. This structuring was use in
> ABC to trim down the syntactic sugar and included an interactive editor.
> This meant that as you typed the code in such as IF the THEN would appear
> after your cursor and your cursor would jump over the THEN once the
> conditional part as completed.
Eeeeeeeuuuuuuwwww! Horrid!
Emile