Eu - Why? and Why Not (Fairly Long Post)
I adopted Euphoria because I'm an adamant (some say vitriolic) advocate
of "appropriate technology." This is a concept which is almost
completely absent from the world of big corporate computing in which I
make a living as what my employer calls - with typically pompous
hyperbole - a "Software QA Engineer."
My dear old Dad used to say "Boy, you don't use a shotgun to swat
flies." I prefer to say that I don't need a 16-wheeler (tractor-trailor
rig) to get my scrawny butt to the corner Quikee-Mart for a Slurpee.
What I was looking for - and seem to have found in Euphoria - is a
"Jeep" language - one that has the following characteristics:
1) Small - It has a limited vocabulary and a direct, uncluttered
syntax, and it produces small "executables" for small tasks.
2) Fast - The speed of interest to me is primarily speed of
installing, learning, and using Euphoria; the execution speed of the
produced code is a pleasant, but not critical, bonus. It took about four
hours from first learning of Euphoria's existence to acquire and
install the software, read the documentation, and complete the first
useful program; I believe that's a personal record for a new language.
3) Flexible - It can handle a wide variety of "everyday" chores in
my environment (primarily Windoz). Specifically, it can produce "system
macros" which can access and control the already existing six zillion
dlls and ocxs on my systems,instead of duplicating their functionality,
and easily creates any sort of textfile manipulation routine. (In this
respect, Euphoria is far simpler to learn and use and more capable
than most Text Editor "macro languages" or "scripting languages" I've
run across.)
4) Sturdy - Simple and adequate debugging capabilities, and stable,
predictable code execution (to the extent possible in a notoriously
unstable and erratic OS).
5) Independence and stability - The language is not subject to
cancerous growth and mutation either from pandering and devious
manipulation by greedy and megalomaniac corporate robber barons - in
particular Satan's Ugly Stepson from Redmond - or from constant revision
and "extension" by an apparently infinite "community" of programmer
wannabees.
6) Security - It does not attract the attention and ire of freelance
internet vandals or the lust of corporate fascists. I think it's highly
unlikely (although obviously not impossible) that someone's web page or
email is going to secretly launch a Euphoria program on my machine to
reconfigure my system to his liking, filtch my financial records, track,
document, and distribute info on my personal habits, or wipe out my hard
drive. (My personal vote for Dumb Crooks of the Century go to the
perpetrators of the webpage messages saying, in effect, "we trying to
personalize this page for you, but we're not getting any personal
information from you."
Conversely, there are several claims made for - and legitimate
attributes of - Euphoria about which I give not a fig. Specifically -
1) I have a basic indifference to, and mistrust of, "cross-platform
development" and "device independence." I see some - but very little -
legitimate need for (or possibility of) "write once - run anywhere." A
forklift and a cement truck are both vehicles used to transport building
materials, but I wouldn't try to train the operators of both with the
same set of operating instructions. And in my experience "device
independence" usually translates into "lowest common device capability."
2) I think Euphoria makes a poor "teaching language" precisely
because it incorporates so much coding "automation" and hides so much of
the "nuts and bolts." I think programming students need to learn the
messy details.
Personally, I would not choose Euphoria for a "large project" anymore
than I would attempt to move my household across the country using a
Jeep. If you get a kick out of building bridges with tackhammers and
toothpicks, I'll give you a very sincere "go on wit' yo' bad self," but
that ain't me. Most "large projects" take place in a business setting.
The vast majority are, in fact, abandoned, often because they're
ill-conceived and unnecessary in the first place, and more often because
they quickly degenerate into chaos due to lack of consideration for the
planning, effort, cooperation, knowledge, and tools required to execute
large software undertakings, including everything from issues internal
to the language, like "namespaces," to "IDE+" issues like collaborative
coding/groupware, version control, documentation, "incident" reporting
and tracking, not to mention distribution, marketing, and staff and
customer training and support. It seems to me that Euphoria does not
offer adequate facilities for any of the "software production" issues.
While some may look forward to a time when Euphoria
includes/accomodates most of these things, I don't. I hope it stays
small, focused, and relatively unpopular (but, of course, becomes or
remains a profitable enterprise for Robert, Junko, David C. and a few
others). There are already plenty of "Boeing 747 Jumbo Stretch Jet"
languages around (most of which started as Jeeps). I need the Jeep.
Having read the newslist for a while now, I realize that the foregoing
sentiments are not necessarily shared by everyone. None of my remarks
are meant to be critical of, or discouraging to, anyone on the list. I
greatly appreciate and admire the contributions of the list members,
including some things I personally would never have bothered to do, but
am happy be able to use. I hope that in the future, I may be able to add
a few small things to the pool. Unfortunately,
at the moment I'm pretty tied in the complexities of a "747 Stretch
Jumbo" installation, and the impending collapse of my employer due to
its insistence on following the "Bigger is better, so we can't make a
living until we rule the world" model.
|
Not Categorized, Please Help
|
|
