Orchid XP v8 wrote:
>>> I suspect it's because we reached the end of the low-hanging fruit in 
>>> language design which also has a high payoff.  
>>
>> I disagree. I can think of a number of persistent problems with large 
>> code bases that aren't solved by todays languages or libraries.
> 
> Such as?

Interactions between large code bases with fundamental different design 
ideas. Documentation. Navigation. Intermixing of different kinds of concerns 
in the same code (logging, error handling, debugging info, actual code you 
care about, etc). Dependency management. Dynamic upgrading (as in, replacing 
code while it's running). Version management (as in, upgrading libraries you 
depend on with the assurance you won't break something, avoiding DLL hell, 
etc., which MS has started to address with the .NET and C# stuff). Modifying 
stored data to match new code.

Some of this is handled in some languages. Nothing popular really has a lot 
of this sort of stuff in it. (Other than, as I said, .NET taking the first 
steps.)

> And anyway, I think he's only saying that the stuff that's "easy" to fix 
> has already been fixed, leaving only the less easy stuff.

Sure. But heck, array indexing wasn't *easy* when it was invented. I'm just 
surprised I haven't seen too much mainstream improvement in how things work 
in so long. About the only things I can think of that got popular since OO 
are dynamic loading of code, libraries like CPAN and imitators, "sandboxing" 
code, and maybe scripting languages (embedded or not).  Generally, 20 years 
ago, programs were pretty well self-contained. Nowadays a lot of them are 
built from public parts.

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message