[10178] in Perl-Users-Digest
Perl-Users Digest, Issue: 3771 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Sep 21 01:07:12 1998
Date: Sun, 20 Sep 98 22:00:13 -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 Sun, 20 Sep 1998 Volume: 8 Number: 3771
Today's topics:
Re: even/odd numbers (John Moreno)
Re: even/odd numbers <nguyend7@msu.edu>
Re: even/odd numbers <uri@sysarch.com>
Re: Number Sort (Sam Holden)
Re: Perl & Java - differences and uses <borg@imaginary.com>
Re: Perl & Java - differences and uses <borg@imaginary.com>
Re: Perl & Java - differences and uses (Sam Holden)
Re: Perl & Java - differences and uses <borg@imaginary.com>
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 (David Formosa)
Re: Perl & Java - differences and uses (David Formosa)
Re: Perl & Java - differences and uses <ajohnson@gpu.srv.ualberta.ca>
Re: Perl & Java - differences and uses <uri@sysarch.com>
Re: Perl & Java - differences and uses <fsg@ultranet.com>
Randal Schwartz in Dallas, Texas 10/3 (Brand Hilton)
Special: Digest Administrivia (Last modified: 12 Mar 98 (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 20 Sep 1998 23:02:05 -0500
From: phenix@interpath.com (John Moreno)
Subject: Re: even/odd numbers
Message-Id: <1dfocuz.1m2ywhu1rv3tn3N@roxboro0-032.dyn.interpath.net>
Josh Kortbein <kortbein@iastate.edu> wrote:
> John Moreno (phenix@interpath.com) wrote:
-snip-
>
> : "modulus" is of course the easiest and most straightforward way of
> : finding out, but it's hardly the only (although the most obvious way
> : would much simplier if perl had a div command like pascal).
>
> The original poster knew at least one other way of determining parity. He
> wanted some sort of builtin function for doing so, i.e. modulus.
I didn't get that impression at all - it looked to me like he was
looking for a algorithm for doing so.
>Which is not straightfoward to find out if you don't know what a
>modulus is.
True, but reading perlop would probably have fixed that problem (if that
was the problem).
--
John Moreno
------------------------------
Date: 21 Sep 1998 03:34:46 GMT
From: Dan Nguyen <nguyend7@msu.edu>
Subject: Re: even/odd numbers
Message-Id: <6u4hgm$9vc$1@msunews.cl.msu.edu>
John Moreno <phenix@interpath.com> wrote:
: "modulus" is of course the easiest and most straightforward way of
: finding out, but it's hardly the only (although the most obvious way
: would much simpler if perl had a div command like pascal).
I don't think that perl needs another operator like div.
You can do
{
use integer;
}
And then do your division. Doing something like
is_odd := num - ((num div 2) * 2); (*in pascal*)
is_even := ((num / 2) = (num div 2));
Isn't really very clear. I don't know if they still teach this in
grade school, but one has to think back to long division and
remainders. And once you realize that the modulus gives the remainder
it's not to far away. And I guess many people who read this group
think differently then the novice programmer, but that's because
taking the modulus function is the easiest way.
For example. In my 'C' class. They told us to do
ch ^= 0x20;
to change uppercase to lowercase and lowercase to uppercase. It's not
the clearest way to do something like that. But it is the easiest
and most efficient way of doing it.
-dan
--
Dan Nguyen | There is only one happiness in
nguyend7@msu.edu | life, to love and be loved.
http://www.cse.msu.edu/~nguyend7 | -George Sand
------------------------------
Date: 21 Sep 1998 00:01:44 -0400
From: Uri Guttman <uri@sysarch.com>
Subject: Re: even/odd numbers
Message-Id: <x7k92yw1uf.fsf@sysarch.com>
>>>>> "DN" == Dan Nguyen <nguyend7@msu.edu> writes:
DN> For example. In my 'C' class. They told us to do
DN> ch ^= 0x20;
DN> to change uppercase to lowercase and lowercase to uppercase. It's not
DN> the clearest way to do something like that. But it is the easiest
DN> and most efficient way of doing it.
and highly wrong today with unicode and other non-ascii char
sets. toupper() is clearer, should be just as fast for ascii and
portable.
perl's uc or \U are the same idea. they are clearer than tr/a-z/A-Z/ and
more protable.
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: 21 Sep 1998 03:04:26 GMT
From: sholden@pgrad.cs.usyd.edu.au (Sam Holden)
Subject: Re: Number Sort
Message-Id: <slrn70bghq.8io.sholden@pgrad.cs.usyd.edu.au>
On Mon, 21 Sep 1998 01:51:25 GMT, Garry T. Williams <garry@america.net> wrote:
>Larry Rosler wrote:
>>
>> [Posted to comp.lang.perl.misc and copy mailed.]
>>
>> In article <36057963.9A2CC13F@america.net> on Sun, 20 Sep 1998 21:52:27
>> GMT, Garry T. Williams <garry@america.net> says...
>> ...
>> > sub numerically {
>> > ($akey) = split(/\|/, $a);
>> > ($bkey) = split(/\|/, $b);
>> > $akey <=> $bkey;
>> > };
>> >
>> > @anarray = sort numerically @anarray;
>>
>> Slow, slow, slow! You want to minimize the amount of computation done in
>> the sort subroutine, which is executed O(n log n) times.
>>
>> For the more efficient approach, read the FAQ and the FMTYEWTK about
>> sorting to which it points. Once you get the hang of the Schwartzian
>> Transform, you can pour it out by rote:
>>
>> @anarray = map $_->[0] => sort { $a->[1] <=> $b->[1] }
>> map { [ $_, (split /\|/)[0] ] } @anarray;
>
>Yes, you're right. I read the FAQ on this long ago and only skimmed it
>at that. The sort operator calls the comparison block *each* time it
>needs a compare of two records (list elements). Although the number is
>not n log n, it's even bigger! (_The Perl Cookbook_ states that for
>1,000 elements, there will be 14,000 comparisons -- which is about 2n ln
>n. That means 28,000 split operations for 1,000 items in the original
>list!) My solution is far too slow as the number of elements in the
>list to be sorted increases.
Of course 2n ln n __is__ O(n log n)- but yes I guess perl's sort would use
qsort(3) or it's own quick sort routine, which is O(n*n) for worst case
O() anyway.
--
Sam
Perl was designed to be a mess (though in the nicest of possible ways).
--Larry Wall
------------------------------
Date: Mon, 21 Sep 1998 03:02:30 GMT
From: George Reese <borg@imaginary.com>
Subject: Re: Perl & Java - differences and uses
Message-Id: <aljN1.1061$Ge.3219069@ptah.visi.com>
In comp.lang.java.programmer Zenin <zenin@bawdycaste.org> wrote:
[ a whole diatribe of assertions that I am referencing gods and some
religion deleted ]
: George Reese <borg@imaginary.com> wrote:
: : It is a good rhetorical device to take a belief which I will affirm
: : (that OO is important) and then dismiss that belief as religious.
: The belief is not religious, only your blind faith it it is.
: : After all, a religious belief is one without reason behind it.
: Religion has quite a bit of reason behind it. Much of it is not
: logical however, which is what brings your comments to mind.
I just quoted this bit of your long slam at my statements as religious
because it beautifully illustrates that you don't have the first clue
as to what reason, logic, faith, and religion are.
Something that is illogical cannot be reasonable. Faith is belief
grounded on faith, not reason. Religions are world views whose
beliefs are grounded in faith.
I have shown rational arguments to backup OO software engineering as a
good paradigm for development in the large. I have not referenced any
authorities as some sort of argument from authority. I have simply
provided many, many reasons.
You may disagree with those reasons, but labeling my beliefs religious
is not only a sad and pathetic way of demonstrating that disagreement,
it is also quite obviously inaccaurate.
: : The world has not arrived at OO software engineering yet, so I fail to
: : see how you can dismiss it as failed.
: The world has not arrived at Esperanto or NewSpeek either.
: Of course OO has not failed. Nore however, has it given any reason
: to most people that it should replace everything else before it.
Everything? I have not seen anyone in this thread advocating it
replace everything. Most everything? The reason is simple.
* In order to get quality software, you need a method of guaranteeing
results given a problem.
* If you want to guarantee results, you need to be able to reduce a
process to a replicatable algorithm.
* OO is the closest thing to a replicatable algorithm we have in
software engineering today.
* 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
Now, if that is not a reasoned belief, I do not know what is.
--
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 03:04:46 GMT
From: George Reese <borg@imaginary.com>
Subject: Re: Perl & Java - differences and uses
Message-Id: <injN1.1062$Ge.3219069@ptah.visi.com>
In comp.lang.java.programmer Zenin <zenin@bawdycaste.org> wrote:
: George Reese <borg@imaginary.com> wrote:
: >snip<
: : Unfortunately, you have not in any way demonstrated that my belief in
: : OO lacks coherent reasoning.
: If OO is infact the end-all, be-all computer science methodology
: of choice, pray tell why is your beloved Python written in C?
Lovely straw man.
* I have never said that OO was proper for everything.
That Python was written in C does not imply that C was necessarily
the best tool for the job. In fact, I believe I have seen rather
lengthy lamentation of this fact in python forums.
--
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: 21 Sep 1998 03:08:27 GMT
From: sholden@pgrad.cs.usyd.edu.au (Sam Holden)
Subject: Re: Perl & Java - differences and uses
Message-Id: <slrn70bgpb.8io.sholden@pgrad.cs.usyd.edu.au>
On Mon, 21 Sep 1998 02:20:09 GMT, George Reese <borg@imaginary.com> wrote:
>In comp.lang.java.programmer Patricia Shanahan <pats@acm.org> wrote:
>: George Reese wrote:
>:>
>:> In comp.lang.java.programmer Patricia Shanahan <pats@acm.org> wrote:
>:> : In any case, those aspects of programming that have been reduced to
>:> : algorithms are not what programmers should be spending their time
>:> : doing. There is a natural progression:
>:>
>:> : 1. Algorithms are identified for doing aspect A of programming.
>:>
>:> : 2. The algorithms for doing A are incorporated into software tools.
>:>
>:> : 3. A stops being a everyday part of programming, and the size and
>:> : difficulty of programs that are considered writable is increased so
>:> : that programming is right at the limit of what programmers can do,
>:> : even without having to worry about A.
>:>
>:> This is false because the algorithm is described in human language,
>:> something a computer is incapable of understanding. And we have yet
>:> to find a way to describe these algorithms in a form the computer can
>:> understand. It is totally false to believe that because an algorithm
>:> exists for doing X that a computer can do X.
>
>: As far as I know, the Church-Turing hypothesis still stands
>: uncontradicted. Perhaps you could post an example of a non-computable
>: algorithm? A clear unambigous statement of the algorithm in English
>: would be fine.
>
>This has nothing to do with the Church-Turing hypothesis. Here is an
>algorithm:
>
>Given a problem:
>* Find a subset of users in the company with extensive business
> expertise.
>* Ask them what concepts are important to their business with respect
> to the stated problem.
>* Ask them to state the ways in which those concepts operate in their
> business.
>* Diagram these business concepts in UML use case, sequence, and class
> diagrams.
>* Give these diagrams to a programmer for coding.
>
>That IS an algorithm. One that cannot currently be done by
>computers. Furthermore, you can identify an algorithm for turning the
>UML diagrams into code. Those can ALMOST be done by computers, but
>not quite.
That is NOT an algorithm... it's a set of instructions, a recipe, and many
other things, but it is not an algorithm.
You would need to define the terms you are using to start with. It is
ambiguous and thus not an algorithm.
--
Sam
There's no such thing as a simple cache bug.
--Rob Pike
------------------------------
Date: Mon, 21 Sep 1998 03:10:18 GMT
From: George Reese <borg@imaginary.com>
Subject: Re: Perl & Java - differences and uses
Message-Id: <usjN1.1064$Ge.3219069@ptah.visi.com>
In comp.lang.java.programmer Zenin <zenin@bawdycaste.org> wrote:
: George Reese <borg@imaginary.com> wrote:
: >snip<
: : Design and naming things should be the result of a repeatable and
: : structured process. That is what OO methodologies are.
: Naming identifiers has *nothing* to do with OO in particular.
Yes it does. Part of object-orientation is the idea that real world
concepts should translate well into the world of code. This implies
naming identifiers in a way that reflects their real world referents.
: Even inside strict OO methodologies, there are many sub-designs
: that can be implemented.
Yes, so?
: : Formatting is a function of standard programming practices, or, better
: : yet, a well structured language like python.
: IYO...
No, actually, everything I have said is Mother Theresa's opinion.
: : Algorithms should be the result of proven design patterns.
: : Otherwise, you are just talking voodoo.
: And those proven algorithms you praise so highly come from where,
: a bible? Handed down from the gods like so much babble?
I think I have blown away this rhetorical line of nonsense you are
spouting regarding religion. If you continue in this line of bullshit
attacks, I will simply dismiss you as I have done Mr. Porter.
: What if there does not currently exist an algorithm to solve the
: problem you are working on? Oh my, you might just have to think for
: yourself...
That is aa system and application design issue and not a programming
issue.
: : You have a real problem with identity of things. No freedom is not
: : the same thing as being automatically generatable.
: But it's damn close.
Not in the least.
: : You don't even know what freedom is.
: >snip<
: : You need to go back and learn what a structured process is.
: And how did "structured process" get formed? Because someone
: had the freedom to think for themself.
You have a real problem with understanding logic (as was evidenced in
the post where you described religion as reasoned beliefs that were
illogical).
Algorithms require creativity to be developed. They do not require
creativity to be followed.
--
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:19:14 -0400
From: Uri Guttman <uri@sysarch.com>
Subject: Re: Perl & Java - differences and uses
Message-Id: <x7ogsaw3t9.fsf@sysarch.com>
>>>>> "PS" == Patricia Shanahan <pats@acm.org> writes:
PS> George Reese wrote:
>>
>> This has nothing to do with the Church-Turing hypothesis. Here is an
>> algorithm:
>>
>> Given a problem:
>> * Find a subset of users in the company with extensive business
>> expertise.
>> * Ask them what concepts are important to their business with respect
>> to the stated problem.
>> * Ask them to state the ways in which those concepts operate in their
>> business.
>> * Diagram these business concepts in UML use case, sequence, and class
>> diagrams.
>> * Give these diagrams to a programmer for coding.
>>
>> That IS an algorithm. One that cannot currently be done by
>> computers. Furthermore, you can identify an algorithm for turning the
>> UML diagrams into code. Those can ALMOST be done by computers, but
>> not quite.
PS> I would call it a methodology, rather than an algorithm. Three stages
PS> depend on judgement and skill on the part of the entity executing it:
PS> 1. Identifying users with "extensive business expertise". This COULD
PS> be reduced to an algorithm such as "identify users with at least 3
PS> years experience in this company, at least 10 years experience in this
PS> industry, and an MBA", but would be more effective if done with some
PS> flexibility.
PS> 2. Identifying "the current problem" to ask about.
PS> 3. Mapping their responses from natural language and business jargon
PS> into UML. I don't think anyone has yet identified a totally accurate
PS> algorithm for even parsing English, let alone converting English to
PS> UML. Given the ambiguities of English, and the need for the UML to be
PS> as unambiguous as possible (especially if it is just going to be
PS> handed to a programmer without a feedback process of questions,
PS> reviews, prototype testing etc.), I don't expect to see an algorithm
PS> for doing it any time soon.
pat, thanx for finally show that this bozo does not understand what an
algorithm is. he quotes the history of the word itself and mentions it
must be repeatable and always generates the same results. then he posts
this crap as an algorithm. if it were reduce to where a computer could
actually perform it, it would be useless in %99 of the real world
cases. again human beings are involved with creative decisions and so it
is not an algorithm. human decisions are more like art where there are
many truths and possibilited and nothing is can guaranteed to produce the
same results.
reese, read "computation: finite and infinite state machines" by marvin
minsky to learn about what is computable and what is not. computable and
algorithm are related. algorithm and methodology are not related.
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 03:32:37 GMT
From: George Reese <borg@imaginary.com>
Subject: Re: Perl & Java - differences and uses
Message-Id: <pNjN1.1067$Ge.3259462@ptah.visi.com>
In comp.lang.java.programmer Patricia Shanahan <pats@acm.org> wrote:
: I would call it a methodology, rather than an algorithm. Three stages
: depend on judgement and skill on the part of the entity executing it:
You are right. I was being careless. My mistake.
: 1. Identifying users with "extensive business expertise". This COULD
: be reduced to an algorithm such as "identify users with at least 3
: years experience in this company, at least 10 years experience in this
: industry, and an MBA", but would be more effective if done with some
: flexibility.
Yep.
: 2. Identifying "the current problem" to ask about.
Yep.
: 3. Mapping their responses from natural language and business jargon
: into UML. I don't think anyone has yet identified a totally accurate
: algorithm for even parsing English, let alone converting English to
: UML. Given the ambiguities of English, and the need for the UML to be
: as unambiguous as possible (especially if it is just going to be
: handed to a programmer without a feedback process of questions,
: reviews, prototype testing etc.), I don't expect to see an algorithm
: for doing it any time soon.
My mistake is in trying to equate the methodology with the algorithm,
which has nothing to do with my central thesis: that programming does
not require freedom.
I am sorry I stupidly dragged you (and others) on this tangent.
--
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 03:35:44 GMT
From: George Reese <borg@imaginary.com>
Subject: Re: Perl & Java - differences and uses
Message-Id: <kQjN1.1068$Ge.3259462@ptah.visi.com>
In comp.lang.java.programmer Uri Guttman <uri@sysarch.com> wrote:
: pat, thanx for finally show that this bozo does not understand what an
: algorithm is. he quotes the history of the word itself and mentions it
: must be repeatable and always generates the same results. then he posts
: this crap as an algorithm. if it were reduce to where a computer could
: actually perform it, it would be useless in %99 of the real world
: cases. again human beings are involved with creative decisions and so it
: is not an algorithm. human decisions are more like art where there are
: many truths and possibilited and nothing is can guaranteed to produce the
: same results.
: reese, read "computation: finite and infinite state machines" by marvin
: minsky to learn about what is computable and what is not. computable and
: algorithm are related. algorithm and methodology are not related.
Jesus Christ, I posted a hastily drawn together set of steps which
clearly were not an algorithm (not even by the definition I posted)
and you take it as an opportunity to make a personal attack on me.
You have personal issues to address and probably should not be seen in
public.
--
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: 21 Sep 1998 13:48:34 +1000
From: dformosa@zeta.org.au (David Formosa)
Subject: Re: Perl & Java - differences and uses
Message-Id: <6u4iai$ai7$1@godzilla.zeta.org.au>
In <tJiN1.1056$Ge.3219069@ptah.visi.com> George Reese <borg@imaginary.com> writes:
[...]
>This has nothing to do with the Church-Turing hypothesis. Here is an
>algorithm:
In an algorythum each step has to be simple and unambugiouse. Yours
fails this.
>Given a problem:
>* Find a subset of users in the company with extensive business
> expertise.
Abbugious because it requires understadning of what extensive means.
I suppose you can ask for peaple who have experence over X years.
>* Ask them what concepts are important to their business with respect
> to the stated problem.
>* Ask them to state the ways in which those concepts operate in their
> business.
These steps are ok.
>* Diagram these business concepts in UML use case, sequence, and class
> diagrams.
This step is not simple nor is it unambigiouse.
>* Give these diagrams to a programmer for coding.
This one is fine.
>That IS an algorithm.
No its a sequence of steps, it fails the neccery requirements to
be an algorthum.
------------------------------
Date: 21 Sep 1998 13:53:06 +1000
From: dformosa@zeta.org.au (David Formosa)
Subject: Re: Perl & Java - differences and uses
Message-Id: <6u4ij2$avr$1@godzilla.zeta.org.au>
In <tSiN1.1057$Ge.3219069@ptah.visi.com> George Reese <borg@imaginary.com> writes:
[...]
>: in fact algorithms are not usually descibed in english but in pseudo
>: code or some formal language. these can easily be converted to working
>: code by your drones.
>Uh, bullshit. Algorithms are described in all sorts of ways. Daniel
>Dennett has a wonderful book called "Darwin's Dangerous Idea" that
>talks all about the idea of evolution as an algorithm. I would love
>to see that formulated in pseudo code.
initalise population
repeat
cross over population
mutate population
select populaton
untill the end of time
I have infact programed systems like this. Of cause this is very much an
abstraction of what happens in real life but both are doable.
------------------------------
Date: Sun, 20 Sep 1998 22:55:54 -0500
From: Andrew Johnson <ajohnson@gpu.srv.ualberta.ca>
Subject: Re: Perl & Java - differences and uses
Message-Id: <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...
! * 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?
! * 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?) ---
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:
!> * 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...
!> 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?
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.
! * 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, 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...
! Now, if that is not a reasoned belief, I do not know what is.
apparently so.
regards
andrew
------------------------------
Date: 20 Sep 1998 23:58:32 -0400
From: Uri Guttman <uri@sysarch.com>
Subject: Re: Perl & Java - differences and uses
Message-Id: <x7lnnew1zr.fsf@sysarch.com>
>>>>> "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.
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.
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: Sun, 20 Sep 1998 20:42:32 -0400
From: fsg <fsg@ultranet.com>
Subject: Re: Perl & Java - differences and uses
Message-Id: <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.
> 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). 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.
> 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.
> 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.
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.
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.
> 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.
> : 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.
> : 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.
The US Army's main rifle was designed to work even if you dragged it
through the mud, filled it with water, and fired it way too many
times way too quickly. Undoubtedly, this attitude towards survival
over purity has saved more than a few American lives. Perl is the
same way. It's nice that it has the power to work even when you're
screaming for more dew at 5:00 am, 3 hours away from a customer
meeting worth a million dollars. But that's that whole 'real world
experience' thing again.
Felix
------------------------------
Date: 18 Sep 1998 22:21:07 GMT
From: bhilton@tsg.adc.com (Brand Hilton)
Subject: Randal Schwartz in Dallas, Texas 10/3
Message-Id: <6tumcj$7tn1@mercury.adc.com>
Randal Schwartz will be speaking in Dallas on October 3rd. Randal
will be giving his now-famous "Just Another Convicted Perl Hacker"
speech. For those of you who have never heard Randal, he's a very
entertaining and informative speaker, and this particular talk has
gotten rave reviews from everyone I've spoken to.
The particulars are:
Saturday, October 3rd, 2:00pm
Skybridge III room of the Doubletree Hotel on LBJ Freeway in Dallas
Admission is free
We're expecting a pretty big crowd, so show up early for good seats.
If you need further information, contact me,
Brand Hilton <bhilton@adc.com>
Last one there programs in Java!!
Brand
--
_____
|/// | Brand Hilton bhilton@adc.com
| ADC| ADC Telecommunications, ATM Transport Division
|_____| Richardson, Texas
------------------------------
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 3771
**************************************
