|
teach Procedural or OO
my young nephew is showing some interest in programming and i think i should start him on the right path.
having say that, should i start him with procedural programming using Pascal or start him off with OO like Java or C#.
coming from learning programming using Pascal then C, i remember there is a much difficultly when i switch to use Java and C#. the mind set is different when we program in OO and when we program in procedurally.
so the question, should i start my young nephew off using OO or should i drill him in the fundamentals of the procedural way first then hopefully he can make the switch to OO when he wants to?
new_one
Monday, May 24, 2004
Go procedural. Ideally, you should teach both, and going from procedural to OO is a lot more natural than the other way around.
Egor
Monday, May 24, 2004
Are you open to other languages? I'd then bring up Python as a possibility.
The advantage is Python has a good merging of procedural and OO. It also carries some flavor of Pascal/Java, since it sort of punishes people for drawing outside the lines, but in a fairly subtle way. It's a line-oriented language, so it's not a far distance from that Pascal/Java style.
Apparently you tend towards static typing, so Python's dynamic typing would be a disadvantage. But keep in mind Pascal/Java have terrible type systems, since they do no inferencing. (Unless you find a dialect which does.)
Tayssir John Gabbour
Monday, May 24, 2004
OO is by far the best way to start. OO is a lot better way to program, as well as conceptually simpler and more likely to be useful in the long run.
Mr Jack
Monday, May 24, 2004
If your nephew is interested in learning programming and he is really smart with the computers, he can pick up a programming book and learn on his own and you can guide him on the way.
You can either start with a procedural language such as C or Python. If you start with Python, you won't be helping your nephew much with brushing up his programming skills. Since you didn't mention Python, probably you don't know and you'll have to learn it yourself too. If you start teaching him C, you'll only bore your nephew since he wouldn't be able to create useful working programs.
Now, if you want to teach him OO programming than you can go for C++, C# or Java. C++ is harder than the other two and it has the same problem as C - your nephew will not be able to create useful working programs as fast as he would be expecting - so he would probably get bored with the programming stuff.
Now whether to go for C# or Java. Let's see.
With Java, he can create Applets, desktop application and mobile phone games. It would be hard for him to set up a web server with JSP support and create web applications.
With C#, he can learn a single language. He can use the same development environment to create desktop applications, web applications, DirectX games, utilties and even network-aware applications (comparatively easier than Java). It would be pretty fun for him. He can start with boring Console applications and quickly move on to desktop applications and later create websites.
Now, why should you choose an event-driven modern object oriented programming language over a procedural command-driven hard-to-learn programming language? It's simple, if he's not a computer science student, be nice with him and teach him something like C#. Don't be boring with him either by teaching him python - he wouldn't be able to create pretty user interfaces by dragging-n-dropping controls over a form. If he likes programming, turn it into a love for programming. If he's not going to be a computer science student, don't take him to the C or Pascal path. He wouldn't be able to create anything useful. He wouldn't be able to implement his own data structures which are so much necessary for any program.
Green Pajamas
Monday, May 24, 2004
Delphi and Object Pascal! All the way. :)
You can write 100% procedural programs in Delphi, and once you've grasped that paradigm, it's very natural and elegant to make the paradibm shift to full-blown O-O. (whereas C-to-C++ is a big horrible mess)
Delphi offers an excellent event-driven RAD environment with a great class library, modern object oriented language (if you'd like to disagree, check it out first), optimizing compiler with blazing speed (virtually instantaneous builds), possibility to develop for multiple platforms (Win32, Linux, .NET), just to name a few.
YF
Monday, May 24, 2004
I have my own bias towards learning procedural programming first, and OO later, because that's how I started. Wrapping my head around OO took a little bit of doing.
Whatever language you use should reflect your own set of teaching skills. I'm in favor of a language that requires static typing, because dynamic typing can introduce some interesting errors that are hard to solve.
As for the whole "writing useful programs" argument against learning C or C++, I'm inclined to think that it's rubbish. Maybe I've been fooling myself and all the software I've written has been useless, but I was writing useful programs to solve problems as soon as I started learning C.
Clay Dowling
Monday, May 24, 2004
We wonder why we produce buggy software. There isn't even a standard way to learn programming.
Start with OOP. No start with procedural. ad nauseum
c:\
Monday, May 24, 2004
Its probably better to let him explore a bit on his own, and maybe you should focus on finding interesting projects for him to do - most kids won't be too interested in writing code that interfaces with a database, but they usually love writing games. Also, writing 2-d or 3-d graphics can give them a really solid grounding in geometry and other areas of maths and physics.
There's absolutely no point in trying to teach a kid sophisticated methodologies before they actually know why they would ever want to use them.
About to Jump
Monday, May 24, 2004
There's no standard human either. So things in Real Life (tm) can sometimes be a bit complicated, and almost always there's more than one right answer.
YF
Monday, May 24, 2004
Start with procedural. At its most atomic level, OO programming is still procedural; the procedures are just small and encapsulated. And once he gets good enough at procedural to be frustrated with its limitations, he'll be able to really appreciate OOP.
Kyralessa
Monday, May 24, 2004
I'd second Python as a good choice.
Python is a good choice because it's simple, elegant (as opposed to VB and Pascal, ahem) and good for beginners, but also very powerful, has a decent set of libraries etc. will do procedural stuff easily but has good OO (and functional) features to use later on. I think this is the natural progression really - you need to have written a few sprawling ugly procedural programs before you can really comprehend the reasons for an OO approach. First of all for a beginner should just be the satisfaction of having the computer do what you tell it to in logical steps. Build on that with OO later...
Matt
Monday, May 24, 2004
Why not Assembly? Since he is starting with a clean slate, would it not be better if he bagan 'coding to the iron' and only then move on to 'coding to the OS, with libraries'? That would help him appreciate whats really happens inside the machine and more importantly, instill discipline in him as he learns to chalk out the algorithms.
KayJay
Monday, May 24, 2004
Having said I prefer OO, I also think that BlitzBasic is one of the best introductions to programming because it makes writting games real easy, and games are kewl.
Mr Jack
Monday, May 24, 2004
I'd say give him an easy to use IDE that is appropriate for what he wants to do. If he's anything like me when I was 12, he's probably full of ideas for little games and stuff he wants to write. The first thing I'd introduce is the value of code reviews, and explain how everybody benefits from having somebody take a second look at the code. From there, I'd just let him do his thing, answer any questions, review his work, discuss his designs and introduce new concepts whenever I'd see a benefit related to what he's working on.
Big B
Monday, May 24, 2004
Obviously you should teach him Scheme, and implementing the Metacircular evaluator. ;)
(Y F) = (F(Y F))
Monday, May 24, 2004
no, no, no.... before any coding, you need to teach him design principles, how to write functional and technical specs, how to create unit tests, uml modeling, badmouthing his boss, grumbling about the previous developer, etc.....
josheli
Monday, May 24, 2004
Don't teach either at first. It's like teaching perspective
first then when teaching painting. Let the lessons
on procedural and OO arise from problems and
observations found during programming.
son of parnas
Monday, May 24, 2004
When I started computing, day one was 'this is a half adder, work out how to combine several into a full adder'. (oops, I forgot day zero: when to use binary, and when to use analogue computers).
I tried LOGO with my son, thinking that being able to draw on the screen would a quick win. Wrong. He wanted to write Quake in 30 minutes.
The approach I'd use now it to find a problem he's really keen to solve, then choose a suitable tool (Python, Python, Python!) and let him take it where he wants to, answering questions as they come up. Don't bother with any particular OOP/procedural pedagogy.
bah humbug
Monday, May 24, 2004
It's just a passing fad. He'll burn out quickly when he realizes how much work it takes just to do something simple like put a black dot on the screen at the mouse cursor when you click the left mouse button.
So if you want him to stay with it, encourage him to keep his expectations low and find things for him to start with that will give quick positive feedback.
Should be working
Monday, May 24, 2004
The first language doesn't matter.
Choose an intersting starter project -- that is what matters. Then, select the language that's appropriate.
igrek
Monday, May 24, 2004
Quick rule of thumb? Whatever's fastest and funnest for writing GAAAAMES. :)
You don't mention age, but you might try looking at some modern Logos (http://en.wikipedia.org/wiki/Logo_programming_language) or Python, depending on age and ambition. Compiled/BDSM languages are complete overkill: ease of use and immediate feedback/reward is what sells it.
<musing>
Was looking at Boxer (http://dewey.soe.berkeley.edu/boxer/) earlier today (been setting up an old PC for young niece and nephew and throwing in various creative apps - drawing, music, 'programming' - along with the usual games and education apps); looks like a superior take on the Logo philosophy, with code blocks being visually represented and manipulated(?) as actual boxes. Unfortunately it's classic MacOS only and doesn't look like it's being actively developed any longer. Would be interested if anyone knows of anything similar though.
I'd love to see something with the approachability and immediacy of the early 80's home micros (minus the spaghetti BASIC of course). There's a wonderful clarity to having the entire programming language printed across the keyboard in front of you; each key generating a complete language keyword in the proper location.
</musing>
As for the OOP question, I'd suggest teaching the minimum amount of technology needed to put programs together, and focus on developing understanding of why some ways of putting programs together are better than others (e.g. deliberately using procedures to give shape and structure to a program as part of the process of methodically solving one problem at a time, rather than as a band-aid retroactively applied to spaghetti soup).
has
Monday, May 24, 2004
Tip: Ask him before you start helping with anything.
I'd facilitate his playing around with programming.
I.e., find out what HE wants to do and try to HELP him by answering questions. It's very easy to start lecturing (with the very best of intentions).
You can slowy introduce good programming techniques if he can recognize that it will help him achieve HIS GOALS.
I.e., if he wants to write progams just for him, then the UI probably doesn't matter to him right now. But if he gets lots of bugs, you might teach him troubleshooting or testing.
Mr. Analogy
Sunday, May 30, 2004
 Recent Topics
Fog Creek Home
|
