Hacker News new | past | comments | ask | show | jobs | submit login
Internal Reprogrammability (2013) (martinfowler.com)
25 points by joeyespo on Nov 28, 2015 | hide | past | favorite | 5 comments



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


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.


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.


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.


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: