Hey, Steve! Sorry about the "tome" but it is an interesting and long-winded subject.
“I agree that use of C has lessened, and that less of us understand C today. I disagree that this is necessarily the cause of the problem.” I'm afraid that is where we differ, Steve, at least in the overall picture of all things Linux. It's been my experience that very few people compile their own Linux. Without that, most people have resorted to other languages as their primary language. From what I have seen, a lot of younger programmers prefer the languages that you mention: Python, Perl, Lua, Ruby, etc. When something new and critical written in C gets shoved into the userspace, all hell breaks loose because a vocal majority do not understand how to “hack it”. It's not part of the “black box” of the kernel. What I am saying is that one of the largest sources of discontent that I hear from more and more Linux quarters it is the fact that you have to use a C compiler at all. The fact that you need to recompile something in order to change its behavior seems especially exacerbating to them. IMHO, Linux users have gotten too lazy and expect every package to be what they want, just as long as they don't have to do it themselves. It's a trait they share with Windows users. “Personally, I think that anything that *can* be written in Python, Perl, Ruby or Lua *should* be written in one of those languages, because doing so limits buffer overruns to those remaining in the language. Also, software written in those, especially Python, which has a rich library of standard libraries, has fewer dependencies that need to be installed. And yes, feature for feature, they're more readable than C.” With respect, I consider those arguments to be ungrounded. Depending on a run-time to catch your buffer overflows is an inanely stupid thing to do. Expecting the compiler to be responsible for catching overflows means that you routinely aren't going to be checking your own bounds. The design of the language might even be such that it prevents you from performing checks you otherwise could or should. An example of this would be C#. Microsoft does not always document which resources are marked as disposable or not, leaving you to guess or test every single object that you instantiate or inherit. Probably the most insidious problem with run-times of this nature, is that if there is a flaw in the run-time, you will have the flaw in your code and it is hard as hell to track down, because you aren't bothering with your own checks. On open-source, it's survivable – just crawl in and fix it. If it isn't, you're hung high and dry until a patch is issued. This is not to mention the additional run-time complexity or the fact that it generates significant processor overhead that can slow things down or diminish battery life. Personally, I'd just rather do it myself. I've never found it to be a feature that I can depend on, nor have I found languages that force it on you to be dependable either. I'm sorry but I don't agree with the idea of Python and other such languages having few dependencies due to a “rich standard library” either. All of them use C bindings for things that they cannot do for themselves. This means that although you are using a higher level language and supposedly removing the possibility of C programming errors, you are still depending on C, and simply adding another layer of complexity with more potential for error on top of what you are already using. This is not to mention that you are now adding whatever run-time to your typically already bloated binary Linux as a system dependency. Systemd is another example of that, in my opinion. You must use tools written in Python, which forces you to further subsidize Python, unless you rewrite them. Another very hated example would be anything to do with PHP. God forbid you ever need to use PHP for any reason. It's a disaster of dependencies waiting to happen. I am a fan of absolute minimal language dependencies, which is why I like C. As for them being more readable, I can't agree with that either. “Readable code” is resides in actually being able to understand the conventions of language. The argument that one language is more readable than another is complete and utter nonsense. I've seen Perl code that I've found difficult to decipher while assembly might be completely comprehensible. It's entirely a subjective idea and not an objective assessment. _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
