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

[R. Matthew Emerson]

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

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.

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.