So, I received my Arduino boards today (http://www.arduino.cc). These things are pretty cool, as far as I can tell.

I say "as far as I can tell," of course, because I haven't been able to upload any code to one yet. You see, compiling the C/C++ environment for this architecture takes about six to eight hours to complete, and it's already bedtime for bonzo. I won't have any more time to futz with this thing until Friday.

As if that weren't enough, there are literally thousands of websites in the noosphere, but not one of them describes, really, how to use these tools. Examples abound, but examples can't help you debug, or to understand principles, or learn best-practices.

So, I really find myself pining for a development environment that I can get running in minutes instead of hours, particularly since I have plans for re-imaging my workstation with 64-bit Slackware. Am I impatient? You're damn right I am. Roughly one third of my life has expired, and I'm on the fast-track for type-II diabetes, heart disease, and other genetic ailments my family has inexorably passed on to me. Another third of my life is spent sleeping, and of the remaining third, two thirds of that is spent working. So, yeah, I'm pretty impatient about this. I don't have time to play silly games with tools.

Forth would be positively ideal for this work, of course, but who supports Forth anymore? If you post Forth code on the Internet today, you're branded quaint (at best) or "wholesale inadequate" (at worst). I've been called both (this is why my Forth-written blog is named "Unsuitable," because some dork-off on Reddit decided Forth was "wholesale unsuitable", and my projects "wholesale inadequate." It follows that my next major Forth project will have to be called Inadequate to follow suit). Even if you don't elicit these kinds of responses, nobody is going to willingly want to work with Forth except those of us who "get it." They'll just as soon translate your Forth code into C, and work with it in their C environment. Problem is, I'm apparently too stupid to get C working with the AVR series, if the results from Google or Bing are any indication.

Which makes us Forth hackers look like prima donnas. Then, we become pompously quaint or inadequate. Fun.

I am very pissed off right now. It's a rhetorical question, but I really want to effin' know why C took off and Forth didn't. I really want to know what effin' jerk-off convinced an entire effin' industry that complexity, opacity, and time wasting was in ANY way more desirable than simplicity, transparency, and rapid development. Really.

These Arduino boards have taken the hobby world by storm, and I'm glad others are able to seek utility from them. I just wish I could share in the fun right now.

It's late. I'm tired. I'm going to bed.

Here's a quote from a news release, Vogon News, repeated in a Bob Pease article in the 1990's:


I've worked for a couple of tiny companies for the last 25 years. One of the luxuries is that when I'm the whole department, or at least the only one who knows anything about my part of the work, I pretty much get to do things the way I want to. That means I pick the processors, microcontrollers, programming languages, and so on. There's no one else with a bias against my way of doing things to put one of those labels on me or fight me. And when they see the projects I've done and how I can get away with minimal equipment investment, it doesn't hurt my image a bit.

In my position, I don't have to care what others think of Forth, or whether they want to support it or not. Or maybe I should just say I don't care what they think. Early on, I had the mentality of wanting to pick up as many programming languages as I could. When I got to Forth, that ended—not all at once, because although I liked it, initially I was skeptical about its ability to do certain things; but as I gained experience with it, I found that not only could it do them, but far more elegantly than anything I had previously seen or imagined.


Rhetorical, yes, as you do know the answer. For other readers, I'll comment anyway. It's politics, and the C compilers makers' potential for profit, something that's harder for Forth suppliers to do since if they say, "You need our new version because it can ________<fill in the blank>," you'll just say, "Good idea!" and go do it yourself, because Forth lets you get under the hood and do it, unlike other languages. And, I suppose, one of the things that gives people a reason to be against if if they really want to be is the fact that it's a "programmer amplifier." It makes good programmers better but bad ones worse, and they'll pick on the latter.

A major editor of, IIRC, Embedded Systems Programming magazine wrote about the foolishness of using Forth in small embedded systems where the comments take up so much room in their already-tight memory budgets. This of course is not true at all and readers jumped all over him for saying something out of what appears to be willful ignorance. He didn't want to be bothered with the facts. His bias against Forth was consistently clear in the various articles. Not long after, I canceled my subscription.

hehe, Douglas Adams humor.

After a career in chemistry I decided in 1988 or 89 to take night C class at a local JC to round me out a bit. Before the teacher started instruction in the language he gave a lecture on form before function. It went something like:

Don't mix code and comments
Use descriptive names for variables and functions
White space doesn't hurt you and makes your code readable

I think he lost the fight.

Remember the 90's when they were selling C as having compilers written by the 'gods of programming'? Spin was: Even if you learned assembly you code could never compete with the efficiency of their code. You were bombarded with 'give into the dark side' advertising.

C is no longer a programming language, it is a religion with its own dogma of faith over fact, rife with true believers. There's nothing wrong with it except some practictioners.

Rick

This is somewhat true, though. Contemporary microprocessors have speculative execution, out-of-order execution, unthinkably deep pipelines which have to be kept full, superscalar execution engines, register renaming, and more. All of these features, alone, accounts for some fraction of the performance boost we enjoy in contemporary processors. Keeping track of the book-keeping needed to ensure that, e.g., a branch doesn't cause some speculative execution to pre-compute some critical value to be thrown away is insanely difficult.

Contemporary stack-architecture processors gets rid of all this overhead, but you're back to one instruction per clock, unless you go with the multiple core approach to parallelism (which I think we're learning is now a vastly superior parallelism model anyway). Now you run into the challenge of how to properly decompose your otherwise sequential application to properly utilize cores in tandem.

It's entirely possible, of course, to engineer a Forth compiler to exploit contemporary CPU features (see the Factor programming language for a great example of a stack-architecture language that has phenominal performance on modern CPUs). But, you're again looking at a compiler that is opaque.

But, my concern isn't with C as a language. I can grok C. I've used C for decades. C is nice, if you respect its limitations (namely, it's a syntactically convenient PDP-11 assembler). The problem I have lies with the tools in particular. Going from C to some flat binary model is a complex operation, that requires tight coupling between each of the tools in the toolchain. Versions mismatch? Screwed. Can't compile the tools themselves? Screwed. Can't understand the documentation? Screwed. Can't FIND the documentation in the first place? SOL.



Well, after going to bed last night, I slept soundly, knowing that after six or so hours, I had my toolchain compiled at long last, and producing object files locally. Tonight, I'll attempt to exercise the hardware by illuminating an LED in morse code, transmitting my amateur radio callsign over and over again.

Then, once that is finished, I hope to repeat the task coding in straight assembly language. (I need to use pure assembly for my Arduinos because I'm coding them to be HDLC transceivers, and that means I need precision timing to retain bit synchrony.)

To me, the funniest part of this classic is that it actually does compile. (It's from an early IOCCC winner, for those who didn't know.)