[10177] in Perl-Users-Digest
Perl-Users Digest, Issue: 3770 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Sep 20 23:07:48 1998
Date: Sun, 20 Sep 98 20:01:24 -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: 3770
Today's topics:
Re: Perl & Java - differences and uses <jgitomer@erols.com>
Re: Perl & Java - differences and uses <jgitomer@erols.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 <garry@america.net>
Re: Perl & Java - differences and uses <borg@imaginary.com>
Re: Perl & Java - differences and uses <pats@acm.org>
Re: what's wrong with win32 perl ? <Savage.Ron.RS@bhp.com.au>
Special: Digest Administrivia (Last modified: 12 Mar 98 (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 20 Sep 1998 21:14:59 -0400
From: "Jerry Gitomer" <jgitomer@erols.com>
Subject: Re: Perl & Java - differences and uses
Message-Id: <6u49n8$mak$2@winter.news.erols.com>
Hi Zenin,
Zenin wrote in message <906130825.257895@thrush.omix.com>...
> >snip<
>
> Perl syntax builds on syntax most programmers already know, thereby
> *reducing* the learning and curve which makes the language *easier*
> to read and maintain.
>
I hate to say it but I think that there are more Visual Basic programmers
out there than all of the C/C++, Java, Pearl, and Python programmers
combined. Adding insult to injury I suspect the same is true of COBOL!!!
If this is so, which I cheerfully admit may not be the case, none of the
real languages is built on "syntax most programmers already know"
regards
Jerry
------------------------------
Date: Sun, 20 Sep 1998 21:00:42 -0400
From: "Jerry Gitomer" <jgitomer@erols.com>
Subject: Re: Perl & Java - differences and uses
Message-Id: <6u49n7$mak$1@winter.news.erols.com>
Hi John,
John Porter wrote in message <36003380.9F1D006F@min.net>...
Big snip here
>
>You can deduce *some* degree of technical goodness, because without
>it, all the non-technical factors in the world wouldn't result in
>C having the popularity that it has had. Look at ADA and PL/1 for
>examples: huge non-technical forces (the DoD and IBM, respectively)
>were unable to make people use those languages.
>
Is this because no one, not even DOD and IBM have the power to make a huge
language or a not-yet-ready-for-release compiler acceptable? From the 70s I
remember horror stories about the size and sloth of PL/1 as compared to
Fortran and COBOL. When ADA was new I remember sitting in on ACM sessions
where the primary topic and concern was quality (or lack thereof) of the
early compiler(s).
In the case of PL/1 I recall that the common perception was that it was
just too much and too complicated. In the case of ADA I believe that the
perception was that the first compilers were rushed out the door and should
have been called beta releases.
regards
Jerry
------------------------------
Date: Mon, 21 Sep 1998 02:20:09 GMT
From: George Reese <borg@imaginary.com>
Subject: Re: Perl & Java - differences and uses
Message-Id: <tJiN1.1056$Ge.3219069@ptah.visi.com>
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.
--
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 02:29:45 GMT
From: George Reese <borg@imaginary.com>
Subject: Re: Perl & Java - differences and uses
Message-Id: <tSiN1.1057$Ge.3219069@ptah.visi.com>
In comp.lang.java.programmer Uri Guttman <uri@sysarch.com> wrote:
:>>>>> "GR" == George Reese <borg@imaginary.com> writes:
: another reason not to hire you.
I did not know I asked you for a job.
: if it is an algorithm and it works it
: can be programmed. it may be a pig but on a turing compatible system it
: can be done.
If it is an algorithm, a computer can be programmed to do it IN
PRINCIPLE. There are a lot of things computers can do in principle
that they cannot yet do in fact.
: 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.
: but you recently stated that programmers do only the grunt work and
: designing the objects and names was the job of the analysts and higher
: ups. sound like they have the same issues programmers had. idiots make
: idiotic decisions at any level. i said that the design was all freedom
: and you responded by pushing that to a higher level. opposite of
: sweeping it under the rug.
You don't read really well. I have done nothing of the sort.
The issue is whether a programming language should allow freedom in
programmers (as does perl) or should a programming language be
tailored to a structured programming method (as is python). I have
stated freedom has no place in programming. You seem to have taken
that to mean freedom has no place.
Whether or not freedom has any place in design has NO bearing on
whether it has any place in programming.
: so my main point is that OO does not remove any of the need for
: creativity from software engineering.
I have never said it did.
: it just relocates and renames
: it.
It isolates it. OO is about isolating all risks.
: you can't get great code form a bank of drone programmers if their
: designers don't know what they are doing.
Again, this has nothing to do with the issue of whether freedom has
any place in programming.
: and even then you have no
: guarantee of the quality of the code. i will take the small team who
: decide how they want to work and with what paradigm over any large scale
: team with methodology restrictions.
Then you are a bad person to be in charge of any enterprise
development at any level.
: i am currently working on a large project with 1 other person. it is a
: mutlithreaded high speed server (can't say more here). it is in
: plain C with no objects. it has an event engine with a tested and simple
: API and we will get it out the door faster and better than any team of
: drones you could ever get, with whatever OO design you could give them.
I would bet against you on this, but I suppose we will never know.
--
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 02:42:46 GMT
From: "Garry T. Williams" <garry@america.net>
Subject: Re: Perl & Java - differences and uses
Message-Id: <3605BD74.FE3D0C01@america.net>
Jerry Gitomer wrote:
[snip]
> >You can deduce *some* degree of technical goodness, because without
> >it, all the non-technical factors in the world wouldn't result in
> >C having the popularity that it has had. Look at ADA and PL/1 for
> >examples: huge non-technical forces (the DoD and IBM, respectively)
> >were unable to make people use those languages.
> >
>
> Is this because no one, not even DOD and IBM have the power to make a huge
> language or a not-yet-ready-for-release compiler acceptable? From the 70s I
> remember horror stories about the size and sloth of PL/1 as compared to
> Fortran and COBOL. When ADA was new I remember sitting in on ACM sessions
> where the primary topic and concern was quality (or lack thereof) of the
> early compiler(s).
>
> In the case of PL/1 I recall that the common perception was that it was
> just too much and too complicated. In the case of ADA I believe that the
> perception was that the first compilers were rushed out the door and should
> have been called beta releases.
I recall using the PL/I Optimizing compiler in the mid seventies. I
marveled at the machine language (S/370 Assembler) it produced. I
learned a lot about efficient Assembler coding by examining that
compiler's output.
I also recall shaking my head at some awful PL/I code. It seemed as if
the author was *trying* to produce bloated and inefficient load
modules. The PL/I compiler could generate some pretty bad code in the
wrong hands. It was well documented that data conversions were
expensive. Yet, many programs I had to pick up went out of their way to
use these features. It was easier to code and took less thought, but it
resulted in bloated programs.
One program I had to pick up sticks in my mind to this day. The data
structure called for an array of boolians to represent errors discovered
in editing payroll data. Each error indicator was set by various procs
when they came across input problems. The programmer had declared the
array as bin(32). That meant, to accommodate a sign, the compiler had
to allocate a double word (eight bytes) for each element. The array was
thousands of elements long. The S/370 had very fast bit operations and
the compiler could have generated optimal code since the offsets and
masks were all known at compile time. The machine didn't have fast
double word instructions. It didn't even have double word integer
arithmetic (only 32 bit instructions for integers). The compiler had to
stand on its head to manipulate 64 bit integers -- just to check if they
were one or zero. If only the programmer had ever learned 'bit(1)'...
I often thought that it would be a Good Thing to only allow a subset of
the language. (I just couldn't *define* that subset. :-))
-Garry Williams
------------------------------
Date: Mon, 21 Sep 1998 02:49:45 GMT
From: George Reese <borg@imaginary.com>
Subject: Re: Perl & Java - differences and uses
Message-Id: <d9jN1.1059$Ge.3219069@ptah.visi.com>
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.
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?
[ 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
Substrate neutrality means the process works well using a pencil, pen,
computer, etc. The power of the algorithm is due to its logical structure.
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.
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.
--
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 19:54:57 PDT
From: Patricia Shanahan <pats@acm.org>
Subject: Re: Perl & Java - differences and uses
Message-Id: <3605BF86.55627452@acm.org>
George Reese 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.
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:
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.
2. Identifying "the current problem" to ask about.
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.
Patricia
------------------------------
Date: 21 Sep 1998 01:14:53 GMT
From: "Ron Savage" <Savage.Ron.RS@bhp.com.au>
Subject: Re: what's wrong with win32 perl ?
Message-Id: <01bd9cb2$46aa0060$90eb1286@steelres-pcm657.resmel.bhp.com.au>
Are you sure there is a problem?
I've recently installed many modules under V 5.005.02, and some issued a
line indicating how to call xsubpp (?). However, this line is quite
harmless. The line I get is the sort of thing you'd expect to see if you
issued 'xsubpp -h'. Do you get that?
Ignore it.
--
Ron Savage
Home (preferred): rpsavage@ozemail.com.au
Office: Savage.Ron.RS@bhp.com.au
http://www.ozemail.com.au/~rpsavage
John Smith <bgates@microsoft.com> wrote in article
<6tvh4s$iks$1@winter.news.erols.com>...
> I still couldn't compile modules under win32.
> So far, I have tried four different versions of perl5,
> include ActiveState perl. They all complained about
> xsubpp. Is it my windows setting or the unsolved problem of win32 perl ?
> Please help.
> If anybody have a binary version of HTML::Embperl
> module, could you please email me ?
> Thanks,
> dc@fcc.gov
>
>
>
>
------------------------------
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 3770
**************************************
