On 6 January 2015 at 13:56, Thomas Koster <[email protected]> wrote: > These two posts by Damien Katz (creator of CouchDB) are inspiring reading > if you are concerned that going back to C is a regression: > > - > http://damienkatz.net/2013/01/the_unreasonable_effectiveness_of_c.html > - http://damienkatz.net/2013/01/follow_up_to_the_unreasonable.html > > On 6 January 2015 at 15:01, Greg Keogh <[email protected]> wrote:
> I read Katz's articles, and I claim there's a fair bit of bluster and > bullshit in what he says about C being a *high level language*. > I wrote assembler daily for 12 years and when I bought the C/C++ SDK 3.1 in > 1992 so I could learn this mystical and legendary language C (and C++ a > soon after) I was quite shocked to discover that C is basically a pretty > indented version of assembler, although much more friendly and productive > in comparison. I actually wished I had been writing C instead of assembler > for all those years. > True, Katz's tone is certainly sensational. I suppose it is all relative to where you are coming from, i.e. how high is "high level" to you? Remembering that he hacks database servers, I can understand his point of view. A point I think Katz forgets to make is that he appears to be speaking strictly about the C *language* (its syntax and operational semantics), not its standard library, which I also agree is little more than library sugar over system calls and assembly. Hoisted into a much higher-level environment, I do believe the C *language* can be a credible scripting language due to its simplicity and predictability. It is certainly simpler to parse, compile, interpret, read and write than JavaScript, for example. > And "callable from anywhere" and "small surface area APIs" ... who's leg > is he pulling? > By "callable from anywhere" I think he means "callable from any language", not portable binaries. It is true that the foreign function interface for almost every higher-than-C-level language that has one uses the target platform's native C ABI for its external interface (P/Invoke, JNI, etc.). The reason behind this migration is more peculiar: there are appalling > performance bugs in the Borland math libraries of Sin, Cos, etc that > apparently will not be fixed, > That is surprising, since I thought Borland compilers were traditionally known for generating high-performing machine code. I believe my 486 had these operations in hardware in 1993, although I wouldn't have known at the time since I was in primary school. P.S. In previous days I've been reading about "Modern C++" ... Are people > here following the style? Guess what I reckon Modern C++ looks like ... C# > and Java. I wonder how Stroustup feels about that. > Stroustrup has an interesting FAQ with many "What do you think about..." questions. http://www.stroustrup.com/bs_faq.html Alexandrescu's book "Modern C++ Design" is apparently the book that changed C++ forever (and for the worse, to those of us who now regard C++ as a write-only language). From what I understand, if you learned C++ the way Microsoft used it in MFC, you should approach this book as if you were learning a new programming language. I don't use C++ any more myself, but I have seen the "template metaprogramming" style used heavily in the Boost C++ libraries. -- Thomas Koster
