As some of you may know, I've been considering the design of a new programming language lately. (And for those who haven't yet heard me talking about it, I will... at great lengths... whether you want me to or not.) This has been one of the things which has kept me busy and away from blogging of late. I'm not sure how much I should ramble on about it here though.
In working through my thoughts on the language, I'm writing an essay in three parts which mainly aims to justify why I'm doing this. (Before the abundance of circumlocutions becomes overwhelming, let us call this new language "Eng".) The first part is basically a laundry list of little features or attributes that Eng — or any language — would need to thrive against the current competitors. The second covers what I deem the fundamental Laws of Language Design, and these perhaps are the crux of the piece; certainly they are the part of the essay which is most liable to be useful outside of organizing my thoughts on Eng. And the third section of the essay is intended to introduce some ideas I have which would make this new language special. But there's a problem.
See, the problem is that many of these nifty new ideas I have are profound. Perhaps not earth-shattering, but certainly interesting enough to warrant each getting an essay of their own to fully delve into explaining what they are, let alone their significance. Just to mention them in brief without exploring at least the first layer of ramifications they introduce would do them a disservice. But if I were to expound upon them, I'd end up with at least three more essays, at which point it's starting to look like I'm writing a book.
Granted, this is one of the things I'm considering for my masters thesis, but if I were to expand the essay into a thesis, it would need to be a lot more focused and tied to my research and experimentation. I.e. it would become more of a manual of how the language is designed, geared towards those who are interested in implementation details, rather than an off-the-cuff analysis of why the current slew of Mid-Level Languages is insufficient and how one might go about creating a new MLL to replace them all. Though, depending on the advisor, there may yet be merit in a thesis which has that as well.
I know many of you are not particularly CS inclined, though a handful are. I guess I'm curious how many of you would actually be interested in hearing me blather on about Eng? At least it's a more accessible discussion to the layman than my second potential thesis topic of implementing Optimality Theory using analogy-making as a Complex Adaptive System.
 The first would be on "lexical aliasing", an interesting abstraction which solves numerous seemingly-unrelated problems and which, taken to it's logical extreme, reinvents most aspects of functional programming. The second would be on the irony of creating an inherently parallel MLL since there's a conflict between what a natively parallel language should do syntactically and what a MLL should. And the third would be on "tensors" (working name), which are a generalization of scalars, arrays/vectors, 2D-arrays/matrices, etc up to arbitrary dimensions. These too are mostly a fallout of native parallelism (of the synchronous variety), but helpful because they merge what are often dealt with as separate entities and also allow scientific-level programming without introducing additional constructs.