jakub_h

The things you're describing are EERILY similar to some stuff I've been conceptualizing and thinking about recently, as inspired by the VPRI people's work/OMeta/Shen. I'd just remark that...

"The program is a UI, and UI interaction is programming. Unison panels take the idea of spreadsheets, which blur the distinction between UI interaction and programming, to its logical conclusion."

...this blurring between programming and interaction (which I've also thought of) probably offers a potentially viable path to much more powerful voice control of devices, since programming APIs serving as user interfaces can now also (besides graphical UI) implicitly define strict grammars for structured voice input. That's the one thing I thought of that I didn't see mentioned there.

Perhaps, but the "solutions", when put together in a single project, probably resemble the "30 quicksorts in a single binary" syndrome. Lots of code doing conceptually the same things.

Do you also expect engineers to drop like flies as they get older so that their numbers would become more in line with the number of available managerial positions? Cause that sounds like a serious flaw with your thinking.

Well, there's always the Smalltalk approach.

> Nobody in their right mind uses this stuff in production code.

You sure about that? I thought the lispy approach was generally pragmatic - you use what you deem handy for your application. It this weren't the case, there would be little need for macros in the first place. I can very well imagine, say, a scientific or engineering application that would share a common infix parser for both user-provided expressions (in the UI, to be more friendly to non-lispers) and heavy math lifting in the source code.