Re: [PATCH] Make "git reset" a builtin. (incomplete)

On Wed, 22 Aug 2007, David Kastrup wrote:

Actually, the same holds for assembly language vs C.  Once the
prototyping is over...

No. Portability.

The point is, C is *more* portable (and thus maintainable) than shell, but 
assembly language is *less* portable than C.

So no, "the same holds" is not at all true.

It's not about whether something is evolving or not: it's about whether 
something is *maintainable* or not.

And C is most definitely maintainable, in ways that scripting languages 
often are *not*.

quoted

Having tried to do internal scripting languages, I can say that it's
just easier to do it in C once you get past the hump of getting it
written in C in the first place.

But it is not "once" that you need to do this.  It is a permanent job.

Sure, and that's exactly where C shines.

C is not great for "quick and dirty, and I'm not sure where this is 
going".

But once you know where it's going, and once it's not "quick and dirty" 
any more, very little beats C. It's easy to extend on, and if all the 
infrastructure is in C, there simply IS NO BETTER WAY TO GLUE THINGS 
TOGETHER.

There are "C bindings" for other languages (like LUA), but the fact is, 
none of them hold a candle to the "C bindings" of native C.

So you're seemingly ignoring the fact that all the infrastructure is in C 
(and absolutely _needs_ to be in C - there are no valid alternative 
languages at that level).

Maintenance: yes.  Development: no.  If you want a product you do not
want to touch again, C is a good final choice.

That's simply not true.

Look around. Most C language projects are really well maintained.

In contrast, a lot of _scripting_ languages are basically write-only. They 
may be write-only because that's their fundamental design (perl), or they 
may be write-only because they are limited enough that you can not easily 
extend them to do new things.

But your statement is provably wrong. Just *look* at well-maintained 
projects that have extended way past their original design and usage 
model. A lot of them are in C.

So why do you make these idiotic arguments that are clearly crap?

			Linus