I have found a new thing i dont like :D

Using templates for a situation where some people might use polymorphism, because i dont feel like switching stuff at runtime and dont want the overhead.

The result is lots of ugly boilerplate.

Its especially not-fun because i feel templates are weakly typed (for type parameters) so it feels im scripting some overly complex spaghetti mess again...

New unfavorite thing : working with other people who make what they think are 'minor' changes to source files you are actively working on which require you to doing a hellish integration first thing in the morning basically putting you in a bad mood the whole day... *sigh*

"int[] blk=new int[64];" vs "int blk[64];";
"for(i=0; i<n; i++)ct[b+i]=Foo(cs[b+i]);" vs "while(cs<cse)*ct++=Foo(*cs++);";

"ct=(byte)((((int)cs)*xsc+2048)>>12);" vs "*ct++=((*cs++)*xsc+2048)>>12;"

var blk = new int[64];

var ct = cs.Skip(b).Take(n).Select(Foo);

var ct = cs.Select(v => (byte)((v*xsc + 2048) >> 12));

easier to read, deferred, wont crash because of array arithmetic.

I don't have to define cse or ct earlier in the code

scalable, I can parallelize easily.

all are 1 line as expected, not crushed together

aggregates errors

these are the things I like about programming.

For me it's coding "editors", be it terrain editors or texture editors, or both(usually).Pretty much everything involving brushes.
My most frustrating would be lighting grr.
How about you?

So far (using C# / C++) I have only whined when making UI, raw UI that is, like directly creating UI with DX, everything else no matter how messed up it is, has been a lot of fun, I don't have a favourite but I do like the challenges involved in using DirectX instead of an engine, XAudio2, XAPO, Direct3D etc Honestly it is like I am playing a game by building one :D

Favourite thing?

Running the compiled project and conducting end user testing is a close tie with initial design and general problem solving.

What I hate the most about programming?

Basically everything else. I dislike actually writing code for some reason.

"int[] blk=new int[64];" vs "int blk[64];";
"for(i=0; i<n; i++)ct[b+i]=Foo(cs[b+i]);" vs "while(cs<cse)*ct++=Foo(*cs++);";
"ct=(byte)((((int)cs)*xsc+2048)>>12);" vs "*ct++=((*cs++)*xsc+2048)>>12;"

var blk = new int[64];
var ct = cs.Skip(b).Take(n).Select(Foo);
var ct = cs.Select(v => (byte)((v*xsc + 2048) >> 12));

yes, but these wont necessarily do exactly the same thing.

trivial examples were used to illustrate the sorts of basic differences, but the actual code is often not-so-pretty, and not necessarily things that map well to Select or even "foreach()". (mappings are not usually 1:1, we typically work with pieces of much larger input/output arrays, ...).

IOW: how you might use an array in a video codec or similar is not necessarily the same as how it might often be used in general programming.

easier to read, deferred, wont crash because of array arithmetic.
I don't have to define cse or ct earlier in the code
scalable, I can parallelize easily.
all are 1 line as expected, not crushed together
aggregates errors

these are the things I like about programming.

there may be reasons for a person wanting to do things C-style.

nicest is if C-style code works nicely.

well, and also because for some of these sorts of code, there was a lot of copying back and forth between C and C# implementations of the codec, trying to keep them roughly in-sync, so avoiding things that would hinder easily copy/pasting code-fragments was preferable in this case. granted, yes, it probably could have been a little easier if I were using unsafe, but I ended up instead opting with wrapped struct based "box pointers" (in C# it is structs + overloaded operators, in C it was typedefs, ...). (basically: glossing over language differences...).

despite all this, it actually went pretty well...

Anyone who thinks C# is a bad language has never used LINQ to write a data mining app in an afternoon.


Good fucking luck touching that kind of productivity in C++.

Depends on a lot of factors. If I were making a game for Linux, I wouldn't bother with C# too much.

Anyone who thinks C# is a bad language has never used LINQ to write a data mining app in an afternoon.


Good fucking luck touching that kind of productivity in C++.

Depends on a lot of factors. If I were making a game for Linux, I wouldn't bother with C# too much.

Your loss.

http://www.monogame.net/

Anyone who thinks C# is a bad language has never used LINQ to write a data mining app in an afternoon.


Good fucking luck touching that kind of productivity in C++.

Depends on a lot of factors. If I were making a game for Linux, I wouldn't bother with C# too much.

Your loss.


http://www.monogame.net/

No, my gain .

I didn't know that such a thing existed.

I hate small tweaks in terms of 2d or 3d space for some reason it is so montonous to me to have to tweak the position of an object. for example a friend and me are working on an infinite runner, he has never made a game by himself before and this is his first after graduating from college. so he bakes in text to a background and then asks me to try to create a button over the top of the text embedded in the background. i thnk the mere thought of doing this delayed the project 2 weeks. not because it's difficult it's extremely easy but it is so montonous tweaking, running, checking if it's in a decent position, wash rinse repeat until it's in a decent space . i don't mean in terms of tweaking all small values but anything related to positioning relative to something.

However I really love debugging .even if it means there was an error in my original logic it reminds me of performing surgery on the organism that is my system . pinpointing the issue , correcting it and then running the program to see the code hopefully running in a healthy/ functional state is great! even better if i catch my bugs before a team member does.