Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > A story about Python... sort of

Reply
Thread Tools

A story about Python... sort of

 
 
Roy Smith
Guest
Posts: n/a
 
      07-03-2003
Dave Brueck <(E-Mail Removed)> wrote:
> If Python were to become too slow or too weird I'd migrate to
> another high-level language


I can certainly see situations were Python might be too slow, but too
weird? When would it be too weird?
 
Reply With Quote
 
 
 
 
Russell Reagan
Guest
Posts: n/a
 
      07-03-2003
"Dave Brueck" <(E-Mail Removed)> wrote

> > I
> > mean, is Linux (or Windows) 'not a viable project'??

>
> Well, again, neither of those are "applications level" projects.


There is a rather large industry which I'll call "computer games" that is
rather CPU intensive, and AFAIK the vast majority of those games are written
in C/C++. It really depends on the definition of "application level". If
we're only including things like word processors and web browsers in the
"application level", then there isn't a great need for C++ in the
"application level", but there are certainly areas where speed and memory
efficiency is important.

I will admit that I'm getting tired of writing a lot of the support code,
debugging, etc., most of which Python provides for "free".


 
Reply With Quote
 
 
 
 
Aahz
Guest
Posts: n/a
 
      07-04-2003
In article <Yg3Na.97773$R73.11565@sccrnsc04>,
Russell Reagan <(E-Mail Removed)> wrote:
>
>There is a rather large industry which I'll call "computer games" that
>is rather CPU intensive, and AFAIK the vast majority of those games are
>written in C/C++. It really depends on the definition of "application
>level". If we're only including things like word processors and web
>browsers in the "application level", then there isn't a great need for
>C++ in the "application level", but there are certainly areas where
>speed and memory efficiency is important.


At the same time, more and more of those games are switching to using
C/C++ only for the rendering engine and using a scripting language (Lua
or Python) for the gameplay itself.
--
Aahz ((E-Mail Removed)) <*> http://www.pythoncraft.com/

Usenet is not a democracy. It is a weird cross between an anarchy and a
dictatorship.
 
Reply With Quote
 
Behrang Dadsetan
Guest
Posts: n/a
 
      07-04-2003


Russell Reagan wrote:
> "F. GEIGER" <(E-Mail Removed)> wrote
>
>
>>[OT] That's not a pro, that's a con on the C++ side. And actually that's

>
> the
>
>>reason why there's so much bad C++ software. A C programmer first has to
>>forget C to be able to program in C++ - well, to be able to program OO in
>>C++.

>
>
> C++ is not an OO language. It is a multi-paradigm language that happens to
> support OO features. No one is required to program OO in C++. It's even very
> debatable if it's better to program OO in C++.


We are getting very philosophical here and I guess we are getting a
little off-topic, but what is an OO language? Isn't one that supports OO
features? Ok, You can write C code and compile it with a C++ compiler,
but does it disqualify C++ as being a OO language?

The advantages you talk about writing C and using a C++ compiler are
pretty weak. C++ is certainly not just about the "typedef" feature... It
is a very powerfull language that can be used to express exactly what
you want the computer to do, and in the same time kind of abstract
details to a level where you can still see what your program was written
for. Agreed, it is a terrificly complex language all together, but it
has its use. If you actually respect the thousand rules from M. Meyer
plus a few from M. Lakos, you can build very reliable and stable
applications. If you are a genius or have some technique and experience,
you can even have a somewhat bigger code where you still have an overview.

The big disadvantage to its C compatibility is that lots of people
beleive they have C++ experience and present themselves at C++ jobs. You
just need an IT management which has no clue about OO technology/C++
(managers that understand anything at this level are in minority) and
you soon have a C programmer who used a C++ compiler converted into a
Java programmer. Little after you will see something really funny, C
compiled by a Java programmer. Is Java therefore not a OO language? I
mean Java will allow C programmers to build classes with only static
methods, with classes of 6000 lines without constructor and all
variables declared as public class members? I have seen this, and I am
not exagerating at all in the description... it actually took me two
days to understand why I did not understand how the programmer cut the
program. Yes, I was naive enough to think one can only write OO in Java,
like in the advert.

Anyway, let us talk about something else, I hate being reminded how
often our IT industry has been guarenteeing our jobs life-time by making
every thing more complicated and more expensive instead of making things
simpler and cheaper as we were entrusted to do. Note that I do not think
we do that on purpose

That said, python does make life easier in many occasions, so there is
maybe some hope that a little tiny community of our IT industry is not
reaping off our dear sponsors (IT users including IT people).

Thanks pyguys for your beautiful contribution, please continue just as
you are now. You have been doing a wonderful job. If you could only
replace VB for all the usages it has now, and convince the planet of
that as well, I would be thankful for ever.

Ben.

 
Reply With Quote
 
Paul Boddie
Guest
Posts: n/a
 
      07-04-2003
"Max Khesin" <(E-Mail Removed)> wrote in message news:<dGZMa.5172$(E-Mail Removed)>.. .
>
> I am not sure where we disagree. This is exactly my point. The statement
> "
> Engineering Lessons
> -------------------
> 1. C/C++ is no longer a viable development language
> "
> is pure rubbish. C++ is still great for certain kinds of projects, and there
> are lots of open-source and proprietary projects to prove this.


I wouldn't agree with you unreservedly here. In many respects, the
choice of C++ for projects is often an educational problem with the
developers - people choose it because it's what they know, potentially
not very well in many cases. So one could say that it's really
something they just know something about - it seems like the
right/safe choice, presumably because their peers/acquaintances who
are just as badly informed tell them so.

Those of us who are used to more high-level languages would think
twice about writing a large application using a language/library
combination without decent (ie. modern) support for memory management,
for example. I can imagine that many developers find it challenging
and even rewarding to think up interesting schemes for allocating and
freeing memory - perhaps they even think that this (and lots of other
unnecessary wheel reinvention) is what programming is all about.
Personally, I'd rather get on with implementing the actual system
concerned.

So, I'd rephrase the original statement: C/C++ are frequently
suboptimal choices for application development. Why? Poor support for
near-essential features found in contemporary languages combined with
the absence of timely, effective standardisation of useful library
functionality.

Paul
 
Reply With Quote
 
John J. Lee
Guest
Posts: n/a
 
      07-04-2003
http://www.velocityreviews.com/forums/(E-Mail Removed) (Aahz) writes:

> In article <Yg3Na.97773$R73.11565@sccrnsc04>,
> Russell Reagan <(E-Mail Removed)> wrote:

[...]
> At the same time, more and more of those games are switching to using
> C/C++ only for the rendering engine and using a scripting language (Lua
> or Python) for the gameplay itself.


Is this true of big-$ commercial games? What sort of market share do
high-level / interpreted languages have there?

Never having been a (graphical) games player, I don't know the first
thing about how games developers do things.


John
 
Reply With Quote
 
Aahz
Guest
Posts: n/a
 
      07-04-2003
In article <(E-Mail Removed)>, John J. Lee <(E-Mail Removed)> wrote:
>(E-Mail Removed) (Aahz) writes:
>>
>> At the same time, more and more of those games are switching to using
>> C/C++ only for the rendering engine and using a scripting language (Lua
>> or Python) for the gameplay itself.

>
>Is this true of big-$ commercial games? What sort of market share do
>high-level / interpreted languages have there?


Depends what you mean by big-$. Humongous Entertainment has recently
switched to requiring Python for all new games. Lua is even more
prevalent; see http://www.lua.org/uses.html
--
Aahz ((E-Mail Removed)) <*> http://www.pythoncraft.com/

Usenet is not a democracy. It is a weird cross between an anarchy and a
dictatorship.
 
Reply With Quote
 
Peter Hansen
Guest
Posts: n/a
 
      07-04-2003
Aahz wrote:
>
> In article <(E-Mail Removed)>, John J. Lee <(E-Mail Removed)> wrote:
> >(E-Mail Removed) (Aahz) writes:
> >>
> >> At the same time, more and more of those games are switching to using
> >> C/C++ only for the rendering engine and using a scripting language (Lua
> >> or Python) for the gameplay itself.

> >
> >Is this true of big-$ commercial games? What sort of market share do
> >high-level / interpreted languages have there?

>
> Depends what you mean by big-$. Humongous Entertainment has recently
> switched to requiring Python for all new games. Lua is even more
> prevalent; see http://www.lua.org/uses.html


Well, you can't get any bigger than "humongous", can you?
 
Reply With Quote
 
Dave Brueck
Guest
Posts: n/a
 
      07-07-2003
On Thursday 03 July 2003 11:48 pm, Russell Reagan wrote:
> "Dave Brueck" <(E-Mail Removed)> wrote
>
> > > I
> > > mean, is Linux (or Windows) 'not a viable project'??

> >
> > Well, again, neither of those are "applications level" projects.

>
> There is a rather large industry which I'll call "computer games" that is
> rather CPU intensive, and AFAIK the vast majority of those games are
> written in C/C++. It really depends on the definition of "application
> level". If we're only including things like word processors and web
> browsers in the "application level", then there isn't a great need for C++
> in the
> "application level",


Actually, games are a particularly good example to illustrate the point:

1) In the movement away from a lower-level language, games are probably one of
the last hold-outs since performance often means so much. Still, even games
do make the transition - the transition away from assembly being the main
example.

2) Even the most performance-intensive games of today are already
transitioning towards higher-level languages - is there any major
first-person shooter or real-time strategy game coming out these days that
doesn't boast a powerful scripting language? With each new generation of
games the developers try to push more and more of the functionality into
their scripting engine leaving as little as possible behind in C/C++ - the
render loop, *some* of the AI, etc. Not only is the game customizable by the
customers, the developers themselves prefer it because of fewer bugs and it
makes it much easier to try new and cool stuff out.

3) More and more of the performance-intensive work is handled by hardware
nowadays anyway - both video and audio. Furthermore, the game itself usually
relies on a pretty rich and powerful supporting library like OpenGL or even
DirectX, which depending on the route you take can supply a ton of the
functionality that the game developer would normally write in C or C++.

4) All of the above mean that in many cases you already *can* do some pretty
elaborate games in higher-level languages (the games listed on Pygame are a
great example), and there's every indication that the trend will continue.

There came a time when it was no longer economically viable to develop an
entire game in assembly, and IMO we've *already* passed the point where it's
no longer economically viable to develop most games entirely in C++ - the
time to market is too long, it's too expensive to add new features,
recovering from early incorrect decisions is too costly, etc. Games are
moving to higher-level languages as much as they can because it's a
competitive advantage to do so.

> but there are certainly areas where speed and memory
> efficiency is important.


Oh, nobody disagrees with that. But due to increases in efficiency and
decreases in prices, the number of cases is shrinking wherein speed and
memory constraints require you to drop to a lower-level language.

-Dave

 
Reply With Quote
 
Ben Finney
Guest
Posts: n/a
 
      07-07-2003
On Mon, 07 Jul 2003 02:02:06 GMT, Russell Reagan wrote:
> Anyway, I know of one chess program written in python, and it is
> dreadfully slow compared to *any* program written in C/C++ (that I've
> seen anyway).


Have you looked at the code for it? Have you profiled it to see where
its bottlenecks are? It's often the case that a program is low because
of poor design, or simply choosing a slow algorithm.

Until profiling, of course, you can't know which algorithms are too slow
for the program.

> The things that make a chess program fast aren't really python's
> strengths, but hopefully I'm being pessimistic due to my lack of
> python/c knowledge.


My suggestion for those who want to write programs that do something
quickly:

- Write a program that does the job at all, paying attention to
simplicity and readability and *no* attention to optimisation.

- Debug the program so it does everything it's supposed to do, albeit
slowly.

- Once the program is correct, and not before, profile it to see where
it's slow.

- Pick the biggest bottleneck and make it faster, by one or more of:

- Choose a faster algorithm, perhaps sacrificing readability or
simplicity
- Re-implement in C

- Iterate the previous step until the program is fast enough or you
run out of (time|money).

You'll have a program that is quite readable, except in the places where
it needs to be fast. In my experience, those places are surprisingly
few, and are surprisingly different to where you expected them to be.

> import chess
> chess.run_program_in_c
> print "Thanks for playing! Bye!"


It may well be that all the "real" chess-thinking stuff may be too slow
in Python; you might end up with the move-evaluation routine in C, for
example.

But discover that by profiling a Python implementation first! If it
turns out to be too slow, at least you've debugged a working algorithm,
and can treat it as pseudocode for the port to C. If it turns out that
the bottlenecks are somewhere else entirely, you've saved yourself a
huge misguided optimisation effort.

--
\ "My roommate got a pet elephant. Then it got lost. It's in the |
`\ apartment somewhere." -- Steven Wright |
_o__) |
http://bignose.squidly.org/ 9CFE12B0 791A4267 887F520C B7AC2E51 BD41714B
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Tell Your Story - Wondershare Released Photo Story Platinum kena Digital Photography 0 06-12-2007 08:42 AM
Newsweek Story just that a Story Mark Test Digital Photography 21 05-22-2005 02:39 PM
Ado sort error-Ado Sort -Relate, Compute By, or Sort operations cannot be done on column(s) whose key length is unknown or exceeds 10 KB. Navin ASP General 1 09-09-2003 07:16 AM
Re: A story about Python... sort of John J Lee Python 7 07-10-2003 12:51 PM
RE: A story about Python... sort of Tony Meyer Python 8 07-10-2003 09:53 AM



Advertisments