penguicon-comphist Mailing List for Penguicon
Brought to you by:
mute_id10t
Menu
▾
▴
penguicon-comphist — Computer History discussion.
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(131) |
Jul
(70) |
Aug
(11) |
Sep
(10) |
Oct
(19) |
Nov
(2) |
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(1) |
Feb
(1) |
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
(30) |
Aug
(33) |
Sep
(82) |
Oct
(22) |
Nov
|
Dec
|
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
(3) |
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
(2) |
| 2004 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Paul & L. <ea...@uc...> - 2004-03-05 04:31:35
|
Hi, Since you took a chance and opened this e mail we'd like to give you a gift to help you in this new year (a great gift). If 2003 was a year you rang up credit card debt and you're ready to find new options to deal with it... and bankruptcy is something you'd rather not do... ...Check out the information below and if you decide to request information ---Everyone who does between today (March 3rd) and midnight March 5th, will recieve a very valuable report as a gift for inquiring. We can't place a value on the gift because we don't sell this report, you can't buy it anywhere. No question, some would say it's worth hundreds. This stunning report will show you every dirty trick the lenders use to take advantage of you while making lots of profit for themselves (all the predatory lending practices you will never fall prey to again). This report will be emailed to you on March 6th if you decide to request more information from the website below. This program can get rid of credit card debt! This is NOT consolidation, reduction or counseling. http://CreditandDebtOptions.biz Thanks- and a safe and Blessed year to you, Paul and Linda If you DO NOT want us to send more mail --- HELP US HELP YOU - use the below web address ONLY. By replying to this email you risk not being processed. Use this address -- http://NoMoremail.biz B.L.M.,LLC 2657 Windmill Parkway #511 Henderson, NV 89074 Phone 702 380 7875 "We promote responsible marketing" We find unique things, but we respect and will honor your wishes if you choose to leave. |
|
From: Rob L. <ro...@la...> - 2003-12-31 23:16:51
|
I have a BOATLOAD of computer history stuff. Wow. Just unpacked a lot of it onto bookshelves. Did I ever mention that I've been scanning in old magazines? http://www.landley.net/history/mirror/scans I think... I'm in the process of updating my old "build a system from source" bash script to be LFS 5.0 based (then busybox and uclibc), and I'm going to use that at the end of my new cable modem (half a megabye per second upload bandwidth, unlimited usage), and finally host my website somewhere it could survive being slashdotted (or farked) if I put up something interesting. Then I can finally redo it to have interesting stuff on it. :) Grad school continues apace. Penguicon 1.0 went fine and 2.0 is on track. I'm starting a southern version (Linucon), and I hope to have some computer history displays there. That's not til october 2004, though... On the computer history front, I've been busy going through lots and lots and lots of old computer books and magazines. On top of that, I'm back within range of the UT library, and as a graduate student I can check out books for four months at a time. I am abusing this priviledge. :) Rob |
|
From: Rob L. <ro...@la...> - 2003-10-06 20:20:26
|
I wonder where they got the email address? :) I'm in grad school. It's taking up all my time at the moment. I've also moved, and am still unpacking. My current page full of computer history stuff is at www.landley.net/history (with the mirror and scans pages underneath). I'm still updating it, just not having much collating or analysis time at th emoment... Rob |
|
From: Rob L. <ro...@la...> - 2003-07-22 15:22:55
|
Well, I've come to rest. I need to get my computer history site (www.landley.net/history, I think) parked on something that ISN'T the end of a fairly slow DSL line, and I need to get a scanner to scan in the zillions of magazines (a new batch arrived just recently)... I've gotten a huge amount of new material (by weight) in the past six months, and I need to collate it all... Sigh... Rob |
|
From: joanne p. <joa...@em...> - 2003-07-16 07:08:59
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <title>Untitled Document</title> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> </head> <body> <span style='mso-bidi-font-size:10.0pt'>Find out if your boss, spouse or a criminal is spying on you<o:p></o:p></span> <p>Also if you have downloaded any music, movie clips, or games then your computer may be infected with SpyWares and AdWares!</p> <p class=MsoNormal>Advertisers use downloadable music as a vehicle to "legally" add</p> <p class=MsoNormal>SpyWares and AdWares to consumer PCs. If you're suspicious that</p> <p class=MsoNormal>Your system is infected then here's your chance to scan your computer free of charge.</p> <p class=MsoNormal>Just click below:</p> <p class=MsoNormal><a href="http://www.spydetector.net/">http://www.spydetector.net</a></p> <p class=MsoNormal><span style='color:blue'><strong><font color="#000000" size="3">This is the only spy detection software that protect you against </font></strong></span><font size="3"><strong><span style='color:red'>99.9%</span><span style='color:blue'> <font color="#000066">of all Spywares</font><o:p></o:p></span></strong><span style='color:blue'><o:p></o:p><o:p></o:p><o:p></o:p><o:p></o:p></span></font><span style='color:blue'><o:p></o:p></span></p> <p class=MsoNormal>"Spyware" is a common term for files that are installed on your system without your knowledge that allow the user to monitor your PCs activities surreptitiously, Silently your PCs Data and your habits are being documented for review and potential use against you.<span style="mso-spacerun: yes"> </span><span style='color:red'>.</span> <br> Spyware devices take many forms: keysroke loggers, web activity recorders, program access monitoring devices, password grabbers, and recovery programs, instant message recorders, email monitors and redirectors, and many more.<span style="mso-spacerun: yes"> </span></p> <p class=MsoNormal><b><span style='color:red'>WARNING: </span><span style='color:blue'>Virus softwares such as Mcafee and Norton Anti-Virus protect you against viruses not Spywares</span></b><span style='color:blue'>. <o:p></o:p></span></p> <p class=MsoNormal> </p> <p class=MsoNormal> </p> <p class=MsoNormal><span style='mso-bidi-font-size:10.0pt'>If you don't want more emails from us please e-mail: <a href="mailto:no...@em...">no...@em...</a><o:p></o:p></span></p> <p class=MsoNormal><span style='mso-bidi-font-size:10.0pt'>This email was sent using an evaluation version of ESMTP @Engine <a href="http://www.esmtp.net/">http://www.esmtp.net</a> <o:p></o:p></span></p> <p class=MsoNormal><span style='mso-bidi-font-size:10.0pt'>The world fastest email delivery software <o:p></o:p></span></p> <p class=MsoNormal><span style='mso-bidi-font-size:10.0pt'>@Engine is not spamming software and ESMTP does not send or encourage the sending of unsolicited email.<span style="mso-spacerun: yes"> </span><o:p></o:p></span></p> <p class=MsoNormal><span style='color:blue'><o:p></o:p></span></p> </body> </html> hCmZYtkBmskBEhGtLRxOtLRLrLBYFkCMBFZCrmCR |
|
From: Rob L. <ro...@la...> - 2003-07-13 06:32:03
|
On Monday 23 June 2003 08:21, Holzrichter, Bruce wrote: > >I have a new email address, and a new webpage. (Penguicon 1.0 happened in > > the > > >meantime, and was a smashing success, by the way.) > > Those Compute! Bring back some memories! > > >My new web page is www.landley.net, and the sub-page for this thing is: > > > >http://www.landley.net/history > > Current events in the *nix landscape could be creating and interesting > chapter in your book, depending on when you plan to deliver it to the > masses. ;o) > > B Current events in the *nix landscape have distracted me from working on the book at the moment. (I co-authored OSI's sco-vs-ibm position paper with Eric Raymond, and that was by no means the end of it...) But I should be back in Austin in about a week, and unpack my library shortly thereafter. I've scanned in a lot of stuff. (You may notice that there's the old "mirror" section, and also "scans" under the above link.) The scans are some of the magazines I've collected, with thumbnails. Way less than 1% of what I've got, of course. And I just got another batch in from norway (which I have to send off cash for postage for, once I get settled...) Rob |
|
From: Holzrichter, B. <bru...@mo...> - 2003-06-23 12:21:42
|
>I have a new email address, and a new webpage. (Penguicon 1.0 happened in the >meantime, and was a smashing success, by the way.) Those Compute! Bring back some memories! >My new web page is www.landley.net, and the sub-page for this thing is: > >http://www.landley.net/history Current events in the *nix landscape could be creating and interesting chapter in your book, depending on when you plan to deliver it to the masses. ;o) B |
|
From: Rob L. <ro...@la...> - 2003-06-01 03:53:11
|
It's been a while since I've posted to this list, hasn't it? I have a new email address, and a new webpage. (Penguicon 1.0 happened in the meantime, and was a smashing success, by the way.) My new web page is www.landley.net, and the sub-page for this thing is: http://www.landley.net/history Under that are two directories. One is scans, where i've started to scan in the huge pile of magazines I've accumulated. I've gone through about 0.1% of what I've got. Scanning magazines in is SLOW. Sigh... The mirror I've been accumulating (the other subdirectory) has gotten fairly large. It's now over 100 megabytes of mirrored stuff, actually. And that's not even counting the episodes of "computer chronicles" that archive.org has, which are just too big for me to mirror. (Gary Kildall was co-host of their first episode, you know...) I'm also reading (#*%#7 enormous) my pile of books. I read each one twice, and take notes on the second pass. I should put the notes on the web page as well. I should start hosting my own mailing lists, as well. (I kind of fell off this one when my email address changed a while back. Hi.) Now that I've got my own website, I'm probably going to start a computer history column to get material written down, and organize into some kind of narrative later... Rob |
|
From: Rob L. <la...@tr...> - 2002-10-06 21:06:00
|
On Sunday 06 October 2002 03:45 am, Alan Chandler wrote: > > > b) Writing detailed design documentation before even coding (we had an > > > a4 sheet form with details of each major subroutine - what it was for, > > > what its input and output parameters were etc) > > > > Bureaucracy. Flowcharting still sucks. I tend to change the design two > > or four times in the course of writing ANYTHING. I usually don't have a > > full understanding of the problem until I've seen why my first pass > > doesn't work... > > Remember we were working in assembler - it was part of the thought process. > The text in these forms were transfered into code headers when the coding > started. I started in basic and worked my way up. To me, assembler has always been performance critical snippets you glue into larger programs. The only standalone assembly-only programs I've ever written (not counting the ones for my old assembly class) were actually written in a monitor, not an assembler. So it was closer to machine language than assembler, really, since there was no text file to binary conversion step except one instruction at a time. (I.E. instruction layout in memory was done by hand.) > > > c) Writing lots and lots of comments in the code itself. I remember > > > writing a comment at the end of almost every line of assembler AND > > > writing a stand alone comment about every 5 or 6 lines. > > > > There's a school of thought that says too MUCH commenting is a bad thing. > > We were working in assembler where function names were limited to 6 > characters. I would say that we moved into C the amount of comments > dropped of quite a bit. However, I am still of the opinion that most > people put far to little explanation of what a lump of code is trying to do > in to it. > > In the past year I have delved into a few pieces of open source software to > try and get to understand them and in lots of cases there are pages and > pages of complex code and absolutely no explanation to go with it. Yup. Skill at documenting is in short supply. On the other hand, you have a lot of code written by people like Andre Hedrick (Linux kernel IDE guy), who apparently do not have english as a first language and are barely understandable in email. > > I went through some code reviews at IBM. It was a political ordeal, > > where hidebound bureaucrats imposed their One True Coding Style on > > everybody else. Not to match the code that was there, but to refactor the > > whole project to be the way they wanted it to be before approving single > > line changes. > > Oh dear, you really had it bad. Our code (and design) reviews were mostly > peer to peer, so it wasn't a question of "approval" more a cross check on > quality. "Hi, this is tested and it works, can you spot any bugs?" "I don't like your variable names." "This is a bug?" "Yes." Something very similar to the above conversation did indeed take place. The objection was, in fact, to local variables. The code reviews in this case were well after the fact. I DID bounce all sorts of stuff off of Pete and Glen as I was architecting and implementing it, but that didn't count. > I had a period during the 90's where, amongst other things I was > responsible for quality in our subsidiary (300 programmers approx). One of Ah yes, the old dilbertian "quality". "The most noticeable qualities of this project are that it smells bad and tends to explode suddenly." > wide dictact that we should use Yourdon as our methodology. I then spent a > few years on a crusade to ensure that our "Software Engineering Policy" was > constructed in such a way that those working on the problem had the ability > to decide the best approach to solving it. The fact that this was in question says to me the company has gone beyond the Bureaucracy Event Horizon... > One of the approaches that we > took was the introduction of process reviews - where the people doing the > work reviewed the quality control proceedures to see how they could improve > them. I have yet to see the imposition of a procedure that could force people to think. I have yet to see the imposition of a procedure review procedure that didn't become recursively abstract and degenerate into navel gazing. But YMMV. Back at IBM I tended to come in on evenings and weekends and get actual work done, and then present people as a fait accompli things they'd dismissed as impossible to do. Annoyed the heck out of some of them, took up a lot of my free time, and half the work got thrown out anyway, but it really was the only way to get anything done. Rob |
|
From: Alan C. <al...@ch...> - 2002-10-06 07:44:55
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 04 October 2002 11:56 pm, Rob Landley wrote: > On Friday 04 October 2002 07:32 pm, Alan Chandler wrote: =2E.. > > b) Writing detailed design documentation before even coding (we had a= n a4 > > sheet form with details of each major subroutine - what it was for, w= hat > > its input and output parameters were etc) > > Bureaucracy. Flowcharting still sucks. I tend to change the design tw= o or > four times in the course of writing ANYTHING. I usually don't have a f= ull > understanding of the problem until I've seen why my first pass doesn't > work... > Remember we were working in assembler - it was part of the thought proces= s. =20 The text in these forms were transfered into code headers when the coding= =20 started. > > c) Writing lots and lots of comments in the code itself. I remember > > writing a comment at the end of almost every line of assembler AND > > writing a stand alone comment about every 5 or 6 lines. > > There's a school of thought that says too MUCH commenting is a bad thin= g. We were working in assembler where function names were limited to 6=20 characters. I would say that we moved into C the amount of comments drop= ped=20 of quite a bit. However, I am still of the opinion that most people put = far=20 to little explanation of what a lump of code is trying to do in to it. In the past year I have delved into a few pieces of open source software = to=20 try and get to understand them and in lots of cases there are pages and p= ages=20 of complex code and absolutely no explanation to go with it. =2E.. > I went through some code reviews at IBM. It was a political ordeal, wh= ere > hidebound bureaucrats imposed their One True Coding Style on everybody > else. Not to match the code that was there, but to refactor the whole > project to be the way they wanted it to be before approving single line > changes.=20 Oh dear, you really had it bad. Our code (and design) reviews were mostly= peer=20 to peer, so it wasn't a question of "approval" more a cross check on qual= ity. I had a period during the 90's where, amongst other things I was responsi= ble=20 for quality in our subsidiary (300 programmers approx). One of my mantra= s=20 was that quality assurance was not about bureaucracy but about adding rea= l=20 value. As a manager I had earlier personally suffered when the major pro= ject=20 in my division went badly adrift (in design terms - but then as a result,= in=20 quality of the finished product - and then as a side effect, in money ter= ms,=20 as the development struggled to reach and end, and then the support costs= =20 went through the ceiling) as a result of a company wide dictact that we=20 should use Yourdon as our methodology. I then spent a few years on a cru= sade=20 to ensure that our "Software Engineering Policy" was constructed in such = a=20 way that those working on the problem had the ability to decide the best=20 approach to solving it. One of the approaches that we took was the=20 introduction of process reviews - where the people doing the work reviewe= d=20 the quality control proceedures to see how they could improve them. =20 - --=20 Alan Chandler al...@ch... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE9n+oNuFHxcV2FFoIRAje8AJ91GcnNCFI/jgGVa84PYlirI7gqoACdHeoH rt6qgRAN/N3coNVn3EtyXLg=3D =3DrORG -----END PGP SIGNATURE----- |
|
From: Rob L. <la...@tr...> - 2002-10-06 01:28:05
|
On Friday 04 October 2002 07:32 pm, Alan Chandler wrote: > On Wednesday 02 October 2002 9:26 pm, Eric S. Raymond wrote: > > I am *glad* this kind of programming is dying out. And I say that as > > somebody who did a lot of it back when it was necessary. I'll say > > this once: > > > > MAINTAINABILITY IS MORE IMPORTANT THAN EFFICIENCY > > > > No, that wasn't the case fifteen years ago, or even ten. Machines were > > too constrained. But today, if I were managing a project and caught > > anybody doing tricks like you describe, I'd chew him out but good. There > > is such a thing as being too clever in the wrong direction, and this is > > it. > > I would say that maintainability has always been more important than > efficiency. It was certainly in my thinking 30 years ago. In those days I > coded in assembler (PDP Macro 11) but we (our project team) spent lots of > time and effort in Part of this is just experience. Until you, personally, have had these kind of things come back to haunt you in your own code, you tend to blame it on the other guy being an idiot. With me it took almost ten years to start compulsively documenting, although that wasn't constant programming. (Two or three years were spent on an amiga, with no development tools, writing english instead of code. Hmmm... And 82 to 90 is only about 8 years.) So more like five or six years of actual "lone wolf" programming experience. Maintainability vs efficiency is always a trade-off, and as storage and computing cycles have gotten cheaper the balance keeps swinging more and more towards maintainability. Stuff used to be written in machine language. Then in assembly (variable names are a form of documentation). Then in higher level languages. Functional programming was about maintainability. Object oriented programming is entirely about modularizing the code to make it maintainable... The Y2K thing was just cleaning up and throwing out legacy cruft... Portability is another kind of maintainability. > a) Making the design simple so that the code would not need to be > convoluted. This design was always documented in a technical spec - which > would start with an overview and progressively get more detailed until... > b) Writing detailed design documentation before even coding (we had an a4 > sheet form with details of each major subroutine - what it was for, what > its input and output parameters were etc) Bureaucracy. Flowcharting still sucks. I tend to change the design two or four times in the course of writing ANYTHING. I usually don't have a full understanding of the problem until I've seen why my first pass doesn't work... Maybe I'm just slow. :) > c) Writing lots and lots of comments in the code itself. I remember > writing a comment at the end of almost every line of assembler AND writing > a stand alone comment about every 5 or 6 lines. There's a school of thought that says too MUCH commenting is a bad thing. The linux-kernel group goes a bit overboard here, but they do have a point. They care deeply about choosing good function names, variable names, structure groupings, etc. And they write up fairly long documentiontion in another directory, and are starting to insert auto-extracted docbook But if you merge a chunk of code that's got comments every three lines, Linus will chew you out. The thing is, comments go stale when the code changes. Sometimes not the immediate area of code, either. And a misleading comment is WORSE than useless. Lots of time has been wasted debugging to comments that don't match the code. The Linux guys generally say if you need much more than a comment at the start of the function to tell you what it does, and then a couple of quick mentions of particularly tricky bits, you should probably rewrite your function to be more obvious. (Do less per line, etc.) Dunno how much I agree with them, my natural style's a bit more verbose than theirs. But then I use 2 space tabs, and they insist on 8 space tabs... :) It's another balance thing. The less active development a section of code is likely to see, the more comments it will probably need. > We did have to do things like pack several flag bits into a word along with > other data, but we always had a detailed documentation showing the layouts > with comments as to why they were like they were. There was one particular > system I first developed in 1975, and we were still developing in the mid > 80's. We had all the internal data structures documented in the "Don't > Panic Guide". This was a paper document - of about 50 pages > > These projects were often fixed price - delivery of a working system to a > customer for a fixed amount of money. Even within the scope of one project > we felt it was worth the time and effort to do the design and document it, > conduct design reviews within the projects and do code reviews of peoples > code after it had been written, but before testing - to check for style and > comments (to weed out the sorts of bad behaviour described in the previous > posts). I went through some code reviews at IBM. It was a political ordeal, where hidebound bureaucrats imposed their One True Coding Style on everybody else. Not to match the code that was there, but to refactor the whole project to be the way they wanted it to be before approving single line changes. It wouldn't have been so bad if we hadn't (for political reasons) had to get approval from another department for our code changes. (I believe they thought that cross-pollination between departments might make us hate each other enough for physical violence to reduce headcount and save them some early retirement incentives. I'm not sure.) I solved it using standard dealing with bureaucracy techniques: went back to my office, worked on other stuff, and let the problem fester until the requirement went away or somebody else dealt with it. Everybody should work for a bureaucracy once. It's like a trial by fire... Had a bad mental image of mandatory code reviews ever since. Having somebody else look at your code, spot problems, and give you their opinion is no problem. Having somebody else arbitrarily and capriciously sign off on your changes on a line by line basis is just evil. Rob |
|
From: Alan C. <al...@ch...> - 2002-10-04 23:32:16
|
On Wednesday 02 October 2002 9:26 pm, Eric S. Raymond wrote: > I am *glad* this kind of programming is dying out. And I say that as > somebody who did a lot of it back when it was necessary. I'll say > this once: > > =09MAINTAINABILITY IS MORE IMPORTANT THAN EFFICIENCY > > No, that wasn't the case fifteen years ago, or even ten. Machines were > too constrained. But today, if I were managing a project and caught > anybody doing tricks like you describe, I'd chew him out but good. The= re > is such a thing as being too clever in the wrong direction, and this is= it. I would say that maintainability has always been more important than=20 efficiency. It was certainly in my thinking 30 years ago. In those days= I=20 coded in assembler (PDP Macro 11) but we (our project team) spent lots of= =20 time and effort in=20 a) Making the design simple so that the code would not need to be convolu= ted. =20 This design was always documented in a technical spec - which would start= =20 with an overview and progressively get more detailed until... b) Writing detailed design documentation before even coding (we had an a4= =20 sheet form with details of each major subroutine - what it was for, what = its=20 input and output parameters were etc) c) Writing lots and lots of comments in the code itself. I remember writ= ing a=20 comment at the end of almost every line of assembler AND writing a stand=20 alone comment about every 5 or 6 lines. We did have to do things like pack several flag bits into a word along wi= th=20 other data, but we always had a detailed documentation showing the layout= s=20 with comments as to why they were like they were. There was one particul= ar=20 system I first developed in 1975, and we were still developing in the mid= =20 80's. We had all the internal data structures documented in the "Don't P= anic=20 Guide". This was a paper document - of about 50 pages These projects were often fixed price - delivery of a working system to a= =20 customer for a fixed amount of money. Even within the scope of one proje= ct=20 we felt it was worth the time and effort to do the design and document it= ,=20 conduct design reviews within the projects and do code reviews of peoples= =20 code after it had been written, but before testing - to check for style a= nd=20 comments (to weed out the sorts of bad behaviour described in the previou= s=20 posts). --=20 Alan Chandler al...@ch... |
|
From: Rob L. <la...@tr...> - 2002-10-03 04:07:36
|
On Wednesday 02 October 2002 08:57 pm, Patrick O'Callaghan wrote: > Rob Landley wrote: > >One advantage of the 8 bits is there wasn't enough space to get truly > > lost. No mater how intricate, non-obvious, or obfuscated, it was still > > 64k of ram, and you could read through the whole thing from start to > > finish, in hex, in a couple hours. Maintainability pretty much took care > > of itself. > > If I may pick a nit: 64k corresponds to a 16-bit address space. Whether > the machine is > what was usually called 8-bit or 16-bit is neither here nor there in > this regard. A PDP-11 > (without the MMU) could only address 64kb of memory and early versions > of Unix > actually ran on such things. I vividly remember spending rather more > than a couple of > hours debugging device drivers, and that wasn't even in hex :-) True. The data lines and the address lines aren't coupled. On the other hand, I don't know of any machines that only had 256 bytes of RAM. :) (Even the 4004 could address 4k. The atari 2600 only had I believe 128 bytes of RAM, but it used a 6502 with a 64k address space and a lot more ROM than RAM (although not as much as you'd think. :).) The original PC had 16-64k of ram, depending on how much you ordered. That put it smack up against the 8 bit market, and the CP/M machines (which, with their 8080 processor also had 64k address space. And 8 bit registers). But the chip in it had a much larger address space (albeit in 64k chunks, since it was really an 8080 design with bits bolted on...) Most of the early programs didn't bother with segments, hence things like gwbasic which could only handle 64k of ram no matter how much was installed. This was actually the big win Lotus 1-2-3 had over the DOS port of visicalc. Visicalc was from the 8 bit machines, it could only deal with 64k of ram. Lotus 1-2-3 could handle any amount DOS could handle. (That and the ability to scroll the screen display and handle more cells than you could display at one time, which is more or less related to having more memory to play with...) > poc Rob |
|
From: Eli <el...@pf...> - 2002-10-03 01:17:18
|
On Wednesday 02 October 2002 03:26 pm, Eric S. Raymond wrote: [snip] > I am *glad* this kind of programming is dying out. And I say that as > somebody who did a lot of it back when it was necessary. I'll say > this once: > > MAINTAINABILITY IS MORE IMPORTANT THAN EFFICIENCY > > No, that wasn't the case fifteen years ago, or even ten. Machines were > too constrained. But today, if I were managing a project and caught > anybody doing tricks like you describe, I'd chew him out but good. There > is such a thing as being too clever in the wrong direction, and this is it. No argument here... but... I think of it differently. When I was playing with GWBASIC, I was writing some fun little games. The graphics weren't half bad for a highschool freshman, and they were fun to make and play.... and I could play them as I made them. I outgrew what GWBASIC could do, and migrated to C. I never wrote any games in C. Graphics were too much of a hassle, and I had begun to try adding a 'design' phase to my development process. (With no formal programming education, I'll leave the definition of 'design' to your imagination ;). ) Programming had become hard. Bit twiddling was new territory, and I enjoyed it, but making something fun was just too much work. On a graphing calculator, you had to be clever, but it was fun, because you were stretching a _calculator_ to play tic-tac-toe against you (in Casio's 400 bytes), or making a chess board and using almost all its memory (TI's 90k). Years passed; I discovered operating systems, got a job doing Linux kernel work. Lots of fun and challenge. But I am one of those fellows that works very hard at being lazy. I had, in my quest for automation, out-grown shell scripting. Yeah, I could do anything in a shell, but good data structures make life a lot easier, and doing any 'real' processing on data was becoming rube-goldbergesque. Quickly getting a program that was "useful" (for an ever-increasing definition of "useful") was getting too painful. So I started looking for a new language to learn. I knew C/C++, and C++ was^Wcould be an improvement, but it was still 'C' to me. I'd seen Java, and it felt like C+=2 which wasn't what I wanted either. Perl just looked like $#!^. I've read a lot about the 'power of Lisp', but I've used ((L),(I),(),(S),(P))... thanks, but no thanks. Then I found Python. The language looked much more high-level, and I could do things with it that I had emulated in C++ (passing a pointer to a member function of a specific object for instance). And it had ready access to GUI toolkits. I've found that programming is fun again, and I'm finally toying with a game idea to implement in Python. (Well, now that I've found PyQt and dumped tkinter... Documentation!!!!) That gets me utilities that are _useful_ very _quickly_. They may be sluggish, but on a decent modern PC, they're fast enough, and can automate things with a click of the mouse that would take me much longer than if I were doing it myself. So what happens when I run into something that is just too slow? Profile to find the hot spots, improve those algorithms if I can, but if I really just need a piece of code to execute faster, I can buy a faster PC or implement just that algorithm in C/C++, and call it from Python. (Or so I've read; I haven't needed to go that far... it's usually algorithmic in nature.) In other words, I can create something that does 0.1% of what I need, and use it, freeing up time to develop the next 0.1% smoothly. It may not handle 10GB inputs, but I don't have those yet, and when I do, I know I can easily make the needed changes _then_. Useful now, better later. Writing 'tight', 'clever' code takes too long. I want to be _using_ this program already! (If laziness is a virtue, is impatience? ;) ) (Note that this doesn't necessarily apply in all areas... kernel work for example. If it has to be reliable, or deal with hostility, the rules change.) Now where'd I leave my asbestos underwear? ;) Eli |
|
From: Patrick O'C. <po...@us...> - 2002-10-03 01:12:53
|
Rob Landley wrote: >One advantage of the 8 bits is there wasn't enough space to get truly lost. >No mater how intricate, non-obvious, or obfuscated, it was still 64k of ram, >and you could read through the whole thing from start to finish, in hex, in a >couple hours. Maintainability pretty much took care of itself. > If I may pick a nit: 64k corresponds to a 16-bit address space. Whether the machine is what was usually called 8-bit or 16-bit is neither here nor there in this regard. A PDP-11 (without the MMU) could only address 64kb of memory and early versions of Unix actually ran on such things. I vividly remember spending rather more than a couple of hours debugging device drivers, and that wasn't even in hex :-) poc |
|
From: Rob L. <la...@tr...> - 2002-10-02 23:08:51
|
On Wednesday 02 October 2002 05:16 pm, Thomas Dodd wrote: > But, you learned a lot from that. Sure, it would be overboard today, > except in embeded devices, but the skills are still usefull. Instead > bits in a byte, it could be bytes in a structure. Or accounting for > cache line length. Also important is knowing *when* to use it, and > documenting it, since comments in the source don't take up space > in the object code. > > But it's good to know how to trim the code when needed. Like a few K > from fitting in one ROM, and the next size up is 2x the cost. Ignoring > the memory footprint is not a good thing. Should I always allocate the > biggest structure I might need, or should I use only what I do need. In > the bloated world today, no consideration of memory is given. For performance, the cache stuff is far more important than most people realise. Modern processors are clock multiplied by almost 20 times the speed of the memory bus. The difference between something that fits in cache and something that doesn't is an order of magnitude. it's also something that desperately needs to be documented, yes. Writing something this way for purposes of cache coherence is NOT obvious. (For example, the linux-kernel guys are starting to learn that many of their inlines are counter-productive, and they're still mostly the original guys who wrote them...) > Should I use if-else or case? Do I these the most common case first or > last. Can I reduce the number of branches by changing the tests? Knowing > the hardware (and compiler) are impoortant there. Forest for the trees. I don't optimize to my compiler. Not even GCC, switching from 2.7 to egcs to 3.2 makes all that go totally out the window... > Documenting what is done is even more important when you use non-obvious > methods. But the methods have valid uses. Look at perl code. Oh please let's not. :) > It can be effecient and understandable. But not for long. > It can be ineffecient and impossible to follow. The default case. :) > > And we've all seen bloated code that is neither effecient nor > maintainable. Having looked at OO.org and Mozilla, I would have > nightmares if I ever saw Windows98/Me/XP or MS-Office. Often, the best way forward is to isolate a subsystem, document the interfaces between it and the rest of the system, and then rip it out by the roots and write a fresh implementation to those interfaces. Often you have to clean up the code a bit before there ARE anything similar to interfaces between subsystems. But that's a pretty important skill... > -Thomas Rob |
|
From: Rob L. <la...@tr...> - 2002-10-02 23:02:59
|
On Wednesday 02 October 2002 04:26 pm, Eric S. Raymond wrote: > > But the art of small code, using neat trick, like the unused bits > > of one variable for bools and condition registers is not done now. > > Imagine most x86 programmers trying to write code with just the > > 6502 register set (A, X and Y). > > I am *glad* this kind of programming is dying out. And I say that as > somebody who did a lot of it back when it was necessary. I'll say > this once: > > MAINTAINABILITY IS MORE IMPORTANT THAN EFFICIENCY I agree. But it's important to learn both. > No, that wasn't the case fifteen years ago, or even ten. Machines were > too constrained. And hence the Y2K problem. :) > But today, if I were managing a project and caught > anybody doing tricks like you describe, I'd chew him out but good. There > is such a thing as being too clever in the wrong direction, and this is it. One advantage of the 8 bits is there wasn't enough space to get truly lost. No mater how intricate, non-obvious, or obfuscated, it was still 64k of ram, and you could read through the whole thing from start to finish, in hex, in a couple hours. Maintainability pretty much took care of itself. Now with 128 megs of ram and zillions of gigabytes of hard disk, it's trivial to make something so incredibly big and nasty that even the author can't understand it after a while. Plus with that much system resources, the output of multiple programmers can be absorbed by a single machine, so you have interfacing between programmers as a big source of complexity... Managing the scale of your program is still the main problem, it's just the limiting factor switched from the capabilities of the box to the capabilities of the programmers. In a certain way, it's the same TYPE of problem, anyway... Rob |
|
From: Rob L. <la...@tr...> - 2002-10-02 22:36:43
|
On Monday 30 September 2002 11:50 pm, Catherine Olanich Raymond wrote: > > Slammed the heck out of the keys when it got key bounce (and I learned > > touch typing on a manual typewriter in 7th or 8th grade: chip used to > > complain I slammed his computer's keys. > > I learned to type on crotchety manuals myself; I understand. (I once > destroyed a manual typewriter by slamming it down onto the desk in a fit of > pique. Not percussive maintenance, mind you. But I suspect some of the > late model manuals were more delicate than the C 64.) :-) > > > Took years to stop doing that... That is one advantage the 8 bits had: they knew they were selling into the retail market for home users who were going to spill sodas on the thing, knock it off their desks, etc. And return it to the store (or try to actually USE the warantee) if it stopped working. Military field hardening had nothing on these people. :) > > But I actually didn't whack the thing too much. I treated it with > > approximately the care and respect I'd treat a toaster or vacuum cleaner. > > Like, next to none? :-) Next to, but not actually "none". I can see my toaster ceasing to work if thrown down a flight of stairs. I'd expect it to have a pretty good chance of surviving, but it might get broken. Rob |
|
From: Thomas D. <te...@cy...> - 2002-10-02 21:16:41
|
Sorry for so many copies of that. The server said it didn't send, then I saw 3 copies went through. Hopfully that's fixed now. Crappy power, and a broken UPS :) Eric S. Raymond wrote: > Thomas Dodd <te...@cy...>: >>But the art of small code, using neat trick, like the unused bits >>of one variable for bools and condition registers is not done now. >>Imagine most x86 programmers trying to write code with just the >>6502 register set (A, X and Y). > > > I am *glad* this kind of programming is dying out. And I say that as > somebody who did a lot of it back when it was necessary. I'll say > this once: > > MAINTAINABILITY IS MORE IMPORTANT THAN EFFICIENCY I would agree in most cases. But efficient code doesn't have to be unmaintainable. > No, that wasn't the case fifteen years ago, or even ten. Machines were > too constrained. But today, if I were managing a project and caught anybody > doing tricks like you describe, I'd chew him out but good. There is such > a thing as being too clever in the wrong direction, and this is it. But, you learned a lot from that. Sure, it would be overboard today, except in embeded devices, but the skills are still usefull. Instead bits in a byte, it could be bytes in a structure. Or accounting for cache line length. Also important is knowing *when* to use it, and documenting it, since comments in the source don't take up space in the object code. But it's good to know how to trim the code when needed. Like a few K from fitting in one ROM, and the next size up is 2x the cost. Ignoring the memory footprint is not a good thing. Should I always allocate the biggest structure I might need, or should I use only what I do need. In the bloated world today, no consideration of memory is given. Should I use if-else or case? Do I these the most common case first or last. Can I reduce the number of branches by changing the tests? Knowing the hardware (and compiler) are impoortant there. Documenting what is done is even more important when you use non-obvious methods. But the methods have valid uses. Look at perl code. It can be effecient and understandable. It can be ineffecient and impossible to follow. And we've all seen bloated code that is neither effecient nor maintainable. Having looked at OO.org and Mozilla, I would have nightmares if I ever saw Windows98/Me/XP or MS-Office. -Thomas |
|
From: Eric S. R. <es...@th...> - 2002-10-02 20:33:43
|
Thomas Dodd <te...@cy...>: > >And it really does develop skills that come in handy later. I used to do > >entire java projects in about 15k, when similar implementations were 500k, > >and they couldn't figure out how I was doing it and I couldn't imagine how > >they could be so completely clueless. (The ability to declare multiple > >classes doesn't mandate it, and the ability to create multiple threads or > >object instances does not require doing so either. Duplication of code or > >data is bad, but making a forest of "if" statements just so you can share > >three lines doesn't always make sense either. Think about what you're > >actually doing, try to understand what the machine's doing, actually > >measure things and measure the RIGHT things... Sigh...) Learning good, economicall design is very valuable, but,,, > But the art of small code, using neat trick, like the unused bits > of one variable for bools and condition registers is not done now. > Imagine most x86 programmers trying to write code with just the > 6502 register set (A, X and Y). I am *glad* this kind of programming is dying out. And I say that as somebody who did a lot of it back when it was necessary. I'll say this once: MAINTAINABILITY IS MORE IMPORTANT THAN EFFICIENCY No, that wasn't the case fifteen years ago, or even ten. Machines were too constrained. But today, if I were managing a project and caught anybody doing tricks like you describe, I'd chew him out but good. There is such a thing as being too clever in the wrong direction, and this is it. -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> |
|
From: Thomas D. <te...@cy...> - 2002-10-02 20:33:29
|
Rob Landley wrote: > Fitting the program you wanted to write into memory was always the big > challeng with the 8 bits. It's the programming equivalent of haiku, > requiring its own kind of creativity and having its own kind of beauty. Which was a large part of the fun too :) > And it really does develop skills that come in handy later. I used to do > entire java projects in about 15k, when similar implementations were 500k, > and they couldn't figure out how I was doing it and I couldn't imagine how > they could be so completely clueless. (The ability to declare multiple > classes doesn't mandate it, and the ability to create multiple threads or > object instances does not require doing so either. Duplication of code or > data is bad, but making a forest of "if" statements just so you can share > three lines doesn't always make sense either. Think about what you're > actually doing, try to understand what the machine's doing, actually measure > things and measure the RIGHT things... Sigh...) I'm always getting in trouble because of thaose habits. I try to make the code effecient, instead of writing it quickly. Example. code to read 10,0000+ lines of text and map it to a binary format. I started writing it read a line at a time from the input, use dynamic allocation of the binary storage, and make the memory footprint small. When that was takeing a while, I was told just use a static store all in memory, and let the OS handle it with swap. So I had static allocations of 2G. Ended up having to rewrite it when it had to be used on smaller memeory machines. But the art of small code, using neat trick, like the unused bits of one variable for bools and condition registers is not done now. Imagine most x86 programmers trying to write code with just the 6502 register set (A, X and Y). Most programmers today have zero understanding of what is happening behind their code. How many C programmers know what or how the printf() function works? So instead whe get huge bloatware, and need more RAM, disk, and ever faster CPUs to do the old stuff. I dislike most "modern" games because there all flashy graphics and sound, and no real game play. Thanks to MAME, I can still play Pac-Man, and Galaga. Amazing that after nearly 20 years those games are still fun, but the current games only last a few months. Or pull out you Atari 2600 (VCS if you prefer) and play Pitfall or River Raid. They are still playable, with only 4bit graphics. -Thomas |
|
From: Thomas D. <te...@cy...> - 2002-10-02 20:06:13
|
Rob Landley wrote: > Fitting the program you wanted to write into memory was always the big > challeng with the 8 bits. It's the programming equivalent of haiku, > requiring its own kind of creativity and having its own kind of beauty. Which was a large part of the fun too :) > And it really does develop skills that come in handy later. I used to do > entire java projects in about 15k, when similar implementations were 500k, > and they couldn't figure out how I was doing it and I couldn't imagine how > they could be so completely clueless. (The ability to declare multiple > classes doesn't mandate it, and the ability to create multiple threads or > object instances does not require doing so either. Duplication of code or > data is bad, but making a forest of "if" statements just so you can share > three lines doesn't always make sense either. Think about what you're > actually doing, try to understand what the machine's doing, actually measure > things and measure the RIGHT things... Sigh...) I'm always getting in trouble because of thaose habits. I try to make the code effecient, instead of writing it quickly. Example. code to read 10,0000+ lines of text and map it to a binary format. I started writing it read a line at a time from the input, use dynamic allocation of the binary storage, and make the memory footprint small. When that was takeing a while, I was told just use a static store all in memory, and let the OS handle it with swap. So I had static allocations of 2G. Ended up having to rewrite it when it had to be used on smaller memeory machines. But the art of small code, using neat trick, like the unused bits of one variable for bools and condition registers is not done now. Imagine most x86 programmers trying to write code with just the 6502 register set (A, X and Y). Most programmers today have zero understanding of what is happening behind their code. How many C programmers know what or how the printf() function works? So instead whe get huge bloatware, and need more RAM, disk, and ever faster CPUs to do the old stuff. I dislike most "modern" games because there all flashy graphics and sound, and no real game play. Thanks to MAME, I can still play Pac-Man, and Galaga. Amazing that after nearly 20 years those games are still fun, but the current games only last a few months. Or pull out you Atari 2600 (VCS if you prefer) and play Pitfall or River Raid. They are still playable, with only 4bit graphics. -Thomas |
|
From: Thomas D. <te...@cy...> - 2002-10-02 20:04:20
|
Rob Landley wrote: > Fitting the program you wanted to write into memory was always the big > challeng with the 8 bits. It's the programming equivalent of haiku, > requiring its own kind of creativity and having its own kind of beauty. Which was a large part of the fun too :) > And it really does develop skills that come in handy later. I used to do > entire java projects in about 15k, when similar implementations were 500k, > and they couldn't figure out how I was doing it and I couldn't imagine how > they could be so completely clueless. (The ability to declare multiple > classes doesn't mandate it, and the ability to create multiple threads or > object instances does not require doing so either. Duplication of code or > data is bad, but making a forest of "if" statements just so you can share > three lines doesn't always make sense either. Think about what you're > actually doing, try to understand what the machine's doing, actually measure > things and measure the RIGHT things... Sigh...) I'm always getting in trouble because of thaose habits. I try to make the code effecient, instead of writing it quickly. Example. code to read 10,0000+ lines of text and map it to a binary format. I started writing it read a line at a time from the input, use dynamic allocation of the binary storage, and make the memory footprint small. When that was takeing a while, I was told just use a static store all in memory, and let the OS handle it with swap. So I had static allocations of 2G. Ended up having to rewrite it when it had to be used on smaller memeory machines. But the art of small code, using neat trick, like the unused bits of one variable for bools and condition registers is not done now. Imagine most x86 programmers trying to write code with just the 6502 register set (A, X and Y). Most programmers today have zero understanding of what is happening behind their code. How many C programmers know what or how the printf() function works? So instead whe get huge bloatware, and need more RAM, disk, and ever faster CPUs to do the old stuff. I dislike most "modern" games because there all flashy graphics and sound, and no real game play. Thanks to MAME, I can still play Pac-Man, and Galaga. Amazing that after nearly 20 years those games are still fun, but the current games only last a few months. Or pull out you Atari 2600 (VCS if you prefer) and play Pitfall or River Raid. They are still playable, with only 4bit graphics. -Thomas |
|
From: Catherine O. R. <ca...@th...> - 2002-10-01 03:47:47
|
On Monday 30 September 2002 05:17 pm, Rob Landley wrote: > On Monday 30 September 2002 09:33 pm, Catherine Olanich Raymond wrote: > > > I'd like to point out that A) these were carpeted stairs, B) I didn't > > > do that. (Although Namaur, the head cat at the time, did like to sleep > > > right behind the thing on top of the cables while I was using it. > > > (Didn't bug me in the slightest, just wanted to feel involved, and > > > liked the heat it put out as well.) > > > > Actually, Namaur was in the safest place to be on the "percussive > > maintenance" front. He'd be safe back on top of the cables if you *had* > > She. Oops. Sorry. <blush> :-) > > decided to throw your C64 down the stairs, and he'd have adequate warning > > to move if you decided to pick up the machine or give it a whack in > > place. (But then, we both know cats are an advanced life form, and had > > millennia to refine their act before humans even came into the picture.) > > :-) > > Slammed the heck out of the keys when it got key bounce (and I learned > touch typing on a manual typewriter in 7th or 8th grade: chip used to > complain I slammed his computer's keys. I learned to type on crotchety manuals myself; I understand. (I once destroyed a manual typewriter by slamming it down onto the desk in a fit of pique. Not percussive maintenance, mind you. But I suspect some of the late model manuals were more delicate than the C 64.) :-) Took years to stop doing that... > :) I was lucky. I had to learn to use electric typewriters in law school, which require less force than a manual, and it weaned me away from whacking the keys too hard before I got my hands on my first computer. > But I actually didn't whack the thing too much. I treated it with > approximately the care and respect I'd treat a toaster or vacuum cleaner. Like, next to none? :-) -- Cathy Raymond <ca...@th...> "Linux isn't going to go away--our job is to provide a better product in the marketplace."--Steve Ballmer |
|
From: Rob L. <la...@tr...> - 2002-10-01 02:17:21
|
On Monday 30 September 2002 09:33 pm, Catherine Olanich Raymond wrote: > > I'd like to point out that A) these were carpeted stairs, B) I didn't do > > that. (Although Namaur, the head cat at the time, did like to sleep > > right behind the thing on top of the cables while I was using it. > > (Didn't bug me in the slightest, just wanted to feel involved, and liked > > the heat it put out as well.) > > Actually, Namaur was in the safest place to be on the "percussive > maintenance" front. He'd be safe back on top of the cables if you *had* She. > decided to throw your C64 down the stairs, and he'd have adequate warning > to move if you decided to pick up the machine or give it a whack in place. > (But then, we both know cats are an advanced life form, and had millennia > to refine their act before humans even came into the picture.) :-) Slammed the heck out of the keys when it got key bounce (and I learned touch typing on a manual typewriter in 7th or 8th grade: chip used to complain I slammed his computer's keys. Took years to stop doing that... :) But I actually didn't whack the thing too much. I treated it with approximately the care and respect I'd treat a toaster or vacuum cleaner. Rob |
14 messages has been excluded from this view by a project administrator.
