Closure, from why the lucky stiff (2013)
github.com
github.com
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.
I worry a lot that I contributed to how this is now, too, in my professional life.
Edit: maybe “how” would be a better word to use.
It's strange to observe a world I dislike even though I was part of the wave driving the change.
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.
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.
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.
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.
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 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.
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).
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.
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.
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).
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.
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.
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'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.
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.
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 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 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.
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.
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.
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”.
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 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.
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.
Ah, has Portland moved on from keeping alive the Dream Of The 90s to the Dream Of The Late 2000s?
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
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.)
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.
ahahahahahha
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
Thanks for the talk!
"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.
[1] https://developers.hp.com/hp-printer-command-languages-pcl [2] https://support.hp.com/us-en/document/c06242096
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.
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 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 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.
--
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.
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.
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...
EDIT: I am now realizing that, ironically, maybe that is appropriate...
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
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.
[1] And that's not just because of the arcane symbols.
But of the languages I mentioned, assembly is certainly the one where the required concepts can be explained quickest, probably by far...
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 learned Fortran in the 80s from the Fortran Coloring Book.
(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
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 fact my blog is called The Art && Science of Ruby
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
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.
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
> 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.)
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.
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).
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.... :)
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.
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 think it's good to leave him alone, that's what wants.
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.
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.
Sorry for the unrelated comment, but maybe the direct pdf link will help others too.
We live in interesting times. Everyone wants to invent their own pdf renderer instead of letting the host OS do it. :)
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.
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.