Languages

Before this topic degrades to a discussion of hacking, I'd like to contribute my 2 cents' worth as well. Here are my opinions:

If you know no language at all or just a little BASIC, then BASIC in some form (Visual Basic, these days) is an acceptable choice. This is assuming you're an amateur who doesn't want to spend a long time learning things, who wants to throw together something trivial and just play around with coding for a couple of weeks or so. I designed a multiplayer text MUD (well, a very small core) in MS BASIC once, but I would not try to do a project larger than about 2000-5000 lines of code in BASIC. It's just too poorly structured, and learning BASIC as a first computer language does irreparable damage to some people.

C takes longer to learn than BASIC but is a sophisticated, portable and sensible language. You will destroy all kinds of things with pointers but you will have fun doing it. Apart from assembly language, which I cannot recommend to anyone for this purpose, C generally produces the fastest code. C is supported, usually with free compilers and environments, on most computer systems known to mankind. Oh yes, and Astonia is programmed in C.

C++ takes even longer to learn than C. I never properly learned it because I consider it too complicated. But C++ is the programming language for vast sectors of the industry, so if you teach yourself C++ by programming a game you may be able to sell those skills. The object oriented capabilities of C are very powerful in skilled hands but newbies tend to use too many classes or for the wrong things, and their programs end up as slow as many well-known Microsoft products. C++ compilers are not quite as easy to come by as C compilers, but can be had for free (see a previous post of mine in this topic).

Someone mentioned Delphi. I am a great fan of Delphi. Delphi has much of the ease of use of Visual Basic, combined with a language that is clean and elegant and produces code that's about as fast as C. You can 'do objects' in Delphi but you don't have to - that's a nice comfortable way to work. With objects and other structuring, Delphi is well suited even to large projects. Unfortunately, few people nowadays know Pascal (that's the language inside of Delphi) and Delphi is kind of a niche product. Borland is working on a port of Delphi to Linux but for the time being, Delphi is only available for Windows. And like Visual Basic, it's not free. Some people also worry about Borland, the only supplier, dropping out of the market.

My current favorite language is Java. It's on the upswing in the programming industry, so learning to program in Java is probably never a waste of time. Java is a rather object-oriented language so you will be forced to learn the concepts but once you have it's pretty painless. Java comes with a VERY complete library of graphics, I/O, networking, data management and all kinds of other routines. Whereas you may need to buy special-purpose libraries for most of the other languages mentioned (such as a socket communications library for Delphi or C++), you will probably not need one with Java. I'm currently programming a simple little client/server Internet game in Java and found the networking code to be almost ridiculously simple. If you're interested, there's also a pretty sophisticated 3D library for Java which abstracts away the complications of Glide or Active3D or whatever it's called. Java and its libraries and add-ons are a free download from www.javasoft.com . The only downside, and the reason Ishtar won't consider a game like Astonia written in Java, is that it's typically slower than other languages. Our server could host fewer people if Ishtar had not wisely chosen the fastest possible language.

Just for interest, let me throw in Python. If you're only going to learn one language, and only for your own enjoyment, or if you want to learn your first language, consider Python. It's a very modern, clean and elegant language, has extensive libraries including some GUI stuff, is supported on many platforms, is free, and people found it very easy to become productive with in a short time. Fans worldwide are writing incredible things in it. Python is a clever language, but it's always interpreted and thus it's even slower than Java in most cases.

As Ishtar already hinted, unless you're a genius and have lots of energy for months at a time (like Ishtar), you should not try to write an online game as your first experience with a computer language or with programming. You'll be disappointed. Learn to walk before you run.

Finally, I can add a qualified answer to the original question: "Is it hard..."

I just got mostly through writing a client-server type of Internet game. I'm the most experienced programmer in this game, though hardly the quickest. I programmed in Java a rather simple kind of game, hardly to be considered graphical. It took me 4150 lines of code and Sharra says I was at it for about 3 weeks, off and on.

Astonia, by comparison, is a nicely graphical game with lots of features. Last I looked, I think it had 20,000 lines of rather tight code and several thousand graphics. It took 18 months to get to most of its current state, and I think Ishtar is a much more productive programmer than I.

It's nice to see programs like Astonia in action and to think, "I could do that too!" The truth is, it's awfully difficult and an enormous amount of work.

K.. i wanna know one thing.. some kid i know tells me VB6(Visual Basic 6) cant make online games.. this true or is he lieing?

He's lying. Heaven knows I don't like VB6, but it's a fairly full and complete programming language. As far as I know, it has a little bit of WinSock support (that's for Internet communications) and you can buy or download some components that do the job even better. Given an NT Server, you can build yourself a server program to run on it, and even without extensions VB is easily graphical enough for many kinds of games.

These days, the language is hardly the deciding factor on whether you can do project X; it's more a matter of:

• Do you know the language well enough?
• Do you know the required technology (Internet, graphics, whatever) well enough?
• Are you a sufficiently good programmer?
• Can you debug your program if something goes wrong?
• Do you have the time and energy to go through with it?

Pascal is a fine language. If more programs were written in Pascal, there would be fewer bugs. Borland/Inprise Delphi contains an excellent implementation of Pascal, and there is now an Open Source (=FREE) version of Object Pascal out.

Pascal is fussier than most other languages, and requires more typing than, say, C or BASIC. But learning Pascal as a first language may make you a better programmer. Be warned, though, that future job markets will probably favor Java and C++.

I found a cool Java programming tutorial at:

http://www.ibiblio.org/javafaq/javatutorial.html

It's pretty fast-paced so you will probably be less likely to get bored. There are many more like it here:

http://www.taxpolicy.com/tutorial/jvtutor.htm

I have sampled a few C tutorials, and find this one the best:

http://www.math.cinvestav.mx/manuales/ctut/clist.html

I'm at work but it's the afternoon of the last working day of the year and almost everybody has gone home. I'm mostly here to man the phones in case there's a problem somewhere. There's some testing and debugging work I should be doing, but I'd rather vent my opinions about how programming is taught, so that's what I'm going to do.

These are just my opinions; whether you take me as an authority is up to you. My qualifications include:

• a B.Sc. in Computer Science
• practical experience with about 20 programming languages
• more than 20 years programming experience
• untold computer magazines and books I have read

This is just the introduction. My "speech" follows in the next post.

A Brief Overview of Selected Programming Languages

Assembler

Assembly language is translated more or less 1:1 into machine language. Each statement you write (generally) encodes one machine instruction. If you write "Y = X + 5" in a higher-level language like BASIC or C, a (hypothetical) assembly language might instead code:

LOAD RegA,X
LOAD RegB,5
ADD  RegA,RegB
STOR RegA,Y

where X and Y are variables, usually implemented as storage locations somewhere in memory, like 0458 and 045A. The assembler (a "compiler" for assembly language) takes away the drudgery of setting up space in memory for variables and remembering where it is, but other than that you need to tell the machine exactly what to do, step by step. To this day, a skilled assembly language programmer needs 2-3 times as long to write any non-trivial program as a programmer working in one of most other languages. Why does anyone still program in assembler? Because, by telling the machine exactly what to do, you can usually write the fastest possible code for any given task. Where speed is essential, assembler still reigns. Modern assemblers help the programmer with conveniences like macros, local variables, etc.

C (Similar: FORTRAN, BASIC, Pascal)

C adds many of the conveniences of modern programming languages to assembler. There are functions, local variables, loop constructs (for/while), if/else, user-defined and structured data types, and much more. You can set a pointer to point at an element of an array, and when you increment the pointer, it will automatically be upped by the correct number of bytes to point at the next element of the array. But you're still very close to the machine level. You don't need to explicitly load and store registers because the compiler manages that for you. But most data types are sized to fit the machine's internal data types: char for a byte, short int for a word (double byte), int for a doubleword and long for a quadword. These sizes aren't cast in stone but vary from system to system to match the needs of the machine. On the mainframe I program, 'int' and 'long' are both 36 bits in size. This implies that C programs that exploit the full range of a variable may work and behave differently on different machines. That's the price you pay for working "close to the metal". C programs are usually nearly as fast as assembler programs. A good C compiler can often out-optimize a less-than-perfect assembler programmer. C coding is more expressive and more dense than assembler, and many programmers abuse this fact to write badly legible code like:

while (!(ch=get1(++k<9?"now":"later",y+=11))) (*do_x)(-5);

Something that helps make C efficient like Assembler is its extensive use of pointers: A variable can be set up with an address of a piece of data, and that data can be accessed through the pointer. Then the pointer can be changed to point at other data, either nearby or far away. Pointers that inadvertently point at the wrong data are a major cause of problems for C programmers: Basically any piece of code that uses pointers could mess up any area of data in a program. Bugs based on stray pointers are fiendishly hard to find, and a whole industry of debugging tools has arisen to help with these problems.

Smalltalk (Similar: Lisp, Python)

Smalltalk is a highly object-oriented language. Most of the things we deal with in Real Life are objects, and it seems natural to represent these things as objects in a program. Objects are collections of data and code, usually representing the "attributes" (how big? what color?) and the "capabilities" (print me! take my square root!) of the object. Smalltalk takes object orientation to the extreme: Even numbers and characters are objects. The beauty of this is that all things in a program are handled the same way, all things have a basic set of similar capabilities, and all things in a program are related, either closely or distantly, because all objects are sub-species of "the master object". All this elegance has its price: Objects tend to be created spontaneously when they are needed, and need to be cleaned up afterward. Before you can add 5 to a numeric object, the system first needs to create a '5' object. Thus, a Smalltalk program is constantly finding free memory to build objects in, and part of the runtime called the Garbage Collector is always running around looking for no-longer needed objects so it can reclaim valuable memory. All this takes time, so speed-critical systems are never written in Smalltalk - at least not Smalltalk alone. On the other hand, there are no (visible) pointers. Every data access is a "message" to an object, and an object either "understands" the message and responds to it, or it refers the message to an ancestor object which understands it, or it creates a well-defined error condition. I'm told that, because everything works the same and everything makes sense, because there is a huge, well thought out and growing library of pre-programmed Smalltalk objects, programming in Smalltalk is a joy. Good Smalltalk programmers are very productive.

C++ (Similar: Objective C)

The core of C++ is mostly similar to C. In fact, to this day, most C programs will compile and run under C++. In building C++, its inventor "tacked on" a number of object-oriented features in a way that made it possible to enjoy most of the benefits of object orientation (bundling of data with code that "knows" the data, "hiding" some data and/or code from unauthorized access, similar handling of similar objects) without sacrificing the speed of C. There are libraries of objects for C++ which make programming more convenient. File objects like cin and cout are arguably more convenient to work with than the file buffers stdin and stdout and the numerous library functions used to access them. Unfortunately, in the interest of speed, memory management is left to the programmer. This means that the programmer must create objects when needed and (in many, but not all cases) remember to destroy them when they're not needed. So-called "memory leaks" due to "forgotten objects" are a major problem in C++ programs, and again they feed a thriving industry of debugging tool makers. Other problems include the fact that C and its runaway pointers are alive and well underneath C++ and could mangle the innards of objects and other data. Operator overloading allows you to change the meaning of any function, including "built-in" ones like + and -. Operator overloading lets you use the shift operators (<< and >>) to make it look like data is flowing into and out of iostreams. This is cute, but largely abused. When you define + for strings, does that mean you concatenate them, or that you will add the values if both strings happen to contain numbers? Some string libraries have defined / to operate on strings. Do you have any idea what it's used for? Neither do I. But given the opportunity to create a mess by taking familiar symbols and giving them a new meaning, many people have done so. Objects themselves are a problem for C++ because they hide complexity. Programming a Windows GUI (Graphical User Interface) used to be tremendously complicated: A "hello world" program example took 80 lines of code. Microsoft built the Microsoft Foundation Classes (in C++) to make this task more approachable, but these classes don't make it THAT much simpler. So toolkit manufacturers generate larger, more complicated C++ libraries to "wrap up" complicated functions and make routine tasks even easier. I remember a slew of ads that read, "Look! A complete GUI application with just 1 line of code!" Well, what happens is that this 1 line of code triggers the execution of hundreds, perhaps hundreds of thousands of lines of code deep in some library. In taking complexity away from programmers (so that programmers become cheaper and easier to train), the industry takes control away from them. A simple 10-line program may be thousands of times slower than a more difficult, but well written 100-line program. I believe this is why Microsoft Word is so amazingly slow at things that shouldn't be. Millions of lines of code unknown to and beyond the control of its programmers. The basic idea behind C++ has grown like a cancer until it has become the perversion of what it once was. A popular saying about C++ goes, "C (with its pointers) lets you shoot yourself in the foot. C++ makes it harder, but when you do, you blast your whole leg off."

Java (Similar: C##, Object Pascal)

Java is younger than C++ and has tried to learn from the mistakes of C++ and other languages. The basic data types have well-defined sizes: An int is 32 bits no matter where. There are no pointers to blast your data with. The handful or so of basic, integer data types are built directly on the hardware's data types (like in C) and operations on these data types are as fast as in C. All other data types are objects. And objects are garbage collected automatically. There is a large and well thought out library. I'm particularly pleased with the fact that not just file-based input/output but also network communications, GUI control and even security are built directly into the "stock" library. I have written a number of Java programs and never needed to use a third-party library for anything.

Java leaves out a number of the dangerous features of C++, so Java programs tend to have fewer mysterious bugs than C++ programs. Still, some programmers miss the convenience of some of the more powerful features of C++, such as templates. And once again there is an industry out there wrapping objects around objects to make them simpler and more powerful. Speed is only about the third priority for Java; Java programs are (mostly) slower than equivlent C programs and often slower than C++ programs, and I worry that the libraries of objects intended to make programming idiot-proof will make it slower still.

I'm finally getting to the point where I argue why C++ is a lousy choice for a language to teach to beginning programmers.

From the overview above, we remember that C++ is C, with the following stuff tacked on:

• Objects (data and code are bundled, objects inherit from other objects)
• Operator overloading ("<<" means "shift" or "move this data", "+" means "add" or maybe "concatenate" or maybe...)
• Templates (if you define an algorithm to work with ints, you can have the compiler copy it to work with floats, or some objects)

Mr. Stroustroup has written a fine language here. Some of the library of objects he has thunk up, like iostreams, solve a number of long-standing problems with the previous functions. Doesn't this:

cout << "Joe" << "and" << "Bob" << nl;

look a lot neater than this:

printf("%s %s %s\n", "Joe", "and", "Bob");

Sure it does. And Strings are a lot easier to work with than arrays of characters. But the fact remains that many of these features that started out in a small and well-defined way have become huge, complicated and unmanageable. Here are a few examples:

Multiple inheritance means that any class can inherit the properties (data and code) from one, two or more parent classes. For any given data member (err, field) or any function (err, method) which is defined in two or more parent classes, how do you know which class contributed it? It's determined by the order in which the parent classes were mentioned in the declaration of the child class. This applies not just to the class you're looking at but to its entire parent hierarchy. There is a good reason why C++ is practically the only language with multiple inheritance. Operator overloading has a few "sexy" applications, but it's mostly used just to cut down on typing and it confuses people in the process. I've already given examples. Templates let you write a set of functions to do something with some data, and you can apply the same set of functions to each data type you use it with. So if you use your "double-ended queue" algorithm on 20 different data types, the compiler will copy your code 20 times. The 20 different versions of your code, each specialized for a certain data type, will doubtless run more quickly than a single version that has to give different treatment to different data types. But it sure can bloat your code! And of course all this code takes a long time to load. Character arrays, character array functions and Pointers are still alive and well in C++! You can mix "old-style" string handling with "object" string handling in the same routine if you want - and confuse the heck out of yourself. Similarly, a single misused pointer in an otherwise completely object-oriented program can bring the whole thing crashing down. C is a fine language in and of itself, but the fact that it lives on in C++ is a liability. Objects, the big selling point for C++, can also be a liability. They can be used to hide a lot of complexity. They can make difficult things easy, but this also means they can make you unaware of what you're doing. Consider the controls in an automobile. My parents used to have a car with no power steering and a manual transmission. Driving that car was WORK! I would never have dreamed of getting into that car and driving it when I was 6 years old, simply because I couldn't have. Modern US cars with Power everything are so simple to drive that kids often do, and often with fatal results, because there's a difference between being able to control a machine and being a qualified operator of it. The industry needs programmers, and other parts of the industry are cranking out tools and add-ons that promise to make programming child's play - much of it object-oriented. It's easy these days to click-and-drag yourself a graphic user interface, but I see many programs that don't work the way I would like or expect, simply because the toolkits and libraries used in constructing them didn't think of certain ways a program might be used. Have you ever noticed how, when you scroll a multi-page document in Netscape using the PageDown key, your cursor stays on the last page you positioned it on? Sometimes touching the wrong key zaps me back to where my cursor was, ages ago, and surprises the heck out of me. It's built into Windows that way, and all the programs that use the Microsoft Foundation Classes work the same way. That was probably a poor example, maybe someone intended for it to work like this. Consider another example: A colleague of mine, programming in C++, passed an object by value rather than a pointer to it into a function. Passing a variable by value causes a copy to be made. It so happens this object contained most of the data of his program, several megabytes in all. This function call was in a loop. Every time the function was called, megabytes of data needed to be copied. He never realized this - it was just one little variable being passed around! He needed outside help to understand why his program was running so slowly.

I got started on this when I realized (or assumed) why Corwin's teacher didn't show him the argc and argv[] arguments to main(): It's because argv[] is an array of character arrays! This is evil. Consider that, for months, Corwin's class has been working with these nice, clean array objects. They have a definite size, they're accessed only with subscripts, never with pointers, and if a subscript is out of range a well-defined error condition occurs. argv[], on the other hand, is a C array. Its size depends on the number of command line arguments; argc tells you how many there are but you're free to ignore argc. argv[] isn't really an array, it's a pointer. You could change its value if you wanted to. You can access the elements of argv[] either with a subscript or a pointer. If the subscript is out of range or the pointer is out of range, you may never know. Similarly, the characters in the elements of argv[] (actually, they're not in argv[]; argv[] is really just a list of -you guessed it- pointers) are just arrays of characters. We don't know how long these strings are, other than that they end when you hit a character that's a binary zero. The "strings" in argv[] can't be concatenated with "+", they don't have "substring" member functions, and although they're input-only data to your program, you can change their contents. I imagine the horror: A class used to the nice, clean, object-oriented methods from the textbook, suddenly confronted to the unshielded ugliness of primitive C. Their teacher (I am guessing) is keeping C a deep, dark secret from his class so that he can get on with the rest of his course load.

When Corwin gets a job, he may end up maintaining C++ code written by old cronies like the colleague I mentioned earlier. This guy is essentially a C programmer, using object-oriented stuff only when he has to. So his code is mostly C, with arrays and pointers and the "old-style" function calls. Corwin will be in for culture shock.

So C++ ends up as an animal like that mythical elephant with the 3 blind men. One of them felt the trunk and thought it was a snake; one felt a leg an said it was a tree; etc. C++ has grown so big that there are a number of very distinctive ways to program in it, and so rich that it takes a very fat book to describe its features in detail. I follow the monthly discussions in the C/C++ User's Journal. Novices write a normal-looking program, then ask the masters why it doesn't work, and the masters quote a page from the Annotated Reference Manual which describes an obscure quirk of the language which surfaces under rare circumstances, possibly only in some compilers. Just yesterday, I read in the editorial of this same magazine that the author had used a certain template construct in his program, and that his compiler had issued an "internal compiler error". Complexity was layered on complexity until neither the compiler nor the author of the program knew what was going on. The author rewrote the construct by trial and error until the compiler stopped choking on it.

Anyone remember PL/I? It had the record structures of COBOL, the arithmetic expressions of FORTRAN, data types from ALGOL, some string-handling capabilities from SNOBOL, I/O facilities from all of these languages. The compiler we had at the University was high-tech; if you made syntax errors, it would try to guess what you REALLY meant and would then generate code to implement its guess. For a while, I thought that PL/I was cool. But when I went to buy the manual from the library/bookstore, it was thicker and more expensive than all the other language manuals. I had learned (enough for a first project) all my other programming languages by buying the manual and reading through each from cover to cover. I couldn't do that with the PL/I manual; if I read it all the way through, I would miss the project deadline. Well guess what: PL/I is practically dead now. C++ isn't quite as feature-laden, but it's well on its way. C++ got a good step up from C, the many programs written in C and the many proficient C programmers. Now C++ has a stranglehold on the industry because there are too many programs written in it to quickly turn away from it. But I think that the dissatisfaction with C++ is still on the rise.

I don't like the War of the Languages being carried out on the backs of young students. I think a language should be small enough to fit into the curriculum of one semester. Pascal and C were such languages; even BASIC was a good learning language in its days. C++ is not. It is too bloated, there are too many rules and too many exceptions to the rules.

I recently bought a book called Java How To Program by H.M.Deitel and P.J.Deitel, (I think) a father-and-son team of professors at some Ivy League college. I think they've written an exceptionally well thought-out book. In their foreword, they say that they were in the midst of setting up to write the 3rd edition (or so) of their (you guessed it) C++ How To Program book when they heard about the emergence of Java. I'm paraphrasing from memory here, but they said they more or less threw their C++ manuscripts out the window and immediately went to work instead on making Java more accessible to students with this new book. They said some nice things about Java that I don't remember, but I remember gathering that they were positively impressed.

I realize I won't make a lasting difference in the Great War of the Languages, and I realize that Java also has its shortcomings. Its worldwide debut in worldwide-compatible browsers was thoroughly botched by both Netscape and Microsoft; it is lacking some features which appear sexy in C++, and can't compete with the speed of C. Still, Java is quietly gaining a lot of ground on servers and workstations all over the world, and is still growing (carefully) and improving. Best of all, I feel Java is considerably simpler than C++ both to learn and to teach.

If you're dead set against Java, there are other possibilities to consider:

C

The classic. There's still not a lot to be said against it, even after all these years. Ishtar has built a very cool game with just his bare hands and a C compiler.

Objective C

A less obese brother to C++. More speed, less clutter.

Python

A very modern and clean, very object-oriented language. Available on practically all systems, with a good and growing library for all purposes. Interfaces nicely with C, Java and other languages. Never as fast as C++, but great for programmer productivity. The core language is tiny and easy to learn.

Object Pascal

Evolved from Pascal, which is also a very clean, simple language. The object-oriented stuff is there if you want it but it's unobtrusive. Borland has given it a Windows IDE and a large, useful library, and called it Delphi. Coming soon to Linux too!

Got to wrap this up before the year ends... best of everything to you all, no matter what language you prefer to program in!

Simple. In what we foolishly call "Real Life", almost nobody programs in a vacuum. Much of the work of programming involves having to deal with other peoples' code, if only to make use of libraries or "steal" code. Even if you have the discipline to write "clean" code, be assured that others don't.

Code communicates not just with computers but also with other humans (usually). English has about 50,000 words and people with different subsets of this vocabulary often have trouble communicating. Think of C++ as a language with 500,000 words.

I'm just reading Dr. Dobb's Journal, my favorite computer mag. This is its 25th anniversary issue. In this issue, they introduced yet another new programming language called Ruby.

This is a very object-oriented language, very simple and very clean. The person who invented it did so because he had this dream of making and using the perfect programming language.

No, I doubt it will replace C, C++, Visual Basic and Java. But there are three reasons you may want to look at it:

1. If you're a non-programmer, you may want to learn and play with this language... maybe you'll like it and become one of us!
2. If you're a programmer, it's never a bad idea to have a good number of languages under your belt.
3. But best of all... It's absolutely free!

Here's the URL for everything Ruby (or at least a good starting point):

http://www.ruby-lang.org

I pay for my subscription of DDJ, and have been doing so for 10 years. My Dollars have been invested into putting up a free Web site for the rest of you at:

http://www.ddj.com

Two languages? *laugh*

I'm familiar with almost 20 and I use 4 different languages almost every day.

The sad thing is, though, that in 'real life' programming languages are rarely chosen for their suitability for the problem at hand. Usually it's a matter of what languages have a sufficient number of proficient programmers available, or cheap tools, or which one has a huge in-house code base to be extended from.

Very often, political considerations win out over technical advantages and the programmers have to live with the decisions of people who may not be qualified to make these decisions.

I earn most of my money by programming in FORTRAN 77 for a German airline. I write programs in support of a flight schedule loading and distribution application. A small fraction of the programming I do for this job is in assembly language, C, BASIC and a proprietary script language called SSG. I also once taught a one-week Java course at this place of work.

As a second job, I am also currently writing a database browsing utility for a small programming shop. They are using an old DOS-based utility which they like a lot but would like to have a Windows program with some more capabilities. So I am writing a clone of their old program for them in Borland Delphi 5.

For a little more fun, I am working on a little 3D online multiplayer game. No, I don't think Ishtar needs to worry about competition from me - I'd say Chong and I are neck to neck. Against Ishtar's strong advice, I'm writing the whole thing in Java, just to see if I can pull it off.

Lastly, I very occasionally look at Astonia's code, I am teaching someone C by correspondence, and I occasionally answer questions about C in this forum.

Even before the Internet craze and the Y2K panic, I never had a shortage of jobs or money, so I think programming is a healthy profession to work in. I realize, though, that it may be possible to haul more money out of a computer-related education based on something other than pure computer science. I hear that various MBA programs with a lot of computing in them make for very profitable careers.

As for what things one can program with "just" a Computer Science degree, you can take a look at some of the things I've done:

http://www.smotricz.com/SSS-projects.html

Bubble, remember to go VERY easy on Java hype. The moment you make statements like:

• Java is cross-platform compatible!
• Java is clean!
• Java has no pointer problems!,

Ishtar tunes you right out out. He labels you as a SunSoft drone, little better than an emissary from the Gates of Hell.

Before you can successfully teach someone, you have to get in sync with his mindframe. So the way to start would be to say,
- Java is the bane of my existence!
- Given a choice, I would rather program in Assembler!
- I learned Java for one week and now I'm writing from an asylum!

Then you go on to say, "but if they have the thumbscrews on you and are holding your first-born hostage, and you absolutely MUST program in Java, then you could do this:..."

I'm hesitant to start another language war, but I think the following comments are pretty harmless:

VB is not a bad language to write standalone games in, i.e. ones you play on your PC without the need for network access. Thousands and thousands of games are written in VB. Most of them suck, but that doesn't (necessarily) mean VB sucks, and you have to start somewhere. VB is probably easier to learn and experiment in than many other languages.

More serious games, such that feature stunning graphics and/or dazzling performance and/or network multiplayer-ness, are usually written in C or C++. But you shouldn't even be thinking of anything like this until you have experience with a few simpler games under your belt.

So: C/C++ are a good bet for the long run but VB is OK for first experiences. Do whatever you want!

Back to Table Of Contents