> Going from Pascal to C was like a breath of fresh air. Pascal is like a combination of everything I hate in all programming languages that I know and I'm glad that the world moved on. C is small, elegant and portable. It's a systems programming language that does what it's supposed to do.
I hate C with its lack of proper arrays handling and brain dead string manipulations that open the door to so many security exploits. Additionally the lack of modules/namespaces is a joke.
Mac/Turbo Pascal, Ada, Modula-2, Modula-3, Oberon(-2) are all examples of system programming languages done right.
C's array and string handling is extremely compact and powerful in many ways. It does, however, require at least some understanding of pointers. But once you understand how it all works, you can do significant string manipulation with relatively little effort, while still retaining exceptional runtime performance and minimal memory usage.
That said, if you're the kind of person who doesn't understand pointers, there are numerous libraries out there that'll provide a variety of functions for working with arrays and strings more easily. C itself doesn't prevent you from using these alternate approach, but rather it enables them.
The problem with C, for most application domains, is not that it requires pointer knowledge, but that it requires constant attention to this knowledge.
Combined with the fact that there's no warning when you've stepped outside the bounds of an array, I think makes it an extremely dangerous language to use for large scale programming.
Years back, a friend was maintaining a system collecting and processing scientific data, in C. Several papers have been published on this data over the course of many years. I remember the sinking feeling we both got - mixed with real fear - when he told me he had discovered an error where an array's bounds had been miscalculated. I don't even want to think about the possible ramifications of that...
For some application domains low level control is necessary of course, or for others the performance gain may make the tradeoff worth the cost.
The problem of people building on top of C is that C is not a language meant for applications. A system collecting and processing scientific data is too high-level for a language like C.
In fact no application should be written on top of a language that doesn't do garbage-collection by default, unless you've got the resources of big companies. Any language that doesn't do garbage-collection by default is dangerous for large scale programming.
On array bounds checking, you can't do such bounds checking at compile time, so you have to rely on runtime checks and metadata. As my highschool professor kept telling us, C is a medium-level programming language. It's optimized for moving bits around in memory, while the code remains reasonably platform-independent. Adding array-bounds checking by default doesn't make sense for a language like C, because it stays in the way of moving bits in memory.
> Adding array-bounds checking by default doesn't make sense for a language like C, because it stays in the way of moving bits in memory.
Any proper language for systems programming allows to turn off bounds checking if required-
This is the way it should be done, disabling the bounds checks on the few spots that require them being disabled, after profiling if they being on really affects the performance of the application.
All the languages I mentioned have the same expressive power as C for pointer manipulation, when required to do so, while being a lot safer by default.
I hate C with its lack of proper arrays handling and brain dead string manipulations that open the door to so many security exploits. Additionally the lack of modules/namespaces is a joke.
Mac/Turbo Pascal, Ada, Modula-2, Modula-3, Oberon(-2) are all examples of system programming languages done right.