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*. > > 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
