6 ms·

What does C++'s language cruft have to do with CS? Generic programming, among other things. The C languages are actually missing a lot of the important concep

What does C++'s language cruft have to do with CS? Generic programming, among other things. The C languages are actually missing a lot of the important concepts, like lambdas, Lambdas are functions without names. They're not important concepts, they're really just syntactical sugar. and discourage other important things like recursion. Just because the language doesn't require TCO doesn't mean it discourages recursion; it just discourages teaching recursion with trivial examples like factorial. Quicksort, for instance, would be an excellent place in a C or C++-based course for teaching recursion.

loup-vaillant 17y ago
> Generic programming, among other things. The proper CS name is "parametric polymorphism". This is not as special as "Generic programming". (What is special, is the abysmal C++ implementation of parametric polymorphism.) > Lambdas are functions without names. They're not important concepts, they're really just syntactical sugar. The transformation required to go from a higher order program to a first order one is called "lambda lifting". This goes way beyond syntactic sugar. So, a language which lack lambdas don't fully implement functions… which look like an important CS concept.
- jemfinch 16y ago
  > The proper CS name is "parametric polymorphism". No, it isn't. You would know this if you actually bothered to understand the terms you used rather than bandying them about in an attempt to win Internet points. Generic programming is a far broader topic than parametric polymorphism: that's why languages which already have parametric polymorphism, like Haskell, have variants which support true generic programming, like Generic Haskell and Scrap Your Boilerplate. > (What is special, is the abysmal C++ implementation of parametric polymorphism.) Given that you obviously don't understand the difference between run-of-the-mill parametric polymorphism and the generic programming enabled by C++ templates (and no other typed implementation except perhaps GADTs, and I remain unconvinced even of that) Id say you're fairly unqualified to be assessing the quality of C++'s implementation of parametric polymorphism. > The transformation required to go from a higher order program to a first order one is called "lambda lifting". This goes way beyond syntactic sugar. Wow, you really seem to enjoy using terms you clearly don't understand. No, lambda lifting doesn't "go way beyond syntactic sugar." It's actually a fairly simple syntactical transformation: the free variables in the function body are converted to arguments to a static function, and closures, when generated, are a simple data structure consisting of a pointer to this static function and the arguments to "fill in" when called. > So, a language which lack lambdas don't fully implement functions… It's hard to believe that you'd even say that, let alone get modded up for doing so. I find it hard to argue against, much like I would have difficulty arguing against someone who said that a country which lacked cars couldn't fully implement wheels. You see, what lambda lifting does is convert closures (which seem synonymous, at least in your writing, with lambdas) into ordinary functions with no free variables. Functions without free variables are more basic than functions with free variables.
  - loup-vaillant 16y ago
    When people talk about "genericness", or "generic programming" in front of me, the first example they give to me is the parametric polymorphism of the STL. It seems I underestimated you (again). But even if you know what you write, many people don't know what they read. Hence my up-mod. The fact that template are Turing complete doesn't hide the restrictions they come with (like how they interact with inheritance). I know they have others goals than mere parametric polymorphism. I even admit that I don't understand these goals. I just say that one goal wasn't met: simple parametric polymorphism. About lambda lifting being a (simple) syntactical transformation, please stop. You're right, but in a trivial sense: every compilation process is a (less simple) syntactical transformation. That includes lambda lifting, ghc's crazy optimizer, and every static compiler on this planet. Now, by "syntactic sugar", I meant something that could be dealt with with local macros. You know, I have done the transformation you speak of manually in C++. More than once. I know this is fairly simple. But it is not local. I still have to write something outside the definition of the function I am writing the closure in. So, to do lambda lifting, I need a more global preprocessor. The locality of the transformation may not be important to you, but to me, it is crucial. I don't mind some noise (semicolons, curly brackets, keywords…), because when used to it, I can see the actual code beneath it. However, the code has to be there. If I have to look up elsewhere, it quickly blows up my short term memory. Also, as long as the transformation is strictly local, you could deal with it with simple macros, like this: -- I assuume "closure" is a Lisp-like macro let x = let y = ... in closure arg1 arg2 (... body ...) So, a language without lambdas doesn't treat functions as first class citizens. That's what I meant by "doesn't fully implement functions". This is a strong wording, but I don't think it is inaccurate. Put the same restrictions on integers, and see if you can still say that they are "fully implemented". Did I overlooked something?
    - jemfinch 16y ago
      > When people talk about "genericness", or "generic programming" in front of me, the first example they give to me is the parametric polymorphism of the STL. The STL embodies (and accomplishes) far more than parametric polymorphism. As far as I know there is no other language with as comprehensive a collection of container-independent algorithms in the standard library. > The fact that template are Turing complete doesn't hide the restrictions they come with (like how they interact with inheritance). I know they have others goals than mere parametric polymorphism. I even admit that I don't understand these goals. I just say that one goal wasn't met: simple parametric polymorphism. And you're still wrong. Templates achieve parametric polymorphism and more. I can write a simple, templated, singly-linked list class in C++ which can do everything the same `'a list` in ML can do. > About lambda lifting being a (simple) syntactical transformation, please stop. You're right, but in a trivial sense: every compilation process is a (less simple) syntactical transformation. That includes lambda lifting, ghc's crazy optimizer, and every static compiler on this planet. I was making a greater claim that you seem to understand. Lambda lifting is a simple syntactical transformation. I can explain the entire transformation in a paragraph or less. I can offer example code of the transformation off the top of my head with ease. All lambda lifting does is make explicit what closures allow to remain implicit. Your following two paragraphs are a fairly obvious attempt to change your original, wrong statement into something defensible. > So, a language without lambdas doesn't treat functions as first class citizens. Ridiculous. A language without lambdas is just that: a language without lambdas. Remove lambda from Python, and you remove only the ability of a Python programmer to define unnamed functions. Functions remain first class; their binding rules remain exactly the same. The only difference is that now programmers must give a name to all their functions.

loup-vaillant 17y ago

> Generic programming, among other things. The proper CS name is "parametric polymorphism". This is not as special as "Generic programming". (What is special, is the abysmal C++ implementation of parametric polymorphism.) > Lambdas are functions without names. They're not important concepts, they're really just syntactical sugar. The transformation required to go from a higher order program to a first order one is called "lambda lifting". This goes way beyond syntactic sugar. So, a language which lack lambdas don't fully implement functions… which look like an important CS concept.

jemfinch 16y ago
> The proper CS name is "parametric polymorphism". No, it isn't. You would know this if you actually bothered to understand the terms you used rather than bandying them about in an attempt to win Internet points. Generic programming is a far broader topic than parametric polymorphism: that's why languages which already have parametric polymorphism, like Haskell, have variants which support true generic programming, like Generic Haskell and Scrap Your Boilerplate. > (What is special, is the abysmal C++ implementation of parametric polymorphism.) Given that you obviously don't understand the difference between run-of-the-mill parametric polymorphism and the generic programming enabled by C++ templates (and no other typed implementation except perhaps GADTs, and I remain unconvinced even of that) Id say you're fairly unqualified to be assessing the quality of C++'s implementation of parametric polymorphism. > The transformation required to go from a higher order program to a first order one is called "lambda lifting". This goes way beyond syntactic sugar. Wow, you really seem to enjoy using terms you clearly don't understand. No, lambda lifting doesn't "go way beyond syntactic sugar." It's actually a fairly simple syntactical transformation: the free variables in the function body are converted to arguments to a static function, and closures, when generated, are a simple data structure consisting of a pointer to this static function and the arguments to "fill in" when called. > So, a language which lack lambdas don't fully implement functions… It's hard to believe that you'd even say that, let alone get modded up for doing so. I find it hard to argue against, much like I would have difficulty arguing against someone who said that a country which lacked cars couldn't fully implement wheels. You see, what lambda lifting does is convert closures (which seem synonymous, at least in your writing, with lambdas) into ordinary functions with no free variables. Functions without free variables are more basic than functions with free variables.
- loup-vaillant 16y ago
  When people talk about "genericness", or "generic programming" in front of me, the first example they give to me is the parametric polymorphism of the STL. It seems I underestimated you (again). But even if you know what you write, many people don't know what they read. Hence my up-mod. The fact that template are Turing complete doesn't hide the restrictions they come with (like how they interact with inheritance). I know they have others goals than mere parametric polymorphism. I even admit that I don't understand these goals. I just say that one goal wasn't met: simple parametric polymorphism. About lambda lifting being a (simple) syntactical transformation, please stop. You're right, but in a trivial sense: every compilation process is a (less simple) syntactical transformation. That includes lambda lifting, ghc's crazy optimizer, and every static compiler on this planet. Now, by "syntactic sugar", I meant something that could be dealt with with local macros. You know, I have done the transformation you speak of manually in C++. More than once. I know this is fairly simple. But it is not local. I still have to write something outside the definition of the function I am writing the closure in. So, to do lambda lifting, I need a more global preprocessor. The locality of the transformation may not be important to you, but to me, it is crucial. I don't mind some noise (semicolons, curly brackets, keywords…), because when used to it, I can see the actual code beneath it. However, the code has to be there. If I have to look up elsewhere, it quickly blows up my short term memory. Also, as long as the transformation is strictly local, you could deal with it with simple macros, like this: -- I assuume "closure" is a Lisp-like macro let x = let y = ... in closure arg1 arg2 (... body ...) So, a language without lambdas doesn't treat functions as first class citizens. That's what I meant by "doesn't fully implement functions". This is a strong wording, but I don't think it is inaccurate. Put the same restrictions on integers, and see if you can still say that they are "fully implemented". Did I overlooked something?
  - jemfinch 16y ago
    > When people talk about "genericness", or "generic programming" in front of me, the first example they give to me is the parametric polymorphism of the STL. The STL embodies (and accomplishes) far more than parametric polymorphism. As far as I know there is no other language with as comprehensive a collection of container-independent algorithms in the standard library. > The fact that template are Turing complete doesn't hide the restrictions they come with (like how they interact with inheritance). I know they have others goals than mere parametric polymorphism. I even admit that I don't understand these goals. I just say that one goal wasn't met: simple parametric polymorphism. And you're still wrong. Templates achieve parametric polymorphism and more. I can write a simple, templated, singly-linked list class in C++ which can do everything the same `'a list` in ML can do. > About lambda lifting being a (simple) syntactical transformation, please stop. You're right, but in a trivial sense: every compilation process is a (less simple) syntactical transformation. That includes lambda lifting, ghc's crazy optimizer, and every static compiler on this planet. I was making a greater claim that you seem to understand. Lambda lifting is a simple syntactical transformation. I can explain the entire transformation in a paragraph or less. I can offer example code of the transformation off the top of my head with ease. All lambda lifting does is make explicit what closures allow to remain implicit. Your following two paragraphs are a fairly obvious attempt to change your original, wrong statement into something defensible. > So, a language without lambdas doesn't treat functions as first class citizens. Ridiculous. A language without lambdas is just that: a language without lambdas. Remove lambda from Python, and you remove only the ability of a Python programmer to define unnamed functions. Functions remain first class; their binding rules remain exactly the same. The only difference is that now programmers must give a name to all their functions.