> Carsten Breuer <CarstenBreuerSvn@textwork.de>:
>> Do we? Memory-allocation bugs are always a problem of discipline and
>> bad coding style.
> No, they're primarily a bug that arises from not baving proper
dynamic > memory
> management. Don't lecture me about C++ -- I learned better than this
> writing LISP back in the 1970s back when C++ was not yet even a gleam
>in Bjarne Stroustrup's eye, then ....
LISP...yes i know. That was the funny language that need 30% runtime
for garbage collection ;-) . Good job ;-) . I work also as a developer
for a long time and have seen too many people talking about garbage
collection and doesn't know what they are doing. A fool need a tool.
> I paid two decades' dues writing C because
> hardware was not yet inexpensive enough to support LISP-like languages
> outside of academia. I can make a pretty good guess at your age by
> the way you write, and my guess is I've been clued in about these
> issues longer than you've been walking and talking.
Well, you are 8 years older. That is really far away, right ;-) .
> I'm coding C++ right now on Battle For Wesnoth. It's an ugly,
> bloated, over-complex language -- an octopus made by nailing extra
> legs onto a dog -- and it encourages ugly, bloated, over-complex
> architectures.
ROFL...Yes, KDE and QT are really bad projects ;-) .
There is enough at C++ i don't like, But i disagree that
all problems are gone if you use python. Python, with this
identation is also pretty ugly an a lot of problems occurs at runtime.
Things that would never happen on C++.
> The "discipline" you speak of has become a *waste of time* for anybody
> not doing kernel or realtime work.
Is discipline ever a waste of time. All i talk about is "think before
implement" and that the "complementarity principle of problems" is also
valid for python.
> With menory and cycles so cheap, p
> programmer hours are best spent on solving real problems, not on
> low-level resource bookeeping.
Well, C++ classes can encapsulate this pretty well.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 4 14:06:46 2007