I have now officially completed the third of four rounds of chemotherapy for the cancer. The drips finished yesterday just before noon, and I had a couple of pills to take this morning after breakfast.
After the infusion yesterday, they stuck a small boxy thing on my abdomen that gave me more medication to stimulate the bone marrow, in particular to ward off a low white blood cell count, another possible side effect of chemo, giving an increased risk of infection. I was instructed to take it off when the green light stopped flashing, which it did about 4:20pm; and I promptly took my first real shower in six days. 😎 (It was a little disconcerting the first time I woke up to see my stomach flashing green; but after a beat or two of cognitive improvement, I knew what it was and could laugh at myself.)
As before, I’ve been fortunate to experience none of the horrible side effect of chemo. I expect my bowels to be all stopped up for two or three days, but that’s just an annoynance.
Next up is to get all ready for my trip to Hawaiʻi that starts on Wednesday. That trip will get in the way of my fourth and final round of treatments which will be delayed a few days until the Monday through Wednesday before Thanksgiving; but I was adamant that I wanted to make the trip. These ISO standards committee meetings are what’s keeping my brain exercised during retirement. 😎
You seem to be doing very well with the chemo, for which I’m glad. Have a great time on your trip!
C++ is pretty nausea-inducing but I am super glad your chemo’s not too bad.
Marcus Ranum:
No, it isn’t.
OK, now that we’ve gotten past points made without evidence being refuted without evidence … 😎
In the hope of not sounding like I’m tooting my own horn, let me say that it’s only because I’m an old fart that I’ve had plenty of time to have written real programs in:
COBOL
Fortran
RPG
BASIC
Pascal
C
C++
Java
Informix 4GL
Oracle’s PL/SQL
various assemblers
PDP-8 machine language
(I’m not old enough to have programmed using wired boards. 😎 )
Of all of the above, I’ve found C++ to be by far the least frustrating.
There’s no such thing as a perfect programming language. C++ certainly has its warts, including some real dangers that could be exploited by hackers or simply used by regular programmers because they don’t know any better. Many were inherited from C, but the WG21 committee has had a few ideas of its own that turned out to be bad ideas in the wild.
We have an imperfect language that was designed by imperfect people. Film at eleven.
Glad the treatment is still not affecting you beyond the constipation, and that you get to go to the standards meeting, enjoy missing a few days of colder weather!
Of all of the above, I’ve found C++ to be by far the least frustrating.
Interesting.
Most of the problems that caused C++ were actually linker resolution issues with the original C object/library model and the authors of that suite being wedded (because of hardware limits) to a single-pass compile/link flow. Otherwise, it would have been relatively simple to put the data type into the object code function template so that a call like:
would link the appropriate object code, by checking the type match. That would also have caught a lot of the breakage that was easy to do with C if you didn’t know your libraries well. That actually covers a whole lot of the stuff that C++ brings, without the need for all the extra crap. The one-passness of the compiler/linker made it necessary to allow mis-linkages on incompatible parameters. A two-pass linker could also do constructors and destructors when something goes in and out of scope, but I’m really not a big fan of those. As a general rule I it is my sternly held opinion that compilers should not call hidden functions – if a programmer wants to initialize a struct foo, why not have them explicitly call init(x); then use the linker overloading to resolve it to a correct function for the type? I used to think that part of a data structure’s definition should include whether it expects to have an init(struct…) call and a free(struct…) call and generate a warning if it falls out of scope.
Last, but not least, C++ (again in my opinion) owes whatever popularity it has to getting away from C’s malloc()/free() manual memory management. Unfortunately, it replaced it with something cumbersome and not hugely better. I’m biased, of course, because when I was writing C++ I was using cfront 1.0 and often had to read the output and all it was doing with new/delete was calling the appropriate member function with free() and a completely disgusting cast. At the time a few of us joked that all a C++ compiler did was cast everything to a (void *) and back, to suppress compiler warnings. Perhaps my disliking for C++ is a result of having looked at the code generation. Of having had to look at the code generation. Yuck. And, because it basically sucked in all of libc in hidden functions, executable bloat was a real problem on a Sun3/110 with 8MB of RAM.
Fun true story, at the first USENIX C++ symposium, in Denver, it was raining and I was returning from lunch with Andy Koenig and Bjarne Stroustrup. At one point, BS started to run across a street, stepped right in front of a bus, and I pulled him back out of the way by his collar. The future of computing changed for the better/worse in that moment. A joke they used to tell in the UNIX room at Murray Hill was that BS had seen the source code for S. R. Bourne’s shell and thought that was a good way to do languages. Bourne used the macro processor to define his own language variant, including some truly horrible preprocessor substitution tricks – like:
X= CALL function param1, param2;
turned into
X = function(param1, param2);
you can see how someone might think that a preprocessor was a “good” way to add constructors/destructors and member functions.
A two-pass linker for C could have handled member functions easily, you simply
struct foo c;
c.free();
and it calls free((struct foo) c); with the specific scope of the variable which is basically what C++ used to do under the hood anyway.
Like any old grognard I mostly grit my teeth in disgust at the popular programming languages of the day, which don’t even have a debugger. Programmers making obscene amounts of money are putting print lines in their code, to figure out what is going on inside. We’ve regressed dramatically since the late 80s. There are interesting problems in computer language design, which language designers appear to be wilfully ignoring, which would make a big difference – e.x.: memory allocation/deallocation and scope tracking, memory tainting, a debugger that works somehow across both sides of a web transaction – browser and server, also transactional persistence and application freeze/thaw state. The web “stateless” service model is complete bullshit and never should have happened, etc.
Fingers crossed for the treatment continue to go well!
I wish you the best, Bill.
I have to say, though, I’m no great fan of C++ (or is I like to call it, C–). I too have programmed in several languages, and ANSI C remains my favorite. Maybe it’s because I’m a hardware guy and like access to the silicon, I don’t know. I first learned K&R C and was very happy with the ANSI changes. I recall when C++ first came out and it struck me as odd. Stuff was hidden from me. I started way back with BASIC and 6502 assembler, and one thing I knew for sure was that I didn’t like assembler. BASIC was much easier (and ideally, not platform dependent) but it was so limited and removed from the hardware. C was ideal when I was programming 68k systems that only had 2 Meg of RAM. With C++, I always felt like, if I needed a spoon, it would give me an entire tableware set for 12. And years later, teaching microcontrollers using the Arduino platform (with 32k RAM on a 16 MHz 8 bit processor), C was the way to go. Who does microcontrollers in assembly anymore? (Yes, technically, the Arduino doesn’t use C, but a sort of subset of it, which is close enough. Besides, I wouldn’t just use the Arduino libraries, but rather I’d explain the library code and use more general techniques that they could apply to almost any microcontroller. There are a zillion Arduino books out there and almost all of them are lousy if you’re trying to learn about microcontrollers in general.)
But arguing about programming can devolve into something akin to arguing about religion, generating more heat than light.
jimf: yeah, for low-level stuff like the microcontrollers you mentioned, I wouldn’t recommend C++ either; but there’s no reason to expect that any particular language will be the best for all applications. IIUC, the market for C++ is mostly the shrink-wrapped software you buy at computer stores, and with numerics folks and game authors becoming increasingly interested.
In my case, most of my experience is in the good old “business data processing” domain; and I’m currently working on a library to access SQL databases, loosely similar to the java.sql.stuff, but more C++-like. (There are some other third-party libraries out there, but they tend to be quirky, and I suspect that they don’t scale up well.)
So I have, among other things, connections, statements, columns, rows and tables, all of which are obvious classes or class templates. I also needed a fixed-point decimal type to be the C++ equivalent of SQL’s NUMERIC and DECIMAL types, so I wrote one. There’s also a transaction class that uses RAII to roll back work that hasn’t been committed when the transaction goes out of scope and so provides a good bit of exception safety. Trying to do any of that in any other language that I know would have left me totally frustrated.
There’s no perfect programming language that can solve all problems.
there’s no reason to expect that any particular language will be the best for all applications
True, and that reminds me of a comparison that I read many years ago:
Novice programmers try to figure out how to code a problem.
Seasoned programmers try to determine which language is best suited to solve a problem.
Expert programmers create a language to solve a particular problem.
Maybe a bit overstated, but there is a ring of truth to it. I certainly do not consider myself an expert, primarily because I always looked at programming as a tool to do other stuff that interested me (in spite of the fact that I have an MS in CS, I consider myself to be an electrical engineer first).
Glad to hear that your chemo is going well. I hope it works like it should and gives you decent quality of life for years to come!