4 ms·
Agreed. When you are bit-banging and other low-level stuff, you want a language like C. It's such a silly argument. Good programmers pick the language that mat
by bprater 17y ago
Agreed. When you are bit-banging and other low-level stuff, you want a language like C.
It's such a silly argument. Good programmers pick the language that matches the problem they are trying to solve. Anyone that considers themselves a hacker isn't a square peg in round hole kind of person. They have several tools in their bag and will pick out the most appropriate one for the job.
That's all the comes to mind these days when I see these arguments: people need to open up their field of view and see what other great language exist for their craft. Did Leonardo only use paintbrushes to write in his notebooks?
- stcredzero 17y agoYou can do bitwise operations in VisualWorks Smalltalk quite efficiently, particularly for encryption applications. Of course, it helps that the encryption library author and the VM engineer at the time collaborated closely. (Hence, the existence of classes like ThirtyTwoBitArray.) I seem to remember a study someone did with CISC machines like VAX. On average, a C statement resulted in 2.5 machine language instructions.
- hazzen 17y agoIt isn't the ability to do efficient bit operations that is a strength of C - it is the ability to easily and succinctly do whatever you want to the bits in memory. Arbitrary pointer/memory operations help greatly in writing things like memory managers, device drivers, and all of the other wonderful parts the make up the guts of an OS. edit: Added the text "easily and succinctly" as a qualifier on doing things to bits in response to stcredzero's comment. It isn't that C is the only language to allow it, it is that C allows one to do it without obscuring your intent. C# handles this quite well with unsafe blocks, Java not so much.
- stcredzero 17y agoI want to go against the misconception that high level languages mean that you have to give up control over bits. You can control particular bits that matter, even if your language runs on a VM. I don't see why arbitrary pointer operations are necessary anymore for memory management and the other things. I think this is something left over from the days when we had to squeeze every iota of performance out of machines. I suspect that entire systems could be built with references and almost no pointer arithmetic, and that we're simply stuck in the way we've always done things. So what if we give up 20 or 30% of the CPU to do this? Pretty soon, we'll be trying to figure out how to keep 8 cores busy on a typical desktop. How about we use some of this to allow greater abstraction in the OS kernel and device drivers?
- gloob 17y agoI don't see why arbitrary pointer operations are necessary anymore for memory management and the other things. I think this is something left over from the days when we had to squeeze every iota of performance out of machines. Squeezing out performance is pretty much the job description of system programmers. Can you give a compelling reason to change that? Pretty soon, we'll be trying to figure out how to keep 8 cores busy on a typical desktop. No, we won't. Software becomes twice as slow every two years. Things will stay pretty much the same as they've always been.
- stcredzero 17y agoSqueezing out performance is pretty much the job description of system programmers. Can you give a compelling reason to change that? Achieving a higher degree of abstraction, more straightforward availability of system resources to programmers, higher levels of code reuse. BeOS/Haiku already achieves this with C++. I think we can improve on this with something like Go.
- gloob 17y agoAchieving a higher degree of abstraction, more straightforward availability of system resources to programmers, higher levels of code reuse. Present-day system programmers seem to be able to build decent enough operating systems and the like at the level of abstraction C provides, and I suspect that most would consider straightforward management of system resources to be higher priority than straightforward availability of them. I will concede the possibility that some unambiguously-better system could be written in a higher-level language. However, until evidence demonstrates that it actually can be done, that remains just a possibility, and one with very real and significant costs. Those costs are not, in the view of many system programmers, worth it.
- stcredzero 17y agoI will concede the possibility that some unambiguously-better system could be written in a higher-level language. However, until evidence demonstrates that it actually can be done, that remains just a possibility Already happened: Symbolics Lisp Machines. (Modulo a few decades of programming practice not available to inform the Lisp Machines.) I suspect that Go could get us there. Interfaces would allow for a higher degree of abstraction. The language would offer much cleaner concurrency. All the memory management cruft would be gone. In such an environment, many things that are now esoteric would become the realm of ordinary programming. I think there is much to be gained.