How do you handle the poor performance of LC 7?

[Richard Gaskin]

Andrew Kluthe wrote:

 > I think the decision boiled down to just wanting more mainstream
 > processes for development and being able to find programmers we
 > didn't have to train from scratch. So the decision was made to become
 > a .Net shop...

Ah yes, that's a conversation I know well.  Some of the members of this 
list may be old enough to remember the mantra of middle management, "No 
one ever got fired for buying IBM".  I have that conversation about 
every few months, with prospective clients and even current clients 
after acquisition or during review.

That's why the Tiobe Index is such a long-tailed L curve: the most 
popular languages are picked up by new users looking for the most 
popular languages.  Heck, Pascal is still in the top 20 there right now, 
while the darling of Big Data, Erlang, is way down at #36 with only 
0.403% of surveyed developers using it (though I'd wager there's at 
least twice as much demand for Erlang, and in arguably more interesting 
companies).

Malcolm Gladwell's "The Tipping Point" explores thisultural dynamic 
well, and Geoff Moore's "The Gorilla Game" applies it to the software 
industry cogently.

The irony of the middle manager fixation on number of available 
developers is that it doesn't really matter if there are a million Java 
programmers, because they're never going to hire a million programmers.

All they really need to see is that the number of developers available 
is higher than the number they want to hire, often just one or two, or 
maybe if they're really invested in a language as many as a dozen.  And 
there are least a dozen developers well versed in Erlang, and in 
LiveCode. :)

That's why middle managers aren't founders:  You don't build a company 
from scratch by doing whatever everyone else is already doing.


The need for good support of third-party version control systems is a 
more practical problem, one that's historically never been addressed by 
any toolkit in this family of languages.

The ability to deliver a single compact binary file that contains both 
objects and code contributes strongly to LiveCode's uncommon 
productivity, but this uncommon way of working doesn't yet fit well in a 
world of VCSes designed for a world of sameness in which apps written in 
most languages are comprised of hundreds of tiny text files.

We're only halfway there now, but a big half: a library stack can be 
expressed as a text file, suitable for use in any VCS, and in 
well-factored projects that's where the meat will be.

That still leaves UI stacks as binaries, and the LiveCode team is 
working on a solution for that.  And I believe Trevor and others are 
already using Monte's solution for that right now.

Once that's built-in, a lot of larger teams will be able to come on board.


In the meantime, LiveCode is just like the other bottom 90 in the Tiobe 
Index:  there will always be those managers who will only consider the 
top 10, which is why the top 10 rarely change position.

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