[Pharo-project] Cobol is the new language to know?

Eliot Miranda eliot.miranda at gmail.com
Tue Feb 22 18:58:52 CET 2011

On Tue, Feb 22, 2011 at 7:12 AM, Casimiro de Almeida Barreto <
casimiro.barreto at gmail.com> wrote:

> Em 22-02-2011 05:12, Geert Claes escreveu:
> >
> > csrabak wrote:
> >>> Focusing in  the squeak/pharo/cuis  branch, I've noticed  that pharo
> >>> people got really concerned in
> >>> aspects that  can attract  market interest.   They're looking for
> >>> funding, fighting  to have "hired
> >>> people" (meaning under wages) minding "hairy  aspects" of development,
> >>> maintenance, documentation
> >>> and some sort of "standardization", etc. Collaborators also produced
> >>> interesting "printed material" (books,
> >>> tutorials) but IMO such material is still very academic in nature.
> People
> >>> in industry likes best "manual"
> >>> stuff  (like "foundation  classes" with  "methods" (messages  in the
> >>> case) documented,  etc). IMO (again)
> >>> here lies a  relevant problem: there  are "no foundation  classes" (no
> >>> "landmarks" or things that cannot  be  > easily changed) and it becomes
> >>> apparent when people exchange ideas  about "keeping this"  and "getting
> >>> rid of that". At least debate is going on and many issues have been
> >>> addressed.
> >>
> >> Yes.
> >>
> > I don't understand what was said here?  Can someone elaborate?
> In order to increase acceptance of smalltalk in corporate world (and
> even in academic and scientific worlds) someone (pharo/squeak/cuis
> people) must come out with a solution that:
> 1) Is well documented
> 2) Is supported
> 3) Is stable

IMO, while important,  this misses the most important features which
together provide a useful platform:

1. excellent FFI (including threading support) so that the system can be
integrated with other code, both as a user of libraries and as a provider of
2. support for foreign files in Monticello so that Monticello can be used to
manage complete projects, not just the Smalltalk assets
3. scripting and excellent file system facilities so that one can easily
interact with the file system, still a vital part of the majority of
software systems (the Squeak file system code is a cruel joke, still
resembling the original Smalltalk-80 code from the late 70's).

Without the necessary functionality people simply can't use Squeak to
produce their applications and are forced to choose something else.  These
features, along with good web support, are what I understand by "platform".
 The web support is also pretty good, with Seaside, SSL, ODBC, HTTP
connectivity, etc being pretty good.  The community has made excellent
progress over recent years.  The "well documented", "supported" and stable"
features are not terrible.  Yes they can always be improved but on the whole
that's not the fundamental block to effective use of Squeak/Pharo.

Performance is also not an issue to getting started; plenty of Ruby and PHP
projects sow that one can tackle performance later on.

Fundamental is providing a platform and we're not there yet.


> To be well documented (in the sense corporate world understands it) a
> smalltalk distro must:
> 1) Have a body (a set of) classes that are considered "foundation
> classes". Those must be present in all versions of the distribution and
> must have an unchanging set of features (in the case of smalltalk: an
> unchanging set of messages,considering instance and class variables are
> available through assessors). Those foundation classes must cover a
> range of functionalities that makes the distro useful.
> 2) These foundation classes must be documented in a way that resembles,
> at least, man pages of *nix (syntax, semantics, dependencies, known
> bugs, exceptions, etc)
> 3) Foundation classes should be arranged in "orthogonal" packages
> (meaning: if I unload one package everything that doesn't depend on it
> still works). Anyways, dependencies should be documented in a very clear
> and explicit way.
> Just to give an example on how lack of documentation hurts open
> smalltalk, how many people gave it up for not  being able to deliver
> acceptable interfaces because Morphic is hideously documented? I know
> several ones. In real corporate world, learning through trial and error
> is not acceptable, just like blowing schedule up due to the need to
> figure out by experience how ProportionalLayout works neither...
> To be supported there must be people in charge of:
> 1) Debugging and fixing it (inside a well known schedule & following an
> agreed maintenance protocol)
> 2) Elaborating suitable documentation (as described above)
> 3) Preparing didactic material (courses, books, etc)
> 4) Disseminating information of what's going on inside distro's
> development (much in the way Ubuntu/Fedora/etc communities do)
> Stable is stable...
> There are other things that are important but IMO they all come after
> ones I just wrote about.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gforge.inria.fr/pipermail/pharo-project/attachments/20110222/4f49fe9e/attachment.htm>

More information about the Pharo-project mailing list