Hello All, Thank you for all of your responses. They are really helping me get a better picture of Pharo, the environment, and the community.
I really like the idea of a REPL type interface. If I understand correctly, all of the functionality that deals with class/method definition is already there. It seems like it would be a matter of writing a little server type application that would communicate via stdin/stdout. I assume one could then send messages to the code that evaluates methods/function definitions and provide result feedback via stdout. Maybe it could also understand some commands like doit and accept. It could be interesting to have a TCP based interface as well. How difficult would it be to do something like this? I may start looking into this. It seems like a good project to jump into the deep end, start paddling, and drinking a little water (hopefully not too much). Is the code that handles this kind of thing readily accessible? I've started looking around a bit. Thanks, Gerry -----Original Message----- > From: "Frank Shearar" <[email protected]> > To: [email protected] > Date: 01/07/12 09:28 > Subject: Re: [Pharo-project] Misc. newbie questions > > On 7 January 2012 15:11, Nicolas Cellier > <[email protected]> wrote: > > 2012/1/7 Frank Shearar <[email protected]>: > >> On 7 January 2012 14:14, Nicolas Cellier > >> <[email protected]> wrote: > >>> 2012/1/6 Lukas Renggli <[email protected]>: > >>>> On 6 January 2012 11:20, Peter Hugosson-Miller <[email protected]> > >>>> wrote: > >>>>> On 6 jan 2012, at 06:41, "Gerry Weaver" <[email protected]> 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 > > > There is also this recent related post which touch this subject: > > > > http://railsrx.com/2011/12/29/getting-back-to-smalltalk/ > > Amusingly, I only just finished reading that in my newsreader. I think > _personally_ that I need to port TWM to Squeak because I'm tired of > being the window manager, and hopefully that would solve my other > pain, which Noel points out - the ability to see multiple methods at a > time is _really useful_. > > (Trivial example: think of how clear code in ML or Haskell looks when > pattern matching on type, versus having five browsers open on various > subclasses' implementations of #foo.) > > I guess I'm saying: the rest of the world isn't automatically wrong > because they're not using Smalltalk, and I want to bring the best > parts of the non-Smalltalk stuff to Smalltalk (like having the > _option_ of using my favourite version control system, text editor, > IDE, etc.) > > frank > > > Nicolas > > > >> > >>> On the other hand, in Smalltalk we have to transfer the complexity of > >>> multi-method changes in the refactoring engines/menus when some simple > >>> modify/replace in a file would work. > >>> > >>> Nicolas > >>> > >>>> -- > >>>> Lukas Renggli > >>>> www.lukas-renggli.ch > >>>> > >>> > >> > >
