High Level Modeling

I use the following rule of thumb and goal about "high-level modeling" (derived from chip design): the high-level equivalent functional model should be about 2 orders of magnitude faster to create. This means you can easily justify the time to doing both, and using the high-level model to validate the final system. In hardware, PL/I is 100 times faster than circuit design, so people make functionally equivalent PL/I models of their circuits to use as a reference test. In sw, I have only once seen one language 100 times faster than the final language. (Some say SoftwareCannotBeModeled) That was APL2 against Ada, for a large, government contract. Sure enough, they were easily able to justify creating the APL2 version and use it as a reference test. CASE tool modeling certainly fails the x100 test, which is why I would not expect to see it pay its way as a reference model. Finding a x100 software expression language is one of my personal grails. -- AlistairCockburn

Quite often, higher level languages like Perl, Python, Visual Basic and TCL/Tk allow you to model a system so quickly and powerfully that you end up not wanting to implement the system in the final language.

This, I think, is one of the reasons scripting languages are becoming more robust and reliable. Once I model a fairly complex system in Python or Perl, I am tempted to complete (fully implement) the system in that language. By being able to embed or link scripted modules with System Programming languages I am able to complete the system without having to rewrite a lot of code.

I wouldn't say that Perl or Python scripts often achieve the above mentioned x100 improvement. But, then again, how much improvement is gained by writing a simple 1 line statement in Perl to perform tricky text parsing using regular expressions over 100 lines of C++?

Of course, my argument may be ignoring the real point of Alistair's statements. I am not so much modeling the system as I am prototyping it. Ah... but this is why programming is so cool: When you model with a programming language, you are using the same material (software) that makes up the final (implemented) system! You can't say that for chip design or building architecture...

-- ToddCoram

-- AlistairCockburn: and REXX, I would add. Indeed the question on the phrase HighLevelModeling is, what is the difference between it and programming in a higher-level or easier language? that is, WhatIsaModel? In the face of good scripting languages fast enough to deliver in, is there still a place for "high level modeling"? I stick by my assertion that x100 faster construction is the economic enabler for high level modeling, and if you don't have that, you either pay too much for the model or you use high level programming, which does not subtract from the problem in the way a model must in order to remain a model.

From my point of view (which was formed during the bygone days of modeling/expert system tools like KEE and GoldWorks?), the modeling and the scripting worlds meet in the gray area of domain-specific languages. From my own experience: after I had developed the underlying structure, a metallurgical ES of mine could have new structures added in about 10 minutes per structure. The Thermo Workbench was essentially a model-development tool -- it was pretty lousy as a calculation system, to be honest -- with lots of support in the object system for tracing equation dependencies and doing simple algebraic stuff. The 2-D part sketcher allowed users to sketch out parts, and then add constraints interactively, and then would spit out lots of part definition files.

One caveat for Alistair's case: it may not be even with the 10x or 100x productivity improvement -- you then need a problem 50-100x the development cost. One project I took over had spent $2-3 M in developing an easy modeling shell to save about $1.5 M per part design, but they only made a part that complex every 5-10 years! I tried to reposition the effort to handle simpler parts, and to save $5-10K a design with 50-100 designs a year, but ran into my and my organization's limits of competency.

KenMeltsner

Personally, I find Perl quite useful for prototyping some things. It's considerably faster than having to write C++ for example. It's also nice to have a running prototype to prod with test cases.

[subsequent discussion moved to PythonVsPerl]