4 ms·

Let me add the perspective of an old dinosaur that learned to program before C had been invented. C maps nearly 1:1 onto simple processor and memory models, an

Let me add the perspective of an old dinosaur that learned to program before C had been invented. C maps nearly 1:1 onto simple processor and memory models, and most importantly, gets out of your way and lets you get on with solving your system programming problems. Before C, just about any meaningful system programming task required a dive into assembly language. In that context, C was a huge win. It is also what makes C the langauge of choice for embedded development today. Of course, system programming problems are not the bread-and-butter of most develpers today -- and a good thing, too. We can now build on top of solid systems and concentrate on delivering value to the customer at much higher levels of abstraction: the levels of abstraction that are meaningful to customers. I dearly love Python because it allows me to work at levels of abstraction that are meaningful to the user's problem. I dearly love C when I want to wiggle a pin on an ARM Cortex-M3. In my mind, CS education should start by teaching problem decomposition and performance analysis using a language like Python that provides high levels of abstraction and automated memory management. Then, just like assembly language was a required CS core course back in my day, students today should spend a semester implementing and measuring the performance of some of the data structures that they have been getting "for free" so that they understand computing at a fundamental level. Some will go on to be systems programmers, and will spend more time at the C level. Some won't ever look at C again, and that is OK. In the end, CS education is about how to solve problems through the application of mechanical computation. The languages will evolve as our understanding of the problems evolve and our ability to create computing infrastructure evolves. CS educcation should be about creating people who can contribute to (and keep up with) that evolution.

nickpsecurity 10y ago
"In my mind, CS education should start by teaching problem decomposition and performance analysis using a language like Python that provides high levels of abstraction and automated memory management. Then, just like assembly language was a required CS core course back in my day, students today should spend a semester implementing and measuring the performance of some of the data structures that they have been getting "for free" so that they understand computing at a fundamental level. Some will go on to be systems programmers, and will spend more time at the C level. Some won't ever look at C again, and that is OK." I agree with that. I've proposed it myself. I'll add that I prefer them starting with a more type- and memory-safe, but low-level, language like Component Pascal so they can learn low-level thinking but appreciate safety features & good language definitions when they learn C afterward. One can emulate a decent bit of that in C and HLL that compile to C. Maybe they'll remember enough to make something valuable.
- dbcurtis 10y ago
  The whole issue of the role of types is one of my current meditations. Python's duck typing is great for getting out of your way and getting on with your job. Usually. I'm just starting to work through some Julia toturials so that I can experiment with multiple dispatch. But I think the way to teach reasoning about types is to learn you some Haskell. I can't see doing a lot of production programming in Haskell today, but I think learning Haskell is a good mind-stretching exercize (just as learning Prolog was, back when Prolog mattered.)
  - nickpsecurity 10y ago
    I agree Haskell will stretch my mind on the subject when I get around to learning it. It's exactly that reason that I've put it off for so long. ;) Far as industry, I'm not feeling as strong doubts as you looking at the quantity and diversity of this list: https://wiki.haskell.org/Haskell_in_industry https://wiki.haskell.org/Haskell_in_industry There's some real ass-kicking going on in industry with Haskell even if it's niche use and has obstacles/issues from that perspective.
    - pjmlp 10y ago
      Do it, Haskell is great learning exercise. I never get to use it at work, but it helped improve my skills when using FP concepts in C++, JVM and .NET languages.
      - nickpsecurity 10y ago
        I might. My idea is to use either it or more pure ML/Ocaml to code the prototype up then convert each function into imperative C, Rust, or Ada. I figure a subset of Haskell should make that achievable. So, I can use all the tools like QuickCheck and QuickSpec for Haskell along with functional style to knock out many issues. Then, direct translation to imperative with no global issues, equivalence testing generated from Haskell tests, and static analysis to ensure local code is proper. That seL4 matched Haskell and C... along with open-sourcing a key tool (AutoCorres)... makes me think this is achievable. My method isn't formal proof but would be more accessible. What do you think?
ryao 10y ago
> I dearly love Python because it allows me to work at levels of abstraction that are meaningful to the user's problem. I dearly love C when I want to wiggle a pin on an ARM Cortex-M3 What keeps you from wriggling that pin in Python? Turing completeness dictates that any Turing complete language is equivalent to any other Turing complete language. In addition, you can do high levels of abstraction in C. The preprocessor and void pointers allow you to do some rather nice things. Structured programming also let you build things up. The advantage that Python enjoys is that it comes with a large number of library functions already provided and there are easily discoverable third party libraries. There are other differences, although every difference has a trade off. Garbage collection bloats memory requirements. Being interpreted means errors that can be caught in advance at compile time occur at runtime.
- dbcurtis 10y ago
  > What keeps you from wriggling that pin in Python? Did you catch that "Cortex-M3" part after "ARM"? No MMU, no OS, very limited SRAM -- CPython doesn't go there. I am, however, a huge fan of MicroPython, but that discussion too OT for this thread.
- bo1024 10y ago
  > Turing completeness dictates that any Turing complete language is equivalent to any other Turing complete language. Sorry to pick on you, but this is a good example of misuse of this fact in an argument where it's not really relevant. Turing-completeness only relates to functions that take some string as input as produce a string as output (since that's all the turing machine model can do). In contrast, real-world programming languages interact with a machine or operating system, and not all languages provide the same interfaces or even run on the same machines. I can easily implement a Turing-complete language whose only allowed system calls are reading from stdin and writing to stdout. Despite being Turing-complete, it will never be able to spawn threads, connect to a network socket, or even allocate memory on the heap.

nickpsecurity 10y ago

"In my mind, CS education should start by teaching problem decomposition and performance analysis using a language like Python that provides high levels of abstraction and automated memory management. Then, just like assembly language was a required CS core course back in my day, students today should spend a semester implementing and measuring the performance of some of the data structures that they have been getting "for free" so that they understand computing at a fundamental level. Some will go on to be systems programmers, and will spend more time at the C level. Some won't ever look at C again, and that is OK." I agree with that. I've proposed it myself. I'll add that I prefer them starting with a more type- and memory-safe, but low-level, language like Component Pascal so they can learn low-level thinking but appreciate safety features & good language definitions when they learn C afterward. One can emulate a decent bit of that in C and HLL that compile to C. Maybe they'll remember enough to make something valuable.

dbcurtis 10y ago
The whole issue of the role of types is one of my current meditations. Python's duck typing is great for getting out of your way and getting on with your job. Usually. I'm just starting to work through some Julia toturials so that I can experiment with multiple dispatch. But I think the way to teach reasoning about types is to learn you some Haskell. I can't see doing a lot of production programming in Haskell today, but I think learning Haskell is a good mind-stretching exercize (just as learning Prolog was, back when Prolog mattered.)
- nickpsecurity 10y ago
  I agree Haskell will stretch my mind on the subject when I get around to learning it. It's exactly that reason that I've put it off for so long. ;) Far as industry, I'm not feeling as strong doubts as you looking at the quantity and diversity of this list: https://wiki.haskell.org/Haskell_in_industry https://wiki.haskell.org/Haskell_in_industry There's some real ass-kicking going on in industry with Haskell even if it's niche use and has obstacles/issues from that perspective.
  - pjmlp 10y ago
    Do it, Haskell is great learning exercise. I never get to use it at work, but it helped improve my skills when using FP concepts in C++, JVM and .NET languages.
    - nickpsecurity 10y ago
      I might. My idea is to use either it or more pure ML/Ocaml to code the prototype up then convert each function into imperative C, Rust, or Ada. I figure a subset of Haskell should make that achievable. So, I can use all the tools like QuickCheck and QuickSpec for Haskell along with functional style to knock out many issues. Then, direct translation to imperative with no global issues, equivalence testing generated from Haskell tests, and static analysis to ensure local code is proper. That seL4 matched Haskell and C... along with open-sourcing a key tool (AutoCorres)... makes me think this is achievable. My method isn't formal proof but would be more accessible. What do you think?

ryao 10y ago

> I dearly love Python because it allows me to work at levels of abstraction that are meaningful to the user's problem. I dearly love C when I want to wiggle a pin on an ARM Cortex-M3 What keeps you from wriggling that pin in Python? Turing completeness dictates that any Turing complete language is equivalent to any other Turing complete language. In addition, you can do high levels of abstraction in C. The preprocessor and void pointers allow you to do some rather nice things. Structured programming also let you build things up. The advantage that Python enjoys is that it comes with a large number of library functions already provided and there are easily discoverable third party libraries. There are other differences, although every difference has a trade off. Garbage collection bloats memory requirements. Being interpreted means errors that can be caught in advance at compile time occur at runtime.

dbcurtis 10y ago
> What keeps you from wriggling that pin in Python? Did you catch that "Cortex-M3" part after "ARM"? No MMU, no OS, very limited SRAM -- CPython doesn't go there. I am, however, a huge fan of MicroPython, but that discussion too OT for this thread.
bo1024 10y ago
> Turing completeness dictates that any Turing complete language is equivalent to any other Turing complete language. Sorry to pick on you, but this is a good example of misuse of this fact in an argument where it's not really relevant. Turing-completeness only relates to functions that take some string as input as produce a string as output (since that's all the turing machine model can do). In contrast, real-world programming languages interact with a machine or operating system, and not all languages provide the same interfaces or even run on the same machines. I can easily implement a Turing-complete language whose only allowed system calls are reading from stdin and writing to stdout. Despite being Turing-complete, it will never be able to spawn threads, connect to a network socket, or even allocate memory on the heap.