Collection interfaces

topmind topmind at technologist.com
Fri Mar 23 00:26:08 EST 2001


"Troy Brumley" <t*b*r*u*m*l*e*y at f*u*s*e.n*e*t> wrote in message
news:B6DF5D0D.D7AE%t*b*r*u*m*l*e*y at f*u*s*e.n*e*t...
> in article anhu6.18497$Im6.1938203 at newsread1.prod.itd.earthlink.net,
topmind
> at topmind at technologist.com wrote on 3/22/01 1:57 AM:
>
> >
> > "Troy Brumley" <t*b*r*u*m*l*e*y at f*u*s*e.n*e*t> wrote in message
> > news:B6DE17D2.D6B0%t*b*r*u*m*l*e*y at f*u*s*e.n*e*t...
> >> in article 3AB8A730.4BE13D22 at mail.com, James A. Robertson at
> >> jarober at mail.com wrote on 3/21/01 8:06 AM:
> >>
> >>> topmind wrote:
> >>>>
> >>>
> >>>>> http://www.cincom.com/smalltalk
> >>>>>
> >>>>
> >>>> I only see a front page, not a parsing example.
> >>>>
> >>>
> >>> Follow the tutorial link - it's right there on that page.
> >>>
> >>>
> >>>> Besides, what are you comparing it to so say
> >>>> it is better than a procedural/relational approach?
> >>>
> >>> It's vastly easier than similar code done in C or basic, for example
> >>
> >> User testimonial here ... last week I had to rip thorugh a pile of IIS
> > logs
> >> to get some statistics for some people, and I used the original
(non-gui)
> >> tutorial code as a starting point. I was once again impressed with how
> > much
> >> easier it was to do several common data processing tasks in Smalltalk
than
> >> it was in Assembly language or C or Pascal.
> >>
> >
> > Give me specific requirements and I bet I can match it on code size.
> >
> > C, Pascal, and Assembly are hardly what I would use for code-size
> > contests.
> >
> > Of course, there is more to comparing than code size, but those often
> > get very subjective or fuzzy.
>
> I rarely worry about code size except how it relates to code clarity. Even
> back in my assembly oriented youth I tried to keep functions under one
page
> on a listing for the sake of clarity.
>

Can you quantify "clarity" or is it a personal thing (subjective)?

What makes people confortable with code seems to vary
greatly per individual.

Do you have specific examples.

> I mention C, Pascal, and Assembly because they are my usual tool set, or
> were until I discovered Smalltalk.

I used similar stuff at first, but was glad to leave them in the dust when I
discovered the concepts of Table Oriented Programming.

I never wanted to see another fricken array again (accept as
hashes/dictionaries to pass single records or parameter
lists or attributes. That is their best use, and not data collection
holding.)

> I've done a lot of business programming
> over the years in procedural environments and used more languages than
those
> (even COBOL and RPG) but for the heavy lifting I would always stick with
> them.
>
> Again, until I discovered Smalltalk :)
>
> I've seen Perl and run away screaming.

Perl is a strong divisor. You either swear by it, or swear at it. There
are few in-betweeners.

> Python and Eiffel are on the to learn
> list, but Smalltalk seems to have the power I need for the tasks I want to
> do these days. Objects are becoming more and more natural as I use them,
and
> my code improves contantly.
>
> >
> >> I'm a long time procedural type, learning to really think in and use
> >> Smalltalk has been an interesting experience.
> >>
> >> I've also done a lot of database "fixing" and Smalltalk has usually
beat
> > out
> >> raw SQL for anything but the most trivial tasks.
> >>
> >
> > Fixing what? SQL is not good at string parsing.
>
> Usually sweeping changes, or dangling referential integrity problems.


Huh? Referential integrity is an option, not a forced feature.

If the lamp keeps you awake at night, then turn it off!

>
> >> All that said, I think it's the environment (interactive) that improves
> > the
> >> experience as much as the language itself. If I had a reasonable
> >> interpretive BASIC environment available, I could probably do many of
the
> >> things I did in Smalltalk almost as easily ... certainly more easily
than
> >> with C.
> >>
> >
> > I find interpretive environments potentially more compact code-wise than
> > static ones.
>
> No argument here.
>
> >
> >>
> >>>
> >>>>
> >>>>>>
> >>>>>>> [snip]






More information about the Python-list mailing list