Learning Computer Programming FAQ

[pmasiar]

This difference between Unix and Windows approach to programming (module-first or GUI-first) is analyzed in Biculturalism article by Joel Spolsky. If you don't know his blog, I think you will spend many interesting hours reading his notes. A hacker who knows how to think, and write.

[AlexRamallo]

Hey, I've been programming games on windows for the past 3 years, and have been using C++ for the past couple of months, and i can make 2D and 3D games...but in windows =[

would programming in Linux with C++ require me to learn any new API's, or read documentation regarding compatibility, or could I just use a C++ library that claims to be platform independent(such as Irrlicht) and program my games normally?

[my_wan]

Often my strategy is to build a program with no GUI in mind. I create functions/methods called ouput() and overlay the code to a console or windowed engine (an external code library).

I agree with that. Most people from Visual Studio come with the opposite idea, "Build the gui, then add functionality" which is plain wrong (although it doesn't force you to do it, most people take that path (not saying everyone! (i'm trying to avoid flamewar (crap, this has more parenthesis than Lisp)))).

Using that idea with "modules" (from Wybrial) let me program completely unrelated things and plug them later.

I'm as raw a noob in the Unix environment as they come. Much of the advice given for "learning to program" is essentially useless to me. I can't even remember the name of the program I typed into the CL 5 seconds ago. Never memorized the multiplication tables either, but I can do calculus in my head. I get the need for people to understand program logic structures and algorithms, but that's the language neutral intuitive part for me. Help files are mostly useless to me, but give me a piece of source to break and I'll break it until I understand it. I even learned to make a MS resource compiler in AutoIt (as strings) by breaking resource DLLs in a hex editor.

As lovely as the CLI is on Unix, the same ideology toward the use of a GUI is just wrong. Yet the two doesn't have to be incompatible. It's made that way by programmers misconceiving the GUI as a distorted representation of the code it was written for (the program separation paradigm). A GUI at its best provides the continuity that the underlying structures intentionally left separate.

If your writing a piece of code with a cool new functionality, fine, forget the GUI up front. I would suggest that GUI code not even be part of the same program. Just remember that the arg structure needs planning in terms of how it might effect future GUI code. Think of the CLI as a pseudo-API for GUI code. Many arg structures make this somewhat difficult.

I intend to write GUI code for this Ubuntu, and I will most definitely consider GUI first, then code. But it is not the GUI code the GUI is written for. It's written for configurable access to the code already on the machine, with its own CLI interface to remod its looks, use, and response for any given instance. This GUI program is a high priority for me, and even a basic implementation will speed my learning curve on this installation at least a hundred fold. Ubuntu has come a long ways, but the GUI functionally still sucks.

My point is that an FAQ on "Learning Computer Programming" will depend heavily on what it is you wish to program. This single minded idiom of code first is valid and highly important at a core level, but it defines the traditional failures of Unix desktops. It doesn't have to, but you can't think of a GUI as an extension of the same program idioms. I must have a GUI, but I can't give up the power of the CLI to have it, and I will not.