Home Original page

Smalltalk and Python

Oldayz sill at localhost.kitenet.net
Wed Dec 13 22:39:15 EST 2000 
On 13 Dec 2000 16:16:06 -0500, David Bolen <db3l at fitlinxx.com> wrote:
>Aaron Jon Reichow <reichowa at tcfreenet.org> writes:
>
>> On 13 Dec 2000, Erno Kuusela wrote:
>> 
>> > the thing that struck me as a little foreign was the apparent
>> > isolation of the smalltalk image from the rest of the operating system
>> > and the filesystem. i want to be able to grep code!
>> 
>> While I'm not a proponent of Smalltalk isolationism, grep is a useless
>> tool (more or less), simply an artifact, ye, a symptom of the
>> sickness known as file-based development.
>
>I'm not sure I'd call it a "sickness" since any development model is
>just that - a model - it may be better or worse than some other model,
>but at least for me, a file-based model works well in many cases.
>
>My biggest problem with the integrated models (with database or other
>repository back-ends) tends to be that often they aren't yet fleshed
>out enough, or in many cases flexible enough, to replicate all the
>functionality I can get out of a file based system with a current
>collection of file based tools that have had lots of time to evolve
>for efficiency and flexibility.
>
>With file-based environments, I generally feel safe that if the
>environment itself doesn't support something, there are enough tools
>that understand the back-end repository (e.g., files) that I can get
>what I want even if I have to go outside the integrated system.  That
>may not be possible with a closed back-end repository.
>
>As was noted elsewhere in this thread, and to tie a little more back
>into Python, this can also be an issue with Zope.  For example, Zope
>may provide grep-like functionality that works through the object
>store, but it may be difficult to replicate what in a filesystem might
>be a grep piped into an awk to produce summary information.  Now maybe
>the right answer is that the same functionality should be done in some
>other manner with Zope, but it may also be a point of needed
>functionality just not yet being supported by the development model.
>(I know in my case there's also a little "queasiness" just because of
>a feeling of lack of control over the store, which I think is just an
>side-effect of my primary file-based focus for so long).
>
>But if the repository model is flexible enough to permit the eventual
>creation of the smaller tools and then their coupling on an as-need
>basis (which Zope may well be for example), then it's more a question
>of a minimal set of functionality to feel comfortable to those of us
>more used to the file system and utilities and tools that we've gained
>proficiency in - that tool proficiency generally leading to
>development efficiency.
>
>--
>-- David

On a related note, I personally dislike IDE/integrated
approach because of exactly one example of missing
functionality you're talking about - I'm addicted
to vi(m) commands, and I can't imagine working with
large bodies of text with regular pico-style commands
(or even emacs-style). Slrn and mutt can both pass on
the task of editing to vim so this approach is really
flexible. Besides, vim supports python as a scripting
language.


-- 

	Andrei
More information about the Python-list mailing list