<p>It may depend on the background of the student. If you are teaching business, language, or liberal arts majors to code, I would use high level languages. These are more like English, and conceptually more accessible to these types of students.</p>

<p>If I were teaching hard-core math and science students, I might use low level languages. For instance, students studying assembler languages will understand the difference between "accumulation" and addition, and be better prepared to understand commands like X=X+1. Even at the most elementary level of "machine" languages, these students are more likely to understand "bits and bytes" than the students described in the previous paragraph.</p>

CC BY-SA 3.0
2017-06-11T02:51:55.350Z
2017-06-11T02:51:55.350Z
Tom Au
<p>My clear preference is to start in a high level language and introduce low  level concepts (1) as needed, and (2) later in the curriculum. This is in spite of the fact that over my long (45+ year) career, I worked in low level languages early on as that is the historical development. I also struggled each time I had to "up my game" as the path from low level thinking to high level thinking isn't necessarily clear or easy. A stone age human, while fully human and having the same mental capacity as modern humans (which they were), and probably an expert (if male, anyway) in creating stone tools, would have a terrible time trying to understand a socket wrench, though a hammer might be easy enough. </p>

<p>However, I don't believe that my students should recapitulate my experience as much of what I learned is now actually obsolete. Flow Charts for example, though some will disagree. </p>

<p>But the real reason for starting in a higher level language is that I'm trying to teach students to <em>think</em> not to <em>code</em>. Higher level languages provide higher level concepts (duh), so provide a more amenable environment for teaching <em>thinking</em>. </p>

<p>I also want students to be able to build modern software, not the kind of thing I built before 1980. They need practice at that. A lot of practice. Modern software builds big things out of small things. The things inter-operate in complex ways, but if I try to build complex things out of complex parts I wind up with a mess. Build big and complex things out of small and simple things. Both object-oriented programming and functional programming emphasize this. A Scheme function returns a single thing, ideally without side effects. Java classes, if well designed represent simple compositions of still simpler things. Of course it is possible to misuse such languages, writing thousand line Scheme functions or hundred method Java classes. </p>

<p>Of course, it is possible to use C as a higher level language, though most programmers don't. A C program could consist of a thousand 4 line programs and be much better than a four thousand line monstrosity that is impossible to understand. Part of the problem is that C was invented at a time at which "subroutines" were rarely used, and only for those things that people thought would be <em>reused</em>. </p>

<p>Actually people learned long ago that <em>reuse</em> is a false deity. Don't worship it. Even in the Algol days it was understood that decomposition into parts was for simplifying the understanding of a problem. High level languages are intended to put a premium on this way of thinking. </p>

<p>If you teach them to think, they will be able to code. </p>

CC BY-SA 4.0
2018-05-27T14:10:45.777Z
2018-05-27T14:10:45.777Z
Buffy
<p>Considering Computer Science/Engineering you should use a general language. I.e. Modern-C++ (C++11 and after). </p>

<p>There are many outdated misconceptions about programming languages and C++ in particular: </p>

<p>1) C++ is not an object-oriented only language. it is used any way you want it to.</p>

<p>2) Modern C++ dose not use pointers anymore or any of the traumatizing old-school coding practices.</p>

<p>3) Modern C++ allows you to go as low-level to as high-level as you want. You could go as high-level as ignore data types. And you can do procedural programming or OOP. and you can go as low level as write assembly in your C++ code. </p>

<p>A Language is only the tool. With a general language like C++ you decide what/how to teach your students instead of  wasting your time teaching different languages' semantics every time you want to approach a different subject. </p>

CC BY-SA 3.0
2018-04-01T21:15:20.150Z
2018-04-01T21:15:20.150Z
Elkady
<p>Well, straight-forward: It depends:</p>

<ol>
<li>If the low level language you are thinking about teaching has complex code paradigms and is very abstract, then teaching it first would not be a good idea. </li>
<li>However, if your low level language is one that caused newer, high level language to be created, then teaching the low level language can aid the students in understanding some core concepts of the newer language. They might be able to spot those concepts in other languages, too (making a sentence like "oh, just like in <code>&lt;insert low level name here&gt;</code>!" quite common)</li>
</ol>

<p>Personally, if I faced a low level language like the one described in <code>2</code>, I would only teach a few things. The students needn't be "fluent" in the low level language, as it isn't widely used in the "career market". I am not quite sure how widely C is used, but I am pretty sure that it is used less than C# or java (and certainly less than python).</p>

<p>So in essence, knowing the main ideas of the low level languages <em>can</em> be useful, but it is less important and useful than knowing high level languages.</p>

<p>As for a foundation for building knowledge, it goes back to teaching the main ideas of low level languages (rather than teaching the entire language), and then teaching the high level languages. </p>

CC BY-SA 3.0
2017-05-27T16:54:41.357Z
I don't doubt that teaching a low level language is beneficial, but it's more a question of which is better as a foundation to build knowledge on: low or high level
BrDaHa
CC BY-SA 3.0
2017-05-27T17:15:15.000Z
@BrDaHa I see your point. I'll add more to the answer.
ItamarG3
CC BY-SA 3.0
2017-05-27T17:18:24.467Z
@BrDaHa edited the answer.
ItamarG3
CC BY-SA 3.0
2017-05-27T09:49:15.997Z
2017-05-27T17:18:03.117Z
2017-05-27T17:18:03.117Z
ItamarG3
<p>Similar to Itamar Green's answer, if I designed a course this way, I would only focus on one or two tasks in the lower level language.  But even so, I might avoid this approach for introductory students.  There is a beautiful course on Coursera that takes this approach called <a href="https://www.coursera.org/learn/build-a-computer" rel="nofollow noreferrer">Nand to Tetris</a>.  It is deservedly well-reviewed, but it is not appropriate for total newbies.</p>

<p>The problem is that, at least for introductory students, lower-level languages often require you to have a fair amount of rather abstract knowledge about how numbers and memory work.  Taking 'C' as en example, we might add two positive numbers and get the correct answer (yay!), a negative number (integer overflow), or a <em>smaller</em> positive number (truncation).  These are all important issues worthy of discussion in a broader CS curriculum, but are highly technical for students who haven't necessarily mastered the oddly-ordered format of a <strong>for</strong> loop yet.</p>

<p>And of course, when you do get to loops, since they're beginners, they'll make infinite loops.  And when you do that, you might well try to write outside of your allocated memory area, and you wind up with the infamous <code>Segfault</code>, which is both very unhelpful for beginners (who <a href="https://cseducators.stackexchange.com/questions/201/teaching-students-to-hunt-for-and-debug-their-own-errors">already aren't great</a> at reading error messages), and sometimes feels like the only damned error you ever get while writing in C.</p>

CC BY-SA 3.0
2017-05-27T16:17:35.650Z
Personally, the infamous error I would get when learning C was SEGFAULT :)
BrDaHa
CC BY-SA 3.0
2017-05-27T16:19:30.133Z
Lol, yes, thank you!!  Slip of the tongue there :P Conceptually similar errors, though.
Ben I.
CC BY-SA 3.0
2017-05-30T13:55:39.130Z
If you, and your students, find the `for` loop syntax odd, start with the `while` loop first. (Set `x`, test `x`, increment `x`). Then "roll it up" into a single `for` loop.
Gypsy Spellweaver
CC BY-SA 3.0
2017-05-30T14:02:03.067Z
I'm not confused by for loops :)  But the ordering of the operations causes confusion.  Looking at `for (1 ; 2 ; 3) { 4 }`, you would expect the operations to run in a similar order, but they don't. Students seem to regularly get confused by this hidden ordering trap - they need to understand the ordering as (1,2,4,3,[2,4,3...])
Ben I.
CC BY-SA 3.0
2017-05-27T10:55:14.257Z
2017-05-27T16:18:21.657Z
2017-05-27T16:18:21.657Z
Ben I.
<p>When structuring a Computer Science curriculum, which prepares students most effectively for a career in technology today? Consider the following scenarios over a student's college career:</p>

<ul>
<li>Starting with low level languages like ASM and C, working toward higher level (i.e. more forgiving) languages like Java, Python, etc.</li>
<li>Starting with higher level languages and then diving deeper into lower level ones.</li>
</ul>

CC BY-SA 3.0
2017-05-27T07:42:20.753Z
Possible duplicate of [Should assembly language be taught in an introductory course (or soon after)?](https://cseducators.stackexchange.com/questions/27/should-assembly-language-be-taught-in-an-introductory-course-or-soon-after)
Peter
CC BY-SA 3.0
2017-05-27T07:44:40.343Z
Disagree. That question is specifically asking if assembly should be taught at all. In today's world, C is considered low level.
BrDaHa
CC BY-SA 3.0
2017-05-27T07:55:17.143Z
Fair enough. I see the distinction you are attempting to draw.
Peter
CC BY-SA 3.0
2017-05-27T11:28:56.810Z
I prefer to teach high level first, and thing that we are usually not high enough. However I have seen one teacher start with very low-level, and hardware. I fully agree with what this teacher did. I would say very high or very low, not in-between. Also do not try to follow the course of history, the history of computing is important, but this should not dictate the order of learning.
ctrl-alt-delor
<curriculum-design>
Is it more effective to teach low level languages before high level ones or vice versa?
# Is it more effective to teach low level languages before high level ones or vice versa?

(Asked by: username_0 on 2017-05-27)

When structuring a Computer Science curriculum, which prepares students most effectively for a career in technology today? Consider the following scenarios over a student's college career:

* Starting with low level languages like ASM and C, working toward higher level (i.e. more forgiving) languages like Java, Python, etc.
* Starting with higher level languages and then diving deeper into lower level ones.

**Tags:** curriculum-design

> **Comments:**
> **username_1**: Possible duplicate of [Should assembly language be taught in an introductory course (or soon after)?](https://cseducators.stackexchange.com/questions/27/should-assembly-language-be-taught-in-an-introductory-course-or-soon-after)  
> **username_0**: Disagree. That question is specifically asking if assembly should be taught at all. In today's world, C is considered low level.  
> **username_1**: Fair enough. I see the distinction you are attempting to draw.  
> **username_2**: I prefer to teach high level first, and thing that we are usually not high enough. However I have seen one teacher start with very low-level, and hardware. I fully agree with what this teacher did. I would say very high or very low, not in-between. Also do not try to follow the course of history, the history of computing is important, but this should not dictate the order of learning.  

---

## 5 answers

### Answer by username_6 on 2017-05-27. Score: 4

Well, straight-forward: It depends:

1. If the low level language you are thinking about teaching has complex code paradigms and is very abstract, then teaching it first would not be a good idea.
2. However, if your low level language is one that caused newer, high level language to be created, then teaching the low level language can aid the students in understanding some core concepts of the newer language. They might be able to spot those concepts in other languages, too (making a sentence like "oh, just like in !" quite common)

Personally, if I faced a low level language like the one described in `2`, I would only teach a few things. The students needn't be "fluent" in the low level language, as it isn't widely used in the "career market". I am not quite sure how widely C is used, but I am pretty sure that it is used less than C# or java (and certainly less than python).

So in essence, knowing the main ideas of the low level languages *can* be useful, but it is less important and useful than knowing high level languages.

As for a foundation for building knowledge, it goes back to teaching the main ideas of low level languages (rather than teaching the entire language), and then teaching the high level languages.

> **Comments:**
> **username_0**: I don't doubt that teaching a low level language is beneficial, but it's more a question of which is better as a foundation to build knowledge on: low or high level  
> **username_6**: @username_0 I see your point. I'll add more to the answer.  
> **username_6**: @username_0 edited the answer.  

---

### Answer by username_7 on 2017-05-27. Score: 3

Similar to Itamar Green's answer, if I designed a course this way, I would only focus on one or two tasks in the lower level language. But even so, I might avoid this approach for introductory students. There is a beautiful course on Coursera that takes this approach called [Nand to Tetris](https://www.coursera.org/learn/build-a-computer). It is deservedly well-reviewed, but it is not appropriate for total newbies.

The problem is that, at least for introductory students, lower-level languages often require you to have a fair amount of rather abstract knowledge about how numbers and memory work. Taking 'C' as en example, we might add two positive numbers and get the correct answer (yay!), a negative number (integer overflow), or a *smaller* positive number (truncation). These are all important issues worthy of discussion in a broader CS curriculum, but are highly technical for students who haven't necessarily mastered the oddly-ordered format of a **for** loop yet.

And of course, when you do get to loops, since they're beginners, they'll make infinite loops. And when you do that, you might well try to write outside of your allocated memory area, and you wind up with the infamous `Segfault`, which is both very unhelpful for beginners (who [already aren't great](https://cseducators.stackexchange.com/questions/201/teaching-students-to-hunt-for-and-debug-their-own-errors) at reading error messages), and sometimes feels like the only damned error you ever get while writing in C.

> **Comments:**
> **username_0**: Personally, the infamous error I would get when learning C was SEGFAULT :)  
> **username_7**: Lol, yes, thank you!!  Slip of the tongue there :P Conceptually similar errors, though.  
> **username_8**: If you, and your students, find the `for` loop syntax odd, start with the `while` loop first. (Set `x`, test `x`, increment `x`). Then "roll it up" into a single `for` loop.  
> **username_7**: I'm not confused by for loops :)  But the ordering of the operations causes confusion.  Looking at `for (1 ; 2 ; 3) { 4 }`, you would expect the operations to run in a similar order, but they don't. Students seem to regularly get confused by this hidden ordering trap - they need to understand the ordering as (1,2,4,3,[2,4,3...])  

---

### Answer by username_3 on 2017-06-11. Score: 2

It may depend on the background of the student. If you are teaching business, language, or liberal arts majors to code, I would use high level languages. These are more like English, and conceptually more accessible to these types of students.

If I were teaching hard-core math and science students, I might use low level languages. For instance, students studying assembler languages will understand the difference between "accumulation" and addition, and be better prepared to understand commands like X=X+1. Even at the most elementary level of "machine" languages, these students are more likely to understand "bits and bytes" than the students described in the previous paragraph.


---

### Answer by username_4 on 2018-05-27. Score: 1

My clear preference is to start in a high level language and introduce low level concepts (1) as needed, and (2) later in the curriculum. This is in spite of the fact that over my long (45+ year) career, I worked in low level languages early on as that is the historical development. I also struggled each time I had to "up my game" as the path from low level thinking to high level thinking isn't necessarily clear or easy. A stone age human, while fully human and having the same mental capacity as modern humans (which they were), and probably an expert (if male, anyway) in creating stone tools, would have a terrible time trying to understand a socket wrench, though a hammer might be easy enough.

However, I don't believe that my students should recapitulate my experience as much of what I learned is now actually obsolete. Flow Charts for example, though some will disagree.

But the real reason for starting in a higher level language is that I'm trying to teach students to *think* not to *code*. Higher level languages provide higher level concepts (duh), so provide a more amenable environment for teaching *thinking*.

I also want students to be able to build modern software, not the kind of thing I built before 1980. They need practice at that. A lot of practice. Modern software builds big things out of small things. The things inter-operate in complex ways, but if I try to build complex things out of complex parts I wind up with a mess. Build big and complex things out of small and simple things. Both object-oriented programming and functional programming emphasize this. A Scheme function returns a single thing, ideally without side effects. Java classes, if well designed represent simple compositions of still simpler things. Of course it is possible to misuse such languages, writing thousand line Scheme functions or hundred method Java classes.

Of course, it is possible to use C as a higher level language, though most programmers don't. A C program could consist of a thousand 4 line programs and be much better than a four thousand line monstrosity that is impossible to understand. Part of the problem is that C was invented at a time at which "subroutines" were rarely used, and only for those things that people thought would be *reused*.

Actually people learned long ago that *reuse* is a false deity. Don't worship it. Even in the Algol days it was understood that decomposition into parts was for simplifying the understanding of a problem. High level languages are intended to put a premium on this way of thinking.

If you teach them to think, they will be able to code.


---

### Answer by username_5 on 2018-04-01. Score: 0

Considering Computer Science/Engineering you should use a general language. I.e. Modern-C++ (C++11 and after).

There are many outdated misconceptions about programming languages and C++ in particular:

1) C++ is not an object-oriented only language. it is used any way you want it to.

2) Modern C++ dose not use pointers anymore or any of the traumatizing old-school coding practices.

3) Modern C++ allows you to go as low-level to as high-level as you want. You could go as high-level as ignore data types. And you can do procedural programming or OOP. and you can go as low level as write assembly in your C++ code.

A Language is only the tool. With a general language like C++ you decide what/how to teach your students instead of wasting your time teaching different languages' semantics every time you want to approach a different subject.


---

