> Visual programming comes around every ten years, and fails each time
True. I think though visual programming is alive in niche markets -- control systems, audio processing, industrial control. It might have never becomes mainstream but it is not dead there. Telling those experts that they now have to write code, is not going to go well, they'll never be ready to open Emacs and start coding.
> Constraint systems are alive and well in SolidWorks, Inventor, and other such systems.
Also GUI layouts in some cases are done using contraints.
> But I also think "different for different's sake" is a good way of eating money and alienating users.
The goal is not to do just different things, but do different things in order to better solve problems.
> It turns out, just because ideas are interesting, doesn't make them actually better at solving real problems in general!
But if it does, and you never go seek out new things, you'd miss out. That was one of the points in the talk.
For example there is mention of actor programming. I use that to program large distributed sytems in Erlang. And it is not just a gimmick, but abstractions provided by the framework allow a more concise representation of ideas. It does feel like going from Assembly to using C in terms of concurrent and fault tollerant system. You can do everything in C++ of course with threads and locks, and a library with serialization and networking. But it feels like using Assembly. The advantage also comes in other ways -- abilty to have less ops pain because system are more fault tolerant, ability to hotpatch live system and so on.
Someone who is used to segfault crashing whole backends and spending weeks chasing hard to find use after free bugs or concurrency bugs, might not know there is another way. They accept that "this is programming", the manager accepts that this is how systems are written and delivered and this level of cost of maintenance and bug chasing is acceptable and normal. Nobody in the chain will go and seek out and try new tools to solve the problem better.
> But I also think "different for different's sake" is a good way of eating money and alienating users.
That's true to. For every "this new technology helped us double so and so metric" there is 10 stories of "we re-wrote our stable backend in the latest fad language someone read about on HN and now 2 years later everything is crashing and nothing works".