gamedevlists-general — List for discussing general game development issues

Re: [GD-General] Eiffel

[Thatcher U. <tu...@tu...>]

On Dec 21, 2001 at 01:56 -0500, Kent Quirk wrote:
> 
> fact, one of the things that I love about Java and wish that C++ had was
> anonymous classes. They provide the only way to deal with the concept of
> functors in generic algorithms where the functor is defined at the same
> point as the algorithm is used. In C++ you can put it nearby. In Java
> you can stick an anonymous class right inline. It's a powerful, useful,
> and very general mechanism, similar to a lambda notation. 

Someone showed me this trick recently:

	...
	struct Function {
		static void Call(int arg) {
			// some code.
		}
	} Instance;
	SomeFunctionTakingAFunctionPointer(Function::Call);
	...

For extra flexibility, define an interface class:

struct Functor {
	virtual void Call(int arg);
};
void SomeFunctionTakingAFunctor(Functor* f);

	...
	struct HandleResults : public Functor {
		vector<int> results;
		void Call(int arg) { results.push_back(arg); }
	} Instance;
	// Call SomeFunction... and collect its results.
	SomeFunctionTakingAFunctor(&Instance);
	// Now Instance.results has the args passed to Instance.Call().

You can beef up HandleResults with a constructor and other members to
parameterize stuff.

I'm still sick of C++ though.  The useful modern stuff I want to use
is all a huge PITA.  Templates stink, (lack of) introspection stinks,
header files stink, manual memory management stinks, and pardon me,
but IMHO the STL stinks as far as usability goes.

-- 
Thatcher Ulrich <tu...@tu...>
http://tulrich.com

RE: [GD-General] dev environments, trifle and other things...

[Warrick B. <War...@po...>]

I also find it crazy that we don't have better tools to work with,
personally I think the *nix breed who prefer to work that way are totally
stark raving mad (In a nice lets make computers continue to seem obscure
kind of way of course ;).  I want my computer environment to evolve to suit
me not the other way around.

I've spent the past few weeks fighting on and off with the command line
driven source (MKS) control system here and I may well go insane.  What used
to be a simple process (Ok when it didn't bugger up) under Source Safe (Or
even CS RCS with it's nice little plugin for VS that did have funny turns
occasionally) that was nicely integrated into Visual Studio has turned into
a nightmare.  Simple things like checking what files I do actually have
checked out seems far too long winded a process now.

Being human (Although arguably barely sometimes it being Christmas party
season and all) I'm visually stimulated (ooer) and I'd much rather see
things layed out in a more graphical diagramtic way then look at the man
pages for another sodding obscure command switch.  I look at the combined
good points of Visual Studio, Visual Basic and other things and can see a
glimpse of the fact that there is a better way of doing this.

I'll have to take a look at this Cocoa hot chocolate stuff Brian mentions -
I do remember a friend of mine swearing by the NextStep stuff.  I've also
been intending to have a look at C# (Gasp) - I suspect environment wise it's
a merge of Visual Basic & Visual C++?  which has to be at least part of a
step in the right direction (intention wise at least).

On a side note recently I've had to write everything in straight C which I
hadn't done for a long while but I find myself missing C++ badly - I never
thought I'd say that....

Warrick.

RE: [GD-General] dev environments

[Tom N. <t.n...@vr...>]

Hi,

I find Borland's Delphi IDE to be pretty hard to beat. It has a very
elaborate class library behind it, including a comprehensive GUI
construction toolkit. You hardly ever need to mess with the Win32 API,
there's no need for MFC or ActiveX controls or whatever, and the
graphical GUI editing works great. It's like Visual Basic, only without
the disadvantages :-)

The Object Pascal language behind Delphi is, in my modest opinion, also
a step up from C++. Coincidentally, I believe it originated on the Mac
-- is there a pattern emerging here? I don't know if Apple still uses it
today, though. Perhaps it got replaced by Obj-C?

Finally, there's also a Linux version available ("Kylix"). I have no
personal experience with this, but I've had reports from people who
compiled the OpenGL demos from my website on Linux, without significant
problems.

> When they added 
> auto-completion for members when typing "." or "->" on a 
> member -- wow, how helpful is THAT? Or being able to click on 
> something and say "Show me your definition".

Yeah, except "Show me your definition" only works _after_ you've
compiled the project with browse info. If you wipe out your "Debug" and
"Release" directories, your browsing abilities are gone. Delphi allows
you to browse your code at _all_ times, compiled or not, and even if you
_would_ have to compile it, it'd take about two seconds to do a complete
rebuild of your entire project, as opposed to several minutes if you
were using VC++.

Oh, and did I mention that you can get Delphi for free? :-)

-- Tom

RE: [GD-General] Eiffel

[Jamie F. <ja...@qu...>]

BION, we had one guy threaten to resign rather than use a tab length he was
unfamiliar with. Funnily enough, he didn't stay long....

Jamie


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Brian Hook
Sent: 21 December 2001 00:58
To: gam...@li...
Subject: RE: [GD-General] Eiffel


> analogue), etc. At my last job (yeah, I'm hunting) the tool
> chain was Windows only so until we got everything running
> under WINE under Linux (which ran it faster than native
> Windows on the same box) I did all my compiles under SSH to a
> Windows box.  Worked fairly nicely too.

So I'm assuming you don't pursue jobs where you're required to use their
tool chain, no exceptions?  I've actually interviewed people before that
said they wouldn't, for example, use Windows (or give up Emacs...or use
Visual Source Safe..or conform to other people's coding styles).
There's nothing wrong with that, mind you, so long as you're in a
position to make those demands.

Brian


_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general

Re: [GD-General] Eiffel

[Kent Q. <ken...@co...>]

Back to the original question. I've been reading the critique Brian
posted:

This critique of C++/Java/Eiffel and others is dated from 1996, so it's
a bit old at this point. Some of the things he criticizes have been
changed in various ways in all of the languages. The paper could
definitely use a fourth revision. (It appears he wrote a book in 1999 by
starting from the paper, so you probably have to buy the book to get an
update.)

My general first take on Eiffel is that it seems awfully wordy and
cumbersome. I understand and generally agree with the concept of writing
more when coding to save trouble later; I use long variable names for
just that reason. But the language has Bertrand Meyer's Pascalish bias
all over it, and having been frustrated by coding in Pascal for a number
of years, I developed a strong allergy to that style. It's a sort of
leather and handcuffs kind of style.

I also found this document:

http://www.elj.com/eiffel/cpp/cpp-report-pd/

And in there, I found these items among a list of things that piss off
C++ programmers -- and they're about the kiss of death as far as my use
of Eiffel is concerned:

-------
No overloading. Eiffel does not allow a feature to be overloaded on the
basis of the types of its arguments. This sometimes leads to rather
artificial manual overloading, as found in the standard IO routines
(put_string, put_character, put_integer). 

However, overloading was not omitted by accident. Not only was it
considered by Eiffel's designer to be of questionable value and not
without costs, but it also would unduly complicate the inheritance
mechanism, which relies on unique names to identify each feature of a
class. Again, it comes down to favoring readability over writeability
and eliminating ambiguity. 

No nested classes. A class cannot be declared within the scope of
another class, nor within a routine. This is not an oversight, but a
deliberate decision. Classes are meant to be reusable modules, and if
one class is written inside another, then it has such a strong
dependency with the enclosing class that it cannot possibly be reused
independently. 

In C++, nested classes are merely a scope issue, rather than a semantic
issue. Thus, if C++-style nested classes are desired, they can be
achieved merely by prepending the enclosing class' name to that of the
nested class, and access to the "enclosing" class' features can be
granted through selective export. 
----------

I understand the logic behind these decisions -- but to me, it feels
like the arguments in favor of them are particularly weak, and evidence
of design by someone who hasn't done a lot of large scale programming. 

Removing overloading removes ambiguity, yes, but it actually increases
complexity by forcing the programmer to maintain a mental list of all
the different ways to do the same task with different objects. I'd
rather have the compiler deal with ambiguity and "undue complications"
than force me to deal with it. I spent WAAAAAAY too much time
duplicating code to handle different types in the bad old days of
Pascal. I don't want to go there again.

Regarding nested classes, there are uses for classes in implementation
as well as design. Not every class needs to be public or reusable. In
fact, one of the things that I love about Java and wish that C++ had was
anonymous classes. They provide the only way to deal with the concept of
functors in generic algorithms where the functor is defined at the same
point as the algorithm is used. In C++ you can put it nearby. In Java
you can stick an anonymous class right inline. It's a powerful, useful,
and very general mechanism, similar to a lambda notation. 

Now if Eiffel supports a lambda notation (I haven't found it) and I've
missed the fact, I'll take this one back. 

I'd really like to find a language that makes more sense in a production
environment than C++ or Java. 

C: "You can do whatever you want."
C++: "You can do whatever you want, if you can figure out how."
Java: "You can do whatever you want that's safe."
Perl: "You can do whatever you want any way you want, and preferably not
the same way twice."
Pascal: "You can't do anything."
Eiffel: "You can do whatever we want."
Python: "Whatever."

Any counterarguments?

	Kent



-- 
-----------------------------------------------------------------------
Kent Quirk                   | MindRover: "Astonishingly creative."
Game Architect               | Check it out!
ken...@co...      | http://www.mindrover.com/
_____________________________|_________________________________________

Re: [GD-General] Eiffel

[<phi...@pl...>]

Not as far as I'm aware. I only mention it because I figure it's
interesting to know that that sort of thing is actually being done on high
profile titles.




                                                                                                                   
                    "Thatcher Ulrich" <tu...@tu...>                                                             
                    Sent by:                                      To:                                              
                    gam...@li...urc        gam...@li...       
                    eforge.net                                    cc:                                              
                                                                  Subject:     Re: [GD-General] Eiffel             
                                                                                                                   
                    12/20/2001 04:23 PM                                                                            
                                                                                                                   
                                                                                                                   




On Dec 20, 2001 at 10:56 -0800, phi...@pl... wrote:
>
> There's a BIG PS2 game out at the moment that was written almost
> entirely in lisp, including the VU code. They wrote their own
> compiler, and apparently have the full rewrite-while-executing
> environment going as well.
Cool, I think I know the one you mean.  I'd love to know more
details... is there any public info about their environment?

--
Thatcher Ulrich <tu...@tu...>
http://tulrich.com

_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general

Re: [GD-General] Eiffel

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

On Thu, 20 Dec 2001 16:57:37 -0800 
Brian Hook <bri...@py...> wrote:

>> At my last job (yeah, I'm hunting) the tool chain was Windows
>> only so until we got everything running under WINE under Linux
>> (which ran it faster than native Windows on the same box) I did
>> all my compiles under SSH to a Windows box.  Worked fairly nicely
>> too.

> So I'm assuming you don't pursue jobs where you're required to use
> their tool chain, no exceptions?  

Depends on what you mean by toolchain.  Compilers, linkers, etc --
things that actually produce the product they're paying me for --
that's the employer's purview and is part of the product definition.
Toolchains in terms of editors, tools, systems, etc, has nothing to
do with my employer (tho maybe something to do with IS).

  Then again, I don't think I've seen a company that asked let alone
  required their employees to all use the same editor/tool/system
  etc since 1988 (I hear they still exist) -- well, not outside
  places like Sun/SGI/HP asking you to use Solaris/IRIX/HP-UX as the
  base OS (ie eat your own dogfood -- and they didn't insist and
  made no mention as to what you ran atop that).  They just want to
  know that what you produce works in the product and can be worked
  with by everyone else in the team/group.

> I've actually interviewed people before that said they wouldn't,
> for example, use Windows (or give up Emacs...or use Visual Source
> Safe..or conform to other people's coding styles).  

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.

  Much like a carpenter or mechanic brings his own tools with him to
  the job, I bring my own tools with me to my job as a developer.

What I will do is adapt/conform on my interfaces to the rest of the
company and the people and systems I work with.  If there are
shared/communal systems/approaches which are required, that's not a
problem.  I'll plug into their source control system, their coding
styles, their shared file systems, etc.  No problem.  If the local
coding is too much of a pain and difficult for me to read/work with,
well, then that's what software is for; it covers up the gaps and
handles the translations (wrap a copy of indent around the check-in
process).

ObNote:  Most of the better shops I've been at have adopted the
coding format of:

  -- Everything within a given file must use the same style.  If you
  edit a file, copy what's there.

  -- Everything within a directory/module should use the same style.
  If you add a file, copy what's there already.

  -- If you do something new, write your own module ets, use
  whatever you want so long as its consistent.

  -- We like it if you use JavaDoc or (insert comment documentation
  system).

This is especially nice when they also embed the coding style in a
modeline comment so that your editor can pickup and reconfigure
itself for the local style transparently as you enter each file.

> There's nothing wrong with that, mind you, so long as you're in a
> position to make those demands.

I suspect this is a demographic difference between Windows and *nix
oriented shops.  I hear/read about Windows shops attempting to
dictate use of developer tools like editors, IDEs, and the like.  I
just haven't seen or heard that in any world I work in for a very
long time (and have a hard time understanding why they'd bother).

-- 
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...>]

> analogue), etc. At my last job (yeah, I'm hunting) the tool 
> chain was Windows only so until we got everything running 
> under WINE under Linux (which ran it faster than native 
> Windows on the same box) I did all my compiles under SSH to a 
> Windows box.  Worked fairly nicely too.

So I'm assuming you don't pursue jobs where you're required to use their
tool chain, no exceptions?  I've actually interviewed people before that
said they wouldn't, for example, use Windows (or give up Emacs...or use
Visual Source Safe..or conform to other people's coding styles).
There's nothing wrong with that, mind you, so long as you're in a
position to make those demands.

Brian

Re: [GD-General] Eiffel

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

On Thu, 20 Dec 2001 16:03:36 -0800 
phil wilkins <phi...@pl...> wrote:
> J C Lawrence <cl...@ka...>:

>> Yup.  I know most of it is close to 15 years old -- going back
>> almost to the old TECO days.  I thought some of the code
>> highlighting and syntax detection and such was a bit younger tho.

> Possibly, I was using a dumb terminal at the time. The only colour
> being green.

Amber!  Amber!  Green was for weenies...and don't get me started on
white.

>> Then again, why would you ever have to work on someone else's
>> machine?

> Debugging code they haven't checked in yet. Tracking bugs that
> only manifest reliably on their system. Sporadic occurences of
> pair programming.  It happens.

<shrug>

In the old days I'd use ange-ftp (Emacs package to edit remote
files, now replaced by TRAMP) and telnet/SSH for that sort of thing.
Sit on your own machine, drive their machine.  Now I use TRAMP and
SSH/XDM etc to the same end.

>> You've got the network.  Use it.

> We have a windows network. Nuff said.

Ahh.  I try to avoid those monstrosities.  

Happily Cygwin seems to do a moderately useful job of fixing them.
You get bash, an SSH daemon, Xfree86, rxvt (xterm analogue), etc.
At my last job (yeah, I'm hunting) the tool chain was Windows only
so until we got everything running under WINE under Linux (which ran
it faster than native Windows on the same box) I did all my compiles
under SSH to a Windows box.  Worked fairly nicely too.

-- 
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

[Thatcher U. <tu...@tu...>]

On Dec 20, 2001 at 10:56 -0800, phi...@pl... wrote:
> 
> There's a BIG PS2 game out at the moment that was written almost
> entirely in lisp, including the VU code. They wrote their own
> compiler, and apparently have the full rewrite-while-executing
> environment going as well.

Cool, I think I know the one you mean.  I'd love to know more
details... is there any public info about their environment?

-- 
Thatcher Ulrich <tu...@tu...>
http://tulrich.com

RE: [GD-General] Eiffel

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

> Hey Brian you're selling this pretty well. I'm about ready to
> go out and buy a Mac. :) Seriously though if you're this 
> excited about something, and it's got Apple's full weight 
> behind it, I'd like to check it out, if for no other reason 
> than to have something to copy in my own designs.

Go check out developer.apple.com for all the blurbs and background
information on Cocoa and Obj-C.  Pick up a book like "Learning Cocoa" or
something similar.  The book "Object Oriented Programming and the
Objective-C Language" is a good place too, and I think it's in PDF form
on their Web site.

I'll warn you now though, you won't be able to copy much of the designs
because much of Cocoa's power comes from the way IB, Cocoa and Obj-C
interact, and Obj-C is just a radically different way of thinking than
C++ (dynamic typing with optional static type checking).

> How did you get into Cocoa/Obj-C and what tools do you need for it?

I've been a NextStep fan boy for ages, but Cocoa was the first time I
got to really use it.  By the time I had the means and time to use NS,
OpenStep was out and not very stable or fast on NT.

Since our games are going to be running no a Mac, I had to buy a
PowerMac anyway.  Just for grins I loaded up PB and tried to write a
little OpenGL visualization tool.  With NO prior Cocoa/Obj-C programming
experience, I got a fractal terrain generator visualization tool, with
UI, working in about 6 hours.  If I had to do it again, more like 45
minutes.

I haven't had much time to mess with it anymore, but I plan on getting
back into it on our later projects that will require tools.

> to give any specifics? Or should I simply go to the Apple dev
> site and read some glossies? :)

Here's the best part -- the dev tools are FREE.  ProjectBuilder, the
compiler (gcc), Interface Builder, libs, everything are freely
downloadable (and come with the OS X retail CDs, although not with OS X
on pre-installed machines).

It's a Better Way of Doing Things.  Unfortunately, it's limited to OS X.

Brian

Re: [GD-General] Eiffel

[<phi...@pl...>]

J C Lawrence <cl...@ka...>:
> Yup.  I know most of it is close to 15 years old -- going back
> almost to the old TECO days.  I thought some of the code
> highlighting and syntax detection and such was a bit younger tho.

Possibly, I was using a dumb terminal at the time. The only colour being
green.


> I'm pretty sure much of the more interesting ispell/aspell
> integration was only done around 5 or 6 years ago.

I remember playing with ispell, but IIRC it was fairly flakey at the time.

...
> Then again, why would you ever have to work on someone else's machine?

Debugging code they haven't checked in yet. Tracking bugs that only
manifest reliably on their system. Sporadic occurences of pair programming.
It happens.

> You've got the network.  Use it.

We have a windows network. Nuff said.

Cheers,
Phil

Re: [GD-General] Eiffel

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

On Thu, 20 Dec 2001 15:13:32 -0800 
phil wilkins <phi...@pl...> wrote:
> J C Lawrence <cl...@ka...>:
>> Thatcher Ulrich <tu...@tu...> wrote:

>>> These days emacs knows a lot, straight out of the box.  It knows
>>> about RCS and CVS, it knows how to indent and highlight various
>>> languages, how to run a build tool and bring you to the errors,
>>> how to run a source-level debugger, how to auto-complete.  It's
>>> got rectangle modes, outline modes, text modes, spell checkers,
>>> yadda yadda.

>> FWLIW those things have been true for at least 6 years, and I
>> think closer to 8.

> At least 13. I used to live in emacs, read mail, news, code,
> debug, everything.

Yup.  I know most of it is close to 15 years old -- going back
almost to the old TECO days.  I thought some of the code
highlighting and syntax detection and such was a bit younger tho.
I'm pretty sure much of the more interesting ispell/aspell
integration was only done around 5 or 6 years ago.

<shrug>

>> Conversely, my approach is to make the tools adapt to me.

> Which is fine, right up until the point where you have to some
> work on someone elses machine, or vice versa.

I remember enough of the defaults to work on a base system, if
somewhat haltingly.  If I really have to work on another's system I
bring over my environment (remember its under source control and
accessible from anywhere, or I just SSH back to my own box).

Then again, why would you ever have to work on someone else's
machine?  (Note: It hasn't happened to me for at least 3 years,
probably longer) Given decent network transparent tools it almost
never happens.  About the only reason you should ever need to leave
your own system (and thus stop your but growing that attractive
secretarial spread) is if you need physical hardware access to the
target box or something attached to it.

  You've got the network.  Use it.  

SSH X11 forwarding and X11's native network transparency make this
all particularly easy.  If you want a bit more portability (and have
a somewhat trusted network) use XDM chooser.  Don't have to kick
anybody off.  Just run XDM on a couple of VTs letting the main user
use the default and leaving :1 open for drop-ins.

-- 
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

[<phi...@pl...>]

J C Lawrence <cl...@ka...>:
>Thatcher Ulrich <tu...@tu...> wrote:
>> These days emacs knows a lot, straight out of the box.  It knows
>> about RCS and CVS, it knows how to indent and highlight various
>> languages, how to run a build tool and bring you to the errors,
>> how to run a source-level debugger, how to auto-complete.  It's
>> got rectangle modes, outline modes, text modes, spell checkers,
>> yadda yadda.

>FWLIW those things have been true for at least 6 years, and I think
>closer to 8.

At least 13. I used to live in emacs, read mail, news, code, debug,
everything.

> Conversely, my approach is to make the tools adapt to me.

Which is fine, right up until the point where you have to some work on
someone elses machine, or vice versa.

Cheers,
Phil

Re: [GD-General] Eiffel

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

On Thu, 20 Dec 2001 16:47:17 -0500 
Thatcher Ulrich <tu...@tu...> wrote:

> These days emacs knows a lot, straight out of the box.  It knows
> about RCS and CVS, it knows how to indent and highlight various
> languages, how to run a build tool and bring you to the errors,
> how to run a source-level debugger, how to auto-complete.  It's
> got rectangle modes, outline modes, text modes, spell checkers,
> yadda yadda.  

FWLIW those things have been true for at least 6 years, and I think
closer to 8.

> It can go out to the 'net and edit files via ftp.  

Use TRAMP (tramp.el) and you can add SSH, rsh, rsync, and various
other transports to that, as well as the ability to bounce thru one
or more intermediate systems (eg a firewall) to get to the final
file.

> None of this stuff requires any customization; you just have to
> dig a bit in the docs to learn the existence of the feature, and
> the keybindings and/or command names.  

Web searching also helps.  There's a very large raft of variously
home grown and third party elisp out there that works very nicely.  

  ObNote: I just found align-regexp.el (align regex matches
  vertically) and dict.el (a dict client) a few months ago, both of
  which have turned out to be very useful.

    ftp://ftp.kanga.nu/pub/users/claw/dot/xemacs/

> My general philosophy is to *not* fiddle with my .emacs too much;
> instead upgrade my wetware -- learn the default keys & commands,
> and only customize if I really have to.  

Conversely, my approach is to make the tools adapt to me.  I'm the
human.  They're the machines.  Machines are there to do things for
me, not me for them.  I don't always succeed, and I regularly
backtrack and pick up the path the tool originally took instead, but
those are more issues with how my views and expectations grow rather
than of the approach or tools themselves.

This partially explains why my .xemacs is almost 14K lines.

-- 
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

[Thatcher U. <tu...@tu...>]

On Dec 20, 2001 at 01:38 -0500, Kent Quirk wrote:
>
> And just to get in my shot...to me, using emacs is like asking for a car
> and being told "here's a pickup truck full of spare parts -- if it
> doesn't meet your needs, you can take it apart and rebuild it all by
> yourself!" I don't have time for that much freedom.

That's what I used to think, until I really made a commitment to learn
emacs.  These days emacs knows a lot, straight out of the box.  It
knows about RCS and CVS, it knows how to indent and highlight various
languages, how to run a build tool and bring you to the errors, how to
run a source-level debugger, how to auto-complete.  It's got rectangle
modes, outline modes, text modes, spell checkers, yadda yadda.  It can
go out to the 'net and edit files via ftp.  None of this stuff
requires any customization; you just have to dig a bit in the docs to
learn the existence of the feature, and the keybindings and/or command
names.  If you're on Windows, it also helps to get cygwin for some of
the default supporting tools (grep, cvs, ...).

I'm not really an emacs old-timer, so maybe this level of integration
is recent, or maybe it's always been there.  My general philosophy is
to *not* fiddle with my .emacs too much; instead upgrade my wetware --
learn the default keys & commands, and only customize if I really have
to.  Sure, the keybindings are not ideal and were designed by a crazy
person, but they work for touch-typing, and hey, I use a QWERTY
keyboard too.

-- 
Thatcher Ulrich <tu...@tu...>
http://tulrich.com

RE: [GD-General] dev environments

[Warrick B. <War...@po...>]

Yeh it's quite good and takes off from where Visual Studio leaves off but it
annoyingly crashes quite often....

-----Original Message-----
From: Brian Hook [mailto:bri...@py...]
Sent: 20 December 2001 19:30
To: gam...@li...
Subject: RE: [GD-General] dev environments


A-ha.  Someone sent me a link to www.wholetomato.com and their Visual
Assist program.  This is the kind of thing I'm talking about!  That's
definitely a step in the right direction.  I'll have to give it a whirl.

Brian


_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general

Re: [GD-General] Eiffel

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

On Thu, 20 Dec 2001 13:38:04 -0500 
Kent Quirk <ken...@co...> wrote:

> And just to get in my shot...to me, using emacs is like asking for
> a car and being told "here's a pickup truck full of spare parts --
> if it doesn't meet your needs, you can take it apart and rebuild
> it all by yourself!" I don't have time for that much freedom.

One of the things which regularly surprises me about other
developers is the cavalier way they treat their development tools
and environments.  Specifically: They don't invest in them.

Yes, they'll learn the tool, they'll figure out how to work
productively with it, but they won't invest in making it closer to
ideal for them with the idea that they'll then be able to carry that
value forward over time, potentially over extended periods of time.
Instead, all personal tool investment seems to be on a 3 year fixed
depreciations schedule -- after that (or sooner) you throw it away
and start over.

I don't grok this.  We blather on about reusable code, about
maintainability, and use versioning systems on our products which
often have code lifetimes (esp outside of the game arena) extending
closer to decades than 3 years, BUT we rarely ever apply those same
ideas and techniques to our own work environments.  Why?

ObNotes: 
  
  Yes, I'm an XEmacs user.  I've been incrementally building and
  adapting my .xemacs RC for almost 10 years.  Its all under source
  control and trivial to check out or update from anywhere.  It
  grows/changes rarely (couple times a year), but steadily improves.
  Its still not perfect, not by any shot, but its largely setup
  exactly the way I want and the curve is asymptotic to some
  (moving) definition of "perfect".

-- 
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] dev environments

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

A-ha.  Someone sent me a link to www.wholetomato.com and their Visual
Assist program.  This is the kind of thing I'm talking about!  That's
definitely a step in the right direction.  I'll have to give it a whirl.

Brian

Re: [GD-General] Eiffel

[Thatcher U. <tu...@tu...>]

On Dec 20, 2001 at 01:38 -0500, Kent Quirk wrote:
> 
> Whoever made the comment about "it's a poor workman who blames his
> tools" -- there's a HUGE difference between blaming your tools for poor
> results and wanting sharper tools.

That was me, and I didn't mean it that way!  I meant it as a criticism
of the people Brian mentioned who can't do any productive work without
their .emacs file.  I.e. it's their fault, not emacs' fault or anyone
else's.  (Especially in this case, since emacs is free and easy to
install...)

Also, I think that adage has another important meaning, which is that
a good workman will seek out effective tools; i.e. I think this is a
worthwhile discussion.

-- 
Thatcher Ulrich <tu...@tu...>
http://tulrich.com

RE: [GD-General] dev environments

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

> 1) what are specific examples of great dev environment 
> features (could be great features in otherwise ordinary environments)?

I haven't found a great dev environment yet, but I can point out
specific features that pull things together.

1.  InterfaceBuilder/Cocoa/Obj-C

The way these three components work together is amazing.  It makes
AppWizard and MFC look like a grade schoolers attempt at building the
Space Shuttle.  You see the shape and the intent, but it's obviously not
going to work.  This is how good Obj-C/Cocoa are for building tools --
if I was starting a game company (that had funding, heh), I would give
all the developers a PowerMac, simply because it would be more cost
effective developing tools on OS X than it would be trying to leverage
existing PCs and forcing reluctant toolsmiths to use MFC/Win32/C++.
Yes, it's THAT good.

I can't really explain too much about how this works, a tutorial would
be better.  I highly recommend the free tutorials and PDFs at
developer.apple.com that deal with Cocoa.  The whole NextStep
architecture was just way, way ahead of its time when it came to custom
apps.

In fact, the existence proofs -- the fact that so many high quality
vertical market apps were built with NS -- are pretty strong evidence
that more productive tools and environments WILL be adopted irrespective
of costs.  And NS was not cheap.

2.  The browsing facility in MSDEV

Booo, hsssss!  MSDEV sucks!  Yeah yeah, but for some reason I still get
work done in it, go figure =)  When they added auto-completion for
members when typing "." or "->" on a member -- wow, how helpful is THAT?
Or being able to click on something and say "Show me your definition".

This could be taken much farther than it has though.  Searching based
not on text, but context, would be great (which would remove my
complaint about function overloading -- do a search for "open" and
you'll get a zillion hits, when all you want is "where do I call open on
a HFile object?").  Being able to query for things like the (contrived)
following:

- "Show me all instances of class XYZ, but NOT its derivatives"
- "Show me all instances of class XYZ or its derivatives"
- "Show me anywhere I call this method for this object type, but not its
children"
- "Show me all functions that are overridden but don't call their parent
implementation"
- "Show me all objects that are derived using MI"
- "Show me all abstract classes"
- "Show me what functions I need to implement to make this class
concrete from its abstract parent"

> 2) what are specific examples of dev environments that "put 
> it all together" and boost productivity?

I haven't found one yet, which is how this all got started =)  My
nearest guess would be SmallTalk, but I only know about it from
reputation.

Brian

Re: [GD-General] Eiffel

[<phi...@pl...>]

"Thatcher Ulrich" <tu...@tu...>:
> If you just write everything in elisp, then you've already got this
magical environment :) I'm not seriously saying that's the way to go (I'm
not even thinking it this time :).

There's a BIG PS2 game out at the moment that was written almost entirely
in lisp, including the VU code. They wrote their own compiler, and
apparently have the full rewrite-while-executing environment going as well.

Cheers,
Phil

RE: [GD-General] Eiffel

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

> But I've jumped on the flavor-of-the-month before (Icon, 
> Smalltalk...got into C++ in 1988, which was at least 5 years 
> too early, maybe 10...got into Java in 1995, which was again 
> too early...) and now I'm wary of language and development 
> platforms that don't have enough general interest to sustain 
> a business. I might even go back and look at Smalltalk again 
> -- there are some grownup versions of it around now.

I think Eiffel is fairly mature -- there are multiple free and
commercial compilers and environments for it.  That was what made me
more interested -- I managed to avoid C++ in the CFront days, but
somehow managed to get sucked in with Borland's first offering.

However, I'm finding that Eiffel does, in fact, have a couple warts.
The biggest is that there is no single implementation that has the
entire language implemented.  Sound familiar? =) However, this seems to
be a temporary problem and can be worked around.  Hopefully it
stabilizes relatively soon.

The other big problem is that there's no STL that is part of the spec.
Each vendor implements their own container class libraries.  However,
there is an open-source STL-like library called GOBO that is portable
among all the variants out today.  Amusingly enough, to accomplish this
they required a preprocessor, gepp, that supports #if, #define, #undef,
etc.  So much for "get rid fo the preprocessor".

> Whoever made the comment about "it's a poor workman who 
> blames his tools" -- there's a HUGE difference between 
> blaming your tools for poor results and wanting sharper 
> tools.

Well said.

> question to me has always been whether that productivity on 
> an individual workstation can translate effectively into 
> productivity for delivery of a shippable consumer product.

I think so.  My Cocoa/Obj-C experience, which I've harped upon now a
zillion times, was an eye opener for how much better the process can be.
And that was mostly by leveraging slightly better tools (IB), frameworks
(Cocoa) and a language (Obj-C) -- ProjectBuilder isn't that good an IDE.
 
> And just to get in my shot...to me, using emacs is like 
> asking for a car and being told "here's a pickup truck full 
> of spare parts -- if it doesn't meet your needs, you can take 
> it apart and rebuild it all by yourself!" I don't have time 
> for that much freedom.

Oh crap, now you've done it.

Brian "Curse you freedom, CURSE YOU!" Hook

[GD-General] dev environments

[Thatcher U. <tu...@tu...>]

On Dec 20, 2001 at 09:50 -0800, Brian Hook wrote:

> I suppose you could make an Emacs set of bindings and modes that would
> support all the things I'd like to see in such an environment, so I'll
> just shut up now and say "Y'all Emacs people are all freaks!" =)

Heh, I can't argue with that :)

To try to get back onto the constructive thread that I think you
intended:

1) what are specific examples of great dev environment features (could
be great features in otherwise ordinary environments)?

2) what are specific examples of dev environments that "put it all
together" and boost productivity?

-- 
Thatcher Ulrich <tu...@tu...>
http://tulrich.com

Re: [GD-General] Eiffel

[Kent Q. <ken...@co...>]

Brian Hook wrote:
> But I digress (again).  I'd like to see Extreme Programming as applied
> to development environments/work flow, not just philosophy and the act
> of typing in code.  I don't want to deal with header files, precompiled
> headers, and all the ugliness of separate files for interface and
> implementation.  I want the dependency analysis done by a custom tool.
> I want the language to concentrate on structure, not details.  Yadda
> yadda yadda.

I absolutely agree with this. I think the biggest problem with C++ is
that it's tied to an obsolete linking model -- almost all its
idiosyncracies arise because they didn't want to try to fix both the
compilation and the linking at the same time.

It's long past time that we should have to cope with broken linkers that
make us be explicit about include files and dependencies. The compiler
should just figure that out. We did this in MindRover's ICE language --
it's completely implicit linking. In fact, we went farther than Java
did, and probably overdid it, because in our world it's hard to figure
out the minimal set of components you need to ship your program to
someone else!

> Eiffel seems to promise a lot of this (which sparked this thread), but
> I'm still suspicious of it because I've yet to see someone actually use
> it then bag on it.  Seems too good to be true, much like Obj-C (which,
> as I've stated, just plain rules all...on OS X).
> 
> As JC Lawrence mentioned, much of this is the argument of atomic vs.
> monolithic, but in this case I'm arguing that monolithic is better
> because the fundamental data has context that all the tools need to
> access.  Yeah, I know, convert to XML and pipe it through the command
> line in a form all the tools understand.  Bah.

My wish is for a compiler that builds a database that the whole tool
chain can use. But I don't want to be locked into a single-vendor
solution, because their priorities will never be my priorities. In the
ideal world, the database would be accessible through an API (preferably
something like SAX so you could leverage XML knowledge) so you could
write additional tools that didn't have to replicate the text processing
of a compiler. 

In particular, the concept of explicit header files and declaring
linkage & stuff is way obsolete, IMO. I think that Java is coming closer
to this than most solutions...and you can find many different languages
now that compile to a Java VM. Jython, for example. 

I like your vision of an integrated source environment, and if I had
such a thing with a cross-platform target and a full set of libraries,
I'd be pretty interested.

But I've jumped on the flavor-of-the-month before (Icon, Smalltalk...got
into C++ in 1988, which was at least 5 years too early, maybe 10...got
into Java in 1995, which was again too early...) and now I'm wary of
language and development platforms that don't have enough general
interest to sustain a business. I might even go back and look at
Smalltalk again -- there are some grownup versions of it around now.

Whoever made the comment about "it's a poor workman who blames his
tools" -- there's a HUGE difference between blaming your tools for poor
results and wanting sharper tools. There may not be a magic bullet, but
there sure as hell are more productive development environments. The
question to me has always been whether that productivity on an
individual workstation can translate effectively into productivity for
delivery of a shippable consumer product.

And just to get in my shot...to me, using emacs is like asking for a car
and being told "here's a pickup truck full of spare parts -- if it
doesn't meet your needs, you can take it apart and rebuild it all by
yourself!" I don't have time for that much freedom.

	Kent

-- 
-----------------------------------------------------------------------
Kent Quirk                   | MindRover: "Astonishingly creative."
Game Architect               | Check it out!
ken...@co...      | http://www.mindrover.com/
_____________________________|_________________________________________