The FORTH liberation

Bought my self two Arduinos (UNO and Mega) because, you know, you need to work with sensors and embedded little thingies. Also, you have to be able to fully grok a circuit, to understand the architecture, the assembly language, and so forth (pun intended). I bought a book about FORTH on the ATmega328P chipset, i.e., the heart of Arduino, by Dr. C.H. Ting, of eForth fame. It blew my mind. You wipe out the original bootloader and load FORTH on it. From that point on, you have full control, even stuff that the Arduino C compiler won't allow you to do. I'll just leave this quote here: "In explaining how this system is constructed, every step in the way, I hope to lay to rest these myths that computers are complicated, programming languages are complicated, and operating systems are complicated. All these things can be very simple, and can be understood by ordinary people and ordinary engineers. If you understand this 328eForth system completely, the understanding can be carried over to any computer and microcontrollers. People using computers are trained to be slaves. You are taught to push certain buttons, and you are taught to push certain keys. Then, you get employed to push buttons and keys to work as slaves. Computers, programming languages, and operating systems are made complicated to enslave people." -- C.H. Ting.

Lisp macros and why Smalltalk doesn't need them

Lisp is homoiconic and this allows for its powerfull macros. But there's two other languages that don't need macros (talking about the 'Big Old Languages', and not the manifold spawns): Smalltalk and Forth.

Here's a very insightful take on why Smalltalk doesn't need macros, by Richard Kenneth Eng:

"...macros make Lisp powerful because they allow you to write programs that themselves write programs. But that’s what macros are, not what enables them–Lisp’s macros aren’t the cause of its power, they’re a symptom of it. What makes Lisp powerful isn’t its macros, it’s the fact that Lisp runs in the same context it’s written in. It’s s-expressions all the way down. This leads to an interesting possibility: could there be other ways to achieve similar power? Are macros the only possible way to make programs that write programs, or might there be others?

Smalltalk goes one further than Lisp: it’s not that Smalltalk’s source code has no syntax so much as Smalltalk has no source code. “Source code,” after all, just means “program that isn’t running,” and there is no such thing as a Smalltalk program that isn’t running! Because there is absolutely nothing in Smalltalk except “data that runs”–which is what an object is, after all–then there is no distinction in Smalltalk between data and programs. Data (objects) can write programs (objects) which write data (objects) which write programs (objects) which… "

Getting the specs right is a fallacy (Lehman-Belady's Law)

"A classic study by Lehman and Belady identified several 'laws' of system change.

Continuing change > A program that is used in a real-world environment must change, or become progressively less useful in that environment.

Increasing complexity > As a program evolves, it becomes more complex, and extra resources are needed to preserve and simplify its structure

Studies have shown that more than half of total software budgets are devoted to 'software maintenance'. Furthermore, there are many claims that the cost of fixing errors in software projects goes up over time. This suggests that one should try to catch errors as early as possible, and perhaps one should invest more effort into 'getting requirements right'. The latter conclusion is a fallacy, however, if we recall that Lehman's laws tell us that requirements will always change."

-- From Oscar Nierstrasz, at a delicious Smalltalk course @  scg.unibe.ch/teaching/sma

-- See the Wikipedia article on Lehman's Law