So, I guess the question is, what are you looking to do?
If you're looking to write for just Windows- learn Visual Basic.
If you're looking to write for the web- look at JAVA or C/C++.
If you're looking to do cgi look at C/C++, Perl, .NET(Visual C++/Basic) or PHP
Cross Platform - JAVA
Commandline and low level (like writting your own OS) - C/C++ or Assembly

I'm quite intrested t see what other people have to say on this matter.

As for a good system for just Windows, GameMaster mentioned Visual Basic. However, my friend Steve is a Delphi programmer, and I got his opinion on Delphi:
"C++ is hardcore. Takes a little time to knock something up. When learning a language it's nice to see some results. Delphi is far superior to C++ in this respect and is far more productive, and has the same speed and power. VB has similar productivity, but is infamously ropey and lacks speed. Delphi is pascal based so is a nicer, easier to read and understand language than C variants. Also every error in Delphi raises an clear exception, so no bizairre crashes. Plus with Delphi 6 you can now work with Linux too. What more could you want?"

Another nice advantage of Delphi and Visual Basic is that they have very fast compilation, and you can even alter the program while it is running to make changes.

Let's distinguish between programming something useful and learning to program -- I'm not saying a language can't fit both, just that they are different categories. I would *not* recommend C++ to someone who has not programmed before.

The two main drawbacks for C++, as a learning language, are it's terseness and many of its features that make it attractive to power programmers.

A few years ago, I'd have recommended Ada 95 -- it's readable, it encourages good software engineering practices (you'd get introduced to them and would practice them before knowing they were good SWEng practices), and you can (as you gain experience) play with pretty much any realm of computer science. But these days, Ada seems to have fallen by the wayside, and you're unlikely to find much support when you need help, unless you find a mentor.

I've heard people praise Python as a learning language, but I have insufficient experience with it to be a judge. I have my doubts, though, particularly in regards to its lack of strong typing (to be fair, my first language -- BASIC -- was weakly typed, and I got over it, but I still think teaching with strong typing initially is better). I attended a workshop last week, and one of the topics of discussion was an appropriate language & text for CS1/CS2. The consensus of the workshop attendees was that their research language was the best of the alternatives (natch), but since most of the attendees didn't have the authority in their departments to make that switch, the discussion then went to C++ or Java. C++ was given preference since Java only provides reference-semantics for everything but the primitive data types. Given C++ as the language by default, the discussion turned to the choice of text. The recommended book (I still need to get a copy to form my own opinion) was Accelerated C++ by Koening & Moo, because it uses only the "safe" aspects of C++ (such as value-semantics) until late in the book when, presumably, the student is less likely to shoot himself in the foot.

Spare a little Basic (al la basica on a 286), I learned to program with C++... Granted that my mind works like that and I got it fairly easy. I have trouble with the MS Visual languages because they hide the bones, which is why I like JAVA, I can make a GUI program using a simple text editor. Basic isn't a bad starting language, but it is so tempting to begin using GOTOs.

They used to teach beginnig programing using Fortran and Pascal in the UW system up until a few years ago... I suppose, if your looking to teach yourself, you should look at some various samples of code and chose the language that looks most natural to you... Most books begin with the dreaded "Hello World" program of sorts, and while that tidbit won't tell you everything you need to know to make a informed desicion, it should give you an idea how easy the code is to figgure out.

IMO, C's not a good learning language, either. In some ways, it's better, in some ways it's worse, than C++.

Basic isn't a bad starting language, but it is so tempting to begin using GOTOs.

Shhh! Don't let them know about the four-letter-word that starts with 'G'! I think the greatest success of the structured programming paradigm was when two quarters ago, a classmate was surprised to learn that C has GOTOs -- goes to show how effectively you can program using structured constructs.

They used to teach beginnig programing using Fortran and Pascal in the UW system up until a few years ago...

You could do worse than teaching yourself to program in Pascal. I didn't mention it earlier since its current following is (I think) smaller than that of Ada, which lends to the issue of getting help. The other reason is that there's not a migration path from Pascal into OO practices.

I suppose, if your looking to teach yourself, you should look at some various samples of code and chose the language that looks most natural to you...

Good advice.

Computer
Software Tools
Project
Book
Mentor

You need access to a computer where you can do your programming. These days, you probably have your own computer, and you are all set.

You need software tools. Specifically, you need a compiler or an interpreter for the language that you are writing in. I think the interesting languages to choose from are: basic, c, c++, java, perl, python. For a total beginner, it doesn't matter much which language you use. My own preferences are (1) perl and (2) java.

You need a project to work on. A lot of people start with simple games because they are small and interactive and don't involve saving state. Start VERY small. If you have never programmed, start with, say, a tic-tac-toe game.

You need books. You need the definitive reference book for the language that you are working on. For C and C++, these are "The C Programming Language" and "The C++ Programming Language". The best publishers are O'Reilly and Addison-Wesley. You may also need some tutorial books in addition to the reference books. Go down to your local tech bookstore and browse and get something that seems good to you.

You need a mentor. Your mentor will help you choose your project and will teach you and answer questions. If you are in a class, then your teacher is your mentor. If you are not in a class, you need to find a mentor. It might be possible to work with your mentor via e-mail, but it's a lot better if you can chat with them in person.

In my opinion, the most important factor is getting the right books, and the second most important factor is choosing a good project. You want a project that is small enough to finish. Lots of people pick something too ambitious, such as a project that nobody's ever done before, and think that they will write that for their first project.

No matter what you answer to any of these, C/C++ is a poor first choice. EngrBohn mentioned some of its problems. I think we could improve the quality of software throught the world if C/C++ were only allowed to be used by licensed professionals.

I'm going to answer my own questions to you and assume that your are interested in programming and want to build some things for your own amusement, but don't know if you want to do it professionally, but are not ruling that out. So, you want a language that lets you be fairly productive off the bat, is not too hard to learn and offers some safety net for you (which is why C++ is out).

Visual Basic is great for hooking together windows components to make them something else. My 'pointy haired boss' has been building his own home entertainment computer by wiring together and re-skinning different media players with VB. The big down side is that it's windows only.

Java is currently my favorite general purpose language. It is very portable. It is very portable. I don't have to worry about memory management. The threading model works pretty well. I think the vm performance hit that GameMaster mentions is a non-issue for five reasons. 1: I can finish a job so much faster in Java than C++, that I have time to work on speeding up the algorithms, which always pays off the most. 2: the JIT compilers are starting to get very close to native code performance. 3: if I really want it to scream I can use a native code compiler for java. It is a little harder to learn than VB, but it puts you in a place where you could actually end up doing programming for a living.

C#, same as Java. It may be windows only today, but various teams are working on unix ports of the CLR. As much as I hate microsoft tools, I think C# may ecplise Java one day.

perl is a potentially interesting first language. It has a vast collection of tools that work with it (CPAN). You can write some pretty amazing stuff in a small program. It is also portable to many platforms. I can't vouch for GUI applications in perl, but I think those should work as well. Perl uses Tk (from tcl) as it's gui toolkit, and I have written tcl/tk programs that work no both unix and windows without change. On the down side, it is a train wreck of language design. It's easy to get into trouble with things not working the way you want. It encourages some pretty bad habits by making variables global by default.

Advantages: simple, fast to develop, extensible, well documented, portable, well liked by "serious" software engineers as well as newbies. Has lots of amazing GUI-building tools. In fact, has lots of amazing tools for just about anything.

Disadvantages: slow (relative to C, OCaml and C++), not that impressive on a resume (yet).

After that: C and/or C++, Perl, Java, LISP and/or OCaml.

I prefer C++ to any other language myself, but I agree with the above posters, it's a real bitch to learn.

From everything I've seen, pre-.NET VB does not provide for non-GUI applications. I'm willing to be proven wrong on this, but I suspected it when, on a whim, I picked up a book entitled "Learn to Program in Visual Basic" ("no programming experience required!") a couple years ago and looked at its table of contents. The entire first half of the book covered laying out the GUI, and actual control constructs weren't mentioned until somewhere around chapter six. I've since talked to a couple people, and they confirmed my suspicion.

Now, I understand VB is an excellent rapid prototyper for GUI applications, but if you're learning to program, you really need to start with so-called console applications so that you only need to worry about the algorithm and not about the display.

I suspect that VB.NET does support console apps, and if it doesn't, it should be straight-forward for someone who already knows how to program to use the .NET framework to set up a "console library" in, say, Managed-C++ that could be used by VB.NET.

Regarding books. I like to look through tables of contents and indices (especially indices) to get a first-order assessment of a book. If you're new to programming, then it'd probably be best to get someone else to judge for you. Something important to remember is that there are good reference books and good educational books, but very few that are both (and many that are neither!). Don't try to find one that's both a good reference and a good tutorial. Assuming you're on a budget, start with a good tutorial book and then when your budget allows, get a good reference book. As a rule of thumb (but not 100% effective, and not endorsing or disparaging any publishers), I've found that O'Reilly produces good reference books, and Addison-Wesley produces good educational books. There are, of course, other publishers with a large footprint in the realm of computer science, but I've noticed a disproportionately large number of AW textbooks, and I haven't encountered a bad one yet.

The thing to remember about reference books (such as "... in a Nutshell") is that they're only effective if you already know enough to understand them, which is why I recommend to get the educational book first.

That's an interesting point, but I'm not sure I totally agree. I've seen elementary school children grasp programming in LOGO, which very graphics based. It is very different from VB GUI though. LOGO focuses on drawing things and getting text input. That is vastly different from callback based programming that you find in VB (and Java/Swing, C++/{Motif,GTK,QT} and Perl/Tk)

Plain BASIC isn't an entirely useless language. I had a lot of fun with it as a little kid, back in the days of DOS. There's actually a lot you can do in BASIC, and it's not bad as an introduction. I found the knowledge useful when I got a TI-83+ calculator, too (and recently, an '89).

And now, my evangelical bit: I think that the UNIX way is a good way to learn programming. The command line and text oriented style process makes pushing and processing data very simple. Plus the modular nature of commands makes it very easy to string together a chain of simple programs to do exactly what you need, even if it's something no one ever thought of before. Naturally, I like Perl. I picked it up a few years ago, in 8th grade. Now barely a day goes by when I don't put Perl to good use.

Oh, as for "goto": even Perl has one. The idea that gotos are satan-spawned is preposterous. Over-using them is definitely not good, but in some cases a goto is a perfectly suitable tool for the job (I've used it once in Perl, in one of my larger programs).

-Andrew

+Andrew is right, though, in that they have their uses; one of those being to jump down to the various destructors in a method if the method fails somewhere in the middle. If/else constructs to do that can get very hard to follow, so are not preferable.

Following BASIC, I tried C and, while I was fine with the syntax, somehow I never grasped pointers, and with no-one to ask, just watched in despair as seemingly simple bits of code reset my PC or put gibberish on the screen. They did suddenly become clear later on; I just wished it had been sooner.

I don't know what to recommend personally, being a Mac user, we don't have the variety of options available to PC users, certainly no good EDP environment (REALbasic quickly becomes a menace). Now, I have Steve in one ear (rather, AIM window) banging on about Delphi, plus one or more people here saying that C is too dangerous (being low-level) for anyone other than top programmers, but, seeing as the main development system for the Mac has been CodeWarrior, which is mainly C/C++, and people here are recommending C++ even for PCs, I feel less bad about the Mac after all. Yay :)

Though, we've got objective C now.

Looks like I've got to go save her ;-)... Harry, Tom, you're with me...
*gets turbolift bound for Delta Flyer...*

Ah, but you should be good at programming in general before writing software in C++ which you expect to be reliable in any way. It's sort of like race car driving. You don't put a beginner in a Formula I car.

I will not deny that there are a lot of programmers out there producing useful software in C. Some of it is commercial products, some is open source. But the dirty secret of the industry is that a lot of it contains severe internal bugs and egregious security holes. If you read BugTraq you find that a huge number of exploits rely on simple buffer overruns. Even experienced C programmers slip up every once in a while and allow a possible overrun to slip in. In a language where you can't have buffer overruns, you can worry about the correctness of your program at a higher level.

- uilleann -
the BASIC I used had very limited structure outside subroutines

An amusing story about BASIC control structures. In 1980, give or take a year, my mom decided to take a programming class from the local junior college to see if she could get interested in the machine my dad built (a Heathkit, for the curious). Now, we lived in the panhandle of Florida at the time, which actually is part of the South -- including some heavy accents. It would seem the instructor spoke fast, and one day she came home befuddled, trying to figure out why she couldn't find "foreign X loops" in her book's index. We soon figured out the instructor was talking about "for-next loops".

Okay, I guess you had to be there.

Hehe, cute.

As for BBC BASIC, IF/THEN/ELSE must come on the same line, multiple IF/THEN/ELSEs on the same line nest not as you'd expect, and there is REPEAT/UNTIL, but no WHILE/WEND so such loops always execute once.

I still managed a large package with no GOTOs, but I think it slowed the code down a lot

1000 IF NOT condition GOTO 1030
1010 REM The "THEN" part goes here
1020 GOTO 1040
1030 REM The "ELSE" part goes here
1040 REM Normal program continues.

I know a little game written in BBC BASIC (a simple SpaceWar clone) that had GOTOs everywhere. What made it worse was that the programmer knew how to use subroutines. My only guess was that the GOTOs were faster than subroutines (which need stack manipulation); the game wasn't overly fast anyhow.

Now, that code was really hard to follow, so if you took all the THENs out (and presumably all the subroutines), you'd have, well, a total mess. Yay for prehistoric coding style.

Even so, assuming you at least had GOSUB, you end up with a code structure resembling assembly. But even assembly has named location labels.

And C's structure is elegant, I think it's the nicest structure I've seen.

C was, from it's inception, designed to be a portable assembler language. It's handling of pointers, it's ++ and -- operators, it's set of primative types - all these things are modeled on the hardware. What it adds above assembler is a some syntactic sugar in it's control structures to make it more readable. C is, however, just as powerful, and dangerous, as any assembly programming.

BASIC is, by all reasonable definitions, a high-level language (albeit a badly designed one in it's early incantations). It abstracts away the hardware, so that you can think in terms of things that are easy to work with. Strings, rather than arrays of bytes. Input and Print statements that are type checked rather than unchecked scanf/printf. Multi-dimensional arrays rather than vectors of vectors. You can't write basic programs that core dump. In C, that's a rite of passage.

If you look at the heritage of C, you start with it's grandfather, BCPL. That was very much an 'machine' level language. It's only data types were byte and word. That gave birth to B, which begat C. Along the way a few more data types were added, but only those that the raw hardware supported. C++ borrowed the class concept from Simula and a few other ideas from other languages, but always tried to remain "close to the machine" (to quote K&R and later Stroustrup).

BASIC has no need to be close to the machine. It was designed to be safe to use and relatively useful from the start. And don't confuse the botched implementations of TRS-80 and Altair (microsoft) BASIC with what Kemeny & Kurtz originally envisioned. They wanted something closer to what enventually shipped as TrueBasic (but 20 years too late to make a difference).

One point you do have right is that Java took the "feel" of C++. It's actual heritage belongs more to Smalltalk and (slightly) Lisp, but it became a commercial success by looking like C++, so that people didn't have to think they were learning anything really new.

I think that ASM should be on the list of things for all programers to learn ... it is a great way to teach people the dangers of stack overflow, and a few tricks to make the code run faster.

Not any more. When I was your age, that might have been true. A working knowledge of the instruction set and what the compiler generated could be used for tweaking inner loops to run a little faster. With today's pipelined architectures, it takes an expert to beat the compiler. The same assembly code will have different performance characteristics on different models of the same family of processor. RISC processor instruction sets are never intended for programmers to use. They get part of their performance by having a sophisticated optimizing compiler selecting the instructions.

Of course you can always find some cases where you're carefully crafted assembly code is faster than what the compiler would generate. It's just not often enough to make it worthwhile (unless your compiler sucks). I would rather finish writing the code in time to meet customer needs than spend twice as much time to make it 5% faster.

It's at this point that one reading this post might wonder "how can a person possibly talk about themself this much without even hinting at actualy having an answer to the question" and I am getting there, trust me. The thing about me is I like to have detailed inderstand of how something works before I can use it in any technical way, I got fed up with the MFCs cause I couldn't stand not knowing what the hell was actualy going on once I'd called an MFC function. If I ever were to use the MFC I would have to read the source code for it and follow each class that I used through before I felt comfortable. This is where I come to the point where I say which language I think it would of been better for me to start on. Assembly, it's the language I've learnt most recently, and since I did that, C++ has just gotten so much easeyer, I can imagen how the C++ statements would be expressed in assebly and I feel more free in my programing for it (I've found a lot of people who are scared of computers are that way for lack of understanding, if they don't know whats possible, they start to think anything could be the wrong thing, this is a simelar case, I felt like I could do more cause I really understood what I was doing). Now to many assembly may seem like a terrible place to start, and if you really feel like you want to start on a 3rd level language, then I would sugest C++, it's nice and easy, and you'd be suprised how much most programming languages are a like, I can't think of any language other than assembly that doesn't have an if command.

Having said all that, you're probably wonding, why, not much unlike Issac Asimove, I wasn't able to just come out and say it, but instead had to explain the works of the universe before I finaly came out with it, I thought maybe it would help you to find you're own perfect starting point if you could think about things like this before you dive in. I think the main thing to ask is how much understanding of a command to you feel you need before you are comfortable issuing it.

That's Pretty much all I have to say, so, goodnight all.

While the machine code generated will be MUCH different (well, Java using the various JVMs, and C++ being compiled diffrently on different systems....). Yet, the syntax is such that once you can get a grip on one, the other is fairly simple. I was playing with JAVA a lot this weekend, and it has taught me that JAVA it is the language that the zealots preach abut. Granted, that it's a bit slower, not a pretty as Visual C++ (at least not without writting a ton of extra panels) and e few other drawbacks... but I am almost sold.

As for the usefulness of learning assembly... Intel chips are fast, because they are small, AMD are a bit more effeicent and the Motorola chips in Macs are well.... So, your definatly right about looking at the ASM output generated by a compiler not making sence from an optimization point of veiw, but the use of bit shifting instead of dividing/multipling by even intergers and using doubles instead of floats (on windows machines) still does increase speed in C/C++ code... Understanding why and how low level things work, give my generation a respect for what has come before, which I think most of my generation lacks. There will, however, always be a need for new low level programs to make better OSs, compilers, virtual machines and the like.

REALbasic is very much a mixed bag. For certain tasks, such as an AIM log viewer, or other smaller utilities, it's ideal - gets the job done fast and easy. However, it is very limited in what it can do, and this can get very frustrating - it still can't raise an alert that I know of, or make an alias, or handle window zooms, and these and most more complex tasks need either plug-ins or for you to learn the Mac OS ToolBox, which you'd need to do for anything special, and I've never managed to locate a good online reference guide to ToolBox calls for REALbasic users. There is one page that does have a little collection, I have the URL at home.

Windows compiles are suspect (and you can't step-debug them to see where they break), and the IDE is somewhat unstable too. Mac OS X compiles are also often defective.

It could be so much more, but isn't, which is a pity seeing what Windows users get with Delphi, and the same with Linux users and Kylix I assume.

I use REALbasic, and will continue to do so because I'm too lazy to learn C++, but will remain reserved in recommending it to anyone.

The good news is that you can download a 30-day trial copy from www.realbasic.com. See what you make of it.

- uilleann

Edit: Chiper, of ChiperSoft Systems, and who made the AthenaIRC IRC client for Mac OS in REALbasic, seems to feel I'm much too harsh on the program. Go download AthenaIRC if you like, see what can be done with REALbasic. To write apps in RB, you'll still want TBFinder, and a fondness for looking up Mac OS API (ToolBox) calls in C header files if you want to write anything large or do anything complex, though, which I still feel is a big weakness given that it's supposed to cross-compile. It will allegedly compile Windows API calls, but I've never tried. Download Athena, and REALbasic, and draw your own conclusions