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

Eliot Miranda eliot.miranda at gmail.com
Tue Feb 22 22:55:09 CET 2011


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

> Em 22-02-2011 14:58, Eliot Miranda escreveu:
> >
> >
> > (...)
> >
> > 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 libraries
> > 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).
>



> +1 here. (1) and (3) are really important. I'd add enhancing network
> streams too.
> One thing that's overseen but is extremely important for developing
> commercial software is full internationalization support (like i18n) and
> its a major task since large sections of "foundation classes"
> (TimeAndDate for instance) would have to be adapted/changed.
>

Agreed.  I knew I didn't have a complete list :)  Where is there a good
place to list what work towards a platform needs to be done?  I'm not sure
that the 4Gb limit is a block to many projects.  It's certainly important to
some.  But I think it can be excluded from the must-have platform
requirements.  A native 64-bit implementation is probably ore important, and
is an aspect of the FFI, i.e. the ability to interface with 64-bit
libraries.

Sp so far we have

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
libraries

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

4. excellent internationalization support




> > 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.
> Performance is a relative thing. As far as there are no limitations to
> performance imposed by VM (and squeakvm/cogvm are really generous),
> things can be continually improved.
>
> There's one aspect of performance that can be an important show stopper
> for pharo/squeak/cog: memory usage ceil at 4GBytes.
>
> > Fundamental is providing a platform and we're not there yet.
> >
> > 2¢
> > Eliot
> >
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gforge.inria.fr/pipermail/pharo-project/attachments/20110222/28262be2/attachment.htm>


More information about the Pharo-project mailing list