[throwanem]

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.

[ertian]

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?

[throwanem]

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.

[ertian]

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.

[throwanem]

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.

[ertian]

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.

[User23]

> 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.

[gsinclair]

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.

[alangibson]

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'

[throwanem]

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.

[hereonout2]

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.

[throwanem]

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.

[Tainnor]

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).

[throwanem]

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.

[hereonout2]

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.

[gensym]

> 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).

[throwanem]

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.

[gensym]

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!

[throwanem]

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...

[DocSavage]

> 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?

[throwanem]

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.

[DocSavage]

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.

[throwanem]

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.

[DocSavage]

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”.

[throwanem]

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.

[Tainnor]

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.

[throwanem]

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.

[Tainnor]

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.

[norir]

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.

[Tainnor]

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.