Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
Discussed that last night at the BLU meeting. Many of the PDP-8s did not come with a ROM. To load the executive, you would key in the RIM(ReadInMode) loader on the front panel switches. The RIM loader was a very simple paper tape reader program whose purpose was to read in the real paper tape loader. From there you could reload the PDP-8. Burger King's point of Sale system in the early 1970s was a PDP-8M with 4 attached registers. No disk, no paper tape, core memory. For the modem, we had to time the 1200 baud with timing loops and send a bit at a time. No UART. We also had to strike the hammers on the printer drum. Keyboard required to reads (row and column). If the system crashed, a service guy had to come in, plug in the paper tape board, and reload the program. On 22 Aug 2002 at 8:36, [EMAIL PROTECTED] wrote: Okay, I have to ask: What's a RIM loader? -- Jerry Feldman [EMAIL PROTECTED] Associate Director Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9 ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
[EMAIL PROTECTED] said: AFAIK, no. I believe that the original development was on some PDP-11's (11/45's?) No, the original development was on a PDP-7, and in assembler. The second machine it ran on was a PDP-11, also in assembler. It was after that port that Dennis wrote C, to make the next port easier. I think that for the most part he succeeded. [EMAIL PROTECTED] said: Okay, I have to ask: What's a RIM loader? O.K.: First you toggle in the BIN loader. On the PDP-8 this was seventeen twelve-bit instructions, so you have to flip (and get ABSOLUTELY CORRECT) 204 switches, and this was AFTER you toggled in the correct starting address. That BIN loader then loaded in a paper tape that had the RIM loader on it, which (hopefully) stayed in memory to load in things like an Editor, Assembler and (eventually) your program. However, with only 4K words (and poor programming skills) you usually overwrote the RIM loader with your program bombing (er, ah) running, so you had to start ALL OVER AGAIN. Ah, the good old days. :-) md -- = Jon maddog Hall Executive Director Linux International(SM) email: [EMAIL PROTECTED] 80 Amherst St. Voice: +1.603.672.4557 Amherst, N.H. 03031-3032 U.S.A. WWW: http://www.li.org Board Member: Uniforum Association, USENIX Association (R)Linux is a registered trademark of Linus Torvalds in several countries. (SM)Linux International is a service mark of Linux International, Inc. ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
[EMAIL PROTECTED] said: All this in 4K memory. Yeah, but Burger King was not selling as many hamburgers back in those days. :-) md -- = Jon maddog Hall Executive Director Linux International(SM) email: [EMAIL PROTECTED] 80 Amherst St. Voice: +1.603.672.4557 Amherst, N.H. 03031-3032 U.S.A. WWW: http://www.li.org Board Member: Uniforum Association, USENIX Association (R)Linux is a registered trademark of Linus Torvalds in several countries. (SM)Linux International is a service mark of Linux International, Inc. ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
In a message dated: Wed, 21 Aug 2002 19:30:45 EDT [EMAIL PROTECTED] said: I'm just curious... was Unix ever developed on any of those? I was pretty much under the impression that Unix assumes an 8-bit byte, but I don't really have anything to back that up... It was originally *developed* on a PDP-7 if my memory banks are correctly ECC'ed :) I believe it was ported to the PDP-8 at one point, but I don't remember for sure. I can check my copy of 25 years w/ UNIX tonight when I get home if you wish :) -- Seeya, Paul -- It may look like I'm just sitting here doing nothing, but I'm really actively waiting for all my problems to go away. If you're not having fun, you're not doing it right! ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
In a message dated: Tue, 20 Aug 2002 16:43:36 EDT [EMAIL PROTECTED] said: I believe it was Ken Thompson, and I believe the remark was intended to be humorous. Step back and ask: Why would he spell create as creat in the first place? If you are going to type five characters, you might as well type six. The reason it was spelled creat in the first place was the linked only supported five characters. That has caused much head-scratching, question-asking, and recompiling-due-to-typos; hence the remark about the spelling. Okay, I'll buy that, but why create a linker that only supports 5 character function names? What was it which caused this scenario? I guess I don't fully understand the role of linkers, if this should be an obvious thing :) -- Seeya, Paul -- It may look like I'm just sitting here doing nothing, but I'm really actively waiting for all my problems to go away. If you're not having fun, you're not doing it right! ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl (or Unix vs. MS, actually)
In a message dated: Tue, 20 Aug 2002 16:52:35 EDT
Steven W. Orr said:
On Tue, 20 Aug 2002 [EMAIL PROTECTED] wrote:
=In a message dated: Tue, 20 Aug 2002 15:16:58 CDT
=Thomas Charron said:
=
=For example, in shell, the construct:
=
= cd /tmp rm foo
Whotchoo talkin 'bout Willis?
cd == chdir is a builtin command. But point taken.
Okay, bad example :) How about:
PID=`ps -ef | grep foo | awk '{print $2}'`
kill -9 $PID
That's 4 sub-processes :)
Actually, debugging bash isn't all that bad.
I'm not saying it can't be done, but...
set -x
isn't the same as a debugger with break points, watches, etc.
And there is a full blown
debugger available for ksh with breakpoints and everything. :-)
Ooh, now *that's* cool! Thanks!
--
Seeya,
Paul
--
It may look like I'm just sitting here doing nothing,
but I'm really actively waiting for all my problems to go away.
If you're not having fun, you're not doing it right!
___
gnhlug-discuss mailing list
[EMAIL PROTECTED]
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
Back in the early days of computers there weren't as many characters to go around and folks had to be very conservative with their use. Since then, more have been pulled out of the ground so we can use them more liberally. -- __ | 0|___||. Andrew Gaunt *nix Sys. Admin., etc. _| _| : : } [EMAIL PROTECTED] - http://www-cde.mv.lucent.com/~quantum -(O)-==-o\ [EMAIL PROTECTED] - http://www.gaunt.org [EMAIL PROTECTED] wrote: In a message dated: Tue, 20 Aug 2002 16:43:36 EDT [EMAIL PROTECTED] said: I believe it was Ken Thompson, and I believe the remark was intended to be humorous. Step back and ask: Why would he spell create as creat in the first place? If you are going to type five characters, you might as well type six. The reason it was spelled creat in the first place was the linked only supported five characters. That has caused much head-scratching, question-asking, and recompiling-due-to-typos; hence the remark about the spelling. Okay, I'll buy that, but why create a linker that only supports 5 character function names? What was it which caused this scenario? I guess I don't fully understand the role of linkers, if this should be an obvious thing :) -- Seeya, Paul -- It may look like I'm just sitting here doing nothing, but I'm really actively waiting for all my problems to go away. If you're not having fun, you're not doing it right! ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
Good thing more colors other than green and amber were invented too. -Mark On Wed, Aug 21, 2002 at 11:00:10AM -0400, Andrew W. Gaunt wrote: Back in the early days of computers there weren't as many characters to go around and folks had to be very conservative with their use. Since then, more have been pulled out of the ground so we can use them more liberally. -- __ | 0|___||. Andrew Gaunt *nix Sys. Admin., etc. _| _| : : } [EMAIL PROTECTED] - http://www-cde.mv.lucent.com/~quantum -(O)-==-o\ [EMAIL PROTECTED] - http://www.gaunt.org ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
On Wed, 21 Aug 2002, at 10:10am, [EMAIL PROTECTED] wrote: Okay, I'll buy that, but why create a linker that only supports 5 character function names? Okay, some Google searches eventually tracked down this explanation: Way back when 16 kilobytes was a lot of memory, a method for encoding five characters into a single 32-bit machine word was developed. It was called Radix-50, or RAD50. The 50 is octal, or 40 decimal. The character set was 26 monocase letters, 10 digits, three special characters, and a null (a total of 40). This encoding was used in the linkers of various DEC PDP operating systems, which is where Unix was born. (That could, of course, be incorrect, but I did find references to Radix-50/RAD50 in some old DEC migration documentation.) I guess I don't fully understand the role of linkers, if this should be an obvious thing :) A compiler/assembler turns source code into object code modules. Those modules are not working programs yet; they have symbolic names instead of addresses for variables and functions in many places. You then need to link the modules together, which includes replacing symbolic names with machine addresses everywhere. The output of the linking process is an executable program. Run-time dynamic linking makes things more complex. *hand wave* -- Ben Scott [EMAIL PROTECTED] | The opinions expressed in this message are those of the author and do not | | necessarily represent the views or policy of any other person, entity or | | organization. All information is provided without warranty of any kind. | ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
Mark Komarinski writes: Good thing more colors other than green and amber were invented too. Newcommer! We only had black print on those cards and listings. ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
To throw a bit (pun un-intentional) more into this discussion, don't assume that a byte was eight bits. The PDP-8, Linc-8 and PDP-12 for instance, were all twelve bit words, broken down into two six-bit characters. Nevertheless, back in those days saving a few bits for every entry in a symbol table was worth the time and effort. md -- = Jon maddog Hall Executive Director Linux International(SM) email: [EMAIL PROTECTED] 80 Amherst St. Voice: +1.603.672.4557 Amherst, N.H. 03031-3032 U.S.A. WWW: http://www.li.org Board Member: Uniforum Association, USENIX Association (R)Linux is a registered trademark of Linus Torvalds in several countries. (SM)Linux International is a service mark of Linux International, Inc. ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
[EMAIL PROTECTED] asked: was Unix ever developed on any of those? (meaning the 12-bit PDP-8/PDP-12 architectures) AFAIK, no. I believe that the original development was on some PDP-11's (11/45's?) that Bell Labs had at the time. Those, of course, are 16-bit machines. But, I don't ever hearing about any back-porting to the PDP-8's. At the time, it would have been a real PITA, because the I/O architectures were totally different. Also, by the time that UNIX was more or less working well enough to distribute to its users, the PDP-8 was rapidly approaching end-of-life; DEC had jumped through some really wierd hoops to get it to address 128kb of memory, and it was clear that that was it. The PDP-11s, on the other hand, could do that much fairly easily and was obviously much more extendible. Much of the development in the mid-70's was to meet some interesting requirements that customers had voiced, and obviously some of those customers were running UNIX. HTH, Bayard, who tried, but failed to find his old copy of the RIM loader... ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
In a message dated: Tue, 20 Aug 2002 15:01:45 EDT Derek D. Martin said: I don't believe there was ever a name-length limitation on filenames. Then you believe incorrectly. Many variants of Unix had a 14-character filename limit. There is still a limit today, though it's ridiculously large, so as not to matter practically. Ahh, 14 characters, that does sound familiar. You're right. It was the mention of 4 character file names which threw me. Sorry. I may only be imagining this, but I could swear it was a predecessor to Unix, from whence many of these commands originally came (possibly multics? anyone?) that did have a four character filename limit. I don't know a lot about multics. Perhaps you're thinking of the 6 character limitations of node names in DECNET, from whence came the famous 'decvax' et. al.? OTOH, I haven't been getting much sleep lately... =8^) What else have you to do? ;) -- Seeya, Paul -- It may look like I'm just sitting here doing nothing, but I'm really actively waiting for all my problems to go away. If you're not having fun, you're not doing it right! ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl (or Unix vs. MS, actually)
In a message dated: Tue, 20 Aug 2002 15:01:45 EDT
Derek D. Martin said:
At some point hitherto, [EMAIL PROTECTED] hath spake thusly:
In a message dated: Tue, 20 Aug 2002 12:37:34 EDT
Derek D. Martin said:
I never claimed Unix commands weren't obscure; they ARE. I prefer
them to Microsoft commands because in general I find they do more and
work better. However, Unix has man pages.
But man pages and documentation aren't going to help a shell script
be more readable! (at least by your own argument).
Which is specifically why I made that point immediately after what you
quoted. Now you're just trolling...
No, I'm using your own argument against you. You state that UNIX has
man pages as if that excuses the obscure command names of the OS.
Yet when I stated that all of Perl's magic variables are clearly
documented, your first reaction was that it doesn't make a perl
program any more readable just because they're documented somewhere.
And my argument all along was
not that Perl has obscurities; it's that it has TOO MANY, and the
people who write perl (in my experience) have a propensity to use them
TOO OFTEN, being not conducive to actually learning perl.
Yes, perl has a lot of obscurities. However, I don't feel that it's
an obstruction to learning the language. I've been programming perl
for about 8+ years now, and can't claim to know more than 4 or 5 of
these off the top of my head. You seem to be implying that to learn
the language one must memorize all of the variables, which is
ridiculous. In common practice, most of these variables aren't used.
If you need to read someone elses code in order to maintain it, then
look the variable up in the docs, and make a comment in the code.
Enhancement *is* part of maintainence.
I'm inclined to think you're being intentionally obtuse.
I'm inclined that you just feel like complaining about something :)
Hundreds of thousands of people have learned to program perl. Many
of them know no other language, so it can't be that difficult.
Of course, that may well be *why* their code is relatively
unreadable, as they've never learned much in the way of proper coding
style (whatever that can be defined as).
I'll try to sum up the reasons for this succinctly, so we can put this
to bed. Preface with IMO, wherever you think it might be appropriate.
- Perl grew rather than being designed. Its syntax is a
mish-mash of features from several other languages and/or utilities
all glued together, and as such sometimes seems to be inconsistent
with itself
Okay, no debate there.
- Perl does some things which are commonly done in programming
languages very, very differently from the rest
Like what? Other than structures which don't need to exist in perl.
- Perl has a lot of obscure features and syntax, like the so-called
magic variables, that don't lend themselves to readable code
I don't see how this is any different than any other language. I've
seen plenty of unreadable C. I've even seen unreadable sh!
The use of obscure features and syntax is available in any language,
and there for the programmer to abuse to their heart's content. This
is a people problem, not a language problem.
- The people who write Perl by and large seem to prefer a style (if
you can call it that) that promotes neither code readability nor
education
This I'll grant you to some extent. However, it's a people problem,
not one with the language.
- For all its wiz-bang features that make many tasks which are
difficult on other languages much easier in perl, it lacks the
ability to easily manipulate data structures; one of the most
common things done with computer programs. Dealing with arrays of
hashes of hashes is somewhat clumsy, by comparison to other
languages
Agreed, and in most cases where you need to deal with arrays of
hashes of hashes, or hashes of arrays of hashes, etc. you're probably
better off using something like C.
Of course, if you've mucked about with this type of thing long
enough, it becomes rather natural and understandable, and therefore,
simpler to deal with than using C.
- learning to do certain common programming tasks in perl is
unneccessarily hard
You keep mentioning this, yet you haven't mentioned what any of these
common programming tasks are. Can you provide examples?
- understanding some of perl's syntax is counterintuitive, and
unnecessarily hard
Other than the magic variables, which for the most part, are
irrelevant, what are some examples of perl syntax which you find
counter-intuitive? I ask not to be difficult, but because I've never
encountered anything in the language I've considered
counter-intuitive. Essentially, all the syntax is based around
performing an operation on a scalar or on lists of scalars and follow
the basic syntax:
commandname {block of code} list of scalars to operate on
- reading and maintaining other people's code
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
On Tue, 20 Aug 2002, at 3:09pm, [EMAIL PROTECTED] wrote: Then you believe incorrectly. Many variants of Unix had a 14-character filename limit. There is still a limit today, though it's ridiculously large, so as not to matter practically. Ahh, 14 characters, that does sound familiar. You're right. It was the mention of 4 character file names which threw me. Sorry. The 14-character filename limit *did* exist in some early Unix or Unixes. I do knot know exactly which ones, but it is an oft-cited limit when worrying about greatest common factors for heterogeneous systems. I am pretty sure there was never a 4-character filename limit. I can think of many things that would not fit: passwd, login, mount, mkdir, rmdir, issue, fstab ... I may only be imagining this, but I could swear it was a predecessor to Unix, from whence many of these commands originally came (possibly multics? anyone?) that did have a four character filename limit. I don't know a lot about multics. Perhaps you're thinking of the 6 character limitations of node names in DECNET, from whence came the famous 'decvax' et. al.? I think he is thinking of the five-character limit in the original linker(s) used to develop Unix (which very well may have come from Multics). That five-character limit gave us the infamous creat(2) system call. -- Ben Scott [EMAIL PROTECTED] | The opinions expressed in this message are those of the author and do not | | necessarily represent the views or policy of any other person, entity or | | organization. All information is provided without warranty of any kind. | ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl (or Unix vs. MS, actually)
[EMAIL PROTECTED] writes: Agreed, and in most cases where you need to deal with arrays of hashes of hashes, or hashes of arrays of hashes, etc. you're probably better off using something like C. Of course, if you've mucked about with this type of thing long enough, it becomes rather natural and understandable, and therefore, simpler to deal with than using C. I've been avoiding getting involved with this thread because I consider Derek's whole line of reasoning to be pretty innane, but I thought I'd comment on this issue. In my opinion, after you learn how to use references in Perl, and after you learn how to use lists of refs and hashes of refs, you'll cry the next time that you have to implement anything similar in C/C++/Java. --kevin -- Kevin D. Clark / Cetacean Networks / Portsmouth, N.H. (USA) cetaceannetworks.com!kclark (GnuPG ID: B280F24E) alumni.unh.edu!kdc ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
In a message dated: Tue, 20 Aug 2002 16:20:29 EDT [EMAIL PROTECTED] said: I think he is thinking of the five-character limit in the original linker(s) used to develop Unix (which very well may have come from Multics). That five-character limit gave us the infamous creat(2) system call. H, I don't believe that's correct either. I remember a discussion with either Brian Kernighan or Dennis Ritchie, who, when asked what he would do different if he had a chance to go back and change anything in UNIX, stated, I'd spell creat(2) with an 'e' on the end.[1] [1] This quote is not necessarilly verbatim, but it's close :) -- Seeya, Paul -- It may look like I'm just sitting here doing nothing, but I'm really actively waiting for all my problems to go away. If you're not having fun, you're not doing it right! ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl (or Unix vs. MS, actually)
In a message dated: Tue, 20 Aug 2002 15:16:58 CDT Thomas Charron said: I do occasionally use Perl, but I find that it's usually when I want to do a lot of regexp work, or shell-script-like work, but don't want to take the performance hit of using a shell script. Otherwise, bash or C suit me better. Performance hit. Thats kinda funny. And what kind of benchmarks have you performed as a basis for this judgement? I guess I dont see what this means, as to why you do it. Well, in Derek's defense, using perl for something similarly written in bash is likely to perform better since bash or any of the traditionall 'shell' languages need to spawn a separate process for everything. For example, in shell, the construct: cd /tmp rm foo creates 2 sub-shell processes, whereas, in perl: chdir (/tmp) unlink(foo); creates 0 sub-shell processes. Therefore, perl is, technically, more efficient in this regard. Does it really matter with todays ridiculously overpowered CPUs and gobs of memory? Probably not in most cases. Though, perl does have a debugger one can use vs. bash which doesn't. That right there is a plus in the perl column for me! :) -- Seeya, Paul -- It may look like I'm just sitting here doing nothing, but I'm really actively waiting for all my problems to go away. If you're not having fun, you're not doing it right! ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
On Tue, 20 Aug 2002, at 4:14pm, [EMAIL PROTECTED] wrote: I think he is thinking of the five-character limit in the original linker(s) used to develop Unix (which very well may have come from Multics). That five-character limit gave us the infamous creat(2) system call. H, I don't believe that's correct either. I remember a discussion with either Brian Kernighan or Dennis Ritchie, who, when asked what he would do different if he had a chance to go back and change anything in UNIX, stated, I'd spell creat(2) with an 'e' on the end.[1] I believe it was Ken Thompson, and I believe the remark was intended to be humorous. Step back and ask: Why would he spell create as creat in the first place? If you are going to type five characters, you might as well type six. The reason it was spelled creat in the first place was the linked only supported five characters. That has caused much head-scratching, question-asking, and recompiling-due-to-typos; hence the remark about the spelling. -- Ben Scott [EMAIL PROTECTED] | The opinions expressed in this message are those of the author and do not | | necessarily represent the views or policy of any other person, entity or | | organization. All information is provided without warranty of any kind. | ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
The 14 character limit did exist in Unix versions 6 and 7. Version 6 was used as a basis for the BSD releases. Version 7 was the basis for what became System 3 followed by System V. Long file names I think came out for the first time in BSD 4.3 (or possibly 4.2). Unlike MS DOS, which had a limit of 8 for the file name and 3 for the extension, the file extension was (and is) a convention, and the dot (.) could appear anywhere in the 14 characters. Filenames beginning with a dot are uninteresting, and not generally displayed by ls. On 20 Aug 2002 at 16:20, [EMAIL PROTECTED] wrote: The 14-character filename limit *did* exist in some early Unix or Unixes. I do knot know exactly which ones, but it is an oft-cited limit when worrying about greatest common factors for heterogeneous systems. -- Jerry Feldman [EMAIL PROTECTED] Associate Director Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9 ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl (or Unix vs. MS, actually)
On Tue, 20 Aug 2002 [EMAIL PROTECTED] wrote:
=
=In a message dated: Tue, 20 Aug 2002 15:16:58 CDT
=Thomas Charron said:
=
=For example, in shell, the construct:
=
= cd /tmp rm foo
Whotchoo talkin 'bout Willis?
cd == chdir is a builtin command. But point taken.
=
=creates 2 sub-shell processes, whereas, in perl:
=
= chdir (/tmp) unlink(foo);
=
=creates 0 sub-shell processes. Therefore, perl is, technically, more
=efficient in this regard. Does it really matter with todays
=ridiculously overpowered CPUs and gobs of memory? Probably not in
=most cases.
=
=Though, perl does have a debugger one can use vs. bash which doesn't.
=That right there is a plus in the perl column for me! :)
Actually, debugging bash isn't all that bad.
set -x
will solve lots of problems and if that doesn't get you going, then
set -xv
will probably do the rest of it. Another great debugging technique is to
set
PS4='.+${0##*/} line $LINENO: '
Also, while bash is arguably the best *login* shell, the best shell
scripting language (aside from perl, but I don't consider that to be a
scripting language in the first place) is ksh. And, BTW, the real ksh93 is
available for free in rpm format, no less. And there is a full blown
debugger available for ksh with breakpoints and everything. :-)
--
-Time flies like the wind. Fruit flies like a banana. Stranger things have -
-happened but none stranger than this. Does your driver's license say Organ
-Donor?Black holes are where God divided by zero. Listen to me! We are all-
-individuals! What if this weren't a hypothetical question? [EMAIL PROTECTED]
___
gnhlug-discuss mailing list
[EMAIL PROTECTED]
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
I think you are correct. Create(2) is a system call. Linkage editors those days were rather primitive. I think the name limit was either 7 or 8, but external names in C were many times autoprefixed with __, such that creat became __creat. The C language had a limit of 8 characters for a variable name (KR 2.1). (Actually a name could be longer, but only the first 8 were significant). I think the only other programmer on this list who might have been writing C back then is my granduncle, Alex Hewitt ;-) On 20 Aug 2002 at 16:43, [EMAIL PROTECTED] wrote: I believe it was Ken Thompson, and I believe the remark was intended to be humorous. Step back and ask: Why would he spell create as creat in the first place? If you are going to type five characters, you might as well type six. The reason it was spelled creat in the first place was the linked only supported five characters. That has caused much head-scratching, question-asking, and recompiling-due-to-typos; hence the remark about the spelling. -- Jerry Feldman [EMAIL PROTECTED] Associate Director Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9 ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
On Tue, 20 Aug 2002, Jerry Feldman wrote: =I think you are correct. Create(2) is a system call. Linkage editors those =days were rather primitive. I think the name limit was either 7 or 8, but =external names in C were many times autoprefixed with __, such that creat =became __creat. =The C language had a limit of 8 characters for a variable name (KR 2.1). =(Actually a name could be longer, but only the first 8 were significant). =I think the only other programmer on this list who might have been writing =C back then is my granduncle, Alex Hewitt ;-) = =On 20 Aug 2002 at 16:43, [EMAIL PROTECTED] wrote: = I believe it was Ken Thompson, and I believe the remark was intended to be = humorous. Step back and ask: Why would he spell create as creat in the = first place? If you are going to type five characters, you might as well = type six. The reason it was spelled creat in the first place was the = linked only supported five characters. That has caused much = head-scratching, question-asking, and recompiling-due-to-typos; hence the = remark about the spelling. I have to jump in with an old arcana of my own. I used to work at Data General during Soul of a New Machine days. Their AOS operating system actually had roots originating from earliest Unix. The deal there was that all external variables (by convention) were coded in uppercase. Why? Because sometimes we needed to assign values at linktime to symbols. This was done on the commandline. And the Data General Command Line Interface (CLI) was case insensitive. So if the symbol wasn't uppercase, then the linker would be monkeying with the wrong symbol. :-) -- -Time flies like the wind. Fruit flies like a banana. Stranger things have - -happened but none stranger than this. Does your driver's license say Organ -Donor?Black holes are where God divided by zero. Listen to me! We are all- -individuals! What if this weren't a hypothetical question? [EMAIL PROTECTED] ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
You had C? All we had was assembler! You had assembler? All we had was ones and zeros! You had ones and zeros? ... -Alex - Original Message - From: Jerry Feldman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, August 20, 2002 4:53 PM Subject: Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ] I think you are correct. Create(2) is a system call. Linkage editors those days were rather primitive. I think the name limit was either 7 or 8, but external names in C were many times autoprefixed with __, such that creat became __creat. The C language had a limit of 8 characters for a variable name (KR 2.1). (Actually a name could be longer, but only the first 8 were significant). I think the only other programmer on this list who might have been writing C back then is my granduncle, Alex Hewitt ;-) On 20 Aug 2002 at 16:43, [EMAIL PROTECTED] wrote: I believe it was Ken Thompson, and I believe the remark was intended to be humorous. Step back and ask: Why would he spell create as creat in the first place? If you are going to type five characters, you might as well type six. The reason it was spelled creat in the first place was the linked only supported five characters. That has caused much head-scratching, question-asking, and recompiling-due-to-typos; hence the remark about the spelling. -- Jerry Feldman [EMAIL PROTECTED] Associate Director Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9 ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl (or Unix vs. MS, actually)
On Tue, 20 Aug 2002, at 12:37pm, Derek D. Martin wrote: [ Several paragraphs of completely irrelevant and bogus argument deleted. I will provide explicit debunking of said argument if so requested. ] There are very few Unix commands whose names are completely unintelligible, and learning them is much easier than learning the difference between $^P and $^B. At least for me, and I suspect most people. [ ... snip ... ] Perhaps. But I have a very good grasp of regexp and that's definitely not what *I* am talking about. Okay, so, you have no trouble understanding the Unix environment, which is inconsistent, obscure, and cryptic. You have no trouble with regular expressions, which have, arguably, the most cryptic syntax of any popular language construct, ever. Yet you complain about Perl being hard to learn and use, for the same reasons, and not just for you, but for everyone? That does not add up. Is Perl cryptic? Sure. So are many other things which *you have no problem with*, which was my point. I am willing to bet, dollars to donuts, that the real reason you find Unix easy while Perl is hard is that you use Unix every day, day in, and day out, while Perl is something you only dabble in. Of course, I cannot prove that assertion, but I ask you consider it as objectively as you can (if that is not a complete logical impossibility, which I rather suspect it is). On Tue, 20 Aug 2002, at 3:01pm, Derek D. Martin wrote: - Perl grew rather than being designed. Its syntax is a mish-mash of features from several other languages and/or utilities all glued together, and as such sometimes seems to be inconsistent with itself. Agreed. But, again, Unix is the same way, and so is MS-Windows, yet we have no problem telling people they can/should learn those. Why does Perl get singled out? - Perl does some things which are commonly done in programming languages very, very differently from the rest True, but irrelevant. Compare Python, C, and Scheme, and you'll get a far bigger diff. All programming languages are different. - Perl has a lot of obscure features and syntax, like the so-called magic variables, that don't lend themselves to readable code Marginal. Mechanisms are in place to eliminate the magic variable problem, because said magic variables are recognized as cryptic. What I find more telling is that, at least in my experience, few of those magic variables are needed in practice. I certainly rarely use them. It is like complaining about trigraphs in C. Yes, they are obscure and cryptic, but nobody uses them, so who cares? Can you give an example of anything *other* than the magic variable problem? I am starting to think you're just hung up on magic variables, the way some people get wedged on whitespace in Python. - The people who write Perl by and large seem to prefer a style (if you can call it that) that promotes neither code readability nor education Can you back that up with any kind of real evidence? My personal theory on this is a bit different. There are people who like to write dense, terse, cryptic code. Perl, being the flexible beast that it is, lets those people do that to the extreme. So those people tend to gravitate to Perl. You see a lot more such code written in Perl, because Perl is the best tool to do it in -- a dubious distinction, I'll agree. However, just because there are a large number of hacks writing line-noise in Perl doesn't mean every Perl coder on the planet does it. I certainly don't find much of that stuff in the Camel books, other than deliberate instances of it. For all its wiz-bang features that make many tasks which are difficult on other languages much easier in perl, it lacks the ability to easily manipulate data structures ... True, and a recognized problem, and one that is being worked on in Perl 6. However, I don't think anyone was suggesting that Perl is the universal fix to all programming problems. Perl excels at munching text, working with dynamic lists of flat data, and associative lookups (among other things). The tasks Perl does well are all tasks done frequently in computer programs as well. But many of the features of Perl compound [the problem of reading other people's code], making for naturally ugly code. I find that Perl often leads to naturally elegant code, when used properly. I have to wonder if your problem is just that you hang around too many lousy Perl hackers. :-) -- Ben Scott [EMAIL PROTECTED] | The opinions expressed in this message are those of the author and do not | | necessarily represent the views or policy of any other person, entity or | | organization. All information is provided without warranty of any kind. | ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
Didn't you work with Grace Hopper :-) Hewitt Tech wrote: You had C? All we had was assembler! You had assembler? All we had was ones and zeros! You had ones and zeros? ... -- -- Gerald Feldman [EMAIL PROTECTED] Boston Computer Solutions and Consulting ICQ#156300 PGP Key ID:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9 ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl (or Unix vs. MS, actually)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 At some point hitherto, [EMAIL PROTECTED] hath spake thusly: Yet you complain about Perl being hard to learn and use, for the same reasons, and not just for you, but for everyone? I absolutely said no such thing. Let's make this even simpler. Mike O'Donnell commented about finding the prospect of learning Perl daunting. I attempted to convey to the perlheads here who responded with incredulity that I too had the same reaction, attempted to learn it, found that learning *facile* use of it was more difficult than any other language I'd tried to learn. I then proceeded to attempt to explain why *I* found it that way, apparently to no one's satisfaction. Suffice it to say that the reasons don't much matter. Whatever the reason, that was my experience, and so I can sympathize with anyone who voices those kinds of opinions. I'm done with this topic. - -- Derek Martin [EMAIL PROTECTED] - - I prefer mail encrypted with PGP/GPG! GnuPG Key ID: 0x81CFE75D Retrieve my public key at http://pgp.mit.edu Learn more about it at http://www.gnupg.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9YvRKdjdlQoHP510RAmxvAKCK63cngoBI1lKJMYC1IV7dK/+CMwCdHpEY DHiXcd02zX933Gi4VoyFNJQ= =gng9 -END PGP SIGNATURE- ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
