4 ms·

You've described my experience exactly. Once I got to learn C at university, I felt that I was now using a "grown up's programming language". It took a few year

You've described my experience exactly. Once I got to learn C at university, I felt that I was now using a "grown up's programming language". It took a few years to realise that C's manual memory management and explicit pointer handling was making me much less productive as an application programmer.

jandrese 9y ago
It's not like Pascal's memory management and pointer situation was that much better.
- pjmlp 9y ago
  They actually are, because Pascal knows the size of its types, while C requires using a mix of sizeof and malloc, which many people still get wrong, specially with arrays.
  - klipt 9y ago
    Of course in C++ you can just use a vector. Object Pascal is certainly closer to C++ than C. The main advantage of Pascal is super fast compilation, but C++ modules should close that gap once they make it into the standard.
    - pjmlp 9y ago
      Which is why C++ became my next favourite language after Pascal, and I joined the C++ side of the C++ vs C USENET "arguments".
      - klipt 9y ago
        Yeah, I loved programming in Delphi back in the day, but I feel like the language isn't evolving much at this point, whereas C++ is a living language (even if it moves bureaucratically slowly) that will eventually have most of the features we want ... plus a bunch of warts we don't really want but have to keep for backwards compatibility :-)
  - wruza 9y ago
    >Pascal knows the size of its types This really means it doesn’t permit variably-sized arrays without a hassle on pure language level, so you can’t fall from a bike because it’s wheels are buried in the basement. Manually-specialized Containers like TStringList still use GetMem() and align a pointer to an “infinite” array to that block, shy trick pretending to be safe until reinvented by mere mortal. Iirc, you had to destroy ^properties in destructor by hand too. Pascal only seemed easier because of three things: a) explicit pointers are hard, b) strings have explicit length of 8 or 16 or 32 bit, and that was also a mess, especially in C interfacing, where PChar worked as intended only half of the time, c) no CS-hard tasks were solved in Pascal by RAD-programmers. Don’t let your fond memories trick you too much. You can get the same/better behavior and speed by using glib, apr, objc, etc and not using pure C arrays at all. https://www.tutorialspoint.com/pascal/pascal_pointers.htm https://www.tutorialspoint.com/pascal/pascal_pointers.htm
    - pjmlp 9y ago
      There was no RAD in Turbo Pascal for MS-DOS, secondly I had the opportunity to live in a country where a CS degree or similar is pretty much a requirement to be hired on the field. Quite a few parallel programming research papers were done in Concurrent Pascal during the 70s. Besides UCSD Pascal, there were a few other OS CS research done in Pascal variants. Variable legth arrays were available. C string manipulation is a joke as well, given that in 2017 still doesn't have a way to handle unicode in spite of wchar_t. The whole point of unsafe code being hard to reach for, is to force people to think instead of producing yet another artifact to hang on the CVE list. Finally, if we are no longer discussing pure C then Pascal also has libraries and extensions, nothing special about C here. In any case, there is no need for C when we have C++, other than keeping UNIX kernel devs happy, and legacy code.
      - wruza 9y ago
        Good points mostly, but I can’t agree on the last one. The new language you mentioned has few drawbacks that can seriously impact the development/architecting cycles (and I experienced these), so for me it must be time-proven first to meet a conclusion.
bpyne 9y ago
That's exactly my evolution as an app dev as well. I understand some people write applications in which they have to wring every bit of inefficiency out of it, but the apps my employer wants don't require that kind of speed.

jandrese 9y ago

It's not like Pascal's memory management and pointer situation was that much better.

pjmlp 9y ago
They actually are, because Pascal knows the size of its types, while C requires using a mix of sizeof and malloc, which many people still get wrong, specially with arrays.
- klipt 9y ago
  Of course in C++ you can just use a vector. Object Pascal is certainly closer to C++ than C. The main advantage of Pascal is super fast compilation, but C++ modules should close that gap once they make it into the standard.
  - pjmlp 9y ago
    Which is why C++ became my next favourite language after Pascal, and I joined the C++ side of the C++ vs C USENET "arguments".
    - klipt 9y ago
      Yeah, I loved programming in Delphi back in the day, but I feel like the language isn't evolving much at this point, whereas C++ is a living language (even if it moves bureaucratically slowly) that will eventually have most of the features we want ... plus a bunch of warts we don't really want but have to keep for backwards compatibility :-)
- wruza 9y ago
  >Pascal knows the size of its types This really means it doesn’t permit variably-sized arrays without a hassle on pure language level, so you can’t fall from a bike because it’s wheels are buried in the basement. Manually-specialized Containers like TStringList still use GetMem() and align a pointer to an “infinite” array to that block, shy trick pretending to be safe until reinvented by mere mortal. Iirc, you had to destroy ^properties in destructor by hand too. Pascal only seemed easier because of three things: a) explicit pointers are hard, b) strings have explicit length of 8 or 16 or 32 bit, and that was also a mess, especially in C interfacing, where PChar worked as intended only half of the time, c) no CS-hard tasks were solved in Pascal by RAD-programmers. Don’t let your fond memories trick you too much. You can get the same/better behavior and speed by using glib, apr, objc, etc and not using pure C arrays at all. https://www.tutorialspoint.com/pascal/pascal_pointers.htm https://www.tutorialspoint.com/pascal/pascal_pointers.htm
  - pjmlp 9y ago
    There was no RAD in Turbo Pascal for MS-DOS, secondly I had the opportunity to live in a country where a CS degree or similar is pretty much a requirement to be hired on the field. Quite a few parallel programming research papers were done in Concurrent Pascal during the 70s. Besides UCSD Pascal, there were a few other OS CS research done in Pascal variants. Variable legth arrays were available. C string manipulation is a joke as well, given that in 2017 still doesn't have a way to handle unicode in spite of wchar_t. The whole point of unsafe code being hard to reach for, is to force people to think instead of producing yet another artifact to hang on the CVE list. Finally, if we are no longer discussing pure C then Pascal also has libraries and extensions, nothing special about C here. In any case, there is no need for C when we have C++, other than keeping UNIX kernel devs happy, and legacy code.
    - wruza 9y ago
      Good points mostly, but I can’t agree on the last one. The new language you mentioned has few drawbacks that can seriously impact the development/architecting cycles (and I experienced these), so for me it must be time-proven first to meet a conclusion.

bpyne 9y ago

That's exactly my evolution as an app dev as well. I understand some people write applications in which they have to wring every bit of inefficiency out of it, but the apps my employer wants don't require that kind of speed.