Cobol is the new language to know?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Cobol is the new language to know?

Geert Claes
Administrator
I just cringed when I read: "The Sydney-based Object Consulting has released a paper detailing those languages which will no longer be supported in the near future, including the likes of .NET 2.0, J2SE 1.4 and Cold Fusion (according to Object Consulting they have a three-year shelf life), while anything on Smalltalk or FoxPro should be junked or moved to a new system immediately as a result of non-support and no further development of the environments."

http://www.channelregister.co.uk/2011/02/20/cobol_is_the_new_language_to_know/
Reply | Threaded
Open this post in threaded view
|

Re: Cobol is the new language to know?

Schwab,Wilhelm K
My favorite parts were:

“I have seen examples of developers on older technologies like RPG and Delphi charging twice the rate of a developer on a newer technology.“

Did it ever occur to them that some of these systems (e.g. Smalltalk) might actually be more productive and hence worth the boost in rate?  Most are just lean supply, but there is also the the power tool vs. hammer concept at work too.


"From the point of view of the companies and institutions, this is a problem. The longer they wait to modernise these systems, the more it is going to cost them when they do – for they will need experts in the old to explain what the heck the systems do to those attempting to modernise it."

Translation: programmers are too dumb to read anything they don't "know."  Give me well-written code in a language I've never seen over a mess in something I use every day.

Bill


________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Geert Claes [[hidden email]]
Sent: Monday, February 21, 2011 6:35 AM
To: [hidden email]
Subject: [Pharo-project] Cobol is the new language to know?

I just cringed when I read: "The Sydney-based Object Consulting has released
a paper detailing those languages which will no longer be supported in the
near future, including the likes of .NET 2.0, J2SE 1.4 and Cold Fusion
(according to Object Consulting they have a three-year shelf life), while
anything on Smalltalk or FoxPro should be junked or moved to a new system
immediately as a result of non-support and no further development of the
environments."

http://www.channelregister.co.uk/2011/02/20/cobol_is_the_new_language_to_know/
http://www.channelregister.co.uk/2011/02/20/cobol_is_the_new_language_to_know/
--
View this message in context: http://forum.world.st/Cobol-is-the-new-language-to-know-tp3317188p3317188.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.


Reply | Threaded
Open this post in threaded view
|

Re: Cobol is the new language to know?

Geert Claes
Administrator
Schwab,Wilhelm K wrote
My favorite parts were:

“I have seen examples of developers on older technologies like RPG and Delphi charging twice the rate of a developer on a newer technology.“

Did it ever occur to them that some of these systems (e.g. Smalltalk) might actually be more productive and hence worth the boost in rate?  Most are just lean supply, but there is also the the power tool vs. hammer concept at work too.
I thought that bit was interesting too.  I used to be a Powerbuilder (which Delphi and VB more or less copied) developer and moved away from it because contracts (even back then) were too few and far between to sustain a reasonable income, so they probably simply need to charge extra to cover for the periods between contracts :)
Reply | Threaded
Open this post in threaded view
|

Re: Cobol is the new language to know?

csrabak
In reply to this post by Geert Claes
Geert,

I'll use my consultant's hat to contribute on this.  My company lives from selling advice on these matters.

Notice that in the table of the referred link: http://www.theaustralian.com.au/australian-it/legacy-languages-prove-lucractive-for-dying-breed-of-programmers/story-e6frgakx-1225993874788 which you point to, Cobol and Smalltalk share the same status of "Retire Now".

So the Channel Register interpretation of the reports has not been that sharp at all.  Also, the company issuing the report is an Aussie centered firm, as the problems we're facing in the companies around the world (in the mainframe) is more what to do with the Natural/Adabas platform, where Natural is a higher level language than Cobol but has a high impedance for conversion to Java (w/o opening the can of worms of running Java in mainframes).

The FUD about Smalltalk going to become unsupported must be counteracted by the pertinent Organizations, like ESUG in Europe and STIC, and of course the Software companies themselves like VW and Instantiations.  When I worked at Gartner, they had a similar table which included Smalltalk in the doom-way in "five years" ca. Y2K and recently they changed their mind a little bit: http://blogs.gartner.com/mark_driver/2008/10/09/remember-smalltalk/ and http://news.squeak.org/2008/10/11/smalltalk-is-cool-again-says-gartner/ (just a sample, Google is your friend if you're really interested).

OTOH, notice that another Research company whose business is selling 'insight' says something about the primadonna du jour: http://www.cincomsmalltalk.com/main/2010/12/java-is-a-dead-end-for-enterprise-app-development/

HTH

--
Cesar Rabak



Em 21/02/2011 08:35, Geert Claes < [hidden email] > escreveu:

I just cringed when I read: "The Sydney-based Object Consulting has released
a paper detailing those languages which will no longer be supported in the
near future, including the likes of .NET 2.0, J2SE 1.4 and Cold Fusion
(according to Object Consulting they have a three-year shelf life), while
anything on Smalltalk or FoxPro should be junked or moved to a new system
immediately as a result of non-support and no further development of the
environments."

http://www.channelregister.co.uk/2011/02/20/cobol_is_the_new_language_to_know/
http://www.channelregister.co.uk/2011/02/20/cobol_is_the_new_language_to_know/ 
--
View this message in context: http://forum.world.st/Cobol-is-the-new-language-to-know-tp3317188p3317188.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.



Reply | Threaded
Open this post in threaded view
|

Re: Cobol is the new language to know?

CdAB63
Em 21-02-2011 16:07, [hidden email] escreveu:

> Geert,
>
> I'll use my consultant's hat to contribute on this.  My company lives from selling advice on these matters.
>
> Notice that in the table of the referred link: http://www.theaustralian.com.au/australian-it/legacy-languages-prove-lucractive-for-dying-breed-of-programmers/story-e6frgakx-1225993874788 which you point to, Cobol and Smalltalk share the same status of "Retire Now".
>
> So the Channel Register interpretation of the reports has not been that sharp at all.  Also, the company issuing the report is an Aussie centered firm, as the problems we're facing in the companies around the world (in the mainframe) is more what to do with the Natural/Adabas platform, where Natural is a higher level language than Cobol but has a high impedance for conversion to Java (w/o opening the can of worms of running Java in mainframes).
>
> The FUD about Smalltalk going to become unsupported must be counteracted by the pertinent Organizations, like ESUG in Europe and STIC, and of course the Software companies themselves like VW and Instantiations.  When I worked at Gartner, they had a similar table which included Smalltalk in the doom-way in "five years" ca. Y2K and recently they changed their mind a little bit: http://blogs.gartner.com/mark_driver/2008/10/09/remember-smalltalk/ and http://news.squeak.org/2008/10/11/smalltalk-is-cool-again-says-gartner/ (just a sample, Google is your friend if you're really interested).
>
> OTOH, notice that another Research company whose business is selling 'insight' says something about the primadonna du jour: http://www.cincomsmalltalk.com/main/2010/12/java-is-a-dead-end-for-enterprise-app-development/
>
> HTH
>
> --
> Cesar Rabak
>
>  
Thing about these tales of "dying languages" & stuff like that is that
it's really hard to avoid conflicting interests while judging things.

I remember the golden age of Microsoft and its happy marriage with
Intel, when companies (Gartner included) hammered execs minds with the
TOC mantra (Microsoft as opposed to Unix/Linux - OSX not available at
that time & Apple starving of Jobs). Following that line of reasoning,
by now Oracle would be history, Linux would be history and Apple would
be the only thing preventing Microsoft running into anti-trust laws.
Obviously history unrolled different ways...

I don't see smalltalk "retiring" or "going six palms down" because from
the corporate vantage point smalltalk just didn't happen (yet). IMO,
some things prevented smalltalk going main stream:

(a) bad marketing from smalltalk players
(b) Java happened and its shortcomings weren't evident to community from
the start but Sun put a real bunch of money in it.
(c) Microsoft had its own ideas about development platforms (C#, .net, etc)
(d) Nobody presented a (really) suitable solution to large scale
problems (performance, scalability, security, stability, etc), so
corporations kept relying on "traditional" solutions (like C, C++, etc).
(e) "Mainframe world" is a completely different breed.

What's happening is that "software development world" is getting short
of solutions to jump to next Fermi levels of systems development. Just a
little look in industry and it becomes really visible. Some development
cycles in "software consumer products" are exceeding five years & costs
are surpassing hundreds of millions of US$.

IMO smalltalk and/or its derivatives may fill important niches. But
wether this happens or not will depend on several things. The most
important of all is the availability of a clean open solution, coherent,
supported and fully documented. Currently there are two divergent
families of "open smalltalk":

(a) gnu smalltalk
(b) squeak/pharo/cuis

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.

One thing I don't (yet) like in pharo is that there's no easy way of
applying fixes. Would be nice to have an update mechanism automating (at
least) fixes installation. I think this kind of thing is important to
market acceptance of smalltalk.

CdAB

Reply | Threaded
Open this post in threaded view
|

Re: Cobol is the new language to know?

csrabak
Em 21/02/2011 18:05, Casimiro de Almeida Barreto < [hidden email] > escreveu:

> Em 21-02-2011 16:07, [hidden email] escreveu:
> > Geert,
> > I'll use  my consultant's  hat to contribute  on this.  My company
> > lives from selling advice on these matters.
> > Notice    that   in    the   table    of   the    referred   link:
> > http://www.theaustralian.com.au/australian-it/legacy-languages-prove-lucractive-for-dying-breed-of-programmers/story-e6frgakx-1225993874788
> > which you point  to, Cobol and Smalltalk share  the same status of
> > "Retire Now".
> > So the Channel Register interpretation of the reports has not been
> > that  sharp at all.  Also, the  company issuing  the report  is an
> > Aussie  centered  firm,  as  the  problems  we're  facing  in  the
> > companies around the  world (in the mainframe) is  more what to do
> > with the Natural/Adabas platform,  where Natural is a higher level
> > language than  Cobol but  has a high  impedance for  conversion to
> > Java (w/o opening the can of worms of running Java in mainframes).
> > The  FUD  about Smalltalk  going  to  become  unsupported must  be
> > counteracted by  the pertinent Organizations, like  ESUG in Europe
> > and STIC, and of course  the Software companies themselves like VW
> > and Instantiations. When  I worked at Gartner, they  had a similar
> > table  which included Smalltalk  in the  doom-way in  "five years"
> > ca.  Y2K  and recently  they  changed  their  mind a  little  bit:
> > http://blogs.gartner.com/mark_driver/2008/10/09/remember-smalltalk/
> > and
> > http://news.squeak.org/2008/10/11/smalltalk-is-cool-again-says-gartner/
> > (just  a   sample,  Google  is   your  friend  if   you're  really
> > interested).
> > OTOH,  notice  that another  Research  company  whose business  is
> > selling  'insight' says  something about  the primadonna  du jour:
> > http://www.cincomsmalltalk.com/main/2010/12/java-is-a-dead-end-for-enterprise-app-development/
> > HTH
> >
> > -- Cesar Rabak
> >
>
> Thing about  these tales of "dying  languages" & stuff  like that is
> that it's  really hard to avoid conflicting  interests while judging
> things.
>
> I remember the  golden age of Microsoft and  its happy marriage with
> Intel, when  companies (Gartner included) hammered  execs minds with
> the  TOC  mantra (Microsoft  as  opposed  to  Unix/Linux -  OSX  not

I think you mean "TCO" here ;-)

> available at  that time  & Apple starving  of Jobs).  Following that
> line of  reasoning, by now Oracle  would be history,  Linux would be
> history  and Apple  would  be the  only  thing preventing  Microsoft
> running into anti-trust  laws.  Obviously history unrolled different
> ways...

From a point of view of corporate IT, Apple _is_ history and Linux is
only present in appliances.  No tsunami happened in the server
industry that shakes Microsoft dominance...  In fact, Linux was the
great bogeyman for Unix flavours.

Yes it unrolled different in the details, but quite much as advertised
:-)

>
> I don't see  smalltalk "retiring" or "going six  palms down" because
> from  the  corporate  vantage  point smalltalk  just  didn't  happen
> (yet).

Well, it happened at its time, but didn't got enough momentum to
become the COBOL of OO languages.

> IMO, some things prevented smalltalk going main stream:
>
> (a) bad marketing from smalltalk players

I think we can agree on this.

> (b) Java happened and its shortcomings weren't evident to community from
> the start but Sun put a real bunch of money in it.

Also, the moment in history and the way as the language was deployed
(no competing flavours or dialects, etc.) was different than when
Smalltalk was introduced.

Java was mainly a means to program in OO, while Smalltalk had to
convince people of way different paradigm, and learn a language.

> (c) Microsoft had its own ideas about development platforms (C#, .net, etc)

Of course!  They make a living selling proprietary stuff! Eons ago,
they got rid of their COBOL business, they Fortran business, etc.
They attempted to 'embrace and extend' Java and when it backfired they
got rid of "VisualJ" and went .Net...

> (d) Nobody presented a (really) suitable solution to large scale
> problems (performance, scalability, security, stability, etc), so
> corporations kept relying on "traditional" solutions (like C, C++,
> etc).

Yep, in the nineties all the Smalltalk projects that I had crossed
were of the nature more or less: "...we've this solution developed in
Smalltalk and need to port to C++ in order to solve the __ problem,
where the blank is one of the above plus some other created by
management.

> (e) "Mainframe world" is a completely different breed.

Yup.

> What's  happening is  that "software  development world"  is getting
> short  of  solutions  to  jump  to  next  Fermi  levels  of  systems
> development. Just  a little look  in industry and it  becomes really
> visible. Some development cycles in "software consumer products" are
> exceeding five years & costs  are surpassing hundreds of millions of
> US$.

Yes.

> IMO smalltalk and/or its  derivatives may fill important niches. But
> wether this happens  or not will depend on  several things. The most
> important  of all  is the  availability  of a  clean open  solution,
> coherent, supported  and fully  documented. Currently there  are two
> divergent families of "open smalltalk":
>
> (a) gnu smalltalk
> (b) squeak/pharo/cuis
>

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

> One thing I don't (yet) like in pharo is that there's no easy way of
> applying fixes. Would be nice to have an update mechanism automating
> (at  least)  fixes installation.  I  think  this  kind of  thing  is
> important to market acceptance of smalltalk.
>

?

--
Cesar Rabak

Reply | Threaded
Open this post in threaded view
|

Re: Cobol is the new language to know?

Geert Claes
Administrator
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?
Reply | Threaded
Open this post in threaded view
|

Re: Cobol is the new language to know?

CdAB63
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

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.

Reply | Threaded
Open this post in threaded view
|

Re: Cobol is the new language to know?

Eliot Miranda-2


On Tue, Feb 22, 2011 at 7:12 AM, Casimiro de Almeida Barreto <[hidden email]> 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 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).

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.

Eliot


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.


Reply | Threaded
Open this post in threaded view
|

Re: Cobol is the new language to know?

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

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


Reply | Threaded
Open this post in threaded view
|

Re: Cobol is the new language to know?

Eliot Miranda-2


On Tue, Feb 22, 2011 at 12:47 PM, Casimiro de Almeida Barreto <[hidden email]> 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
>
>



Reply | Threaded
Open this post in threaded view
|

Re: Cobol is the new language to know?

Schwab,Wilhelm K
In reply to this post by CdAB63
+1 overall, and to seeking better socket streams.  FFI+Callbacks too.  




________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Casimiro de Almeida Barreto [[hidden email]]
Sent: Tuesday, February 22, 2011 3:47 PM
To: [hidden email]
Subject: Re: [Pharo-project] Cobol is the new language to know?

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.

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



Reply | Threaded
Open this post in threaded view
|

Re: Cobol is the new language to know?

umer001
This post has NOT been accepted by the mailing list yet.
In reply to this post by Geert Claes
cobol is one of the important language and it is 85% of the mainframe language
so if you are intersted in mainframe then you have to learn cobol
many programes are developed in cobol language