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

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

Re: Python handles globals badly.

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Python handles globals badly. tdev@freenet.de - 2015-09-02 11:47 -0700
    Re: Python handles globals badly. tdev@freenet.de - 2015-09-02 12:32 -0700
    Re: Python handles globals badly. Emile van Sebille <emile@fenx.com> - 2015-09-02 12:34 -0700
    Re: Python handles globals badly. Ian Kelly <ian.g.kelly@gmail.com> - 2015-09-02 13:38 -0600
    Re: Python handles globals badly. "Sven R. Kunze" <srkunze@mail.de> - 2015-09-02 22:08 +0200
    Re: Python handles globals badly. MRAB <python@mrabarnett.plus.com> - 2015-09-02 21:22 +0100
    Re: Python handles globals badly. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-02 22:19 +0100
    Re: Python handles globals badly. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-03 02:16 +0100
    Re: Python handles globals badly. Steven D'Aprano <steve@pearwood.info> - 2015-09-03 11:49 +1000
    Re: Python handles globals badly. Vladimir Ignatov <kmisoft@gmail.com> - 2015-09-04 20:05 -0400
    Re: Python handles globals badly. Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-09-08 10:40 +0200
    Re: Python handles globals badly. Vladimir Ignatov <kmisoft@gmail.com> - 2015-09-08 07:55 -0400
    Re: Python handles globals badly. Akira Li <4kir4.1i@gmail.com> - 2015-09-08 15:35 +0300
    Re: Python handles globals badly. Mario Figueiredo <marfig@gmx.com> - 2015-09-08 14:05 +0100
    Re: Python handles globals badly. Ian Kelly <ian.g.kelly@gmail.com> - 2015-09-08 08:31 -0600
      Re: Python handles globals badly. Steven D'Aprano <steve@pearwood.info> - 2015-09-09 01:56 +1000
        Re: Python handles globals badly. Michael Torrie <torriem@gmail.com> - 2015-09-08 17:55 -0600
          Re: Python handles globals badly. Steven D'Aprano <steve@pearwood.info> - 2015-09-09 13:23 +1000
            Re: Python handles globals badly. Christian Gollwitzer <auriocus@gmx.de> - 2015-09-09 18:09 +0200
              Re: Python handles globals badly. Steven D'Aprano <steve@pearwood.info> - 2015-09-10 03:22 +1000
                Re: Python handles globals badly. Chris Angelico <rosuav@gmail.com> - 2015-09-10 03:27 +1000
                Re: Python handles globals badly. William Ray Wing <wrw@mac.com> - 2015-09-09 13:59 -0400
                Re: Python handles globals badly. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-09 20:20 +0100
                  Re: Python handles globals badly. Peter Pearson <pkpearson@nowhere.invalid> - 2015-09-10 20:49 +0000
                Re: Python handles globals badly. MRAB <python@mrabarnett.plus.com> - 2015-09-09 20:22 +0100
                Re: Python handles globals badly. Chris Angelico <rosuav@gmail.com> - 2015-09-10 05:27 +1000
        Re: Python handles globals badly. Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-09-09 12:42 +0200
        Re: Python handles globals badly. Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-09-09 09:33 -0400
    Re: Python handles globals badly. random832@fastmail.us - 2015-09-08 12:13 -0400
    Re: Python handles globals badly. MRAB <python@mrabarnett.plus.com> - 2015-09-08 18:41 +0100
    Re: Python handles globals badly. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-08 23:41 +0100
    Re: Python handles globals badly. MRAB <python@mrabarnett.plus.com> - 2015-09-09 00:20 +0100
    Re: Python handles globals badly. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-09 00:32 +0100
    Re: Python handles globals badly. Random832 <random832@fastmail.com> - 2015-09-08 20:02 -0400
      Re: Python handles globals badly. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-09-11 10:23 +0200
    Re: Python handles globals badly. Mario Figueiredo <marfig@gmx.com> - 2015-09-09 02:09 +0100
      Re: Python handles globals badly. Steven D'Aprano <steve@pearwood.info> - 2015-09-10 03:55 +1000
        Re: Python handles globals badly. Laura Creighton <lac@openend.se> - 2015-09-09 20:05 +0200
        Re: Python handles globals badly. Emile van Sebille <emile@fenx.com> - 2015-09-09 11:23 -0700
          Re: Python handles globals badly. Steven D'Aprano <steve@pearwood.info> - 2015-09-10 22:20 +1000
        Re: Python handles globals badly. "Sven R. Kunze" <srkunze@mail.de> - 2015-09-09 20:26 +0200
          Re: Python handles globals badly. Steven D'Aprano <steve@pearwood.info> - 2015-09-11 01:50 +1000
        Re: Python handles globals badly. random832@fastmail.us - 2015-09-09 14:59 -0400
          Re: Python handles globals badly. Steven D'Aprano <steve@pearwood.info> - 2015-09-11 01:59 +1000
            Re: Python handles globals badly. random832@fastmail.us - 2015-09-10 12:31 -0400
              Re: Python handles globals badly. Steven D'Aprano <steve@pearwood.info> - 2015-09-11 04:13 +1000
                Re: Python handles globals badly. Chris Angelico <rosuav@gmail.com> - 2015-09-11 04:33 +1000
                Re: Python handles globals badly. Jussi Piitulainen <harvesting@makes.email.invalid> - 2015-09-10 22:11 +0300
                Re: Python handles globals badly. random832@fastmail.us - 2015-09-10 16:30 -0400
            Re: Python handles globals badly. Chris Angelico <rosuav@gmail.com> - 2015-09-11 02:48 +1000
            Re: Python handles globals badly. alister <alister.nospam.ware@ntlworld.com> - 2015-09-10 19:56 +0000
            Re: Python handles globals badly. random832@fastmail.us - 2015-09-10 16:07 -0400
            Re: Python handles globals badly. Chris Angelico <rosuav@gmail.com> - 2015-09-11 11:35 +1000
            Re: Python handles globals badly. Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-09-11 12:19 +0200
              Re: Python handles globals badly. Marko Rauhamaa <marko@pacujo.net> - 2015-09-11 14:59 +0300
                Re: Python handles globals badly. Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-09-14 09:13 +0200
        Re: Python handles globals badly. Chris Angelico <rosuav@gmail.com> - 2015-09-10 05:00 +1000
        Re: Python handles globals badly. Laura Creighton <lac@openend.se> - 2015-09-09 21:14 +0200
        Re: Python handles globals badly. Chris Angelico <rosuav@gmail.com> - 2015-09-10 05:18 +1000
          Re: Python handles globals badly. Steven D'Aprano <steve@pearwood.info> - 2015-09-10 22:18 +1000
            Re: Python handles globals badly. jkn <jkn_gg@nicorp.f9.co.uk> - 2015-09-10 08:09 -0700
            Re: Python handles globals badly. rurpy@yahoo.com - 2015-09-10 12:04 -0700
              Re: Python handles globals badly. Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-09-10 20:33 -0400
              Re: Python handles globals badly. Gene Heskett <gheskett@wdtv.com> - 2015-09-10 22:19 -0400
              Re: Python handles globals badly. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-12 03:35 +0100
              Re: Python handles globals badly. Mario Figueiredo <marfig@gmx.com> - 2015-09-12 05:11 +0100
              Re: Python handles globals badly. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-12 05:38 +0100
              Re: Python handles globals badly. Mario Figueiredo <marfig@gmx.com> - 2015-09-12 16:52 +0100
              Re: Python handles globals badly. Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-09-12 12:24 -0400
              Re: Python handles globals badly. Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-09-12 12:29 -0400
              Re: Python handles globals badly. MRAB <python@mrabarnett.plus.com> - 2015-09-12 18:09 +0100
              Re: Python handles globals badly. Mario Figueiredo <marfig@gmx.com> - 2015-09-12 22:57 +0100
              Re: Python handles globals badly. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-12 23:05 +0100
              Re: Python handles globals badly. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-12 23:07 +0100
        Re: Python handles globals badly. "Sven R. Kunze" <srkunze@mail.de> - 2015-09-09 21:21 +0200
        Re: Python handles globals badly. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-09 20:24 +0100
        Re: Python handles globals badly. Mario Figueiredo <marfig@gmx.com> - 2015-09-09 20:57 +0100
        Re: Python handles globals badly. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-09 21:15 +0100
        Re: Python handles globals badly. Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-09-10 09:27 +0200
          Re: Python handles globals badly. Marko Rauhamaa <marko@pacujo.net> - 2015-09-10 10:49 +0300
        Re: Python handles globals badly. Michael Torrie <torriem@gmail.com> - 2015-09-10 08:21 -0600
        Re: Python handles globals badly. Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-09-11 09:28 +0200
          Re: Python handles globals badly. Steven D'Aprano <steve@pearwood.info> - 2015-09-12 13:48 +1000
            Re: Python handles globals badly. Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-09-14 10:30 +0200
              Re: Python handles globals badly. Steven D'Aprano <steve@pearwood.info> - 2015-09-16 11:13 +1000
                Re: Python handles globals badly. Steven D'Aprano <steve@pearwood.info> - 2015-09-16 11:20 +1000
                  Re: Python handles globals badly. Chris Angelico <rosuav@gmail.com> - 2015-09-16 11:58 +1000
                Re: Python handles globals badly. Random832 <random832@fastmail.com> - 2015-09-15 21:54 -0400
                Re: Python handles globals badly. Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-09-16 10:51 +0200
        Re: Python handles globals badly. random832@fastmail.us - 2015-09-11 08:50 -0400
    Re: Python handles globals badly. Ben Finney <ben+python@benfinney.id.au> - 2015-09-09 11:26 +1000
    Re: Python handles globals badly. Chris Angelico <rosuav@gmail.com> - 2015-09-09 11:41 +1000
    Re: Python handles globals badly. Mario Figueiredo <marfig@gmx.com> - 2015-09-09 03:43 +0100
    Re: Python handles globals badly. Chris Angelico <rosuav@gmail.com> - 2015-09-09 13:03 +1000
    Re: Python handles globals badly. Ben Finney <ben+python@benfinney.id.au> - 2015-09-09 15:53 +1000

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#96263

On Thursday, 10 September 2015 13:18:39 UTC+1, Steven D'Aprano  wrote:
> On Thu, 10 Sep 2015 05:18 am, Chris Angelico wrote:
> 
> > On Thu, Sep 10, 2015 at 5:14 AM, Laura Creighton <lac@openend.se> wrote:
> >> In a message of Thu, 10 Sep 2015 05:00:22 +1000, Chris Angelico writes:
> >>>To get started, you need some other sort of kick.
> >>
> >> Having Brian Kernighan write a really nice book about you, helps a lot.
> > 
> > It kinda does. And of course, it also helps to have a time machine, so
> > you can launch your language when there are less languages around.
> > Today, you compete for attention with myriad languages that simply
> > didn't exist when C was introduced to an unsuspecting world.
> 
> I don't think that's quite right. I think, if anything, there were more
> languages in the 1970s than now, it's just that they tended to be
> proprietary, maybe only running on a single vendor's machine. But even if
> I'm mistaken, I think that there is near-universal agreement that the
> single biggest factor in C's popularity and growth during the 1970s and 80s
> is that it was tied so intimately to Unix, and Unix was taking over from
> mainframes, VAX, etc.
> 
> 
> 
> -- 
> Steven

In 'The Design and Evolution of C++', Bjarne Stroustrup writes about a principle that was applied to C with classes (an early embodiment of C++):

"C with Classes has to be a weed like C or Fortran because we cannot afford to
take care of a rose like Algol68 or Simula. If we deliver an implementation and
go away for a year, we want to find several systems running when we come back.
That will not happen if complicated maintenance is needed or if a simple port
to a new machine takes longer than a week". (pp. 37)

I think the 'C is a weed' observation one is a good one to explain the
proliferation. I say this as a good thing, and as a programmer in C, C++ and Python.

    Jon N

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

#96289

On Thursday, September 10, 2015 at 6:18:39 AM UTC-6, Steven D'Aprano wrote:
> On Thu, 10 Sep 2015 05:18 am, Chris Angelico wrote:
> > On Thu, Sep 10, 2015 at 5:14 AM, Laura Creighton <lac@openend.se> wrote:
> >> In a message of Thu, 10 Sep 2015 05:00:22 +1000, Chris Angelico writes:
> >>>To get started, you need some other sort of kick.
> >>
> >> Having Brian Kernighan write a really nice book about you, helps a lot.
> > 
> > It kinda does. And of course, it also helps to have a time machine, so
> > you can launch your language when there are less languages around.
> > Today, you compete for attention with myriad languages that simply
> > didn't exist when C was introduced to an unsuspecting world.
> 
> I don't think that's quite right. I think, if anything, there were more
> languages in the 1970s than now, it's just that they tended to be
> proprietary, maybe only running on a single vendor's machine. But even if
> I'm mistaken, I think that there is near-universal agreement that the
> single biggest factor in C's popularity and growth during the 1970s and 80s
> is that it was tied so intimately to Unix, and Unix was taking over from
> mainframes, VAX, etc.

The growth of C and Unix were mutually interdependent, one was not 
the cause of the other.

A big factor in the growth of Unix was that it was portable to 
new hardware relatively easily, a portability made possible by C.

I note that even today, 3 or 4 decades later, the availability of 
Python on a wide variety of platforms is made possible by C.

I also doubt there were more programming languages around in the
1970s than now, on the grounds that there were far fewer people
capable of writing a compiler or interpreter in those days, and 
there were far fewer tools to help, or easily accessible knowledge 
about how to do do it.

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

#96307

On Thu, 10 Sep 2015 12:04:05 -0700 (PDT), rurpy--- via Python-list
<python-list@python.org> declaimed the following:

>I also doubt there were more programming languages around in the
>1970s than now, on the grounds that there were far fewer people
>capable of writing a compiler or interpreter in those days, and 
>there were far fewer tools to help, or easily accessible knowledge 
>about how to do do it.

	Yet there were enough assorted semi-specialized languages in use on
military programs to induce the DoD to run the competition for a singular
language -- which became Ada.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#96314

On Thursday 10 September 2015 20:33:03 Dennis Lee Bieber wrote:

> On Thu, 10 Sep 2015 12:04:05 -0700 (PDT), rurpy--- via Python-list
>
> <python-list@python.org> declaimed the following:
> >I also doubt there were more programming languages around in the
> >1970s than now, on the grounds that there were far fewer people
> >capable of writing a compiler or interpreter in those days, and
> >there were far fewer tools to help, or easily accessible knowledge
> >about how to do do it.
>
> 	Yet there were enough assorted semi-specialized languages in use on
> military programs to induce the DoD to run the competition for a
> singular language -- which became Ada.

And which should be noted that it has been a rather spectacular failure 
in the commercial market.  Does that mean that those who can code in Ada 
are working only for the military's suppliers, and because they are a 
scarce commodity, writing their own paycheck? I don't know, other than 
no one is publically bragging about it.

> --
> 	Wulfraed                 Dennis Lee Bieber         AF6VN
>     wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

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

#96382

On 11/09/2015 03:19, Gene Heskett wrote:
> On Thursday 10 September 2015 20:33:03 Dennis Lee Bieber wrote:
>
>> On Thu, 10 Sep 2015 12:04:05 -0700 (PDT), rurpy--- via Python-list
>>
>> <python-list@python.org> declaimed the following:
>>> I also doubt there were more programming languages around in the
>>> 1970s than now, on the grounds that there were far fewer people
>>> capable of writing a compiler or interpreter in those days, and
>>> there were far fewer tools to help, or easily accessible knowledge
>>> about how to do do it.
>>
>> 	Yet there were enough assorted semi-specialized languages in use on
>> military programs to induce the DoD to run the competition for a
>> singular language -- which became Ada.
>
> And which should be noted that it has been a rather spectacular failure
> in the commercial market.  Does that mean that those who can code in Ada
> are working only for the military's suppliers, and because they are a
> scarce commodity, writing their own paycheck? I don't know, other than
> no one is publically bragging about it.
>
>> --
>> 	Wulfraed                 Dennis Lee Bieber         AF6VN
>>      wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/
>
>
> Cheers, Gene Heskett
>

Ada took over from CORAL in the UK, at least in military projects.  It 
was also used in the aircraft industry. My old work mates tell me that 
its completely died a death, to be replaced by C++.  Someone please 
remind me never to fly again.

-- 
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]

#96391

On 12-09-2015 03:35, Mark Lawrence wrote:
>
> Ada took over from CORAL in the UK, at least in military projects.  It
> was also used in the aircraft industry. My old work mates tell me that
> its completely died a death, to be replaced by C++.  Someone please
> remind me never to fly again.

Alright. But then someone should probably have reminded you that a long
time ago.

Maybe you missed it when an Ada integer overflow bug produced one of the
most expensive software bugs in history by crashing the Ariane 501
rocket and its 4 cluster sattelites payload.

But sure. Don't let that get in your way of thinking there are safe
languages.

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

#96396

On 12/09/2015 05:11, Mario Figueiredo wrote:
> On 12-09-2015 03:35, Mark Lawrence wrote:
>>
>> Ada took over from CORAL in the UK, at least in military projects.  It
>> was also used in the aircraft industry. My old work mates tell me that
>> its completely died a death, to be replaced by C++.  Someone please
>> remind me never to fly again.
>
> Alright. But then someone should probably have reminded you that a long
> time ago.
>
> Maybe you missed it when an Ada integer overflow bug produced one of the
> most expensive software bugs in history by crashing the Ariane 501
> rocket and its 4 cluster sattelites payload.
>
> But sure. Don't let that get in your way of thinking there are safe
> languages.
>

Nothing to do with this being untested software then?  Actually it was 
so I'd put that down to a programmer error.  "The code always worked 
before so it's bound to work this time".  Such a pity that this 
particular launch wasn't the same as anything done previously.

-- 
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]

#96424

On 12-09-2015 05:38, Mark Lawrence wrote:
> 
> Nothing to do with this being untested software then?  Actually it was
> so I'd put that down to a programmer error.  "The code always worked
> before so it's bound to work this time".  Such a pity that this
> particular launch wasn't the same as anything done previously.

I am not even sure what you are saying. Can't be that C++ bugs are not
not caused by programmer errors. Because C++ is actually used in
numerous mission critical systems.

But anyways. If you are that scared of C++ it is indeed best you don't fly.

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

#96427

On Sat, 12 Sep 2015 03:35:00 +0100, Mark Lawrence <breamoreboy@yahoo.co.uk>
declaimed the following:

>
>Ada took over from CORAL in the UK, at least in military projects.  It 
>was also used in the aircraft industry. My old work mates tell me that 
>its completely died a death, to be replaced by C++.  Someone please 
>remind me never to fly again.

	Still used on some of the boxes being made... (I've just spent a month
investigating problem reports for a software release).

	Granted, that's an Ada 83 cross compiler running on VAX/VMS itself
running on a Windows server box with an emulator. It would cost way too
much money to try to recompile with, say, GNAT Pro -- as the entire suite
(including the compiler) would have to be recertified for airworthiness.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#96428

On Sat, 12 Sep 2015 05:11:46 +0100, Mario Figueiredo <marfig@gmx.com>
declaimed the following:

>On 12-09-2015 03:35, Mark Lawrence wrote:
>>
>> Ada took over from CORAL in the UK, at least in military projects.  It
>> was also used in the aircraft industry. My old work mates tell me that
>> its completely died a death, to be replaced by C++.  Someone please
>> remind me never to fly again.
>
>Alright. But then someone should probably have reminded you that a long
>time ago.
>
>Maybe you missed it when an Ada integer overflow bug produced one of the
>most expensive software bugs in history by crashing the Ariane 501
>rocket and its 4 cluster sattelites payload.
>

	As I recall, the software did exactly what it was supposed to do in
that situation...

	But no one had tested the algorithm with the rate of change the Ariane
5 could produce -- so an algorithm that was developed for, and safe with,
the smaller Ariane suddenly went "something's wrong -- abandon ship"

	Nothing inherent in the language...
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#96435

On 2015-09-12 17:29, Dennis Lee Bieber wrote:
> On Sat, 12 Sep 2015 05:11:46 +0100, Mario Figueiredo <marfig@gmx.com>
> declaimed the following:
>
>>On 12-09-2015 03:35, Mark Lawrence wrote:
>>>
>>> Ada took over from CORAL in the UK, at least in military projects.  It
>>> was also used in the aircraft industry. My old work mates tell me that
>>> its completely died a death, to be replaced by C++.  Someone please
>>> remind me never to fly again.
>>
>>Alright. But then someone should probably have reminded you that a long
>>time ago.
>>
>>Maybe you missed it when an Ada integer overflow bug produced one of the
>>most expensive software bugs in history by crashing the Ariane 501
>>rocket and its 4 cluster sattelites payload.
>>
>
> 	As I recall, the software did exactly what it was supposed to do in
> that situation...
>
> 	But no one had tested the algorithm with the rate of change the Ariane
> 5 could produce -- so an algorithm that was developed for, and safe with,
> the smaller Ariane suddenly went "something's wrong -- abandon ship"
>
> 	Nothing inherent in the language...
>
What would C++ have done in the same situation? Would Ariane still have
failed? Probably...

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

#96462

On 12-09-2015 18:09, MRAB wrote:
> On 2015-09-12 17:29, Dennis Lee Bieber wrote:
>>     But no one had tested the algorithm with the rate of change the
>> Ariane
>> 5 could produce -- so an algorithm that was developed for, and safe with,
>> the smaller Ariane suddenly went "something's wrong -- abandon ship"
>>
>>     Nothing inherent in the language...
>>
> What would C++ have done in the same situation? Would Ariane still have
> failed? Probably...
> 

And that's exactly the point. C++, or Ada, for that matter have decades
old documented best practices and code patterns to deal with those
aspects of the language that can induce in error. Integer overflow is a
well documented problem. And relying on it, is documented as a bad idea
for several reasons, including the changes in the underlying system that
eventually led to Ariane incident.

For all that is worth, C++ issues with all sorts of overflows and
unchecked memory are documented from the very first beginning of the
language. Same with C and same with Ada own particular issues.

A safe(r) language just presents different ways of shooting one's foot.
We can discuss how much of a bad boy C++ is, but at the end of the day
programers will just keep on make mistakes and eventually on those very
areas the safer language doesn't provide a safety net.

One can argue that by offering more ways to shoot one's foot, C and C++
are more dangerous to use than other considered safer languages. But
that doesn't gel with the operative history of C or C++ that are running
mission critical systems, from stock markets to nuclear power plants.
These languages just demand a different breed of programmers and
different methods of testing.

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

#96463

On 12/09/2015 17:29, Dennis Lee Bieber wrote:
> On Sat, 12 Sep 2015 05:11:46 +0100, Mario Figueiredo <marfig@gmx.com>
> declaimed the following:
>
>> On 12-09-2015 03:35, Mark Lawrence wrote:
>>>
>>> Ada took over from CORAL in the UK, at least in military projects.  It
>>> was also used in the aircraft industry. My old work mates tell me that
>>> its completely died a death, to be replaced by C++.  Someone please
>>> remind me never to fly again.
>>
>> Alright. But then someone should probably have reminded you that a long
>> time ago.
>>
>> Maybe you missed it when an Ada integer overflow bug produced one of the
>> most expensive software bugs in history by crashing the Ariane 501
>> rocket and its 4 cluster sattelites payload.
>>
>
> 	As I recall, the software did exactly what it was supposed to do in
> that situation...
>
> 	But no one had tested the algorithm with the rate of change the Ariane
> 5 could produce -- so an algorithm that was developed for, and safe with,
> the smaller Ariane suddenly went "something's wrong -- abandon ship"
>
> 	Nothing inherent in the language...
>

Well if the backup system that took over when the primary system gave up 
the ghost had used a different algorithm, and had been tested for an 
appropriate range of inputs, we wouldn't be having this discussion.  It 
didn't.  The rest is history, and very expensive history at that.

-- 
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]

#96464

On 12/09/2015 17:24, Dennis Lee Bieber wrote:
> On Sat, 12 Sep 2015 03:35:00 +0100, Mark Lawrence <breamoreboy@yahoo.co.uk>
> declaimed the following:
>
>>
>> Ada took over from CORAL in the UK, at least in military projects.  It
>> was also used in the aircraft industry. My old work mates tell me that
>> its completely died a death, to be replaced by C++.  Someone please
>> remind me never to fly again.
>
> 	Still used on some of the boxes being made... (I've just spent a month
> investigating problem reports for a software release).
>
> 	Granted, that's an Ada 83 cross compiler running on VAX/VMS itself
> running on a Windows server box with an emulator. It would cost way too
> much money to try to recompile with, say, GNAT Pro -- as the entire suite
> (including the compiler) would have to be recertified for airworthiness.
>

Having seen the comments on this thread I think some of the participants 
need to be recertified for programmerworthiness.

-- 
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]

#96213

On 09.09.2015 21:00, Chris Angelico wrote:
> Suppose it's possible, somehow, to design the perfect language. (It
> isn't, because the best language for a job depends on the job, but
> suppose it for the nonce.) It is simultaneously more readable than
> Python, more ugly than Perl, more functional than Haskell, and
> compiles to lower level code than C does. The compiler's/interpreter's
> internals are a bug-free demonstration of utter code beauty, and you
> no longer have reason to use any other programming language, because
> this one is the ultimate.

That sounds boring, right? ;)

Best,
Sven

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

#96217

On 09/09/2015 20:14, Laura Creighton wrote:
> In a message of Thu, 10 Sep 2015 05:00:22 +1000, Chris Angelico writes:
>> To get started, you need some other sort of kick.
>
> Having Brian Kernighan write a really nice book about you, helps a lot.
>
> Laura
>

Who?  Did he play left wing or right wing for City?  Or was it United?

-- 
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]

#96218

On 09-09-2015 18:55, Steven D'Aprano wrote:
> On Wed, 9 Sep 2015 11:09 am, Mario Figueiredo wrote:
> 
>> You know, it is a pointless exercise to try and downplay programming
>> languages (any programming language) that has proven its worth by being
>> generally adopted by the programming community. Adoption is the sign of
>> a respected and well designed language.
> 
> Counter-examples: PHP and C.
> 
> Adoption of programming languages is driven by many things, technical
> excellence and careful design are not even in the top 10. Most of them are
> social in nature, particularly "what is everyone else using?". Network
> effects dominate: you could design the perfect language, but if nobody else
> uses it, nobody will use it.

You paint a dim picture of the computer science ecosystem. You almost
make it look like we are a bunch of fashionists. There is some truth to
what you are saying, but not to the level you are implying. "Technical
excellence not being on the top 10" is just a blanket statement that
does not address the constant search for better programming languages.

The fact is that you, I and a large representative number of software
engineers are always on the constant lookout for better designed
languages. And it's people like us that eventually ensure the success of
a programming language based on its merits. It's the software
engineering "society" that eventually promotes a programming language
out of obscurity and into popular use. And this can only happen if that
language holds enough merits. We may have been experiencing a rise in
programming languages protected by commercial interests, but so far they
still obey this simple truth.

That speech that languages are popularity contests is just a superficial
view of the whole of the industry and frankly very much untrue.

> Sometimes a language will actually gain a kind of technical excellence
> despite some really shitty design decisions -- but usually at great cost
> elsewhere. C is a good example of that. Due to lousy decisions made by the
> designers of C, it is a language really well suited for writing fast,
> incorrect code.

Right. There we go. Another, C is a badly designed language...
If I had a penny for every time I heard this, I could then wish for a
penny for every other program or computer language that was designed in
C. I would be twice as rich.

Almost all of the modern programming edifice sits on top of C on one way
or another. Our operating systems, many of our most mission critical
system, even many of our high level programming languages, including the
one represented on these forums. But somehow, there is always someone
trying to sell that C is a lousy designed programming language. At this
point in history, I couldn't blame C anymore. If it is such a lousy job,
then the real problem must be with the people that kept on truckin' it
around. That includes the whole of the computer science industry.

And that just doesn't make sense. Your programming language based on
lousy decisions, proved instead that those those lousy decisions around
lack of security are necessary when you need to create a systems
programming language that can eventually carry on its shoulders the
weight of an entire industry.

Maybe Rust will finally be able to prove that you can do better. That it
is actually possible to create a close-to-the-metal programming language
with security in mind and as performant as C. But if it does succeed
(and I'd like for it to succeed, make no mistake), it took us over 40
years to actually come up with something.


> In fairness to the C creators, I'm sure that nobody back in the early
> seventies imagined that malware and security vulnerabilities would be as
> widespread as they have become.

Of course they did. The Design of C states this on several occasions,
while The C Programming Language is full of mentions to the security
concerns in some of the programming language semantics. Meanwhile the
patterns and best practices for secure C code are known for decades,
well before the widespread use of computers and the internet itself.

> I believe that the computing industry may never recover from the harm done
> to it by the widespread use of C.

Yes. It's been a terrible 4 decades of technological innovation.

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

#96220

On 09/09/2015 20:57, Mario Figueiredo wrote:
> On 09-09-2015 18:55, Steven D'Aprano wrote:
>> On Wed, 9 Sep 2015 11:09 am, Mario Figueiredo wrote:
>>
>>> You know, it is a pointless exercise to try and downplay programming
>>> languages (any programming language) that has proven its worth by being
>>> generally adopted by the programming community. Adoption is the sign of
>>> a respected and well designed language.
>>
>> Counter-examples: PHP and C.
>>
>> Adoption of programming languages is driven by many things, technical
>> excellence and careful design are not even in the top 10. Most of them are
>> social in nature, particularly "what is everyone else using?". Network
>> effects dominate: you could design the perfect language, but if nobody else
>> uses it, nobody will use it.
>
> You paint a dim picture of the computer science ecosystem. You almost
> make it look like we are a bunch of fashionists. There is some truth to
> what you are saying, but not to the level you are implying. "Technical
> excellence not being on the top 10" is just a blanket statement that
> does not address the constant search for better programming languages.
>

If the designers of languages spent more time considering business 
benefits rather than better languages, then I believe we'd end up with 
better languages.  However that depends on your (plural) definition of 
"better".

-- 
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]

#96248

Op 09-09-15 om 19:55 schreef Steven D'Aprano:
> In fairness to the C creators, I'm sure that nobody back in the early
> seventies imagined that malware and security vulnerabilities would be as
> widespread as they have become. But still, the fundamental decisions made
> by C are lousy. Assignment is an expression?

What is wrong with that?

-- 
Antoon Pardon

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

#96250

Antoon Pardon <antoon.pardon@rece.vub.ac.be>:

> Op 09-09-15 om 19:55 schreef Steven D'Aprano:
>> In fairness to the C creators, I'm sure that nobody back in the early
>> seventies imagined that malware and security vulnerabilities would be
>> as widespread as they have become. But still, the fundamental
>> decisions made by C are lousy. Assignment is an expression?
>
> What is wrong with that?

C is an extremely strong language. However, I also think they made some
slightly regrettable choices, some of which later standards have
alleviated. One of my main issues with C has been the intentional
confusion between arrays and pointers. Also, the type notation is
clearly inferior to that of Pascal.

The greatest blessing C has bestowed upon programmers is the void
pointer. While C++ programmers (among others) have built a ridiculous
cathedral (templates) to capture the same universal notion, C
programmers just shrug their shoulders and store the reference in a void
pointer variable.


Marko

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

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

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

csiph-web