3 ms·

No, it is an argument for teaching intro programming in C so they better understand what operations a computer is capable of doing. When you are used to C most

No, it is an argument for teaching intro programming in C so they better understand what operations a computer is capable of doing. When you are used to C most other languages feels like a library that automates tedious tasks rather than something alien, you are well aware of the things needed to happen in the background so that the code you write in other languages can do what it does.

garmaine 5y ago
C imparts a very specific architecture onto your code. Scheme is more of a blank slate upon which many different paradigms can be taught.
- b5n 5y ago
  I've never looked under the hood of a `cdr` implementation but I feel pretty confident in saying that it's likely to be an incremented pointer most of the time. Learning C (and even a little ASM), gives a better understanding of the underlying layers. I think that provides a great foundation for learning a scheme, and then branching out from there.
- mhuffman 5y ago
  > Scheme is more of a blank slate upon which many different paradigms can be taught. reply Also, for a lot of first-time programmers, Scheme and other lispy languages, can come with heavier cognitive friction. Unlike procedural languages where you can think about what you want to do, break it down into steps, and then make those steps, there is a higher-level (or deeper-level, if you like) of thinking that needs to goes into functional development, where one thing feeds into the next which feeds into the next. If you already have a very strong background in mathematical theory, this might not be so bad (and might make a lot more logical sense), but it is a shift in thinking from how many people do day-to-day tasks, which is more similar to procedural programming.
  - garmaine 5y ago
    While this is true of, say, Haskell, I really don’t think it is true of scheme. You can write procedural, stateful scheme.
kaba0 5y ago
C is not really representative of underlying hardware anymore, and is a language with basically no compile time defenses, making the student scratch their head at hard to debug segfaults. I would definitely not start with C.
- jjav 5y ago
  > C is not really representative of underlying hardware anymore While I understand where this is coming from, can you suggest any language that is closer to the mental model of how the underlying hardware works than C (other than assembly)?
  - kaba0 5y ago
    Well, hard to define closer as a simple dimension — but in certain things perhaps Rust — eg. SIMD is notoriously bad in C. Also, multithreading — which is not exactly a new thing either and don’t forget about pointer aliasing — though that latter is more of an optimization possibility. Fortran may also be considered as another candidate for having SoA over AoS which can potentially be more cache-friendly. But my point was more like, there is no reasonable difference between eg. C and another language that compiles down to machine code — the old saying that a seasoned C programmer can reasonably guess the created machine code of a program is no longer true with today’s heavily optimizing compilers and the amount of magic happening is almost comparable to eg. Haskell.
    - jjav 5y ago
      What about multithreading? Someone exposed to developing a multithreaded app in C using pthreads will have a much better understanding about threads. I have worked with too many younger developers who are confused about kernel threads, cooperative multitasking, green threads, 1:1, 1:M due to only having experienced higher level languages. You couldn't ever have this type of confusion after working in C with threads. Memory handling of course is the other big area. So many developers grown only on higher level languages have varying level of confusion about memory allocation, passing buffers around by copying vs. pointers, modifying memory vs. copy on write vs. reallocating everything. You couldn't possibly come out confused by any of this after a solid stint in C. And just like threads, it's very valuable understanding even if later you mostly program in higher level languages. So yes, while it certainly true that in the 80s you could squint at C code and see the generated assembly code, and that's no longer necessarily true today, it is still true that having a solid foundation in C will help tremendously in understanding what's going in the CPU and memory in ways that probably no other language (that I'm aware of) will help you learn. I do need to spend a solid season in Rust sometime to have a deeper opinion about it!

garmaine 5y ago

C imparts a very specific architecture onto your code. Scheme is more of a blank slate upon which many different paradigms can be taught.

b5n 5y ago
I've never looked under the hood of a `cdr` implementation but I feel pretty confident in saying that it's likely to be an incremented pointer most of the time. Learning C (and even a little ASM), gives a better understanding of the underlying layers. I think that provides a great foundation for learning a scheme, and then branching out from there.
mhuffman 5y ago
> Scheme is more of a blank slate upon which many different paradigms can be taught. reply Also, for a lot of first-time programmers, Scheme and other lispy languages, can come with heavier cognitive friction. Unlike procedural languages where you can think about what you want to do, break it down into steps, and then make those steps, there is a higher-level (or deeper-level, if you like) of thinking that needs to goes into functional development, where one thing feeds into the next which feeds into the next. If you already have a very strong background in mathematical theory, this might not be so bad (and might make a lot more logical sense), but it is a shift in thinking from how many people do day-to-day tasks, which is more similar to procedural programming.
- garmaine 5y ago
  While this is true of, say, Haskell, I really don’t think it is true of scheme. You can write procedural, stateful scheme.

kaba0 5y ago

C is not really representative of underlying hardware anymore, and is a language with basically no compile time defenses, making the student scratch their head at hard to debug segfaults. I would definitely not start with C.

jjav 5y ago
> C is not really representative of underlying hardware anymore While I understand where this is coming from, can you suggest any language that is closer to the mental model of how the underlying hardware works than C (other than assembly)?
- kaba0 5y ago
  Well, hard to define closer as a simple dimension — but in certain things perhaps Rust — eg. SIMD is notoriously bad in C. Also, multithreading — which is not exactly a new thing either and don’t forget about pointer aliasing — though that latter is more of an optimization possibility. Fortran may also be considered as another candidate for having SoA over AoS which can potentially be more cache-friendly. But my point was more like, there is no reasonable difference between eg. C and another language that compiles down to machine code — the old saying that a seasoned C programmer can reasonably guess the created machine code of a program is no longer true with today’s heavily optimizing compilers and the amount of magic happening is almost comparable to eg. Haskell.
  - jjav 5y ago
    What about multithreading? Someone exposed to developing a multithreaded app in C using pthreads will have a much better understanding about threads. I have worked with too many younger developers who are confused about kernel threads, cooperative multitasking, green threads, 1:1, 1:M due to only having experienced higher level languages. You couldn't ever have this type of confusion after working in C with threads. Memory handling of course is the other big area. So many developers grown only on higher level languages have varying level of confusion about memory allocation, passing buffers around by copying vs. pointers, modifying memory vs. copy on write vs. reallocating everything. You couldn't possibly come out confused by any of this after a solid stint in C. And just like threads, it's very valuable understanding even if later you mostly program in higher level languages. So yes, while it certainly true that in the 80s you could squint at C code and see the generated assembly code, and that's no longer necessarily true today, it is still true that having a solid foundation in C will help tremendously in understanding what's going in the CPU and memory in ways that probably no other language (that I'm aware of) will help you learn. I do need to spend a solid season in Rust sometime to have a deeper opinion about it!