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):
��
��
��
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::
��
��
��
��
��
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.