Re: Language Oriented Programming

Responding to JXStern...

Another problem is dealing with the computing space. Almost all commercial software critically involves mapping a business domain into the domain of hardware computational models. One must necessarily manipulate the business abstractions in a manner that provides optimization in terms of the hardware models. To avoid explicitly dealing with that optimization the DSL compiler must provide optimization for the computing space. But the only way that can be done is if the DSL itself is sufficiently abstract so that it is independent of local computing environments. However, that segues to the second evolutionary road. 


I think I disagree with this somewhat, as I have my own, my very own,
theory (think the old Monty Python routine) that computation is more a
unipolar constructive enterprise than a mapping, but that's another
rant.  The use of the term "optimization" sort of jumped out at me
here, aren't we satisficed if it at least works, isn't optimization
sort of a secondary issue?

It depends on the subject matter. I spent two decades in R-T/E working on megabuck machines where the hardware was an order of magnitude faster than the computer feeding it and the customer wants throughput for that investment. I spent another decade solving np-Complete problems on machines that were too small. So from my perspective performance is often as important as correctness in practice.

<hot button>
Years ago Djikstra wrote a piece for one of the professional rags bewailing code bloat and downgrading performance. (Anyone remember when one could run a spread*** on an Apple II, whose cycle rate was measured in KHz, with 128 Kb of memory and a 700 Kb floppy disk?) At the time I thought he was, once again, ahead of his time. Moore's Law has lulled a lot of the industry into believing that performance problems can be solved by waiting for next month's bigger and better machine.

IT has been particularly affected because disk access time has not dropped as quickly as CPU cycles/sec have grown so the traditional I/O bottleneck has just gotten worse and software optimization has become an arcane issue for server engines. Got a performance problem? Buy another server.

The result is that the industry has largely forgotten how to optimize so I think there is going to be a nasty surprise coming up in the next decade. Moore himself has expressed concern that his Law is likely to fail soon. But far more important, IMO, is the fact that the problems are beginning to catch up to the machines. That is, until recently the size of the problems being solved has not grown as quickly as computing power, especially in IT where the thing that tends to scale is I/O volume.

One reason is that until relatively recently we simply didn't have the productivity and quality control to attack truly large problems in commercial environments. Really big problems, like atmospheric diffusion, were solved on mainframes by very bright post-graduate slave labor who didn't have to worry a lot about maintainability because the requirements (algorithms) didn't change much.

Today, though, we have the technology, tools, methodologies, and project management processes that enable small teams to produce MLOC applications with fairly reasonable quality in a fairly short time. So the /business/ problems that /can/ be solved on desktops are starting to increase in size and I see that growth as approaching exponential until it catches up to machine power -- simply because of the productivity and QA gains among developers. IOW, since we have more capacity for problem solving, we will solve bigger problems.

We already see this happening for OSes and office tool suites. Today as much as 60% of the CPU cycles is devoted to activities (GUI, OS housekeeping, interoperability) peripheral to the user's problem and the fraction is growing despite Moore's Law. Stuff more and bigger and more bloated applications into that environment and we are going to have a problem even with Moore's Law still working. One manifestation is that we have to keep upgrading our desktops as we upgrade software even though we may still be doing pretty much the same things.

Perhaps one of the best examples is interoperability. Today we have lots of infrastructures for enhancing developer productivity, particularly for interoperability. Things like remote object access make life a whole lot easier for the software developer. The problem is that the infrastructure is not free; it carries horrendous overhead compared to simple data transfer messages. But the developer would have to worry about protocols and encode/decode details on either end without the infrastructure. The result is awful performance that contributes to the huge overhead in CPU cycles.

That's a trade-off between short-term developer cost vs. long-term cost in the execution environment. The vendor always opts for developer productivity because that reduces out-of-pocket expenses and the long-term cost is borne by the customer in upgrading hardware. So far the industry has gotten away with this because of hardware costs dropping like a stone. But PCs are now commodities, the CPU is only a small part of the cost of a PC, and there is no Moore's Law for the rest. So we are approaching a stabilization in hardware pricing.

When commodity prices stabilize to close to cost-of-living increases and the problems increase in size, then the cost of software performance will become more apparent to the customers through the cost of upgrading. At that point the industry is in for a rude awakening.

[Actually, I expect this wakening to be awhile mainly because there is another rude awakening that is more imminent. Customers are beginning to realize that the only things that break in their lives nowadays are software. Very soon reliability is going to become a major competitive advantage in software development, just as it became in the '80s for "hard" industry. (One example is the market share hit WinX is taking over Linux reliability.) Unfortunately moving commercial software from 4-Sigma to 5-Sigma and beyond is going to take awhile so the winners are going to be those who got on board earliest. But I digress...]
</hot button>



If one has sufficient abstraction so that the solution representation is independent of the local computing environment, one has a 4GL. To provide that level of independence one needs a high degree of abstraction. In particular, one needs to be able to abstract business concepts directly in those terms simply because one can't use computing space terms. That happens to be exactly what OOA does. If one has a general purpose language capable of such abstraction, one doesn't need a DSL because one can directly abstract exactly the same way the DSL does.


You mean, that's what OOA *tries* to do.

Remember that you are talking to a translationist. B-) Because our OOA model is eaten by a code generator we are forced to apply the methodological rigor necessary to ensure separation of customer and computing concerns. IOW, we /always/ do what elaboration OOA modelers /should/ do but often don't.

Implementation pollution will get translation reviewers to bring out the crucifixes and garlic cloves faster than anything else. The acid test for an OOA model is whether it could be unambiguously implemented as a manual system in the customer's environment without change (however inefficient that might be).


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions  -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH



.