How Nested Functions Work, part 2
Jeremie Pelletier
jeremiep at gmail.com
Wed Sep 23 12:20:27 PDT 2009
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" :)
More information about the Digitalmars-d
mailing list