TIP: Click on subject to list as thread! ANSI
echo: barktopus
to: Paul Ranson
from: Robert Comer
date: 2004-02-05 10:55:38
subject: Re: Jobs (or the lack thereof)

From: "Robert Comer" 

> C++ provides the idioms to safely manage resources, especially in the
event
> of exceptions.

It's to bad a lot of C++ programmers don't know how to use them.  I don't
know about Java either and C# isn't even on the radar yet for me.

>There aren't any other significant players in town.

What, you've never worked in a shop with a midrange or a mainframe?  There
is significant code in all sorts of languages better suited to
stability/security out there.

You're also missing another language on the PC, probably the most used of all, VB.

> Raw execution speed should interest you. Not every app is writing to a
> database.

Actually, in my environment everything read/writes/updates databases.  RAW
execution speed gains nothing for me. That's why an AS/400 is good for this
type work, while raw computational speed isn't even up to low end desktop
standards, everything is optimized for I/O, so that 500Mhz processor can
serve 100 users with sub second response times.

>A bit more attention to speed, efficiency and accuracy would
> remove a lot of bugs and structural issues, not to mention dependencies.

That I agree with, but that kind of goes without saying.

> Most exploits I've looked at have been down to C coding style from the
good
> old Unix days rather than contemporary usage of C++.

I agree, but C++ lets you use that coding style, and that's basically my
complaint in a nutshell, dump the old baggage and it would be an okay
language.

>The one area where Unix
> is really dragging is in encouraging good coding practice. A browse across
> SourceForge shows a real stick-in-the-mud attitude. I think many of these
> people would be much happier on a PDP11.

They probably would, but I wouldn't!

- Bob Comer



"Paul Ranson"  wrote in message
news:4022582f{at}w3.nls.net...
> "Robert Comer"  wrote in message
> news:40225208{at}w3.nls.net...
> > > You can leak memory and resources in a garbage collected environment.
> And
> > > these leaks will be more insidious than a straightforward C++ memory
> leak.
> >
> > They can be but I don't think I'd say they would be, especially when C++
> can
> > have the same type too.
>
> C++ provides the idioms to safely manage resources, especially in the
event
> of exceptions. C# is having some of this inserted into it for the next
> release of .Net but will still be relatively clunky. I've not seen
anything
> regarding Java. There aren't any other significant players in town.
>
> > > Without the risks you don't get the rewards.
> >
> > Just what rewards can I get here that I can't get from a better designed
> > language, size of executables don't matter anymore, I/O is still the
drag
> on
> > everything so raw execution speed doesn't interest me, object oriented
can
> > be done in a LOT of other languages, code reuse can be done better in
> other
> > languages.  For OS stuff, there sure have been a lot of exploits to
think
> > that C++ is really where we want to go for secure computing...
>
> Raw execution speed should interest you. Not every app is writing to a
> database. A bit more attention to speed, efficiency and accuracy would
> remove a lot of bugs and structural issues, not to mention dependencies.
> Most exploits I've looked at have been down to C coding style from the
good
> old Unix days rather than contemporary usage of C++. The one area where
Unix
> is really dragging is in encouraging good coding practice. A browse across
> SourceForge shows a real stick-in-the-mud attitude. I think many of these
> people would be much happier on a PDP11.
>
> Paul
>
>

--- BBBS/NT v4.01 Flag-5
* Origin: Barktopia BBS Site http://HarborWebs.com:8081 (1:379/45)
SEEN-BY: 633/267 270
@PATH: 379/45 1 633/267

SOURCE: echomail via fidonet.ozzmosis.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.