[OT] SWIFT

[Richard Gaskin]

Terence Heaford wrote:
 >
 > On 15 Jul 2014, at 19:10, Richard Gaskin wrote:
 >
 >> As a long time friend of ListMaster's author and having been
 >> the original publisher of ListMaster for several years, I know
 >> very well what a joy it is to work with.
 >>
 >> That is, if your audience is exclusively Mac.
 >
 >
 > Is LiveCode’s market purely cross platform?

"Purely"?  Given the broad range of people and companies who use 
LiveCode I'd hesitate to suggest any single usage pattern applies to all 
of them.

But I do think that among commercial developers (read, "Those purchasing 
the proprietary licenses that keep the joint running so the rest of us 
can enjoy the FOSS edition"), one of the key attractions to LiveCode is 
the uncommonly high number of platforms it supports.

Even among users of the Community Edition, I think those building for 
just one platform is a very small percentage.

After all, when reaching other 90% of the world is just a checkbox away, 
why not?


 > Clearly ListMaster is Mac only but this should not preclude
 > LiveCode’s authors from trying to achieve an acceptable level
 > of performance from their controls.

As ListMaster's author can tell you, it's not a trivial task to write 
something like that.  Multiply that by the number of platforms LiveCode 
supports, and multiply that again by the much wider range of layouts the 
DG supports, and the cost is pretty darn high.

In fact, the cost is so high that no one, not even the maker of 
ListMaster, has attempted to make any external for any xTalk that does 
what the DG does.

So it's not as though the folks at RunRev are just sitting on the beach 
drinking Mai Tais thinking, "Man, our customers must be pretty dumb, we 
can ship a DataGrid with slower-than-C scrolling and they'll eat it up. 
  Waiter!  Another round!"

On the contrary, the team has been hard at work on the core of the 
problem, the very core of the LiveCode engine itself - this is the video 
I alluded to earlier:

<http://livecode.com/blog/2014/07/08/the-next-generation-widgets-themes/>


 > Clearly DG has limited performance as it is built in the scripting
 > environment,
 >
 > For those wishing to use a DG as a scrolling table it is, again this
 > is my opinion, inadequate for the task.

Sure, we'd all like it to be faster.  Heck, I want everything faster. 
Ever try to write an image convolver in an xTalk?  I want more speed, 
for everything I do.

But I also want to ship software.  So I could write my app three times 
in C, once for Mac, and again for Windows, and again for Linux, and it 
would run pretty fast - but would cost more to write than I could make 
from it, so that puts a damper on that option.  Negative ROI is a 
serious buzzkill for a business. ;)

Fortunately, with LiveCode we have a middle path:  I can write most of 
it in script, and in areas where best-of-breed performance is critical I 
can write externals - I get most of the savings of avoiding C for most 
of the app, but can still get the speed where it's needed.

Personally, while I wouldn't rate the DG's scrolling speed as 
tremendous, for the apps I've used it in it's good enough.  Sometimes to 
keep the books balanced "good enough" is good enough.  I haven't had any 
customers storming my castle with pitchforks and torches demanding 
better scrolling speed - but I do have a list of requests for new 
features and capabilities unrelated to list scrolling speed, so that's 
where I devote my attention.

I figure if I'm delivering an app where the scrolling is the key driver 
of subjective satisfaction, my problem isn't the scrolling speed at all, 
but rather how I designed things such that the data the user is looking 
for is so frequently beneath the fold, hidden from view.

A few years back I attended a session at a SIGCHI conference on a 
comprehensive eye-tracking study of how people find things in lists. 
Huge cognitive load, the sort of thing we take for granted until you see 
a heat map of all the ways eyeballs bounce around on screen trying to 
discern a specific set of glyphs in a uniform columnar presentation.

Sure, I get clients who love to have everything in one list, like 
they'll get some sort of merit badge for being able to turn to their 
partners and say, "Look!  We can display half a million records in one 
view!"  But it does no good for the user to do that, and the user pays 
the bills.

So instead I try to ask myself, can I provide simpler, more fluid 
filtering so the user has the data they're looking for right in front of 
them? Would another representation for the data, like Miller columns, be 
a better fit?  If we're looking at aggregate data, could we try 
something more visual like a chart?  What other options might help the 
user avoid having to hunt for data at all?

Scrolling is indeed basic and fundamental.  But if the user is required 
to do a lot of it I'm inclined to look at the larger workflow context, 
and try to find alternate views that make the data of interest more 
readily visible.

Not every workflow will lend itself to that, and when you need a list 
you need a list.  But overall, the DG's scrolling performance hasn't 
been the make-or-break for anything I've worked on.



 > I am trying to provide genuine feedback. LC’s authors must know the
 > limitations of the DG but do not seem to have a plan to remedy the
 > situation.

It's been good feedback, very clear and very thorough.

But when something seems amiss, whether with the folks at RunRev or 
anyone else, before suggesting ignorance or inability it may be helpful 
to first ask why things are as they are.

Read the blog and the newsletters.  Lots of activity in Edinburgh.

On this issue, it seems they heard you even before your first post. 
Making an xTalk that's both the world's fastest and the most flexible 
takes some time, but with the independent column alignment in the new 
Uniode-savvy fields in v7, and the new Widget architecture outlined in 
that video, they're on it.

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