"Young people occasionally ask me whether language X is something they'll need to make computer games, or what they should learn if they want to become programmers. And what language should we teach in school?"
Thought I'd post this here. Full article by a current programmer for Funcom (Anarchy Online): http://enno.homeunix.net/index.php?itemid=224
C
I'm not certain I'd pick C first, but I'd definitely have a person learn C before C++ and Java.
I agree with the author that learning Java first is a mistake. Yes, it's nice that the student doesn't need to worry about pointers (oh, no!), but teaching OO first is a mistake - a very bad one. Java is also horrid in its verbosity and sprawling library.
While OO is conceptually easy, actually implementing it isn't, at least in Java and C++. Further, since it hides logic, hidden effects can occur. This is impossible in C. WYSIWYG.
I've heard people argue that python may be a good starter language.
When I studied theoretical compsci + telematics, we were "taught" Oberon and Algol. Those are nice beginner languages, because they make you realize real fast whether you really want to be a programmer or not, and in that respect I advocate their teaching
I agree with the notion mentioned in >>4 that python may be a good choice, because -in my opinion- it is conceptionally close enough to C to be of use while being somewhat easier to pick up at first.
i'm surprised no one's mentioned perl yet... i'd say perl and c would be the two best choices...
java actually wouldn't be too bad for a beginner language... it was my second language and it definitely made learning other languages seem a lot easier...
C wouldn't be a very good language to start out with, IMHO. It simply isn't a very newbie-friendly language. Error messages are often cryptic, documentation is often inconsistant or incorrect and don't get me started on 3rd party library use.
When learning programming, it is really more learning a way of thinking rather than learning a language. If you can code in one procedural language, you can usually pick up another procedural language with relative ease. However, when actually in the process of learning that 'way of thinking' it is in my eyes better for the one doing the learning to be able to actually focus on the learning of that way of thinking rather than trying to figure out what 'Error 01' means (true story, by the way... I still have no idea what it's supposed to mean).
I do think a procedural language would be the best to begin with, though. Not only is it easier to grasp than, for example, OO, but once you do begin using OO, you'll also be using concepts used in procedural programming.
>Java is also horrid in its verbosity
Eh? Why would verbosity be horrid? Programming is programming, whether a method is called c_str() or toCharArray(), it all requires the same way of thinking.
>Further, since it hides logic, hidden effects can occur. This is impossible in C.
I'm still curious as to how OO hide logic more than the use of functions and structures do.
>>5
Another benefit of Python is that even though it's capable of being used as an object-oriented language, students can transition smoothly from procedural base libraries to more specialised OO libraries. Unfortunately, the deprecation of procedural functions in the string library doesn't bode well for the future of that sort of transition.
It's also worth noting that Python enforces the use of proper indentation and spacing.
>>7
OO classes make use of private functions that may be incomplete or faulty implementations of functionality available in other third-party libraries used by the same project. It isn't clear exactly how any function works in a given class relative to similar functions provided by other classes. In a well-designed, totally self-sufficient, fully-encapsulated object, I suppose it wouldn't matter, but how many classes realistically provide all the functionality you'd ever need from it without having to subclass it at some point?
> In a well-designed, totally self-sufficient, fully-encapsulated object, I suppose it wouldn't matter, but how many classes realistically provide all the functionality you'd ever need from it without having to subclass it at some point?
I can see you've never used Cocoa.
(Unfortunately, that's probably not an option for teaching GUI programming...)
This should tell you all you need to know:
http://groups.google.co.nz/groups?selm=60k4s3%24dci%40netlab.cs.rpi.edu&output=gplain
>OO classes make use of private functions that may be incomplete or faulty implementations of functionality available in other third-party libraries used by the same project. It isn't clear exactly how any function works in a given class relative to similar functions provided by other classes.
In C, at least, it's also possible to prevent others from using a certain function. So, if I wanted to use the functionality that function provides myself, I'd have to write a function with that functionality myself, which may be an incomplete or faulty implementation of that function.
>In a well-designed, totally self-sufficient, fully-encapsulated object, I suppose it wouldn't matter, but how many classes realistically provide all the functionality you'd ever need from it without having to subclass it at some point?
How is that any different from having to write your own function because a certain library doesn't provide the functionality I need?
I think, whatever lang you start out with, it should be an interpreted one. They let you more quickly see the results of your code without having to hassle with the compile-debug-compile loop. And it's not like n00bs are going to be writing serious resource-intensive programs anyway.
I'd go with Python.
C isn't a good first language - it's a bit too unforgiving - but it is definitely a very good second or third one. Everyone should learn C at some point, just for the lower-level understanding of computing it gives you. These days, learning assembly isn't really feasible any more, so C is a good second choice for learning how a machine works. Besides, pretty much everything you actually use is written in C or C++.
For a first language, I'd agree that an interpreted one might be a good choice. The best would be a interpreted one with an interactive mode, but those are few and far between these days. Depending on your mindset, Perl might be very good or completely awful. An easily overlooked alternative, however, is Javascript. Javascript is syntactically very simple and elegant, it lets you do things that are actually somewhat fun, and it is available on pretty much every machine by default. The downside is that it requires some familiarity with HTML before you can really use it.
C is very useful to learn at some point for the sole reason that a whole bunch of languages are based on the C syntax - C++, javascript, java, php, and probably a bunch more. One may like or dislike these but getting to know their syntax for "free" is a good thing.
>>13
If JavaScript is interpreted exactly the same way by all interpreters and executes predictably in every browser, maybe.
>>11
Procedural languages don't conceal data in classes that only the class' own functions can access and manipulate. With C, you can personally debug and correct any function that you write to manipulate the data. In an OO language, you might have to code an entire custom class that reimplements most of another class' functionality from scratch just to work around a bug (child classes can't access the parent's private data). With a procedural language, you can get away with replacing or adding only the one function that's broken or missing.
There are C interpreters out there. I learned C with one of them. It was limited but very useful to get the hang of C. Plus the code could be re-used into a proper C compiler afterwards.
As for bad documentation, I don't know the current state of affairs but Borland was very clear back then when I learned. One click and the function was explained, with examples that could be copy/pasted.
While Microsoft Visual C's help was a total nightmare, very unintuitive.
The language itself executes pretty predicatbly across most browsers. It's when you start digging into the DOM that you run into the problems.
>>16
Odd that. I used to think that Microsoft's strong point was their documentation. Going from QuickBasic and QuickC to TurboC++, I remember clearly thinking that Borland's documentation was horrible. I often referred to QC's documentation for details.
I never used QuickC (for DOS) nor TurboC++ (for Windows).
I practiced with Borland TurboC/C++ (for DOS) and MS VisualC 2.x (for Windows).
Maybe they had completely different help?
Meanwhile I found the name of the C Interpreter I used: Quincy.
It was offered with an issue of DrDobbs Journal, and is still available at www.ddj.com.
I find Microsoft's documentation very good as well, particularly in content and organization. It's come a long way in the last 7 or so years. As far as horrible documentation goes, I'm going to have to give the prize to Sun.
>Procedural languages don't conceal data in classes that only the class' own functions can access and manipulate.
True, but that doesn't mean data can't be concealed. It can be.
>With C, you can personally debug and correct any function that you write to manipulate the data.
In an OO language, if you wrote the class doing the concealing of data yourself, then obviously, you'll be able to debug and correct any method that's part of that class to manipulate the data.
If you didn't write the class yourself, but want to write a function that manipulates that data, then you'll need to make some workaround, of course.
But then, the same goes for procedural languages; if the data is concealed (which can be), you can't acces, and thus, not manipulate it, unless you make some workaround.
To elaborate on verbosity:
I hesitate to elaborate on why I believe Java is too verbose, simply because there are so many exceptions and caveats. After some thought I've come to the conclusion that it isn't the language itself I dislike. It's the standard library that comes with it.
Now, why does terseness matter? The issue for me is the quick recognition of what the code is doing.
Ie:
class YeOldeHelloWorld {
public static void main(String[] args) {
System.out.println("Hello World!");
}
}vs:
print "Hello world!"vs:
"Hello world!" .;Now, you can get around that rather ugly System.out.println mess by importing (see: an exception already). It's also unfair to bash Java for the "public static void" since they serve important functions. However, this whole mindset pervades the entire standard library, and leeches into the code that I've seen other people produce.
"Sure," you say, "but you should have a deep understanding of the code anyway! Most your time won't be reading or writing the code."
That's true! But when you're dealing with large amounts of code, shortening the interval until comprehension is critical. Can you fit the meaning of a code statement in one glance, or do you have to read it for a couple moments? Multiply that by a never-ending stream of code as you sit there all day, and that reading becomes a time sink. More reading, less thinking.
There's also the problem of reader fatigue, which has been studied in different disciplines (http://cogprints.org/753/00/pmuter1.htm for an overview). That's all nice and well, except when you bump up against java's library (I detest Java 3D):
TransformGroup tGrp = new TransformGroup();
rootGrp.addChild(tGrp);
tGrp.setCapability(TransformGroup.ALLOW_TRANSFORM_WRITE);
tGrp.setCapability(TransformGroup.ALLOW_TRANSFORM_READ);MouseRotate mRot = new MouseRotate();
mRot.setTransformGroup(tGrp);
mRot.setSchedulingBounds(new BoundingSphere());...which is by far not the worst example I can come up with, since it doesn't involve the creation of useless objects just to pass some silly values to the Java3D library (ie: bc.addBox(0.5f, 0.5f, 0.5f, new Color3f(1, 0, 0), new Color3f(1, 0, 0));).
To point out further why terseness matters, allow me to make an absurd example:
c_str()
vs:
toCharArray()
vs:
ConvertAllCharactersInArrayToOneByteUnsignedCharacters()
Alright, that's extreme. But I hope you see where I'm going: it takes time to read that. Even toCharArray() may be too long, since it will probably be part of an entire statement, not just sitting there on a single like alone.
On the other hand, something like ca() is the opposite problem: it's so short it conveys no useful information (one reason why complex regex's are sometimes called "write-only"). Obviously, a balance must be struck between meaning and descriptiveness. I think the Java libs err on the side of descriptiveness.
Of course, this is entirely my preference. YMMV.
Actually, what the Java runtime does is make difficult things possible, and easy things just as difficult. For instance, if you want to use the Java library to load an image from disk and process it, you have to create a horde of useless objects, including one object whose purpose is to monitor when the image has finished loading and tell you about it. This is all obviously designed to be usable in an environment such as a web browser, where you want to issue requests for images over various kinds of network connections and have them load in the background. However, when you want to load a single image from a local disk, you have to do JUST AS MUCH WORK as if you were loading it asynchronously over the network.
PHP
I'd agree that PHP is in the same class as BASIC or Pascal, but the danger in teaching people PHP is that they might actually use it for something. <-- troll
Yes. Whereas if we teach them Perl instead, they won't be able to use it for anything. <-- troll right back
>>24
That's the problem with Java in general, it takes the jackhammer approach to everything. It's virtually almost never the right size for the any given task.
The concept Java is based on is good, but they really screwed up the implementation.
Well, there is always QuickBasic. The language was simple, as was the IDE, and came with extensive help and examples. It's what I started with, and I had a lot of fun.
What's good in an learning language is instant gratification. Having a good graphics and game library is a great thing in an learning language, because making graphics and games is fun.
If you have an interactive mode to just punch in expressions to see how they work, that's even better.
>>30: Python it is, then.
order i learned: LOGO, then ZZT-OOP, then QuickBasic, then javascript or C (and from there one should be able to learn anything, right?)
brainfuck?
> ZZT-OOP
lol
A school of thought holds that Scheme is a good choice for a first programming language. First, learn how to program, then learn C's syntax.
>>36's school is full of it.
You pretty much end up learning to program twice if you do it that way. Some people who have been doing CS for far too many years have forgotten all about what being a novice programmer is like. Functional programming may appeal to people who are already familiar with the rigorously mathematical way of thinking, but for the novice an imperative language is far easier to understand and follow - reading a recipie is easier than reading a mathematical proof to most people.
I wouldn't be that harsh. Assignment in imperative languages isn't exactly intuitive either.
Scheme as a first language is definitely unorthodox though. o.x
use perl;
Isn't Scheme the first language taught at MIT for CS?
And sure reading a recipe is easier than a mathematical proof, but it does't make you a good cook^^;
Most people who go into CS should be pretty decent at math, and if they don't understand the algorithm behind a program they should work on catching up because otherwise they are not going to get far.
We did HUGS (Haskell) in first semester CS and I didn't have any particular problems (backed up only by school maths and no programming experience at all), now one semester later we are doing Java and comparing the two of them I'm glad we started with the functional one.
>>40
Fortunately, programming and computer science aren't inextricably bound to each other. Many programming projects require neither math nor mathematical thinking; only a clear sense of what you (or your users) want the program to do, and how to present that functionality. The backend and coding framework will reveal itself with a bit of trial and error.
There's a place for math in physics modeling and all that stuff, but I don't see it as a definitive element that must be mastered to get anywhere.
Two languages should be taught. The first should be C. This gets kids used to playing with VB, JavaScript, and the like down to real machine level problems, like pointer manipulation, buffer resizing, data structure design, etc. You really learn how systems programming actually works with C, something that langauges like Java hide from you. And debugging in C is for real, chasing pointers and poking through data structures by hand. It's as close to assembly as you'll get without having to learn a specific machine architecture.
Second should be a language that breaks all the usual paradigms, like Common Lisp. You can teach OO in it, you can teach functional programming in it, you can teach compiler design in it, you can teach complex systems analysis in it, graphics programming, automated code rewriting and optimization, all sorts of stuff. You're abstracted away from the machine unlike in C, but you can dig deep and play with the bits if you want.
After that learning Java, C++, Perl, PL/SQL, COBOL, or anything else is pretty easy because the concepts in all of those languages have simple maps to either C or CL or both.
Your arguments are correct, but these are not "first" and "second" languages, but more like second and third, or even later. This isn't really about what to teach at the university level, but what to teach to those who want to learn programming from the start. There is a lot to be said for a first language that DOES hide all that from you, just to get you used to thinking in terms of programming.
Why do you hate Tcl/Tk? I like it.
>>43
If you don't already have some minor programming experience before entering a university program in computer science then you probably deserve to lose. You should already be capable of thinking algorithmically (although obviously not necessarily good at it) by the time you take your first formal programming class at university, because this is something that shouldn't need to be taught, just as use of variables shouldn't need to be taught in mathematics at a university. It's also something you are unlikely to learn quickly enough to pass your first semester in computer science. Therefore the languages that university students should be learning are languages which expose them to the maximal programmatic experience.
If you want to learn how to think of and write computer programs, go to a community college or learn it in high school. University professors shouldn't need to waste their time handholding CS students. This doesn't apply to programming classes for people the natural or social sciences, since they're not expected to be talented with computers; however CS students shouldn't be taking those classes (unless they need an easy A).
I don't understand why university CS departments are trying so hard to be monolingual. Linguists are expected to learn at least two other languages besides their native language, and human languages are much harder to learn than programming languages. (It takes a typical linguist a couple of years to learn a language well enough to hold ordinary conversations. It takes a typical programmer a couple of months to learn a programming language well enough to write ordinary programs in it.) It seems to me that CS students should be expected to learn several programming languages, and to use them confidently. Particular classes would of course focus on particular languages, but it's strange to me why departments insist on only teaching one major language and then introduce one or two others in passing for a single semester and have students write only toy programs in them. CS students today ought to graduate with full competence in at least C, Java, and some "minority language" which is quite different from the Pascal/C camp like Lisp, Haskell, Erlang, Smalltalk, etc. They can go on to learn "industry" languages like PL/SQL, COBOL, Intercal, Fortran, et similia in the working world, and will have experience learning new languages quickly because of their education. And they'll naturally pick up Perl or Python or PHP or something because that's just what happens.
Hah, I see your point. It's just that they're rather rare now days (yay!).
COBOL: primarily legacy code in banks
Fortran: legacy code in scientific circles
PL/SQL: heavy-duty DB
Intercal: uh... someone help me here... do people use this?
When I think "industry" I think C/C++, Java/C#, VB, Perl/PHP/Python.
http://www.catb.org/~esr/intercal/ might be what you're looking for.
Here's ROT-13 implemented in Intercal: http://www.ofb.net/~jlm/rot13.i
My teacher used to says one is not a programmer before he can program xx programs in three languages. I forgot how much was xx - maybe 30. 3 x 30 = 90 programs.
>>39 is DQN
He's wrong. One is a programmer when one can program any program in any language. Subject to inherent limitations in the languages and what is a reasonable amount of work, of course, but a real programmer transcends language.
Now, that is what should be taught at university: How to write any program in any language.