OSDev.org

It occurs to me that it might be of use for the newer programmers here if the senior members wrote down whatever general advice they could offer in a single thread, which newbies could read immediately. What I have in mind is not so much a FAQ as a listing of advice for how to start off.

Let me start off with my own recommendations about learning to program:

My advice is to try to look beyond the languages you're working in and understand the more general principles involved. Programming is more than just writing code in a given language; if you can see the larger picture, then you should be able to work in any language, with a little time and effort.

Don't get caught up in learning a particular language, such as C or VB, too early on; it is all too easy to get a kind of tunnel vision that way. It is better to start of in a language that is suited for beginners, and concentrate on learning the concepts, than to jump into something where you'll struggle with the language itself so much that you miss the ideas.

You do, however, want to understand the languages themselves; indeed, the more languages you know, the easier it is to see the general ideas, as they apply to each different language in turn. While you will probably want to specialize eventually, it is best to get a broad view first.

If I were to suggest a specific curriculum, it would be:

• Start off learning HTML markup before getting into an actual programming language; it is structured quite similarly to many programming languages, but is much easier to learn.
  
• Learn a language that can be run interactively. This means that you can write pieces of a program at the interpreter prompt, rather than having to write a whole program at once; you can learn the pieces of a program separately, and try out things on the fly, and get an immediate response. Good languages for this are Python, Scheme, FORTH, ML, or Smalltalk. If you can, learn two different ones, one after the other, before continuing, as that will help you see how different languages affect how you program.
  
• Go on to a simple compiled language, like Pascal, running it on the command line (rather than in an IDE). C is an OK choice for this, but you'd probably be better off waiting until you understand low-level programming better. You could just skip this part, as it just is to get you used to the idea of compiling programs and using the linker and debugger.
  
• Learn some assembly language. While it is unlikely that you will ever use it very much in general programming, understanding how the cvomputer works at the lower level will help you understand a lot of how the programs really work in general. Make sure that you learn about addressing, character strings, and stack frames, in particular.
  
• Learn the basics of Perl scripting now. Perl is ubiquitous, and even a little of it can make a big difference.
  
• Now dive into C, and learn it in depth; if you are doing a lot of programming, you will definitely want to know it, and now you should be ready to really understand it.
  
• Go back and learn more Perl, or another scripting language like VBA. If you have a chance, and didn't earlier, learn a little bit of both Scheme and Smalltalk.
  
• Last, tackle either C++ or Java, depending on what you mean to be doing with it. You can always go back and learn the other; you should by now have enough language experience under your belt that even a massive language like C++ should be easy to learn enough to work in.

I would recommend learning PHP more than I would perl.

I have to disagree, not because Perl is the better language, but because it is the more universal language. Whether PHP is a better language for Web scripting or not is irrelevant, since web scripting is only one part of what Perl is used for; its role in automating system administration and operation, while less visible, is far more important. Perl has long since supplanted C-Shell as the preeminent scripting language under Unix, while under Windows, it far outstrips the use of VB for Scripting (which is not to be mistaken for VBScript, which is M$ half-assed answer to JavaScript). I have heard it estimated that amount of Perl code written daily exceeds that of all other programming languages combined, and it seems plausible. Given it ubiquity, if you don't know at least a little Perl, you're going to have serious problems.

In short, I included Perl for the same reason I included HTML and C: because in the programming field today, you don't really have a choice about it.

Hmmmm... Thats a lot of truth. And btw nice idea of a thread.

Thank you. I did overstate the case a little - the reality is a bit more complicated - but I stand by the assertion.

What is actually happening is that in professional programming today, there are only about a dozen programming languages in widespread use, about six of which - C, C++, Java, Visual Basic (and its derivatives like VBScript), JavaScript, and Perl - dominate the field. While it is by no means necessary to know all of them, a professional programmer (or even an academic or hobbyist programmer who wants to stay in touch with most devellopments) more or less must know at least one of them if they want to stay in the business, and would do well to learn at least a little bit of each of them if they can. Of these languages, Perl is the one which gains the greatest leverage with the least effort - Perl interpreters are common in both the Unix and Windows worlds, and the language, while rather hairy, is pretty easy to use, and can be quickly applied to a variety of purposes. While it is most powerful in conjunction with a compiled language like C, it is extremely useful even on it's own. While other languages like Python might fill its roles, the sheer volume of Oerl code means that a programmer will need to at least be able to read and modify Perl scripts on occasion.

Enough; I don't want this to turn into a Perl advocacy thread. Suffice it to say that there are good pragmatic reasons to learn it.

BTW, I should emphasize again the importance of HTML and XML. Even more than with the others I mentioned, you cannot afford to ignore them. HTML is the mother tongue of the WWW; if you cannot write HTML code by hand, you'll always be at a disadvantage. XML, which is a language for defining other markup languages, is now the basis of nearly all new file formats, including the latest standard version of HTML. If you ever need to do any work on Web pages, or anything involving most of the newer file formats, you'll need to know one of the them, and preferably both. Fortunately, being more or less linear markup systems, they are both a lot easier to learn and use than a Turing-complete programming language (i.e., one which is theoretically capable of performing any algorithmically-definable computation, which includes all full programming languages today) is, yet they have much in common with several of the major languages today. They are an excellent place to start before one jumps into programming per se, and an important thing to learn if you already are programming.

Also, you'll notice that, despite all of this, I still favor learning the less widspread languages, and what's more, I recommend learning them first. I have good reasons for this: first off, they are generally easier to learn and use than the current major languages, and thus don't get in the way of learning the concepts (this is especailly true with Scheme). Also, they have conspicuously unique paradigms, and understanding them will give you a broader vision of what programming is and can be. Understanding them can make your programming better in other languages as a result (this is esp. true of Smalltalk, which is the ur-OOP language; learning Smalltalk can really help clarify Java and C++ programming issues). Lastly, they are, IMAO, more interesting than the more conventional languages.

Don't be lazy on the keyboard. In a world of auto-completing IDEs, there's no excuse for cryptic variable names, and they make code maintenance a nightmare.

Languages like C and C++ give you a high degree of flexibility in the way that you write programs. Unfortunately, they also allow you to write bizarre expressions like this:

Avoid complex expressions that save you a few statements. Clear code is better than short code.

Comments are not optional. There's no such thing as self-documenting source code, no matter how well you write it. Even if you write beautiful, readable code (and many people don't), comments allow you to provide hints that aid someone else's understanding of the code, as well as your own if you don't look at the code for six months. Comments can drastically reduce the time it takes to figure out exactly what a section of code does.

Sometimes, it is better to test an algorithm on a sheet of paper, just to get a clue of what it is doing or if it is doing what you expect it to do.

Use Nassi-Schneiderman-diagrams to construct your program. Write down ideas, because later on they may be obscured by other brain-and-mind fuzz.

If you use pointers, be sure to have them point at the right direction. Or at least initialize them with NULL. these lads tend to do weird things if not initialized properly.

and, buckie-lad, remember at all times when you code, where you are, what stands in your variables and pointers. Praise god, but if you don't know what your program does at which time, you are kinda stuck in debugging hell.

For me, a good program starts with the creation of tools: small functions that do all-days-needed-crap, like sorting, stuffing elements in lists, initializing lists, comparing elements, fetching and testing input. With this tools, I take a step up the abstraction and build fundamental algorithms for the program. and after his is done, I put them together like bricks. the good thing is: small elements are easier debugged than huge chunks. the testing is just simpler. You know you have something that runs relatively good. At the end, you'll have a running program.

Don't get fuzzed with programming *languages* busy your grey cells with the algorithms of the program. Lateron there is enough to do with implementation, but prior to that, you have to get an overall picture of what you want to do. Just imagine it - make a picture in your brain - what you want it to do, to look like. Code itself ... How to code is easy learned, but how to code right and build an useable program is difficult.

@HTML&XML: Maybe, maybe it is important ... I won't give 'em too much importance. If you have to work with COBOL (I do) or with PowerBuilder(I do), you don't have to care about them too much. But having HTML knowledge at hands is is always a nice feature.

I recommend learning SQL. Data query language that is needed presque everywhere. Sorry, thats 'nearly'.

Stay safe folks

Assume least common denominator when considering who may one day read your source.

That would be someone on an 80 column console who has good knowledge of the language the source is written in and knows general progamming algorithms without having specific knowledge of the source they are looking at.

Write your source and pitch your comments to this fictional person. It's handy because when you look at this source a few years later, after working on numerous other pieces of code, it's usually difficult to remember all the details of the program.

I would highly recommend starting off with HTML, however instead of going into a compiled language, I would suggest an interpreted language instead.

For example, starting off with say Lisp allows the novice to type into the interpreter and see exactly the consequences of the code. This is encourages expirimentation, whichs is exactly what a novie should be doing.

-m

www.modus-ponens.com/blog/blog.php

I would recommend learning xhtml and css.. That way you learn a bit about xml and you learn proper html design.

- Nick

Some advice regarding effective problem solving.

First, adjust your mindset by reading selected passages from the Jargon File. If nothing else, it will help lighten the mood, and will help instill the mix of arrogance and curiosity that is so important for these sort of things.

Also, read the essay, "How to Ask Questions the Smart Way". The points this makes are considered so important by the forum-goers here that there is a permanent link to it on the OS Development forum.

I would add to the general advice ESR gives with some more specific things:

Learn how to think through problems in an organized and logical manner, and try to solve it on your own before asking for help. You'll learn a lot more if you work it out a solution on your own than you will if it's given to you.

Learn how to use basic debugging techniques, such as breakpoints, watchpoints, assert(), status prints, binary elimination, and so forth.

Learn how to use man(1) and info(1), the help menus for Windows and MacOS, and other reference systems on your workstation. This includes any on line documentation for you programming environment, such as the EMACS help menu or the MSDN CDs.

Learn how to read a manual effectively, both for overview purposes and for quick reference. Understand how online and dead-tree manuals are different, and use both effectively.

Learn how to find the appropriate FAQs or HOWTOs, and how to read them effectively.

Learn how to locate sources of basic tools and utilities, such as compilers, editors, debuggers, etc.

Learn how to research both systems and techniques, on or offline. Knowing how to use Google and other search engines effectively, how to read a library catalog and find books appropriate to a give topic, and how to locate research and thesis papers, are all critical skills in programming.

Learn how to use the search function of this message board, and any other you use. Learn how to use it to mine the old messages for answers.

This thread seems to have fallen off to the wayside. Anyone have any more to add to it?

Get this topic stickied... Maybe some novices will actually notice the thread.

I would follow Schol-R-LEA's steps. With no programming experience I started off with C and it was quite rough. I actualy ended up stopping and starting back up multiple times, each time getting a tiny bit further. I did some PHP (I also had previous HTML experience) in between which helped me out before I started back up the final time. I've been programming in C ever since. So I REALLY recommend starting with, like Schol-R-LEA said, HTML and then working your way up with Python, etc. Python is very nice btw

Some recommended reading:
How to Become a Hacker and How to Ask Questions the Smart Way by Eric S. Raymond. Excellent material over all, though much of it should be taken with a grain of salt (esp. his anti-MS stance, his political bias and his incessant egotism). Note that he uses the word 'hacker' in the older sense of master programmer, not in the sense of cracker or blackhat. ESR is also the current editor of the Jargon File, another excellent resource even if Eric's taken to using it as a bully pulpit. Links to his other works abound in these, and he tends to repeat himself often, so adding any others would be redundant.

How to Be a Programmer - some wonderful advice on starting out. Pay particular attention to the material on debugging, revision control, documentation and finding information. It is broken up into beginner, intermediate and advanced sections, and it really does build up from each previous section's experiences.

The Design of Everyday Things by Donald A. Norman. This is a classic work on the subject of usability design, and is valuable reading for anyone designing tools or programs for others to use. A must read.

Programming Pearls by Jon Bentley. Another classic, this time addressing issues of basic programming design and problem solving. It's anecdotal, conversational tone helps bring life to some otherwise dry-seeming issues.

Computer Lib by Ted Nelson. A hard to find work, now thoroughly dated but still quite inspirational, this was a seminal work in the development of personal computing. The 1987 edition can be found in many public and college libraries; the 1974 edition is a valuable collector's item.

Hackers by Steven Levy. A good historical overview of the early MIT and Bay Area hacker cultures from 1960 to 1984. Like ESR, he uses the older sense of the term 'hacker' primarily, though there's some overlap. Useful if you want to get a sense of the history. (PS: a search on Google may or may not turn up copies of the text, or parts of it, though they are strictly unauthorized.) Easy to find in most public libraries in the US.

Michael Abrash's Graphics Programming Black Book - Despite the title, this book is largely concerned with the practice of program optimization, the how, what, when and why (or as often as not, why not to). Even if you never learn x86 assembly language or write a graphics engine, this book is still well worth reading if you can find it. An online copy (of unknown legal status) is also available.