Kickstarter 2013 Revisited

[Richmond]

On 10/05/15 20:21, Mark Waddingham wrote:
>> I have taken quite some time to write this, and the reason that I have
>> taken the trouble is that, oddly enough, I both believe in Runtime
>> Revolution, and have put a very significant amount of time and effort
>> into learning how to get the thing to do things over the last 14
>> years.
>>
>> Had I come to it just before the Open Source Kickstarter campaign I
>> don't think I would have bothered, and I don't think I would be
>> working
>> with LiveCode just now.
>
> I appreciate the time you have taken - and, indeed, I appreciate your 
> ongoing support (which you clearly still give unconditionally it 
> seems, even though you are perhaps not entirely enamoured with the way 
> we go about things!).

I am lucky insofar as I don't depend on LiveCode for my bread and 
cheese, and as such I feel I can give support even if that is seen in
a somewhat negative light from time to time.

As someone remarked just the other day, I am prepared to state what 
others may be reluctant to. I am well aware that has made me seem
a complete baboon from time to time, and doesn't exactly make me the 
most popular chap on the block. But as I have always been a bit of
a baboon and fairly unpopular, at 53 I can live with that without any 
undue qualms.

If by writing what I do I can effect some changes then all "that" is 
well worth it.

Even if nothing else, the fact that you have taken a lot of trouble to 
construct a careful and well thought-out reply to my post justifies
both my post and your recent increased involvement in the use-list and 
so forth.

>
> Indeed, the fact you have taken this time suggests that we (from the 
> technical point of view) have failed to a certain degree to 
> communicate adequately what we are doing and the path we are taking to 
> achieve it.
>
> I'm not going to go into specific details or responses to your direct 
> questions just now as that would take longer than I perhaps have on an 
> idle Sunday evening whilst my other half is working - but there is 
> obviously a communication issue here we need to address and we will in 
> time.
>
> In the meantime, however, please believe me when I say that no 
> KickStarter goals have been forgotten - they are just taking longer to 
> achieve than we had originally hoped. Indeed, in the process of 
> attempting to achieve them we did decide to go down a slightly 
> different route than we had originally intended.
>
> The reality is that the scope of what LiveCode is, and indeed we want 
> it to be, is so wide that the current rift between engine and script 
> cannot continue if we are to keep up with the pace of evolution of the 
> software industry. We have an engine written in what I would term 
> C++ish (the codebase goes back 25 years or so at this point), and we 
> have an IDE written in what we term LiveCode Script (LCS). C++ is not 
> a forgiving task-master and in reality if you are using LiveCode you 
> are probably doing so to avoid using C++ or other lower-level 
> languages to a certain degree.

Ouch! Indeed that is the truth. I am currently in a dialogue with 
members of the teaching community here in Plovdiv, Bulgaria who have to 
teach
teenagers PASCAL (at non-Mathematical High Schools) and C++ (at 
specialist Mathematical High Schools) effectively turning off vast numbers
of children who might, under different circumstances, become brilliant 
and innovative programmers.

They (the teachers) are, in turn, "kicking" against the Ministry of 
Education who are, it seems, stuck in about 1985.

>
> Therefore, as a result, we are in a situation where the people who 
> perhaps would be best to help evolve the platform find it difficult to 
> do so having to rely on those who have C++ abilities (and, indeed, 
> understand how the engine works!). This disconnect directly reflects 
> the more fundamental problem which LiveCode is intended to solve - 
> 'Everyone Can Code' is an ambitious goal, certainly, but the way by 
> which it works is having a high-level system which is tailored towards 
> individual domains (black-boxes tied together with a flexible language 
> for composing and expressing algorithms that act on them).
>
> The solution we came up with is widgets. We are trying to raise the 
> level at which the majority of what you currently consider to be 'the 
> engine' is written so that there isn't that rather large chasm between 
> the way the the functionality you use everyday is written and the 
> functionality you build atop it. By raising the level of language in 
> which 'the engine' is written, we both gain rapidity of development 
> for ourselves, but also (perhaps more importantly) raise the ability 
> of the LiveCode community as a whole to introspect on and also adapt 
> and improve what we do.

That is only going to happen if members of the LiveCode community see 
obvious, direct and instant benefits to themselves.
Right now there are people who are having problems with LiveCode that go 
back to versions released years ago, which have not been addressed
when mentioned, and give the impression (whether true or not) that 
RunRev only listen selectively to their community.
>
> Of course, I say 'try' here - but there is no try. It works, it really 
> does work. Even in its nascent form LCB is proving to be a highly 
> useful and productive way to implement the things people really need 
> and it can only get better as we iterate on its feature-set and its 
> gradual unification with LiveCode Script.

All that is all very well, and appreciated. But, even before we get to 
LCB, there is the question of the Kickstarter goals and a general feeling
of malaise with relations between RunRev and their core user-base which 
has to be addressed and sorted out.

Most people who use LiveCode are like most kids who use LEGO: they don't 
want to build a robot that makes coffee, trims your nails and
gives you a massage; all they want to do is build a sports car or a 
model of the Millennium Falcon. And until end-users can build the equivalent
of sports cars there is not much point in talking-up the ability to 
construct the robot.

Richmond.