Ironically, almost every newbie smalltalk programmer I know LIKES the
IDE and thinks it is better than anything out there.
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.
L.
On 1/14/12 9:22 PM, 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" <[email protected]>
To: [email protected]
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 < [email protected]
<mailto:[email protected]>>
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.
