Re: living and learning (Re: RunRev vs RealBasic (Richard Gaskin))
On Jan 19, 2005, at 12:05 PM, Chipp Walters wrote: It's really just a matter of style, for instance, I *never* use the card method for this. I only use multiple card stacks in a couple places: 1) Wizards 2) I many times use the 2nd card in a stack to store all the icons for the first card. This goes along with the concept of keeping the data and presentation layers completely seperate. HyperCard (and to an extent RunRev) allow users to mix the two, I prefer not to for a variety of good reasons. I'm not sure I understand what you mean here. If we're talking about a way to set up a tab panel, we're not talking about data at all. The different cards would have different controls -- presentation layers, if you prefer -- on them. If you're talking about data vs. presentation, then are you talking about the common practice of using HyperCard stacks as a database? You have a multi-card stack with a common group of controls, with different data in the fields on each card. I also generally prefer not to do that, although I'm not religious about it. Apart from philosophical issues, it limits you to several thousand records (in Revolution) as beyond that stacks become significantly slow to open and save. regards, Geoff Canyon [EMAIL PROTECTED] ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
RE: RunRev vs RealBasic (Richard Gaskin)
It seems to me a more significant contest between the two systems would be to assign the same project to two very experienced developers with each development environment, and see who gets it finished quicker. I cannot imagine many situations where productivity is not of great significance. If a person can create a program in half the time of his competitors, he can afford to charge less to his clients, and still make a bigger profit. This is not to say that Real Basic is not a fast development environment - I honestly do not know that much about it one way or the other. I am just saying that this particular contest misses the point for like 99 out of 100 programming situations. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chipp Walters Sent: Thursday, January 20, 2005 9:48 PM To: How to use Revolution Subject: Re: RunRev vs RealBasic (Richard Gaskin) Hi David, A quick Google shows you're the product manager for Real Basic. Guess that sorta slipped your sig ;-) I certainly understand your desire to defend RB to the max. I followed closely the previous RB-RR thread, and don't recall it as you do. Perhaps we should discuss over lunch? (I'm in Austin, too!) -Chipp -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.7.0 - Release Date: 1/17/2005 ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Offset with 'charstoskip' doesn't work? [was RunRev vs RealBasic (Richard Gaskin)]
I thought I would see if I could solve the RB/Rev/SC challenge and tried this as a first attempt: on mouseUp put fld 1 into sFld put fld 2 into tFld put into fld 3 -- put 0 into it --*1 put zero into t --*2 repeat with i= 1 to the number of lines in tFld repeat -- get offset(line i of tFld,sfld,it) --*1 get offset(line i of tFld,sfld,t) --*2 put it into t --*2 if it is zero then exit repeat put line i of tFldiitreturn after fld 3 end repeat end repeat end mouseUp but what happens is along the way it finds a search string in question at char 246674 and then finds it again at 250675 and then finds it again at 246674 then at 250675 then at 246674 then at 250675 ... Is offset not working or am I not? Michael ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: RunRev vs RealBasic (Richard Gaskin)
Chipp Walters wrote: Hi David, A quick Google shows you're the product manager for Real Basic. Guess that sorta slipped your sig ;-) I certainly wasn't trying to hide my affiliation and I did use my REAL Software email address. I tend not to use a signature very often although it would probably be a good habit to get into. I certainly understand your desire to defend RB to the max. I followed closely the previous RB-RR thread, and don't recall it as you do. Before posting to this list I wanted to confirm my recollection and read original messages from both the RunRev and REALbasic mailing lists. Perhaps we should discuss over lunch? (I'm in Austin, too!) Sounds good - feel free to contact me off list. Best regards, David ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: RunRev vs RealBasic (Richard Gaskin)
Richard Gaskin wrote: We had a rather funny thread here last year in which an RB fan started a bake-off for speed on a parsing algorithm on a fairly large file. True 'nuff, RB was faster -- but only by 3 milliseconds. And that was the overal score -- in the most common task, loading a file, Rev was nearly twice as fast. A number of small clarifications on this. The person who started the speed comparison was not an RB fan but rather a SuperCard user evaluating both REALbasic and Revolution. His initial attempt found that REALbasic was significantly faster than Revolution. After both sets of code were further optimized the speed differences were negligible. The primary difference after optimization is the readability and maintainability of the code. The guts of the routine in REALbasic is 6 lines of code but 37 lines of code in Revolution. As for the speed of the load, the results are probably misleading for REALbasic because it includes the first step of string processing. Either way the load is extremely fast in both environments and it's a tiny tiny fraction of the total task. Here's the code for each environment: copied from http://www.yav.com/speed.html REALbasic: x=uBound(STarray) For i = 0 to x If InStrB(TT,(STarray(i))) 0 then Matches=Matches+STarray(i)+chr(13) End if Next Revolution: replace quote with empty in stList put lower(tMatchList) into tLowerMatchList replace quote with empty in tLowerMatchList put md5Digest(tMatchList) into tDigest if (tDigest textDigest) then put empty into shortFindList repeat for each word w in tLowerMatchList put char 1 of w into c put c after shortFindList put TRUE into isWord[w] put TRUE into isWord[w0w] put w into w0 end repeat put tDigest into textDigest end if set the caseSensitive to TRUE repeat for each line inLine in stList put empty into shortFind put lower(inLine) into inLineLower put 0 into i put empty into w0 repeat for each word w in inLineLower if not isWord[w0w] then put empty into shortFind exit repeat end if put char 1 of w after shortFind put w into w0 end repeat if (shortFind is empty) then next repeat put offset(shortFind, shortFindList) into x if (x 0) then if (offset(inLineLower, tLowerMatchList, x*2-1) 0) then put inLine return after MatchList end if end if end repeat -- David Grogono ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: RunRev vs RealBasic (Richard Gaskin)
Yes 4000 times faster, once you take your shoes off. One char, 4 char and 8 char replacement is fast. on mouseUp repeat with i = 1 to 100 put 1234567890 after dd end repeat put 990 into a get the long seconds put a into char a of dd put abcd into char a to a+3 of dd put abcdefgh into char a to a+7 of dd put the long seconds - it end mouseUp Michael On Jan 20, 2005, at 12:38 AM, Richard Gaskin wrote: Richard Gaskin wrote: Chipp Walters wrote: Richard Gaskin wrote: I've been pondering this new speed enhancement to same-size chunk replacements, specifically in regard to image processing. Since much of what image processing involves is replacing a specific number of bytes, I wonder if any of the folks here have made any recent experiments with writing image filters in native Transcript. With the sort of speed Dar reports we may find that some types of filters can run acceptably well in Transcript alone. I did write some compositing and blur/sharpen filters in transcript some time ago, but I don't know the details of the 'same-size chunk' replacements. Where can I find more info? All I know is what Dar posted here, but it sounded really tasty. Apparently he made a suggestion to Scott Raney about ways to optimize operations in which a string of a given length is used to replace a substring of the same length within a larger chunk. In previous versions a very generalized approach was used for all replacement operations, requiring that the data be copied during the replacement, which can be computationally expensive with large chunks. Since the data being inserted is the same length as the data being removed the handle size doesn't change, allowing the operation to work in-place, without copying. IIRC, Raney reported that the new method should improve speed by roughly 4000 times for those cases. Dar - got the details for us? Found the Bugzilla notes: http://support.runrev.com/bugdatabase/show_bug.cgi?id=586 ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: RunRev vs RealBasic (Richard Gaskin)
Michael D Mays wrote: All I know is what Dar posted here, but it sounded really tasty. Apparently he made a suggestion to Scott Raney about ways to optimize operations in which a string of a given length is used to replace a substring of the same length within a larger chunk. In previous versions a very generalized approach was used for all replacement operations, requiring that the data be copied during the replacement, which can be computationally expensive with large chunks. Since the data being inserted is the same length as the data being removed the handle size doesn't change, allowing the operation to work in-place, without copying. IIRC, Raney reported that the new method should improve speed by roughly 4000 times for those cases. Dar - got the details for us? Found the Bugzilla notes: http://support.runrev.com/bugdatabase/show_bug.cgi?id=586 Yes 4000 times faster, once you take your shoes off. One char, 4 char and 8 char replacement is fast. on mouseUp repeat with i = 1 to 100 put 1234567890 after dd end repeat put 990 into a get the long seconds put a into char a of dd put abcd into char a to a+3 of dd put abcdefgh into char a to a+7 of dd put the long seconds - it end mouseUp For clarity, I should admit that I'd accidentally misquoted Scott Raney's claim from the Bugzilla report: it's *only* 1000 times faster, not 4000 times. What does once you take your shoes off mean in this context? -- Richard Gaskin Fourth World Media Corporation ___ [EMAIL PROTECTED] http://www.FourthWorld.com ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: RunRev vs RealBasic (Richard Gaskin)
In fairness to Rev, there was no stipulation regarding how many lines of code it take to generate the results. In fact, one could concatenate all lines of the Rev code using ';' to solve the problem in only 1 line of code ;-) Also, there are certainly different things going on in the two code snippets you posted. In RB, variables are not declared, but in Rev some are instantiated-- not to mention the MD5digest reset switch (only in the Rev code). Also, as I recall, this project was a 'moving target.' Once Rev posted a 'winning time', the challenge changed benefiting RB. Assuming 'readability' and 'maintainability' were set as primary goals, it's hard to deny Xtalk languages excel in both areas. All that said, it does look like either application can handle string parsing w/out problems. -Chipp David Grogono wrote: A number of small clarifications on this. The person who started the speed comparison was not an RB fan but rather a SuperCard user evaluating both REALbasic and Revolution. His initial attempt found that REALbasic was significantly faster than Revolution. After both sets of code were further optimized the speed differences were negligible. The primary difference after optimization is the readability and maintainability of the code. The guts of the routine in REALbasic is 6 lines of code but 37 lines of code in Revolution. As for the speed of the load, the results are probably misleading for REALbasic because it includes the first step of string processing. Either way the load is extremely fast in both environments and it's a tiny tiny fraction of the total task. Here's the code for each environment: copied from http://www.yav.com/speed.html -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.7.0 - Release Date: 1/17/2005 ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: RunRev vs RealBasic (Richard Gaskin)
David Grogono wrote: Richard Gaskin wrote: We had a rather funny thread here last year in which an RB fan started a bake-off for speed on a parsing algorithm on a fairly large file. True 'nuff, RB was faster -- but only by 3 milliseconds. And that was the overal score -- in the most common task, loading a file, Rev was nearly twice as fast. A number of small clarifications on this. The person who started the speed comparison was not an RB fan but rather a SuperCard user evaluating both REALbasic and Revolution. Having once been the leading vendor of third-party components for SuperCard, I've known him for more than a decade. Somewhere in the communications he mentioned that he'd felt so burned by the Allegiant experience that he was resistent to working with xTalks in general, and accordingly had a preference for RB. His initial attempt found that REALbasic was significantly faster than Revolution. That was the second round. The first round had Rev way in the lead (twice as fast IIRC), using nothing more than a half-dozen lines of code found in an old MetaCard example stack. After both sets of code were further optimized the speed differences were negligible. The primary difference after optimization is the readability and maintainability of the code. The guts of the routine in REALbasic is 6 lines of code but 37 lines of code in Revolution. We could selectively compare subsets, but to get the job done the final published code listings have 74 lines for RB and 79 lines for Rev. As for the speed of the load, the results are probably misleading for REALbasic because it includes the first step of string processing. It's odd that after so many RB'ers helped with that code they came up with an inefficient method. But maybe it's not so bad -- his Rev code uses: put url (file:fn) into tMatchList That also does string processing, changing any line endings to match the Unix convention used internally within the engine. binfile is often faster than file, since it loads the file wholesale without modifying line endings. Either way the load is extremely fast in both environments and it's a tiny tiny fraction of the total task. Here's the code for each environment: copied from http://www.yav.com/speed.html From that page: RealBasic (5.5.1) Revolution (2.2) Load Data 28 ms 14 ms Check Matches 1036 ms 1049 ms Display All184 ms 188 ms TOTAL1248 ms (78 ticks) 1251 ms (78 ticks) What's interesting here is not RB vs. Rev, but RB vs. C. One of the advantages RB personnel like to tout is that RB is fully compiled, in contrast to what they characterize as Rev being interpreted (in truth Rev is a bit of both, like Java but with more efficient structure, but that's another hair-splitting story). If RB were indeed fully compiled, we should expect it to beat the pants off of any interpreted language by a very wide margin, and have speeds more in line with what one would expect from compiling C or anything else that outputs machine-specific object code. That so many common tasks perform with nearly equivalent speed in an ultra-high-level language like Transcript speaks rather well for its inventor. And given the many productivity advantages to typeless languages outlined by Osterhout and others (http://www.tcl.tk/doc/scripting.html), Rev makes a very strong case for itself that more than compensates for the few specialized cases where RB may actually turn out to be significantly faster. -- Richard Gaskin Fourth World Media Corporation __ Rev tools and more: http://www.fourthworld.com/rev ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: RunRev vs RealBasic (Richard Gaskin)
see thread Bugzilla 586, the fast char replacement (was Revolution compilation) I had a hard time counting to 4. I get a 4000X improvement on my dual 2GHz PPC G5. Michael On Jan 20, 2005, at 4:43 PM, Richard Gaskin wrote: For clarity, I should admit that I'd accidentally misquoted Scott Raney's claim from the Bugzilla report: it's *only* 1000 times faster, not 4000 times. What does once you take your shoes off mean in this context? ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: RunRev vs RealBasic (Richard Gaskin)
Chipp Walters wrote: In fairness to Rev, there was no stipulation regarding how many lines of code it take to generate the results. In fact, one could concatenate all lines of the Rev code using ';' to solve the problem in only 1 line of code ;-) True, there wasn't a line requirement. However, since the speed was roughly the same in both cases I'd be much happier maintaining the 6 lines of code. I have a hard time believing that most people can look at this particular Rev code and easily understand what it's doing. Also, there are certainly different things going on in the two code snippets you posted. In RB, variables are not declared, but in Rev some are instantiated-- not to mention the MD5digest reset switch (only in the Rev code). Valid point, although the amount and readability of code would still be quite different. Also, as I recall, this project was a 'moving target.' Once Rev posted a 'winning time', the challenge changed benefiting RB. Not true. At first no-one on the REALbasic list spent any time optimizing the code since the initial post had found REALbasic to be 5 times faster. Once there was some Rev code that appeared to be faster, those on the REALbasic list took up the challenge. During this process someone noticed that the new Rev code was inadvertently ignoring duplicate matches. Rev may have been faster at this point but the code wasn't doing the full job. It was also pointed out that the Rev code had been optimized for 2 and 3 letter searches and the original poster decided to update his data set to be more representative of his needs. Assuming 'readability' and 'maintainability' were set as primary goals, it's hard to deny Xtalk languages excel in both areas. Sure, but in order to get maximum performance in this particular case it seems both of these things have been sacrificed. All that said, it does look like either application can handle string parsing w/out problems. Agreed. Richard Gaskin wrote: A number of small clarifications on this. The person who started the speed comparison was not an RB fan but rather a SuperCard user evaluating both REALbasic and Revolution. Having once been the leading vendor of third-party components for SuperCard, I've known him for more than a decade. Somewhere in the communications he mentioned that he'd felt so burned by the Allegiant experience that he was resistent to working with xTalks in general, and accordingly had a preference for RB. He didn't have a preference for REALbasic, in fact very early during the thread he mentioned that he was a REALbasic novice: You know more than most on this list that I will squeeze every millisecond out of my code, but SuperCard will only go just so fast. I'm just a novice with Revolotion and RealBasic, so I'm trying to figure out if RealBasic really is THAT fast and whether Revolution can't be coaxed to go a bit faster than I'm able to make it. His initial attempt found that REALbasic was significantly faster than Revolution. That was the second round. The first round had Rev way in the lead (twice as fast IIRC), using nothing more than a half-dozen lines of code found in an old MetaCard example stack. I can't find any evidence of this assertion on either mailing list. The above quote seems to indicate he had found otherwise. After both sets of code were further optimized the speed differences were negligible. The primary difference after optimization is the readability and maintainability of the code. The guts of the routine in REALbasic is 6 lines of code but 37 lines of code in Revolution. We could selectively compare subsets, but to get the job done the final published code listings have 74 lines for RB and 79 lines for Rev. True, but the RB code will display appropriate error messages when the data file is missing or locked. It doesn't look like the Revolution code does this. Removing this code could save 20+ lines. Alternatively the same functionality could be accomplished with fewer lines if anyone cared. As for the speed of the load, the results are probably misleading for REALbasic because it includes the first step of string processing. It's odd that after so many RB'ers helped with that code they came up with an inefficient method. I never said the method was inefficient. I was just pointing out that the timing wasn't simply timing a file load. You were using this one data point to imply that Revolution loaded files twice as fast as REALbasic. But maybe it's not so bad -- his Rev code uses: put url (file:fn) into tMatchList That also does string processing, changing any line endings to match the Unix convention used internally within the engine. binfile is often faster than file, since it loads the file wholesale without modifying line endings. This demonstrates my point. The definition of load was peculiar to this example and shouldn't be used as a basis for a general comparison. Either
Re: RunRev vs RealBasic (Richard Gaskin)
Hi David, A quick Google shows you're the product manager for Real Basic. Guess that sorta slipped your sig ;-) I certainly understand your desire to defend RB to the max. I followed closely the previous RB-RR thread, and don't recall it as you do. Perhaps we should discuss over lunch? (I'm in Austin, too!) -Chipp -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.7.0 - Release Date: 1/17/2005 ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: living and learning (Re: RunRev vs RealBasic (Richard Gaskin))
On Jan 17, 2005, at 12:12 PM, Dan Shafer wrote: On another app, though I *had* to use the hide/show groups method because only part of a window (card) changes in response to the users selections. Note that the multi-card solution for tabs can still be used even if only a part of the window needs to change, as long as there is only one. You can group everything else (perhaps along with the tab panel itself) and include it on all the cards. Then create only what you want to change as card controls. You _have_ to use the show/hide groups technique (or something similar) if you have more than one tab panel and they have to change independently. regards, Geoff Canyon [EMAIL PROTECTED] ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: living and learning (Re: RunRev vs RealBasic (Richard Gaskin))
Geoff Good point. I have a mixture of the two types of needs, but when I can, I now use the card method as it is much more flexible and easier to code. Dan On Jan 19, 2005, at 7:37 AM, Geoff Canyon wrote: On Jan 17, 2005, at 12:12 PM, Dan Shafer wrote: On another app, though I *had* to use the hide/show groups method because only part of a window (card) changes in response to the users selections. Note that the multi-card solution for tabs can still be used even if only a part of the window needs to change, as long as there is only one. You can group everything else (perhaps along with the tab panel itself) and include it on all the cards. Then create only what you want to change as card controls. You _have_ to use the show/hide groups technique (or something similar) if you have more than one tab panel and they have to change independently. regards, Geoff Canyon [EMAIL PROTECTED] ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: living and learning (Re: RunRev vs RealBasic (Richard Gaskin))
It's really just a matter of style, for instance, I *never* use the card method for this. I only use multiple card stacks in a couple places: 1) Wizards 2) I many times use the 2nd card in a stack to store all the icons for the first card. This goes along with the concept of keeping the data and presentation layers completely seperate. HyperCard (and to an extent RunRev) allow users to mix the two, I prefer not to for a variety of good reasons. best, Chipp Dan Shafer wrote: Geoff Good point. I have a mixture of the two types of needs, but when I can, I now use the card method as it is much more flexible and easier to code. Dan -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.7.0 - Release Date: 1/17/2005 ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: living and learning (Re: RunRev vs RealBasic (Richard Gaskin))
Dan Shafer wrote: On Jan 19, 2005, at 7:37 AM, Geoff Canyon wrote: Note that the multi-card solution for tabs can still be used even if only a part of the window needs to change, as long as there is only one. You can group everything else (perhaps along with the tab panel itself) and include it on all the cards. Then create only what you want to change as card controls. You _have_ to use the show/hide groups technique (or something similar) if you have more than one tab panel and they have to change independently. Good point. I have a mixture of the two types of needs, but when I can, I now use the card method as it is much more flexible and easier to code. Most of the time. :) What got me started using groups instead of cards was referencing objects in scripts: While designing WebMerge 2.0 I kept moving controls from one tab to another until I got myself clear on what the program's flow should be. During those changes I'd have to change every script reference to every object to include the different card name. With groups I have all 180+ controls on one card, so I can say: get the hilite of btn idxTemplateOption ...and it doesn't matter to the code which group that's part of. I like many aspects of working with card-based tabs, and tend to use that wherever I can. But for the flexibility it lends to the design process, I'll probably use groups for a lot of tabbed interfaces going forward (at least until I learn to do proper paper prototyping like da pros at UIE http://uie.com/browse/paper_prototyping/). -- Richard Gaskin Fourth World Media Corporation __ Rev tools and more: http://www.fourthworld.com/rev ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: living and learning (Re: RunRev vs RealBasic (Richard Gaskin))
On Jan 19, 2005, at 12:34 PM, Richard Gaskin wrote: What got me started using groups instead of cards was referencing objects in scripts: While designing WebMerge 2.0 I kept moving controls from one tab to another until I got myself clear on what the program's flow should be. During those changes I'd have to change every script reference to every object to include the different card name. With groups I have all 180+ controls on one card, so I can say: get the hilite of btn idxTemplateOption ...and it doesn't matter to the code which group that's part of. Unless (as is the case in one of my apps), you have multiple groups with controls that have the same name. This facilitates making the code more generic/abstract and allowing me to place scripts at a higher level, but has the downside that I have to track the current group and do things like: get the hilite of btn idxTemplateOption of group curGroup WHen you forget to to that, stuff breaks in ways that are all but invisible. Dan ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: living and learning (Re: RunRev vs RealBasic (Richard Gaskin))
Dan Shafer wrote: On Jan 19, 2005, at 12:34 PM, Richard Gaskin wrote: What got me started using groups instead of cards was referencing objects in scripts: While designing WebMerge 2.0 I kept moving controls from one tab to another until I got myself clear on what the program's flow should be. During those changes I'd have to change every script reference to every object to include the different card name. With groups I have all 180+ controls on one card, so I can say: get the hilite of btn idxTemplateOption ...and it doesn't matter to the code which group that's part of. Unless (as is the case in one of my apps), you have multiple groups with controls that have the same name. This facilitates making the code more generic/abstract and allowing me to place scripts at a higher level, but has the downside that I have to track the current group and do things like: get the hilite of btn idxTemplateOption of group curGroup WHen you forget to to that, stuff breaks in ways that are all but invisible. But that's where my curmudgeonly habits have their rare moment of practical applicability: The name idxTemplateOption is already a unique identifier. The idx prefix tells me which part of the program it relates to, and the rest describes what it does. I can move the object anywhere in the card, from group to group, and always address it by name alone. Of course it's less readable from an English standpoint, but fortunately code is skimmed more often than it's read, and funky prefixes tend to stand out visually from the more English-like words native to Transcript. For example, skim this sentence with theWindows and the Windows and see if the former stands out as much as tWindows. Of course someone with your experience already has whatever funky naming tricks help you skim, but newcomers might find some of these helpful: http://www.fourthworld.com/embassy/articles/scriptstyle.html -- Richard Gaskin Fourth World Media Corporation __ Rev tools and more: http://www.fourthworld.com/rev ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: RunRev vs RealBasic (Richard Gaskin)
Thomas Gutzmann wrote: And with the recent 4000-fold increase in speed for same-size chunk replacements, I wonder if the kind of graphics processing you're doing could now be done in Rev. What does that entail? This speed increase is impressing, but having tried quite some alternatives, I'm sure that only C++ (which I don't like) and RB where adequate solutions, There are so many calculations when moving objects and scrolling the pane, that I simply cannot imagine that Rev is fast enough. But I will give it a try as soon as I have some time, and I will come back to the list with the results. For some tasks I'd have to agree, but for many you might be surprised. I've had more than one magazine mistake my WebMerge application for being written in C (that includes a writer for C++ User Journal g). And that was before I did my recent optimization which has since more than doubled WebMerge's throughput. We had a rather funny thread here last year in which an RB fan started a bake-off for speed on a parsing algorithm on a fairly large file. True 'nuff, RB was faster -- but only by 3 milliseconds. And that was the overal score -- in the most common task, loading a file, Rev was nearly twice as fast. I've been pondering this new speed enhancement to same-size chunk replacements, specifically in regard to image processing. Since much of what image processing involves is replacing a specific number of bytes, I wonder if any of the folks here have made any recent experiments with writing image filters in native Transcript. With the sort of speed Dar reports we may find that some types of filters can run acceptably well in Transcript alone. It's a bit disappointing that Rev doesn't provide support for the other Unixes any more - that was one of the big advantages against RB. Which ones are you using that are no longer supported? In my understanding the dropped platforms simply weren't used. With enough interest they might bring some back. Well, ahem, I purchased the Rev license because I wanted to rewrite tools for HP/UX and SunOS. I have to stick with Java there, now. I know that my company cannot produce enough revenue for Rev to justify any extra work for the Unix platforms - but Rev should remove the features from the web site if they don't plan to provide it, or they should give an estimated release date. Agreed. CC'ing the CEO here to make sure that gets attention. (He reads the list, but when something comes up that's really important I trust he doesn't mind the extra effort to help ensure it gets done, esp. something so small.) On the flipside, if there's a way they can help automate those builds it does indeed make a nice statment to show those platforms actively supported, and Sun OS is still quite in use. Now please don't flame! No reasonable person could flame such a balanced and thoughtful post. Thanks for taking the time. Well, I have seen the contrary. But maybe this list is really different. Results vary from list to list, and from reader to reader. But I think you'll find this is a very good crew here in this regard. Most of the pros here use multiple tools and can relate to what you're saying, and the pure Transcripters here probably enjoy learning about what other systems offer, esp. when it's presented as fairly as you have. And any post that furthers the request for alternate-colored-lines in fields will always get a round of applause here. :) Have you added your vote to the Bugzilla request for that? -- Richard Gaskin Fourth World Media Corporation __ Rev tools and more: http://www.fourthworld.com/rev ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: RunRev vs RealBasic (Richard Gaskin)
I did write some compositing and blur/sharpen filters in transcript some time ago, but I don't know the details of the 'same-size chunk' replacements. Where can I find more info? Richard Gaskin wrote: I've been pondering this new speed enhancement to same-size chunk replacements, specifically in regard to image processing. Since much of what image processing involves is replacing a specific number of bytes, I wonder if any of the folks here have made any recent experiments with writing image filters in native Transcript. With the sort of speed Dar reports we may find that some types of filters can run acceptably well in Transcript alone. -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.7.0 - Release Date: 1/17/2005 ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: RunRev vs RealBasic (Richard Gaskin)
Chipp Walters wrote: Richard Gaskin wrote: I've been pondering this new speed enhancement to same-size chunk replacements, specifically in regard to image processing. Since much of what image processing involves is replacing a specific number of bytes, I wonder if any of the folks here have made any recent experiments with writing image filters in native Transcript. With the sort of speed Dar reports we may find that some types of filters can run acceptably well in Transcript alone. I did write some compositing and blur/sharpen filters in transcript some time ago, but I don't know the details of the 'same-size chunk' replacements. Where can I find more info? All I know is what Dar posted here, but it sounded really tasty. Apparently he made a suggestion to Scott Raney about ways to optimize operations in which a string of a given length is used to replace a substring of the same length within a larger chunk. In previous versions a very generalized approach was used for all replacement operations, requiring that the data be copied during the replacement, which can be computationally expensive with large chunks. Since the data being inserted is the same length as the data being removed the handle size doesn't change, allowing the operation to work in-place, without copying. IIRC, Raney reported that the new method should improve speed by roughly 4000 times for those cases. Dar - got the details for us? -- Richard Gaskin Fourth World Media Corporation __ Rev tools and more: http://www.fourthworld.com/rev ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: RunRev vs RealBasic (Richard Gaskin)
Richard Gaskin wrote: Chipp Walters wrote: Richard Gaskin wrote: I've been pondering this new speed enhancement to same-size chunk replacements, specifically in regard to image processing. Since much of what image processing involves is replacing a specific number of bytes, I wonder if any of the folks here have made any recent experiments with writing image filters in native Transcript. With the sort of speed Dar reports we may find that some types of filters can run acceptably well in Transcript alone. I did write some compositing and blur/sharpen filters in transcript some time ago, but I don't know the details of the 'same-size chunk' replacements. Where can I find more info? All I know is what Dar posted here, but it sounded really tasty. Apparently he made a suggestion to Scott Raney about ways to optimize operations in which a string of a given length is used to replace a substring of the same length within a larger chunk. In previous versions a very generalized approach was used for all replacement operations, requiring that the data be copied during the replacement, which can be computationally expensive with large chunks. Since the data being inserted is the same length as the data being removed the handle size doesn't change, allowing the operation to work in-place, without copying. IIRC, Raney reported that the new method should improve speed by roughly 4000 times for those cases. Dar - got the details for us? Found the Bugzilla notes: http://support.runrev.com/bugdatabase/show_bug.cgi?id=586 -- Richard Gaskin Fourth World Media Corporation ___ [EMAIL PROTECTED] http://www.FourthWorld.com ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
living and learning (Re: RunRev vs RealBasic (Richard Gaskin))
On Jan 15, 2005, at 10:12 PM, Richard Gaskin wrote: You have two basic ways to work with tabs in Rev: putting the tab in a shared group and moving between cards in response to the menuPick message, or responding to that message by hiding and showing groups. Damn! :-) I never tought of sharing a tab and moving through cards I have this app with 8 tabs and I am hiding and showing groups... silly me... Thanks Richard, again, I learn a new trick from your mail! andre -- Andre Alves Garzia 2004 BRAZIL http://studio.soapdog.org ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: living and learning (Re: RunRev vs RealBasic (Richard Gaskin))
On 1/17/05 12:25 PM, Andre Garzia [EMAIL PROTECTED] wrote: On Jan 15, 2005, at 10:12 PM, Richard Gaskin wrote: You have two basic ways to work with tabs in Rev: putting the tab in a shared group and moving between cards in response to the menuPick message, or responding to that message by hiding and showing groups. Damn! :-) I never tought of sharing a tab and moving through cards I have this app with 8 tabs and I am hiding and showing groups... silly me... Thanks Richard, again, I learn a new trick from your mail! I do this all the time - create a tab button, group it, set the backgroundbehavior to true, then set its script to: on menuPick newTab,oldTab go card newTab end menuPick Easy! :-) Ken Ray Sons of Thunder Software Web site: http://www.sonsothunder.com/ Email: [EMAIL PROTECTED] ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Multiple Languages per App (was: RunRev vs RealBasic (Richard Gaskin))
Hi Dan, Thomas. Can you say something about how you get the separate pieces to work together seamlessly? I'd often like to use multiple languages for some apps but the problem of cooperation has always stymied me. one of the very basic prequisites is to use a multi-user database; we are going for Postgres because for several reasons which I don't want to list here. Next requirement is to have a similar look-and-feel for the separate parts of the application, especially the menus must look alike. The parts of the application must be grouped functionally to minimise the work required for handling the resume and suspend events - and they are where the applications work together. At resume, the application must retrieve and store the state, preferably from the database. By the way, this allows to share the application between computers. though this may be a bit mundaine. It's a pity that Apple abandoned OLE; nowadays with the fast hardware it would be nice to have it. Under Windows, it allows some extra integration, e.g. using VB as a wrapper application. Apple,on the other hand, has AppleScript, which is superior to Windows scripting. I don't have an idea for Unix, yet. No, I don't think it's difficult to use multiple tools to provide a unified solution, and I think it's the way to go in the future, even including foreign applications like iCal, Excel, Word, Mail etc. - which is very easy with AppleScript. I wrote a small app to help my colleagues and me manage some 50+ servers with different login requirements, usernames, passwords etc. simply be combining Rev, KeyChain and iTerm; I made this app for getting known to Rev, and it was astonishing how fast I had the application ready. Cheers, Thomas G. ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
RE: RunRev vs RealBasic (Richard Gaskin)
- I sometimes have the impression that Revolution as a company doesn't really exist. They are hardly ever seen in this list, it's hard to get responses from them. I think that one of the secrets of the success for RB was (and is) their presence and visibility in the developer community. Agreed 200% -- timely contact with a vendor is critical, as is a regular and ongoing vendor presence on their list. Those were both so important I wanted to make sure they were included here, and have cc'd Kevin to make sure he doesn't miss it. But how many times do we have to come back this subject or tell Kevin this (I've told him more than a dozen times at least! And I know others have too!)? Just to hear another client request it again later... Ah, I know! No one put in a bugzilla request! LOL ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
RE: RunRev vs RealBasic (Richard Gaskin)
Hi all. Here is an alternative perspective on rev vs realbasic. Nothing to do with the product usabliity. Go to these links on the apple store (I use windows myself) Runtime revolution search http://store.apple.com/1-800-MY-APPLE/WebObjects/AppleStore.woa/71502/wo/NqzSeidBmxYv2IKanzr7Wtb2d1e/1.3.0.6.5.2.0.2.1.1 runrev search http://store.apple.com/1-800-MY-APPLE/WebObjects/AppleStore.woa/71502/wo/NqzSeidBmxYv2IKanzr7Wtb2d1e/5.0.11.1.0.6.45.0.1 Realbasic search http://store.apple.com/1-800-MY-APPLE/WebObjects/AppleStore.woa/71502/wo/NqzSeidBmxYv2IKanzr7Wtb2d1e/7.0.11.1.0.6.45.0.1 So if you dont want to go to the website, then here is a summary. Nothing found when searching for runrev or revolution or runtime revolution. A search for realbasic showed that apple sell realbasic. Now A NOVICE DEVELOPER who wants to make a wee programme for his mac may look on the apple store first and think a I should get this, it looks easy then later they discover runrev and think... Oh well I have realbasic so although runrev looks better, I now know how to use realbasic. I did the opposite, I looked at realbasic and thought that runrev was better, however I cam uppon runrev by chance... My 2p worth. -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.6.13 - Release Date: 16/01/2005 ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: RunRev vs RealBasic (Richard Gaskin)
Am 31.12.2004 um 05:30 schrieb Ken Ray: Personally I think on of the biggest advantages that Rev has over RB is that you can go from editing to running *immediately*; you don't need to compile and run. So for example, if you're working on a dialog box that would normally take you 5 mouse clicks to get to from the start of your program, you would have to run that sequence every time you made a simple change to the dialog box. In Rev, you'd just switch to the browse tool, and you're running immediately; you can test right away. I know that this discussion has been over since half a month, but I haven't read the thread before. Using BBEdit as an external editor (on MacOS/X) gives even more power: stay in run mode, modify the script, save it, and go on testing. This is something I'm missing in RB. If you combine this with the power of a scriptable database like PostgreSQL or Oracle, you can can even go further, by modifying database procedures and functions on the fly (which would work in RB the same way). In my 30 years of software development I never had a development environment which gave me such a comfort. It's like a dream. The good thing in RB is that you have true OOP. The bad thing in RB is that you have true OOP. If the application can be divided in small chunks, e.g. windows for working on different tables in a database, you're better off with Rev, because you can work on all of them separately - given that you don't switch to the second window (well, stack) before the first is really perfect. Then you can clone it, and making the second is amazingly quick. But there are cases where OOP is simply better, and then RB is the better choice, of course (better than Java, too). I have an application where I need a very fast and complicated graphic interface with a large number of objects. This I have written in RB; the rest of the application is being written in Rev. All these single and largely independent windows can be done in RB, sure, but it simply takes too long. I'm not sure yet how to do the printing and reporting part - maybe I switch to a third tool for that, like Perl. There are some other points to consider. - RB has more interface elements; it's easier to make tabbed windows (I have given this up in RB), there are much more options for lists, and so on. - In Rev this good old HyperCard idea of cards, combined with the substacks, can be used to combine all elements of a user interface for a given part of the application (e.g. managing data entry using a selection list, modification dialogs, and so on) in one stack. This makes the code MUCH easier to maintain. We have stopped development in RB when the number of dialogs got about a certain threshold - development time exploded. - It's also easier to share development in Rev, because there are less mutual dependencies. If you have one stack for common handlers and functions, you can reduce the sharing just to this stack, the rest can be distributed amongst developers (given, it's a database oriented application with a central db). - Though both systems claim to be x-platform, my experience is that Rev is better in this respect than RB. Maybe that's due to the smaller amount of interface elements. It's a bit disappointing that Rev doesn't provide support for the other Unixes any more - that was one of the big advantages against RB. - Documentation is often criticised in Rev, but after working with it for some time, I think it's not worse than RB. The online documentation is faster to work with, once you have found out how to get around the weak spots. - Support is better in RB, but that may be due to the size of the company; RB brings out new versions faster, and their bug tracking system is better. But on the other hand there are VERY engaged people on this list which make good a lot - but not all. - I sometimes have the impression that Revolution as a company doesn't really exist. They are hardly ever seen in this list, it's hard to get responses from them. I think that one of the secrets of the success for RB was (and is) their presence and visibility in the developer community. But that's also in our hands as customers: we must help them sell licenses... - The IDE of RB was much better in the past, but with 2.5 Rev has improved so much that - after having worked with it for several weeks - I think it's as good as RB now, if not better. Hard to explain in detail - I don't want to waste more or your time. Bottom line: we will continue developing with RB, Java etc. - but now that I'm nearly through with a pilot, we will start using Rev for many portions of applications where we used RB, Java and Perl before, and I'm sure that the larger percentage (by far) will be done with Rev. And once they have finished the transition to SunOS etc. (if ever), we can abandon Java for all GUI programs. Now please don't flame! Cheers, Thomas G. ___
Re: RunRev vs RealBasic (Richard Gaskin)
Thomas Gutzmann wrote: But there are cases where OOP is simply better, and then RB is the better choice, of course (better than Java, too). I have an application where I need a very fast and complicated graphic interface with a large number of objects. This I have written in RB; the rest of the application is being written in Rev. All these single and largely independent windows can be done in RB, sure, but it simply takes too long. How does OOP help with that? And with the recent 4000-fold increase in speed for same-size chunk replacements, I wonder if the kind of graphics processing you're doing could now be done in Rev. What does that entail? I'm not sure yet how to do the printing and reporting part - maybe I switch to a third tool for that, like Perl. In its simplest form, Rev prints a card. So you can lay out a card to appear as you want it on paper, fill it with what you need, and execute a print card command. It can get tricker if you need things like multi-column lists of variable size, but all the raw materials for figuring out the layout dynamically (see the print properties and formattedHeight, pageHeights, etc.) are available in the language for most printing needs. - RB has more interface elements; Which common GUI elements are not also in Rev? it's easier to make tabbed windows (I have given this up in RB), Did you mean Rev? If so, what difficulties did you entounter? You have two basic ways to work with tabs in Rev: putting the tab in a shared group and moving between cards in response to the menuPick message, or responding to that message by hiding and showing groups. Is working with lists of controls in code easier in RB? Or do they have another way of doing it? there are much more options for lists, and so on. What options would be useful to have added to Rev lists? - It's also easier to share development in Rev, because there are less mutual dependencies. If you have one stack for common handlers and functions, you can reduce the sharing just to this stack, the rest can be distributed amongst developers (given, it's a database oriented application with a central db). Amen to that, brother. You can do minimal- or zero-dependancy code in Rev, as you wish. Working on a stack doesn't mean pulling a long clique of classes along with it. It's a bit disappointing that Rev doesn't provide support for the other Unixes any more - that was one of the big advantages against RB. Which ones are you using that are no longer supported? In my understanding the dropped platforms simply weren't used. With enough interest they might bring some back. - Support is better in RB, but that may be due to the size of the company; RB brings out new versions faster, and their bug tracking system is better. But on the other hand there are VERY engaged people on this list which make good a lot - but not all. - I sometimes have the impression that Revolution as a company doesn't really exist. They are hardly ever seen in this list, it's hard to get responses from them. I think that one of the secrets of the success for RB was (and is) their presence and visibility in the developer community. Agreed 200% -- timely contact with a vendor is critical, as is a regular and ongoing vendor presence on their list. Those were both so important I wanted to make sure they were included here, and have cc'd Kevin to make sure he doesn't miss it. Now please don't flame! No reasonable person could flame such a balanced and thoughtful post. Thanks for taking the time. -- Richard Gaskin Fourth World Media Corporation __ Rev tools and more: http://www.fourthworld.com/rev ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: RunRev vs RealBasic (Richard Gaskin)
On Jan 15, 2005, at 3:25 PM, Thomas Gutzmann wrote: I have an application where I need a very fast and complicated graphic interface with a large number of objects. This I have written in RB; the rest of the application is being written in Rev. All these single and largely independent windows can be done in RB, sure, but it simply takes too long. Thomas. Can you say something about how you get the separate pieces to work together seamlessly? I'd often like to use multiple languages for some apps but the problem of cooperation has always stymied me. Dan ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: RunRev vs RealBasic (Richard Gaskin)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have a very limited amount of experience with Visual Basic, and ran the RealBasic demo when trying to decide on a tool for the project I am doing. I have had a little more experience with other languages, including other forms of Basic (Applesoft Basic, QuickBasic), C, Java, Pascal, Ada, etc. I definitely agree that one of Rev's biggest advantages is that program execution can be overlapped with development. While designing a program in the IDE, you can easily switch among form editing, script editing, and browse (execution) modes and not take extensive time for recompiling. If there is a bug during execution, you can often patch it up in the script and restart the script operation w/o needing to go through and restart the entire program. What traditional tools would provide as Debugging information, such as watch windows for variables, etc. are easily accessible through the Rev interface. Immediate command execution is possible through the Message box. There are numerous advantages to an interpreted environment, and even more with the modal used by Rev. However, there are a few disadvantages, as well: some with the modal, and some with Rev specifically. Rev's documentation is somewhat lacking for beginners, so if you do not already have familiarity with an XTalk environment such as HyperCard/SuperCard, it will be a bit of an adjustment to deal with -- of course, it would be an adjustment even with good docs, but it would at least come more easily. However, once you have learned the modal of development used by Rev, and have some familiarity with how to search the docs and use this list, it is not difficult to pick up new topics and use them rather efficiently. My own coding style and use of Rev's features is constantly improving with techniques I pick up on accidentally using this list. Printing is also in need of some improvement, at least under Windows (which has different screen and printer font metrics). Once a few issues have been worked out, and after you get on to how printing is done, you can access some quite powerful features rather easily, though. Also, Rev is an interpreter, not a compiler. Code execution is much slower than what you would get with a compiled language such as RealBasic. This is somewhat compensated for by the fact that so many slow algorithms are already implemented and easy to access through simple instructions in Transcript, and can be further enhanced by using external routines in compiled modules bundled with your program (for computationally intensive tasks not easily covered by Transcript, or for accessing outside libraries or functions currently missing from Rev). Overall though, for most functionality, Transcript is sufficiently fast that this is not a problem, except for computationally intensive algorithms. The language itself is rather simple to learn, and allows you to write software quite quickly once you are on to it. Another advantage of Rev over RealBasic is that many of the tools you use to develop your programs are actually included in the runtime engine for the programs. Drawing/Painting tools, field layouts, etc. can be modified dynamically if you allow them to be, and it is possible to do some rather interesting things by combining the available tools. So download the demo and give it a try. It's not an end-all-else tool (nothing is), but it can be a very powerful way to create simple (and even very complex) programs quite rapidly. On Dec 30, 2004, at 11:30 PM, Ken Ray wrote: On 12/30/04 4:42 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Thanks, Richard, point taken. I'll begin by telling about myself. I have fairly extensive experience with the Windows API, Unix, and the Macintosh environment. I am very familiar with tools such as XCODE, GCC, etc. I have recently (within the last 3 years) found that RealBasic strikes a very, very good middle ground with power vs. ease of use; not sacrificing a great deal of the former. I can't really complain about their support either. My only knowledge of RunRev is what I'm reading from the website and hearing from testimonials. I'm sure you're familiar with the saying all science is magic until discovered (or thereabouts), so basically I am curious as to whether most users are novice developers and are only impressed with RunRev because it is something they can use, or if it really does pack a great deal of power along with flexibility to do the complex things. IMHO, Revolution packs a lot of power in an easy to use shell. I know RB as well as Rev, and I would have to say that if your just looking for raw functionality (i.e. can it do x), Rev and RB are very similar in abilties (RB does a few things Rev can't and vice-versa). However, when it comes to *ease* of implementation (which applies to speed of development and efficiency), as Richard pointed out, Revolution can be much
Re: RunRev vs RealBasic (Richard Gaskin)
References: [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.2 X-Originating-IP: 12.203.234.218 Thanks, Richard, point taken. I'll begin by telling about myself. I have fairly extensive experience with the Windows API, Unix, and the Macintosh environment. I am very familiar with tools such as XCODE, GCC, etc. I have recently (within the last 3 years) found that RealBasic strikes a very, very good middle ground with power vs. ease of use; not sacrificing a great deal of the former. I can't really complain about their support either. My only knowledge of RunRev is what I'm reading from the website and hearing from testimonials. I'm sure you're familiar with the saying all science is magic until discovered (or thereabouts), so basically I am curious as to whether most users are novice developers and are only impressed with RunRev because it is something they can use, or if it really does pack a great deal of power along with flexibility to do the complex things. I am currently developing software as a contractor for several different companies and am very interested in anything that can help me do the job faster without losing much. Currently, my primary interest would be in developing data-connected finance and tracking applications. From my ignorant position, it would appear that RB is much more fit for the robust requirements, but as I said I don't know that for a fact. Hope that gives you a little more insight into where I am. Thanks again, Michael I would happily do my best to help explain why MacWorld UK calls Rev the Best Rapid Application Development tool on the market (Dec 04, p55) if you'll kindly tell us a bit more about your interest in Rev. A shotgun approach usually just turns into a pissing match, and there's plenty in the archives of both lists and elsewhere to feed appetites for that sort of thing. So if you can describe why you're considering Rev we can better address your specific areas of interest. Also, when you say you're not interested in ease of use, does that also rule out productivity? Greater productivity is probably the strongest argument for 4GLs over lower-level languages. Osterhaut makes one of the most cogent arguments in favor of 4GLs -- c check out his seminal paper on the topic: http://home.pacbell.net/ouster/scripting.html. After you've read that please describe why you're considering switching and we'll happly do out best to answer your questions. You may also want to check out Rev's web site: http://www.runrev.com, as most of the questions in your post are addressed there. Your notions about how Rev's pricing compares to RealBASIC's can be clarified there as well, looking beyond the price of admission to total costs for upgrades, support, etc. -- Richard Gaskin Fourth World Media Corporation __ Rev tools and more: http://www.fourthworld.com/rev This message was sent using IMP, the Internet Messaging Program. ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: RunRev vs RealBasic (Richard Gaskin)
On 12/30/04 4:42 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Thanks, Richard, point taken. I'll begin by telling about myself. I have fairly extensive experience with the Windows API, Unix, and the Macintosh environment. I am very familiar with tools such as XCODE, GCC, etc. I have recently (within the last 3 years) found that RealBasic strikes a very, very good middle ground with power vs. ease of use; not sacrificing a great deal of the former. I can't really complain about their support either. My only knowledge of RunRev is what I'm reading from the website and hearing from testimonials. I'm sure you're familiar with the saying all science is magic until discovered (or thereabouts), so basically I am curious as to whether most users are novice developers and are only impressed with RunRev because it is something they can use, or if it really does pack a great deal of power along with flexibility to do the complex things. IMHO, Revolution packs a lot of power in an easy to use shell. I know RB as well as Rev, and I would have to say that if your just looking for raw functionality (i.e. can it do x), Rev and RB are very similar in abilties (RB does a few things Rev can't and vice-versa). However, when it comes to *ease* of implementation (which applies to speed of development and efficiency), as Richard pointed out, Revolution can be much easier to use than RB (IMHO), allowing for one-liners that would take RB several lines to implement (to be fair, this happens the other way as well, but IMHO it seems that more often than not Rev can do things more efficiently than RB). Personally I think on of the biggest advantages that Rev has over RB is that you can go from editing to running *immediately*; you don't need to compile and run. So for example, if you're working on a dialog box that would normally take you 5 mouse clicks to get to from the start of your program, you would have to run that sequence every time you made a simple change to the dialog box. In Rev, you'd just switch to the browse tool, and you're running immediately; you can test right away. Just my 2 cents, Ken Ray Sons of Thunder Software Web site: http://www.sonsothunder.com/ Email: [EMAIL PROTECTED] ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
