Chuck> I don't know if it's true anymore, but in the EDP world, Chuck> knowing how to do an efficient external sort on tape (cf: Chuck> oscillating merge, polyphase merge, cascade merge, balanced Chuck> merge) used to be a requirement for a programmer. Now, it's Chuck> probably a lost art. Not quite; it's still written up in detail in Knuth volume 3. Some of this stuff still makes sense. You still need external sort to sort really large data files, and algorithms that access the external files sequentially are still winners even with disk files. paul

At 12:48 PM 4/6/2009, Paul Koning wrote: As routine files are measured in gigabytes or larger, hard drives seem more like tape drives. It takes a while to move things. - John

In article <49D9DABB.6767.567DE224 at cclist.sydex.com>, "Chuck Guzis" <cclist at sydex.com> writes: Its not a lost art because several of these algorithms are documented in Knuth's Art of Computer Programming. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>

Or even lots over 30 - I'm 45 this July and I've never written a real polyphase merge sort, or indeed any other external sort. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

On 6 Apr 2009 at 15:12, Paul Koning wrote: But there's the "art" aspect. Anyone can paint by numbers or use a cookbook or program an algorithm given in a textbook. That doesn't make one a painter or a chef or a programmer-artist (I don't have a better word). I'm inclined to think that Knuth intended that expressive facility when he titlled his series "The Art of Programming", not "How to Program". But I wouldn't presume to put words in his mouth. Besides, I learned my sorting from the Flores book. :) --Chuck

Well, I'm 29 (30 this year!) and although I'm not a professional programmer I do pick up things on this list which I add to my 'something to learn' list. I can't say I'll know how to do it before I hit 30 (September) as I have too many other projects going right now, but I'll see if I can learn how to do it before I hit 31! Regards, Andrew B aliensrcooluk at yahoo.co.uk --- On Mon, 6/4/09, Chuck Guzis <cclist at sydex.com> wrote: From: Chuck Guzis <cclist at sydex.com> Subject: Re: The VAX is running To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> Date: Monday, 6 April, 2009, 7:59 PM On 6 Apr 2009 at 12:34, Richard wrote: So, pull a programmer under 30 at random from his desk and ask him to write a polyphase merge sort optimized for 8 tapes. An art may still be lost in practice even if there's literature around describing it. --Chuck

REVERSE LINE FEED? Never heard of that. What is a 3-up mailing label? That perforated roll of three mailing labels per line? I can do that in BASIC with just one of the hands.

??? Why not take three registers and print one line in three labels at once?!?! Am I being too dumb or was your friend too dumb? :oO

On Mon, Apr 6, 2009 at 6:28 PM, Fred Cisin <cisin at xenosoft.com> wrote: I think I wrote something like that in C for VMS about 20 years ago (without the backing up ;-). When I most recently did it (last year), it was much easier - I wrote a Perl script to emit Postscript, rendered each label in order and let the Postscript rendering engine worry about the details. But yes... one should be able to write it when it has to be one physical line at a time, no backsies. -ethan

Fred> I've run into "CS" graduates from the university who supposedly Fred> have learned about really "good" sort algorithms (usually Fred> "Shell-Metzner"), without understanding which situations an Fred> optimized "bubble" is better for. Fred> When presented with "write a sort for a database that is too Fred> large to fit into memory", the only response that they can Fred> think of is "well, get more memory." Fred> I fired one who was unable to write a program to print 3-up Fred> mailing labels because the printer didn't have a reverse Fred> line-feed! Fred> There are way too many "computer scientists" who haven't even Fred> read Knuth. "They only assigned a few specific pages" This is a good way to sort the ones worth hiring from those who are not. paul

Ian King wrote: Mine has always been to postulate a singly-linked list with each node containing a string value, then ask them to write something to print out the list in reverse order. There's a bunch of obvious ways to solve that problem; the nice thing about it is that depending on the answer that they give you can apply more constraints (copying isn't allowed, memory is constrained, optimize for speed, whatever) in order to better estimate their approach to solving problems. -- Chris Kennedy chris at mainecoon.com AF6AP http://www.mainecoon.com PGP KeyID 108DAB97 PGP fingerprint: 4E99 10B6 7253 B048 6685 6CBC 55E1 20A3 108D AB97 "Mr. McKittrick, after careful consideration..."

John Floren wrote: Only if you have an arbitrary amount of memory available. What if you're constrained to a handful of automatics? -- Chris Kennedy chris at mainecoon.com AF6AP http://www.mainecoon.com PGP KeyID 108DAB97 PGP fingerprint: 4E99 10B6 7253 B048 6685 6CBC 55E1 20A3 108D AB97 "Mr. McKittrick, after careful consideration..."

bfranchuk at jetnet.ab.ca wrote: That just makes the list shorter. :-)

On Mon, Apr 6, 2009 at 3:05 PM, bfranchuk at jetnet.ab.ca <bfranchuk at jetnet.ab.ca> wrote: And the list is being input forward-order over a 1 way serial link without flow control, has an unknown number of items, and you need to print it in reverse order on a 3 cps printer.

On Mon, Apr 6, 2009 at 5:59 PM, bfranchuk at jetnet.ab.ca <bfranchuk at jetnet.ab.ca> wrote: But the chimps are too busy scribbling down the numbers they see being displayed on the oscilliscope to pound on the typewriters. Do you think this company is made of chimps? Every day asking for more chimps... When we have to downsize you'll be sorry....

John Floren wrote: Recursion will eat up a lot of memory if the list is long. If memory is tight and nobody else is using the list, flip the pointer direction as you go down the list. When you hit the end, print it out, follow the pointers back to the beginning, flipping them back again. Or perhaps the singly linked list already stores the XOR of the forward and back pointers and so no flipping is necessary.

Jim Battle wrote: Yep. Which hints at what Eric offered up: The amazing thing is that well north of 90% of candidates don't bother to ask questions that would help them identify the most appropriate solution to the problem. The typical approaches are to repeatedly iterate, to recurse or to use an explicit stack (which is materially the same thing). Questions like "can I modify the list?" or "Is there anything that precludes changing the spec to make this a doubly-linked list" are rarely posed -- and when they are, I know I've got a keeper. The most tortured solution offered to date was the one where the guy proposed to create a doubly-linked list that contained pointers to nodes of the original list... -- Chris Kennedy chris at mainecoon.com AF6AP http://www.mainecoon.com PGP KeyID 108DAB97 PGP fingerprint: 4E99 10B6 7253 B048 6685 6CBC 55E1 20A3 108D AB97 "Mr. McKittrick, after careful consideration..."

Jochen Kunz wrote: Jochen -- First, I'd argue that then you aren't doing recursion; you have transformed recursion into iteration. For the stated problem, using recursion requires creating a stack frame for each node in the list, chewing up a lot of memory. It could be transformed into an iterative operation by having an auxiliary list to save the address of each node as you traverse the list, but that is eating up memory too (though likely much less than a stack frame per node). My proposed solution for low memory situations is iterative, but requires only a small, fixed amount of working space. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ This is only tangentially related, but it is connected by the need to use a small, fixed amount of scratch space to operate on large lists of data. Once upon a time, I disassembled a lot of the TRS-80 model III ROM. Part of that was the garbage collection routine. Because strings were dynamically allocated without any explicit recovery mechanism, the interpreter would on occasion have to sweep dead strings from memory. This gave the appearance of locking up the computer for long stretches -- the amount of time varied based on the amount of free memory and the number of active strings. It could easily take more than half a minute. The code was written to use the tiniest amount of scratch space. The garbage collector was something like this. One pointer was used to sweep through the variable table, looking for all strings, and after it swept the variable table, it would also sweep through the the currently active expression stack to find live strings there too. It would find the string with the lowest address and move the string at that location to the start of free string memory if it wasn't already located there, and patch up the variable table or expression stack to point to the new location. Then a second round was done, again looking for the lowest string address it could find which was also greater than the address just found in the previous iteration. On and on it would go until no new string was found. This is a classic O(n^2) algorithm, which is why the thing ran so slowly. I seem to recall it required only four bytes of storage other than using the CPU registers to do this sweep. If instead of waiting to do garbage collection until there was only four bytes left it invoked the garbage collector when, say, 64 bytes were left, they could have swept 16 live strings per pass. It would still be O(n^2), but it would have finished roughly 16 times faster. I'm pretty sure other MS BASICs used the same simple & slow garbage collector. I wonder how hard it would have been to put in an incremental garbage collector that ran during input prompts, and perhaps even while waiting for disk I/O. It wouldn't have helped the worst case, but it would have helped in the average case.

On Tue, Apr 7, 2009 at 11:01 AM, Pete Turnbull <pete at dunnington.plus.com> wrote: Always. The major problem with the MS-BASIC garbage collection was with the user experience. Gates chose rapid allocation through a top-of-heap pointer rather using a heap walker. While there was enough space for allocations, allocations were fast, but reallocation was impossible except at the top of the heap. Once garbage collection starts it must proceed to completion. The user experience, with sufficiently large memory, was of the computer hanging. Most users would power cycle rather than wait. The heap walker method slows allocations, but space can be reused without garbage collection, and once garbage collection is required, it can be short circuited once a sufficiently large free region is available for the current allocation. I can see why you'd want the Gates method on a 2k machine with 300 bytes available for program and data, but once BASIC started using 8K of address space for its own code on a machine with 32K+ of RAM, they could have found room for a better allocator and garbage collector. Eric

Marvin Minsky was never at SAIL (in the academic sense--he probably did visit at one time or another). His career was all at MIT; he is a contemporary of Noam Chomsky, the well-known linguist. Also, I think you are confusing the koan about Moon and the student who discovers reference-counting garbage collection, and the koan about Minsky's response to Sussman's random wiring of a neural net. Note that Sussman and Moon are contemporaries, along with Steele of Common Lisp fame. Garbage collection is in point of fact so nontrivial that many papers on the topic were published in CACM, JACM, and other ACM and IEEE pubs in the 60s, 70s and into the 80s. I read most of them when I was into LISP implementation. Rich Alderson Vintage Computing Server Engineer Vulcan, Inc. 505 5th Avenue S, Suite 900 Seattle, WA 98104 mailto:RichA at vulcan.com (206) 342-2239 (206) 465-2916 cell

AMOS Basic (for the Amiga) keeps all temporary text in one area, between LoChaine and HiChaine. When I was learning 68K ASM last year (July - Sept) I wrote a few commands for AMOS which crashed it - I was setting the HiChaine internal AMOS variable incorrectly (needed to be even!). To help with bugfixing my commands I wrote a "Set Hichaine ADDRESS" command (you could use it in Direct Mode where commands are run instantly, kind of like a CLI). The upside of this is that you can ditch all the text garbage instantly - a welcome bonus since AMOS' garbage collection is awful! Regards, Andrew B aliensrcooluk at yahoo.co.uk --- On Tue, 7/4/09, Pete Turnbull <pete at dunnington.plus.com> wrote: From: Pete Turnbull <pete at dunnington.plus.com> Subject: Re: The lost art (Was: The VAX is running To: "On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> Date: Tuesday, 7 April, 2009, 7:01 PM On 07/04/2009 17:40, Jim Battle wrote: of that was the garbage collection routine. Because strings were dynamically allocated without any explicit recovery mechanism, the interpreter would on occasion have to sweep dead strings from memory. This gave the appearance of locking up the computer for long stretches -- the amount of time varied based on the amount of free memory and the number of active strings. It could easily take more than half a minute. Garbage collection isn't as trivial as one might think. There's a trade-off between space and time, and there's a well-known story about a student of David Moon's at MIT(?), and Marvin Minsky (who wrote a pretty well-known GC at SAIL). Search Google for "Minsky garbage" and look up http://groups.csail.mit.edu/mac/users/dae/notes/ai-koans -- Pete Peter Turnbull Network Manager University of York

On 07/04/2009 20:32, Jim Battle wrote: No, I know you understand it! -- Pete Peter Turnbull Network Manager University of York

Or how many engineering managers think recursion has no place in production code. Recursion is really neat and clever, and really gives the academics the jollies, but is often a big red flag for unreadable, hard-to-maintain code in the real world. -- Will

cctalk-bounces at classiccmp.org wrote: Couldn't the answer be "loop from 2 to N=147, sum += ln(N)"? Or do I need another coffee? Antonio

Chris Kennedy wrote: 1) Print list out in conventional order. 2) Instruct user to turn their terminal upside-down. # 2 can be substituted with "instruct user to stand on their head" in the event of heavy terminals. (well all the sane answers were taken! :-)

And what did you do with the people who wrote (int)strtol(s,0,8)? :) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

Ian King wrote: Do you mean that the octal digits are packed one per 3 bits, or that each item in the string matches to one of the chars '0'..'7'? (I think I've seen the latter problem somewhere else - can't recall if it was an interview or some form of test, though, or even what language was expected to be used)

It was thus said that the Great Ian King once stated: Ah, but what about the student that uses strtol() or strtoul() (depending on if negative numbers are required)? About a decade ago, a friend of mine was interviewed for a C programming job, and was asked to read in a list of numbers and store them in a linked list (single pointer), within an hour (and yes, that's all the program had to do). When he finished in thirty minutes (after extensive testing to make sure it worked) he was told he was the *only* candidate to have finished the program in the alloted time frame. -spc (True story---I even knew the interviewer ... )

On Mon, 6 Apr 2009, der Mouse wrote: You don't think agree that even the theoretician should understand that some algorithms can take advantage of existing order and end early, while others are a fixed duration? Example: The library is doing a "retrospective conversion" of its card catalog to an OPAC ("Online Public Access Catalog"). The cards are mechanically scanned. They are nominally in order, however, due to being handled by humans, a lot, there "might be" some errors in sequence. "Might" - yeah, right. Which sort is "better"? "Shell-Metzner" or "shaker"?

On Sun, 12 Apr 2009, Roy J. Tellason wrote: Good. I'd hate to meet anybody who thinks that they already understand ALL of it! Try page 110 of Knuth's "Sorting and Searching" (Volume 3 of "Art of Programming" ISBN 0-201-03803-X) Rather oversimplified: Take a plain bubble sort; add a conditional test to end early if NO changes were made during a pass. Modify the end points of the passes, so that it doesn't bother going back through territory that has already achieved final order. So far, that is just optimizing the bubble sort algorithm. Now modify it so that it alternates the passes between going left to right and going right to left. THAT is a "Shaker Sort". It is just one variety of "Bubble Sort", and for worst case scenario (and almost as bad with truly random data), it could end up needing N-1 passes, with an average of N/2 (approx) comparisons in each pass, which is TERRIBLE performance. BUT, . . . if the data happens to already be in order, it will require ONE pass with N-1 comparisons, V Shell-Metzner still going through the same amount of work as for random data. Shaker will require a maximum of one more pass than the number of elements that are out of order. That ability to take advantage of existing order can be rather important in the real world. In addition to data that is partially in order, many managers who ought to know better, instead of merging data sets will append a small amount of new data to the end of a sorted data set and then "sort" to put it back into order. For a basic Bubble sort, that provides WORST CASE, with N-1 passes of ~N/2 comparisons per pass. Swapping endpoints so that the passes go right to left instead of left to right, immediately reduces it elements added. In an analogous situation, a compression algorithm that takes into account the type of data being compressed might outperform an algorithm that is theoretically significantly "better" for "random" data. -- Grumpy Ol' Fred cisin at xenosoft.com

Thanks for that. I for one hate learning something by text only, as you can sometimes mis-interprate it (something I do more often than I would like!), but if simple straight forward visuals are included (or examples) I can often understand things much quicker. Bubblesort is nice and easy to understand :) I have bookmarked that page and will look up the other sorting methods once I have more time on my hands. Regards, Andrew B aliensrcooluk at yahoo.co.uk --- On Mon, 13/4/09, Huw Davies <huw.davies at mail.vsm.com.au> wrote: From: Huw Davies <huw.davies at mail.vsm.com.au> Subject: Re: The lost art (Was: The VAX is running To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> Date: Monday, 13 April, 2009, 3:38 AM On 13/04/2009, at 7:52 AM, Fred Cisin wrote: "Art of For those of you who find pictures help understanding, take a look at: http://www.hatfulofhollow.com/posts/code/visualisingsorting/index.html This was a totally serendipitous find - I was just catching up on this week's Python news. Huw Davies | e-mail: Huw.Davies at kerberos.davies.net.au Melbourne | "If soccer was meant to be played in the Australia | air, the sky would be painted green"

What? No mention of the n-way polyphase sort/merge?

I had written.. To which Chuck replied... Most implementations of the n-way polyphase sort/merge that I have seen - have been "internal", with just the algorithm being described as "external sorts of tapes too large to fit into memory". It's a wonderful technique for multiple chunks of inordered data. Like the buckets in an ISAM type file.... Jay

On 6 Apr 2009 at 13:40, Fred Cisin wrote: Heh. When I worked on a compiler that produced on-line listings, the issue of printing the cross-reference list came up. Space was tight (this was a 64KB systerm) and disks (floppy) were slow. It turned out that a simple selection sort was more than adequate to keep the printer busy. Internal sorts were a gotcha on the STAR too. SInce *all* instructions were essentially vector (with scalar being treated as a vector of length 1), startup overhead for short vectors and scalars was hideous. For arrays of less than about 1000 words, a simple selection sort was faster than any of the "super-duper" algorithms, as one could use a single vector select instruction. --Chuck

Marketable skills ==> engineering degree Theoretical study ==> science degree That was always the interesting dilemma hiring people for a software engineering company: few people ever studied software engineering. I actually found that many of my best hires were those who had used computers within the discipline of an experimental science or an engineering program. -- Ian

Someone on the list (whose attribution wasn't passed on) So. Hmm... as one who has written plenty of embedded application code and firmware (boot ROMs) and quite a bit of user application code for 8-bit, 16-bit, and 32-bit processors for money (and 12-bit processors for fun), all I can say is you must be new. The short answer is one instruction at a time like a composer writes symphonies one note at a time. The overall effect is stunning, even if a single note/single instruction doesn't do much. Perhaps in building the skills to take a real-world problem apart into solvable components and abstract the steps necessary to produce a solution? It's something I see novice programmers struggle with. This comment reminds me of an idea put forth in Rick Cook's "Wizardry" series about a Cupertino programmer summoned to a land of magic and dragons. He, in essence, creates a language and compiler for magic spells. At one point, he describes the difference between himself (as a programmer and a person from a technological world) and the wizards of his new home from the standpoint of how their styles of "magic" are different. The traditional wizards study for years and years to learn a spell _exactly_ because they don't understand every nuance that contributes to the spell working. They see "this tree" or "this blade of grass" and seek to understand just that one instance. They can't generalize into class: tree and instance: this tree. One can learn "a language" or "a computer", but when that language or that vendor or that architecture fades from prominence, it's a lot harder for that person to keep current than learning how "languages" or "computers" work with each different one being an instance of a class. I myself know plenty of compiled languages and plenty of scripted and/or interpreted languages. I don't really worry about learning one more or twenty more. I "grok" the underlying concepts. The specifics are merely window dressing. -ethan

On Tue, Apr 7, 2009 at 6:44 PM, Charles H Dickman <chd_1 at nktelco.net> wrote: Ah. That would be the one. ;-) Sorry for not spotting it - in the context of the stream-of-postings, the sarcasm was entirely unclear to me. -ethan

On Mon, 2009-04-06 at 18:28 -0400, Charles H Dickman wrote: I get stuff done with assembly language every day. I had much the same comment from someone at a BCS meeting once, who was ranting about assembly being irrelevant and everything should be written in Java. He got quite upset when I asked him how he planned to squeeze a JVM into 1024 words of ROM, along with the application. Gordon

Andrew Burton wrote: You need to find another place to work. *Almost none* of the PC software written here runs in a situation *anything* like that. Peace... Sridhar

On 7 Apr 2009 at 13:55, Ian King wrote: And too few people who take the trouble to learn the assembly bother to learn the machine representation of the instructions--or the architecture of the implementation. Even fewer learn how to time instruction execution--perhaps it's no longer relevant. Recently I had a conversation with another programmer who was surprised to find that the mapping of x86 assembly to machine language is not one-to-one; i.e. for a given assembly instruction, there is often more than one way to express it in machine code. --Chuck

You've never found a compiler bug? :-) Besides, my colleague who's writing the Massbus disk emulator doesn't get to use a compiler. He's done line-by-line assembly code, squeezing out every unnecessary byte and machine cycle. Don't tell HIM this sort of knowledge is no longer relevant. -- Ian

In article <FF6AB92D97A23A409701CDBF66F03FCD2E96AD17 at 505fuji>, Ian King <IanK at vulcan.com> writes: To be honest, no. Every time I *thought* it was a compiler bug, it was mine. Then again, I don't work in anything remotely like embedded computing where the quality of the compiler can vary considerably I'm told. I often hear from game programmers that game console C++ compilers are pretty shitty. Apparently the console vendors insist on making their own compilers or licensing a shitty one instead of making a decent back end for gcc or something reasonably like that. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>

On Tue, Apr 7, 2009 at 10:58 PM, Sean Conner <spc at conman.org> wrote: GCC is definitely not the most enlightened compiler out there. Thus spake Kernighan, "useth the Plan 9 compilers", and we did, and the compiler did generate object files, and the linker did link them, and yea even the mkfiles weren't too terrible. John -- "I've tried programming Ruby on Rails, following TechCrunch in my RSS reader, and drinking absinthe. It doesn't work. I'm going back to C, Hunter S. Thompson, and cheap whiskey." -- Ted Dziuba

On Tue, Apr 7, 2009 at 11:29 PM, Jim Brain <brain at jbrain.com> wrote: I'd like it if Linux wasn't built around the many weirdnesses of GCC X.Y.Z, and heaven help you if you want to compile with a non-GCC compiler. I've heard tales (from reputable people who have been doing Unix longer than I've been alive) of not being able to build GCC with various previous versions. The toolchain is huge, and the whole thing just seems baroque as hell. Have I been bitten by any of these things? Well, I have had software fail to compile for no reason other than having the wrong GCC version (no, don't remember what software, seems like half of the Linux source out there won't even compile most of the time), the others, not yet. However, all the real programming I've done in the last couple years has been in Plan 9 with the Plan 9 editor, the Plan 9 dialect of C, and the Plan 9 compilers and linkers (8c, 8l, 6c, 6l, qc, ql, etc.). I'm rather dreading the MPI programming I'll soon have to do for my Multi Processor Systems course, which will be POSIX C (with MPI added in), written in vi or emacs unless I can compile one of my favored Plan 9 editors on the cluster, and compiled with GCC. John -- "I've tried programming Ruby on Rails, following TechCrunch in my RSS reader, and drinking absinthe. It doesn't work. I'm going back to C, Hunter S. Thompson, and cheap whiskey." -- Ted Dziuba

On 08/04/2009 04:29, Jim Brain wrote: gcc is designed around the x86 family, and on a good day produces decent code for that family. Use it to generate code for a different endianness or different architecture and it "does less well". Take code written for gcc's foibles and compile it with another good compiler, and see how many complaints the other compiler makes about code that gcc lets by. The speed and (in)efficiency might not be apparent unless you have something else to compare it with, but for SGIs and Suns, I do. Last time I used gcc to compile something for an SGI, it took longer to do the compilation (not counting the time to find gcc-compatible libraries), and the resulting code was significantly larger and significantly slower than the result from SGI's compiler. -- Pete Peter Turnbull Network Manager University of York

I do not think a human could do reasonable optimization for today's processors - even by some assembler guru. Even back with STRETCH, we started to see the future is in the compiler. -- Will

Ironically, tomorrow I am seeing a friend that is an ox driver. Seriously. -- Will

In article <49DB7797.24880.5CCAA535 at cclist.sydex.com>, "Chuck Guzis" <cclist at sydex.com> writes: There's an in-depth understanding and then there's wasting time learning details that don't matter. Where the line is drawn depends on the task at hand and the needs driving the software. There are times where "slow and simple" is the design win, not "I understand what every bit of my 400 MB executable is doing!". -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>

In article <49DBC630.27572.5DFDC848 at cclist.sydex.com>, "Chuck Guzis" <cclist at sydex.com> writes: While this statement is indeed true for WEATHER FORECASTING, the average programmer is not attempting to solve "Grand Challenge" problems. <http://en.wikipedia.org/wiki/Grand_Challenge> Probably less than 1/10,000th of a percent of all programmers are working in that field. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>

True. But it remains the case that there are tasks that push the limits of what the available processors can do. Or there may be special considerations that you simply can't tell the compiler -- either it doesn't know, or you can't say it in C. I continue to do assembly language programming, occasionally. It's a small fraction of the total code but it has to be done that way for one reason or another; the compiler just isn't an option. For example, I have some cache flush code that runs about 10x the speed of C code. And it works correctly, which the C code can't because the hardware has some very odd requirements that no compiler ever written can cope with. paul

Gordon JC Pearce MM3YEQ wrote: Hmm can you squeeze enough of a TCP/IP stack into 1024 bytes to install a loader and just download the JVM from the Internet when needed? ;)

I suspect it would have been even more 'fun' if it had. Sticky labels tend to come unstuck from the backing paper if fed back and forth over the platten, the reuslt generally requiring the diassembly of bits of the printer. Anyone who only reads what they're assigned is not somebody I want to work with or employ. -tony