[OT] Dao language 1.0.1 with SDL and OpenGL bindings

SDL Development
21

Actually, some things are the same like 99% of the time. For instance,
a certain local variable might provably be always a value of the
same type. Or it may happen that it is almost always a certain type.
Optimizations can be made at this time. Or some other certain property
of a certain local variable might always be the same. A rather
prolific example of this: hash-table pre-fetch caching. That’s… not
what it’s actually usually called, but the idea is that you already
know the outcome of a certain operation because the values upon which
it depends are not likely or are even guaranteed not to change.
There’s a lot of things going on out there which benefit from these
kinds of optimizations.

Yes, but what stops the non-runtime compiler to do the same
optimisations? I don’t argue with you that a JIT compiler can optimise
a lot. I argue with your statement that JIT can optimise better than
a conventional compiler, what’s more, that the JIT compiler can gain
run-time from these optimisations that is more than what is needed to
do the optimisation, that is, that the same program will be faster with
the JIT compiler than with a traditional optimising compiler generating
an executable binary.

In practice, none of these things are true because database
applications are never bottlenecked at the CPU, they are bottlenecked
at bandwidth.

I can’t argue with that - I am not really a database guy and even if I
was, chances are I wouldn’t really know the internal workings of a fat
big database engine like Oracle. Nevertheless, I still believe that if
the SQL engine would be absolutely sure that certain SQL statements
could never be followed by certain other statements, it could make
advantage of that. That is, if it had a complete overview of the user
application (like a static compiler) it could take advantage of that
information, but since it doesn’t (as it is ‘compiling’ just in time)
it can not do that. Orthogonal to this aspect is the fact that a real
database engine has to serve simultaneous requests, resolve access
conflicts, interdependencies of multiple pending transactions and so
on. That is not in the compiler domain, I think, but more in the
opsys domain, because it is all about parallel processes, resource
allocation, locks, synchronisation and the like.

You should never assume the database will never be changed because a
mistake might be made.

It is generally true, but I was talking about a hypothetical example.

Does your application only allow one client to access any individual
database at any time? You may want an “embedded” database that does
not make transactions via a client-server model, but rather is just a
library you link directly into your application.

I am aware of SQLite, which is exactly that, a library that interprets
and executes SQL statements. The application I was talking about was a
hypothetical one, not a real one. Nevertheless, there are cases where a
database is changing quite infrequently while having to serve huge
amounts of retrieval operations. Not all databases are transaction
systems.

Zoltan

22

In practice, none of these things are true because database
applications are never bottlenecked at the CPU, they are bottlenecked
at bandwidth.

Ummmm… Maybe if all you use a database for is web page hosting.

I work in telecom, and we have tools that analyze MILLIONS of records at a time, with the results going directly into another table, so bandwidth is a non-issue and it sometimes calculates for a few hours.

Maybe we could squeeze out more performance by performing the calculations outside the DB, but it’s still faster than any other tools we have seen in use by a tremendous difference.

Pat

23

Planning and designing code is the most important and most time-consuming
part of programming. Debugging should occupy no more that 1/3 of total
project time, and typically should be much less.

Excessive time debugging is a clear indication that the code was not well
designed.

You are absolutely right.

Limin

Yes, absolutely right… as long as your project never gets exposed to the real
world. If your software is actually released to the public, and a non-trivial number
of people get it and use it, there are GUARANTEED to be a few that will break
it because they try to use it for something you never imagined it could be used
for and therefore were unable to design around.

At work we make software that manages advertising and scheduling for broadcast
media. We’re the industry leaders in several market segments, so our program
gets a lot of use. We recently got a bug report from a client whose program
crashed when they tried to place a ridiculous number of ads (in the tens of
thousands IIRC) on the schedule for a single show. Why in the world would
they want to do that?!? Well… because they were running an online broadcast
with targetted advertising technology, and that was the best kludge they could
come up with to track what was actually being run.

That’s the sort of thing you just can’t design for ahead of time, and it happens
all the time in the real world. I stand by my claim that over the total lifecycle
of a project, far more work is done on maintenance than was ever done on
initially producing the code.>From: Limin Fu

Subject: Re: [SDL] [OT] Dao language 1.0.1 with SDL and OpenGL bindings

24

Completely off-topic here, but having seen similar situations, I’d have to agree.
A database server tends to have a heck of a lot more number-crunching
hardware power available than the client systems that connect to it, and a
good SQL engine is already heavily optimized for dealing with calculations
on large sets of data.

Trying to hand some of the work off to the client is like… umm…struggles to
come up with a good analogy OK. Imagine a bodybuilder with two 100-lb
dumbbells in each hand, because he’s just that strong. And then he hands
one of them to a stereotypical 95-pound weakling in high school and says
"hey kid, hold this for me, would you?" Yeah, now he’s got less weight to
carry, but the kid’s useless for actually helping out. :P>----- Original Message ----

From: Patryk Bratkowski
Subject: Re: [SDL] [OT] Dao language 1.0.1 with SDL and OpenGL bindings

In practice, none of these things are true because database
applications are never bottlenecked at the CPU, they are bottlenecked
at bandwidth.

Ummmm… Maybe if all you use a database for is web page hosting.

I work in telecom, and we have tools that analyze MILLIONS of records
at a time, with the results going directly into another table, so bandwidth
is a non-issue and it sometimes calculates for a few hours.

Maybe we could squeeze out more performance by performing the
calculations outside the DB, but it’s still faster than any other tools we
have seen in use by a tremendous difference.

25

2009/6/10 Mason Wheeler

That’s the sort of thing you just can’t design for ahead of time, and it
happens
all the time in the real world. I stand by my claim that over the total
lifecycle
of a project, far more work is done on maintenance than was ever done on
initially producing the code.

I would say the maintainability of a project depends more on its original
design than on its language of implementation. Maintenance is not just about
fixing problems, it is also about adding new functionality, a well designed
software would make adding new functionality much easier.

26

I’ve seen NES and SNES games crash… but more often than not, it’s
the hardware acting up. Most problems on those systems were minor
glitches, but I did experience one on the Genesis. It even has a
name: “Mojo’s Time Crunch”… Very bad.

As for the main conversation here, I support the ‘tools’ idea too.

Jonny DOn Tue, Jun 9, 2009 at 7:14 PM, Mason Wheeler wrote:

(Paulo mentioned that the Xbox 360 uses a lot of managed code. ?You know what else it has a lot
of? ?Updates because the release version is full of bugs. ?I don’t think I ever once saw an NES or
SNES game crash…)

27

Yes, absolutely right… as long as your project never gets exposed to the
real world.

Our products were very much exposed to the real world.

If your software is actually released to the public, and a
non-trivial number of people get it and use it, there are GUARANTEED to be
a few that will break it because they try to use it for something you never
imagined it could be used for and therefore were unable to design around.

One of the tests my boss used to do was to bang on the keyboard randomly and
issue goofy commands to the code. It didn’t break. It might do something
goofy in response to a goofy command, but the response was exactly what it
should have been per the design spec. (Goofy command in this context means a
legitimate but non-sensical command; illegitimate commands were ignored.)

The vast majority of user problems were hardware failures, or bugs in the
user’s system (which we coded around when possible).

That’s the sort of thing you just can’t design for ahead of time, and it
happens all the time in the real world. I stand by my claim that over
the total lifecycle of a project, far more work is done on maintenance than
was ever done on initially producing the code.

Your original claim was that most of the time was spent in debugging and
maintenance. Time spent in maintenance is entirely dependant on the users’
desire for new features or modifications. Software can and should be designed
to allow relatively painless enhancements. It worked for us.

JeffOn Wednesday 10 June 2009 04:52, Mason Wheeler wrote:

28

OTOH, it is possible that no compiler can do as well as you. There
are some astonishingly good programmers in the world. And, you could
well be one of them. (I used to generate 10 to 20 times more bug free
code than the people I worked with, and I know of people who are 10 or
more times more productive than I ever was.) Then consider that if you
are that good, then 98% of the rest of programmers are not good enough
to do as well as a compiler. Then consider that if you used your skill
to learn how to leverage a good optimizing compiler that you could
then be many times better than you currently are.

Does it mean I’m one of those if I honestly don’t get why everyone else
says that stuff like memory management, recursion and multi-threading
are difficult? :stuck_out_tongue:

Yeah, if that is honestly true, then you are head an shoulders above
the average programmer. If you haven’t read "The Mythical Man Month"
get a copy right now and read it.

And I never claimed I’m better than a compiler. ?I know better than that.
What I said is that no matter how good your compiler is at optimizing
code, it can never make up for bad language design or bad algorithm
design.

OK, I did not read that in what you said. Seriously, that is not what
I got out of your posting. If I had I would have agreed with you
instead of arguing with you. OTOH, I have to point out that what
qualifies as bad at one time in history or for one situation can be
the best at another time and situation and vice versa.

I will say this. ?With a profiler and a natively-compiled language that
will let me code at any level, functional, OO, procedural or even raw
assembly, I will always be able to produce better code than I could
with a compiler that tries to manage all the complexity for you and
doesn’t let you work below certain arbitrary levels of abstraction.

What this comes down to is the definition of the word “better”. You
have a working definition of the word that lets you honestly say that
your code is better. If you create what you consider to be a great
piece of code, but I can’t use it because it doesn’t work in my
production environment, then your code is not “better” by my
definition of the word.

Which is better, a Volkswagen beetle or a Mac dump truck? Depends on
whether I want to build a sand rail or haul 20 tons of sand. Any time
you use the word “better” without being able to assign a measurable
metric that you can compare with > you are playing in a fantasy land.
The existence of the word “better” and my ability to write a sentences
such as , “A grape is better than a neutron star” fools most people
into believing that the word “better” and such sentences have meaning,
when in fact they don’t.

Honestly, half of what I hear people arguing about are sentences that
have no actual meaning.

Bob PendletonOn Tue, Jun 9, 2009 at 9:25 PM, Mason Wheeler wrote:

----- Original Message ----
From: Bob Pendleton <@Bob_Pendleton>
Subject: Re: [SDL] [OT] Dao language 1.0.1 with SDL and OpenGL bindings

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
±----------------------------------------------------------

29

Does it mean I’m one of those if I honestly don’t get why everyone else
says that stuff like memory management, recursion and multi-threading
are difficult? :stuck_out_tongue:

Yeah, if that is honestly true, then you are head an shoulders above
the average programmer. If you haven’t read "The Mythical Man Month"
get a copy right now and read it.

Heard about it, never read it. Maybe I will sometime. I heard it’s about
project management. I’m one of the lower guys on the totem pole at
work, since I’m new with the company. How would this book apply
to me?

I will say this. With a profiler and a natively-compiled language that
will let me code at any level, functional, OO, procedural or even raw
assembly, I will always be able to produce better code than I could
with a compiler that tries to manage all the complexity for you and
doesn’t let you work below certain arbitrary levels of abstraction.

What this comes down to is the definition of the word “better”. You
have a working definition of the word that lets you honestly say that
your code is better. If you create what you consider to be a great
piece of code, but I can’t use it because it doesn’t work in my
production environment, then your code is not “better” by my
definition of the word.

Fair enough. Here are my personal criteria for quality code, in no
particular order:

Security. It doesn’t matter how “cool” a program is if it’s got a
buffer overflow in it that lets people steal your credit card number.
Fortunately, in Delphi you’ve gotta really work hard to get a buffer
overflow that doesn’t raise a runtime exception. :stuck_out_tongue:

Functionality: This one’s obvious. A program’s no good unless
it does something useful.

User-friendliness: this one’s related to functionality. If a program
does something useful but the end-user can’t figure out how,
or the process of doing it is complicated and unintuitive, it’s of
no use to them, especially if there’s a competing product that
does it more easily.

Efficiency: This is particularly important in game programming.
All other things being equal, would you rather play a game where
the levels take a minute to load, or where they load in 5 seconds?
And on a smaller time-scale, the less CPU time each individual
operation takes, the more you can fit into a frame that only lasts,
X number of miliseconds, allowing you to boost your framerate,
improve graphics or gameplay quality, or both.>----- Original Message ----

From: Bob Pendleton
To: A list for developers using the SDL library. (includes SDL-announce)
Sent: Wednesday, June 10, 2009 11:11:22 AM
Subject: Re: [SDL] [OT] Dao language 1.0.1 with SDL and OpenGL bindings

30

Does it mean I’m one of those if I honestly don’t get why everyone else
says that stuff like memory management, recursion and multi-threading
are difficult? :stuck_out_tongue:

Yeah, if that is honestly true, then you are head an shoulders above
the average programmer. If you haven’t read "The Mythical Man Month"
get a copy right now and read it.

Heard about it, never read it. Maybe I will sometime. ?I heard it’s about
project management. ?I’m one of the lower guys on the totem pole at
work, since I’m new with the company. ?How would this book apply
?to me?

No, it is not about project management. It is about misconceptions
about the task of programming, how they affect getting products out
the door, and how to avoid them.

Even if it was about project management it would directly apply to any
programmer because you are managing your project. Good heavens man,
99% of programming is managing your project.

I will say this. ?With a profiler and a natively-compiled language that
will let me code at any level, functional, OO, procedural or even raw
assembly, I will always be able to produce better code than I could
with a compiler that tries to manage all the complexity for you and
doesn’t let you work below certain arbitrary levels of abstraction.

What this comes down to is the definition of the word “better”. You
have a working definition of the word that lets you honestly say that
your code is better. If you create what you consider to be a great
piece of code, but I can’t use it because it doesn’t work in my
production environment, then your code is not “better” by my
definition of the word.

Fair enough. ?Here are my personal criteria for quality code, in no
particular order:

Security. ?It doesn’t matter how “cool” a program is if it’s got a
buffer overflow in it that lets people steal your credit card number.
Fortunately, in Delphi you’ve gotta really work hard to get a buffer
overflow that doesn’t raise a runtime exception. :stuck_out_tongue:

How do you measure security? The number of buffer overflows is not a
measure of security.

Functionality: ?This one’s obvious. ?A program’s no good unless
it does something useful.

Compliance with the specification. This is a useful measure. If code
doesn’t comply with the specification it has no value. BTW, this is an
either or, their is not better or worse when it comes to complying
with the specification.

User-friendliness: this one’s related to functionality. ?If a program
does something useful but the end-user can’t figure out how,
or the process of doing it is complicated and unintuitive, it’s of
no use to them, especially if there’s a competing product that
does it more easily.

Yep, with a focus groups and good use of prototypes you can measure
the usability of a GUI. I have never met a programmer (including
myself) who was qualified to judge usability.

Efficiency: This is particularly important in game programming.
All other things being equal, would you rather play a game where
the levels take a minute to load, or where they load in 5 seconds?
And on a smaller time-scale, the less CPU time each individual
operation takes, the more you can fit into a frame that only lasts,
X number of miliseconds, allowing you to boost your framerate,
improve graphics or gameplay quality, or both.

In that example the word “efficiency” has no meaning. Efficiency is
the ratio of something to its cost. For example, in terms of dollars
per bit transported 200 miles a pick up truck full of DVDs is a whole
lot more efficient than building an OC-192 line.

What you are really talking about is not efficiency, but just another
example of complying to specifications. If the specification says that
you will achieve 60 frames/second then meeting that specification is a
requirement. IF you don’t meet it, you have 0 value. OTOH exceeding it
is a waste of money and therefore is not an inefficient use of the
companies money.

This is as far off topic as I am willing to go, and farther than I
should have gone. End of Topic.

Bob PendletonOn Wed, Jun 10, 2009 at 1:53 PM, Mason Wheeler wrote:

----- Original Message ----
From: Bob Pendleton <@Bob_Pendleton>
To: A list for developers using the SDL library. (includes SDL-announce)
Sent: Wednesday, June 10, 2009 11:11:22 AM
Subject: Re: [SDL] [OT] Dao language 1.0.1 with SDL and OpenGL bindings

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
±----------------------------------------------------------

31

How do you measure security? The number of buffer overflows is not a
measure of security.

Good question. Just look at the “Is IE or Firefox more secure” debates.
But do you mean to say, with a question like that, that security isn’t
important because it can’t be easily quantified?

Functionality: This one’s obvious. A program’s no good unless
it does something useful.

Compliance with the specification. This is a useful measure. If code
doesn’t comply with the specification it has no value. BTW, this is an
either or, their is not better or worse when it comes to complying
with the specification.

Only if the spec is right. Your statement is only valid if the
customer actually knows what they want.

User-friendliness: this one’s related to functionality. If a program
does something useful but the end-user can’t figure out how,
or the process of doing it is complicated and unintuitive, it’s of
no use to them, especially if there’s a competing product that
does it more easily.

Yep, with a focus groups and good use of prototypes you can measure
the usability of a GUI. I have never met a programmer (including
myself) who was qualified to judge usability.

Focus groups? snort Didn’t Microsoft produce the original Xbox
controller–you know, the one that wouldn’t fit well into the hand of
anyone smaller than a gorilla?–because some focus group liked it?
Focus groups are among the worst ways to produce good usability.
(Hollywood’s use of the practice makes for lousy movie QC too.)
You get good usability by 1) dogfooding and 2) beta tests with
actual people who are going to use the product.

Efficiency: This is particularly important in game programming.
All other things being equal, would you rather play a game where
the levels take a minute to load, or where they load in 5 seconds?
And on a smaller time-scale, the less CPU time each individual
operation takes, the more you can fit into a frame that only lasts,
X number of miliseconds, allowing you to boost your framerate,
improve graphics or gameplay quality, or both.

In that example the word “efficiency” has no meaning.

What you are really talking about is not efficiency, but just another
example of complying to specifications. If the specification says that
you will achieve 60 frames/second then meeting that specification is a
requirement. IF you don’t meet it, you have 0 value. OTOH exceeding it
is a waste of money and therefore is not an inefficient use of the
companies money.

Again, this is assuming that the spec is right. (And, more
fundamentally, that it’s complete! 60 FPS on what hardware
configuration?) Specs don’t magically make for good programs.
They help quite a bit, but they’re not code and can’t substitute for
it. (See http://www.joelonsoftware.com/items/2007/12/03.html for
the problem with thinking this way.)

Also, your assertion that if you don’t meet it you have 0 value seems
a bit strange to me, as does the statement that going beyond it is
wasteful. Are you saying that if you only get 59 FPS then your code
has no intrinsic value? Also, is there no value in producing code that’s
capable of 70 FPS on the specified hardware, thus allowing you to
lower your minimum system requirements and make your game
available to more potential buyers?

This seems to be a fundamental philosophical difference. You try
to measure quality by numbers and things that can be tested,
specified and proven. I prefer "will people enjoy using this?"
and if not, “how can I make it work better?” Completely
subjective, impossible to prove, but it’s been very
successful for me as a design and implementation guideline.
I’ve occasionally gone out on my own initiative and done
something the spec didn’t mention because I’d like it
better that way if I was the one using the program. Most
of the time when I do that, the boss ends up having the
spec altered to match my work.>----- Original Message ----

From: Bob Pendleton
Subject: Re: [SDL] [OT] Dao language 1.0.1 with SDL and OpenGL bindings

32

How do you measure security? The number of buffer overflows is not a
measure of security.

Good question. ?Just look at the “Is IE or Firefox more secure” debates.
But do you mean to say, with a question like that, that security isn’t
important because it can’t be easily quantified?

Nope, I’m saying that unless you can quantify it and measure it you
can’t claim to have it.

Functionality: ?This one’s obvious. ?A program’s no good unless
it does something useful.

Compliance with the specification. This is a useful measure. If code
doesn’t comply with the specification it has no value. BTW, this is an
either or, their is not better or worse when it comes to complying
with the specification.

Only if the spec is right. ?Your statement is only valid if the
customer actually knows what they want.

If the customer doesn’t know what they want it is your job to guide
them to learn what they want. It is not your job to decide what they
want for them.

User-friendliness: this one’s related to functionality. ?If a program
does something useful but the end-user can’t figure out how,
or the process of doing it is complicated and unintuitive, it’s of
no use to them, especially if there’s a competing product that
does it more easily.

Yep, with a focus groups and good use of prototypes you can measure
the usability of a GUI. I have never met a programmer (including
myself) who was qualified to judge usability.

Focus groups? ?snort Didn’t Microsoft produce the original Xbox
controller–you know, the one that wouldn’t fit well into the hand of
anyone smaller than a gorilla?–because some focus group liked it?
Focus groups are among the worst ways to produce good usability.
(Hollywood’s use of the practice makes for lousy movie QC too.)
You get good usability by 1) dogfooding and 2) beta tests with
actual people who are going to use the product.

MS is the perfect example of a company that has never ever made
effective use of basic human factors principles.

Efficiency: This is particularly important in game programming.
All other things being equal, would you rather play a game where
the levels take a minute to load, or where they load in 5 seconds?
And on a smaller time-scale, the less CPU time each individual
operation takes, the more you can fit into a frame that only lasts,
X number of miliseconds, allowing you to boost your framerate,
improve graphics or gameplay quality, or both.

In that example the word “efficiency” has no meaning.

What you are really talking about is not efficiency, but just another
example of complying to specifications. If the specification says that
you will achieve 60 frames/second then meeting that specification is a
requirement. IF you don’t meet it, you have 0 value. OTOH exceeding it
is a waste of money and therefore is not an inefficient use of the
companies money.

Again, this is assuming that the spec is right.

If the spec is wrong, or incomplete, you need to point that out and do
your best to make sure the spec is complete and that the customer
believes it is right.

?(And, more

fundamentally, that it’s complete! ?60 FPS on what hardware
configuration?) ?Specs don’t magically make for good programs.
They help quite a bit, but they’re not code and can’t substitute for
it. ?(See http://www.joelonsoftware.com/items/2007/12/03.html for
the problem with thinking this way.)

I like Joel, but you can’t use him as a authority in one area while
refusing to accept him in others. He is a huge fan of LISP, the
original (more than 50 years and going strong) managed code
environment. BTW, Joel is the boss. He gets to write and change the
specs. He writes from the point of view of the responsible party. You,
the programmer, are rarely the responsible party. You get to suggest,
request, and even through a tantrum. You do not get to make the final
decision.

Also, your assertion that if you don’t meet it you have 0 value seems
a bit strange to me, as does the statement that going beyond it is
wasteful.

Are you saying that if you only get 59 FPS then your code
has no intrinsic value?

If the spec says 60, the 59 doesn’t cut it.

Anecdote time: The team I was on at E&S built what was at the time the
fastest graphics box ever. (it was not as fast as a $15 card you find
in a box at Goodwill today…) Chrysler put up $30 million to help
develop the box. If the box was late, or it lacked any of the required
features, E&S would have to give back the $30 million. E&S was making
about $120 million a year back then. If they had to give back the
money the company would close. Two months before the end of the
contract the lawyers from E&S and Chrysler sat down with the VP of
engineering and the President of the division and went over the box
and ran tests and demos to demonstrate that every feature was there.
They found one that wasn’t. It had been left out of spec. We had 1
month to design, implement, and fully test the ability to do color
overlay planes using our hardware and X11. The trouble was that we had
no overlay planes. We did it. Blood was not shed, though tears were. I
did get a whole box of marker pens thrown at me one…at…a…time.

That is a case where not meeting the specs had a value of a negative
$30 million dollars. That is how business really works. Programming
has to work within business. Saying that not meeting the spec gives
you code with $0 value is being very nice.

?Also, is there no value in producing code that’s
capable of 70 FPS on the specified hardware, thus allowing you to
lower your minimum system requirements and make your game
available to more potential buyers?

If you got to 70 without affecting budget and schedule, who is going
to complain? That is found money. If getting there cost anything more
than getting to 60, then yes, it was a mistake to go there. If not
going past 60 could have save a day on schedule, then going to 70 is a
dead loss.

This seems to be a fundamental philosophical difference.

Yep. I base my view on having brought in a number of projects on time
and on budget.

You try

to measure quality by numbers and things that can be tested,
specified and proven. ?I prefer "will people enjoy using this?"
and if not, “how can I make it work better?” ?Completely
subjective, impossible to prove, but it’s been very
successful for me as a design and implementation guideline.
I’ve occasionally gone out on my own initiative and done
something the spec didn’t mention because I’d like it
better that way if I was the one using the program. ?Most
of the time when I do that, the boss ends up having the
spec altered to match my work.

You finally got it. When you see that the spec is wrong or that it can
be improved you change the spec. You do it after you have cleared it
with the customer, whomever that may be.

The boss has a budget and a schedule to manage not to mention having
to manage customer expectations. If the programmer decides to go off
on his own and make changes that effect any of those he needs to be
talked to. The second time he needs to be fired. And yes, I have fired
a lead developer who did everything you describe and created a great
game. Trouble is that it was 4 months late because of what he did.
That caused us to miss the Christmas market.

Bob PendletonOn Wed, Jun 10, 2009 at 5:45 PM, Mason Wheeler wrote:

----- Original Message ----
From: Bob Pendleton <@Bob_Pendleton>
Subject: Re: [SDL] [OT] Dao language 1.0.1 with SDL and OpenGL bindings

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
±----------------------------------------------------------

33

I like Joel, but you can’t use him as a authority in one area while
refusing to accept him in others.

Sure I can. He’s human and therefore imperfect. He’s got a whole lot
of very good ideas and a bunch that aren’t so good. So I take the good
and try to incorporate it, and dismiss the rest.

He is a huge fan of LISP, the original (more than 50 years and going
strong) managed code environment.

He’s also the guy who wrote Back To Basics, The Law of Leaky
Abstractions, and The Perils of Java Schools, and IMO those pieces
alone prove he’s smarter than the vast majority of coders these days.
Also, he does most of his work on network-based apps, which are a
heck of a lot more forgiving when it comes to performance than
desktop programs.

Anecdote time:
That is a case where not meeting the specs had a value of a negative
$30 million dollars. That is how business really works. Programming
has to work within business. Saying that not meeting the spec gives
you code with $0 value is being very nice.

Also, is there no value in producing code that’s
capable of 70 FPS on the specified hardware, thus allowing you to
lower your minimum system requirements and make your game
available to more potential buyers?

If you got to 70 without affecting budget and schedule, who is going
to complain? That is found money. If getting there cost anything more
than getting to 60, then yes, it was a mistake to go there. If not
going past 60 could have save a day on schedule, then going to 70 is a
dead loss.

The boss has a budget and a schedule to manage not to mention having
to manage customer expectations. If the programmer decides to go off
on his own and make changes that effect any of those he needs to be
talked to. The second time he needs to be fired. And yes, I have fired
a lead developer who did everything you describe and created a great
game. Trouble is that it was 4 months late because of what he did.
That caused us to miss the Christmas market.

E&S, huh? Thanks for the name. Now I know never to go work for them.
They’ve got their ideas fundamentally backwards. You want a company
that knows how to make games, look at Blizzard. They don’t care about
missing the Christmas market. Heck, they don’t care about missing
several Christmas markets in a row. All they care about is doing the game
right, like your unfortunate lead developer did. They take the time to get
the details right.

Case in point: They had Starcraft almost finished as basically a
Warcraft game in space, when they realized it sucked. So they went back
and redesigned and recoded pretty much the whole thing, and ended up
eventually releasing what’s still regarded today, 11 years later, as one of
the greatest RTSes of all time.

It drives the fans up the wall sometimes, myself included, but somehow
they always end up being forgiven because the finished product is Just
That Good. Consistently. Every time. And you know what? When
their games get released, whenever the release happens to be, the
profits come pouring in.

I’ll take their model over “build to a rigid spec on a rigid deadline” any
day.>----- Original Message ----

From: Bob Pendleton
Subject: Re: [SDL] [OT] Dao language 1.0.1 with SDL and OpenGL bindings

34

Case in point: They had Starcraft almost finished as basically a
Warcraft game in space, when they realized it sucked. So they went back
and redesigned and recoded pretty much the whole thing, and ended up
eventually releasing what’s still regarded today, 11 years later, as one of
the greatest RTSes of all time.

It drives the fans up the wall sometimes, myself included, but somehow
they always end up being forgiven because the finished product is Just
That Good. Consistently. Every time. And you know what? When
their games get released, whenever the release happens to be, the
profits come pouring in.

I’ll take their model over “build to a rigid spec on a rigid deadline” any
day.

Don’t forget Duke Nukem Forever…

That game is fantastic xD

35

Hey, you can’t say I didn’t try.

What you are doing is something that is well documented in psychology.
You are accepting only details that you think support your point and
are rejecting everything that doesn’t without even looking at it. You
are backing it up with an appeal to authority, and the funny part is
that as far as I can tell you are misinterpreting the authority.

BTW, E&S was not a game company. The company where I fired the guy,
was a game company. E&S did things exactly the way you like them done.
They built the very best graphics machines in the world. People loved
them and the profits came rolling in. It was founded by Dave Evans and
Ivan Sutherland. They had patents on all the key parts of 3D graphics.
But, they didn’t see what was happening to their market and they are
pretty much broke now. The tiny company that is left makes graphic
projectors for planetariums. The economics of doing it your way killed
them.

If you go back to what I said you’ll see that I talked about modifying
the spec. I said that over and over again. I was not talking about a
rigid spec. When the spec doesn’t work you have to start over with a
new spec. That is a concept called the waterfall model of design. It
is exactly what you describe Blizzard doing. Sadly, very few companies
have a business model that provides the kind of profits needed to do
it as completely as Blizzard does. If you look at the history, of oh
say USAF aircraft you’ll see they do the same thing. You have a whole
series of X craft that test new ideas, and then for every model
deployed their are a whole lot that were not. Where are all the planes
between the B-58 and the XB-70? And yet, everyone of those had a spec
that was complied with, and modified. Why else were there more than 15
different versions built?

Have fun,

Bob PendletonOn Wed, Jun 10, 2009 at 9:25 PM, Mason Wheeler wrote:

----- Original Message ----

From: Bob Pendleton <@Bob_Pendleton>
Subject: Re: [SDL] [OT] Dao language 1.0.1 with SDL and OpenGL bindings

I like Joel, but you can’t use him as a authority in one area while
refusing to accept him in others.

Sure I can. ?He’s human and therefore imperfect. ?He’s got a whole lot
of very good ideas and a bunch that aren’t so good. ?So I take the good
and try to incorporate it, and dismiss the rest.

He is a huge fan of LISP, the original (more than 50 years and going
strong) managed code environment.

He’s also the guy who wrote Back To Basics, The Law of Leaky
Abstractions, and The Perils of Java Schools, and IMO those pieces
alone prove he’s smarter than the vast majority of coders these days.
Also, he does most of his work on network-based apps, which are a
heck of a lot more forgiving when it comes to performance than
desktop programs.

Anecdote time:
That is a case where not meeting the specs had a value of a negative
$30 million dollars. That is how business really works. Programming
has to work within business. Saying that not meeting the spec gives
you code with $0 value is being very nice.

Also, is there no value in producing code that’s
capable of 70 FPS on the specified hardware, thus allowing you to
lower your minimum system requirements and make your game
available to more potential buyers?

If you got to 70 without affecting budget and schedule, who is going
to complain? That is found money. If getting there cost anything more
than getting to 60, then yes, it was a mistake to go there. If not
going past 60 could have save a day on schedule, then going to 70 is a
dead loss.

The boss has a budget and a schedule to manage not to mention having
to manage customer expectations. If the programmer decides to go off
on his own and make changes that effect any of those he needs to be
talked to. The second time he needs to be fired. And yes, I have fired
a lead developer who did everything you describe and created a great
game. Trouble is that it was 4 months late because of what he did.
That caused us to miss the Christmas market.

E&S, huh? ?Thanks for the name. Now I know never to go work for them.
They’ve got their ideas fundamentally backwards. ?You want a company
that knows how to make games, look at Blizzard. ?They don’t care about
missing the Christmas market. ?Heck, they don’t care about missing
several Christmas markets in a row. ?All they care about is doing the game
right, like your unfortunate lead developer did. ?They take the time to get
the details right.

Case in point: ?They had Starcraft almost finished as basically a
Warcraft game in space, when they realized it sucked. ?So they went back
and redesigned and recoded pretty much the whole thing, and ended up
eventually releasing what’s still regarded today, 11 years later, as one of
the greatest RTSes of all time.

It drives the fans up the wall sometimes, myself included, but somehow
they always end up being forgiven because the finished product is Just
That Good. ?Consistently. ?Every time. ?And you know what? ?When
their games get released, whenever the release happens to be, the
profits come pouring in.

I’ll take their model over “build to a rigid spec on a rigid deadline” any
day.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
±----------------------------------------------------------

36

Bob Pendleton wrote:

Hey, you can’t say I didn’t try.

What you are doing is something that is well documented in psychology.
You are accepting only details that you think support your point and
are rejecting everything that doesn’t without even looking at it. You
are backing it up with an appeal to authority, and the funny part is
that as far as I can tell you are misinterpreting the authority.

BTW, E&S was not a game company. The company where I fired the guy,
was a game company. E&S did things exactly the way you like them done.
They built the very best graphics machines in the world. People loved
them and the profits came rolling in. It was founded by Dave Evans and
Ivan Sutherland. They had patents on all the key parts of 3D graphics.
But, they didn’t see what was happening to their market and they are
pretty much broke now. The tiny company that is left makes graphic
projectors for planetariums. The economics of doing it your way killed
them.

I worked at E&S, we were building multi monitor, real-time flight
simulators before the PC keyboard was invented. Sad to hear they aren’t
still riding the crest of success.

37

You’re absolutely right, Bob. If you can’t quantify and measure it, then for
all practical purposes, it doesn’t exist.

“What are the facts? Again and again and again–what are the facts? Shun
wishful thinking, ignore divine revelation, forget what ‘the stars fortell’,
avoid opinion, care not what the neighbors think, never mind the unguessable
’verdict of history’–what are the facts, and to how many decimal places? You
pilot always into an unknown future, facts are your only clue. Get the
facts!” – Robert Heinlein

If you can’t quantify it, what you have is a conjecture, not a theorem.
Conjectures are useful, but to really know what you’re doing, you need
theorems, not conjectures.

Jeff
(Those who don’t understand the above should have paid more attention in their
math classes. Software engineering is applied math. See, for example, “The
Art of Computer Programming” by Donald Knuth.)On Wednesday 10 June 2009 18:46, Bob Pendleton wrote:

Nope, I’m saying that unless you can quantify it and measure it you
can’t claim to have it.

38

Mason Wheeler wrote:

I’ll take their model over “build to a rigid spec on a rigid
deadline” any
day.

Is there some way I can ensure that you, and people you’ve taught,
never get anywhere near programming a life support system, or
aeroplane, etc, that I may come in to contact with?

As a part time industrial programmer, the ‘ship now patch later’ thing
makes me want to vomit. People would like to think it’s professional,
but all one’s doing is marketing gloss over crappy coding/procedures.
Admittedly, sometimes there are understandable historical reasons for
crappy code and procedures. But that is not an excuse for not striving
for perfect code and procedures. First time. Each and Every time.

I’d rather sell some code and take a support contract where I don’t have
to do anything, than have to write even one line of new code a month
under support because I screwed up somewhere. And I guess I’ll just
never understand why professional scientists (because that’s what coders
are) would want to have it any other way.

P.

39

Hi,

completly right on the point Bob.

As an example, of the right tool depends on which context.

I had the luck to spend a couple of years at CERN.

There they have tons of highly optimized Fortran and C++ code processing GB
of
data per minute coming out of the particle accelerator. With optimized
network
protocols done at the IP level for the cluster communications.

But the cluster graphical monitoring tools are mostly written in managed
languages.

And the cluster configuration tools and runtime options are done in Python.

Again a good example of using the best tool for the job at hand.–
Paulo

On Wed, Jun 10, 2009 at 8:11 PM, Bob Pendleton wrote:

… cutted …

Which is better, a Volkswagen beetle or a Mac dump truck? Depends on
whether I want to build a sand rail or haul 20 tons of sand. Any time
you use the word “better” without being able to assign a measurable
metric that you can compare with > you are playing in a fantasy land.
The existence of the word “better” and my ability to write a sentences
such as , “A grape is better than a neutron star” fools most people
into believing that the word “better” and such sentences have meaning,
when in fact they don’t.

40

Mason Wheeler wrote:

I’ll take their model over “build to a rigid spec on a rigid deadline” any
day.

Is there some way I can ensure that you, and people you’ve taught,
never get anywhere near programming a life support system, or
aeroplane, etc, that I may come in to contact with?

As a part time industrial programmer, the 'ship now patch later’
thing makes me want to vomit. People would like to think it’s
professional, but all one’s doing is marketing gloss over crappy
coding/procedures. Admittedly, sometimes there are
understandable historical reasons for crappy code and
procedures. But that is not an excuse for not striving for perfect
code and procedures. First time. Each and Every time.

I’d rather sell some code and take a support contract where I
don’t have to do anything, than have to write even one line of new
code a month under support because I screwed up somewhere.
And I guess I’ll just never understand why professional
scientists (because that’s what coders are) would want to have
it any other way.

OK, I’m all confused here. I say “I’d rather take the time to get it
right than be stuck on a schedule that forces me to ship an
inferior product just to meet the deadline,” and you say “I never
want you working for me because you’d ship crap and try to
patch later instead of trying to get it right the first time.” How in
the world did you read it 180 degrees from what I actually
said?>----- Original Message ----

From: Peter Lawler
Subject: Re: [SDL] [OT] Dao language 1.0.1 with SDL and OpenGL bindings