--0eh6TmSyL6TZE2Uz
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Mar 31, 2011 at 02:27:13AM +0900, Mike Stephens wrote:
> >> Are you saying that you're creating some kind of stand-alone variant
> >> of VBA?
> 
> Unfortunately most people think the words 'Excel' and 'programming'
> must equal VBA. I spent a lot on a book called Professional Excel
> Development which hardly mentions Excel itself. I think however in ome
> circumstances VBA functions may have to be used eg to call realistic
> SOAP services.  The key is to keep them as functions ie no calling and
> waiting. They should look exactly like in-built functions. Also the
> accomplished S# programmer only uses them as a last resort.

I know that one can use other languages to manipulate data in Excel, but
when you use those other languages, you use those other languages -- and
not so much Excel (with its embedded macro language, VBA).  When you say
"I'm using JScript with Excel," that doesn't mean VBA.  When you say "I'm
using Excel," though, that to me *does* mean VBA -- or no programming
language at all.


> >>
> >> it's three metric tons of VM-like overhead
> 
> but seems to load faster than Ruby

Maybe on MS Windows.  I hear rumors Ruby is slower on that platform.  On
the other hand, on a dual-boot system, Ruby runs quickly enough for the
limited purposes for which I use it on Win7.  It's faster on the Unixy
side, though.

Perhaps you're confusing preloaded application being presented to the
user with actually opening the application, though.  The default behavior
for MS Office is to load the whole shebang when the OS starts up, and
just hide it from view until the user clicks the appropriate icon, thus
giving the appearance of very fast loading applications.  The truth of
the matter is that it just consumes a lot of RAM even when you aren't
using it.


> >>
> >> Maybe you'd like working with a database management system that
> >> offers some kind of stored procedures or triggered functions
> >> capabilities more.
> 
> Your remark is highly relevant. Tedd Codd deliberately designed the
> relational model to eliminate the requirement to describe process. SQL
> is a very powerful functional programming system. Stored procedures
> however are usually...procedural.

By default, it's a bit more declarative than functional -- though with
various procedural extensions to SQL it is quite possible to do some FP
magic as well.


> >>
> >> Excel is to DBMSes as those old Power Wheels toys are to actual
> >> cars, after all.
> 
> I suspect you can do a lot of real world 'database' processing in Excel
> -just like some folks use ActiveRecord (no - don't start me off on
> ORMs...). On that basis, I guess a simple web site could use a lot of
> functional programming functions without resorting to DBMS facilties.

You can also do a lot of real world traveling with one of those Power
Wheels toys, but it's slow, inefficient, burdened with a frustratingly
limited set of controls, and notably lacking on ability to scale to high
loads.  Being able to do something with a given tool by no means suggests
it's a good tool for the job.


> 
> As I said earlier, one of the attractions is you have to think
> differently.

Sometimes, I like to pretend I'm writing software meant to run in 128KB
of RAM, too.

-- 
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]

--0eh6TmSyL6TZE2Uz
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (FreeBSD)

iEYEARECAAYFAk2TheIACgkQ9mn/Pj01uKUduQCg1Cl5vxK9NRZPTP4vBgm8Lcpz
97sAoMEED4YrjV1SzyzhS7rVCX1K/3iz
3d
-----END PGP SIGNATURE-----

--0eh6TmSyL6TZE2Uz--