Mailing List Archive: Productivity and the two language approach (was: Using Python for Modular Artificial Intelligence code)

Productivity and the two language approach (was: Using Python for Modular Artificial Intelligence code)

May 3, 1999, 12:01 PM

Post #1 of 7 (925 views)

Tim Auld wrote in message ...

>Sure, I can appreciate the programming ease which these higher level
>languages bring (I think Java is really clean), but when you are working on
>games you kinda need to go "blind on speed" to a large degree.
It did work in Scientific Computing and now I do work in Information
Systems. It is the same argument over there.
Anyway again, I think that 'Python Lovers' love the language so much because
it really improves productivity

>It's no good having a game that was easy to program if it runs like a dog.
True, but it is also no good if it takes days or even weeks to program and
debug something, if it only takes a few % of your total run time and it
could be programmed in only a few hours in another language, right?

>You can learn
>the syntax to any language in a few days, but a language is more than just
>syntax. There are many small things you need to learn, and the different
>libraries/APIs/tools/experience etc. that come along with it.

Most certainly true!!

>This is not supposed to be a "my language is better than yours" debate :)
>please let's agree to disagree -
Ok

>I really think Python is good, it's just
>that using it doesn't weigh up in this situation.
The latter I still am not sure of, but lets refrase:

Is there anybody who has detailed numbers on the productivity increase using
the two-language approach.?

Ilja

Productivity and the two language approach (was: Using Python for Modular Artificial Intelligence code) [ In reply to ]

dfan at harmonixmusic

May 3, 1999, 1:09 PM

Post #2 of 7 (922 views)

"Ilja Heitlager" <news@helen.demon.nl> writes:

| Is there anybody who has detailed numbers on the productivity
| increase using the two-language approach.?

The canonical paper is "Scripting: Higher Level Programming for the
21st Century" by John Ousterhout, inventor of Tcl. It has a table
with some quantitative but anecdotal numbers on productivity.

http://www.scriptics.com/people/john.ousterhout/scripting.html

--
Dan Schmidt -> dfan@harmonixmusic.com, dfan@alum.mit.edu
Honest Bob & the http://www2.thecia.net/users/dfan/
Factory-to-Dealer Incentives -> http://www2.thecia.net/users/dfan/hbob/
Gamelan Galak Tika -> http://web.mit.edu/galak-tika/www/

Productivity and the two language approach (was: Using Python for Modular Artificial Intelligence code) [ In reply to ]

May 4, 1999, 4:27 AM

Post #3 of 7 (917 views)

Dan Schmidt wrote in message ...
>The canonical paper is "Scripting: Higher Level Programming for the
>21st Century" by John Ousterhout, inventor of Tcl. It has a table
>with some quantitative but anecdotal numbers on productivity.
>
>http://www.scriptics.com/people/john.ousterhout/scripting.html

Thanks. Note for Tim (I am becoming evangelistic) productivity increase
measured from 4-60 for 8 different projects!

Any numbers on Python/C or JPython/Java already? (both productivity and
performance)

Ilja

Productivity and the two language approach (was: Using Python for Modular Artificial Intelligence code) [ In reply to ]

fredrik at pythonware

May 4, 1999, 6:33 AM

Post #4 of 7 (918 views)

Ilja Heitlager <news@helen.demon.nl> wrote:
> >http://www.scriptics.com/people/john.ousterhout/scripting.html
>
> Thanks. Note for Tim (I am becoming evangelistic) productivity increase
> measured from 4-60 for 8 different projects!

careful with those figures. iirc, they describe existing
projects that were rewritten in Tcl by experienced
programmers, and seem to focus on coding and code
debugging efforts only. there's a lot more to take into
account out in the real world...

python's no silver bullet, you know...

(but it's a damned good tool!)

</F>

Productivity and the two language approach (was: Using Python for Modular Artificial Intelligence code) [ In reply to ]

May 4, 1999, 8:08 AM

Post #5 of 7 (915 views)

Fredrik Lundh wrote in message
<009001be9633$e3875bf0$f29b12c2@pythonware.com>...
>careful with those figures. iirc, they describe existing
>projects that were rewritten in Tcl by experienced
>programmers,
It described 5 C first and 3 Tcl first projects. 8 projects is not enough
evidence, I know, but it is convincing, at least to my manager ;-)

> and seem to focus on coding and code
>debugging efforts only. there's a lot more to take into
>account out in the real world...

Real developers start with requirements, analysis, design and later
implementation, testing and user testing ;-).

Anyway, currently I am working on a algebraic pattern matcher. The project
is on a code-test-design basis (with a lot of ADT's and list-processing
algo's). Having short code-test cycle's, interactivity/scripting, *NO
POINTERS* and Python's nifty language features is *REALLY* improving my
productivity.

And a good C++ programmer is probably more productive than a bad Python
programmer. (As Tim is telling us).

SOOOO, it all depends, right?

>python's no silver bullet, you know...
No, it's platinum ;-)

>(but it's a damned good tool!)
Fact.

Ilja

Productivity and the two language approach (was: Using Python for Modular Artificial Intelligence code) [ In reply to ]

sdm7g at Virginia

May 4, 1999, 12:24 PM

Post #6 of 7 (917 views)

On 3 May 1999, Dan Schmidt wrote:

> "Ilja Heitlager" <news@helen.demon.nl> writes:
>
> | Is there anybody who has detailed numbers on the productivity
> | increase using the two-language approach.?
>
> The canonical paper is "Scripting: Higher Level Programming for the
> 21st Century" by John Ousterhout, inventor of Tcl. It has a table
> with some quantitative but anecdotal numbers on productivity.
>
> http://www.scriptics.com/people/john.ousterhout/scripting.html
>

The introductory chapters of the swig manual have a very nice writeup
of the rationale of the two language approach:
<http://www.swig.org/doc.html>

No attemps to measure productivity though, but that's very difficult
to do. It's expensive to develop everything in duplicate or triplicate,
and when you're done, it's not clear what you've measured.

---| Steven D. Majewski (804-982-0831) <sdm7g@Virginia.EDU> |---
---| Department of Molecular Physiology and Biological Physics |---
---| University of Virginia Health Sciences Center |---
---| P.O. Box 10011 Charlottesville, VA 22906-0011 |---

Productivity and the two language approach (was: Using Python for Modular Artificial Intelligence code) [ In reply to ]

fredrik at pythonware

May 5, 1999, 12:24 AM

Post #7 of 7 (918 views)

Ilja Heitlager wrote:
> And a good C++ programmer is probably more productive than a bad Python
> programmer. (As Tim is telling us).

on the other hand, he doesn't realize that a good
C++ programmer is very unlikely to be a bad Python
programmer for more than a few days...

(while a good Python programmer can continue being
a bad C++ programmer for the rest of his life -- I just
*hate* that language ;-)

</F>