First, this programming technique is indeed a fast way to solve certain kinds of repeated interaction problems, but leads to fragile systems. They tend to be poorly laid out, hard to understand, have lots of things that can go wrong that aren't handled, and so on. You should recognize this description if you've ever dealt with critical business processes that got started as a glorified spreadsheet from a non-programmer. Those drawbacks aren't a big problem for testing suites. But they are if you're maintaining production systems.
Second, my personal reaction to anyone who is excitedly talks about the next big paradigm shift is to label them as someone who likely doesn't know what they are talking about, and almost certainly doesn't understand Kuhn. Put simply, a paradigm worth discarding at the drop of a hat wasn't worth owning, and the paradigm that you discarded the first one for probably isn't either. Paradigm shifts are not good things, they're very expensive messes that sometimes become unavoidable. The value that is perceived in them could not arise but for the far less visible effects of people working within good paradigms before and after the shift.
If the second comment puzzles you, read The Structure of Scientific Revolutions by Thomas Kuhn. Again if necessary.
In reply to Re^3: Spreadsheets, HTTP::Recorder and interactivity
by tilly
in thread Spreadsheets, HTTP::Recorder and interactivity
by zby
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |