Re: Consistent "macro" Language
- From: spinoza1111@xxxxxxxxx
- Date: 28 May 2005 07:05:14 -0700
Hmm, implementing a macro language is one of those areas wherein the
implementors often feel themselves innocent of constraint and can
invent their own paradigm for a compiler and an interpreter which is
sorta what a macro language is...which provides a simplifying paradigm
at the cost of that sort of thought which is miscalled complexity but
remains *gedanken*.
Thus, in reflecting on what it means to learn and follow commands they
reflect in an American, or American influenced, culture on a Taylorist
paradigm in which the ideal is that the macro follower will repeat a
small and "simple" set of commands mindlessly.
With the result that the macro follower's state becomes snarfy after a
couple of macros have been executed and the macro follower has to be
reset which corresponds to beating the employee.
Barbarism is preserved to the extent that to make the macro processor
at all useful, you have to purge it of memory, which implies that it
cannot learn from experience.
A macro processor which is innocent of block structure, which Learns a
sequence of user commands and then "repeats" them, is a "simple"
product exclusively from the narcissistic viewpoint of the programmer
who is correspondingly innocent, in a faux-naif manner, of several
generations of misery caused by ignorance of block structure and
runtime semantics.
Consider the fetishized simplicity of selecting a word in Word and
retyping over it. What if the word is not there? What if the document
is noty there? Not only do macros written in an oversimplified language
change state from one run to the next they each have expectations as to
the initial state.
Programmer "simplicity" is visited on the user, who performs actions
which of course change state on his computer in such a way that what
was supposed to be simple and repeatable is instead a carnival as
underlying entities respond in unplanned ways.
Financial systems become unauditable, unwalkable throughable because at
the critical point, an analyst from Wharton uses Excel to give himself
a fat raise.
This, in addition to the fact that macros allow bozos to create
viruses, gives macro writing and usage a bad name.
"Conditional and looping" commands are regarded in this model as
supplementary and in some undefined way parasitic as in the relation of
writing and speech, as seen in Derrida. "All the user wants" is the
ability to repeat a list of commands. "All the user wants" is a
buzzing, hissing heap of damaged data as a sort of electronic
punishment for being, in effect, and in the minds of "professional"
programmers, a Sophist, a script kiddie who has tried, innocently
enough, to use a computer for its central purpose of instruction
following, and saving us toilers from toil.
I mean, does anybody even remember the fact that computers were going
to give us the Life of Riley, a two hour day where like George Jetson
we zip to the office, speak a macro name to the computer, and zip home?
"Speech recognition" is intimately tied to macro processing, but the
speech recognizing honchos all took physics in place of Compilers for
Boneheads 101.
Early assembler writers on the first mainframes actually found that an
assembly language macro processor needed assembly time processing but
this knowledge died a quiet death along with the C preprocessor which
was a horror because not Turing complete, and which is blamed by C++
programmers for global warming and Sep 11. This, and the disaster that
was PL/I's noble attempt to allow you to use PL/I at compile time,
causes software managers to empurple when a single preprocessor
expression is used in code.
User-programmable macros would give us freedom from toil,whether in
work outside of software creation or inside, but a sort of death wish
curses the user with macros that don't macro worth a damn.
Therefore I propose that it's irresponsible to implement a macro
language that is less than Turing complete and furthermore does not
provided stack semantics with explicit or implicit block structure, as
well as strong types, while at the same time supporting the responsible
creation and use of same.
The compiler and interpreter in my <shamelessPlug> book Build Your Own
..Net Language and Compiler </shamelessPlug> show that even QuickBasic,
since it benefited in the 1980s from the 1970s realization that
implicit block structure is absolutely necessary, and at least allows
strong typing, is one such product.
It as a .Net engine emits events when it encounters QB output
statesments and these events can drive a macro processor while
providing it with conditional capability. At the same time, Input
events can be used to sense the environment and avoid snarfiness.
Otherwise what you goin get goin be America's Funniest Home Macros,
which aren't funny when they wipe out your data.
Perhaps through my own laziness, I have never discovered a way to use
macros to automate general Windows tasks, while I occasionally record
simple macros inside Word and Excel. Whereas on the vastly more simple
timesharing systems of the mainframe we had Rexx which was a block
structured language coded originally nights and weekends by IBM Fellow
Mike Cowlishaw.
On the mainframe, we didn't have a mouse which is hard to "serialize",
perhaps, as a sequence of commands. "Go there": where? There is no
there, there since the window done gone missing. To be adequate to the
world of Windows, the macro processor would have to be able to describe
complex objects as they appear to the end user and in the way the end
user thinks of them.
Which means an adequate Windows macro language would be
object-oriented, a frightening thought. But perhaps Ruby is a
candidate.
mwmiller314@xxxxxxxxx wrote:
> In the somewhat recent past I downloaded the program "Quick Macros"
> from the site download.com. The program has allowed me to fashion a
> number of "macros" to execute sequences of user actions from within an
> MS Windows environment.
>
> However, it has become more noticable with increasing use that Quick
> Macros 1.x,the freely distributed version with no trial use expiration,
> often ceases to function and must be restarted in order to be relied on
> to function again. For instance, I have written a macro to reposition
> the mouse cursor to an often handy position, but when entering the
> keyboard shortcut to activate the macro, no action follows.
>
> Is there a "macro" language/platform that functions without these
> interruptions?
>
> (Also I would be interested in hearing from others that have found
> "macros" of their own or others' creation handy. I use them to
> navigate yahoo chat amoung other uses.)
.
- References:
- Consistent "macro" Language
- From: mwmiller314
- Consistent "macro" Language
- Prev by Date: Re: How to name variables in a program?
- Next by Date: Re: Advice for mid-life career change (to programming)
- Previous by thread: Consistent "macro" Language
- Next by thread: Can anyone post JMF VoIP examples?
- Index(es):
Relevant Pages
|
