December 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [Progress Report] Zinc HTTP Components

by Sven Van Caekenberghe

Norbert, Thanks for you interest. On 07 Dec 2010, at 21:14, Norbert Hartl wrote: > I scanned the code a few days ago. I tried an initial port to gemstone. There are quite a few things to do. After discovering that there are really big changes from version to version and the existence of classes with suffixes Old and New made me stop the effort. I'm really missing a usable http client in gemstone but it seemed to be very hard to keep up with the port. This should be much better now: the whole confusion is now gone (the 'Old' categories and classes were moved into a separate MC package that should not be loaded unless you want to do historical research; the 'New' has been removed from existing categories). Please have another look. I assume that you have read the overview and getting started pages (http://homepage.mac.com/svc/Zinc-HTTP-Components) The category 'Zinc-HTTP-Core' contains a object model of the key building blocks of the HTTP protocol. Except for learning and teaching, this is not useful on itself. Building on top of the core are the classes in 'Zinc-HTTP-Server' for various clients and servers. The category 'Zinc-HTTP-Support' contains helpers for the implementation, many of which can be considered portability enablers (much like Seaside has them). Now, why is there not just one good client, why are there 4 different ones ? Because different users have different requirements, because each of them has different features, complexity and above all, a different interface. Part of this is also a search for the ideal API. ZnClient is the simplest one: some class methods to fire off one shot requests. ZnFixedClient is useful to connect to a single server and reuse the connection for multiple requests, like with a web services API. ZnHttpClient is a builder like interface (think of Gofer), it also has some extra features. ZnHTTPSocketFacade is a replacement for the current Pharo/Squeak HTTPSocket API. In my development images, this is active, which means that all HTTP functionality (for MC for example) is handled by Zinc HTTP - a case of eating my own dog food. On the server side there is ZnServer which can be customized with a delegate and authorizer. A static web file server, a Monticello server as well as a Seaside adaptor are available. > Do you port an existing library to smalltalk or do you figure out how it should be done right now? And what do you think about going towards cross-platform? This would need a decision if you are willing to integrate grease/sport in your client. I can imagine that this is not wanted per se because it introduces dependencies. It will be just very hard to do it cross-platform if you do not. The first goal of Zinc HTTP is to be useful for Pharo, to replace existing HTTP functionality in the image. Hence portability is not high on the list. Like you said, building on top of a portability layer would mean external dependencies that would most probably conflict with the first goal. But I am not against portability (most of the code except for some obvious missing crypto stuff still runs on Squeak as well). We can always try to find a solution. Regards, Sven

Dec. 8, 2010

[Pharo-project] Hudson and version number

by Luc Fabresse

Hi all, I was looking the results of the 1.2 build #33. https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.2/33/ Where is displayed the version number of the 1.2 used for this build? Was it the12271? Thanks, #Luc

Dec. 8, 2010

Re: [Pharo-project] Popularity or not of smalltalk?

by laurent laffont

Thank you Jimmie, I've enjoyed your mail. And as a "little guy in the enterprise who has small side projects", I feel Pharo is better week after week and this is good. Laurent On Wed, Dec 8, 2010 at 2:21 AM, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: > On 12/7/2010 5:38 PM, csrabak(a)bol.com.br wrote: > >> Sean, >> >> Hope that additional to the fun, we can converge to an understanding how >> can we increase Smalltalk popularity. >> >> OTOH, I made the reference as a sample, I did not intend to have this as >> all encompassing list of issues nor start a thread about comparisons with >> other languages. >> >> As I said earlier, what is 'trivial' or 'intuitive' for some is 'maverick' >> or 'bizarre' for others, it is in the eyes of the beholder... ;-) >> >> My main message is more around this: although Smalltalk was a very >> advanced technology when its inception, present status have almost all of >> its characteristics embedded in present technology. Even, when newer >> concepts as xUnit have started in Smalltalk, the _concept_ was absorbed in >> mainstream technologies so again we're stuck with small delta between what >> Smalltalk does 'better' than the incumbent technologies we would like to >> replace. >> > > I can't help but disagree with this most strenuously. > > Almost nothing has touched Smalltalk's advanced technology. They don't have > the world view or paradigm for doing so. They are languages that operate in > dead cycles. They have dead processes and do dead post mortem debugging. > Yuck! (yes, I know that was redundant. :) > > I am not a computer scientist or trained programmer. I am a creative guy > who is a businessman. I find Smalltalk empowering. I also use Python when > necessary, but Squeak/Pharo is my preferred language. I find myself > infinitely more productive in Smalltalk than in Python. Operating in a live > environment is incredibly empowering, enabling and productive. Where else > can I find this. C, C++, C#, Java, Python, Ruby, VB, nope, none... > > Demonstrating large scale Smalltalk projects have been canceled does not > prove Smalltalk's inferiority, nor that the competition (should one choose > to refer to them as such) has caught up or passed us. Especially when said > project was not canceled for technical reasons but political ones and for > software that was/is demonstrably inferior to the already existing Smalltalk > software. But what it does prove is that Smalltalk has been and can be > effectively deployed for large scale projects where someone has the courage > or political will to choose something different than the status quo > languages. > > The decisions of PHBs (Pointy Haired Bosses, Dilbert) does not invalidate > anything about Smalltalk. After all their primary motivation is job > security, not project success. No one ever got fired for choosing, MS, Java, > IBM, Oracle, etc... > > The biggest weakness for Smalltalk or at least our open source version in > Squeak/Pharo IMHO is its integration, cooperation or access story to certain > outside systems and technologies. And I speak as an end user who cannot > develop a plugin, or use Alien or FFI and program in C. In my situation for > example. I have to interface to either a Windows dll or to a Java library to > access financial servers. No choice. So I must choose a technology which can > interface their technology. In my case, I chose to use Python to interface > the Windows dll. I have written a minimal Python app which accesses the dll > and thus the servers to access the data and my accounts. But the business > logic I am writing in Pharo. The Python app simply provides my Pharo app the > data and executes the actions directed by the Pharo app. > > I would that I could have interfaced the dll (or Java library) directly > from Pharo. But despite that obstacle I am choosing to write my app in > Pharo. Most in this business are using VB/C#/Java. They do not provide the > flexibility or productivity that I have in Pharo/Smalltalk. They do not > enable the small guy like me as well as Pharo/Smalltalk. Yes, this is my > opinion. But guess what. This is a Pharo mailing list populated by people > who are for and proponents of Smalltalk. If we favored other languages and > environments we would be there. Many of those on the this list are also > pretty dog gone expert in the other technologies as well. They did not make > their decisions out of ignorance. What I don't understand is that if you are > so convinced that the advantages of Smalltalk are so minimal and of no > consequence, then why are you here? > > I would like to see Pharo/Squeak bridge the gap to be able to interface > system components or other business libraries. I would like to be able to > use Pharo/Squeak anywhere I could use Python. I would like to see that there > are fewer and fewer technical reasons for not choosing Pharo/Squeak. I can > understand other choices. Other people are more comfortable with other > languages, systems, environments. They may have a knowledge, systems, and > process investment. But this can only validate their decision for them and > in no way invalidates the technology or capabilities of Smalltalk. > > There are many, many projects for which Smalltalk/Pharo/Squeak have no > discernible technological disadvantages. They do not require any systems > integration or use of the "native ui". > > Enterprise. I agree with the sentiment that we don't need to worry about > it. Let Cincom address enterprise users. We need to empower the little guy > in the enterprise who has small side projects which do not have to go > through the same channels as the larger "enterprise" projects. Projects for > which they might choose Python or Ruby. Over time we can improve our > enterprise story and infiltration. Fortunately for us, > Smalltalk/Squeak/Pharo is in the long game. It has seen technologies come > and go and is still here. If we the open source Smalltalk community continue > to make the improvements we are making, then we will be an increasingly > viable choice for the entrepreneur, small businessman, enterprise guy with > the side project, the person with a project they do on their personal time > at home. It is the most enabling technology I know. > > Well, I'll end my rant here and get back to being enabled in the > development of my business app. > > Jimmie > >

Dec. 8, 2010

Re: [Pharo-project] Issue 3385 in pharo: TextEditor doest not understand #model

by Alain Plantec

I agree with Levente. The basic completion (cmd-q) is also only usable with a SmalltalkEditor. Cheers Alain Le 08/12/2010 03:58, Levente Uzonyi a Ã©crit : > On Wed, 8 Dec 2010, Francisco Ortiz Pe?aloza wrote: > >> So Levente you're saying that given the following use case you musn't >> add >> #model to TextEditor but change TextEditor collaboration with an >> instance of >> SmalltalkEditor >> >> OCompletion works well to edit code in the system browser as is, the DNU >> occurs when as an example you do a class find (Cmd+f) on >> SystemBrowser and >> you start typing on that "Class name or fragment" window looking for >> something. > > Adding the accessor is fine of course, it may be useful for other > things too. I'm saying that OCompletion is intended to work in places > where code completion is necessary and those places are usually > SmalltalkEditors. There are two things to think about: > - should OCompletion be used in that panel? > - should that panel use TextEditor instead of SmalltalkEditor? > > Btw using the latest version of PharoCore (12271) I can't reproduce > the error in the way you described it. > > > Levente > >> >> Cheers, >> Francisco >> >> On Tue, Dec 7, 2010 at 9:07 PM, Levente Uzonyi <leves(a)elte.hu> wrote: >> >>> On Tue, 7 Dec 2010, pharo(a)googlecode.com wrote: >>> >>> Status: Accepted >>>> Owner: guillermopolito >>>> >>>> New issue 3385 by guillermopolito: TextEditor doest not understand >>>> #model >>>> http://code.google.com/p/pharo/issues/detail?id=3385 >>>> >>>> The accessor should be added to load last version of OCompletion in >>>> Core >>>> 1.2 >>>> >>>> >>>> >>> OCompletion shouldn't be used in a TextEditor. OCompletion is for >>> Smalltalk >>> code completion, while TextEditor is intended to be a text editor (ask >>> Juan). That's why OCompletion adds the model accessor to >>> SmalltalkEditor and >>> not to TextEditor. >>> >>> >>> Levente >>> >>> >> > >

Dec. 8, 2010

Re: [Pharo-project] Popularity or not of smalltalk?

by Schwab,Wilhelm K

I have generally been able to connect to things. The ODBC package works quite well. We have some room to grow with handling of structure fields (Dolphin does a really nice job of it). Dolphin also leads Squeak/Pharo in being able to make calls on separate OS threads (which can be VERY useful). Dolphin handles callbacks out of the box, but as Eliot says, those things are in works. We need a solid DoubleArray. Networking was going to be the second thing I would start to use heavily; ironically, other things keep getting in line in front of it. Seaside and MC/Gofer seem to make good use of sockets, but I have not (yet) been able to really pound them in my own code. I send some SMTP messages, and I have one small TCP server that has been good to us. My backup plan was to do do the job in Dolphin, but I didn't need to run home. As for being eager to impress "Enterprises," I'm not really, but would not be bothered if we could do so without losing Smalltalk's strengths in the process. I think it's not so much that we should not care to impress them, but that we might never be able to do so (in most cases). I think Pharo has the potential to become the "gcc of Smalltalk." We might land a big fish or two some day. My usual concern stands: errors and broken and missing features are one thing, but, failures must be reported as exceptions and/or logged. For VM level things where exceptions might be overkill or destabilizing, rotating logs could be helpful while keeping storage use to a low roar. Jimmie, rant on, and good luck! Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of David T. Lewis [lewis(a)mail.msen.com] Sent: Tuesday, December 07, 2010 9:16 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Popularity or not of smalltalk? Bravo, well and truly stated. (I can't help but wonder how many folks who talk about this stuff have actually encountered an "Enterprise" in real life, and if so why they are still so eager to impress these people, much less go to work for them.) Thanks Jimmy, you have captured a lot of positive energy in a few words. Dave On Tue, Dec 07, 2010 at 07:21:58PM -0600, Jimmie Houchin wrote: > On 12/7/2010 5:38 PM, csrabak(a)bol.com.br wrote: > >Sean, > > > >Hope that additional to the fun, we can converge to an understanding how > >can we increase Smalltalk popularity. > > > >OTOH, I made the reference as a sample, I did not intend to have this as > >all encompassing list of issues nor start a thread about comparisons with > >other languages. > > > >As I said earlier, what is 'trivial' or 'intuitive' for some is 'maverick' > >or 'bizarre' for others, it is in the eyes of the beholder... ;-) > > > >My main message is more around this: although Smalltalk was a very > >advanced technology when its inception, present status have almost all of > >its characteristics embedded in present technology. Even, when newer > >concepts as xUnit have started in Smalltalk, the _concept_ was absorbed in > >mainstream technologies so again we're stuck with small delta between what > >Smalltalk does 'better' than the incumbent technologies we would like to > >replace. > > I can't help but disagree with this most strenuously. > > Almost nothing has touched Smalltalk's advanced technology. They don't > have the world view or paradigm for doing so. They are languages that > operate in dead cycles. They have dead processes and do dead post mortem > debugging. Yuck! (yes, I know that was redundant. :) > > I am not a computer scientist or trained programmer. I am a creative guy > who is a businessman. I find Smalltalk empowering. I also use Python > when necessary, but Squeak/Pharo is my preferred language. I find myself > infinitely more productive in Smalltalk than in Python. Operating in a > live environment is incredibly empowering, enabling and productive. > Where else can I find this. C, C++, C#, Java, Python, Ruby, VB, nope, > none... > > Demonstrating large scale Smalltalk projects have been canceled does not > prove Smalltalk's inferiority, nor that the competition (should one > choose to refer to them as such) has caught up or passed us. Especially > when said project was not canceled for technical reasons but political > ones and for software that was/is demonstrably inferior to the already > existing Smalltalk software. But what it does prove is that Smalltalk > has been and can be effectively deployed for large scale projects where > someone has the courage or political will to choose something different > than the status quo languages. > > The decisions of PHBs (Pointy Haired Bosses, Dilbert) does not > invalidate anything about Smalltalk. After all their primary motivation > is job security, not project success. No one ever got fired for > choosing, MS, Java, IBM, Oracle, etc... > > The biggest weakness for Smalltalk or at least our open source version > in Squeak/Pharo IMHO is its integration, cooperation or access story to > certain outside systems and technologies. And I speak as an end user who > cannot develop a plugin, or use Alien or FFI and program in C. In my > situation for example. I have to interface to either a Windows dll or to > a Java library to access financial servers. No choice. So I must choose > a technology which can interface their technology. In my case, I chose > to use Python to interface the Windows dll. I have written a minimal > Python app which accesses the dll and thus the servers to access the > data and my accounts. But the business logic I am writing in Pharo. The > Python app simply provides my Pharo app the data and executes the > actions directed by the Pharo app. > > I would that I could have interfaced the dll (or Java library) directly > from Pharo. But despite that obstacle I am choosing to write my app in > Pharo. Most in this business are using VB/C#/Java. They do not provide > the flexibility or productivity that I have in Pharo/Smalltalk. They do > not enable the small guy like me as well as Pharo/Smalltalk. Yes, this > is my opinion. But guess what. This is a Pharo mailing list populated by > people who are for and proponents of Smalltalk. If we favored other > languages and environments we would be there. Many of those on the this > list are also pretty dog gone expert in the other technologies as well. > They did not make their decisions out of ignorance. What I don't > understand is that if you are so convinced that the advantages of > Smalltalk are so minimal and of no consequence, then why are you here? > > I would like to see Pharo/Squeak bridge the gap to be able to interface > system components or other business libraries. I would like to be able > to use Pharo/Squeak anywhere I could use Python. I would like to see > that there are fewer and fewer technical reasons for not choosing > Pharo/Squeak. I can understand other choices. Other people are more > comfortable with other languages, systems, environments. They may have a > knowledge, systems, and process investment. But this can only validate > their decision for them and in no way invalidates the technology or > capabilities of Smalltalk. > > There are many, many projects for which Smalltalk/Pharo/Squeak have no > discernible technological disadvantages. They do not require any systems > integration or use of the "native ui". > > Enterprise. I agree with the sentiment that we don't need to worry about > it. Let Cincom address enterprise users. We need to empower the little > guy in the enterprise who has small side projects which do not have to > go through the same channels as the larger "enterprise" projects. > Projects for which they might choose Python or Ruby. Over time we can > improve our enterprise story and infiltration. Fortunately for us, > Smalltalk/Squeak/Pharo is in the long game. It has seen technologies > come and go and is still here. If we the open source Smalltalk community > continue to make the improvements we are making, then we will be an > increasingly viable choice for the entrepreneur, small businessman, > enterprise guy with the side project, the person with a project they do > on their personal time at home. It is the most enabling technology I know. > > Well, I'll end my rant here and get back to being enabled in the > development of my business app. > > Jimmie

Dec. 8, 2010

Re: [Pharo-project] Popularity or not of smalltalk?

by Jimmie Houchin

Dec. 8, 2010

Re: [Pharo-project] Issue 3385 in pharo: TextEditor doest not understand #model

by Levente Uzonyi

On Wed, 8 Dec 2010, Francisco Ortiz Pe?aloza wrote: > So Levente you're saying that given the following use case you musn't add > #model to TextEditor but change TextEditor collaboration with an instance of > SmalltalkEditor > > OCompletion works well to edit code in the system browser as is, the DNU > occurs when as an example you do a class find (Cmd+f) on SystemBrowser and > you start typing on that "Class name or fragment" window looking for > something. Adding the accessor is fine of course, it may be useful for other things too. I'm saying that OCompletion is intended to work in places where code completion is necessary and those places are usually SmalltalkEditors. There are two things to think about: - should OCompletion be used in that panel? - should that panel use TextEditor instead of SmalltalkEditor? Btw using the latest version of PharoCore (12271) I can't reproduce the error in the way you described it. Levente > > Cheers, > Francisco > > On Tue, Dec 7, 2010 at 9:07 PM, Levente Uzonyi <leves(a)elte.hu> wrote: > >> On Tue, 7 Dec 2010, pharo(a)googlecode.com wrote: >> >> Status: Accepted >>> Owner: guillermopolito >>> >>> New issue 3385 by guillermopolito: TextEditor doest not understand #model >>> http://code.google.com/p/pharo/issues/detail?id=3385 >>> >>> The accessor should be added to load last version of OCompletion in Core >>> 1.2 >>> >>> >>> >> OCompletion shouldn't be used in a TextEditor. OCompletion is for Smalltalk >> code completion, while TextEditor is intended to be a text editor (ask >> Juan). That's why OCompletion adds the model accessor to SmalltalkEditor and >> not to TextEditor. >> >> >> Levente >> >> >

Dec. 8, 2010

Re: [Pharo-project] Issue 3385 in pharo: TextEditor doest not understand #model

by Francisco Ortiz PeÃ±aloza

So Levente you're saying that given the following use case you musn't add #model to TextEditor but change TextEditor collaboration with an instance of SmalltalkEditor OCompletion works well to edit code in the system browser as is, the DNU occurs when as an example you do a class find (Cmd+f) on SystemBrowser and you start typing on that "Class name or fragment" window looking for something. Cheers, Francisco On Tue, Dec 7, 2010 at 9:07 PM, Levente Uzonyi <leves(a)elte.hu> wrote: > On Tue, 7 Dec 2010, pharo(a)googlecode.com wrote: > > Status: Accepted >> Owner: guillermopolito >> >> New issue 3385 by guillermopolito: TextEditor doest not understand #model >> http://code.google.com/p/pharo/issues/detail?id=3385 >> >> The accessor should be added to load last version of OCompletion in Core >> 1.2 >> >> >> > OCompletion shouldn't be used in a TextEditor. OCompletion is for Smalltalk > code completion, while TextEditor is intended to be a text editor (ask > Juan). That's why OCompletion adds the model accessor to SmalltalkEditor and > not to TextEditor. > > > Levente > >

Dec. 8, 2010

Re: [Pharo-project] Popularity or not of smalltalk?

by David T. Lewis

Bravo, well and truly stated. (I can't help but wonder how many folks who talk about this stuff have actually encountered an "Enterprise" in real life, and if so why they are still so eager to impress these people, much less go to work for them.) Thanks Jimmy, you have captured a lot of positive energy in a few words. Dave On Tue, Dec 07, 2010 at 07:21:58PM -0600, Jimmie Houchin wrote: > On 12/7/2010 5:38 PM, csrabak(a)bol.com.br wrote: > >Sean, > > > >Hope that additional to the fun, we can converge to an understanding how > >can we increase Smalltalk popularity. > > > >OTOH, I made the reference as a sample, I did not intend to have this as > >all encompassing list of issues nor start a thread about comparisons with > >other languages. > > > >As I said earlier, what is 'trivial' or 'intuitive' for some is 'maverick' > >or 'bizarre' for others, it is in the eyes of the beholder... ;-) > > > >My main message is more around this: although Smalltalk was a very > >advanced technology when its inception, present status have almost all of > >its characteristics embedded in present technology. Even, when newer > >concepts as xUnit have started in Smalltalk, the _concept_ was absorbed in > >mainstream technologies so again we're stuck with small delta between what > >Smalltalk does 'better' than the incumbent technologies we would like to > >replace. > > I can't help but disagree with this most strenuously. > > Almost nothing has touched Smalltalk's advanced technology. They don't > have the world view or paradigm for doing so. They are languages that > operate in dead cycles. They have dead processes and do dead post mortem > debugging. Yuck! (yes, I know that was redundant. :) > > I am not a computer scientist or trained programmer. I am a creative guy > who is a businessman. I find Smalltalk empowering. I also use Python > when necessary, but Squeak/Pharo is my preferred language. I find myself > infinitely more productive in Smalltalk than in Python. Operating in a > live environment is incredibly empowering, enabling and productive. > Where else can I find this. C, C++, C#, Java, Python, Ruby, VB, nope, > none... > > Demonstrating large scale Smalltalk projects have been canceled does not > prove Smalltalk's inferiority, nor that the competition (should one > choose to refer to them as such) has caught up or passed us. Especially > when said project was not canceled for technical reasons but political > ones and for software that was/is demonstrably inferior to the already > existing Smalltalk software. But what it does prove is that Smalltalk > has been and can be effectively deployed for large scale projects where > someone has the courage or political will to choose something different > than the status quo languages. > > The decisions of PHBs (Pointy Haired Bosses, Dilbert) does not > invalidate anything about Smalltalk. After all their primary motivation > is job security, not project success. No one ever got fired for > choosing, MS, Java, IBM, Oracle, etc... > > The biggest weakness for Smalltalk or at least our open source version > in Squeak/Pharo IMHO is its integration, cooperation or access story to > certain outside systems and technologies. And I speak as an end user who > cannot develop a plugin, or use Alien or FFI and program in C. In my > situation for example. I have to interface to either a Windows dll or to > a Java library to access financial servers. No choice. So I must choose > a technology which can interface their technology. In my case, I chose > to use Python to interface the Windows dll. I have written a minimal > Python app which accesses the dll and thus the servers to access the > data and my accounts. But the business logic I am writing in Pharo. The > Python app simply provides my Pharo app the data and executes the > actions directed by the Pharo app. > > I would that I could have interfaced the dll (or Java library) directly > from Pharo. But despite that obstacle I am choosing to write my app in > Pharo. Most in this business are using VB/C#/Java. They do not provide > the flexibility or productivity that I have in Pharo/Smalltalk. They do > not enable the small guy like me as well as Pharo/Smalltalk. Yes, this > is my opinion. But guess what. This is a Pharo mailing list populated by > people who are for and proponents of Smalltalk. If we favored other > languages and environments we would be there. Many of those on the this > list are also pretty dog gone expert in the other technologies as well. > They did not make their decisions out of ignorance. What I don't > understand is that if you are so convinced that the advantages of > Smalltalk are so minimal and of no consequence, then why are you here? > > I would like to see Pharo/Squeak bridge the gap to be able to interface > system components or other business libraries. I would like to be able > to use Pharo/Squeak anywhere I could use Python. I would like to see > that there are fewer and fewer technical reasons for not choosing > Pharo/Squeak. I can understand other choices. Other people are more > comfortable with other languages, systems, environments. They may have a > knowledge, systems, and process investment. But this can only validate > their decision for them and in no way invalidates the technology or > capabilities of Smalltalk. > > There are many, many projects for which Smalltalk/Pharo/Squeak have no > discernible technological disadvantages. They do not require any systems > integration or use of the "native ui". > > Enterprise. I agree with the sentiment that we don't need to worry about > it. Let Cincom address enterprise users. We need to empower the little > guy in the enterprise who has small side projects which do not have to > go through the same channels as the larger "enterprise" projects. > Projects for which they might choose Python or Ruby. Over time we can > improve our enterprise story and infiltration. Fortunately for us, > Smalltalk/Squeak/Pharo is in the long game. It has seen technologies > come and go and is still here. If we the open source Smalltalk community > continue to make the improvements we are making, then we will be an > increasingly viable choice for the entrepreneur, small businessman, > enterprise guy with the side project, the person with a project they do > on their personal time at home. It is the most enabling technology I know. > > Well, I'll end my rant here and get back to being enabled in the > development of my business app. > > Jimmie

Dec. 8, 2010

Re: [Pharo-project] Popularity or not of smalltalk?

by Peter Hugosson-Miller

+10^27 (That's hellaplus ;-)) Best and most positive rant I've heard in a long time! -- Cheers, Peter On Wed, Dec 8, 2010 at 2:26 AM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > Hear hear!! > > (specific responses below) > > On Tue, Dec 7, 2010 at 5:21 PM, Jimmie Houchin <jlhouchin(a)gmail.com>wrote: > >> On 12/7/2010 5:38 PM, csrabak(a)bol.com.br wrote: >> >>> Sean, >>> >>> Hope that additional to the fun, we can converge to an understanding how >>> can we increase Smalltalk popularity. >>> >>> OTOH, I made the reference as a sample, I did not intend to have this as >>> all encompassing list of issues nor start a thread about comparisons with >>> other languages. >>> >>> As I said earlier, what is 'trivial' or 'intuitive' for some is >>> 'maverick' or 'bizarre' for others, it is in the eyes of the beholder... ;-) >>> >>> My main message is more around this: although Smalltalk was a very >>> advanced technology when its inception, present status have almost all of >>> its characteristics embedded in present technology. Even, when newer >>> concepts as xUnit have started in Smalltalk, the _concept_ was absorbed in >>> mainstream technologies so again we're stuck with small delta between what >>> Smalltalk does 'better' than the incumbent technologies we would like to >>> replace. >>> >> >> I can't help but disagree with this most strenuously. >> >> Almost nothing has touched Smalltalk's advanced technology. They don't >> have the world view or paradigm for doing so. They are languages that >> operate in dead cycles. They have dead processes and do dead post mortem >> debugging. Yuck! (yes, I know that was redundant. :) >> >> I am not a computer scientist or trained programmer. I am a creative guy >> who is a businessman. I find Smalltalk empowering. I also use Python when >> necessary, but Squeak/Pharo is my preferred language. I find myself >> infinitely more productive in Smalltalk than in Python. Operating in a live >> environment is incredibly empowering, enabling and productive. Where else >> can I find this. C, C++, C#, Java, Python, Ruby, VB, nope, none... >> >> Demonstrating large scale Smalltalk projects have been canceled does not >> prove Smalltalk's inferiority, nor that the competition (should one choose >> to refer to them as such) has caught up or passed us. Especially when said >> project was not canceled for technical reasons but political ones and for >> software that was/is demonstrably inferior to the already existing Smalltalk >> software. But what it does prove is that Smalltalk has been and can be >> effectively deployed for large scale projects where someone has the courage >> or political will to choose something different than the status quo >> languages. >> >> The decisions of PHBs (Pointy Haired Bosses, Dilbert) does not invalidate >> anything about Smalltalk. After all their primary motivation is job >> security, not project success. No one ever got fired for choosing, MS, Java, >> IBM, Oracle, etc... >> >> The biggest weakness for Smalltalk or at least our open source version in >> Squeak/Pharo IMHO is its integration, cooperation or access story to certain >> outside systems and technologies. And I speak as an end user who cannot >> develop a plugin, or use Alien or FFI and program in C. In my situation for >> example. I have to interface to either a Windows dll or to a Java library to >> access financial servers. No choice. So I must choose a technology which can >> interface their technology. In my case, I chose to use Python to interface >> the Windows dll. I have written a minimal Python app which accesses the dll >> and thus the servers to access the data and my accounts. But the business >> logic I am writing in Pharo. The Python app simply provides my Pharo app the >> data and executes the actions directed by the Pharo app. >> > > Indeed. An immature FFI, lack of dll options etc. Integration is indeed > one of the biggest weaknesses. But we're making progress here. So things > may be different in months, if not years. > > >> >> I would that I could have interfaced the dll (or Java library) directly >> from Pharo. But despite that obstacle I am choosing to write my app in >> Pharo. Most in this business are using VB/C#/Java. They do not provide the >> flexibility or productivity that I have in Pharo/Smalltalk. They do not >> enable the small guy like me as well as Pharo/Smalltalk. Yes, this is my >> opinion. But guess what. This is a Pharo mailing list populated by people >> who are for and proponents of Smalltalk. If we favored other languages and >> environments we would be there. Many of those on the this list are also >> pretty dog gone expert in the other technologies as well. They did not make >> their decisions out of ignorance. What I don't understand is that if you are >> so convinced that the advantages of Smalltalk are so minimal and of no >> consequence, then why are you here? >> >> I would like to see Pharo/Squeak bridge the gap to be able to interface >> system components or other business libraries. I would like to be able to >> use Pharo/Squeak anywhere I could use Python. I would like to see that there >> are fewer and fewer technical reasons for not choosing Pharo/Squeak. I can >> understand other choices. Other people are more comfortable with other >> languages, systems, environments. They may have a knowledge, systems, and >> process investment. But this can only validate their decision for them and >> in no way invalidates the technology or capabilities of Smalltalk. >> >> There are many, many projects for which Smalltalk/Pharo/Squeak have no >> discernible technological disadvantages. They do not require any systems >> integration or use of the "native ui". >> >> Enterprise. I agree with the sentiment that we don't need to worry about >> it. Let Cincom address enterprise users. We need to empower the little guy >> in the enterprise who has small side projects which do not have to go >> through the same channels as the larger "enterprise" projects. Projects for >> which they might choose Python or Ruby. Over time we can improve our >> enterprise story and infiltration. Fortunately for us, >> Smalltalk/Squeak/Pharo is in the long game. It has seen technologies come >> and go and is still here. If we the open source Smalltalk community continue >> to make the improvements we are making, then we will be an increasingly >> viable choice for the entrepreneur, small businessman, enterprise guy with >> the side project, the person with a project they do on their personal time >> at home. It is the most enabling technology I know. >> >> Well, I'll end my rant here and get back to being enabled in the >> development of my business app. >> >> Jimmie >> > > Thanks for these fine words Jimmie! > > best > Eliot > >

Dec. 8, 2010