
Internal Reprogrammability (2013) - joeyespo
http://martinfowler.com/bliki/InternalReprogrammability.html
======
agumonkey
Another instance is ex-Alias|Wavefront Maya. The software had a very similar
design. A tiny core for the intensive tasks, and most user facing interaction
programmed through the Mel (Maya Embedded) language. The fun part is when you
realize the whole maya software is a big set of mel scripts. The program can
be run headless, it becomes a mel repl for a geometry DAG and time varying
values.

ps: Saying this circa ~2000-2008. Since then they rebuilt the UI it may not be
the case

~~~
vvanders
I think "fun" can be used pretty loosely here, the number of bugs and gotchas
were quite large. It's hard to say how much of that was due to everything
being built on MEL but it certainly wasn't pretty.

~~~
agumonkey
I never used it professionally but it was one of the "fastest" and most stable
program I've had the pleasure to use. I recall one crash in ten years over
multiple versions. On unsupported hardware. But I can imagine how mel
'semantics' could lead to nasty bugs.

------
tacostakohashi
The author suggests that "Internal Reprogrammability" (I'd just call it
configurability) is a philosophy that has gone out of fashion. I don't think
it has gone out of fashion overall, rather I think it's an early evolutionary
phase in development of most categories of product.

These phases are approximately:

* Primitive (ed, Mosaic, NCSA httpd). These work, just enough to show the promise of the category, but if you want to fix the shortcomings you have to re-implement your own, or hack source code that wasn't even intended for configuration.

* Highly Configurable / "Internal Reprogrammability" (vi, emacs, Netscape, Apache, IBM PC clones). These _can_ be configured to do exactly what you want, with enough knowledge - but then, having done that, one has an unreproducible snowflake system, subtly different and incompatible with any other in the world.

* Evolved (Chrome, nginx, Macbook Air). These are barely configurable at all, and resemble the best possible configuration of the previous generation of products - i.e., they're the configuration you _actually wanted_ all along (and maybe even customized the previous generation to end up with), without having to make all the mistakes yourself to work that all.

The way I see it, these are phases that apply generally to the development of
all categories over time, and different products are at different stages -
they're not philosophies that themselves go in our out of fashion. I quite
often see products that are fairly clearly in one of these phases, and use
that phase to help choose wether it's something I want to hack on an early
incarnation of, or wait for the dust to settle.

~~~
rileymat1
It is completely fair to distinguish "Internal Reprogrammability" from
configurability with respect to Emacs. Emacs is vastly different than most
systems that are highly configurable that you mention.

