Introductions to programming suck
-
harold aptroot wrote:
So I blame the choice of language.
First your implicit suggestion is that the language is to blame which entirely ignores the role of the teacher both in teaching and the choice of language itself. Second the concept of programming is difficult because it is something that no one has encountered before they actually learn it. Nothing that they have learned before is like it. Third standard programming languages do not exist to teach. They exist to solve problems. And they were designed with that in mind.
harold aptroot wrote:
People who might (I think) otherwise have become decent programmers
I doubt that. Although it is possible that more people would succeed if teachers were better. All though it would probably only be a small percentage increase.
harold aptroot wrote:
It's conceptually simple. No confusing abstractions.
Which ignores the real difficulty in that one must still get exactly the right sequence the first time for it to work at all. And you might note that there have been languages designed specifically for teaching programming. None of them have been successful in that regard.
jschell wrote:
you might note that there have been languages designed specifically for teaching programming. None of them have been successful in that regard.
Probably because they were designed by people who taught computer science classes. They are far too enamored of making the language include their pet theoretical feature (WTF is a 'monad' anyway?) rather than concentrating on the end goal. That goal should be to teach core principles required of every programmer, whether they do embedded development or line of business apps. I also think an introductory language must be based on an existing language, possibly with syntax limitations. If you teach fundamental principles in an academic language that isn't used elsewhere, student will suffer. There will always be a 'cognitive discontinuity' when they translate those principles from the academic language to Java, C++, or whatever they're using. Knowledge of those principles must become second nature, and students won't acquire the ability to generalize them to other languages without a lot of time and experience. Longer term, I firmly believe that university computer science and engineering curricula should include a two semester sequence in real-world development, taught by a working professional. It should include undocumented and changing requirements, an unreasonable schedule, and faulty tools. The only reason I had the faintest clue about real-world programming when I graduated from college was that I worked as a programmer part-time the last three years of school.
Software Zen:
delete this; -
I've seen tons of people utterly fail to grasp the introduction to programming, and to be honest, I don't really blame them. Many failed to grasp not the syntax of whatever arbitrary language the teachers decided to throw at them (often C++, Java or C#), but the core idea of programming: you're giving the computer a list of instructions that it blindly executes. So I blame the choice of language. The languages commonly used to introduce CS students to programming do not make it obvious what programming actually is, to the beginner it all looks like magic. Especially when OOP is added - without building it on top of something (the way it's usually taught is out of the blue and with flawed real life analogies), that's just pure magic. People who might (I think) otherwise have become decent programmers if they had been taught differently get stuck behind the hurdle of figuring out the core concept for themselves (while getting bogged down in abstract concepts that aren't useful at that stage yet), and give up. IMO a simple assembly language would make a much better first language. It makes the core concept explicit. It's conceptually simple. No confusing abstractions. The syntax is trivial. It really is as simple as a list of instructions. The only problem with assembly (hard-to-manage growth of complexity as projects get bigger) is irrelevant in this situation - you're only going to give assignments for simple straight line code at first, then some conditionals and loops, subroutines if you're brave, nothing unwieldy. ps: I learned z80 assembly as a first programming language so I might be biased.
I learned Spectrum Basic, then Z80 assembler, but that's not how I'd want my son to start if that's what he wanted to learn. I disagree with assembly as a starting language. In many ways, to my mind, what's important is teaching algorithms and data structures - the language used is immaterial (within reason - I suspect Haskell may be a bad beginner's language). I'd find it easier to teach programming in C# or Java, but would want to bring it back to earth with C or C++, so that memory management was not just black magic. My 8 year old son has been learning with the help of Flowol, which is largely flowchart based. That gives the fundamentals of step-by-step processing and decision making as well as anything, but for older students I'd start with higher-level languages.
-
I learned Spectrum Basic, then Z80 assembler, but that's not how I'd want my son to start if that's what he wanted to learn. I disagree with assembly as a starting language. In many ways, to my mind, what's important is teaching algorithms and data structures - the language used is immaterial (within reason - I suspect Haskell may be a bad beginner's language). I'd find it easier to teach programming in C# or Java, but would want to bring it back to earth with C or C++, so that memory management was not just black magic. My 8 year old son has been learning with the help of Flowol, which is largely flowchart based. That gives the fundamentals of step-by-step processing and decision making as well as anything, but for older students I'd start with higher-level languages.
What I had in mind what just be for the introduction really, a month or so of assembly to get rid of common misconceptions about how computers work and what programming is, and then let them have a higher level language. Algorithms and data-structures are very important, I agree, but there's plenty of time for that after the introduction..
-
And I my opinion, DCL is the best command language ever. A pity that the Unix and the Microsoft guys didn't know about it (or weren't in love with it).
:thumbsup:
-
Brings back fond memories of teaching CS101 to freshmen in 1984. In my first lecture, I made the students parts of a human computer - each got an instruction (which they weren't supposed to share with others) and we laboriously walked through a
forloop that counted from 1 to 10. Took close to an hour to get the "program" to finish. I then asked them how long they thought it would take on a mainframe. Responses ranged from "less than a second" to "1 second". I upped the ante and asked what if the loop ran to a 100? A thousand? Ten thousand? Responses were mixed, but nobody was ready for the app to finish running in a few seconds. They were completely blown away. (Learning experience #1: computers are FAST). Next, I made the human computer subtract the index instead of counting up, causing an infinite loop. The kids saw the error right away. We then programmed the mainframe (a VAX-11/780) to do the same thing. Whoops! Infinite loop! (Learning experience #2: computers are STUPID). We didn't write code until week 2. By then, 2 interesting things occured: (1) many students dropped the course and (2) almost all of those who stayed on loved it and got nothing less than a B. It was one of the best experiences of my brief (3 year) teaching career and I was happy to receive an award for being one of the best undergrad instructors at NYIT. :) /raviMy new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
Two posts and I already love this thread! Next time I get the opportunity to teach, I will remember that :-D
- A.
-
I've seen tons of people utterly fail to grasp the introduction to programming, and to be honest, I don't really blame them. Many failed to grasp not the syntax of whatever arbitrary language the teachers decided to throw at them (often C++, Java or C#), but the core idea of programming: you're giving the computer a list of instructions that it blindly executes. So I blame the choice of language. The languages commonly used to introduce CS students to programming do not make it obvious what programming actually is, to the beginner it all looks like magic. Especially when OOP is added - without building it on top of something (the way it's usually taught is out of the blue and with flawed real life analogies), that's just pure magic. People who might (I think) otherwise have become decent programmers if they had been taught differently get stuck behind the hurdle of figuring out the core concept for themselves (while getting bogged down in abstract concepts that aren't useful at that stage yet), and give up. IMO a simple assembly language would make a much better first language. It makes the core concept explicit. It's conceptually simple. No confusing abstractions. The syntax is trivial. It really is as simple as a list of instructions. The only problem with assembly (hard-to-manage growth of complexity as projects get bigger) is irrelevant in this situation - you're only going to give assignments for simple straight line code at first, then some conditionals and loops, subroutines if you're brave, nothing unwieldy. ps: I learned z80 assembly as a first programming language so I might be biased.
"IMO a simple assembly language would make a much better first language. It makes the core concept explicit. It's conceptually simple. No confusing abstractions. The syntax is trivial. It really is as simple as a list of instructions. The only problem with assembly (hard-to-manage growth of complexity as projects get bigger)... This is what the early versions of BASIC were for, before it got so complex.
"Microsoft -- Adding unnecessary complexity to your work since 1987!"
-
I've seen tons of people utterly fail to grasp the introduction to programming, and to be honest, I don't really blame them. Many failed to grasp not the syntax of whatever arbitrary language the teachers decided to throw at them (often C++, Java or C#), but the core idea of programming: you're giving the computer a list of instructions that it blindly executes. So I blame the choice of language. The languages commonly used to introduce CS students to programming do not make it obvious what programming actually is, to the beginner it all looks like magic. Especially when OOP is added - without building it on top of something (the way it's usually taught is out of the blue and with flawed real life analogies), that's just pure magic. People who might (I think) otherwise have become decent programmers if they had been taught differently get stuck behind the hurdle of figuring out the core concept for themselves (while getting bogged down in abstract concepts that aren't useful at that stage yet), and give up. IMO a simple assembly language would make a much better first language. It makes the core concept explicit. It's conceptually simple. No confusing abstractions. The syntax is trivial. It really is as simple as a list of instructions. The only problem with assembly (hard-to-manage growth of complexity as projects get bigger) is irrelevant in this situation - you're only going to give assignments for simple straight line code at first, then some conditionals and loops, subroutines if you're brave, nothing unwieldy. ps: I learned z80 assembly as a first programming language so I might be biased.
My first programming language was assembly also; CDC 3100 assembly language (COMPASS) in 1971. The fundamentals I learned from using assembly language served me well until this very day, from assembly language to Fortran to C to C++ to Cold Fusion to C# and VB.Net. Even if one never uses assembly language again, the knowledge one gains about how the computer actually works is invaluable. Operating system basics should also be taught as no programming language stands alone.
-
I've seen tons of people utterly fail to grasp the introduction to programming, and to be honest, I don't really blame them. Many failed to grasp not the syntax of whatever arbitrary language the teachers decided to throw at them (often C++, Java or C#), but the core idea of programming: you're giving the computer a list of instructions that it blindly executes. So I blame the choice of language. The languages commonly used to introduce CS students to programming do not make it obvious what programming actually is, to the beginner it all looks like magic. Especially when OOP is added - without building it on top of something (the way it's usually taught is out of the blue and with flawed real life analogies), that's just pure magic. People who might (I think) otherwise have become decent programmers if they had been taught differently get stuck behind the hurdle of figuring out the core concept for themselves (while getting bogged down in abstract concepts that aren't useful at that stage yet), and give up. IMO a simple assembly language would make a much better first language. It makes the core concept explicit. It's conceptually simple. No confusing abstractions. The syntax is trivial. It really is as simple as a list of instructions. The only problem with assembly (hard-to-manage growth of complexity as projects get bigger) is irrelevant in this situation - you're only going to give assignments for simple straight line code at first, then some conditionals and loops, subroutines if you're brave, nothing unwieldy. ps: I learned z80 assembly as a first programming language so I might be biased.
Part of the problem today is that they have abandoned Flow Charting of the task before even starting to program. A Flow Chart may not provide the same skills as assembly language, it clarifies the task to the point that it can be stepped through on paper to find logic and calculation errors. A good Flow Chart can be implemented in any language.
-
Part of the problem today is that they have abandoned Flow Charting of the task before even starting to program. A Flow Chart may not provide the same skills as assembly language, it clarifies the task to the point that it can be stepped through on paper to find logic and calculation errors. A good Flow Chart can be implemented in any language.
-
I've seen tons of people utterly fail to grasp the introduction to programming, and to be honest, I don't really blame them. Many failed to grasp not the syntax of whatever arbitrary language the teachers decided to throw at them (often C++, Java or C#), but the core idea of programming: you're giving the computer a list of instructions that it blindly executes. So I blame the choice of language. The languages commonly used to introduce CS students to programming do not make it obvious what programming actually is, to the beginner it all looks like magic. Especially when OOP is added - without building it on top of something (the way it's usually taught is out of the blue and with flawed real life analogies), that's just pure magic. People who might (I think) otherwise have become decent programmers if they had been taught differently get stuck behind the hurdle of figuring out the core concept for themselves (while getting bogged down in abstract concepts that aren't useful at that stage yet), and give up. IMO a simple assembly language would make a much better first language. It makes the core concept explicit. It's conceptually simple. No confusing abstractions. The syntax is trivial. It really is as simple as a list of instructions. The only problem with assembly (hard-to-manage growth of complexity as projects get bigger) is irrelevant in this situation - you're only going to give assignments for simple straight line code at first, then some conditionals and loops, subroutines if you're brave, nothing unwieldy. ps: I learned z80 assembly as a first programming language so I might be biased.
Any language you want to use for teaching has to be available, for free. This one factor has doomed more prospective CS students than any other. Java is way too weirdly complex for teaching, but you can have it free. 40 years ago you could get Pascal for free, but you had to come up with time on the mainframe to run it. These days you can make the students buy and support their own damn computers. Bwah ha ha. There is a tension between pedagogy and relevance. You may think it's easier to teach programming concepts in LEARNOL (whatever that is), but it's hard to get a job programming in that language. It's harder to teach Java, but there are one million jobs programming in java. Computer Science ought to be like medicine, with 8 years of study and 4 years of supervised apprenticeship, but they throw you out into the real world after only four years, so you have time to absorb only so much, and it all better be relevant. Some students have more trouble with abstraction than others. It's hard for some to make the leap from very concrete arithmetic (like counting on your fingers or putting paper into mailboxes labelled with machine addresses or using people as instructions) to y = mx + b and then from there to y = f(x). Of course there will be failures. Not everybody can carry a tune or shoot a basket either. I think we who already "get" computers have a hard time helping people who don't get it yet to understand the not-very-apt metaphors we use (which is really the abstraction thing again). I remember trying to explain to my smart-but-completely-uneducated adult brother what the file concept was all about and how a program was a file, but not all files were programs, and how you build a program using a compiler, but the files output by the compiler weren't programs either, but relocateable modules that had to be processed again by another program called the linker before the file was a program. Oy! (Had no pedagogical choice here, he was given a canned program to modify and run for a music theory class). We use a lot of metaphors that make sense to us *now*, but how in the world did we ever learn them? Finally, there is a shortage of material that teaches the really basic parts of programming. Something that starts with, "OK, I have a Toshiba Protege computer. It's powered up and showing a screen with a column of little pictures down the left edge. The network cable is connected. Now, how do I make a java program?" I have to confess that after being a competent developer for 20 years, this particular ques
-
Any language you want to use for teaching has to be available, for free. This one factor has doomed more prospective CS students than any other. Java is way too weirdly complex for teaching, but you can have it free. 40 years ago you could get Pascal for free, but you had to come up with time on the mainframe to run it. These days you can make the students buy and support their own damn computers. Bwah ha ha. There is a tension between pedagogy and relevance. You may think it's easier to teach programming concepts in LEARNOL (whatever that is), but it's hard to get a job programming in that language. It's harder to teach Java, but there are one million jobs programming in java. Computer Science ought to be like medicine, with 8 years of study and 4 years of supervised apprenticeship, but they throw you out into the real world after only four years, so you have time to absorb only so much, and it all better be relevant. Some students have more trouble with abstraction than others. It's hard for some to make the leap from very concrete arithmetic (like counting on your fingers or putting paper into mailboxes labelled with machine addresses or using people as instructions) to y = mx + b and then from there to y = f(x). Of course there will be failures. Not everybody can carry a tune or shoot a basket either. I think we who already "get" computers have a hard time helping people who don't get it yet to understand the not-very-apt metaphors we use (which is really the abstraction thing again). I remember trying to explain to my smart-but-completely-uneducated adult brother what the file concept was all about and how a program was a file, but not all files were programs, and how you build a program using a compiler, but the files output by the compiler weren't programs either, but relocateable modules that had to be processed again by another program called the linker before the file was a program. Oy! (Had no pedagogical choice here, he was given a canned program to modify and run for a music theory class). We use a lot of metaphors that make sense to us *now*, but how in the world did we ever learn them? Finally, there is a shortage of material that teaches the really basic parts of programming. Something that starts with, "OK, I have a Toshiba Protege computer. It's powered up and showing a screen with a column of little pictures down the left edge. The network cable is connected. Now, how do I make a java program?" I have to confess that after being a competent developer for 20 years, this particular ques
I don't really agree that there's that much of a tension between pedagogy and relevance. It's not like you have to pick just one language and stick with it - you could start out with something simple, and then move on to something relevant. Neither step takes anywhere near 4 years, and doing it in two steps probably doesn't take longer anyway since both steps are so much easier then plunging into the deep end of a relevant language right from the start.
-
I don't really agree that there's that much of a tension between pedagogy and relevance. It's not like you have to pick just one language and stick with it - you could start out with something simple, and then move on to something relevant. Neither step takes anywhere near 4 years, and doing it in two steps probably doesn't take longer anyway since both steps are so much easier then plunging into the deep end of a relevant language right from the start.
In a 4 year degree program hopefully you are exposed to many programming languages and paradigms. I agree with you, given unlimited time. Not every programming course is a 4 year degree. Sometimes it's just one class. Changing languages is not completely frictionless either, especially if introductory students have to install and support their own tools.
-
jschell wrote:
you might note that there have been languages designed specifically for teaching programming. None of them have been successful in that regard.
Probably because they were designed by people who taught computer science classes. They are far too enamored of making the language include their pet theoretical feature (WTF is a 'monad' anyway?) rather than concentrating on the end goal. That goal should be to teach core principles required of every programmer, whether they do embedded development or line of business apps. I also think an introductory language must be based on an existing language, possibly with syntax limitations. If you teach fundamental principles in an academic language that isn't used elsewhere, student will suffer. There will always be a 'cognitive discontinuity' when they translate those principles from the academic language to Java, C++, or whatever they're using. Knowledge of those principles must become second nature, and students won't acquire the ability to generalize them to other languages without a lot of time and experience. Longer term, I firmly believe that university computer science and engineering curricula should include a two semester sequence in real-world development, taught by a working professional. It should include undocumented and changing requirements, an unreasonable schedule, and faulty tools. The only reason I had the faintest clue about real-world programming when I graduated from college was that I worked as a programmer part-time the last three years of school.
Software Zen:
delete this;Gary Wheeler wrote:
I also think an introductory language must be based on an existing language, possibly with syntax limitations
Pretty sure that existed. Based either on C or Java.
Gary Wheeler wrote:
The only reason I had the faintest clue about real-world programming when I graduated from college was that I worked as a programmer part-time the last three years of school.
Yes. Which is why just the education itself is mostly worthless.
-
Gary Wheeler wrote:
I also think an introductory language must be based on an existing language, possibly with syntax limitations
Pretty sure that existed. Based either on C or Java.
Gary Wheeler wrote:
The only reason I had the faintest clue about real-world programming when I graduated from college was that I worked as a programmer part-time the last three years of school.
Yes. Which is why just the education itself is mostly worthless.
jschell wrote:
Which is why just the education itself is mostly worthless
Hmm. To my mind the education by itself, or being a self-taught programmer without formal education, are both weaker in the long run. A formal education at least tries to show you a range of approaches to solving problems. Unfortunately the education rarely teaches the practical necessities of the workplace. I've worked with several self-taught programmers, and they all share a common attribute: every problem's a nail, and they have a favorite hammer. Their responses are limited, and they often have bad cases of Not Invented Here syndrome. A good education plus an internship with a company that will teach you practical skills is the best of both worlds.
Software Zen:
delete this; -
jschell wrote:
First your implicit suggestion is that the language is to blame which entirely ignores the role of the teacher both in teaching and the choice of language itself.
I said I blame the choice of language, not the language (those languages are, as you say, not even meant for teaching in the first place, so it's not their fault they're bad for it). The role of the teacher in that choice irrelevant - it doesn't change the choice. The role of the teacher in teaching is very relevant of course, but that doesn't make a badly suited language a good choice.
jschell wrote:
Third standard programming languages do not exist to teach. They exist to solve problems. And they were designed with that in mind.
Thus making all of them a poor choice for the introduction, yes.
jschell wrote:
And you might note that there have been languages designed specifically for teaching programming. None of them have been successful in that regard.
Many have failed or are in the process of failing (some of them perhaps only through lack of notability). That doesn't mean it's inherently impossible. Some of the suggestions in this thread seem promising.
harold aptroot wrote:
I said I blame the choice of language
Someone besides the students made that choice. Those people are responsible for the aptness of that choice.
harold aptroot wrote:
That doesn't mean it's inherently impossible.
It does however make it more likely that it is impossible.
-
jschell wrote:
Which is why just the education itself is mostly worthless
Hmm. To my mind the education by itself, or being a self-taught programmer without formal education, are both weaker in the long run. A formal education at least tries to show you a range of approaches to solving problems. Unfortunately the education rarely teaches the practical necessities of the workplace. I've worked with several self-taught programmers, and they all share a common attribute: every problem's a nail, and they have a favorite hammer. Their responses are limited, and they often have bad cases of Not Invented Here syndrome. A good education plus an internship with a company that will teach you practical skills is the best of both worlds.
Software Zen:
delete this;Gary Wheeler wrote:
A formal education at least tries to show you a range of approaches to solving problems.
Yes but the "tries" is the issue.
Gary Wheeler wrote:
I've worked with several self-taught programmers, and they all share a common attribute: every problem's a nail...
I have worked in places where everyone had a degree and there was no plethora of advanced thinking there. One of the worst programmers I worked with had two PHDs.
-
harold aptroot wrote:
I said I blame the choice of language
Someone besides the students made that choice. Those people are responsible for the aptness of that choice.
harold aptroot wrote:
That doesn't mean it's inherently impossible.
It does however make it more likely that it is impossible.
-
I've seen tons of people utterly fail to grasp the introduction to programming, and to be honest, I don't really blame them. Many failed to grasp not the syntax of whatever arbitrary language the teachers decided to throw at them (often C++, Java or C#), but the core idea of programming: you're giving the computer a list of instructions that it blindly executes. So I blame the choice of language. The languages commonly used to introduce CS students to programming do not make it obvious what programming actually is, to the beginner it all looks like magic. Especially when OOP is added - without building it on top of something (the way it's usually taught is out of the blue and with flawed real life analogies), that's just pure magic. People who might (I think) otherwise have become decent programmers if they had been taught differently get stuck behind the hurdle of figuring out the core concept for themselves (while getting bogged down in abstract concepts that aren't useful at that stage yet), and give up. IMO a simple assembly language would make a much better first language. It makes the core concept explicit. It's conceptually simple. No confusing abstractions. The syntax is trivial. It really is as simple as a list of instructions. The only problem with assembly (hard-to-manage growth of complexity as projects get bigger) is irrelevant in this situation - you're only going to give assignments for simple straight line code at first, then some conditionals and loops, subroutines if you're brave, nothing unwieldy. ps: I learned z80 assembly as a first programming language so I might be biased.
I`m just glad there`s a Person behind all this, programming! :rolleyes: Where are the step by steps tutorials?:confused:
http://tomtotom1.regfix.hop.clickbank.net http://tomtotom1.tspecial.hop.clickbank.net/?tid=REAL http://www.viralpdf.com/classicedition/index.php?&aff\_id=5183 http://tomtotom1.googlecash.hop.clickbank.net/?tid=SEEME http://tomtotom1.innantech.hop.clickbank.net/?tid=SEESE
-
I've seen tons of people utterly fail to grasp the introduction to programming, and to be honest, I don't really blame them. Many failed to grasp not the syntax of whatever arbitrary language the teachers decided to throw at them (often C++, Java or C#), but the core idea of programming: you're giving the computer a list of instructions that it blindly executes. So I blame the choice of language. The languages commonly used to introduce CS students to programming do not make it obvious what programming actually is, to the beginner it all looks like magic. Especially when OOP is added - without building it on top of something (the way it's usually taught is out of the blue and with flawed real life analogies), that's just pure magic. People who might (I think) otherwise have become decent programmers if they had been taught differently get stuck behind the hurdle of figuring out the core concept for themselves (while getting bogged down in abstract concepts that aren't useful at that stage yet), and give up. IMO a simple assembly language would make a much better first language. It makes the core concept explicit. It's conceptually simple. No confusing abstractions. The syntax is trivial. It really is as simple as a list of instructions. The only problem with assembly (hard-to-manage growth of complexity as projects get bigger) is irrelevant in this situation - you're only going to give assignments for simple straight line code at first, then some conditionals and loops, subroutines if you're brave, nothing unwieldy. ps: I learned z80 assembly as a first programming language so I might be biased.
Z80 -- Luxury , I had to make do with Sinclair Basic. You had to be very gentle with the ZX81 if you that 16K RAM Pack , when you got to the end of the program and pressed that final key with a flourish , the RAM Pack connection flexed and whoosh away went all your work . There was nothing to save to your cassette recorder . Maybe the scrathcy Led Zepplin recordinsg were safe after all. Nostalgia ain't what it used to be ;) Mike
Mike
-
I've seen tons of people utterly fail to grasp the introduction to programming, and to be honest, I don't really blame them. Many failed to grasp not the syntax of whatever arbitrary language the teachers decided to throw at them (often C++, Java or C#), but the core idea of programming: you're giving the computer a list of instructions that it blindly executes. So I blame the choice of language. The languages commonly used to introduce CS students to programming do not make it obvious what programming actually is, to the beginner it all looks like magic. Especially when OOP is added - without building it on top of something (the way it's usually taught is out of the blue and with flawed real life analogies), that's just pure magic. People who might (I think) otherwise have become decent programmers if they had been taught differently get stuck behind the hurdle of figuring out the core concept for themselves (while getting bogged down in abstract concepts that aren't useful at that stage yet), and give up. IMO a simple assembly language would make a much better first language. It makes the core concept explicit. It's conceptually simple. No confusing abstractions. The syntax is trivial. It really is as simple as a list of instructions. The only problem with assembly (hard-to-manage growth of complexity as projects get bigger) is irrelevant in this situation - you're only going to give assignments for simple straight line code at first, then some conditionals and loops, subroutines if you're brave, nothing unwieldy. ps: I learned z80 assembly as a first programming language so I might be biased.
I consider Assembler not to be a good first language simply because there is very little introductory literature about it, at least none that makes a point of also introducing the general concepts of computer programming. I didn't learn programming until I entered university in the early 80s, and then the first languages were Pascal, then Assembler. I believe the order and choice of languages makes sense, since the first approaches the human-computer interface from the human side, whereas the latter approaches it from the tech/computer side. I am convinced that for someone not familiar with computers, the human side approach is better. But for really understanding computer languages in general, you need to look at the tech/computer side too. My favorite book at that time was COMIC-PASCAL by Helmut-Zwittlinger[^]. The comics therein were of questionable quality, but the real-world analogies used to explain language structures were very well chosen and illustrated. Unfortunately the book is german only (or maybe I should say austrian - it does use some choice words from austrian dialect) P.S.: Many of my fellow students already had learned some language. Usually C=64 Basic, or the equivalent Basic from Apple II, and some even delved into the 6502 Assembly. It didn't make them better students however. To the contrary, they had to unlearn their bad habits and generally had a harder time to learn properly structured programming techniques compared to those unbiased by a priori computer knowledge.