6 ms·

> But it actually has some truth in programming. I've learned a few programming languages over the years and I generally accept the Blub Paradox (right now I'm

• btilly 17y ago
  I will never forget the brain lock I encountered the first time I had to deal with a relatively small program that made extensive use of closures. In hindsight the program was well-designed and clearly written. Yet I simply could not understand it for over at least half an hour. And even once I did figure it out, it took days before I could truly digest what made that design work. A couple of years later on the Perl 5 core mailing list I responded to a claim that a good Perl programmer could support any well-written Perl program with a key line from that program. From the volume of the squawks I got, a collection of good Perl programmers generally were not prepared to understand that code, despite years of experience in a language that fully supported closures. I will not claim that it is impossible to imagine effective closures. I know there are people who are far more intelligent than me, who think very differently than I do. If history played out again a few times, perhaps it would play out differently. But I say without false modesty that I'm a significantly above average programmer, and I am convinced that I personally could not have come up with effective closures on my own. And I've known quite a few good programmers who I am sure could not have done it. And I've never personally known anyone who has left me convinced that they could have done it. And finally the history of how closures were invented does not support the idea that someone imagined what could be done with them and then invented them for that reason.
  • RyanMcGreal 17y ago
    > the history of how closures were invented does not support the idea that someone imagined what could be done with them and then invented them for that reason. Most really interesting and disruptive inventions are at least partially accidental. Ideas rarely spring fully formed; instead they appear through cross-fertilization, recombination and serendipity. Once the idea is there, we invent whatever models and languages are necessary to describe and implement it. That process can be comprehensive and all-at-once but more often is iterative and progressive. Even radical innovations that seem to spring fully formed did so after long gestation outside public view.
  • eru 17y ago
    Thanks. An interesting story. About your last paragraph: What's so special about closures? They have been in lambda-calculus for ages. And lambda-calculus just formalizes mathematicial function application and abstraction. (OK, I guess most mathematicians are not aware of lexical scoping. But it springs naturally from alpha equivalence, a notion that every mathematician agrees with intuitively.) Of course coming up with the mathematical ideas and notations in the first place wasn't easy. But closures pre-date computers. The computer scientists `just' had to find ways to implement them effectively.
    • deleted 17y ago
      [deleted]
    • btilly 17y ago
      My answer is that what's special about closures is that if you actually structure your program around using them, then you reorganize how you design things in a somewhat surprising way.
      • eru 17y ago
        I agree. It's similar with Monads, Arrows, Functors. They have been around far ages in category theory, but only recently have some of us begun to structure our programs around them.
  • mquander 17y ago
    I would be interested if you can present a specific piece of code that would be really confusing to a programmer who does not have experience using languages with lexical closures. I didn't follow the same order of education, so I never really experienced an a-ha moment like that; they seem like a simple language construct to me (although I can definitely understand how it would be hard to recognize their utility without having experience using them.) (I can understand how code passing around anonymous functions can be confusing to people who don't use a language with first-class functions, but I would figure they're confused by the logic, not by the closures.)
    • btilly 17y ago
      The line I presented to p5p went something like this: print join "\t", map {$format[$_]->($row[$_])} 0..$#format; http://www.perlmonks.org/index.pl?node_id=34786 http://www.perlmonks.org/index.pl?node_id=34786 has a longer code example which I used to introduce some idea of what closures could be useful for to a lot of Perl programmers.
• philh 17y ago
  Not impossible, but it would have been harder. If you did succeed in thinking about them, it seems likely that along the way you would invent a language that supported them. By that I mean you would have developed notation to write your thoughts down compactly. You wouldn't need to implement the language. There was nothing to stop people from doing calculus pre-Newton. But doing calculus without the language (theorems and definitions) of calculus would be hard. Once Newton had provided the language, it became something high school students could learn. (Historical accuracy not guaranteed, but I hope it illustrates my point.)
  • btilly 17y ago
    Historical note. Newton invented Calculus then carefully found other ways to regenerate the results he got that way. The language of Calculus that we have was separately invented by Leibniz. The subject of the first big priority dispute was whether Leibniz' invention of Calculus was independent, or was obtained from the traces of it left in the Principia.
  • brlewis 17y ago
    That fits my experience. In the 1980s as a teenager I programmed in BASIC. I read a magazine article about generating mazes. I couldn't wrap my head around the algorithm. Later I learned Forth. After that, the algorithm made sense, because I finally had a language in my head suitable for recursion.
• Retric 17y ago
  Once you build a generic structure it's easy to find it far more powerful than you first expected. IMO, this is the secret of all great programmers.