[Pharo-project] Misc. newbie questions

Frank Shearar frank.shearar at gmail.com
Wed Jan 18 23:48:00 CET 2012

On 18 January 2012 11:07, Frank Shearar <frank.shearar at gmail.com> wrote:
> On 18 January 2012 10:29, Serge Stinckwich <serge.stinckwich at gmail.com> wrote:
>> On Sat, Jan 7, 2012 at 10:28 PM, Frank Shearar <frank.shearar at gmail.com> wrote:
>>> On 7 January 2012 15:11, Nicolas Cellier
>>> <nicolas.cellier.aka.nice at gmail.com> wrote:
>>>> 2012/1/7 Frank Shearar <frank.shearar at gmail.com>:
>>>>> On 7 January 2012 14:14, Nicolas Cellier
>>>>> <nicolas.cellier.aka.nice at gmail.com> wrote:
>>>>>> 2012/1/6 Lukas Renggli <renggli at gmail.com>:
>>>>>>> On 6 January 2012 11:20, Peter Hugosson-Miller <oldmanlink at gmail.com> wrote:
>>>>>>>> On 6 jan 2012, at 06:41, "Gerry Weaver" <gerryw at compvia.com> wrote:
>>>>>>>> 2. There appear to be some tool choices in the Pharo image. I would like to
>>>>>>>> be able to create a class and it's methods in an editor in one go. I like
>>>>>>>> being able to see all of the class code at once. Is there a way to do this?
>>>>>>>>  I just want to be able to type it all in and accept (evaluate?) all at
>>>>>>>> once.
>>>>>>>> This is an interesting question to me personally. After 15 years of working
>>>>>>>> exclusively in Smalltalk I've recently been forced to start programming in
>>>>>>>> Java, where the source code is always (as far as I know) arranged in the way
>>>>>>>> you describe.
>>>>>>>> This organization just emphasizes the dead and compiled nature of Java (and
>>>>>>>> similar languages), compared to the living objects of Smalltalk, where even
>>>>>>>> methods are objects, created by sending messages to other objects. Source
>>>>>>>> code is relegated to being a mere artifact, which can be saved and organized
>>>>>>>> in any way one wishes, and preferably never shows its ugly face to the coder
>>>>>>>> :-p
>>>>>>> Which of course is no argument why Smalltalk code could not be
>>>>>>> displayed in a more programmer friendly way as a continuous block of
>>>>>>> text. There is no technical reason why source ranges in text box
>>>>>>> couldn't correspond to life method objects. Compared to other
>>>>>>> languages it is extremely tedious in Smalltalk to get an overview over
>>>>>>> a project, a package, or even a single class or to navigate between
>>>>>>> entities.
>>>>>>>> And yes, I really *really* miss a good, object oriented class browser!
>>>>>>> Eclipse is pretty good, especially with the Java Browsing Perspective.
>>>>>>> Lukas
>>>>>> As soon as you would display the code for many methods in a single text pane,
>>>>>> you will find file-based-educated people making large refactorings in
>>>>>> a single pass...
>>>>>> Imagine this leads to many syntax errors, they will soon be willing to
>>>>>> save their changes for a later rework...
>>>>>> This would be a complete change in programming flow and if we really
>>>>>> want to support this, we would have to:
>>>>>> - add a way to save syntactically incorrect code
>>>>>> - let IDE tools work on partially correct code (syntax highlighting,
>>>>>> navigation, etc...)
>>>>>> IMHO, these features add a lot of complexity... Is it really worth?
>>>>>> I like the discipline of focusing on a single method until it is at
>>>>>> least syntactically correct.
>>>>> The Pharo community has extremely limited resources so it seems quite
>>>>> fair to me for Pharo to say "yes, but it's up to you because we have
>>>>> no time". It _is_ very useful to be able to see and edit long reams of
>>>>> text: my favourite text editor's been beaten on since the late 70s. It
>>>>> is now very, very good at manipulating text, in multiple programming
>>>>> languages, in multiple human languages, on many platforms. That I
>>>>> can't use this text editor to manipulate a textual representation of
>>>>> my favourite language is extremely annoying!
>>>>> frank
>>>> Yeah, but my take was that re-inventing a very narrow subset of these
>>>> 40 years old text editors in Smalltalk would likely be a failure...
>>>> (or a big project)
>>> It would be a fairlly big piece of work although we do have lots of
>>> pieces lying around:
>>> * Coral's working on a scripting/REPL-like interface,
>>> * the Common Lisp community has been using SLIME to provide a REPL to
>>> a running image for years while also using files to store their code,
>>> * we have Gitocello (which also translates Squeak/Pharo to gst),
>>> * we have LanguageBoxes (*) allowing us to permit craziness like
>>> storing code outside the image in one format without affecting the
>>> entire language (letting us store Smalltalk code in something other
>>> than chunk format)
>>> (*) watch this space: I'm making progress on breaking up the Helvetia
>>> image into a bootstrappable bunch of packages
>> Did you commit your code somewhere ?
> Not yet: what I have at the moment is a Squeak Installer script to
> bootstrap a vanilla 4.3 image up to the point where I can start
> loading Cutie-Helvetia, the first of the LanguageBoxes packages,
> dependency-wise, together with a few shims necessary to add some
> Pharo-specific bits to Squeak. Those shims are as yet unpublished,
> just because I haven't taken the time to put them anywhere.
> It's still very much in hack form, but you can see what I have so far
> at https://gist.github.com/1632449.
> Right now I'm trying to figure out how to load Cutie-Helvetia: it
> occurred to me late last night that Monticello can't load the
> non-Smalltalk methods because it's trying to use the image's compiler
> rather than the class-specific parser. I don't yet have a solution: I
> need the class-side methods compiled and loaded before I can try
> compile the instance-side methods, and right now Monticello compiles
> everything before installing anything. I guess a custom loader's what
> I need.

Update: I've made a dumping ground for all my interim work -
http://ss3.gemstone.com/ss/Scratchpad-fbs - which _should_ be
exhaustive. I have yet to solve the loading problem I mentioned,

> frank
>> Regards,
>> --
>> Serge Stinckwich
>> UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam
>> Matsuno Laboratory, Kyoto University, Japan (until 12/2011)
>> http://www.mechatronics.me.kyoto-u.ac.jp/
>> Every DSL ends up being Smalltalk
>> http://doesnotunderstand.org/

More information about the Pharo-project mailing list