Open Source Kickstarter Report Card

[Richard Gaskin]

Ali Lloyd wrote:
> I doubt we will be writing a whole new script editor from scratch in one
> go.

Wise, for all the reasons Joel talks about here (good link, Scott):
<http://www.joelonsoftware.com/articles/fog0000000069.html>


> More likely we will replace individual elements with widgets (as has
> been done with the variables pane) to make sure all the components work as
> expected.

LiveCode 8's Builder language will be an exciting addition to the 
platform, at long last allowing the dev team to enjoy the same benefit 
the rest of us choose LiveCode for: not having to work in C++, able to 
use a high-level scripting language for much greater productivity.

With the IDE things are even better:  it's already written in a 
high-level scripting language.  Why not use LiveCode Script?

If we can't build a good text editor in LiveCode, what are any of us 
doing here?

Fortunately we can.  Indeed LiveCode is an excellent tool to build such 
things with, as it is right now.

LiveCode Builder is a great alternative to C++, but there's no true need 
to replace LiveCode Script elements with new LiveCode Builder 
implementations.

Doing so merely overloads the already-laden v8 dev cycle, and worse it 
prevents backporting solutions to the product that is currently the 
company's sole source of revenue, v7.  Conversely, everything written 
for v7 goes along for the ride seamlessly to v8, the clearly winning 
option for things already in script.

The ROI of writing things in LC Builder that might otherwise have 
required C++ is unquestionable.  And similarly unquestionable is the 
benefit of using the current scripting language for things already 
written in the current scripting language.

Somewhere down the road there might be a reason to rewrite those, but 
right now the downsides seem so clearly outweighing the upsides on every 
level, from technical to revenue to marketing (do we really intend to 
convey the message that LiveCode can't be used to build a text editor?), 
it would seem optimal to just dive in an optimize what we have.

This thread began with a sober realization of the difficulty of 
estimation vs. actual delivery times.  I'm a programmer too, so I 
appreciate the seductive attraction of greenfield projects; no one like 
working in other people's code.  But most programming is exactly that, 
and as Joel points out it's extremely rare that a working system can 
benefit from a complete rewrite, when all that's needed are some 
optimizations and a very small number of new and rather discrete features.

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