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 -- Lukas Renggli www.lukas-renggli.ch

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

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

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:

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

On 01/08/2012 02: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 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.

The answer is that it is basically trivial to do and many people have already done it in various forms - I even did a TCP server for Joe Armstrong (one of the creators of Erlang) that does similar things: http://www.squeaksource.com/JoesServer.html ...BUT... when it comes to Joe he wanted to use Squeak from Erlang in order to dynamically create UIs etc. So he had a reasonable use case. ;) ...if you just happe to "like REPLs" then you should really try to use and learn the Squeak/Pharo IDE. Think of it as a full blown live graphic REPL with tons of cool tools. Every text area in Pharo/Squeak is a "REPL" anyway. regards, Göran

Hello All, I've been thinking about the idea of an alternate IDE quite a bit. What I'm envisioning would be something akin to the Delphi IDE. Delphi is probably the most productive gui based environment I've ever worked in. It would be very interesting to combine Smalltalk with such an environment. My feeling about the current IDE is that it is somewhat dated. It was designed at a time when monitors were the size of port holes. I think an updated environment would go a long way to making the language more interesting and accessible. The difficult part about Smalltalk certainly isn't the language, it's the strange IDE layout. If that barrier were to be removed, then a person could really hit the ground running. The only real difference I would see between the old and the new would be the code editor. The rest would just be a little rearranging of what is already there. I'm slowly talking my self into actually starting down the road a bit. I think I'll try to find a few days that I can spend doing some investigating. Any thoughts? Thanks, Gerry

On 12 Jan 2012, at 10:23, Stéphane Ducasse wrote:

Hello Gerry

...

Hello All,

I've been thinking about the idea of an alternate IDE quite a bit. What I'm envisioning would be something akin to the Delphi IDE. Delphi is probably the most productive gui based environment I've ever worked in. It would be very interesting to combine Smalltalk with such an environment. My feeling about the current IDE is that it is somewhat dated.

+ 1000000

...

It was designed at a time when monitors were the size of port holes. I think an updated environment would go a long way to making the language more interesting and accessible. The difficult part about Smalltalk certainly isn't the language, it's the strange IDE layout. If that barrier were to be removed, then a person could really hit the ground running. The only real difference I would see between the old and the new would be the code editor. The rest would just be a little rearranging of what is already there. I'm slowly talking my self into actually starting down the road a bit. I think I'll try to find a few days that I can spend doing some investigating.

Any thoughts?

Brainstorm using glamour to prototype something. We definitively need innovation and rethink how we work.

I can tell you that what we have is not what I dream of.

I am all for people trying/prototyping new stuff, new ideas; that's one of the strong points of Smalltalk. However, I think/feel that for most Smalltalk developers, the combination of Language+Libraries+IDE in its current state is way better than anything else out there, why else would we keep using it, why else would we choose it above other environments ? In that perspective, I am a bit wary about people who want to change it all to make it so much better, especially if they are not experienced Smalltalkers. BTW, what is the current state of Nautilus ? When working with Camillo during the last sprint, he had Nautilus in his image and it seemed to work well. Sven

I am all for people trying/prototyping new stuff, new ideas; that's one of the strong points of Smalltalk.

However, I think/feel that for most Smalltalk developers, the combination of Language+Libraries+IDE in its current state is way better than anything else out there, why else would we keep using it, why else would we choose it above other environments ?

In that perspective, I am a bit wary about people who want to change it all to make it so much better, especially if they are not experienced Smalltalkers.

People should show and we will decide :)

BTW, what is the current state of Nautilus ?

Benjamin is waiting for me to work on RPackage :( Else it is working well. Now he started to implement all the widgets necessary to support refactoring and since he started to get bored to redo all the time the same we started to explore reuse. Skip the beginning of this document and have a look at how we can reuse UI elements. This is on my todo since mid december to read it calmly.

When working with Camillo during the last sprint, he had Nautilus in his image and it seemed to work well.

Sven

Is there some fundamental difference between Spec and ToolBuilder? Best -Tobias Am 2012-01-12 um 16:57 schrieb Benjamin:

I have to work again on Spec and on this chapter to make it more sexy :)

But basically, I think it can help to avoid having to don again and again the same UIs from scratch :)

For your experiments, maybe are you interest in (and maybe you already know) that the GUI implementation of Smalltalk/X is very compatible with to the VisualWork. See: http://live.exept.de/doc/online/english/tools/uipainter/TOP.html 2012/1/12 Stéphane Ducasse <stephane.ducasse@inria.fr>

- One model can propose multiple spec. - Declarative. Now we should build more experience on it. Apparently vw people are happy with literal spec.

Stef

...

Is there some fundamental difference between Spec and ToolBuilder?

Best -Tobias

Am 2012-01-12 um 16:57 schrieb Benjamin:

...

I have to work again on Spec and on this chapter to make it more sexy :)

But basically, I think it can help to avoid having to don again and again the same UIs from scratch :)

Hi Gerry: On 12 Jan 2012, at 10:13, Gerry Weaver wrote:

I've been thinking about the idea of an alternate IDE quite a bit. What I'm envisioning would be something akin to the Delphi IDE. Delphi is probably the most productive gui based environment I've ever worked in.

Could you point me to screenshots? Because I fear that you are talking about what I used to know as Borland Delphi.(http://www.blichmann.de/en/programming/delphi/themeddelphi/luna.png) Not that it is bad, but like Visual Studio and Eclipse, the main concepts are IMO as dated as what you got in Pharo. If you are just looking for a UI designer, have you seen this? https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki/... I would rather be interested in a 'more fluid' version of Hopscotch: http://bracha.org/hopscotch-wasdett.pdf Did not find a good demo without digging to much (there is one somewhere on youtube) but maybe this is already close enough: http://www.youtube.com/watch?feature=player_detailpage&v=gGJ2y0BNkpc#t=1536s Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

2012/1/12 Stéphane Ducasse <stephane.ducasse@inria.fr>

but UI building is just one part of the story. If after you just get a long initialize methods then nothing gets really reused.

Yes, It is reason why I hate VisualStudio and Delphi approaches. It is imposible to create reusable components of user interface applications.

On 12 January 2012 10:07, Denis Kudriashov <dionisiydk@gmail.com> wrote:

2012/1/12 Stéphane Ducasse <stephane.ducasse@inria.fr>

...

but UI building is just one part of the story. If after you just get a long initialize methods then nothing gets really reused.

Yes, It is reason why I hate VisualStudio and Delphi approaches. It is imposible to create reusable components of user interface applications.

Er, no. It's easy to make reusable UI components in Delphi. In fact (modulo my experience, of Delphi 3 -> Delphi 7) that was (*) its main strength. frank (*) I haven't used Delphi in a number of years, but I would be surprised to learn that its UI framework degraded into rubbish.

From reusable components I want two main things

- ability to change appearance and behavior of component when I use it iniside different component - ability to subclass component and specify different appearance and behavior for created child component class "Mainstream UI designer-approaches" does not get me this stuff. So it is forced me to copy UI code again and again and stop object programming. 2012/1/12 laurent laffont <laurent.laffont@gmail.com>

On Thu, Jan 12, 2012 at 11:07 AM, Denis Kudriashov <dionisiydk@gmail.com>wrote:

...

2012/1/12 Stéphane Ducasse <stephane.ducasse@inria.fr>

...

but UI building is just one part of the story. If after you just get a long initialize methods then nothing gets really reused.

Yes, It is reason why I hate VisualStudio and Delphi approaches. It is imposible to create reusable components of user interface applications.

??? Haven't use Delphi for +4 years but from Delphi 3 -> 7 it was not really hard to create reusable components, extend them and the IDE itself......

Laurent

2012/1/12 Stéphane Ducasse <stephane.ducasse@inria.fr>

Did you publish your code? So that we can have a look?

Yes, of course http://www.squeaksource.com/Presenty.html. But... :( - It is work on pharo1.1. - It is too young. It has not much "standart UI stuff" - Settings of presenty application is not stored with Monticello package. (it's just live prototype objects) - It has some bugs. But I really want improve it. I have two commercial applications based on Presenty which our clients used. And we improve it. So Presenty will be necessarilly improved Now I fix implementation of conceptual part of framework which give many new interesting stuff and bug fixing

Hello. Let me say first that several year ago I understand that any ambient of Smalltalk is more powerfull that any IDE Delphi for work with object, but this depend of your skills in one enviroment obviously. For that, I'm a more powerful programer in Delphi that in Smalltalk, for misfortune for me. Second, let me say something about Delphi, just for information, anyway, correct me if I'm wrong: 2012/1/13 blake <dsblakewatson@gmail.com>

On Thu, Jan 12, 2012 at 3:07 AM, laurent laffont < laurent.laffont@gmail.com> wrote:

...

On Thu, Jan 12, 2012 at 11:07 AM, Denis Kudriashov <dionisiydk@gmail.com>wrote:

...

2012/1/12 Stéphane Ducasse <stephane.ducasse@inria.fr>

...

but UI building is just one part of the story. If after you just get a long initialize methods then nothing gets really reused.

Yes, It is reason why I hate VisualStudio and Delphi approaches. It is imposible to create reusable components of user interface applications.

??? Haven't use Delphi for +4 years but from Delphi 3 -> 7 it was not really hard to create reusable components, extend them and the IDE itself......

Laurent

Perhaps I can interject usefully here.

It isn't =hard= to create reusable components in Delphi. What it is is =different=. Delphi adopted Visual Basic's "two classes of developers" approach through delegation that hides all the actual object-oriented programming from those who aren't comfortable with it. When you create an event routine for a component on a form, the method is part of the form class.

This method is for manage the event, not for do something that is really part of the model. A Form, no is part of the model. This is similar in VW: you coded your event handler method in the AplicationModel, that is like a Form in Delphi.

Rather horrifyingly, Delphi auto-creates forms by default and assigns them to global variables, thus encouraging the practice of referencing a =specific instance= of the class. Re-usable? It sets novices up to create interfaces that don't even work properly with multiple instances of the =same= form.

No. The IDE automaticaly define a global variable and create code for create and assign a instance, but if you want more instances of same Form you can easy declare local variables and create new instance (on initialize of other instance or on the fly in accesor methods) and asign to. Same in Smalltalk.... And you can delete this automaticaly created code. Now, creating a component requires creating an actual object, then

compiling and installing it into the environment. It's not hard, but it's easy to screw up, and fixing it requires going back into this other mode. (It's not quite frozen once installed but it's not completely flexible, either.)

I agree. I spend very much dead time in code-compile-debug cycle, but this is not mainly for use component, is for lack of a truth ambient of programing with object, Delphi is just an IDE. I screw up very often in Smalltalk, but I fix this directly in the debugger and go on :)

Components are supposed to be contract-less, meaning user type #1 can't break them (at least from inside the object inspector).

The upshot is that, yes, it is actually more difficult to create a reusable UI. The delegation model encourages the mashing of the V and C into the M, as it were.

mmm no. Again, a Form is not part of model, idealy this is for write event methods handlers.

You can easily make all the buttons on a form call the same code, but buttons on a different form? Well, now you're looking at that compiled component model.

In the Buttons you can use Actions for delegate the handler method of the click event. In general, you can assign method of a Form to events of controls in another Form, but I do not do often that becouse I only write a small code in the event handler in the Form for delegate to some model the work (DataModules).

JBuilder (the Java equivalent of Delphi) sub-classed everything, which seemed less than ideal, too.

A Smalltalk-style equivalent could out-do this easily, since component design wouldn't be any different from any other sort of programming. You could use delegates OR subclass, and any subclass could instantly appear as a component.

I started using Smalltalk with VisualAge. While there were a lot of limitations with the connector approach, I always thought it was kind of cool: Being able to visually connect two objects so that a message from one was matched up to a method the other was superior than "Intellisense" in a lot of ways.

Finally, I like work with component in Delphi when I begin a proyect, but I guess that when I comming to make something more complex the IDE no aid much, you have to go at code editor and sometimes the utilization of components even hinder... In Smalltalk (Pharo) I have the problem at begining becouse I have to write all code by hand, but at end all work (coded, debug) is very simple all the time. Gastón

Hello Blake. I like discuss about Delphi, but I don't say much more here becouse this is a Smalltalk list :) 2012/1/13 blake <dsblakewatson@gmail.com>

Gaston,

...

This method is for manage the event, not for do something that is really part of the model. A Form, no is part of the model. This is similar in VW: you coded your event handler method in the AplicationModel, that is like a Form in Delphi.

Delphi was a direct reaction to VB, which was eating Borland Pasal's lunch. MVC was nowhere to be seen. It was all about "look how easy it is to do [whatever]." Never "look how easy it is to re-use" or "look how easy it is to maintain". I'm not a Basic basher, but the atmosphere surrounding it has always been "Computer science is =haaaaarrd=. I just wanna program!"

In general, the user of Delphi do not know how to make good programming with it, becouse Delphi granted them make the things quickly and bad. There are a VERY good book named "The dark side of Delphi...", and the DARK word is for the general unknown about it. Here is (in Spanish sorry): http://www.marteens.com/pdfs/TheDarkSideOfDelphi6.pdf

You CAN do it right. But here I am (right now!) looking at a guy who's encoded multi-hundred-line event handlers, that are massive if-then chains, with code duplicated like crazy between the events.

hehe, Maybe a sometime when I'm very hurry... but too in Delphi I can use polimorphic, strategy, double dispatch, etc, for avoid use of if-then. And no massive code, just necesary code for handle event, just in VisualWorks :)

Really, the "beauty" of the VB model is that you didn't HAVE to learn OO. (And, hey, reality bears out that code quality and profit are not strongly correlated.)

...

No. The IDE automaticaly define a global variable and create code for create and assign a instance, but if you want more instances of same Form you can easy declare local variables and create new instance (on initialize of other instance or on the fly in accesor methods) and asign to. Same in Smalltalk.... And you can delete this automaticaly created code.

Sure. You can do a lot of things right. The underlying weakness is in the static typing and poorly defined messaging. (I haven't tried FireMonkey yet, though, it may be different.)

Sure! I completely agree with you. You are deal with reserved words like "virtual, override, dinamic" for achieve dinamic message dispatch across static variable typing. This is very inconveniente for clean code (and has bad psychological consequences in the developers hehe). I do not try the Embarcadero version (and I do not), but them improved some things. For example added use de "Class Helper" for do some similar a trait to a class (but in a context). No only Smalltalk evolves :). FYI see:: http://edn.embarcadero.com/article/34324

mmm no. Again, a Form is not part of model, idealy this is for write event

...

methods handlers.

I'm glad you're following the ideal. I started using Delphi on the beta in 1994, and in the past 18 years, I've seen about two instances of the ideal being properly followed in the real world (that I didn't write).

hehe, again, "the DARK side..." never is very popular.

...

In the Buttons you can use Actions for delegate the handler method of the click event. In general, you can assign method of a Form to events of controls in another Form, but I do not do often that becouse I only write a small code in the event handler in the Form for delegate to some model the work (DataModules).

Point is: Buttons then become inflexible pass-throughs. In Smalltalk what you'd do is allow a component to be swapped for any other component if it had the right handlers.

In Delphi I can change the component too if they has the right handlers with out major work, but I agree with you in that this in not possibly do it easily that in Smalltalk. But, the class of the variable that hold the current component should be ancestor of both interchangeables components, very inconvenient!

If you could lay out forms in Smalltalk and press a button to create a lean, deployable version, I'd only use Delphi for CPU intensive tasks. What'd be optimal is a Smalltalk (with some VA/Delphi influences) in a browser with an overall approach like that of OPA or maybe Morfik (not Morphic) so that front and back-end stuff was seamless. Smalltalk was born for that.

:) Regards. Gastón.

On 15 January 2012 04:22, Gerry Weaver <gerryw@compvia.com> wrote:

2. I don't think the image concept works in the current world. I realize there are many folks who would argue this to death, but the fact is that it hinders adoption. I believe it would be better to focus on a robust full featured library and unload the maintenance of the image based environment. I would think of Smalltalk as a Java alternative.

I have a minor nit here: it's not an image that's the problem, it's living in the image. Great for rapid development, and very easy to tangle things together. But the community's making increasing use of build tools and configuration management, especially in the form of Metacello.

4. Developing in Smalltalk should be just like any other high level language. It should have a REPL type interface and it would also be nice to have the capability to compile to a native executable. The various Lisp implementations would be a good example. They too came from a similar environment.

Lisps are image-based systems, but one tends to construct one's working image from a base image + extras. SBCL's SAVE-LISP-AND-DIE lets you turn that image into an executable. I don't think anyone would particularly care - or even know - that their TextLint is, on the inside, some small image + VM. In short, I don't think it's a lot of work to get something ostensibly a native executable, and I don't think that compiling to a native executable's particularly valuable. (Java applications aren't compiled to a native executable, for instance!)

7. An interim solution to the items above would be to create a server based interface to the Smalltalk image. This would allow an external IDE to interact with the image in the same way that the embedded tools do.

That also permits general Smalltalk-written remote tools like remote debuggers!

My personal plan for Smalltalk/Pharo is to create an external IDE and a socket based interface in the Pharo image to support it. I also intend to create an image manager server that can manage, monitor, and communicate with multiple images. I have already been working on an IDE for Lisp. Adding Smalltalk support seems logical.

If I may suggest, take a look at Common Lisp's SLIME/swank architecture. (I'll be looking at this soon, with an eye towards connecting emacs to a running image.) With a standard protocol in place, one could connect _any_ IDE (plus plugin) to the image. I've spoken to a colleague about this kind of thing, and he suggests taking a look at https://github.com/ivan4th/swank-js because its architecture is rather simple, thus amenable to analysis and cribbing. _My_ personal plan is * a TCP-based interface in the Smalltalk image * a translating adapter between standard Squeak/Pharo syntax and GNU Smalltalk syntax (for "lexically scoped" class/method definitions) * an emacs mode for loading files or parts of files * ... and then copy a whole bunch of the above for the same thing for Newspeak.

Okay.. I've dug my foxhole and I'm in it with my helmet on. Fire away!

Thanks, Gerry

________________________________ -----Original Message----- From: "Gastón Dall' Oglio" <gaston.dalloglio@gmail.com> To: Pharo-project@lists.gforge.inria.fr Date: 01/14/12 10:06 Subject: Re: [Pharo-project] New IDE alternative (was Misc. newbie questions)

Hello Blake.

I like discuss about Delphi, but I don't say much more here becouse this is a Smalltalk list :)

2012/1/13 blake < dsblakewatson@gmail.com>

...

Gaston,

...

This method is for manage the event, not for do something that is really part of the model. A Form, no is part of the model. This is similar in VW: you coded your event handler method in the AplicationModel, that is like a Form in Delphi.

Delphi was a direct reaction to VB, which was eating Borland Pasal's lunch. MVC was nowhere to be seen. It was all about "look how easy it is to do [whatever]." Never "look how easy it is to re-use" or "look how easy it is to maintain". I'm not a Basic basher, but the atmosphere surrounding it has always been "Computer science is =haaaaarrd=. I just wanna program!"

In general, the user of Delphi do not know how to make good programming with it, becouse Delphi granted them make the things quickly and bad. There are a VERY good book named "The dark side of Delphi...", and the DARK word is for the general unknown about it. Here is (in Spanish sorry): http://www.marteens.com/pdfs/TheDarkSideOfDelphi6.pdf

...

You CAN do it right. But here I am (right now!) looking at a guy who's encoded multi-hundred-line event handlers, that are massive if-then chains, with code duplicated like crazy between the events.

hehe, Maybe a sometime when I'm very hurry... but too in Delphi I can use polimorphic, strategy, double dispatch, etc, for avoid use of if-then. And no massive code, just necesary code for handle event, just in VisualWorks :)

...

Really, the "beauty" of the VB model is that you didn't HAVE to learn OO. (And, hey, reality bears out that code quality and profit are not strongly correlated.)

...

No. The IDE automaticaly define a global variable and create code for create and assign a instance, but if you want more instances of same Form you can easy declare local variables and create new instance (on initialize of other instance or on the fly in accesor methods) and asign to. Same in Smalltalk.... And you can delete this automaticaly created code.

Sure. You can do a lot of things right. The underlying weakness is in the static typing and poorly defined messaging. (I haven't tried FireMonkey yet, though, it may be different.)

Sure! I completely agree with you. You are deal with reserved words like "virtual, override, dinamic" for achieve dinamic message dispatch across static variable typing. This is very inconveniente for clean code (and has bad psychological consequences in the developers hehe). I do not try the Embarcadero version (and I do not), but them improved some things. For example added use de "Class Helper" for do some similar a trait to a class (but in a context). No only Smalltalk evolves :). FYI see:: http://edn.embarcadero.com/article/34324

...

...

mmm no. Again, a Form is not part of model, idealy this is for write event methods handlers.

I'm glad you're following the ideal. I started using Delphi on the beta in 1994, and in the past 18 years, I've seen about two instances of the ideal being properly followed in the real world (that I didn't write).

hehe, again, "the DARK side..." never is very popular.

...

...

In the Buttons you can use Actions for delegate the handler method of the click event. In general, you can assign method of a Form to events of controls in another Form, but I do not do often that becouse I only write a small code in the event handler in the Form for delegate to some model the work (DataModules).

Point is: Buttons then become inflexible pass-throughs. In Smalltalk what you'd do is allow a component to be swapped for any other component if it had the right handlers.

In Delphi I can change the component too if they has the right handlers with out major work, but I agree with you in that this in not possibly do it easily that in Smalltalk. But, the class of the variable that hold the current component should be ancestor of both interchangeables components, very inconvenient!

...

If you could lay out forms in Smalltalk and press a button to create a lean, deployable version, I'd only use Delphi for CPU intensive tasks. What'd be optimal is a Smalltalk (with some VA/Delphi influences) in a browser with an overall approach like that of OPA or maybe Morfik (not Morphic) so that front and back-end stuff was seamless. Smalltalk was born for that.

:)

Regards. Gastón.

On 15 January 2012 09:08, Stefan Marr <smalltalk@stefan-marr.de> wrote:

Hi:

On 15 Jan 2012, at 09:53, Frank Shearar wrote:

...

On 15 January 2012 04:22, Gerry Weaver <gerryw@compvia.com> wrote:

* a TCP-based interface in the Smalltalk image

...

Okay.. I've dug my foxhole and I'm in it with my helmet on. Fire away!

I hope you guys are aware of Spoon:

http://thiscontext.wordpress.com/2011/06/09/my-favorite-text-editor-editing-...

http://thiscontext.wordpress.com/category/spoon/

Indeed! Spoon takes another approach, mapping classes/methods to files (in a WebDAV file system). Spoon's REPL, if I recall correctly, consists of writing to one file and reading from another. frank

Best regards Stefan

-- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax:   +32 2 629 3525

On 15 January 2012 09:40, Gerry Weaver <gerryw@compvia.com> wrote:

Hi Frank,

...

I have a minor nit here: it's not an image that's the problem, it's living in the image.

Yes. This is pretty much what I was thinking about. Thanks for the clarification.

...

Lisps are image-based systems, but one tends to construct one's working image from a base image + extras. SBCL's SAVE-LISP-AND-DIE lets you turn that image into an executable. I don't think anyone would particularly care - or even know - that their TextLint is, on the inside, some small image + VM. In short, I don't think it's a lot of work to get something ostensibly a native executable, and I don't think that compiling to a native executable's particularly valuable. (Java applications aren't compiled to a native executable, for instance!)

Firstly, for many reasons, I think Java is the absolute worst thing that has ever happened to software development. However, it is a testament to the power of good marketing ;-) I'm going to resist going on a rant. It would suffice to say that the packaging of Java apps is one of the many things that I dislike.

Sure. I'm suggesting that packaging a VM + image isn't necessarily the end of the world and, in particular, isn't necessarily an obstacle to developer adoption. (But also, we have loads of Pharo images packaged up as executables - Pharo itself, Seaside, Helvetia, and so on.)

I like native executables, because they are so much easier to package and distribute. They also play nicer with the OS in terms of shared libraries etc. Each OS already has a well known mechanism for dealing with them. There just... more comfortable. The ability to embed the VM solves this nicely as well (ie; ECL, Gambit-C, etc.) It would be pretty cool to have multiple instances of the Smalltalk VM running in an embedded fashion.

Thanks, Gerry

Hi Lawson,

Ironically, almost every newbie smalltalk programmer I know LIKES the IDE and thinks it is better than anything out there. 

I think this would largely depend on your background and experience. There is a whole class of developers that refuse to use anything, but vi and emacs. Once they realize that Smalltalk forces them to use a GUI, they will run away fast.

BTW, if you want to see how smalltalk can be used as an embedded language, like at f-script... whose IDE, which everyone >who uses it, loves, is very much a standard smalltalk IDE.

I'm not saying that the current IDE shouldn't exist. I just think that it should be decoupled from the image in such a way to make it reasonably easy to create alternatives. People that are coming from a systems level programming background are used to holding the details of their applications in their head. Being able to see the code at the class level works better with that approach. If you have worked that way for a while, the Smalltalk IDE feels extremely tedious to say the least. It's like trying to run when you're waist deep in water. Thanks, Gerry

Hi Andreas,

you are always writing "Smalltalk IDE". Which Smalltalk variants do you know? Squeak and Pharo are not the only ones. There >are some others, some commercial and some free. If you haven't any experiences with them yet you should at least have a look at them.

I have looked at Squeak, Pharo, Dolphin, VisualWorks, and VA. I am generalizing, because they all have the things that I find problematic. I also looked at GNU, but I don't like the whole GNU license thing very much. The one that comes the closest to what I'm thinking about is something called Smalltalk XY (not Smalltalk/X), but it is no longer maintained. I am more than happy to learn. Are there any others I should check out? Thanks, Gerry

Hi Andreas,  

I am not comfortable with the idea to write parts of an application in different languages. Typically the disadvantages overweigh the advantages to do so as you would have different languages and systems to master >and update. Interoperability with other systems and languages should be easy and Squeak/Pharo are still lacking in this area. This is well >known and hopefully there will be some improvements in the future.

I guess I would have to disagree with you here. Most of the editors and IDEs of other languages are not maintained by the language proper. There are many editors and IDEs that support many languages in addition to the one they are written in. I think the benefits of using a full featured GUI toolkit to create an IDE would be significant.  

Planning to give up on parts like GUI is a bad idea in my opinion. Smalltalk would be even more niche than it is now. I want >to be able to build complete applications without the need to build parts in another language.

In theory I would agree with you. However, I wasn't able to come up with an application scenario where the Pharo GUI would work. Either the widget set and OS integration are too limited or performance is a problem. For example, the last several applications I have done needed to display PDF files. I have done a little testing with Pharo and I'm sorry to say the results were not very encouraging.  The problem I think is one of limited resources. I think that maybe trimming some things would render more progress on the core. Perhaps a good and complete binding to one of the current GUI toolkits would be easier to maintain. You would also get the instant advantage of everything the toolkit had to offer (including performance). A more robust FFI would inevitably be realized as a result. 

Especially having the IDE in Smalltalk itself and thus being able to inspect and debug and modify everything is a big advantage >over any IDE in a different language.

I don't understand why the IDE needs to be in the image/language to do that.  

All Smalltalk implementations have shortcomings in some areas. There are a multitude of reasons for it, be it commercially  (greater estimated expenses than earnings from it) or just lack of capacity. Smalltalk users are rare these days and the >community is split because of different implementations and interests. For me, Pharo is on a good way to take the Smalltalk >language into a better ecosystem.  But for the moment Dolphin Smalltalk is my preferred system because it's relatively cheap >and has only few known bugs. In my eyes it deserves a bigger community and better commercial success. But I guess that's >what every Smalltalker thinks about his preferred Smalltalk system...

Dolphin seems to be one of the better implementations, but the problem with Dolphin is Windows. All of the projects on my radar right now are moving applications away from Windows to Mac/Linux (mostly Mac). Thanks, Gerry

On 1/15/2012 6:55 AM, Gerry Weaver wrote:

Hi Andreas,

...

I am not comfortable with the idea to write parts of an application in different languages. Typically the disadvantages overweigh the advantages to do so as you would have different languages and systems to master and update. Interoperability with other systems and languages should be easy and Squeak/Pharo are still lacking in this area. This is well known and hopefully there will be some improvements in the future.

I guess I would have to disagree with you here. Most of the editors and IDEs of other languages are not maintained by the language proper. There are many editors and IDEs that support many languages in addition to the one they are written in. I think the benefits of using a full featured GUI toolkit to create an IDE would be significant.

And I have to disagree with you here. You lack the imagination and knowledge to understand the significant advantage of having a single language, environment and toolset that Smalltalk provides.

...

Planning to give up on parts like GUI is a bad idea in my opinion. Smalltalk would be even more niche than it is now. I want to be able to build complete applications without the need to build parts in another language.

In theory I would agree with you. However, I wasn't able to come up with an application scenario where the Pharo GUI would work. Either the widget set and OS integration are too limited or performance is a problem. For example, the last several applications I have done needed to display PDF files. I have done a little testing with Pharo and I'm sorry to say the results were not very encouraging. The problem I think is one of limited resources. I think that maybe trimming some things would render more progress on the core. Perhaps a good and complete binding to one of the current GUI toolkits would be easier to maintain. You would also get the instant advantage of everything the toolkit had to offer (including performance). A more robust FFI would inevitably be realized as a result.

Again, I think you lack imagination. You are stuck in box built by all your previous tools and experience. And from your box you are trying to look at Smalltalk and trying to shape it to your experience and thusly declaring its deficiencies. This does not make Smalltalk wrong. Most of us here like the Smalltalk experience. We like the language. We like the image. Are there issues that we would like to overcome? Of course. Outside of interfacing with the outside world being made easier, I don't think you are really addressing those issues. Instead, your are creating issues we don't have. And many of us find many things we can do living in our world and slowly working on what our world can access. If you want to mold Pharo into the image that you think it should be. Please feel free to do so. It is open source. Fork it and make it so. We would even help where we are able. But you are going outside of the vision and worldview of this community and most any Smalltalk community. Cincom, Gemstone, or any of the other commercial Smalltalks have reasonable success despite all the deficiencies you have discovered. And if you decide that Smalltalk doesn't fit your worldview. That is ok. Find the tool that fits you. Be productive with it. And if you want to create what you think is a better way with what you learn from Smalltalk. Go for it. As far as GUI. I like ours. I think it can be improved greatly. But I like access to it as part of my environment. What is a standard UI? Who set this standard? Why is QT standard? or WxWidgets or ...? Look at the most used apps out there. Are they using native standard UI? I don't think so. iTunes is a hugely used app. Is it standard UI? No. Apple Mail? Safari? Windows Media player? No these things are used by most of the computing world and they don't even use the normal standard native UI of their platform. And they are all ugly. Is Facebook standard? Web apps are used all the time. Who says what is standard. And is what is standard today, what we should strive for? Or can we work towards a better future. I use all kinds of applications which do not meet your standard of being a native standard UI. But I use them. Why? Because they provide the abilities to do what I want or need. Not because they meet any particular standards as defined by nameless potentially clueless people. So more than meeting any particularly defined standard of UI, what is required is than an application be compelling. If it is not, then no matter how standards compliant it will meet with little receptiveness. Is Eclipse, Netbeans, Vi, Emacs standard. Windows or Mac? If Windows, XP, Vista, 7, 8? What is standard on Linux? KDE, Gnome, Unity, pick your favorite WM. So why is it your developers get to use non-standard tools, (Emacs, Vi), or define then standard as being what they use? There are lots of applications where the UI is almost never standard by anyone's definition. In my world financial investment apps. Education apps, games, ... This argument passes no reasonable standard.

...

Especially having the IDE in Smalltalk itself and thus being able to inspect and debug and modify everything is a big advantage over any IDE in a different language.

...

I don't understand why the IDE needs to be in the image/language to do that. All Smalltalk implementations have shortcomings in some areas. There are a multitude of reasons for it, be it commercially (greater estimated expenses than earnings from it) or just lack of capacity. Smalltalk users are rare these days and the community is split because of different implementations and interests. For me, Pharo is on a good way to take the Smalltalk language into a better ecosystem. But for the moment Dolphin Smalltalk is my preferred system because it's relatively cheap and has only few known bugs. In my eyes it deserves a bigger community and better commercial success. But I guess that's what every Smalltalker thinks about his preferred Smalltalk system...

Dolphin seems to be one of the better implementations, but the problem with Dolphin is Windows. All of the projects on my radar right now are moving applications away from Windows to Mac/Linux (mostly Mac).

So, in this statement, by definition you are moving from the most standard defined UI to lesser standard UIs. Linux is all over the map. The above are simply my opinions and I make no express statements that anyone else in the Pharo community agrees with them. Personally I am all for improving the Pharo worlds and making more things accessible within that world. Not necessarily becoming like the world outside of Pharo/Smalltalk. If I want that world, it is already there. I would also presume that by your exploration of our little world, which by the way is 30+ years old, that you have sufficient deficiencies in the world you come from to explore what else is available. Jimmie

+100 On 16 Jan 2012, at 02:44, Jimmie Houchin wrote:

On 1/15/2012 6:55 AM, Gerry Weaver wrote:

...

Hi Andreas,

...

I am not comfortable with the idea to write parts of an application in different languages. Typically the disadvantages overweigh the advantages to do so as you would have different languages and systems to master and update. Interoperability with other systems and languages should be easy and Squeak/Pharo are still lacking in this area. This is well known and hopefully there will be some improvements in the future.

I guess I would have to disagree with you here. Most of the editors and IDEs of other languages are not maintained by the language proper. There are many editors and IDEs that support many languages in addition to the one they are written in. I think the benefits of using a full featured GUI toolkit to create an IDE would be significant.

And I have to disagree with you here. You lack the imagination and knowledge to understand the significant advantage of having a single language, environment and toolset that Smalltalk provides.

...

...

Planning to give up on parts like GUI is a bad idea in my opinion. Smalltalk would be even more niche than it is now. I want to be able to build complete applications without the need to build parts in another language.

In theory I would agree with you. However, I wasn't able to come up with an application scenario where the Pharo GUI would work. Either the widget set and OS integration are too limited or performance is a problem. For example, the last several applications I have done needed to display PDF files. I have done a little testing with Pharo and I'm sorry to say the results were not very encouraging. The problem I think is one of limited resources. I think that maybe trimming some things would render more progress on the core. Perhaps a good and complete binding to one of the current GUI toolkits would be easier to maintain. You would also get the instant advantage of everything the toolkit had to offer (including performance). A more robust FFI would inevitably be realized as a result.

Again, I think you lack imagination. You are stuck in box built by all your previous tools and experience. And from your box you are trying to look at Smalltalk and trying to shape it to your experience and thusly declaring its deficiencies. This does not make Smalltalk wrong.

Most of us here like the Smalltalk experience. We like the language. We like the image. Are there issues that we would like to overcome? Of course. Outside of interfacing with the outside world being made easier, I don't think you are really addressing those issues. Instead, your are creating issues we don't have. And many of us find many things we can do living in our world and slowly working on what our world can access.

If you want to mold Pharo into the image that you think it should be. Please feel free to do so. It is open source. Fork it and make it so. We would even help where we are able. But you are going outside of the vision and worldview of this community and most any Smalltalk community.

Cincom, Gemstone, or any of the other commercial Smalltalks have reasonable success despite all the deficiencies you have discovered.

And if you decide that Smalltalk doesn't fit your worldview. That is ok. Find the tool that fits you. Be productive with it. And if you want to create what you think is a better way with what you learn from Smalltalk. Go for it.

As far as GUI. I like ours. I think it can be improved greatly. But I like access to it as part of my environment.

What is a standard UI? Who set this standard? Why is QT standard? or WxWidgets or ...? Look at the most used apps out there. Are they using native standard UI? I don't think so. iTunes is a hugely used app. Is it standard UI? No. Apple Mail? Safari? Windows Media player? No these things are used by most of the computing world and they don't even use the normal standard native UI of their platform. And they are all ugly.

Is Facebook standard? Web apps are used all the time.

Who says what is standard. And is what is standard today, what we should strive for? Or can we work towards a better future.

I use all kinds of applications which do not meet your standard of being a native standard UI. But I use them. Why? Because they provide the abilities to do what I want or need. Not because they meet any particular standards as defined by nameless potentially clueless people.

So more than meeting any particularly defined standard of UI, what is required is than an application be compelling. If it is not, then no matter how standards compliant it will meet with little receptiveness.

Is Eclipse, Netbeans, Vi, Emacs standard. Windows or Mac? If Windows, XP, Vista, 7, 8? What is standard on Linux? KDE, Gnome, Unity, pick your favorite WM. So why is it your developers get to use non-standard tools, (Emacs, Vi), or define then standard as being what they use?

There are lots of applications where the UI is almost never standard by anyone's definition. In my world financial investment apps. Education apps, games, ...

This argument passes no reasonable standard.

...

...

Especially having the IDE in Smalltalk itself and thus being able to inspect and debug and modify everything is a big advantage over any IDE in a different language.

...

I don't understand why the IDE needs to be in the image/language to do that. All Smalltalk implementations have shortcomings in some areas. There are a multitude of reasons for it, be it commercially (greater estimated expenses than earnings from it) or just lack of capacity. Smalltalk users are rare these days and the community is split because of different implementations and interests. For me, Pharo is on a good way to take the Smalltalk language into a better ecosystem. But for the moment Dolphin Smalltalk is my preferred system because it's relatively cheap and has only few known bugs. In my eyes it deserves a bigger community and better commercial success. But I guess that's what every Smalltalker thinks about his preferred Smalltalk system...

Dolphin seems to be one of the better implementations, but the problem with Dolphin is Windows. All of the projects on my radar right now are moving applications away from Windows to Mac/Linux (mostly Mac).

So, in this statement, by definition you are moving from the most standard defined UI to lesser standard UIs. Linux is all over the map.

The above are simply my opinions and I make no express statements that anyone else in the Pharo community agrees with them.

Personally I am all for improving the Pharo worlds and making more things accessible within that world. Not necessarily becoming like the world outside of Pharo/Smalltalk. If I want that world, it is already there.

I would also presume that by your exploration of our little world, which by the way is 30+ years old, that you have sufficient deficiencies in the world you come from to explore what else is available.

Jimmie

On 16 January 2012 09:59, Lawson English <lenglish5@cox.net> wrote:

On 1/15/12 6:44 PM, Jimmie Houchin wrote:

...

On 1/15/2012 6:55 AM, Gerry Weaver wrote:

...

Hi Andreas,

...

I am not comfortable with the idea to write parts of an application in different languages. Typically the disadvantages overweigh the advantages to do so as you would have different languages and systems to master and update. Interoperability with other systems and languages should be easy and Squeak/Pharo are still lacking in this area. This is well known and hopefully there will be some improvements in the future.

I guess I would have to disagree with you here. Most of the editors and IDEs of other languages are not maintained by the language proper. There are many editors and IDEs that support many languages in addition to the one they are written in. I think the benefits of using a full featured GUI toolkit to create an IDE would be significant.

And I have to disagree with you here. You lack the imagination and knowledge to understand the significant advantage of having a single language, environment and toolset that Smalltalk provides.

I agree that there is an advantage to having a unified IDE/environment/etc, but Smalltalk IS stuck in the past in that it doesn't take advantage of multiple cores. I'm not talking about multi-threading in the usual sense, but things like the ability to debug one image from another so that the errors that pop up in the application under development don't affect the environment being used TO development that application. This issue pops up most obviously when trying to debug Cobalt/Croquet in a multi-user configuration, but arises all the time, especially when external libraries (e.g. OpenGL) are being used and errors occur that the current toolset isn't designed to accommodate.

We need to develop better ways of doing things, both for individual and collaborative environments. IOW, we need spoon and teatime and various other solutions to mature and work together.

If only we knew some folks working on the problem... http://marcusdenker.de/publications/Casa09aObjectSpaces.pdf :) Of course, there's a bit of elbow grease required to turn a research topic into a production-ready system. frank

Thanks jimmie :) You summarize well some of my thoughts. Stef going back to talk to an image with one process and no ui and trying to get a repl so that I can debug our 3.2 mb image :). Yes the way to bootstrapping is slow :)

On 1/15/2012 6:55 AM, Gerry Weaver wrote:

...

Hi Andreas,

...

I am not comfortable with the idea to write parts of an application in different languages. Typically the disadvantages overweigh the advantages to do so as you would have different languages and systems to master and update. Interoperability with other systems and languages should be easy and Squeak/Pharo are still lacking in this area. This is well known and hopefully there will be some improvements in the future.

I guess I would have to disagree with you here. Most of the editors and IDEs of other languages are not maintained by the language proper. There are many editors and IDEs that support many languages in addition to the one they are written in. I think the benefits of using a full featured GUI toolkit to create an IDE would be significant.

And I have to disagree with you here. You lack the imagination and knowledge to understand the significant advantage of having a single language, environment and toolset that Smalltalk provides.

...

...

Planning to give up on parts like GUI is a bad idea in my opinion. Smalltalk would be even more niche than it is now. I want to be able to build complete applications without the need to build parts in another language.

In theory I would agree with you. However, I wasn't able to come up with an application scenario where the Pharo GUI would work. Either the widget set and OS integration are too limited or performance is a problem. For example, the last several applications I have done needed to display PDF files. I have done a little testing with Pharo and I'm sorry to say the results were not very encouraging. The problem I think is one of limited resources. I think that maybe trimming some things would render more progress on the core. Perhaps a good and complete binding to one of the current GUI toolkits would be easier to maintain. You would also get the instant advantage of everything the toolkit had to offer (including performance). A more robust FFI would inevitably be realized as a result.

Again, I think you lack imagination. You are stuck in box built by all your previous tools and experience. And from your box you are trying to look at Smalltalk and trying to shape it to your experience and thusly declaring its deficiencies. This does not make Smalltalk wrong.

Most of us here like the Smalltalk experience. We like the language. We like the image. Are there issues that we would like to overcome? Of course. Outside of interfacing with the outside world being made easier, I don't think you are really addressing those issues. Instead, your are creating issues we don't have. And many of us find many things we can do living in our world and slowly working on what our world can access.

If you want to mold Pharo into the image that you think it should be. Please feel free to do so. It is open source. Fork it and make it so. We would even help where we are able. But you are going outside of the vision and worldview of this community and most any Smalltalk community.

Cincom, Gemstone, or any of the other commercial Smalltalks have reasonable success despite all the deficiencies you have discovered.

And if you decide that Smalltalk doesn't fit your worldview. That is ok. Find the tool that fits you. Be productive with it. And if you want to create what you think is a better way with what you learn from Smalltalk. Go for it.

As far as GUI. I like ours. I think it can be improved greatly. But I like access to it as part of my environment.

What is a standard UI? Who set this standard? Why is QT standard? or WxWidgets or ...? Look at the most used apps out there. Are they using native standard UI? I don't think so. iTunes is a hugely used app. Is it standard UI? No. Apple Mail? Safari? Windows Media player? No these things are used by most of the computing world and they don't even use the normal standard native UI of their platform. And they are all ugly.

Is Facebook standard? Web apps are used all the time.

Who says what is standard. And is what is standard today, what we should strive for? Or can we work towards a better future.

I use all kinds of applications which do not meet your standard of being a native standard UI. But I use them. Why? Because they provide the abilities to do what I want or need. Not because they meet any particular standards as defined by nameless potentially clueless people.

So more than meeting any particularly defined standard of UI, what is required is than an application be compelling. If it is not, then no matter how standards compliant it will meet with little receptiveness.

Is Eclipse, Netbeans, Vi, Emacs standard. Windows or Mac? If Windows, XP, Vista, 7, 8? What is standard on Linux? KDE, Gnome, Unity, pick your favorite WM. So why is it your developers get to use non-standard tools, (Emacs, Vi), or define then standard as being what they use?

There are lots of applications where the UI is almost never standard by anyone's definition. In my world financial investment apps. Education apps, games, ...

This argument passes no reasonable standard.

...

...

Especially having the IDE in Smalltalk itself and thus being able to inspect and debug and modify everything is a big advantage over any IDE in a different language.

...

I don't understand why the IDE needs to be in the image/language to do that. All Smalltalk implementations have shortcomings in some areas. There are a multitude of reasons for it, be it commercially (greater estimated expenses than earnings from it) or just lack of capacity. Smalltalk users are rare these days and the community is split because of different implementations and interests. For me, Pharo is on a good way to take the Smalltalk language into a better ecosystem. But for the moment Dolphin Smalltalk is my preferred system because it's relatively cheap and has only few known bugs. In my eyes it deserves a bigger community and better commercial success. But I guess that's what every Smalltalker thinks about his preferred Smalltalk system...

Dolphin seems to be one of the better implementations, but the problem with Dolphin is Windows. All of the projects on my radar right now are moving applications away from Windows to Mac/Linux (mostly Mac).

So, in this statement, by definition you are moving from the most standard defined UI to lesser standard UIs. Linux is all over the map.

The above are simply my opinions and I make no express statements that anyone else in the Pharo community agrees with them.

Personally I am all for improving the Pharo worlds and making more things accessible within that world. Not necessarily becoming like the world outside of Pharo/Smalltalk. If I want that world, it is already there.

I would also presume that by your exploration of our little world, which by the way is 30+ years old, that you have sufficient deficiencies in the world you come from to explore what else is available.

Jimmie

On 16 January 2012 20:08, Sean P. DeNigris <sean@clipperadams.com> wrote:

After pounding at the system and countless books/articles/keynotes, I get that Smalltalk is a vision, not a syntax. Fortunately, I was hooked from the beginning by Alan Kay's TED Talk, so I enthusiastically pushed through the pain of adapting to the image, losing my vi bindings, etc. If it was only about syntax, without the live, open, dynamic, turtles-all-the-way-down system, I would probably use Ruby, which has more of the libraries I need and want (although I would definitely miss passing blocks as any argument, and keywords are nice).

*However*, like any "blue plane" idea, there are people that don't get it (and actually /can't/ get it) and want to relate to Smalltalk as "a language with cool syntax", giving up the productivity of a live environment. This is the nature of paradigm shift.

Now, while I feel bad that those people are totally missing out on the magic, if they are willing to join our community and contribute to the libraries, fix bugs, user test, etc., let's welcome them with crappy (i.e. standard) tools and reap the benefits of more pairs of hands and eyes.

I've been biting my tongue for a while now in this thread. Please don't take this the wrong way, we're all interested in the same wonderful language and environment, and so on. But. I've seen just about every time someone joins a Smalltalk community and dares to suggest that they've had enjoyable experiences with FOO, the Smalltalk community forms a laager (I think Americans would call this "circle the wagons!"), with statements like "you lack imagination" or "when you get it" or whatever. There are many sources of value that are not present in the Smalltalk community, that were not invented in the Smalltalk community. Someone saying that they like FOO might actually have experience in both Smalltalk and elsewhere. They might actually know a thing or two about software, about Smalltalk, and STILL not be satisfied with what Smalltalk has to offer. We should be HAPPY about this! We should carefully examine new things, and learn new languages, so that we can _pillage these ideas_. Knee-jerk rejection of ideas that didn't stem from the hallowed halls of the Golden Age of Smalltalk means the rest of the world passes you by, out-innovates you, renders you obsolete. (Quibble: Ruby _is_ a live, dynamic, turtles-all-the-way-down system. It's just a pity it has a rubbish syntax. But otherwise, Avi Bryant's right: it's a Smalltalk. It's just that Rubyists don't live in their image, more like construct a tent and tear it down. (It makes me angry that I can sometimes feel more productive writing Ruby in Emacs than in Squeak/Pharo! Why can I not have BOTH a world-class text editor AND live in an image (when I choose to)?)) frank

I'm sure it won't be long before they are pair programming with or watching someone at ESUG/Smalltalks/STIC who "gets it". When they start zipping through senders and implementors, inspecting live objects, and opening debuggers, I'm sure many will start to understand. Not all popcorn kernels pop at the same time.

Hopefully, one of the converts will finally implement vi bindings in the image development tools before I get around to doing the work ;-)

Sean

-- View this message in context: http://forum.world.st/Misc-newbie-questions-tp4268310p4301259.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

On Mon, Jan 16, 2012 at 2:43 PM, Frank Shearar <frank.shearar@gmail.com>wrote:

Frank, I agree with what you said EXCEPT that I don't see the NIH mentality in Smalltalk. What I do see, and have seen a lot of over the years, is people coming in and banging on Smalltalk's differences without taking the time to learn the whys and wherefores. I don't think it's knee-jerk defense so much as a creeping sense that the person complaining maybe isn't in the best position to do so. (And I say this as someone who's been on several sides of the argument.)

Am 17.01.2012 um 13:26 schrieb Frank Shearar:

On 17 January 2012 03:20, blake <dsblakewatson@gmail.com> wrote:

...

On Mon, Jan 16, 2012 at 2:43 PM, Frank Shearar <frank.shearar@gmail.com> wrote:

Frank,

I agree with what you said EXCEPT that I don't see the NIH mentality in Smalltalk. What I do see, and have seen a lot of over the years, is people coming in and banging on Smalltalk's differences without taking the time to learn the whys and wherefores. I don't think it's knee-jerk defense so much as a creeping sense that the person complaining maybe isn't in the best position to do so. (And I say this as someone who's been on several sides of the argument.)

I'm aware of the reasons why the NIH arises, and I'm sure that's part of why the reaction arises in many other communities. I reserve the right to say "ahem, take the time to actually read what the person's asking for, because they might actually have good ideas".

And, in particular, Gerry raises concerns _this very list_ has raised. Living permanently in the image is _bad_, which is why we're moving to Metacello for everything so we can _construct_ an image. Look at There is a big difference between rescuing artifacts outside the image for distribution, reuse and storage and working outside the image. I would like to be able to remotely debug Smalltalk but not for the price of giving up what we already have. For me there is a big advantage to have the "living objects world". There might be alternatives to the image concept in order to have it. But Eclipse, NetBeans, Emacs, vi and Visual Studio don't provide anything better. Each these IDE's are in itself bigger and more complex than Pharo. These IDE's provide tools to deal with big muds of dead code - quite the opposite of a "living objects world". With each new release the get a little bit nearer to what our "living object world" gives us but with the big price tag of overwhelming complexity and never being able to really overtake.

So yes, we should be open minded to enhance our world. Eg. Pharo lacks some standard widgets like a grid. The whole GUI framework should be modernized. Polymorph is a step in the right direction in my opinion. Our versioning systems should be able to deal with artifacts (documents, drawings and so on) from the outside world. But unless the versioning system of the outside world will provide what we need there is no real advance in using them for Smalltalk. There are already alternatives to the standard Smalltalk systems. GNU smalltalk left behind the image and is using a standard GUI framework. You can edit the code in your preferred editor. F-Script is an example for embedding the Smalltalk syntax in the Mac world. The Cocoa framework is directly accessible. There are other Smalltalks directly embedded into Java, DOT.NET and even Javascript. So a lot of people already had the idea to move outside the traditional Smalltalk world and did that in several projects. But to my knowledge they didn't get much attention. No revolution happened. Andreas

On 1/17/2012 2:57 PM, Frank Shearar wrote:

Emacs + SLIME = image-based, interactive development. As image-based as you'd like, at least. Eclipse + Cusp = image-based development: you're connecting to a running Common Lisp image, which you can snapshot and restore any time you like (just like choosing to work in a built image or in a persistent one). IDE and "living world" are orthogonal concerns.

Ok. I have no experience in this realm. It may be exactly as you say. But within the context of this discussion and this discussion occurring in a Smalltalk forum I want to bring up a common Smalltalk experience. One thing that I dearly love in my Pharo environment is this. I have multiple browser windows open with code I am viewing or editing. I have one or more workspaces open with code and objects that I am experimenting with or exploring their values to learn. I save my image, and open back up and all of that is there ready for me to continue. I can do this with the image on a flash drive, the local drive or on a network. With this Emacs + SLIME can I do some thing similar? Honest question, honest comparison? I suspect the answer, but I do not factually know it. When I restore an Emacs+SLIME image. Do I have available the editing and the REPL (or workspace like element) exactly as I left it. Cursors in the original location. Workspace like elements with the objects available for exploration. If as I suspect the answer is no. Then we are not exactly talking about the same things. Maybe similar or close, but not the same. However, I am happy to agree that LISPs are worlds ahead of most other languages in this regard. For me this is one simple value of the IDE in the image and being one of the many live objects I am editing. One of the things that was seen as having no value in this discussion. And as I stated, if the proposer sees no value in this. Fine, do what works for you. Jimmie

On 1/16/2012 4:43 PM, Frank Shearar wrote:

On 16 January 2012 20:08, Sean P. DeNigris<sean@clipperadams.com> wrote:

...

After pounding at the system and countless books/articles/keynotes, I get that Smalltalk is a vision, not a syntax. Fortunately, I was hooked from the beginning by Alan Kay's TED Talk, so I enthusiastically pushed through the pain of adapting to the image, losing my vi bindings, etc. If it was only about syntax, without the live, open, dynamic, turtles-all-the-way-down system, I would probably use Ruby, which has more of the libraries I need and want (although I would definitely miss passing blocks as any argument, and keywords are nice).

*However*, like any "blue plane" idea, there are people that don't get it (and actually /can't/ get it) and want to relate to Smalltalk as "a language with cool syntax", giving up the productivity of a live environment. This is the nature of paradigm shift.

Now, while I feel bad that those people are totally missing out on the magic, if they are willing to join our community and contribute to the libraries, fix bugs, user test, etc., let's welcome them with crappy (i.e. standard) tools and reap the benefits of more pairs of hands and eyes.

I've been biting my tongue for a while now in this thread. Please don't take this the wrong way, we're all interested in the same wonderful language and environment, and so on.

But.

I've seen just about every time someone joins a Smalltalk community and dares to suggest that they've had enjoyable experiences with FOO, the Smalltalk community forms a laager (I think Americans would call this "circle the wagons!"), with statements like "you lack imagination" or "when you get it" or whatever.

Well lets be specific. When I spoke of lacking imagination it was specifically referencing two different areas. 1) The advantage of a live environment where your editor and your code exist together. No I did not explain the advantages. Maybe I should have. But I patently despise dead code editors and their lack of understanding of my code. Yuck! Anyone who loves them may use them. 2) He couldn't think of an area where Pharo's GUI would be suitable for an application. Yes, that is a total lack of imagination. I listed multiple areas where the application uses UI elements which differ from the standard UI of the platform. I have a harder time something that meets the ethereal standards desired by such. I don't know of a web browser that uses the OSes menu bar or UI elements, mail program, etc. There is really very little consistency in applications beyond the use of common elements which are often provided by the apps libraries and not the OS. Menu bars, icons, context sensitive menus, etc. Unless you absolutely require the widgets provided by the OS, which is a standard OS vendors don't adhere to, then you can do most of the same thing in Pharo. I won't argue that it may not be as easy as we would like. But that is a far cry from we need a native UI via QT (or insert favorite widget library). In another message he spoke that he wanted the language and libraries, but almost everything else could go. If that's what you want, get Ruby and run. As I said, this is open source. If he or anyone else wants to pursue the vision he laid out, please go for it. And where his vision and ours overlap, we could cooperate. But if he or whomever want others to join them in such a vision, they would have to provide a compelling argument. I just don't this audience here is the right one to sell it to. And this problem is not unique to Smalltalk and its hallowed halls or it adherents and their narrow-mindedness. No, you can find it in almost any group who has somebody coming in from the outside and telling them that they need feature X that their favorite language/tool provide. Go to the Python group and try to persuade them they need an image. It will get shot down. You can Google it if you wish. Tell them they need all the features of Perl. Or that white space significant syntax is all wrong. Tell some other language they don't need the semicolons because... Go to any other group and tell them their distinctives are wrong and they should adopt your ideas and you'll get a similar outcome. And if you wandered into comp.lang.lisp and got a reply from Erik Naggum (RIP), take cover. If you are going to come into a Smalltalk group with ideas you think we need to adopt, then be prepared to engage in vigorous challenges. Provide compelling arguments in a give and take. Don't expect us to automatically lay down and say your right. We've been doing it wrong all along. If the ideas do not get accepted either because of merit or the supposed narrow-mindedness of the community. Then it is either due to the merit of the idea not actually working. Or there is a difference of vision. That doesn't make the vision of the community the wrong one. It would be incumbent on the other individual to develop his vision and create a community around it. And do the work. Differences in vision are ok. But the individuals making the challenges need to accept that their vision may not be accepted by community they are challenging.

There are many sources of value that are not present in the Smalltalk community, that were not invented in the Smalltalk community. Someone saying that they like FOO might actually have experience in both Smalltalk and elsewhere. They might actually know a thing or two about software, about Smalltalk, and STILL not be satisfied with what Smalltalk has to offer. We should be HAPPY about this! We should carefully examine new things, and learn new languages, so that we can _pillage these ideas_.

Yes, there are many things that the outside world does well. We should learn from them. Use them where appropriate. But that does not mean give up who or what we are. This poster expressed his knowledge and understanding of Smalltalk explicitly. We didn't impute anything. Do you really think that any new ideas were offered. I don't.

Knee-jerk rejection of ideas that didn't stem from the hallowed halls of the Golden Age of Smalltalk means the rest of the world passes you by, out-innovates you, renders you obsolete.

I think the knee-jerk reaction is yours. You act as if anybody who states anything contrary can't be challenged. And as I see in your post, you offer no comments as to where we are misunderstanding the values proposed or where my or anyone else's comments are wrong. You provide no substance. That hallowed hall of the Golden Age of Smalltalk contains much value and much wisdom. Most of us here aren't so willing to jettison quite as easy as those who don't even value it.

(Quibble: Ruby _is_ a live, dynamic, turtles-all-the-way-down system. It's just a pity it has a rubbish syntax. But otherwise, Avi Bryant's right: it's a Smalltalk. It's just that Rubyists don't live in their image, more like construct a tent and tear it down. (It makes me angry that I can sometimes feel more productive writing Ruby in Emacs than in Squeak/Pharo! Why can I not have BOTH a world-class text editor AND live in an image (when I choose to)?))

I am all for improving our editing experience. But I want it in my image and not in Emacs/vi. I would rather see our world improved than to see it require an external editor which sees code as text, not objects, where different external editors have differing features. Unity in tools and vision have tremendous value. I really hate that when I am using other languages that I have to choose which features I value most, because Netbeans has X, PyDev has Y, ... and then I want to do some Clojure and the editor I use in Python isn't as well supported by Clojure. Or Ruby or ... Then you also get the lack of unity in almost anything else. Git vs. Mercurial. Github vs. Bitbucket. ... And yes, I am thoroughly pro Pharo. Do I believe there are deficiencies. Yes. I just don't believe the GUI being non-standard, the image, and the editor being in the image are not among them. And I don't believe that challenges to those things should go unchallenged and accepted just because somebody And yes, I am just as opinionated about my perceptions of the deficiencies of Python, Clojure, Ruby, Eclipse, Netbeans, ... Or my frustrations when using them. I just don't go into those communities expecting them to shape their favorite tool to my vision. I rather try to use their tools and attempt to learn their values and ways, assuming they have reason and purpose for their language and tools. I recently spent a while learning Clojure (beginning of the journey). And what I learned I bring back into the development of my application in Pharo. The biggest problem is people visiting a community and believing they have the right to speak into that community. If you want that right, spend some time here. Develop community relations. Then in time you earn that right to be heard. I have limited rights to be heard here because I have been a part of the Squeak/Pharo community for a long time. I have less rights than others because I haven't contributed anything of consequence. Others who have been here far less time but have contributed a lot more, have greater rights. Just my opinions. But I think that they are reasonably founded. I spend a lot more time with people than programming. Jimmie

hi guys this was a lively discussion. Now it you want to improve our system, you can do it!. Did you see my easy to guess wonderful subliminal message? We have no problem of vision just lack of manpower. I always wanted the best of both worlds: a scriptable system with a syntax for VI lovers with a image when you want it based on a core that can bootstrap itself and load package at lighting speed. BTW I'm writing a document explaining the goals, process and current efforts in Pharo so that people can understand the big picture and join and help Stef

2012/1/18 laurent laffont <laurent.laffont@gmail.com>

Ah yes another thing which wouuld be nice to have something with one can

...

understand without studying it for years and repeated tries. A simple way of building somewhat resembling GUI applications in Pharo/Squeak. Ah yes flame me that I do appreciate the fantastic Morph world. It's so fantastic that just the developers can build a somewhat "usable" interface with it. Tell me about the "great" applicatons using Morph (anything besides yet another Browser please)

I has two financial domain applications based on Presenty which works with Morphic backend. I think morphic is the best UI. It is only UI framework which reflect smalltalk live object enviroment. Any primitive UI part is live object which you can touch (debug, inspect,...) But Morphic has many problems in design and implementation part which I sure will be fixed in future.

I think yes. But our organisation dont want to share smalltalk roots of this products :(. So it is just screenshots 2012/1/18 Stéphane Ducasse <stephane.ducasse@inria.fr>

Denis

could we put your screenshots on our web site?

Stef

On Jan 18, 2012, at 9:53 AM, Denis Kudriashov wrote:

...

2012/1/18 laurent laffont <laurent.laffont@gmail.com> Ah yes another thing which wouuld be nice to have something with one can understand without studying it for years and repeated tries. A simple way of building somewhat resembling GUI applications in Pharo/Squeak. Ah yes flame me that I do appreciate the fantastic Morph world. It's so fantastic that just the developers can build a somewhat "usable" interface with it. Tell me about the "great" applicatons using Morph (anything besides yet another Browser please)

I has two financial domain applications based on Presenty which works with Morphic backend. I think morphic is the best UI. It is only UI framework which reflect smalltalk live object enviroment. Any primitive UI part is live object which you can touch (debug, inspect,...)

But Morphic has many problems in design and implementation part which I sure will be fixed in future. <kassa.png><kioskBankCabinet.png><kioskInputForm.png>

On 18 January 2012 07:19, Friedrich Dominicus <frido@q-software-solutions.de> wrote:

Jimmie Houchin <jlhouchin@gmail.com> writes:

...

I am all for improving our editing experience. But I want it in my image and not in Emacs/vi. I would rather see our world improved than to see it require an external editor which sees code as text, not objects, where different external editors have differing features. Well I suggest then to start with adding an Editor which deserves that name. By all means the  editors in any Smalltalk are poor. And now that you mention Emacs. There is nothing comparable to this Editor for Text editing in any Smalltalk world-wide. So yes you an live within the live "objects!" but you have to leave them whenever you want to write something more but 5 lines of code.

And yes, I am thoroughly pro Pharo. Do I believe there are deficiencies. Yes. I just don't believe the GUI being non-standard, the image, and the editor being in the image are not among them. And I don't believe that challenges to those things should go unchallenged and accepted just because somebody Ah yes another thing which wouuld be nice to have something with one can understand without studying it for years and repeated tries. A simple way of building somewhat resembling GUI applications in Pharo/Squeak. Ah yes flame me that I do appreciate the fantastic Morph world. It's  so fantastic that just the developers can build a somewhat "usable" interface with it. Tell me about the "great" applicatons using Morph (anything besides yet another Browser please)

And yes, I am just as opinionated about my perceptions of the deficiencies of Python, Clojure, Ruby, Eclipse, Netbeans, ... Or my frustrations when using them. I just don't go into those communities expecting them to shape their favorite tool to my vision. I rather try to use their tools and attempt to learn their values and ways, assuming they have reason and purpose for their language and tools. Well at least you get an Editor with Eclipse and Netbeans. But yeah we don't need not stinking Editor.

The editor in Pharo suits my needs pretty well. I do not use it for editing rich text , i use it for coding. 5 lines of code per method. Period. No need for code folding, no need for sophisticated regex search/replace. No need bookmarks No need for (put your favorite). Just because it is there for coding in smalltalk. If you want an editor which can edit books, feel free to implement it. I am using bicycle to get to work. It is comfortable, fast and reliable for daily use. Now what you would think about a guy on street who attempting to laugh at me because my bike don't have jet engine to travel to Earth's orbit?

Regards Friedrich

-- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus

-- Best regards, Igor Stasenko.

On 18 January 2012 16:13, Friedrich Dominicus <frido@q-software-solutions.de> wrote:

Igor Stasenko <siguctua@gmail.com> writes:

...

The editor in Pharo suits my needs pretty well. I do not use it for editing rich text , i use it for coding. 5 lines of code per method. Period.

Well for programming this is true, but even as programmer you type text quite often. This e.g is written using Emacs. It can handle anything which resembles text. Now do that with PharoEditor. Search for a "simple" think as a news reader with a decent Editor in any software written in Smalltal goo luck

...

No need for code folding, no need for sophisticated regex search/replace. No need bookmarks No need for (put your favorite). Just because it is there for coding in smalltalk. If you want an editor which can edit books, feel free to implement it. Yes that's an easy escape isn't it. Do it yourself, you do not have anything else to do.

I am using bicycle to get to work. It is comfortable, fast and reliable for daily use. Now what you would think about a guy on street who attempting to laugh at me because my bike don't have jet engine to travel to Earth's orbit? Even you handle text and you do not use Pharo for that. So yes it's a wonderful world of POT.

It does not make sense to really pinpoint on the most weakest spots in ones Universe. No you are right everything is fine and that what is not fine, can be easily self-programmed. So make me an offer to implement a decent Editor in Pharo with at least a somewhat useful Gui. Should be a piece of cake shouldn't it?

I will not stress you too much just something like Evolution yepp even outlook firebird would suite my needs.

Now Smalltalk is now how old? And nothing like that even near existence. Probably it's not that easy....

Before the thread devolves any further into flames: this thread started because Gerry pointed out some deficiencies in Pharo's toolset. I took umbrage at what I consider to be dismissive remarks. The Pharo folk lack manpower, so I consider it a perfectly valid response for Igor/Stephane/whoever to say "go write it yourself, because we're too busy". So far we've established that there's desire in the community for a REPL-like interface to a running image (see Coral, Gerry's comments, my comments). I suggest we go look at a few such things and see what we like or not. I'm told swank-js has a primitive/simple (hence understandable) architecture showing how to connect emacs + SLIME to node.js, so that's where I've started. With a similar back end in Pharo we should allow suitable separation to allow Coral to talk to it, AND allow emacs monkeys to talk to it, thus reducing the overall effort. To be precise: this lets Coral and emacs people do what they want on the client side while being able to share the server side. frank

On 17 January 2012 06:34, Jimmie Houchin <jlhouchin@gmail.com> wrote:

I have limited rights to be heard here because I have been a part of the Squeak/Pharo community for a long time. I have less rights than others because I haven't contributed anything of consequence. Others who have been here far less time but have contributed a lot more, have greater rights.

I don't think there should be any "rights" related to level of contribution. But it is true, you are much likely will be heard and your ideas taken into account, if you will show others your dedication. And of course a simplest way of showing it is to contribute :)

Just my opinions. But I think that they are reasonably founded. I spend a lot more time with people than programming.

Jimmie

-- Best regards, Igor Stasenko.

Hi--

...

(It makes me angry that I can sometimes feel more productive writing Ruby in Emacs than in Squeak/Pharo! Why can I not have BOTH a world-class text editor AND live in an image (when I choose to)?))

This is why I want Coral.

Another approach is to just make Smalltalk appear as an entire filesystem. Then any editor can speak to it like any other hard disk. For an example (using WebDAV), see [1]. -C [1] http://tinyurl.com/7j26wk6 (thiscontext.wordpress.com) -- Craig Latta www.netjam.org/resume +31 6 2757 7177 + 1 415 287 3547

On 22 Feb 2012, at 21:52, Frank Shearar wrote:

But I think such a plugin would be missing the point. What I want is to be able to see a lot more source on my screen than one method at a time. Do you remember the Whisker Browser a few years ago? It let you view and edit multiple methods at a time, across multiple classes. That was pretty neat.

You refer to this one? http://www.fit.vutbr.cz/study/courses/OMP/public/software/sqcdrom2/Packages/... Cool, but I like the feeling of Newspeaks' one still better (random link with screenshots: http://langexplr.blogspot.com/2009/04/writing-small-twitter-client-with.html) Is there actually anyone who would be interested to break with the Smalltalk's traditional approach? -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

On Thu, Feb 23, 2012 at 3:33 AM, Frank Shearar <frank.shearar@gmail.com>wrote:

On 22 February 2012 21:12, Stefan Marr <smalltalk@stefan-marr.de> wrote:

...

On 22 Feb 2012, at 21:52, Frank Shearar wrote:

...

But I think such a plugin would be missing the point. What I want is to be able to see a lot more source on my screen than one method at a time. Do you remember the Whisker Browser a few years ago? It let you view and edit multiple methods at a time, across multiple classes. That was pretty neat.

You refer to this one?

http://www.fit.vutbr.cz/study/courses/OMP/public/software/sqcdrom2/Packages/...

...

Cool, but I like the feeling of Newspeaks' one still better (random link

with screenshots: http://langexplr.blogspot.com/2009/04/writing-small-twitter-client-with.html )

I confess I find the Brazil browser deeply confusing and, when I started getting the hang of it, found it even more "pinhole-y" than the standard browser. I started a project to build a SLIME-like REPL to a running Newspeak image, but I've so far merely written a minor mode (https://github.com/frankshearar/newspeak-mode). I will at some point pick up that work again.

...

Is there actually anyone who would be interested to break with the Smalltalk's traditional approach?

Well, me! One thing that would make my life considerably easier is a MessageSet-like browser that "flattened" the methods, so they were displayed one above the other - simulating a text file, in other words. So many times I want to look at how a set of classes implement some method.

+1 exactly my sentiment..

frank

...

-- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

I hope you've seen CodeBubbles[0]... Wouldn't it be better something like that? If you want to see more than one method (understandable situation), you open multiple "method views" and that's it. Seeing a whole class as a file doesn't solve much of the problem: nothing guarantees the methods you want to see are toghether in "the file", and nothing guarantees the methods belong to the same class... Maybe just decoupling the method pane from the rest of the browser (and providing some popping-out mechanism to have multiple method panes at the same time) could help? [0] http://www.andrewbragdon.com/codebubbles_site.asp On Thu, Feb 23, 2012 at 1:43 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

good idea!

Stef

On Feb 22, 2012, at 11:03 PM, Frank Shearar wrote:

...

Well, me! One thing that would make my life considerably easier is a MessageSet-like browser that "flattened" the methods, so they were displayed one above the other - simulating a text file, in other words. So many times I want to look at how a set of classes implement some method.

On 23 February 2012 19:47, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

Sure we know. And we also know that it requires effort and lot of people are talking.

are *just* talking. :)

Stef

On Feb 23, 2012, at 7:27 PM, Matias Garcia Isaia wrote:

...

I hope you've seen CodeBubbles[0]...

Wouldn't it be better something like that? If you want to see more than one method (understandable situation), you open multiple "method views" and that's it. Seeing a whole class as a file doesn't solve much of the problem: nothing guarantees the methods you want to see are toghether in "the file", and nothing guarantees the methods belong to the same class...

Maybe just decoupling the method pane from the rest of the browser (and providing some popping-out mechanism to have multiple method panes at the same time) could help?

[0] http://www.andrewbragdon.com/codebubbles_site.asp

On Thu, Feb 23, 2012 at 1:43 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

...

good idea!

Stef

On Feb 22, 2012, at 11:03 PM, Frank Shearar wrote:

...

Well, me! One thing that would make my life considerably easier is a MessageSet-like browser that "flattened" the methods, so they were displayed one above the other - simulating a text file, in other words. So many times I want to look at how a set of classes implement some method.

-- Best regards, Igor Stasenko.

On Thu, Feb 23, 2012 at 7:27 PM, Matias Garcia Isaia <mgarciaisaia@gmail.com

wrote:

I hope you've seen CodeBubbles[0]...

Nooo!!! he comes from Java!! he starts with index 0. Kill him!!! ;) Just kidding, I know him :)

Wouldn't it be better something like that? If you want to see more than one method (understandable situation), you open multiple "method views" and that's it. Seeing a whole class as a file doesn't solve much of the problem: nothing guarantees the methods you want to see are toghether in "the file", and nothing guarantees the methods belong to the same class...

Maybe just decoupling the method pane from the rest of the browser (and providing some popping-out mechanism to have multiple method panes at the same time) could help?

[0] http://www.andrewbragdon.com/codebubbles_site.asp

On Thu, Feb 23, 2012 at 1:43 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

...

good idea!

Stef

On Feb 22, 2012, at 11:03 PM, Frank Shearar wrote:

...

Well, me! One thing that would make my life considerably easier is a MessageSet-like browser that "flattened" the methods, so they were displayed one above the other - simulating a text file, in other words. So many times I want to look at how a set of classes implement some method.

-- Mariano http://marianopeck.wordpress.com

On 24 February 2012 00:18, Matias Garcia Isaia <mgarciaisaia@gmail.com> wrote:

On Thu, Feb 23, 2012 at 5:08 PM, Mariano Martinez Peck <marianopeck@gmail.com> wrote:

...

Nooo!!! he comes from Java!! he starts with index 0. Kill him!!!  ;)

Ooops... Time to get a new identity :)

On 23 February 2012 19:47, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

...

Sure we know. And we also know that it requires effort and lot of people are talking.

I know there's a loooong way to see what CodeBubbles can do, and that requires to do a big effort, but imagined that some kind of alternative - I'm not sure that CB is **exactly** what I want (sure Java-ers want to see **something more** than just a file pimped with colours, but Smalltalk **allready has** much more than a text file - have real code)  - could be very less effort-consuming. Making the current browser (Nautilus? - newbie here :) ) pop a new ¿window?¿morph? showing a method instead of updating a single pane (the current one showing method's source) don't seems to be so "far" away to me.

Of course that's my point of view, based on what I imagine that could be. I should spend some time to see how it is implemented, and to see if it really is that simple, but anyway trust you if you say is a huge effort...

Well, popping out a new morph every time you clicking around is easy part. The hard part is to make this stuff really consistent and easy to use for navigation and development. It requires far more serious work than just spending 2 hours implementing "bubbling" behavior.

Cheers :)

-- Best regards, Igor Stasenko.

omg.. i like that. what i would add is that depending on workflow, sometime i would like to have standard view for usual navigation, tree view for focusing on some specific class/package and bubble view for focusing on some concrete exemplar (be it method or class or inspector).. that means that i would like to have it all, nicely put together , of course :) On 24 February 2012 20:02, S Krish <krishnamachari.sudhakar@gmail.com> wrote:

I love Pharo's ability to mould/ twist in spare time something that is imminently usable..

Just playing around over an hour plus, I find this tree view grouping more convinient than current browsers in giving a coherent view that easily extends:

All editable code text morphs, spreading over to mutliple worlds one can traverse too if needed. or appears on tab anyways for each group.

a) Package, Class, Category , Hierarchy levels.

b) Senders, implementors ..

c) Arbitrary groups of methods if one desires to..

Can also include some class definition info bubble/ reduce noise through some more optimization to make it optimized

... we can have a little customizations too to get a good grip of the whole as well as the part.

But I agree, Gaucho / Code Bubbles are nice, but I am afraid fo fragmented view it will still represented. May be each will have little twist of his predilictions and cannot be highly generalized.

On 2/24/12, Igor Stasenko <siguctua@gmail.com> wrote:

...

On 24 February 2012 00:18, Matias Garcia Isaia <mgarciaisaia@gmail.com> wrote:

...

On Thu, Feb 23, 2012 at 5:08 PM, Mariano Martinez Peck <marianopeck@gmail.com> wrote:

...

Nooo!!! he comes from Java!! he starts with index 0. Kill him!!!  ;)

Ooops... Time to get a new identity :)

On 23 February 2012 19:47, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

...

Sure we know. And we also know that it requires effort and lot of people are talking.

I know there's a loooong way to see what CodeBubbles can do, and that requires to do a big effort, but imagined that some kind of alternative - I'm not sure that CB is **exactly** what I want (sure Java-ers want to see **something more** than just a file pimped with colours, but Smalltalk **allready has** much more than a text file - have real code)  - could be very less effort-consuming. Making the current browser (Nautilus? - newbie here :) ) pop a new ¿window?¿morph? showing a method instead of updating a single pane (the current one showing method's source) don't seems to be so "far" away to me.

Of course that's my point of view, based on what I imagine that could be. I should spend some time to see how it is implemented, and to see if it really is that simple, but anyway trust you if you say is a huge effort...

Well, popping out a new morph every time you clicking around is easy part. The hard part is to make this stuff really consistent and easy to use for navigation and development. It requires far more serious work than just spending 2 hours implementing "bubbling" behavior.

...

Cheers :)

-- Best regards, Igor Stasenko.

-- Best regards, Igor Stasenko.

A simple runtime example (runs directly in the web browser), the JavaScript code (with a short introduction) and the documentation are all in the three links given in the previous mail. Please note that it is a simple implementation of Morphic. The the code has a neat look and is very readable. --Hannes On 2/25/12, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

can you send the code that we play with it because I would like to learn how you do that.

Stef

On Feb 24, 2012, at 7:02 PM, S Krish wrote:

...

I love Pharo's ability to mould/ twist in spare time something that is imminently usable..

Just playing around over an hour plus, I find this tree view grouping more convinient than current browsers in giving a coherent view that easily extends:

All editable code text morphs, spreading over to mutliple worlds one can traverse too if needed. or appears on tab anyways for each group.

a) Package, Class, Category , Hierarchy levels.

b) Senders, implementors ..

c) Arbitrary groups of methods if one desires to..

Can also include some class definition info bubble/ reduce noise through some more optimization to make it optimized

... we can have a little customizations too to get a good grip of the whole as well as the part.

But I agree, Gaucho / Code Bubbles are nice, but I am afraid fo fragmented view it will still represented. May be each will have little twist of his predilictions and cannot be highly generalized.

On 2/24/12, Igor Stasenko <siguctua@gmail.com> wrote:

...

On 24 February 2012 00:18, Matias Garcia Isaia <mgarciaisaia@gmail.com> wrote:

...

On Thu, Feb 23, 2012 at 5:08 PM, Mariano Martinez Peck <marianopeck@gmail.com> wrote:

...

Nooo!!! he comes from Java!! he starts with index 0. Kill him!!! ;)

Ooops... Time to get a new identity :)

On 23 February 2012 19:47, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

...

Sure we know. And we also know that it requires effort and lot of people are talking.

I know there's a loooong way to see what CodeBubbles can do, and that requires to do a big effort, but imagined that some kind of alternative - I'm not sure that CB is **exactly** what I want (sure Java-ers want to see **something more** than just a file pimped with colours, but Smalltalk **allready has** much more than a text file - have real code) - could be very less effort-consuming. Making the current browser (Nautilus? - newbie here :) ) pop a new ¿window?¿morph? showing a method instead of updating a single pane (the current one showing method's source) don't seems to be so "far" away to me.

Of course that's my point of view, based on what I imagine that could be. I should spend some time to see how it is implemented, and to see if it really is that simple, but anyway trust you if you say is a huge effort...

Well, popping out a new morph every time you clicking around is easy part. The hard part is to make this stuff really consistent and easy to use for navigation and development. It requires far more serious work than just spending 2 hours implementing "bubbling" behavior.

...

Cheers :)

-- Best regards, Igor Stasenko.

<Pharo_CodeBrowser01.JPG>

looks nice. Except from 1-sec GC pauses on FireFox. Our VMs run same things much much smoother :) On 25 February 2012 21:13, H. Hirzel <hannes.hirzel@gmail.com> wrote:

A simple runtime example (runs directly in the web browser), the JavaScript code (with a short introduction) and the documentation are all in the three links given in the previous mail.

Please note that it is a  simple implementation of Morphic. The the code has a neat look and is very readable.

--Hannes

On 2/25/12, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

...

can you send the code that we play with it because I would like to learn how you do that.

Stef

On Feb 24, 2012, at 7:02 PM, S Krish wrote:

...

I love Pharo's ability to mould/ twist in spare time something that is imminently usable..

Just playing around over an hour plus, I find this tree view grouping more convinient than current browsers in giving a coherent view that easily extends:

All editable code text morphs, spreading over to mutliple worlds one can traverse too if needed. or appears on tab anyways for each group.

a) Package, Class, Category , Hierarchy levels.

b) Senders, implementors ..

c) Arbitrary groups of methods if one desires to..

Can also include some class definition info bubble/ reduce noise through some more optimization to make it optimized

... we can have a little customizations too to get a good grip of the whole as well as the part.

But I agree, Gaucho / Code Bubbles are nice, but I am afraid fo fragmented view it will still represented. May be each will have little twist of his predilictions and cannot be highly generalized.

On 2/24/12, Igor Stasenko <siguctua@gmail.com> wrote:

...

On 24 February 2012 00:18, Matias Garcia Isaia <mgarciaisaia@gmail.com> wrote:

...

On Thu, Feb 23, 2012 at 5:08 PM, Mariano Martinez Peck <marianopeck@gmail.com> wrote:

...

Nooo!!! he comes from Java!! he starts with index 0. Kill him!!!  ;)

Ooops... Time to get a new identity :)

On 23 February 2012 19:47, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

...

Sure we know. And we also know that it requires effort and lot of people are talking.

I know there's a loooong way to see what CodeBubbles can do, and that requires to do a big effort, but imagined that some kind of alternative - I'm not sure that CB is **exactly** what I want (sure Java-ers want to see **something more** than just a file pimped with colours, but Smalltalk **allready has** much more than a text file - have real code)  - could be very less effort-consuming. Making the current browser (Nautilus? - newbie here :) ) pop a new ¿window?¿morph? showing a method instead of updating a single pane (the current one showing method's source) don't seems to be so "far" away to me.

Of course that's my point of view, based on what I imagine that could be. I should spend some time to see how it is implemented, and to see if it really is that simple, but anyway trust you if you say is a huge effort...

Well, popping out a new morph every time you clicking around is easy part. The hard part is to make this stuff really consistent and easy to use for navigation and development. It requires far more serious work than just spending 2 hours implementing "bubbling" behavior.

...

Cheers :)

-- Best regards, Igor Stasenko.

<Pharo_CodeBrowser01.JPG>

-- Best regards, Igor Stasenko.

On 25 February 2012 21:48, H. Hirzel <hannes.hirzel@gmail.com> wrote:

BTW, which version of FF?

well, it updates itself quite frequently nowadays.. i just can tell that it is one of most recent ones.

Yes, it is probably slower that a native Morphic plus VM. I just used Opera.

The other side of course is that you do not need to deploy anything. Exciting to have a Morphic experience in a regular web site with a download of a text file of 213kB. The JavaScript engines get faster with each browser version. It might be good enough for many cases.

Jens Mönig writes that he is working with morphic.js on things like this http://chirp.scratchr.org/dl/experimental/JsMorphic/nasciturus.html

So it depends on what to want to use it for.

My main point however --- I think it is exciting to see a cleanly written JavaScript port of Morphic.

No doubt.

--Hannes

-- Best regards, Igor Stasenko.

Hopefully this should be good to play on a Pharo 1.3 image. It does not work, as expected, in Pharo 1.4 image.. as MorphTreeColumn>> rowMorphFor: aNode "the rowMorphGetSelector defaults to nil in Pharo 1.3.. !. but is a block Pharo 1.4.. can hack this to see the same effect.." I have a hacked.. version for Pharo 1.4 .. but let me figure out the wirings of MorphTreeColumn better to share it for 1.4 On Sat, Feb 25, 2012 at 9:59 PM, Stéphane Ducasse <stephane.ducasse@inria.fr

wrote:

can you send the code that we play with it because I would like to learn how you do that.

Stef

On Feb 24, 2012, at 7:02 PM, S Krish wrote:

...

I love Pharo's ability to mould/ twist in spare time something that is imminently usable..

Just playing around over an hour plus, I find this tree view grouping more convinient than current browsers in giving a coherent view that easily extends:

All editable code text morphs, spreading over to mutliple worlds one can traverse too if needed. or appears on tab anyways for each group.

a) Package, Class, Category , Hierarchy levels.

b) Senders, implementors ..

c) Arbitrary groups of methods if one desires to..

Can also include some class definition info bubble/ reduce noise through some more optimization to make it optimized

... we can have a little customizations too to get a good grip of the whole as well as the part.

But I agree, Gaucho / Code Bubbles are nice, but I am afraid fo fragmented view it will still represented. May be each will have little twist of his predilictions and cannot be highly generalized.

On 2/24/12, Igor Stasenko <siguctua@gmail.com> wrote:

...

On 24 February 2012 00:18, Matias Garcia Isaia <mgarciaisaia@gmail.com> wrote:

...

On Thu, Feb 23, 2012 at 5:08 PM, Mariano Martinez Peck <marianopeck@gmail.com> wrote:

...

Nooo!!! he comes from Java!! he starts with index 0. Kill him!!! ;)

Ooops... Time to get a new identity :)

On 23 February 2012 19:47, Stéphane Ducasse <stephane.ducasse@inria.fr

...

...

wrote:

...

Sure we know. And we also know that it requires effort and lot of people are talking.

I know there's a loooong way to see what CodeBubbles can do, and that requires to do a big effort, but imagined that some kind of alternative - I'm not sure that CB is **exactly** what I want (sure Java-ers want to see **something more** than just a file pimped with colours, but Smalltalk **allready has** much more than a text file - have real code) - could be very less effort-consuming. Making the current browser (Nautilus? - newbie here :) ) pop a new ¿window?¿morph? showing a method instead of updating a single pane (the current one showing method's source) don't seems to be so "far" away to me.

Of course that's my point of view, based on what I imagine that could be. I should spend some time to see how it is implemented, and to see if it really is that simple, but anyway trust you if you say is a huge effort...

Well, popping out a new morph every time you clicking around is easy part. The hard part is to make this stuff really consistent and easy to use for navigation and development. It requires far more serious work than just spending 2 hours implementing "bubbling" behavior.

...

Cheers :)

-- Best regards, Igor Stasenko.

<Pharo_CodeBrowser01.JPG>

Will hive this off to a new package.. rather than tacking it to the PackageTreeExample. My primary prototype involved a SimpleMorphicView.. which I hived off.. but on my image this combined with TabbedPane is a great time saver in navigations.. This is particularly helpful in keyboard navigation down/ right key usage flipping through methods.. down the whole tree. Also have a crude / workable find class/ selector too that can open the relevant tree node.. Sketching out some regular use cases I have: like * group methods in a right side multi text tree pane view kind of a two pane view.. * class browser that opens two paned: instance and class side by side.. , implementors/ senders / references in similar views. * drop in the variables/ class definition also in to this tree traversal to make it bit more complete.. * Create / Define class.. with a simple dialog.. akin to VW.. * Hook up minimal refectoring: move/ copy methods .. accessors.. * Normal browseIt continues to work.. as an when required for System/ OB Browser.. or in future the Nautilus.. Inline expand text view/ other extended button actions, will help make it more than adequate. Just good enough for what I see is my personal predilictions.. Of ********************* if we want specific..packages to open: MorphicViewNewPackageBrowser new packageNames: { 'Morphic' } ; open On Sun, Feb 26, 2012 at 10:22 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:

thanks :)

Stef

On Feb 26, 2012, at 5:08 PM, S Krish wrote:

...

Hopefully this should be good to play on a Pharo 1.3 image.

It does not work, as expected, in Pharo 1.4 image.. as

MorphTreeColumn>> rowMorphFor: aNode

"the rowMorphGetSelector defaults to nil in Pharo 1.3.. !. but is a block Pharo 1.4.. can hack this to see the same effect.."

I have a hacked.. version for Pharo 1.4 .. but let me figure out the wirings of MorphTreeColumn better to share it for 1.4

On Sat, Feb 25, 2012 at 9:59 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote: can you send the code that we play with it because I would like to learn how you do that.

Stef

On Feb 24, 2012, at 7:02 PM, S Krish wrote:

...

I love Pharo's ability to mould/ twist in spare time something that is imminently usable..

Just playing around over an hour plus, I find this tree view grouping more convinient than current browsers in giving a coherent view that easily extends:

All editable code text morphs, spreading over to mutliple worlds one can traverse too if needed. or appears on tab anyways for each group.

a) Package, Class, Category , Hierarchy levels.

b) Senders, implementors ..

c) Arbitrary groups of methods if one desires to..

Can also include some class definition info bubble/ reduce noise through some more optimization to make it optimized

... we can have a little customizations too to get a good grip of the whole as well as the part.

But I agree, Gaucho / Code Bubbles are nice, but I am afraid fo fragmented view it will still represented. May be each will have little twist of his predilictions and cannot be highly generalized.

On 2/24/12, Igor Stasenko <siguctua@gmail.com> wrote:

...

On 24 February 2012 00:18, Matias Garcia Isaia < mgarciaisaia@gmail.com> wrote:

...

On Thu, Feb 23, 2012 at 5:08 PM, Mariano Martinez Peck <marianopeck@gmail.com> wrote:

...

Nooo!!! he comes from Java!! he starts with index 0. Kill him!!! ;)

Ooops... Time to get a new identity :)

On 23 February 2012 19:47, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:

...

Sure we know. And we also know that it requires effort and lot of people are talking.

I know there's a loooong way to see what CodeBubbles can do, and that requires to do a big effort, but imagined that some kind of alternative - I'm not sure that CB is **exactly** what I want (sure Java-ers want to see **something more** than just a file pimped with colours, but Smalltalk **allready has** much more than a text file - have real code) - could be very less effort-consuming. Making the current browser (Nautilus? - newbie here :) ) pop a new ¿window?¿morph? showing a method instead of updating a single pane (the current one showing method's source) don't seems to be so "far" away to me.

Of course that's my point of view, based on what I imagine that could be. I should spend some time to see how it is implemented, and to see if it really is that simple, but anyway trust you if you say is a huge effort...

Well, popping out a new morph every time you clicking around is easy part. The hard part is to make this stuff really consistent and easy to use for navigation and development. It requires far more serious work than just spending 2 hours implementing "bubbling" behavior.

...

Cheers :)

-- Best regards, Igor Stasenko.

<Pharo_CodeBrowser01.JPG>

<PackageTree-Browser-Experiment-skrish.5.mcz>

Sure.... I will do that Sudhakar krishnamachari Extn 91-40403012 Cell 9902104814 On Feb 27, 2012, at 3:58 AM, Tudor Girba <tudor@tudorgirba.com> wrote:

Hi,

I tried to load it but it does not work because PharoMorphicObject is missing.

Could you add this code to some repository instead of sending it by mail? With this occasion you would make the license clear as well :)

Cheers, Doru

On 26 Feb 2012, at 17:08, S Krish wrote:

...

Hopefully this should be good to play on a Pharo 1.3 image.

It does not work, as expected, in Pharo 1.4 image.. as

MorphTreeColumn>> rowMorphFor: aNode

"the rowMorphGetSelector defaults to nil in Pharo 1.3.. !. but is a block Pharo 1.4.. can hack this to see the same effect.."

I have a hacked.. version for Pharo 1.4 .. but let me figure out the wirings of MorphTreeColumn better to share it for 1.4

On Sat, Feb 25, 2012 at 9:59 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote: can you send the code that we play with it because I would like to learn how you do that.

Stef

On Feb 24, 2012, at 7:02 PM, S Krish wrote:

...

I love Pharo's ability to mould/ twist in spare time something that is imminently usable..

Just playing around over an hour plus, I find this tree view grouping more convinient than current browsers in giving a coherent view that easily extends:

All editable code text morphs, spreading over to mutliple worlds one can traverse too if needed. or appears on tab anyways for each group.

a) Package, Class, Category , Hierarchy levels.

b) Senders, implementors ..

c) Arbitrary groups of methods if one desires to..

Can also include some class definition info bubble/ reduce noise through some more optimization to make it optimized

... we can have a little customizations too to get a good grip of the whole as well as the part.

But I agree, Gaucho / Code Bubbles are nice, but I am afraid fo fragmented view it will still represented. May be each will have little twist of his predilictions and cannot be highly generalized.

On 2/24/12, Igor Stasenko <siguctua@gmail.com> wrote:

...

On 24 February 2012 00:18, Matias Garcia Isaia <mgarciaisaia@gmail.com> wrote:

...

On Thu, Feb 23, 2012 at 5:08 PM, Mariano Martinez Peck <marianopeck@gmail.com> wrote:

...

Nooo!!! he comes from Java!! he starts with index 0. Kill him!!! ;)

Ooops... Time to get a new identity :)

On 23 February 2012 19:47, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

...

Sure we know. And we also know that it requires effort and lot of people are talking.

I know there's a loooong way to see what CodeBubbles can do, and that requires to do a big effort, but imagined that some kind of alternative - I'm not sure that CB is **exactly** what I want (sure Java-ers want to see **something more** than just a file pimped with colours, but Smalltalk **allready has** much more than a text file - have real code) - could be very less effort-consuming. Making the current browser (Nautilus? - newbie here :) ) pop a new ¿window?¿morph? showing a method instead of updating a single pane (the current one showing method's source) don't seems to be so "far" away to me.

Of course that's my point of view, based on what I imagine that could be. I should spend some time to see how it is implemented, and to see if it really is that simple, but anyway trust you if you say is a huge effort...

Well, popping out a new morph every time you clicking around is easy part. The hard part is to make this stuff really consistent and easy to use for navigation and development. It requires far more serious work than just spending 2 hours implementing "bubbling" behavior.

...

Cheers :)

-- Best regards, Igor Stasenko.

<Pharo_CodeBrowser01.JPG>

<PackageTree-Browser-Experiment-skrish.5.mcz>

-- www.tudorgirba.com

Innovation comes in least expected form. That is, if it is expected, it already happened.

On 22 Feb 2012, at 22:12, Stefan Marr wrote:

Is there actually anyone who would be interested to break with the Smalltalk's traditional approach?

Of course, there is :). Even more than that. As I announced several times before, I would be interested in collaborating and synchronizing the efforts around the IDE. I believe there is a large potential for innovation in this space. Because this is a large topic, the idea was to organize a so called TaskForce to be able to cope with the problem in the large. So, if someone is interested in such a collaboration, please announce your intention. Cheers, Doru -- www.tudorgirba.com "Be rather willing to give than demanding to get."

On Feb 22, 2012, at 10:12 PM, Stefan Marr wrote:

On 22 Feb 2012, at 21:52, Frank Shearar wrote:

...

But I think such a plugin would be missing the point. What I want is to be able to see a lot more source on my screen than one method at a time. Do you remember the Whisker Browser a few years ago? It let you view and edit multiple methods at a time, across multiple classes. That was pretty neat.

You refer to this one? http://www.fit.vutbr.cz/study/courses/OMP/public/software/sqcdrom2/Packages/...

I always like it. Stef

Cool, but I like the feeling of Newspeaks' one still better (random link with screenshots: http://langexplr.blogspot.com/2009/04/writing-small-twitter-client-with.html)

Is there actually anyone who would be interested to break with the Smalltalk's traditional approach?

Göran Krampe wrote

Just a silly note, but I presume you have already investigated: http://map.squeak.org/packagebyname/SVI

Yes. It's pretty cool. -- View this message in context: http://forum.world.st/Misc-newbie-questions-tp4268310p4316303.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

On 15 January 2012 12:23, Gerry Weaver <gerryw@compvia.com> wrote:

Hello All,

I think I have delivered the message that I intended to. Perhaps this thread has run it's course. I appreciate y'all taking the time to respond. The information you provided has been helpful. I have taken another look at the Smalltalk XY project. It pretty much does everything I need. I would be picking up around 12k lines of C code to maintain, but the code looks to be fairly clean and portable. I may start my little project with that. I don't get the impression there is very much interest in the things that I've mentioned here. Anyway, it may turn out to be kind of fun to tweak things in a Smalltalk VM ;-)

I suspect that your interests and mine coincide on 2 out of 3 points - I hope that wasn't lost in the noise. In particular: I am very interested in a REPL interface to a running Smalltalk image (hence my interest in Coral). I don't particularly care about a _GUI_ IDE, but if the Cusp folks can have an Eclipse plugin using swank to talk to an SBCL image, I see no impediment to doing the same for Smalltalk: swank provides a common image-side adapter, and to that you can attach your Eclipse, IntelliJ, emacs... or just a plain old SSH connection. frank

Thanks Again, Gerry

Guys, the best thing what can be done is to sit and write down new GUI/IDE/remote tools/whatever will make your joy with smalltalk greater. Talking endlessly "how better it would be if there be ... " is just waste of time. my 2 cents. -- Best regards, Igor Stasenko.

Am 15.01.2012 um 05:22 schrieb Gerry Weaver:

Hello All,

First, let me apologize for starting the Delphi thing. I only mentioned it as an example IDE layout. I was not trying to say that the internal workings of it were good, bad, or indifferent.

I have spent some time playing around with things in Pharo. I have been trying to imagine how I would use it on a typical project. I have also been asking myself what it is about the current Smalltalk implementations that are keeping them from being more popular. When I consider the language/environment features that are commonly sited as Smalltalk's strengths, I am surprised that there are so few real world applications out there. I know folks are quick to point to a handful of applications, but the numbers pale in comparison to the mainstream languages. I don't share the same opinion on the productivity of the IDE. It limits my productivity.

DISCLAIMER: I am not trying to be critical of Pharo or Smalltalk in general. I am trying to provide some feedback from a Smalltalk newbie that has worked as a professional programmer for many years. I am not trying to push or force my opinion on anyone. I'm just telling it the way I see it. I apologize if anyone is offended by my words. This is certainly not my intention.

The following are some thoughts and observations about Smalltalk.

1. I believe Smalltalk's main strength is the language and it's library.

2. I don't think the image concept works in the current world. I realize there are many folks who would argue this to death, but the fact is that it hinders adoption. I believe it would be better to focus on a robust full featured library and unload the maintenance of the image based environment. I would think of Smalltalk as a Java alternative.

3. I think Smalltalk should probably forget about the desktop gui completely. There are so many good tools to build gui interfaces these days that it would take a huge effort to match even half of the functionality and performance they provide. Smalltalk should focus on rich web interfaces instead. The gui code and tools are stealing valuable resources from development.

4. Developing in Smalltalk should be just like any other high level language. It should have a REPL type interface and it would also be nice to have the capability to compile to a native executable. The various Lisp implementations would be a good example. They too came from a similar environment.

5. It should be possible to embed the Smalltalk VM in other languages (ie; C/C++ etc.) with a nice two-way call interface (think Lua). This would allow servers and GUIs written in other languages to leverage Smalltalk for their application logic.

6. The IDE itself would probably be better written in another language. This would ease platform integration, improve performance, and make for a much richer experience overall. My personal choice for this would be Nokia Qt. There is absolutely no reason that the same browser, workspace, transcript based IDE environment wouldn't be possible. This would also pave the way for IDEs like Eclipse, Netbeans, etc. to provide plugins.

7. An interim solution to the items above would be to create a server based interface to the Smalltalk image. This would allow an external IDE to interact with the image in the same way that the embedded tools do.

I like the Smalltalk language very much. I think it would make for an awesome embedded scripting language. I also think that it is perfectly suited to hosting the back-end business logic of a large application. I think the best approach for the future is to focus on what Smalltalk would be good at, and not waste valuable resources on things that it is not really the right solution for.

My personal plan for Smalltalk/Pharo is to create an external IDE and a socket based interface in the Pharo image to support it. I also intend to create an image manager server that can manage, monitor, and communicate with multiple images. I have already been working on an IDE for Lisp. Adding Smalltalk support seems logical.

Okay.. I've dug my foxhole and I'm in it with my helmet on. Fire away!

Thanks, Gerry

Proposals like yours aren't new. In fact there are also complementary proposals like "give up that strange syntax and introduce curly braces...". Combined that will lead to either C# or Java.

From your ideas I only like the enhancements for Squeak's and Pharo's interfacing to non Smalltalk libraries. All others will only weaken Smalltalk's strengths (even if you don't realize that yet). If you are not only developing web applications or server only applications then you might want to have a look at Dolphin Smalltalk in order to see a decent Smalltalk IDE. The free community edition lacks some of the tools (system browser and idea space) but still you will get an idea of what is possible.

Regards, Andreas

Everything depends on what do you need Smalltalk for. Pharo fits my need perfectly. The image and having the IDE running in the same memory than the application are the most important assets for what I use Smalltalk everyday. It is like saying that a particular place X is the best place to go for holidays... Well... it may depend on whether you prefer trekking or diving. Cheers, Alexandre On 15 Jan 2012, at 01:22, Gerry Weaver wrote:

Hello All,

First, let me apologize for starting the Delphi thing. I only mentioned it as an example IDE layout. I was not trying to say that the internal workings of it were good, bad, or indifferent.

I have spent some time playing around with things in Pharo. I have been trying to imagine how I would use it on a typical project. I have also been asking myself what it is about the current Smalltalk implementations that are keeping them from being more popular. When I consider the language/environment features that are commonly sited as Smalltalk's strengths, I am surprised that there are so few real world applications out there. I know folks are quick to point to a handful of applications, but the numbers pale in comparison to the mainstream languages. I don't share the same opinion on the productivity of the IDE. It limits my productivity.

DISCLAIMER: I am not trying to be critical of Pharo or Smalltalk in general. I am trying to provide some feedback from a Smalltalk newbie that has worked as a professional programmer for many years. I am not trying to push or force my opinion on anyone. I'm just telling it the way I see it. I apologize if anyone is offended by my words. This is certainly not my intention.

The following are some thoughts and observations about Smalltalk.

1. I believe Smalltalk's main strength is the language and it's library.

2. I don't think the image concept works in the current world. I realize there are many folks who would argue this to death, but the fact is that it hinders adoption. I believe it would be better to focus on a robust full featured library and unload the maintenance of the image based environment. I would think of Smalltalk as a Java alternative.

3. I think Smalltalk should probably forget about the desktop gui completely. There are so many good tools to build gui interfaces these days that it would take a huge effort to match even half of the functionality and performance they provide. Smalltalk should focus on rich web interfaces instead. The gui code and tools are stealing valuable resources from development.

4. Developing in Smalltalk should be just like any other high level language. It should have a REPL type interface and it would also be nice to have the capability to compile to a native executable. The various Lisp implementations would be a good example. They too came from a similar environment.

5. It should be possible to embed the Smalltalk VM in other languages (ie; C/C++ etc.) with a nice two-way call interface (think Lua). This would allow servers and GUIs written in other languages to leverage Smalltalk for their application logic.

6. The IDE itself would probably be better written in another language. This would ease platform integration, improve performance, and make for a much richer experience overall. My personal choice for this would be Nokia Qt. There is absolutely no reason that the same browser, workspace, transcript based IDE environment wouldn't be possible. This would also pave the way for IDEs like Eclipse, Netbeans, etc. to provide plugins.

7. An interim solution to the items above would be to create a server based interface to the Smalltalk image. This would allow an external IDE to interact with the image in the same way that the embedded tools do.

I like the Smalltalk language very much. I think it would make for an awesome embedded scripting language. I also think that it is perfectly suited to hosting the back-end business logic of a large application. I think the best approach for the future is to focus on what Smalltalk would be good at, and not waste valuable resources on things that it is not really the right solution for.

My personal plan for Smalltalk/Pharo is to create an external IDE and a socket based interface in the Pharo image to support it. I also intend to create an image manager server that can manage, monitor, and communicate with multiple images. I have already been working on an IDE for Lisp. Adding Smalltalk support seems logical.

Okay.. I've dug my foxhole and I'm in it with my helmet on. Fire away!

Thanks, Gerry

-----Original Message----- From: "Gastón Dall' Oglio" <gaston.dalloglio@gmail.com> To: Pharo-project@lists.gforge.inria.fr Date: 01/14/12 10:06 Subject: Re: [Pharo-project] New IDE alternative (was Misc. newbie questions)

Hello Blake.

I like discuss about Delphi, but I don't say much more here becouse this is a Smalltalk list :)

2012/1/13 blake < dsblakewatson@gmail.com> Gaston,

This method is for manage the event, not for do something that is really part of the model. A Form, no is part of the model. This is similar in VW: you coded your event handler method in the AplicationModel, that is like a Form in Delphi.

Delphi was a direct reaction to VB, which was eating Borland Pasal's lunch. MVC was nowhere to be seen. It was all about "look how easy it is to do [whatever]." Never "look how easy it is to re-use" or "look how easy it is to maintain". I'm not a Basic basher, but the atmosphere surrounding it has always been "Computer science is =haaaaarrd=. I just wanna program!"

In general, the user of Delphi do not know how to make good programming with it, becouse Delphi granted them make the things quickly and bad. There are a VERY good book named "The dark side of Delphi...", and the DARK word is for the general unknown about it. Here is (in Spanish sorry): http://www.marteens.com/pdfs/TheDarkSideOfDelphi6.pdf

You CAN do it right. But here I am (right now!) looking at a guy who's encoded multi-hundred-line event handlers, that are massive if-then chains, with code duplicated like crazy between the events.

hehe, Maybe a sometime when I'm very hurry... but too in Delphi I can use polimorphic, strategy, double dispatch, etc, for avoid use of if-then. And no massive code, just necesary code for handle event, just in VisualWorks :)

Really, the "beauty" of the VB model is that you didn't HAVE to learn OO. (And, hey, reality bears out that code quality and profit are not strongly correlated.)

No. The IDE automaticaly define a global variable and create code for create and assign a instance, but if you want more instances of same Form you can easy declare local variables and create new instance (on initialize of other instance or on the fly in accesor methods) and asign to. Same in Smalltalk.... And you can delete this automaticaly created code.

Sure. You can do a lot of things right. The underlying weakness is in the static typing and poorly defined messaging. (I haven't tried FireMonkey yet, though, it may be different.)

Sure! I completely agree with you. You are deal with reserved words like "virtual, override, dinamic" for achieve dinamic message dispatch across static variable typing. This is very inconveniente for clean code (and has bad psychological consequences in the developers hehe). I do not try the Embarcadero version (and I do not), but them improved some things. For example added use de "Class Helper" for do some similar a trait to a class (but in a context). No only Smalltalk evolves :). FYI see:: http://edn.embarcadero.com/article/34324

mmm no. Again, a Form is not part of model, idealy this is for write event methods handlers.

I'm glad you're following the ideal. I started using Delphi on the beta in 1994, and in the past 18 years, I've seen about two instances of the ideal being properly followed in the real world (that I didn't write).

hehe, again, "the DARK side..." never is very popular.

In the Buttons you can use Actions for delegate the handler method of the click event. In general, you can assign method of a Form to events of controls in another Form, but I do not do often that becouse I only write a small code in the event handler in the Form for delegate to some model the work (DataModules).

Point is: Buttons then become inflexible pass-throughs. In Smalltalk what you'd do is allow a component to be swapped for any other component if it had the right handlers.

In Delphi I can change the component too if they has the right handlers with out major work, but I agree with you in that this in not possibly do it easily that in Smalltalk. But, the class of the variable that hold the current component should be ancestor of both interchangeables components, very inconvenient!

If you could lay out forms in Smalltalk and press a button to create a lean, deployable version, I'd only use Delphi for CPU intensive tasks. What'd be optimal is a Smalltalk (with some VA/Delphi influences) in a browser with an overall approach like that of OPA or maybe Morfik (not Morphic) so that front and back-end stuff was seamless. Smalltalk was born for that.

:)

Regards. Gastón.

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

On Sat, Jan 14, 2012 at 8:22 PM, Gerry Weaver <gerryw@compvia.com> wrote:

First, let me apologize for starting the Delphi thing. I only mentioned it as an example IDE layout. I was not trying to say that the internal workings of it were good, bad, or indifferent.

I think there's a lot to be learned there but, of course, I would.

...

1. I believe Smalltalk's main strength is the language and it's library.

Language, yes. Library? Seems unlikely. The core libraries are cool but overall the efforts of more popular languages positively dwarf ST's.

...

I don't think the image concept works in the current world. I realize there are many folks who would argue this to death, but the fact is that it hinders adoption. I believe it would be better to focus on a robust full featured library and unload the maintenance of the image based environment. I would think of Smalltalk as a Java alternative.

Java was alternative to Smalltalk. The image concept works, it's just too murky.

...

3. I think Smalltalk should probably forget about the desktop gui completely. There are so many good tools to build gui interfaces these days that it would take a huge effort to match even half of the functionality and performance they provide. Smalltalk should focus on rich web interfaces instead. The gui code and tools are stealing valuable resources from development.

Open Source: People do what they want to do. Even if you stopped people from doing GUIs, they wouldn't necessarily shift to doing what you want.

...

4. Developing in Smalltalk should be just like any other high level language.

Then why have it? Just for the syntax?

...

It should have a REPL type interface

Workspace/Transcript? ===Blake===

Hi Stefan,

Because I fear that you are talking about what I used to know as Borland Delphi.(http://www.blichmann.de/en/programming/delphi/themeddelphi/luna.png) Not that it is bad, but like Visual Studio and Eclipse, the main concepts are IMO as dated as what you got in Pharo.

Actually, it's now Embarcadero Delphi, but yes that's what I'm talking about. I'm not talking about the visual aspect of the environment. What I'm talking about is the dockable windows and the tight integration of the different IDE components. For example, you double click a button and your placed in a code stub for the click event in the editor. You don't have to go hunting for things. For example, one thing I don't like about VisualWorks is the gui framework. It's gets in the way with imposed MVC. If a developer wants to use MVC then they can code that way, but I don't think it is the IDE's or framework's job to force it. It just needs to be a simple event based model. Actually, when it comes to gui toolkits Nokia Qt is the best. MVC is an option, but not forced. You could use QtCreator as a substitute for Delphi above. The idea is still the same. I guess some examples of what I'm wishing for would be: 1. A code editor that will allow editing a complete class in one go (with code folding etc.) 2. The concept of projects and subprojects. All project classes are readily accessible without drilling and searching. 3. A code aware gui designer. 4. The ability to switch between gui design and code within a tabbed editor. 5. The ability to have all project classes open in editor tabs/panes at once. 6. A tree based system browser with separate tabs for system and project classes. ...

If you are just looking for a UI designer, have you seen this? https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki/...

Yes. I have seen this. It would definitely be nice to integrate it with the ideas above. Thanks, Gerry

My 5 cents: I would like to have even wider capabilities to setup several dev. environments for different projects. For example, I see that as a browser that shows me a list of "environments" in the first panel (hiding those I don't need at the moment), and for each of them it allows me to add packages, individual classes, methods, tests, scripts, tasks (ToDo-s), inspectors, etc — in general any tool/window/morph (parametrized, if needed)… maybe some smart objects (like searches, scripts). GUI development tools could be added as special kind of tools here. Extending the approach a bit further, I'd like this not to be just a single-window browser, but an endless field where I can place my "environments" and their components, link some of them together (i.e. organize them visually and semantically). Some navigation tools would be needed, of course. And BTW, Code Bubbles [ http://www.cs.brown.edu/~spr/codebubbles/demovideo.mov] is somewhat close to what I want. 2012/1/12 Stefan Marr <smalltalk@stefan-marr.de>

Hi:

On 12 Jan 2012, at 12:56, Gerry Weaver wrote:

...

I guess some examples of what I'm wishing for would be: 1. A code editor that will allow editing a complete class in one go (with code folding etc.)

That is also the one and most important point for me. I always miss my context. Smalltalk's browser style where you need a new window for every semantic entity just does the opposite. It hides away context/invariants and does not allow my to benefit from my spacial+visual memory that helps to related to code normally.

Best regards Stefan

-- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

-- Dennis Schetinin

On Sat, Jan 7, 2012 at 10:28 PM, Frank Shearar <frank.shearar@gmail.com> wrote:

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

Did you commit your code somewhere ? 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/

On 18 January 2012 11:07, Frank Shearar <frank.shearar@gmail.com> wrote:

On 18 January 2012 10:29, Serge Stinckwich <serge.stinckwich@gmail.com> wrote:

...

On Sat, Jan 7, 2012 at 10:28 PM, Frank Shearar <frank.shearar@gmail.com> wrote:

...

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

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

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/

On Sat, Jan 7, 2012 at 6:32 AM, Philippe Marschall <kustos@gmx.net> wrote:

On 06.01.2012 06:41, Gerry Weaver wrote:

...

Hello All,

Firstly, let me say that I am enjoying Pharo very much at this point. I wish I would have found the time to look at this a long time ago.

I have a few misc. newbie questions.

1. VisualWorks - I am doing a lot of thinking about projects that I could use Smalltalk on. I have a consulting project coming up that might be a good candidate, but I'm sure I would be required to use a commercial Smalltalk version for it. I guess it may be odd to ask about VisualWorks on this list, but I'm not really looking for a comparison to Pharo. What I'm interested in is your opinion of the product. I would like to know if any of you would consider using it on a project. I would appreciate anything y'all could share in the form of experiences good or bad. I am trying to get my hands on it, but Cincom's mail server (windoze) is having issues. I am also having some trouble getting pricing out of them. Anyway, I would like to get your take on the Cincom products.

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.

3. I've seen some discussion about images and image sizes. What is the current state of this. Is it possible to strip an image down to just the required components for an application (ie; no world menu, etc.). I would like to be able to run an image that would bring my gui application up filling the image window such that it looks a close as possible to a conventional gui application.

4. I have been reading about something called "Opentalk". It is a way for images to be able to comminucate with each other over the network. I've also seen something callesd "rST" that appears to do a similar thing. In addition, I notice that someone has done some FFI bindings for zeromq. What would y'all recommend as the best option to achieve something like this in Pharo?

5. I'm trying to figure out exactly what the Pharo gui toolkit provides in the way of widgets. Is there a widget gallery type thing somewhere that shows all of them? I know I can play with them in the image, but it would be nice to see a list of what is there with a brief description.

6. I know Pharo doesn't currently support OS threads in an image, but I'm wondering about the FFI. Is it possible to call a foreign function in a separate OS thread or asynchronously in Pharo?

My understanding is with the very latest mt Cog VMs that FFI call-outs happen in a native OS thread. I'm not sure whether the required infrastructure is already in Pharo.

That's the idea in the MT (multi-threaded) VMs. But its not the case in the standard VM. This makes all FFI calls from the VM thread, blocking the VM until the call returns or calls-back. N.B. the MT VMs are not yet production ready.

Cheers Philippe

-- best, Eliot