Why's (Poignant) Guide to Ruby (2004)(poignant.guide) |
Why's (Poignant) Guide to Ruby (2004)(poignant.guide) |
I always suspected that ROR's popular with young programmers in the 2000's had more to do with Why's writing style than specific merits of ROR.
I still love Ruby and use it all the time.
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.
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.
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.
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.
I admit the comedy style is showing its age–a little cringe now.
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.
I feel like you might be a bit confused about the relationship between the world and one random person.
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.
(Although I suppose a case could be made for it still being "empty.")
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 . . .
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”
https://m.youtube.com/watch?v=njr39cVU7d0&list=PLjyiiigeVQV-...
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.
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.
The whimsy was a welcome relief.
Someone with your taste would be better off reading The Art of Computer Programming though.
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 do not require that my peers think in the same fashion as I do. Quite the opposite.
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.
Quite the opposite. It's replicated because it's now become a trope.
"Repetition is the essential comedic device": https://en.wikipedia.org/wiki/Comedic_device#Repetition
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.
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.
each, unless. It's just such a beautiful language.
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
I always missed the simplicity of Python.
Ruby community was just awesome. Pushing at the bleeding edge of getting stuff done fast, if a bit magical.
Been debating about going back. Cleaning up 8 year old magical ruby apps is getting old.
It pretty much did, but then Rails and Ruby's hype cycle faded a bit, and Python kept going, recovered and found new niches.
https://web.archive.org/web/20150310154942/https://poignant....
It used to be on a different domain. Just checked my email history and I sent a link to it in 2008 when it was hosted at a .net domain.
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.
It's not hate.
> Why does every programming book need to be K&R?
It doesn't. Nor do NONE of them need to be.
> 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.
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.
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"
(https://ocw.mit.edu/courses/electrical-engineering-and-compu...)
Why the Lucky Stiff and The Thirsty Cups at RailsConf 2006
Enough magic is fine, productive, but too much magic (Imagine making your own magic with Ruby) will make you hurt.
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/.
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.
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.
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.
Consider Logicomix: An Epic Search for Truth https://smile.amazon.co.uk/Logicomix-Search-Truth-Apostolos-... -- a biographies of Frege, Russell, and Gödel and the history of predicate logic in comic book form …
Or consider The Thrilling Adventures of Lovelace and Babbage: The (Mostly) True Story of the First Computer https://smile.amazon.co.uk/Thrilling-Adventures-Lovelace-Bab... -- a history of early mechanical computer science in comic book form …
Or consider Understanding Comics: The Invisible Art by Scott McCloud https://smile.amazon.co.uk/Understanding-Comics-Invisible-Sc... -- literary criticism of the comic book form in comic book form!
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.
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.
I may be biased, but I find Rails and Ruby conventions still more intuitive and less surprising than Django, especially when onboarding new people.
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).
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.
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.
And, the language is faster than ever with 3.0.
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.
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.
Ruby itself is great but it’s everything around it that makes it so productive.
I've really enjoyed working with FastAPI in Python for web apps.
No, the problem isn't "reposting".
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?
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.
But, people I respect love it, so I guess it's just different strokes for different folks, and that's perfectly fine.
So Ruby Rails is bottom of the list.
1. Javascript.
2. Java.
3. Python.
4. C#.
5. C/C++.
I'm also weighing each of the against the difficulty of learning the language and the ecosystem.
Ruby could be nice but I doubt it breaks top 10 anymore. Your mileage may vary.
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.
https://www.youtube.com/channel/UC2AQkHXNVA-w9FA1m9VqO7A
My favorite may be this one, a one-hour single-take monologue about finding the meaning of life in a Garfield strip.
It made a lasting mark.
K&R is for one of those. _why's guide is for the other.
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.
Once they get the build fixed. Again.
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.
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.
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.
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.
You guys make this too easy. Unless it was sarcasm, so whoosh me, and chapeau!
Before you can have dozens of people fighting about a thing, you need more than a dozen people to care about that thing.
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
Pretentious doesn’t mean rude or unwelcoming and I don’t want to insinuate that.
Thankfully we grew out of it.
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.
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'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.