[10180] in Perl-Users-Digest
Perl-Users Digest, Issue: 3773 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Sep 21 03:07:15 1998
Date: Mon, 21 Sep 98 00:01:35 -0700
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Mon, 21 Sep 1998 Volume: 8 Number: 3773
Today's topics:
Re: Perl & Java - differences and uses (Sam Holden)
Re: Perl & Java - differences and uses <uri@sysarch.com>
Re: Perl & Java - differences and uses <borg@imaginary.com>
Re: Perl & Java - differences and uses <borg@imaginary.com>
Re: Perl & Java - differences and uses <borg@imaginary.com>
Re: Perl & Java - differences and uses <pats@acm.org>
Re: Perl & Java - differences and uses (Sam Holden)
Re: Perl & Java - differences and uses <borg@imaginary.com>
Re: script: scriptMangle! (Craig Berry)
Special: Digest Administrivia (Last modified: 12 Mar 98 (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 21 Sep 1998 05:06:48 GMT
From: sholden@pgrad.cs.usyd.edu.au (Sam Holden)
Subject: Re: Perl & Java - differences and uses
Message-Id: <slrn70bnn7.8io.sholden@pgrad.cs.usyd.edu.au>
On Mon, 21 Sep 1998 02:49:45 GMT, George Reese <borg@imaginary.com> wrote:
>In comp.lang.java.programmer Sam Holden <sholden@pgrad.cs.usyd.edu.au> wrote:
>: Which part of term algorithm do you not understand???
>
>None. Appearantly, I understand it much better than you. And Knuth
>was wrong, or he was specifically talking about algorithms in computer
>science. Since your quotes are taken out of context, I do not know
>which is true.
Silly me I thought a discussion in comp.lang.* would be using the definition
for algorithm as used in computer science - standard scoping rules...
>
>Let's take some examples:
>
>: 'An algorithm is a set of rules for getting a specific output from a specific
>: input. Each step must be so precisely defined that it can be translated into a
>: computer language and executed by a machine.'
>: -- Donald E. Knuth
>
>Isn't this begging the question? If we define an alogorithm as
>something a machine can do, we have not really said anything useful.
>Isn't an algorithm really a tool for reaching a goal? Why is it
>important that a machine must be one of the things that goal?
>
>: 'The distinguishing feature of an algorithm is that all vagueness must be
>: eliminated; the rules must describe operations that are so simple and so well
>: defined that they can be executed by a machine.'
>: -- Donald E. Knuth
>
>Why?
If an algorithm is not defined with enough precision then it would be
interpreted differently by different people and thus be useless as a means
of describing a way to acieve a certain result. Your underlying mindlessness
below and substrate neutrality by using saying it must work with the
simplest tool and thus all tools.
>
>[ some other quotes deleted ]
>
>: 'Sort this by using comparison operations' is a vague description.
>
>Yes, it is. This is certainly not an algorithm. An algorithm exists
>to yield a certain result. You have not even stated what sort of
>result you wish to achieve.
>
>: 'Sort this using merge sort' is a vague description, unless a 'set of rules'
>: in which 'each step must be so precisely defined that it can be translated
>: into a computer language and executed by a machine' exists and is labelled
>: 'merge sort' - in which case the statement is an algorithm
>
>That you have provided an example of something that is most definitely
>not an algorithm does not mean that all algorithms are performable by
>computers.
>
>A little history lesson for you. The word algorithm comes from the
>Persian mathematician M{usb al-Khowbrizm. The idea of the algorithm
>as we understand the term today comes from the works of Turing, Gvdel,
>and Church. An algorithm has three key features:
>* substrate neutrality
>* underlying mindlessness
>* guaranteed results
I do actually read books every so often and did actually know this, and also
that the Babylonian's where writting programs for numerical problems around
1800BC which is significantly earlier....
And that his name had a : "Abu 'Abd Allah Muhammad ibn" on the front ( I
can't do the funky characters with this editor (well I probably can, I just
haven't learnt how, since I use a different editor most of the time)).
But that's enough of 'my mum can beat up your mum' for me...
The difference between the algorithms of the Babylonians and Persian, and
what we use the term for now is that their's were concerned only with
numerical calculation, now we are concerned with symbolic manipulation, in
the future they'll be concerned with something else...
>
>Substrate neutrality means the process works well using a pencil, pen,
>computer, etc. The power of the algorithm is due to its logical structure.
Exactly and the reason for adding the executed by a machine bit to the
definition... To be executed by a machine means everything must be defined
to such a great level of detail (which we then abstract away - after proving
it works of course).
Computers are the weakest of those tools, anything that can be done with
a computer can be done with a pencil. Everything that can be done with
a pencil can not be done with a computer however...
If I describe something in English with great precision a person with
a pencil can probably do it. A computer probably could not. If I
describe the same thing in some formal language then the person with a
pencil can probably do it and the computer probably could too.
>
>Underlying mindlessness means that each step must be simple. It
>should not require wise decisions.
Again saying it must be able to be computed by a machine enforced this.
>
>Guaranteed results means that whatever the algorithm does, it should
>always provide the same results.
Otherwise it would not be particularly useful... ;)
>
>Now, certainly OO methodologies do violate the second criteria. But
>they do isolate the "wise decisions" required of the process to early
>in the process. The result is a sert of UML documentation that does
>remove the need for wise decisions on the part of programmers in the
>development process. The problem we have in translating this
>algorithm for building applications lies in translating business rules
>into something that would make sense to a computer. But we can get
>them simple enough so that novice programmers can work with them,
>given a properly structured language.
But each programmer would do something slightly different so as an algorithm,
it is not valid.
The programmers still need to make many wise decisions. Implementation
details such as the name of loop counter variables tend not to be in the
UML docs, but are extremely important for the maintenance of the product.
Whether to use a linear or binary search may not be stated in the docs but
be of the utmost importance to the final product...
A bad programmer might when given the docs and the implementation language
of python implement it by writing perl code and wrapping the perl script
in a python object which still implements the specified interface... Now that
would be an unwise decision by the programmer but since the programmer
doesn't have to make wise decision is that OK? I think not.
--
Sam
Perl was designed to be a mess (though in the nicest of possible ways).
--Larry Wall
------------------------------
Date: 21 Sep 1998 01:15:02 -0400
From: Uri Guttman <uri@sysarch.com>
Subject: Re: Perl & Java - differences and uses
Message-Id: <x7af3uvyg9.fsf@sysarch.com>
>>>>> "f" == fsg <fsg@ultranet.com> writes:
f> Our man George Reese browbeats:
>> The freedom you talk about is why software engineering is such a
>> voodoo practice that results in gobs of absolute crap being
>> produced.
f> George, your schtick was briefly amusing in the sophomore-learns-a
f> new-language-and-decides-its-the-bestest-ever kind of way, but
f> these repetitious assertions of categorical fact and incoherent,
f> raving evangelism are making you out as a dolt in front of millions
f> of your potential employers and coworkers.
hear! hear!
>> Algorithms should be the result of proven design patterns.
f> Once you actually begin to design algorithms in the real world, you
f> will find out that this sentence, beyond just not making any kind
f> of sense at all, is purest levity.
of course you can design OO for speed! :-) i can't wait for an OO rtos
project! wince and com anyone? too painful to contemplate!
>> Otherwise, you are just talking voodoo.
f> If 99% of the world is held together by voodoo -- which it is,
f> considering what's running your car, your microwave, your computer,
f> your routers, your electronic musical instruments, your thermostat,
f> and your utilities -- then maybe you should give voodoo a little
f> respect.
now, go do that voodoo that you do so well!! (hedly lamarr in blazing saddles)
f> I think we can forgive Uri that -- after all, you clearly don't
f> know what it is to be a programmer.
i don't need forgiveness. but i appreciate the thought. i stand by my
writings about freedom, creativity and georgie's one size fits all mentality.
f> And you need to stop learning from books and try to make money out
f> here in the asynchronous sixty-way in-the-dark firefight we
f> professional hackers call 'trying to make a living writing
f> software'. We look forward to competing with you. Not to be too
f> cruel, but at this point, I'd take 1 Ari over 30 George Reeses.
^^^
i normally don't correct typos but my name is uri. and thanx for the
compliment, but i think you got the ratio a little too low! maybe
300 george drones to 1 me :-)
OO will be passed over by the next big thing to make programmers into
drones. we are not borg and we will not be assimilated. programming is
a human art and will always remain so as long as humans and art remain.
and OO is not programming but another method to design programs. again
human art is involved so it can't be formalized.
what if you have a problem space (like servers) but the analyst knows
only financial cobol design? can he apply your precious OO methods and
braqk down the problem into objects with a nice api? the human must know
the problem space so it is a human art form to break it down. the method
has no benefits there. and as someone else said, two humans with the same
methods will generate two different OO systems. big win there!
uri
--
Uri Guttman ----------------- SYStems ARCHitecture and Software Engineering
Perl Hacker for Hire ---------------------- Perl, Internet, UNIX Consulting
uri@sysarch.com ------------------------------------ http://www.sysarch.com
The Best Search Engine on the Net ------------- http://www.northernlight.com
------------------------------
Date: Mon, 21 Sep 1998 00:28:37 -0500
From: "George Reese" <borg@imaginary.com>
Subject: Re: Perl & Java - differences and uses
Message-Id: <bulN1.1090$Ge.3312073@ptah.visi.com>
Uri Guttman wrote in message ...
>>>>>> "GR" == George Reese <borg@imaginary.com> writes:
> GR> Jesus Christ, I posted a hastily drawn together set of steps which
> GR> clearly were not an algorithm (not even by the definition I posted)
> GR> and you take it as an opportunity to make a personal attack on me.
>
> GR> You have personal issues to address and probably should not be seen
in
> GR> public.
>
>you claimed it was an algorithm, not me. you stated it was a repeatable
>set of instructions which would generate the same results. yet there was
>much human decision making in your "algorithm". so i punched a hole in
>your logic.
Actually, Patricia punched a hole in my logic--a fact I immediately
acknowledged as being contrary to the definition of algorithm I provided.
All you have done is be a flaming asswipe.
>OO is a methodlogy which is a human oriented aspect of software, not an
>algorithm. breaking a problem down to components (objects or whatever)
>is a highly creative process that cannot be made into an algorithm. the
>overall path may be listed in an algorithmic style but the details are
>always left to humans to decide.
>
>and yes i am fit to be in public. just not near OO types. i go postal
>with their blather and bad designs. how many OO projects really left
>around reusable object for another project. i am not refering to modules
>specifically designed to be used by more than one project. i mean
>modules of a single project that were reused as is. most are too tightly
>ties to the main idea of the project since their designers had that in
>mind and the methodology doesn't give them the freedom to think outisde
>the box. a module could have a different api and make it more shareable
>but that is not allowed if it doesn't fit into the design of this
>project.
Your failure to understand what OO software engineering is does not condemn
the paradigm.
--
George Reese (borg@imaginary.com) http://www.imaginary.com/~borg
PGP Key: http://www.imaginary.com/servlet/Finger?user=borg&verbose=yes
"Keep Ted Turner and his goddamned Crayolas away from my movie"
-Orson Welles
------------------------------
Date: Mon, 21 Sep 1998 00:44:21 -0500
From: "George Reese" <borg@imaginary.com>
Subject: Re: Perl & Java - differences and uses
Message-Id: <WIlN1.1093$Ge.3318860@ptah.visi.com>
Sam Holden wrote in message ...
>On Mon, 21 Sep 1998 02:49:45 GMT, George Reese <borg@imaginary.com> wrote:
>>In comp.lang.java.programmer Sam Holden <sholden@pgrad.cs.usyd.edu.au>
wrote:
>>: Which part of term algorithm do you not understand???
>>
>>None. Appearantly, I understand it much better than you. And Knuth
>>was wrong, or he was specifically talking about algorithms in computer
>>science. Since your quotes are taken out of context, I do not know
>>which is true.
>
>Silly me I thought a discussion in comp.lang.* would be using the
definition
>for algorithm as used in computer science - standard scoping rules...
Silly you indeed. Since I was specifically stating that algorithms had a
place outside of programming languages, such a narrow definition is quite
clearly not what I have in mind.
>>
>>Let's take some examples:
>>
>>: 'An algorithm is a set of rules for getting a specific output from a
specific
>>: input. Each step must be so precisely defined that it can be translated
into a
>>: computer language and executed by a machine.'
>>: -- Donald E. Knuth
>>
>>Isn't this begging the question? If we define an alogorithm as
>>something a machine can do, we have not really said anything useful.
>>Isn't an algorithm really a tool for reaching a goal? Why is it
>>important that a machine must be one of the things that goal?
>>
>>: 'The distinguishing feature of an algorithm is that all vagueness must
be
>>: eliminated; the rules must describe operations that are so simple and so
well
>>: defined that they can be executed by a machine.'
>>: -- Donald E. Knuth
>>
>>Why?
>
>If an algorithm is not defined with enough precision then it would be
>interpreted differently by different people and thus be useless as a means
>of describing a way to acieve a certain result. Your underlying
mindlessness
>below and substrate neutrality by using saying it must work with the
>simplest tool and thus all tools.
That is not at all true. Part of being an algorithm is that intermediate
steps may be indeterminate so long as they will still guarantee the final
results. Again, long division is an excellent example of such an algorithm.
And by your arguments, a computer program is not an algorithm is since it is
something that cannot be done with hammers, knives, and screws.
There is some level of fitness to the task that the substrate must have.
>>
>>Substrate neutrality means the process works well using a pencil, pen,
>>computer, etc. The power of the algorithm is due to its logical
structure.
>
>Exactly and the reason for adding the executed by a machine bit to the
>definition... To be executed by a machine means everything must be defined
>to such a great level of detail (which we then abstract away - after
proving
>it works of course).
>Computers are the weakest of those tools, anything that can be done with
>a computer can be done with a pencil. Everything that can be done with
>a pencil can not be done with a computer however...
>If I describe something in English with great precision a person with
>a pencil can probably do it. A computer probably could not. If I
>describe the same thing in some formal language then the person with a
>pencil can probably do it and the computer probably could too.
I would agree with all of that. That does not imply, however, that a
computer is the sole definer of a valid algorithm. Specifically, it may not
be capable of handling certain logical forms due to sheer lack of processing
power or lack of expressiveness in terms of computer languages.
>>Now, certainly OO methodologies do violate the second criteria. But
>>they do isolate the "wise decisions" required of the process to early
>>in the process. The result is a sert of UML documentation that does
>>remove the need for wise decisions on the part of programmers in the
>>development process. The problem we have in translating this
>>algorithm for building applications lies in translating business rules
>>into something that would make sense to a computer. But we can get
>>them simple enough so that novice programmers can work with them,
>>given a properly structured language.
>
>But each programmer would do something slightly different so as an
algorithm,
>it is not valid.
No, that each programmer does different things does NOT make it not an
algorithm. The results need to be the same, not the intermediate steps.
>The programmers still need to make many wise decisions. Implementation
>details such as the name of loop counter variables tend not to be in the
>UML docs, but are extremely important for the maintenance of the product.
>Whether to use a linear or binary search may not be stated in the docs but
>be of the utmost importance to the final product...
Yes, but you are interpreting my claim way too strong and in a way I clearly
have stated is not the case. Quoting from above:
"Now, certainly OO methodologies do violate the second criteria. "
Meaning, I do not think an OO methodology is an algorithm in any strong
sense.
I do think it isolates wise decisions in most cases, and dumbs down the wise
decisions in other places.
>A bad programmer might when given the docs and the implementation language
>of python implement it by writing perl code and wrapping the perl script
>in a python object which still implements the specified interface... Now
that
>would be an unwise decision by the programmer but since the programmer
>doesn't have to make wise decision is that OK? I think not.
I don't think you could argue this is following the documentation since part
of the documentation will be implementation details like the language is
python and so on.
--
George Reese (borg@imaginary.com) http://www.imaginary.com/~borg
PGP Key: http://www.imaginary.com/servlet/Finger?user=borg&verbose=yes
"Keep Ted Turner and his goddamned Crayolas away from my movie"
-Orson Welles
------------------------------
Date: Mon, 21 Sep 1998 01:14:37 -0500
From: "George Reese" <borg@imaginary.com>
Subject: Re: Perl & Java - differences and uses
Message-Id: <i9mN1.1100$Ge.3331787@ptah.visi.com>
Andrew Johnson wrote in message <3605CE4A.6BD6BF3C@gpu.srv.ualberta.ca>...
>George Reese wrote:
>!
>[snip]
>
>! * In order to get quality software, you need a method of guaranteeing
>! results given a problem.
>
>do you? ...you need to be a great deal more specific if you wish your
>sweeping statements to be taken as any kind of premise while building
>an argument...
You have done nothing here to suggest my statement is sweeping other than
state it is sweeping. I probably should have used 'guaranntee' instead of
'get', but that is a small technical difference and not worthy of your
blanket condemnation.
>! * If you want to guarantee results, you need to be able to reduce a
>! process to a replicatable algorithm.
>
>do you? again, specificity is lacking here: what results? what
>process? --- and aren't all algorithms replicable?
Results being the production of software.
>! * OO is the closest thing to a replicatable algorithm we have in
>! software engineering today.
>
>OO is an algorithm? I thought you said it was a methodology --- do two
>people with equal OO skill in an OO language produce the same
>solutions to any given problem? (or might they be 'free' to choose
>different but equally good (or bad) OO implementations of a solution
>to a problem?) ---
No, I said it was the closest thing to an algorithm.
There is a difference.
>If you are trying to say that OO development is (or is approaching)
>being an algorithm for software engineering, you should recall your
>own mention of the properties of algorithms in another post:
Note that approaching does not require strict adherence to that definition.
>!> * substrate neutrality
>!> * underlying mindlessness
>!> * guaranteed results
>!>
>!> Substrate neutrality means the process works well using a pencil, pen,
>!> computer, etc. The power of the algorithm is due to its logical
structure.
>
>part of substrate neutrality is language neutrality...
Not in the least bit. I challenge you to describe a piece of software to me
in meows or Klingon.
>!> Underlying mindlessness means that each step must be simple. It
>!> should not require wise decisions.
>!>
>!> Guaranteed results means that whatever the algorithm does, it should
>!> always provide the same results.
>
>if you are calling OO an algorithm, what 'same results' can we expect?
>everyone writes identical code? or merely that everyone writes OO code?
No, that everyone will write code that passes the proper tests for the
system in question--i.e. does what the design prescribes.
>And besides, if X is the closest thing to Y we have, this does not
>confer upon X any of the necessary or sufficient properties of Y,
>in particular, if Y is known to be reliable, the statement that X is
>close to Y cannot be used to draw inferences on X's reliability ...
>such properties of X must be demonstrated on their own.
If Y is known to be reliable and X is known to exhibit many of the
properties that make Y reliable, it is a valid inference to say that X is
likely to be mostly reliable. It is certainly one worthy of testing.
>! * OO does sometimes incur performance costs and thus the predticability
>! of the process is sometimes offset by these performance costs.
>!
>! * Most software engineering tasks do not encounter a requirement for
>! the the level of performance cost by OO software engineering.
>!
>! - Therefore, it is the best solution for any software engineering task
>! where the side effects
>
>aside from the apparently dangling sentence in your conclusion,
I screwed up in the editor. It should have said:
"Therefore, it is the best solution for most software engineering tasks."
> none of
>your premises or statements logically lead to your conclusion that
>OO is 'the best solution' for anything...indeed, they do not lead
>(as given) to any sort of conclusion about OO whatsoever...
Yes, they do.
>! Now, if that is not a reasoned belief, I do not know what is.
>
>apparently so.
Nice personal attack there.
--
George Reese (borg@imaginary.com) http://www.imaginary.com/~borg
PGP Key: http://www.imaginary.com/servlet/Finger?user=borg&verbose=yes
"Keep Ted Turner and his goddamned Crayolas away from my movie"
-Orson Welles
------------------------------
Date: 20 Sep 1998 23:16:44 PDT
From: Patricia Shanahan <pats@acm.org>
Subject: Re: Perl & Java - differences and uses
Message-Id: <3605EEDB.82E0187C@acm.org>
Sam Holden wrote:
>
> On Mon, 21 Sep 1998 02:49:45 GMT, George Reese <borg@imaginary.com> wrote:
> >In comp.lang.java.programmer Sam Holden <sholden@pgrad.cs.usyd.edu.au> wrote:
> >: Which part of term algorithm do you not understand???
> >
> >None. Appearantly, I understand it much better than you. And Knuth
> >was wrong, or he was specifically talking about algorithms in computer
> >science. Since your quotes are taken out of context, I do not know
> >which is true.
>
> Silly me I thought a discussion in comp.lang.* would be using the definition
> for algorithm as used in computer science - standard scoping rules...
...
I think to avoid the logical fallacy of "begging the question" in the
context of a discussion of whether all algorithms can be evaluated by
computer one should assume the more general definition. It still isn't
an algorithm, as George agrees.
Patricia
------------------------------
Date: 21 Sep 1998 06:19:14 GMT
From: sholden@pgrad.cs.usyd.edu.au (Sam Holden)
Subject: Re: Perl & Java - differences and uses
Message-Id: <slrn70brv2.blh.sholden@pgrad.cs.usyd.edu.au>
On Mon, 21 Sep 1998 00:44:21 -0500, George Reese <borg@imaginary.com> wrote:
>
>Sam Holden wrote in message ...
>>On Mon, 21 Sep 1998 02:49:45 GMT, George Reese <borg@imaginary.com> wrote:
>>>In comp.lang.java.programmer Sam Holden <sholden@pgrad.cs.usyd.edu.au>
>wrote:
>>>: Which part of term algorithm do you not understand???
>>>
>>>None. Appearantly, I understand it much better than you. And Knuth
>>>was wrong, or he was specifically talking about algorithms in computer
>>>science. Since your quotes are taken out of context, I do not know
>>>which is true.
>>
>>Silly me I thought a discussion in comp.lang.* would be using the
>definition
>>for algorithm as used in computer science - standard scoping rules...
>
>Silly you indeed. Since I was specifically stating that algorithms had a
>place outside of programming languages, such a narrow definition is quite
>clearly not what I have in mind.
Programming languages != computer science.
I thought you were still in the realms of computer science.
However, if you are going to say that something substrate neutral then it
better work with a computer as well...
>
>>>
>>>Let's take some examples:
>>>
>>>: 'An algorithm is a set of rules for getting a specific output from a
>specific
>>>: input. Each step must be so precisely defined that it can be translated
>into a
>>>: computer language and executed by a machine.'
>>>: -- Donald E. Knuth
>>>
>>>Isn't this begging the question? If we define an alogorithm as
>>>something a machine can do, we have not really said anything useful.
>>>Isn't an algorithm really a tool for reaching a goal? Why is it
>>>important that a machine must be one of the things that goal?
>>>
>>>: 'The distinguishing feature of an algorithm is that all vagueness must
>be
>>>: eliminated; the rules must describe operations that are so simple and so
>well
>>>: defined that they can be executed by a machine.'
>>>: -- Donald E. Knuth
>>>
>>>Why?
>>
>>If an algorithm is not defined with enough precision then it would be
>>interpreted differently by different people and thus be useless as a means
>>of describing a way to acieve a certain result. Your underlying
>mindlessness
>>below and substrate neutrality by using saying it must work with the
>>simplest tool and thus all tools.
>
>
>That is not at all true. Part of being an algorithm is that intermediate
>steps may be indeterminate so long as they will still guarantee the final
>results. Again, long division is an excellent example of such an algorithm.
>
>And by your arguments, a computer program is not an algorithm is since it is
>something that cannot be done with hammers, knives, and screws.
Anything a computer can do I can do with a hammer (assuming I have an infinitely
long peice of wood on which to leave marks to keep track of things - it would
just take a long time)
I guess I'm talking about calculating things, but you were one who referred
back to the Persians and thus that seems to be the topic. Symbol manipulation
of course makes calculating things very powerful.
>
>There is some level of fitness to the task that the substrate must have.
>
>>>
>>>Substrate neutrality means the process works well using a pencil, pen,
>>>computer, etc. The power of the algorithm is due to its logical
>structure.
>>
>>Exactly and the reason for adding the executed by a machine bit to the
>>definition... To be executed by a machine means everything must be defined
>>to such a great level of detail (which we then abstract away - after
>proving
>>it works of course).
>
>>Computers are the weakest of those tools, anything that can be done with
>>a computer can be done with a pencil. Everything that can be done with
>>a pencil can not be done with a computer however...
>
>>If I describe something in English with great precision a person with
>>a pencil can probably do it. A computer probably could not. If I
>>describe the same thing in some formal language then the person with a
>>pencil can probably do it and the computer probably could too.
>
>
>I would agree with all of that. That does not imply, however, that a
>computer is the sole definer of a valid algorithm. Specifically, it may not
>be capable of handling certain logical forms due to sheer lack of processing
>power or lack of expressiveness in terms of computer languages.
Processing power is not a limiting factor since there has been no restriction
on running time. If it takes a computer an order of magnitude or two longer
than the age of universe to complete an algorithm, then it is still an
algorithm.
Computer languages have the required level of expressive power. If it can't be
expressed then it is too vague - note it might be a real pain to express it,
it may require enumerating an extremely large number of definitions, but it
can be done.
I won't use any examples for anything since you seem to think they are the
basis of what I'm saying and not just a way to explain an abstract concept with
a real world example. (They are not evidence for anything they are an example
of how to apply what has been said - go and look at those Persian algorithms
you mentioned a while ago and see examples in action).
>
>
>>>Now, certainly OO methodologies do violate the second criteria. But
>>>they do isolate the "wise decisions" required of the process to early
>>>in the process. The result is a sert of UML documentation that does
>>>remove the need for wise decisions on the part of programmers in the
>>>development process. The problem we have in translating this
>>>algorithm for building applications lies in translating business rules
>>>into something that would make sense to a computer. But we can get
>>>them simple enough so that novice programmers can work with them,
>>>given a properly structured language.
>>
>>But each programmer would do something slightly different so as an
>algorithm,
>>it is not valid.
>
>
>No, that each programmer does different things does NOT make it not an
>algorithm. The results need to be the same, not the intermediate steps.
By slightly different I meant with slightly different final results, that
still meet a vague specification. These will usually surface on the boundary
conditions of a problem or in parts of the spec that were 'so obvious' that
they didn't need to set out in great detail.
>
>>The programmers still need to make many wise decisions. Implementation
>>details such as the name of loop counter variables tend not to be in the
>>UML docs, but are extremely important for the maintenance of the product.
>>Whether to use a linear or binary search may not be stated in the docs but
>>be of the utmost importance to the final product...
>
>
>Yes, but you are interpreting my claim way too strong and in a way I clearly
>have stated is not the case. Quoting from above:
>
>"Now, certainly OO methodologies do violate the second criteria. "
>
>Meaning, I do not think an OO methodology is an algorithm in any strong
>sense.
>I do think it isolates wise decisions in most cases, and dumbs down the wise
>decisions in other places.
>
>>A bad programmer might when given the docs and the implementation language
>>of python implement it by writing perl code and wrapping the perl script
>>in a python object which still implements the specified interface... Now
>that
>>would be an unwise decision by the programmer but since the programmer
>>doesn't have to make wise decision is that OK? I think not.
>
>
>I don't think you could argue this is following the documentation since part
>of the documentation will be implementation details like the language is
>python and so on.
But I could write Python code that just opens a pipe to perl, and prints
in perl code. Grabs the output and returns that. An unwise programmer could
argye it is in Python and thus meeting the spec. Said programmer would be
wrong of course, but knowing that requires a (very low) level of wisdom.
But the point is null anyway since I was giving a counter example to your
sweeping statement :
The result is a sert of UML documentation that does
remove the need for wise decisions on the part of programmers in the
development process.
Which you seem to have recanted above with
I do think it isolates wise decisions in most cases, and dumbs down the
wise decisions in other places.
--
Sam
Just don't create a file called -rf. :-)
--Larry Wall
------------------------------
Date: Mon, 21 Sep 1998 01:23:48 -0500
From: "George Reese" <borg@imaginary.com>
Subject: Re: Perl & Java - differences and uses
Message-Id: <WhmN1.1101$Ge.3336726@ptah.visi.com>
fsg wrote in message <3605A0F8.4CA9E00E@ultranet.com>...
>Our man George Reese browbeats:
>> The freedom you talk about is why software engineering is such a
>> voodoo practice that results in gobs of absolute crap being produced.
>
>George, your schtick was briefly amusing in the sophomore-learns-a
>new-language-and-decides-its-the-bestest-ever kind of way, but these
>repetitious assertions of categorical fact and incoherent, raving
>evangelism are making you out as a dolt in front of millions of your
>potential employers and coworkers.
Is a barrage of insults commonly accepted in comp.lang.perl.misc as a proper
form of argumentation? Trust me, perl programmers are not my potential
employers or coworkers.
>> Design and naming things should be the result of a repeatable and
>> structured process. That is what OO methodologies are.
>
>Besides one other person, I have traditionally been the most vocal
>standard-bearer on perl5-porters for 'OO methodologies' (sic).
Hmm. If the OO-ness of perl is any measure of your OO expertise, I do fear
greatly.
> But
>even I understood after my sophomore year that OO is not for
>everything. And you too will come to understand, one day, after
>your first meaningful software project, that there are all sorts of
>things a hell of a lot more important than ideological purity.
You and Uri just keep repeating the mantra that I think OO is for everything
in spite of the fact that I have repeatedly stated that is not the case.
And here you misrespresent my point view punctuated with an insult.
>> Formatting is a function of standard programming practices, or, better
>> yet, a well structured language like python.
>
>Python is a little less well structured than Perl, which is about
>what you'd expect from a subset of Perl.
Then you either don't know jack shit about python or you don't know jack
shit about structured programming. You are the only person I have ever
heard make this ridiculous claim. Even in this thread, no one has tried
that line of argumentation.
>> Algorithms should be the result of proven design patterns.
>
>Once you actually begin to design algorithms in the real world,
>you will find out that this sentence, beyond just not making any
>kind of sense at all, is purest levity.
You mean once I do what I have been doing for years, something I am a
recognized expert in? Damn!
>For a good real world example that you can study the source code
>for, try the perl5 regular expression code. It was not designed
>with 'design patterns' in mind -- in fact, it was invented more
>than a decade before 'design patterns' became the latest vogue --
>but it has survived numerous attempts to supplant it with
>replacements designed by 'OO methodologies' (sic). Why? Because
>cleanliness is not everything. In some cases, speed is
>everything. In others, functionality is everything. In still
>others, cost is everything. In my several years of real world
>software, I would guess that speed and cost have been my most
>usual requirements, followed by cleanliness and thence by
>functionality.
And this would be why I would not hire you.
>By the by, I'm also a major advocate of design patterns, have
>written articles, etc., etc. But it's just _funny_ to suggest
>that even a third of your code can be based on the current art.
Funny only if you do not understand anything about OO software engineering.
>> Otherwise, you are just talking voodoo.
>
>If 99% of the world is held together by voodoo -- which it is,
>considering what's running your car, your microwave, your
>computer, your routers, your electronic musical instruments,
>your thermostat, and your utilities -- then maybe you should
>give voodoo a little respect.
Those are small, isolated applications. Try moving into the world of more
complex applications.
>> : so don't say you don't need freedom when you must have it, you use it
and
>> : you don't even know it.
>>
>> You don't even know what freedom is.
>
>I think we can forgive Uri that -- after all, you clearly don't
>know what it is to be a programmer.
Another personal attack. At least when I stated Uri does not know what
freedom is, it came after showing where his use of the word was absurd. You
are just simply making attacks which, in this case, is clearly not backed up
the facts.
>> : get a clue about what programming really is. you obviously think you
>> : know it but you don't. it is not following some fixed set of rules to
>> : solve each problem the same way (no freedom, remember!).
>>
>> You need to go back and learn what a structured process is.
>
>And you need to stop learning from books and try to make money out here
>in the asynchronous sixty-way in-the-dark firefight we professional
>hackers call 'trying to make a living writing software'. We look
>forward to competing with you. Not to be too cruel, but at this
>point, I'd take 1 Ari over 30 George Reeses.
I make a very good living at writing software, thank you.
------------------------------
Date: 21 Sep 1998 06:16:27 GMT
From: cberry@cinenet.net (Craig Berry)
Subject: Re: script: scriptMangle!
Message-Id: <6u4qvr$e8l$1@marina.cinenet.net>
Chris Russo (news@russo.org) wrote:
: >Honestly, that wasn't and isn't my intention. I wish someone could tell
: >me why it's being taken that way!
:
: Your error is in assuming that you're in a rational discussion, based upon
: economics and logic.
:
: To the contrary, you're touching upon "Free Software", and it is a
: religious issue.
:
: So either be prepared to weather irrational chastisement, or keep your
: mouth shut, like I (normally) do.
I find myself forced into reluctant agreement with you. And here I'd
hoped to trade viewpoints and learn things. Silly me. Just discussions
of how to build an array of hashes of arrays from here on out for me...
---------------------------------------------------------------------
| Craig Berry - cberry@cinenet.net
--*-- Home Page: http://www.cinenet.net/users/cberry/home.html
| "Ripple in still water, when there is no pebble tossed,
nor wind to blow..."
------------------------------
Date: 12 Jul 98 21:33:47 GMT (Last modified)
From: Perl-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Special: Digest Administrivia (Last modified: 12 Mar 98)
Message-Id: <null>
Administrivia:
Special notice: in a few days, the new group comp.lang.perl.moderated
should be formed. I would rather not support two different groups, and I
know of no other plans to create a digested moderated group. This leaves
me with two options: 1) keep on with this group 2) change to the
moderated one.
If you have opinions on this, send them to
perl-users-request@ruby.oce.orst.edu.
The Perl-Users Digest is a retransmission of the USENET newsgroup
comp.lang.perl.misc. For subscription or unsubscription requests, send
the single line:
subscribe perl-users
or:
unsubscribe perl-users
to almanac@ruby.oce.orst.edu.
To submit articles to comp.lang.perl.misc (and this Digest), send your
article to perl-users@ruby.oce.orst.edu.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
To request back copies (available for a week or so), send your request
to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
where x is the volume number and y is the issue number.
The Meta-FAQ, an article containing information about the FAQ, is
available by requesting "send perl-users meta-faq". The real FAQ, as it
appeared last in the newsgroup, can be retrieved with the request "send
perl-users FAQ". Due to their sizes, neither the Meta-FAQ nor the FAQ
are included in the digest.
The "mini-FAQ", which is an updated version of the Meta-FAQ, is
available by requesting "send perl-users mini-faq". It appears twice
weekly in the group, but is not distributed in the digest.
For other requests pertaining to the digest, send mail to
perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
sending perl questions to the -request address, I don't have time to
answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V8 Issue 3773
**************************************
