4 ms·

Show HN: Learn Basics of Programming in 40 Minutes

13 points by chkas 5y ago

karmakaze 5y ago
One thing I'd like to see is a basics of programming, but from a functional perspective. What's the desired output for a given input? How can a complex transformation of input to output be decomposed into parts and put together into a full solution. This eliminates the many low-level details about programming, loops, nested-control structures, etc. It starts and ends 'one level' higher. e.g. take a collection, filter it using 'filter' passing in a 'condition'. No one should have to write for/if loops. That was for when machines were so slow that we were barely better than human 'assemblers' writing C.
- chkas 5y ago
  Yes, that would be nice too. Haskel, APL, modern Python written in a way that is easier to understand and easier to use. This has to be done by someone who is "at home" in these languages. I prefer to go the conventional imperative way - although APL has always fascinated me. For beginners, I think the imperative way is still easier to understand. Also, almost the whole computer science world is based on programs written in the "old" C programming language. With a lot of loops, conditions and even jumps with "goto".
  - karmakaze 5y ago
    > For beginners, I think the imperative way is still easier to understand. This is the part that I think we assume without consideration. If someone has trouble learning programming the way we teach it we never think it's the methods or languages we try to teach them. Starting from zero, I think a non-procedural table of inputs to outputs is easy to understand on paper. Then to program it, we don't need any computation 'steps' that execute in a time dimension with mutable values, only logical building blocks that do what we learn they do and can rely upon. The emphasis could be on the invariants before and after a non-procedural expression. I would also avoid rebinding values to vars: = means equal to at scope (let), not re/assign. They would probably hit recursion much sooner and be confused by it at first, but then be so much better off learning to decompose problems.

13 points by chkas 5y ago

One thing I'd like to see is a basics of programming, but from a functional perspective. What's the desired output for a given input? How can a complex transformation of input to output be decomposed into parts and put together into a full solution. This eliminates the many low-level details about programming, loops, nested-control structures, etc. It starts and ends 'one level' higher. e.g. take a collection, filter it using 'filter' passing in a 'condition'. No one should have to write for/if loops. That was for when machines were so slow that we were barely better than human 'assemblers' writing C.

chkas 5y ago
Yes, that would be nice too. Haskel, APL, modern Python written in a way that is easier to understand and easier to use. This has to be done by someone who is "at home" in these languages. I prefer to go the conventional imperative way - although APL has always fascinated me. For beginners, I think the imperative way is still easier to understand. Also, almost the whole computer science world is based on programs written in the "old" C programming language. With a lot of loops, conditions and even jumps with "goto".
- karmakaze 5y ago
  > For beginners, I think the imperative way is still easier to understand. This is the part that I think we assume without consideration. If someone has trouble learning programming the way we teach it we never think it's the methods or languages we try to teach them. Starting from zero, I think a non-procedural table of inputs to outputs is easy to understand on paper. Then to program it, we don't need any computation 'steps' that execute in a time dimension with mutable values, only logical building blocks that do what we learn they do and can rely upon. The emphasis could be on the invariants before and after a non-procedural expression. I would also avoid rebinding values to vars: = means equal to at scope (let), not re/assign. They would probably hit recursion much sooner and be confused by it at first, but then be so much better off learning to decompose problems.