• ore-sama <spam here.lot> Nov 07 2008
• bearophile <bearophileHUGS lycos.com> Nov 07 2008
• ore-sama <spam here.lot> Nov 07 2008
• Ary Borenszweig <ary esperanto.org.ar> Nov 07 2008
• Walter Bright <newshound1 digitalmars.com> Nov 07 2008
• Derek Parnell <derek psych.ward> Nov 07 2008
• Janderson <ask me.com> Nov 09 2008
• ore-sama <spam here.lot> Nov 09 2008
• Janderson <ask me.com> Nov 09 2008
• "Chris R. Miller" <lordsauronthegreat gmail.com> Nov 09 2008
• Walter Bright <newshound1 digitalmars.com> Nov 09 2008

ore-sama <spam here.lot> writes:

bearophile Wrote:

 After 8 hours of coding, when I'm tired, I'm a novice myself, and I can
appreciate any help the compiler can offer.
 

bearophile <bearophileHUGS lycos.com> writes:

ore-sama:
 Can tired programmer think about business process?


I can answer you that I use the first hours to think more and the later hours
to program more.
But what I've just said can't help you see why it's so important for the
compiler to help avoid as many bugs as possible. I can't explain such essential
concept in few lines here, so I suggest you to keep programming and reading,
eventually you will probably get it.

Later,
bearophile

ore-sama <spam here.lot> writes:

bearophile Wrote:

 But what I've just said can't help you see why it's so important for the
compiler to help avoid as many bugs as possible. I can't explain such essential
concept in few lines here, so I suggest you to keep programming and reading,
eventually you will probably get it.
 

Ary Borenszweig <ary esperanto.org.ar> writes:

ore-sama escribió:
 bearophile Wrote:
 
 But what I've just said can't help you see why it's so important for the
compiler to help avoid as many bugs as possible. I can't explain such essential
concept in few lines here, so I suggest you to keep programming and reading,
eventually you will probably get it.




if(x);
   doSomething

Cool, you can express this: test something, and do nothing if true. Do 
you really need that expressiveness?

Another one: the Eclipse Java compiler would tell if you might get a 
NullPointerException since at the beginning of a method you assign some 
variable to null, then you might change it to something non-null in some 
path, but you might not realize that you didn't make sure to set it to 
something non-null in all paths. So there goes Eclipse and tells you: in 
this specific line, that variable might be null.

Do you want to be able to express "I probably have a bug here"?

Walter Bright <newshound1 digitalmars.com> writes:

Ary Borenszweig wrote:
 Do you want to be able to express "I probably have a bug here"?


Even if the code is correct, if it looks like a bug, it will cause 
problems by repeatedly being flagged by others doing a code review.

Derek Parnell <derek psych.ward> writes:

On Fri, 07 Nov 2008 07:34:26 -0800, Walter Bright wrote:

 Ary Borenszweig wrote:
 Do you want to be able to express "I probably have a bug here"?


 Even if the code is correct, if it looks like a bug, it will cause 
 problems by repeatedly being flagged by others doing a code review.


Yes, that is one more item in the "cost of maintenance". My mantra for
many, many years now has been that programming languages exist to serve
people rather than serve computers, and their greatest service is to reduce
the cost of maintenance. 

Initial coding is a once-off price and after that the (long) time following
we must pay the piper (like the 2nd law of thermodynamics insomuch as
everything decays over time unless energy is added to stop it decaying) 

There are many things in the D programming langauge that helps us reduce
maintenance costs, but more can still be done.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell

Janderson <ask me.com> writes:

ore-sama wrote:
 bearophile Wrote:

 But what I've just said can't help you see why it's so important for 




such essential concept in few lines here, so I suggest you to keep 
programming and reading, eventually you will probably get it.




force programmer to write a lot of text to make compiler happy, this in 
turn can cause bugs.

Writing extra code to tell the compiler what you really mean is not 
necessarily a bad thing.  Think about where you actually spend most of 
your time.  If you are working on a small project, maybe you spend more 
of your time typing out the code.  I think this is why scripting 
languages are loved for getting some done fast but grow unwieldy as the 
program gets larger.

For me I can code something up pretty fast once I know what I want.  How 
it interacts with the rest of the system is the difficult part. 
Particularly as a game programmer (I imagine its the same for other 
factions).  I spend most of my time debugging and integrating with other 
peoples code.  It's more difficult to spot a bug that someone else wrote.

Lets take game AI for instance.  The team can do their best to plan out 
a good AI for a character however when you hit the run button the AI 
appears to take on a life of its own.  Why does the character decide to 
pick this target over this other target?  Why does the character go left 
instead of right in this particular situation?  Why does it only happen 
in release?  I don't want spend hours tracking down the issue only to 
find its (for example)
  - an un-initialized variable or
  - a change introduced by Joe which changed how a particular class was 
designed to work. Note: unit tests are great here to enforce things 
continue to work the same way.

Just a general question to everyone.  Do you sometimes take conscious
notes of what you spend your time doing?  Then try to figure out ways to 
improve on it?

I have found that there's things I didn't expect that I was spending 
time on.

Even simple things like:
  - adding commonly used code fragments to visuals assists intellisense
  - using programs like distCC or incredibuild if your build is slow
  - not reinventing the wheel
  - Cheats and macros to improve debugging time.
  - Always fixing a bug and making sure it can't be repeated without at 
least a highly visible warning.
  - Making classes invariant so they can't be used in a wrong way
...
go a long way to improving productivity.

-Joel

ore-sama <spam here.lot> writes:

Janderson Wrote:

 I spend most of my time debugging and integrating with other 
 peoples code.  It's more difficult to spot a bug that someone else wrote.



 however when you hit the run button the AI 
 appears to take on a life of its own.


Souldn't it do so?

Janderson <ask me.com> writes:

ore-sama wrote:
 Janderson Wrote:
 
 I spend most of my time debugging and integrating with other 
 peoples code.  It's more difficult to spot a bug that someone else wrote.




:)

Everyone who is better then me is an expert everyone who is below me is 
a novice.  One day everyone but me will be a novice :)

 
 however when you hit the run button the AI 
 appears to take on a life of its own.


 Souldn't it do so?


:)

The point was that AI can be very complex when you add all the bits and 
pieces together.  In a game you want the AI to look intelligent but also 
make the game fun.  Sometimes these to ideals don't meet.

-Joel

"Chris R. Miller" <lordsauronthegreat gmail.com> writes:

Janderson wrote:
 ore-sama wrote:
 Janderson Wrote:

 I spend most of my time debugging and integrating with other peoples
 code.  It's more difficult to spot a bug that someone else wrote.


 you. :3


 :)
 
 Everyone who is better then me is an expert everyone who is below me is
 a novice.  One day everyone but me will be a novice :)
 
 however when you hit the run button the AI appears to take on a life
 of its own.


 Souldn't it do so?


 :)
 
 The point was that AI can be very complex when you add all the bits and
 pieces together.  In a game you want the AI to look intelligent but also
 make the game fun.  Sometimes these to ideals don't meet.


I smell a disappointed GR:AW player.

Walter Bright <newshound1 digitalmars.com> writes:

Janderson wrote:
 however when you hit the run button the AI appears to take on a life of its
own.


Please tell me you don't work for Cyberdyne Systems!