Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #76731 > unrolled thread

Python vs C++

Back to article view | Back to comp.lang.python

Contents

  Python vs C++ David Palao <dpalao.python@gmail.com> - 2014-08-21 14:54 +0200
    Re: Python vs C++ wxjmfauth@gmail.com - 2014-08-21 07:08 -0700
    Re: Python vs C++ Rustom Mody <rustompmody@gmail.com> - 2014-08-21 07:10 -0700
    Re: Python vs C++ Grant Edwards <invalid@invalid.invalid> - 2014-08-21 14:59 +0000
      Re: Python vs C++ Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-08-21 23:12 -0400
    Re: Python vs C++ Christian Gollwitzer <auriocus@gmx.de> - 2014-08-22 10:05 +0200
      Re: Python vs C++ Chris Angelico <rosuav@gmail.com> - 2014-08-22 18:50 +1000
        Re: Python vs C++ Marko Rauhamaa <marko@pacujo.net> - 2014-08-22 12:29 +0300
          Re: Python vs C++ "Neil D. Cerutti" <neilc@norwich.edu> - 2014-08-22 08:51 -0400
          Re: Python vs C++ Skip Montanaro <skip@pobox.com> - 2014-08-22 07:58 -0500
            Re: Python vs C++ Marko Rauhamaa <marko@pacujo.net> - 2014-08-22 20:16 +0300
              Re: Python vs C++ mm0fmf <none@mailinator.com> - 2014-08-23 17:47 +0100
                Re: Python vs C++ Marko Rauhamaa <marko@pacujo.net> - 2014-08-23 19:54 +0300
          Re: Python vs C++ Chris Angelico <rosuav@gmail.com> - 2014-08-22 23:00 +1000
          Re: Python vs C++ Christian Gollwitzer <auriocus@gmx.de> - 2014-08-22 21:25 +0200
            Re: Python vs C++ Stefan Behnel <stefan_ml@behnel.de> - 2014-08-22 21:58 +0200
            Re: Python vs C++ Marko Rauhamaa <marko@pacujo.net> - 2014-08-22 23:06 +0300
              Re: Python vs C++ Michael Torrie <torriem@gmail.com> - 2014-08-22 15:38 -0600
                Re: Python vs C++ wxjmfauth@gmail.com - 2014-08-23 03:00 -0700
              Re: Python vs C++ Chris Angelico <rosuav@gmail.com> - 2014-08-23 07:49 +1000
                Re: Python vs C++ Rustom Mody <rustompmody@gmail.com> - 2014-08-23 05:38 -0700
                  Re: Python vs C++ Chris Angelico <rosuav@gmail.com> - 2014-08-23 23:00 +1000
                  Re: Python vs C++ Ian Kelly <ian.g.kelly@gmail.com> - 2014-08-23 08:02 -0600
                    Re: Python vs C++ Rustom Mody <rustompmody@gmail.com> - 2014-08-23 07:21 -0700
                      Re: Python vs C++ Terry Reedy <tjreedy@udel.edu> - 2014-08-23 16:51 -0400
                  Re: Python vs C++ Chris Angelico <rosuav@gmail.com> - 2014-08-24 00:21 +1000
                  Re: Python vs C++ Terry Reedy <tjreedy@udel.edu> - 2014-08-23 15:09 -0400
                  Re: Python vs C++ Joseph Martinot-Lagarde <joseph.martinot-lagarde@m4x.org> - 2014-08-24 14:54 +0200
                  Re: Python vs C++ "Neil D. Cerutti" <neilc@norwich.edu> - 2014-08-25 09:01 -0400
              Re: Python vs C++ Michael Torrie <torriem@gmail.com> - 2014-08-22 15:56 -0600
              Re: Python vs C++ Chris Angelico <rosuav@gmail.com> - 2014-08-23 08:00 +1000
                Re: Python vs C++ Marko Rauhamaa <marko@pacujo.net> - 2014-08-23 10:27 +0300
              Re: Python vs C++ dieter <dieter@handshake.de> - 2014-08-23 07:56 +0200
              Re: Python vs C++ Chris Angelico <rosuav@gmail.com> - 2014-08-23 16:11 +1000
                Re: Python vs C++ Paul Rudin <paul.nospam@rudin.co.uk> - 2014-08-23 08:36 +0100
                  Re: Python vs C++ Chris Angelico <rosuav@gmail.com> - 2014-08-23 18:04 +1000
            Re: Python vs C++ dieter <dieter@handshake.de> - 2014-08-23 07:48 +0200

Page 2 of 2 — ← Prev page 1 [2]

#76863

On Saturday, August 23, 2014 3:19:37 AM UTC+5:30, Chris Angelico wrote:
> On Sat, Aug 23, 2014 at 7:38 AM, Michael Torrie  wrote:
> > 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. ...

> Frankly, I wouldn't write OO in anything, because I think the entire
> concept of a WYSIWYG editor is flawed. Much better to use markup and
> compile it. But if I were to write something like that, probably what
> I'd do would be to write a GUI widget in whatever lowish-level
> language is appropriate (probably C, with most GUI toolkits), and then
> use a high level language (probably Python or Pike) to build the
> application. I'm not familiar with all of OO/LO's components, but I
> believe that model will probably work for all of them (the document
> editor, obviously; the presentation editor might be done a bit
> differently, but it'd still work this way; the spreadsheet quite
> possibly doesn't even need a custom widget; etc).

Here is an example (not identical but analogous to) where markup+compile is 
distinctly weaker than wysiwyg:

You can use lilypond to type music and the use a midi player to play it
But lilypond does not allow playing and seeing-in-realtime

WYSIWYG editors allow that -- can make a huge difference to beginners
who find music hard to read.

Here's an example I typed out in the wysiwig editor nted
https://vimeo.com/16894001 ¹

Many more examples like this on the musescore site eg
http://musescore.com/user/19710/scores/261621

I believe that in a like way an app like Word that has a full (Turing complete)
language -- VBA -- is more powerful than an offline tool like lilypond

¹ No I dont enjoy clickety-click when a typewriter would work better.
I know a musician friend who has worked out the best combo: type in
with a cheap midi connected keyboard, then use Sibelius.
I believe its only a question of time before musescore like wysiwyg editors
will be able to do that

[toc] | [prev] | [next] | [standalone]

#76864

On Sat, Aug 23, 2014 at 10:38 PM, Rustom Mody <rustompmody@gmail.com> wrote:
> Here is an example (not identical but analogous to) where markup+compile is
> distinctly weaker than wysiwyg:
>
> You can use lilypond to type music and the use a midi player to play it
> But lilypond does not allow playing and seeing-in-realtime
>
> WYSIWYG editors allow that -- can make a huge difference to beginners
> who find music hard to read.

I don't buy that it's weaker. In fact, I'd say this proves that markup
is distinctly better - just a little harder to do "Hello, world" in.

At best, the simple GUI makes it easier to do something
straight-forward, and then basically lets you drop to the more
complicated form. At worst, it makes it easier to do the very simple,
and nearly impossible to do the more complicated.

ChrisA

[toc] | [prev] | [next] | [standalone]

#76869

[Multipart message — attachments visible in raw view] — view raw

On Sat, Aug 23, 2014 at 6:38 AM, Rustom Mody <rustompmody@gmail.com> wrote:
> Here is an example (not identical but analogous to) where markup+compile
is
> distinctly weaker than wysiwyg:
>
> You can use lilypond to type music and the use a midi player to play it
> But lilypond does not allow playing and seeing-in-realtime
>
> WYSIWYG editors allow that -- can make a huge difference to beginners
> who find music hard to read.

I don't know how fast lilypond is, but perhaps one could write an editor
that wraps lilypond and invokes it in realtime to show the output in an
adjacent panel, perhaps with a brief delay when the user stops typing.

[toc] | [prev] | [next] | [standalone]

#76871

On Saturday, August 23, 2014 7:32:12 PM UTC+5:30, Ian wrote:
> On Sat, Aug 23, 2014 at 6:38 AM, Rustom Mody <rusto...@gmail.com> wrote:
> > Here is an example (not identical but analogous to) where markup+compile is
> > distinctly weaker than wysiwyg:
> > You can use lilypond to type music and the use a midi player to play it
> > But lilypond does not allow playing and seeing-in-realtime
> > WYSIWYG editors allow that -- can make a huge difference to beginners
> > who find music hard to read.

> I don't know how fast lilypond is, but perhaps one could write an
> editor that wraps lilypond and invokes it in realtime to show the
> output in an adjacent panel, perhaps with a brief delay when the
> user stops typing.

Yes.
Wordperfect was one of the best wysiwyg editors Ive used.
One could use it in normal (1-screen) mode
Or one could split the screen and see the formattings in the lower window
along withe the formatted in the upper.

Which is to say I believe weve not the heard the last of finding the 
best mix between WYSIWYG and coded-text+compile

This the same as what you are saying because if one
writes the editor to wrap lilypond and show in another window
the next step is to allow editing in either windows and have the app
keep them in sync

[toc] | [prev] | [next] | [standalone]

#76899

On 8/23/2014 10:21 AM, Rustom Mody wrote:

> Wordperfect was one of the best wysiwyg editors Ive used.
> One could use it in normal (1-screen) mode
> Or one could split the screen and see the formattings in the lower window
> along withe the formatted in the upper.

I wrote at least two books with Wordperfect. Seeing the formatting code 
was essential to get the detail correct. Word, and even OO and LO are 
downgrades in this respect. At least with LO, one can get or enable 
saving as flat xml and edit at that level.

> Which is to say I believe weve not the heard the last of finding the
> best mix between WYSIWYG and coded-text+compile

I'd like to have side-by-side windows with LO.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#76872

On Sun, Aug 24, 2014 at 12:02 AM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> I don't know how fast lilypond is, but perhaps one could write an editor
> that wraps lilypond and invokes it in realtime to show the output in an
> adjacent panel, perhaps with a brief delay when the user stops typing.

You theoretically could, but it'd be a bit awkward in places. It's not
hard for a small textual change to result in a large visual change (eg
if you use relative notes and add/remove an octave shift - it'll shift
every subsequent note in the staff, which might mean more/less ledger
lines needed, which will affect how much vertical space the staff
needs, which will affect pagination...), so it'd often make for rather
nasty flicker. Better to keep it explicit.

ChrisA

[toc] | [prev] | [next] | [standalone]

#76888

On 8/23/2014 8:38 AM, Rustom Mody wrote:

> WYSIWYG editors allow that -- can make a huge difference to beginners
> who find music hard to read.
>
> Here's an example I typed out in the wysiwig editor nted
> https://vimeo.com/16894001 ¹

"Awww, snap!
This video can’t be played with your current setup"

How informative. At least we try to do better with Python exception 
messages.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#76930

Le 23/08/2014 16:21, Chris Angelico a écrit :
> On Sun, Aug 24, 2014 at 12:02 AM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
>> I don't know how fast lilypond is, but perhaps one could write an editor
>> that wraps lilypond and invokes it in realtime to show the output in an
>> adjacent panel, perhaps with a brief delay when the user stops typing.
>
> You theoretically could, but it'd be a bit awkward in places. It's not
> hard for a small textual change to result in a large visual change (eg
> if you use relative notes and add/remove an octave shift - it'll shift
> every subsequent note in the staff, which might mean more/less ledger
> lines needed, which will affect how much vertical space the staff
> needs, which will affect pagination...), so it'd often make for rather
> nasty flicker. Better to keep it explicit.
>
> ChrisA
>
Frescobaldi (http://www.frescobaldi.org/) works exactly like this. It's 
like a latex IDE but for lilypond. It's quite powerfull and 
multiplatform. I use it exclusively now, it's way better that the bash 
script I used before that more or less rebuild the files when changed.

This way you get the power of plain text and you have an almost 
instantaneous snapshot of the end result.

[toc] | [prev] | [next] | [standalone]

#76979

On 8/23/2014 9:00 AM, Chris Angelico wrote:
> On Sat, Aug 23, 2014 at 10:38 PM, Rustom Mody <rustompmody@gmail.com> wrote:
>> Here is an example (not identical but analogous to) where markup+compile is
>> distinctly weaker than wysiwyg:
>>
>> You can use lilypond to type music and the use a midi player to play it
>> But lilypond does not allow playing and seeing-in-realtime
>>
>> WYSIWYG editors allow that -- can make a huge difference to beginners
>> who find music hard to read.
>
> I don't buy that it's weaker. In fact, I'd say this proves that markup
> is distinctly better - just a little harder to do "Hello, world" in.
>
> At best, the simple GUI makes it easier to do something
> straight-forward, and then basically lets you drop to the more
> complicated form. At worst, it makes it easier to do the very simple,
> and nearly impossible to do the more complicated.

The worst part of using a WYSIWIG program is the frustration of 
correcting a bewildering problem when some kind of autoformatting magic 
goes wrong.

One odd example is when using Word to compose template documents meant 
for merging with external data. The markup+compile phase takes on a 
whole new, horrible meaning. My ears are turning red just imagining the 
next time I have to do it.

-- 
Neil Cerutti

[toc] | [prev] | [next] | [standalone]

#76827

On 08/22/2014 03:49 PM, Chris Angelico wrote:
> My main issue with callbacks in either C or C++ is that functions
> aren't first-class objects. You can pass function pointers around (and
> you don't need (void *) to do it, you can use typed function pointers
> just fine), but you can't actually construct a function at run-time.

I'm not sure I fully understand your meaning.  You seem to prefer
dynamic languages, which is great because this is the Python list after
all.  I'm not sure I know of any statically compiled language that lets
one construct a function at run-time.  I know Boost supports lambda
functions but I'm not sure this is quite what you are referring to either.

[toc] | [prev] | [next] | [standalone]

#76828

On Sat, Aug 23, 2014 at 7:56 AM, Michael Torrie <torriem@gmail.com> wrote:
> On 08/22/2014 03:49 PM, Chris Angelico wrote:
>> My main issue with callbacks in either C or C++ is that functions
>> aren't first-class objects. You can pass function pointers around (and
>> you don't need (void *) to do it, you can use typed function pointers
>> just fine), but you can't actually construct a function at run-time.
>
> I'm not sure I fully understand your meaning.  You seem to prefer
> dynamic languages, which is great because this is the Python list after
> all.  I'm not sure I know of any statically compiled language that lets
> one construct a function at run-time.  I know Boost supports lambda
> functions but I'm not sure this is quite what you are referring to either.

Right, I'm just saying that callbacks are inherently restrictive in a
language without first-class functions. So I'm not sure why you have
further issue with C++; C's way of doing callbacks works fine in C++,
and there's not going to be anything better.

ChrisA

[toc] | [prev] | [next] | [standalone]

#76844

Chris Angelico <rosuav@gmail.com>:

> I'm just saying that callbacks are inherently restrictive in a
> language without first-class functions.

You don't have to go that far to have great callback support. C# (and
Delphi) show a great model that I wish C++ had adopted from the
beginning. C++ could have declared that a function pointer contains the
function pointer plus the (optional) this pointer. That would have dealt
with the whole (important) issue.

> So I'm not sure why you have further issue with C++; C's way of doing
> callbacks works fine in C++, and there's not going to be anything
> better.

Well, C++11 brings in the lambda (<URL:
http://www.cprogramming.com/c++11/c++11-lambda-closures.html>):

   One of the biggest beneficiaries of lambda functions are, no doubt,
   power users of the standard template library algorithms package.
   Previously, using algorithms like for_each was an exercise in
   contortions.


Using void pointers in C++ is like sacrificing to the idols.


Marko

[toc] | [prev] | [next] | [standalone]

#76842

Chris Angelico <rosuav@gmail.com> writes:
> Frankly, I wouldn't write OO in anything, because I think the entire
> concept of a WYSIWYG editor is flawed.

That would limit (so called) office applications to experts only.
But the success of these applications relies on the fact, that
even a complete novice can immediately use them. For "non-experts"
WYSIWYG editors are important.

[toc] | [prev] | [next] | [standalone]

#76843

On Sat, Aug 23, 2014 at 3:56 PM, dieter <dieter@handshake.de> wrote:
> Chris Angelico <rosuav@gmail.com> writes:
>> Frankly, I wouldn't write OO in anything, because I think the entire
>> concept of a WYSIWYG editor is flawed.
>
> That would limit (so called) office applications to experts only.
> But the success of these applications relies on the fact, that
> even a complete novice can immediately use them. For "non-experts"
> WYSIWYG editors are important.

People say that. But WYSIWYG editors are the primary cause of
frustrated yelling from the far end of the house, in my experience. I
think they're an attractive nuisance. They're complicated to get right
("pure" WYSIWYG is useless, so you have to balance the visual benefit
of being close to the result against the utility of seeing some of the
non-printing information), and non-modular. With a text editor +
compiler concept (whether the compiler's language is as big and
complex as LaTeX or as simple as ReST), you can change editors without
breaking anything. You don't like Libre Office Writer? Tough, there's
no real alternative if you want to work on LO files.

ChrisA

[toc] | [prev] | [next] | [standalone]

#76845

Chris Angelico <rosuav@gmail.com> writes:

> On Sat, Aug 23, 2014 at 3:56 PM, dieter <dieter@handshake.de> wrote:
>> Chris Angelico <rosuav@gmail.com> writes:
>>> Frankly, I wouldn't write OO in anything, because I think the entire
>>> concept of a WYSIWYG editor is flawed.
>>
>> That would limit (so called) office applications to experts only.
>> But the success of these applications relies on the fact, that
>> even a complete novice can immediately use them. For "non-experts"
>> WYSIWYG editors are important.
>
> People say that. But WYSIWYG editors are the primary cause of
> frustrated yelling from the far end of the house, in my experience. I
> think they're an attractive nuisance. They're complicated to get right
> ("pure" WYSIWYG is useless, so you have to balance the visual benefit
> of being close to the result against the utility of seeing some of the
> non-printing information), and non-modular. With a text editor +
> compiler concept (whether the compiler's language is as big and
> complex as LaTeX or as simple as ReST), you can change editors without
> breaking anything. You don't like Libre Office Writer? Tough, there's
> no real alternative if you want to work on LO files.
>

The other problem is that because people are so used to using Word for
all text preparation we end up with Word files being used to carry
content for which plain text is just fine and would be preferable.

The conflation of text editing / word processing / desk top publishing
is problematic on a lot of levels.

I'm unconvinced is that e.g. LaTeX is inherently more "expert" that Word
for simple document preparation. It's mostly a question of familiarity.

[toc] | [prev] | [next] | [standalone]

#76849

On Sat, Aug 23, 2014 at 5:36 PM, Paul Rudin <paul.nospam@rudin.co.uk> wrote:
> I'm unconvinced is that e.g. LaTeX is inherently more "expert" that Word
> for simple document preparation. It's mostly a question of familiarity.

I think LaTeX probably is, in the same way that PhotoShop or Gimp is
more expert than a simple paint program, but something like ReST
should be easy for anyone to work with... and it'd require less
familiarity than Word does before you get to call yourself an expert.

ChrisA

[toc] | [prev] | [next] | [standalone]

#76841

Christian Gollwitzer <auriocus@gmx.de> writes:
> ...
> * Java: I don't see that it is much higher level than C++. It has a
> GC, but that's all, and you can have that in C++, too, if you want. On
> the other hand, you loose the metaprogramming facilities provided by
> C++ templates (needs a guru to make a library, but can be handy and
> easy to use, e.g. everything in Boost). You loose direct memory
> access, gaining what? no idea.

Automatic memory compaction -- which can be quite helpfull with
long running applications (avoiding memory fragmentation).

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.python

csiph-web