January 2012 - Pharo-dev - lists.pharo.org

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

by Andreas Wacknitz

Am 15.01.2012 um 11:16 schrieb Gerry Weaver: > 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 > Gerry, 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. Regards, Andreas

Jan. 15, 2012

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

by Andreas Wacknitz

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

Jan. 15, 2012

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

by Gerry Weaver

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

Jan. 15, 2012

Re: [Pharo-project] SmallLint

by Lukas Renggli

>>> One could also think on how to efficiently visualize the results of smallLint ... >> >> See for example the SmallLint results of Seaside 3.0 run by Jenkins: >> http://jenkins.lukas-renggli.ch/job/Seaside%203.0/791/checkstyleResult/. > > How simon can help concretely? Make it possible so that code critics can run on-the-fly in the code editors (pretty standard in any IDE today). I had that in Helvetia, but that code depends on the whole Helvetia stack depends on the old editor. Lukas -- Lukas Renggli www.lukas-renggli.ch

Jan. 15, 2012

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

by Frank Shearar

On 15 January 2012 09:40, Gerry Weaver <gerryw(a)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 > > > >

Jan. 15, 2012

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

by Gerry Weaver

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

Jan. 15, 2012

Re: [Pharo-project] What is the difference between ActionSequence and WeakActionSequence

by StÃ©phane Ducasse

Ah yeas now I remember this is event raising when:to:do:â¦ Yet another thing unused but not totally and probably a bit shaky. Some points for the future: - I do not understand why this is not packaged with EventManager - We want to remove DependentFields from Object like in CUIS and we will probably use, fix and reduce the API of actionSequence. just 27 methods in Object. - Now this is strange that ActionSequence got removed. - I do not understand why this is called ActionSequence, the name does not tell much. May be this is the equivalent of DependencyTransformer in VW. It looks also quite similar to announcement. So once we have ephemerons may be we should move to announcement this behavior - The related question is do we want any object to be able to register to event. I have serious doubt about that and we could: - have a trait - define a subclass of Object

Jan. 15, 2012

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

by Frank Shearar

On 15 January 2012 09:08, Stefan Marr <smalltalk(a)stefan-marr.de> wrote: > Hi: > > On 15 Jan 2012, at 09:53, Frank Shearar wrote: > >> On 15 January 2012 04:22, Gerry Weaver <gerryw(a)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 > >

Jan. 15, 2012

Re: [Pharo-project] [Pharo-users] OCompletion configuration for 1.4

by StÃ©phane Ducasse

Thanks thanks thanks and â¦ thanks Stef On Jan 13, 2012, at 10:53 PM, Mariano Martinez Peck wrote: > Thanks Guille. It works perfect. I have just commited a small fix in Ocompletion-MarianoMartinezPeck.114 ;) > > cheers > > On Fri, Jan 13, 2012 at 10:34 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 13 January 2012 17:24, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > Thanks a lot!!!! > > > yeah, i just checked and it works out of the box. good job! > > > Stef > > > > On Jan 13, 2012, at 3:53 PM, Guillermo Polito wrote: > > > >> I've written a new version of OCompletion for 1.4 with several fixes and compatibility additions for Pharo 1.4 > >> > >> Gofer it > >> squeaksource: 'MetacelloRepository'; > >> package: 'ConfigurationOfOCompletion'; > >> load. > >> > >> ConfigurationOfOCompletion loadStable > >> > >> If someone wants to try it :). > >> > >> Guille > > > > > > > > -- > Best regards, > Igor Stasenko. > > > > > -- > Mariano > http://marianopeck.wordpress.com >

Jan. 15, 2012

Re: [Pharo-project] Preparing 1.4 beta

by StÃ©phane Ducasse

On Jan 13, 2012, at 11:14 PM, Henrik Johansen wrote: > > On Jan 13, 2012, at 9:44 30PM, StÃ©phane Ducasse wrote: > >> >>> (but have a backwards-compatible external package) >> >> I think that it will be difficult enough to swap the two events notification systems >> and that we will not make a backward compatible package. I think that for migrating the few users will just have to >> register to the new one. Now give me 10 full time engineers and we do it. >> At the end of the day, we should do some reality checks and put resources on the right items. >> >> Stef > > I'm talking of existing external users of the SystemChangeNotifier, like (assumption on my part) OCompletion, OB, Coral and others. > Implementing a backwards-compatible protocol as one of the steps shouldn't be too hard, is probably needed to keep the system running while swapping out the existing one anyways, and will ease migration of the external packages by keeping them loadable with the backwards-compat package in in image. > > To avoid another rant of getting legs kicked out from under one as part of an upgrade, and provide a generally pleasant upgrade experience for everyone, I think it is crucial. I know now this is a question of energy/time. > If I can make it in May, I'll work on it. Thanks > > Cheers, > Henry

Jan. 15, 2012