Re: Perl (or Unix vs. MS, actually)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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... 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. I'm inclined to think you're being intentionally obtuse. You are also aware that my first Perl program was a > 1000 line program for managing host resolution, which worked well enough for us to use it in production at MCL, with or without the web-based interface. So you know I'm not trying to damn perl to unusability; I'm only saying that as languages go, I can see why some people find it reletively hard to learn, as compared to a lot of other languages. Myself included. 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 - Perl does some things which are commonly done in programming languages very, very differently from the rest - Perl has a lot of obscure features and syntax, like the so-called "magic" variables, that don't lend themselves to readable code - 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 - 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 For these reasons, I and others find perl difficult. That is, more often than not, I/we find that: - learning to do certain common programming tasks in perl is unneccessarily hard - understanding some of perl's syntax is counterintuitive, and unnecessarily hard - reading and maintaining other people's code is unnecessarily hard The last one is a key point. Maintaining someone else's code in any language is often difficult, especially if they don't comment their code and use a style that lends itself to readability. But many of the features of Perl compound this problem, making for naturally ugly code. When you sum these things all up, they keep me from reaching for Perl to do much of anything. You don't have to agree. 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. > >I will also point out that many of the "traditional" Unix command were > >named when there was a four-letter limitation on filenames. > > 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. 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. OTOH, I haven't been getting much sleep lately... =8^) - -- 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 iD8DBQE9YpIZdjdlQoHP510RAobSAKCbPcNGlC5f+GWjZtbYzp+FV7mxBACfZa8O 4TDjJ8v8KW34ywa7RO8Ogjs= =Ksgm -END PGP SIGNATURE- ___ 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 sca
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: Perl (or Unix vs. MS, actually)
Quoting "Derek D. Martin" <[EMAIL PROTECTED]>: > Which is specifically why I made that point immediately after what you > quoted. Now you're just trolling... 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. I'm > inclined to think you're being intentionally obtuse. This is primarily becouse perl is, at a core, a functional language. No attempt has ever been made to enforce style or methods within perl. It wasnt built to be pretty, it was built to be efficient. > You are also aware that my first Perl program was a > 1000 line > program for managing host resolution, which worked well enough for us > to use it in production at MCL, with or without the web-based > interface. So you know I'm not trying to damn perl to unusability; > I'm only saying that as languages go, I can see why some people find > it reletively hard to learn, as compared to a lot of other languages. > Myself included. Agreed. But only when coming from a standpoint of attempting to learn the language without applying any sort of engineering logic to it. The people that find it relatively hard to learn have limited exposure to knowing exactly how and why something works, and typically are simply trying to do something with a lanuage they know little or nothing about. By and large, I tend to label these as, no pun meant twards anyone, but, 'Web Monkeys'. This isn't a bad thing, but perl wasn't really evolved for this type of environment. Languages such as Visual Basic and VBScript, or even better, PHP, where.. > - 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 Definatly nailed that one on the head. Thats why it is the way it is. > - Perl does some things which are commonly done in programming >languages very, very differently from the rest Hrm, I'm unsure exactly what you mean, the sentence seems off, but if I read the meaning, its that perl does things differently. This, I have to disagree with. It does things in a very simular manner as C. When treating perl using OO syntax, it looks nearly identical to using C code using OO methodologies by stuffing things in structs and calling it an object. The shortcuts that are provided, or 'magic variables', arent uncommon. There choice of NAMES could be thought of as wierd, I suppose.. ;-) > - Perl has a lot of obscure features and syntax, like the so-called >"magic" variables, that don't lend themselves to readable code Actually, I find most perl code alot easier to read then alot of C, C++, or java code around. You just cant read it as thought it where english. No one that isnt familiar with perl will be able to read them, thats for sure. So readable, yes, but not by an casual observer. > - 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 Becouse its funcational. It's a thought process I guess. I can pickup most perl modules and be able to read thru and know what they're doing a whole lot easier then many other languages. I think that perhaps its becouse things are more compact within the logic of the code, and hence, you have some very intense things going on in a relatively small space, as opposed to a more human readable form in a more descriptive language, where the cost of readability is obfuscated logic do to the human 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 Compare. A data structure within perl is called a module. A module in perl is the equivilant of a structure, or even better, a class, in other languages. I suppose this may be looked at from several standpoints, but from an engineering mindset, this is perfectly natural. Hell, a linked list is, technically speaking, a pointer to a pointer to a pointer to a pointer to a pointer to a pointer to a pointer (repeate adnasuem), and sometimes, the reverse, and, if someones really tricky, an indexed hodgepodge of memory locations. > - learning to do certain common programming tasks in perl is >unneccessarily hard Programing tasks is an interesting way to state it. Programming and engineering are two distinct things, and perl is much more an engineering language. > - reading and maintaining other people's code is unnecessarily hard > The last one is a key point. Maintai
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: 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: 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: 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
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
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: 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: 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: 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: 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 (K&R 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 (K&R 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 (K&R 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: 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: 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: 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) ]
[EMAIL PROTECTED] writes: > 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.) It was also known as "squoze code" around the M.I.T. AI lab. RAD50 may have originated at DEC, but I wouldn't bet either way. The description is close. Radix 50 actually allows you to get three characters into a 16 bit word (40*40*40 <= 65536), or 6 into a 32 bit word. 5 characters will actually fit into 27 bits (10240 being no greater than 134217728). That means that you can also have up to 5 bits of "flags", say, for symbol type, in the same (double 16 bit) word of your symbol table as that which stores the name. When it wasn't uncommon to have as little as 4k words (8k bytes) on your PDP-11/20, people really did care about bit twiddling. People writing in assembly language for such machines didn't seem to chaff at such symbol length restrictions. (Perhaps few of them could type, and short names were easier.) Linkers developed for use with assemblers were pressed into service for linking C because originally the C compiler produced assembly languagy, and the assembler was invoked on the output. Bill ___ 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) ]
On Wed, 21 Aug 2002, at 2:52pm, Bill Freeman wrote: > The description is close. Radix 50 actually allows you to get three > characters into a 16 bit word (40*40*40 <= 65536), or 6 into a 32 bit > word. Ya know, I thought a gain of only one character (five characters, vs the four 8-bit bytes in a 32-bit word) seemed too small, but I didn't actually do the math. Hypothesis: Since "creat" is a system call, and system calls are often implemented "behind the scenes" by functions with an underscore prefix (i.e., "_creat"), that might explain where the sixth character went. This debate only goes to show why Ken Thompson might well believe that the biggest mistake he made was spelling "creat" without the trailing "e". :-) -- 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) ]
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) ]
On Wed, 21 Aug 2002, at 6:44pm, Jon Hall wrote: > 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. 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... -- 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) ]
[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
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
On Thu, 22 Aug 2002, at 12:12am, Bayard R. Coolidge wrote: > Bayard, who tried, but failed to find his old copy of the > RIM loader... Okay, I have to ask: What's a "RIM loader"? -- 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) ]
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) ]
Or alternatively the service person could load the appropriate diagnostic into a machine and then carry the core memory module to the system that needed to be diagnosed. This could be very useful when the system you needed to repair was difficult to get at (sitting in a cramped closet, etc.). The memory module was easier to get at then trying to plug in a peripheral and it's controller. Once you had the core memory plugged into the system you would load the starting address of the diagnostic and then hit the "run" switch. -Alex P.S. Geez, I guess I am getting to be "older than dirt"! ;^) - Original Message - From: "Jerry Feldman" <[EMAIL PROTECTED]> To: "Greater NH Linux User Group" <[EMAIL PROTECTED]> Sent: Thursday, August 22, 2002 8:56 AM Subject: 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 > ___ 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) ]
Actually, WRT: Burger King, the PDP-8 was located under the counter. The AMF service guys were equipped with a briefcase mounted paper tape reader, and a few other things including the board. The POS maintained inventory, hourly sales by product, cash control, as well as the normal POS functions. The data was transmitted to Miami every night. There was only a single day's storage available. 100% of the software was written in PDP-8 assembler (Sabre I believe). Program changes were uploaded as necessary. All this in 4K memory. On 22 Aug 2002 at 9:18, Hewitt Tech wrote: > Or alternatively the service person could load the appropriate diagnostic > into a machine and then carry the core memory module to the system that > needed to be diagnosed. This could be very useful when the system you needed > to repair was difficult to get at (sitting in a cramped closet, etc.). The > memory module was easier to get at then trying to plug in a peripheral and > it's controller. Once you had the core memory plugged into the system you > would load the starting address of the diagnostic and then hit the "run" > switch. > > -Alex > > P.S. Geez, I guess I am getting to be "older than dirt"! ;^) > > - Original Message - > From: "Jerry Feldman" <[EMAIL PROTECTED]> > To: "Greater NH Linux User Group" <[EMAIL PROTECTED]> > Sent: Thursday, August 22, 2002 8:56 AM > Subject: 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 > > > -- 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: > 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: Thu, 22 Aug 2002 00:12:36 EDT "Bayard R. Coolidge" said: >[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. I thought they were PDP-7s, no? If so, then they wouldn't need to back-port to the 8, would they? Though for some reason, I thought that the 7 and 11 were closer in architecture and that the 8 was totally different than anything else. >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. Different from the 7 *and* 11, or just different from the 11? -- 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: Thu, 22 Aug 2002 09:02:50 EDT Jon Hall said: >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. Okay, I've got to ask. Anyone here actually have this 204 switch-toggling sequence *still* memorized after all these years? ;) -- 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: Thu, 22 Aug 2002 08:56:37 EDT "Jerry Feldman" said: >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. You know, I just heard someone complaining that the quaility of "service" people has taken a drastic drop in the last 20-30 years. I guess if, to work for Burger King inthe 1970s you needed to be able to operate a PDP-8 class machine you'd have to be a whole lot smarter than those "touch screen monkeys" they have now-a-days, which explains why QoS at the burger joints has gone down hill ;) -- 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