Re: Your mission...Wrap Emacs?
edre...@yahoo.com
This is intended as reply to Robin Dunn's excellent post: "Your
mission, should you choose to accept it. The essence of Robin's
'mission impossible' is:
"So here is your challenge and your mission impossible, should you
choose to accept it: Create a code editor that will pry emacs and its
25-year-old nearly dead technology out from under my fingers."
As a thought experiment, I would like to ask, suppose we waved a magic
wand and produced a complete (whatever that means) Python (swig?)
wrapper for Emacs: the *real* Emacs. Would that be what Robin wants?
If not, why not?
In particular, what is the "25-year-old nearly dead technology" to
which Robin refers. Is it elisp? Is it the c implementation?
Something else?
In other words, suppose we could access all of Emacs *itself* from
Python. Would that be sufficient?
Here is where I am coming from. I spent over a year putting an emacs
minibuffer in Leo. This was time well spent, and not just because it
gave Leo new features. The biggest win was being able to think in
terms of Emacs-like commands. I have lost track of the times that
being able design at the level of do-this, do-that, do-another-thing
has clarified my thinking.
So I am a huge fan of Emacs's design. Furthermore, Emacs is a
*platform*, similar to Java, wxWidgets, tkinter, etc. But this
platform is optimized for editing! It's hugely popular, it's very
fast, and just about everything that anyone has ever wanted exists as
an Emacs mode.
So maybe the idea of giving Emacs a set of python wrappers is more
than just a thought experiment? It would be a new playground for me:
I could add Leo stuff to Emacs and stop trying to do what Emacs
already does so well. But don't these remarks apply more or less to
every developer on pyxides?
What do you think, Amigos?
Edward
Ali Afshar
Hi Edward,
Well we have gone some of the way in wrapping real Emacs in a python
wrapper in PIDA, http://pida.co.uk/
screenshot: http://pida.co.uk/files/screenshots/pida_0-5-1_16.png
I am not sure this is exactly what you mean, but it is certainly a
viable approach to achieving some of the things you are hinting about.
Ali
edre...@yahoo.com
"PIDA is different from other IDEs in that it will use the tools that
are already available rather than attempting to reinvent each one."
It was exactly this kind of thought lead me to the thought experiment
of wrapping Emacs. Here is another quote from the pida handbook:
"PIDA is essentially a bunch of services bound together by a Boss. The
services are discovered from service directories and loaded by a
Service Manager for the Boss."
One of my recent ideas (omitted from the original post in the interest
of brevity) was that perhaps a new way of wrapping code is needed.
Perhaps pida is showing the way.
Is it possible, from pida, to access individual Emacs c or elisp
functions? It's not clear whether being able to execute any elisp
command would suffice.
Edward
edre...@yahoo.com
> wand and produced a complete (whatever that means) Python (swig?)
> wrapper for Emacs: the *real* Emacs.
standard python library. Something like:
import emacs
editor = emacs.editor()
editor.run()
All details hazy. Presumably, there would be ways to augment or
override the emacs startup code. And we would probably want the
following:
editor.executeElispFunction(name-of-elisp-function)
and
editor.executePythonScript(aPythonScript)
BTW, pymacs allows something like this. It's not clear to me whether
anything 'better' than pymacs is even conceivable.
Edward
Ali Afshar
Yes, we actually send elisp across the wire for Emacs to execute. In
addition to commands, we found it necessary to be able to respond
asynchronously to Emacs events (e.g. when a new buffer has been opened).
There is a small amount of information here about the hows and whys:
http://pida.co.uk/trac/wiki/EmacsSupport
And you can browse the emacs integration code (which I would guess is
fairly PIDA-independent) at
http://pida.co.uk/trac/browser/trunk/pida/utils/emacs/emacscom.py
Ali
Nicolas Chauvat
>
> > I am not sure [pida] is exactly what you mean, but it is certainly a
> > viable approach to achieving some of the things you are hinting about.
>
> Very interesting. I just glanced at the pida handbook and found this:
>
> "PIDA is different from other IDEs in that it will use the tools that
> are already available rather than attempting to reinvent each one."
http://www.logilab.org/project/oobrother
has been our attempt at this. It drives a shell, emacs, vi, pylint and
a gtk-based app that includes a class browser, menus with actions,
generated forms, etc.
Code browsable at
http://www.logilab.org/hg/oobrother
--
Nicolas Chauvat
logilab.fr - services en informatique scientifique et gestion de connaissances
Ali Gholami Rudi
Pymacs is really a nice tool. But it has not been maintained in the
last few years. Since ropemacs (rope plugin for emacs) depends on it
and I needed to fix some of its problems I've started a mercurial repo
to make my fixes on it:
* repo: http://rope.sf.net/hg/rpymacs
* snapshot: http://rope.sf.net/hg/rpymacs/tip.tar.gz
I'll be happy if someone maintains pymacs once more (if no one
volunteers, I'll be happy to).
Regards,
-- Ali
Christopher Barker
edre...@yahoo.com wrote:
> This is intended as reply to Robin Dunn's excellent post:
I loved that post -- it's almost as if he scanned my brain when writing it.
However, in a little of the discussion I've since seen, I think the
problem is that a lot of folks want some pieces of what Emacs gives
them, but we all want different pieces.
> As a thought experiment, I would like to ask, suppose we waved a magic
> wand and produced a complete (whatever that means) Python (swig?)
> wrapper for Emacs: the *real* Emacs. Would that be what Robin wants?
> If not, why not?
hmm -- rather than answer that questions (not for Robin, but for me),
I'll tell you what I want, and you can decide if wrapping emacs is the
way to get it.
> In particular, what is the "25-year-old nearly dead technology" to
> which Robin refers. Is it elisp? Is it the c implementation?
Well, I won't comment in what is or isn't dead technology, but I know I
want to be able to script my editor in python, not lisp, so that needs
to be possible (and convenient, and clean). Can you write a python
wrapper for elisp that will feel like python?
> Something else?
For me, aside from scriptability in Python, the other think I want that
is different from emacs is a UI that conforms to modern GUI conventions
-- I spend much of my day in my code editor, but the rest of it in other
apps that all use the same keystrokes for the basic stuff like copy,
cut, paste, etc -- I want my editor to be the same as that. I also want
to be able to get at things I use less frequently with menus, toolbars,
etc. Somehow it just feels wrong to use Emacs on a Macintosh, so I never
have.
Emacs does support custom key bindings, so there is no real reason one
couldn't do a full re-map to a different paradigm, but I think you'd
break a lot of extensions in the process, and the extensions are the
real reason I use emacs. (actually Xemacs, but the point is the same).
> In other words, suppose we could access all of Emacs *itself* from
> Python. Would that be sufficient?
Maybe -- if there was total access -- but is this really easier than
building something on STC and other existing python modules?
> The biggest win was being able to think in
> terms of Emacs-like commands. I have lost track of the times that
> being able design at the level of do-this, do-that, do-another-thing
> has clarified my thinking.
A agree with this, and I think that's one of the key things I want in an
editor -- frankly, I wish all software was built with a scripting
interface first, and GUI second (or at least a full scripting interface
at some point!). It kind of reminds me of the KDE application
configuration philosophy (I don't know if they still stick to this):
- All configuration will be held in user-readable text files
- All configuration will have a GUI to manipulate it.
You really need BOTH of these. I this case it's:
- All functionality will have a scripting interface
- All functionality will have a GUI accessor (though I could relax
that to "most", or even "much")
Anyway, Robin's post list a bunch of must-have features, most of which I
agree with. However, with a good scripting interface, we can get most
specific features by writing a script, so I'll give a short list:
- Good scripting interface (in python, natch) -- what this means is
that every action one might do to text is some kind of function or method.
- Completely customizable key bindings (and a default set that matches
modern GUI standards)
- multiple views of the same buffer, and multiple top-level windows.
- A concept of "Modes" to support different languages, etc.
- soft-wrapping of text (this is the ONE thing that Emacs doesn't do
well!)
Sound like emacs? yup , expect for the modern UI and python scripting,
so maybe wrapping emacs is the way to get there. However, Peppy, and a
few other python editors are getting really close, so I don't know that
adding the big dependency and the complexity of wrappers really is the
best way to go.
that's my thoughts....
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
edre...@yahoo.com
> addition to commands, we found it necessary to be able to respond
> asynchronously to Emacs events (e.g. when a new buffer has been opened).
I feel much the same now as when someone told me about pyrex. At the
time I had some vague ideas about translating python-looking code into
c. Imagine my joy when I saw that pyrex had solved problems I never
new existed. Suddenly I had a new tool that already was *much* better
than I would have produced on my own.
pida may be the 'master tool' that allows developers to concentrate on
what they do best. For Leo, that means outline stuff, and nothing
else. In particular, Leo supports (but not too well) almost all the
features on Robin's mission impossible list, but *none* of those items
is what Leo does better than any other editor/ide.
My dream is that for every possible editor feature there would be one
or two developers who 'own' that feature, and who 'provide' that
feature to the rest of us. The owners of a feature are those who have
solved problems that the rest of us don't know exist. At present, I
feel like a jack of all trades, and a master of one. I really would
like to use other people's design and code.
Enough for now. I've got to give pida much more study before I say
more.
Edward
edre...@yahoo.com
> However, in a little of the discussion I've since seen, I think the
> problem is that a lot of folks want some pieces of what Emacs gives
> them, but we all want different pieces.
use. Maybe pida has found a way to package those beans?
> I want to be able to script my editor in python, not lisp, so that needs
> to be possible (and convenient, and clean). Can you write a python
> wrapper for elisp that will feel like python?
Iirc, pymacs does a pretty good job of handing conversion of
arguments. Ali's offer to support pymacs is most welcome in this
context.
> the other thing I want that
> -- I spend much of my day in my code editor, but the rest of it in other
> apps that all use the same keystrokes for the basic stuff like copy,
> cut, paste, etc -- I want my editor to be the same as that. I also want
> to be able to get at things I use less frequently with menus, toolbars,
> etc. Somehow it just feels wrong to use Emacs on a Macintosh, so I never
> have.
>
> Emacs does support custom key bindings, so there is no real reason one
> couldn't do a full re-map to a different paradigm, but I think you'd
> break a lot of extensions in the process, and the extensions are the
> real reason I use emacs. (actually Xemacs, but the point is the same).
viper (vim) plugin break all other Emacs extensions? That's hard to
believe.
> > In other words, suppose we could access all of Emacs *itself* from
> > Python. Would that be sufficient?
>
> Maybe -- if there was total access -- but is this really easier than
> building something on STC and other existing python modules?
requires more than a year of work, regardless of what tools one starts
with. In particular, Emacs has hundreds of commands to support all
the items on Robin's list. True, most commands are fairly easy to do,
but the job remains daunting. Furthermore, implementing the
minibuffer itself takes a lot of work. And what did I get when I
finished this year of work? Lots of commands that are kinda like
Emacs, but which were less tested and (in many cases) less well
thought out.
Edward
edre...@yahoo.com
> what they do best. For Leo, that means outline stuff, and nothing
> else.
A python wrapper for Emacs would allow Leo to use outlines to specify
Emacs settings. In other words, Leo would use the wrappers to change
(or augment) how the user specifies settings in Emacs. Similarly, I
would like a way to augment IPython's excellent scripting capabilities
with Leo's outline-oriented scripting features.
In both cases, I do *not* want to duplicate code, either in Emacs or
IPython. Neither to I want to change code in Emacs or IPython. In
essence, I want to use the existing code, and hook into the existing
code to augment it. It's similar to overriding a class.
The point is that features like outlines have global consequences.
They are not just a hunk of code that can be plunked into a code base:
they affect many other aspects of an app. As another example,
IPython's key handling (a readline extension) should presumably affect
key handling in many places in an app.
In other words, mixing and matching features from different apps is an
"interesting" problem. In order to play with mixing and matching, we
must be able to use existing code. Wrapping apps in python could
allow this. (IPython doesn't need wrappers because it is written in
Python). If we have to reimplement features in order to play with
them very little 'playing' will actually happen: it's just too much
work.
Edward
Nicolas Chauvat
> In other words, mixing and matching features from different apps is an
> "interesting" problem. In order to play with mixing and matching, we
> must be able to use existing code.
http://www.logilab.org/project/logilab-aspects ?
But after trying aspects and coping with their complexity, I am not
so sure they are a good idea in Python, for the language is very
flexible and dynamic already.
Oliver
Interesting discussion. A few ideas that have been recurring in my
search for (and, unlikely, creation of) holy grail of IDE, and have
been mentioned in this and other pyxides threads:
1. Functionality before GUI: the GUI should come second to the
application's functionality. Build the objects that provide
functionality, then create a nice GUI atop it. This has the
advantage that: A. different GUI can be built (or GUI can evolve
more than if the GUI influenced the encapsulation of
functionality); B. regression testing can be maximized to
maintain robustness throughout evolution; C. scripting the
application will be available almost "out of the box", allowing
for macros;
2. Modularized functionality: define the "services" that should be
available in IDE, THEN define an interface for each service, THEN
build components that satisfy those interfaces, THEN build the
glue that binds the services into an application. Implementations
of services can then easily be swapped in an out. E.g. a service
might be "provide documentation for a function": there are many
ways to do this, e.g. load the file and parse it yourself, or
import the file and get the __doc__, etc, each method has pros
and
cons and different users may prefer different ones. Each service
is like an input-process-output black box that the application
calls upon at the right time (e.g., when the user enters "("
after
some letters).
3. Modularized GUI: the GUI should be broken down into independent
pieces that communicate via pubsub-type messaging. This allows
for
more configurability, disabling unused/unwanted portions of GUI
to
keep things simple, etc. E.g. a "show function documentation for
a
function" GUI component would take the output of the "provide
documentation for a function" service (received e.g. via a
message) and show it in a pop-up box. Someone else could decide
to
create a different implementation of this GUI component which,
instead of a pop-up box, is a separate panel, and the user could
swap the default for this one.
4. Configurable menu/toolbar: the problem with many IDE's that
provide extension points is that the UI does not define where the
plugin's UI should go. E.g. I have seen editors/IDE where all
plugin menu items go in one "tools" menu. This rapidly becomes
unusable: plugins don't know about each other so they use names
that are sometimes similar and you end up not knowing what menu
item corresponds to which plugin, or the ordering of menu items
is
awkward/non-existent. When adding a plugin (which would provide
one or more services according to pre-defined interface), the
user
should be able to change the default menu items (name and
location
in menu hierarchy) that will be added for that plugin.
The major benefit of above is that it would allow progressive
implementation, and allow all contributors to provide something "their
way". It's really a pitty that so many IDE's exist isn't it: some are
very good, but they each miss something that the others provide or
have different bugs that are annoying, mostly because any given
developer has a finite amount of time to implement so much
functionality. So the goal must be to provide an architecture that
allows developers to combine efforts.
I'll see if I can go over the interface of a few IDE/editors and give
concrete examples of the above, that should show whether any of it
makes sense in practice :)
Oliver
edre...@yahoo.com wrote:
>
>> However, in a little of the discussion I've since seen, I think the
>> problem is that a lot of folks want some pieces of what Emacs gives
>> them, but we all want different pieces.
>>
>
> use. Maybe pida has found a way to package those beans?
>
> > This is intended as reply to Robin Dunn's excellent post:
>
> I loved that post -- it's almost as if he scanned my brain when writing it.
>
> However, in a little of the discussion I've since seen, I think the
> problem is that a lot of folks want some pieces of what Emacs gives
> them, but we all want different pieces.
>
Rob McMullen
> 4. Configurable menu/toolbar: the problem with many IDE's that
> provide extension points is that the UI does not define where the
> plugin's UI should go. E.g. I have seen editors/IDE where all
> plugin menu items go in one "tools" menu.
Amen, brother. In addition, some IDEs populate the menubar/toolbar
with every possible item and just disable the inapplicable items.
This is much more cluttered than simply leaving out the items that
don't apply to the sort of text file you're editing. Emacs does a
good job by dynamically modifying the menu depending on the major mode
and is what I tried to duplicate.
This was not as easy is I had hoped -- I even tried a constraint
solver to allow plugins to define what menu items they came before or
after. I don't have a great solution to this currently, as the items
insert themselves at some location in one of the menus at a default
position, with the idea that there will be a menu location editor at
some point where the user can reposition everything at will.
> So the goal must be to provide an architecture that
> allows developers to combine efforts.
Indeed, that's the problem. But it's a big one. A flexible
architecture is extremely difficult to write, which is why everyone
(myself included) seems to start out writing a flexible architecture
but ends up constraining themselves and and making choices that limit
the flexibility in order to get something working.
> I'll see if I can go over the interface of a few IDE/editors and give
> concrete examples of the above, that should show whether any of it
> makes sense in practice :)
Every discussion seems to mention Eclipse at some point, although it's
obviously in Java and if all of us here wanted to do that we wouldn't
be here. But I can't help but think that it's something of that
magnitude that we really want. I know how complicated these things
get -- I thought peppy would have a stable architecture long ago, but
the more flexible an architecture you develop, the more it explodes
with interactions among components.
Maybe a pure message passing scheme would result in less coupling, but
I've found message passing systems to be debugging nightmares.
Granted, most of my message passing experience is multiprocessing with
MPI, but it scars you. :)
At any rate, I'd love to see examples and documentation of other
architectures and how they've worked in practice. I'd love to point
to peppy's documentation for comparison purposes, but through all
fault of my own it has lagged far behind the development.
Rob
Ali Afshar
PyGTK has the ability to modify menus and toolbars on the fly. It merges
snippets of XML from various sources (in this case plugins), and can
unmerge them.
The user interface builder Gazpacho has a facility to edit this XML from
a UI.
Ali Afshar
Well I have no doubt you could build something easily as good as PIDA,
it has a long way to go. But it would make me very happy if the general
Pyxides direction was towards something PIDA-like, because then I would
use it.
The main problem I have with PIDA fitting into the Pyxides movement is
that its PyGTK, and almost everything else seems wxPython orientated. I
hope that whatever happens will eventually be GUI agnostic.
Ali
Josiah Carlson
> Maybe a pure message passing scheme would result in less coupling, but
> I've found message passing systems to be debugging nightmares.
> Granted, most of my message passing experience is multiprocessing with
> MPI, but it scars you. :)
You mean like wx.lib.pubsub? I mention it because I've found it to be
quite convenient for plugging things together without needing to know
about widget hierarchy, object relationships, etc. I haven't altered
my editor to use it fully (right now, I'm using the standard wxPython
event system, manually reordered handling, etc.), but newer tools I'm
writing for other projects use it.
- Josiah
Oliver
On Jan 3, 2:43 pm, "Josiah Carlson" <josiah.carl...@gmail.com> wrote:
into its own project: pypubsub, at http://cheeseshop.python.org/pypi/PyPubSub
on cheeseshop. Robin has not yet integrated the new version into wx).
As Rob mentioned, messaging can increase the difficulty of debugging
but I find that the level of effort required depends a lot on the
library. E.g. with proper logging and some automated sanity checks by
library, errors are more easily traced (the new pubsub will be quite
powerful that way).
I'm looking at enabling pubsub to support layered architectures. E.g.
if bottom layer of an application (furthest away from user) emits
messages of type A, then next layer up can (but doesn't have to) make
these subtopics of itself, e.g. B.A. In this case anything listening
for topic B messages will get the B.A messages too (though it would be
up to each layer to "publish" topics). This capability still needs
proper specification.
Oliver
Rob McMullen
> Yes like pypubsub (note: I moved pubsub module out of wx.lib last year
> into its own project: pypubsub, at http://cheeseshop.python.org/pypi/PyPubSub
> on cheeseshop. Robin has not yet integrated the new version into wx).
Thanks for the pointer to the new version of pubsub; I wasn't aware of
this new version.
> As Rob mentioned, messaging can increase the difficulty of debugging
> but I find that the level of effort required depends a lot on the
> library.
One of the things I would have helped me in my previous dealings with
wx.lib.pubsub would have been the ability to set a breakpoint when a
certain message was sent. I looked through your v3 code a bit --
maybe with some slight modifications the __notifyOnSend could be used
for that purpose? Probably OT for pyxides; I'll post something on
your forum when I've had a better look at pubsub v3.
Rob
Christopher Barker
>> Can you write a python
>> wrapper for elisp that will feel like python?
>
> Something like callElispFunctionByName(name-of-elisp-function) ?
well, no. It's a start, but it really means that you have to now and
work with elisp to work with the editor component. I was thinking more
along the lines of how you wrap C++ or ObjC, so that:
(name-of-elisp-function, parameter1, parameter2)
becomes:
name-of-elisp-function(parameter1, parameter2)
(if I remember lisp syntax at all!
A simple example like that looks easy, but I suspect it'll get a lot
harder when you try to do something real.
> Really? I don't know enough about Emacs to say for sure, but does the
> viper (vim) plugin break all other Emacs extensions? That's hard to
> believe.
I don't know, I've never used it. What I'm referring to is that the
extensions have their own key bindings, and so you may have to re-bind
all those too. Though I think the convention is Ctrl-C before the
extension commands, so, though you'd want Ctrl-C for "copy", you may be
able to just re-bind that. I have no idea how viper works.
>> Maybe -- if there was total access -- but is this really easier than
>> building something on STC and other existing python modules?
>
> My experience is that trying to duplicate Emacs's functionality
> requires more than a year of work, regardless of what tools one starts
> with. In particular, Emacs has hundreds of commands to support all
> the items on Robin's list. True, most commands are fairly easy to do,
> but the job remains daunting.
Quite true. However, there is always the trade-off between getting
something functional fast, and getting it right. Unless the code you're
wrapping was really designed to be a library or component (and maybe
emacs was), then you'll always be fighting it (or your users will),
because it will never fit in.
> Furthermore, implementing the minibuffer itself takes a lot of work.
Only because your framework didn't support that idea from the beginning
-- I'm guessing you didn't start with a many-to-many relationship
between buffers and views. But even if I'm right, it doesn't change your
point -- emacs has a lot that's done right, and is incredibly
feature-full, well tested, and debugged. It's a LOT of work to get
anywhere near that stage.
If you can embed emacs in a python IDE and make it not feel like emacs
-- I'll be glad to use it!
edream
> > Something like callElispFunctionByName(name-of-elisp-function) ?
>
> well, no. It's a start, but it really means that you have to now and
> work with elisp to work with the editor component. I was thinking more
> along the lines of how you wrap C++ or ObjC, so that:
>
> (name-of-elisp-function, parameter1, parameter2)
>
> becomes:
>
> name-of-elisp-function(parameter1, parameter2)
pymacs shows that issues relating to types of arguments can be
resolved satisfactorily.
Let's step back a bit. In some sense, what I 'really' would like is
Emacs written in Python :-) That's never going to happen, because
Emacs is written in elisp and Emacs developers and users like what
they have. But supposing we use pymacs, or something like it, we can
get what you propose: programming Emacs with Python. That may be
quite useful: we can 'pretend' that Emacs is, in fact, written in
Python.
Let's step back a bit farther. The reason I originally proposed
creating Python wrappers for Emacs was so that python code would
control Emacs, not the other way around. Indeed, the following
appears at: http://webpages.charter.net/edreamleo/emacs.html
"A clarification is needed about two-way communication between Python
and lisp scripts: in truth, Python scripts can call the Pymacs.lisp
function only if the Python script was invoked from emacs. Otherwise,
calling Pymacs.lisp will hang the process making the call."
In short, wrapping Emacs means the following to me (at present):
1. I want to be able to invoke & control Emacs from a python 'master'
script, not the other way around.
2. I want to execute Emacs elisp functions using Python conventions,
as Chris suggests.
Edward
edream
> so sure they are a good idea in Python, for the language is very
> flexible and dynamic already.
same terminology (weave and tangle) as Knuth's so-called literate
programming (LP) system. I doubt that this is a coincidence. As you
may know, Leo got its start as an LP tool, but the more I use Python,
the less I use LP.
My first impression is that aspect oriented programming (AOP) is
pretty 'heroic'. It's ambitious, but not necessarily in a good way.
But this is only my first impression.
In any event, we can hardly require that every tool that we want to
use uses AOP. That's why I am interested in wrapping already existing
products like Emacs or Texmacs or IPython. BTW, the IPython folk are
doing in a refactoring/repackaging of IPython called IPython1, so the
notion of creating a python wrapper for a python program isn't an
oxymoron.
Let me throw out another idea here. The reverse of an 'heroic'
solution would be a 'simplistic' approach. Sometimes simple
guidelines can be surprisingly useful. I am thinking in particular of
the best programming advice ever given to me: namely to make class
methods or functions be as small as possible. At first, this sounds
like simplistic (simple minded) advice, but my experience is that it
is not. Following this advice has produced all kinds of unexpected
and far-reaching happy consequences. For example, small functions are
easy to write unit tests for, they are easy to combine in novel ways,
and they are easy to understand and document. BTW, this advice came
to me from Bernhard Mulder, one of Leo's most influential developers
and users. The goal of all simplification programs is to arrive
eventually at what I call a 'big collapse' of complexity. This has
happened many times in Leo's development, and my intuition is that it
could happen here.
So I continue to wonder whether relatively simple principles, cleverly
applied, might have significant consequences. As far as overall
design goes, I have yet to encounter a better overall framework for
design than the model-view-controller design pattern. It cuts across
the questions of gui-first or whatever. All three kinds of classes
are important in their own ways.
In short, I think code reuse is possible, but it will take innovative
thinking applied to the simplest possible building blocks.
Edward
P.S. I have been vague on purpose in this discussion because nothing
is (or should be) clear in the early parts of creative exploration.
Imo, the essential quality needed for creative thinking is the ability
to tolerate ambiguity, confusion and uncertainly for extended periods
of time. The confusion is itself a reliable indicator that good
things are happening. The last thing I want to do at times like this
is to remove the confusion too soon. The subconscious thrives on
ambiguity. Let's enjoy it.
EKR
edream
> 1. Functionality before GUI: the GUI should come second to the
> application's functionality.
can support multiple gui's. At present, a wxWidgets gui plugin is
under active development.
> 2. Modularized functionality: define the "services" that should be
> available in IDE, THEN define an interface for each service, THEN
> build components that satisfy those interfaces, THEN build the
> glue that binds the services into an application.
pida encourages this way.
> 3. Modularized GUI: the GUI should be broken down into independent
> pieces that communicate via pubsub-type messaging.
abstract text widget that then gets implemented by a gui-specific
classes. Base classes handle common code, subclasses fill in
details. This has worked surprisingly well in Leo, and I see no
reason it could not work in other contexts. In particular, Leo can
(or easily could) handle all the situations that you enumerate.
OTOH, perhaps a message-oriented approach might simplify the code
further. I want to keep an open mind about this.
Edward
Don Dwiggins
> Let me throw out another idea here. The reverse of an 'heroic'
> solution would be a 'simplistic' approach. Sometimes simple
> guidelines can be surprisingly useful. I am thinking in particular of
> the best programming advice ever given to me: namely to make class
> methods or functions be as small as possible. At first, this sounds
> like simplistic (simple minded) advice, but my experience is that it
> is not.
Practically all of them had the effect of limiting the size of classes
and methods. (His general principle was "lots of little pieces".)
--
Don Dwiggins
Advanced Publishing Technology