On Jan 8, 2012, at 2:05 AM, Gerry Weaver wrote:
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 stout.
Yes :) With the MTvm you can already do that: talk to the vm via a console :).
Maybe it could also understand some commands like doit and accept. Yes. A doit is somehow no more than Compiler evaluate: asString
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" <frank.shearar@gmail.com> To: Pharo-project@lists.gforge.inria.fr Date: 01/07/12 09:28 Subject: Re: [Pharo-project] Misc. newbie questions
On 7 January 2012 15:11, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
2012/1/7 Frank Shearar <frank.shearar@gmail.com>:
On 7 January 2012 14:14, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
2012/1/6 Lukas Renggli <renggli@gmail.com>:
On 6 January 2012 11:20, Peter Hugosson-Miller <oldmanlink@gmail.com> wrote:
On 6 jan 2012, at 06:41, "Gerry Weaver" <gerryw@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
There is also this recent related post which touch this subject:
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