Reference
Rustom Mody
rustompmody at gmail.com
Tue Mar 4 22:36:38 EST 2014
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
More information about the Python-list
mailing list