Very disappointed with revolution

[AndyP]

Hi theRock777,

There is a great utility here:

http://www.createchsol.com/ScriptReporter/

for print out the stack and card scripts.

Hope it helps

Andy

[FourthWorld]

Some of us need to make self imposed rigours.

While I don't know of a way to make Rev enforce variable typing, you can make it enforce declarations using the explicitVariables global property.

This helps enforce at least a modest level of discipline in requiring that any variables used are declared.

Personally, I don't use it much since I find my own coding work starts out very exploratory, and slowly fleshes itself out as I figure out the best algo, add error-checking, etc. In such flux having to go back and declare variables eats a lot of time, esp. since I'm likely to be changing things a lot as I go.

But if you like such discipline you may find the explicitVars property very helpful. It comes in very handy for catching typos in var names too, catching them during compile rather than letting you discover them later on during unit testing.

[FourthWorld]

Yes I was a bit disappointed when I realised I couldn't have $variables and

%hash = (
"key"=>"value",
"key2"=>"value2"
);

and @array = ("one","two","three");

Or maybe I can and don't realise it.

Kinda sorta.

While the equals operator is only used for comparison in RevTalk and cannot generally be used for assignment*, you can use the split command to turn a list of lines or items into an array, and you could make a handy handler to do that for you so you can call it in one line:

Code: Select all

on mouseUp
  put ToArray("one,two,three") into tMyArrayA
  put the keys of tMyArrayA
end mouseUp

function ToArray pList
  split pList by comma
  return pList
end ToArray

Doesn't save much scripting, but might be helpful.

Most of my arrays use named keys, so perhaps this variant would be more useful:

Code: Select all

on mouseUp
  put ToKeyedArray("key1,value1" &cr& "key2,value2" &cr& "key3,value3") into tMyArrayA
  put the keys of tMyArrayA
end mouseUp

function ToKeyedArray pList
  split pList by cr and comma
  return pList
end ToKeyedArray

* When declaring script-local vars and constants you can use "=" as an assignment operator, e.g.:

sMyScriptLocal = "SomeValue"
kMyConstant = "SomeOtherValue"

Within handlers, however, "=" is always reserved for comparison only.

Is there any reason why I cant have g_var, t_var etc?

None. In fact, the word-boundary algo in Rev's text engine was updated in v3. so that double-clicking variable names containing an underscore now selected the entire work, underscore and all.

[FourthWorld]

You found Devin Assay's BYU site - excellent. Though he's far too humble to ever admit it, he is a teaching god. His site is one of the most valuable resources for learning Rev.

Based on your experience with revolution, would share what revolution is not good for? We all know that all programing languages have their weaknesses and strengths, I just want to make sure I'll be using this language for the correct apps, before I learn it well.

The limits of Rev's performance are fairly common among typeless very-high-level languages: being typeless, computationally intensive operations on large collections of numeric value, such as making graphic filters, will be much slower in Rev than in strongly-typed languages. It can be done, and there are a few examples of making graphic filters in Rev (Chipp Walters and Wilhelm Sanke have done a few), but they're not exactly lightning fast.

Similarly, Rev's engine isn't very good at operations which could benefit from true multitasking, such as asynchronous progress indicators or multi-sprite animations. Malte's wonderful AnimationEngine gets excellent performance and flexibility for a wide range of animations and is well worth checking out, but when we compare what Rev can do to an engine designed from the ground up for animation, like Flash or Director, you'll find some aspects, shall we say, "challenging".

Also, projects requiring an unusual number of objects on a card may bog down in Rev. In some recent stress testing I was doing for a project I found performance remained very good with up to 10,000 buttons, but beyond that, or even using that many fields (fields are much more complex beasts under the hood), performance degraded noticeably. It's very, very rare that a layout will require more than a few thousand objects at most, and fortunately those seem to work quite well.

Unicode support in Rev is much improved in recent versions, but still has some limitations. For example, displaying right-to-left languages like Hebrew and Arabic works well enough, but attempting to drag selections in fields displaying them is wonky. Also, the heart of Rev's text processing strengths lies with "chunks" (describing text by line, word, character, item), and such expressions do not currently work well if at all with Unicode text. Given how central chunks are to Rev and how central Unicode is to computing I expect this will be improved sooner rather than later, but at the moment Rev's text engine is a bit weak with some aspects of Unicode.

That said, the benefits of their text engine are remarkably strong. You can throw the entire Bible into a field (I did this not long ago using the Gutenberg Project text) and the buffering of the field is so smartly done that it scolls far more smoothly than even Word.

And for the ISO-8959-1 character set which Rev uses natively, chunk operations are generally very efficient.

I wouldn't want this discussion to turn into another "vs" thread, but these tests produced interesting results:
http://web.archive.org/web/200407031322 ... speed.html

They compared text processing tasks among three different languages, one of them billed as "fully compiled" (in contrast to Rev's VM-like runtime compilation). Even with runtime compilation, Rev performed admirably well.

I suppose if one were to make further task-specific optimizations in each of the languages used there performance would increase for each of them, and so I wouldn't necessarily regard those results as the final work on any sort of comparison (let's please not have another "vs" thread).

I bring it up here only to illustrate how well Rev does with the things it does well, text processing being one of the strongest, and thankfully in one form or another text processing is at the root of a broad range of tasks.

Areas of strength and weakness with the Rev engine can be anticipated by thinking about the language as a sort of "glue", letting you use runtime-compiled scripts to link together well-optimized machine-code instructions crafted in C++ in the engine. In general, whenever you can let the engine do the heavy lifting you'll be glad you did, which is why my mantra is:

Know the engine
Trust the engine
Use the engine



Some parts of the engine are complex, though, so while this is a generally useful rubric it rarely applies to things like regex, where you can often get far better performance hand-crafting a parsing routine than you can by enjoying the one-liner convenience of regex. It's not that there's anything wrong with Rev's regex implementation, but merely that regex is such a very generalized solution that it's a very complex subsystem with a lot of internal overhead, overhead we generally don't have to worry about unless we're doing something that requires the fastest possible solution.

This notion of VHLLs as "glue" was introduced to me in this paper:

Scripting: Higher Level Programming
for the 21st Century
http://home.pacbell.net/ouster/scripting.html

Osterhout's description there of the benefits of typeless languages for a wide variety of tasks applies as well to Rev as it does to his TCL.

This paper is also helpful in finding the sweet spot for scripting:

In Praise of Scripting: Real Programming Pragmatism
http://www.cse.wustl.edu/~loui/praiseieee.txt

[therock777]

Thank you Andy, this utility will help a lot.

Leonardo,

[therock777]

Richard,
Thanks for this wonderful explanation, now I can have a peace of mind when the time to developed my projects arrive, Revolution should be sufficient to solve my problems, since I'm not going to need that many buttons and fields.