(Discussion moved from SelfDisciplineDiscussion.)
...And, despite your doubts, hard-wiring in intelligent support for FunctionalReactiveProgramming and EventDrivenProgramming and PublishSubscribeModel (to access external data and event sources) is a fully proven requirement. Even your applications would benefit from it - unless you can honestly tell me that there is no business demand for 'reports' and forms that stay updated in real-time. Besides, with LanguageDesign, how much do we really need a new language that rehashes all the problems of the old one?
Please clarify "fully proven requirement". I don't doubt that certain niches make heavy use of them. The issue is whether they should be hardwired into every app language. As far as "updated in real time", a "refresh" button and/or auto-polling has been plenty sufficient the few times I've had to implement such. And when I leave, the new guy can understand it without reading about a convoluted framework. I believe a sound cost/benefit analysis will show me correct. And even MS building Excel may not be enough times to justify adding it to C++, since only say 1/1000 of every C++ app needs it also. For the other 999, it's just a thicker book and a bigger index to learn to visually ignore in the right spots. Fat books are often not a productivity improvement. I'd put the break-even point at very roughly 10%. If we start looking at common idioms, my wish-list based on observed frequency doesn't look anything like yours. -t
[...]
It takes a serious WorseIsBetter mentality to say that simply because your clients are used to pressing 'refresh' buttons means they should be. The demand for real-time features has been around for years now. My own clients want DVR-style rewind capabilities - not a refresh button, but a temporal 'slider' to quickly review histories. But people are used to disappointment, and you seem entirely too pleased and smug about disappointing them.
Please tell me more about this application. How long does it keep a history? How frequently? Does it get data from a database? Does it keep any stale snapshots, or is it constantly querying? How do you ensure its not flooding the RDBMS?
- My application: user-defined time to keep history (limited by HDD), reactivity requirement is <100ms, data is from several dozen different sources (unmanned systems, different maps databases, sensor networks (cameras, radar, motion sensors, GPS units) - all of them 'live'), there are also hundreds of rules that must be evaluated determining alerts and display properties (i.e. whether a particular icon is greyed or enabled, whether a particular icon is visible or highlighted, etc.) And ideally there is no network traffic between it an any external DBMS except when a relevant change occurs (polling - as in "constantly querying" - is only for shitty designers). But even typical CBAs would benefit from much the same... i.e. a forum or WikiWiki where one could see changes immediately as people post, and where the checkmarks in the check boxes indicate a live state that you're free to mutate.
- You are not describing the context or industry. But it sounds like something akin to a chemical plant, war room, or nuclear power-plant control and monitoring system. I agree that a fancier approach to display concurrency management is warranted under such a system. Perhaps that domain needs a special app language: real-time control systems. I knew some guys who used to build those with LabView. As far as a Wiki with better change-display management, that would indeed be nice to try, but the programming for that would be much greater because there's more integration to manage and more configuration decisions to be made. (Actually, I'd prefer a ParagraphWiki, which would change the dynamics.) Thus, all that stuff is not a free lunch even if it exists in a language. And it wouldn't be at the top of my wiki wish-list. It might even be distracting. I'd rather focus on writing and then worry about who changed what when I'm done. My head is single threaded. I find your justification weak. There's lots of other areas I'd fancy-up first or create a GodLanguage around if going on a feature spree. You are not singing to my needs, but rather your needs. And I believe your GodLanguage approach will never succeed in the marketplace due to the reasons described in the WorseIsBetter article. -t
And I said that auto-polling was also an option, not JUST a refresh button. For example, let's say it's a screen for managers at an order fulfillment warehouse to monitor pending and recently-filled orders. To avoid flooding the database, the poll rate is set to 30 seconds. But for the few times he/she wants info quicker, there's a Refresh button. That way the DB is not flooded with re-queries, and the refresh button gives the option of quicker update time for the few times it's needed.
Refresh Need Discussion