C-INTERCAL

Following on from the amazing success and uptake of the esoteric language interpreter suite (a bandwidth busting  total of 49 downloads!), I've commenced searching  for other languages ripe for my unwelcome code attentions. And after reading this prolix and circular prose, C-INTERCAL is indeed worthy of consideration.

"The last part of a statement is an optional ONCE or AGAIN. ONCE specifies that the statement is self-abstaining or self-reinstating (this will be explained below); AGAIN specifies that the statement should behave like it has already self-reinstated or self-abstained. Whether the behaviour is self-abstention or self-reinstatement depends on whether the statement was initially abstained or not; a ONCE on an initially reinstated statement or AGAIN on an initially abstained statement indicates a self-abstention, and a ONCE on an initially abstained statement or AGAIN on an initially reinstated statement indicates a self-reinstatement."

Excerpted from: http://www.catb.org/~esr/intercal/ick.htm#Syntax

Agile vs DDD: A microcosm

I've been carrying on with some refactoring to support simple eso-language interpreters generally, building on the False language work. Next target is Befunge-93, and that led me to a few thoughts as the dog and I meandered along.

Bear with me. False has a simplistic notion of a program counter (PC); in fact, a rather standard one, that we can think of as a uni dimensional object - a number, if you will. Befunge-93 by way of contrast, has a program counter that is a point in a finite cartesian space along with an implied vector of movement.

This is why I pondered agile approaches today. When I commenced this amusing side project to create some eso-language interpreters, I was aware of the Funge style languages, and therefore cannot maintain that I had no  idea that  the classical representation of a PC was going to be flawed.

Thus, any base abstractions I implemented that 'enjoyed' this representation would likewise be limited in scope, and would not advance me towards the goal of a more generalized interpreter framework for the esoteric family of languages. However, I did want to release my False language interpreter sooner rather than later - not because of any latent demand you understand, just for personal pleasure.

My own trivial undertaking therefore, and perhaps unsurprisingly, encapsulates a microcosm of the issues we face in a business sphere during software development:

• Time to market: I wanted the False interpreter released more than I wanted the generalized framework in place. I was content to trade off releasing sooner against the predicted cost of refactoring
• YAGNI or TALIA: As I wasn't sure that I would continue, it seemed that YAGNI would apply here, instead of TALIA (previous post) 
• DDD: This eso-language idea falls uncomfortably in the middle of a domain driven design/simple exercise. The entire sphere of eso-languages shows great variety, but little real complexity of domain. For example, Funge-98 describes the existence of possible large n dimensional spaces for program execution - but that is more an implementation difficulty detail, as the model implied does not impose a significant cognitive load for most people.

Simplistic notions simply presented.