"stereotyping"

ruby-talk
1

Sean O’Dell wrote:

That’s my experience. I love Ruby, but I just don’t see a large
team working
together without at least SOME form of type checking.

Does smalltalk have it? (Genuinely asking, I was under the
assumption
it did not, but I don’t know smalltalk.) I do believe there have
been
some historically large smalltalk projects in the past, no?

However I have noticed that I need to “read the source” far more
often
than with Java libraries, and correctly interpreting the source
requires
experience.

Thank you, that was my point. It’s far easier to read the method
definition
and see the types than to dig around in code. Good for smallish
projects,
not efficient nor safe for large team projects.

I might note here that the fact he has to read the source wasn’t
attributed to the fact there were no types listed. (It might have
been, but you’re presuming it was, and I see no evidence of that
based
on the quote.)

I would love to do a comparative experiment myself; one team with
Java
and one with Ruby. Just not sure the boss would fund it :slight_smile:

This was my point, too. At least with some type checking you could
show that
Ruby would be at least as safe as Java, but with all the freedom of
Ruby.
It’s a win-win. Hard to argue against.

You’re making the presumption here that type checking can be
correlated with “safety”, which I’m not sure has been shown yet.

···

Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/

2

It’s associated with “understanding” which is usually the predicate of
“safety.” Understanding what a method expects helps you to call it properly.

Sean O'Dell
···

On Wednesday 19 November 2003 07:01 pm, Michael Campbell wrote:

Sean O’Dell wrote:

This was my point, too. At least with some type checking you could

show that

Ruby would be at least as safe as Java, but with all the freedom of

Ruby.

It’s a win-win. Hard to argue against.

You’re making the presumption here that type checking can be
correlated with “safety”, which I’m not sure has been shown yet.

3

Sean O’Dell wrote:

You’re making the presumption here that type checking can be
correlated with “safety”, which I’m not sure has been shown yet.

It’s associated with “understanding” which is usually the predicate of
“safety.” Understanding what a method expects helps you to call it properly.

How do the smalltalkers manage?

4

Michael campbell wrote:

How do the smalltalkers manage?

Couldn’t say for sure, but I’ve never known a smalltalker who
worked as part of a team on a project of extended duration…
I’m sure that says something.

5

Clifford Heath wrote:

Michael campbell wrote:

How do the smalltalkers manage?

Couldn’t say for sure, but I’ve never known a smalltalker who
worked as part of a team on a project of extended duration…
I’m sure that says something.

Wow! That’s quite the troll! - I think I’ll bite.

As a smalltalker who has been working on the same project in a team at
work for 9 months and who has been contributing to open source projects
as part of rather large distributed teams for several years, I can
assure you that the fact that you’ve never met any smalltalkers who have
done so reflects more on who you’ve met than on who is out there.

I quick scan of http://www.whysmalltalk.com/production/index.htm gives
you some idea of some of the many large scale applications deployed
using Smalltalk. These applications are used by companies like Chrysler
and FedEx as well as many large banks, insurance companies, etc. I
think we can safely assume that these applications are developed by more
than a single individual and over an extended duration.

To touch on the broader issue, I don’t need a static type to know what a
method expects. My method parameter might be called aWidget, for
example which tells me it is expecting something that behaves like a
widget. Then if I need more clarification, I can look at the code
(which is probably no more than 5-10 lines - smalltalk methods are
usually that short) and see what methods are called on it. Then I know
it’s expecting an object that responds to those methods. If for some
reason, it still wasn’t clear, I could easily put in a comment
explaining what was expected but I can’t think of a time recently where
that has been necessary.

I can’t say I’ve ever run into cases in Smalltalk where I can’t
understand what a method expects because I don’t have static typing.
And I’d laugh at anyone who claims Java code (for example) is easier to
read than Smalltalk - I don’t need a Javadoc equivalent in Smalltalk to
understand the code.

Julian

6

Julian Fitzell wrote:

Wow! That’s quite the troll! - I think I’ll bite.

Sorry, it probably was a bit OTT. Interesting though that most of the
apps listed are either inhouse dev’t or products sold to generate
support (customisation) revenue - like large trading apps for example.

My experience is with designing and extending large software products
(>1MLOC) over dozens of upgrade cycles and six+ years, where you gather
a large base of legacy code and entrenched design faults, with a need
for backward compatibility and migration at every release, with teams
of 10-30 engineers (not super-large, but enough that central review and
control is quite hard), most of whom have been working on the product
for less than half its life. I’ve done this three times now.

9 months on a project doesn’t really count. Problems arise over 9 years
when you can’t provide hands-on support for customer upgrades. I can’t see
how I’d do that with any fully dynamic language without even optional
typing. Not Ruby, definitely not Smalltalk, though both are superlative in
some fields. That doesn’t mean I’m happy with the languages I have used
however, I think the computer language field has a long way to go yet.
Wish I had time to write Rite :slight_smile: Ruby’s so good, and Rite is such a good
opportunity for significant further improvement.

If for some
reason, it still wasn’t clear, I could easily put in a comment
explaining what was expected but I can’t think of a time recently where
that has been necessary.

That is indeed the mark of a good language - it communicates by itself
without the need for comments. However, the lack of method typing in
both R&S limit the amount of information that can be included without
adding comments, and that’s a pity when so much else is right. Note that
it’s only partly about what the compiler can check, it’s mainly about
what the human can apprehend.

Clifford.

7

Clifford Heath wrote:

Julian Fitzell wrote:

Wow! That’s quite the troll! - I think I’ll bite.

Sorry, it probably was a bit OTT. Interesting though that most of the
apps listed are either inhouse dev’t or products sold to generate
support (customisation) revenue - like large trading apps for example.

Well, I’ve never had a discussion about this that has changed the minds
of either party, so I’m weary of carrying on much longer and I certainly
stop short of trying to convince you - but I figure I might as well put
the counterarguments out in the open for those who may be reading.

My experience is with designing and extending large software products
(>1MLOC) over dozens of upgrade cycles and six+ years, where you gather
a large base of legacy code and entrenched design faults, with a need
for backward compatibility and migration at every release, with teams
of 10-30 engineers (not super-large, but enough that central review and
control is quite hard), most of whom have been working on the product
for less than half its life. I’ve done this three times now.

People often say that Smalltalk is never successfully used for “large”
projects, but they usually mean “large” in the sense of code size as
opposed to large in the sense of amount of functionality. In my
opinion, no language is ever used successfully for “large” projects when
using the former definition. In my experience, writing in Smalltalk
produces code that has the same functionality as Java with a tenth of
the volume of code. Our project is an enterprise level application for
a university community of 30,000 people; many of the large smalltalk
applications out there are being used in similar environments and have
been around for more than 6 years.

This doesn’t in any way prove that static typing is evil or even worse,
but the statement that “large” projects can’t be done in a
non-statically-typed language is pretty flawed, in my opinion.

9 months on a project doesn’t really count. Problems arise over 9 years
when you can’t provide hands-on support for customer upgrades. I can’t see
how I’d do that with any fully dynamic language without even optional
typing. Not Ruby, definitely not Smalltalk, though both are superlative in
some fields. That doesn’t mean I’m happy with the languages I have used
however, I think the computer language field has a long way to go yet.
Wish I had time to write Rite :slight_smile: Ruby’s so good, and Rite is such a good
opportunity for significant further improvement.

I really don’t understand your statement that “I can’t see how I’d do
that with any fully dynamic language”. That statement seems to depend
on the assumption that there is some problem with dynamic typing which
is exactly the point being debated in this thread (though not, really,
the point of my response, which was just to point out that Smalltalkers
do in fact work in teams over extended periods of time).

If for some reason, it still wasn’t clear, I could easily put in a
comment explaining what was expected but I can’t think of a time
recently where that has been necessary.

That is indeed the mark of a good language - it communicates by itself
without the need for comments. However, the lack of method typing in
both R&S limit the amount of information that can be included without
adding comments, and that’s a pity when so much else is right. Note that
it’s only partly about what the compiler can check, it’s mainly about
what the human can apprehend.

Again, I don’t really see how it limits the amount of information that
can be included. Is “someMethod: fooString” really any less clear a
declaration that “someMethod(String foo)” ? The difference to the human
reader seems pretty minimal. In fact, to a human reader, why would it
even matter if it had to be expressed in a comment instead of as a type?

The point of the compiler enforcement really is the crux of the matter
in my opinion. Some people like the basic security of static checking,
but it gets in your way every time you want to change a type (you have
to go change all the methods that take that as a parameter) even though
the behaviour or interface is the same. You need to spend a lot of time
up front making sure your types and interfaces are correct so you don’t
have to go through making changes like that later. You have to always
worry about casting when you take objects out of an array (assuming
we’re talking about Java anyway) and you can have a runtime type error
anyway if the object doesn’t cast correctly.

To many of us, the increased plasticity allows us to more easily
refactor and to make the code reflect what we mean as we develop rather
than bending to the will of a compiler. This, in my opinion, leads a
cleaner system that is easier to understand, less likely to contain
bugs, and easier to find bugs in when they do occur. Others may
disagree, but this is my experience.

And I will also say (though has little more merrit than you saying you
don’t know any Smalltalkers who work in teams on large projects) that
the vast majority of people I have talked to who have used dynamic and
static typing swear by dynamic typing.

Not the most compelling argument, but like I said, I’m not trying to
tell anyone else they can’t use static typing. All I’m saying is:

a) I don’t want to use it; and
b) I don’t experience any of the problems, when using dynamic typing,
that people who like static typing say I should be experiencing.

Julian

8

Julian Fitzell wrote:

Well, I’ve never had a discussion about this that has changed the minds

I’m not the religious type, and I appreciate you taking the time to
write, and in fact I agree with a lot of what you say, including about
Java. Although I’ve only done smaller projects using it I agree that a
lot of things about it are windy and annoying, and lack of proper
generics makes it less type-safe than promoted. C# has most of the same
problems, but it’ll be interesting to see how generics change that.

In my opinion, no language is ever used successfully for “large” projects
when using the former definition.

Well, that’s probably a fair generalisation over the industry, but my
experience is different - all three products on which I’ve worked (C,
C++, C#, with Perl, Ruby, Java and horrors! VBScript in parts) are/were
large in most relevant senses, including extent and depth of maintenance
over time by a changing team. It’s really the human factors that allow
or deny success in this kind of project.

Our project is an enterprise level application for a university community
of > 30,000 people; many of the large smalltalk applications out there are
being > used in similar environments and have been around for more than 6 years.

One customer, right? Try doing that with fifty customers, all on different
old versions, all abusing the system in different ways that the designers
didn’t intend, and all wanting their issues attended to without having to
take the hit for an upgrade to the most recent version.

Your comments on refactoring are well-taken, but I feel would be solved
better by better tool support in a more strongly-typed language. To safely
refactor in any language, you must be confident of limiting side effects.
A dynamic language just makes side effects will occur at runtime instead
of compile time - and if your test suite doesn’t give very high code
coverage how will you know that the system can be released. Remember, you
can’t just patch it after it’s in production because it’s not just one
local customer, it’s dozens.

How often during your time on this project have you needed to quickly patch
a critical error recently introduced into production? That sort of thing is
simply impossible in our product environment, and would guarantee business
failure almost immediately.

I really don’t understand your statement…

Perhaps what I’ve said clarifies it a bit.

Clifford.

9

Um. Sorry, but type signatures don’t promise you that side effects
are limited to compile-time. Only testing will do that. Which brings
you right back to the advantages of dynamic languages as opposed to
static type signatures.

-austin

···

On Fri, 21 Nov 2003 10:33:39 +0900, Clifford Heath wrote:

Your comments on refactoring are well-taken, but I feel would be
solved better by better tool support in a more strongly-typed
language. To safely refactor in any language, you must be
confident of limiting side effects. A dynamic language just makes
side effects will occur at runtime instead of compile time - and
if your test suite doesn’t give very high code coverage how will
you know that the system can be released. Remember, you can’t just
patch it after it’s in production because it’s not just one local
customer, it’s dozens.

–
austin ziegler * austin@halostatue.ca * Toronto, ON, Canada
software designer * pragmatic programmer * 2003.11.21
* 01.43.11

10

Austin Ziegler wrote:

Um. Sorry, but type signatures don’t promise you that side effects
are limited to compile-time.

That’s true, but they help by catching some cases. Said cases are
more likely to occur in some programs and human environments than
others. Whether Ruby should be used in environments where these
errors are common and avoidable seems to be the main bone of contention.
Optional typing (whether static, dynamic, or some combination) would
increase the range of purposes for which Ruby is suitable. You might
not want that, but I do.

Which brings you right back to the advantages of dynamic languages
as opposed to static type signatures.

No it doesn’t. It leaves you with no guarantee, but more confidence.
But there are no guarentees anyhow - even if the software works as
designed, nothing says it meets the user’s need. Nothing’s certain in
life, instead we must live within certain confidence levels. Static
typing can improve confidence levels. So can thorough testing.
Nothing about the absence of static typing can yield these particular
improvements - though individual languages may have (mostly) unrelated
other features which do, including reduced verbosity.

Clifford.

11

Austin Ziegler wrote:

Um. Sorry, but type signatures don’t promise you that side
effects are limited to compile-time.
That’s true, but they help by catching some cases.

I don’t find that they catch useful cases, but rather cases where
work had to be done to accommodate the static typing system in the
first place.

Said cases are more likely to occur in some programs and human
environments than others.

I would agree, but I think that our definitions for such programs
and environments are radically different. Mine would be the
“absolutely must never fail” embedded code for heart monitors and
such. Typical business apps are not those environments. There are
good reasons for thinking this, too, that I’ll describe below.

Whether Ruby should be used in environments where these errors are
common and avoidable seems to be the main bone of contention.
Optional typing (whether static, dynamic, or some combination)
would increase the range of purposes for which Ruby is suitable.
You might not want that, but I do.

Frankly, Ruby is already suitable to those non-“absolutely must
never fail” environments. What’s not happening is that people aren’t
feeling comfortable with their own developers’ capabilities – and,
I think, are underestimating them. Question: what is the purpose of
software in a business environment? Answer: serving business
purposes. Question: how much C++ or Java code actually serves
business purposes? Answer: It depends…

The situation is somewhat better now in C++ than it used to be (with
the STL), but I know that significant portions of the production-
level C++ code that I’ve worked with and on that deal with memory
management and other overhead details. In some cases, as much as
half of the code was needed for wrangling with the language. In
Java, it’s even worse, especially if you’re using J2EE. There’s a
book that advocates using Ruby for those environments where
management has been convinced to use J2EE or .NET that covers this
50 - 75% overhead code: Code Generation in Action.

What if your developers could write directly to the business
requirements without having to worry about language overhead? With
Ruby – and other strongly-typed dynamic languages – they can. Joel
Spolsky (www.joelonsoftware.com) wrote CityDesk, a desktop-based
content management system, in Visual Basic with Visual C++
performing necessary performance improvements or other things that
can’t be done in VB. It’s easily one of the best – and most
responsive – programs I’ve ever used on Windows.

He did this because in VB he was able to write closer to his
business requirements without having to deal with the overhead (both
mental and codewise) of C++. Joel’s a bright man. I think that his
lesson learned in this is generally applicable and is applicable
to Ruby’s situation as well.

Which brings you right back to the advantages of dynamic
languages as opposed to static type signatures.
No it doesn’t. It leaves you with no guarantee, but more
confidence.

Often it’s false confidence, Clifford. If static typing actually
gave you anything of value, people wouldn’t have to resort to tricks
like (void *). As Bruce Eckels pointed out in the article I found
earlier[1], when he tried some stuff in Python, he found that he no
longer had to upcast. His class hierarchy was made simpler.

Note that strongly and explicitly typed languages like Ada aren’t
actually as frustrating as C++, because they make you think about
how your types are used, rather than sometimes doing things
implicittly.

But there are no guarentees anyhow - even if the software works as
designed, nothing says it meets the user’s need.

Again, I think that if we consider how much code is framework code
in C, C++, and Java, all of the supposed advantages of statically
typed languages disappear under the productivity killing crush.

Nothing’s certain in life, instead we must live within certain
confidence levels. Static typing can improve confidence levels. So
can thorough testing. Nothing about the absence of static typing
can yield these particular improvements - though individual
languages may have (mostly) unrelated other features which do,
including reduced verbosity.

I’m not the only one who thinks that dynamically typed languages are
at least as suitable as statically typed languages for business
applications:

http://www.osteele.com/archives/2003/08/test_versus_type.html

As Oliver Steele points out, the productivity boost has been shown
in research!

-austin
[1] http://www.mindview.net/WebLog/log-0025

···

On Fri, 21 Nov 2003 17:13:36 +0900, Clifford Heath wrote:

austin ziegler * austin@halostatue.ca * Toronto, ON, Canada
software designer * pragmatic programmer * 2003.11.21
* 09.21.33

12
> What if your developers could write directly to the business > requirements without having to worry about language overhead? With > Ruby -- and other strongly-typed dynamic languages -- they can. > I'm not the only one who thinks that dynamically typed languages are > at least as suitable as statically typed languages for business > applications: > > http://www.osteele.com/archives/2003/08/test_versus_type.html > > As Oliver Steele points out, the productivity boost *has been shown > in research*!

this article is in agreement with you, and good reading for anyone interested
in strong vs. week type systems:

http://home.pacbell.net/ouster/scripting.html

tcl is the worlds greatest language, but ousterhout is a very bright guy.

-a

···

On Fri, 21 Nov 2003, Austin Ziegler wrote:

ATTN: please update your address books with address below!

===============================================================================

EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
PHONE :: 303.497.6469
ADDRESS :: E/GC2 325 Broadway, Boulder, CO 80305-3328
STP :: Solar-Terrestrial Physics Data | NCEI
NGDC :: http://www.ngdc.noaa.gov/
NESDIS :: http://www.nesdis.noaa.gov/
NOAA :: http://www.noaa.gov/
US DOC :: http://www.commerce.gov/

The difference between art and science is that science is what we
understand well enough to explain to a computer.
Art is everything else.
– Donald Knuth, “Discover”

/bin/sh -c ‘for l in ruby perl;do $l -e “print "\x3a\x2d\x29\x0a"”;done’
===============================================================================

13

Austin Ziegler wrote:

Um. Sorry, but type signatures don’t promise you that side
effects are limited to compile-time.

That’s true, but they help by catching some cases.

I don’t find that they catch useful cases, but rather cases where
work had to be done to accommodate the static typing system in the
first place.

Said cases are more likely to occur in some programs and human
environments than others.

I would agree, but I think that our definitions for such programs
and environments are radically different. Mine would be the
“absolutely must never fail” embedded code for heart monitors and
such. Typical business apps are not those environments. There are
good reasons for thinking this, too, that I’ll describe below.

The humans writing the code usually determine points of failure, though.
Humans circumvent ALL type checking; there is no perfect language. All you
can do is give them the suggestion, and if they want to swerve off the road,
they’re the ones taking that risk.

Whether Ruby should be used in environments where these errors are
common and avoidable seems to be the main bone of contention.
Optional typing (whether static, dynamic, or some combination)
would increase the range of purposes for which Ruby is suitable.
You might not want that, but I do.

Frankly, Ruby is already suitable to those non-“absolutely must
never fail” environments. What’s not happening is that people aren’t
feeling comfortable with their own developers’ capabilities – and,
I think, are underestimating them. Question: what is the purpose of
software in a business environment? Answer: serving business
purposes. Question: how much C++ or Java code actually serves
business purposes? Answer: It depends…

I think people know how to evaluate their own developer’s skills. I’ve seen
enough spaghetti code in my life to know that I personally do not suffer from
chronic UNDER-estimation of developers I work with.

He did this because in VB he was able to write closer to his
business requirements without having to deal with the overhead (both
mental and codewise) of C++. Joel’s a bright man. I think that his
lesson learned in this is generally applicable and is applicable
to Ruby’s situation as well.

These are good points, and it’s exactly why Ruby should not force any sort of
harsh typing restrictions on anyone.

Which brings you right back to the advantages of dynamic
languages as opposed to static type signatures.

No it doesn’t. It leaves you with no guarantee, but more
confidence.

Often it’s false confidence, Clifford. If static typing actually
gave you anything of value, people wouldn’t have to resort to tricks
like (void *). As Bruce Eckels pointed out in the article I found
earlier[1], when he tried some stuff in Python, he found that he no
longer had to upcast. His class hierarchy was made simpler.

Confidence is confidence. If a person moves forward and works, instead of
fretting over what a method is going to do, they’re working and moving
forward. If they’re offered the opportunity to “give it a try” knowing
they’re likely to get a harmless error message for trying, they’re working,
thinking, moving forward.

But there are no guarentees anyhow - even if the software works as
designed, nothing says it meets the user’s need.

Again, I think that if we consider how much code is framework code
in C, C++, and Java, all of the supposed advantages of statically
typed languages disappear under the productivity killing crush.

That has nothing to do with whether or not they are statically typed, that’s
100% about the foundation the developers are given to work with when they
begin development. Typical C projects don’t have any form of string handling
and they make calls to memory management routines constantly. That’s a lot
of overhead. They basically lack a smart foundation to work with; there are
many things missing you have to work around and that slows production down.

Java doesn’t suffer from this nearly as much, so I think that’s a bad example,
but C++ definitely does have this problem.

However, I think that goes more to the implementations. The people writing
C/C++ compilers are compiler writers. They typically stop when the compiler
works, and think little about language usage. Ruby and Python, though, are
developed with both the parser and the language usage in mind; Matz didn’t
just write an interpreter, who wrote LIBRARIES.

It’s all about this: how much time did the people who implemented my
environment spend on giving me cool libraries to work with?

Nothing’s certain in life, instead we must live within certain
confidence levels. Static typing can improve confidence levels. So
can thorough testing. Nothing about the absence of static typing
can yield these particular improvements - though individual
languages may have (mostly) unrelated other features which do,
including reduced verbosity.

I’m not the only one who thinks that dynamically typed languages are
at least as suitable as statically typed languages for business
applications:

http://www.osteele.com/archives/2003/08/test_versus_type.html

Count me as one of them, too. I believe in both dynamic and static languages.
I’m glad Ruby is not becoming a statically typed language!

Sean O'Dell
···

On Friday 21 November 2003 06:21 am, Austin Ziegler wrote:

On Fri, 21 Nov 2003 17:13:36 +0900, Clifford Heath wrote:

14

Ara.T.Howard wrote:

tcl is the worlds greatest language, but ousterhout is a very bright guy.

Umm, is there a “not” missing from this sentence? :slight_smile:

Hal

15

mh… based on this we must hope that matz is really really stupid :slight_smile:

···

il Fri, 21 Nov 2003 08:11:17 -0700, “Ara.T.Howard” ahoward@ngdc.noaa.gov ha scritto::

tcl is the worlds greatest language, but ousterhout is a very bright guy.

16

oh man - that is embarassing. definitely a missing ‘not’!

-a

···

On Sat, 22 Nov 2003, Hal Fulton wrote:

Date: Sat, 22 Nov 2003 03:35:09 +0900
From: Hal Fulton hal9000@hypermetrics.com
Newsgroups: comp.lang.ruby
Subject: Re: “stereotyping”

Ara.T.Howard wrote:

tcl is the worlds greatest language, but ousterhout is a very bright guy.

Umm, is there a “not” missing from this sentence? :slight_smile:

–

ATTN: please update your address books with address below!

===============================================================================

EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
PHONE :: 303.497.6469
ADDRESS :: E/GC2 325 Broadway, Boulder, CO 80305-3328
STP :: Solar-Terrestrial Physics Data | NCEI
NGDC :: http://www.ngdc.noaa.gov/
NESDIS :: http://www.nesdis.noaa.gov/
NOAA :: http://www.noaa.gov/
US DOC :: http://www.commerce.gov/

The difference between art and science is that science is what we
understand well enough to explain to a computer.
Art is everything else.
– Donald Knuth, “Discover”

/bin/sh -c ‘for l in ruby perl;do $l -e “print "\x3a\x2d\x29\x0a"”;done’
===============================================================================

17

Hi,

···

In message “Re: “stereotyping”” on 03/11/22, gabriele renzi surrender_it@rc1.vip.ukl.yahoo.com writes:

il Fri, 21 Nov 2003 08:11:17 -0700, “Ara.T.Howard” >ahoward@ngdc.noaa.gov ha scritto::

tcl is the worlds greatest language, but ousterhout is a very bright guy.

mh… based on this we must hope that matz is really really stupid :slight_smile:

Don’t worry. I am.

By the way, where should I put “not” in the above statement, Ara?

						matz.
18

loop { self.mouth << self.foot } if clr?

for the record:

tcl is not the worlds greatest language, but ousterhout is a very bright guy.
^^^
^^^
^^^

wouldn’t want to offend ousterhout!

:wink:

-a

···

On Sat, 22 Nov 2003, Yukihiro Matsumoto wrote:

Hi,

In message “Re: “stereotyping”” > on 03/11/22, gabriele renzi surrender_it@rc1.vip.ukl.yahoo.com writes:

il Fri, 21 Nov 2003 08:11:17 -0700, “Ara.T.Howard” > >ahoward@ngdc.noaa.gov ha scritto::

tcl is the worlds greatest language, but ousterhout is a very bright guy.

mh… based on this we must hope that matz is really really stupid :slight_smile:

Don’t worry. I am.

By the way, where should I put “not” in the above statement, Ara?

  					matz.

–

ATTN: please update your address books with address below!

===============================================================================

EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
PHONE :: 303.497.6469
ADDRESS :: E/GC2 325 Broadway, Boulder, CO 80305-3328
STP :: Solar-Terrestrial Physics Data | NCEI
NGDC :: http://www.ngdc.noaa.gov/
NESDIS :: http://www.nesdis.noaa.gov/
NOAA :: http://www.noaa.gov/
US DOC :: http://www.commerce.gov/

The difference between art and science is that science is what we
understand well enough to explain to a computer.
Art is everything else.
– Donald Knuth, “Discover”

/bin/sh -c ‘for l in ruby perl;do $l -e “print "\x3a\x2d\x29\x0a"”;done’
===============================================================================