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