|
![](/i/fill.gif) |
Warp wrote:
> I failed to see the good points in the first article. What are they?
I think we can both agree that monkey patching sucks. :-)
Depends on how big he thinks a "large" project is. And I don't "trust" C
code more than I trust Java or C#. Experience leads me to believe that there
are more security holes in C programs than in safe (or even
by-default-checked) languages, which just stands to reason.
> Personally I hate C more than I hate Java. I wouldn't want to make any
> project, minuscule or large, in C.
I like C. I've done 40,000 lines of C where I was the main author and we had
2 other people working on it. We started with good specs (basically, BASIC
programs that already did pretty much what we wanted), but it was also in
the days of 33MHz computers with 640K of RAM that took 2 hours to link the
program.
The data containers weren't that difficult - stuff like spreadsheet-like
tables of constants, data for help files and report generation, etc. The
algorithms weren't too hard. It was business computing, not scientific
computing. We didn't wind up with many or any memory leaks. (This included
everything from screen management and single-character console input, input
forms and screens, flexible report generation, computations that were
complicated but not complex (life insurance accounting is complicated but
not complex), and so on.
Now, granted, I didn't maintain it for 5 years, but there was no good reason
why it wouldn't keep working with a bit of care in upgrading the
calculations and such.
As for strings, I allocated strings from a circular buffer, so we could do
things like
printf("%s", concat(mid(upper(his->name), 3, 20), lower(his->city)));
and not worry about the intermediate strings. The stuff like records from
the help and configuration files were managed similarly.
Header files were generated automatically by editor macros based on the
public declarations in the source files, so that kept out that kind of bug.
I've also done a variety of "library" type things in C, where the
performance rules were such that I couldn't copy buffers (for example).
Again, it was pretty straightforward to design. The callers had to follow
the rules, but they weren't hard to follow.
Which isn't to say that C++ isn't far superior for that stuff, because it
lets you centralize all those sorts of things in the classes.
> C++ has its own quirks and problems too (being inherited from C and all),
> but in most cases (especially in very small projects) it allows me to
> concentrate on the *algorithm* I'm implementing, rather than all the
> ancillary stuff I need in order to implement it (eg. data containers).
Agreed. In small projects, the higher level languages win. When you're
coding something from scratch for a year with three people? Hmmm... Not so
clear. Most of the time is going to be spent chasing requirements and
designing stuff. When your program is simple enough to build without having
written specs first, it's going to be easier to use a higher level language
with built-in data structures.
I think it's not really the fact that a langauge is "high level". I went
back and looked at some old Erlang I wrote about 6 months ago. It's ugly, in
large areas unreadable, and would be hard to maintain. Not because the
language is "low level", but because it lacks powerful data structures, and
the program is trying to manipulate data structures with a simple API and a
complex implementation.
> Handling the data and trying to make it fast required
> dynamic data containers, sorting, binary searches and such. C++ allowed
> me to start implementing my ideas *right away* because I didn't have to
> waste any time at all on the data containers (and trivial algorithms like
> binary search).
I think that's what I'm referring to. The built-in structures are more
important than the details of the language. (At least once you have a
reasonable language actually designed for humans, rather than something like
brainfuck or whatever it's called.)
But when you get into a program that does a whole bunch of stuff that's
using conceptually simple data, the existence of pre-defined data structures
is a lot less useful.
Now, something like Open Office, in C? Awful. The data is too complex.
Something like a calendar program, or a network protocol, or some such? No
problem.
> I wouldn't trust these C hackers for anything. They don't know the first
> thing about programming.
Hmmm... Well, I think there's a couple kinds of open-source code.
1) Stuff written by someone who needed to solve a particular problem, who
then released it.
2) Stuff written by someone planning to make it look good, work well, and be
maintainable and valuable (like, say, OpenOffice).
I've seen good stuff in proprietary code, and awful stuff in proprietary
code. I've *written* awful stuff in proprietary code (in HLLs at that), when
the business demands were such that it made sense to do so.
I'm betting the very first version of the Linux kernel was pretty hacky too,
for the same reasons: it was done to learn how to do it, and Linus didn't
really care if others took it over or not, as I understand it.
If you start out not knowing what you want, then stopping as soon as it's
good enough for the original author to use, you're gonna have crappy code,
regardless of the language.
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
Post a reply to this message
|
![](/i/fill.gif) |