|
harold aptroot wrote: Do I have to pick one of those?
Nope.
harold aptroot wrote: I'd start with assembly. It's structurally simple and easy to learn incrementally. "Literally a list of instructions" is the simplest model to get used to.
That's a really good point -- I've always thought that a person learning programming should begin with what the processor is doing.
Marc
|
|
|
|
|
Marc Clifton wrote: That's a really good point -- I've always thought that a person learning programming should begin with what the processor is doing.
Than one can also argue that before learning what the processor is doing, they should learn about how it works and digit circuit design (AND gates, OR gates, Multivibrators, FlipFlops, FIFO, LIFO, etc...).
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|
|
Marc Clifton wrote: I've always thought that a person learning programming should begin with what the processor is doing. I think that makes C a nice learning language. It is based on a fairly low-level processor abstraction.
Of course, it is like teaching your child how to cut their food using a chainsaw...
Software Zen: delete this;
|
|
|
|
|
Dude, I can't tell if you're serious. Because if you are, I'd say, "YIKES!" (and more below).
If you're not, then I'd be happy to pile on with more helpful suggestions, like "Forget Assembly. If you really want to dip your toes in the water you should start out with machine language -- go straight to the binary, so you can really understand the way the computer thinks!"
...And if I really have to explain my "YIKES" comment...
Assembly is a marginally useful language to explore for advanced coders. It is absolutely NOT what beginners should be introduced to. That's like giving entry-level math students a calculus book.
Seriously. Yikes. Please never teach an intro course.
|
|
|
|
|
I actually am serious. I don't disagree about the low relative usefulness. Of course assembly is not a convenient or easy-to-use language.
But none of that matters. At its core, assembly is simple. Literally a list of instructions, that is something everyone immediately understands. The syntax is trivial too. What people have trouble with is decomposing problems into the right parts, which is a bit harder in assembly. But you can jump right in. Other languages suffer the problem that in order to do anything (or even read anything), a lot of pointless syntax and other magic incantations have to be learned.
kdmote wrote: Seriously. Yikes. Please never teach an intro course. Too late. I'm a teaching assistant for a computer architecture course. First year course, straight to assembly (architecture too, of course). They also learn Java in parallel, where they get confused about declarations and types, many stay confused until they take a course in compiler construction. Almost no one is fundamentally confused about assembly, they just find it hard to use.
|
|
|
|
|
kdmote wrote:
That's like giving entry-level math students a calculus book.
I would strongly disagree. It is much more like teaching them the basics of arithmetic by hand before letting them use a calculator.
|
|
|
|
|
Don't agree... There is a reason people don't use GOTO in c anymore... Assembly is a whole bunch on GOTOs with some non-portable code.
"Program testing can be used to show the presence of bugs, but never to show their absence."
<< please vote!! >></div>
|
|
|
|
|
Yes, but that reason was that it doesn't scale to large programs and is in general hard to use, not that it's hard to learn or to at least understand the fundamentals. The point of a first language is not writing large programs in it so that aspect doesn't matter.
|
|
|
|
|
If someone were learning to program I would recommend they start with Scratch - that way they get to understand the mechanics of programming (loops, variables, conditional branching) before they get bogged down in syntax.
|
|
|
|
|
Duncan Edwards Jones wrote: with Scratch
I actually wish programming was just like that!
Marc
|
|
|
|
|
|
I'd go with C.
It helps a lot understanding the basic flow of instructions, it enforces the need to think to the solution before writing as many typed languages do. It's clean and logical and helps keeping the clutter to the bare minimum until it is understood what inclusion of headers do - and the meaning of definition, declaration and modularity.
It allows to learn programming by steps, seeking new instruments when needed instead of providing with a messy garage of instruments with varying degrees of necessary skills to be used properly - the contrary of Java and VB6 (my first programming language excluding a brief and failed encounter with GW-BASIC) for example.
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
"When you have eliminated the JavaScript, whatever remains must be an empty page." -- Mike Hankey
If a coffee bean is between the Earth and the Sun, is it a Java Eclipse? -- Sascha Lefèvre
/xml>
|
|
|
|
|
Marc Clifton wrote: Which would you prefer to teach to someone new to programming?
To teach someone programming then a strongly-typed OO language. That will teach concepts that can be translated to any language, and even adapted or "down played" for languages like javascript etc where there is a knack to keeping in mind that something might not have a fixed type. I think it's easier to go from typed to non-typed than the other way.
If you learned using javascript you're going to start something like c# and make everything "var" and wonder why nothing works (although people do that anyway), or try and implement a bad design you've learned from non-typed languages and end up with some horrible implementation to circumvent the languages strongly-typed nature. For example how many times have you seen questions in QA where people using c# ask things like
"I'm creating a dynamic form and I might have as many as twenty textboxes and if I do I want my class to have properties Textbox1, Textbox2, then I want to loop around those properties like this
for (int i = 1; i < 21; i++)
{
string text = obj.Textbox + i;
} "
They end up approaching problems from completely the wrong angle.
|
|
|
|
|
I agree. Strong typing, although initially confusing when first encountered makes for a clearer understanding of things in the long term. It's also easier to temporarily unlearn it for scripting languages, than to go the otherway around.
|
|
|
|
|
My kid has taken some classes in writing mods for Minecraft (Java).
MIT uses Python for its non-programming students.
One of the main reasons I bought a MicroVAX is because VAX BASIC still has interactive mode. Just how I was introduced to programming in 1983.
Personally, I would avoid scripting languages and OOP-only languages.
|
|
|
|
|
I would go with Compiled languages. Possibly with native ones like C/C++.
The process of Compile / Build to obj. Make to EXE everything goes with an edible flow. You don't need to learn a new framework to understand these.
And ultimately, to explain how these Exe's get executed on a CPU, you can explain it fairly straight, without the circus of JVMs/ Run times etc.
Having said all these, The ducktypes? There's nothing much to explain, you could just say that the last part of the pervious model is getting done line by line. Basically an Interpreted ones vs Compiled ones.
If you just want to learn Programming language, I would go with Scripts/Interpreters. The whole developement set up is not required. All you need is a browser and a notepad to start with.
But if you want to teach the whole of it, then we should not for the duck-type ones as you call it. Compiled ones do best there.
Starting to think people post kid pics in their profiles because that was the last time they were cute - Jeremy.
|
|
|
|
|
For a kid, the new Micro:bit initiative looks very interesting: BBC micro:bit : Create code[^]
The MS block editor makes syntax errors a thing of the past, and lest them concentrate on the essentials of development without worrying about the specifics. When they have got them down well, they will (hopefully) want to move to a more complex language which lets them control the code better (and the structure of the block editor would make a transition to C# fairly painless).
Block editor[^]
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
i'd go with the simplest dynamically-typed scripting language i could find. introducing the language plus a compiler & linker is just too much at once.
|
|
|
|
|
|
I would start with a high-level language, either dynamically or statically typed. From your list probably Python or C#. The idea is to get up and running fairly easily. Then, after a while, depending on interest and if you want to dig deeper, try something lower-level like C.
Kevin
|
|
|
|
|
Programming is a lot like picking at a scab. You probably shouldn't but you inevitably do.
Does anybody set out to pick at scabs? I suppose a startled would-be psychologist. Notices all the blood that pours out, realizes it's not as painful as he imagined such a flow to be, and then wonders why he would need to stop it now that it's continuing.
Let me ask you a question. When you think of Python, do you shiver a little?
|
|
|
|
|
RedDk wrote: When you think of Python, do you shiver a little?
I've been doing some Python programming for a BeagleBone SBC. And yes, I shiver.
Marc
|
|
|
|
|
Marc Clifton wrote: Javascript Did you say "duck-typed" or "duct-taped"?
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
As someone who has actually taught people to code...
First, everyone is different.
Second, what is usually lacking is are students that understand how to solve a problem!
The answer is always, it depends. I had some kids who developed Lego NXT apps
as their first programming with a GUI.
I had college kids learning Java. (They just wanted to pass the class, mostly).
What is important, to me. Is an expressive set of problems the student is interested in solving.
Teaching them to read/interpret code first, then to write code.
I found that giving students a working solution, and having them make small changes was the fastest way to wet their whistles. The naturals would excel on their own pretty quickly. The others started to pick up the "Oh, if I change this, this changes".
Then from there it gets easier, because they have a basis of the language and how to make it run.
|
|
|
|
|
First languages I ever learned were the Motorola M6800 and DEC PDP-8 & 12 assembly languages in the late 1970's.
The first language I ever did anything actually useful to anyone else in was REXX in 1980. It's a duct-typed script language. I created a questionnaire application used in rating courses and instructors at the IBM Ed center.
I loved REXX. The datatype of a variable was context-of-use-dependent. If x contained "100" then x would (automagically) be a string in string situations, or an integer or float in those situations.
I still think it's a pity it never became mainstream.
If someone is learning programming... hmmmm
My bottom line criterion would be: least distraction from the learning experience
My REXX experience (and perhaps that of millions of MS-DOS BASIC users) indicates to me that the advantages of duct-typed script languages for neophytes are:
- all you need is a text editor (IDE's can be learned later!)
- the runtime environment can be simplified (the person isn't also, say, learning windowing concepts)
- produces feedback for their efforts quickly (the experience of delight is important I think)
- strong typing can be learned later
- they are imperative and that form of programming is (IMO) more intuitive and therefore easier to grasp.
Cheers,
Mike Fidler
"I intend to live forever - so far, so good." Steven Wright
"I almost had a psychic girlfriend but she left me before we met." Also Steven Wright
"I'm addicted to placebos. I could quit, but it wouldn't matter." Steven Wright yet again.
|
|
|
|