Reference

[Rustom Mody]

On Wednesday, March 5, 2014 7:39:17 AM UTC+5:30, Roy Smith wrote:
>  "Rhodri James" wrote:
> > wrote:
> > > Code should look like its intent. Warping it around performance is
> > > hardly ever worthwhile.
> > That depends.  In Python, I'd agree with you; if I'm worrying about  
> > performance in Python, I'm worrying at the level of the algorithms I'm  
> > using.  In a constrained embedded C environment, which is where I spend  
> > most of my working life, writing your code so that the compiler chooses  
> > the right optimisation is critical.  Sometimes it matters a great deal to  
> > me that something like "x *= 5" compiles to a single ARM instruction, or  
> > that splitting a loop into two to avoid a conditional test will let an  
> > DSP's optimiser double the speed of a section of code.

> Yeah.  BTDT.  I've stolen the bottom three bits of a pointer for my own 
> use because I know everything is 64-bit aligned so it's all zeros 
> anyway.  I feel like there must be some organization I should be going 
> to every month that meets in a church basement and I can get up in front 
> of the room and say, "Hi, my name is Roy and I'm a C++ hacker", and have 
> everybody be supportive.

> I mostly live in the Python world these days, where I'm firmly in the 
> camp of, "Stay away from O(n^2) and don't hit the database with 
> unindexed queries, and you're probably good".  But, that's because we 
> push most of the hard work off onto C and C++ code that is written by 
> guys who worry about the bottom three bits.

> One of those really awesome tools is haproxy.  It's just amazing how 
> fast (and stable) that thing is.  It's all written in C.  Most of the if 
> statements are decorated with #pragmas telling the compiler which branch 
> is the most likely to be taken, so it can optimize better.  We need 
> people like that down in the trenches, so the rest of us can run around 
> naked in the park with flowers in our hair and not worry about the 
> bottom three bits any more.

I agree with most of the sentiment above...
Except the implication that C and C++ are equivalent

I wrote http://www.the-magus.in/Publications/chor.pdf
25 years ago criticising C *in education*.
I was half my age then and used stronger language then than I would now
Ive tried to express some pangs of conscience here
http://blog.languager.org/2013/02/c-in-education-and-software-engineering.html

However my point then as now was:
"C is dangerous to TEACH CS/programming with.
Its sweet if you KNOW what you are up to."

With C++ its horrible all the way

- C++ has pretentious abstractions that invariably leak*
  C is honest in having few abstractions

- C++ syntax is ridiculously brittle. C syntax is mostly straightforward     

- One of C's difficulties is complex binding-times: pre-process, compile, link
  load, run.  Needs work but is master-able. With C++ Ive not got the
  basics after 25 years -- order of static constructors, templates...

- I dont believe its coincidence that most of the rock-solid software
  I use has a C (not C++) under-belly -- python, linux-kernel,
  emacs, gcc, haskell, git, latex
  With apps in C++ its always catching-cook -- will it segfault me before 
  I save my file?
- Some guys with a wee bit more reputation who seem to agree with
  yours truly
  o http://article.gmane.org/gmane.comp.version-control.git/57918
  o http://harmful.cat-v.org/software/c++/rms

* ... which summarizes my objection in this thread: Python's 'is' leaks the 
machine abstraction. 'id' does it legitimately (somewhat), 
'is' does it illegitimately