3 ms·

Light Table is such a koan, created by a master of the path of living-memory-image reflective systems Two answers. 1) So then someone should create a Haskell K

Light Table is such a koan, created by a master of the path of living-memory-image reflective systems Two answers. 1) So then someone should create a Haskell Koan which has just as much popular appeal and broad intuitive popular understanding. But then again, not really, because: 2) Really, get off of this Koan nonsense. It was really just a very well thought out and effective demo which chose exactly the right way to get across the benefits of such a system. Whereas, in Smalltalk itself, the seams aren't visible, because the system is coherent. Oh, there are seams! And warts! Indeed, it is the rare software engineer who actually experienced any paradigm shifts regarding Computer Science Really? It sounds like you haven't experienced too many of those kinds of paradigm shifts. All you know is the math-y kind. Haskell's design and ecosystem "reflects" enlightenment on category theory, somewhat like Smalltalk "reflects" enlightenment on living-memory-image OOP. Neither system teaches those skills, though. Absolutely wrong. If you delve into the Smalltalk image and class library, it does teach you OOP! The long and short of the way to communicate all the Haskell "stuff" efficiently, not just monads, is to: 1. give the learner the meta-skill... 2. throw a Category Theory textbook at the learner... Either put up or shut up. Anyone can have an esoteric uber language off in a corner somewhere and tell themselves the world misunderstands them while circle jerking with like minded folks. Been there, done that. The whole world is chok full of little groups like that. Stopping at just that is not that which makes a difference in the world. What you are saying seems to amount to: "We're awesome! We're the superior learners, which is why we're superior, but alas poor us, it also makes us suck at teaching." I call BS. It doesn't matter if your tools are superior, if their qualities and the community's qualities make them inherently inferior at gaining mindshare. Either they're so superior, everyone will take the time to adopt them, or they're not so superior that it really matters that much. Try and produce stuff. Try and reach people. The world will see who succeeds. Simple as that.

derefr 8y ago
> It sounds like you haven't experienced too many of those kinds of paradigm shifts. All you know is the math-y kind. You know that HN readers are about the 99th percentile of "willingness to learn random new CS concepts", right? Most programmers know one language. In fact, most programmers have only ever worked for one company, on one product, for their whole productive careers so far. Your idea of an "average" programmer is, in fact, a rare programmer. > If you delve into the Smalltalk image and class library, it does teach you OOP! That is the exact equivalent of reading a textbook on the subject, except it's not presented in prerequisite order, so it's slightly harder to digest. A system that teaches is a system that allows you to notice the micro-skills you're missing faster than a textbook. A textbook is the brute-force approach. Smalltalk is not a system that teaches. It's just a system. You can get out what you put into delving through it, but you can do that just as well with any random system. To be pedagogical, a system has to accelerate that process. > We're awesome! We're the superior learners, which is why we're superior, but alas poor us, it also makes us suck at teaching. Er, no: people that "know Haskell" (category theory) generally suck at teaching Haskell (category theory) because people suck at teaching by default, because they haven't learned the meta-skill of teaching. And even those that do, haven't yet put in the effort to factor their mental-model of a given skill to turn it into a teachable skill. The people that can teach you something about Haskell (category theory), are, y'know, teachers, that have learned Haskell (category theory) and then applied educational principles to their understanding of it in order to be able to teach it well. Has nothing to do with Haskell, other than Haskell actually having a relatively-difficult skill in it for people coming from a SwEng background to learn. Other languages are easier or harder for such people to learn, because the skills they require are more or less natural given a SwEng background; and, comparatively, people with a CS or Physics or Electrical Engineering background have other backgrounds that make different languages have a different skill-gulf. Haskell (category theory) is easy for mathematicians. Assembly is easy for electrical engineers. Prolog is easy for DB systems programmers. Etc. Nothing special about any of them—they're just different points in knowledge-space, that different people start out closer or further from because of their backgrounds. > Try and produce stuff. I do! Not in Haskell, though. Despite writing the above, I have literally never used Haskell once in my life. I'm just talking about it as a specific application of the general principle of skill-gulfs. > Try and reach people. Why? In all of the above, nobody ever said why anyone is trying to teach anyone else monads. Honestly, I think people just shouldn't bother. No "amateur teacher" is attempting to teach anyone else graph theory, or linear algebra, or the x86 ISA. Professional teachers, at universities, do that, because those are skills independent of any programming language. People generally understand that teaching these skills is the job of professional teachers, and that you have to apply yourself as a student, full-time, to learn them. Well, category theory is such a skill. In short: stop trying to teach people monads. Petition more schools to teach people monads (category theory), outside of the context of any particular language. Then Haskell is just a language, with no skill gulf. To say that you should "reach people" with an explanation of monads, is like expecting RDBMS docs to "reach people" with an explanation of relational algebra. It's not their job. You're supposed to come in with that skill. Their job is to provide you a thing that you know you want—a solution for a problem you know you have—given that the skills you already possess give you the ability to evaluate that solution.

derefr 8y ago

> It sounds like you haven't experienced too many of those kinds of paradigm shifts. All you know is the math-y kind. You know that HN readers are about the 99th percentile of "willingness to learn random new CS concepts", right? Most programmers know one language. In fact, most programmers have only ever worked for one company, on one product, for their whole productive careers so far. Your idea of an "average" programmer is, in fact, a rare programmer. > If you delve into the Smalltalk image and class library, it does teach you OOP! That is the exact equivalent of reading a textbook on the subject, except it's not presented in prerequisite order, so it's slightly harder to digest. A system that teaches is a system that allows you to notice the micro-skills you're missing faster than a textbook. A textbook is the brute-force approach. Smalltalk is not a system that teaches. It's just a system. You can get out what you put into delving through it, but you can do that just as well with any random system. To be pedagogical, a system has to accelerate that process. > We're awesome! We're the superior learners, which is why we're superior, but alas poor us, it also makes us suck at teaching. Er, no: people that "know Haskell" (category theory) generally suck at teaching Haskell (category theory) because people suck at teaching by default, because they haven't learned the meta-skill of teaching. And even those that do, haven't yet put in the effort to factor their mental-model of a given skill to turn it into a teachable skill. The people that can teach you something about Haskell (category theory), are, y'know, teachers, that have learned Haskell (category theory) and then applied educational principles to their understanding of it in order to be able to teach it well. Has nothing to do with Haskell, other than Haskell actually having a relatively-difficult skill in it for people coming from a SwEng background to learn. Other languages are easier or harder for such people to learn, because the skills they require are more or less natural given a SwEng background; and, comparatively, people with a CS or Physics or Electrical Engineering background have other backgrounds that make different languages have a different skill-gulf. Haskell (category theory) is easy for mathematicians. Assembly is easy for electrical engineers. Prolog is easy for DB systems programmers. Etc. Nothing special about any of them—they're just different points in knowledge-space, that different people start out closer or further from because of their backgrounds. > Try and produce stuff. I do! Not in Haskell, though. Despite writing the above, I have literally never used Haskell once in my life. I'm just talking about it as a specific application of the general principle of skill-gulfs. > Try and reach people. Why? In all of the above, nobody ever said why anyone is trying to teach anyone else monads. Honestly, I think people just shouldn't bother. No "amateur teacher" is attempting to teach anyone else graph theory, or linear algebra, or the x86 ISA. Professional teachers, at universities, do that, because those are skills independent of any programming language. People generally understand that teaching these skills is the job of professional teachers, and that you have to apply yourself as a student, full-time, to learn them. Well, category theory is such a skill. In short: stop trying to teach people monads. Petition more schools to teach people monads (category theory), outside of the context of any particular language. Then Haskell is just a language, with no skill gulf. To say that you should "reach people" with an explanation of monads, is like expecting RDBMS docs to "reach people" with an explanation of relational algebra. It's not their job. You're supposed to come in with that skill. Their job is to provide you a thing that you know you want—a solution for a problem you know you have—given that the skills you already possess give you the ability to evaluate that solution.