Re: How Nested Functions Work, part 2

[Jeremie Pelletier]

Walter Bright wrote:
Jeremie Pelletier wrote:
Yeah, but its like calling for a failed experiment, there is no such 
thing, only experiments. Think of these "worse" languages as 
experiments on how not to design languages :)

Besides I was talking about better or worse in the scope of languages 
which are actually used.

Many languages are "worse" because they solve problems that no longer 
exist, use techniques that have been obsoleted by newer ideas, were 
constrained by issues that have since gone away, etc.

This often doesn't stop zealots from using them, but their numbers 
shrink steadily as they die off and are not replenished :-)

It's sort of like when quantum mechanics theory rose in the physics 
world. Acceptance of it was with the new physicists, not the old guard, 
and QM didn't become dogma until the old guard died off.

True, which is why we have a thing called progress, and I'm glad I found 
 about D for that reason, since it's quite a refreshing feel to the 
world of systems languages. That does not make every code using C/C++ wrong.

Quantum theory is far from being complete, and so is general relativity, 
we're still searching for that "god particle" and a way to unify those 
two theories. It does not make these two theories "wrong" but rather 
required stepping stones to attain a better one. Just like Newton's 
theory was a stepping stone for Einstein, among others. And I would like 
to mention that even if Newton's theories have been outdated for almost 
a hundreds years now, they're still widely used as being *much* cheaper 
to compute for no noticeable difference, so long as we stay in our scale 
of things. You don't need to learn differential algebra to understand 
Newton either.

Those new and better ways of doing things in programming languages might 
imply semantics some programmers are not willing to use, and would 
rather keep their older language and implement their own version of that 
feature themselves, pure C will always dominate in that in my opinion 
since I can't think of anything in the language itself that generate 
calls to runtime methods, which fortunately can also be done in D. A lot 
of D features require runtime calls, not everyone is willing to dig into 
the runtime to learn what such calls imply in terms of performance. For 
example, I myself stay off scope() for real time code because I'm aware 
it needs to call into _d_framehandler.

Maybe I'm just too optimistic, but I have a hard time labeling things as 
"wrong", I prefer to use the term "different" :)