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.
_______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
