[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_kno... http://www.channelregister.co.uk/2011/02/20/cobol_is_the_new_language_to_kno... -- View this message in context: http://forum.world.st/Cobol-is-the-new-language-to-know-tp3317188p3317188.ht... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Geert Claes [geert.wl.claes@gmail.com] Sent: Monday, February 21, 2011 6:35 AM To: pharo-project@lists.gforge.inria.fr 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_kno... http://www.channelregister.co.uk/2011/02/20/cobol_is_the_new_language_to_kno... -- View this message in context: http://forum.world.st/Cobol-is-the-new-language-to-know-tp3317188p3317188.ht... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
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 :) -- View this message in context: http://forum.world.st/Cobol-is-the-new-language-to-know-tp3317188p3317247.ht... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
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-lucract... 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-enterpris... HTH -- Cesar Rabak Em 21/02/2011 08:35, Geert Claes < geert.wl.claes@gmail.com > 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_kno... http://www.channelregister.co.uk/2011/02/20/cobol_is_the_new_language_to_kno... -- View this message in context: http://forum.world.st/Cobol-is-the-new-language-to-know-tp3317188p3317188.ht... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Em 21-02-2011 16:07, csrabak@bol.com.br 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-lucract... 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-enterpris...
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
Em 21/02/2011 18:05, Casimiro de Almeida Barreto < casimiro.barreto@gmail.com > escreveu:
Em 21-02-2011 16:07, csrabak@bol.com.br 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-lucract... 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-enterpris... 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
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? -- View this message in context: http://forum.world.st/Cobol-is-the-new-language-to-know-tp3317188p3318737.ht... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
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.
On Tue, Feb 22, 2011 at 7:12 AM, Casimiro de Almeida Barreto < casimiro.barreto@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 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. 2¢ 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.
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
On Tue, Feb 22, 2011 at 12:47 PM, Casimiro de Almeida Barreto < casimiro.barreto@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
+1 overall, and to seeking better socket streams. FFI+Callbacks too. ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Casimiro de Almeida Barreto [casimiro.barreto@gmail.com] Sent: Tuesday, February 22, 2011 3:47 PM To: Pharo-project@lists.gforge.inria.fr 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
participants (5)
-
Casimiro de Almeida Barreto -
csrabak＠bol.com.br -
Eliot Miranda -
Geert Claes -
Schwab,Wilhelm K