> I was just throwing in some suggestions. Yes maintainability, other
> possiblities might include developer time, platform availability, platform
> independance. You can probably think of more as well!
> >>>I wnat a language in which is it easy to write good programs.
> >>>I'm still waiting for one...
> >>
> >> I think we need to define what we mean by "good", "bad", "perfect" and so
> >> on.
> >>
> >> Presumably "perfect" means "as good as it is possible to be" but...
> >> does good mean fast, reliable, bug-free on first compile/run?
> >> does bad mean memory-hungry, buggy, inefficient?
>
> > That's part of the problem.
> > But not a particularly big one - you can get 90% goodness in all these
> > areas. For the remaining 10% - well, there's always assembly.
>
> But you still haven't said what "good" actually means!
Actually, I almost think that rate of productivity (code lines per
unit of "functionality required") could be the ultimate arbiter of
what makes a language "good". I'm suggesting that "good to write" is
probably highly correlated with "good to maintain". As regards
platform availability - I regard that as a side issue, because after
all, there's no intrinsic reason why, say, Forth will run on a PC, but
not UNIX. Having said that, the argument doesn't quite work with
assembler, or VB.
Actually, I'm rather attracted to the idea of a previous poster
suggesting Lisp as the ultimate programming language, especially the
bit about every sufficiently complex problem has a poor implementation
of Lisp.
Take XML/Latex/html. When you think about it, these are just examples
of Lisp done badly. If people were to mark everything up in valid
Lisp, then nobody would have to write parsers for them. They'd be
ready for processing right from the second you wrote them.