Scripting Languages
zach...@gmail.com
roguelike-ish game (mostly for us to learn game development/
programming/etc. above pushing the line).
One of the big decisions we have made is to use a scripting language
for as much of the game as is reasonable.
I notice that a lot of games recently are using Lua (Crawl, ToME, and
DoomRL to name a few), and I was wondering why Lua was chosen above
Python (which is the scripting language we are firstly considering)?
I have read a few comparison between Python and Lua, so I know most of
the general differences (power, imprint, community, etc.), but I am
looking for more of a roguelike developer's opinion on choosing a
scripting language in a roguelike and what to use it for.
Thanks for all responses!
Kenneth 'Bessarion' Boyd
1) Python was considered for V Angband as well. (Cf. the V2.8.3 test-fork
PAngband, i.e. Programmable Angband.) It proved much easier to integrate LUA
than Python (V3.0.0 through V3.0.6 have Lua support, this was torn out in V3.0.7
as it never was really used properly in V. T.o.M.E. does use Lua properly,
often to do things that are very difficult in C.)
More importantly, PAngband was forked by the same maintainer as the V3.0.0 to
V3.0.5 series: Robert Ruehlmann. This intimates that there was some key flaw
with the Python integration that made switching to Lua from Python reasonable.
2) The Python language specification is highly unstable between major versions;
beyond the most basic syntax, it's fairly certain that each major version will
break the prior version's scripts. Lua has a track record of not doing this.
3) The most recent Python to have any sort of restricted-execution model is
2.2.x. This model was always defeatable with moderate knowledge of the target
language. New-style exceptions broke this, so the Python devteam just tore out
restricted-execution entirely.
The main advantage of Python is that it has a more recognizable object model.
However, if *that* is a real concern one should *not* be using C as the base
language to integrate a scripting language into -- and neither Lua nor Python
have easy integration with C++, let alone more dynamic languages.
Kornel Kisielewicz
> A few of my friends and I are going to embark on the creation of a
> roguelike-ish game (mostly for us to learn game development/
> programming/etc. above pushing the line).
>
> One of the big decisions we have made is to use a scripting language
> for as much of the game as is reasonable.
>
> I notice that a lot of games recently are using Lua (Crawl, ToME, and
> DoomRL to name a few), and I was wondering why Lua was chosen above
> Python (which is the scripting language we are firstly considering)?
Lua is fast, so you will learn a language that is useful all around in
game programming.
Lua is simple, so you won't spend much time learning it to a very good
level.
Lua is light, so you won't bloat the user with no huge bloated downloads.
Lua allows you to do things the way you want it -- it's a very flexible
language, that allows to extend itself via metaprogramming and userdata.
And last but not least, it's absurdly easy to implement in any project
-- the API is very clean and really easy to hold on to.
Not to mention that it's a beautiful language indeed! Like the moon
itself ;].
regards,
Kornel Kisielewicz
Ido Yehieli
> One of the big decisions we have made is to use a scripting language
> for as much of the game as is reasonable.
You could use python or lua for all of the game- i think there are
plenty of people here who do just that. Computers are fast these days,
and if you do get to a part where performance is important you can
drop into a c from there - you don't have to do it the other way
around.
i wouldn't embed a scripting language off the bat, especially if it's
your 1st game.
-Ido.
Ido Yehieli
wrote:
> 2) The Python language specification is highly unstable between major versions;
> beyond the most basic syntax, it's fairly certain that each major version will
> break the prior version's scripts.
Major versions change every 6-7 years. That's not exactly often, and
there will be transition tools for converting python 2.x to 3.0.
Kenneth 'Bessarion' Boyd
> On Dec 27, 5:07 pm, Kenneth 'Bessarion' Boyd
> wrote:
> > 2) The Python language specification is highly unstable between major versions;
> > beyond the most basic syntax, it's fairly certain that each major version will
> > break the prior version's scripts.
>
> Major versions change every 6-7 years. That's not exactly often, and
> there will be transition tools for converting python 2.x to 3.0.
Python 2.5 breaks Python 2.4 scripts.
Python 2.4 breaks Python 2.3 scripts.
And so on. That not only defines the first decimal place as what tracks a major
version for Python (which is fairly common; both PHP and the major web forums do
this in practice, if not denotation). And these breaks of non-deprecrated core
features are coming every 18 months or so, historically.
The Python 2.5 docs are fairly clear on what core non-deprecated features were
broken in each major version transition since 2.2 to 2.3. I can't think of any
other programming language whose devteam intentionally trashes upward
compatibility this much.
Fortunately, Python is a powerful enough language to justify this for specialist
applications. For an embedded language to support wild extensibility by third
parties, it's a critical if not fatal liability.
takkaria
> DoomRL to name a few), and I was wondering why Lua was chosen above
> Python (which is the scripting language we are firstly considering)?
>
> I have read a few comparison between Python and Lua, so I know most of
> the general differences (power, imprint, community, etc.), but I am
> looking for more of a roguelike developer's opinion on choosing a
> scripting language in a roguelike and what to use it for.
Lua is much more lightweight and far simpler than Python, and since it is also
designed to be embedded, is quicker to get up-and-running. I'm the maintainer
of Angband, and though I took Lua support out because it wasn't used very well
and thus made the bar to entry higher, if I ever do my own variant, I plan to
use Lua a lot.
I consider the lack of any object model in Lua a distinct advantage. You can
shape it how you want it, pretty much.
Things to use it for:
- data definition (objects/monsters/terrain) -- this saves you writing a
seperate parser
- object and spell effects
- interaction with the terrain, if you have interesting terrain
- some bits of AI (I wouldn't, for example, put pathfinding in Lua)
- dungeon generation -- though making it performant might be hard
- anything where you're doing more than a little string handling
Generally, I'd consider writing all stuff that will be done repeatedly (e.g.
creating a square room) in C (or whatever your host language is), and using Lua
just for the stuff that it will be useful to tweak quickly.
If you're on an x86 platform, you might wish to consider LuaJIT, which compiles
Lua into native machine code just-in-time (like e.g. Java) -- doing that might
well make dungeon generation speedy.
Andrew Sidwell
fbk
> for as much of the game as is reasonable.
Considering that last sentence, I would go with python.
Lua is the language of choice if you want to integrate a scripting
language in legacy c or c++ code, because it makes this task so easy.
But if you start from scratch, I would consider using nothing but
python. It has got excellent threading abilities and a vast standard
library: Something you will not find in lua!
Anyway: Good luck with your game!
Fred
Kornel Kisielewicz
In that case he'd be better off writing the whole game in Python from
the start.
regards,
Kornel
Gerry Quinn
d50b93...@i12g2000prf.googlegroups.com>, Ido.Y...@gmail.com
says...
> On Dec 27, 4:21 pm, zach.b...@gmail.com wrote:
> > One of the big decisions we have made is to use a scripting language
> > for as much of the game as is reasonable.
>
> You could use python or lua for all of the game- i think there are
> plenty of people here who do just that. Computers are fast these days,
> and if you do get to a part where performance is important you can
> drop into a c from there - you don't have to do it the other way
> around.
I think there are people who have tried to use Python for roguelikes
and gotten burned on the speed issue, though. Not sure about Lua, but
I'm sure the same would apply.
- Gerry Quinn
zach...@gmail.com
> and gotten burned on the speed issue, though. Not sure about Lua, but
> I'm sure the same would apply.
>
See I knew that Lua was faster than Python, but I figured for a
roguelike that is turn-by-turn I should be fairly safe. Can you or
anyone else expound on that statement? Especially where the speed
traps were. We are using Java with Python... well we planned on it.
Things can change of course.
Kenneth 'Bessarion' Boyd
> > I think there are people who have tried to use Python for roguelikes
> > and gotten burned on the speed issue, though. =A0Not sure about Lua, but
> > I'm sure the same would apply.
You pretty much have to use the Python native language constructs heavily to
avoid speed issues (and even then juggling binary data is slow).
C Python is faster than badly written C when fully using the core language
features of Python. Of course, this does expose you to my main complaint with
Python: the next major release (bump of first decimal place) *will* break your
script if it's of any reasonable size. I'd do an intentional fork at each major
version, simply to have a known-working-on-old-Python version while fixing up
the new one.
Lua is small enough that the devteam can optimize it to exhaustion. I would not
use speed as a tiebreaker between Lua and Python, however.
> See I knew that Lua was faster than Python, but I figured for a
> roguelike that is turn-by-turn I should be fairly safe. Can you or
> anyone else expound on that statement? Especially where the speed
> traps were. We are using Java with Python... well we planned on it.
> Things can change of course.
Java as base does completely lock you out of Lua.
As noted elsewhere, it is perfectly reasonable to write a roguelike in either
Lua or Python directly. C Python does have the critical flaw that the standard
Windows release doesn't have a curses module. I would guess this shouldn't be a
real problem with Jython (Java Python).
Ed Kolis
implementation of that interface for JavaScript. You might want to
check it out... :)
Here are the javadocs for the scripting interfaces:
http://java.sun.com/javase/6/docs/api/javax/script/package-summary.html
I wonder if .NET has integration with VBscript yet... :P
M
Kenneth 'Bessarion' Boyd <zai...@zaimoni.com> wrote:
> On 2007-12-27 20:23:33, Ido Yehieli <Ido.Y...@gmail.com> wrote:
>
> > On Dec 27, 5:07 pm, Kenneth 'Bessarion' Boyd
> > wrote:
> > > 2) The Python language specification is highly unstable between
> > > major versions; beyond the most basic syntax, it's fairly certain
> > > that each major version will break the prior version's scripts.
> >
> > Major versions change every 6-7 years. That's not exactly often, and
> > there will be transition tools for converting python 2.x to 3.0.
>
> Python 2.5 breaks Python 2.4 scripts.
>
> Python 2.4 breaks Python 2.3 scripts.
>
> And so on.
Breakage does not happen this often. Going from 2.4 to 2.5 normally will
not break your code.
(Changes to 2.5: http://docs.python.org/whatsnew/whatsnew25.html)
However, breakage may still occur. Therefore, a range of commercial
applications are shipped together with a specific Python interpreter
version (or the packages have a dependency to such a version). I do not
see, why this approach should be impossible for a roguelike game.
> For an embedded language to support wild extensibility by third
> parties, it's a critical if not fatal liability.
I think that the breakage problem is exaggerated in Kenneth's
evaluation.
M
Kenneth 'Bessarion' Boyd
> On Thu, 27 Dec 2007 20:01:55 +0000 (UTC)
> Kenneth 'Bessarion' Boyd wrote:
>
> > On 2007-12-27 20:23:33, Ido Yehieli wrote:
> > > Major versions change every 6-7 years. That's not exactly often, and
> > > there will be transition tools for converting python 2.x to 3.0.
> >
> > Python 2.5 breaks Python 2.4 scripts.
> >
> > Python 2.4 breaks Python 2.3 scripts.
> >
> > And so on.
>
> Breakage does not happen this often.
One of the following in-house applications always has been nailed and needed
immediate fixing on upgrade to next major version:
* a custom image editor (first written for Python 2.2)
* XCOM UFO editor (first written for Python 2.4)
* makefile regeneration system (first written for Python 2.3)
We're talking about less than 400 lines of code across all three Python
applications. With this track record, I don't see the point of releasing
something I can't count on working even one language revision later.
For 2.4 to 2.5, the XCOM UFO editor broke due to incompatible changes in the
struct module, and had to be fixed. The other two were not broken.
> Going from 2.4 to 2.5 normally will
> not break your code.
> (Changes to 2.5: http://docs.python.org/whatsnew/whatsnew25.html)
Missing the point. Breakage is from old features changing, not new features.
Jeff Lait
You obviously haven't heard me scream and curse when a minor tweak to
better follow the ANSI turns a routine compiler upgrade into yet more
grunt work.
Python's version incompatibilities are thousand times worse. Code rot
is supposed to be a light hearted joke. Python makes it a crushing
reality.
I really want to like Python. It has a lot of very nice things. The
idiotic insistence on quit() to finish an interactive session (Don't
say Ctrl-D or I will shoot you - win32 python wants Ctrl-Z plus enter
for some bizarre reason) drives me insane. But the intentional
destruction of working code is much more evil. I'd be much more
tolerant if they had built versioning into the language so Python 2.5
could see a .py file flagged as 2.4 and drop into compatibility mode.
As for what language to use for a roguelike?
There are two possible scripting goals:
1) Data Definition. You want to write your data tables in something
more legible than C Structures and don't want to write your own
parser. No brainer: use Lua.
2) All your spell effects, room building, AI, and the kitchen sink,
leaving only a "game engine" in the native code.
a) Don't use a scripting language. Write your game in the scripting
language instead, with "native code" being helper functions for if/
when you find performance issues. Working on a game engine is a great
way to not make a game.
b) Use TOME. This instantly solves the game engine part, letting you
work on the scripts. If you think TOME isn't good enough for your
game, consider briefly how many years it has been worked on and
rethink your timeline for making your own game engine.
--
Jeff Lait
(POWDER: http://www.zincland.com/powder)
Martin Read
>The idiotic insistence on quit() to finish an interactive session
>(Don't say Ctrl-D or I will shoot you - win32 python wants Ctrl-Z plus
>enter for some bizarre reason)
Ctrl-Z ENTER is Windows' way of having the user denote "end of file" in
an interactive session. Ctrl-D is UNIX's.
--
\_\/_/ some girls wander by mistake into the mess that scalpels make
\ / are you the teachers of my heart? we teach old hearts to break
\/ --- Leonard Cohen, "Teachers"
zach...@gmail.com
about.
Jeff Lait
> Jeff Lait <torespondisfut...@hotmail.com> wrote:
> >The idiotic insistence on quit() to finish an interactive session
> >(Don't say Ctrl-D or I will shoot you - win32 python wants Ctrl-Z plus
> >enter for some bizarre reason)
>
> Ctrl-Z ENTER is Windows' way of having the user denote "end of file" in
> an interactive session. Ctrl-D is UNIX's.
I am aware of that. And it is a cute bit of folklore. But slavish
adherence to an antiquated divergence in control codes which
completely screws over anyone who regularly works in both platforms is
not appreciated. This is the epitome of the python stupidity - the
same boneheaded idiocy which led them to having quit output "Type
quit() ... to quit" rather than just adding a damn keyword to let you
quit.
The really laughable part is that requests for such a keyword are met
with pious concerns about backwards compatibility or old scripts that
rely on being able to execute every keyword without side-effect. This
is rich coming from the people who plan on changing the behaviour
of /, the division operator.
Darshan Shaligram
> On Dec 29, 8:28 pm, Martin Read <mpr...@chiark.greenend.org.uk> wrote:
>> Jeff Lait <torespondisfut...@hotmail.com> wrote:
>> >The idiotic insistence on quit() to finish an interactive session
>> >(Don't say Ctrl-D or I will shoot you - win32 python wants Ctrl-Z
>> >plus enter for some bizarre reason)
>> Ctrl-Z ENTER is Windows' way of having the user denote "end of
>> file" in an interactive session. Ctrl-D is UNIX's.
> I am aware of that. And it is a cute bit of folklore. But slavish
> adherence to an antiquated divergence in control codes
Sending EOF on a terminal is hardly antiquated, unless you're prepared
to go further and state that terminals are themselves antiquated. :-P
Windows' end-of-file silliness is just another aspect of silliness in
Windows. Blaming Python for it is... misdirected blame. :-)
> which completely screws over anyone who regularly works in both
> platforms is not appreciated. This is the epitome of the python
> stupidity - the same boneheaded idiocy which led them to having quit
> output "Type quit() ... to quit" rather than just adding a damn
> keyword to let you quit.
I'm not a powerful admirer of Python myself, but your examples here
make *you* look worse, not Python. A programmer dissing a language
because he has difficulty remembering how to send EOF in a terminal on
his OS du jour? Jeff, this is unworthy of you. :-)
--
Darshan Shaligram <scin...@gmail.com> Deus vult
Christophe Cavalaria
> The really laughable part is that requests for such a keyword are met
> with pious concerns about backwards compatibility or old scripts that
> rely on being able to execute every keyword without side-effect. This
> is rich coming from the people who plan on changing the behaviour
> of /, the division operator.
This is wrong wrong wrong. They didn't change the default behaviour of / in
any version of Python.
Christophe Cavalaria
> On 2007-12-27 20:23:33, Ido Yehieli <Ido.Y...@gmail.com> wrote:
>
>> On Dec 27, 5:07 pm, Kenneth 'Bessarion' Boyd
>> wrote:
>> > 2) The Python language specification is highly unstable between major
>> > versions; beyond the most basic syntax, it's fairly certain that each
>> > major version will break the prior version's scripts.
>>
>> Major versions change every 6-7 years. That's not exactly often, and
>> there will be transition tools for converting python 2.x to 3.0.
>
> Python 2.5 breaks Python 2.4 scripts.
>
> Python 2.4 breaks Python 2.3 scripts.
This must be some bad case of bad luck or something like that. There is
ample enouth examples of scripts from Python 1.5 which still work today
with the most recent release.
> And so on. That not only defines the first decimal place as what tracks a
> major version for Python (which is fairly common; both PHP and the major
> web forums do
> this in practice, if not denotation). And these breaks of non-deprecrated
> core features are coming every 18 months or so, historically.
It took them two version to forbid code which used None as a local vaiable
name. First in the changes from 2.2 to 2.3 it was cited that affecting a
value to None would cause a SyntaxWarning, then in the 2.3 to 2.4, after
ample time to catch on those warnings, doing so tranformed into a full
SyntaxError. More than half the core changes cited are of that kind: first
a new warning, then the next version makes it an error. It leaves script
writers that care for the most recent version quite a lot of time to catch
up. Those that do not care about the most recent version will be shipping
their own Python interpreter.
> The Python 2.5 docs are fairly clear on what core non-deprecated features
> were
> broken in each major version transition since 2.2 to 2.3. I can't think
> of any other programming language whose devteam intentionally trashes
> upward compatibility this much.
They do care. There are quite a lot of changes that were rejected because
they would break compatibility too much. Such changes are reserved for
Python 3000 and are often available with from __future__ imports, like the
new / operator behaviour. The only accepted changed that make it
intentionaly to that list http://docs.python.org/whatsnew/porting.html are
considered vital bug fixes or are warned about through the
DeprecationWarnings one major version in advance.
Christophe Cavalaria
Write it in Python and provide C performance modules for the heavy
computational tasks :) Pyrex helps a lot for that once you get it up and
running.
Jeff Lait
wrote:
I said *plan*, not that they did.
http://www.python.org/dev/peps/pep-0238/
/ will switch from integer division to float division by Python 3.0.
Jeff Lait
> Jeff Lait <torespondisfut...@hotmail.com> writes:
> > On Dec 29, 8:28 pm, Martin Read <mpr...@chiark.greenend.org.uk> wrote:
> >> Jeff Lait <torespondisfut...@hotmail.com> wrote:
> >> >The idiotic insistence on quit() to finish an interactive session
> >> >(Don't say Ctrl-D or I will shoot you - win32 python wants Ctrl-Z
> >> >plus enter for some bizarre reason)
> >> Ctrl-Z ENTER is Windows' way of having the user denote "end of
> >> file" in an interactive session. Ctrl-D is UNIX's.
> > I am aware of that. And it is a cute bit of folklore. But slavish
> > adherence to an antiquated divergence in control codes
>
> Sending EOF on a terminal is hardly antiquated, unless you're prepared
> to go further and state that terminals are themselves antiquated. :-P
>
> Windows' end-of-file silliness is just another aspect of silliness in
> Windows. Blaming Python for it is... misdirected blame. :-)
No, it is not. Python is fully capable of ignoring the windows
silliness and making the quit Ctrl-D. Or perhaps supporting both if
they feel more than 3 windows users would even consider using Ctrl-Z
to quit a program. It is anything but standard in Windows. I've used
Ctrl-Z to suspend more than I've used it as EOF.
> > which completely screws over anyone who regularly works in both
> > platforms is not appreciated. This is the epitome of the python
> > stupidity - the same boneheaded idiocy which led them to having quit
> > output "Type quit() ... to quit" rather than just adding a damn
> > keyword to let you quit.
>
> I'm not a powerful admirer of Python myself, but your examples here
> make *you* look worse, not Python. A programmer dissing a language
> because he has difficulty remembering how to send EOF in a terminal on
> his OS du jour? Jeff, this is unworthy of you. :-)
It is not sufficient to remember what OS you are currently using (or
sshed into). You also have to remember which version of python you are
using - some builds like the Cygwin one will decide to be unixy and
use Ctrl-D, other one's decide to be DOSy and use Ctrl-Z. And I have
the misfortune of having to interact with both types on a daily
basis. Thus my frustration.
The purpose of a language is to abstract details about my OS and
hardware so I don't have to worry about them. If I cared about the
ancient history of my platform I'd be writing in assembler, not
Python.
Kenneth 'Bessarion' Boyd
> Kenneth 'Bessarion' Boyd wrote:
>
> > On 2007-12-27 20:23:33, Ido Yehieli wrote:
> >
> >> On Dec 27, 5:07 pm, Kenneth 'Bessarion' Boyd
> >> wrote:
> >> > 2) The Python language specification is highly unstable between major
> >> > versions; beyond the most basic syntax, it's fairly certain that each
> >> > major version will break the prior version's scripts.
> >>
> >> Major versions change every 6-7 years. That's not exactly often, and
> >> there will be transition tools for converting python 2.x to 3.0.
> >
> > Python 2.5 breaks Python 2.4 scripts.
> >
> > Python 2.4 breaks Python 2.3 scripts.
>
> This must be some bad case of bad luck or something like that. There is
> ample enough examples of scripts from Python 1.5 which still work today
> with the most recent release.
See other thread. 400 lines of code (that does exclude comments; I was angry
enough to do that innuendo), by a *novice* Python programmer. My dominant
language is C++; my most-used language at work is Perl. The projects I named in
that other thread are Python because Python was the best language to implement
them in (of both my fluent and non-fluent programming languages), even though
I'm taking a 4x programmer time hit from non-fluency.
Don't be fooled by the version numbers I started those applications at. I just
spend barely enough time to optimize my applications to death and eliminate
newly deprecated constructs, after version-shock bugfixes. The Python
documentation is so comprehensive, thorough, and well-organized that no
language-specific skill is required to maximally optimize a Python program.
Systematic attention to detail and thorough regression testing, suffices. In
contrast, I am *still* not an expert Perl 5 programmer, only fluent; seven years
after I started using it seriously, I am still learning basic techniques for
code clarity, reliability, and speed.
My complaint is *not* about when the system works (critical bug fixes,
pre-announced declarations, or __future__ declarations). It is about *not*
having the unit testing in place to stop all undocumented breaking changes in
public libraries and interfaces.
As this has attracted the attention of the Python dev team (cf. the PyUnit
testing framework): a minimal white-box test suite, with enforced policy of
reporting all white-box test changes in the appropriate section of the release
notes, is the single best thing that they could do for Python 2.6. And it's
worth breaking the release schedule for.
Sherman Pendley
> I really want to like Python. It has a lot of very nice things. The
> idiotic insistence on quit() to finish an interactive session (Don't
> say Ctrl-D or I will shoot you - win32 python wants Ctrl-Z plus enter
> for some bizarre reason) drives me insane.
Blame Windows for that one. Unix shells interpret Ctrl-D themselves, and
respond by closing the active process' stdin. Windows' cmd shell does the
same in response to Ctrl-Z + Enter.
A tool that's simply reading from stdin until it gets to eof doesn't have
any say in the matter. :-(
sherm--
--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Krice
> looking for more of a roguelike developer's opinion on choosing a
> scripting language in a roguelike and what to use it for.
I don't use scripting languages at all. I really can't see
how they would make it easier to create a roguelike game,
but maybe someone will tell me.
Since (big) roguelikes handle a lot of data it's important
to know how to implement that in your game and try to create
a flexible data base system capable of handling different
types of data.
I wish I had known that when I started my project.
copx
"Sherman Pendley" <spam...@dot-app.org> schrieb im Newsbeitrag
news:m163yg6...@dot-app.org...
> Jeff Lait <torespon...@hotmail.com> writes:
>
>> I really want to like Python. It has a lot of very nice things. The
>> idiotic insistence on quit() to finish an interactive session (Don't
>> say Ctrl-D or I will shoot you - win32 python wants Ctrl-Z plus enter
>> for some bizarre reason) drives me insane.
>
> Blame Windows for that one. Unix shells interpret Ctrl-D themselves, and
> respond by closing the active process' stdin. Windows' cmd shell does the
> same in response to Ctrl-Z + Enter.
>
> A tool that's simply reading from stdin until it gets to eof doesn't have
> any say in the matter. :-(
OT: Your old email address (sherm...@dot-app.org - without the NOSPAM of
course) bounces. Could you please send my an email with a working address?
Jeff Lait
> Jeff Lait <torespondisfut...@hotmail.com> writes:
> > I really want to like Python. It has a lot of very nice things. The
> > idiotic insistence on quit() to finish an interactive session (Don't
> > say Ctrl-D or I will shoot you - win32 python wants Ctrl-Z plus enter
> > for some bizarre reason) drives me insane.
>
> Blame Windows for that one. Unix shells interpret Ctrl-D themselves, and
> respond by closing the active process' stdin. Windows' cmd shell does the
> same in response to Ctrl-Z + Enter.
>
> A tool that's simply reading from stdin until it gets to eof doesn't have
> any say in the matter. :-(
If only there was some way the tool could tell if it was run
interactively versus just reading from a file.
Oh yeah, there is. isatty.
If a simple tool like ls can be smart enough to reconfigure itself
depending on whether it is going to a terminal vs file, I'd hope
something as complex as python could show similar smarts.
Of course, this whole Ctrl-Z vs Ctrl-D issue would be moot if python
respected some other convention for quitting. Like, for example, the
perennial favourite "quit". Linux python users happily ignore the
stupid quit() rule because they just hit Ctrl-D all the time.
Malte Helmert
> On Dec 30, 12:31 pm, Sherman Pendley <spamt...@dot-app.org> wrote:
>> Jeff Lait <torespondisfut...@hotmail.com> writes:
>>> I really want to like Python. It has a lot of very nice things. The
>>> idiotic insistence on quit() to finish an interactive session (Don't
>>> say Ctrl-D or I will shoot you - win32 python wants Ctrl-Z plus enter
>>> for some bizarre reason) drives me insane.
> If a simple tool like ls can be smart enough to reconfigure itself
> depending on whether it is going to a terminal vs file, I'd hope
> something as complex as python could show similar smarts.
I think it's a plus that the interactive interpreter doesn't perform any
special magic on any input; if you want to call the quit function, use
parentheses like with any other function.
But if you really want to be able to type just "quit" or "exit" to quit
the interpreter, stick this into your $PYTHONSTARTUP:
========================================================================
class Quitter(object):
def __repr__(self):
raise SystemExit
exit = quit = Quitter()
========================================================================
If you want a more robust version that doesn't pollute the namespace and
doesn't kick you out when you type "globals()", try this:
========================================================================
class Quitter(object):
def __repr__(self):
import readline
position = readline.get_current_history_length()
last_cmd = readline.get_history_item(position)
if last_cmd in ["exit", "quit"]:
raise SystemExit
else:
return "<quitter>"
exit = quit = Quitter()
del Quitter
========================================================================
Also note that the standard interactive interpreter is intentionally
quite basic. Maybe something like ipython might suit you better?
Malte
Risto Saarelma
> I don't use scripting languages at all. I really can't see
> how they would make it easier to create a roguelike game,
> but maybe someone will tell me.
One feature of scripting languages is the ease of modding the game or
designing game features with little programming experience. This is
probably one of the less useful features for roguelikes, since they
generally need to be made into a reasonably playable and complete form
by one person before anyone will be interested in modding them.
Somewhat more interesting is the possibility of parsing and evaluating
script code when the program is running. This is just plain impossible
when using a C-like language without resorting to unholy abominations
[1]. When you spot a bug, you could in theory patch a script, order the
engine to reload it and see whether the bug has gone away, without
quitting the game and losing the conditions where the bug arose. You
could also have an in-game console where you can write one-liners to do
things with the game state. I'm not aware of things like
console-onliners being used a lot in games, they're more like something
you do in Smalltalk images and when working with Emacs.
While I have the feeling that game engines might want to be more like
Smalltalk images, this is again something that makes more sense in games
bigger than roguelikes. If a big C++ game takes 15 minutes to compile
and 2 minutes to load the game world, making small tweaks to the core
logic and seeing what has changed isn't nearly as much fun when you
can't do it when the game is running. But compared to big commercial
games, roguelikes probably don't have quite so drastic build times.
The biggest benefits in scripting languages are probably the higher
level of abstraction and dynamic typing. A clever use of a high-level
and dynamically typed language allows a programmer to implement the same
logic using fewer lines of code. And for a single developer, being able
to do things with a few lines of concise code instead of many lines is a
big win. C-style languages aren't very good at making things concise,
and single developers of big projects can feel this [2].
One problem seems to be just that C++ is a needlessly painful language.
Its successors like Java, C# and D, have the same statically typed
object oriented paradigm, but are in general a lot less painful to
program in. The problem of needing to type verbose type annotations for
statically typed programs was actually solved in 1978, but Java and C++
never got the memo and C# is just now getting a hang of this type
inference thing. Various ways to twist the core language into a
game-domain specific language by writing syntax tree transformers are
old tricks figured out by bearded men from the 70's, but C++ has again
been left in the dark. (D, on the other hand, seems to be getting into
this bandwagon as well as having supported type inference for a while
now.)
So we're left with the dynamic typing thing. This part is a bit tricky.
Most games consist of the algorithm part and the object model part, the
ratios of which can change. An abstract shooter has lots of algorithm
stuff and a simple object model. An interactive fiction game is almost
all object model. And a roguelike has both lots of algorithms and a
complex object model. I think that a good static type system (C++
doesn't have a good one, Haskell does) is just the way to go for
algorithms like line-of-sight, terrain generation or pathfinding. The
typing acts as an extra testing system and allows the compiler to
produce more efficient code.
The object system is a bit different. In a game, we've got a game world
with a bunch of objects that have both one or very few base types
(interchangeable objects, creatures or items in the virtual world), and
a huge spread of subclass-specific functionality. A pebble and an armored
knight on horseback are both physical objects in the game world, but the
amount of things the knight can do and have done to it are much, much
broader than those of the pebble. This is a problem for the strict
application of a static type system.
We don't want to have a huge interface specifying operations like 'doff
vambrace' for every game object. Instead, we need some sort of method
for querying whether a given game object supports the operation we're
interested in. Modern systems for this seem to be component-based ones,
where the base game object is a relatively simple one and contains a set
of named components. The object can the be queried for the "guy in
armor" component, which downcasts to GuyInArmorComponent class that
provides the DoffVambrace method [3]. A dynamic system would allow us to
get past the component-fetching and downcasting stuff and just send the
method to the object and catch an exception if the object doesn't
support it. On the other hand, we'd still need a component system, since
building game objects piecewise like that can actually work and not end
up in the rigid mess doing things with raw single or multiple
inheritance will lead to. So as far as I see, no big win for dynamic
typing here either. Incidentally, the component system seems to be a
major problem for using Objective CAML for programming games with
complex object models. It has objects, but the design seems to have a
principled objection to downcasting. So once you make the uniform
container of core component objects, there's no way to expand a
component acquired from there to its subclass type ever.
Another thing dynamically typed languages have is reflection, where you
can write code which looks at the insides of objects and classes of the
program. Thus far, the most significant use of reflection for games has
been making automatic save game systems. But again this doesn't seem to
be restricted to the scripting/dynamic language world. C++, D (for now)
and I'm guessing FreePascal don't have reflection, while Java and C# do
have it. There might be more you can do with reflection than save games
(see my "games should be more like Smalltalk images" idea), but I'm not
entirely sure what this would be.
So what's the conclusion? Scripting languages are more expressive than
C++, but this is more due to C++ being a clumsy language than to it not
being a scripting language. There are some ways that scripting languages
can be a big win, but they are more relevant to multi-developer projects
and massive online games than roguelikes. And scripting languages come
with the big hit of needing to maintain a code base in two languages
with a complex interface between them and different runtimes with
different failure modes and means of debugging (if the scripting
language even is debuggable). Still, if the base language must be C++,
many people seem to think that scripting languages are worth the
trouble.
[1] http://programming.reddit.com/info/62v70/comments/c02nqcu
[2] http://steve-yegge.blogspot.com/2007/12/codes-worst-enemy.html
[3] Chris Stoy: Game Object Component System in Game Programming Gems 6
is a good presentation of a component system.
--
Risto Saarelma
Gerry Quinn
4d6d26...@f3g2000hsg.googlegroups.com>,
torespon...@hotmail.com says...
> On Dec 30, 12:20 am, Darshan Shaligram <scinti...@gmail.com> wrote:
> > Windows' end-of-file silliness is just another aspect of silliness in
> > Windows. Blaming Python for it is... misdirected blame. :-)
>
> No, it is not. Python is fully capable of ignoring the windows
> silliness and making the quit Ctrl-D. Or perhaps supporting both if
> they feel more than 3 windows users would even consider using Ctrl-Z
> to quit a program. It is anything but standard in Windows. I've used
> Ctrl-Z to suspend more than I've used it as EOF.
Indeed, it's a console thing. Consoles in Windows are implemented only
for backward compatibility with MSDOS, as far as I am concerned.
- Gerry Quinn
--
Lair of the Demon Ape
http://indigo.ie/~gerryq/lair/lair.htm
Kenneth 'Bessarion' Boyd
> On 2007-12-30, Krice wrote:
> > I don't use scripting languages at all. I really can't see
> > how they would make it easier to create a roguelike game,
> > but maybe someone will tell me.
>
> One feature of scripting languages is the ease of modding the game or
> designing game features with little programming experience. ....
Yes. It's a good argument for bolting a scripting language in after completing
core development (when you know what data structures you're integrating
against).
And one can obviate maintainability issues by simply freezing the version of the
target scripting language. It just looks weird to do that.
> Somewhat more interesting is the possibility of parsing and evaluating
> script code when the program is running. This is just plain impossible
> when using a C-like language without resorting to unholy abominations
> [1].
Insofar as this is an advantage, it is even more so when writing *in* a
reasonable scripting language from the start (one that provides realtime
building and execution of source code). Self-modifying code is an unusual style
to consider for any project, however.
> ... The problem of needing to type verbose type annotations for
> statically typed programs was actually solved in 1978, but Java and C++
> never got the memo and C# is just now getting a hang of this type
> inference thing.
Your C++ information is a decade out of date for end-use programs (but is still
true for the libraries those end-use programs use). Judging from my own
projects, about 90% of this is covered in modern C++ between template functions
and the STL functional specification. The Boost libraries cover the remaining
10% (and let me assure you, the ability to choose the exact implementation of a
function at compile-time does wonders for erasing the slowness of C++ relative
to C).
I see little difference in complexity between the low-level implementation of a
dynamically typed system, and doing it explicitly in library headers. (To be
specific, I'm comparing against Perl 5's implementation.) The key in C++ is to
shove it in reusable library headers and intentionally design the usage to never
touch verbose type annotations.
> ... I think that a good static type system (C++
> doesn't have a good one, Haskell does) is just the way to go for
> algorithms like line-of-sight, terrain generation or pathfinding. The
> typing acts as an extra testing system and allows the compiler to
> produce more efficient code.
This extra testing system is very useful for any large project. Function
prototyping helps, but it just isn't enough.
> .... We don't want to have a huge interface specifying operations like 'doff
> vambrace' for every game object. Instead, we need some sort of method
> for querying whether a given game object supports the operation we're
> interested in. Modern systems for this seem to be component-based ones,
> where the base game object is a relatively simple one and contains a set
> of named components. The object can the be queried for the "guy in
> armor" component, which downcasts to GuyInArmorComponent class that
> provides the DoffVambrace method [3]. A dynamic system would allow us to
> get past the component-fetching and downcasting stuff and just send the
> method to the object and catch an exception if the object doesn't
> support it.
If one could be reasonably confident that only most-derived types were being
used (big if), in theory the Curiously Recurring Template Pattern shoves this
querying to compile-time rather than run time in C++. (It is somewhat intricate
to rig this to always compile when it should, of course: no reliable
compile-time reflection fragmentary features even with the Boost libraries).
Radomir 'The Sheep' Dopieralski
fbk wrote:
>> One of the big decisions we have made is to use a scripting language
>> for as much of the game as is reasonable.
> Considering that last sentence, I would go with python.
I agree with Kornel here -- if you want to use python, better make most
of the game in python and eventually maybe (if you are bored) rewrite
the really computationally-instensive parts in C if they prove to be slow.
But most of the time just rethinking the algorithm or the data structure
is enough.
> But if you start from scratch, I would consider using nothing but
> python. It has got excellent threading abilities and a vast standard
> library: Something you will not find in lua!
About threading, I would like to make two notes. First, threads are an
exceptionally tricky and hard to tame beast, that has chewed on many
programmers. The illusion of easily solving a problem is quickly dismissed
by various race conditions, locking problems and and randomly appearing
bugs, that may stay unnoticed until computers get 3x faster. On top of
that, I see no reason why a roguelike game would need threads for anything
-- even if it's a graphical game with animation.
Second, threads are not useful for improving performance of Python
programs, as there can be only one Python thread running at a time in an
instance of the interpreter -- they get switched every 100 instructions,
but only one of them is exected at a time -- at least for Python code,
this does not impact C library calls (if the wrapper is well written, at
least), so you can still thread on IO.
If you plan on using threads in Python, I would rather go with processes
-- they will run in parallel and have no silly shared memory.
--
Radomir `The Sheep' Dopieralski <http://sheep.art.pl>
() ascii ribbon campaign - against html e-mail
/\ <www.asciiribbon.org> - against proprietary attachments
Paul Donnelly
> On 2007-12-30, Krice <pau...@mbnet.fi> wrote:
>> I don't use scripting languages at all. I really can't see how they
>> would make it easier to create a roguelike game, but maybe someone will
>> tell me.
>
> So what's the conclusion? Scripting languages are more expressive than
> C++, but this is more due to C++ being a clumsy language than to it not
> being a scripting language.
Programmers somehow got the idea that Python, Perl, Ruby, and the like,
aren't "general purpose" programming languages, and less powerful
languages like C++ are. After getting this backwards, the obvious thing to
do was to come up with a name for languages that aren't "proper":
scripting languages. So now C, C++, and Java (if you're feeling generous)
are general purpose, slow but powerful languages are scripting languages,
and fast, powerful languages are never talked about or used. Go figure.
Christophe Cavalaria
Python 3.0 also known as Python 3000 is the version to break all code.
Python is an old language and the authors made quite a lot of what they
consider to be mistakes. They take the opportunity to fix as much as
possible that could break code with Python 3000. Although they still avoid
breaking things for the sake of it, they do not worry too much about that
either. People that install the new version shall not expect all existing
Python code to work out of the box. Yet again, changes will not be dramatic
enouth that porting the code will be difficult. I have been working on an
integrated Python 2.4 interpreter in a work app and we had no problems at
all when we fixed the behaviour of / to be the new one for all modules,
even those not using the future import. Not a single line of code broke in
the process.
What I wonder is if they'd go to the extreme of using a different file
extension just to mark the difference, and if it'd be easy to install both
versions of Python on a Unix system and have them cooperate :)
After all, that is what most Php hosts did when they "upgraded" it between 3
and 4. They install both the versions at the same time and redirect
the .php3 files to the old one and .php to the lastest version. Not sure
how they handled php 5 because I haven't been following that one yet.
Gerry Quinn
> If one could be reasonably confident that only most-derived types were being
> used (big if), in theory the Curiously Recurring Template Pattern shoves this
> querying to compile-time rather than run time in C++. (It is somewhat intricate
> to rig this to always compile when it should, of course: no reliable
> compile-time reflection fragmentary features even with the Boost libraries).
Better not to be obsessive about re-use, and use templates only where
massive re-use is guaranteed (libraries, essentially). The obscurity
of template code makes it best avoided if possible, even if that means
a little extra typing.
- Gerry Quinn
Gerry Quinn
donn...@sbcglobal.net says...
> On Mon, 31 Dec 2007 11:46:05 +0000, Risto Saarelma wrote:
>
> > On 2007-12-30, Krice <pau...@mbnet.fi> wrote:
> >> I don't use scripting languages at all. I really can't see how they
> >> would make it easier to create a roguelike game, but maybe someone will
> >> tell me.
> >
> > So what's the conclusion? Scripting languages are more expressive than
> > C++, but this is more due to C++ being a clumsy language than to it not
> > being a scripting language.
>
> Programmers somehow got the idea that Python, Perl, Ruby, and the like,
> aren't "general purpose" programming languages, and less powerful
> languages like C++ are.
I don't understand this comment. Everyone knows that Python is a (very
slow) general programming language, and would probably after a little
thought say the same of Ruby. Perl might be considered a text-
processing language, but I will accept that it is also general-purpose.
I'm not sure of your definition of 'powerful'. If the power of a
language refers to the possible functionality of programs written in it
on a given processor, Python is a weak language compared to C++,
because programs typically run 10-100 times slower, and therefore it is
useless for many applications.
> After getting this backwards, the obvious thing to
> do was to come up with a name for languages that aren't "proper":
> scripting languages. So now C, C++, and Java (if you're feeling generous)
> are general purpose, slow but powerful languages are scripting languages,
> and fast, powerful languages are never talked about or used. Go figure.
What "fast, powerful" languages do you refer to?
- Gerry Quinn
Risto Saarelma
> I'm not sure of your definition of 'powerful'. If the power of a
> language refers to the possible functionality of programs written in it
> on a given processor, Python is a weak language compared to C++,
> because programs typically run 10-100 times slower, and therefore it is
> useless for many applications.
The confusion here is that there are two qualities which both are said
to make a language powerful. One is expressiveness, being able to define
complex algorithms with few program tokens, and the other is the ability
to produce efficient executables. In practice, these qualities tend to
oppose each other. Expressivity is gained at the price of letting the
compiler or runtime come up with an inefficient way to accomplish what
the programmer intends.
On the part of the high-level languages, the confusion can be solved by
calling them expressive instead of powerful. Perhaps the C-style
languages could be called high-performance languages. Programmers
express, programs perform.
>> scripting languages. So now C, C++, and Java (if you're feeling generous)
>> are general purpose, slow but powerful languages are scripting languages,
>> and fast, powerful languages are never talked about or used. Go figure.
>
> What "fast, powerful" languages do you refer to?
I'm guessing languages from the ML family, SML and Objective CAML.
Possibly Haskell as well, although high-performance programming in
Haskell can be tricky due to the purely functional core language.
--
Risto Saarelma
Kenneth 'Bessarion' Boyd
> After all, that is what most Php hosts did when they "upgraded" it between 3
> and 4. They install both the versions at the same time and redirect
> the .php3 files to the old one and .php to the lastest version. Not sure
> how they handled php 5 because I haven't been following that one yet.
PHP5 was handled very differently. The design intention was that PHP5 shall run
PHP4 source completely unaltered, although the parsed representation is
completely incompatible. At least, until PHP4 stops being maintained entirely
(Jan 2008); after that PHP4 as a regression check on PHP5 will be dropped.
While I haven't done the hand verification that the enumerated list of truly
exotic breaking cases is exhaustive, there are many major applications
(phpMyAdmin, phpBB, and so on) that have had no difficulty using the same source
code for PHP4 and PHP5 for the past three years.
Most breakage is actually from not shipping the same modules (in particular, the
MySQL DB module was dropped from the core distribution).
Kenneth 'Bessarion' Boyd
> On 2008-01-01, Gerry Quinn wrote:
> > What "fast, powerful" languages do you refer to?
>
> I'm guessing languages from the ML family, SML and Objective CAML.
> Possibly Haskell as well, although high-performance programming in
> Haskell can be tricky due to the purely functional core language.
No comment about Haskell. I've done (archaic) ML programming on the side
before.
ML's primary advantages are making spaghetti code maintainable (due to
compensations for forbidding all loop constructs), and total immunity to stack
overflow. An ML implementation that compiles to machine rather than bytecode
can be fast because it doesn't have to worry about loops.
ML's function/operator overloading left much to be desired back in 1997.
Kenneth 'Bessarion' Boyd
> In article , paul-
> donn...@sbcglobal.net says...
> > On Mon, 31 Dec 2007 11:46:05 +0000, Risto Saarelma wrote:
> >
> > > On 2007-12-30, Krice wrote:
> > >> I don't use scripting languages at all. I really can't see how they
> > >> would make it easier to create a roguelike game, but maybe someone will
> > >> tell me.
> > >
> > > So what's the conclusion? Scripting languages are more expressive than
> > > C++, but this is more due to C++ being a clumsy language than to it not
> > > being a scripting language.
> >
> > Programmers somehow got the idea that Python, Perl, Ruby, and the like,
> > aren't "general purpose" programming languages, and less powerful
> > languages like C++ are.
>
> I don't understand this comment. Everyone knows that Python is a (very
> slow) general programming language, and would probably after a little
> thought say the same of Ruby. Perl might be considered a text-
> processing language, but I will accept that it is also general-purpose.
There is a tradeoff between machine time and programmer time. One extreme is Oz
(which allows directly coding nondeterministic algorithms).
Python is unusual in that it has a target domain (C-style text processing)
where, when used properly, it is as fast as competent C.
The speed hit is from overly general internal representations. Modern project
management might be able to eliminate this by making the required specialization
zoo maintainable.
> ....So now C, C++, and Java (if you're feeling generous)
> > are general purpose, slow but powerful languages are scripting languages,
> > and fast, powerful languages are never talked about or used. Go figure.
>
> What "fast, powerful" languages do you refer to?
Logic paradox. I can think of only one expressive language (ML) that counts
when compiled to machine, and the maintainers were so proud of ditching that
capability. (Self-building is a virtue in a language, only if the language
supports inline assembly. Otherwise, it's a platform lock.)
Of course, if you have the money you could have a custom-designed processor
whose opcodes are a specific language's bytecode representation. That'll make
C/C++ slow. (Now, if Parrot ever stabilizes *that* would be an interesting
marketing idea.)
Kenneth 'Bessarion' Boyd
> In article , zai...@zaimoni.com says...
>
> > If one could be reasonably confident that only most-derived types were being
> > used (big if), in theory the Curiously Recurring Template Pattern shoves this
> > querying to compile-time rather than run time in C++. (It is somewhat intricate
> > to rig this to always compile when it should, of course: no reliable
> > compile-time reflection fragmentary features even with the Boost libraries).
>
> Better not to be obsessive about re-use, and use templates only where
> massive re-use is guaranteed (libraries, essentially).
Yes, this is a low-reuse example. I'd start with a more normal noun-verb or
verb-noun router. If the architecture proved to be a debugging hot zone, I'd
consider converting to the Curiously Recurring Template Pattern; then the former
runtime bugs are compile time bugs.
> The obscurity
> of template code makes it best avoided if possible, even if that means
> a little extra typing.
As I find that heuristic invalid for the switch operator, what motive do I have
for considering that valid for template code? (Especially since the C++ STL
uses template metaprogramming so heavily that the C++ STL would have to be
obscure, for template metaprogramming to be obscure.)
Obvious practical reasons for avoiding template code are:
* template code kills both automatic type promotions and conflating derived
classes with base classes in reference parameters.
* template code always loses to exactly-matching functions.
* Just because you can hardcode loop bounds as template parameters, doesn't mean
it's worth bloating the object code that way.
* As an implementation detail, template code without a well-supported export
keyword has to be recompiled every single time. On top of this, bad linker
support can cause one copy of a template function in each compilation unit, even
though only one should be called.
Given the above, my rule of thumb is to use template code only when it
implements Once And Only Once.
Timofei Shatrov
confuse everyone with this message:
>> After getting this backwards, the obvious thing to
>> do was to come up with a name for languages that aren't "proper":
>> scripting languages. So now C, C++, and Java (if you're feeling generous)
>> are general purpose, slow but powerful languages are scripting languages,
>> and fast, powerful languages are never talked about or used. Go figure.
>
>What "fast, powerful" languages do you refer to?
Common Lisp, perhaps?
--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________|
Kenneth 'Bessarion' Boyd
> On Tue, 1 Jan 2008 13:46:55 -0000, Gerry Quinn tried to
> confuse everyone with this message:
>
> >> After getting this backwards, the obvious thing to
> >> do was to come up with a name for languages that aren't "proper":
> >> scripting languages. So now C, C++, and Java (if you're feeling generous)
> >> are general purpose, slow but powerful languages are scripting languages,
> >> and fast, powerful languages are never talked about or used. Go figure.
> >
> >What "fast, powerful" languages do you refer to?
>
> Common Lisp, perhaps?
Easy enough to check: "just" compile Urban War to machine rather than bytecode.
Gerry Quinn
> On 2008-01-01 14:40:11, Gerry Quinn <ger...@indigo.ie> wrote:
> > The obscurity
> > of template code makes it best avoided if possible, even if that means
> > a little extra typing.
>
> As I find that heuristic invalid for the switch operator, what motive do I have
> for considering that valid for template code?
If you find the switch operator obscure, you are very unusual.
> (Especially since the C++ STL
> uses template metaprogramming so heavily that the C++ STL would have to be
> obscure, for template metaprogramming to be obscure.)
It *is* obscure, but that doesn't matter because it's library code, and
therefore users don't have to read it.
Libraries are exactly where template code belongs.
- Gerry Quinn
Kenneth 'Bessarion' Boyd
> In article , zai...@zaimoni.com says...
> > On 2008-01-01 14:40:11, Gerry Quinn wrote:
>
> > > The obscurity
> > > of template code makes it best avoided if possible, even if that means
> > > a little extra typing.
> >
> > As I find that heuristic invalid for the switch operator, what motive do I have
> > for considering that valid for template code?
>
> If you find the switch operator obscure, you are very unusual.
I don't. Several C++ coding standards I have locally mirrored do for
inspiration and selective use not only do, they implicitly encourage template
metaprogramming while explicitly blacklisting normal ternary operator usage.
Paul Donnelly
> In article <pan.2008.01.01....@sbcglobal.net>, paul-
> donn...@sbcglobal.net says...
>> On Mon, 31 Dec 2007 11:46:05 +0000, Risto Saarelma wrote:
>>
>> > On 2007-12-30, Krice <pau...@mbnet.fi> wrote:
>> >> I don't use scripting languages at all. I really can't see how they
>> >> would make it easier to create a roguelike game, but maybe someone
>> >> will tell me.
>> >
>> > So what's the conclusion? Scripting languages are more expressive
>> > than C++, but this is more due to C++ being a clumsy language than to
>> > it not being a scripting language.
>>
>> Programmers somehow got the idea that Python, Perl, Ruby, and the like,
>> aren't "general purpose" programming languages, and less powerful
>> languages like C++ are.
>
> I don't understand this comment. Everyone knows that Python is a (very
> slow) general programming language, and would probably after a little
> thought say the same of Ruby. Perl might be considered a text-
> processing language, but I will accept that it is also general-purpose.
>
> I'm not sure of your definition of 'powerful'. If the power of a
> language refers to the possible functionality of programs written in it
> on a given processor, Python is a weak language compared to C++, because
> programs typically run 10-100 times slower, and therefore it is useless
> for many applications.
I hope you'll pardon me if I don't immediately answer this myself, but
instead quote Peter Norvig:
"There is a myth that Lisp and Prolog are "special purpose" languages,
while languages like Pascal and C are "general purpose." Actually, just
the reverse is true. Pascal and C are special-purpose languages for
manipulating the registers and memory of a von Neumann-style computer. The
majority of their syntax is devoted to arithmetic and Boolean expressions,
and while they provide some facilities for forming data structures, they
have poor mechanisms for procedural abstraction or control abstraction."
This is my position as well. It may be over-charitable to include Python
and its sluggish brethren in the same group as Lisp, Prolog, and
Smalltalk, but the "scripting languages" qualify more than C-style
languages do.
While Python may be useless for *many* applications, that doesn't mean
it's useless for *most* applications, unless you think that most
applications are built to do high-speed numerical processing or something.
To me, the power of a language has more to do with how much of my time it
wastes than with how fast my program could possibly run. The only thing
better than writing highly optimized code is knowing when not to. I don't
want to give the impression that I'm cavalier about efficiency, or that
I'm exactly happy with Python's performance, but I don't write much C for
the same reason I don't drive a racecar or move faster than the eye can
see when I reach for the table salt. My car would break and I would knock
everything off the table, and the same goes for programs I'd write in C. I
rate my tools by how much they extend my reach, and most of the time the
promise of "ultimate cosmic speed" doesn't buy me much.
>> After getting this backwards, the obvious thing to do was to come up
>> with a name for languages that aren't "proper": scripting languages. So
>> now C, C++, and Java (if you're feeling generous) are general purpose,
>> slow but powerful languages are scripting languages, and fast, powerful
>> languages are never talked about or used. Go figure.
>
> What "fast, powerful" languages do you refer to?
Common Lisp, as Timofei guessed, was near the front of my mind, but iirc
Smalltalk, while slower than Common Lisp, C, or C++, is fairly efficient
as well. It's certainly not slower than it is powerful, if that makes any
sense. There are probably others too, but since no one talks about them I
don't know of them, and even if I did I wouldn't be allowed to tell you.
You've probably noticed that I'm implicitly grouping C++ and, to a lesser
extent, Java in with C. While those languages do improve on C's safety in
some ways (a smaller need to deal directly with pointers, garbage
collection) and possibly on its power (I'm not sold on the OO
implementation in those languages, and I'm especially not a fan of
templates), I don't think they go above and beyond when it comes to
increasing my leverage like the languages on the other side of the line do.
Gerry Quinn
Then they are written by fuckwits.
> while explicitly blacklisting normal ternary operator usage.
What has that got to do with the switch operator?
- Gerry Quinn
Paul Donnelly
And then what?
Kenneth 'Bessarion' Boyd
> In article , zai...@zaimoni.com says...
> > On 2008-01-01 23:44:04, Gerry Quinn wrote:
> > > If you find the switch operator obscure, you are very unusual.
> >
> > I don't. Several C++ coding standards I have locally mirrored do for
> > inspiration and selective use not only do, they implicitly encourage template
> > metaprogramming
>
> Then they are written by ....
Take a look for yourself before jumping to conclusions:
http://www.codingstandard.com/HICPPCM/index.html
> > while explicitly blacklisting normal ternary operator usage.
>
> What has that got to do with the switch operator?
Same thing: ? : , as in (test_me) ? func1() : func2()
switch is a keyword, not an operator.
Kenneth 'Bessarion' Boyd
> On Tue, 01 Jan 2008 19:19:08 +0000, Kenneth 'Bessarion' Boyd wrote:
>
> > On 2008-01-01 19:38:32, gr...@mail.ru (Timofei Shatrov) wrote:
> >
> >> On Tue, 1 Jan 2008 13:46:55 -0000, Gerry Quinn tried to confuse
> >> >What "fast, powerful" languages do you refer to?
> >>
> >> Common Lisp, perhaps?
> >
> > Easy enough to check: "just" compile Urban War to machine rather than
> > bytecode.
>
> And then what?
And then play it.
I think the laggy screen updates and vulnerabilty to crashing from typing too
fast, are both are an artifact of compiling the LISP source to bytecode rather
than machine. I furthermore suspect that there would be no issues when compiled
to machine language.
Paul Donnelly
Ah. I had actually not tried the game until just now, so I wasn't aware of
those issues. I'm playing it now and not seeing either of them, so right
you may be about compiling it to native code. If I hold down a key for a
couple hundred turns nothing happens (except I may be killed if I'm moving
across the map, of course).
Keith H Duggar
> Gerry Quinn wrote:
> > The obscurity
> > of template code makes it best avoided if possible, even
> > if that means a little extra typing.
>
> As I find that heuristic invalid for the switch operator,
> what motive do I have > for considering that valid for
> template code? (Especially since the C++ STL uses template
> metaprogramming so heavily that the C++ STL would have to
> be obscure, for template metaprogramming to be obscure.)
First, the C/C++ switch is not an operator; it is a statement.
Second, while the C++ STL is an example of generic programming,
it does not employ template metaprogramming. Boost on the other
hand does employ metaprogramming. Not every use of the template
keyword is "metaprogramming". In fact, I would guess most uses
are not metaprogramming.
> Obvious practical reasons for avoiding template code are:
> * template code kills both automatic type promotions and
> conflating derived classes with base classes in reference
> parameters.
This makes no sense to me (the words "kills" and "conflating"
are not defined by C++ and have no clear meaning here. Please
provide a code example of what you are trying to say.
> * template code always loses to exactly-matching functions.
What do you mean by "loses"? If you are referring to overload
resolution, why would you want it any other way? How is this
a "practical reason for avoiding template code"?
> * As an implementation detail, template code without a well-
> supported export keyword has to be recompiled every single
> time.
This is wrong. First, the standard does not require that the
body of templates be present in every translation unit. Second,
even if it is (via header files etc) the compiler is free to
instantiate and compile the body once for each parameterization.
(Practically it /might/ be scanned repeatedly but not be parsed,
emitted, etc.) Third, explicit instantiation is certainly a
viable option for a limited code base such as a roguelike or
small app. This allows single translation unit instantiation
without the export keyword.
> On top of this, bad linker support can cause one copy of a
> template function in each compilation unit, even though only
> one should be called.
Explicit instantiation solves this problem and is still more
convenient than manual specification of overloads.
> Given the above, my rule of thumb is to use template code
> only when it implements Once And Only Once.
That does not make sense to me. Can you explain it in other
words please?
KHD
Paul Donnelly
> Second, while the C++ STL is an example of generic programming, it does
> not employ template metaprogramming. Boost on the other hand does employ
> metaprogramming. Not every use of the template keyword is
> "metaprogramming". In fact, I would guess most uses are not
> metaprogramming.
Sure they are. What is metaprogramming but writing code that writes code
for you?
Timofei Shatrov
<zai...@zaimoni.com> tried to confuse everyone with this message:
I did. So can you, the source is freely available. And man, is it fast! ;) Ok,
there is one SBCL related bug that I meant to fix for some time, but I'm now
working on a web application in CL that will totally kick ass.
Krice
> Common Lisp, as Timofei guessed, was near the front of my mind, but iirc
> Smalltalk, while slower than Common Lisp, C, or C++, is fairly efficient
> as well.
I think the most important reason that Lisp is a marginal
language is the syntax.. I mean, most of the exciting
languages that people suggest me as alternative to C++
have really cosmic syntax that no normal human can
possibly understand.
Gerry Quinn
> On 2008-01-02 04:10:53, Gerry Quinn <ger...@indigo.ie> wrote:
>
> > In article , zai...@zaimoni.com says...
> > > On 2008-01-01 23:44:04, Gerry Quinn wrote:
>
> > > > If you find the switch operator obscure, you are very unusual.
> > >
> > > I don't. Several C++ coding standards I have locally mirrored do for
> > > inspiration and selective use not only do, they implicitly encourage template
> > > metaprogramming
> >
> > Then they are written by ....
>
> Take a look for yourself before jumping to conclusions:
> http://www.codingstandard.com/HICPPCM/index.html
I don't see how it implicitly encourages template metaprogramming. It
includes some standards for it, true...
> > > while explicitly blacklisting normal ternary operator usage.
...but it also includes standards for the ternary operator (identical
to those for 'if', 'for', 'while' etc.
- Gerry Quinn
Krice
> And scripting languages come with the big hit of needing to
> maintain a code base in two languages with a complex interface
> between them
I call scripting an extra layer over the actual source
code. That's why I don't know why people use scripting.
Maybe it's something derived from linux world, you know,
making everything as complex as possible..
Paul Donnelly
As opposed to C++'s simple syntax? Tell me, what is the meaning of
x * y(z)
in C++? I don't have the faintest idea. :) I catch your meaning with
regard to Lisp's unconventional syntax, but in my opinion the biggest
problem is how poorly most programmers are introduced to it. It's all
"Car, cdr, recursion!" The whole point of Lisp is that you don't have to
write that stuff -- not more than once anyway. Teaching Lisp as a real
language rather than an intentionally difficult academic curiosity would
do a lot for its acceptance, in my opinion.
Martin Read
>As opposed to C++'s simple syntax? Tell me, what is the meaning of
>
>x * y(z)
>
>in C++? I don't have the faintest idea. :)
The meaning of
x * y(z)
in C++ is that someone needs to be beaten over the head with a style
guide and a copy of Stroustrup's TC++PL.
--
\_\/_/ some girls wander by mistake into the mess that scalpels make
\ / are you the teachers of my heart? we teach old hearts to break
\/ --- Leonard Cohen, "Teachers"
Krice
> Tell me, what is the meaning of
>
> x * y(z)
>
> in C++? I don't have the faintest idea. :)
What is x * y(z)? Looks like math.
Kenneth 'Bessarion' Boyd
> Kenneth 'Bessarion' Boyd wrote:
> > Gerry Quinn wrote:
> > > The obscurity
> > > of template code makes it best avoided if possible, even
> > > if that means a little extra typing.
> >
> > As I find that heuristic invalid for the switch operator,
> > what motive do I have > for considering that valid for
> > template code? (Especially since the C++ STL uses template
> > metaprogramming so heavily that the C++ STL would have to
> > be obscure, for template metaprogramming to be obscure.)
>
> First, the C/C++ switch is not an operator; it is a statement.
? : has been called the switch operator as far back as K&R C.
> Second, while the C++ STL is an example of generic programming,
> it does not employ template metaprogramming. Boost on the other
> hand does employ metaprogramming. Not every use of the template
> keyword is "metaprogramming". In fact, I would guess most uses
> are not metaprogramming.
I have to disagree here. Boost makes it easier (by providing standardized ways
of conditionally defining functions, automatically grabbing appropriate types
for parameters of functions, and so on).
The decision that it is not worth the programmer's time to cut-and-paste the
definition of a function indefinitely, is the decision to metaprogram rather
than program. It's simply much easier to do this in LISP, etc than in a
moderately staticly typed language.
> > Obvious practical reasons for avoiding template code are:
> > * template code kills both automatic type promotions and
> > conflating derived classes with base classes in reference
> > parameters.
>
> This makes no sense to me (the words "kills" and "conflating"
> are not defined by C++ and have no clear meaning here.
They are well-defined in vernacular English; my statement is an immediate
consequence of template parameters having to exactly match before
instantiation.
> > * template code always loses to exactly-matching functions.
>
> What do you mean by "loses"? If you are referring to overload
> resolution, why would you want it any other way? How is this
> a "practical reason for avoiding template code"?
Yes, I am referring to template resolution.
At best, source code that is never referred to is confusing. At worst, it's a
semantic error.
> > * As an implementation detail, template code without a well-
> > supported export keyword has to be recompiled every single
> > time.
>
> This is wrong. First, the standard does not require that the
> body of templates be present in every translation unit.
Which is why I specified "without a well-supported export keyword". Comeau does
have proper support of the export keyword. Without export, the standards do
require exactly that -- where the template is instantiated.
> Second, even if it is (via header files etc) the compiler is free to
> instantiate and compile the body once for each parameterization.
True, but I can't think of a compiler that actually does so over multiple
compilation units.
> ... Third, explicit instantiation is certainly a
> viable option for a limited code base such as a roguelike or
> small app.
There is no such thing (currently) as a successful small roguelike.
Explicit instantiation has legitimate uses, e.g. library code where user code
must not know the template even exists. In those cases, the requirements make
the impaired maintainability from explicit template instantiation a necessary
evil.
> > Given the above, my rule of thumb is to use template code
> > only when it implements Once And Only Once.
>
> That does not make sense to me. Can you explain it in other
> words please?
It's an Extreme Programming mnemonic for "defining the same thing more than
once, is a semantic error because it impairs maintainability."
Kenneth 'Bessarion' Boyd
> In article , zai...@zaimoni.com says...
> > > > while explicitly blacklisting normal ternary operator usage.
>
> . ..but it also includes standards for the ternary operator (identical
> to those for 'if', 'for', 'while' etc.
It is fairly deep down, but the entry 10.20 appears to prohibit many normal uses
of the ternary/switch operator. In particular, it prohibits these expressions
as function parameters. (Which is why I did not import that particular standard
into my in-house one.)
Norbert Melzer
> On Wed, 02 Jan 2008 06:16:36 -0800, Krice wrote:
>
>> On 2 tammi, 04:27, Paul Donnelly <paul-donne...@sbcglobal.net> wrote:
>>> Common Lisp, as Timofei guessed, was near the front of my mind, but iirc
>>> Smalltalk, while slower than Common Lisp, C, or C++, is fairly efficient
>>> as well.
>>
>> I think the most important reason that Lisp is a marginal
>> language is the syntax.. I mean, most of the exciting
>> languages that people suggest me as alternative to C++
>> have really cosmic syntax that no normal human can
>> possibly understand.
>
> As opposed to C++'s simple syntax? Tell me, what is the meaning of
>
> x * y(z)
>
> in C++? I don't have the faintest idea. :)
Simple... Multiply the content of the variable "x" with the result of the
function named "y" given the content of the variable named "z" to it. Oh...
And then forget the result. So this line makes not really sense.
And the thing with the styleguid like Martin said is true too.
IIRC the line translated to lisp would be something like:
(* x (y z) )
Either in C nor in Lisp this code "speaks".
So I would prefer some code like the following (in c of course):
/** Returns the sinus of the given parameter.
*
* @param angle The angle in degrees. 0..359
* @return The sinus of angle
*/
double sin ( double angle )
{
/// @todo add working code here
return something :-)
}
double result = anUselessVar * sin ( anotherUselessVar );
MUch better readable than your example, but more space on harddisk. But you
have to admit to that undocumentet source is bad in ANY language, even
naturaly speaking :-)
Bye
Norbert
Risto Saarelma
> I think the most important reason that Lisp is a marginal
> language is the syntax.. I mean, most of the exciting
> languages that people suggest me as alternative to C++
A bit more prosaic problem is that there doesn't seem to be a free
Common Lisp that produces high-performance native code executables that
run in Windows. As far as I've understood, SBCL is the main free Common
Lisp implementation that compiles to native code, and it apparently uses
some black magic to accomplish this which makes it very difficult to
port to Windows. CLISP runs in Windows, but it only compiles to
bytecode, and appears to have significantly less performance than SBCL.
Although there is some perverse elegance in the idea of a game that runs
much faster on Mac OS X and Linux than on Windows, Common Lisp still
seems like a bit of a limiting move here.
--
Risto Saarelma
Risto Saarelma
> Am Wed, 02 Jan 2008 14:41:12 GMT schrieb Paul Donnelly:
>> As opposed to C++'s simple syntax? Tell me, what is the meaning of
>>
>> x * y(z)
>
> function named "y" given the content of the variable named "z" to it. Oh...
> And then forget the result. So this line makes not really sense.
Unless x is an object which has overloaded the operator '*', in which
case this can do anything at all, if the overloading is something
strange.
If we can't count on sanitary programming, we can't tell much about an
having a something that looks like a throw-away expression as a
statement. After all the second line in
int x = 0;
x << 2;
is a similar nonsensical statement that just evaluates an expression and
throws away the result, while the second line in
std::ostream& x = std::cout;
x << 2;
uses the standard way to print the string representation of 2 to stdout
and is quite meaningful as a statement.
I'm not sure if this was the idea of the original message about the syntax
of C++ not necessarily being simple.
--
Risto Saarelma
Paul Donnelly
> On 2008-01-02, Krice <pau...@mbnet.fi> wrote:
>> I think the most important reason that Lisp is a marginal language is
>> the syntax.. I mean, most of the exciting languages that people suggest
>> me as alternative to C++
>
> A bit more prosaic problem is that there doesn't seem to be a free
> Common Lisp that produces high-performance native code executables that
> run in Windows.
This is true, however it depends on how much you really need to do.
There's absolutely no reason you couldn't implement a roguelike that ran
acceptably in CLISP. You might have to cut things like real-time lighting
with mirrors and prisms (an important feature) from your game, but making
little ascii guys wander around a dungeon and fight each other is not
intrinsically taxing. I understand from this thread that Urban Warfare is
sluggish in CLISP, but it has an ambitious world model and has not been
extensively optimized, as far as I can tell from a quick grep for
telltales and the fact that it was written in just a week. If that's what
you're basing your speed estimate on, it's probably more pessimistic than
it needs to be.
> As far as I've understood, SBCL is the main free Common Lisp
> implementation that compiles to native code, and it apparently uses some
> black magic to accomplish this which makes it very difficult to port to
> Windows. CLISP runs in Windows, but it only compiles to bytecode, and
> appears to have significantly less performance than SBCL.
This is true as well. ECL is another option for cross-platform delivery.
It can even be embedded in C/C++ programs as an extension language. I'm
seriously considering my game up and running in it when I have something
to distribute.
> Although there is some perverse elegance in the idea of a game that runs
> much faster on Mac OS X and Linux than on Windows,
Sounds like business as usual to me.
> Common Lisp still seems like a bit of a limiting move here.
To some extent, yes. There's no obvious "compile and away you go"
solution, but neither is it extremely difficult to get a program out the
door in Lisp. I wouldn't let (and am not letting) my fear of distribution
issues stop me from using Lisp.
Paul Donnelly
> Am Wed, 02 Jan 2008 14:41:12 GMT schrieb Paul Donnelly:
>
>> On Wed, 02 Jan 2008 06:16:36 -0800, Krice wrote:
>>
>>> On 2 tammi, 04:27, Paul Donnelly <paul-donne...@sbcglobal.net> wrote:
>>>> Common Lisp, as Timofei guessed, was near the front of my mind, but iirc
>>>> Smalltalk, while slower than Common Lisp, C, or C++, is fairly efficient
>>>> as well.
>>>
>>> I think the most important reason that Lisp is a marginal
>>> language is the syntax.. I mean, most of the exciting
>>> languages that people suggest me as alternative to C++
>>> have really cosmic syntax that no normal human can
>>> possibly understand.
>>
>> As opposed to C++'s simple syntax? Tell me, what is the meaning of
>>
>> x * y(z)
>>
>> in C++? I don't have the faintest idea. :)
>
> Simple... Multiply the content of the variable "x" with the result of the
> function named "y" given the content of the variable named "z" to it. Oh...
> And then forget the result. So this line makes not really sense.
No, silly, I'm declaring a pointer named y. Or basically anything, since
the operator may be overloaded, but I doubt most C++ programmers would
confuse things even further.
Paul Donnelly
Nope, it's memory management.
Krice
> Nope, it's memory management.
Nope, it's wacky language syntax.
awhite
[on the context-free meaning of x * y(z) in c++]
> On 3 tammi, 00:32, Paul Donnelly <paul-donne...@sbcglobal.net> wrote:
>> Nope, it's memory management.
>
> Nope, it's wacky language syntax.
Yep, it's both; it's the wacky language syntax inherent to C++ and C.
x * y(z) could be:
1) a function declaration (void *func(int))
2) object construction (int *bob(ptr_to_other_bob_object))
3) multiplication (height * getwidth(object))
5) ... other? I think that's it.
Adam
Keith H Duggar
> Keith H Duggar wrote:
> > Kenneth 'Bessarion' Boyd wrote:
> > > As I find that heuristic invalid for the switch operator,
> > > what motive do I have > for considering that valid for
> > > template code? (Especially since the C++ STL uses template
> > > metaprogramming so heavily that the C++ STL would have to
> > > be obscure, for template metaprogramming to be obscure.)
>
> > First, the C/C++ switch is not an operator; it is a statement.
>
> ? : has been called the switch operator as far back as K&R C.
What references do you have that support that claim?
> > Second, while the C++ STL is an example of generic programming,
> > it does not employ template metaprogramming. Boost on the other
> > hand does employ metaprogramming. Not every use of the template
> > keyword is "metaprogramming". In fact, I would guess most uses
> > are not metaprogramming.
>
> The decision that it is not worth the programmer's time to cut-and
> -paste the definition of a function indefinitely, is the decision
> to metaprogram rather than program. It's simply much easier to do
> this in LISP, etc than in a moderately staticly typed language.
By your reasoning (and literally by your words) even a non
template function is a metaprogram since it avoids pasting
the function code again and again. This is, of course, BS.
If you want to claim the word metaprogramming as a synonym
for "programming" and the phrase template metaprogramming
as a synonym for "template programming" (because you think
it's l33t to throw "meta" around) go ahead. But understand
that when the C++ community as a whole refers to template
metaprogramming it means techniques more specific than
just using the keyword "template". (I'm basing this broad
claim on every article, book, discussion, conference, and
seminar I've ever read or been party to.)
> > > * template code always loses to exactly-matching functions.
>
> > What do you mean by "loses"? If you are referring to overload
> > resolution, why would you want it any other way? How is this
> > a "practical reason for avoiding template code"?
>
> Yes, I am referring to template resolution.
>
> At best, source code that is never referred to is confusing.
> At worst, it's a semantic error.
Writing code that is never used has nothing to do with it
being templated or not. Just as if you wrote an overload
and then never used it. So again, how is this a "practical
reason for avoiding template code"? Please provide a code
example as I'm finding your vernacular curiously obtuse.
> > > * As an implementation detail, template code without a well-
> > > supported export keyword has to be recompiled every single
> > > time.
>
> > This is wrong. First, the standard does not require that the
> > body of templates be present in every translation unit.
>
> Which is why I specified "without a well-supported export keyword".
> Comeau does have proper support of the export keyword. Without export,
> the standards do require exactly that -- where the template is
> instantiated.
No it does not require "exactly that" if "that" is your claim that
"[the] template code ... has to be recompiled every single time."
That is simply flat wrong. It must only be scanned (ie tokenized)
to verify the one-definition-rule is not violated.
> > Second, even if it is (via header files etc) the compiler is free to
> > instantiate and compile the body once for each parameterization.
>
> True, but I can't think of a compiler that actually does so over multiple
> compilation units.
IIRC Comeau (which you mentioned) does along with the HP,
Sun, and even Cfront compilers.
> > ... Third, explicit instantiation is certainly a viable
> > option for a limited code base such as a roguelike or
> > small app.
>
> There is no such thing (currently) as a successful small
> roguelike.
For roguelike I said limited not small. By limited I had
in mind certain things regarding number of types, number of
developers, design scope, development cycle, etc.
> > > Given the above, my rule of thumb is to use template code
> > > only when it implements Once And Only Once.
>
> > That does not make sense to me. Can you explain it in other
> > words please?
>
> It's an Extreme Programming mnemonic for "defining the same
> thing more than once, is a semantic error because it impairs
> maintainability."
This still makes no sense to me from a C++ perspective. Please
provide a code example showing code that you would not templatize
because it does not "implement Once And Only Once".
Also, I think the word "semantic" does not mean what you think
it means. Because "impairs maintainability" has nothing to do
with semantics and is certainly not a "semantic error" in the
C++ or even general computer science sense.
KHD
Kenneth 'Bessarion' Boyd
> Kenneth 'Bessarion' Boyd wrote:
> > Keith H Duggar wrote:
> > > Kenneth 'Bessarion' Boyd wrote:
> > > > As I find that heuristic invalid for the switch operator,
> > > > what motive do I have > for considering that valid for
> > > > template code? (Especially since the C++ STL uses template
> > > > metaprogramming so heavily that the C++ STL would have to
> > > > be obscure, for template metaprogramming to be obscure.)
> >
> > > First, the C/C++ switch is not an operator; it is a statement.
> >
> > ? : has been called the switch operator as far back as K&R C.
>
> What references do you have that support that claim?
Online, rather than hardcopy C books from the 1970's? Not in Top 100 Google.
Getting back to 1999 is easy enough:
http://www.cs.berkeley.edu/~lazzaro/sa/book/saol/exstat/index.html , copyright
1999, uses definition of ? : straight from C as "switch operator" for a proposed
programming language for MPEG-4 audio.
> > The decision that it is not worth the programmer's time to cut-and
> > -paste the definition of a function indefinitely, is the decision
> > to metaprogram rather than program. It's simply much easier to do
> > this in LISP, etc than in a moderately staticly typed language.
>
> By your reasoning (and literally by your words) even a non
> template function is a metaprogram since it avoids pasting
> the function code again and again. This is, of course, BS.
And intentionally misreading what I write, two consecutive replies in a row,
isn't? [That, incidentally, is why I'm not replying to most of of your reply.
I do have both the C++97 and C++0x standards locally on my hard drive; you are
right on tokenization being enough to check the C++ one-definition
well-definedness rule, but otherwise mostly contradict both.]
> > > ... Third, explicit instantiation is certainly a viable
> > > option for a limited code base such as a roguelike or
> > > small app.
> >
> > There is no such thing (currently) as a successful small
> > roguelike.
>
> For roguelike I said limited not small. By limited I had
> in mind certain things regarding number of types, number of
> developers, design scope, development cycle, etc.
Which presumably excludes: Nethack, Crawl Stone Soup, T.o.M.E.
> > > > Given the above, my rule of thumb is to use template code
> > > > only when it implements Once And Only Once.
> >
> > > That does not make sense to me. Can you explain it in other
> > > words please?
> >
> > It's an Extreme Programming mnemonic for "defining the same
> > thing more than once, is a semantic error because it impairs
> > maintainability."
>
> This still makes no sense to me from a C++ perspective. Please
> provide a code example showing code that you would not templatize
> because it does not "implement Once And Only Once".
Logic paradox, *and* inciting spamming the newsgroup. No.
Cf. http://www.c2.com/cgi/wiki?OnceAndOnlyOnce for an inductive definition.
Perhaps I should get Skirmish 0.0.0 from the vaporware family to a releasable
state, as that does use classes (strictly, structs) that do not need
templatization to attain Extreme Programming "Once And Only Once".
* Item, Item_historical, Agent, Agent_historical : do not expect to reuse
between games effectively. Just the structure names and public base
relationships.
* LogicalSide: can't template because of a design requirement that it be one
byte in size. This requirement is enforced by a BOOST_STATIC_ASSERT pending
compiler support. As I don't see how I'm going to legitimately use more than 15
species or 15 intra-species factions in a single game, using bitfields to stuff
both into a single (8-bit) byte doesn't look like that big a restriction.
Juho Julkunen
0000 (UTC), Kenneth 'Bessarion' Boyd <zai...@zaimoni.com> says...
> On 2008-01-03 06:08:31, Keith H Duggar <dug...@alum.mit.edu> wrote:
> > > > First, the C/C++ switch is not an operator; it is a statement.
> > >
> > > ? : has been called the switch operator as far back as K&R C.
> >
> > What references do you have that support that claim?
>
> Online, rather than hardcopy C books from the 1970's? Not in Top 100 Google.
Yeah, all the articles about switcing an operator clutter up the
search. 'ternary "switch operator"' gets 49 hits (first couple from
this thread), though it still gets "switch ( operator )" hits.
'ternary "conditional operator"' gets 10000+ hits.
I don't have original K&R, but Ansi C edition (1988) doesn't refer to a
"switch operator", only "switch statement" and "conditional operator".
> Getting back to 1999 is easy enough:
> http://www.cs.berkeley.edu/~lazzaro/sa/book/saol/exstat/index.html , copyright
> 1999, uses definition of ? : straight from C as "switch operator" for a proposed
> programming language for MPEG-4 audio.
Well, SAOL guide from 1999 isn't exactly a C book from 1978, is it?
--
Juho Julkunen
Paul Donnelly
That was pretty much the message. I could have equally well gone with the
overloading of <<, although that's C++ specific and is something most C++
programmers are trained to look out for too, so it wouldn't make the point
as well. My point being that if you're looking for a poster boy for easy,
rational syntax, C++ is not your man.
Kenneth 'Bessarion' Boyd
> In article , on Thu, 3 Jan 2008 06:48:58 +
> 0000 (UTC), Kenneth 'Bessarion' Boyd says...
> > On 2008-01-03 06:08:31, Keith H Duggar wrote:
>
> > > > > First, the C/C++ switch is not an operator; it is a statement.
> > > >
> > > > ? : has been called the switch operator as far back as K&R C.
> > >
> > > What references do you have that support that claim?
> >
> > Online, rather than hardcopy C books from the 1970's? Not in Top 100 Google.
>
> Yeah, all the articles about switcing an operator clutter up the
> search. 'ternary "switch operator"' gets 49 hits (first couple from
> this thread), though it still gets "switch ( operator )" hits.
As in "operator is the variable name being switched on".
> I don't have original K&R, but Ansi C edition (1988) doesn't refer to a
> "switch operator", only "switch statement" and "conditional operator".
I noticed the same thing in the C99 standard. I'm mildly curious how the usage
got injected at all. [I learned it from the Borland Turbo C 3.0 documentation
(although at this distance it could have been hardcopy rather than in-program),
and was not corrected by either the MSVC++ 2.0 or MSVC++ 4.0 docs as shipped
with the CD-ROMs.]
> > Getting back to 1999 is easy enough:
> > http://www.cs.berkeley.edu/~lazzaro/sa/book/saol/exstat/index.html , copyright
> > 1999, uses definition of ? : straight from C as "switch operator" for a proposed
> > programming language for MPEG-4 audio.
>
> Well, SAOL guide from 1999 isn't exactly a C book from 1978, is it?
Agreed, but it does demonstrate the usage when talking about C is merely
archaic. (My first use of a C compiler was what, 1986 AD/CE?).
Keith H Duggar
> Juho Julkunen wrote:
> > I don't have original K&R, but Ansi C edition (1988) doesn't refer to a
> > "switch operator", only "switch statement" and "conditional operator".
>
> I noticed the same thing in the C99 standard. I'm mildly
> curious how the usage got injected at all.
Injected where, your mind? Because so far that is the only
placed it's been injected (other than a website from 1999
whose author shares the same incorrect vocabulary).
> [I learned it from the Borland Turbo C 3.0 documentation
> (although at this distance it could have been hardcopy
> rather than in-program), and was not corrected by either
> the MSVC++ 2.0 or MSVC++ 4.0 docs as shipped with the
> CD-ROMs.]
Or perhaps your memory of them is flawed. Have you checked
the docs to confirm this new claim?
> > > Getting back to 1999 is easy enough:
> > >http://www.cs.berkeley.edu/~lazzaro/sa/book/saol/exstat/index.html, copyright
> > > 1999, uses definition of ? : straight from C as "switch operator" for a proposed
> > > programming language for MPEG-4 audio.
>
> > Well, SAOL guide from 1999 isn't exactly a C book from 1978, is it?
>
> Agreed, but it does demonstrate the usage when talking
> about C is merely archaic. (My first use of a C compiler
> was what, 1986 AD/CE?).
Ah no ... it only demonstrates that another person used
the same mistaken vocabulary. Let me ask you this: from now
on are you going to refer to it as either the "conditional"
or "ternary" operator or you going to keep calling it the
"switch operator" sowing further confusion?
KHD
Keith H Duggar
> Keith H Duggar wrote:
> > Kenneth 'Bessarion' Boyd wrote:
>
> > > The decision that it is not worth the programmer's time to cut-and
> > > -paste the definition of a function indefinitely, is the decision
> > > to metaprogram rather than program. It's simply much easier to do
> > > this in LISP, etc than in a moderately staticly typed language.
>
> > By your reasoning (and literally by your words) even a non
> > template function is a metaprogram since it avoids pasting
> > the function code again and again. This is, of course, BS.
>
> And intentionally misreading what I write, two consecutive
> replies in a row, isn't?
Fascinating, you now claim to know my intentions. Perhaps it's
simply, as I previously stated, that to me your vernacular is
obtuse. That is precisely why I've requested code samples, for
example.
> [That, incidentally, is why I'm not replying to most of of
> your reply.]
Uh huh, sure. A convenient albeit a manufactured excuse.
> I do have both the C++97 and C++0x standards locally on my
> hard drive;
Congratulations.
> you are right on tokenization being enough to check the C++
> one-definition well-definedness rule, but otherwise mostly
> contradict both.]
To me the only obvious way to parse that final clause is "but
[you] otherwise mostly contradict both [standards]". If that
is the correct then I say this: it is easy and vacuous to make
such claims; it is more difficult to substantiate them (ex the
"switch operator" claim). So prove it.
> > > It's an Extreme Programming mnemonic for "defining the same
> > > thing more than once, is a semantic error because it impairs
> > > maintainability."
>
> > This still makes no sense to me from a C++ perspective. Please
> > provide a code example showing code that you would not templatize
> > because it does not "implement Once And Only Once".
>
> Logic paradox
Yet another unsupported and unlikely claim; prove it.
> *and* inciting spamming the newsgroup. No.
Only if your are incapable of providing concise examples.
Are you incapable?
> Perhaps I should get Skirmish 0.0.0 from the vaporware family to a releasable
> state, as that does use classes (strictly, structs) that do not need
> templatization to attain Extreme Programming "Once And Only Once".
Perhaps now I finally understand what you meant by:
"Given the above, my rule of thumb is to use template
code only when it implements Once And Only Once."
did you mean:
"... my rule of thumb is to use template code only when
it helps one code a Once-And-Only-Once implementation."
?
> * Item, Item_historical, Agent, Agent_historical : do not expect to reuse
> between games effectively. Just the structure names and public base
> relationships.
> * LogicalSide: can't template because of a design requirement that it be one
> byte in size. This requirement is enforced by a BOOST_STATIC_ASSERT pending
> compiler support. As I don't see how I'm going to legitimately use more than 15
> species or 15 intra-species factions in a single game, using bitfields to stuff
> both into a single (8-bit) byte doesn't look like that big a restriction.
In what way is the above relevant to our discussion?
KHD
Kenneth 'Bessarion' Boyd
> Kenneth 'Bessarion' Boyd wrote:
> > Keith H Duggar wrote:
> > > Kenneth 'Bessarion' Boyd wrote:
> >
> > > > The decision that it is not worth the programmer's time to cut-and
> > > > -paste the definition of a function indefinitely, is the decision
> > > > to metaprogram rather than program. It's simply much easier to do
> > > > this in LISP, etc than in a moderately staticly typed language.
> >
> > > By your reasoning (and literally by your words) even a non
> > > template function is a metaprogram since it avoids pasting
> > > the function code again and again. This is, of course, BS.
> >
> > And intentionally misreading what I write, two consecutive
> > replies in a row, isn't?
>
> Fascinating, you now claim to know my intentions. ....
The wild excursion into who reads standards more clearly merely provides
confidence that you are qualified to reply. Said qualification rules out all
other potential intentions.
That is, you *do* know that while collating practically identical code fragments
into a function is "the same kind" of text manipulation as collating practically
identical function/class definitions into a template function/class, that it is
*not* the same because functions are one level of abstraction above the source
code defining them.
Metaprogramming is to functional programming what functional programming is to
"one huge main()". LISP, Haskell, and Smalltalk make this easy. C++ needs a
complicated syntax because it has moderately strong static typing.
(As for obtuseness: one of my literary style models is Ayn Rand. Failing to
correct her flaws will do it every time)
> > *and* inciting spamming the newsgroup. No.
>
> Only if your are incapable of providing concise examples.
See below:
> > * Item, Item_historical, Agent, Agent_historical : do not expect to reuse
> > between games effectively. Just the structure names and public base
> > relationships.
> > * LogicalSide: can't template because of a design requirement that it be one
> > byte in size. This requirement is enforced by a BOOST_STATIC_ASSERT pending
> > compiler support. As I don't see how I'm going to legitimately use more than 15
> > species or 15 intra-species factions in a single game, using bitfields to stuff
> > both into a single (8-bit) byte doesn't look like that big a restriction.
>
> In what way is the above relevant to our discussion?
It's the design rationale behind the requested code examples.
Gerry Quinn
81d89a...@i12g2000prf.googlegroups.com>, pau...@mbnet.fi says...
But the layers are present in any rational game architecture anyway.
Using different languages for different layers is therefore feasible,
and may be attractive if their advantages for the particular level are
sufficient. (For example, if C gives you fast FOV calculations and
graphical animations, whereas Lua makes it easier to design spells and
script events.)
On the other hand, writing a roguelike entirely in one language is also
perfectly feasible, and I would guess the majority are so written.
People well versed in low-level languages are able to use them to
perform tasks better suited to scripting languages without much
difficulty.
- Gerry Quinn