compileIt for revolution?

[Jim Bufalini]

Jon,

My point exactly: "a large array of numbers" = "data" So is the photograph
you are computing the histogram on. Would either of these change, if you
switch languages? Hence, they are external to your language, or "data."

I write business application software, so I've never had to compute a
histogram and admit I have no clue as to what's involved in that process.

However, I have to believe that it is no different than someone saying we
have over 200,000 lengthy depositions and need to quickly know any
deposition where Jon said to Jim "with all due respect" in the second
quarter of the year 2005 while discussing the topic of "compilIT for
revolution?". And, we don't want any false positives.

If you try to brute force this and depend on your language, OS, and platform
for speed of execution, you could be waiting minutes, hours or even days for
the result.

But, if you know the kind of data manipulation you will be doing in advance,
you can parse, index, or otherwise reorganize the source data in such a way
as to minimize large data sources or "large arrays."

Now, depending on how well you organized your data, whether your language is
in pcode or machine compiled, results in only milliseconds of difference.

Believe me, over 25 years of programming experience bears this out.

Jim

-----Original Message-----
From: Jon [mailto:jbondy at sover.net]
Sent: Friday, June 24, 2005 1:27 AM
To: YourSignup at Yahoo.com; How to use Revolution
Subject: Re: compileIt for revolution?


With all due respect, Jim, if you are trying to do even simple math on a
large array of numbers (like computing a histogram of image data), Rev
is simply too slow to use.  It has nothing to do with data structures:
it has to do with slow pCode trying to run tight loops.

Jon

Jim Bufalini wrote:

>Guess I'll add my two cents.
>
>I'm a newbie to "Rev" (Revolution) but worked over 25 years in "Rev"
>(Revelation), another similar, high-typed, extensible, flexible, run as you
>program, script language. It's an implementation of Pick on the PC. I was
>considered an expert. I also owned a company and employed programmers.
>
>I too, have heard these discussions hundreds of times, over the years.
>
>Speed of execution rarely relates to code, or the language, or whether it's
>compiled, or in pcode or whatever. It always has to do with data, whether
>the data is in arrays, or a database, or whatever object. Any language can
>add 2 to 2 instantly, regardless of the syntax.
>
>You don't get speed by changing languages, or writing lengthy workarounds,
>or complaining about your tools. You get speed by designing, in advance,
the
>layout of your data.
>
>This requires straight thinking. 1. Know what you are setting out to
>accomplish before you type one character of code (what are your client's
>(your) goals?). 2. Layout and optimize the data you are going to access
>BEFORE writing any code. How are you indexing the data? Is it real indexing
>or organization? 3. Now write your code. If you find yourself writing
>spaghetti code, STOP, go back to step 1.
>
>Jim
>
>-----Original Message-----
>From: use-revolution-bounces at lists.runrev.com
>[mailto:use-revolution-bounces at lists.runrev.com]On Behalf Of Dan Shafer
>Sent: Wednesday, June 22, 2005 12:12 PM
>To: How to use Revolution
>Subject: Re: compileIt for revolution?
>
>
>This whole discussion has been revealing and intriguing to me.
>
>My favorite programming language is Smalltalk. But before it was
>possible to create UIs for Smalltalk without writing code, I found it
>cumbersome. When a product called WindowBuilder came along, I felt
>like we'd achieved the ultimate development environment. In many
>ways, I still think that. Smalltalk had other problems,
>unfortunately, that made it great to code in, difficult to impossible
>to deploy.
>
>Then my second favorite language was Python. The GUI-building tools
>for Python are pathetic to non-existent. But the language is powerful
>and elegant and extends naturally. If the PythonCard project I was
>engaged in before I discovered Revolution had been on a fast track or
>complete, odds are I'd have never used Rev.
>
>Now I favor Transcript and RunRev. Building UIs is all but painless
>and 95% of what I want or need to do in creating apps is simple
>inside the elegance of Transcript. But Transcript isn't  object-
>oriented.
>
>Two aphorisms came to mind as I read this entire thread again today.
>
>One is, "No good programmer uses only one tool for everything."
>
>The other is, "It's a poor workman who blames his tools."
>
>
>
>
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>Dan Shafer, Revolution Consultant and Author
>http://www.shafermedia.com
>Get my book, "Revolution: Software at the Speed of Thought"
> From http://www.shafermedia.com/revolutionbooks.html
>
>
>
>
>_______________________________________________
>use-revolution mailing list
>use-revolution at lists.runrev.com
>Please visit this url to subscribe, unsubscribe and manage your
subscription
>preferences:
>http://lists.runrev.com/mailman/listinfo/use-revolution
>
>
>
>_______________________________________________
>use-revolution mailing list
>use-revolution at lists.runrev.com
>Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
>http://lists.runrev.com/mailman/listinfo/use-revolution
>
>
>
>