20 ms·

From the top comment: > Yoneda-crazy: I know Haskell, I know some category theory, but I am highly sceptical that teaching the Yoneda Lemma to C++ programmers

From the top comment: > Yoneda-crazy: I know Haskell, I know some category theory, but I am highly sceptical that teaching the Yoneda Lemma to C++ programmers is actually useful in any way. This is infuriatingly true. Everything you do in Haskell you can understand in terms of what code gets executed where and how. This is just as true of Haskell as it is of any other high-level language. Indeed, you can take an arbitrary Haskell program, and rewrite it in C with the same semantics, and all you'll learn is how GHC's runtime is implemented and how it executes your program. For a small concise program, this actually makes for a nice exercise. I don't know why, but people sometimes seem to think the runtime is "magic".

pjmlp 11y ago
> I don't know why, but people sometimes seem to think the runtime is "magic". Apparently somewhere in the last 20 years people stopped learned about how compilers work. That knowledge is now kept by the few druids that possess the abilities to read the old runes and release the enchantments that reside in them.
- tormeh 11y ago
  At my school (NTNU) there's even talk of removing the compiler course. It's a ye-olde write-a-compiler-for-a-c-like-language-in-c course ("the cs students should learn C at some point "), which I find all kinds of wrong, but it's still sad.
  - pjmlp 11y ago
    Just checked NTNU.I've spent sometime in Trondheim when doing consulting for NetCom, nice city. My university (FCT/UNL) had a strong focus in language design, data structures and systems programming back in the 90's as part of the compulsory lectures, with everything else being optional credits.
  - cousin_it 11y ago
    Just curious, what's wrong with writing a compiler for a C-like language in itself? It seems to me that one of the goals of a compiler course is to fill the mysterious gap between what machines do and what high-level languages do. For maximum educational effect, the language being compiled should be the same as the language used for the compiler. Anything higher level than C would probably require a runtime, with garbage collection etc., so a C-like language seems like the obvious sweet spot.
    - tormeh 11y ago
      Well, because writing a compiler is pretty hard, and I would like to not juggle pointers to arrays of pointers while doing it. C wastes your time, basically. And a C-like language is profoundly unexciting, at least to me; I can almost see the assembly lying underneath.
      - kbenson 11y ago
        Well, they could write a list in python, but that's more a single night's homework than an entire class (with the appropriate foreknowledge) to my understanding, so what's an interesting middle ground? A logical language (e.g. Prolog) would be interesting, but I have no idea the complexities involved. I imagine implementing in python would reduce the complexities of the actual programming step allowing more time for what I think are the interesting parts of a compiler course.
      - cousin_it 11y ago
        What would you propose instead? Which language is easy enough to compile, and pleasant enough to write a compiler in?
        pjmlp 11y ago
        Lisp derived languages are quite easy to implement, e.g. "An Incremental Approach to Compiler Construction" paper. Wirth has published compiler books based on Pascal and Oberon, quite simple single pass implementations. The language proposed by the Tiger book variants (a ML like language) is also quite simple to implement.
rtpg 11y ago
At least for me, coming from an imperative language OCaml's runtime seemed like magic. But I know now that it's only because I was comparing OCaml to C. I think getting lost in the implementation details is what gets many Haskell learners, because the majority know an imperative language and use it as the base.
- toolslive 11y ago
  https://en.wikipedia.org/wiki/Clarke's_three_laws https://en.wikipedia.org/wiki/Clarke's_three_laws Law number 3.
kzhahou 11y ago
Personally I find category theory to be a red herring when it comes to Haskell and really programming. I feel that people learn a bit of CT, then quote it endlessly as a sort of elevation of programming from lowly code-slinging to a high mathematical pursuit. Except CT doesn't really provide all that much insight. At least not unless you're knee-deep in advanced type theory. But who has really read Benjamin Pierce's books (as beautiful as they are), or the original Hindley texts? A side comment, this one's more about CT itself, is that the standard texts don't seem to really have many results. Not compared to, say, any undergrad book on algebra or number theory, where cool theorems come at you every few pages to twist up your brain. Category Theory always felt almost mechanical to me. Lots of definitions and rules for assembling diagrams and such, but then what. Just the Yoneda Lemma and that's it? If anyone can point me to the fun CT theorems, I'd love to hear about them.
- nabla9 11y ago
  >CT itself, is that the standard texts don't seem to really have many results. Oh man. If you like math, CT gives nice mathematical definitions for stuff. I would love to use my algebra skills to do general programming like I can use my linear algebra knowledge in numerical programming. I'm making bold claim that I hope someone can debunk with awesome counterexamples: "CT HAS ZERO APPLICABILITY IN PROGRAMMING" Using CT to Linear algebra analogy: CT in programming is like learning definitions of vector spaces, subspaces, span, and basis and stopping there. No CT equivalent for solving linear systems, linear transformations, least-squares or eigenvalues. Just because you have rooted programming in cool algebraic notation does not mean anything in itself.
  - pron 11y ago
    This is a kind of marketing trick Haskell has pulled, which some people fall for (regardless of the merits of the language), namely that Haskell is somehow more "mathematical" than other languages. The truth is that Haskell -- like all programming language -- has made a design choice, which was to bake in correctness proofs based on the Curry-Howard correspondence into the language. This means that instead of bringing the math to your program like other verification methods do[1], it takes you to the math, requiring your participation. Haskell just feels more mathy because C-H puts the math in your face. Another trick Haskell uses is preferring abstractions that are based on concepts from CT[2], and validating the utility of those abstractions on their "rigorous mathematical foundations". This is again just another case of taking you to the math rather than the other way around. Programming languages are first and foremost human languages, meant to be written and read by humans. As such, their power is drawn from a single source: their interaction with human cognition. Whether an abstraction is "mathematical" (whatever that means) has absolutely no relevance to its power, which comes from cognition (and psychology in general) rather than math. All this "in your face" math does is make the machine's job of verifying your software easier. A Haskeller tried convincing me that such a language is a good fit for human programmers, too, because all it is is a subset of more traditional, impure languages. But the notion of subset => simpler is a mathematical notion with no relevance to cognition. If humans operated in this way, natural languages would have been much more mathematically simpler, too. [1]: See KeY: http://www.key-project.org/ http://www.key-project.org/ [2]: To be fair, I'm not sure that Haskell, given its original design philosophy, has much choice in the matter.
tel 11y ago
> This is infuriatingly true. Everything you do in Haskell you can understand in terms of what code gets executed where and how. This is just as true of Haskell as it is of any other high-level language. I think anyone who really understands what they're talking about (which is, admittedly, not everyone who talks, sometimes loudly) would happily agree with you and then wonder what we were arguing about :) Haskell tries to take the line that the "compilation semantics" are second class citizens to the "equational semantics". A lot of the technology Haskell introduces is in some way or another directly aimed at this. It doesn't, however, mean that the compilation (or operational, though that word gets abused and won't take you where you want to go exactly if you google it) semantics isn't totally valid, interesting in it's own right, and a useful thing to study. Some of the core-er Haskellers like to write about this stuff too. I particularly love Edward Yang's posts on the Haskell Heap http://blog.ezyang.com/2011/04/the-haskell-heap/ But all that said, the reason for having the compilation semantics take a back seat is not because it's unimportant but instead because if you don't intentionally take that stance then it, due to its front-and-center role in executing your language, will become dominant. What we really want is a language with many compatible and well-developed choices of semantics! Then we can pick and choose our reasoning tools on the fly and know that we won't be led astray by small (or vast) incompatibilities. It turns out this is tremendously difficult. It's also important to note that Haskell only does a so-so job at it. Interestingly, this makes it one of the absolute best examples of any large language pulling it off. SML probably takes the cake depending on what flavos you're interested in, though.
- kbenson 11y ago
  > What we really want is a language with many compatible and well-developed choices of semantics! So, Perl6. > It turns out this is tremendously difficult. Yep.
  - tel 11y ago
    Tbh, I have never looked at Perl 6. But I know it was written from the influence of Haskell so... quite possibly!
    - 11y ago
marcosdumay 11y ago
That's the definition of a Turing complete language. What I dislike the most is that the Haskell execution order in particular isn't hard to reason about[+]. Yet, because it's things don't simply happen in the order you write them, people tell beginners to not think about execution order at all, and wait until laziness bite them. [+] Really. If you just assume that the only things that gets evaluated is the first argument of the IO monad (>>) operator (not (>>=)), and it pulls evaluation until it gets all the data it needs, you'll have 99.9% of the model done. Read about GHC green threads and the FFI and you'll get everything that does not use unsafePerformIO right.

pjmlp 11y ago

> I don't know why, but people sometimes seem to think the runtime is "magic". Apparently somewhere in the last 20 years people stopped learned about how compilers work. That knowledge is now kept by the few druids that possess the abilities to read the old runes and release the enchantments that reside in them.

tormeh 11y ago
At my school (NTNU) there's even talk of removing the compiler course. It's a ye-olde write-a-compiler-for-a-c-like-language-in-c course ("the cs students should learn C at some point "), which I find all kinds of wrong, but it's still sad.
- pjmlp 11y ago
  Just checked NTNU.I've spent sometime in Trondheim when doing consulting for NetCom, nice city. My university (FCT/UNL) had a strong focus in language design, data structures and systems programming back in the 90's as part of the compulsory lectures, with everything else being optional credits.
- cousin_it 11y ago
  Just curious, what's wrong with writing a compiler for a C-like language in itself? It seems to me that one of the goals of a compiler course is to fill the mysterious gap between what machines do and what high-level languages do. For maximum educational effect, the language being compiled should be the same as the language used for the compiler. Anything higher level than C would probably require a runtime, with garbage collection etc., so a C-like language seems like the obvious sweet spot.
  - tormeh 11y ago
    Well, because writing a compiler is pretty hard, and I would like to not juggle pointers to arrays of pointers while doing it. C wastes your time, basically. And a C-like language is profoundly unexciting, at least to me; I can almost see the assembly lying underneath.
    - kbenson 11y ago
      Well, they could write a list in python, but that's more a single night's homework than an entire class (with the appropriate foreknowledge) to my understanding, so what's an interesting middle ground? A logical language (e.g. Prolog) would be interesting, but I have no idea the complexities involved. I imagine implementing in python would reduce the complexities of the actual programming step allowing more time for what I think are the interesting parts of a compiler course.
    - cousin_it 11y ago
      What would you propose instead? Which language is easy enough to compile, and pleasant enough to write a compiler in?
      - pjmlp 11y ago
        Lisp derived languages are quite easy to implement, e.g. "An Incremental Approach to Compiler Construction" paper. Wirth has published compiler books based on Pascal and Oberon, quite simple single pass implementations. The language proposed by the Tiger book variants (a ML like language) is also quite simple to implement.

rtpg 11y ago

At least for me, coming from an imperative language OCaml's runtime seemed like magic. But I know now that it's only because I was comparing OCaml to C. I think getting lost in the implementation details is what gets many Haskell learners, because the majority know an imperative language and use it as the base.

toolslive 11y ago
https://en.wikipedia.org/wiki/Clarke's_three_laws https://en.wikipedia.org/wiki/Clarke's_three_laws Law number 3.

kzhahou 11y ago

Personally I find category theory to be a red herring when it comes to Haskell and really programming. I feel that people learn a bit of CT, then quote it endlessly as a sort of elevation of programming from lowly code-slinging to a high mathematical pursuit. Except CT doesn't really provide all that much insight. At least not unless you're knee-deep in advanced type theory. But who has really read Benjamin Pierce's books (as beautiful as they are), or the original Hindley texts? A side comment, this one's more about CT itself, is that the standard texts don't seem to really have many results. Not compared to, say, any undergrad book on algebra or number theory, where cool theorems come at you every few pages to twist up your brain. Category Theory always felt almost mechanical to me. Lots of definitions and rules for assembling diagrams and such, but then what. Just the Yoneda Lemma and that's it? If anyone can point me to the fun CT theorems, I'd love to hear about them.

nabla9 11y ago
>CT itself, is that the standard texts don't seem to really have many results. Oh man. If you like math, CT gives nice mathematical definitions for stuff. I would love to use my algebra skills to do general programming like I can use my linear algebra knowledge in numerical programming. I'm making bold claim that I hope someone can debunk with awesome counterexamples: "CT HAS ZERO APPLICABILITY IN PROGRAMMING" Using CT to Linear algebra analogy: CT in programming is like learning definitions of vector spaces, subspaces, span, and basis and stopping there. No CT equivalent for solving linear systems, linear transformations, least-squares or eigenvalues. Just because you have rooted programming in cool algebraic notation does not mean anything in itself.
- pron 11y ago
  This is a kind of marketing trick Haskell has pulled, which some people fall for (regardless of the merits of the language), namely that Haskell is somehow more "mathematical" than other languages. The truth is that Haskell -- like all programming language -- has made a design choice, which was to bake in correctness proofs based on the Curry-Howard correspondence into the language. This means that instead of bringing the math to your program like other verification methods do[1], it takes you to the math, requiring your participation. Haskell just feels more mathy because C-H puts the math in your face. Another trick Haskell uses is preferring abstractions that are based on concepts from CT[2], and validating the utility of those abstractions on their "rigorous mathematical foundations". This is again just another case of taking you to the math rather than the other way around. Programming languages are first and foremost human languages, meant to be written and read by humans. As such, their power is drawn from a single source: their interaction with human cognition. Whether an abstraction is "mathematical" (whatever that means) has absolutely no relevance to its power, which comes from cognition (and psychology in general) rather than math. All this "in your face" math does is make the machine's job of verifying your software easier. A Haskeller tried convincing me that such a language is a good fit for human programmers, too, because all it is is a subset of more traditional, impure languages. But the notion of subset => simpler is a mathematical notion with no relevance to cognition. If humans operated in this way, natural languages would have been much more mathematically simpler, too. [1]: See KeY: http://www.key-project.org/ http://www.key-project.org/ [2]: To be fair, I'm not sure that Haskell, given its original design philosophy, has much choice in the matter.

tel 11y ago

> This is infuriatingly true. Everything you do in Haskell you can understand in terms of what code gets executed where and how. This is just as true of Haskell as it is of any other high-level language. I think anyone who really understands what they're talking about (which is, admittedly, not everyone who talks, sometimes loudly) would happily agree with you and then wonder what we were arguing about :) Haskell tries to take the line that the "compilation semantics" are second class citizens to the "equational semantics". A lot of the technology Haskell introduces is in some way or another directly aimed at this. It doesn't, however, mean that the compilation (or operational, though that word gets abused and won't take you where you want to go exactly if you google it) semantics isn't totally valid, interesting in it's own right, and a useful thing to study. Some of the core-er Haskellers like to write about this stuff too. I particularly love Edward Yang's posts on the Haskell Heap http://blog.ezyang.com/2011/04/the-haskell-heap/ But all that said, the reason for having the compilation semantics take a back seat is not because it's unimportant but instead because if you don't intentionally take that stance then it, due to its front-and-center role in executing your language, will become dominant. What we really want is a language with many compatible and well-developed choices of semantics! Then we can pick and choose our reasoning tools on the fly and know that we won't be led astray by small (or vast) incompatibilities. It turns out this is tremendously difficult. It's also important to note that Haskell only does a so-so job at it. Interestingly, this makes it one of the absolute best examples of any large language pulling it off. SML probably takes the cake depending on what flavos you're interested in, though.

kbenson 11y ago
> What we really want is a language with many compatible and well-developed choices of semantics! So, Perl6. > It turns out this is tremendously difficult. Yep.
- tel 11y ago
  Tbh, I have never looked at Perl 6. But I know it was written from the influence of Haskell so... quite possibly!
  - 11y ago

marcosdumay 11y ago

That's the definition of a Turing complete language. What I dislike the most is that the Haskell execution order in particular isn't hard to reason about[+]. Yet, because it's things don't simply happen in the order you write them, people tell beginners to not think about execution order at all, and wait until laziness bite them. [+] Really. If you just assume that the only things that gets evaluated is the first argument of the IO monad (>>) operator (not (>>=)), and it pulls evaluation until it gets all the data it needs, you'll have 99.9% of the model done. Read about GHC green threads and the FFI and you'll get everything that does not use unsafePerformIO right.