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

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

by csrabak＠bol.com.br

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... -- Cesar Rabak Em 07/12/2010 05:00, laurent laffont < laurent.laffont(a)gmail.com > escreveu: I agree on the feeling, I only think we all miss a very important tactical point here: in what realm is Smalltalk superior to other technologies? Â Fun :) Laurent The issue some cool and kicking creatures could have been done is not enough, we need also to be certain we can get newcomers and have them quickly up to speed in doing so. _That_ has lead other ('younger') languages to their present status. -- Cesar Rabak

Dec. 7, 2010

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

by Tudor Girba

Hi, Exactly, that is why I am saying to not even try. I believe a much better approach is to just focus on producing something else that people need, and I also believe that we should focus on the layers above Smalltalk and start infusing Smalltalk lessons in those domains. Moose is such an example. Moose addresses the analysis domain, and it brings in it the lessons of Smalltalk (like everything is an object = everything is an entity). Afterwards, you bundle that with an explicit use case that makes sense and get that in the hands of people. If it's good, they will use it not because of a Smalltalk-related argument, but because of its inner value. And, if they love it, they will pay more attention to what is behind. Cheers, Doru On 7 Dec 2010, at 07:18, HernÃ¡n Morales Durand wrote: > Tudor, > > You cannot convince someone which have already choosen an option. > Cheers > > 2010/12/6 Tudor Girba <tudor.girba(a)gmail.com>: >> Hi, >> >> I believe Smalltalk is perceived in the following way: >> 1. Smalltalk is cool: 0.01% >> 2. What is Smalltalk?: 19,99% >> 3. Smalltalk is dead: 80% >> >> It is hard to convince the 2nd category to look at something new. Why should they? But, if it's hard to convince someone of something new, you need a miracle to convince someone that something is not dead. But, I think that a miracle like this can be administrated in the form of cool and kicking creatures and then tell them that they kick because of Smalltalk :) >> >> Cheers, >> Doru >> > > -- > HernÃ¡n Morales > Information Technology Manager, > Institute of Veterinary Genetics. > National Scientific and Technical Research Council (CONICET). > La Plata (1900), Buenos Aires, Argentina. > Telephone: +54 (0221) 421-1799. > Internal: 422 > Fax: 425-7980 or 421-1799. > -- www.tudorgirba.com "When people care, great things can happen."

Dec. 7, 2010

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

by csrabak＠bol.com.br

Dennis, I think if we dig enough we'll find a list of similar size right here in Pharo-project list... Look for the thread about 'silent failures' by Bill Schawb, and similar threads. We have to accept that what used to be 'oddity' became 'intuitive' or 'natural' as (my favorite example) the case of from ver 95 onwards, to turn off a Windows machine you've to look for the "Start" button... -- Cesar Rabak Em 07/12/2010 04:27, Dennis Schetinin < chaetal(a)gmail.com > escreveu: 2010/12/7 <csrabak(a)bol.com.br> 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Â¹? Just to compare: http://www.javapuzzlers.com/contents.html :) -- Dennis Schetinin

Dec. 7, 2010

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

by csrabak＠bol.com.br

HernÃ¡n, On the other hand, it is hard to try to convince someone to switch if the data we have to present our advantages are not compelling. -- Cesar Rabak Em 07/12/2010 04:18, HernÃ¡n Morales Durand < hernan.morales(a)gmail.com > escreveu: Tudor, You cannot convince someone which have already choosen an option. Cheers 2010/12/6 Tudor Girba : > Hi, > > I believe Smalltalk is perceived in the following way: > 1. Smalltalk is cool: 0.01% > 2. What is Smalltalk?: 19,99% > 3. Smalltalk is dead: 80% > > It is hard to convince the 2nd category to look at something new. Why should they? But, if it's hard to convince someone of something new, you need a miracle to convince someone that something is not dead. But, I think that a miracle like this can be administrated in the form of cool and kicking creatures and then tell them that they kick because of Smalltalk :) > > Cheers, > Doru > -- HernÃ¡n Morales Information Technology Manager, Institute of Veterinary Genetics. National Scientific and Technical Research Council (CONICET). La Plata (1900), Buenos Aires, Argentina. Telephone: +54 (0221) 421-1799. Internal: 422 Fax: 425-7980 or 421-1799.

Dec. 7, 2010

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

by csrabak＠bol.com.br

Guillermo, On the surface it may appear as such, but 'non technical' people decide about their business as a whole, and from their perspective, they've heard of Java because it is mainstream and the 'someones' "recommending' it have stakes in this technology... -- Cesar Rabak Em 07/12/2010 03:38, Guillermo Polito < guillermopolito(a)gmail.com > escreveu: Do we have marketing people?Â We need someone selling smalltalk to business people. :P In most cases (at least here in Argentina), the technology is decided by non technical people (like managers or customers) because they heard something called java and someone recommended it to them... Sad.

Dec. 7, 2010

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

by Levente Uzonyi

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

Re: [Pharo-project] ProcessWrapper

by Facundo Vozzi

Levente, On Sat, Dec 4, 2010 at 10:24 PM, Levente Uzonyi <leves(a)elte.hu> wrote: > > > Pharo 1.1 (and 1.1.1) is a bit harder to fix, because there's a bug in > MIMEDocument class >> #guessTypeFromName:. This method tries to send > #forURIReturnSingleMimeTypeOrDefault: to MIMEType, but that class doesn't > implement this method. Actually no class implements this is Pharo 1.1. > > But you can avoid this problem by downloading the prebuilt plugin dll from > > http://people.inf.elte.hu/uzonyile/ProcessWrapper/2/ProcessWrapperPlugin.dl… copy it to your image or VM folder before loading the package to your > image. > It works fine on Pharo 1.1.1. See you, Facu

Dec. 7, 2010

Re: [Pharo-project] IRC meeting notes

by Sean P. DeNigris

Log at http://pastebin.com/Y7MFaddK -- View this message in context: http://forum.world.st/IRC-meeting-notes-tp3077266p3077349.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 7, 2010

Re: [Pharo-project] 'stash' a Smalltalk shell or what happens when you let your mind wander in the shower....

by Dale Henrichs

Another example of what I'm thinking about: cd /Monticello/SqueakSource/MetacelloRepository cd ConfigurationOfMetacello-DaleHenrichs.489 vi version10: or cd /Monticello/GemSource/MetacelloRepository grep ConfigurationOfOB *.* shell-style manipulation of artifacts that will never be exported to the OS file system... Dale On 12/07/2010 12:08 PM, Dale Henrichs wrote: > Eliot, > > To riff a little bit on the idea...the notion is to not export to the OS > but to model the OS from within Smalltalk...so we would write the unix > tools in Smalltalk .... > > /vm might be a mount point for proc-style access to vm parameters > /Smalltalk might be a mount point for accessing structured/named objects > > So the idea of stash is to pull the shell into Smalltalk and then > provide the types of tools you are talking about but all from within > Smalltalk ... staying completely within Smalltalk means that we don't > have to squeeze Smalltalk fit onto the disk, the nodes in the directory > structure would be objects, so they wouldn't be bounded by bytes... > > using the "file system model" gives us a different model to use for > working with in-image artifacts that has it's advantages while also > providing a familiar model for folks that are new to Smalltalk... > > Dale > > On 12/07/2010 11:48 AM, Eliot Miranda wrote: >> Dale, >> >> I'm not sure if this is part of your idea, but would it be cool if >> you could build this as a virtual file interface so that a Smalltalk >> image could be mounted and searched using unix tools? Sort of like your >> idea inside-out. >> >> Eliot >> >> On Tue, Dec 7, 2010 at 10:30 AM, Dale Henrichs<dhenrich(a)vmware.com >> <mailto:dhenrich@vmware.com>> wrote: >> >> I was thinking about a number of things in the shower this morning >> and then it occurred to me that it would be interesting to create a >> shell environment INSIDE a Smalltalk vm. >> >> It wouldn't be a complete environment, but it would include a small >> set of standard unix utilities: >> >> - awk >> - sed >> - grep >> >> the "directory structure" would be the package structure in the >> image (or maybe multiple views on the image contents) with the basic >> idea that you 'cd' into a class where there is a 'file' that >> contains the class attributes. you then 'cd instance/all' and you >> are in a "directory" of methods where you can 'vi at:put:' and have >> a vi-like editor come up on the source of the at:put: method of >> course awk, grep, and sed work on all of these 'source files'... >> there would be 'executable files' that are simply workspaces ... >> >> I know that folks have externalized files, but I don't know if >> anyone has internalized the shell environment ... >> >> The reason for internalizing the shell is that it becomes easy to >> transition to the debugger and other traditional browsers/windows. >> >> The big reason for internalizing the shell is to provide a unix-like >> interface for Smalltalk that might make transition to the Smalltalk >> tools easier for folks new to Smalltalk. >> >> The secondary reason (and probably just as important) for >> internalizing the shell, is that the hard-core Smalltalk developers >> might actually find some utility in using the "smalltalk shell" in >> the normal course of development and if hard-core developers use it, >> it will be maintained and might lead to other interesting things... >> >> The idea is that the entire "smalltalk shell" would be implemented >> in Smalltalk so you could bring up browsers with a command ... >> >> I've been thinking wistfully back to the days when I lived inside of >> Emacs in the days before every terminal had a mouse ... back then I >> put my hands on the keyboard at the start of the day and they stayed >> there the entire day all window navigation was done via the keyboard >> ... I lost all of that once I started doing development in Smalltalk... >> >> Anyway that about covers todays "ideas from the shower"... >> >> Dale >> >> > >

Dec. 7, 2010

[Pharo-project] IRC meeting notes

by Adrian Lienhard

This evening the announced IRC meeting took place. I've published the notes as a blog post on our website: http://pharo-project.org/news?article=irc-meeting-notes Cheers, Adrian ___________________ http://www.adrian-lienhard.ch/

Dec. 7, 2010