gamedevlists-general — List for discussing general game development issues

STL was RE: [GD-General] Eiffel

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

At 05:04 PM 12/25/2001 -0800, Brian Sharon wrote:
> > Which is good, because I don't think that's what I said =)
>
>Just to set the record straight, you did say:
>
>"Which is a pretty strong indicator that STL could use some tightening up
>in its design or, alternatively, that implementation should provide
>basic pre and post-condition checking."

Crapola dude, what, you gonna nit pick everything by pointing out something 
where I obviously said something I didn't think I said? =) Listen to what I 
meant, not what I said..heh.

Just to be clear, I don't have much of an opinion on STL's design, since 
it's obviously working with a different set of goals and limitations than, 
say, the Eiffel Base/GOBO container classes of Java Collection classes.

My earlier comment was more of a general hand waving of "STL has issues 
when it comes to usability, I'm not sure which, so I'll be wishy washy and 
say they can be fixed with a slightly different design or a better 
implementation".

Which, of course, would be in the "duh" category.

>penance, I'm going to start a new thread with the subject  "STL: Rocks 
>Like Slayer or Totally Sucks?" ;)

Actually, I'm real curious how STL's design compares to 
Obj-C's/CoreFoundation, Java Collections and Eiffel/GOBO.  The designers of 
those libraries likely made very different choices in how they approached 
things (for example, IIRC Java Collections throw an exception when you have 
multiple iterators operating on the same container, whereas in STL this 
will lead to a run-time error that may be tough to track down).

Brian

RE: [GD-General] Eiffel

[Brian S. <bs...@mi...>]

>> that's your baby.  But you can't argue that STL is badly=20
>> designed because Plauger's implementation does no input=20
>> validation or debug checking.  You might be able to argue it=20
>> from other standpoints, but not from that one.

> Which is good, because I don't think that's what I said =3D)

Just to set the record straight, you did say:

"Which is a pretty strong indicator that STL could use some tightening =
up
in its design or, alternatively, that implementation should provide
basic pre and post-condition checking."

I think I characterized that quite fairly, and as for the notion that my =
first email was "raging", well I'm not quite sure what to chalk that up =
to.  I actually thought that parts of it were amusing, and it was merely =
meant to relate my experience of watching people give up on STL after =
the briefest of encounters.  I thought my email might provide =
inspiration, or at least comfort, in the knowledge that programming with =
STL does actually improve with time (like so many other things).  I know =
that's an extremely wishy-washy position for me to hold.  As penance, =
I'm going to start a new thread with the subject  "STL: Rocks Like =
Slayer or Totally Sucks?" ;)

Happy holidays to all.=20

--brian

-----Original Message-----
From:	Brian Hook [mailto:bri...@py...]
Sent:	Mon 12/24/2001 12:58 PM
To:	gam...@li...
Cc:=09
Subject:	RE: [GD-General] Eiffel

> Near the end of your email, I think you made the right=20
> distinction between debugging STL (which I'm arguing is a=20
> distraction at best)

More generally, debugging a third party set of reusable code should be a
distraction at best.

> So - given that I was talking about debugging STL in that bit=20
> you excerpted - what's the contradiction?

It seemed to me that the bulk of your e-mail was raging against the
notion of "debugging STL", I was merely stating that no one said as much
(i.e. my complaints were on the "debuggability of programs that use
STL").

> lessons are deeply ingrained.  So since I never free things=20
> twice any longer, does that mean free() is badly designed?

Yes, in fact, it does.  The CRTL is not what I consider an example of
good library design.  A library that allows, for lack of a better
phrase, "intuitive but incorrect usage", is probably poorly implemented
(maybe not designed, but once again, I'm not against STL's design -- I
haven't used it enough to really judge -- but I am against the
implementations).

> that's your baby.  But you can't argue that STL is badly=20
> designed because Plauger's implementation does no input=20
> validation or debug checking.  You might be able to argue it=20
> from other standpoints, but not from that one.

Which is good, because I don't think that's what I said =3D)

> p.s. sorry if I got anyone's hopes up too high, the STLPort=20
> iterators do NOT actually use Mr. T voices.

Well crap, I guess I'm cancelling that download now.

Brian


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

Re: [GD-General] The D Programming Language

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

At 10:44 PM 12/24/2001 -0800, Grills, Jeff wrote:
>It seems to retain the things I use most in C++, strips away a lot of 
>cruft I don't care for, and adds a lot of things I really wish C++ had.

This actually describes Java (for me).  I'm still torn between Java and 
Obj-C.  The sheer power from a dynamically typed system is something I'd 
hate to eschew, which is why Obj-C keeps lingering in the background.  But 
Java's GC and "portability" are also very tempting.

For my next server, Java is programming to be the language of choice.  But 
I still have a couple more puzzle games to put out before I tackle a 
project needing a server =)

Brian

[GD-General] The D Programming Language

[Grills, J. <jg...@so...>]

To throw another language into the mix:

http://www.digitalmars.com/d/

This language looks really promising to me.  It seems to retain the things I
use most in C++, strips away a lot of cruft I don't care for, and adds a lot
of things I really wish C++ had.  Since there isn't a compiler available for
it yet, I'm sure that no one has extensive experience in it to understand
the ugly spots.  Hopefully that will come soon enough to allow the designers
the opportunity to fix the language before they end up with too much
production code they don't dare to break (as certainly is the case in C++).

j
Jeff Grills 
Star Wars Galaxies 
Technology Director, Austin Studios 
Sony Online Entertainment Inc. 

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

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

[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

[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

[Tom S. <tsp...@mo...>]

> But now that I've written my own, I find I'm much happier
> with own implementation instead of using STL's.

    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.  Do you want to teach new hires your custom collections classes
or do you simply look for programmers with experience with STL?  To me it's
about being more productive in order to make a better games... not building
technology because you don't like underscores. =)  Not that it is the case
here, but it's an all too common thing.  Tom

----- Original Message -----
From: "Brian Hook" <bri...@py...>
To: <gam...@li...>
Sent: Monday, December 24, 2001 1:01 PM
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: [GD-General] Eiffel

[Tom H. <to...@3d...>]

At 12:58 PM 12/24/2001, Brian Hook wrote:
>It seemed to me that the bulk of your e-mail was raging against the
>notion of "debugging STL", I was merely stating that no one said as much
>(i.e. my complaints were on the "debuggability of programs that use
>STL").

My only problems with STL are:
1. Debugging code that uses it is ugly. Drilling into the containers and 
iterators to get at your data is cumbersome, and in some cases, impossible 
(can't think of an example right this second, but I seem to recall the 
overloading of -> operator to be a problem)
2. Compile time errors messages are so incredibly long and ugly that it 
takes ages to decipher what they're saying and what the proper fix is.

To solve #1 I've had to stop debugging, change the code to create a temp 
variable of the proper type, and run again. So far this hasn't been a huge 
problem since I've been able to at least get a workable solution in the 
situations I've run into so far, but if I ever have to deal with a hard to 
dupe bug, I'm going to be in hell.

#2 seems like it's mostly a debug environment issue that could be addressed 
with better tools.

I've been following this thread with great interest because I'm really not 
very happy with C++. It gets the job done, but it's an ugly bitch at times.

Tom

RE: [GD-General] Eiffel

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

> Near the end of your email, I think you made the right 
> distinction between debugging STL (which I'm arguing is a 
> distraction at best)

More generally, debugging a third party set of reusable code should be a
distraction at best.

> So - given that I was talking about debugging STL in that bit 
> you excerpted - what's the contradiction?

It seemed to me that the bulk of your e-mail was raging against the
notion of "debugging STL", I was merely stating that no one said as much
(i.e. my complaints were on the "debuggability of programs that use
STL").

> lessons are deeply ingrained.  So since I never free things 
> twice any longer, does that mean free() is badly designed?

Yes, in fact, it does.  The CRTL is not what I consider an example of
good library design.  A library that allows, for lack of a better
phrase, "intuitive but incorrect usage", is probably poorly implemented
(maybe not designed, but once again, I'm not against STL's design -- I
haven't used it enough to really judge -- but I am against the
implementations).

> that's your baby.  But you can't argue that STL is badly 
> designed because Plauger's implementation does no input 
> validation or debug checking.  You might be able to argue it 
> from other standpoints, but not from that one.

Which is good, because I don't think that's what I said =)

> p.s. sorry if I got anyone's hopes up too high, the STLPort 
> iterators do NOT actually use Mr. T voices.

Well crap, I guess I'm cancelling that download now.

Brian

RE: [GD-General] Eiffel

[Brian S. <bs...@mi...>]

> You just spent an e-mail discussing how "everyone gets bit by some
> aspect of STL" then go on to say that the STL needs much debugging is =
a
> fallacy?

Near the end of your email, I think you made the right distinction =
between debugging STL (which I'm arguing is a distraction at best) and =
debuggable STL programs (which no one in their right mind is against).

So - given that I was talking about debugging STL in that bit you =
excerpted - what's the contradiction?  Anyone can get bit by a thing =
they didn't expect in a library or language they're unfamiliar with.  I =
can certainly remember vividly the first time I learned about C struct =
packing, and when I discovered that I couldn't free() something twice.  =
It's just that competent people - what I assume we all are - don't KEEP =
getting bit by these things, repeatedly, daily. Once you spend a few =
hours debugging your early programs, those lessons are deeply ingrained. =
 So since I never free things twice any longer, does that mean free() is =
badly designed?  I would argue my expectations were badly formed.

Does that mean I'm saying we should just count on studly programmers to =
fix all their bugs alone?  Hell no, no way, never.  We all have enough =
sense to run things like debug heaps to catch memory leaks, even though =
we know what causes memory leaks and theoretically should never let one =
come into a program.  After all, none of us are programming =
theoretically - we're out in the real world where people do make =
mistakes.  For STL, the STLPort implementation (http://www.stlport.org) =
has a debugging mode that catches lots of misuses, and if you're looking =
for a version with iterators that will slap you cross the face and say =
in a Mr. T voice, "I pity the fool who uses this invalid iterator", =
that's your baby.  But you can't argue that STL is badly designed =
because Plauger's implementation does no input validation or debug =
checking.  You might be able to argue it from other standpoints, but not =
from that one.

The good thing is that awareness that most of your problems are =
self-inflicted means you're beyond the denial stage...next stop anger :)

--brian

p.s. sorry if I got anyone's hopes up too high, the STLPort iterators do =
NOT actually use Mr. T voices.

-----Original Message-----
From:	Brian Hook [mailto:bri...@py...]
Sent:	Mon 12/24/2001 11:14 AM
To:	gam...@li...
Cc:=09
Subject:	RE: [GD-General] Eiffel

> Behalf Of Brian Sharon
=20
> Additionally, I think it's funny how most people who dislike=20
> STL say that it's "too hard to debug". =20

A well designed class library and API provides assertion mechanisms to
help users detect their own errors.  By that logic, DX or Win32
shouldn't return error codes, because hey, it's the user's bugs that are
causing the problems.

To which I say, "Duh" =3D)  But a key part of ANY reusable code is =
making
sure that it provides competent debugging assistance.  ESPECIALLY when
that API is difficult to grasp initially.

> The earliest is denial - the idea that the problem=20
> lies within STL rather than your own code. =20

No, I would just like it if I knew what I did wrong when everything
explodes, instead of being stuck looking at some variable like "___p".
=20
> In the early stages, everyone gets bit by some aspect of STL.=20

Which is a pretty strong indicator that STL could use some tightening up
in its design or, alternatively, that implementation should provide
basic pre and post-condition checking.  DirectX provides this, one of
the areas I think it does a better job than OpenGL.

> But the notion that the STL needs much debugging, or any=20
> really, is a fallacy in my opinion.

You just spent an e-mail discussing how "everyone gets bit by some
aspect of STL" then go on to say that the STL needs much debugging is a
fallacy?

> It can be hard to look=20
> at the code and figure out what you're doing wrong, but I've=20
> never seen anyone in the denial stage actually find a bug in it.

My mistake.  I said "STL was difficult to debug" when, in fact, I meant
"debugging STL programs is difficult".  Subtle but important
distinction.  As a professional software developer for many years now,
I'm well aware most problems I encounter are self-inflicted =3D)  But =
part
of software engineering is finding tools that help the programmer find
and fix what is now trendily called "software defects".  Just dumping
that onus on the programmer rather flies in the face of what many in the
software engineering world are trying to push -- better software through
better tools and development methodologies, instead of relying entirely
on programmer studliness.

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 Mon, 24 Dec 2001 11:20:18 -0800 
Brian Hook <bri...@py...> wrote:

>> Obviously your approach works very well for you. Do you know of
>> other people who work the same way?

> Tons.  TONS.

> Back when I was in college, I religiously used Unix and tvtwm.
> The idea of using anything other than Emacs, focus-follows-mouse,
> tcsh and a virtual desktop manager was mind bogglingly hideous to
> me.  I couldn't imagine how others that needed to get work done
> could possibly survive in a Windows environment.

> Of course, I got over that =)

> Now I realize that when doing what is fundamentally text editing
> that I can survive in just about any environment because the real
> work is between my ears, not at my fingertips.  

Part of the deal for me is attempting to export as much as I can of
that gooey stuff between my ears out onto the screen.  I try to
build an interface that my mind automatically reacts to by adopting
the appropriate context, frameset, set of recollections, etc just
upon seeing in.  The, "Oh yeah, I was ... and now lets see where
that lead..." ideally needs to happen in less than a second after I
switch contexts.

> My earlier argument for better environments isn't so much about
> getting better, monolithic text editing environments, but
> eschewing text editing as the fundamental interface we do things.

In contrast I tend to devolve everything to text.  Its more data
dense at the human UI level.

> I just think that the next logical step is to have tools that are
> fully integrated and look at things as classes, hierarchies,
> interfaces, etc. instead of whitespace and keywords and
> identifiers and files.

Fair dinkum, and I'd probably use and like them if they weren't
monolithic, could be easily disassembled and rebuilt/replugged in
personally suiting patterns, etc.  

One of the basic bits about the MS approach to development which
bugs me is that assumption that you're going to use the MS tools
everywhere.  Why can't I rip out the MS editor and replace it
transparently with MultiEdit, QEditPro, SlickEdit, XEMacs, or
something else?  (Apocryphal question) Why isn't the system built
with cleanly drawn interfaces so I can rip out and replace any other
component as well, replacing the compiler, replacing the debugger,
replacing the linker, replacing the tag tracking system, etc.

Components and interfaces damnit.

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

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

On Mon, 24 Dec 2001 11:20:18 -0800 
Brian Hook <bri...@py...> wrote:

> The one user-interface concession I still won't make is the
> placement of control key.  I just purchased a nextstep ADB
> keyboard for my PowerMac simply because I get CTS if the control
> key is located in the standard position.

Oddly enough I refuse to work on anything but buckling spring
keyboards (with IBM Model M preferred in particular).  So, I bring
one with me to every job.  Happily they are cheap and readily
available at second hand stores.

  For those not in the know, The Model M was the standard keyboard
  on IBM PS/2 systems.  Its mostly known for having a 5lb metal
  plate in the bottom, and a loud clacky noise when used.

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

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

On Mon, 24 Dec 2001 11:50:26 -0000 
Philip Harris <ph...@me...> wrote:

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

Ahh, MDI.  <retch>

I tend to run windows in terms of contexts.  A virtual desktop will
have a number of windows on it, all applying or related to a given
task.  Typically this will mean a few XEMacs frames, a few xterms, a
few browser windows, etc.  Then repeat that on the next desktop for
the next task (more accurately "frame of mind").

Sometimes its system based.  Currently I have a desktop devoted to
some IPSec work I'm doing on Alice (system name), another devoted to
some InterMezzo stuff going on on Koala, a desktop for root sessions
on various machines (grouped for security reminders), one devoted to
some work stuff I'm doing locally on a protocol stack, another for a
private PHP project, etc

> It's interesting (at least to me) that you find that sort of
> environment so efficient. 

I got used to it -- started with the approach roughly 14 years ago
and have never looked back.

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

At any given time I'll tend to work only on a small subset.  But
then I change subsets fairly regularly.  It might take me several
days, occasionally more than a month, to get back to any particular
context set (private projects particularly tend to suffer such long
gaps), but when I do everything is still there ready and waiting in
the exact same relationship, with the exact same XEmacs edit history
and internal context etc as it had the instant I stopped working on
it -- easy for the mental gears to click back into and start up
again.

ObNote: My work system is inherently built on the assumption that my
systems will have uptimes measured in months.  As such I can
establish and preserve such "work contexts" for extended periods,
building and maintaining their value.  Typically I log into my
desktop once and then don't log back out again until I install a new
kernel (once or twice a year).

  Yeah, its Linux, so I tend to follow the hectic kernel upgrade
  path.  I'd rather do upgrades, and thus reboots, every other year,
  but there are always too many interesting things depending on some
  new kernel rev to tempt me away to upgrading.

> Obviously your approach works very well for you. Do you know of
> other people who work the same way? 

I know of a few (perhaps a half dozen), not that many.  Of course a
few of them have copied from me -- usually after having copied my
FVWM RC (which seems to be a viral meme in its own right).

> Is it an apporach you've been using a long time or it still
> evolving? 

At the low level it evolves constantly as I adopt new tools and
changes smaller practices.  As you can see from the screenshots
directory I posted a while back, its wasn't that long ago I finally
decided that icons were evil and evicted them from my system.
Similarly I recently moved from Netscape to Galeon (a Gecko based
browser which supports a number of useful UI features such as being
able to restart with all the same windows open and all the same
pages loaded as it had when it was brought down).

My browsing habits haven't changed in detail.  I still follow the
same pattern of reading a page and opening a new window (or TAB in
Galeon's case) on every interesting link as I go along (I almost
never use the forward/back buttons), but now I tend to group pages
in Galeon Windows on a task, character, and interest basis.  As such
I have a Galeon window each containing multiple TABs devoted only to
pages which will require long term study research (typically online
books), another to firewall research, another to IPSec, another to
MUD-Dev, another to blogs, another to performance metrics, another
to Kanga.Nu, another to temp/trash stuff...etc.

> I'm just interested because that sort of approach doesn't seem
> efficient to me at all.

I suspect our work methods are not that different within a single
given project.  In any given contenxt I usually have little going on
(a couple XEmacs frames, a few xterms, a browser or two, a couple
supporting apps, and that's about it).  The likely difference is
that I maintain state and context for many projects and sub-projects
as I go along, that I expect to keep them (and do) for variously
long periods, that I fork such contexts regularly, and that I pop
among them easily.

  I get a lot of startled looks from passersby.  

The ticket is not trying to work with them all at once, but building
and storing work contexts such that they're easily context shiftable
among.  Easy support for mental context shifting is the basic
assumption of this work method.

My problem now, and my current big interest in XEMacs UI
development, is seeing how I can shove that same work process down
into editing sessions within XEmacs on a large project.  Too often I
get into a "What is this token and why is it being used quite like
this?" research project, which of course recursively forks as I dig
down into other identical researches on other tokens. I need a way
to tag and lock context frames on those investigations so that I can
later pop back to them, and then usefully pop about among them,
possibly with a matching annotation system.  Barry Warsaw's WinRing
elisp looks very useful as a component for this, but I haven't
settled on a basic approach yet.

-- 
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: Design of STL was RE: [GD-General] Eiffel

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

On Mon, 24 Dec 2001, Brian Hook wrote:

> 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++).

You don't need full genericity to support container classes without
casting.  Parametric polymorphism is sufficient for that. It's relatively
easy to implement and does not suffer from any code bloat.  There are a
number of proposed extensions to Java that include this style of
polymorphism.  From what I understand, there are plans to add this add at
some point.

I'd also like to claim that type checking isn't a religious issue -
formalizing type disciplines is the best promising method to achieve a
higher level of software correctness.  Some key issues when analyzing a
type system are:

  Generality - are meaningful programs rejected?
  Accuracy - what kind of properties can be described?
  Decidability - is it possible to determine if an expression is
     well-typed?
  Brevity - how much information must be provided by the programmer?
     how much can be inferred by the compiler?
  Elegance - how easy is the system to understand? is adequate
     feedback given in case of a type error?
  Efficiency - how much time is spent analyzing types?

(note that this list comes from some course notes by Frank Pfenning -
likely to appear in a book he is working on called Computation and
Deduction).

Java's container classes support generality, but are weak in accuracy,
decidability, brevity, elegance, and efficiency.  I agree that this
doesn't make it fundamentally a bad feature, but we can certainly hope to
do better.

Patrick

RE: [GD-General] Eiffel

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

> Obviously your approach works very well for you. Do you know 
> of other people who work the same way?

Tons.  TONS.

Back when I was in college, I religiously used Unix and tvtwm.  The idea
of using anything other than Emacs, focus-follows-mouse, tcsh and a
virtual desktop manager was mind bogglingly hideous to me.  I couldn't
imagine how others that needed to get work done could possibly survive
in a Windows environment.

Of course, I got over that =)

Now I realize that when doing what is fundamentally text editing that I
can survive in just about any environment because the real work is
between my ears, not at my fingertips.  My earlier argument for better
environments isn't so much about getting better, monolithic text editing
environments, but eschewing text editing as the fundamental interface we
do things.  If programming ends up being nothing but generating syntax
for a set of external tools, then using Emacs or MSDEV shouldn't matter,
it's just a personal choice.  I just think that the next logical step is
to have tools that are fully integrated and look at things as classes,
hierarchies, interfaces, etc. instead of whitespace and keywords and
identifiers and files.

The one user-interface concession I still won't make is the placement of
control key.  I just purchased a nextstep ADB keyboard for my PowerMac
simply because I get CTS if the control key is located in the standard
position.

Brian

RE: [GD-General] Eiffel

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

> Behalf Of Brian Sharon
 
> Additionally, I think it's funny how most people who dislike 
> STL say that it's "too hard to debug".  

A well designed class library and API provides assertion mechanisms to
help users detect their own errors.  By that logic, DX or Win32
shouldn't return error codes, because hey, it's the user's bugs that are
causing the problems.

To which I say, "Duh" =)  But a key part of ANY reusable code is making
sure that it provides competent debugging assistance.  ESPECIALLY when
that API is difficult to grasp initially.

> The earliest is denial - the idea that the problem 
> lies within STL rather than your own code.  

No, I would just like it if I knew what I did wrong when everything
explodes, instead of being stuck looking at some variable like "___p".
 
> In the early stages, everyone gets bit by some aspect of STL. 

Which is a pretty strong indicator that STL could use some tightening up
in its design or, alternatively, that implementation should provide
basic pre and post-condition checking.  DirectX provides this, one of
the areas I think it does a better job than OpenGL.

> But the notion that the STL needs much debugging, or any 
> really, is a fallacy in my opinion.

You just spent an e-mail discussing how "everyone gets bit by some
aspect of STL" then go on to say that the STL needs much debugging is a
fallacy?

> It can be hard to look 
> at the code and figure out what you're doing wrong, but I've 
> never seen anyone in the denial stage actually find a bug in it.

My mistake.  I said "STL was difficult to debug" when, in fact, I meant
"debugging STL programs is difficult".  Subtle but important
distinction.  As a professional software developer for many years now,
I'm well aware most problems I encounter are self-inflicted =)  But part
of software engineering is finding tools that help the programmer find
and fix what is now trendily called "software defects".  Just dumping
that onus on the programmer rather flies in the face of what many in the
software engineering world are trying to push -- better software through
better tools and development methodologies, instead of relying entirely
on programmer studliness.

Brian

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

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

> 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

Re: [GD-General] Objective Caml (was Ruby opinions)

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

To provide a more objective viewpoint on OCaml, here are some thoughts I
have on how I think it can be improved:

  - more bindings to native os libraries
  - lack of an IDE
      (two recent developments are working on this, one native OCaml
       development and another that leverages VC++)
  - OCaml byte-code can't run OCaml native-code easily
      (the reverse is possible with a slight performance hit)
  - no debugger support for native-code
  - needs better package management support
  - improved standard library with more consistent APIs
      (the Caml team is really good about backwards compatibility which
       makes progress in this area unlikely)
  - more documentation/tutorials
  - some form of operator overloading to at least deal with
    floating point and integer operations
      (Jun Furuse is working on an extensional polymorphism extension
       that would solve this and much more)
  - some syntax rules from a historical perspective can be confusing
      (camlp4 solves this nicely, and version 3.04 allows syntax
       extensions to be used in the top-level interpreter.
       Users can use a wide variety of syntax options and extend
       the language with new keywords and constructs)

On Mon, 24 Dec 2001, Kent Quirk wrote:

> It looks a bit light on the library side, but it may prove to be a very
> useful tools language and perhaps even a delivery language.

Please let the community know what libraries and tools you need to make it
a success.

> I've just downloaded a version and will start tinkering on my vacation.
> I'll let you know in a week or so. ;-)

Sounds good - I'll be interested to hear your opinions.

Patrick

RE: [GD-General] Eiffel

[Brian S. <bs...@mi...>]

Additionally, I think it's funny how most people who dislike STL say =
that it's "too hard to debug". =20

I've often thought that you could take Elisabeth Kubler-Ross' five =
stages of dying (denial, anger, bargaining, depression, and acceptance) =
and map it pretty well to process of learning the STL.  The earliest is =
denial - the idea that the problem lies within STL rather than your own =
code. =20

In the early stages, everyone gets bit by some aspect of STL.  Example: =
erasing items from containers can invalidate iterators.  Let's say you =
make that mistake.  So you spend time trolling through obfuscated =
template code trying to figure out what stupid mistake was made in the =
STL, because God knows there's no bugs in your code.  After you figure =
out the problem, you might read the documentation and find that the =
container is behaving exactly as advertised. =20

Or you might decide that you've had it at that point.  I suspect that's =
where a lot of people bail out.

But the notion that the STL needs much debugging, or any really, is a =
fallacy in my opinion.  It can be hard to look at the code and figure =
out what you're doing wrong, but I've never seen anyone in the denial =
stage actually find a bug in it.

--brian
(not on the VC++ team, have never met Plauger, and am in no way =
defending his coding style)

-----Original Message-----
From:	Kent Quirk [mailto:ken...@co...]
Sent:	Mon 12/24/2001 8:15 AM
To:	Brian Hook
Cc:	gam...@li...
Subject:	Re: [GD-General] Eiffel

I *really* have to disagree here.=20

The DESIGN of the STL is absolutely gorgeous. I have never seen another
container library that has such a neat separation of containers,
iterators, algorithms, and data. The more I use the STL the more I love
its design.=20

Yes, there are warts on the usage of the STL that mostly come from
limitations in C++. Plauger's implementation (for Microsoft) is
appalling in its use of (nearly) obfuscated 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.

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.

STLPort fixes a lot of the problems with MS's version, btw, though it's
still not perfect.

	Kent


Brian Hook wrote:
>=20
> At 10:08 AM 12/21/2001 -0500, Thatcher Ulrich wrote:
> >but IMHO the STL stinks as far as usability goes.
>=20
> 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), 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.
>=20
> Someone should sift through the STL source code some time then come =
back
> and tell me it's GOOD.
>=20
> The primary advantage is that if you need a List or a Map you can just =
use
> STL without having to reroll it, but since I have that stuff lying =
around
> anyway, it doesn't bother me.

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

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

Re: [GD-General] Objective Caml (was Ruby opinions)

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

At GDC last year, Chris Hecker raved about OCaml. One of the people who
works here heard it and has been suggesting for a while now that we look
at it.

After poking around several language comparison pages for a while, I'm a
bit amazed. It appears to be as fast and easy to write as say, Python,
the native compiler performance is consistently at the top of every
benchmark I've seen, plus there are implementations for PC, Mac, and
Unix. 

It looks a bit light on the library side, but it may prove to be a very
useful tools language and perhaps even a delivery language.

I've just downloaded a version and will start tinkering on my vacation.
I'll let you know in a week or so. ;-)

       Kent

Patrick M Doane wrote:
> 
> On Sat, 22 Dec 2001, Brian Hook wrote:
> 
> > Oh, and if anyone has opinions on BETA or OCaml, I'm all ears =)
> 
> Sure, I'll be an OCaml advocate for you.  I've been using it for years and
> feel I had a good understanding of its strengths and weaknesses. Here are
> some high-level points:
> 
>   - Excellent performance of runtime code and garbage collector
>   - Unifies many programming paradigms in a single language:
>       object-oriented, functional, traditional imperative
>   - Compilation times are fast and provide good diagnostic feedback
>   - Code is very portable between Windows and Unix
>   - Debugger supports replay functionality
>   - More 3rd party libraries than similar languages (e.g. Haskell/Clean)
>   - Powerful type-inference mechanism eliminating the need for most
>     type annotations
>   - Strict type-checker to catch many errors at compile time
> 
> Some specific points about the language:
> 
>   - First class functions - kind of like inner classes in Java but
>     syntax is very lightweight and easy to use
>   - Support for parametric polymorphism (extensional polymorphism
>     is in the works)
>   - Easy to define new data types and operate on them via pattern matching
>     (a generalized case statement that allows arbitralily deep
>     introspection)
>   - Exceptions
>   - Sophisticated module system including functors (a simple lamba
>     calculus on modules to support paramterization)
>   - OO framework with support for multiple inheritance, binary methods,
>     and functional updates
> 
> I'm not particularly interested in entering a debate over which language
> is better -- that's very much a personal choice.  Personally, I have a
> strong mathematical background and appreciate formalism and notation.
> For that reason, Haskell is in many ways a more attractive language to me.
> However, OCaml still remains my language of choice for any serious
> development work.
> 
> Patrick Doane
> 
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general

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

Re: [GD-General] Eiffel

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

I *really* have to disagree here. 

The DESIGN of the STL is absolutely gorgeous. I have never seen another
container library that has such a neat separation of containers,
iterators, algorithms, and data. The more I use the STL the more I love
its design. 

Yes, there are warts on the usage of the STL that mostly come from
limitations in C++. Plauger's implementation (for Microsoft) is
appalling in its use of (nearly) obfuscated 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.

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.

STLPort fixes a lot of the problems with MS's version, btw, though it's
still not perfect.

	Kent


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), 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 primary advantage is that if you need a List or a Map you can just use
> STL without having to reroll it, but since I have that stuff lying around
> anyway, it doesn't bother me.

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

RE: [GD-General] Eiffel

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

You tried that under like windows? Like 95? Maybe NT would give bette=
r
results? Or not, who cares use UNIX...

-----Original Message-----
=46rom: gam...@li...
[mailto:gam...@li...]On Behalf Of=
 J
C Lawrence
Sent: Sunday, December 23, 2001 8:41 PM
To: ph...@me...
Cc: gam...@li...
Subject: Re: [GD-General] Eiffel


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=92t 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.

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

[GD-General] STL

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

Ahhhh! Well maybe the version you were using was convoluted, difficult to
debug, etc..
I guess part of tee problem is that I was trained on C++ first and so C++
naturally makes
a lot of sense since it was the first language I ever used. Maybe if you
have existing libraries
of code you use for data structures then the STL is not for you, but for
people who don't (ME!) it
is very handy, and honestly I have not had any bugs that I can recall, that
were really the fault
of the STL AND I use the original version of the STL that comes with VC++ 6
which is reputed to be
one of the worst versions there is.

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Brian Hook
Sent: Saturday, December 22, 2001 11:09 AM
To: gam...@li...
Subject: Re: [GD-General] Eiffel


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), 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 primary advantage is that if you need a List or a Map you can just use
STL without having to reroll it, but since I have that stuff lying around
anyway, it doesn't bother me.

Brian


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