gamedevlists-general — List for discussing general game development issues

RE: [GD-General] Eiffel

[Philip H. <ph...@me...>]

> > That's a great list of problems with Windows but the 
> majority if not 
> > all of them only apply to 99.99% of users.
> 
> I'm fairly sure that's not what you meant.

:-) Well, at least someone's sure.

> Small trivial example, which is rather outside of my GUI 
> preferences (eg no icons).  My typical idle state has ~20 
> windows on my desktop. When actively working that tends to 
> rise quickly to 50+ with values close to 100 not being 
> unseen.  This is a side effect of a way of working that I 

I can see why that would cause problems under windows although I would
guess that your multiple Emacs frames would be one window with a lot of
children on Windows. It's interesting (at least to me) that you find
that sort of environment so efficient. I tend to work the opposite way,
the less windows, files and apps open at any one time the quicker things
move along. Perhaps it's Windows imposing its will on me...

> Hehn.  Not a question of stopping, but a question of 
> difficulty versus reward for the sorts of problems I consider 
> interesting for me to solve.  Within that space Windows 
> doesn't win, and most specifically, seems to enforce 
> unacceptable contortions without delivering any increased 
> productivity, value, insight, effectiveness, or anything else 
> of value (to me) for the trouble.

Obviously your approach works very well for you. Do you know of other
people who work the same way? Is it an apporach you've been using a long
time or it still evolving? Note, I'm not suggesting that Windows is the
magic efficiency bullet, or that you should even consider using it. I'm
just interested because that sort of approach doesn't seem efficient to
me at all. 
 
Phil

RE: [GD-General] dev environments

[Philip H. <ph...@me...>]

> > Similarly there's many types of game where it's inefficient to run 
> > cross platform on the Mac.
> 
> Having done quite a bit of cross development work for 
> Mac/Windows, what types of games do you think are not 
> appropriate on the Mac?  I'm not disputing the claim - just 
> curious about your opinions.

I didn't phrase that very well, specifically I mean most console games. 
 
> Absolutely - one really nice tool I used in the past was 
> Resourcerer. It provided an environment for editing data 
> structures that only required a simple definition of how that 
> structure should be represented on disk. That, combined with 
> a spreadsheet for raw data, provided almost all the tooling 
> we needed for game development.

Sounds interesting, was this a Mac tool?
 
> > Given that we're considering porting a couple of titles to 
> the Mac I 
> > may have the opportunity to try out your suggestions in the future.
> 
> Will this be OS X only or will you support older versions of 
> the OS? Many modern games do not port well to older Mac OS 
> versions.  This is especially true for games that rely on 
> virtual memory and file i/o performance.

It will be modern Macs only although I couldn't tell you exactly which
ones yet :)

Phil

RE: [GD-General] dev environments

[Philip H. <ph...@me...>]

> Mostly interface building and maintenance issues (once you build the 
> interface, you can change it later trivially as long as you 
> adhere to the 
> MVC paradigm...I never found AppWizard to be nearly as good in that 

In that case it probably wouldn't benefit me as much as it does you. I
don't find MFC gets in the way, building and maintaining the GUI for the
tools is a relatively small part of tool development for me. 

> >Similarly there's many types of game where it's inefficient to run 
> >cross platform on the Mac.
> 
> Er, maybe console games, 

Exactly, I didn't phrase that very well, sorry.

> >That depends entirely on your GUI library, if the desktop 
> can give you 
> >lots of windows or high resolution then what's to stop the 
> game doing 
> >the same?
> 
> Most games create a single window and operate within it.  Windows 
> specifically is architected around the MDI paradigm so 
> writing multi-window 
> apps that don't exist inside a parent workspace is not commonly done 
> (obviously it CAN be done, but most sample code and docs 
> don't go out of 
> their way to illustrate this).

Windows has been moving away from MDI for some time (Word defaults to
non-MDI mode for example) and there is a lot of support but as you say
it's not publicised very well. I suspect Windows users are used to MDI
so want to stick to it. 

Phil

Re: [GD-General] Re: C++ turing complete

[Jesse J. <jes...@mi...>]

At 11:45 PM -0500 12/23/01, Patrick M Doane wrote:
>On Sun, 23 Dec 2001, Jesse Jones wrote:
>
>  > Well, there's a lot of value in being able to generate the code from
>>  within C++. It's more portable and convenient than using something
>>  like Perl and it's better integrated with the other parts of the
>>  language.
>
>There other ways to generate code besides Perl--consider a parser
>generator like Yacc.

Sure, but none of these are as tightly integrated with C++ as 
templates. This seems to me to limit their applicability. And, I'd 
note, that there are many more heavy duty template libraries than 
code generating systems like Yacc.

>One could probably implement this using template
>meta-programming techniques, but I'm sure that Yacc can give much better
>error messages and provides a syntax that is easier to use than templates.

Probably. If you haven't read it you might want to check out a book 
called "Generative Programming". It has several very interesting 
chapters including a good chapter on template meta-programming.

>Integration with the language is nice, but it's a pity that it comes at
>such a high price to the syntax.  This becomes especially noticeable when
>compared with similar systems in Lisp or Camlp4.

Yep, I think part of the problem was that templates were designed for 
things like containers and algorithms. From what I've read the 
functional programming aspects came as a surprise. The committee is 
talking about a few things like typeof that would make 
meta-programming a bit easier, but AFAICT it's going to remain an 
activity practiced by only a few people.

   -- Jesse

Re: [GD-General] Eiffel

[J C L. <cl...@ka...>]

On Sun, 23 Dec 2001 20:45:08 -0800 
Brian Hook <bri...@py...> wrote:

> That's why listening to informed opinions is fascinating to me,
> and unfortunately real good comparisons are hard to come by.  I'm
> still very impressed by Ian Joyner's relatively objective analysis
> of Java vs. C++ vs. Eiffel in "Objects Unencapsulated".  There's
> another book I just ordered that talks about OOP in terms of C++,
> Obj-C, Object Pascal and, I believe, SmallTalk.

I presume you're familiar with LambdaTheUltimate then.

  http://lambda.weblogs.com/

-- 
J C Lawrence                
---------(*)                Satan, oscillate my metallic sonatas. 
cl...@ka...               He lived as a devil, eh?		  
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.

Language comparisons was Re: [GD-General] Eiffel

[Brian H. <bri...@py...>]

At 12:20 AM 12/24/2001 -0500, Patrick M Doane wrote:
>I was thinking more from the perspective of what might be useful to game
>developers.  The programs in Doug's shootout are way too small.  Here are
>some examples of the scope I was thinking about:
>
>   - MUD server
>   - ray tracer
>   - AI algorithms, e.g: best paths, neural networks

Those would be good samples, and I'm pretty certain that there are MUD 
servers written in about every language imaginable we could probably at 
least look at.  I know there's at least one prototype MUD server written in 
Lua, called Lune.  Pretty clean code.

> > At a high level, there is C vs. C++ vs. Obj-C vs. Java vs. Eiffel, and once
> > again a small program doesn't necessarily take into account.
>
>I'm not sure I understand what you're saying here.

Sorry, half-finished though.  Basically, I was trying to say "a small 
program doesn't necessarily take into account the complexities of building 
a larger system".  Yeah, duh =)

>If issues like bit-twiddling and hex constants are keeping you from using
>Eiffel, then use a preprocessor to begin with, and if these functions
>still seem very important, extending the language should be easy
>enough.

Well, language designers have (theoretically) spent far more time thinking 
about language issues than I have.  When I go in and start dicking with a 
language by extending it, then I've probably already entered the domain of 
diminishing returns.  Although I'm sorely tempted to hack my Lua 
distribution to support '//' style comments instead of the Eiffel like '--' 
comments. =)

I'd like to avoid a preprocessor as much as possible, but I'm still baffled 
why modern language designers adamantly refuse to put in block 
comments.  Eiffel lacks block comments, so special preprocessors have to be 
written (gepp?) to support #if 0/#endif mechanisms.  Same problem applies 
to Lua.  Just wish people would make it a part of the language proper and 
save us headaches in the real world.  GOBO is strewn with #ifdefs to make 
it work with the various Eiffel implementations, unfortunately they had to 
do their own #ifdef architecture IIRC.

>Environments and libraries are a little harder to deal with of course.

Yes, as are other things like language integration and extension.  For 
example, Lua just drops in beautifully.  It's amazingly easy to integrate 
into a C program as an extension language, and this is something you only 
learn through experience.  You can read the language spec to understand the 
language's coolness, but it takes doing it to learn the nice parts of 
implementation with the language.

License issues can be a potential gotcha -- things would look radically 
different if many languages were GPLed (or if their libs were).

Brian

Re: [GD-General] Eiffel

[Patrick M D. <pa...@wa...>]

On Sun, 23 Dec 2001, Brian Hook wrote:

> At 11:20 PM 12/23/2001 -0500, Patrick M Doane wrote:
> >Perhaps it would be interesting to come up with a few small programs or
> >algorithms and see how they are implemented in various languages.  That
> >might make learning these languages easier.  Any thoughts?
>
> Actually, that's been done before (sort of) in the Great Computer Language
> Shootout.  A pretty nifty article that covers the performance aspects.

I was thinking more from the perspective of what might be useful to game
developers.  The programs in Doug's shootout are way too small.  Here are
some examples of the scope I was thinking about:

  - MUD server
  - ray tracer
  - AI algorithms, e.g: best paths, neural networks

Some of these could obviously get complex, but there should be simple
implementations to make all of these approachable.

> The problem is that small programs don't tell you that much.

Absolutely - that's why I was thinking of slightly more complicated
examples.

> At a high level, there is C vs. C++ vs. Obj-C vs. Java vs. Eiffel, and once
> again a small program doesn't necessarily take into account.

I'm not sure I understand what you're saying here.

> Just reading about Eiffel taught me a lot (both about it and C++), and
> it wasn't until I started getting into the grittier details that some
> of the warts started to show up.  I still think it's a cool language,
> but for games specifically it may not be ideal (no real bit twiddling,
> no hex constants) without calling out to C/C++ constantly to do real
> work.  The environments and libraries also have their own set of
> issues.

If issues like bit-twiddling and hex constants are keeping you from using
Eiffel, then use a preprocessor to begin with, and if these functions
still seem very important, extending the language should be easy
enough.

Environments and libraries are a little harder to deal with of course.

> That's why listening to informed opinions is fascinating to me, and
> unfortunately real good comparisons are hard to come by.  I'm still very
> impressed by Ian Joyner's relatively objective analysis of Java vs. C++ vs.
> Eiffel in "Objects Unencapsulated".  There's another book I just ordered
> that talks about OOP in terms of C++, Obj-C, Object Pascal and, I believe,
> SmallTalk.

You also might find "A Theory of Objects" by Abadi & Cardelli to be
interesting.  The first 5 chapters review object oriented features and do
a good job of separating concepts like inheritance and subsumption.  The
authors are also very aware of the wide variety of OOP languages that
exist -- at least 20 different programming languages are explicitly
mentioned in the text.

Note that the majority of the book focuses on developing a theory of
objects that could serve as a foundation for all OOP languages.  In
effect, they are trying to establish what lambda calculus did for
procedural languages.  So, I would really only recommend reading it if you
are interested in learning more about progamming language theory.

Patrick

Re: [GD-General] Re: C++ turing complete

[Patrick M D. <pa...@wa...>]

On Sun, 23 Dec 2001, Jesse Jones wrote:

> I have a vague recollection of a more practical definition of a
> Turing complete language. It went something like: a language is
> Turing complete if it has sequential statements, some form of if
> statement, and I think one other thing that I can't recall.

Probably recursion - that should be sufficient to make it Turing-complete.
This is a limiting definition though as those behaviors aren't
strictly necessary.

> >Regardless, templates provide an expressive meta-language for static
> >compilation.  I'll admit that I don't fully understand the excitement as
> >one can do this in a more powerful (and understandable) fashion by simply
> >generating C++ code.
>
> Well, there's a lot of value in being able to generate the code from
> within C++. It's more portable and convenient than using something
> like Perl and it's better integrated with the other parts of the
> language.

There other ways to generate code besides Perl--consider a parser
generator like Yacc.  One could probably implement this using template
meta-programming techniques, but I'm sure that Yacc can give much better
error messages and provides a syntax that is easier to use than templates.

Integration with the language is nice, but it's a pity that it comes at
such a high price to the syntax.  This becomes especially noticeable when
compared with similar systems in Lisp or Camlp4.

At least C++ template syntax is not as bad as Unlambda.

Patrick

Re: [GD-General] Eiffel

[Brian H. <bri...@py...>]

At 11:20 PM 12/23/2001 -0500, Patrick M Doane wrote:
>Perhaps it would be interesting to come up with a few small programs or
>algorithms and see how they are implemented in various languages.  That
>might make learning these languages easier.  Any thoughts?

Actually, that's been done before (sort of) in the Great Computer Language 
Shootout.  A pretty nifty article that covers the performance aspects.

The problem is that small programs don't tell you that much.  You really 
need a large body of experience to give you the nitty gritty details about, 
say, the pros and cons of using Lisp vs. Lua vs. Ruby vs. Python for a game 
extension language.  Very few people have the depth of experience in all 
three to make a real valid comparison.

At a high level, there is C vs. C++ vs. Obj-C vs. Java vs. Eiffel, and once 
again a small program doesn't necessarily take into account.  Just reading 
about Eiffel taught me a lot (both about it and C++), and it wasn't until I 
started getting into the grittier details that some of the warts started to 
show up.  I still think it's a cool language, but for games specifically it 
may not be ideal (no real bit twiddling, no hex constants) without calling 
out to C/C++ constantly to do real work.  The environments and libraries 
also have their own set of issues.

And, of course, there are GUI tools, command line tools, text processors, 
etc. all of which can be implemented in many different appropriate languages.

That's why listening to informed opinions is fascinating to me, and 
unfortunately real good comparisons are hard to come by.  I'm still very 
impressed by Ian Joyner's relatively objective analysis of Java vs. C++ vs. 
Eiffel in "Objects Unencapsulated".  There's another book I just ordered 
that talks about OOP in terms of C++, Obj-C, Object Pascal and, I believe, 
SmallTalk.

Brian

Re: [GD-General] Eiffel

[Patrick M D. <pa...@wa...>]

On Sun, 23 Dec 2001, Brian Hook wrote:

> However, C++ vs. [insert alternative language here] debates are interesting
> to me since there are so many new languages that I have either no or
> minimal familiarity with that I stand to learn a lot.  BETA, OCaml,
> Haskell, Dylan, Ruby, SmallTalk, Eiffel, Python, Lua, etc. all come under
> these classification.

Perhaps it would be interesting to come up with a few small programs or
algorithms and see how they are implemented in various languages.  That
might make learning these languages easier.  Any thoughts?

Re: [GD-General] Re: C++ turing complete

[Jesse J. <jes...@mi...>]

At 8:41 PM -0500 12/23/01, Patrick M Doane wrote:
>This is getting off-topic, but this discussion has not been focused
>entirely on gaming, so...
>
>On Sun, 23 Dec 2001, Jesse Jones wrote:
>
>>  My recollection of Turing machines is a bit rusty, but you can use
>>  template meta-programming just like you would use a functional
>>  language and you can also write stuff like compile time if statements
>>  and loops. Sounds Turing complete to me...
>
>This kind of meta-programming is certainly possible to do as long as
>progress is being made (at least in my experience with templates).  For
>example, one can compute factorial numbers using templates because this
>process terminates.
>
>This might be picking on a fine point, but a programming language is
>Turing-complete if it can simulate the behavior of a turing machine with
>finite storage capacity.  One of the fundamental properties of such
>machines is that the halting problem is undecidable.  In fact, Turing
>machines were originally formalized to prove this.  So the idea of being
>Turing-complete while ensuring that computation terminates doesn't seem
>very compatible.

I have a vague recollection of a more practical definition of a 
Turing complete language. It went something like: a language is 
Turing complete if it has sequential statements, some form of if 
statement, and I think one other thing that I can't recall.

>Regardless, templates provide an expressive meta-language for static
>compilation.  I'll admit that I don't fully understand the excitement as
>one can do this in a more powerful (and understandable) fashion by simply
>generating C++ code.

Well, there's a lot of value in being able to generate the code from 
within C++. It's more portable and convenient than using something 
like Perl and it's better integrated with the other parts of the 
language.

   -- Jesse

Re: [GD-General] Eiffel

[Brian H. <bri...@py...>]

At 07:19 PM 12/23/2001 -0800, J C Lawrence wrote:
>I would like to think that I've steered clear of those uglier bits,
>tho the discussion has become rather noisier than I'd like.

Oh, absolutely, I didn't mean to imply that anyone had gone overboard.  In 
fact, that's why I specifically stated that I think these types of 
discussions so far have been very good.  The Windows/Unix argument isn't as 
interesting to me because, well, I've been through that enough for 10 years =)

However, C++ vs. [insert alternative language here] debates are interesting 
to me since there are so many new languages that I have either no or 
minimal familiarity with that I stand to learn a lot.  BETA, OCaml, 
Haskell, Dylan, Ruby, SmallTalk, Eiffel, Python, Lua, etc. all come under 
these classification.

Brian

Re: [GD-General] Eiffel

[J C L. <cl...@ka...>]

On Sun, 23 Dec 2001 18:57:19 -0800 
Brian Hook <bri...@py...> wrote:
> At 06:41 PM 12/23/2001 -0800, J C Lawrence wrote:

>> It is implicitly a subjective thing.

> Bingo.  There are sane and intelligent reasons that Windows and
> Unix suck in different ways for different users.

http://www.jwz.org/doc/linux.html
http://catalog.com/hopkins/unix-haters/handbook.html

> But there are a whole gamut of areas where you cannot objectively
> point and say "This sucks in an absolute sense".  This is the fine
> line between intelligent discussion and flamefest.

I would like to think that I've steered clear of those uglier bits,
tho the discussion has become rather noisier than I'd like.

-- 
J C Lawrence                
---------(*)                Satan, oscillate my metallic sonatas. 
cl...@ka...               He lived as a devil, eh?		  
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.

Re: [GD-General] Eiffel

[Brian H. <bri...@py...>]

At 06:41 PM 12/23/2001 -0800, J C Lawrence wrote:
>It is implicitly a subjective thing.

Bingo.  There are sane and intelligent reasons that Windows and Unix suck 
in different ways for different users.

But there are a whole gamut of areas where you cannot objectively point and 
say "This sucks in an absolute sense".  This is the fine line between 
intelligent discussion and flamefest.

 >>> Intelligent discussion
A.  Unix provides me many more options when it comes to configuring and 
maintaining my tool set.

 >>> Entering danger zone, but still okay
B.  Windows just isn't a productive work environment [for me].  I'm far 
more productive, and everyone else I know, are far more productive in the 
Unix environment because we have it configured to increase our workflow 
tremendously. [Note: the danger here is because there is an implicit 'and 
everyone else using Windows isn't as productive' in there that often gets 
initial feathers ruffled].

 >>> Flame fest!
C.  So all you Windows people are small minded idiots that don't have the 
ability to manage a real operating system.  I have no idea how anyone gets 
Windows to work in the first place.

Back to my musical instrument analogies, it's a lot like Fender vs. 
Gibson.  Different instruments with different characters, but "better" 
would be entirely determined by your own personal criteria.  Windows is a 
"better" environment than Unix for many different reasons, but many of 
which won't be valid for everyone.

Brian

Nature of OT was Re: [GD-General] Re: C++ turing complete

[Brian H. <bri...@py...>]

At 08:41 PM 12/23/2001 -0500, Patrick M Doane wrote:
>This is getting off-topic, but this discussion has not been focused
>entirely on gaming, so...

Well, this is the one gamedevlists mailing list where OT is kinda hard to 
determine.  But we'll know it when we see it =)

GD-Algorithms, Linux, Windows, Design and Console all have very well 
defined charters, but GD-General is pretty much "Any discussion that might 
pertain to games but which doesn't fall under any of the other list 
charters".  In fact, this list doesn't need to be limited to programming 
only (the charter specifically uses the phrase "game development" instead 
of "game programming").

I think choice of programming language (and why) is very relevant to game 
development.  So long as the discussions don't become flamefests, I think 
we're cool.

I've been pleasantly surprised at the quality of discussion so far.  People 
can actually state why they don't like something (C++, Windows, whatever) 
without getting shouted down.

Brian, co-admin for gamedevlists-*

Re: [GD-General] Eiffel

[J C L. <cl...@ka...>]

On Sun, 23 Dec 2001 11:06:55 -0000 
Philip Harris <ph...@me...> wrote:

> That's a great list of problems with Windows but the majority if
> not all of them only apply to 99.99% of users. 

I'm fairly sure that's not what you meant.

> The fact that the kernel is untrustable and that is has an
> incomplete syscall interface makes no difference to my
> productivity and I spend roughly 75% of my time developing
> software.

<shrug> It depends on what you do.  What I don't have is a single
point, which if fixed, would instantly make everything better.  It
seems to be endemic.  Or more castigatingly, Windows seems to be
designed to make working in the manner I consider efficient and
effective deliberately difficult, so I don't.

Small trivial example, which is rather outside of my GUI preferences
(eg no icons).  My typical idle state has ~20 windows on my desktop.
When actively working that tends to rise quickly to 50+ with values
close to 100 not being unseen.  This is a side effect of a way of
working that I find very easy and efficient (and is FWVLIW what
initially drive me to Software Carousel from DOS, and thence to
DesqView, and thence to OS/2 and thence to the *nix world).  Its
also a work approach which Windows suffers under (eg I currently
have (counting) 28 browser windows open, 9 xterms, 18 XEmacs frames,
and 15 other odd/assorted applications).  This is work method, which
is in itself a tool, is something that my current toolset and
environment handles trivially.  I've attempted a couple times to
transplant it to Windows ('92, '95, and '99) to transplant that to
Windows, each time with glaring lack of success (much of which was
my fault).

Wander about the shorts (variously old) at for an idea:

  ftp://ftp.kanga.nu/pub/users/claw/screenshots/Desktop/

>> and ease of building new tools.  We're engineers -- that's what
>> we do: build and use tools.  Windows tends to assume

> That's not how I see it at all, yes we use tools, we probably
> build our own tools as well, but they are just tools. What matters
> is the results, specifically are they the results our customers
> want. 

Yup.  In the end we solve problems.  There's a logical sequence
there starting with solving problems, then solving problems with
tools, then solving problems with tools we build and use, etc.  It
all rests on solving a problem with the latter step defining the job
of an engineer.  I skipped the lower foundations as assumable.

> I really don't care whether the cabinet maker has his own tools
> are simply uses his teeth, all I'm interested in is whether the
> cabinets are good and can he deliver what I've ordered when he
> says.

Bingo.

> Now if Windows actually stops you producing those results then
> that's a problem but for the majority of people that is not going
> to be the case.  

Hehn.  Not a question of stopping, but a question of difficulty
versus reward for the sorts of problems I consider interesting for
me to solve.  Within that space Windows doesn't win, and most
specifically, seems to enforce unacceptable contortions without
delivering any increased productivity, value, insight,
effectiveness, or anything else of value (to me) for the trouble.

Yes, I can build a cabinet, yes I can build a cabinet with someone
else's tools, and yes I can build a cabinet with my own selection
and preference in tools.  Guess which set I'll be most effective,
productive, and efficient with?  Guess which set will distract me
least from the problem I'm actually working on?  Guess which set I'd
prefer to work with?

> The work I do (and I'm sure this applies to a lot of people, even
> if you aren’t one of them) the vast majority of my time is
> centered around solving a problem. 

<nod>

> At the moment it's behaviour AI and the solution does not depend
> on Windows and Windows has no effect on how efficiently I solve
> that problem. 

Good design can be implemented anywhere.  Every platform at the
implementation level comes with certain compromises, usually labeled
under "architectual model" such as thread models, IPC models, memory
models, RPC models, VM models, etc.  90+% of my code and designs
could be fairly easily implemented under Plan9, *nix, Windows,
VAX/VMS, or OS9 (the rest being designed against a given platforms
intricacies).  Efficiency of the implementation is not in question.
Efficiency in _producing_ the final implementation is in question.

> Nor do the tools for that matter, C++ affects the implementation
> but actually solving the problem and getting the behaviour I want
> has nothing to do with OS or language or tools or RFC compliance.

Precisely.  Ignoring the fact that I tend to work in arenas where
RFC compliance is significant (ie multi-system and 'net related
stuff), the *ability* of an arbitrary OS to support or implement the
solutions I render is not in question, nor is the ability of the OS
to do such a thing efficiently.  My point rests solely on my
efficiency in producing those solutions -- an efficiency which I'm
paid for.

> I'm guessing that you do a lot of UNIX system level type stuff in
> which case Windows isn't going to provide what your looking for
> but then it isn't supposed to. 

I do a fair bit of systems work.  Most of what I do sits between the
upper levels of the kernel and the lower levels of applications.  As
such I dally just above hardware drivers and skulk just under
user-application logic the majority of the time.  Not quite
middleware, as I don't tend to get involved in middleware rules and
logics.  I guess a lot of it would end up being called, "system
infrastructure", "libraries", "integration protocols" and the like.

> But that doesn't make Windows "excessively difficult to be
> productive under".

There's an implicit phrase there of, "for me and what I do."  I've
not said that the same evaluation applies to everyone, as it
manifestly doesn't.  

Requoting my initial statement:

  I won't work under Windows.  Not worth my time.  Not worth my
  employer's time.  Can't see a reason to bother.  Not a religious
  thing -- its just an environment which I consider and find
  excessively difficult to be productive under, and without any
  return value for that difficulty.

It is implicitly a subjective thing.

-- 
J C Lawrence                
---------(*)                Satan, oscillate my metallic sonatas. 
cl...@ka...               He lived as a devil, eh?		  
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.

Re: [GD-General] Re: C++ turing complete

[Patrick M D. <pa...@wa...>]

This is getting off-topic, but this discussion has not been focused
entirely on gaming, so...

On Sun, 23 Dec 2001, Jesse Jones wrote:

> My recollection of Turing machines is a bit rusty, but you can use
> template meta-programming just like you would use a functional
> language and you can also write stuff like compile time if statements
> and loops. Sounds Turing complete to me...

This kind of meta-programming is certainly possible to do as long as
progress is being made (at least in my experience with templates).  For
example, one can compute factorial numbers using templates because this
process terminates.

This might be picking on a fine point, but a programming language is
Turing-complete if it can simulate the behavior of a turing machine with
finite storage capacity.  One of the fundamental properties of such
machines is that the halting problem is undecidable.  In fact, Turing
machines were originally formalized to prove this.  So the idea of being
Turing-complete while ensuring that computation terminates doesn't seem
very compatible.

Regardless, templates provide an expressive meta-language for static
compilation.  I'll admit that I don't fully understand the excitement as
one can do this in a more powerful (and understandable) fashion by simply
generating C++ code.

Patrick

[GD-General] Re: C++ turing complete

[Jesse J. <jes...@mi...>]

At 7:46 PM -0500 12/23/01, Patrick M Doane wrote:
>On Sun, 23 Dec 2001, Jesse Jones wrote:
>
>>  The difference is that templates are a Turing complete compile time
>>  language. This is obviously enormously powerful (and awkward because
>>  templates were never designed to do this). This lets you do all
>>  manner of things. Here are a few:
>
>Is it true that templates are Turing complete?

My recollection of Turing machines is a bit rusty, but you can use 
template meta-programming just like you would use a functional 
language and you can also write stuff like compile time if statements 
and loops. Sounds Turing complete to me...

   -- Jesse

[GD-General] Re: C++ turing complete

[Patrick M D. <pa...@wa...>]

On Sun, 23 Dec 2001, Jesse Jones wrote:

> The difference is that templates are a Turing complete compile time
> language. This is obviously enormously powerful (and awkward because
> templates were never designed to do this). This lets you do all
> manner of things. Here are a few:

Is it true that templates are Turing complete?  I've seen a simulation of
a turing machine in C++ using templates but I've only been able to make
halting programs execute.  My compiler (gcc 2.95-2) complains when it
evaluates a computation state that has already visited.

Maybe gcc doesn't conform to the standard or C++ templates are not Turing
complete?  Even with limitations on the size of the tape and number of
states, it should still be possible to write a (turing) program that does
not halt.

Patrick

Re: [GD-General] Eiffel

[Jesse J. <jes...@mi...>]

At 11:47 PM -0500 12/22/01, Thatcher Ulrich wrote:
>On Sat, 22 Dec 2001, Jesse Jones wrote:
>  > It allows you to write code like this:
>>
>>  Editor* editor = ...;
>>  boldButton->SetCallback(boost::bind(&Editor::SetStyle, editor,
>>  kBold));
>>
>>  italicButton->SetCallback(boost::bind(&Editor::SetStyle,
>  > editor, kItalic));
>
>That's nice, but I don't think that addresses Kent's complaint.

Like I said, it's not a replacement for closures.

>Let's
>say you wanted to toggle the bold mode on boldButton.callback; how
>would you write:
>
>	struct anon {
>		static Editor* editor;
>		anon(Editor* e) : editor(e) {}
>		static void callback() {
>			int	s = editor->GetStyle();
>			s ^= kBold;
>			editor->SetStyle(s);
>		}
>	} instance(editor);
>	boldButton->SetCallback(instance::callback);
>
>I'm not claiming that's great (in fact it stinks :).

You can't write it inline like Kent wants to (although you might be 
able to with the lambda library). In general I think the best 
approach is to put the logic in a member function and have the 
callback call that.

>An example of how the STL is not "really easy to use":
>
>	std::hash_map<string, int> my_hash;
>
>	...
>	string	my_key = something...;
>	int	my_value = something...;
>
>	// I want to see if my_key is in my_hash, and if so, whether
>	// its value matches my_value.
>	std::hash_map<string, int>::iterator it = my_hash.find(my_key);
>	if (it != my_hash.end() && (*it).second == my_value)
>	{
>		// Match.
>	} else {
>		// Mismatch.
>	}

Try:
    if (my_hash.count(my_key) > 0)
       // match
    else
       // mismatch

>I think I got that right.  The iterator is just obfuscation.  Whereas
>the way you'd do it in Perl or Lua, the seemingly obvious:
>
>	if (my_hash[my_key] == my_value) {
>		// Match.
>	} else {
>		// Mismatch.
>	}
>
>compiles, and leaks memory!

Compiles, but shouldn't leak memory.

>  I've seen code like the above, written by
>professional C++ coders.  I probably wrote code like that myself the
>first half-dozen times I used map or hash_map.  A hash container
>should not define operator[] the way std::hash_map does; it's just
>programmer abuse.

It's not the way I would have written it, but calling it programmer 
abuse is way too strong.

>I find that kind of thing is endemic to the STL.  The STL was designed
>(cleverly) as a demonstration of generic programming, rather than as a
>nice container library.
>Unfortunately, people use it as a container
>library, and IMO it stinks for that.

It's far better than any other container library I've seen...

   -- Jesse

Re: [GD-General] Eiffel

[Jesse J. <jes...@mi...>]

At 5:16 PM -0800 12/22/01, Brian Hook wrote:
>Anyway, back to the point -- how does C++'s templates provide 
>genericity that is better than Eiffel's?  After looking at Eiffel, 
>it seems like it supports generic programming in a much more open 
>and friendly fashion and without all the compile time weirdness that 
>C++ jams down our throat.

The difference is that templates are a Turing complete compile time 
language. This is obviously enormously powerful (and awkward because 
templates were never designed to do this). This lets you do all 
manner of things. Here are a few:

1) STL knows exactly which types it's dealing with. This means it can 
switch off the type and use optimized code as appropriate.  For 
example, when a vector resizes it has to copy the old elements into a 
new block. A good implementation will use memcpy for primitive types 
(and user types that the user marked as POD) instead of an element by 
element copy.

Another trick that STL implementations use is to use partial 
specialization so that all pointers share the same code. This cuts 
way down on bloat if you use a lot of containers of pointers in your 
code. AFAIK Eiffel's collections don't take advantage of type info 
like this.

2)  Like C++ Eiffel is statically typed. But sometimes you have to 
store arbitrary data. This has traditionally been done with unions in 
C++, but templates can provide a cleaner solution. For example, 
boost::any is a non-template class that contains a templated class. 
This lets you do things like have heterogeneous containers:

    std::vector<boost::any> c;
    c.push_back(1);   // int
    c.push_back(std::string("one"));
    etc

    if (int* ip = boost::any_cast<int*>(c[0]))
       // it's an int, muck around with it
    else (std::string* ip = boost::any_cast<std::string*>(c[0]))
       // it's a string

I don't think Eiffel can do this because it lacks member templates.

3) There are a number of libraries that really push templates. 
Blitz++ for example allows you to write matrix code in a natural 
style (A = B*C + D) but uses expression templates to optimize the 
code and eliminate temporaries at compile time. This allows them to 
meet or beat Fortran's performance. Try that in Eiffel. :-)

There are also a number of lambda libraries out there for C++. These 
allow you to write closures in C++. For example:

    int c[4] = [1, 2, 3, 4];
    for_each(c, c+4, cout << arg1 << " ");

will execute the expression 'cout << arg1 << "' for each element in 
the iterator range assigning the element value to "arg1". Some of 
them even support conditional expressions in the expression. Of 
course Blitz and the lambda libraries are much more complex and push 
templates a lot further than STL. It's still not clear that libraries 
like this will be useable by mortals in production code.

>My biggest concern with Ruby right now is performance.  Looking at 
>the benchmarkst at the GCLS, it looks like Ruby is pretty far behind 
>the other languages, including Lua (which I would guess is Ruby's 
>primary competitor -- Python, Ruby and Lua seem to be accomplishing 
>much the same thing).

Ruby's pretty darn cool, but I'd have to agree with you. It might be 
good for protoyping though. BTW there's supposed to be a decent Cocoa 
wrapper for Ruby although I haven't checked it out yet.

>>But the biggest problem with C++ might be that it simply requires 
>>too much time and study to become proficient in the language and 
>>aware of all the pitfalls.
>
>I would put this another way: C++ was trying to be idiom-neutral and 
>provide all the tools for any kind of programming style.  Because of 
>this, you can become very proficient in one tiny aspect of C++.  I 
>feel I know C++ very well for my purposes, but because I 
>purposefully have avoided templates, exception handling, MI and many 
>other things that I consider more problematic than worthwhile, I 
>can't say I "know" C++.  In fact, I'm not sure many people can say 
>they know the whole language since the whole language is overkill 
>for any specific framework design.

Very very few people know the entire language. I know an awful lot, 
but there are still plenty of arcane template rules that I haven't 
bothered to learn.

>I would even argue that any framework that uses EVERY element of C++ 
>is probably a disaster.  Which goes back to my complaints about STL 
>=)

This is absolutely not true. Take your earlier list: "templates, 
exception handling, and MI". Every single one of these is *very* 
useful in frameworks and I've seen multiple frameworks that used them 
effectively.

I can only think of two C++ features that I avoid: virtual base 
classes and exception specifiers. Virtual base classes are one of the 
worst part's of the language and exception specifiers have an 
unfortunate tendency to abort your program if the wrong exception 
sneaks through.

   -- Jesse

Re: [GD-General] Eiffel

[Jesse J. <jes...@mi...>]

At 9:09 AM -0800 12/22/01, Brian Hook wrote:
>At 10:08 AM 12/21/2001 -0500, Thatcher Ulrich wrote:
>>but IMHO the STL stinks as far as usability goes.
>
>THANK you for saying that.  I'm so tired of people going on and on 
>about how great STL is (it's probably the #1 validation of C++ and 
>templates I've seen),

Templates are flawed but great. There might be better options in 
other languages, but for C++ there's just a ton of useful stuff you 
can do with them. In my code I make heavy use of smart pointers 
(exception safety, memory management, COM-style interface ptr 
wrappers, and preferences), the boost callback classes, type-safe 
logging functions, and STL. Note that this is all stuff that is very 
useful to ordinary programmers.

>when in fact IT'S NOT THAT GOOD.  It's convoluted, difficult to 
>debug, has bizarre syntax, takes forever to compile, generates tons 
>of warnings, requires third party implementations for stability. 
>The only reason people dig on it is that they didn't have to write 
>it.
>
>Someone should sift through the STL source code some time then come 
>back and tell me it's GOOD.

The design is more important than the implementation and IMO the 
design is quite good. I've yet to see a really good implementation, 
but CodeWarrior's at least doesn't suck.

   -- Jesse

RE: [GD-General] dev environments

[Patrick M D. <pa...@wa...>]

On Sun, 23 Dec 2001, Brian Hook wrote:

> So porting between the two should be trivial, given code that is reasonably
> portable to begin with.  If you're hardcoding calls to Win32 or DSound,
> well, yeah, you're asking for trouble.

For the most part, the code can be factored around such calls or even a
wrapper around the Mac OS can be built.  The biggest offender I've seen is
DirectPlay.  While some innovate hackers have built a compatible
implementation of DirectPlay, it doesn't take much effort from Microsoft
to break that work.

If you care about portability, implement TCP/IP support using WinSock.

Patrick

RE: [GD-General] dev environments

[Patrick M D. <pa...@wa...>]

On Sun, 23 Dec 2001, Philip Harris wrote:

> > > Personally, I'd rather build the tools into the game using a
> > > GUI library. It saves all that messing around with stand
> > > alone tools :)
> >
> > This is fine, when it works, but there are many types of
> > tools where it just doesn't fit within the game.
>
> Similarly there's many types of game where it's inefficient to run cross
> platform on the Mac.

Having done quite a bit of cross development work for Mac/Windows, what
types of games do you think are not appropriate on the Mac?  I'm not
disputing the claim - just curious about your opinions.

> Several of those examples you mentioned I wouldn't build a standalone
> app for anyway, a straightforward spreadsheet can sometimes be far more
> efficient than a custom tool, no matter how easy it was to write the
> tool.

Absolutely - one really nice tool I used in the past was Resourcerer. It
provided an environment for editing data structures that only required a
simple definition of how that structure should be represented on disk.
That, combined with a spreadsheet for raw data, provided almost all the
tooling we needed for game development.

> Given that we're considering porting a couple of titles to the Mac I may
> have the opportunity to try out your suggestions in the future.

Will this be OS X only or will you support older versions of the OS?
Many modern games do not port well to older Mac OS versions.  This is
especially true for games that rely on virtual memory and file i/o
performance.

Patrick

Re: [GD-General] Eiffel

[Patrick M D. <pa...@wa...>]

On Sat, 22 Dec 2001, Brian Hook wrote:

> I would put this another way: C++ was trying to be idiom-neutral and
> provide all the tools for any kind of programming style.  Because of this,
> you can become very proficient in one tiny aspect of C++.  I feel I know
> C++ very well for my purposes, but because I purposefully have avoided
> templates, exception handling, MI and many other things that I consider
> more problematic than worthwhile, I can't say I "know" C++.  In fact, I'm
> not sure many people can say they know the whole language since the whole
> language is overkill for any specific framework design.

There are many kinds of programming styles that C++ fails to implement. It
does a decent job with traditional structured programming and
object-oriented programming.  Generic programming is extremely awkward,
as is functional programming.  There is no support for logic
programming.

I feel I can honestly say that I know C++ well - but this knowledge comes
from using other languages that are better than C++, and also developing
in it for the past 10 years or so.  The language is far from overkill - it
fails to offer crucial functionality in almost every programming paradigm.

Despite some major semantic limitations, there were terrible choices made
regarding syntax.  As an example, consider a case where some code needs to
be made generic.  It has a dependency on a particular structure that
should now be parameterizable.  To make this transition in C++ requires
changing almost every line of code.  Contrast this with OCaml which
requires two lines of code for the implementation and one line of code in
the namespace using the new parameterized structure.

> I would even argue that any framework that uses EVERY element of C++ is
> probably a disaster.

Hmm... I'm not aware of any feature of C++ that has not seemed appropriate
in some context -- they are there for a reason.  The desire for such
features does not inherently make the framework a disaster, although
bending over backwards to conform to C++ syntax might make the programmer
go crazy.

Patrick