I have been quite busy these last couple of weeks working on a number of things. Most of the time my brain is in perl, but occasionally I switch out of that mode and into C++ mode and boy does that take some work.
It could be easier. I know a lot of people who write code in perl like its just another version of C where you don't always have to put the semicolons at the end of the line and the variables all start with a dollar sign. Their code is rather long winded and misses at least half the point of perl. Several years ago, while working with my friend at another startup, I decided I was going to truely work in perl, and think in perl; which meant doing things differently than I did before. Miles of map{}s and grep{}s later, my code shows no resemblance to C, and I've actually had to work on using for loops again where they are occasionally called for.
C++ is another language, closely tied to its parent language C, but all about shifting away from the limited constructs of that ancient language and creating a environment where new more complicated objects can be created. Unlike lisp, where each problem is solved by creating a new internal language; C++ is all about creating new objects (and object slivers) that organize themselves around the problem until the problem is solved in a line or two. But given its much younger age, there are rough spots that have to be worked around.
The first problem in moving from one language to the other, is that the workflow is totally different. In perl, you move through the problem throwing patches of code here, and using the incredible syntax and components of the language itself to transmogrify the problem and bind the steps to the answer together. Its like using giant inflatable tubes and rings, and a whole host of super amazing sticky plastic to build a house. You probably wouldn't plan things ahead of time too much, you'd just start inflating parts and gluing everything together. If something wasn't turning out right, instead of trying to fix it; you'd just cut it out and do it again in a few minutes—the ultimate iterative environment. This of course would drive architects crazy, as they would be out of a job. And it would probably be an alien process to your regular carpenter who wants to have something to cut and nail together, and expects to report to the same site for a month or more before he has to move on to the next job.
Programming in C++ is even more alien. Its like creating the ultimate tool, that with one press of the trigger: will cut, assemble and fasten the entire house. Except of course, that the people who came before you only needed either a single room house, or a skyscraper. So you sit there with the cover up on the darn thing trying to jigger it to make a dormer. Or you decide you'll start with the one room, and then hit the button a few more times to make some more, then maybe try turning it sideways and see if you can shake out a second story. If you're lucky enough to go through this a couple of times without killing yourself, then the next time around you start to wonder if you might be able to start with the skyscraper instead, and then tack on dormers and pitched roof. And after about five or six of these, you start to understand the structure underneath and you start trying to make your own gadgets which goes along great until your wife asks if you can add on a garage.
It doesn't help that its been a while since I did any serious C++ work, and quite a bit of it was on startup projects where I had a blank slate to start with, and so amassed a closet full of rather complex gadgets. Some are easy to pickup after collecting dust. My tlist class is still one of my favorites, especially with my auto-iterating-pointer. When I show people, my loop, and its just: while (++ p) { p-> do(); }, they are amazed. But that's how things should be—powerful concepts, realized simply. That's what made C so great. The string copy function was just so darn simple:
strcpy(char *dest, char *src) { while (*(dest++)= *(src++)) {} }Some of my other gadgets are not quite as polished, and I don't always cleanup everything before I put things away. I wasted a couple of cycles just this week trying to remember what the entire comm library was about as it seemed to be just another way to implement a io_framer. I finally reminded myself that having a framer function tacked onto a network library module was great when you were doing networking, but not so handy when you wanted to frame a stream. comm was all about separating out that orthogonal feature so that it could be reapplied anywhere, not just to the first thing I had thought of using it with. So now I can just assemble together a stream and a line based framer with the wave of my hand, and I'm all done:
People complain that modern languages are cryptic, and I've written lines of code in both C++ and perl that give others fits. But there's a reason for the madness. Programmers can only write so many lines a day, and for so many lines of code written, there's going to be a certain number of errors. The amazing thing is that this metric is the same whether you're writing assembly language or perl. The difference is, to accomplish the same task might take 30 lines of perl, or 200,000 lines of assembly. Still its all relative. The string copy example in C was probably just as foreign to your BASIC, FORTRAN, and PASCAL programmers of the day. It was too condensed, it was too simple. But ultimately, after one learned the new concepts of pointers, null terminated strings, and shortcut operators; one was much more productive in C than in those other languages, and C succeeded.class testlink : public commf_ascii, public estream_process { public: testlink(const char * acmd, comm_dispatch * adest) : estream_process(acmd), commf_ascii(adest), ecore_io(_fdport) { } } * link= new testlink("ping localhost", new testdest()) ;
The question to the modern programmer is, will they learn the ideas behind today's power languages, and how long will I be stuck behind them in traffic while they try and change gears? Hmmm. Maybe somebody could invent a mental automatic transmission ...
I'm trying to buy some cheap welding rod, which is unfortunately heavy. Each can is fifty pounds, and I'm interested in at least ten of them. Well, lets see how the web revolution holds up for this one:
Google freight shipping — freightquote.com
Looks promising, sort of the pricegrabber for freight shippers. Of course you have to sign up first (sigh), ok fine. blah blah blah, yahoo.com, blah blah blah done. Ah, there's my nice confirmation letter. Full of so many promises:
Freightquote.com is fast. You only need a few pieces of information, and in seconds you can choose a carrier, schedule a pickup, print shipping documents, and you're done.Ok. login, press Quote & ship. bam!Freightquote.com is easy. Track all your shipments and all your carriers in one place. Get all your shipment activity and freight costs summarized on one simple weekly invoice. And get great customer service through email, online chat, or toll-free over the phone.
Freightquote.com is free. Shopping at Freightquote.com is always free. You only pay for the carriers you use, when you use them.
They forgot one on that list above:
Freightquote.com is broken. We're full of promise but can't deliver when push comes to shove.
But we'd love for you to give us a call. Toll-free: 800.323.5441
At first it was annoying. A can would fall out of the six pack rings and you'd sit there struggling with it for a few minutes to stick it back in. Then it got to be a secret spy ability that you could put the cans back into a holder and mess with your parent's minds (my parent's minds were not on that solid of ground thanks to my efforts). Later as I took over stocking the dorm coke machine, it was all about how fast I could get the cans out of the stupid holder. Figured I knew just about all there was to know about those things in regards to a soda can.
So I was getting a fountain drink at the chevron station, and the guys were hanging out behind the counter, putting the plastic holders back on cans. At first I thought they had spilled some cans and were putting the holder back on. Then I saw one of them reach into a box where they had a whole role of these things and pull another few off. It turns out the station owner buys the cans without the plastic holders, then has the employees stand around putting them on manually. Its not that they're saving the money of not buying the holder, cause obviously they've got a whole box of them there. Somehow its cheaper to have people manually stick the things on than pay the bottling company an extra 0.3 cents a six pack to have a machine do it.
Must be really rewarding work too.
I was helping a friend out over the weekend with a project and we got to the access control unit where he wanted to have long sequences of random numbers for the access key. "Fine," I said, "lets go find some random numbers." Sure you could use rand(), but unix random numbers have never had much respect. Long ago I pulled up a pseudo-random routine from the back of some programming magazine (that's how we learned about new stuff before the internet), and that's sat around in my toolkit for quite some time:
At some point, once cyptrography became more widespread, having something better became more important and people started looking for real randomness. One such attempt was
Still, this is 2006, not 1984; there ought to be some solution out there perfect for the casual user:
Ah, web 2.0 to the rescue: random.org, using background radio noise from the atmosphere as an entropy source, this site produces numbers, sequences, raw bytes or even pictures.
HTML, http, soap and Corba are all welcome.
