|
Because those who cannot JOIN tables should wait tables 
|
|
|
|
|
|
The trouble with all these languages is that they're grossly unsuitable for teaching anyone anything: they all start off at an advanced level. Students should be taught Pascal first - or Algol-60 - and when they've got the hang of that (and when they can actually produce working algorithms), then teach them machine code and assembly language - so that they actually understand what's happening... and then teach them something on this list. And Forth - just because they should understand something completely different.
C# is a problem: try explaining to a beginner student why everything is a class, and what instantiation means, and so forth. C is a problem: explain to a student why they have to allocate memory for things and then dispose of it, and why a ten character string occupies eleven bytes, and what a heap is, and so on. Functional programming is a non-starter for a new programmer. JavaScript (or anything else browser-based) is a complete waste of time: it's something which is impossible to teach without first teaching the entire DOM structure and so forth: you spend more time making concessions to bugs in browsers than actually doing anything useful.
|
|
|
|
|
Well, it shows that it's not a good idea to start teaching a programming language without covering some fundamentals first. For example, to explain why everything in C# is a class, you have to tell people about object oriented programming, what it is and how it works. The same is true for all the other languages. I'm not sure if that means you have to start at the bare metal level and let them write assembler code, but it would be a good starting point to understand how a computer program works and how much of that gets hidden by higher-level languages.
|
|
|
|
|
I did it by covering various languages at the same time: Algol-60, BASIC and Assembly... this way each language made the others make sense... and of course Algol-60 makes Pascal, C, C#, Java and all these other things make sense since it's their ancestor...
|
|
|
|
|
I strongly disagree with your reasoning for why C is a problem. All the things you list are not only things programmers need to know, but things that will bite them in the behind regularly, even if they use a language that allegedly handles all of that stuff for you.
FWIW, my first programming class was Assembly, on 8080 workstations with an octal keypad and 3 sets of 8 LEDs for output. Pretty much as primitive as you can get, but it gave me a foundation from which the "problems" of C were easily grasped.
|
|
|
|
|
You're missing the point. Of course programmers need to know these things: they just don't need to know them as soon as they start learning to program. Don't you think that learning how to think as a programmer should come first, then learning how to make concessions to the machine and the language should come once you've got the basic hang of things? Why should it be necessary to learn this stuff on the first day? It discourages a lot of people from continuing.
I've programmed things like your 8080 machine, too: MK14s and stuff like that: I've written entire enterprise-level solutions in 8086 Assembly language, back in the days when nothing else was fast enough -- it's not as though I don't know what I'm talking about, or that I'm somehow ignorant of how a machine works... but psychologically, most people just don't respond well to being thrown in at the deep end of, say, memory management, when they don't even know why they're thinking about memory in the first place (yet).
|
|
|
|
|
There isn't a need to teach what is class to beginner.
What they need to know/play is:
Console.Write("May I know your name: ");
string myname = Console.ReadLine();
Console.WriteLine("Hello, " + myname);
Console.WriteLine("Welcome to C#");
Console.Read();
Sooner and later, they will know what is Class is all about.
Teach functions, and this will arise their interest very quickly.
Once they have fun in the functions, they'll start to love the language.
and then learning the "Grammar" will not as hard as if the "Grammar" is being taught first.
You can always skip teaching "Using", "Class", "Constructor" to beginner.
Learn "What is Class" later.
modified 29-Oct-14 7:09am.
|
|
|
|
|
Right, but it's a horrible way to start. You have to tell them to ignore the fact that it says "Console" all over the place, and that they're not equipped to understand it yet. Then you have to explain why ReadLine and Read have to have parentheses on them: they can't write a single line of code, but they already have to learn how to parameterize void class methods, without knowing what a class or a method are? There's no way this stuff is going to stick in their head without their understanding these things, because if they don't, it's all just arbitrary randomness.
|
|
|
|
|
Try to recall how you learn English in the first place?
Do we learn the Grammar first before we can speak English?
For example part of speech, present tense, past tense, etc... etc...?
No, we learn it by repeating how others say.
We learn the grammar later.
This is same as learning programming languages.
|
|
|
|
|
|
I agree with you. Typically, you want to present primitive types, keyword, conditional and looping statements early. At that point everything can be written inside main function.
Afterward, you might present some existing and useful classes like list, string then present function, classes and then OOP.
You cannot learn everything at once and it is perfectly valid to use Console.WriteLine as a black box at that point...
Philippe Mori
|
|
|
|
|
Totally agree with you 
|
|
|
|
|
Machine Code for all!!!
Then they'll value whatever language you let them dev with (even COBOL!)
--
The trouble with people,
is that they want to hear only what they want to hear.
|
|
|
|
|
I chose multiple but wish I could have ranked them.
1 - javascript
2 - Java
3 - C#
4 - C/C++
unfortunate to see my first love (c/c++) fall to the bottom but even I find fewer reasons to use over others. javascript is fist only because it is something that requires the least setup and gives kids instant gratification.
|
|
|
|
|
I agree with some of the other posters, any specific language is just a tool, and tools change over time. What is critical for a programmer is the ability to take a problem and translate it into working code.
Given that most of the world uses some form of procedural language (operative word "most"), I would opt for one of the "C" variants, or JAVA as a starting point. Once the basics of programming have been instilled, then there needs to be classes on data structures, algorithms, computer hardware elements for those students with a deeper interest.
Using computers is now a requirement for many, many jobs, so having some understanding of what makes them work has to make using them a little easier. However, few of the jobs using computers require programming skills, so forcing high schoolers too deeply into them is not needed. It would be much more useful to teach them basic financial concepts that will aid them no matter what job they end up with.
Dave Legg
|
|
|
|
|
Thus Pascal. It's simply the best language for teaching. You can mutate it into Delphi after a while, then look at the .Net side of it, and then sidestep into C#. Java is a waste of time: C# is what Java should've been.
|
|
|
|
|
Pascal is an option, it's not a language I really have any experience with.
I would not discount Java so quickly though. It has the advantage of being easily obtainable and widely used. The latter makes it easier to obtain assistance which can be critical when starting out.
It is the second most popular languange next to C according to one site http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html[^]
C# is really a Windows based product, so if that is the environment you have, it's fine.
As an intro to programming, most any procedural language would be quite adequate.
I think the thing to remember in all this is we are talking about "new" programmers. The finer points of memory allocation, heap usage, etc. are meaningless when you are talking about simple "hello world", "bubble sort" and such programs. What is important is that they can make something happen quickly and simply and don't get bogged down in details that are not essential to the problem they are trying to solve. Once the basics of programming have been taught, it's time to concentrate on data structures, algorithms, etc. Having them use a different language actually (IMO) helps to separate the logic of the solution from the details of the language.
As with any profession, you have to start with the basics and build up to the current state of the art. In my opinion, being a good programmer has little to do with what languages you know, it's about solving problems to the best of your ability using the tools available.
|
|
|
|
|
Hmmm... well, Java's OK at first, but then you start having to make so many concessions to the virtual machine, then trying to figure out why it doesn't work half the time: to me, it comes under the heading of one of those bitty languages which is only half there...
Pascal was designed specifically for teaching, and is thus amazingly less write-only than most languages: Borland got hold of it in the early '80s and added object orientation; it then morphed into Delphi in the '90s, and became event-driven and so on; finally, it became a .Net-aware thing... so you really can go all the way from the 1960s to today with it.
For me, anyway, if you're going to teach programming then you should be teaching programming, not teaching all about why a machine doesn't work, and which excuse to use at any given point for why you have to do [this inexplicable thing] when you want to do [that]; Pascal is very good at avoiding all that nonsense by being a pure, beautiful language which doesn't require a framework behind it (until you get to the Windows/.Net implementations of Delphi - at which point you should be pretty good at it already). So if you want to teach programming as a skill involving designing algorithms and representing them as programs, then there really isn't a much better place to start.
These days, though, Pascal is useless as a career skill (unless you find yourself somewhere which insists on using Delphi); I guess the real question is how long you want to take to learn to program: do you want to do it properly, or do you want to do it so you can make money very quickly?
I was lucky: I started early (the late '70s) -- so I had the luxury of being around at a time when languages like Pascal and Forth were used for real applications: I even got to write a few systems in pure assembly language -- that just doesn't happen any more. I feel sorry for new programmers today: they have to start at the end, and then try to find time to develop the interest to work backwards.
|
|
|
|
|
I chose Python. It is a very flexible language with OO properties like C++ without having to deal with a compiler, which I think would tend to get in the way of teaching programming principles. This, of course, should just be used to demonstrate more rigorous teaching of algorithms and recursion, etc. Then say the other half of the year can be spent on web frameworks. PHP, JavaScript, HTML, CSS can be used. I think all this can be taught in one school year, since not a lot of time will be spent on setting things up and they can jump right in and start learning. Finally, a couple of weeks at the end of the year can be spent on getting into the weeds with an assembly language and get closer to the hardware.
|
|
|
|
|
Despite what many of us may think, COBOL is going to be around long after many of the others on the list have disappeared. There are literally millions of lines of COBOL code in production use, including government, banks and multi-national corporations.
Migrating to other technologies is likely to be cost prohibitive, therefore these aforementioned institutions are going to need people to maintain these systems.
That's a fact, like it or not.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
|
|
|
|
|
Possibly true, but I see no reason why we should teach it to kids in school because of this.
Certainly no new (sensible) projects will ever use it.
Regards,
Rob Philpott.
|
|
|
|
|
There are more lines of COBOL code in current production use than possibly all other languages combined. I think that's a very persuasive argument.
All those systems require updating with new features as well as fixing bugs.
With so many lines of production code, does the industry not need to address the shortfall in skilled developers who can maintain these systems?
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
|
|
|
|
|
Dominic Burford wrote: There are more lines of COBOL code in current production use than possibly all other languages combined
That's a wild claim. Do you have anything to back it up?
Regards,
Rob Philpott.
|
|
|
|
|
https://scs.senecac.on.ca/~timothy.mckenna/offline/COBOL_not_dead_yet.htm[^]
Quote: Because there are more lines of COBOL in production than all other languages combined; Gartner estimates about 180 billion lines. "By some estimates, the total value of the applications residing on mainframes today exceeds US$1 trillion. Most of that code was written over the past 40 years in COBOL."
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
