Us and them? [was Re: Livecode Dictionary]

[Richard Gaskin]

Curry Kenworthy wrote:

 > Richard:
 >  > Curry Kenworthy wrote:
 >  >> What people need most in the Script Editor is to view and edit the
 >  >> code itself smoothly, without jitters or delays
 >
 >  > Not hard to make one.  A frontScript trapping the editScript
 >  > message lets you do whatever you want.
 >
 > It's interesting when we take a comment out of context and spin it in
 > another direction by treating it as a different request or problem! :)

Not my intention to take it out of context, but to broaden the context. 
My suggestion of considering a custom SE isn't reductio ad absurdum. 
It's far worse:  I'm actually serious.

Here's where I'm coming from:


Maybe it's just because I was one of the last MC users, but Dr. Raney's 
DIY encouragement never left me: "Let a thousand flowers bloom" he would 
say of anyone with time and interest to fork and replace IDE components.

I kept using the MC IDE about a decade after Revolution first premiered. 
  Eventually I got tired of making my own GUIs for the new engine 
features, so I started using LC IDE - but the script editor was too slow.

So I forked MC's, added line numbers (years before the LC IDE had line 
numbers - we were all such savages back then <g>), and made it into a 
plugin.  Ken Ray also helped with some of the fork, and we used it for 
another five years or so even after we switched from MC to LC so we 
could use the other tools.

After the big Waddingham SE Overhaul things got a lot better, and the 
balance of features vs performance became more favorable for me, esp. in 
light of the work required to properly maintain a fork. So now I use 
LC's SE.

There's a couple points with this:

1. People can and do make their own script editors.

Why not?  It's text in a field.  If we can't make a good text editor in 
LC why are we even here?  But after delivering a good many custom work 
processors I came to believe -- and still do -- that LC can make an 
excellent text editor.

Basic features aren't hard.  It's modestly rewarding, and you learn a 
lot about making text editors.

What I found, though, was:


2. It ain't the field slowing us down.

As far as I can tell, the LC field object is pretty responsive to input.

And MC is faster than LC.  Given the same engine, the difference is in 
the scripts.

So the good news is that fixing serious slowdowns require the one skill 
everyone on this list has:  LiveCode scripting.

I've spent enough time going through the LC SE code to know that I don't 
enjoy it.  No offense to the team; it just has layers of legacy stuff 
and over time it's accumulated a bit of cruft, made more complex by the 
demands of the audience for new features.  I understand how it got that 
way, and I appreciate it's ambitions.  I just don't enjoy working on it; 
it's a beast.

So if anyone were relying on me to fix the SE performance issue (and 
there are many reasons we're all glad no one is relying on me for that), 
I'd be inclined to write a new one from scratch instead.

It may be possible to design and build something with all the current 
engine strengths and weaknesses in mind that could become more 
satisfying than continually patching a complex legacy stack.

However...

...there's a reason the team patches rather than replaces.  Replacing is 
expensive.  Done well would take tremendous time.  Sure, a field with a 
"Save" button takes only an hour, and a slightly more usable feature set 
takes a day; but a productive set takes weeks; greatness would take months.

And even then, ultimately we may find ourselves left with the question:

     Is it possible to deliver the feature set current SE users demand
     without adding a performance hit?


I'm one of the lucky ones, because once I turned off the SE features 
that seemed likely to slow me down, I no longer have a slow SE. 
Accordingly, I'm happily making stuff for clients, and am not very 
motivated anymore to work on a script editor.

But if this were bothering me, I'd either dive into the existing SE and 
fix it, or write my own.

Life's too short not to have what we want.



 > The wiki sounds like a neat project. Simplicity helps, and whether to
 > locate it in the SE is a consideration. Besides performance, another
 > issue is that the original proposal here was adding user comments back
 > to the Dictionary.

Personally, I prefer dedicated tools.  The MC SE slowed down a lot when 
it was combined with the debugger.  When I forked it I returned to a 
editor separate from a debugger, each purpose-built for the task they do 
(extra bonus points that a sufficiently discrete debugger can also be 
used in a standalone).

Combining lots of functionality into one window contributes to 
complexity, which often finds expression in performance, and can slow 
maintenance work while increasing cognitive load for user and developer 
alike.

For that reason, I'd prefer a wiki be in a layout optimized for reading, 
leaving the script editor optimized for writing.

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com