Collection interfaces

[Troy Brumley]

in article Q7Bu6.2721$P4.207644 at newsread1.prod.itd.earthlink.net, topmind at
topmind at technologist.com wrote on 3/23/01 12:26 AM:

> 
> "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)?

My rule of thumb definition back in assembly days was not having to have a
separate note pad to keep track of what was going on. When I saw many
coworkers running out of fingers to mark pages in fanfold listings as they
flipped back and forth, I realized there was an easier solution -- move code
around and rewrite it. Yet another reason why refactoring comes natural to
me, I've never been afraid to rewrite code.

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

True.

> Do you have specific examples.

Not anymore. That system is retired. I still use those principles when I am
forced into a procedural environment because I know they work and people
have repeatedly said "thanks for cleaning that code up so I could understand
it" back in those old days. Unlike some, my personal software process has
not developed to include record keeping.

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

While I'm not familiar with table oriented programming, a long time ago I
did read a book on decision tables in software engineering.

I wonder if your advocacy of TOP is because it's the paradigm that works
best with how your mind works? I know people who can do wonderful things in
RPG that I could never do in the language, and indeed I found that working
in it gave me headaches. These same people, bright and capable, couldn't
work in my prefered environment of assembly language. Some assembly language
programmers I worked with could not transition to 4GLs like Cincom's MANTIS.

We all have different thinking styles, and I think language/environment
preference relates directly to this. I'm a non-linear non-verbal intuitive
thinker and I like Smalltalk. I know one verbal linear type who I couldn't
imagine working in Smalltalk, but she's a very sharp gal.

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

Scripting tools are wonderful, but why write one with an ugly looking C type
of code? Yuck! :)

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

Peculiar to our stage in development. We have both database enforced and
some program enforced integrity to manage. I prefer to have the integrity
turned on and would like more of it managed in the database, but in a couple
of cases there's a chicken and egg cycle between tables.

Some of our deletes needed to cascade and did not. I botched some things on
a migration and had to go in and fix them up as well.

Data does not refactor as well as code :)

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