On 10/12/2011 11:08 PM, Pontus Pihlgren wrote: A friend of his and mine on G+ posted this: Barry Shein - I'm personally saddened by this news. I've known Dennis for a long time. Before I was involved in Usenix etc he would drop by at Boston University where I was a grad student, he was a good friend of Professor Joyce Friedman there, they knew each other when they were in grad school at Harvard so we'd all go out. I remember a couple of years later I got roped into doing a presentation at DECUS, my first computer conference, and Dennis was also there for the recognition of the 15th anniversary of the Unix operating system. Both of us pretty much didn't know anyone there so we hung out and found dinner etc. Over the years we'd run into each other at Usenix and hang out, occasionally exchange email particularly on how dopey something was like some technical flame fest on usenet or some mailing list. When I founded The World in 1989 he sent an email message to msgs at world.std.com which meant it posted so that everyone logging in would see it. something we actually allowed back then!: From uunet!research.att.com!dmr Tue Oct 17 03:35:50 1989 Subject: printf "Hello, world.std.com!\n" Dennis Ritchie --- He will be missed.

On Thu, Oct 13, 2011 at 09:58:57AM -0400, Sridhar Ayengar wrote: I think of it as my favourite IOCCC entry, whether it is C or not is up for debate :) Now that is a fun and useful construct :) Regards, Pontus.

On Thu, 2011-10-13 at 10:26 -0400, Keith M wrote: Is it a C99 compiler?

On Thu, Oct 13, 2011 at 10:26:15AM -0400, Keith M wrote: Assuming the URL starts with HTTP:// he effectively put a label called "HTTP" somewhere. and everyting after // is a comment. Soo, as long as noone gotoes to http, he should be fine :) I like it :) /P

On 13 Oct 2011 at 14:45, Fred Cisin wrote: Back when Dennis was posting his puzzles on Usenet, the assumptions were K&R C. "//" comments did not exist and there were be puzzles posted with lexical gotchas such as division by a dereferenced pointer. (a=b/*p and the like). There were also answers that were "Undefined", which really bugged me about C as a language. --Chuck

On 13 Oct 2011 at 20:12, Toby Thain wrote: Yes, I know--and have known this for at least 30 years, when Dennis pointed it out. C started off as a sort of "cheap and dirty in leiu of assembly" language. I was surprised that someone would bother to formalize it. I can well imagine that the first ANSI committe used lots of Excedrin. I know that was the case for ANSI PL/I--a co-worker was on the committe on that one and if you asked him how the work was going, he'd just shake his head. --Chuck

On 14/10/11 2:37 AM, Pontus Pihlgren wrote: While some disagree with the "portable assembler" characterisation, at C's level, it is indeed a language for micromanagers. Many people don't seem to appreciate that it's not ideal for most problems above the infrastructural/system level. It can't hurt to learn it but it can hurt to use it for the wrong problems (applies equally to C++).* An analogy may help. If your problem is "a room for the night," sometimes it's better not to begin by digging the foundations for a hotel.? --Toby (longtime C programmer) * - don't make it your go-to language! (har har) ? - I'm sure the same arguments were made against *assembler* while C became popular (during 1980s).

On 10/14/11 8:49 AM, Dave Caroline wrote: In a word, no. Time to market and 'refactoring' trumps performance. The only place this seems to be a concern is in the embedded/mobile space where they can't throw MIPS at the problem because of power considerations.

On Oct 14, 2011, at 12:34 PM, Dave McGuire <mcguire at neurotica.com> wrote: High frequency trading is another area where deep understanding is required. The back end of many of these cloud services also often require some pretty tight code though not to the extent that the HFT folks do. George

On 10/14/2011 01:56 PM, Chuck Guzis wrote: Kids and idiots. These are the same people who would never dream of passing through Sacramento on their way home from work in downtown DC to the DC suburbs, because it'd be stupid and inefficient, but they do the same thing in their software...because that's "just fine". It's incompetence at a very basic level. I spent about an hour doing assembly *this morning*. I'm working on a project (new contract, woohoo!!) and needed to tweak my crt0.s. ARM assembler is kinda fun, but caffeine is definitely required. There will always be a need to know assembler (How else will we write compilers? How else will we debug them?), "these kids today" seem to have a great deal of fun ASSerting that it isn't done anymore. Quite a bit of IBM mainframe work is done in assembler, too, I should point out. When one has to process a gazillion ATM transactions per second, one doesn't usually do it in Java. (though today's mainframes do have Java acceleration hardware! Because it needs it!) The vast majority of embedded development these days is done in C, with some things (notably some low-level device handling, as you know) are done in assembler. You can't really do any serious embedded work without doing at least SOME assembler, for the C startup code (crt0.[so]), but the "canned" ones distributed with cross compilers are getting closer to being able to handle all "before calling main()" needs. C will be the king in the embedded space for a long time, I suspect. This has been the case for a very long time (I've personally been doing embedded development in C for 21 years, and it was being done that way for a long time before that), and things like that don't change overnight, even though each new crop of college kids have their "favorite language of the week" and love to proclaim how it's going to replace everything. When trying to make a locomotive engine controller work, we use what's known to be dependable, not what's trendy and cutesy. -Dave -- Dave McGuire New Kensington, PA

On 10/14/2011 03:40 PM, Keith M wrote: I think that's not necessarily a bad thing, if the COTS NPUs are actually good at what they're supposed to do. A few years ago, I moved my network from a studly, very fast Cisco Catalyst 5500 to a Cisco Catalyst 3548XL. That moved me from packets switched in FPGA-based hardware to packets switched in firmware running on a PowerPC chip, a 405 I think. My power bill dropped by about $50/mo (which was the goal) but man the performance drop was huge. If these new NPUs can do their jobs as quickly and efficiently as the FPGA-based switching (whether it's done by firmware running on soft cores or directly switched by an FPGA-based hardware switching fabric), personally I think that's ok. -Dave -- Dave McGuire New Kensington, PA

On Fri, 14 Oct 2011 20:46:41 +0200 Jochen Kunz <jkunz at unixag-kl.fh-kl.de> wrote: Ahhh, there is a newer version: http://dl.fefe.de/optimizer-isec.pdf -- \end{Jochen} \ref{http://www.unixag-kl.fh-kl.de/~jkunz/}

Right now as we speak I'm writing a POWER macroassembler for Mozilla's JavaScript interpreter, which turns bytecodes into one:many POWER assembly instructions. I'm modelling the memory access on SPARC and the ALU work on ARM. It's going to be a curious hybrid when I'm finished (about 33%). The "trampoline" that hands off execution is handwritten PPC assembly. -- ------------------------------------ personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com -- Nasty habits/Here to stay! -- Oingo Boingo ---------------------------------

I'll probably release it back to Mozilla for inclusion in the Firefox tree (it will be in TenFourFox, I'm planning for 9), although the tracer that is already in TenFourFox is already obsolete, so it's kind of not worth it sometimes. -_- I'm trying to accentuate the positive :) That said, I see few people in PPC land hanging onto Opera. People seem to prefer Camino, Firefox 3.6 or Safari. I don't know why more people don't use OmniWeb; it's quite good and is my choice when I have to use WebKit. -- ------------------------------------ personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com -- Why was I born with such contemporaries? -- Oscar Wilde --------------------

OmniWeb today is essentially a WebKit shell with additional features. I like its bookmark management, and it supports Gopher protocol, which for me personally is a huge plus. :) It has a distinct advantage over other WebKit shells like, e.g., iCab, in that it includes its own WebKit components and does not rely on the system-installed version. Thus, on 10.4, you can get a WebKit equivalent to Safari 5. The JavaScript engine is standard SquirrelFish (JavaScriptCore). Other than TenFourFox, there are no native code JavaScript compilers for PPC. The PPC SquirrelFish is a bytecode compiler only. -- ------------------------------------ personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com -- I can't walk a mile in their shoes. They smell funny. ----------------------

On 15 October 2011 16:43, Toby Thain <toby at telegraphics.com.au> wrote: Seconded. Since I've revived my Mac mini G4 for occasional duties, 10.4Fx is a lifesaver, under either 10.4 or 10.5. Thanks, Cameron! -- Liam Proven ? Info & profile: http://www.google.com/profiles/lproven Email: lproven at cix.co.uk ? GMail/GoogleTalk/Orkut: lproven at gmail.com Tel: +44 20-8685-0498 ? Cell: +44 7939-087884 ? Fax: + 44 870-9151419 AIM/Yahoo/Skype: liamproven ? MSN: lproven at hotmail.com ? ICQ: 73187508

On 10/14/2011 02:37 PM, Jason McBrien wrote: Then explain why an OS (Windows and MacOS X for example) is so slow and bloated? I'm not talking about the pretty layers of user interface atop the OS, but the OS itself. We've had dialog boxes and pull-down menus for decades, on machines whose memory measured in hundreds of kilobytes and clock rates in the single-digit MHz. This stuff isn't THAT complex, man! -Dave -- Dave McGuire New Kensington, PA

On 10/14/2011 03:32 PM, Cameron Kaiser wrote: Mine is this guy: on OS X, Firefox used to hang quite often. This bug has been there for ages and has gone from one version of Firefox to another. I see emails of new bugs at the rate of one or two per month being closed as dupes of this. Yet, it still has not been fixed! https://bugzilla.mozilla.org/show_bug.cgi?id=476541 (Most noticeable when you're downloading something and it fails while you have a File-Save dialog open. If you do anything other than hit ESC or Enter, the two dialog boxes hang firefox.) Another favorite is if you save a web page that has stuff in it that can't be saved, the download window pops up multiple instances of "Could not download foobar.html" - one for each item that failed. It's just like whack-a-mole! What crappy code... sigh...

Listed on CraigList Spokane. PDP 11/03 with 2 Rx02 drives in a cabinet. 2 "winchester" drives included as well. Seller is asking $200 and "wants it gone." System was apparently operational when he acquired it. Item 2636158984 steve

On Sun, Oct 16, 2011 at 9:14 PM, steve shumaker <shumaker at att.net> wrote: I emailed him and provided those board descriptions based on the pictures he provided. There are also some other spare board too. Looks like a fairly typical 11/03 configuration with some spare boards. The one board that doesn't seem to fit is the M7284 board as that is listed as a Unibus board instead of a Q-bus board. Spokane is too long of a drive from Seattle for me. (Plus I don't need another -11 anyway). M7264 KD11-F 11/03 processor M7284 DA11-F Window control ??? M7957 DZV11-M 4-line async serial M8012 BDV11 Bus terminator, bootstrap and diagnostic ROMs M9400 REV11 Terminator, DMA refresh, bootstrap M7270 KD11-HA LSI-11/2 CPU (card 2) ????? CRC-MSV11 Memory (card 3) M8029 RXV21 RX02 floppy controller (card 4) ????? ????? M8043 DLV11-J equivalent (card 5) ????? ????? winchester controller??? (card 6) M7940 DLV11 async serial line M8045 MSV11 memory

On 10/14/2011 04:17 PM, Jason McBrien wrote: Doesn't need to be switched or selected at run-time; index into a table of pointers to the correct routines. Well ok, this burns CPU no matter how you slice it, unless you use hardware crypto accelerators. I do, and will never go back! These burn more bandwidth than CPU cycles. Who uses more than one (or maybe two) at a time? If anyone does, I'd love to know why. As above, indexing into a table is fast. And how many languages does ONE person really want to use to interact with their computer? Usually one. Why even have the others installed? Also as above, the decisions between them don't need to be made during use, but only during initialization. Unless you mean stuff like abstract display coordinate systems, which can (and arguably should) be handled by the display hardware. GL is pretty much standardized these days. I see and agree with your point. But if these things are competently implemented, the performance impact should be minimal. But different kernels for different hardware configurations are handled by pluggable modules. Save for some indirection through device tables and such, ALL of that stuff is handled at boot time. Minimal time-of-use impact. -Dave -- Dave McGuire New Kensington, PA

On Fri, 14 Oct 2011 14:48:56 -0400 Dave McGuire <mcguire at neurotica.com> wrote: Part of the problem: Unexperienced programmers. Recently a colleague showed a code snipet to me. It was 10..15 lines of C++ from some Linux package manager GUI. There was a bug in it regarding the call of a command line tool to do the actual work of adding a package. It was clearly visible that the person who wrote that code didn't know exactely what he did. (This is particularly bad in C++.) I am sure he did it in the best aim to give something usefull back to the Linux community. I am sure he did it as well as he could and that he wasn't sloppy. But lacking experience and knowledge, his code was awfully bad. (e.g. calling system(3) and using temp-files insted of using popen(3) or pipe(2) / fork(2) / exec(3), passing std:string by value instead const reference, ...) So this is only one tiny example from one programmer. But today there are many of those programmers and they write a lot of bad code. New programmers come and they learn coding by reading that bad code and extending it... But regarding optimization, keep in mind, to cite Donald Knuth: premature optimization is the root of all evil The problem herin is: Sometimes the need for optimization arises later and your boss doesn't give you the time needed to do the refactoring of legacy, non-optimal code... -- \end{Jochen} \ref{http://www.unixag-kl.fh-kl.de/~jkunz/}

Jason McBrien wrote: But that complexity often isn't a concurrent thing - I don't think there's a reason that you can't pile an application up with features, but only load (or install) those that are actually needed on a per-user basis. It's going back to the Unix "chain lots of little widgets together to suit the task at hand" philosophy rather than the "build a monster app whether you need all the features or not" approach that seems the norm today. I don't give a crap about half the things that some of my regularly-used apps do. I can completely understand that some people want them, and so I can understand the developers writing them. I just don't think I should be forced to have them just because someone else thinks they're good. If we all had computers that just did exactly what we needed of them and nothing more, the world would be a better place. I suppose in a way, at least in the mobile arena, things are going that way too: small apps for this that and the other running within a common OS framework - so maybe that trend will happen once again with desktops, too... cheers J.

On 10/14/2011 03:33 PM, Jules Richardson wrote: Same here. Except that I *am* a perfectionist. :-/ Oh yes, fun stuff indeed! I love challenges like that. That's happening *now*, at least with the crashing. Many people I've talked to from the Windows world (no offense to Josh, who may be one of Microsoft's only competent developers) honestly think that's "just how computers are". :-( Guest pointing at big server with 16 hard drives: "Man, I'd hate to have to reinstall THAT!" Me: "Reinstall? Why would I ever need to?" Guest: "Every computer needs to be reinstalled once in a while!" Me: [head explodes] -Dave -- Dave McGuire New Kensington, PA

On 10/14/2011 11:49 AM, Dave Caroline wrote: I sure hope so. Two jobs ago, I had to deal with a financial that had half their customers on one node of a VCS cluster, and have on the other running the same application. That application, in Java, had a few hundred thousand threads. No, I'm not kidding. This thing interfaced with MQ and of course had one thread per queue. Each client had something like 10 threads total, some MQ listeners, some to send results back to the client, some to do various other things, and in QA, for each client, there was a complete fictional counterparty, complete with its own set of threads. Of course, there were also pools of threads for database connectivity too. We couldn't throw more memory at the problem since the JVM at the time had a limit of 2GB. The only thing to do was to chop the application up into different VMs. Which of course would fail in their own interesting ways. Of course the incompetent programmers there decided to not use MQ for these JVMs to talk to each other - they used something MQ-like that the JVM had built in and spoke over http. Why? I've no idea, but this bridge went down quite often and required bouncing also. You can image what a clusterfuck that was in terms of both performance and debugability. There were monthly out of memory crashes as some run away thread didn't release memory. These were usually caused by running out of database threads. Whenever the db portion of the platform ran out of threads, for some reason the app decided that it should spawn of a thread for every incoming request. Or maybe that's what it normally did and I didn't notice it because when things were working that thread shut itself down after the request was processed. One very famous problem at that place was solved when they actually hired the one and single competent java programmer. Of course, he has since left there too. The problem had to do with padding strings with spaces in some report so that it would be exactly X bytes wide. It turns out that if you do it in a loop and append a space to the end, java creates X-len copies of that string, and each one has to be garbage collected, and of course was insanley slow. I think he simply invoked Java's version of printf to solve this. :-D I don't play programmer in my day jobs, though I can code in C and a few other languages. My role at that place, and in the current one is sysadmin. As incompetent programmers are apt to, they go and blame the database, or the network, or Veritas Cluster Server, or Solaris, or the hardware, anything but their own code. A lot of my time was spent *proving* that these other things were infact functioning as they should and that the programmers needed to re-examine their code. I probably spent more time looking at the stderr and stdout of the JVMs than the clowns that wrote that crappy code. Because this thing was so crappy and so likely to crash, it ran in production with the debug level in log4j fairly high, which produced gigabyte sized logs every hour, and of course slowed down the application by several orders of magnitude (of course the SAN got really slow due to so much crap being written to disk, and the programmers were blaming the SAN for the slowness of their app!) One of the big projects before I left there, was for the good programmers to go through the miles of code and to disable logging in places it was no longer needed. :-) A few days ago, I posted a message here about creeping layers of abstractions. The above is what you get when that's taken to absurd levels. What drives this? Corporations that want replaceable cheap cogs, that is one programmer to be identical to another so they can be replaced by cheaper ones, either in the same market, or outsourced overseas. They love java because everything is handed to them on a silver platter and they don't have to learn how linked lists or hash tables or quick sort or anything else actually work. They just say new foo bar and use that with no consideration to the performance implications. When it breaks, they've no idea why, or how, let alone how to go about fixing it. Had these guys tried to write this kind of thing in pure C it would have probably never compiled, or would have segfaulted every two seconds, thus pointing out their failures. But because it was Java, and Java is easy to learn, the company felt compelled to hire young guys who barely went through some Java 101 class and threw them at a financial app that supposedly processed billions of dollars per year. If you're a young guy looking at learning to code for a living, I highly recommend you learn what corporations consider esoteric languages instead, and either find a place that welcomes them, or start your own company. Learn C, and assembly then either smalltalk or lisp. I'm not saying that this is the state of the art in Java or other high level languages, but rather, because it's easy to learn, it allows this kind of incompetence to be acceptable. I'm glad I don't work there anymore, and instead work in sane place for and with bright people with a clue.

On Thu, 13 Oct 2011, Chuck Guzis wrote: Part of what made C truly powerful was flexibility of implementation. If your machine would work better with 18 bit integers instead of 16, then you could do so. The downside, of course was extreme frustration when you encountered a lack of rigidity on things such as what 32767 + 1 was going to do, which increment would occur first on n=3; A[n++] = n++; (is that A[3]=3; A[3]=4; A[4]=3; or A[4]=4;?, yet while(*T++=*S++); would work!), etc. You really didn't have the safety of a padded play area like certain other languages. If you wanted to shoot yourself in the foot, C would give you unlimited rope. Attempting to make use of YOUR compiler's behavior in an "undefined" situation was foolish. What SHOULD happen if you divide by 0? (few compilers could implement a black hole) -- Grumpy Ol' Fred cisin at xenosoft.com

Keith M wrote: I think it depends. On whitespace on a line all by itself, it should work. But if the whitespace is within a statement or function call then it could fail if code ends up commented out, e.g. printf("hello\n" ); ... paste a URL into that and the compiler will get confused :-) Aside: I recall encountering one C compiler which didn't handle nested comments - if you had a "/*"-style comment within a "//"-style one, it'd barf. I think it may have been an early (I mean, 1990s) version of gcc. Creating a file called "*foo.html" and then accessing it via firefox and apache as "http://localhost/*foo.html" works, although I'm not sure if it's technically a legal URL or not :-) cheers Jules

You have always been a jerk Tony, and you are not that clever. Today of all days. Any c snippet is welcome.

I used to get laughed at for being explicit when I coded C. Some of the guys in the office said that my C looked like perfectly formed Pascal..... I spent less time chasing bizarre bugs though! Doug On Fri, Oct 14, 2011 at 5:13 PM, Pontus Pihlgren <pontus at update.uu.se>wrote: -- Doug Jackson VK1ZDJ http://www.dougswordclock.com/ -< My clocks http://www.vk1zdj.net -< My Amature Radio Activities

On 14/10/11 2:13 AM, Pontus Pihlgren wrote: The example *above* doesn't require reading any standards; it's basic C usage and is in K&R 1. It would be hard to read or write C in any serious way without having internalised things like this. (Because both constructs are common.) iirc, you would avoid using any auto (stack) variables that were in scope. --Toby

Exit ;) -- ------------------------------------ personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com -- Careful with that Axe, Eugene. -- Pink Floyd -------------------------------

On 10/14/2011 8:23 PM, Toby Thain wrote: And I would tend to prefer a loop that involves some sort of bounds checking :). - Josh

Josh Dersch wrote: checking :). On most common general-purpose computers, you do get that. When one of the pointers exceeds the segment bounds, you'll get a segfault and the process will be killed. I suppose you probably wanted checking against some more restricted bounds, though.

On Oct 15, 2011, at 11:35 AM, Toby Thain <toby at telegraphics.com.au> wrote: Yes. And if you think about it, that particular change would slow pretty much everything on the planet down. While it's convenient, it really amounts to programmer hand-holding. I'm certainly able to keep track of my own arrays, surely you are as well. ;) -Dave -- Dave McGuire New Kensington, PA

On 10/15/2011 10:50 AM, Joost van de Griek wrote: malloc and friends I think are a greater evil than null terminated strings. Ben

On 10/15/2011 01:25 PM, ben wrote: If "evil" is defined as "doesn't protect incompetent programmers from themselves", sure, I'd agree with that. -Dave -- Dave McGuire New Kensington, PA

On 10/15/2011 4:05 PM, Dave McGuire wrote: Well you can add one more to that list, I know a great burger flipper and a fair Pascal programmer on the side. You can always get a job with burgers, but computers change so fast now days. Ben.

I just had a really great burger (and milkshake)! Please, keep the ones that you referred to writing operating systems.

On Fri, 14 Oct 2011, Josh Dersch wrote: In C, what happens when you do: char A[1000]; char * t; char * s; strcpy(A,"anything"); t = &A[0]; s = &A[1]; strcpy(t,s); /*to delete a character*/ printf("%s",A); t = &A[1]; s = &A[0]; strcpy(t,s); /*to insert a character*/ printf("%s",A); <pedantic> Why? How SHOULD you do it? In C, if you want ANY error checking, then YOU have to put it in, thus making it an inappropriate language for beginners to write operating systems in. </pedantic> -- Grumpy Ol' Fred cisin at xenosoft.com

On Sat, 15 Oct 2011, Toby Thain wrote: In C, you can have as much and as thorough error checking as you want. <RANT> The REAL problem is that too many people who are employed as programmers don't understand the importance of error checking, and it isn't adequately taught in college classes! In MY "Data Structures and Algorithms in C" class, there were COMPLAINTS that I spent class time teaching error checking as a fundamental component of all algorithms. </RANT>

On Sat, 15 Oct 2011, Toby Thain wrote: Is C* like C# ? "unnecessary"???????? "no real payoff"??????? HARRUMPH! I think that having an Operating System, AND having applications, that are reliable IS a major payoff, and whatever work it takes for THAT is extremeley NECESSARY. That is at the expense of extreme slowdown from runtime error checking that includes checking for situations that could not occur. For example, if the divisor is going to be either 12 or 16, is it really necessary to have runtime code on the nature of: Y = 12; if (y == 0) . . . . . Z = X / Y; C lets you put in all of the error checking that you need, and lets you leave out the error checking that you don't need. But, obviously, SOME people employed as programmers don't know the difference, and really should be using "padded cell" high level languages, instead! Some of them are incompetent when it comes to understanding what kinds of exceptions need to be planned for. Naah. I think that we agree on all of the truly important stuff. -- Grumpy Ol' Fred cisin at xenosoft.com

On 10/15/2011 02:59 PM, Fred Cisin wrote: So, hire competent programmers. I realize that has gone out of style in recent years, but it does solve the problem. You can hire people who need all sorts of hand-holding by their compiler because they simply can't handle it themselves, or you can hire people who know what the hell they're doing. -Dave -- Dave McGuire New Kensington, PA

On Oct 15, 2011, at 6:39 PM, Diane Bruce <db at db.net> wrote: Yes, most definitely. C gives people enough rope to hang themselves. Such people could use some hangin'. -Dave -- Dave McGuire New Kensington, PA

On 15 Oct 2011, at 19:34 , Fred Cisin wrote: LOL .tsooJ

Hm. For whatever reason this ended up on cctech when I responded, so here it is again on the right list (sorry for the spam if you're on both.) On 10/15/2011 10:34 AM, Fred Cisin wrote: Depends on the compiler and the C-runtime, I suppose. All of the documentation I have suggests that the behavior of strcpy is undefined when the strings being copied overlap. So no C runtime libraries do any error checking for you? That's not true. I'm pretty sure fopen() won't return you a file handle pointing into the ether (and scribbling all over the disk if the programmer chooses to use it) if the user asked to open a file without checking to see if it existed first. I appreciate (and understand) the notion that for absolute performance, automatic bounds checking of arrays can be an impediment. I also know that all people make mistakes, no matter how hard they try and how long they've been writing operating systems. (Anyone who says differently is either lying or hasn't yet found their mistakes.) And these days, a mistake in bounds checking costs many more people than the developer. C-style strings and the library of runtime functions that support them do not make anyone's lives easier in the correctness department, due to issues inherent in the design (as has been mentioned by others on this list). Where I work, strcpy (and their ilk) are verboten; we use variants like strcpy_s to prevent inadvertent buffer overflows, since it does the validation we'd have to do manually anyway and it's guaranteed to work properly. And it's not like our code spends 99% of its time copying strings, so the performance hit is approximately zero. - Josh

On Fri, 14 Oct 2011, Chuck Guzis wrote: howzbout: not a COMPILER, but, . . . function 9 of MS-DOS and CP/M, that uses '$' terminated strings! There are many ways to store a string. Terminating character requires a little bit of extra care, but are the others much better?

On 15 Oct 2011 at 11:25, Fred Cisin wrote: Sure--the strings that employ descriptors are particularly great-- there's no need to figure out the length of a string before doing anything with it. On RISC systems with wide words, one can move a string very quickly, without having to look at it byte-byte for a terminator. In compiling, string descriptors allow for the "pooling" of constants having common substrings. For example, the string: "Oregon is bordered by Washington, Idaho, Nevada and California" allows for the sharing of substrings without duplication. I'm well aware of CP/M function 9--and the inability to print a "$" using it. CDC SCOPE/KRONOS/MACE used 6-bit characters. There were some operating system functions that terminated character records on a 00 (octal) byte. Unfortunately, the 63-character set lacked a colon, so one was introduced for octal 00 and the definition of a coded (i.e. character) record altered to "terminated by zero in the low-order 12 bits of of the final word". Then double colons created problems of their own, for which no one had any satisfactory answers, except "don't do it". SCOPE 2 on the 7600 used length-prefix character records (W type) and the problem was completely unknown to them. Furthermore, you could query the device being read from ahead of time to obtain the length of the current record. (I think DEC FORTRAN had that feature with their Q format designator). How many new "C" programmers have made the mistake of thinking that strlen() returns the total length of a string (including the delimiter)? Take the original example in C: while( *a++=*b++); Now execute the snippet with two pointers that create an overlapping move, such that the null terminator of the source string is destroyed The string move eats its tail, clobbering evertyhing in its path. That would never happen with descriptor-based strings. --Chuck

On 15 Oct 2011 at 17:57, Dave McGuire wrote: And sometimes there are functions that are guaranteed to work, no matter the overlap (e.g. memmove() vs. memcpy() ). But what kind of person would use the given sample loop, rather than a library routine? When working with C on an unfamiliar platform, I study the generated code both to get a handle on how the compiler handles code generation for the platform. I realize that this is probably considered to be "old fashioned" however. C was a great assembler for the PDP-11, but for other platforms, maybe not so much. How, for example, do you implement byte pointers on hardware that only addresses words? (e.g. Cray 1). Most 8080 Cs were perfectly dreadful--and I've been surprised to see C implementations on 8-bit PIC hardware. --Chuck

On 10/15/2011 7:17 PM, Dave McGuire wrote: But only as cross compilers ... Native C still is painful on the 8080 or 8086. Did the PDP-10 have a good C complier? Ben.

On 10/15/2011 8:19 PM, Eric Smith wrote: I don't know about C, but I assume that 7 bit ascii is standard for everybody but IBM 360's. Ben.

On 10/15/2011 8:39 PM, Eric Smith wrote: How ever this is under C triva, not the latest standard of the year. So what does the C-bible say on this?

On 10/15/2011 9:43 PM, Fred Cisin wrote: Did you remember the -2GB is for imaginary data when C gets REAL numbers.

On 16/10/11 1:02 AM, Fred Cisin wrote: You'll be pleased to know this is still an FAQ - on sites like Quora, etc. Don't worry! They may end up with co-workers like this guy: http://www.reddit.com/r/programming/comments/l32qk/if_only_we_all_had_cowor… --Toby

On 16/10/11 1:02 AM, Fred Cisin wrote: On 16/10/11 2:43 PM, Tony Duell wrote: I never understood the popularity of that approximation. 52163?16604 is more accurate. --Toby

I never understood the populrity of that approximation. 31415926535897932384626433832795028841971693993751058209749445923078164 / 10000000000000000000000000000000000000000000000000000000000000000000000 is more accurate.

Fred Cisin wrote: If you encode the digits using something with more scope than characters 0..9, there's a lot less to memorize. ;-)

Gold!!! On Mon, Oct 17, 2011 at 5:00 PM, Pontus Pihlgren <pontus at update.uu.se>wrote: -- Doug Jackson VK1ZDJ http://www.dougswordclock.com/ -< My clocks http://www.vk1zdj.net -< My Amature Radio Activities

Pontus Pihlgren wrote: Heh :-) I did think of mentioning that - but it's only in the extended ASCII set, isn't it?

iF WE ALL USED petscii THEN WE WOULD HAVE A PI CHARACTER, BUT ONLY IN UPPERCASE MODE. -- ------------------------------------ personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com -- "Garbage in -- gospel out" -------------------------------------------------

On 17/10/11 4:55 PM, Tony Duell wrote: Heck, 355/113 got us to the moon! In fact it's so practical and sensible it should be legislated as the OFFICIAL approximation to ?. --T

Of course. I was trying to prevent a thread where we get one message after another givning the rational approximation obtained by adding one more term to the continued fraction approximation. Yes, it's very easy to remember, and accurate enough for a lot of practical work. Of course it _is_ an aproximation, anyone who claims it's exact is plain wrong. -tony

On 16/10/11 5:13 PM, Chuck Guzis wrote: Right, it's much safer in the hands of "education reform" plutocrats :D --T

On Mon, 17 Oct 2011, Rich Alderson wrote: Once a planet, ALWAYS a planet!

Ahem 3.141592653589 *7* 9 (Finlly, memorising the first 200 digits all those years ago proves useful :-)) Antonio arcarlini at iee.org

On Mon, Oct 17, 2011 at 09:46:41PM +0100, Tony Duell wrote: Yes it does. The underlying problem is almost never "achieve perfection" but is "get a result accurate enough to let me build this bridge and have it not fall down" or "make the code work fast enough". The tricky bit is that once you've got a good enough approximation for, eg, sqrt(2), which you then use, to bear in mind that the result is an approximation, and that if you then perform some other operation with that result and with another approximation that the errors grow, and grow, and grow, and then DOOM. I wish there was a widely available, widely known general purpose programming language which had a "number with precision" type, which would Do The Right Thing when doing things like multiplying values together - ie, decreasing the precision - and would let you specify a required minimum precision for results or function parameters, with exceptions being thrown if those can't be achieved. It would be nice to be able to automate away the problem of "measure with a micrometer, mark with chalk, cut with an axe". -- David Cantrell | semi-evolved ape-thing You can't spell AWESOME without ME!

From: David Cantrell <david at cantrell.org.uk> I am almost certain Ada 95 provides this. You can certainly specify the number of digits of precison and create your own type or subtype and I believe the runtime automatically protects you from loss of precision. The only thing is because of the rigid typing it's hard to move data around unless everything is the same type.

From: Eric Smith <eric at brouhaha.com> Ada 95 Reference Manual ISO/IEC 8652:1995(E) p. 45 section 3.5.9 Fixed Point Types: "A fixed point type is either an ordinary fixed point type, or a decimal fixed point type. The error bound of a fixed point type is specified as an absolute value, called the delta of the fixed point type." That suggests to me there is a guarantee against loss of precision. Why do you feel otherwise? I'm sure he's glad you're his mom. Maybe you could let him speak for himself and we can hear what he thinks.

On 10/18/2011 09:25 AM, vintagecoder at aol.com wrote: as an Why do Because that only specifies the precision of the type. It both doesn't guarantee the precision of operations on the type, and doesn't help you with keeping track of the precision of results of limited-precision operations. himself I wasn't referring to what David was thinking, which clearly I don't know. I was referring to what David wrote, which clearly wasn't what Ada95 provides.

On 18 Oct 2011 at 10:28, David Cantrell wrote: Should be the first lesson in bonehead numerical methods. An answer with 20 digits, none of which is significant. Are there any modern hardware platforms that allow the user to specify the "noise digit" (using an ancient term for lack of a modern one) in floating-point operations? That is, can the user specify the bit pattern that is to be used when filling in nonsignificant positions during the process of normalizing? It used to be a useful exercise running the same calculations using say, all zeroes as normalizing fill and then repeating using all ones (or zeroes and nines, if you like to count on your fingers). --Chuck

On 18 Oct 2011 at 16:44, Vintage Coder wrote: Program much 1620 SPS using Monitor II? *NOISE DIGIT n was an SPS control record when using the floating-point subroutines. It was stored in the system table area on disk. Oddly, this was not offered as an option on FORTRAN II-D. CDC 6000 series machines had three sets of floating point instructions. Nomalized, un-normalized and "rounded". Rounded would introduce non-zero normalization fill, which varied depending on the operation. --Chuck

On 18 Oct 2011 at 18:16, vintagecoder at aol.com wrote: The "red book"? I've still got the one I bought in the 1960s. I didn't say that S/360 didn't have unnormalized FP operations; it certainly did, at least according to my "green card" that I still have. I can't find anything about FP rounding normalization bits. I thought your reference might be to a bit in the PSW that I hadn't noticed before, but a quick check shows otherwise. No, the evil in the S/360 FP operations was that normalization was carried out to, not bit boundaries, but "nibble" (half-byte) boundaries. So the casual user, thinking that he's got 24 bits of precision in the mantissa would find out that he was very wrong. AFAIK IEEE floating point didn't enter into the picture until S/390. --Chuck

Some years ago, at the HPCC conference (I think it was in 2007), Hugh Steers presents a piece of software he'd written where you could specift the precieon you wanted in the answer and which would then use better approximations as necesssty until that precision had been reached. I won't publish hs e-mail address on this list, but if you are interested i can put you in touch with him. -tony

On 19/10/11 6:34 AM, David Cantrell wrote: It is not clear why this idea has been so consistently ignored, except it may be another case of "worse is better"... Re Steve Richfield's "significance arithmetic" proposal, see: https://groups.google.com/d/msg/comp.arch.arithmetic/d9YzeOe3Bok/eQT9uNBUCO… https://groups.google.com/d/msg/comp.arch.arithmetic/d9YzeOe3Bok/wlDjDjshfK… https://groups.google.com/d/msg/comp.arch.arithmetic/aCDUAQDgmOg/vqgbA2YUpn… More rationale: https://groups.google.com/d/msg/comp.arch.arithmetic/aCDUAQDgmOg/dnRUg3kuvr… et seq. There are many good anecdotes in that thread - including at least one involving Dennis Ritchie - and much discussion of the shortcomings of IEEE-754 arithmetic. Richfield: "Significance arithmetic will not change ANY results - it will just tell you which ones are reaching beyond the capability of the methodology being used." Mathematica does some precision tracking, for what it's worth. --Toby

On Wed, Oct 19, 2011 at 01:19:51PM -0700, Fred Cisin wrote: No, it tells you that it can *represent no more than* 24 binary significant digits. float pi = 3.1f; /* close enough for government work */ that the *type* can have 24 significant binary digits doesn't mean that the *data* has 24 significant binary digits. -- David Cantrell | top google result for "topless karaoke murders" EINE KIRCHE! EIN KREDO! EIN PAPST!

An overly truthful upgrade policy? -- ------------------------------------ personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com -- .signature violation (core dumped) -----------------------------------------

On Thu, 20 Oct 2011, Cameron Kaiser wrote: Windoze 3.11 was "WFW". MS said that that was "Windows For Workgroups", but some people claimed that the second 'W' was for a word that is offensively obscene to Brits. On Fri, 21 Oct 2011, Liam Proven wrote: It is handy, and it is nice that the newer one has some minimal "scientific" and BASE CONVERSION functions. It doesn't compare with an HP REAL calculator, but I can always find it. Pointless rambling Windows Write anecdote: I was the first person in the UC Berkeley School of Library and Information Studies to use a word processor for PhD written exams. Mostly because I publicly demanded that they publicly state their REASONS for requiring hand written, and I assured them that I would still be able to make enough spelling erors. They were panic-stricken over how to "sanitize" a computer so that answers couldn't be smuggled in! But, then they asked ME to pick a word-processor! Since all that I wanted was a TEXT EDITOR and a printer, I responded, "ANY word processor. ANY. Just tell me which one a week ahead, so that I can learn enough of its quirks to use it." We settled on Windows Write, which protected me from even more insane choices or botched installation, and protected them from the possibility that I might recompile from source [on PC-Write or the like] or object code edit in paragraphs of pre-written text. But mostly it let them choose which PC to use at the last minute. After all of that, they ended up just handing me a few blank disks and key to an office with a PC in it, and never even checked up on me. And then THEY printed out my files. I passed. Which shows how sloppy their standards are! -- Grumpy Ol' Fred cisin at xenosoft.com

On Fri, 21 Oct 2011, Liam Proven wrote: I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone. - Bjarne Stroustrup

At 5:17 pm -0700 2011/10/20, Chuck Guzis wrote: K&R C (vaguely on subject here) permitted a compiler to rearrange expressions at will, but ANSI C forbids any optimization that could change the results of a calculation. FORTRAN from the very beginning has had the rule that parentheses must be respected, but all else is fair game. -- Kevin Schoedel <schoedel at kw.igs.net> VA3TCS

On 10/21/2011 03:38 PM, Fred Cisin wrote: How many of today's "glue black boxes together" programmers would even KNOW when it's appropriate, though? That's the scary part. We got to the moon in 1969...no telling whether or not we'll be able to get there again, with programmers being the way they are now. :-( Maybe we can hitch a ride with the Chinese. -Dave -- Dave McGuire New Kensington, PA

On 10/21/2011 07:53 PM, Fred Cisin wrote: [head explodes] This is sooo depressing. :-( -Dave -- Dave McGuire New Kensington, PA

On 22/10/11 4:36 PM, John Foust wrote: Beautiful example of the tyranny of low expectations in the PC ghetto. --T

On 24 Oct 2011 at 2:16, Alexander Schreiber wrote: This seems to be a trend that is increasingly an unquestioned article of faith. From a Chinese forum moderator in response to what is a very clear software crash: "As we know there are no such "Bug Free" software exist. This is why the software need to be updated regularly. Please check back the software update regularly." In this case, "regularly" means "last recompiled in 2008". Those damned file dates! --Chuck

John Foust wrote: Well, that's perhaps true, because eventually a hardware glitch will surely take it out :-)

Oh, approximately the same number as the number of 'glue FPGAs and Microcontrollers together' hardware 'designers' who can calcualtr LED current limiting reissotrs, bias a transistor properly, etc. -tony

I said nothing about using FPGAs or microcontrollers _well_ (or even properly). I was thinking of the sort of 'designer' who draws a schemaitc with a microcontroller or FPGA in the middle and that's it. The programming of said chip is a 'software problem' and is not his responsibility. Oh, such people rarely look at the features of the microcontorller they're using, so you'll find a microcontroller with, say, on-chip I2C support talking to an I2C EPROM but not using the pinms for said hardawre suppor so it has to be bit-banged. And then there are the FPGA designers who design like this : THey'll enter a scheamtic in the schematic capture program and simulate it. It doens't work so they say things like 'let's invert that signal and see if that helps. OK, it didn't, what happes if we change that AND to an OR?' No real method, no logic to what they are doing. I've met them... Using these chips well does take considerable skill, I agree. -tony

Exactly!. At least with FPGAs thay can't (easily) use analogue monostable circuits. This sort of designer let loose on TTL will thow '123s everywhere without realising that if the timing components drift the signals can change in the wrong order. At least they ddin't put ferrite beads on the leads of the protection zenrs, thus ensuring said zeners cna't catch a fast spike. I guess this is the sort of person who puts a fuse in series with the anode of a crowbvar SCR to protect it. Yes I did seee that one once, I commented _before_ it got built, fortunately. -tony

Unfortuantely _yes_ !. These are the sort of people who say 'There are no 382.73 ohm resistors in the box, and I can't find them in any catalogue'. When you ask what they want them for, it turns out that's the value they calcuated using (V_supply - V_f)/I_Led using data sheet typical values of V_f (LED forward voltate) and I_Led (LED current) for the nominal supply voltaget hey're using. And they don't believe you when you tell them to stick in the first 390 Ohm resistor they find. -tony

On Thu, Oct 20, 2011 at 03:45:40PM -0700, Fred Cisin wrote: What I'm getting at is that there's no widely understood datatype that lets me say: pi = 3.1 to two significant decimal digits; and that it is foolish to assume that any float is accurate to 24 significant binary digits. The moment you, eg, multiply two floats which are already approximations together, then you lose precision. -- David Cantrell | Enforcer, South London Linguistic Massive Irregular English: ladies glow; gentlemen perspire; brutes, oafs and athletes sweat

On 21 Oct 2011 at 12:35, Fred Cisin wrote: Howzabout: 77 PI PIC 9V9 VALUE 3.1. --Chuck

On 21 Oct 2011 at 23:43, Benjamin S?lberg wrote: Yup. Could just as easily be done in PL/I: DECLARE PI FIXED DECIMAL (2,1) INITIAL(3.2); --Chuck

On 19/10/11 4:19 PM, Fred Cisin wrote: Or rather, *how much* of the value is significant. That "count" wouldn't mean much. But you can track, at least through simple operations, how much of the value is significant. Compared to the agonies of C, this would be a straightforward addition to any Lisp numeric tower. The idea has been around for a while - usually named "significance arithmetic". In particular, Mathematica implements a related system (fwiw). * http://mathworld.wolfram.com/SignificanceArithmetic.html * http://www.wolfram.com/technology/guide/SignificanceArithmetic/ * http://www.mathkb.com/Uwe/Forum.aspx/mathematica/21243/remarks-on-significa… * and some of the Usenet links I posted earlier. Steve Richfield has advocated this proposal as an important refinement of IEEE-754. --T

On 15 Oct 2011 at 19:39, Eric Smith wrote: Must an int contain an integral number of chars? Back in the 70s, there were several proposals for supporting 8-bit ANSI and EBCDIC character sets on Cyber 70/170 series of machines with 60-bit words. One such was that a word would contain 7.5 characters. Another proposal was to use only the low-order 48 bits (certain instructions made this very attractive). Another proposal was to go to 10- or 12-bit characters (the latter attractive from an efficient I/O standpoint). What was finally chosen, IIRC, was a mix of 6- and 12-bit character codes, with a 00 code acting as an "escape" for the lowercase set. It was very messy. The Cray-1 COS approach was just to unpack character data into a 1- per-word format, wasting 56 bits out of every word. "Pack" and "unbpack" system read/write calls were available. --Chuck

On 15 Oct 2011 at 22:51, Eric Smith wrote: Wasn't it presumptuous of K&R to assume that the smallest native datum was a char? At the time the spec was being written, there did exist bit-addressable machines, so directly-addressed bit arrays were certainly possible on some hardware. --Chuck

On 16 Oct 2011 at 11:03, Toby Thain wrote: Not the same at all. I don't believe that in C I can declare: bit anything[60000]; K&R have bitfields as comprising parts of larger datatypes, say int, but not as a datatype in their own right. Can you imagine how inconvenient it would be if the type "char" was available only as a member of type "int"? Bit arrays are enormously useful to facilitate vector math, either to accompany sparse arrays or as a control vector for storing results. And then there's the obvious application as a simple bitmap. As I said, K&R C is extremely myopic and to my eye always appeared as PDP-11 shorthand assembler. It's not as if bit vectors are anything new; APL has had them for a very long time. Another thing that's dogged me over the years is the extremely weak preprocessor in C. To be sure, the template feature in C++ has remedied a lot of it, but that's not C--it's C++. C's preprocessor never came up to the level of the macro facility in a good macro assembler or, for that matter, the preprocessor in PL/I. Yes, I know the recommendation is to use a generic external macro facility, such as M4 or a host of other tools, but none of those are part of the C language. What can be done with a really good macro-assembler is very eye- opening. Sadly, not many newer assemblers, particularly those for microcontrollers, have assemblers worth spitting at. --Chuck

On 16 Oct 2011 at 14:17, Toby Thain wrote: Early in my career, I was placed under the tutelage of a consultant-- an ex-IBMer who was quite an authority on COBOL--he was part of the old COMTRAN team as well. He came to California and "found himself"-- but that's another story. The task at hand was a translator between dialects of COBOL. Ours was a multi-processor transaction-oriented system with communicating multiple threads, shared variables, etc. This was long before the "Dragon Book" or even YACC (I'm not sure how amenable YACC is to COBOL at any rate). He'd asked me how I would go about writing such a translator. I responded that the simple way would be to use a specialized language such as SNOBOL or perhaps even FORTRAN (our options were pretty limited back then) and then refine the result. He opined that I'd missed the point of the question. He then proceded to explain his idea of how to go about it. He proposed a fictitious machine that, instead of bits and bytes, handled abstract data types, such as tokens and had a very simple set of instructions that could query and alter properties of tokens as well as generate some on its own. It had its own symbol table primitives as well as a way to generate output. I was a little dubious, but we put it together anyway; we invented some instructions and the support software for this machine (my job) and wrote a bunch of very funny-looking assembler code using the macro facility of the assembler. The initial run was ready in an amazing 3 months--far faster than anyone had anticipated. We had customers trying it out on their own code and reporting back problems, which were taken care of rather simply. Because of the huge macro content, assembling the translator took the better part of an hour (on one of the fastest CPUs of the time). And because execution was interpretive, it was awfully slow. The next step was to rewrite the macros for the instructions to have them generate native code and demote the interpreter to a bunch of support routines for the native code. Things sped up by almost an order of magnitude and the end result turned out to be extremely stable, so much so that my job and his disappeared and maintenance was turned over to the COBOL compiler group, who didn't udnerstand one iota of what it was about. I learned a lot from that process and when I had to turn out a full business-oriented BASIC for the 8085 years later, we implemented the whole affair in 6 months (compiling to a type of P-code) and had a compiler-and-runtime that ran programs considerably faster than BillG's compiled BASIC. I received a note a couple of months ago from an ex-dealer who informed me that, as far as he knew, the BASIC was still in use, running on Unix, although said customer was attempting to make the leap to Visual BASIC and Windows. Nova Try some of the mainframe assemblers. Even late versions of MASM aren't too terrible. On the other hand, the AVR assembler feels as if it was written by an intern. While I can use it, I loathe it. --Chuck

Yet another great post. I wish you would write a book with all these stories. I mean it. If I am not broke, and can't bootleg a copy off the net, I would definitely buy it. Then again I would buy it just to have a hard copy. Is there more than one? But yeah, the IBM macro language is amazing, for all intents and purposes it's a full programming language. I use it a lot, but have never come close to using its full power. Several languages have been implemented using it pretty heavily. SNOBOL4 is a good example that you mentioned. I'm always disappointed in assemblers for other targets, not just because of the (lack) of macro support though. To change the subject yet again in this thread...now that most of us agree C is not much more than a (possibly bad) high level assembler, what does everybody recommend for a general purpose UNIX programming language? Seems to me nothing has the library, GUI support etc. like C and C++ do, but those languages seem suboptimal for most things. I write almost no code on UNIX because I haven't ever found a traditional compiled language I like that has enough support to make it usable.

My inability to identify a good general purpose UNIX programming language that is compiled to native code and has good library support :-) I'd like to be able to write apps with a GUI and be able to issue SQL, just general purpose stuff. On IBM I prefer assembler. PL/I is a good (excellent) general purpose language. Ada 95 is also a good general purpose langauge, but stiffer than PL/I and can be annoying especially when working with strings. I'm not aware of any PL/I for UNIX or Linux, and Ada while available and very good, lacks SQL and GUI support or quickly runs into GPL contamination issues just from linking libraries which is not something I'm going to get into. The ncurses interface for Ada is excellent btw but ncurses has limitations. The examples you listed aren't general purpose programming languages by any stretch and Scheme and CL are normally byte code compiled although if you look hard enough you can find a native code version here or there, but they all have various quirks. Any language that forces you into a paradigm like "everything is tail recursion" or "every solution is a functional program" is (far) too narrow for general use. I could abuse FORTRAN as it has been for most of its life and force it outside the box, but I don't want to do that. C is a good model of the generic approach in that you can write procedural code or write OO code, basically it lets you do what you want rather than forcing a paradigm on you. In that sense, to me it is good. But it's too low level for my taste and there are other things I don't like about it. PL/I would be about perfect if it existed except for the fact all the UNIX header files are in C. To me that is a problem I don't know how to get around in all languages other than C/C++. GUI and SQL would be on top of the list. Not sure what else I would want since I don't write code on UNIX yet. Hoping to though. I used to make a point to choose an appropriate (domain specific) language for whatever task I had to solve. I wound up being good enough with many languages and not an expert at any of them back then. There has been so much language development over the years, I'm hoping there is some magic bullet language (for me) that's general enough and high level enough to be easily usable but with interfaces to anything a normal application could want. Maybe that's not a reasonable goal on UNIX, I don't know enough to say. I do know on IBM all of the application programming languages offer more or less the same support for various items like database, UI etc. and I am used to that model. There are a lot less choices over there so we aren't as fussy. UNIX has so many choices, it makes it a little harder kind of like at a restaurant that serves only one thing (pizza, chicken wings) you don't have much deciding to do but if you go to a place with a phone book for a menu all of a sudden life is complicated. I know there is a lot of UNIX knowledge on this list and wanted to bat the idea around a little and hear what people are using for their main GOTO language (no pun intended!) and why.

On Mon, Oct 17, 2011 at 06:22:58AM -0700, Gene Buckle wrote: Has anyone here given D a shot? /P

On Mon, 17 Oct 2011, Pontus Pihlgren wrote: I always thought that "D" was one of the traditional names to give to languages created in introductory compiler design classes. -- David Griffith dgriffi at cs.csubak.edu A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail?

On Mon, 17 Oct 2011, vintagecoder at aol.com wrote: Kylix is no longer available, but Embarcadero (the company that now owns the Delphi/C++ Builder toolchain) have a new Linux version on their 2012 roadmap. The latest release of Delphi (XE2) natively supports iOS/MacOS and Windows 32 & 64 bit dev. This includes their C++ Builder product. I look at it this way - if they don't like it, they're free to reference Figure One. :) g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.diy-cockpits.org/coll - Go Collimated or Go Home. Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! Political correctness is a doctrine, fostered by a delusional, illogical minority, and rabidly promoted by an unscrupulous mainstream media, which holds forth the proposition that it is entirely possible to pick up a turd by the clean end.

On Mon, Oct 17, 2011 at 6:58 PM, ben <bfranchuk at jetnet.ab.ca> wrote: Is that a trick question? Free Pascal is written in Pascal: http://www.freepascal.org/faq.var#WhatIsFP -- Regards, Torfinn Ingolfsen

On 10/17/2011 08:07 AM, vintagecoder at aol.com wrote: Whilst willfully ignoring the subject's request, I remembered this. I think it's a fitting tribute to dmr. (Piano version here: http://www.youtube.com/watch?v=XHosLhPEN3k ) Filk author Brian Marshall Write in C When I find my code in tons of trouble, Friends and colleagues come to me, Speaking words of wisdom: "Write in C." As the deadline fast approaches, And bugs are all that I can see, Somewhere, someone whispers: "Write in C." Write in C, Write in C, Write in C, oh, Write in C. LOGO's dead and buried, Write in C. I used to write a lot of FORTRAN, For science it worked flawlessly. Try using it for graphics! Write in C. If you've just spent nearly 30 hours Debugging some assembly, Soon you will be glad to Write in C. Write in C, Write in C, Write in C, yeah, Write in C. Only wimps use BASIC. Write in C. Write in C, Write in C Write in C, oh, Write in C. Pascal won't quite cut it. Write in C. Write in C, Write in C, Write in C, yeah, Write in C. Don't even mention COBOL. Write in C. (and what about C++ ?)

From: Fred Cisin <cisin at xenosoft.com> Hah, Fred, I thought it was just me. Glad somebody else had the courage to ask that question. On this list! Yeah, I'm talking about real computers, stuff that needs water cooling, three phase, raised floor, a hundred tons of A/C and a bunch of guys to keep it going.