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