4 ms·
Completely agree. TBH, my ideal language for this job would probably be Rust, but that is just not a mature enough ecosystem currently. Don't get me wrong, I
by TickleSteve 10y ago
Completely agree.
TBH, my ideal language for this job would probably be Rust, but that is just not a mature enough ecosystem currently.
Don't get me wrong, I would consider myself a C proponent currently, but I would love to see change in a Rust-like direction.
Despite you classing yourself as a C-opponent, I suspect we agree more than disagree.
- nickpsecurity 10y agoProbably. I think you're a pragmatist rather than a true believer. ;) Btw, what do you think of a reboot of Modula-2, Modula-3, or just Ada/SPARK? Your opinion on them would be interesting given your background. Closest thing to Modula's that's actively developed is Astrobe Oberon for embedded. https://en.wikipedia.org/wiki/Modula-3 https://en.wikipedia.org/wiki/Modula-3 http://www.astrobe.com/Oberon.htm http://www.astrobe.com/Oberon.htm
- TickleSteve 10y ago(Certainly a pragmatist) I started off with Turbo Pascal before graduating to Turbo C, so I do have a fondness for the Pascal family of languages. I also love type-safety.... TBH, I would prefer a hypothetical "fix" for the C language that improved type strictness/safety over "fixes" for resource/memory management issues which I consider should be bread and butter for any software engineer. So in that, I do not like large runtimes or garbage collection, more visibility to what the machine is really doing is needed. GC systems are also not predictable enough, deterministic runtime is absolutely essential to making reliable software. I have poked my nose around Modula-2 in the past, but C took over for me personally. ADA I consider to be far to heavyweight for anything serious (and thats after being in a company that used it extensively in the defence world, tho I never had to touch it myself) Currently Rust is my best hope for the future.... but C has survived well IMO.
- nickpsecurity 10y agoInteresting response. Thanks.
- pjmlp 10y agoAlso a pragmatist, as although I tend to bash on C on every occasion and would rather not use it, if a customer does require it, I will use it. For me a kind of escape path from C, back when I was into Turbo Pascal, was to move to Turbo C++. I only got to use Turbo C around one year before getting to learn about this new cool language called C++. It allowed me to keep some of the Turbo Pascal safety around. What are your approaches when using plain C, coming from "so I do have a fondness for the Pascal family of languages. I also love type-safety" ? My solutions were: - Use translation units as TP units, only exposing functions and struct accessors (macros if function calls were too expensive) - Always make use of debug functions to validate pointers in debug builds (e.g. _malloc_dbg, _CrtIsValidPointer on Windows) - make use of const as much as possible - write my own wrappers around strncpy and friends - compile warnings as errors - if given the option, just use C++ instead and prefer library types to inherited C ones (string, array, references, RAII).