Hi Loup
Very good question -- and tell your Boss he should support you!
If your boss has a math or science background, this will be an easy sell because there are many nice analogies that hold, and also some good examples in computing itself.
The POL approach is generally good, but for a particular problem area could be as difficult as any other approach. One general argument is that "non-machine-code" languages are POLs of a weak sort, but are more effective than writing machine code for most problems. (This was quite controversial 50 years ago -- and lots of bosses forbade using any higher level language.)
Four
arguments against POLs are the difficulties of (a) designing them, (b) making them, (c) creating IDE etc tools for them, and (d) learning them. (These are similar to the arguments about using math and science in engineering, but are not completely bogus for a small subset of problems ...).
Companies (and programmers within) are rarely rewarded for saving costs over the real lifetime of a piece of software (similar problems exist in the climate problems we are facing). These are social problems, but part of real engineering. However, at some point life-cycle costs and savings will become something that is accounted and rewarded-or-dinged.
An argument that resonates with some bosses is the "debuggable requirements/specifications -> ship the prototype and improve it" whose benefits show up early on. However, these quicker
track processes will often be stressed for time to do a new POL.
This suggests that one of the most important POLs to be worked on are the ones that are for making POLs quickly. I think this is a huge important area and much needs to be done here (also a very good area for new PhD theses!).
Taking all these factors (and there are more), I think the POL and extensible language approach works best for really difficult problems that small numbers of really good people are hooked up to solve (could be in a company, and very often in one of many research venues) -- and especially if the requirements will need to change quite a bit, both from learning curve and quick response to the outside world conditions.
Here's where a factor of 100 or 1000 (sometimes even a factor of 10) less code will be
qualitatively powerful.
Right now I draw a line at *100. If you can get this or more, it is worth surmounting the four difficulties listed above. If you can get *1000, you are in a completely new world of development and thinking.
Cheers,
Alan
Locked
