i would pay good money...

for a book or something that assumes i am a total moron when it comes to programming in UT. (which I am)

sega500 tutorials are really great...especially for free...:-)

but there are alot of things that are being assumed...or need the presence of an instructor.

someone really needs to publish a 300 page book....i know it would sell.


---C

[elmuerte]

Well, who's going to write it ?
you need somebody to write it before you can publish it. Ofcourse it has to be written by somebody with writing experience in the field of programming books.

[legacy-Grimfort]

If your good money was somewhere in the region of 10 thousand pounds, id write it.

[legacy-|VS|Brad]

I'd write one, but I'm a programmer. Following the general guidelines of outside documentation, programmers are never supposed to write manuals. I tried once, but no one could understand what I was saying.......

[legacy-bullethole inc]

Try 3dbuzz.com, they have an Unrealscript class which geared more for beginners than the Sega500 class. I'd advise going through their videos first and then going through the sega tutorials.

Thanks

yeah, I have been waiting for the 101 class...but i guess things take longer than expected.

the tutorials on there are still a bit over my head.

{edit}...oh, i see the vids now...should hold me over..thanks!


---C

I tried once, but no one could understand what I was saying...

The fact that you TRIED makes all us programmers look bad.

When they ask me to document anything, I simply laugh loudly and pretend it was never spoken.

Originally posted by DFlor
The fact that you TRIED makes all us programmers look bad.

When they ask me to document anything, I simply laugh loudly and pretend it was never spoken.

yeah....thats cool....horde your knowlege...thats what makes the world a better place.


---C

Originally posted by DFlor
The fact that you TRIED makes all us programmers look bad.

When they ask me to document anything, I simply laugh loudly and pretend it was never spoken.

I dont even know where to begin. Documenting should be paid even more attention than the code that it is describing. Attitudes like this will only lessen the quality, reusability, and future support of your code. In the long run, your code will be useless. It is you that is making programmers look bad, not someone that makes at least a minimal effort to properly document. I'm not sure where you got this idea that documentation is bad but I'd love to hear your reasoning behind it (mostly for the purpose of dispute).

There's a simple answer: I'm talking about documentation. You're talking about comments.

First off, there's a difference between commenting code and writing documentation. I comment my code reasonably often - with a project that can reach a line count in the millions, it's necessary - but don't ask me to explain how it all works from te user's standpoint.

For instance, let's say I built a car, and now you want the documentation for it. There is a big difference between writing the technical specifications of the equipment so that mechanics know what to do and the "idiomatics" that are the owner's manuals ("left foot makes car slow down, right foot makes car speed up").

The comment I made is directed at writing documentation. For example, I was one of the lead programmers of the "Canvas" drawing program by Deneba Software. I know how the print system works, but don't ask me to explain it in 50 words or less.

Programmers write documentation so that only people with PhDs and a lot of time can handle. For example, I was asked to write documentation for something I wrote. I did write documentation, totalling thirteen pages; the sales and marketing department did it in two.

Commenting code is a whole other matter, and that has both ends of the spectrum as well. Generally, at least for the "upper echelon" programmers, the code is self-explanatory - I can read code to know what it does. That's why not a lot of people comment code fluently, because it truly isn't necessary amongst higher level programmers. And, in the case of "Canvas", if you're going in to that higher level code and don't understand it, you don't have any business in that part of the code to begin with.

I've seen commenting taken to the extreme as well: I do not need every line of a shell sort commented. I do not need a paragraph describing six lines of code unless those six lines were written by God himself and only he can comprehend them.

DFlor.....well, you certainly make a good argument.

as a visual artist I feel the same way.

alot of the time I get questions asking me how I created an image.....you know...like steps I took to do it.


But most Of the time I can not answer them.



----C

[legacy-Mr Evil]

Originally posted by ccherub
yeah....thats cool....horde your knowlege...thats what makes the world a better place.


---C

I think his point is that it is hopeless fro a person knowledgeable on a subject to try to document it for beginners. They simply won't understand, making the whole excersise a complete waste of time for everyone. Ideally, such documentation should be written by someone who is in the process of learning the subject, not too far ahead of the person who wishes to read the documentation.

[legacy-Haral]

I don't know how they do things there in the 'upper echelon' of programming, but where I come from we use the same foot for the gas and brake.

You're not always as smart as you think you are. Documentation is a waste of time, as is uncommented code. If you don't need to comment it, anyone could have written it and you're nothing more than the monkey pressing buttons.

If you don't need to comment it, anyone could have written it and you're nothing more than the monkey pressing buttons.

No. You don't need to comment it if you know the person reading it has the capacity to understand it.

Back to my Canvas example: the code for the rendering pipeline is undocumented, but there are only three people in the company that should ever be in that code. If you are in that code and need comments to understand it, you're way out of your league.

[elmuerte]

you are forgetting about the other question you might ask when looking at code, the "why" question.
It's often a good choise to add why you did the following. The "how" is pretty simple because the code is there, it's the "why" that is interesting, both for you and other coders.