3 ms·

Obviously, I have no perfect solution. I was initially harboring the vague hope that Nimrod would be able to avoid this problem by virtue of compiling to C. Bu

by xaa 13y ago

Obviously, I have no perfect solution. I was initially harboring the vague hope that Nimrod would be able to avoid this problem by virtue of compiling to C. But I do still assert that this is a "fatal flaw" for a systems programming language. When I wrap a C library in, say, Python, I am already forced to write a wrapper layer, so there's no discomfort or surprise in declaring a few additional structs or function prototypes. For a novel systems programming language, however, whose raison d'être is to save me keystrokes over C/C++, it feels like two steps forward and one step back to have a more concise main program but lots of auxillary handwritten header translations that have to be manually maintained. I believe that the primary reason for the success of C++ is its easy compatibility with C, and any creators of would-be C++ replacements who fail to understand this are doomed to failure.

pjmlp 13y ago
> I believe that the primary reason for the success of C++ is its easy compatibility with C, and any creators of would-be C++ replacements who fail to understand this are doomed to failure. The main reason were actually - Most C compiler vendors bundled C++ compilers in the begining - The C and C++ compiler vendors that matter are OS vendors Any language can replace C or C++, if an OS vendor decides that it is the way to go. Lets say Apple decides to have Objective-C as their systems language, or Microsoft decides to have C# as their systems language. Once upon a time, Apple's system programming language was a Pascal dialect, just as an example. Developers are always at the mercy what languages are the official ones in a given platform. This is how Microsoft is deprecating C on Windows nowadays, by leaving their C compiler at C90 level and stating C++ is the official systems language for Windows on their tooling.
- 0x09 13y ago
  > This is how Microsoft is deprecating C on Windows nowadays, by leaving their C compiler at C90 level Actually they've recently gone back on that and are implementing c99 language[1] and standard library[2] features in an apparent sudden realization that the rest of the C world has moved on (since they cite FFmpeg as a reason, my pet theory is that they were just that embarrassed by Ron Bultje's c99 to c89 translator[3]) [1] http://blogs.msdn.com/b/somasegar/archive/2013/06/28/cpp-conformance-roadmap.aspx http://blogs.msdn.com/b/somasegar/archive/2013/06/28/cpp-con... [2] http://blogs.msdn.com/b/vcblog/archive/2013/07/19/c99-library-support-in-visual-studio-2013.aspx http://blogs.msdn.com/b/vcblog/archive/2013/07/19/c99-librar... [3] http://blogs.gnome.org/rbultje/2012/09/27/microsoft-visual-studio-support-in-ffmpeg-and-libav http://blogs.gnome.org/rbultje/2012/09/27/microsoft-visual-s...
  - pjmlp 13y ago
    Those C99 features are only at library level and are partially required by C++11 and C++14, there is no change of mind going on, at least for the moment.

by xaa 13y ago

pjmlp 13y ago

> I believe that the primary reason for the success of C++ is its easy compatibility with C, and any creators of would-be C++ replacements who fail to understand this are doomed to failure. The main reason were actually - Most C compiler vendors bundled C++ compilers in the begining - The C and C++ compiler vendors that matter are OS vendors Any language can replace C or C++, if an OS vendor decides that it is the way to go. Lets say Apple decides to have Objective-C as their systems language, or Microsoft decides to have C# as their systems language. Once upon a time, Apple's system programming language was a Pascal dialect, just as an example. Developers are always at the mercy what languages are the official ones in a given platform. This is how Microsoft is deprecating C on Windows nowadays, by leaving their C compiler at C90 level and stating C++ is the official systems language for Windows on their tooling.

0x09 13y ago
> This is how Microsoft is deprecating C on Windows nowadays, by leaving their C compiler at C90 level Actually they've recently gone back on that and are implementing c99 language[1] and standard library[2] features in an apparent sudden realization that the rest of the C world has moved on (since they cite FFmpeg as a reason, my pet theory is that they were just that embarrassed by Ron Bultje's c99 to c89 translator[3]) [1] http://blogs.msdn.com/b/somasegar/archive/2013/06/28/cpp-conformance-roadmap.aspx http://blogs.msdn.com/b/somasegar/archive/2013/06/28/cpp-con... [2] http://blogs.msdn.com/b/vcblog/archive/2013/07/19/c99-library-support-in-visual-studio-2013.aspx http://blogs.msdn.com/b/vcblog/archive/2013/07/19/c99-librar... [3] http://blogs.gnome.org/rbultje/2012/09/27/microsoft-visual-studio-support-in-ffmpeg-and-libav http://blogs.gnome.org/rbultje/2012/09/27/microsoft-visual-s...
- pjmlp 13y ago
  Those C99 features are only at library level and are partially required by C++11 and C++14, there is no change of mind going on, at least for the moment.