3 ms·
It's much easier for C to be backward compatible, not because it's a system language per se but rather because it's so minimalist. You don't have problems deali
by simias 7y ago
It's much easier for C to be backward compatible, not because it's a system language per se but rather because it's so minimalist. You don't have problems dealing with unicode when you don't deal with unicode. You don't have a problem dealing with ranges and iterators when your most advanced looping construct is for(i = 0; i < 10; i++). Other more advanced and fully-featured system languages like C++, Rust or Go have a different story to tell and making them backward compatible comes at a significant maintenance cost.
Portability issues in C are mostly between architectures, not standard versions. The fact that "char" is normally signed on x86 but unsigned on ARM for instance is a common source of problems while porting code between these architectures. At least when you have python3 code you can be reasonably sure that it's going to run on any compliant python3 interpreter.
- Mikhail_Edoshin 7y agoBy the way, recently I realized that what I want is a language that does less instead of doing more. After all all these niceties with ranges and iterators are just syntactic sugar. Write pythonic code and face problems when porting this algorithm to C because C has nothing of Python niceties, which stop looking so nice at this point. Write non-pythonic C-like code without classes but with `__slots__` and functions all the way down and get not only the code that can be ported much easier to C and many other languages, but, surprisingly, also the code that is much more accessible and easier to reason about.
- CJefferson 7y agoHowever, I can also still run C++98 code happily, and there has been no suggestion (AFAIK) from any major C++ compiler to remove this support.