> Lew wrote:
>>> where full-bore O-O suits, nothing like Python or Ruby is going to
[quoted text clipped - 11 lines]
> other mechanisms of the "big-iron" languages like C++, C#, Java or
> Smalltalk.
If it is purely about the OO aspect then both Python and
Ruby are OO.
But there are several other aspects where Python and Ruby are
a different type of language than Java.
Arne
Lew - 16 Feb 2007 04:00 GMT
> If it is purely about the OO aspect then both Python and
> Ruby are OO.
>
> But there are several other aspects where Python and Ruby are
> a different type of language than Java.
I see the difference to do more with static vs. dynamic typing than O-O vs.
not. Java, C++/# and others have a heavy compilation stage that allows for all
kinds of industrial-strength idioms. This is not to advocate such idioms per
se, but to characterize a difference.
When compile-time checks and scaffolds of inheritance and composition are what
you want, then the "big" languages tend to offer benefit. These are the
aspects that I call "full-bore" - contractor-scale machinery. Looser webbing
has its place, too.
A salesman tried to get a farmer to buy a tractor. The farmer replied that he
needed the money to buy a cow. "You'll look pretty silly riding a cow around
to mow your fields," the salesman urged. "Look sillier milking a tractor," the
farmer rejoined.
- Lew
Andrew Thompson - 16 Feb 2007 15:20 GMT
...
> A salesman tried to get a farmer to buy a tractor. The farmer replied that he
> needed the money to buy a cow. "You'll look pretty silly riding a cow around
> to mow your fields," the salesman urged. "Look sillier milking a tractor," the
> farmer rejoined.
LOL! I have actually 'milked' a tractor.
Mind you, I needed the diesel. ;-)
Andrew T.
> Lew wrote:
>>> where full-bore O-O suits, nothing like Python or Ruby is going to
[quoted text clipped - 5 lines]
> Actually, maybe it would. I was basing my comment on comments others
> have made, and likely was unfair to Python.
I was just curious to know what impressions you had about Python. When I
started looking at Python a while back, initially my reaction was,
"uurgh! dynamic/loose typing! What? You don't declare interfaces?" and
things like that. What I soon came to realise is that there is a
Pythonic way to do things, a mindset, along with Python and the
community. And one of those ways is to put tests in place with good
coverage. But yes, you'll catch less problems at compile time with
dynamic typing...
There are some things about Python I love. I love the fact you can do
away with getters and setters, allowing direct access to members, which
is ok in the vast majority of cases. In the remaining cases, you use the
fact that writing "a = chicken.beak" in Python calls a getter that is
implicit, which you can override (so you don't break any existing code).
(Although exposing the members directly does involve breaking
encapsulation and reveals some implementation detail...!)
I also love how compact and cohesive the language is. Want a substring?
Want a list slice? It's the same format for both:
string = "This is a string, hello my world"
substring = string[1:10]
list = [2, 6, 4, 7, 8, 3]
subList = list[2:4]
Size of list versus size of string? Same syntax:
print len(string)
print len(list)
This all said and done, when I think "OO" with big capital 'O's, I do
usually think of Java first.
But Python's pretty hard to beat for fast prototyping and getting
something functioning in not much time.
> My impression is that the so-called "scripting" languages are less good
> about things like compile-time elimination of bugs, developing larger
> components, more thorough exception- and error-handling mechanisms and
> other mechanisms of the "big-iron" languages like C++, C#, Java or
> Smalltalk.
I know what you mean... although I often think people underestimate
Python as well.
I would never consider doing a large, OO heavy project in Perl. But
Python would be much more of a contender.
lex
Lew - 16 Feb 2007 14:42 GMT
> There are some things about Python I love. I love the fact you can do
> away with getters and setters, allowing direct access to members, which
> is ok in the vast majority of cases.
public class Exposed
{
public int kount;
public String name;
}
Wherever did you get the notion that Java doesn't permit that?
> In the remaining cases, you use the fact that writing "a = chicken.beak" in Python calls a getter that is
> implicit, which you can override (so you don't break any existing code).
That is usual among scripting languages. JSP EL, for example, requires that
member access be mediated through accessors/mutators, but gives the notational
convenience of direct attribute references.
> (Although exposing the members directly does involve breaking
> encapsulation and reveals some implementation detail...!)
Which is why, though it is a choice, it isn't often the best choice.
> I also love how compact and cohesive the language is. Want a substring?
> Want a list slice? It's the same format for both:
[quoted text clipped - 4 lines]
> list = [2, 6, 4, 7, 8, 3]
> subList = list[2:4]
À chacun son goût.
("Ah! Chaka [Khan] is some goat!" <http://en.wikipedia.org/wiki/Chaka_Khan>)
> Size of list versus size of string? Same syntax:
>
> print len(string)
> print len(list)
/ibid./
- Lew