Richard Bucker

The any language challenge

Posted at — Jan 5, 2015

One of the challenges of most programming languages is the stratification of complexity. Just last night I was responding to a post which criticized K&R and this morning it’s even more clear to me that there is a stratification of code within any application. Meaning that some code is almost considered MACRO like and some code is considered low level. In my opinion one thing that makes any code hard to read is when the delineation between layers gets fuzzy.

In almost every application I write there are 4 layers:
And with a sensible namespace and directory structure it’s easy to learn and relearn.

Over the last few years I have repeatedly fallen into a trap. On the one hand I want to make software implementation more like assembly… just bolting things together in a loose sort of way. (think Macros) and every time I get there I start thinking about embedded lua, tcl or some other small footprint language. And in some fits of insanity even a lisp variant.

When I wake from my dream I realize that what I’m thinking about is not embedding a simple macro language but strengthening the layers. This, of course, can be accomplished in the source language and requires no special structure or feature. In the wayback days we would use function and filename namespaces to provide hints. Now everything is a package or module.

** with the latest set of golang tools (version 1.4) it might be possible to take this to another level where the task is the code that is generated. That might just be another view of the same solution…