Closure, from why the lucky stiff (2013)(github.com)
github.com
Closure, from why the lucky stiff (2013)
https://github.com/steveklabnik/CLOSURE
148 comments
Honestly at the time I remember getting weird twee/precious vibes from the Ruby community and I wasn't particularly interested in it or Rails. I only discovered _why's poignant guide later after I had to learn Rails on the job, and to be honest I never finished it.
I still strongly prefer the worldview, circumstances, mindset, etc. where that kind of content is written, read, and celebrated over today's focus on Influence and Professionalism.
I still strongly prefer the worldview, circumstances, mindset, etc. where that kind of content is written, read, and celebrated over today's focus on Influence and Professionalism.
I actually knew _why's real identity, but I refused to divulge it partly because I didn't want his performance to end (even though, sadly, I knew it couldn't last forever) and partly because _why is a fellow native of my home state of Pennsylvania. And I totally agree that his whimsical style is far more preferable than anything every written by any LinkedIn programming "influencer."
I seem to remember multiple incidents where Rails programmers complained that everyone at the conference they went to was playing Werewolf instead of sticking to the topic. It made me wonder what kind of community would lead to that.
As for _why, there is nothing special about him. If you need an overly precious twee white guy, we have a natural source of them called the city of Portland. You can go find another ten of them there. They have waxed mustaches and are running combination coffee bars and thrift stores.
As for _why, there is nothing special about him. If you need an overly precious twee white guy, we have a natural source of them called the city of Portland. You can go find another ten of them there. They have waxed mustaches and are running combination coffee bars and thrift stores.
> As for _why, there is nothing special about him
That sounds patently false to me considering we're still talking about him almost 20 years after his flagship work was published.
Minimizing _why because of a tired, narrow-minded focus on identity politics seems disingenuous and like a missed opportunity to learn
That sounds patently false to me considering we're still talking about him almost 20 years after his flagship work was published.
Minimizing _why because of a tired, narrow-minded focus on identity politics seems disingenuous and like a missed opportunity to learn
That's because the rest of them are working in other fields (combination coffee bars, thrift stores and barber shops.) I am proposing hiring them as tech writers instead.
Also, I don't think identity politics particularly have anything to do with it. (Japanese people are even more hipster than Portlanders and of course invented Ruby, so you could probably find some of them too for diversity. The aesthetic would be different though because of cultural differences.)
Also, I don't think identity politics particularly have anything to do with it. (Japanese people are even more hipster than Portlanders and of course invented Ruby, so you could probably find some of them too for diversity. The aesthetic would be different though because of cultural differences.)
[deleted]
> They have waxed mustaches and are running combination coffee bars and thrift stores.
Ah, has Portland moved on from keeping alive the Dream Of The 90s to the Dream Of The Late 2000s?
Ah, has Portland moved on from keeping alive the Dream Of The 90s to the Dream Of The Late 2000s?
For reference,
https://youtu.be/TZt-pOc3moc
https://youtu.be/TZt-pOc3moc
I don't think that's true at all. If you go back and read his stuff, it ages pretty well in my estimation, largely because _why was apolitical. And he was way more informed by good humanities sources than any average Portland woke hipster.
> largely because _why was apolitical
ahahahahahha
ahahahahahha
> largely because _why was apolitical.
I mean, he is pretty expressly anticapitalist in this work. The name "why the lucky stiff" is found in Rand. _why was regularly political, though it wasn't always a focus of his.
I mean, he is pretty expressly anticapitalist in this work. The name "why the lucky stiff" is found in Rand. _why was regularly political, though it wasn't always a focus of his.
[deleted](1)
I don't.
Even in the terms of the false dichotomy you've constructed here, I would much rather participate in a community of professionals who've organized themselves around sufficiently overlapping shared intents, than one accreted around the kind of twee, precious narcissism that characterized the early days of Ruby and Rails.
That comparison is informed by direct experience with both, and is the precise reason why my professional experience with both the language and the platform will to my dying day consist of one successful project a few months long.
A good professional community supports a wide variety of learning styles and levels of engagement, and tends to make a lot of resources easy to find for anyone who's willing to put in a little effort of research. The early Ruby and Rails communities did the exact opposite of this. Between "_why"'s guide serving a primary-reference role to which it is manifestly ill suited, and nobody much bothering to document anything effectively outside that, figuring out how to work with their garbage software was like pulling teeth - especially because, in a language constructed as a farrago of the worst ideas from Perl, Smalltalk, and Common Lisp, even reading the source is anything but a guarantee of understanding.
The structural exclusivity alone was bad enough, but the behavior of community leaders quickly demonstrated that the exclusivity was the point. That the "Poignant Guide" should be considered acceptable as primary documentation implies that the function of selecting for people willing to put up with that kind of nonsense was intended - maybe not as a matter of explicit design, although this would not surprise me, but "the purpose of a system is what it does". This system was created by narcissists to select for acolytes, and while I wouldn't quite call it a cult, neither am I prepared to say those who have are entirely wrong. And if it was a cult, it was a stupid cult, because Ruby is a language that makes programmers worse and Rails was never good technology; its sole unqualified success lies in having inspired software engineers to do similar things in better ways.
I'm sure by now I've upset some folks; there are some for whom no criticism of Ruby, Rails, or their leading lights can fail to read as a personal attack. If that's you who's reading this now, all I can say is this shows the difference between us: if you're cut out to be an acolyte, fine, go to it! I would rather be a practitioner in a community of practice. Granted this means my technical documentation comes without cartoon foxes and a level of pretense suited to an early 2000s Abercrombie catalog, but for documentation that actually documents that's a trade I'm happy to make.
Even in the terms of the false dichotomy you've constructed here, I would much rather participate in a community of professionals who've organized themselves around sufficiently overlapping shared intents, than one accreted around the kind of twee, precious narcissism that characterized the early days of Ruby and Rails.
That comparison is informed by direct experience with both, and is the precise reason why my professional experience with both the language and the platform will to my dying day consist of one successful project a few months long.
A good professional community supports a wide variety of learning styles and levels of engagement, and tends to make a lot of resources easy to find for anyone who's willing to put in a little effort of research. The early Ruby and Rails communities did the exact opposite of this. Between "_why"'s guide serving a primary-reference role to which it is manifestly ill suited, and nobody much bothering to document anything effectively outside that, figuring out how to work with their garbage software was like pulling teeth - especially because, in a language constructed as a farrago of the worst ideas from Perl, Smalltalk, and Common Lisp, even reading the source is anything but a guarantee of understanding.
The structural exclusivity alone was bad enough, but the behavior of community leaders quickly demonstrated that the exclusivity was the point. That the "Poignant Guide" should be considered acceptable as primary documentation implies that the function of selecting for people willing to put up with that kind of nonsense was intended - maybe not as a matter of explicit design, although this would not surprise me, but "the purpose of a system is what it does". This system was created by narcissists to select for acolytes, and while I wouldn't quite call it a cult, neither am I prepared to say those who have are entirely wrong. And if it was a cult, it was a stupid cult, because Ruby is a language that makes programmers worse and Rails was never good technology; its sole unqualified success lies in having inspired software engineers to do similar things in better ways.
I'm sure by now I've upset some folks; there are some for whom no criticism of Ruby, Rails, or their leading lights can fail to read as a personal attack. If that's you who's reading this now, all I can say is this shows the difference between us: if you're cut out to be an acolyte, fine, go to it! I would rather be a practitioner in a community of practice. Granted this means my technical documentation comes without cartoon foxes and a level of pretense suited to an early 2000s Abercrombie catalog, but for documentation that actually documents that's a trade I'm happy to make.
It must have been awful when you were forced to engage with a whimsical community like that. I mean...I'm assuming you were forced, because why else would you harbor so much bitterness over the fact that there were once some people who did things differently than you would have liked?
Come now. Surely you can find something to criticize in what I've actually said, without needing to resort to footless inference about my person.
Your long rant is not actually interesting or factual enough to criticise in detail.
I’m only writing this reply to point out that you have already engaged in a lot of making footless inference about other people’s person, so please don’t be surprised if the same is done to you.
I’m only writing this reply to point out that you have already engaged in a lot of making footless inference about other people’s person, so please don’t be surprised if the same is done to you.
My main criticism is just that your whole point comes down to "they did things in a way I didn't like!"
So what? They had different personalities or different goals. When I found _why's guide back in 2004 or whatever, at a boring job that involved a lot of sitting around, I learned Ruby as a side effect of poking through this odd little text. That introduced me to concepts I hadn't come across at school learning Java and C, and ended up nudging me into a different direction, so that by the next year I was writing my class projects in Lisp when I could.
If I'd instead come across a sober-minded manual documenting a proper "serious" programming language, I'd have skipped it. That would have sucked. I enjoyed programming a lot more in my own post-_why timeline, even though I agree in retrospect that Ruby isn't a great programming language for serious projects and the twee-ness of the guide itself was a bit grating (to me) at times.
Criticism is easy and mostly useless. There's so much criticism on the internet, seemingly because it makes people feel superior, and I find it exhausting. Just don't use the thing.
So what? They had different personalities or different goals. When I found _why's guide back in 2004 or whatever, at a boring job that involved a lot of sitting around, I learned Ruby as a side effect of poking through this odd little text. That introduced me to concepts I hadn't come across at school learning Java and C, and ended up nudging me into a different direction, so that by the next year I was writing my class projects in Lisp when I could.
If I'd instead come across a sober-minded manual documenting a proper "serious" programming language, I'd have skipped it. That would have sucked. I enjoyed programming a lot more in my own post-_why timeline, even though I agree in retrospect that Ruby isn't a great programming language for serious projects and the twee-ness of the guide itself was a bit grating (to me) at times.
Criticism is easy and mostly useless. There's so much criticism on the internet, seemingly because it makes people feel superior, and I find it exhausting. Just don't use the thing.
Any criticism boiled down far enough ends up in "they did things in a way I didn't like". It's not a meaningful response.
In this case, the criticism was in response to a perspective on these past events that is in my view overly informed by nostalgia, and while I don't make a general habit of snatching rose-colored glasses off anyone's face, in a public setting and especially in this public setting it is not unreasonable to do so.
I'm glad you found some good in the Poignant Guide. I had a similar experience with the Camel Book, a decade or so earlier, with similarly favorable outcomes - had my mom not proven amenable to being wheedled on the subject of an expensive birthday gift in which she could see no immediate value, I would likely not even be a working programmer today, to say nothing of someone able to grasp some rudiments of what may in a few more decades develop into a recognizable engineering practice. But I don't still use Perl or defend it, because beyond the most ephemeral and exploratory of contexts it is objectively godawful, and even in that context it lacks compared with tools that at least don't falsely advertise themselves as production-worthy. When people criticize it, I understand that they are criticizing it and not me.
And finally, on the point of whimsy versus professionalism - I mentioned the development of engineering practice, and that's a desirable outcome already too long in coming, because when we're trusted to build systems on which people's lives and livelihoods depend, we bear a responsibility of which a whimsical approach to the work constitutes active dereliction. Would you trust your life to a whimsical airplane, or your retirement to a whimsical advisor? Of course not! No one would, nor should they.
Other preparadigmatic engineering disciplines had the advantage of us here; a whimsically designed boiler, for example, will most likely maim or kill its perpetrator well before the bad idea gets much chance to spread, while we easily fall prey to the sorts of delusions that come from working with ideas and materials whose potential danger is much less immediately obvious. I would like us to be better at recognizing and extirpating such errors, and criticizing them where the opportunity arises seems like a decent way to advance that goal. I don't mind if you don't like it, but I would like you not to like it for better thought through reasons than these.
In this case, the criticism was in response to a perspective on these past events that is in my view overly informed by nostalgia, and while I don't make a general habit of snatching rose-colored glasses off anyone's face, in a public setting and especially in this public setting it is not unreasonable to do so.
I'm glad you found some good in the Poignant Guide. I had a similar experience with the Camel Book, a decade or so earlier, with similarly favorable outcomes - had my mom not proven amenable to being wheedled on the subject of an expensive birthday gift in which she could see no immediate value, I would likely not even be a working programmer today, to say nothing of someone able to grasp some rudiments of what may in a few more decades develop into a recognizable engineering practice. But I don't still use Perl or defend it, because beyond the most ephemeral and exploratory of contexts it is objectively godawful, and even in that context it lacks compared with tools that at least don't falsely advertise themselves as production-worthy. When people criticize it, I understand that they are criticizing it and not me.
And finally, on the point of whimsy versus professionalism - I mentioned the development of engineering practice, and that's a desirable outcome already too long in coming, because when we're trusted to build systems on which people's lives and livelihoods depend, we bear a responsibility of which a whimsical approach to the work constitutes active dereliction. Would you trust your life to a whimsical airplane, or your retirement to a whimsical advisor? Of course not! No one would, nor should they.
Other preparadigmatic engineering disciplines had the advantage of us here; a whimsically designed boiler, for example, will most likely maim or kill its perpetrator well before the bad idea gets much chance to spread, while we easily fall prey to the sorts of delusions that come from working with ideas and materials whose potential danger is much less immediately obvious. I would like us to be better at recognizing and extirpating such errors, and criticizing them where the opportunity arises seems like a decent way to advance that goal. I don't mind if you don't like it, but I would like you not to like it for better thought through reasons than these.
I think better criticism is, well, constructive. "Here's a better way to accomplish what they're attempting", not "That's all crap because I don't like it". And before you can do that, I think you have to understand what it is they're attempting.
I'm a professional programmer now, and I much prefer simple, straightforward manuals with clear descriptions. If I was trying to get work done, a bunch of whimsical cartoons would only get in the way. I would have no use for _why's guide today. Even way back when, I was annoyed by the ratio of text and cartoons to actual code & lessons.
But the world isn't made up entirely of professional programmers trying to get work done. There are teenagers who are curious about programming but intimidated by thick volumes and spare language websites pointing at API references. There are workers sick of their current career and looking for something new, and bored stay-at-home spouses. Whimsical guides to quirky languages are for them, not you.
I don't think anybody is pointing to _why's guide as a reference for people who need to write software for self-driving cars or aircraft telemetry in the immediate future. Nobody is arguing that all programming material must be whimsical and quirky. But there was room in the world for a cute little guide to catch newbie or non programmers and teach them a bit. The guide was just an on-ramp, and the community that surrounded it was just a bunch of newcomers fooling around, not Serious Programmers™. That's all it ever was. And in spite of that: a lot of good ideas came from that community, as others have pointed out elsewhere in this thread. A lot of them went on to be Serious Programmers.
I'm not under the impression that you're criticizing me. I read a chunk of _why's guide before I got bored, and then used Ruby for some hobby projects for a couple years nearly two decades ago, before switching to more robust languages: my identity isn't tied up in either of them. I feel like a bystander sitting on a park bench sipping coffee, witnessing you yelling at a group of kids dressed up as an anime characters or whatever, that they should put on a suit and find a real job goddamn it. Like dude, they're just having fun, and frankly it's none of your damn business. You don't like cosplay? Good for you. But maybe chill out a bit and stop yelling at strangers that they're living their life wrong.
I'm a professional programmer now, and I much prefer simple, straightforward manuals with clear descriptions. If I was trying to get work done, a bunch of whimsical cartoons would only get in the way. I would have no use for _why's guide today. Even way back when, I was annoyed by the ratio of text and cartoons to actual code & lessons.
But the world isn't made up entirely of professional programmers trying to get work done. There are teenagers who are curious about programming but intimidated by thick volumes and spare language websites pointing at API references. There are workers sick of their current career and looking for something new, and bored stay-at-home spouses. Whimsical guides to quirky languages are for them, not you.
I don't think anybody is pointing to _why's guide as a reference for people who need to write software for self-driving cars or aircraft telemetry in the immediate future. Nobody is arguing that all programming material must be whimsical and quirky. But there was room in the world for a cute little guide to catch newbie or non programmers and teach them a bit. The guide was just an on-ramp, and the community that surrounded it was just a bunch of newcomers fooling around, not Serious Programmers™. That's all it ever was. And in spite of that: a lot of good ideas came from that community, as others have pointed out elsewhere in this thread. A lot of them went on to be Serious Programmers.
I'm not under the impression that you're criticizing me. I read a chunk of _why's guide before I got bored, and then used Ruby for some hobby projects for a couple years nearly two decades ago, before switching to more robust languages: my identity isn't tied up in either of them. I feel like a bystander sitting on a park bench sipping coffee, witnessing you yelling at a group of kids dressed up as an anime characters or whatever, that they should put on a suit and find a real job goddamn it. Like dude, they're just having fun, and frankly it's none of your damn business. You don't like cosplay? Good for you. But maybe chill out a bit and stop yelling at strangers that they're living their life wrong.
> Any criticism boiled down far enough ends up in "they did things in a way I didn't like". It's not a meaningful response.
Objectively false. Although, granted, much criticism does fall in that category and it's generally worthless. However some criticism is "they did things in a way that was strictly worse than this other alternative that I will describe in actionable detail."
Interestingly enough, virtually all unsolicited criticism falls in the former category.
Objectively false. Although, granted, much criticism does fall in that category and it's generally worthless. However some criticism is "they did things in a way that was strictly worse than this other alternative that I will describe in actionable detail."
Interestingly enough, virtually all unsolicited criticism falls in the former category.
Your entire argument is that you personally don't like Ruby nor the ways of the Ruby community combined with a bunch of unsubstantiated assertions. There's nothing else there. What else should they address besides 'your person'
They actually did a pretty good job of elaborating a critique of my criticism in replying to the same comment you did, so I chose to continue the dialogue there.
There was a lot of quirkiness and egotism then, the cult of personality was rife, not just with project leaders such as DHH but ancillary dramas from folks like Zed Shaw.
The stuff from _why was always wacky but some of their projects were also really inspiring for younger programmers, of which I was one. I could take or leave the cartoon foxes but I remember seeing the code for the Camping framework when it was released and being amazed at how simple and elegant it was.
The ruby and rails community set a path that is followed by many to this day. We're all python programmers now but there'd be no Flask without Sinatra, or Django without Rails. The author of the excellent dependency management tool Bundler went onto work on Yarn for javascript and then created Cargo for rust. Mitchell Hashimoto wrote Vagrant in ruby before starting hashicorp, there's loads of examples like this
I disagree that the Poingant Guide was the primary documentation for anything, it was a quirky guide for new comers. The Pragmatic bookshelf had the definitive guide to the language, as well as the rails book and then a whole series of other publications. I also remember spending a lot of time on the core ruby documentation, which does a fantastic job of covering the extensive standard library.
The stuff from _why was always wacky but some of their projects were also really inspiring for younger programmers, of which I was one. I could take or leave the cartoon foxes but I remember seeing the code for the Camping framework when it was released and being amazed at how simple and elegant it was.
The ruby and rails community set a path that is followed by many to this day. We're all python programmers now but there'd be no Flask without Sinatra, or Django without Rails. The author of the excellent dependency management tool Bundler went onto work on Yarn for javascript and then created Cargo for rust. Mitchell Hashimoto wrote Vagrant in ruby before starting hashicorp, there's loads of examples like this
I disagree that the Poingant Guide was the primary documentation for anything, it was a quirky guide for new comers. The Pragmatic bookshelf had the definitive guide to the language, as well as the rails book and then a whole series of other publications. I also remember spending a lot of time on the core ruby documentation, which does a fantastic job of covering the extensive standard library.
Ruby itself was tolerably well documented, but that was a rare bright spot, and of limited utility when Rails leveraged the malleability of the language into near incomprehensibility even by the language's own low standard. And while you're not wrong that by spending enough money it was possible to obtain halfway decent documentation for Rails that if you were very lucky might still be mostly applicable after a couple of point releases, not everyone had a lot of money to spend in that way. Pay-to-play access to knowledge required for basic competence is another example of structural exclusivity, and one that stood in stark contrast to most contemporaneous projects of similarly high profile, by comparison with which Rails had all the openness of a Freemason lodge in 18th-century Italy - oh, they advertised themselves very effectively, that I grant you, but in terms of actually fostering development among those so attracted, I think a secret society in which membership could be a death sentence would probably do a lot better.
> The ruby and rails community set a path that is followed by many to this day.
I've already acknowledged this, albeit without the unwarranted gloss. I might instead have said that Rails' one unqualified success was as a fount of good ideas badly implemented. But since on reflection I'm pretty sure Rails' use of ActiveRecord popularized ORMs in web application development, I suppose it isn't even fair to say that all the ideas were good.
> The ruby and rails community set a path that is followed by many to this day.
I've already acknowledged this, albeit without the unwarranted gloss. I might instead have said that Rails' one unqualified success was as a fount of good ideas badly implemented. But since on reflection I'm pretty sure Rails' use of ActiveRecord popularized ORMs in web application development, I suppose it isn't even fair to say that all the ideas were good.
Hibernate predates ActiveRecord, if I'm not mistaken, and to this date I can't decide which of the two I hate more. They both do different things very wrong. So I'm not sure if you can blame ORMs on Rails.
Also I'm not sure what you mean by the documentation criticism. I criticised Rails elsewhere in the comments, but I can't really fault it for the documentation, which IMHO was always excellent. And then you also had Michael Hartl's excellent Rails guide (which was available online freely, at least at the time) which was what basically taught me modern backend development (including what automated testing is).
Also I'm not sure what you mean by the documentation criticism. I criticised Rails elsewhere in the comments, but I can't really fault it for the documentation, which IMHO was always excellent. And then you also had Michael Hartl's excellent Rails guide (which was available online freely, at least at the time) which was what basically taught me modern backend development (including what automated testing is).
I'd have loved to know about such a thing at the time! One wonders why none of the people in the various IRC channels and forums where I then sought Rails advice saw fit to mention it.
In entire, albeit mildly grudging, fairness, I do have to concede that Rails introduced me to the concept of unit testing. But I'm still glad I learned modern backend development in the years immediately after Rails peaked, and while the worthwhile was being sorted from the nonsense among the many concepts and approaches that Rails does, for better or worse, deserve credit for having made newly popular.
In entire, albeit mildly grudging, fairness, I do have to concede that Rails introduced me to the concept of unit testing. But I'm still glad I learned modern backend development in the years immediately after Rails peaked, and while the worthwhile was being sorted from the nonsense among the many concepts and approaches that Rails does, for better or worse, deserve credit for having made newly popular.
But rails was modern backend development back then, it offered an alternative to a world full of mod_perl, PHP4, Java servlets with JSP and XSLT.
Having had the displeasure of working on all those stacks it's hard to overstate how transformative rails was at the time for me.
Built in unit testing is one thing, not having to write a java class to expose a custom function to an xslt processor in order to format a string is something else.
Having had the displeasure of working on all those stacks it's hard to overstate how transformative rails was at the time for me.
Built in unit testing is one thing, not having to write a java class to expose a custom function to an xslt processor in order to format a string is something else.
> But since on reflection I'm pretty sure Rails' use of ActiveRecord popularized ORMs in web application development
As someone mired in enterprise web application development in the early oughts, I can tell you this is kind of backwards. ActiveRecord was actually a simplification of the more complex ORM that enterprise software (mostly in Java at the time, but a little bit of Objective C in the banking realm) was using. I _think_ the term "ActiveRecord" was first used in the 2003 book Patterns of Enterprise Architecture, and it was described as a pattern you could use when you didn't need the complexity of a full-blown ORM. For people who had wrestled with Hibernate or WebObjects, ActiveRecord felt like a light-weight sigh of relief.
That said - even as someone who still works on RoR apps - I'm glad we've mostly moved beyond ORMs (primarily by moving beyond objects, which were never a very good fit for representing data in the first place).
As someone mired in enterprise web application development in the early oughts, I can tell you this is kind of backwards. ActiveRecord was actually a simplification of the more complex ORM that enterprise software (mostly in Java at the time, but a little bit of Objective C in the banking realm) was using. I _think_ the term "ActiveRecord" was first used in the 2003 book Patterns of Enterprise Architecture, and it was described as a pattern you could use when you didn't need the complexity of a full-blown ORM. For people who had wrestled with Hibernate or WebObjects, ActiveRecord felt like a light-weight sigh of relief.
That said - even as someone who still works on RoR apps - I'm glad we've mostly moved beyond ORMs (primarily by moving beyond objects, which were never a very good fit for representing data in the first place).
Huh, okay, that's fair. ActiveRecord was the first ORM I worked with, and ActiveRecord in 2013 was easily poor enough to color my perspective on the category. I've heard Hibernate criticized before, of course, but I didn't realize it both predated ActiveRecord and was so much worse as to leave ActiveRecord even in its day looking good by comparison.
I still think Rails gets the blame for popularizing the concept, but I suppose that has to be mitigated by prior art making it so easy to popularize - "it's just like what you're used to, but won't make you want to kill yourself to use" is a pretty compelling pitch.
I still think Rails gets the blame for popularizing the concept, but I suppose that has to be mitigated by prior art making it so easy to popularize - "it's just like what you're used to, but won't make you want to kill yourself to use" is a pretty compelling pitch.
LOL. I feel like a geezer whenever I talk to people about what enterprise software was before RoR came along. XML. So much XML. Do you think that you should write XML in order to query data from a DB with a perfectly serviceable query language? People sure did think that in 2001!
You joke, but honestly, it's still the same class of problem. I don't think I should write TypeScript in order to query a DB with a perfectly serviceable query language, either, and I've seen so much time get spent on dealing with the headaches condign upon leaky abstractions to render the productivity benefits claimed by ORM proponents transparently nonsensical. And yet...
> I would much rather participate in a community of professionals who've organized themselves around sufficiently overlapping shared intents
I thoroughly enjoyed my involvement with early (US) Ruby and Rails folks from the first Rails conf to _why's unusual entertainment to Matz's calm and humble demeanor. People bounced ideas off each other and just enjoyed coding up interesting things. Dave Thomas and the Pragmatic Programmer group wrote what many of us used, not so much _why's guide which was still a fun read. I moderated a Ruby panel at the old Odeo HQ just before they pivoted. I didn't know the group gathering at that Ruby SF meeting would include not only Twitter but Github founders as well. At the time, tweets seemed pretty absurd to some of us but guess what happens when you try out ideas in a community that was into exploration?
I thoroughly enjoyed my involvement with early (US) Ruby and Rails folks from the first Rails conf to _why's unusual entertainment to Matz's calm and humble demeanor. People bounced ideas off each other and just enjoyed coding up interesting things. Dave Thomas and the Pragmatic Programmer group wrote what many of us used, not so much _why's guide which was still a fun read. I moderated a Ruby panel at the old Odeo HQ just before they pivoted. I didn't know the group gathering at that Ruby SF meeting would include not only Twitter but Github founders as well. At the time, tweets seemed pretty absurd to some of us but guess what happens when you try out ideas in a community that was into exploration?
I mean, it's usually preferable to be part of an ingroup than of its outgroup, sure. Otherwise, what value in the distinction? But the iron law applies here, too.
I wouldn't be so quick to claim Twitter, either, even among zero-interest-rate phenomena more generally. It might be easy to forget these days, but that's been harmful to society on net since long before Musk bought it.
I wouldn't be so quick to claim Twitter, either, even among zero-interest-rate phenomena more generally. It might be easy to forget these days, but that's been harmful to society on net since long before Musk bought it.
I think you're missing my point. The early Ruby and Rails community I remember was a collection of very smart and explorative programmers who wanted to build cool stuff with this interesting language. People were trying out DSLs -- sure they could've used LISP -- but Ruby's metaprogramming was inviting and was a reason for the succinct Rails syntax which was a selling point compared to say Java's cumbersome approach.
The speed of trying stuff out (even if it wasn't super efficient) why startups used it. So it was a community of highly productive people sharing their love of building new things. That's my memory of that time period.
The speed of trying stuff out (even if it wasn't super efficient) why startups used it. So it was a community of highly productive people sharing their love of building new things. That's my memory of that time period.
I'm not missing your point, but I don't see where it constitutes the counterargument that context and framing suggest you mean it to be.
What you're describing here is your perspective from within the small and insular group busily developing and advocating new technology, always focused on the next new thing that was cool and interesting and succinct and powerful. What I'm describing is my perspective from well outside that pale. Both can be true at the same time.
What you're describing here is your perspective from within the small and insular group busily developing and advocating new technology, always focused on the next new thing that was cool and interesting and succinct and powerful. What I'm describing is my perspective from well outside that pale. Both can be true at the same time.
Then maybe you shouldn’t generalize your one viewpoint to say that early Ruby/Rails was not a worthy community for professionals or of use to people who practice jointly valued skills like entrepreneurship.
It’s also odd to see your long rant of whimsical vs professional when some of the most well-known companies were built with that community of so-called non-professionals. We have a difference in opinion on what constitutes “professional”.
It’s also odd to see your long rant of whimsical vs professional when some of the most well-known companies were built with that community of so-called non-professionals. We have a difference in opinion on what constitutes “professional”.
The entire point I'm making is that, however well that community may have fulfilled those roles for people embedded in the social context of its ingroup, it did a lousy-to-failing job of the same outside that circle.
Speaking as someone who started out with Ruby and Rails and has since migrated to other stacks...
I would never conflate Ruby and Rails.
Ruby is a language that took interesting ideas and developed them in a unique way. Today, it doesn't align with my goals 100% anymore (I do like Ruby's focus on expressivity, but not when it comes at the expense of predictability), but I don't think that's Ruby's fault.
Rails, by contrast, is software that did a few things right (things should work mostly out of the box, automated migrations, testing built in) and way too many things wrong. Design and architecture are dirty words for much of the Rails community (and this thought very explicitly originates with DHH who still maintains that you don't need anything besides models, views and controllers), autoloading is hot garbage, "magic" libraries that start monkeypatching your code just because you add them to your Gemfile are a thing, the biggest auth library, devise, is an opinionated mess, writing proper (fast) unit tests is difficult and goes against the framework, and so on.
I would say that most of the good ideas that came with Rails have now been incorporated by better frameworks (even in Ruby itself, but in particular also in other ecosystems), so it's good that it was there, but I wouldn't recommend it any more.
But Ruby didn't originate with Rails. To my knowledge it's still used today by Japanese developers who don't particularly care about Rails.
I would never conflate Ruby and Rails.
Ruby is a language that took interesting ideas and developed them in a unique way. Today, it doesn't align with my goals 100% anymore (I do like Ruby's focus on expressivity, but not when it comes at the expense of predictability), but I don't think that's Ruby's fault.
Rails, by contrast, is software that did a few things right (things should work mostly out of the box, automated migrations, testing built in) and way too many things wrong. Design and architecture are dirty words for much of the Rails community (and this thought very explicitly originates with DHH who still maintains that you don't need anything besides models, views and controllers), autoloading is hot garbage, "magic" libraries that start monkeypatching your code just because you add them to your Gemfile are a thing, the biggest auth library, devise, is an opinionated mess, writing proper (fast) unit tests is difficult and goes against the framework, and so on.
I would say that most of the good ideas that came with Rails have now been incorporated by better frameworks (even in Ruby itself, but in particular also in other ecosystems), so it's good that it was there, but I wouldn't recommend it any more.
But Ruby didn't originate with Rails. To my knowledge it's still used today by Japanese developers who don't particularly care about Rails.
If I've conflated Ruby and Rails, it wasn't by intent.
I do think Rails was like it was in large part by direct derivation from, and enshrinement of, Ruby's allergy to rigor - which isn't to say they're the same thing, but that the latter directly predated and heavily informed the former.
I do think Rails was like it was in large part by direct derivation from, and enshrinement of, Ruby's allergy to rigor - which isn't to say they're the same thing, but that the latter directly predated and heavily informed the former.
Yes, Ruby has always prioritised readability and "developer happiness" over predictability and rigour, but that doesn't mean that it necessarily encouraged incomprehensible meta-frameworks. Sinatra or similar projects show how things can be done more decently in Ruby, while still utilising its malleability in order to create a nice DSL.
When a main goal to maximize a subjective trait such as "developer happiness," you are almost certain to cause the opposite for a significant portion of your users. This is the curse of inherited ruby code.
Ruby gives incredible flexibility to individual developers writing code the way they prefer. For a large team, that can be a problem but I'm not sure that was Ruby's original target group.
I miss that in general. Everyone has become a Cool Internet Person who acts like a celebrity, or at least in a homogenized way. I miss the internet of weirdos, that felt separate from the real world.
I worry a lot that I contributed to how this is now, too, in my professional life.
I worry a lot that I contributed to how this is now, too, in my professional life.
Internet is still full of weirdos.
What changed are primarily two things:
1) The social media war hasn't been won by those platforms that offered users possibilities to customize their page (MSN spaces, myspace, tumblr still survives) but by pre-canned, limited but simple platforms.
2)Internet citizens are increasingly less anonymous on all those platforms which makes them further unwilling to be unfiltered.
What changed are primarily two things:
1) The social media war hasn't been won by those platforms that offered users possibilities to customize their page (MSN spaces, myspace, tumblr still survives) but by pre-canned, limited but simple platforms.
2)Internet citizens are increasingly less anonymous on all those platforms which makes them further unwilling to be unfiltered.
All frontiers close eventually. I wouldn't take too much on myself about it, if I were you.
Honestly, internet of weirdos that feels separate from the real world is on private discords now. I pluck people from various semi-public communities that seem cool and build cool private communities.
There is a huge difference between pockets of weirdos sharing giphy memes in walled gardens using tools provided by a corporation and what felt like practically the entire internet being comprised of, built for and used by absolute weirdos.
[deleted]
Fair enough. It just became too much of a risk to put your full private self out there on the internet unless you're a special kind of DGAF, I think.
Those discords are full of "weirdos" who are all exactly the same. I'm talking about the self hosted blogs about how the moon landing is fake that also explained how to emulate NES games, BBS' etc.
Every Discord I've seen is just a bunch of Zoomer communist furries which, while not exactly your average bunch, are all very similar to each other and everyone on Twitter and Mastodon.
Every Discord I've seen is just a bunch of Zoomer communist furries which, while not exactly your average bunch, are all very similar to each other and everyone on Twitter and Mastodon.
Why do you think you contributed?
Edit: maybe “how” would be a better word to use.
Edit: maybe “how” would be a better word to use.
Sometimes I feel bad for having been a customer of digital devices and internet, and then going into computing studies.
It's strange to observe a world I dislike even though I was part of the wave driving the change.
It's strange to observe a world I dislike even though I was part of the wave driving the change.
[deleted]
Hey folks. Not sure why this is here today, but happy to answer questions.
I've long held... complicated feelings about a lot of all of this. For an analysis I did of the work at the time, https://www.youtube.com/watch?v=MaWHVceDbFo
I've long held... complicated feelings about a lot of all of this. For an analysis I did of the work at the time, https://www.youtube.com/watch?v=MaWHVceDbFo
Time well spent.
Thanks for the talk!
Thanks for the talk!
Page 17 mentions a link and then goes off on a poignant meditation about its likelihood of breaking:
"It feels like I may have just gone ahead and ruined what I am by [dumping this link]. Has all of this writing lost its timelessness, to have this relic here? But maybe this link will never break, maybe it will stay there for all time. Maybe it's me. I'm a relic which is already out of his time in the present age."
The link is now broken. You weren't the relic, _why.
"It feels like I may have just gone ahead and ruined what I am by [dumping this link]. Has all of this writing lost its timelessness, to have this relic here? But maybe this link will never break, maybe it will stay there for all time. Maybe it's me. I'm a relic which is already out of his time in the present age."
The link is now broken. You weren't the relic, _why.
Would anyone be willing to explain this? Who is "us", what is a PCL, what is a spool, what are these random words? Is this supposed to be a puzzle?
A few weeks/months before _why published this book, this page appeared on his "public print queue" on his site, hinting that the print queue would become active on April 18: https://github.com/steveklabnik/CLOSURE/blob/master/PDF/DESO...
A day or two before April 18, this page appeared containing a hand-written OCaml script you could use to hook up your own printer to _why's public print queue: https://github.com/steveklabnik/CLOSURE/blob/master/PDF/HOME...
On April 18, a bunch of us gathered in an IRC chat room (https://viewsourcecode.org/why/CLOSURE/ircLog.html). A few of us got the script working on our machines, and so every 10-15 minutes our printers would suddenly start up and print the next page as _why slowly published them one at a time throughout the day. Steve Klabnik gathered all the pages into one PDF and gave it the name "CLOSURE".
This article does a good job of giving more context around the book itself (as well as a partial summary): https://kev.town/2013/04/30/why-did-why-the-lucky-stiff-quit...
A day or two before April 18, this page appeared containing a hand-written OCaml script you could use to hook up your own printer to _why's public print queue: https://github.com/steveklabnik/CLOSURE/blob/master/PDF/HOME...
On April 18, a bunch of us gathered in an IRC chat room (https://viewsourcecode.org/why/CLOSURE/ircLog.html). A few of us got the script working on our machines, and so every 10-15 minutes our printers would suddenly start up and print the next page as _why slowly published them one at a time throughout the day. Steve Klabnik gathered all the pages into one PDF and gave it the name "CLOSURE".
This article does a good job of giving more context around the book itself (as well as a partial summary): https://kev.town/2013/04/30/why-did-why-the-lucky-stiff-quit...
I am still kinda sad that the only place I kept the video of my printer printing out pages was Vine. Oh well.
EDIT: I am now realizing that, ironically, maybe that is appropriate...
EDIT: I am now realizing that, ironically, maybe that is appropriate...
As far as I can tell, many (all?) Vine videos are still available if you have the link
Oh wow! Okay hmmm, thank you, I will see what I can do...
1. "Us" is the Ruby community (and arguably programming at large)
2. https://en.wikipedia.org/wiki/Printer_Command_Language
3. https://en.wikipedia.org/wiki/Spooling#Print_spooling
4. They are individual titles of each page
5. yes, this was a puzzle of sorts, though the answers were kind of given to us beforehand, so you can argue that it wasn't a difficult puzzle. The PDF is the "answer" to the puzzle, if you will.
2. https://en.wikipedia.org/wiki/Printer_Command_Language
3. https://en.wikipedia.org/wiki/Spooling#Print_spooling
4. They are individual titles of each page
5. yes, this was a puzzle of sorts, though the answers were kind of given to us beforehand, so you can argue that it wasn't a difficult puzzle. The PDF is the "answer" to the puzzle, if you will.
Others already explained this, I just wanted to add that you make me feel old...
I'm 48. I don't think age has anything to do with knowing the context behind this. From the other explanations, you apparently had to follow a very specific subculture dedicated to a specific individual. I did not, rather the opposite. I tried to read his Ruby book when it came out and I simply couldn't. No offense to the vast army of folks who enjoyed it -- I think we're all allowed to like what we like.
There's something wrong with the way my brain is wired. I am by accounts an intelligent, capable, successful person, but I am completely unable to "read" comic books. I might as well be staring at a foreign language. When I'm trying to learn a technical topic, I thrive on dry reference material. Put a cartoon in and it's like running into a brick wall.
I don't know where I was going there except I feel like any time this comes up, I have to over-explain myself for not liking that book, because everybody loves that book and I will be burned at the stake for not regarding it as the greatest programming book ever written. It's just my personal experience, and I accept that I'm totally wrong about it, ok? Anyway, shorter version is that I had such a visceral reaction, any time I see "why_" mentioned, my reading comprehension reverts to that of a toddler.
If that's all irrelevant and the point you were making was more like "kids today don't know what PCL is", I am very familiar with PCL and print spoolers, but detached from any context that would suggest printers, they failed to take on any semantic value.
There's something wrong with the way my brain is wired. I am by accounts an intelligent, capable, successful person, but I am completely unable to "read" comic books. I might as well be staring at a foreign language. When I'm trying to learn a technical topic, I thrive on dry reference material. Put a cartoon in and it's like running into a brick wall.
I don't know where I was going there except I feel like any time this comes up, I have to over-explain myself for not liking that book, because everybody loves that book and I will be burned at the stake for not regarding it as the greatest programming book ever written. It's just my personal experience, and I accept that I'm totally wrong about it, ok? Anyway, shorter version is that I had such a visceral reaction, any time I see "why_" mentioned, my reading comprehension reverts to that of a toddler.
If that's all irrelevant and the point you were making was more like "kids today don't know what PCL is", I am very familiar with PCL and print spoolers, but detached from any context that would suggest printers, they failed to take on any semantic value.
Dude, it’s ok.
I loved the work _why did back at the time, in general. Doesn’t mean I loved every single thing.
In particular, I never bothered to finish the poignant guide. It didn’t speak to me. But I loved the fact that it enthused other people.
There never was a need for worship as far as _why was concerned.
I loved the work _why did back at the time, in general. Doesn’t mean I loved every single thing.
In particular, I never bothered to finish the poignant guide. It didn’t speak to me. But I loved the fact that it enthused other people.
There never was a need for worship as far as _why was concerned.
[deleted]
You can be perfectly capable of reading a comic book and not really care to try to learn technical information by way of a comic book.
I'd much rather learn from concise code examples, with short explanations for new concepts. It's a lot more efficient than wading through all the irrelevant prose and illustration.
I'd much rather learn from concise code examples, with short explanations for new concepts. It's a lot more efficient than wading through all the irrelevant prose and illustration.
Idem. I remember not being able to get past the first page of the guide way back in the day, and indeed cannot today either. The signal to noise ratio is just abysmal.
I also cannot read comic books and, with perhaps the exception of the systemd man pages, likewise thrive on reference material.
Somewhat relatedly, I can't really do podcasts or audiobooks, either, unless they're in a foreign language, and then the challenge of comprehension provides something for my brain to latch onto.
I also cannot read comic books and, with perhaps the exception of the systemd man pages, likewise thrive on reference material.
Somewhat relatedly, I can't really do podcasts or audiobooks, either, unless they're in a foreign language, and then the challenge of comprehension provides something for my brain to latch onto.
I believe the conceit here is that _why is communicating to us through a printer queue or "spool". PCL files are a form of printer data file.
[deleted]
PCL is postscript common language or something like that, basically an alternative to PDF as far as I know.
Printer Common Language. More an alternative to PostScript than to PDF, in that it's a language that a lot of printers understand (as the name suggests).
No, it's HP Printer Command Language[1]; it's the 'native tongue' of things like HP LaserJets. It predates and is different from PS and PDF[2] and isn't an alternative for PDF in that you don't store documents 'in PCL'.
[1] https://developers.hp.com/hp-printer-command-languages-pcl [2] https://support.hp.com/us-en/document/c06242096
[1] https://developers.hp.com/hp-printer-command-languages-pcl [2] https://support.hp.com/us-en/document/c06242096
From: https://github.com/steveklabnik/CLOSURE/issues/3
--
vi commented on Sep 30, 2015
What is CLOSURE.PDF? Readme is not helpful. I don't even understand is it a scientific paper, a book, a program or a game. My first thought was "Fed up! I'm closing! Here is my closure manifesto."
Along with Thanks, _why. there should be answer to What is CLOSURE? question in repository description.
--
mikehenrty commented on Aug 13, 2016
I think the problem is that nobody except for _why and perhaps a few people close to him know the context of this material. It just showed up on his blog one day after years of online radio silence. These hacker news posts show some of the confusion and excitement from that time:
https://news.ycombinator.com/item?id=5015087
https://news.ycombinator.com/item?id=5571387
Note that the link from Hacker News, _why's original blog, is now operated by some Australian guy with no apparent relation to _why.
--
vi commented on Sep 30, 2015
What is CLOSURE.PDF? Readme is not helpful. I don't even understand is it a scientific paper, a book, a program or a game. My first thought was "Fed up! I'm closing! Here is my closure manifesto."
Along with Thanks, _why. there should be answer to What is CLOSURE? question in repository description.
--
mikehenrty commented on Aug 13, 2016
I think the problem is that nobody except for _why and perhaps a few people close to him know the context of this material. It just showed up on his blog one day after years of online radio silence. These hacker news posts show some of the confusion and excitement from that time:
https://news.ycombinator.com/item?id=5015087
https://news.ycombinator.com/item?id=5571387
Note that the link from Hacker News, _why's original blog, is now operated by some Australian guy with no apparent relation to _why.
_why offered a vision of computing, art and delight that we could maybe use more of nowadays. For more reference see “This Hack Was Not Properly Planned” here: https://web.archive.org/web/20080512050317/http:/hackety.org...
interesting timing, I've been thinking about _why lately; Brett Victor's recent update https://news.ycombinator.com/item?id=36596095 gave me _why vibes.
a thing I realized recently is that _why's disappearance ends up making his work more "Poignant" - the tech stuff washes away, but the story lives on. In that sense, it's a success.
if you look at old technology, the descriptions and documentation tend to outlast the artifacts. I like to imagine us as stage performers - any given implementation of a Shakespeare play only lasts a couple hours, but the structure of it is timeless. Perhaps we should all be writing more, implementing less.
also, it's always good to consider what fame is, and what it does to people. In an attention economy, we imagine that fame is wealth - but it's clearly not so straightforward
a thing I realized recently is that _why's disappearance ends up making his work more "Poignant" - the tech stuff washes away, but the story lives on. In that sense, it's a success.
if you look at old technology, the descriptions and documentation tend to outlast the artifacts. I like to imagine us as stage performers - any given implementation of a Shakespeare play only lasts a couple hours, but the structure of it is timeless. Perhaps we should all be writing more, implementing less.
also, it's always good to consider what fame is, and what it does to people. In an attention economy, we imagine that fame is wealth - but it's clearly not so straightforward
Permanence is a major theme of _why's work. Some of his final tweets were about comparing computer programs to works of literature, specifically Kafka. A longer meditation on this appears in this work.
Kafka asked his friend Max to burn all of his works and not have them published, but he was betrayed, and so we have Kafka's books.
_why burned his own works, but thanks to git, we were able to posthumously un-burn them.
And then this work was temporary, and what I did was make it permanent. Again.
Most of _why's projects don't really work on modern hardware, or with up to date compilers, or up to date versions of Ruby. Yet we can still read this book today.
Kafka asked his friend Max to burn all of his works and not have them published, but he was betrayed, and so we have Kafka's books.
_why burned his own works, but thanks to git, we were able to posthumously un-burn them.
And then this work was temporary, and what I did was make it permanent. Again.
Most of _why's projects don't really work on modern hardware, or with up to date compilers, or up to date versions of Ruby. Yet we can still read this book today.
He and I went to high school together, and he was really funny then too.
In our seminary class, I would always ask him to play the Peanuts theme song on piano. I loved how he didn’t care what anybody thought and he just did his own thing.
I lost track of him after we graduated.
I'll take this opportunity to link to Why's Poignant Guide to Ruby - https://poignant.guide - one of the most unique and inspiring programming language tutorials you'll ever read.
I never got it. Everyone says it’s fantastic, I feel like an idiot for absolutely not getting it at all when it came out and still not today.
It was very much of a time and place, and obviously people are welcome to take or leave it. I certainly cringe that every language now seems to need its own twee, jokey, book-long tutorial, like Learn You a Haskell for Great Good and Clojure for the Brave and True. But Why’s (Poignant) Guide captured the playfulness and nostalgia for lost time that the Ruby community evoked for a lot of people back then, especially those that had grown up with computers but drifted into enterprise software and watched the joy of technology slowly seep out of their lives. Whether it's a good way to learn Ruby the language, I don't really remember.
I don't think the jokey book-long tutorial is a new phenomenon.
I learned Fortran in the 80s from the Fortran Coloring Book.
I learned Fortran in the 80s from the Fortran Coloring Book.
1981 Getting Started with TRS-80 Basic was also playful - https://archive.org/details/Getting_Started_with_TRS-80_Basi...
I now also see Comic Pascal from 1984, fair enough.
Computer Lib / Dream Machines, 1974.
In case it makes anybody feel better, I was "around" at the time and I never got it, either. Tried to read it many times and never could finish.
That's okay.
Another senior DBA lived on a boat, so I took my DBAs over to his boat and we spent the afternoon, then went for a walk in the tony seaside town at which his boat was moored. We went to an art gallery.
One of the pieces was a semi-abstract gradient, but the colors could definitely remind one of the sky, and the steely gray of the ocean. I loved the way you looked at it and kind of got lost in the middle. It "felt" like the ocean more than "looking" like the ocean to me.
Another DBA was standing there looking at it and said, "I don't get it."
"I'm not sure there's something to 'get', exactly."
"Is there a boat or a person hidden in it? I can't find it."
For this person, looking at a picture had to have a point--a subject. It was, on some level, a "Where's Waldo?" exercise and since he didn't solve the problem of finding Waldo, he didn't get it.
But not everything's like that. It's okay to not like something. It's okay to not get it. You can still be a DBA. You can still have a picnic on the boat.
Another senior DBA lived on a boat, so I took my DBAs over to his boat and we spent the afternoon, then went for a walk in the tony seaside town at which his boat was moored. We went to an art gallery.
One of the pieces was a semi-abstract gradient, but the colors could definitely remind one of the sky, and the steely gray of the ocean. I loved the way you looked at it and kind of got lost in the middle. It "felt" like the ocean more than "looking" like the ocean to me.
Another DBA was standing there looking at it and said, "I don't get it."
"I'm not sure there's something to 'get', exactly."
"Is there a boat or a person hidden in it? I can't find it."
For this person, looking at a picture had to have a point--a subject. It was, on some level, a "Where's Waldo?" exercise and since he didn't solve the problem of finding Waldo, he didn't get it.
But not everything's like that. It's okay to not like something. It's okay to not get it. You can still be a DBA. You can still have a picnic on the boat.
I said this elsewhere too -- while in general I like things _like_ the poignant guide, and appreciate its existence, I never actually finished reading it.
To me it's an interesting touchstone work showing/reminding that the "invisibly neutral" tone we've collectively adopted is still an editorial choice and cultural moment.
I'm sure writing and communication styles will drift back and forth over the next few decades. Sometime soon (if not already) another generation of younger developers will coalesce around some document that feels authentically counter-cultural, like their own late-night jokes and dreams have been given just enough coherence to hook them in, and then I probably still won't get it because I'll be out of touch.... :)
To me it's an interesting touchstone work showing/reminding that the "invisibly neutral" tone we've collectively adopted is still an editorial choice and cultural moment.
I'm sure writing and communication styles will drift back and forth over the next few decades. Sometime soon (if not already) another generation of younger developers will coalesce around some document that feels authentically counter-cultural, like their own late-night jokes and dreams have been given just enough coherence to hook them in, and then I probably still won't get it because I'll be out of touch.... :)
For what it’s worth, I felt the same way, but never dared voice it.
I think it’s worth appreciating as a thing of beauty. The raw talent required to make it is just incredible, and it probably takes a Rubyist to fully see the intricacies of what we’re meant to “get”. There’s a place for this kind of work, and it’s one of the delights of life that it exists at all.
I think it’s worth appreciating as a thing of beauty. The raw talent required to make it is just incredible, and it probably takes a Rubyist to fully see the intricacies of what we’re meant to “get”. There’s a place for this kind of work, and it’s one of the delights of life that it exists at all.
I did get it, and I would argue this book made me a better engineer. People learn different ways and retain knowledge differently. Some folks do really well with technical manuals and minimal but factual informational, and some folks respond better to more novel approaches. _why's guide was definitely the latter, and a vocal group of people seemed to agree. While _why's version was definitely on the far side of novel, the approach itself was used in a whole series[0] of books. It's all good that it wasn't your thing, and you're not an idiot, it just wasn't your style.
0. https://en.wikipedia.org/wiki/Head_First_(book_series)
0. https://en.wikipedia.org/wiki/Head_First_(book_series)
Mostly the same, except I don’t feel like an idiot for not getting it. I thought it was self-indulgent and too clever by half. But I admit that’s just taste and not a measure of its objective worth.
I have a theory about _why’s popularity though. I think a lot of it comes from the cohort of us who were strictly trained in a C/Fortran/Knuth Art of Computer Programming style old-school approach. When your first presented with the mind blowing ideas of what programming can be when you start to liberate yourself from the machine — if the source has a quirky voice, there always remains a soft spot in your heart for them, be it the Little Schemer, SICP or _why.
I have a theory about _why’s popularity though. I think a lot of it comes from the cohort of us who were strictly trained in a C/Fortran/Knuth Art of Computer Programming style old-school approach. When your first presented with the mind blowing ideas of what programming can be when you start to liberate yourself from the machine — if the source has a quirky voice, there always remains a soft spot in your heart for them, be it the Little Schemer, SICP or _why.
it characterizes programming in a way that is basically incoherent to most stereotypical programmers
(i agree with you, for the record, it was gobbledegook to me too)
the question is: does programming represent some kind of subjective expression, or some kind of objective precision? why's little zine says it's the former, but that's not how i see it at all
programming is, for me, like working on math problems, or balancing equations, it's strict and pure and precise, and that's what i love about it, there's no connection to anything like art, or writing (in the novel sense), or other kinds of subjective expression
but for some people, programming is like art, or writing a novel, or in any case a subjective expression of some abstract idea (or ideas) that they have
at least this is what i see as the discrepancy
(i agree with you, for the record, it was gobbledegook to me too)
the question is: does programming represent some kind of subjective expression, or some kind of objective precision? why's little zine says it's the former, but that's not how i see it at all
programming is, for me, like working on math problems, or balancing equations, it's strict and pure and precise, and that's what i love about it, there's no connection to anything like art, or writing (in the novel sense), or other kinds of subjective expression
but for some people, programming is like art, or writing a novel, or in any case a subjective expression of some abstract idea (or ideas) that they have
at least this is what i see as the discrepancy
Programming, objectively speaking, is nothing like balancing equations. When balancing equations, there is only one right answer. When programming, there is a goal and a series of subjective choices need to made in order to reach the goal. There are many right answers. The art and craft is in those subjective decisions. You might not care about the craft in those decisions, but, objectively speaking, I don’t think you can reduce programming to something like balancing equations.
preseinger(1)
Worth noting that mathematicians also argue over the art vs. science approach to math itself. Ask one what makes a formula "elegant", for example, can lead to some hand-waving that boils down to "you know it when you see it."
My take: the art is always about the human communication through the medium. As soon as programming is abstracted beyond the 1s and 0s, every choice represents a mental model for communicating intent from a human to a computer and by extension, from a human to a human. Writing "elegant code" is all about communicating intent to other programmers.
You can say the same about math - so much of the human-ness of math is backed into the symbols we use to represent things and relationships. Just think of the human impact of doing multiplication in Arabic numerals vs. Roman numerals and you can understand how math is totally a human construct.
But underneath it, the logic of multiplication is non-human and those that focus on that are the "science-minded" ones. But so much of our human understanding comes from the "art-minded" ones, for obvious reasons.
My take: the art is always about the human communication through the medium. As soon as programming is abstracted beyond the 1s and 0s, every choice represents a mental model for communicating intent from a human to a computer and by extension, from a human to a human. Writing "elegant code" is all about communicating intent to other programmers.
You can say the same about math - so much of the human-ness of math is backed into the symbols we use to represent things and relationships. Just think of the human impact of doing multiplication in Arabic numerals vs. Roman numerals and you can understand how math is totally a human construct.
But underneath it, the logic of multiplication is non-human and those that focus on that are the "science-minded" ones. But so much of our human understanding comes from the "art-minded" ones, for obvious reasons.
Mathematicians love arguing about which proof is the most elegant or most insightful, and which definitions are the ones that most captivate the essence of a concept (ask three mathematicians from different fields to define Euler's constant e, for example).
So yeah, there is very clearly a human and subjective element in mathematics, even when the results themselves are objective (modulo axioms and inference rules).
So yeah, there is very clearly a human and subjective element in mathematics, even when the results themselves are objective (modulo axioms and inference rules).
There's a reason one of the most famous computer scientists and programmers titled his series of books "The Art of Computer Programming".
it's definitely possible to model programming as an art, and there is value in that model, but (imo) that model is neither productive nor accurate in most programming contexts
Knuth doesn't mean "art" as in "fine art to be admired" but rather "art" as in a description of something about which it is not possible to be purely scientific about.
He means both. From his 1974 Turing lecture ("Computer Programming as an Art" http://www.paulgraham.com/knuth.html):
> To summarize: We have seen that computer programming is an art, because it applies accumulated knowledge to the world, because it requires skill and ingenuity, and especially because it produces objects of beauty.
(See also, from an earlier paragraph “When I speak about computer programming as an art, I am thinking primarily of it as an art form, in an aesthetic sense.” — though the summary is a better reflection of his views.)
> To summarize: We have seen that computer programming is an art, because it applies accumulated knowledge to the world, because it requires skill and ingenuity, and especially because it produces objects of beauty.
(See also, from an earlier paragraph “When I speak about computer programming as an art, I am thinking primarily of it as an art form, in an aesthetic sense.” — though the summary is a better reflection of his views.)
I always said "Python is like writing maths, ruby is like writing english"
right! and, to build on that: people who see programming as maths understand it fundamentally differently than those who see it as prose, they approach every aspect of programming differently, evaluate "quality" on entirely different metrics, etc.
in my experience, this is a major source of friction in programming teams, and deserves to be addressed more directly -- if i had it my way, i'd prefer that those who see programming as prose would be disabused of this incorrect notion, but i understand that this is my bias speaking, and not any objective truth :)
in my experience, this is a major source of friction in programming teams, and deserves to be addressed more directly -- if i had it my way, i'd prefer that those who see programming as prose would be disabused of this incorrect notion, but i understand that this is my bias speaking, and not any objective truth :)
As both a writer and someone who has a degree in math, I see the segregation of prose and mathematics into fundamentally different categories as arbitrary, perhaps even incorrect. I see an artistic element to mathematics, just as much as I see a mechanical element to prose. The mechanics of the thing tell us what we can do, the art of it tells us what we want to do. Perhaps even _why we do it.
I find the strict separation of human intellectual activities into "soft" humanities and "hard" sciences kind deeply sad. I'm not claiming that writing is the same thing as performing a physics experiment, but to me, humanity is at its best when it combines both of these elements instead of keeping them apart.
i fully understand and appreciate the distinctions, and equivocations, you're describing here. i also agree with you that the best "stuff" acknowledges and maximizes both left- and right-brained parameters
my point is less about these abstract concepts, and more about the perspectives that human beings have when engaging with this "stuff"
concretely -- when i'm playing a musical instrument, my brain is in a mode that is completely different than, and totally incompatible with, the mode my brain is in when i'm writing a program, or working on a math problem
it's one or the other
why's book reads to me as a "playing an instrument" perspective on a "writing a program" problem, which doesn't work for me, at all -- personally!
other people, it works, i get that
my point is less about these abstract concepts, and more about the perspectives that human beings have when engaging with this "stuff"
concretely -- when i'm playing a musical instrument, my brain is in a mode that is completely different than, and totally incompatible with, the mode my brain is in when i'm writing a program, or working on a math problem
it's one or the other
why's book reads to me as a "playing an instrument" perspective on a "writing a program" problem, which doesn't work for me, at all -- personally!
other people, it works, i get that
I don’t mean it as a separation, it’s an emotional response to how I do things.
In fact my blog is called The Art && Science of Ruby
In fact my blog is called The Art && Science of Ruby
With Ruby I feel (feel being the operative word) like I’m free to get the computer to do what I want and create something that looks good and makes me happy.
But in other languages I immediately feel cramped and constrained - and the code looks ugly to my eyes.
As for correctness and quality, number one is it has to fulfil the business requirements I’m being paid for (and I’ve shipped lots of crappy code that I’m ashamed of but the clients are very happy) and secondary, I like to look back at it and see something elegant that also looks good in an editor.
Of course, the definitions of elegant and “looks good” are the real questions here.
But in other languages I immediately feel cramped and constrained - and the code looks ugly to my eyes.
As for correctness and quality, number one is it has to fulfil the business requirements I’m being paid for (and I’ve shipped lots of crappy code that I’m ashamed of but the clients are very happy) and secondary, I like to look back at it and see something elegant that also looks good in an editor.
Of course, the definitions of elegant and “looks good” are the real questions here.
yep! and i have almost exactly the opposite experience!
with ruby i feel (same caveats) like there is so much ambiguity that i can't build a coherent and predictable mental model of my program -- it makes me feel anxious and unsure
what you characterize as "cramped and constrained" i probably experience as "precise and unambiguous" -- it makes me feel calm and in control
no judgment from me about which of these perspectives is better or worse, i don't think there is any way to say that, just want to point out this interesting difference in perspective among practitioners
with ruby i feel (same caveats) like there is so much ambiguity that i can't build a coherent and predictable mental model of my program -- it makes me feel anxious and unsure
what you characterize as "cramped and constrained" i probably experience as "precise and unambiguous" -- it makes me feel calm and in control
no judgment from me about which of these perspectives is better or worse, i don't think there is any way to say that, just want to point out this interesting difference in perspective among practitioners
math is like writing a novel, though
I loved it and found it super funny and inspiring. Never cared about Ruby though.
Seriously, same here.
Yeah not my thing either, I'd rather see a cheatsheet and a few examples lol
You can't learn a programming language like that, unless it already has very similar paradigms to languages you already know. For example, try to learn APL[1] or Haskell like that (or just assembly if you haven't done any kind of assembly yet).
[1] And that's not just because of the arcane symbols.
[1] And that's not just because of the arcane symbols.
I think assembly is probably the one language family you'd find most success learning from a reference sheet.
Yeah, sure - as long as that reference sheet is the CPU reference manual.
Once you've been told what a register, a stack, and an addressing mode is (among other details), sure. But then you do know the paradigms already.
But of the languages I mentioned, assembly is certainly the one where the required concepts can be explained quickest, probably by far...
But of the languages I mentioned, assembly is certainly the one where the required concepts can be explained quickest, probably by far...
I would argue that it is the only programming tutorial that could be called literature.
Chunky Bacon forever!
I really miss his energy, crazy kind soul of his.
What is this?
Why the lucky stiff wrote a great, poignant guide to Ruby. A lot of people loved it and demanded more from Why. They decided they didn't want to be in the public eye even a little, and wrote a goodbye. I think CLOSURE is that goodbye?
This is broadly correct, yes. _why decided to leave, and did so. Years later, his website reappeared, containing the information I've collected here. CLOSURE is the title I gave it, because that is what I think it represents.
Has he ever reached out to you? His identity isn't that hard to work out - though he's no longer an engineer.
I think it's good to leave him alone, that's what wants.
I think it's good to leave him alone, that's what wants.
We have never spoken. He came to my hometown once, for an event, but I could not attend as I was out of town that weekend.
Part of me would love to talk to him someday, and part of me would prefer that we don't. I am incredibly thankful that he braved the danger to give us this; in some ways I do feel like this was us talking.
It's complicated.
Part of me would love to talk to him someday, and part of me would prefer that we don't. I am incredibly thankful that he braved the danger to give us this; in some ways I do feel like this was us talking.
It's complicated.
Thank you for your sensitive curatorial work, Steve.
Thank you for the clarification. I was hoping someone would correct me because I don't know the whole story. (But of course I wanted to help answer the question)
Worth reading through for a chuckle. Don't deprive yourself.
Why_ had a type of character we can easily forget used to exist, in this modern world where everyone is either slammed through cookie-cutters to become over-socialized slimy corporate people or medicated into a zombie-like state of partial existence.
Why_ had a type of character we can easily forget used to exist, in this modern world where everyone is either slammed through cookie-cutters to become over-socialized slimy corporate people or medicated into a zombie-like state of partial existence.
GitHub is one of the most frustrating platforms to try to read a pdf on. Would anyone mind posting a direct link? It’s basically impossible to get it to show on my iPad, and I forget the raw url syntax at the moment.
Sorry for the unrelated comment, but maybe the direct pdf link will help others too.
Sorry for the unrelated comment, but maybe the direct pdf link will help others too.
Perfect, thank you. Somehow the download button didn’t lead here, or at least didn’t trigger this for me. It might be because I have the GitHub iOS app installed.
this worked! thanks
Does this link from the repo's README help? https://www.dropbox.com/s/c0n2dljz8anih62/CLOSURE.pdf?dl=0
Thank you for the attempt. On an iPad it’s only a small step up from GitHub. Dropbox’s renderer doesn’t load in all the pages, so most of it is blank.
We live in interesting times. Everyone wants to invent their own pdf renderer instead of letting the host OS do it. :)
We live in interesting times. Everyone wants to invent their own pdf renderer instead of letting the host OS do it. :)
When you open it, there is a download button on the top right of the frame around the PDF.
My complicated feelings is that producing it and consuming it was all very unhealthy. There is nothing mystical about a machine and it isn't curious or interested that you can make a universal machine do the logic of any conceivable machine.
I feel these works did a lot to hobble people in their growth by putting too much emphasis on fantasy and not enough of actual understanding. I blame our mess of a JavaScript ecosystem on this idea that if you can dream it you can do it, and should do it, and that's wrong. It is like the old toddler wielding a knife thing, just because you found it doesn't mean you know what you have.
I feel these works did a lot to hobble people in their growth by putting too much emphasis on fantasy and not enough of actual understanding. I blame our mess of a JavaScript ecosystem on this idea that if you can dream it you can do it, and should do it, and that's wrong. It is like the old toddler wielding a knife thing, just because you found it doesn't mean you know what you have.
This take reads like you've never created anything for the intrinsic joy of creation. Not everything must be utilitarian. Art is still art even if its clumsily made or seen only by the artist.
Most of us do this to feed and clothe ourselves and our families. Its easy to lose sight of the fact that we're often engaged in creative, artistic pursuits. If you were lucky enough to become enchanted by computers before you had to keep a roof over your head you likely stayed up late writing code, tweaking parameters and watching the pixels or the numbers fall out the other end. Late nights driven only by your own curiosity and the joy you felt while doing it. No feature requests, design documents, or stakeholders except yourself.
Of course there is also the code that keeps the planes in the sky and the electricity in the wires, necessary and beautiful in its own right, but that isn't what this is about.
Most of us do this to feed and clothe ourselves and our families. Its easy to lose sight of the fact that we're often engaged in creative, artistic pursuits. If you were lucky enough to become enchanted by computers before you had to keep a roof over your head you likely stayed up late writing code, tweaking parameters and watching the pixels or the numbers fall out the other end. Late nights driven only by your own curiosity and the joy you felt while doing it. No feature requests, design documents, or stakeholders except yourself.
Of course there is also the code that keeps the planes in the sky and the electricity in the wires, necessary and beautiful in its own right, but that isn't what this is about.
There are many replies to this story about how it got people into the field of programming? Art is one thing, and I'm sure it was a great feeling to create leftpad but these writings sell a mystique that doesn't exist. It has always been people and relationships. I guess I don't know how to explain how it appeared to experienced professional working developers. It was like, here have a ticket for the burnout ride.
Most of us that would've been into _why's stuff now have more traditional-looking jobs and responsibilities. But I'm so grateful for what he showed us then, and miss the more genuinely human, broken and vulnerable community he represented.