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 >>>> >>> >> >
