Older blog entries for ncm (starting at number 324)

chalst: I have the advantage of having no desire whatsoever to preserve existing Haskell code, nor Haskell coding conventions, nor favored Haskell idioms, nor even laziness-by-default. I'm talking about a language that preserves the fundamental strengths of Haskell-like languages (which does not include their built-in Lispy data structures), adds the fundamental strengths of C++ (most particularly the destructor), and stirs in enough practicality to make the language industrially useful. To be adopted it needs to be able to use C headers as-is with no annotations, and to access structs and call functions declared there, but the syntax for doing it needn't be pretty. Heavily-used, mature C libraries would soon have convenience wrappers (and, probably, annotations), but most substantial programs use a few more-or-less obscure C libraries that don't merit wrappers or annotation. That's OK; most programs that use obscure third-party libraries call them only in a couple of places.

I'm under no illusion about the contempt in which such a language would be held in academia, but academic contempt is a very cheap price indeed for usefulness.

I'm predicting that the end of Battlestar Galactica is going to involve time travel of magnitude ~2000-3000 years.

chalst: Change the language, change the programming, er, paradigm. The great weakness of C++ is its obligate compatibility with C. Aside from this, it's not so different, fundamentally, from Haskell or an ML, except that Haskell lacks the facilities to enable programmers to code and encapsulate resource management. Provide those, and much of what appears to be the core language moves to the library. Add the ability to parse C header files directly, and call functions declared there, and most of your standard library collapses to trivial wrappers. It would certainly be a different language, then, but it could be a foundation for an industry, and perhaps even the Glorious Successor to C++.

Advogato is was under attack. Please Thank you for your help by marking "New Advogator Members" as spammers.

chalst and graydon: It's good to see you both here. I find it a little bit ironic, under the circumstances, for Haskell to be a pig, considering that the Haskell/Caml family of languages has, potentially, much less use for garbage collection than other functional languages, and could, with (what are really quite) minor language changes, live with runtime support no larger than C++'s.

ta0kira: You're right and you're wrong. You're right that it's unfortunate that (by convention) all these headers have the same suffix. There are three types of files involved: (1) Regular C headers with no accommodations for C++; C++ programs that include them must wrap the inclusion in an extern block. (2) Headers that are explicitly both C and C++, and may just be included directly. (3) C++ headers that can't be used in C programs. C99 has some features not yet incorporated into C++, and some that never will be, so a C header that uses them might not be compatible with the C++ compiler you have, or any C++ compiler. A library meant for wide use, though, won't have such constructs in its header file. (I will mention here the contempt and resentment toward C++ exhibited by many members of the ISO C committee, tempered mainly by implementers who have customers that use both.)

Where you're wrong is in the details that make for this messy situation. First, C++ was never, ever implemented as a preprocessor. Even the first implementation translated to C as the target, as is (today) a common way to implement a new language. There was never a time when any text was just passed through; it was always fully parsed and then corresponding C code generated. Second, as redi notes, the compiler has no notion of the language of a header file; it's all just bytes. Some people like to use ".hpp" or ".hh" for C++-only headers, and that's OK, but the idea seems not to have caught on much. Fortunately most C99-only features aren't especially useful in header files.

C++09 is due out soon, and C++09 compilers will accommodate many C99 features older compilers didn't, minimizing the header file compatibility problem. C++1x, in maybe five or six years, will have a proper module system, and maybe we'll be able to get away from header files someday. Practically the only reason for C to exist as a separate language, any more, is as a linkage target for other languages.

If Advogato offered some hint as to how long it's been since a recentlog poster actually read (or, anyway, GETted) recentlog, we would know better whether it makes sense to reply to said poster in recentlog.

I just noticed that it's been a very long time since I clicked through a Slashdot story to read comments, and way, way longer since I posted there. I guess that means Slashdot is dead, in my world. I still read the front page, but now I'm going to start paying attention to whether any of the squibs I find interesting haven't already shown up in other places I read. It seems like there must be some, still.

StevenRainwater: My solution to the problem of twitter feeds has been to filter out all posts by that user. My main difficulty with syndication is that when I go to post a (copy of my) reply to certain syndicators on their own blogs, it sometimes turns out to be impossible. The only place this has caused me any distress is bagder's blog. If I knew that he actually read Advogato, my distress would largely dissipate. Daniel, if you're there, speak!

redi and bagder: I have only heard of "lib" rhymed with "gibe" in a few Microsoft shops. Everywhere else it rhymes with "bib". The old GNU library libiberty (now happily redundant) makes no sense otherwise. Of greater moment, I have encountered people ignorantly spelling out ACL ("access control list") as "ayseehell". It rhymes with "hackle", and always has. Of less moment is "char" -- I have heard it read as "care", "char", and "car", but not yet "chair". Anything goes, but "car" is silly. There is a tradition of doggedly pronouncing acronyms exactly as written, as a futile but unbowed way to discourage bad ones. This rule seems not to apply in the vicinity of RFCs.

In short: cdfrey is 100% right. Avery is 100% wrong. Sorry, Avery. You're still right more than half the time, just not this time.