Top all-time · #22858
Perl Alchemy
Personal blog · perlalchemy.blogspot.comprogrammingphilosophy
Perl Alchemy is a personal blog at perlalchemy.blogspot.com about programming and philosophy. Since 2008, 3 different Hacker News readers have linked it 14 times. The last post was in 2013, but the archive is still widely read.
What Hacker News says?
A bit shorter explanation from me: http://perlalchemy.blogspot.com/2011/05/bitcoin-protocol-hig... Not so detailed - but I think it covers the main mechanics.
Comment linking /2011/05/bitcoin-protocol-highlevel-explanation.html
on “How the Bitcoin protocol actually works”Submitted This cargo cult is rather effective in luring the cargo planes as a story · 7 points
HN discussionRecently I have been thinking a lot about Dependency Injection. It has clear benefits - like in testing - but there is also something that resonated with my preferences on a different level. It has been puzzling me for some time until I identified it - DI let's you code with less digressions: http://perlalchemy.blogspot.com/2011/10/concentration-and-fl...
Comment linking /2011/10/concentration-and-flow-or-yet-another.html
on “Confident Code”Submitted Thesis: simple - antythesis: easy - synthesis: ... | Agile & Rich Hickey as a story · 3 points
HN discussionA propos 'intuitiveness' and learnability - here is a great anecdote from 'Making Software', and my interpretation of it: http://perlalchemy.blogspot.com/2012/05/on-importance-of-int...
Comment linking /2012/05/on-importance-of-intuitive-names.html
on “API Design - Matt Gemmell”Submitted On Scaffoldings (in programming) as a story · 1 points
HN discussionI entirely agree with you - but I think the hardest thing is SPLITTING THINGS UP into coherent units that compose the lower level API you write about. The problem is that we can divide things in many possible ways - what makes one division better then the other? This is hard, layering is the easier part (but still far from obvious: http://perlalchemy.blogspot.com/2012/04/breaking-problems-do... ).
Comment linking /2012/04/breaking-problems-down-and-defaults.html
on “We Who Value Simplicity Have Built Incomprehensible Machines”The culprit of the 'ugly Perl' meme is the $ character, all the rest is just a rationalisation of the first impression: http://perlalchemy.blogspot.com/2011/01/is-responsible-for-u...
Comment linking /2011/01/is-responsible-for-ugliness-of-perl.html
on “A little thing to love about Perl 6 and COBOL”Kind of related: The usual pattern of a copy command: copy source destination The pattern of git push command push destination source:destination http://perlalchemy.blogspot.com/2011/04/git-push-and-other-c...
Comment linking /2011/04/git-push-and-other-copy-commands.html
on “Git 1.8.0”Just one point - the 'Where are your patches' attitude takes for granted that the implementation is more important than the design. This might be good approach at the beginning to bootstrap a library or language - but after it gains momentum then it becomes clear that API design is at least as important as the implementation of those APIs. And if design is important - then we need to accept that design critique is a…
Comment linking /2009/05/api-design.html
on “Oh Yeah? Where's Your Patches Zed?”It might look noisy - but it is just easier to parse in your head when you know what is a variable and what is a function or a keyword. I have came to believe that much of the 'Perl is ugly' notion comes from the fact that the $ character does not have nice typefaces ( http://perlalchemy.blogspot.com/2011/01/is-responsible-for-u... ).
Comment linking /2011/01/is-responsible-for-ugliness-of-perl.html
on “Why Did I Choose Perl When Building Crowdtilt?”First of all I don't care how a library is written - what I care is only its interface. Functional is more black box - if the abstraction suits you then it is great. OO is more manipulable, adaptable - you can override methods, set state etc. I also suspect that imperative programming is more natural (think cooking recipes and other instructions how to make something). In many cases the optimal solution is to provid…
Comment linking /2012/04/breaking-problems-down-and-defaults.html
on “Tell Above, and Ask Below: Hybridizing OO and Functional Design”Update: Removed the unnecessary and (as noted below) false remark about Joel not understanding Dependency Injection. The main (but not only) reason we have object factories is to be able to extract code suitable to be unit-tested from the whole application. And unit testing is like testing the tire of a car in a laboratory instead of testing the whole car on a race track. Not that we don't test cars on race tracks -…
Comment linking /2010/02/frameworks-are-framing-libraries-are.html
on “Why I Hate Frameworks (2005)”I've used Catalyst in the past, now at work I am stuck with CGI::Application and it seems rather OK, but still a little step back. At least in Catalyst it is natural to have multiple classes (each for one controller) - while the app being developed here ended up as one huge application class. But really the more imporatant part of the decision is what templating and ORM to use. I have a blog post on that: http://per…
Comment linking /2008/10/progress.html
on “Ask HN: Web Frameworks for Perl”