"Why Scripting Is Evil" -- comments?
in [Shell]
|
Prev: Bash Shell escapes not working via Putty ssh?
Next: An instructive example of trace-function and some example of debugging
From: J. on 12 Jun 2010 10:22 Is all that FAST/ObjecTime/TestMaster/TAU/UBET/etc related to UML (Unified Modelling Language)? All of this anti-scripting remembers me to a man directing his project, where a lot of time was spent doing UML diagrams, unit tests for everything... He didn't want a single line of python in his project. These things seem to me a way of making users rely on very complicated things and having a lot of control over everything and everybody. Another reason might be cargo-cult believings. Ed Morton <mortonspam(a)gmail.com> wrote: > Looks like it's just rehashing all the old arguments for why model driven > approaches to software development are superior to just programming solutions to > a specific problem. In particular the discussion reminds me of the product-line > architecture or FAST (Family-oriented Abstraction, Specification and > Translation) approach from the 1990s. All good arguments, and all usually > negated by the fact that programmers just don't want to do it for many reasons > including their familiarity with the approach, initial development schedule, > cost of licensing the modeling tools, risk of getting bound to one modeling > toolset that might go belly-up or change their specification format (as SO many > have - ObjecTime, TestMaster, TAU, UBET, etc, etc.) and so on. > > All good arguments in theory but as we all know theory and practice are only > equivalent in theory, in practice they're quite different. > > Ed.
From: Ed Morton on 12 Jun 2010 14:16 On 6/12/2010 9:22 AM, J. wrote: <PLEASE DON'T TOP-POST, FIXED BELOW> > > Ed Morton<mortonspam(a)gmail.com> wrote: >> Looks like it's just rehashing all the old arguments for why model driven >> approaches to software development are superior to just programming solutions to >> a specific problem. In particular the discussion reminds me of the product-line >> architecture or FAST (Family-oriented Abstraction, Specification and >> Translation) approach from the 1990s. All good arguments, and all usually >> negated by the fact that programmers just don't want to do it for many reasons >> including their familiarity with the approach, initial development schedule, >> cost of licensing the modeling tools, risk of getting bound to one modeling >> toolset that might go belly-up or change their specification format (as SO many >> have - ObjecTime, TestMaster, TAU, UBET, etc, etc.) and so on. >> >> All good arguments in theory but as we all know theory and practice are only >> equivalent in theory, in practice they're quite different. >> >> Ed. > Is all that FAST/ObjecTime/TestMaster/TAU/UBET/etc related to UML > (Unified Modelling Language)? FAST - no, it's a methodlogy for you to create your own AOLs ObejTime - not exactly, it was OO but predated UML. TestMaster - no, it was it's own language. TAU - no, it was various ITU specs (e.g. Z.120, SDL, etc.) UBET - no, it was ITU Z.120 for HMSCs Ed. All of this anti-scripting remembers me > to a man directing his project, where a lot of time was spent doing > UML diagrams, unit tests for everything... He didn't want a single > line of python in his project. > > These things seem to me a way of making users rely on very complicated > things and having a lot of control over everything and everybody. > Another reason might be cargo-cult believings. >
From: Ed Morton on 12 Jun 2010 14:18
On 6/12/2010 1:16 PM, Ed Morton wrote: > On 6/12/2010 9:22 AM, J. wrote: > <PLEASE DON'T TOP-POST, FIXED BELOW> > >> >> Ed Morton<mortonspam(a)gmail.com> wrote: >>> Looks like it's just rehashing all the old arguments for why model >>> driven >>> approaches to software development are superior to just programming >>> solutions to >>> a specific problem. In particular the discussion reminds me of the >>> product-line >>> architecture or FAST (Family-oriented Abstraction, Specification and >>> Translation) approach from the 1990s. All good arguments, and all >>> usually >>> negated by the fact that programmers just don't want to do it for >>> many reasons >>> including their familiarity with the approach, initial development >>> schedule, >>> cost of licensing the modeling tools, risk of getting bound to one >>> modeling >>> toolset that might go belly-up or change their specification format >>> (as SO many >>> have - ObjecTime, TestMaster, TAU, UBET, etc, etc.) and so on. >>> >>> All good arguments in theory but as we all know theory and practice >>> are only >>> equivalent in theory, in practice they're quite different. >>> >>> Ed. > > Is all that FAST/ObjecTime/TestMaster/TAU/UBET/etc related to UML > > (Unified Modelling Language)? > > FAST - no, it's a methodlogy for you to create your own AOLs > ObejTime - not exactly, it was OO but predated UML. > TestMaster - no, it was it's own language. > TAU - no, it was various ITU specs (e.g. Z.120, SDL, etc.) ....actually, come to think of it TAU DID use UML for it's architecture models, but not for design, coding or verification IIRC. Ed. > UBET - no, it was ITU Z.120 for HMSCs > > Ed. > > All of this anti-scripting remembers me > > to a man directing his project, where a lot of time was spent doing > > UML diagrams, unit tests for everything... He didn't want a single > > line of python in his project. > > > > These things seem to me a way of making users rely on very complicated > > things and having a lot of control over everything and everybody. > > Another reason might be cargo-cult believings. > > |