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

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

by Eliot Miranda

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

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

by Jimmie Houchin

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] Pharo integration in enterprise feedback

by csrabak＠bol.com.br

Igor, This is partially true: the percentage of 'power users' in the enterprise who write small systems in Access and Spreadsheets (be it with or w/o VBA) is impressive. It is in the radar screen of consulting firms selling services about risk management due the inherent problems these approaches have to the companies. So empowering the end user is an interesting topic. We need to gain their hearts... Em 07/12/2010 21:35, Igor Stasenko < siguctua(a)gmail.com > escreveu: On 8 December 2010 00:19, wrote: > This is a good point! Â However, the issue with it is that in enterprises > programmers are paid to produce code having or not fun :-( > > OTOH, the main advantage of an environment as Smalltalk, IMNHO the empowerment to the end user, is lost once the programming starts to be Taylorized with a "systems" or "IT" department in charge of this duties and end users having to interact via Requirement Engineers and so on... > because Requirement Engineers also want to eat and feed their families :) Indeed, smalltalk makes programming closer down to something, which anyone can do.. But no, people won't buy it, because of the fear of doing something awful, like putting PC on fire and get fired because of that :) > -- > Cesar Rabak > -- Best regards, Igor Stasenko AKA sig.

Dec. 8, 2010

Re: [Pharo-project] Dictionary responds to #add:, #addAll: but shouldNotImplement #remove: and #remove:ifAbsent

by jaayer

---- On Tue, 07 Dec 2010 03:51:00 -0800 StÃ©phane Ducasse wrote ---- >did you create an issue? >and where did you publish the code? I uploaded them to the PharoInbox, but as I said, only one minor change in SmallDictionary>>remove: (adding a carrot "^" at the beginning) will fix the discrepancy between the two. But if the consensus is that Dictionary>>remove: and Dictionary>>remove:ifAbsent: should not be implemented, maybe the same should be true of SmallDictionary as well. >>>> Is anyone else bother[ed] by this inconsistency? >>> >>> Apparently not. Well, I uploaded two packages to the PharoInbox. One adds #remove: and #remove:ifAbsent: to Dictionary >>> and updates SmallDictionary's implementations of those messages to return the same value >> >> Regardless of what comes of those packages I uploaded, SmallDictionary>>remove: and SmallDictionary>>remove:ifAbsent: returning two different values is clearly a bug. Looking at it again, I was wrong about SmallDictionary>>remove:ifAbsent: returning the key; it does return the removed association. Which means at a minimum, SmallDictionary>>remove: only needs to have a ^ inserted at its beginning to fix the discrepancy. >> >>> - the association removed - rather than their current behavior of #remove: returning self (no explicit return value) and >>> #remove:ifAbsent: returning the key of the removed association. >>> The second package adds #testRemove and >>> #testRemoveIfAbsent to DictionaryTest (through a trait). >>> >>> >>> >> >> > > >

Dec. 8, 2010

Re: [Pharo-project] Why is FileStream writing almost an order of a magnitude slower than reading ?

by Nicolas Cellier

2010/12/8 Levente Uzonyi <leves(a)elte.hu>: > On Tue, 7 Dec 2010, Philippe Marschall wrote: > > snip > >> No, buffering should not be in a subclass or even the file stream class >> itself. Buffering should be an other class that wraps file stream. > > Stream wrappers are cool, but they are totally different from the current > stream design. One could create new stream classes that could do buffering, > conversion, compression, etc. and rewrite existing code to use them, but if > you just rewrite the existing code using an existing stream library (for > example XTreams), then you'll get pretty much the same thing with less > effort. > By now, you have at least two wrapper libraries: The VW Xtreams port at http://www.squeaksource.com/Xtreams.html These are wrappers focused on clean-ness / cross dialect portability. Efficiency is not at top but might be improved later. Also the SqueaXTream at http://www.squeaksource.com/XTream.html more focused on efficiency. I don't count Nile which provides a few wrappers but is more oriented toward Traits composition. Nicolas > > Levente > >> >> Cheers >> Philippe >> >> >> > >

Dec. 7, 2010

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

by csrabak＠bol.com.br

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. Em 07/12/2010 15:57, Sean P. DeNigris < sean(a)clipperadams.com > escreveu: This is fun! Thanks for the discussion... csrabak wrote: > > Sean, once you really get to metal subtleties and other nuances on the > language and syntax appear to bug your team. Have you ever heard of > John McSweeney's "Smalltalk âTrapsâ" pieceÂ¹? > [ sean isOnChair ] whileTrue: [ sean laugh ]. 7 pages! (actually 6.5 - with embedded images) That actually proves my point vs. entire textbooks ;-) Not to mention that: * the first page and a half's examples are trivial and not exactly "traps" (the fact that self is implicitly returned) * the "10 + (10 negated) negated" "trap" executes intuitively and correctly in Squeak * the example of changing a loop while iterating with do: seems like C++ code translated literally into Smalltalk * the last 1.5 pages are totally contrived (and use global variables which are discouraged anyway; I haven't had to use one yet) - yes, if you *want* to screw up the system, you can: #right basicAt: 1 put: 119; basicAt: 2 put: 114; basicAt: 3 put: 111; basicAt: 4 put: 110; basicAt: 5 put: 103. #right An equivalent argument is: if you hit your laptop repeatedly with a bat, it will not work regardless of what programming language you were using, so you might as well pick any csrabak wrote: > > Well, comparing C, even C++ which normally hasn't automatic garbage > collection, is somewhat stretching the argument... > Well, that's just the point, isn't it? We're talking about language popularity and those are #2 and #3 on the TIOBE index. csrabak wrote: > > even with those > "idiosyncrasies" as soon the size of the application grows up, these > perks of Smalltalk quickly become less noticeable > I've been using Smalltalk for less than a year, but I'm already more productive by far than in C, C++, or even Ruby, and haven't hit that limit writing software for small businesses. If there is a size at which the benefit lessens, isn't it more likely caused by poor design/devs or any number of factors (don't most large projects fail)? It can't be the same or worse to use a poor library in a dynamic live environment. I recently wrote a simple Ruby bridge and found it liberating to deal with the library in the Smalltalk tools rather than in Ruby's code/run cycle. csrabak wrote: > > Smalltalk... programmers attention to avoid the attribution of wrong > objects to instance variables as there is no type checking... > I have never encountered this and I've often heard it said by dynamic language experts to be mostly static language paranoia. What is the evidence that this becomes a severe problem in real-life dynamic systems? Sean -- View this message in context: http://forum.world.st/Popularity-or-not-of-smalltalk-tp3073990p3076885.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 7, 2010

Re: [Pharo-project] Pharo integration in enterprise feedback

by Igor Stasenko

On 8 December 2010 00:19, <csrabak(a)bol.com.br> wrote: > This is a good point! Â However, the issue with it is that in enterprises > programmers are paid to produce code having or not fun :-( > > OTOH, the main advantage of an environment as Smalltalk, IMNHO the empowerment to the end user, is lost once the programming starts to be Taylorized with a "systems" or "IT" department in charge of this duties and end users having to interact via Requirement Engineers and so on... > because Requirement Engineers also want to eat and feed their families :) Indeed, smalltalk makes programming closer down to something, which anyone can do.. But no, people won't buy it, because of the fear of doing something awful, like putting PC on fire and get fired because of that :) > -- > Cesar Rabak > -- Best regards, Igor Stasenko AKA sig.

Dec. 7, 2010

Re: [Pharo-project] Smalltalk in small steps ?

by Stefan Marr

Hi: On 07 Dec 2010, at 21:51, Sean P. DeNigris wrote: > > James Ladd wrote: >> >> Would it be worth while for the Smalltalk community, and language >> enthusiasts if I were to do the same with >> Redline Smalltalk, that is, make each features implementation part of a >> blog post and a 'work along' ? >> > > I would be very interested in seeing the intention and process behind the > final code. Me too :) Thanks Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

Dec. 7, 2010

Re: [Pharo-project] Why is FileStream writing almost an order of a magnitude slower than reading ?

by Levente Uzonyi

On Tue, 7 Dec 2010, Philippe Marschall wrote: snip > No, buffering should not be in a subclass or even the file stream class > itself. Buffering should be an other class that wraps file stream. Stream wrappers are cool, but they are totally different from the current stream design. One could create new stream classes that could do buffering, conversion, compression, etc. and rewrite existing code to use them, but if you just rewrite the existing code using an existing stream library (for example XTreams), then you'll get pretty much the same thing with less effort. Levente > > Cheers > Philippe > > >

Dec. 7, 2010

Re: [Pharo-project] Why is FileStream writing almost an order of a magnitude slower than reading ?

by Levente Uzonyi

On Tue, 7 Dec 2010, Sven Van Caekenberghe wrote: > Levente, > > On 07 Dec 2010, at 16:20, Levente Uzonyi wrote: > >> That's because filestreams are read buffered, but not write buffered. I implemented a subclass of FileStream (intended as a possible replacement of StandardFileStream) which is read and write buffered. It gives the same performance for reading as the current implementation and a significant boost for writes, so it can be done. But write buffering has side effects, while read buffering doesn't. Maybe it can be added as a separate subclass of FileStream if there's need for it, but the multibyte stuff has to be duplicated in this case (note that it's already duplicated in MultiByteFileStream and MultiByteBinaryOrTextStream). I also had an idea to create MultiByteStream which would be a stream that wraps another stream and does the conversion stuff using a TextConverter. It'd be a lot of work to do it and I don't expect more than 30% performance improvement (for the read performance). > > Thanks for the explanation, some quick and dirty buffering makes a huge difference: > > [ FileStream fileNamed: '/tmp/numbers.txt' do: [ :fileStream | > 1000 timesRepeat: [ > fileStream nextPutAll: > (String streamContents: [ :stream | > 100 timesRepeat: [ stream print: 100 atRandom; space ] ]) ] ] ] timeToRun. > 159 > > Still, the asymmetry is a bit strange. > Can't the side effects be dealt with using #flush ? Lets go back in time. A year ago there was no read buffering (Pharo 1.0 was not released, Squeak 3.10.2 was out) and reading from a file was as slow as writing is currently. Read buffering could be added transparently, so it could give a huge speed improvement to all existing code. Write buffering could be done the same way, but it would break code, because currently a write is immediately done, while with buffering it wouldn't be. Some files would be written only when the finalization process closes the file. The solution for this could be automatic flushing on each write, which could be turned off by a method. But that would be the same as not using write buffering at all. But with the same effort you could use another stream implementation, that does write buffering. And write buffering can't be used to speed up existing code without reviewing it. Levente > >> There are several stream libraries (for example XTreams) that can easily support write buffering without the need to care about compatibility. > > Yeah, although the Smalltalk Collection and Stream classes were better than everything else 20, 30 years ago, lots of things have changed and there is lots of competition. The fact that these classes are so nice to use seem to have prevented necessary improvements. > > I think I might file this as a Pharo issue. > > Sven > > >

Dec. 7, 2010