This weblog is all about Embedded Systems Design for smaller 8 and 16 bit systems because that's what I do all day. You'll find links to and commentary on stories that I dig up while browsing around the web, and from time to time I'll write up an article on something that particularly intrigues me.

Interesting content so far:

[via Scripting News] The New York Times reports that Charles Simonyi is leaving Microsoft to start his own company that hopes to make writing computer programs easier by using a combination of graphic images, charts, and text.

The idea, Mr. Simonyi said, is to make it easier to build and debug complex software programs by moving a step further away from conventional, close-to-the-machine coding ? the painstaking handwork that can be where programmers' good ideas or intentions are lost or left out.

Some of you may not know that Simonyi is also the architect of the Hungarian notation that is used in many Microsoft products. It adds prefixes to identifiers to help programmers understand the identifier more easily. In its most extreme form, it makes code unreadable, so I use a trimmed down version in my own code.

What gets me all fired up is the notion that designing and implementing complex software systems can be made easier by automating the process. Programming is hard work. The hardest part is getting the design right.

How does wrapping the problem up in yet another layer of abstraction make things easier? And how do you debug the code generated by this graphical system?

"His research had its ups and downs at Microsoft, Mr. Simonyi acknowledged. But he is being joined in founding Intentional Software by another leading researcher in software engineering, Gregor Kiczales. Mr. Kiczales, a computer scientist at the University of British Columbia, has had success applying a technology called aspect-oriented programming to make changes automatically in complex software, like sophisticated financial-transaction programs.

Don't hold your breath. By the time they figure out how to make accurate changes in huge code bases like financial tracking systems we'll be old and grey.

[via SlashDot] Edsger Wybe Dijkstra has died after a lengthy struggle with cancer.

Dijkstra was notorious for his wit, eloquence, and way with words, such as in his remark "The question of whether computers can think is like the question of whether submarines can swim"; his advice to a promising researcher, who asked how to select a topic for research: "Do only what only you can do"; and his remark in his Turing Award lecture "In their capacity as a tool, computers will be but a ripple on the surface of our culture. In their capacity as intellectual challenge, they are without precedent in the cultural history of mankind."

I know that my professors at the University of Waterloo tried to hammer the complexities of real-time programming into my thick head, and that only real-world experience taught me how it actually works. For those of you that don't remember, Dijkstra deveolped the p & v notation for describing locks on resources. Every time you write or use code that handles resource locks (like Radio does) you are using stuff developed by Dijkstra. Thank God he didn't patent any of it!

Dijkstra was a prodigious writer. His entire collection of over thirteen hundred written works was digitally scanned and is accessible at http://www.cs.utexas.edu/users/EWD. He also corresponded regularly with hundreds of friends and colleagues over the years --not by email but by conventional post. He strenuously preferred the fountain pen to the computer in producing his scholarly output and letters.

Amen. I'll take my Mont Blanc Meisterstuck and a notebook filled with creamy paper over a laptop for scribbling ideas any day. Rest in peace Edsger.

The new 2.1.5 Version of pbForth has a few minor bugs fixed, including a stack error in MARKER and a fix for LEAVE. The GUI also has a few minor fixes.

I've also added a tutorial on sending and receiving IR data using pbForth.

Thanks go out to Alexander Cech of Austria for supplying great bug reports!

[via c.l.f] Here's a guy that really nails the idea of silver bullets in programming:

It seems to me that, at a minimum, a professional programmer should be expected (and expect of themselves) proficiency in one assembly language, one procedural language, one object language, one scripting language, and several design/definition methodologies. Only with these "bullets" in hand will they be able to make rational design and implementation tradeoffs.

If you have a hammer, everything looks like a nail.

In principle, all Turing Complete languages can compute anything that is computable. But in practice, they are not all equally suited to all classes of problems. Most importantly, New Bullets Are Not Inherently Better Than Old Ones. They each just solve different classes of problems well.

Amen, brother...

The new 2.1.3 Version of pbForth has a few minor bugs fixed, including a stack error in SOUND_TONE and a pesky communications bug that causes the RCX to hang if you shine a bright light at it.

Thanks go out to David Rojas and Rob Harvey for supplying great bug reports!

The pbForth website has been updated with a new article describing how to use the pbForth Assembler. The assembler is a text script that you upload to the RCX. The RCX actually assembles source code for itself. Total code space usage is about 4K.

The new 2.1.2 Version of pbForth has support for background processing and saving your work as an SREC file that you can load agin like regular firmware.

This means you no longer have to load the base pbForth firmware and then load all the text scripts on top. You just save your working system as its own firmware! Super feature if you're involved in code-only competition and need to email a firmware file.

The pbForth website has also been updated with articles describing how to use SAVE-SYSTEM and the new background handler.