Plea to sell Dan's book widely

Alex Tweedly alex at tweedly.net
Sat Aug 7 11:05:44 EDT 2004


At 09:37 07/08/2004 -0400, Richard Gaskin wrote:

>Indeed the productivity benefits are hard to match, and I've seen no
>reasoned argument describing something more productive.

Agreed - though I would guess that, for me, Revolution is less than half as 
productive than it *should* be. It's held back by
   - documentation (somewhat improved in 2.5B)
   - flaky behaviour of keyboard shortcuts (improved in 2.5B, but still 
quirky compared to the platform standards)
   - poor error reporting (getting to be less of an issue as I get used to 
ignoring the message itself and just inspect the code in the area)
   - poor script colorizer (improved but still disappointing in 2.5B)
   - lack of navigation features (raise/focus next window, edit indicated 
handler, etc.)
   - non-intuitive (and poorly documented) distinctions between keywords, 
arguments, evaluated strings, variable names, etc. - and lack of diagnostic 
when you get it wrong

This is aggravated by lack of a good, well-organized collection of 
user-contributed scripts and libraries. (I can't decide whether RevOnline 
is going to be a step forward or a step backward here - won't be able to 
tell until we see it in operation).


>But on performance, I think you must have missed a few posts here
>over the last year:
>
>Everytime someone who who doesn't use Rev comes trolling in here looking
>to pick a fight on performance, ultimately it is the troll who goes away
>embarassed when Rev is demonstrated to outperform their fave, and often
>in fewer lines.

I've raised a number of performance related issues. I didn't come here 
deliberately trolling to find them :-)

What I've found is that if I do something the *obvious* way in Rev, the 
performance can be appallingly poor.  There is usually (maybe always) a 
different way to do it that is adequately fast (at least within 10 or 20% 
of the performance of other scripting languages), but requires a far less 
natural or convenient way to do it.

examples ?
1. draw moderate number of rectangles:
      Other language - you draw a number of rectangles
      Revolution - you draw a single large polygon with invisible edges and 
rectangular markers at each vertex. (!?)

The Rev way works quite nicely, only 10 or 20% slower than in the other 
language, but I'd never have found it without the help of this group. And I 
didn't find it without wasting hours (days ?) pursuing other more obvious 
ideas which all failed through performance.

2. Modify the size, colour or position of some of those rectangles you just 
drew in example 1.
    Other - you change the colour (shape, position) of the rectangle, and 
re-draw the set
    Revolution - you maintain a number of polygons (as lists of vertices in 
variables, not in the graphics themselves), representing the different 
combinations of colour and size needed,and then remove the required line 
from one polygon and add it to another, then re-draw (i.e. put the variable 
into the graphic) the two polygons. Oh - and if you need to deal with 
layering, then you need mulitple polygons per color/size/layer ...

Again, it works - but it is about as self-documenting as Fortran :-)

3. Read a CSV file
The simple natural way (of course) doesn't work - CSV isn't like that :-)
The proper way works OK in Rev, though performance is an issue.
The quick way (thanks again Richard !) works well, and has pretty decent 
performance; but it is 20-30 lines including a couple of non-obvious 
techniques - which as a beginner in the language I wouldn't have considered.

And to change to a different dialect of CSV (e.g. read csv from Access 
rather than from Excel) would be another 20-30 lines, with a couple of 
subtle differences.

The Python equivalent is to use a standard library - so a couple very 
obvious and well-documented lines instead of those 20-30; to use a 
different dialect is one extra phrase (dialect="Access")

4. Displaying a CSV file (re-formatted into a scrollable set of columns).
I did this using a number of list-fields, and scrolling the group - I might 
have used the altFieldHeader had I known about it at the time).

This worked "kind of OK" - did what I wanted, but was a bit slow.
Didn't take long to think about it, move all the workings into variables, 
and finally write the variables to the fields. |mproved the performance 
from "iffy" up to "just fine".

So again - Rev can do it with adequate performance - but I find myself 
having to consider performance in a way I haven't had to do for years.  And 
there's a trade-off between performance and natural data structuring that I 
haven't had to deal with elsewhere.

-- Alex.


More information about the use-livecode mailing list