I've always felt this was a singular achievement, one which perfectly captured the spirit of its author, the community he inhabited, and a particular zeitgeist in programming and on the internet. The need for various other authors to attempt to replicate it for other languages by creating rambling, twee books with wacky titles and comic characters of their own, I've frankly found a bit sad and underwhelming. It's a bit like Boaty McBoatface. It was funny because it broke all the traditional austere rules for naming things, not because Nouny McNounface is somehow innately funny. And yet the joke is replicated endlessly as if each time it's possible for it to be new.
This about sums up most Monty Python and Rick & Morty references as well.
A lot of nerd/hacker culture falls into this kind of recognition of unique humor and wit, then squeezing every little drop of joy out of it until it's as empty as a Garfield cartoon.
> A lot of nerd/hacker culture falls into this kind of recognition of unique humor and wit, then squeezing every little drop of joy out of it until it's as empty as a Garfield cartoon.
Or maybe they truly enjoy it, and you're also witnessing the lucky 10,000 effect (https://xkcd.com/1053/)? I mean, not to be insulting, but talk about humorless . . .
I think the parent was suggesting that if you enjoy something and want to replicate that feeling in others, one won't be able to do it by simply recreating the surface elements without the context of what made it unique. Garfield is a great example. Garfield's initial popularity stemmed from him being a sharp turn from the cat depicted as the "cute, lovable pet". He was fat, judgmental, and sarcastic. Countless movies, TV shows, commercials, etc. have watered Garfield down to just a face that means nothing. Maybe there are still a lucky 10,000 for Garfield but they're not getting that same experience.
But he mentioned "Rick and Morty" and Monty Python. I myself didn't even see a single episode of "Rick and Morty" until last December when I binged them all at my brother's place. Yeah, I had heard of it, was vaguely aware of the memes, but paid it little attention. When I did finally watch it without having previously been bathed in the hubbub surrounding it, I found it at times darkly funny and deeply touching.
> I've always felt this was a singular achievement, one which perfectly captured the spirit of its author, the community he inhabited, and a particular zeitgeist in programming and on the internet
There’s been a talk earlier this year based on that, by Sunny Ripert: “A poignant look back at "why the lucky stiff's" legacy”
Thanks for posting this! I’m aware my curmudgeonly tone set the stage for further grumpy comments but I want to reiterate that I do actually find _why’s guide delightful, I just don’t think other attempts (which it would probably be mean to name) work outside the narrow circumstances of the original.
reading this stuff i always feel like the author is trying to keep my attention by jiggling some car keys in front of my face as if i am an infant. this applies to books like learn you a haskell too.
If a person was anxious to learn Ruby ASAP and found this guide, it would've been frustratingly sparse and meandering. And the humor is too laid-back to be laugh-out-loud funny. But I think you just weren't the target audience.
I found it on a dull day at school, and just kept reading the way you might a web comic. I wasn't rolling on the floor, but I cracked a smile pretty often. And I picked up ruby (and some new-to-me concepts like lambdas, closures, etc) almost by accident.
Fully agree. There are lots of "normal" programming guides for a language as popular as Ruby. This is really good at appealing to the type of person who would really like Ruby.
I agree, but I really hate those books that try to be funny and quirky when trying to explain a technical subject. Give me K&R every single time.
The problem is not the humor or the silliness, the problem is that for a newbie it is impossible to distinguish what it is important from what is not, what is an exaggerated truth for comic effect and what it isnt. This is a sin very common in popular science/technical books.
"Dont worry about not understanding General Relativity. In a certain sense the concept is very simple, space bends according to the mass/energy distribution like fabric under a heavy ball (maybe the bowling ball of your uncle Bob), so it becomes curved.... and that's why you derive the Christoffel symbols from the Lagrangian of the equation of motion under a given metric.
TBF, input is generally linear; prior to experiencing both, one will be better suited to go first. Usually because it makes the broader concept-space - and thus the second - more generally accessible.
Knuth's presentation on his new project, a replacement for TeX, called iTeX, which offers monthly subscription plans, and discounts for seniors and children under 5.
I found it delightful and I just found it a couple of months ago. It intrigued me and encouraged me to learn the language. And I am reading ruby guides and manuals in late nights. I have no idea _why.
I think the book spoke to my heart. Or I am an infant who is attracted to weird stuff. My point is, it is helpful to some people.
I have a similar personal reaction but let’s recognise that the whimsical narrative mode of teaching appeals very greatly to many others, including folks that hadn’t previously realised they could program a computer too.
I do not require that my peers think in the same fashion as I do. Quite the opposite.
It really is a pretentiousness held in a group of language zealots.
You don’t hear the same about Nim, for example(yet?), In my experience.
I don’t deny Ruby’s impact on the industry I just have a hard time with the attitudes prevalent in the devs I’ve worked with... it is strikingly stereotypical.
Complains about the "pretentiousness" of Ruby developers (Out all the languages!). Proceeds to mention Nim. Rub his mustache, drink his kombucha a put another vinyl.
I don’t see your point. A large base of Nim users are looking for a pragmatic alternative to the C/C++ family without the aggressive anti-modernism of Go. Nim is certainly not the only player in this realm, but far as I know there isn’t a “Nim Drama” Twitter or tumblr. The drama queen stereotype of Ruby and Rails is very well earned on a repeated basis. All the communities have had their dramas but Ruby and Rust to a lesser extent seem to attract it a lot more as a pattern.
This is a real shame, I think, because the same things that made Ruby and its community such a revelation in the early years of this century (as a sort of revolt against enterprise development and especially the Java ecosystem), make me quite like Nim in a world with the complexity of C++ and the restraints of Rust. To be clear I happen to like all these languages but I also value their many contrasting personalities.
> It really is a pretentiousness held in a group of language zealots.
Can’t tell if this is ironic or not, but Rubyists are pretty well known as the friendliest out of all language communities, and have been for over a decade now
From my experience both inside the Ruby community and out, it is pretty much exclusively Rubyists saying that about themselves. Almost every community I've seen considers itself inclusive and friendly.
We are always on the receiving end of some claims. The feeling of easy accomplishment and unhindered flow is not something you get from every language out there, and not all languages explicitly advertise themselves as "maximizing developer happiness". I've never focused on lisp or emacs, but I am neutral towards their claims that god wrote the universe in lisp. Same with a perl user's claims of succinctness. I don't judge or envy them. Won't know until I learn the language and its tooling. And you won't really know until you try chaining a few map/reduce/select operations and have them compute lazily in ruby.
The essence of comedy is confounded expectations, and it’s true repetition can set this up, and in some cases itself be the joke, especially in standup where a comedian will stretch out a bit beyond people’s comfort zone. But it would be difficult to achieve that with Nouny McNounface at this point. Just making a callback isn’t funny. It’s only funny if it takes time to actually dawn on an audience that that’s what’s happening.
When you've heard your kid tell the same "knock knock" joke 50 times, you'll realize that repetition alone isn't enough. Repetition is an important part of humour and communication in general, but context, surprise, originality, irony, and wit matter too.
_why was at the FOSCON at FreeGeek 10+ years ago. I walked up to him, and he looked at me and said "You look familiar."
Looking back, I'm sure we had never met. I just think he probably did that to build connection with anyone he met, and I loved that moment with him. There was amazing intimacy that he created everywhere.
I'd think he'd do that to hedge against not recognizing someone whom he should've recognized and looking as a douchebag in the process. I hear that many recognizable people do this. At some point you just see so many people and many of them expect you to recognize them, so you just act as if you do recognize everyone.
It is not an exaggeration to suggest that If I - liberal arts graduate focusing on technology in academia - had not found _why's guide, I would never have believed I had a mind capable of doing code professionally. I will be celebrating my 10th year in the industry soon.
My understanding is that he burned out and had to take himself offline. He used to be involved in quite a bit (also see Hackety Hack), and it can be really exhausting for some people. I'm hopeful that he found the balance that he needed, and glad for all the contributions he made along the way.
My understanding is that his "true identity" got outed and he disappeared off the scene after that.
Imagine! The guy was both an insanely productive programmer and Ruby evangelist. He gave more to the community than anyone could repay. And what did he ask for in return? He asked to be the Lone Ranger.
All he wanted was anonymity. He wanted to be the masked hero who rides in, does a bunch of good, and then gallops off before anyone has had a chance to thank him. He was an eccentric, a romantic. That romantic eccentric was a benefactor who asked basically nothing in return.
And some nobody decided it would be fun to pull off the mask. Who was that? We'd have to look him up to know his name. He ruined it for _why and for the rest of the Ruby community. Why? What for?
It's not so much that I'm sad that _why is gone, as that I'm sad that there aren't more people like him. We went from having one _why-like force in programming to having zero. And that is the shame.
When I found this as a ~15 year old I had farmer parents who were pushing me away from computer based careers because they didn’t want me to “waste my life in front of a box”. I had done some C++ coding small adventure games but programming then still felt really cold and academic.
When I found Why’s book, I loved it. I thought it was funny, dark and moving. It wasn’t about programming, Ruby was a sidecar to this person expressing themself in an incredibly vibrant way. I felt like: wow, there are people like me in programming, too!
Now I run a 30 person product shop in NYC. I may have never learnt to code if not for Why.
I'm more and more convinced Rails has caused much of the demise of Ruby. As well as make it big in the first place.
I love Ruby. And with a decade of fulltime Rails development, know and like both Rails and Ruby very well. But 'sharp knives' have caused just too many rails projects to become mudballs over time. This makes teams or companies 'move to language X'. When it really was (their use of) Rails causing the mudballing. Let alone Ruby.
'Performance' is often cited, but I'm certain hardly anyone ever had severe performance issues in practice with Ruby. Maybe with Rails, probably activerecord and quite likely their own implementation thereof. But hardly Ruby the Language
1. Start writing software -greenfield-. "Wow this framework is really neat".
2. Grow it over years. Maintain it. "This language/framework/architecture really sucks"
3. We should rewrite it in Rust. Goto 1.
The real problem is that architecture is hard. Maintainance is difficult, scope creap a thing and accumulating technical debt will kill you eventually.
In Rails, getting a Proof of Concept "blog" out there, is done in hours. But all the "shortcuts" like "throw in Devise for auth" will get back to you in future, turning "hours of rapid development" into "months of stagnation". Getting a basis that will survive pivots, quick market changes, scope creep and allow to tackle technical debt when time is right, takes years of experience with not just Rails, but with "software architecture" in general.
Yes, no argument there. Growing projects is plain hard, no matter what language/framework you use. People talk so much about stack choices as if that's where the problem/solution lies. It's more about building effective teams, respecting seniority, not churning out your employees, having good product people (e.g knowing what to build). That's way more important to most businesses than the endless chat about graphql/react/rails/node/php.
But as techies, we tend to view every problem as a technical problem that can be solved by throwing more graphql at it...
Off topic, but how do you evaluate whether you should switch stacks? I have lots of Ruby experience and am not that young anymore. The "easy" thing for me to do is sticking to Ruby, but I'm sometimes anxious about the availability of jobs 10-15 years from now.
> It pretty much did, but then Rails and Ruby's hype cycle faded a bit
It was Rails' hype cycle that turned me off using Ruby & Rails in the first place. It had more in common with the cult I grew up with than I wanted to be part of, and made it hard for a sceptical outsider to get in.
Which is a shame as I think I'd have enjoyed it very much.
I couldn't stand DHH's "I'm right" attitude about everything. I listened about programming and then he started talking about things I know lots about and I realised he wasn't exactly wrong, just hadn't seen other ways of doing things.
You left out Python 3. That lack of a clear transition from Python 2 didn’t help. Despite that, I still think it’s great, but it made it multiple times more difficult for a newbie to get setup.
I've not done Python outside playing around really early on in my career during an internship, but I've never felt attracted to it; the 2 vs 3 debacle, installing the odd tool is like "what" (yeah just do `pip install this`, but first you need to install pip by using `easy_install`), and I've heard dependency management and environment setup is still quite backwards.
It needs a big ecosystem and tooling overhaul for me to be interested.
ATM I'm doing Go, which seems to have gotten the tooling part right at least.
Smalltalk did not have the ?/! delineation that GP is specifically talking about. Not that Ruby used it consistently (it was largely just for enumerators e.g. Array#push rather than Array#push!).
Does anyone know if this site was recently put together or if it's been around all along? WHOIS says the domain was registered back in '14. I love _why's writings and largely credit him with getting me excited about using Ruby back when I was in college. Really nice to be reminded of his work.
Although I am fascinated by _why's personality and his art, I think this book is partly to blame that Ruby is not as popular as it could (and should) have been. It somehow embodies that proto-hipster vibe the Ruby community used to have at the beginning, which alienated a lot of potential users. Luckily I managed to overcome that initial hurdle (the Pickaxe book helped a lot), but a lot of (good) developers I know haven't, and lots of them stayed with ASP (and its later offspring) and PHP.
I feel that Python is more to blame for that. When you have two similar languages but one of them takes away the paradox of choice, it’s gets evident why more people would choose Python in the end.
I don’t get the hate for Why the Lucky Stiff. Why does every programming book need to be K&R? Not everyone wants to read something as dry as a white paper all the time.
> Not everyone wants to read something as dry as a white paper all the time.
But some do, and _why's stuff isn't that.
You answered your own question. People like different things. Some didn't like _why's stuff; I'm one. I'm sure the guy is perfectly delightful, I just didn't enjoy nor get much from his writings.
Odd. I ended up in the Python world, but printed out a copy of Why's (Poignant) Guide to Ruby and read it because it reminded me that making stuff is fun.
Every time this book is mentioned, I feel like a moron.
I learnt ruby reading books, going through the koans, the rails turorial from M. Hartl... But I could never ever understand the poignant guide to ruby. I mean, I got paid to write ruby for several years so I obviously learnt the language, but I never understood what Why’s book was about or how it could teach me ruby. Just completely went « whoosh! » over my head at the time. And it still does.
By analogy you're pretty much saying that you don't understand Sesame Street -- educational material plus silly gags. What's not to understand? It's a comic, a comic strip whose putative subject matter is the teaching of a particular programming language. What's not to get? Why does that conceptual union go over your head?
If a counting numbers tutorial can be taught by a vampire puppet in a TV show then a programming tutorial can be couched in the form of a comic strip with talking foxes.
Maybe I'm taking you too literally. I mean, are you saying that the Poignant Guide is not to your taste? I'd understand if you were saying that it isn't to your taste. But you don't appear to be saying that -- you appear to be saying that you essentially don't get how the genre is meant to work.
> Every time this book is mentioned, I feel like a moron.
Admitting you don't know or understand is the first step to knowledge. And this may not be a shortcoming on your end - many Great Books of literature are well-known to be good enough that you get something out of them upon each reading, hence those lists of "ten books you'd take to a deserted island."
Perhaps there are technical works like that, and this is one of them? Not arguing for obfuscation, just that some concepts don't boil down easily into bite sized chunks, and very often those are the most valuable.
Maybe. I just wish I could see what people see in this book, at least out of curiosity.
To me, it’s a very convoluted way to learn ruby with a ton of irrelevant comic strips and pop culture references I don’t get that just add to the sizable cognitive load of learning a new language.
> To me, it’s a very convoluted way to learn ruby with a ton of irrelevant comic strips and pop culture references I don’t get that just add to the sizable cognitive load of learning a new language.
Fair, and to each their own. I do appreciate having cut and dry specs and whitepapers, but too often I feel that we as programmers take things too seriously and take for granted aesthetics. And while aesthetics may be subjective, for me at least, having multiple ways to approach something (like a new (to me) programming language) helps me really wrap my head around it and build a mental model.
FWIW, I'm in your boat. I never "got" it, though I had some years of Ruby experience under my belt by the time it came out. The whole thing felt rather cultish without ... substance, to me.
But, people I respect love it, so I guess it's just different strokes for different folks, and that's perfectly fine.
The guide's intro reminds me of the SICP intro in that it asks you to put aside your expectations and come learn about this cool thing.
Guide:
"My conscience won’t let me call Ruby a computer language. That would imply that the language works primarily on the computer’s terms. That the language is designed to accommodate the computer, first and foremost. That therefore, we, the coders, are foreigners, seeking citizenship in the computer’s locale. It’s the computer’s language and we are translators for the world.
But what do you call the language when your brain begins to think in that language? When you start to use the language’s own words and colloquialisms to express yourself. Say, the computer can’t do that. How can it be the computer’s language? It is ours, we speak it natively!
We can no longer truthfully call it a computer language. It is coderspeak. It is the language of our thoughts."
SICP:
"I'd like to welcome you to this course on computer science. Actually, that's a terrible way to start. Computer science is a terrible name for this business. First of all, it's not a science. It might be engineering or it might be art, but we'll actually see that computer so-called science actually has a lot in common with magic, and we'll see that in this course"
Ruby is an appealing language for sure , but is it worth learning it in 2020, with the intention of getting paid for one’s work? It is an honest question and in no way am i trashing the language. Just curious what others have to say about it
Yep, absolutely. Python has taken off in a major way for data science / machine learning work, but Ruby is still a fantastic option for web apps and for general purpose programming, with a great community. You can be productive in it very very quickly.
I may be biased, but I find Rails and Ruby conventions still more intuitive and less surprising than Django, especially when onboarding new people.
I think if you ask ten developers, you'll get ten different rankings like this, with minor overlap :)
It's going to be really really really dependent on your field of work, your career experience and network.
I'm not even going to attempt to offer a top five list, because I'm sure it will be wrong :D
FWIW, I would not base your decision on what language to learn only (or even mainly) based on "what's the most common language in use".
There's more than enough work in the world in all common languages, unless you're talking about really obscure research langs.
There's also value in getting expertise in something more niche - because fewer people know it, you can make a bigger impact and have less competition. It's also a powerful status signal - if you tell me you enjoy working in "Python and Haskell" or "Ruby and Erlang", versus "C# and Java" I'll have a very different impression of you (as unfair as that may be).
In summary, I'd say, try out a few languages, and learn the ones that you enjoy the most and feel most productive in. You'll spend most of your waking hours thinking in it, you might as well pick something that is fun for you to express yourself in, rather than a language that you have to fight.
If you’re planning on creating something that you can build a business around, yes. If you’re learning from scratch and want a business as quickly as possible, Rails is your best bet. If you want a job working at companies where they use Ruby, also yes.
Just search HN for the current year and you’ll find threads like “what framework should I use for <current year>“ and the common denominator over the past 10 years is Rails (or the language/framework you know better than Rails).
There are absolutely Ruby jobs out there that will pay your bills, and it's absolutely a successful ecosystem with which you can build effective modern products.
That said, in 2020 if you're picking a language, I don't think it has the most jobs available (probably JS), or the best paid jobs available (something ML, maybe Python), or the most interesting jobs available (up to you). For similar reasons, I'm not sure it's the best language to pick for a new product - it doesn't have the largest community or most momentum nowadays, it's neither the forefront of powerful tech nor the backbone of rock-solid boring tech.
If you already know Ruby, or you just want to learn it anyway, it's definitely not a bad choice. If you're choosing afresh though with no specific reason to pick Ruby, it's probably not the right choice.
I'm not writing it right now, but have never had trouble find really high quality work (in NYC and elsewhere). The community is active and generally very friendly/positive.
The ecosystem is obviously rails-heavy, and you have to like that, but the skills translate to python jobs well too, and rails has done a good job both keeping up with modern trends and staying modular.
Great. Im based in NYC but have been doing .NET for a while now and am rather turned off by it, the types of solution I’ve been working on are too damn complicated for no aparent reason
In one way or another, Ruby has been helping me pay my bills since 2008. I've used other languages, worked in various industries, embedded, robotics, healthcare, from freelance to full-time, etc... Ruby, SQL, and bash have been the only constants for me.
Just today, in fact, I had a phone screen for a (non-Rails) Ruby position and I'm not even really looking.
I'm currently hunting Ruby roles in Europe (that will sponsor a visa to move continents) and it seems like recruiters do not have a lot of roles open for Ruby. They want to know about the Java that I did 10 years ago, or whether I have Kafka, Python and machine learning, or maybe some JS.
Maybe this has something to do with the few Ruby giants not taking CVs from recruiters, but those giants aren't calling me back either. :shrug, maybe it's just me.
I don't see a lot of new and exciting things being done in Ruby, and I don't think it's a popular choice for highly technical companies any more; even if you find one company doing cool stuff with it, do you want to be looking for a job in 5 years' time having spent 5 years in Ruby?
Rails is still the fastest way to bang out a CRUD webapp, and there's a lot of companies who use those webapps for critical parts of their business - but those also tend to be companies that are not primarily technical, for whom this is more of a cost center than a profit center (and who may well have outsourced the original creation of the app and then barely maintained it). So while you could probably make a career as "the tech guy" at that kind of company, it's likely to be an unrewarding position with limited opportunity for growth. (On the other hand, it might be a stable position, particularly with a big company in a lucrative industry like finance). Consulting for companies like that has more potential, but only if you're good at negotiation, as you'll likely face a lot of clients who want to nickel-and-dime you.
Well there's all the companies that were built around 2006-2015 with Ruby, when Rails was hot stuff. Many of them can't afford migrating to a new stack, or want to.
But generally I kinda agree - more is being created with other stack nowadays. A byproduct of that is way more people learn Python / Java as a first language, so you also perhaps need to think if being a Python guy gives you any edge when you turn 45-50 as hordes of young people learn it as we speak. Outsourcing a Python project is gonna be way easier 10 years from now than doing the same with Ruby.
I don't have clear answers btw, there's just pros and cons.
> Well there's all the companies that were built around 2006-2015 with Ruby, when Rails was hot stuff. Many of them can't afford migrating to a new stack, or want to.
Right, so either you're working for a struggling company, or you're working on the old stack while things are gradually being migrated and most new stuff is being done in a different stack. Maybe you'd find a company that is sticking with Ruby because they like it, but that's pretty rare, and probably means that company hasn't scaled past a certain point.
> A byproduct of that is way more people learn Python / Java as a first language, so you also perhaps need to think if being a Python guy gives you any edge when you turn 45-50 as hordes of young people learn it as we speak. Outsourcing a Python project is gonna be way easier 10 years from now than doing the same with Ruby.
Well if it's hard to replace you in your current position then that cuts both ways. So you might be able to find a comfortable position, but there won't be much opportunity for growth.
> Right, so either you're working for a struggling company, or you're working on the old stack while things are gradually being migrated and most new stuff is being done in a different stack
Well, currently I'm working for neither. Just a Ruby company that's doing well. I'm sure there's more of them. It's not as if the idea of a rewrite was never thrown, but honestly why would they? It would take years, all the while your old dev team needs to pick up a new language and your new hires need to pick up both Ruby and the rewrite language. If the whole architecture was service oriented that may be not too bad but many Ruby companies are running a few big monoliths.
Besides, this whole idea of lack of Ruby jobs seems weird to me especially if you're from North America. Mainland Europe is a different beast though.
Well, if a company is successfully running a Ruby monolith without hitting the scaling problems that would make it start cutting out services to implement in other languages then that suggests the company either hasn't grown past a certain point, or isn't doing anything particularly heavy technically.
That's a controversial topic though. Keep in mind that companies like Github and Shopify showed us it's damn well possible to scale massively with a monolith.
But I take your point as being correct, there are quite a few Ruby companies who didn't reach Shopify/Stripe scale (is that a problem though? and if so - why?)
> there are quite a few Ruby companies who didn't reach Shopify/Stripe scale (is that a problem though? and if so - why?)
I think it makes for an environment that may be comfortable, but one where it's harder for a technical person to grow. It's not just about scaling, it suggests the company doesn't have major technical challenges - in which case the company probably isn't technically innovative (which doesn't make it a bad company or a bad business, but does make it a bad environment to pursue a purely technical career). Of course scaling isn't the only way to get interesting technical problems, but I've not seen people favour Ruby for heavy algorithmic work or anything like that either (though I'd stand to be corrected) - rather the great strength of Ruby is rapidly rolling out UI, so it tends to be chosen for problems where the UI is a large proportion of the thing you're building.
> but I've not seen people favour Ruby for heavy algorithmic work or anything like that either
I suppose if Shopify / Github have heavy algorithmic work they do do it in Ruby. I think you have a somewhat different understanding than I do on what software devs do most days. And it doesn't matter if it's php/ruby or java/c++, so many of us, I believe, just glue pieces of business logic together. If you happen to have a problem that's purely algorithmic (let's say finding the shortest path on some map), the first thing most devs I know would do is look for an open source solution for that (and if one doesn't exist in Ruby, you can always wrap it in a Ruby API).
That's what I know about most of software engineering, you have a different take (now of course there are different fields like embedded etc which I'm not referring to, I speak only of high level business logic coding).
> I suppose if Shopify / Github have heavy algorithmic work they do do it in Ruby.
I'd be surprised. I'd expect they'll implement it in something else and interface to it in Ruby.
> I think you have a somewhat different understanding than I do on what software devs do most days. And it doesn't matter if it's php/ruby or java/c++, so many of us, I believe, just glue pieces of business logic together. If you happen to have a problem that's purely algorithmic (let's say finding the shortest path on some map), the first thing most devs I know would do is look for an open source solution for that (and if one doesn't exist in Ruby, you can always wrap it in a Ruby API). That's what I know about most of software engineering
I think most software devs spend 95% of their time plumbing together existing things. But I think there's actually a very big difference between that and spending 100% of your time just plumbing together existing things. I wouldn't expect to do serious algorithmic work every day or even every month, but I think if a company is truly technical then it should be doing something that goes a little beyond what's in pre-packaged libraries, and that's often the most fulfilling part of the job.
Shopify (along with its millions of shops) is probably the biggest user of Rails (with Ruby) in production. Aside from them, not sure who uses Ruby at that scale.
I learned basically nothing from this book. Maybe if I were a new programmer it would have helped but as an experienced programmer I found its pedagogy too distracting to learn anything. But Ruby is easy to learn and fun to use. The headline about it is that code can be executed in a class definition. If that's not broadcast right at the beginning, it'll take a long time to learn what's going on in Rails.
I'm pretty sure it was _why who set up the first darknet I was ever on. You had to set up your /etc/hosts and do some other tricks, to browse to hidden pages. Unless I'm confusing with another similar thing around the same time, there was some JS involved and you could find hidden features layered on regular websites.
This book always brings back good memories for me.
If you are interested in diving deeper into _why's work you can find a comprehensive catalogue of his public works here https://viewsourcecode.org/why/.
I learn't my first Ruby with Why's guide and will always be grateful.
For me the most important point is the simplest: that learning things should be fun. We're too serious about lots of things, making it fun not only makes the process more enjoyable - it's more effective too.
For me, this is one of those quintessential software books. Reading it takes me back to 2005, when I was in college — not studying CS but still building for the web as I have been since I was 13 — and feeling so seen to see a book/collection of essays/language introduction written in an original and irreverent style much more akin to Dave Eggers than anything else of the genre.
I never really embraced Ruby — though I always admired it and adopted TextMate like all the other cool kids — but this and _why’s other work stuck with me as sticks with me now.
I've tried Ruby (and RoR, which, while I've never used it professionally, has had a huge impact on the whole realm of web application development that I'm into), but I never fully understood it. Made a first RoR app from a book, but when trying to deploy it I ran into a minor issue (probably wrong database configuration), apparently I had to restart the application but the webhoster I used did not give access to restart the thing so I just sighed, gave up, and went back to PHP.
I miss why. He was great to work with. His mind worked in differently than anyone I've worked with. He was still so nice, humble and a good teacher. Famous for Ruby, he could twist any language to solve a problem - or twist it just for the fun of it.
I miss _why being out there, producing content. He reminded me of the Beagle Bros books for the Apple II, which were my first introduction to programming in 1990 or so.
this is legitimately the worst programming book i've ever read. i wanted to get started with ruby back in 2009, and everyone was praising this book. i got it, read the first few chapters, and got bored out of my mind. it meanders and takes forever to get to the point. in the end, i never really learned ruby, and the main cause was this book.
Sorry, but blaming a single book for not learning something when there are an enormous number of other resources (and have been all along -- _why's was a long time ago, but so were, say Agile Web Development with Ruby on Rails and the others mentioned here, and there has long been tons free on the web) probably means _you_ were actually the main cause.
sorry but no. there's a lot of programming languages out there and it's the job that the programming language and its community to convince me to use it when there are many alternatives to choose from.
i don't have time to commit to learning any random programming language that pops into my field of vision at all costs.
a language is a tool. a tool was being marketed to me as something of high quality. i tried it, but because of poor instructions (this book), didn't get the results i was expecting.
so i cut my losses and moved on to other tools that actually worked for me.
This is a bit like saying you don’t like television because one day you tried one episode from one particularly unusual show from one specific genre and decided after that you would just listen to the radio since television failed to win you over, as if none of the other shows you never tried could ever possibly work for you.
I love Ruby and have been working with it full-time since 2014.
Additionally, I would say that my taste in humor and art tends towards the wacky and whimsical, and even twee sometimes I suppose.
But, like you.... maaaaaaaaaan, to say that book/guide didn't connect with me would be an understatement.
Among other issues I had, is that it begins (I'm paraphrasing) by describing Ruby as a seamless and intuitive extension of one's brain.
Now, I love Ruby, and think it's admirably friendly, but you still need a solid handle on basic computer science concepts to be good at it, and maaaaan there's a lot of unintuitive Ruby stuff out there and you hit it extremely quickly as soon as you venture outside of the standard library... and sometimes even before.
Even conventions like affixing ? and ! to methods is just a convention and ! is barely even a convention: it can mean "mutate in place" or "this method is going to try and do a thing, but might throw an exception instead so be ready to catch it" (ala ActiveRecord's #save!)
But... I am glad others like _why's work and get value from it.
I understand how you feel (personally, I really liked the book). I think it depends on your goal. If your goal is to just "get on with things" and essential read something more akin to a reference manual or a focused tutorial without any fluff, then yes, Why's guide is not appropriate.
While I enjoyed Why's guide, I found the Little Schemer book to be somewhat impenetrable in contrast. That book has a similar kind of style in the sense that it's in a non-traditional format and is widely praised, but I think it occupies the more intellectual / academic space than where Why's guide is targeted (that is, moreso at the regular Joe Blow programmer rather than someone who who lives and breathes everything CS). K&R seems to reach a good middle ground between practicality and whimsy.
This book is an art piece. That works for some people! Not others! The O'Reilly "The Ruby Programming Language" is the better choice; it has small contributions from _why but they're measured and appropriate.
I have to agree, but I wouldn’t be a dick about it. Lots of people enjoyed this book. For me, I can’t get through the first 30 seconds. My brain just rebels against this style. Partly because there’s something wrong with me, I can’t understand comics. Doesn’t mean it’s the worst book ever, it just doesn’t work for me. But it did have the effect of turning me off Ruby permanently.
Seems a little suspect to blame this book, when there were plenty of other excellent resources for learning Ruby at the time, and this one was obviously a little offbeat. For what it's worth I had the same experience with this book, but instead of blaming an artist whose book inspired thousands of Ruby programmers because it didn't inspire me, I moved on and got the Pragmatic Programmer's Ruby book instead, and I've had nearly 15 years of joyous Ruby programming in my career since. I'd say the main cause of you not learning Ruby was not this book, but your own behavior.
it has its place. If you already know how to code but are learning Ruby, it's not a good book (lot of fluff). But if you are learning to code for the first time it's good. This was my case in 2012.
I admit the comedy style is showing its age–a little cringe now.
yeah if you're actually 100% new to code, this book is pretty terrible, at least for the way I learn. if you're already familiar with the common programming concepts, then this book is probably more applicable, but still hugely inefficient.
i like it as a thing that exists, but I got started programming via self-taught ruby, and the _why guide had almost nothing to do with that, despite wanting to like it.
I've been trying to figure out at which point ruby turned from hero into villain, but I feel like it's more a generation gap rather than some series of acute moments.
When a proof of concept app hits a multi-million+ requests a day.
Suddenly your large monolith app that has been fine for years falls apart.
So you rush out and higher 10 react developers, 10 go developers, and 10 support engineers to try and write a micro service replacement while keeping the ruby app alive long enough to finish the rewrite. Oh and an elixir developer somehow managed to sneak in.
Meanwhile your original 2 Ruby developers moved on, and their replacements are treated like dirt since Ruby Is on the way out... for a few years.
Let's not say "Why do Rubyists like this…", consider instead "Why do humans like this…". Some of us liked it because it was fun, and appealed to our sense of humor. Ruby was weird back then. Some of us didn't like it, and for them there was the Pickaxe book among others.
Personally I loved what _why did in the early Ruby scene. In fact one day I cold mailed him because I was feeling rather blue, and he sent back a link to a new project of his he hadn't released yet that blew my mind back then. It was smaller community, and there was more room for play and joy.
It was a sandboxed online Ruby interpreter. Oh gosh, it must have been at least 13 years ago now. The idea that I could execute arbitrary Ruby in a web based repl taking to a server was pretty wild then. Now with docker and web assembly we have lots of options for this kind of thing, but then it was quite exciting.
Honestly, I would not recommend this book to somebody who wanted to learn Ruby.
I wouldn't recommend this to somebody who had a serious project or task to solve.
However, I love that this added flavor to the Ruby community. For years afterwards people would hide Easter eggs like "chunky bacon" in their conference slides. It was a fun inside joke to share with fellow Rubyists.
I mean, Python has references to Monty Python skits in their stuff.
_why was not writing for an audience of people who wanted to learn a programming language to get a job to make money. There are certainly people who did get that out of The (Poignant) Guide, but it wasn't the primary goal. The primary goal, as I understood it, was to share a way to find joy in a particular way that humans can interact with computers.
