A proposal... (python)

[K.I.L.E.R]

Well you can replace most, if not all, big switches with either lambdas or the fact that functions are first class in python.

def apply_heal(living_thing, heal_magnitude, cures):
     living_thing.mod_hp(heal_magnitude)
     living_thing.cure(cures)

...

potion["heal"] = {"name":"Heal", "desc":"Heal 300 and such", "effect":apply_heal}

This is perfectly valid in python

Or:

class SimpleHeal(Effect):

def apply(living_thing):
     living_thing.mod_hp(heal_magnitude)
     living_thing.cure(cures)

[Atarlost]

Those are no longer purely edit files but modules that can be imported as code. You can only get away with that because Python is interpreted. Those modules are as difficult to edit as the core of the game engine, but because Python is interpreted everything is as easy to edit as the current edit files.

You'll notice that little clause "in compiled languages" in my post. It's an argument against C++ and I think Java, not against Python or any other interpreted language. There are other arguments against interpreted languages. For example trying to implement borg-grade AI on all humanoid monsters would probably lag the game noticeably more in an interpreted language.

[Sirridan]

I still want edit files mostly because in some cases python may or will be compiled to machine code, such as for windows where python isn't installed natively.

[AnonymousHero]

Just for the record, Java has absolutely no trouble loading code dynamically, it's what class loaders do. It can also check that loaded code actually conforms to the specification (interface). You can also do it in C++ and C (plugins, anyone?) can also do it, but it is more brittle.

In Java you'd also get some assurance that the "living_thing" in that heal() method actually had mod_hp() and cure() methods.

IMO, Python is fine for rapid prototyping and smallish systems, but unless you're prepared to write comprehensive unit tests it's going to be hell once your code base gets large. Even if you do write comprehensive unit tests (as e.g. the Bazaar people do), there's lots of times silly errors make it through. I've been bitten by completely trivial errors in Bazaar numerous times, for example. That's not to say that Java doesn't have its share of flaws (null, I'm looking at you!), but at least you don't have to write unit tests to do checking which the compiler can easily do.

[d_m]

IMO, Python is fine for rapid prototyping and smallish systems, but unless you're prepared to write comprehensive unit tests it's going to be hell once your code base gets large. Even if you do write comprehensive unit tests (as e.g. the Bazaar people do), there's lots of times silly errors make it through. I've been bitten by completely trivial errors in Bazaar numerous times, for example. That's not to say that Java doesn't have its share of flaws (null, I'm looking at you!), but at least you don't have to write unit tests to do checking which the compiler can easily do.

And IMO, writing Java is like being stabbed in the eye. But to each their own.

I'm not sure the issues you're talking about are problems with Python per se, so much as with design and/or coding style. Almost all of my professional programming experience (on large projects) is in dynamic languages like Python or Perl. I don't think large code bases written in C# or Java are inherently more correct or easier to maintain, and static type systems aren't inherently more correct than dynamic ones.

Anyway, I simultaneously want to respond to your provocative comment and want to avoid a flamewar I guess I chose to do something in between.

[Derakon]

There are other arguments against interpreted languages. For example trying to implement borg-grade AI on all humanoid monsters would probably lag the game noticeably more in an interpreted language.

Which is when you break out Python's ability to talk to compiled languages with ease.

For example, one of my Python projects has some moderately heavy math being done in custom Vector and Polygon classes. I pinned them down as being a major source of slowdown by using Python's built-in profiler, then converted those modules to Cython, which is basically Python with a header file and typed variables. These modules in turn get compiled at program start (or a cached version is used if available), and everything else talks to them just as if they were ordinary Python. This gave me a 17% speedup in my tests (which degree of speedup obviously depends on how heavily you use the modules you're converting; in my case they went from "biggest offender" to "not in the top 50" on my profiling results).

And if that's not enough, you can write Python modules in C and create appropriate bindings so they can be invoked from Python's side. This requires you to have separate build processes for each OS you want to use, though, since such compiled libraries aren't binary-compatible.

Bottom line is, "interpreted languages are slow" is not a reason to avoid using Python, because you can put all the bits that must be fast into a non-interpreted language and still reap the vast majority of the benefits that Python provides.

[Atarlost]

You were supposed to chuckle or at least smirk at the very idea of implementing something that would be so much work for so little gain, not rebut it as if it was a serious argument.

I'm pretty sure implementing borg-grade AI on large numbers of monsters would create the same pathfinding hell that brings modern computers to their knees in Dwarf Fortress catsplosions. I'd expect it to be unacceptably slow no matter how low level the implementation.

[Derakon]

I was responding to the implied higher-level argument of "Python is too slow", not the specific example. I've optimized plenty of Python programs, and while no, they don't reach the speed of an equivalent C program, they're nowhere near problematic. I doubt our player base would mind spending 5% more CPU on their games if that meant a faster turnaround on change requests.

(Of course in our case, the main bottleneck for new changes is often all the bickering we do, not the actual implementations....)

[Therem Harth]

On the desktop, I really don't think Python has that bad a speed handicap. I hardly ever see PyGTK applications lag significantly, whereas Java ones lag like crazy; I'm not entirely sure, but I think the overhead of the JVM more than makes up for the slower execution speed of Python and other interpreted languages.

In other words, performance benchmarks tell one story, and desktop use tells another. IMO of course.

[Therem Harth]

BTW.

==11061== Invalid read of size 4
==11061==    at 0x810C505: object_desc (object1.c:2059)
==11061==    by 0x81369C9: test_object_wish (xtra2.c:7411)
==11061==    by 0x8136D7D: make_wish (xtra2.c:7570)
==11061==    by 0x81C0429: do_cmd_debug (wizard2.c:1912)
==11061==    by 0x80EC55D: process_command (dungeon.c:3558)
==11061==    by 0x80F155D: process_player (dungeon.c:4875)
==11061==    by 0x80F2255: play_game (dungeon.c:5327)
==11061==    by 0x81DE9DB: main (main.c:908)
==11061==  Address 0x4602724 is 12 bytes before a block of size 1,440 alloc'd
==11061==    at 0x4024918: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)

This is why games should be written in a high-level language IMO. ANY high-level language.

(BTW, did you know that ToME2 has some kind of IRC client built in? The game probably has an exploitable buffer overflow every dozen lines. I can't imagine what script kiddies would make of it. Probably Swiss cheese.)

[Atarlost]

I doubt that with modern processors our player base would notice spending 5% more CPU time or even 50%. Angband hasn't grown all that much from a game that ran on 8386 and 8486 processors. While we have become less patient we haven't become less patient nearly as fast as processors have become faster either. Maybe the Mangband people would notice a 50% increase in processor load, but for those of us not playing real time variants I can't see any issues unless the code is anti-optimized.

[Derakon]

(Note: 5% figure is completely made up, like 95% of all statistics)

[zaimoni]

.... but unless you're prepared to write comprehensive unit tests it's going to be hell once your code base gets large.

But you should be prepared to write such unit tests no matter what the programming language.

I do not like using languages without compile-time type checking for large programs, period -- the absence of syntax errors is a time-waster. (Unfortunately, there is no real choice for web server applications. 33% of my billable time on those, is due to the absence of C/C++ rigorous compile-time type checking in Perl and PHP.)

I'm prejudiced about Python merely because every single version shift of the following has broken at least one of my in-house Python programs by a completely undocumented backward-compatibility breaking change: 2.2 |-> 2.3, 2.3 |-> 2.4, 2.4 |-> 2.6, 2.5 |-> 2.6. None of the affected programs are more than 500 lines of code (excluding comments). It's a great language for text-processing, and decent for any other target task that doesn't require hordes of variable overwrites.

[Atarlost]

The only real benefits of interpreted languages are lost if you do that. At that point why not just stick with C? It's not like anyone with the ability to download Angband doesn't also have the ability to download Python. I suppose it might make a difference to people with limited permissions using Angband as a portable app off a thumbdrive, but the intersection of them and people who actually edit their edit files is probably negligible.

[Therem Harth]

Because C is spectacularly unfriendly for casual hacking.