Dear Everyone,
I need your help. Basically, this is a call-for-papers on Information
Technology and the [human] organizational decision making process. It
surrounds the interpretation of symbols. I keep on having disagreements
with people on the meaning of the phrase Mission Critical. I just want
to point out that it is not to be confused with Critical Condition. I
am organizing my points which must be in english not techno-babble. I
will attempt to argue that lambda calculus will save your life.
So far I think this, but maybe it is just a gut feeling:
The runtime performance of software will directly affect human
organizational performance over the lifetime of the 'program'. By
'program', I mean the human system which the software is there to
assist, as well as the code itself. (Try thinking in 10 year chunks)
I believe that lambda calculus is an extremely valuable tool.
If I am wrong on any one of these points just tell me and I will attempt
to correct myself, I am not here to argue.
I loaned my book with formal definitions of lambda calculus to a friend.
Lambda calculus offers the software (code) the ability to be completely
(possibly 100%) dynamically linked at runtime. Most algorithms probably
do not require 100% dynamicity. However, the person who knows how to
interpret the algorithm should be the judge of the interpretation of
those symbols and not necessarily your vendor.
Things you can get (from lambda calculus and from quality in general):
Dynamic memory access and management. Memory refers just as much to the
'humans' memory as the silicon in that last sentence.
Lexical binding & runtime function dispatch.
Ability to run two dissimilar applications in the same memory space when
necessary. (no artificial interface protocol required)
As simple as these things sound, I believe that they are essential. (It
is less work, and can give you more room for improvement. Think about
what that can do for your organization over a 15 year period.)
Imagine you are traveling at 160mph, with 11 Beamers behind you at 2
foot intervals. [6 inch?] It is nighttime, slightly raining.
Headlights are on high beam for safety. Suddenly a deer walks on to the
road in front of you. It looks directly at you and freezes.
Are we going to blue screen? Where is your debugger then?
1-800-GET-HELP ?
If you are lucky, your debugger was built by somebody who knows how
lambda calculus with affect the end result of an expensive long term
engineering project.
You must have flexibility built into your design.
John McCarthy and Alonzo Church come to mind for some ghostbusters to
call.
Alpha and beta reductions seem like something familiar.
I will be snagging my book back from my friend.
Can we discuss this casually for the time being?
If some of the engineers I have met were the debuggers of this
situation, I believe the imaginary scenario would continue as follows:
The deer presence is signaled both by the road and by the vehicle.
Distributed Scheduler is made aware. Anti-lock breaks are applied
simultaneously for all 12 vehicles. (thanks to your vehicle maintenance
program) You reach 20 mph, horns are sound, lights flashed, deer jumps
off the road. Highway department receives email to check for a break in
the fence, Game Warden is notified. Cars accelerates synchronously to
160, schedules adapt to the event, and it is another day at the office
for night crew.
Success is in your organizational efficiency and not necessarily one
particular component. Design engineers should pamper efficiency,
despite the fact that they don't want to share shit and prefer their
holy paycheck. Is Lambda Calculus a false icon of efficiency?
I want to be friends with Erik Naggum. (I am not sure if friendship
rules out fist fighting, certainly not with pads, at least)
It's because Naggum.no that you do not mess with high energy
transportation systems. (and he speaks english)
I was hoping that Erik and Kent and Friends could help me write english
(right here on c.l.l.), I have a lisp.
(no, this is not a homework assignment)
Thanks,
Andrew K. Wolven
* Andrew K Wolven wrote:
> If you are lucky, your debugger was built by somebody who knows how
> lambda calculus with affect the end result of an expensive long term
> engineering project. You must have flexibility built into your
> design. John McCarthy and Alonzo Church come to mind for some
> ghostbusters to call. Alpha and beta reductions seem like something
> familiar. I will be snagging my book back from my friend. Can we
> discuss this casually for the time being?
I said this about some previous posting from this `person' that it was
obviously a machine. It *must* be mustn't it?
--tim
damn straight.
Tim Bradshaw wrote:
> * Andrew K Wolven wrote:
>
> > If you are lucky, your debugger was built by somebody who knows how
> > lambda calculus with affect the end result of an expensive long term
> > engineering project. You must have flexibility built into your
> > design. John McCarthy and Alonzo Church come to mind for some
> > ghostbusters to call. Alpha and beta reductions seem like something
> > familiar. I will be snagging my book back from my friend. Can we
> > discuss this casually for the time being?
>
> I said this about some previous posting from this `person' that it was
> obviously a machine. It *must* be mustn't it?
>
> --tim
* "Tim" == Tim Bradshaw <ยทยทยท@cley.com> writes:
* Andrew K Wolven wrote:
>> If you are lucky, your debugger was built by somebody who knows how
>> lambda calculus with affect the end result of an expensive long
>> term engineering project. You must have flexibility built into
>> your design. John McCarthy and Alonzo Church come to mind for some
>> ghostbusters to call. Alpha and beta reductions seem like
>> something familiar. I will be snagging my book back from my
>> friend. Can we discuss this casually for the time being?
Tim> I said this about some previous posting from this `person' that
Tim> it was obviously a machine. It *must* be mustn't it?
That's what I thought as well when reading the post. Each separate
sentence is pretty meaningful, and many of them are somewhat related,
but it's hard to get the idea behind the post.
If he really is a machine, how it was done? Markov chains? I've seen
some texts done this way, but this one looks more coherent.
--
Eugene
P.S. BTW, it can be a good candidate for next Loebner Prize contest...
Okay Everyone,
I see that you all are trying to tell me that I am a terrible
netconversationalist.
I will try to narrow the topic down some, since this is a contest about
nitty gritty details.
Can anyone tell me where to find a guy named Eric Buckman, who may have been
at Lockheed Aeronautical Systems in 1988?
I want to ask him if he does consulting, and if so, what is his fee.
(I will continue to scan the net, however my modem is quite slow.)
Your Bot,
Andrew K. Wolven