Technical Difficulties from on Top of the Mountain
2006-09-28
  Changing gears in the middle of traffic
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:
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()) ;
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.

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 ...

 
2006-09-23
  Web 2.%&$#
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 shippingfreightquote.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.

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.

Ok. login, press Quote & ship. bam!

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
 
2006-09-16
  Just so tedious
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.

 
2006-09-06
  Just a little random
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: #define Ra 1629 #define Rm 1048576 static unsigned long ran_seed ; void init_rand() { ran_seed= time() % Rm ; } int get_rand(int n) { ran_seed= (long) (Ra * ran_seed) % Rm ; return (n * ran_seed) / Rm ; } This is fine and all when you just need a few random bits for a game of hangman, or picking a random fortune, but its not so good when having something be random actually is important. There are of course larger pseudo-random cycles, and ways to whiten the data to avoid bias, but you're still dealing with something that's predictable on some scale or another.

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 /dev/random which counted all the generic processes going on inside a computer, accumulating them together to produce random results. The length of a disk seek, the number of times an event was triggered, the checksum bits from various network packets received; thrown together and shaken. This produced decent results when used sparingly, but still not really random. If you're willing to spend enough money, you can buy these really cool boxes that have a radioactive isotope or high temperature thermal emitter and a detector that counts the picosecond spaces between individual particle emissions, but for something casual, these might be overkill.

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.

 
Life in the middle of nowhere, remote programming to try and support it, startups, children, and some tinkering when I get a chance.

ARCHIVES
January 2004 / February 2004 / March 2004 / April 2004 / May 2004 / June 2004 / July 2004 / August 2004 / September 2004 / October 2004 / November 2004 / December 2004 / January 2005 / February 2005 / March 2005 / April 2005 / May 2005 / June 2005 / July 2005 / August 2005 / September 2005 / October 2005 / November 2005 / December 2005 / January 2006 / February 2006 / March 2006 / April 2006 / May 2006 / June 2006 / July 2006 / August 2006 / September 2006 / October 2006 / November 2006 / December 2006 / January 2007 / February 2007 / March 2007 / April 2007 / June 2007 / July 2007 / August 2007 / September 2007 / October 2007 / November 2007 / December 2007 / January 2008 / May 2008 / June 2008 / August 2008 / February 2009 / August 2009 / February 2010 / February 2011 / March 2011 / October 2011 / March 2012 / July 2013 / August 2013 / September 2013 / October 2013 / November 2013 / December 2013 / December 2014 / February 2015 / March 2015 / July 2016 / September 2016 / December 2016 / April 2017 / June 2017 / July 2018 / November 2018 / January 2019 / February 2019 / April 2019 / December 2019 / March 2020 / April 2020 / May 2020 / September 2020 / November 2020 / March 2021 / May 2023 /


Blogroll
Paul Graham's Essays
You may not want to write in Lisp, but his advise on software, life and business is always worth listening to.
How to save the world
Dave Pollard working on changing the world .. one partially baked idea at a time.
SnowDeal
Eric Snowdeal IV - born 15 weeks too soon, now living a normal baby life.
Land and Hold Short
The life of a pilot.

The best of?
Jan '04
The second best villain of all times.

Feb '04
Oops I dropped by satellite.
New Jets create excitement in the air.
The audience is not listening.

Mar '04
Neat chemicals you don't want to mess with.
The Lack of Practise Effect

Apr '04
Scramjets take to the air
Doing dangerous things in the fire.
The Real Way to get a job

May '04
Checking out cool tools (with the kids)
A master geek (Ink Tank flashback)
How to play with your kids

Powered by Blogger