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

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

Why Python is like C++

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

Contents

  Why Python is like C++ Roy Smith <roy@panix.com> - 2013-12-20 09:19 -0500
    Re: Why Python is like C++ Serhiy Storchaka <storchaka@gmail.com> - 2013-12-20 19:46 +0200
      Re: Why Python is like C++ Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2013-12-21 10:44 +1300
        Re: Why Python is like C++ Michael Torrie <torriem@gmail.com> - 2013-12-20 22:25 -0700
          Re: Why Python is like C++ Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2013-12-21 21:06 +1300
            Re: Why Python is like C++ Chris Angelico <rosuav@gmail.com> - 2013-12-21 19:17 +1100
            Re: Why Python is like C++ Christian Gollwitzer <auriocus@gmx.de> - 2013-12-21 11:19 +0100
              Re: Why Python is like C++ Tim Chase <tim@thechases.com> - 2013-12-21 08:52 -0600
                Re: Why Python is like C++ Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2013-12-22 13:17 +1300
              Re: Why Python is like C++ Tim Chase <python.list@tim.thechases.com> - 2013-12-21 08:43 -0600
                Re: Why Python is like C++ Roy Smith <roy@panix.com> - 2013-12-21 10:59 -0500
                  Re: Why Python is like C++ Tim Chase <python.list@tim.thechases.com> - 2013-12-21 10:29 -0600
                  Re: Why Python is like C++ Chris Angelico <rosuav@gmail.com> - 2013-12-22 06:04 +1100
                Re: Why Python is like C++ Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2013-12-22 13:27 +1300
              Re: Why Python is like C++ Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2013-12-22 13:14 +1300
            Re: Why Python is like C++ Michael Torrie <torriem@gmail.com> - 2013-12-21 08:46 -0700
              Re: Why Python is like C++ Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2013-12-22 13:36 +1300
    Re: Why Python is like C++ Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-21 05:34 +0000
      Re: Why Python is like C++ Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2013-12-21 21:09 +1300
        Re: Why Python is like C++ Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-21 08:22 +0000
      Re: Why Python is like C++ Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-12-21 11:37 +0000
        Re: Why Python is like C++ Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-21 12:12 +0000
    Re: Why Python is like C++ Dan Stromberg <drsalists@gmail.com> - 2013-12-21 00:18 -0800
      Re: Why Python is like C++ Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-12-21 11:51 +0000
      Re: Why Python is like C++ Roy Smith <roy@panix.com> - 2013-12-21 10:10 -0500
        Re: Why Python is like C++ Terry Reedy <tjreedy@udel.edu> - 2013-12-21 17:03 -0500
          Re: Why Python is like C++ Roy Smith <roy@panix.com> - 2013-12-21 17:28 -0500
            Re: Why Python is like C++ Terry Reedy <tjreedy@udel.edu> - 2013-12-21 19:20 -0500
    Re: Why Python is like C++ Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-21 08:42 +0000
    Re: Why Python is like C++ Gene Heskett <gheskett@wdtv.com> - 2013-12-21 14:05 -0500

Page 1 of 2  [1] 2  Next page →

#62434 — Why Python is like C++

http://xkcd.com/1306/

[toc] | [next] | [standalone]

#62445

20.12.13 16:19, Roy Smith написав(ла):
> http://xkcd.com/1306/

QBASIC$, not $QBASIC.

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

#62454

Serhiy Storchaka wrote:
> 20.12.13 16:19, Roy Smith написав(ла):
> 
>> http://xkcd.com/1306/
> 
> QBASIC$, not $QBASIC.

Or just QB$. (Most BASICs of that era only regarded
the first two characters as significant.)

-- 
Greg

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

#62465

On 12/20/2013 02:44 PM, Gregory Ewing wrote:
> Serhiy Storchaka wrote:
>> 20.12.13 16:19, Roy Smith написав(ла):
>>
>>> http://xkcd.com/1306/
>>
>> QBASIC$, not $QBASIC.
> 
> Or just QB$. (Most BASICs of that era only regarded
> the first two characters as significant.)

Maybe BASIC's of the 70s.  But Not QB.  QuickBasic was a pretty
impressive compiler in its day.  Completely modern, structured language.
 And a pretty impressive IDE for its day that did some pretty slick
source code navigation.

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

#62474

Michael Torrie wrote:
> Maybe BASIC's of the 70s.  But Not QB.  QuickBasic was a pretty
> impressive compiler in its day.  Completely modern, structured language.

I may have been thinking of GW-BASIC. There was
definitely something that was pretty much an
old-school BASIC with line numbers, GOSUBS and
all that.

-- 
Greg

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

#62476

On Sat, Dec 21, 2013 at 7:06 PM, Gregory Ewing
<greg.ewing@canterbury.ac.nz> wrote:
> Michael Torrie wrote:
>>
>> Maybe BASIC's of the 70s.  But Not QB.  QuickBasic was a pretty
>> impressive compiler in its day.  Completely modern, structured language.
>
>
> I may have been thinking of GW-BASIC. There was
> definitely something that was pretty much an
> old-school BASIC with line numbers, GOSUBS and
> all that.

GW-BASIC is what you're describing. Q-BASIC isn't the same as
QuickBasic, though. Q-BASIC had subs and functions and stuff, but it
was still, at its heart, BASIC. And you could DIM something with a
type, but normally it was the adorning suffix that determined type: A$
is a string, A% is an integer, A! (or A) is float, A# is double.

ChrisA

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

#62482

Am 21.12.13 09:06, schrieb Gregory Ewing:
> Michael Torrie wrote:
>> Maybe BASIC's of the 70s.  But Not QB.  QuickBasic was a pretty
>> impressive compiler in its day.  Completely modern, structured language.
>
> I may have been thinking of GW-BASIC. There was
> definitely something that was pretty much an
> old-school BASIC with line numbers, GOSUBS and
> all that.
>

GW-BASIC was a weak language, but two significant characters is 
definitely too few. I think it was eight. Never used QuickBasic, I went 
Turbo Pascal instead, which had 32 significant characters.

	Christian

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

#62494

On 2013-12-21 08:43, Tim Chase wrote:
> Then there's the 6502 assembly on that Apple with its 2 user-facing
> registers (plus the Instruction Pointer and Stack Pointer), so I
> guess you could say that it has 1-bit variable names ;-)

Doh, forgot momentarily that the 6502 had X, Y, and A, making THREE
registers.  ooh, the luxury of 2-bit naming conventions! :-D

-tkc

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

#62518

Tim Chase wrote:
> Doh, forgot momentarily that the 6502 had X, Y, and A, making THREE
> registers.  ooh, the luxury of 2-bit naming conventions! :-D

Two bits? That's enough to name FOUR registers!
We've been cheated!

-- 
Greg

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

#62495

On 2013-12-21 11:19, Christian Gollwitzer wrote:
> GW-BASIC was a weak language, but two significant characters is 
> definitely too few. I think it was eight. Never used QuickBasic, I
> went Turbo Pascal instead, which had 32 significant characters.

In know that my first BASIC, Applesoft BASIC had the 2-character
names, and you had to load Integer Basic (with Ints in addition to the
standard Floats used in the BASIC provided by the ROM, a strange
choice).  So moving to Turbo Pascal (started with a 3.x series
version, but 6.x was a major upgrade) gave me more breathing-room and
data-types than I know what to do with :-)

Then there's the 6502 assembly on that Apple with its 2 user-facing
registers (plus the Instruction Pointer and Stack Pointer), so I
guess you could say that it has 1-bit variable names ;-)

-tkc

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

#62498

In article <mailman.4472.1387638502.18130.python-list@python.org>,
 Tim Chase <python.list@tim.thechases.com> wrote:

> In know that my first BASIC, Applesoft BASIC had the 2-character
> names, and you had to load Integer Basic (with Ints in addition to the
> standard Floats used in the BASIC provided by the ROM, a strange
> choice).

Why is it a strange choice?  If you're only going to support a single 
type of numeric value, floats make a lot more sense than ints.  Floats 
are a superset of integers.

Javascript, anyone?

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

#62500

On 2013-12-21 10:59, Roy Smith wrote:
> > In know that my first BASIC, Applesoft BASIC had the 2-character
> > names, and you had to load Integer Basic (with Ints in addition
> > to the standard Floats used in the BASIC provided by the ROM, a
> > strange choice).  
> 
> Why is it a strange choice?  If you're only going to support a
> single type of numeric value, floats make a lot more sense than
> ints.  Floats are a superset of integers.
> 
> Javascript, anyone?

It's one thing when JS uses bajillion-bit precision on the floats.
With an 8-bit processor, the accuracy was wanting (according to
Wikipedia[1], single-precision with 8-bit exponent & 31-bit
significand), so you'd often hit cases where INT1 + INT2 *should*
equal INT3
+ INT4, but because of floating-point errors, they wouldn't.  It's
maddening to have the mathematical equivalent of

  2 + 4 != 1 + 5

manifest itself in your programs.  And even harder to explain to a
middle-schooler that I was at the time. :-/

Also, one of the main reasons to choose INTEGER BASIC on the Apple
was that was notably faster, since FP math was managed in software,
rather than in dedicated FP hardware.

-tkc


[1]
http://en.wikipedia.org/wiki/Applesoft_basic#Background

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

#62506

On Sun, Dec 22, 2013 at 2:59 AM, Roy Smith <roy@panix.com> wrote:
> In article <mailman.4472.1387638502.18130.python-list@python.org>,
>  Tim Chase <python.list@tim.thechases.com> wrote:
>
>> In know that my first BASIC, Applesoft BASIC had the 2-character
>> names, and you had to load Integer Basic (with Ints in addition to the
>> standard Floats used in the BASIC provided by the ROM, a strange
>> choice).
>
> Why is it a strange choice?  If you're only going to support a single
> type of numeric value, floats make a lot more sense than ints.  Floats
> are a superset of integers.

No, reals are a superset of integers, and are also a superset of
floats. Whether a float can precisely represent every int in your pool
depends on their relative sizes; in another thread we've just had
complaints about fixed-size integers in C, but they do simplify
discussions like this!

With IEEE floating point, it's theoretically possible to represent any
integer smaller than 2**M, where M is the size of the mantissa
(including its leading 1 bit). In practical terms, that means your
float has to take up twice as much space as an int would (a 64-bit
float has a 53-bit mantissa, so it can represent 32-bit numbers -
nobody actually asks for 53-bit integer support, but you do have it).
I don't know about non-IEEE float systems, but they'll be doing
something similar.

Arbitrary precision throws a whole new spanner in the works. It's
pretty easy to offer an arbitrary-precision integer type that
guarantees accuracy down to the last digit. Offering a float type that
can represent a ridiculous range of integers is problematic. I notice
that Python offers the former and not the latter :) REXX offered
configurable-precision numeric calculations, but performance dropped
off badly as the precision rose. That is to say, it was fine for the
default 9 digits, fine for 100 digits (but now you have to format
numbers for display, or they'll be ugly), starting to get slow if you
asked for 500 digits, and really quite ridiculously slow with NUMERIC
DIGITS 10000.

I wouldn't say that most languages' float type is truly a superset of int.

ChrisA

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

#62520

Tim Chase wrote:
> In know that my first BASIC, Applesoft BASIC had the 2-character
> names, and you had to load Integer Basic (with Ints in addition to the
> standard Floats used in the BASIC provided by the ROM, a strange
> choice).

That's not the way I remember it working. Integer Basic
provided only integers; Applesoft was an alternative ROM
that replaced Integer Basic and provided both float and
int variables.

But I think the only reason to use int variables (ending
with %) in Applesoft was to save memory -- they were
always converted to floats for doing arithmetic. And they
were 16-bit ints, so they had less precision than floats.

-- 
Greg

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

#62517

Christian Gollwitzer wrote:
> GW-BASIC was a weak language, but two significant characters is 
> definitely too few. I think it was eight.

That may have been true for MS-DOS era BASICS. If
you have a whopping 640KB for your program, then
it doesn't matter so much.

The 8-bit era was much more constrained. With only
48KB (or less, depending on how fancy a graphics
mode you wanted to use) people didn't like to use
any more chars than they strictly needed!

-- 
Greg

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

#62497

On 12/21/2013 01:17 AM, Chris Angelico wrote:
> GW-BASIC is what you're describing. Q-BASIC isn't the same as
> QuickBasic, though. Q-BASIC had subs and functions and stuff, but it
> was still, at its heart, BASIC. And you could DIM something with a
> type, but normally it was the adorning suffix that determined type: A$
> is a string, A% is an integer, A! (or A) is float, A# is double.

Yes you could use suffixes if you wanted to on QuickBasic and QBasic.

QBasic actually was the same language as QuickBasic, just that it was an
interpreter only, not a compiler.  The language itself was identical (to
ver 4.5 if I recall correctly).  If you want a trip down memory lane,
download qb64[1] for your chosen platform and have fun.  qb64 is
actually a full-blown compiler that implements almost all of the
QuickBasic/QBasic language with an integrated IDE that is a
re-implementation of the good old DOS one that was in QBasic and QuickBasic.

[1] http://qb64.net

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

#62521

Michael Torrie wrote:
> And you could DIM something with a
>>type, but normally it was the adorning suffix that determined type: A$
>>is a string, A% is an integer, A! (or A) is float, A# is double.

Some versions of 8-bit Microsoft Basic also had a way of
overriding the default type for a range of names.
So, for example, Fortran programmers could DEFINT I-N
and feel right at home.

I guess that means it would occupy a zero-crossing on
the sigil oscillation curve -- you could have it either
way.

-- 
Greg

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

#62466

On 20/12/2013 14:19, Roy Smith wrote:
> http://xkcd.com/1306/
>

I believe that to be a very superficial like.  They're unlike in that 
once C++ people have compiled their code they can head down to the pub, 
but Python people have to stay at work testing because the compiler 
hasn't caught all potential errors.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

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

#62475

Mark Lawrence wrote:
> On 20/12/2013 14:19, Roy Smith wrote:
> 
>> http://xkcd.com/1306/
>>
> 
> I believe that to be a very superficial like.  They're unlike in that 
> once C++ people have compiled their code they can head down to the pub, 
> but Python people have to stay at work testing because the compiler 
> hasn't caught all potential errors.

But it takes so much longer for the C++ people to
write their program in the first place, that the
Python people often get to the pub first anyway.
And even if they don't get to the pub at all, they
enjoy what they're doing so much that they don't
care.

-- 
Greg

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

#62477

On 21/12/2013 08:09, Gregory Ewing wrote:
> Mark Lawrence wrote:
>> On 20/12/2013 14:19, Roy Smith wrote:
>>
>>> http://xkcd.com/1306/
>>>
>>
>> I believe that to be a very superficial like.  They're unlike in that
>> once C++ people have compiled their code they can head down to the
>> pub, but Python people have to stay at work testing because the
>> compiler hasn't caught all potential errors.
>
> But it takes so much longer for the C++ people to
> write their program in the first place, that the
> Python people often get to the pub first anyway.
> And even if they don't get to the pub at all, they
> enjoy what they're doing so much that they don't
> care.
>

Having thought about this for all of 2ns I've come to the startling 
conclusion that I entirely agree with you.  I'm very biased though, 
suffering extremely badly from both C++phobia and Javaphobia.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web