Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!newsfeed.xs4all.nl!newsfeed1.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Date: Fri, 22 Aug 2014 15:38:56 -0600
From: Michael Torrie <torriem@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131118 Thunderbird/17.0.11
MIME-Version: 1.0
To: python-list@python.org
Subject: Re: Python vs C++
References: <mailman.13248.1408625664.18130.python-list@python.org> <lt6tk2$118$1@dont-email.me> <mailman.13280.1408697414.18130.python-list@python.org> <87fvgoj2i8.fsf@elektro.pacujo.net> <lt85g5$mlq$1@dont-email.me> <87siko9tlq.fsf@elektro.pacujo.net>
In-Reply-To: <87siko9tlq.fsf@elektro.pacujo.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.13311.1408743547.18130.python-list@python.org>
Lines: 65
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:76825

On 08/22/2014 02:06 PM, Marko Rauhamaa wrote:
> I tend to think the opposite: C++ barely has a niche left. I definitely
> wouldn't want to use C++ very far from its (very narrow) sweet spot.

I agree that it's niche is narrowing.  But it's still pretty wide and
widely used.  Many adobe products are C++, for example.  OpenOffice and
LibreOffice is C++.  You could argue that's because they are old
projects and were started in C++. But honestly if you were
reimplementing OpenOffice today what would you choose?  Python would be
appropriate for certain aspects of OO, such as parts of the UI, macros,
filters, etc.  I certainly wouldn't want to use Java (contrary to
popular belief OO is not written in Java; it's definitely C++).  Go is
quite young but promising except that unicode is all UTF-8 byte strings,
so string operations are going to be a bit slow.  C# never lived up to
its promise as the next app development language, even on Windows.  So
at this moment I'd still do it in C++ I think.  Apple chose to use C++
to build clang and llvm in, rather than C.

> My disillusionment with C++ came from the language's inability to
> represent callbacks. C can do it (void *), C# can do it (delegates),
> Java can do it (anonymous inner classes), Python can do it (methods),
> Scheme can do it (closures).

C++ can do it quite well, actually.  Maybe not quite as nicely as
Python.  But boost and libsigc++ both offer nice, type-safe ways to
implement signals and slots.  You can pass references to a callback
around in an easy, safe way.

> Qt needs callbacks ("signals" IIRC). It doesn't use C++ to express them.
> It uses a fricking metacompiler for them.

This is only partially true.  The actual, original, .cpp files with Qt
macros in them compile directly on the C++ compiler.  moc runs on the .h
file to generate some supporting code to help with event dispatching.
There's no such thing as Qt C++.  It's all standard C++, with macros to
help when defining things such as signals.

Macros were chosen instead of templates because at the time, not all C++
compilers supported templates.  Now if it was done all over again,
they'd do something like libsigc++, or boost.

> And Stroustrup's thick book didn't even seem to be aware of callbacks as
> a paradigm and thus didn't show any examples of dealing with them. Too
> bad Stroustrup wasn't aware of C#'s delegates; C++ should have defined
> function pointers as delegates.

Maybe the language doesn't need to implement them as keywords because
it's already possible to do safely with templates.  libsigc++ is a great
implementation that works really well (and it's quite fast at
dispatching events).  libsigc++ has an advantage over Qt in that the
signals are actual type-safe template objects.  Qt's signals are
actually strings under the hood, and I've had weird name clash issues in
the past when I didn't realize that.  Can't remember the circumstances
or the details now.  Basically something that should have been caught at
compile time became a runtime error.

Doing event-driven programming with Gtkmm and libsigc++ is actually
pretty darn nice and is right at home in C++.

> There is one big advantage C++ has over C: virtual method dispatching.
> However, I have been able to come up with C idioms that make practical
> method dispatching relatively painless.

Seems like Vala might fit this niche pretty well.