[Pharo-project] New IDE alternative (was Misc. newbie questions)

Frank Shearar frank.shearar at gmail.com
Sun Jan 15 03:53:54 EST 2012


On 15 January 2012 04:22, Gerry Weaver <gerryw at 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 at gmail.com>
> To: Pharo-project at 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 at 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.




More information about the Pharo-dev mailing list