I also wrote my own Forth implementation, in 6502asm, back in high school. Was great fun and a great learning experience. I later wrote a Star Trek space battle

I also wrote my own Forth implementation, in 6502asm, back in high school. Was great fun and a great learning experience. I later wrote a Star Trek space battle game in it. As for aiming for less is hard to reconcile - that's where you and the majority of programmers in the industry go wrong. You should have said "aiming for less is always a valid approach." - full stop. My LMDB database engine is the world's smallest/fastest/most reliable full ACID transactional data store. The core of the engine is less than 32KB of x86-64 object code - it can execute entirely within a CPU's L1 instruction cache. It blows away other DB engines that are several times bulkier in size. It's only 6kloc of C. It does what it does precisely by following the Forth philosophy - do what you need, throw everything else away. http://symas.com/mdb/ http://symas.com/mdb/ Efficiency always matters, even today with CPUs whose L2 cache is larger than entire computer systems of 30 years ago. Efficiency always matters because all of these compute resources have a cost - electricity isn't free, and time spent is irreplaceable. I have other ongoing projects in Forth because it can handle some cases easily that are awkward in other languages. (E.g., an ASN.1 parser for dynamically adding new syntaxes to the OpenLDAP server. Forth is the perfect tool for the job because it's inherently a language designed for extension.)