Re: Why did no one invent Python before?

Discussion in 'Python' started by Michael Sparks, Jun 4, 2004.

  1. On 2 Jun 2004, j_mckitrick wrote:
    ....
    > Yes, it's a silly question, but given how far we have come, why is it
    > that a natural looking, easy to read, incredibly powerful language has
    > appeared only recently, from a tech standpoint?
    >
    > I can't *believe* how much more productive I am with the built in data
    > types and powerful expressions Python offers. It made me want to quit
    > my C++ job. Well, not quite. ;-)
    >
    > Seriously, why is a language like this only NOW appearing? And aside
    > from the interpreter, because while it is nice, it's not the main
    > forte' of the language, IMHO.


    Around 10 years ago I was using a language called Amiga E. After
    programming with python for about a week, I realised why it felt
    comfortable - Amiga E felt pretty much the same to program in. Key
    differences were amiga specific (but the amiga was still alive, just,
    then), compiled rather than interpreted (but compiled blazingly fast for
    the tim), and not using whitespace for block structure.

    People constantly invent new things, and sometimes they fly, and sometimes
    they don't. It's probable the reason why python, perl, etc are flying now
    is because the processing power is sufficient to make them practical now.

    For example, if running your test suite takes 20 minutes now, on a dual
    3Ghz machine then 10-15 years ago you're talking 20,000 minutes to run the
    same tests on a 7Mhz machine of the time. ie approximately a month.

    So 10-15 years ago, some modern styles of programming simply were not
    practical.

    Taking that same jump to extremes, *if* CPU cycle availability continues
    to scale for the next 10-15 years, the same tests would take around 1.2
    seconds, meaning the entire test suite _might_be possible to run during
    program startup. At that point new languages and programming techniques
    might become _practical_ which aren't practical today.

    At that point, someone might come along and say "I can't believe how much
    more productive I am with the built in runtime system diagnostic testing,
    and automated algorithm anealling that Foobarr offers. It made me want to
    quit my Python job. Well, not quite. ;-)".

    ;-)

    More seriously, for a different perspective, read http://tinyurl.com/2kbse
    for similar comments on Babbage's machines and similar.


    Michael.
    Michael Sparks, Jun 4, 2004
    #1
    1. Advertising

  2. Michael Sparks <> wrote in message news:<>...

    > Taking that same jump to extremes, *if* CPU cycle availability continues
    > to scale for the next 10-15 years, the same tests would take around 1.2
    > seconds, meaning the entire test suite _might_be possible to run during
    > program startup. At that point new languages and programming techniques
    > might become _practical_ which aren't practical today.
    >
    > At that point, someone might come along and say "I can't believe how much
    > more productive I am with the built in runtime system diagnostic testing,
    > and automated algorithm anealling that Foobarr offers. It made me want to
    > quit my Python job. Well, not quite. ;-)".


    That already happened: the language is called Eiffel.

    Checking all pre- and postconditions and invariants on each call was
    terrible slow when i started my project with a PIV 400 MHz. It was
    mostly impossible to use on normal size data sets. Now i use a PIV
    2800 and give away my product (http://www.ruby-ide.com :) with all
    runtime checks enabled. This makes my programming style much much
    better.
    Lothar Scholz, Jun 4, 2004
    #2
    1. Advertising

  3. Michael Sparks

    j_mckitrick Guest

    > That already happened: the language is called Eiffel.
    >
    > Checking all pre- and postconditions and invariants on each call was
    > terrible slow when i started my project with a PIV 400 MHz. It was
    > mostly impossible to use on normal size data sets. Now i use a PIV
    > 2800 and give away my product (http://www.ruby-ide.com :) with all
    > runtime checks enabled. This makes my programming style much much
    > better.


    So you wrote a ruby IDE in Eiffel?

    Which language do you prefer, then?
    j_mckitrick, Jun 4, 2004
    #3
  4. (j_mckitrick) wrote in message news:<>...
    > > That already happened: the language is called Eiffel.
    > >
    > > Checking all pre- and postconditions and invariants on each call was
    > > terrible slow when i started my project with a PIV 400 MHz. It was
    > > mostly impossible to use on normal size data sets. Now i use a PIV
    > > 2800 and give away my product (http://www.ruby-ide.com :) with all
    > > runtime checks enabled. This makes my programming style much much
    > > better.

    >
    > So you wrote a ruby IDE in Eiffel?
    >
    > Which language do you prefer, then?


    I prefer to use the right language for each job.
    Lothar Scholz, Jun 5, 2004
    #4
  5. (Lothar Scholz) writes:

    > I prefer to use the right language for each job.


    Careful: With so many languages being written these days, someone are
    bound to name their language "Right" simply because all the other
    words are taken. :)
    Tor Iver Wilhelmsen, Jun 6, 2004
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. j_mckitrick

    Why did no one invent Python before?

    j_mckitrick, Jun 2, 2004, in forum: Python
    Replies:
    42
    Views:
    960
    Mel Wilson
    Jun 6, 2004
  2. Mr. SweatyFinger
    Replies:
    2
    Views:
    1,669
    Smokey Grindel
    Dec 2, 2006
  3. Replies:
    2
    Views:
    570
  4. Daniel Waite
    Replies:
    2
    Views:
    209
    Daniel Waite
    May 2, 2008
  5. Simeon Chaos
    Replies:
    5
    Views:
    124
    James Harris
    Jan 11, 2014
Loading...

Share This Page