"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.
> a real programmer transcends language.
And this from a Bertrand Russell fan.
My school is switching from VB.NET and Java to Python and standard ISO-compliant C.
for the 1st learn... u should try BASIC...
since no one clever enough to understand why we must learn BASIC (is for learn flowchart)
TRY C or C++ (better).
by the time u use above, u will not learn how the prog work.. if you learn from this step:
U will soon understand what i speak about.
the step i say basicly 2 step!
the question u will ask only What computer language should we teach? => the answer above step.
if they learn C (not full learn is no PROBLEM)
U will find out every prog. using same style like C..
oh yeah.... Java is the <b>D</b> languages.. (Djava)
the cause of C is to upgrade B, The D is to upgrade C. one more u should know.. Java is a island in Country named INDONESIA and i live there and write from that island
Basic will fuck over your ability to program in every other language by teaching you bad style and making you lazy around UI's.
Basic will fuck over your ability to program in every other language by teaching you bad style and making you lazy around UI's.>>>
i don't say you have to learn BASIC... U learn the flowchart from BASiC... u don't have to face the dim (array things)...
is that suck... YEAH
but face it... no one cleaver than me.. since I more STUPID than U!
>>59 deleted because it was incoherent rambling that broke the tables with coded text. Don't do that kind of shit in here, please.
Teach them to program directly in the target system's machine language. If they have the patience to even manage a hello world program then we can probably trust them not to use horrible shortcuts in higher level languages.
On a more serious note though, I think Python has been touted as a good language for beginners. I agree with >>51 though. Programmers should aim to learn the concepts of programming in a manner that does not depend on implementation. Unfortunately this is not easy to do because most people will balk if they see even the smallest difference in syntax. A lot of people complained to one of my professors for having his examples in Pascal when they were being taught Java.
We shouldn't be teaching a language, we should be teaching how to build components, which means instead of picking a language environment that is language oriented like Java, it should be one that is component oriented, which means ones like the main .NET languages, Delphi, or even, horror, regular Visual Basic.
This places the focus on actually solving the real problem and thinking about how and making your little component behave consistently with other components.
I think we should be teaching people not to think like >>62.
>>62
stfu troll
If you don't understand my comments when I am being intentionally abstruse, you can always ask what the hell I am talking about.
Component oriented looks like a zomg new term for object oriented. Someone explain to me how they differ.
No, "components" are things you license from shady software companies, and have half-finished implementations, bad documentation, and numerious bugs.
the question in this page are What computer language should we teach?
it mean... the person ask this are want to know what ideal languages should he/she teach to everyone like me or U!
Damn i believe i was wrong/mistake to know what he/she want!
why i give that talk! (see BEDUL) >>>>56 because in my university i use that Way!
BTW... the step i lear is:
2.Basic
2b. fortran
3. pascal
3b. VB (welll VB 5 not VB#net)
4. cobol (trust me... is real)
5. C
6. ASM
basicly.. what u want to teach is up to you. Even is only basic (change languages u able to use), u must remember one things... there a lot people in the world MAY not know about Basic (or that kind) or maybe MORE ADVANCE than u.. Don't affraid.. i use to be that...
what i going to do is learn from them... HEy... Teacher (or assistant) can learn from her/his student. The time has changes.. to learn.. u must not always to be the supperior... u have to be adapted...
BTW sory about my languages... in the 1st i was arrogant.
i'm from Indonesia... so my english in this are rather.. confused... not good english huh!
Components are more generic pieces. They link to each other using your chosen communication framework, sending messages to each other to get things done.
In one model, the only assumptions you make about other components are in the input and output of each component. Everything, including implementation/language, is hidden. You then use your connecting framework to link everything together.
That sort of thing has its place, but it's no model for general purpose programming. You're not going to be using linked list components or hash table components in your code anytime soon. The overhead of the communications framework is far too big. That sort of thing is more for high level systems design.
>>71
Yes, that's right.
Personally, I say teach program flow, then OO, then PLs. The people that won't understand the general idea won't understand if you start with Lisp or Scheme anyway. At least this way you get a bunch of people that know how to script, which is useful. Whether you should kick them out of CS is up to you. It has to be done within 2 years if you want to give them a chance to go into something else.
IMO python is best suited for that purpose.
It's easy, powerful, portable, interpreted, and very similar to most popular languages (c/c++,java,...)
I wouldn't touch commercial, unportable stuff like delphi, or vb with a ten-foot pole.
In my country pascal is usually taught in high schools, but i don't think anyone is using it for anythig else. ;)
Anyway, if you know one language, learning another isn't hard.
If you know one language, learning another is very hard.
If you know three languages, learning another isn't hard.
learning just C make u learn PHP, ASP (even like VB), even all linux based and JAVA!
but learn 1 languages is useless without learn how to manage/make everyone beside the builder understand ur languages (program).
what i mean is... u must know to make anyone beside u (i now u will never created the prog alone! so anyone is your patner) know the prog works.
I am thinking it would be more useful to learn English.
i think assembler is the best as a teaching language. expecially RISC assembler >:)
>>76
I concur.
From my experience, the best way to teach programming is to start (and here's the really clever bit) before the University. A mandatory school course in basic computer science, with focus on program flow and algorithm (as opposed to data structure) concepts would not only help teach CS in general, but would also aid the general population to stop treating computers as black boxes that work somewhat in the same way as the laws of physics.
Languages of choice for that would include any scripting languages, with my preference being JavaScript, and possibly Basic. It is important to note that many of those habbits picked up by using these languages often reflect fault in mentality (which should be broken while inside those languages) rather than fault in choice of first language. Also, these languages hide the UI behind a black box, exposing newbies to an intermediate between flowcharting and in-depth UI programming. (Seriously, does anybody actually like using message pumps for events?)
After simple algorithmics, it is important to get a feel for the basic structures that power computer programs. A data structures and algorithms class is a must at a very early level; languages of choice for this would be C, Java/C# (little OOP emphasis). While C prevents dealing with OOP concepts right away (which might or might not be a good thing at this point), it introduces a lot of ideas that also might be completely extraneous - namely the nightmare that is memory management. On the other hand, automatic, non-preemptive garbage collecting ala SmartPointers should be covered in a DS class... Really depends on the specific nature of the class.
After this grounding in computer science (which realistically should occur before the University level) concepts emerging from evolution into OOP and complex infrastructures (esp. as Operating Systems, Networked Systems and Enterprise Systems) should be taught. At this point, language really does not matter, except for implementation specifics.
Note: the above is only half of the story. It only covers the practical programming side of CS. The theoretical side is a widely different animal. To start, CS theory has solid grounding in math. Without basic familiarity with combinatorics, probablity, and possibly some graph theory, aspiring computer scientists would get lost in the tangles of theory.
Like mathematics, it is best to study CS theory in Historic order - i.e. emergence of static computing engines -> finite state machines -> pushdown automata -> turing machines -> equivalence between language decision/recognition and solution of generic problems -> computability -> complexity... After that the simple linear model protrayed above breaks down, getting into increasingly abstract (though sometimes not so) fields. Information theory, i.e. coding/data size, cryptography, etc. and other such things can really be done in any language, though their formal definitions are usually expressed in mathematical terms.
The more 'academic' languages mentioned above, most notably Scheme, belong in the group of languages used to teach the theory of CS, rather than the practice. I, personally like the beauty of scheme, but would not be caught dead trying to build an enterprise system on it - it is too rigid, too formalized for practical purposes. Similarly, imagine an engineer being forced to use cutting-edge mathematics from theoretical physics to calculate stress from loads in his designs. Not practical whatsoever. If all those applicants that did not know C++ showed up for the interviewed mentioned in the article with their language of choice replaced with Scheme, it is unlikely they would have been hired.
A true CS program includes a balanced collection of functional languages, theoretical languages, and specialty languages (SQL, COBOL, the like). Their order should proceed in terms of increasing complexity - increasing demand for logical/declarative rather than intuitive/temporal expressionism.
Well... the above and 50c might get you on the bus, if the fares ever got lower.
> To start, CS theory has solid grounding in math. Without basic familiarity with combinatorics, probablity, and possibly some graph theory, aspiring computer scientists would get lost in the tangles of theory.
I dunno. You can learn most of the maths you'll ever need for CS (unless you get into crypto or something) in a couple of months. You should probably do that, but it's not like CS uses any really heavy maths.
And let's face it, CS people couldn't do a real mathematical proof if their lives depended on it. <-- troll!
> Like mathematics, it is best to study CS theory in Historic order - i.e. emergence of static computing engines -> finite state machines -> pushdown automata -> turing machines -> equivalence between language decision/recognition and solution of generic problems -> computability -> complexity...
I'm not convinced here either. A lot of that is fairly esoteric with little practical use. That doesn't mean you shouldn't learn it - it means you shouldn't learn it first, because then you'll just be going "What the hell is this shit? Why do I care?". You appreciate the theory of many of those topics much more if you've previously dealt with them in practice.
> You appreciate the theory of many of those topics much more if you've previously dealt with them in practice.
Exactly. What I was trying to get accross there is that Scheme and other languages of the same nature should not be taught first, and should never be taught as a "practical" language. Which unfortunately, my University does... to "Intro to Computers" students, no less. I feel so bad for them...
>>68
Congratulations, you have just described Java and the majority of open source, all of which fail at componentization. Next you're going to tell us "services" are for enforcing a subcription model to make everyone pay $$$.
>>67
One of the more basic differences between component-oriented and just object-oriented languages are what gets treated as "first-class". CO languages may or may not be OO, but in general, current CO based languages are also OO based.
Most of this thread show why industry has so little faith in the ability of the eduational system - NFI where they're going or what they're doing on the leading edge, 5 years behind otherwise.
>> And let's face it, CS people couldn't do a real mathematical proof if their lives depended on it. <-- troll!
But it's true! :O
> One of the more basic differences between component-oriented and just object-oriented languages are what gets treated as "first-class".
Could you elaborate?
At least with open-source, you don't have to pay through your nose to receive shit. Also, your statement sort of implies that open source software wouldn't suck if it was "componentized". I find this hilarious.
Furthermore, academia has never been about teaching the flavour of the month. You want that, you go to a vocational school. Going from one language to another is trivial for a person with a real education in programming. Going from one paradigm to another, likewise. Especially when these paradigms are so nearly equivalent to each other. You can't even seem to illustrate an actual difference between object oriented and component oriented programming, whatever it is.
Following what Waha said in >>84, I thought I might jump in here and mention my experiences to date.
I started with BASIC back when I was about six or seven years old, and while this didn't go far, it was when I first got my taste for computing, and that's stuck with me ever since. With my limited capacity at the time, I wasn't going to get far beyond simple procedural programming, and that's what happened.
Early in high school when I was eleven or twelve I taught myself HTML through osmosis and picked up some Javascript after that (but I eventually had to buy a book to understand what the '.' was doing and that was the start of OO.
Not much happened until I got to uni some four/five years later (where I started Computer Engineering). In first year we were taught Haskell (everyone hears Pascal whenever you tell them this) in COMP1A, which is a very... "pure" functional programming language. I admit it was kinda cool in ways, but it also gave me the shits, bigtime. Having a firm idea of procedural programming in my head, this was hard to get a handle on.
Second year we were doing Data Organisation, where we learnt C (what I regard as my first "real" programming language). So we did fun things with memory allocation and pointers and structs.
After that it's been microprocessors and some more hardcore bare-metal stuff. Looking back on it, I think this has been a really great path in learning programming and computing in general. The way the course has built has been very solid and you're getting a view of the whole thing as you go. C may have been invented, what, 30 years ago? There's a reason why it's still used and taught today. Simple fact is, it's relevant.
It's a wholistic method of teaching programming and comp. in general. When you understand how it all works and fits together, then you can pick up languages easily. As waha said earlier, when you know maybe three languages, learning another one is easy? Why? Because chances are you now know what you're doing, and why.
Other comments from earlier:
2. Assembler as a teaching language: Sure, but make it the teaching language for when you're teaching hardware at the same time (hardware @ the single-cycle computer level). Assembler is great fun, but be kind to their sanity and make it RISC (I like ARM).
3. Maths in Comp. Okay, I fscking hate the mathematics I'm taught. Sure, I can almost see some of it being useful, but I hate the rest of it. And yeah, I probably can't do a proof to save my arse. Besides, that's what AMN and Z is for, right? :)
>>81
Are you at Berkeley by any chance?
A lot of people complain about Scheme being taught in the CS3 course. But it's not something they picked at random. The people behind CS3 include people with degrees in education as well as CS, which is unusual. So at least they're thinking about it and they have reasons, even if the reasons are arguable.
BASIC is a great first language, but VB is a poor first teaching environment. Get them going in QuickBASIC for the coursework; encourage them to explore VB on their own if they have a mind to, and give them any guidance they want.
QB will make them think about what they are doing, as they must implement the program logic themselves. At the same time, the fact that they can apply what they're learning in QB (with some amendments) to a graphical application in VB (which they can show off to their mates) encourages further personal experimentation.
Don't forget to explain to them why you're teaching them in a crusty old environment; and don't forget to ENCOURAGE THEM to explore on their own. 90% of real world programming (100% made up statistic) is self-taught -- familiarising with interfaces to new modules, searching for and through documentation, etc etc.
Explain to them that you can only show them ways to think about programming; that they must teach themselves how to program, by using this new thinking that you are demonstrating.
Instill in them the hacker mentality: there are no impossible things; merely things I have not yet taught myself to do.
When you teach them to program independently, you don't need to teach them their second and third and nth languages; they will teach themselves, for themselves. (Subsequent programming classes should then focus on concepts, theory, methodologies, etc: the heavy stuff that's better absorbed in the classroom than from google.)
Inspire them!
you're treating students like teaching the wrong language will kill them. more important is determination on the student's part.i tried to learn java when i was eleven/twelve.it was bloody hard by myself,and it took a seriously long time,just over a year before i could do anything good,and i had no results for ages.i would suggest a baptism of fire - teaching them something practical, something built for the present like java or c++ because it allegedly rocks.however i was self-taught and had all the time in the world,different from teaching.i agree with the last guy though - the 'hacker mentality' is very good and useful.
> you're treating students like teaching the wrong language will kill them. more important is determination on the student's part.i tried to learn java when i was eleven/twelve.
As a general policy, I think we shouldn't teach any shitty languages. Java is a shitty language. Therefore we shouldn't teach it to anyone, newcomers included.
Also, I disagree that learning should be an painful experience. "Baptism of fire" makes it sound like you're in the military and your life might be on the line.
Back me up, I'm goin' in!
I'd advocate C as the first language. It's small, in that the number of reserved words and the size of the standard library are small, and these days you could teach the use of debugging tools in the same course. Not to mention that it's low level, so you could build on top of those programming 101 courses that teach MIPS assembler as first language.
Also teaches people either to not fear the almighty pointer, or to be continually scared shitless of the big bad segfault.
>>90
Both of which are good things. Seconded.
C is a bad first language. You have to learn too much right up-front before you can write code.
Certainly no more than you have to learn to use Java, and Java is a popular first language at lots of schools. Actually, you have to learn quite a bit more to use Java meaningfully.
>>92
You can learn C in little bite-size increments. Starting with your first #include directive, which is like "without it, the compiler is mad at you, with it the compiler is happy"; everything else is just a function returning an int and taking no arguments and a function that prints text to stdout. No need to go into pointers or even arrays on the first day. Integers and maybe if() and for(), if it's an university course. That %d in the printf call can remain a magic mystery until a couple of weeks forward.
Contrast with Java, where... uh... how exactly do you explain what System.out is? Or what "public static" in main's declaration means? And why String needs to be used with a capital S? Or why you need to have an object or a class to call a method? What is a method anyway? Why do instance methods behave differently from class methods? And how does this relate to what we learned about MIPS assembly in computer innards 101?
I tried to learn Verilog about a year ago. It was indeed quite difficult an experience, given that I have absolutely no experience in the low-level nitty gritty of electrical engineering. Imagine how clueless the young students are going to be when they have no concept of, say, control flow.
>>94
As opposed to most scripting languages, which start something similar to this:
print "Hello world"C would make a fine second language. It strikes me as a bit sadistic to recommend it as a first.
>>95
I'm sure those are the exact thoughts of the people who recommended BASIC as the first language.
And what exactly is wrong with BASIC? GOTO/GOSUB? Oh no, the humanity!
I have news for you, man: perl/python/ruby/et al are far more powerful than C, except for certain niche domains. A powerful language doesn't need to have a high learning curve.
A lot is wrong with BASIC. Don't take my word on it, take Edsger Dijkstra's word.
>>97
Except you don't want to teach people powerful languages as their first language. The flipside of powerful is "can't fit a cheat sheet on the sides of a coffee mug", and TMTOWTDI is a pretty much certain way to confuse the newbies. Seriously, try explaining generators to someone who doesn't understand control flow in the first place.
With C it's what you see is what the compiler will give you, undefined results, furballs and all. And that is one of the things where C++ fails it as a teaching language; how do you explain in the first few lectures that "yes, at this point this operator is called the into-the-stream operator, but at that other point it's a bit shift".
Anyway, I'm going to take your "certain niche domains" to mean damn near all of system-level software in modern Unix-like operating systems (i.e. the *BSD variants, Linux and whatever the HURD is these days).
If system-level software isn't a niche domain, what is?