"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
> 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?
>>100
Elevator controllers.
> Except you don't want to teach people powerful languages as their first language.
Why the hell not? First you (I assume you're >>94) argue you can learn C in "little bite-size increments", now you claim you shouldn't do such a thing in another language?
Regardless, the relevant issue here is as thus: it has less to do with the power of a language, and more with its learning curve. And you can do a lot in Python without using its generators. How much can you do in C without pointers? This isn't even the same ballpark...
> damn near all of system-level software in modern Unix-like operating systems
May I be the first to point out that most of said system-level software need not be written in C? Indeed, the world might have been better off if a more powerful language had been used (and a less shitty library that thinks we're still in the era of the PDP and VAX). Think of all that wasted productivity.
Furthermore, >>100 is bang on. When was the last time you looked for employment?
Pascal reeks of old, but I'd still teach Pascal first. It's simple and straight to the point of the first paradigm one should learn - traditional/imperative/structured programming.
Then I'd move on to C and see things from a low-level standpoint, and from it I'd go to Python which is a pretty good, clean language IMO.
I just wouldn't teach Python first because it deals with more complex things (objects, references, lists, etc.) which you are bound to stumble upon if you do anything with it. Besides, people might think less of it if they see it first, or they may never discover the good stuff it has.
As for OO, no OO for starters, that's a bad idea; and much less Java, which is a crappy language with a crappy API that's going to get students nowhere.
> How much can you do in C without pointers?
Without pointers, not much. Without pointer arithmetic, lots and lots.
It's not really pointers that are hard. It's the pointers-to-base-types and pointer arithmetic that is hard. You can teach a whole lot by just ignoring the existence of these things. As long as you treat pointers to system structures and objects as opaque types, you've basically got what Java has, and nobody says Java is too hard because it uses object references.
Sooner or later you have to learn these things, but you don't have to learn them right away. The learning curve shouldn't suffer if you don't go our of your way to make it hard.
> Without pointer arithmetic, lots and lots.
In C, [] is pointer arithmetic. Would you live without arrays?
Pointers aren't hard, but they require you to be agile enough to think of them, and have pretty clear concepts of variables and memory organization. For example, if somebody thinks ***a is more complex than **a, he needs to improve on this.
>>103
I think you should really have a functional language as the second or third. Teach some easy scripting language like Python or JavaScript as a first language, then C and a functional language as the second or third. That sort of balanced mix will get people to be able to think about programming from a variety of perspectives.
That's what it is, but you don't have to know that. You can pretend it's just a magic array index operator, until you reach the point where you're ready to deal with it in more detail.
That sort of approach will also mean each new language is as hard as the first one, since you can't carry over most of your earlier knowledge. If you're smart, you'll probably take it in your stride, but if you're smart you're going to learn this stuff sooner or later anyway. If you're not so smart, you're just learning a bunch of stuff that won't really benefit you and that you would be better off without.
Of course, I think functional languages are largely a waste of time (except maybe as a warning as to why you shouldn't let failed maths majors do CS).
Newsflash: Learning can be hard. Programming is a hard subject. Learning a hard subject is extra hard. Some people will have trouble with it, sure, but they should maybe pick an easier subject.
And really, I do not think you know what you're talking about when you dismiss functional programming. Maybe you haven't worked on projects big enough to understand the need for abstraction? ... Sure, Haskell and Scheme are not the world's most practical programming languages, but techniques from functional programming are invaluable, and they can help you write clear, effective code even in C.
>>106
To tell you the truth, I'm not terribly sure what's a better idea - to start from a more theoretical point of view then build downwards or to start with a more low-level point of view then build upwards.
However, I wouldn't call Python simple for a few reasons; I'd rather start with JavaScript.
I dismiss functional programming for the one single reason that it is not practical. It doesn't matter how mathematically elegant it is, if you can't use it to write real-world code it's just theoretical wanking. But let's not start up that discussion again - look through some of the older threads for more on that.
>>110
Though it wouldn't be a bad idea to teach it. It's a bit of an enlightening experience, and you can use some functional constructs in real world, practical, down-to-Earth multiparadigm langauges such as Python or Ruby.
Then wouldn't it be better to teach how to use those constructs in those languages? A lot of students I know don't get enlightened from learning a functional language, they get annoyed, and will want nothing to do with those afterwards.
There's nothing inherently impractical about functional programming. It's quite possible to write "real-world" code in a functional language just as easily as it is in a procedural one. Or rather, it's just as easy in a language that's mostly functional. Of course it's ridiculous to program in a completely functional way, just as it's ridiculous these days to program in a completely procedural way. There's lots of benefits to programming functionally, as long as you don't adhere to the paradigm beyond all reasonable logic.
But this brings up an important point regarding attempting to teach functional programming: There's no reason to use a language like scheme or haskell if all you want to do is teach a paradigm; you can program functionally in python or perl too. Maybe not to as great a degree, but much more than one might expect.
On the flip side of that coin, though, is the fact that so-called functional languages like lisp don't adhere you to a functional paradigm either. You can program procedurally in lisp if you want; actually, you can pretty much do anything you want in lisp. That's one of its perks. Moreover, there's plenty of real-world code written in common lisp, and enough libraries and support that it's just as easy to write actual code in lisp as it is in perl or any other language, for the most part. So as far as functional programming goes, if you're concerned about practicality then you're thinking about the issue in the wrong way.
No, I agree entirely that functional programming methods are useful in languages that aren't purely functional. It's just the purely functional languages that I can't stand, because they elevate dogma above everything else.
C++ is the way to go in 99% of all real world applications. Learning script languages isn't nearly as useful.
If by "real world applications" you mean "GUI apps under Windows", sure. But that's hardly all real world apps.
>>115
Has never been a sysadmin.
C++ really is a pretty bad language. It's so big that people normally learn a subset of the language and program in that. Which can work great, until you try to collaborate with other programmers, and they use a different subset. I won't deny that C++ is useful, but the situations where you need it are becoming less and less, and I think that's a good thing.
>>115
Eh, what? A good number of my real world applications are indeed written in C++, but I'm also running lots of low-level software written in plain C, and lots of high-level scripts and applications written in PHP, Python, Perl, and ugh Java.
>>115
moar liek 30% amirite? i speculate that 30% is taken up by c programs, 20% is taken up by high level scripting/interpreted languages and the other 20% taken up by other compiled languages.
I have no idea what language should be teached, but I definitely know which language should be learned first: one you can start using right away, where you can experience your first successes one hour after starting fooling around, where experimenting with stuff is easy.
That means:
Obvious candidates are Python and Ruby, and both have the added advantage of being used in the real world.
>>115
Definitely, because unlike your time, these CPU are really expensive!
Going only by your description, Visual Basic really is a much better choice than either of those.
Compiled languages don't necessarily constitute not being able to learn quickly and be able to reach success within an hour.
For example, QBasic is a compiled language, yet, IMO, easier to gain quick success than Python or Ruby.
>QBasic is a compiled language
But QBasic progs could only be run from inside the QBasic IDE, no? I don't think this truly counts as compilation, in the sense that it doesn't build a stand-alone application.
>>122
I think there's too much magic involved in those visual languages for a beginner to feel that he makes things happen, to understand what is going on.
>>123
I shouldn't have said "no compilation", more that it's important that the process is no more complicated than write and run - no setup before, no waiting after.
>>124
QuickBasic can compile. They're probably thinking of that.
I was of course not seriously suggesting Visual Basic, I just wanted to see what argument you would use against it.
You did say "As high-level language as possible". But then you dismiss Visual Basic as too magic. But isn't all high-level constructs magic? Are you sure you don't mean "suitably high-level", in that case?
"I'm against Visual Basic, now I just need some arguments against it for every practical purpose"
>>127
Yes, I should have stated my idea without big words. Basically, I think that for a beginner, it's important to feel in control.
I think that when you run a small script that writes something to a terminal, you feel more in control than you'd feel displaying it in a window using a visual language and its impressive IDE. (even if a lot is involved in displaying stuff to a terminal - it's purely on the psychological level)
Of course, I'm not arguing that using a GUI is a problem, only that keeping things simple is good because the learner feels in control.
But of course the best argument against VB is that it's a bad language that will teach you bad habits.
Picking up a language when you really need it is easy once you can already code, so I think that for a first language quality is more important than real-world usage, and choosing as a first a good language that is also used in the real world is better since mastering it will be a good investment.
My opinion is to remove the barriers to entry and needless frustrations. As I said in >>121, it's not that good an argument for what language should be teached, but I think it makes sense for which language somebody should decide to learn first: making the experience painless keeps you motivated.
>>128 i'm support vb but in back i hate them
I am this close to issuing one of our very, very rare bans for you.
Not only do you post shit in every thread, start new useless shitty threads, but now you are impersonating other posters.
Stop it NOW, or face the consequences. Understand?
>>102
I can make my argument well enough without your strawmen, thank you very much.
My point was that pointers, though much maligned in this limpy-wristed era of Java and oodles of other heavy leather mittens languages, aren't that hard to teach given an audience that is acquainted with something like MIPS assembly. In fact to someone who knows what a memory address is, a pointer is just a hint for the compiler to produce code that offsets the pointer in a type-specific way. Consider that many universities teach assembly to EE/CS students before they go into higher-level languages.
It's not that I don't see the utility of having a language like Python. But teaching something like that to a student without making clear what the correlation between machine instructions and programming language constructs is only serves to produce a class of people who prefer to think of e.g. compilers as magic and consider the use of a debugger something that only gurus have the skills to do; if it didn't work when they typed it out from the Great Big Cookbook of Black Magic then it's never going to.
What's the better way to teach someone to program computers effectively, then? Top-down, where you tell him that references are magical and exceptions Just Happen and generators are deep magic for when you grow up (close your eyes and think of England, and don't have too much fun because God is watching)? Or bottom-up, by letting the students figure the hows, whys and whats of abstraction out for themselves (or not, in which case there's always a market for COBOL grinders...)?
This all reminds me about a post on some forgotten message board about a young programmer who wanted to get into x86 assembly but was concerned that he might permanently fuck up his computer by accident. He explained that he had read somewhere that this could happen if one wasn't careful. Perhaps something like this is going on with pointers, today? "Ooh eek it's scary, it's frightening, it's something that Sun says is evil and outdated and hello, 1994 calling, they'd like their pointers back!".
(And sorry about the necropost.)
> aren't that hard to teach given an audience that is acquainted with something like MIPS assembly
Which implies that they learned MIPS assembly earlier. That conflicts a bit with teaching C as a first language.
> Consider that many universities teach assembly to EE/CS students before they go into higher-level languages.
EE? I wouldn't be surprised. For what they do assembly is already a fairly high level.
CS? I'm not familiar with any university teaching assembly first.
> He explained that he had read somewhere that this could happen if one wasn't careful.
With good reason, I'd say. I don't recall MASM and TASM coming with libraries, which left you with several hazardous options.
So you want to write to files, do you? cue evil laughter
> > He explained that he had read somewhere that this could happen if one wasn't careful.
> With good reason, I'd say. I don't recall MASM and TASM coming with libraries, which left you with several hazardous options.
> So you want to write to files, do you? cue evil laughter
it's still nearly impossible to permanently fuck up a computer with software. and in those rare cases where it is possible, it's usually because of a hardware bug.
Well, there was the legendary destruction of monitors. In 1994 there were probably still a few vulnerable ones floating around. Having said that, yes, you're right.
My main worry when fooling with assembly was destroying my data. Fortunately it never happened, although I did end up with a non-booting machine several times.
C, just the cross-compatible stuff...If they learn BASIC first, they won't go back, I'd know...
Two problems here. At least.
1st. Students shouldn't be buried. It's inefficient & demoralizes 'em. This implies smallish lang, smallish ref doc, good tools, eg an IDE. Rules out trad bare editors for command line save/compile/debug/edit... cycle. The Stockholm syndrome may demand we make 'em suffer, but computing is too important for us to indulge.
2nd The lang chosen should not teach bad habits. EWD has a real point. LISP's littered with parens, APL is a terseness too far, & Forth requires simultaneous concern w/ contents of the stack & much higher level issues like getting correct information to (or from) disk. Java is so careful it's a feather pillow -- you're buried in fluff, teaching newbies bad expectations. Ditto many of the special purpose languages, eg for Web work. C's syntax is ad hoc and confusing (so's PERL), and pointer artihmetic (as in C) is a bug farm. C was built for a group who used it were the intellectual peers of Thompson and Ritchie. Few of us are, and no students can be expected to be.
3rd Don't force teachers to reinvent wheels, eg first class teaching materials. They should already be available. Algorithms are a central issue in coding, and part of teaching a first lang should be an appreciation of algorithm design and evaluation. The lang should'nt be so difficult algorithm structures and mechanisms are obscured.
MUMPS, PILOT, LOGO, are all small, but too special purpose or too unusual. APL, Prolog, Simula are too far from the mainstream to carry over much to actual problems. C++, Ada, PL/1, Smalltalk, and Java are too large for a first lang. Intercal, and other Retro-Computing Museum wierdies are only for the self-masochistic; sort of like COBOL and Fortran. Maybe as comic relief? The functional langs (and partial ones like LISP) are too exotic for a first lang, even if they are theoretically cool. Assemblers (for any CPU) are too detailed to be even partially plausible. Even MIX. One of the BASICs might be adequate (I think not VB in any form), but they tend to have some specialized feature that's been over stressed and so aren't very general purpose.
I'd suggest Modula-2. There's a truly superb text, by KN King, in print and in use for a very long time. A very large point in most teaching situations. It's a small lang (the Modula-2 Report is slim, was specified in BNF (a chance for some teaching about lesing/parsing), and has no obscure syntax like C's operators. Obfuscated code is next to impossible; students won't acquire bad habits in the Dijkstra EWD498 sense. Yet it has both pass-by-value and pass-by-reference (w/o going thru memory mapping/allocation/deallocation; none needed to make a pedagogic point), and has access to bare hardware if needed to show device register operations. Data types offered are fine to illustrate programming interaction with the gritty reality of underlying bits. Both are good things, in some intro courses and for some purposes. And it has a sort of multi-programming (the coroutine and monitor provisions) which can be a useful entry into teaching a bit about concurrency. This will help introduce processes, threads and such, if needed.
If Modula 2 is not on, perhaps as insufficiently OO, try Oberon (or Oberon 2). Full OO, just not the Java, C++, or Smalltalk way. The Oberon Report is much smaller still, for those concerned. Oberon and its relatives are almost as clear in their code (though a newbie can twist anything into a pretzel). Lots of free versions, and even an entire operating system/lang/utilities collection for Intel as well.
My favorite term-long project is to require students to read Mythical Man Month (Brooks) to inject some reality, and to translate most of the code in Software Tools (1st RatFor edition) into the lang they're learning. Groups work on diff chunks to allow the whole thing to be done in a term. With more care and thought, in two terms. When they're done, or as extra help, I have them implement/compare some of the algorithms in Sedgewick.
You're forgetting one incredibly important thing: Nobody wants to learn something useless. It doesn't matter how educational it is, if you can't make "real" programs in it, people will complain non-stop about having to put in the effort to learn something they can not use later on.
>>139
Yeah, agreed. I was going to post, "But hey, CVSup is written in Modula-2", but it turns out that's Modula-3. (http://www.cvsup.org/faq.html#notc)
>>138
I don't understand your "buried in fluff" complaint. Explain?
Ignoring that one, what about Lua (http://www.lua.org/)? It's simple, approachable, and has real-world use as an embedded scripting language.
>>140
You'd think the garbage collector would take care of all that fluff.
I'm guessing Lua, Python, etc. were covered by "many of the special purpose languages." Is 'sane programming languages don't make the coder deal with memory management' a bad expectation?
I don't think that's a bad expectation. It's important to know how memory management works and many of us in this thread have agreed that C is a good second or third language. However, for first learning to program, one should not have to face the bookkeeping.
>>138
your comment about no student should be expected to be the intellectual peer of someone or other is short sighted. better by far to aim too high and fall short than to aim too low and never advance past success.
the best intellects in the world had to learn once upon a time; you'll never add to the pool if you go around preaching defeat before anyone even starts.
>>139,143
If the goal was introduction into thinking in computer logic, then languages that give the user quick and satisfying results such as logo and squeak and kid's programming language are great. Languages such as Pascal are fine too. If the goal was to teach them to think in terms of computer science level algorithms, then you use a lower level language along the lines of C. If the goal was to teach the person how to become a general purpose programmer, eg. a junior level programmer of a company IT software project, use a higher level language that assists in not wasting the programmer's time by not requiring them to think in low level. Languages such Ruby or C# or Python are great for this.
> it's still nearly impossible to permanently fuck up a computer with software. and in those rare cases where it is possible, it's usually because of a hardware bug.
Unless you are using a BIOS designed by some kind of wacky monkeys, accidentially flashing the BIOS is pretty much impossible.
For me, it depends on what you're teaching: to program, or about programming. In teaching to program, there is a huge class of languages (including C/C++, Java, C#, Python, Ruby, etc.) which offer variations on the same experience (mutable state, strict evaluation, etc., etc.). I'd like to think that my pedagogy will be more important in teaching my students to program than the tools we use.
When teaching about programming, on the other hand, I think that there are significantly fewer options. Depending on the school, many of the students won't have any experience with code that isn't imperative/OO. If you're going to teach about programming (an introduction to PL theory, for example) then you either need an extremely rigourous and flexible language, or you need lots and lots of languages. For me, I'd choose to go with Haskell (though Scheme [witness: SICP, the Reasoned Schemer, etc.] and CL will be able to handle all of the same techniques and content, just with much reduced safety, and Oz is perfect for such an approach [witness: van Roy and Haridi, 2004. Concepts Techniques and Models of Computer Programming.]) for the sole reason of monads. Implementing imperative, OO, non-deterministic, and logic programming yourself really helps get to grips with their intricacies. Furthermore, many students won't have used a language with a strong type system before (no, C/C++, Java, etc. don't count); the main reason people rail against type-checking is that their only experience is of Java's rather pathetic type system. Algebraic data-types, pattern matching, type-classes, and type inference give a much more compelling case for type-checking than anything from the C/C++, Java, etc. world.
To link this back to the original question, I don't see why the first case (teaching to program) and the second (teaching about programming) must necessarily be distinct. I plan to try a "fundamentals" approach to teaching programming (in Haskell) next year if I can get a good set-up and presentation figured out in time.
> I'd like to think that my pedagogy will be more important in teaching my students to program than the tools we use.
To an experienced programmer, switching languages is like switching pants. One easily forgets that this is most definitely not so for a novice programmer, and the particulars of the language are indeed very important.
As for the rest of the argument, I'd opine that functional languages are great for teaching functional programming. For teaching about programming in general, I am pretty sure your first option of using many languages is the only really useful choice.
>>149 DQN is that-a-way ->
Start with C or assembly language to show people how the machine actually works on the lowest level, then show JAVA to see a language on a very high level [good for software engineering concepts], then introduce various popular languages like Python, Perl, etc..
I wouldn't call Java a particularly high-level language...
it wouldn't call you one either