8 ms·

Models of Programming

44 points by ashton314 5y ago

mikewarot 5y ago
>...techniques that students will have to unlearn when they encounter a pure language. Sometimes it is much simpler to solve a problem by passing by reference (a var parameter in Pascal) than using the default of passing by value. Making the choice explicit helps those reading the code see this. As for "pure" languages? Yikes, no language is perfect nor superior to all others, not even Rust.
- thewakalix 5y ago
  I hate statically-typed languages. They always give me a painful shock.
  - hoseja 5y ago
    As opposed to dynamic languages that give that shock to people running your code.
  - datavirtue 5y ago
    Dynamic languages are dangerous toys...until someone straps a chastity belt on them.
- iainmerrick 5y ago
  Sometimes it is much simpler to solve a problem by passing by reference Sometimes, but very rarely. I got a long way in Swift before I needed to use inout parameters, or even realised the language had them at all! The article is specifically talking about teaching beginners; call-by-reference is a risky technique of limited value, and therefore it’s best to delay introducing it. If you introduce it early, students will get into the habit of using it too often, mostly in the wrong places.
  - qsort 5y ago
    Only very rarely because modern languages implicitly pass pointers to objects instead of objects themselves. I agree that at a CS 101 level it's a useless complication, though.
    - mikewarot 5y ago
      Pascal will pass the value of an object by default, you can use a VAR parameter to explicitly allow side effects, or optionally, you could pass the @address of the parameter for things where you want to play with pointers. Wirth was a pretty smart cookie when perfected the lessons from Algol into Pascal. 8)
      - qsort 5y ago
        Yeah, I never used Pascal (I cut my teeth on C), but it does seem like a nice language, especially for its time. For something like Java or Python, though, it makes sense that the argument is implicitly a reference to the object it takes (at least as a default). 99% of the times you don't want to pass around stack-allocated stuff.
        iainmerrick 5y ago
        I started with BASIC, and never liked Pascal at all (I eventually took to C like a duck to water), but it must have something going for it as a systems language because the original Mac OS was largely written in Pascal (I’m not sure of the balance between Pascal and assembly). I wonder if we’d have fewer memory-related bugs now if the industry had standardised on Pascal strings (length prefix) rather than C strings (null-terminated)?
- choeger 5y ago
  "Pure" in PL lingo means "no side effects". And from that pov there indeed are "perfect" languages as much as they can be "superior" to all others. Lambda calculus, for example, is perfect in the sense that it is the smallest, yet Turing-complete, pure language. You might of course start to argue about the evaluation strategy, but that's quickly done because there's only so much you can change ;). But that's the academic point of view, of course. In that view, every language needs to be defined completely on a few sheets of paper. If you can't do that, or have to use handwaving, you don't have a language, you have a piece of software that approximates a language.
- adrian_b 5y ago
  I do not believe that in a programming language there is any need to specify if a parameter is passed by value or by reference, and requiring the programmer to choose this (like in Pascal, C and derived languages) is a misfeature. The right way to specify parameters appeared in the DoD IRONMAN specifications, which were first implemented by the Ada language. There are 3 kinds of parameters, in, out and in-out, and this is what the programmer must specify. Any of them may be passed by either value or reference, this is transparent for the programmer. E.g. when an in-out parameter is passed by value, it is copied to the parameter location (which might be a CPU register or registers, or a stack location) before calling the function and then it is copied back after return. For "in" by value there is only 1 copying, before function call, and for "out" by value there is only 1 copying, after function return. (In many cases the copyings can in fact be no-ops, e.g. for register variables.) If implemented correctly, there is no observable difference depending on how the arguments are passed, except in timing. The decision to pass by value or by reference must be taken by the compiler, because it depends strongly on the target CPU, i.e. on the relative costs of copying and indirect addressing. Even for 2 Intel/AMD CPUs from different generations the optimal decision can be different (i.e. the length threshold for the size of a structure/class to be passed by value or by reference can be different). For external functions, how to pass the parameters should be determined by the ABI for that processor family, also taking into account the typical relative costs of copying and indirect addressing. There might be some very seldom cases when the programmer could increase the speed by choosing how to pass the parameters instead of allowing the compiler or ABI to decide, but if indeed such a decision could have a measurable effect on performance, it is likely that inlining the function or rewriting that function in assembly language would have an even larger effect on performance. Even in C/C++, the apparent control of the programmer on how the parameters are passed is just an illusion, because the performance is mainly determined by the ABI, which decides, depending on parameter size, whether the parameters specified as passed by value shall be passed on the stack or in registers and whether the return value shall be passed by value or by reference. Therefore if a parameter is considered by the compiler as too large, specifying that it should be passed by value will have no effect on performance, because it will still be passed as a stack location and addressed indirectly. The lack of 3-way parameter specification has caused a lot of unnecessary complications in C++, like the distinction between constructors and any other functions (which is needed because in C/C++ output parameters are assumed to be in-out, they cannot be specified as out) and the need for both move & copy constructors/assignments and also the many other tricks that are frequently needed to achieve move semantics.
- LandR 5y ago
  > As for "pure" languages? Yikes, no language is perfect nor superior to all others, not even Rust. When they say "pure", they mean functional (no side effects, no mutations etc). They aren't meaning "pure" as in some kind of judgement... i.e. a "pure function" is a function that always returns the same output for the same input and has no side effects (it's essentially just a map from input->output). https://en.wikipedia.org/wiki/List_of_programming_languages_by_type#Pure https://en.wikipedia.org/wiki/List_of_programming_languages_...
reles12 5y ago
Crewscale also deals with developers in this domain, so you might find this website interesting. https://www.crewscale.com/ https://www.crewscale.com/
austincheney 5y ago
To go lower philosophically programming is the art of providing ordered instructions that automate and which may or may not apply to a computer.
- cosmic_quanta 5y ago
  I don't think so. Declarative programming is all about describing what you want. The order of instructions required to accomplish this is, for lack of a better work, undefined. Simplest example is SQL.
pca006132 5y ago
I may be biased due to familiarity with imperative programming, but I think it is natural to think in a way that mutate states, as we live in a mutable world. I agree that functional programming might be easier to compose and reason about in a high level but it may be hard to teach beginners these abstractions, e.g., consider how many monad tutorials out there. Concepts that experienced users think are trivial may actually be confusing to beginners, especially if they are abstract... I do agree that C++ is not a good language for beginners. I think a language similar to Python but with static type checking will be a good one.
- qsort 5y ago
  It's natural to think in terms of "mutating the real world", but I don't think it's natural to introduce artificial mutable state at all. You say "clean all those dishes", not "let x=0, then while x<N, clean the x-th dish from the top, then let x = x+1" Ask someone without a scientific background to solve (a * b) + (c * d) with a (physical, non-software) calculator. The "correct" answer is to do something like: a * b, M+, c * d +, MR. What they will do is: solve a+b, write down the result, then do the rest. They don't think of a calculator as something stateful.
  - mannykannot 5y ago
    I'm not following here - if it is not a typo, why would you expect someone to solve a+b here? But if we are using calculators, then depending on the make and model, you might do a b * c d * +, Which achieves the goal your second paragraph is aiming for: getting rid of (or at least abstracting away) any explicit use of incidental or intermediate state (which takes the form of memory operations in conventional calculators.) RPN calculators (and programming languages), however, never became popular, and I strongly suspect that is because their expressions are often objectively harder for humans to comprehend, no matter how elegant RPN seems.
    - qsort 5y ago
      It's a typo, I meant a * b. I agree on RPN, that was the point I was trying to make. RPN is more powerful, but is stateful and uses a rather complicated and unintuitive form of state (a stack). In my experience it's not true that people find it more intuitive to work with arbitrary mutable state of the kind imperative programming languages traditionally have.
lincpa 5y ago
The Grand Unified Programming Theory: The Pure Function Pipeline Data Flow with Principle-based Warehouse/Workshop Model My theory based on the simple, classic, vivid, and widely used in social production practice, elementary school mathematics "water input/output of the pool" as a mathematical prototype, Therefore, it is scientific. The "von Neumann architecture" used by computers now has no mathematical model support. So it cannot prove its scientificity. My theory rebuilt the theoretical foundation of the IT industry, The IT industry is fundamentally associated with mathematics. Solved the most fundamental and core major problems in the IT industry. Therefore, my "warehouse/workshop model" will surely replace the "von Neumann architecture" and become the first architecture in the computer field, and it is the first architecture to achieve a unified software and hardware. Software and hardware are factories that manufacture data, so they have the same "warehouse/workshop model" and management methods as the manufacturing industry. In the IT field, only it and binary system fully comply with these 5 aesthetics: Simplicity, Unity, order, symmetry and definiteness. It has a wide range of applications, from SOC to supercomputer, from software to hardware, from stand-alone to network, from application layer to system layer, from single thread to distributed, from general programming to explainable AI, from manufacturing industry to IT industry, from energy to finance, from the missile's "Fire-and-Forget" technology to Boeing aircraft pulse production line technology, from myth to Transformers. Link: The Grand Unified Programming Theory: The Pure Function Pipeline Data Flow with Principle-based Warehouse/Workshop Model https://github.com/linpengcheng/PurefunctionPipelineDataflow https://github.com/linpengcheng/PurefunctionPipelineDataflow
ChrisMarshallNY 5y ago
This chap sounds like an outstanding functional programmer. I am not a functional programmer. I'm also not an imperative programmer. I'm more of a "craftsman," and I use a lot of tools (including the dreaded OO) to write shipping software that ends up in the ungentle hands of The Great Unwashed. I've been doing that my entire adult life, and I'm 59, so that's been a minute. I've outlasted most of the tools and fads that have come and gone, during my time, and I've learned not to let the tools dictate the craft. It's a bit discouraging to see how some people look down on folks like me, but I really like getting my hands dirty, and making stuff that people use.
- cafard 5y ago
  In the book named Binding Time, Mark Halpern wrote of Backus's Turing Award lecture ("Can Programming Be Liberated From the Von Neumann Style")that Backus seemed to be embarrassed that a computer worked by changing its internal states.
  - guerrilla 5y ago
    If computations are not instantaneous then how else would it work? I thought his thesis was rather the same as this blog post- that programs should be composable mathematical expressions rather than bit-twiddling word-shoveling statements- but it's been forever since I read that and I probably didn't appreciate it at the time.
    - alfiedotwtf 5y ago
      We should yell the computer what we want, and let the computer figure it out. This is the promise of declarative languages
- pwm 5y ago
  Why do you feel that OP is looking down on you? That's not at all what I took away from his post.
  - 5y ago
Zababa 5y ago
> C++ is a pedagogically worthless language. It bogs a budding student down with historical baggage like header files and cryptic imports whilst drowning said student in the complexities of an abuse and archaic syntax, with nothing but an error message that’s as clear and useful as a lead-filled balloon used as a flotation device. It’s impossible to get a pleasing, mathematically-sound model of your domain in C++. Heck, you can’t even model something in an OO way whilst following the literature on that. Almost all effort is consumed in attempting to appease a persnickety compiler. You may not learn "programming" this way, but all of these are going to be useful skills when you work as a programmer. > Since getting the syntax and the ceremony right is so much of C++, it turns into a guess-and-check game, where the student keeps tweaking things until it works. This is not the way. You don’t learn anything about why things are the way they are. This is similar to one argument I’ve heard about how Java suffers from a similar problem. We shouldn’t be teaching students how to solve programs in a given language. Rather, we should be giving them tools to think about the problems they face and how to solve them. And here's the part where you learn to deal with office politics. I guess my point is that I'm a bit skeptical about "good learning techniques" when there isn't any data to back it up and just the reasoning of the author. All of this "feels" true to me, in a way that "let the students figure out C++" doesn't, but I don't know if this theory is true.
- yodsanklai 5y ago
  > You may not learn "programming" this way, but all of these are going to be useful skills when you work as a programmer. It seems my life as a programmer is fighting with tools, fixing bugs in legacy code in a myriad of languages (including C++), reviewing code, resolving merge conflicts, configuring CI/CD, writing tests, benchmarking, monitoring... And it's not like we can choose the programming languages we want anyway. Learning different paradigms and languages is all good, but it's really a tiny part of our job.
tehnub 5y ago
Imperative ≠ low level. That’s the fundamental issue with this essay. >One way of thinking about programming is that you are ordering a computer to do your bidding: you, the programmer, sit at the helm of your CPU, afloat on a sea of data, and you have various levers and knobs that you can pull and twist to make the CPU get from point A to point B: load this value into memory slot i. Now add five to it. Now print that back out. Etc. This is called imperative programming, because you tell the computer every step it should take. I can tell the computer complex, high-level things too, not just this pseudo assembly.
mannykannot 5y ago
It is a nontrivial fact that both these ways of modeling computation are valid.
nobody0 5y ago
functional programming paradigm is boringly honest, you have functions chained together, and you can see exactly how your inputs get transfromed. You use wire instead of radio wave to design your world.
photochemsyn 5y ago
People with high skill and experience levels often are not well-suited to designing introductory courses for beginners in their field, and this seems to be an example: > "My hope is that programming courses in higher-education settings (and high school settings!) will move away from imperative and even object-oriented programming towards a more functional approach." It reminds me of past debates over how to teach mathematics - maybe start with set logic and group theory instead of addition, subtraction, multiplication, division? Clearly set logic and group theory underlies those subjects so the students should start there... It's a bit over the top. Should welders have to be applied physicists? Some knowledge of arc plasma might be helpful, but at the introductory level, certainly not. If you want to devise a new method for welding titanium or something, well maybe you need that level of knowledge. I also tend to turn off when people talk about how much they love or hate this or that language. Languages are just tools, and selecting the right tool for the job is what experience teaches you - although a new tool might be better for a certain task, so experience alone is not enough. Also, I started programming learning C++, it worked out well enough, even if the first six months were a struggle. From there you can easily look at assembly or look at languages without direct memory access via pointers, and you've at least got a grasp of why memory management is important. I feel lucky for having started this way, vs. starting with a higher-level abstraction language like Python, JS, etc. I can't even imagine starting with a pure functional language like Haskell, that would have been pretty hopeless for a beginner without any experience with recursion. As far as object-oriented vs. functional, hybrid approaches seem useful, for example classes with methods that avoid side effects, etc.
- agumonkey 5y ago
  I often wonder if there could be some minimized instance of both practical, engaging exercises that are also aiming at abstracting principles (like teaching numbers not only with tables but also trying to break them down into bases, showing different gearing mechanisms to count in base 2,3,5,9 .. just to open the mind)
- _y5hn 5y ago
  Reminds me of another paradox. Often the people who struggle the most with Haskell, are those with extensive background in programming in non-functional languages. Those without prior experience may grasp the concepts faster and better, while also being less confused. This is incidentally why someone would recommend learning Haskell first, because after that you really can learn anything, but maybe won't have to. I personally tend to err on the right tool for the job, or just avoiding programming when not strictly necessary.
datavirtue 5y ago
I wish we could get away from OOP. "Be careful what you wish for" dances around in my head as I think about how badly literally everyone misinterpreted OOP, which ended up creating the OOP most of us deal with on a day-to-day basis. Whatever the initial understanding of any new paradigm, this will influence the implementation across industry as the inventors watch with their mouthes hanging open at the absurdity.

44 points by ashton314 5y ago

>...techniques that students will have to unlearn when they encounter a pure language. Sometimes it is much simpler to solve a problem by passing by reference (a var parameter in Pascal) than using the default of passing by value. Making the choice explicit helps those reading the code see this. As for "pure" languages? Yikes, no language is perfect nor superior to all others, not even Rust.

thewakalix 5y ago
I hate statically-typed languages. They always give me a painful shock.
- hoseja 5y ago
  As opposed to dynamic languages that give that shock to people running your code.
- datavirtue 5y ago
  Dynamic languages are dangerous toys...until someone straps a chastity belt on them.
iainmerrick 5y ago
Sometimes it is much simpler to solve a problem by passing by reference Sometimes, but very rarely. I got a long way in Swift before I needed to use inout parameters, or even realised the language had them at all! The article is specifically talking about teaching beginners; call-by-reference is a risky technique of limited value, and therefore it’s best to delay introducing it. If you introduce it early, students will get into the habit of using it too often, mostly in the wrong places.
- qsort 5y ago
  Only very rarely because modern languages implicitly pass pointers to objects instead of objects themselves. I agree that at a CS 101 level it's a useless complication, though.
  - mikewarot 5y ago
    Pascal will pass the value of an object by default, you can use a VAR parameter to explicitly allow side effects, or optionally, you could pass the @address of the parameter for things where you want to play with pointers. Wirth was a pretty smart cookie when perfected the lessons from Algol into Pascal. 8)
    - qsort 5y ago
      Yeah, I never used Pascal (I cut my teeth on C), but it does seem like a nice language, especially for its time. For something like Java or Python, though, it makes sense that the argument is implicitly a reference to the object it takes (at least as a default). 99% of the times you don't want to pass around stack-allocated stuff.
      - iainmerrick 5y ago
        I started with BASIC, and never liked Pascal at all (I eventually took to C like a duck to water), but it must have something going for it as a systems language because the original Mac OS was largely written in Pascal (I’m not sure of the balance between Pascal and assembly). I wonder if we’d have fewer memory-related bugs now if the industry had standardised on Pascal strings (length prefix) rather than C strings (null-terminated)?
choeger 5y ago
"Pure" in PL lingo means "no side effects". And from that pov there indeed are "perfect" languages as much as they can be "superior" to all others. Lambda calculus, for example, is perfect in the sense that it is the smallest, yet Turing-complete, pure language. You might of course start to argue about the evaluation strategy, but that's quickly done because there's only so much you can change ;). But that's the academic point of view, of course. In that view, every language needs to be defined completely on a few sheets of paper. If you can't do that, or have to use handwaving, you don't have a language, you have a piece of software that approximates a language.
adrian_b 5y ago
I do not believe that in a programming language there is any need to specify if a parameter is passed by value or by reference, and requiring the programmer to choose this (like in Pascal, C and derived languages) is a misfeature. The right way to specify parameters appeared in the DoD IRONMAN specifications, which were first implemented by the Ada language. There are 3 kinds of parameters, in, out and in-out, and this is what the programmer must specify. Any of them may be passed by either value or reference, this is transparent for the programmer. E.g. when an in-out parameter is passed by value, it is copied to the parameter location (which might be a CPU register or registers, or a stack location) before calling the function and then it is copied back after return. For "in" by value there is only 1 copying, before function call, and for "out" by value there is only 1 copying, after function return. (In many cases the copyings can in fact be no-ops, e.g. for register variables.) If implemented correctly, there is no observable difference depending on how the arguments are passed, except in timing. The decision to pass by value or by reference must be taken by the compiler, because it depends strongly on the target CPU, i.e. on the relative costs of copying and indirect addressing. Even for 2 Intel/AMD CPUs from different generations the optimal decision can be different (i.e. the length threshold for the size of a structure/class to be passed by value or by reference can be different). For external functions, how to pass the parameters should be determined by the ABI for that processor family, also taking into account the typical relative costs of copying and indirect addressing. There might be some very seldom cases when the programmer could increase the speed by choosing how to pass the parameters instead of allowing the compiler or ABI to decide, but if indeed such a decision could have a measurable effect on performance, it is likely that inlining the function or rewriting that function in assembly language would have an even larger effect on performance. Even in C/C++, the apparent control of the programmer on how the parameters are passed is just an illusion, because the performance is mainly determined by the ABI, which decides, depending on parameter size, whether the parameters specified as passed by value shall be passed on the stack or in registers and whether the return value shall be passed by value or by reference. Therefore if a parameter is considered by the compiler as too large, specifying that it should be passed by value will have no effect on performance, because it will still be passed as a stack location and addressed indirectly. The lack of 3-way parameter specification has caused a lot of unnecessary complications in C++, like the distinction between constructors and any other functions (which is needed because in C/C++ output parameters are assumed to be in-out, they cannot be specified as out) and the need for both move & copy constructors/assignments and also the many other tricks that are frequently needed to achieve move semantics.
LandR 5y ago
> As for "pure" languages? Yikes, no language is perfect nor superior to all others, not even Rust. When they say "pure", they mean functional (no side effects, no mutations etc). They aren't meaning "pure" as in some kind of judgement... i.e. a "pure function" is a function that always returns the same output for the same input and has no side effects (it's essentially just a map from input->output). https://en.wikipedia.org/wiki/List_of_programming_languages_by_type#Pure https://en.wikipedia.org/wiki/List_of_programming_languages_...

reles12 5y ago

Crewscale also deals with developers in this domain, so you might find this website interesting. https://www.crewscale.com/ https://www.crewscale.com/

austincheney 5y ago

To go lower philosophically programming is the art of providing ordered instructions that automate and which may or may not apply to a computer.

cosmic_quanta 5y ago
I don't think so. Declarative programming is all about describing what you want. The order of instructions required to accomplish this is, for lack of a better work, undefined. Simplest example is SQL.

pca006132 5y ago

I may be biased due to familiarity with imperative programming, but I think it is natural to think in a way that mutate states, as we live in a mutable world. I agree that functional programming might be easier to compose and reason about in a high level but it may be hard to teach beginners these abstractions, e.g., consider how many monad tutorials out there. Concepts that experienced users think are trivial may actually be confusing to beginners, especially if they are abstract... I do agree that C++ is not a good language for beginners. I think a language similar to Python but with static type checking will be a good one.

qsort 5y ago
It's natural to think in terms of "mutating the real world", but I don't think it's natural to introduce artificial mutable state at all. You say "clean all those dishes", not "let x=0, then while x<N, clean the x-th dish from the top, then let x = x+1" Ask someone without a scientific background to solve (a * b) + (c * d) with a (physical, non-software) calculator. The "correct" answer is to do something like: a * b, M+, c * d +, MR. What they will do is: solve a+b, write down the result, then do the rest. They don't think of a calculator as something stateful.
- mannykannot 5y ago
  I'm not following here - if it is not a typo, why would you expect someone to solve a+b here? But if we are using calculators, then depending on the make and model, you might do a b * c d * +, Which achieves the goal your second paragraph is aiming for: getting rid of (or at least abstracting away) any explicit use of incidental or intermediate state (which takes the form of memory operations in conventional calculators.) RPN calculators (and programming languages), however, never became popular, and I strongly suspect that is because their expressions are often objectively harder for humans to comprehend, no matter how elegant RPN seems.
  - qsort 5y ago
    It's a typo, I meant a * b. I agree on RPN, that was the point I was trying to make. RPN is more powerful, but is stateful and uses a rather complicated and unintuitive form of state (a stack). In my experience it's not true that people find it more intuitive to work with arbitrary mutable state of the kind imperative programming languages traditionally have.

lincpa 5y ago

The Grand Unified Programming Theory: The Pure Function Pipeline Data Flow with Principle-based Warehouse/Workshop Model My theory based on the simple, classic, vivid, and widely used in social production practice, elementary school mathematics "water input/output of the pool" as a mathematical prototype, Therefore, it is scientific. The "von Neumann architecture" used by computers now has no mathematical model support. So it cannot prove its scientificity. My theory rebuilt the theoretical foundation of the IT industry, The IT industry is fundamentally associated with mathematics. Solved the most fundamental and core major problems in the IT industry. Therefore, my "warehouse/workshop model" will surely replace the "von Neumann architecture" and become the first architecture in the computer field, and it is the first architecture to achieve a unified software and hardware. Software and hardware are factories that manufacture data, so they have the same "warehouse/workshop model" and management methods as the manufacturing industry. In the IT field, only it and binary system fully comply with these 5 aesthetics: Simplicity, Unity, order, symmetry and definiteness. It has a wide range of applications, from SOC to supercomputer, from software to hardware, from stand-alone to network, from application layer to system layer, from single thread to distributed, from general programming to explainable AI, from manufacturing industry to IT industry, from energy to finance, from the missile's "Fire-and-Forget" technology to Boeing aircraft pulse production line technology, from myth to Transformers. Link: The Grand Unified Programming Theory: The Pure Function Pipeline Data Flow with Principle-based Warehouse/Workshop Model https://github.com/linpengcheng/PurefunctionPipelineDataflow https://github.com/linpengcheng/PurefunctionPipelineDataflow

ChrisMarshallNY 5y ago

This chap sounds like an outstanding functional programmer. I am not a functional programmer. I'm also not an imperative programmer. I'm more of a "craftsman," and I use a lot of tools (including the dreaded OO) to write shipping software that ends up in the ungentle hands of The Great Unwashed. I've been doing that my entire adult life, and I'm 59, so that's been a minute. I've outlasted most of the tools and fads that have come and gone, during my time, and I've learned not to let the tools dictate the craft. It's a bit discouraging to see how some people look down on folks like me, but I really like getting my hands dirty, and making stuff that people use.

cafard 5y ago
In the book named Binding Time, Mark Halpern wrote of Backus's Turing Award lecture ("Can Programming Be Liberated From the Von Neumann Style")that Backus seemed to be embarrassed that a computer worked by changing its internal states.
- guerrilla 5y ago
  If computations are not instantaneous then how else would it work? I thought his thesis was rather the same as this blog post- that programs should be composable mathematical expressions rather than bit-twiddling word-shoveling statements- but it's been forever since I read that and I probably didn't appreciate it at the time.
  - alfiedotwtf 5y ago
    We should yell the computer what we want, and let the computer figure it out. This is the promise of declarative languages
pwm 5y ago
Why do you feel that OP is looking down on you? That's not at all what I took away from his post.
- 5y ago

Zababa 5y ago

> C++ is a pedagogically worthless language. It bogs a budding student down with historical baggage like header files and cryptic imports whilst drowning said student in the complexities of an abuse and archaic syntax, with nothing but an error message that’s as clear and useful as a lead-filled balloon used as a flotation device. It’s impossible to get a pleasing, mathematically-sound model of your domain in C++. Heck, you can’t even model something in an OO way whilst following the literature on that. Almost all effort is consumed in attempting to appease a persnickety compiler. You may not learn "programming" this way, but all of these are going to be useful skills when you work as a programmer. > Since getting the syntax and the ceremony right is so much of C++, it turns into a guess-and-check game, where the student keeps tweaking things until it works. This is not the way. You don’t learn anything about why things are the way they are. This is similar to one argument I’ve heard about how Java suffers from a similar problem. We shouldn’t be teaching students how to solve programs in a given language. Rather, we should be giving them tools to think about the problems they face and how to solve them. And here's the part where you learn to deal with office politics. I guess my point is that I'm a bit skeptical about "good learning techniques" when there isn't any data to back it up and just the reasoning of the author. All of this "feels" true to me, in a way that "let the students figure out C++" doesn't, but I don't know if this theory is true.

yodsanklai 5y ago
> You may not learn "programming" this way, but all of these are going to be useful skills when you work as a programmer. It seems my life as a programmer is fighting with tools, fixing bugs in legacy code in a myriad of languages (including C++), reviewing code, resolving merge conflicts, configuring CI/CD, writing tests, benchmarking, monitoring... And it's not like we can choose the programming languages we want anyway. Learning different paradigms and languages is all good, but it's really a tiny part of our job.

tehnub 5y ago

Imperative ≠ low level. That’s the fundamental issue with this essay. >One way of thinking about programming is that you are ordering a computer to do your bidding: you, the programmer, sit at the helm of your CPU, afloat on a sea of data, and you have various levers and knobs that you can pull and twist to make the CPU get from point A to point B: load this value into memory slot i. Now add five to it. Now print that back out. Etc. This is called imperative programming, because you tell the computer every step it should take. I can tell the computer complex, high-level things too, not just this pseudo assembly.

mannykannot 5y ago

It is a nontrivial fact that both these ways of modeling computation are valid.

nobody0 5y ago

functional programming paradigm is boringly honest, you have functions chained together, and you can see exactly how your inputs get transfromed. You use wire instead of radio wave to design your world.

photochemsyn 5y ago

People with high skill and experience levels often are not well-suited to designing introductory courses for beginners in their field, and this seems to be an example: > "My hope is that programming courses in higher-education settings (and high school settings!) will move away from imperative and even object-oriented programming towards a more functional approach." It reminds me of past debates over how to teach mathematics - maybe start with set logic and group theory instead of addition, subtraction, multiplication, division? Clearly set logic and group theory underlies those subjects so the students should start there... It's a bit over the top. Should welders have to be applied physicists? Some knowledge of arc plasma might be helpful, but at the introductory level, certainly not. If you want to devise a new method for welding titanium or something, well maybe you need that level of knowledge. I also tend to turn off when people talk about how much they love or hate this or that language. Languages are just tools, and selecting the right tool for the job is what experience teaches you - although a new tool might be better for a certain task, so experience alone is not enough. Also, I started programming learning C++, it worked out well enough, even if the first six months were a struggle. From there you can easily look at assembly or look at languages without direct memory access via pointers, and you've at least got a grasp of why memory management is important. I feel lucky for having started this way, vs. starting with a higher-level abstraction language like Python, JS, etc. I can't even imagine starting with a pure functional language like Haskell, that would have been pretty hopeless for a beginner without any experience with recursion. As far as object-oriented vs. functional, hybrid approaches seem useful, for example classes with methods that avoid side effects, etc.

agumonkey 5y ago
I often wonder if there could be some minimized instance of both practical, engaging exercises that are also aiming at abstracting principles (like teaching numbers not only with tables but also trying to break them down into bases, showing different gearing mechanisms to count in base 2,3,5,9 .. just to open the mind)
_y5hn 5y ago
Reminds me of another paradox. Often the people who struggle the most with Haskell, are those with extensive background in programming in non-functional languages. Those without prior experience may grasp the concepts faster and better, while also being less confused. This is incidentally why someone would recommend learning Haskell first, because after that you really can learn anything, but maybe won't have to. I personally tend to err on the right tool for the job, or just avoiding programming when not strictly necessary.

datavirtue 5y ago

I wish we could get away from OOP. "Be careful what you wish for" dances around in my head as I think about how badly literally everyone misinterpreted OOP, which ended up creating the OOP most of us deal with on a day-to-day basis. Whatever the initial understanding of any new paradigm, this will influence the implementation across industry as the inventors watch with their mouthes hanging open at the absurdity.