The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
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.
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.
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.
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.
Which would you prefer to teach to someone new to programming?
"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.
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 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.
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?
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.
"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.
I have a slightly different perspective on this. I think the language matters less and the environment matters more. In other words, to an absolute beginner, the important thing is understanding what the cryptic words and squiggly characters are going to do within that little world the language resides in and how the language's actions are useful to them.
The problem with most contrived tutorials like "make an array of addresses" or "make the kitty move across the screen until it hits the side wall" is that it's not something they want or need to do and their interest wanes quickly. That 2nd reference isn't a dig at Scratch at all, because I think Scratch is awesome, and the best way I've seen to help young kids understand loops and if/then logic gates. However, if Scratch doesn't ignite more curiosity like, "how can I make the kitty navigate through a maze?", then they're not going to experiment more.
If it's a kid and they're into Minecraft, then learning how to write a Minecraft mod is a perfect task that will keep their experimental fires burning because they want to see that mod work.
Another possibility is writing a basic iPhone app, because it's exciting being able to show your friends, "look at that app in the App Store, I wrote that!", even if the app is just a button you push and it shows a smiley face.
If it's an adult and they want to automate some tasks in Word or Excel, then showing them how to write some VBA code is a good intro to programming.
Regarding a specific language, I think Ruby is a pretty nice language, and for a beginner it's nice that it doesn't require semicolons. I don't know Python well but it's nice that it also doesn't require semicolons. Python does require indents/whitespace--not sure if that is confusing or helpful to a beginner? I learned Perl and VB6 at the same time and I remember the case-sensitivity of Perl confused me and it was nice that VB didn't have that, but I also remember that VB's linebreak requirements (like you have to say "If a=b Then" and not "If a=b --linebreak-- Then") confused me and I liked that Perl was fine with splitting things onto a new line.
One neat thing about Python is that it's used in a number of programs for scripting, like the free image-editing program GIMP. Being able to write a Python script to resize or rotate a batch of photos for example would be a cool and useful thing to teach. The Raspberry Pi board also uses Python scripting, which is another possible platform to teach it.
You could definitely just do Python scripting in a terminal window to manipulate a text file, but that's where I think it could get boring to a beginner unless they could see real-world possibilities.
First, understand that dynamic vs static typing and script vs compiled are NOT tied together.
Second, I recommend losing the pejorative terms such as "duck-typed" as well.
Beyond that, it would depend more on the student's goals and objectives. If they are hoping to become professional developers, then it would help to look at what the local market (or market they want to work in) is looking for. If they are simply looking to play around, then you need to ask what platform they most like, and more.
Having actually done some teaching of programming to high school kids, I can attest that Python is a nice language to start with. In particular, Python notebooks are a great way to get your feet wet in programming, and teachers can put together nice "cheat sheets" that are actually executable using the notebooks.
I would stay far away from any compile-link-run environment. Goodness, why inflict that on any beginner when there are such nicer options around.
Last Visit: 13-Aug-20 16:58 Last Update: 13-Aug-20 16:58