[Help-smalltalk] lessons from the python environment

[Robert Collins]

Just a few thoughts here... I've had to do a bunch of development in
python, and there are a few things they do that we might want to adapt.
No syntax or class changes - this is about the environment, not the
language.

So herewith are my ideas on 'import', editor-bindings, refactoring and
scripting use.

import:
Python has an import statement, which is roughly a fileIn: that searches
a defined search path for .py files.

The nice thing here is that the is an automatic Namespace creation:
import foo.bar
will look in the search patch for a directory called foo (with a
__init__.py file), parse that **into a new namespace 'foo'**, and then
if there is no bar symbol in the foo namespace, try to file in
foo/bar.py.

The effect this has on development is quite noticable: namespaces are
used much more often, the environment can automatically determine when
something needs filing in, and you don't need to manually create and
maintain a xml description of your package: you just put it in the right
subdir.

I'd like to propose we do something similar:
PackageLoader import: 'gtk' !
should look along a defined search path for a directory called gtk
containing a predefined filename, and then fileIn: that filename. My
eyes are adjusted to __init__.py now, but thats only because python has
problems and uses __foo__ to work around some of them :}. candidate
names that come to mind are 'package.st', 'module.st'. 

likewsie:
PackageLoader importAll !
should load every package it can find into the image. This would be
great for ensuring we refactor properly across defferent implementations
of things like Blox. We'd need to address some code warts to be able to
use this today :].

A default search path might be: the kernel directory, ~/smalltalk-
packages, /usr/share/gnu-smalltalk, /usr/share/gnu-smalltalk/site-
packages

This is particularly useful as you get third party modules, because they
can be trivially dropped on disk, and it all just works. The presence of
vm images only slightly reduces the utility: anyone working on a package
that needs to run as a script will appreciate this hugely.

editor-bindings:
we already have an emacs mode, but AFAIK thats the only editor we have
bindings too. Having (for instance) a vim-smalltalk, which can use gnu-
smalltalk as a coprocess could allow use to do something similar to what
'BicycleRepairMan' does. BRM is a refactoring toolkit for python, that
is able to be called into from vim, idle & emacs. Given the attachment
folk tend to get to their editor, allowing more folk to code in their
preferred environment, AND leverage smalltalk & the smalltalk tools in
their image would be fantastic. I think we are on the right path here
already.. just making a note of this.

refactoring:
I think gst suffers quite a bit not having a refactoring browser at the
moment. The sheer beauty of the language saves us. That said the python
community at large seems rather ignorant of refactoring: BRM is by no
means a common tool there, for all of its utility. One of the
opportunities I see for gnu-smalltalk is to be a scripting-language ..
with a ref-browser out of the box.

scripting use:
This is probably the biggest thing. pythons ability to be trivially used
for 'quick hack' scripts as well as long-lived server processes is one
of the things that seems to attract people. I know I find python easier
to do quick scripts in than gst - at the moment. This seems to me to be
driven by 2 things:
*) #!/bin line support: 
  rather than writing a wrapper script that calls gst with the right
packages & .st files to load, or that pipes stuff into gst, users just
create a file with #!/bin/env python at the top, and it just works. I'm
working on a patch to do this for gnu-smalltalk.
*) their 'import' system:
  the base python vm, in a similar way to the shipped gnu-smalltalk vm
does not have everything loaded into it, so within the script a
developer just imports what they need:
  import os
  import shutils 
etc. This means that they can change their required tools quickly on the
fly.. including packages they have in their home dir/working tree.. See
my first point for an equivalent thing we can use.

If we can make quick-n-dirty scripting easy to do using smalltalk, I
think it could really become useful to a bunch of folk that have been
scared off by the impression that its just a gui environment for
learning stuff in! (I've been told that by several folk ?!?). 

This of course presumes that making gst easier for folk to adopt is a
common thought here.. I haven't read enough of the lists to tell - so
flame away if needed :}.

Rob

signature.asc
Description: This is a digitally signed message part