[Openmcl-devel] prompt-for-file (embarrassing question)

[Craig Lanning]

See below.

On Thu, 2017-03-30 at 11:09 -0700, R. Matthew Emerson wrote:
> > 
> > On Mar 30, 2017, at 10:41 AM, Dimitri Simos <dim at lissys.demon.co.uk
> > > wrote:
> > 
> > Thanks Rainer,
> > 
> > I very much appreciate your thoughts, and your taking the time to
> > read all of my disgraceful rant.
> > 
> > I guess I was just blowing off a decade's steam. For me personally,
> > and for Piano, there is in fact no real issue at all. The software
> > is stable and all development that needs to be done in future can
> > be handled in LW with the assistance of this wonderful Lisp
> > community's extraordinary Wizards.
> > 
> > My broader concern is for the next generation. After all this time,
> > they really deserved to be able to get their hands on something at
> > least as magical as the diskette that landed on my lap in the late
> > '80s and changed my life. Then again, this generation will also
> > fail to see a moon landing as I did, or to see a Europe united as I
> > did, or to aspire to US values, or to enjoy reading dusty books
> > under bedcovers instead of existing in a Whatsappiverse. We're
> > really not being awfully nice to our kids. There, that felt good.
> > I'll now shut up, crawl into a dark corner and be quietly old and
> > fester.
> > 
> > Thanks again,
> > Dimitri
> 
> 
> No, no, your rant is right on.
> 
> I'll share some thoughts on an IDE.  Note that this is my own private
> opinion.  As I'm not even currently employed by Clozure Associates,
> I'm certainly not speaking for them.
> 
> I am convinced that the current IDE code in ccl:cocoa-ide; is not the
> right thing to build on.  It needs to be replaced entirely.  Here are
> a couple of reasons why I think that.
> 
> An editor is the most important component of a good IDE.  The editor
> has to be programmable from lisp.  Lisp has to be able to handle all
> key events, mouse events, whatever.  The current IDE does not do
> this, and its design more-or-less precludes it.  It goes to a lot of
> fuss (and uses a lot of wasteful hacks) in order to be able to use an
> NSTextView to handle text drawing/selection/input, but this makes it
> virtually impossible to customize any of that from Lisp.  I don't
> know if you are familiar with it, but I find the design of the Deuce
> editor from Dylan to be appealing (https://discuss.atom.io/t/the-deuc
> e-editor-architecture/2218).
> 
> More fundamentally, the IDE uses Cocoa directly. Even though the
> current Objective-C interface is clever, and tries to make foreign
> Objective-C objects look like CLOS objects, we still end up
> essentially writing Objective-C code in Lisp.  This causes us to have
> to face the same memory management problems (and attendant crashes)
> that the C programmer does.  Additionally, Cocoa is huge, and it's
> not really feasible to expect users to be able extend the IDE by
> writing additional Cocoa code.  In my opinion (informed in part my
> experience working on Opusmodus) some kind of safe Lisp interface for
> UI programming is essential. (Some kind of interface to the
> Objective-C runtime will still be needed, but I think that it's
> better to treat Objective-C objects as opaque foreign things rather
> than try to integrate them into CLOS.)
> 
> So, if the IDE needs to be rebuilt, this opens up the question of
> whether Cocoa is the right user interface technology to build on.  I
> think it is.  Despite its failings, the Macintosh is still the only
> reasonable platform for a really nice IDE.  There are certainly times
> when think I'd like to tell Apple to take a hike, but I simply do not
> see any better alternative.
> 
> There's Windows, of course.  One nice thing there is that it's not
> necessary to do all GUI operations on the initial thread. But I fear
> that Windows is probably a bridge too far:  I'm not sure I'm willing
> to become sufficiently familiar with how Windows does things, and I
> don't know if my heart would ever be in it.  What's more, the Windows
> port of CCL is probably the weakest of all the ports, so there would
> be work to do on that, too, as if the UI stuff was not already
> enough.
> 
> I'm not inclined to try to make the IDE run in any other CL
> implementation besides CCL.  This is mostly because I know the guts
> of CCL, and I feel that it's likely that an IDE will need support at
> the lisp implementation internals level.
> 
> On the other hand, there is a case to be made that the IDE should
> support controlling a tethered slave (or remote) lisp.  This way,
> horrible bugs in the code you are developing will not bring down your
> editor.  Slime has shown that this sort of two-part architecture is
> workable and useful.  It would be nice to take advantage of a great
> IDE to attach to and work/debug in a lisp: that might be on a big
> remote server or in a little ARM box on your desk.  Of course, you'd
> still want to be able to support in-image development too:  that way,
> you could work in the traditional MCL-like style where you build up
> the IDE until it becomes your application.
> 
> I think native is the only way to go for user
> interfaces.  Applications written using  cross-platform toolkits like
> Qt, for example, never quite look or feel right.  If a new IDE can be
> written in such a way that dependences on CCL and Cocoa are all kept
> in one place, I think that's a good idea.  But I wouldn't want to
> make compromises or cause undue pain in the name of supporting some
> future cross-platform implementation that may or may not ever come to
> pass.

Have you looked at CLIM (Common Lisp Interface Manager).

It was designed to be a cross platform GUI system for Common Lisp and
is intended to make use of whatever toolkit is on the local system.

You build your GUI using the high level CLIM presentation mechanisms
and it gets rendered to the appropriate native toolkit of the platform
it is running on through an appropriate backend.

On a Symbolics the CLIM app would use a Dynamic Windows backend.
On a Mac, it would use a Cocoa backend.
On Linux, it would use either a Gnome/GTK or KDE/QT backend.
On Windows, it would use Win32 or Win64 depending on whether it was 32-
bit or 64-bit Windows.

On some other platform, it would use whatever toolkit was available
there.

> It is not clear to me how I would ever get paid for making an
> IDE.  Digitool made a run at it with MCL, and they did not
> survive.  Perhaps business decisions or other non-technical reasons
> may have contributed to its demise (I simply don't know), but I fear
> that the market for paid developer tools is just incredibly small
> (and if it was small in the MCL day, it's surely even less likely
> today that people will pay for development tools).  However,
> https://www.jetbrains.com seems to be making a go of it, but their
> market includes hordes of Java programmers.  LispWorks, too, is
> somehow able to charge $3000/copy for a 64-bit Lisp, and are still in
> business, so they must be doing something right.  Their IDE, though,
> doesn't exactly look elegant. Their commitment to their cross-
> platform CAPI interface probably hurts them a bit there.
> 
> I want the IDE to be simple enough that I don't feel like I'm
> drowning in buttons or obscure hidden keyboard commands.  Above all,
> I want the IDE to help me be able to feel like I am the master of my
> computer, to feel like the computer is my willing servant.  MCL made
> me feel like that.  THINK Pascal made me feel like that.  I'm sure I
> must be looking back on the past through rose-colored glasses, but I
> would like to recapture that great, even magic feeling that whatever
> I can imagine, I can create.

For me that feeling was when I was using Lisp on a Symbolics with
Dynamic Windows.

> Too often today, it seems like the computer is some vengeful god that
> must be propitiated by appropriate amounts of pain and suffering
> before it will do what you want.  We can do better.
> 
> I still think CL and a good user interface are unbeatable for
> exploring things and solving difficult problems.  I think that I'm
> perhaps uniquely prepared to make a good Cocoa IDE for CCL, given my
> experience with both, but maybe I am deluding myself.

I agree that CL is an excellent way to explore and I think that CLIM is
the right mechanism to use for the User Interface.  A lot of the
presentation oriented concepts in Dynamic Windows made their way into
CLIM.  I think that CLIM with a Lisp Listener interface would make some
of the exploring a lot easier.  The Symbolics Lisp Listener was great
because anything that was printed on the window became clickable so you
could click on it a describe it or throw it into the windowed
inspector.  Exploring doesn't get any better than that.

My CLIM porting effort started with porting the basic CLIM code and the
CLX backend.  This provides a very basic look and feel that will run on
any system that has an X11 server.  I have it compiled, but something
in the CLX backend is not right.  When I try to build my application in
CCL with this CLIM it has trouble with the command completion getting
incorrect characters.  I have not had time to properly debug this.

I would like to use the CCL FFI mechanism to build a GTK3/GNOME3
backend for Linux since most GNOME based desktops are moving to GNOME3.

I'd be happy trying the GTK2/GNOME2 stuff that is already in CCL, but I
don't know how to load it and use it and have not had time to look more
intently at the documentation to see what it says about doing that.

Craig