gamedevlists-general

RE: Design of STL was RE: [GD-General] Eiffel

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

>     This may work well in smaller environments, but when you 
> have to work in larger teams having a standard that is well 
> documented is absolutely necessary.

So document your internal frameworks.  I'm not sure how this is any
different than the other internal frameworks a company with a large team
has internally developed.

> Do you want to teach new 
> hires your custom collections classes or do you simply look 
> for programmers with experience with STL?

I look to hire smart people.  Pre-existing knowledge of an API or
language is pretty much irrelevant.  As long as they're smart and
understand how to program, everything else is just a detail that should
be learned almost trivially quickly.  The only exception is when I'm
hiring someone for their specific domain knowledge (e.g. a porting
specialist).

> To me it's about 
> being more productive in order to make a better games...

Right, which is how this whole thread started =)

> building technology because you don't like underscores. =)  

No, it's building technology because you WANT to be productive, and the
pre-existing tools aren't conducive to that.

Brian

RE: Design of STL was RE: [GD-General] Eiffel

[Idahosa E. <ida...@sw...>]

Well STL could never compete with your own custom library. Is it STL like?
Or does it just
implement the containers and algorithms in a way that is intuitive to you as
opposed to being
general purpose? If I was writing containers and algorithms for MY own
purpose then I would write
them much differently than if I was writing just a custom port of the STL.

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Brian Hook
Sent: Monday, December 24, 2001 1:02 PM
To: gam...@li...
Subject: Design of STL was RE: [GD-General] Eiffel


> Behalf Of Kent Quirk
>
> I *really* have to disagree here.
>
> The DESIGN of the STL is absolutely gorgeous.

I didn't mean to comment on STL's design, only the practical
implications involved with its implementation (both in terms of choice
of language and the actual implementations such as Microsoft's).

A paper on genericity in C++ vs. Eiffel:

http://www.elj.com/eiffel/ij/templates/

> variable names, etc. But I have found that idiomatic use of
> the STL drastically reduces both the amount of code I have to
> write and the number of errors I make in that code.

Compared to writing that code yourself, or not using those data
structures at all, or what?

When I started using STL I decided I liked it simply because all too
often when I was in a hurry I would do stupid things like linear
searches instead of taking the time to dig up a proper class that did
binary searches or whatever.  So I thought STL was cool simply because
it forced me to use appropriate algorithms when I was too lazy to
implement them ("I'll fix it later").  But now that I've written my own,
I find I'm much happier with own implementation instead of using STL's.

> One of my frustrations with Java is the lack of ability to
> write anything like the STL in it. It's a frustration because
> I otherwise like it a great deal.

I'm coming back around to liking Java.  Since it lacks true generic
programming, it uses a SmallTalk/Obj-C style of container where casting
is required.  However, this is not fundamentally a bad thing unless
you're religious about static type checking (in which case, Eiffel seems
to be a better philosophical match than C++).  I happen to like Obj-C
and Java's introspection mechanisms since you can code a lot of very
powerful stuff without forcing it all to be generated at compile time.
You can also change your generic code WITHOUT FORCING A RECOMPILE OF ALL
CLIENTS.  This is just, well, huge, in my book.  I don't want to export
my code to everyone that is using my class libraries; and I sure don't
want them to have to recompile just because some implementation detail
has changed.

Brian



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

RE: Design of STL was RE: [GD-General] Eiffel

[Idahosa E. <ida...@sw...>]

Actually I like Brian's way.. that sounds like a company I could actually
get a job at, rather than one that demands "experience"! Which is a little
difficult
because to get a job you have to have "experience", but to have "experience"
you have to get a job... But that is really an excuse :)

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Brian Hook
Sent: Monday, December 24, 2001 5:01 PM
To: gam...@li...
Subject: RE: Design of STL was RE: [GD-General] Eiffel


>     This may work well in smaller environments, but when you
> have to work in larger teams having a standard that is well
> documented is absolutely necessary.

So document your internal frameworks.  I'm not sure how this is any
different than the other internal frameworks a company with a large team
has internally developed.

> Do you want to teach new
> hires your custom collections classes or do you simply look
> for programmers with experience with STL?

I look to hire smart people.  Pre-existing knowledge of an API or
language is pretty much irrelevant.  As long as they're smart and
understand how to program, everything else is just a detail that should
be learned almost trivially quickly.  The only exception is when I'm
hiring someone for their specific domain knowledge (e.g. a porting
specialist).

> To me it's about
> being more productive in order to make a better games...

Right, which is how this whole thread started =)

> building technology because you don't like underscores. =)

No, it's building technology because you WANT to be productive, and the
pre-existing tools aren't conducive to that.

Brian


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

RE: Design of STL was RE: [GD-General] Eiffel

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

Well, I didn't mean to imply that NO experience is okay.  There is the
experience of "programming at large" and then there's the experience
with a specific language or API.  The former is important, the latter
isn't (in my eyes).  

There are a lot of habits, tricks and experiences that you pick up
throughout a programming career that are absolutely vital and often
spell the difference between newbie and grizzled, bitter veteran =)  So
inexperience still works against you, but I don't think inexperience
with a specific API really should matter.

I've done a lot of weird ass programming in my life, and I'm a better
programmer for having gone through it, but those specific domains of
knowledge just aren't relevant to anything I'm doing today.  SEG:OFF
programming under real-mode DOS, VCPI/DPMI management for 32-bit
extended DOS, DIVE on OS/2, Mode X on VGA, NetWare IPX/SPX handling,
writing my own interrupt handlers, FIFO handling on a 16550, sliding
windows with VESA BIOS extensions, fixed point math using 386
instructions, using XOR EAX, EAX instead of MOV EAX, 0...

All kinds of crap that just doesn't matter anymore, but which has made
me a better programmer today.  It's my standard toolbox of "Back in my
day..." war stories.  We all have 'em =)

> Actually I like Brian's way.. that sounds like a company I 
> could actually get a job at, rather than one that demands 
> "experience"! Which is a little difficult because to get a 
> job you have to have "experience", but to have "experience" 
> you have to get a job... But that is really an excuse :)