This is a 2009 post referencing a 2005 letter. Got my hopes up that _why was back!
For those unaware, https://en.wikipedia.org/wiki/Why_the_lucky_stiff _why’s legacy from things like https://poignant.guide/ was a radical shift in how web programming could be taught, and how fun and approachable (for folks of all backgrounds, academic and otherwise) it could be to learn. IMO we owe a tremendous amount of the modern startup landscape to him.
He's more of an idea and an ideal anyway. It's better this way, better that he never "returns."
Who wants to see Instagram posts of _why talking about the shitty hamburger he ate? He's always going to be a mystery to me and that's so much better than anything else could ever be. And the reason he is legendary only increases because of that.
_why will never return even if the person comes back into the limelight because _why was a character played by a specific person at a specific point in time. David Bowie did that a few times, some (The Thin White Duke) being more regrettable than others (Ziggy Stardust) but none of them being truly him, or really meant to last.
This is not a correction to/opinion about anything you said, but I happen to have this note handy on my desktop because I was caught trying to find different words for the same concept you were speaking of above with the word "ideal".
Found these words: archetype, prototype, ideal, ur-form, primordial (mathematics), formal cause, exemplar, Platonic form, essences, archetypal, original pattern, fundamental pattern, first principle, protype, paradigm, archetypical
Just mentioning it as an aside in case anyone's ever similarly trying to find the right word in the future.
I tried to read the poignant guide three times and hated it and stopped every time. Didn’t care about the cuteness, at all, and was super confused. Just my experience.
same here. different people like different things, but it was the opposite of what i'd like to see more of. fun yes, eclectic yes. silly? superficial? trite? not so much.
i appreciate the sentiment of _why, but quality, depth, rigor, and tenacity are also important. _why is no Richard Stevens.
if you fold up and throw a tantrum the minute that your 5 seconds of fame is over and you get to experience some real criticism and apathy and all sorts of other unpleasant things that successful people have to handle, it sort of underscores the immaturity of it all.
matz is still around, isn't he? hell, so is even larry wall.
The thing is, _why never wanted to be successful — specifically in the sense of having any of his prose work depended upon by others as pieces of education; nor any of his programs depended upon as pieces of engineering.
Rather, _why was pretty clearly an artist, and was trying — in both his prose and his programming — to make what one might call “experimental didactic art”: works that explore how to teach and how to learn (mostly, about programming), rather than works that use concrete teaching methods to teach particular concepts. The Poignant Guide, Shoes.rb, any of the libraries he spun off — they were all this. You weren’t supposed to use them; you were supposed to look at them, analyze them like a painting, think about the “brush strokes” involved in their construction, and from that, grow your perspective on education itself, and programming education in particular.
But people weren’t doing this. People were treating his “software artwork” like he had intended it all as FOSS projects — things to be contributed to and to polish and to grow, even at the expense of the original goal of representing an exploration of a particular idea, to be absorbed and stolen from. And people were treating him as if he was a core contributor to said not-projects, someone to submit bugs and complaints to, rather than someone who made their own finished thing as a statement and only wanted to discuss its meaning, not keep working on it forever.
matz and Wall are bad comparisons. A better comparison would be to someone famous for being a member of a particular band, who is now no longer in that band, but instead in a different band, making a different genre of music. Are they happy that people still appreciate their old work? Sure. Do they wish people would stop asking them about it? Also yes. Do they want to know that they played a wrong note on a song they recorded twenty years ago? No; what good would that do them now? Do they want you to fix that song of theirs for them, 20 years after release, because hey I’m a sound engineer and — no. Stop. It’s fine. It still works as art with the wrong note; and even if it didn’t, it’s long past its relevance; the people the art was aimed at, the people it was supposed to affect, already either got it or didn’t.
If an engineer takes all their software down, you might call that “throwing a tantrum in response to criticism.” But if an artist takes all their art from one “period” of their works down, they’re just doing something artists do every day: ending a gallery exhibition, either because the message it communicated either succeeded in becoming culturally embedded, or failed to resonate. For an artist, the value of their art is in the communication of thought it enacts, not in the art itself; a piece of art doesn’t have to stick around forever, it just has to be seen by the right people at the right time to nudge the world in the way the artist desired. (In extremis, this is why so many artists are perfectly happy making performance art, where each unique showing is done once, only for those there at the time, to never be experienced again once it’s over. The art was never the point; the communication was!)
This viewpoint makes a lot of sense and helps me understand better.
I like to be able to say “experimental didactic art” is not for me - without implying anything negative about the art or myself. And I really like looking at the author’s actions as the acts of an artist, including performance art. Frees me from the need to comprehend motivation.
> if an artist takes all their art from one “period” of their works down
Maybe I don't understand artists, but I'd be irritated if an artist did that too. Especially if it's supposed to be FOSS. And it's still throwing a tantrum anyhow (I guess artists are allowed/expected to be immature?) - I picture trope of the manic artist burning all his beautiful paintings instead of selling them to make rent.
What, did all the folks using his FOSS ever know it was just a temporary art installation? I wonder why they assumed he was a core maintainer and why they didn't realize that these FOSS projects where actually "not-projects". I wonder if that was ever prominently mentioned during his 5 minutes of fame?
Anyhow, yes, it leaves a bad taste when somebody is, as others have characterized it, LARPing as a FOSS core contributor and then just run off.
I would suggest picturing it more like a young and naive artist being pressured by a demanding community into gradually, accidentally assuming the role of a software engineer and project maintainer, when that's never what they intended to become, nor what makes them happy to do with their life; and is also something they had no training or skills to cope with the challenges of.
What you might call a tantrum, I would call "asserting your boundaries." Like cutting ties with abusive parents who keep barging back into your life, by deleting your Facebook account, changing your phone number, and changing the locks on your house (or moving to a different city.) _why's software art projects are the hooks other people had in him, so that's what he had to drop.
So why burn everything down? I mean he failed to completely do so, but he really tried to destroy it all. That's the tantrum. Asserting your boundaries is - "look I put it out there, you can take it or leave it. I'll do X, but I'm not going to do Y or Z. Don't push me." It is NOT "you guys didn't love me enough 100% so I'm deleting everything with no warning".
And there was nothing going on like an "abusive" relationship at all. Criticism != abuse. Work, commitments, expectations != Abuse. Just say "No. Hey I don't want to do this anymore, but I left all my stuff out on the curb". You don't delete it all out of spite with no warning. Option #1 gets sympathy. Option #2 is a major dick move.
"Immature". Yes that part is right. But we knew that already from reading the crunchy-bacon riddled adventures. And people didn't mind the immaturity and fun of it (I didn't like it too much, but then I'm just an old buzzard).
It didn't go wrong until he bailed and he didn't just bail, he burned it all down. That's the problem. That's the showing of the real person. He didn't just walk away and never look back. He said - if I can't have it, then I'll take it all back and destroy it.
That's not just an "artistic temperament". That's an asshole who didn't like the prize he fairly won and decided to be a dick about it.
Thankfully people who did care stepped up. I personally don't even like the stuff, but I never want to see it destroyed so those folks who stepped up are the heros. The system and idea of FOSS is the hero too.
I think the difference is in "worry too much". You can write shitty code and push boundaries. You can write clean code and push boundaries. But if you're spending too much time worrying about if your code is tidy enough to publish what you created (or not publish because it isn't), then that's time wasted on not exploring the idea.
There's been a few posts on HN that I remember which could be summarised as "I made this cool and useful thing, but I'm worried I'll be criticised because it's not polished enough. Should I just throw it away?" That's the "worry too much" view.
If you're developing something that you aren't currently capable of testing or keeping 'tidy', should you just give up? If you focus on developing that thing and make the tests work later, it is absolutely possible to push boundaries.
There was no testing framework capable of testing my latest JS library so I built my own; but here's the catch: the testing framework for the library is bootstrapped by the library itself, necessitating building a large amount of the functionality before getting CI in place.
I’ve spent the last two weeks agonizing over the design of some API endpoints for a side project I’m working on (clean and tidy).
This is stopping me from actually making any meaningful progress on some other challenges in the codebase. (pushing boundaries)
And for the actual problem: is drawing a card actually move with a source and destination?
/player1/draw
/move/player1_deck/to/player1_hand
I keep getting hung up on the fact that move feels “more right abstractly” but now the move endpoint has to know about _all states_ to know if the move is valid.
I am not a Ruby programmer, so this is the first I've heard of _why.
I don't think it's fair to comment on the person based on one letter - although I will say the tone is reminiscent of some folk in my community who have their own demons.
I can see that as advice to a new programmer, a call to experiment, play around, stretch skills, share small scripts etc is useful.
Once you start building more meaningful, long term, things in a team context, then things like consistency, tests, comments and do on become a lot more important.
I've been lucky enough to work with very bright people over the years. But for some of them, their code is hard to read, somewhat prone to bugs, and generally working with it is "disliked." It is slowly being replaced. I include some of my early code in this.
Over the years personally I've tried to change from writing "clever" code to "clear" code. The latter seems less impressive but ultimately lasts longer.
I think it's still good advice for programmers of all experiences.
I have worked with too many programmers that know everything about engineering and process but can't actually DO THE WORK or solving problems, applying data structures, innovating their way out of a corner.
They can go a long way with senior management because they speak all the right lingo.
But when push comes to shove, and a new system needs to be built, or a bug needs to be solved quickly and safely in production without backwards incompatible changes, or business requirements collide against technology options...they are lost.
You are describing "bad" programmers, and clearly there are no shortage of those.
But the advice in the post doesn't make bad programmers into good programmers - it just makes bad programmers "try to be clever" - which frankly doesn't end well.
Do some of these techniques help bad programmers _become_ good programmers? Sometimes yes. But then it should come with the caveat never to do it in "real" code. It might be a good learning tool, but it's a terrible production tool.
This makes me yearn for the days back when programming was still fun. Back when Ruby was my main language and the sky was dark at night despite my eyes being wide open. All I could see was code!
I just wrote some Ruby for a side project after ~7 years. The language is still fun, ecosystem is good, and things have progressed nicely. I never worried about "Ruby is slow" because I never used it at the scale/for software where it mattered much. That said, it's much faster now!
Maybe I'll go back to some Sinatra and CLI work I have been putting off...
Gotta say, last time I checked up on Rails though, it really depressed me how bloated it got. Maybe I'll just use ActiveRecord and ActiveSupport... but there was so much to love about Rails, I'm just really sad all the JS support kinda overwhelmed it from my perspective.
I've been doing Rails for a long time now and I'm not sure this is true. The latest release seems sleeker than the Rails 3 series. Back then we had RJS still going on and UJS becoming a thing. It's a web framework so JS will always have a place, and if anything I'd say they've finally sorted out the JS side to give you some saner options from the beginning - turbo/hotwire being just one of the options.
2011 college me liked his ideas. The me of today rolls my eyes. I want to finish this bugfix/feature and get home to my family. I cleaned up a few times after cowboy coders, it's never fun or enlightening.
well, you've cleaned something existing and running, and also received some money doing that. Who knows, maybe with uptight approach those things would never happen.
_why's message lands aptly upon those who cannot see the value in experimentalism. It takes a backwards kind of discipline to force yourself to push code you know isn't perfect. Sometimes seeing the whole before each part.
This mentality is what led me to my own methodology: Write everything twice, from scratch".
Of course, in practice there's never enough time for as much experimentation and rewriting as we'd like. Still I believe it's an ideal worth aspiring towards.
I loved his writing. I wish we could let _why go though. His creator did. It was a point in time, it wouldn't work the same now, and his final writing alluded to that.
Programming has culturally shifted. It's not as fun as it used to be, but it is more accessible and has less mystery about it. That was my time as a young programmer, if you missed out on that then that's too bad, but I missed out on previous and probably even more wild times - both my parents were programmers and I envy their experience. I'm sure there's slices of programming culture now that I have no access to that are again wild and exciting in their own way, just not in web or application programming. So the wheel turns.
Different things are fun, and the same things are fun in different ways.
Hardware hacking, for example, is "back" in that it's once again in the limelight for beginner programmers after a period of being too expensive and too limiting to be attractive to a lot of people. It never went away, certainly, but in the late 1990s it looked more like this:
That's a webpage which compares the BASIC Stamp to an Arduino setup. The upshot? The BASIC Stamp was about $120 all-in to buy the hardware plus a proprietary development environment, whereas a comparable setup for the Arduino is $60 (or less) for the hardware plus a more pleasant development environment, especially if you're coming from Python or ECMAScript and don't like the idea of learning a SHOUTY LINE-BASED 1960s CRUFTFEST that isn't even something cool like assembly language.
So in some ways we've circled back around, but it's more like a helix: Yes, kids are Making LEDs Blink Again, but this time it's with a language that isn't a dead-end and it's with hardware they don't have to be so paranoid about blowing up. Experimentation is more fun if you're not afraid of failure. It's the same point in some dimensions, but it's a few miles different in a different dimension.
Speaking of dimensions, Web programming has gained a whole new set of dimensions. Say what you will about webdev as a whole, there's few easier ways to show off your work than being able to give your friends a URL so they can just load and go. Shadertoy alone is, from a 1990s perspective, so cool my teenage self would have gone of the deep end with it.
It is a mystery why Ruby collapsed, and Python came to eat its lunch.
Python was there first, and took a very long time to gain its hegemony. Pandas and Jupyter could in principle have been built on Ruby: why weren't they? Python suffered massively in the 2->3 transition and has only just begun to essay thread-safety, which both should have given Ruby a leg up.
Was it a core implementation group's superior openness to the needs of such projects?
Ruby was the prettier and more consistent language that was slow, prone to weird regressions, and a huge pain-in-the-ass to put into production compared to Python.
Ruby metaprogramming made for some write-once-read-never codebases.
Back when you could deploy Python with apache and mod_wsgi straight out of your distribution's package directory. Ruby meant mongrel or fcgi, usually hand-built off in /usr/local, usually leaking memory, usually coughing up core dumps on the regular. Ruby libraries that linked to C libraries usually depended on bleeding-edge versions that were on developer Macbooks, but not the versions that were packaged in Debian or Redhat.
Python attracted certain types of folks who wanted to say quickly understand the latest output of the large hadron collider, about the size of life peoples let’s say. Ruby attracted live action role playing larger than life sage type of people. Seems people just about the size of life is what is needed to make languages flourish.
Statistics folks, data science peeps. Just needing to get things done, and not necessarily interested in--or aware of--programming ergonomics (for example).
> LARP
Personalities, like a Carmack. People we refer to just by name, due to technical agility, charisma, or sheer output.
I liked _why's stuff. The way he left is not how I would expect a persona to depart. There were some shifts in the programming landscape, and it led to a kind of forlorn sadness or mourning.
If I had to list others, Chris Crawford and Mark Pilgrim.
> Seems people just about... what's needed for language to flourish
Folks needing to munge data from CSV or Excel found python (and R, and other data libs) earlier, or more convenient to use; this built momentum as others tried Python instead.
Maybe also academia, python was there so it was taught. Another example could be students learned UNIX and brought it to their jobs. Same with Java.
I did a contract with a Rails shop and refused to renew it. Without Rails there's not a strong reason to use Ruby. It's a beautiful language, no doubt, but other languages fill its niche just fine (Python, PHP, js).
cpython has supported thread safety since last millennium, it's just slow is all
probably ruby, like lisp, is better for experiments to figure out what problem you're solving, but python (or, more so, golang or kotlin or typescript) is better for writing a maintainable solution to the problem once you more or less understand it
i think of python as favoring flexibility a bit more than i'd like, at the expense of comprehensibility and performance, but ruby is even more extreme along that axis
but probably random chance also plays a large role
It's not mysterious though. It's not particularly complex. You can say the same about tooling and libraries in many languages. React Fibres are probably a mystery to most React programmers, but only because they don't go and look. I've read through the autoloading code, and I just happened to be looking through React's codebase this weekend. React is way more complicated.
What a lot of people don't seem to realise is Ruby was eating Python pretty badly around 2005-2010 as Rails and Github exploded and other things like Vagrant, Puppet and Chef took over.
Ruby had all the mindshare and hype over Python back then. To me as a Python fan, it felt like Python had peaked and wasn't going to grow further.
Then Node came along and stole the bandwagon followers that had flocked to Rails. The Ruby community was mostly the Rails community, so this kinda capped the growth of Ruby.
Python though had lots of competing Web frameworks, and other use outside webdev incl core tooling for Linux distros etc. Ansible (and Salt to a lesser extent) came along and stole back share from Chef/Puppet. Less fashionable Python kept on trucking along and was well placed to pick up machine learning.
No, a good number of Rails devs stayed around and it became more of a mature community, but the hype driven growth/mindshare was over. There is a certain loud percentage of webdevs driven by fashion, and that portion follow the latest fashion around around. Rails lost some to Node, Node lost some to things like Go and/or React as API backed SPAs grew.
I really doubt many Rails devs went to .NET. In those days Ruby was pretty bad on Windows machines (might still be?), and nearly all Rails devs were Mac users.
I never knew .NET MVC was Rails inspired - I always assumed it would've been closer in style to the older Java MVC frameworks Rails was keen to disrupt in the beginning.
_why was an extremely influential programmer, but he optimized for fun while writing, at expense of misery while debugging or changing the code years later. This can be felt in the whole Ruby ecosystem even today.
His distaste for tests is just a consequence of that.
> Two chapters from now you'll be writing your own Ruby programs. In fact, it's right about there that I'll have you start writing your own role-playing game, your own file-sharing network (a la BitTorrent), as well as a program that will pull genuine random numbers from the Internet.
Which always sounded cool to me (and still does), but it's never brought up again in the book. Were those meant (and I realize no one can say for sure) merely as examples of projects one could do, or did (a version of) the book walk you through their implementations? Or am I missing something?
75 comments
[ 3.2 ms ] story [ 91.8 ms ] threadFor those unaware, https://en.wikipedia.org/wiki/Why_the_lucky_stiff _why’s legacy from things like https://poignant.guide/ was a radical shift in how web programming could be taught, and how fun and approachable (for folks of all backgrounds, academic and otherwise) it could be to learn. IMO we owe a tremendous amount of the modern startup landscape to him.
He's actually still in Seattle, last I heard.
He's more of an idea and an ideal anyway. It's better this way, better that he never "returns."
Who wants to see Instagram posts of _why talking about the shitty hamburger he ate? He's always going to be a mystery to me and that's so much better than anything else could ever be. And the reason he is legendary only increases because of that.
Thanks so much for that, _why, whenever you are.
Found these words: archetype, prototype, ideal, ur-form, primordial (mathematics), formal cause, exemplar, Platonic form, essences, archetypal, original pattern, fundamental pattern, first principle, protype, paradigm, archetypical
Just mentioning it as an aside in case anyone's ever similarly trying to find the right word in the future.
Still, it was pretty influential and original.
i appreciate the sentiment of _why, but quality, depth, rigor, and tenacity are also important. _why is no Richard Stevens.
if you fold up and throw a tantrum the minute that your 5 seconds of fame is over and you get to experience some real criticism and apathy and all sorts of other unpleasant things that successful people have to handle, it sort of underscores the immaturity of it all.
matz is still around, isn't he? hell, so is even larry wall.
Rather, _why was pretty clearly an artist, and was trying — in both his prose and his programming — to make what one might call “experimental didactic art”: works that explore how to teach and how to learn (mostly, about programming), rather than works that use concrete teaching methods to teach particular concepts. The Poignant Guide, Shoes.rb, any of the libraries he spun off — they were all this. You weren’t supposed to use them; you were supposed to look at them, analyze them like a painting, think about the “brush strokes” involved in their construction, and from that, grow your perspective on education itself, and programming education in particular.
But people weren’t doing this. People were treating his “software artwork” like he had intended it all as FOSS projects — things to be contributed to and to polish and to grow, even at the expense of the original goal of representing an exploration of a particular idea, to be absorbed and stolen from. And people were treating him as if he was a core contributor to said not-projects, someone to submit bugs and complaints to, rather than someone who made their own finished thing as a statement and only wanted to discuss its meaning, not keep working on it forever.
matz and Wall are bad comparisons. A better comparison would be to someone famous for being a member of a particular band, who is now no longer in that band, but instead in a different band, making a different genre of music. Are they happy that people still appreciate their old work? Sure. Do they wish people would stop asking them about it? Also yes. Do they want to know that they played a wrong note on a song they recorded twenty years ago? No; what good would that do them now? Do they want you to fix that song of theirs for them, 20 years after release, because hey I’m a sound engineer and — no. Stop. It’s fine. It still works as art with the wrong note; and even if it didn’t, it’s long past its relevance; the people the art was aimed at, the people it was supposed to affect, already either got it or didn’t.
If an engineer takes all their software down, you might call that “throwing a tantrum in response to criticism.” But if an artist takes all their art from one “period” of their works down, they’re just doing something artists do every day: ending a gallery exhibition, either because the message it communicated either succeeded in becoming culturally embedded, or failed to resonate. For an artist, the value of their art is in the communication of thought it enacts, not in the art itself; a piece of art doesn’t have to stick around forever, it just has to be seen by the right people at the right time to nudge the world in the way the artist desired. (In extremis, this is why so many artists are perfectly happy making performance art, where each unique showing is done once, only for those there at the time, to never be experienced again once it’s over. The art was never the point; the communication was!)
I like to be able to say “experimental didactic art” is not for me - without implying anything negative about the art or myself. And I really like looking at the author’s actions as the acts of an artist, including performance art. Frees me from the need to comprehend motivation.
Thank you.
Maybe I don't understand artists, but I'd be irritated if an artist did that too. Especially if it's supposed to be FOSS. And it's still throwing a tantrum anyhow (I guess artists are allowed/expected to be immature?) - I picture trope of the manic artist burning all his beautiful paintings instead of selling them to make rent.
What, did all the folks using his FOSS ever know it was just a temporary art installation? I wonder why they assumed he was a core maintainer and why they didn't realize that these FOSS projects where actually "not-projects". I wonder if that was ever prominently mentioned during his 5 minutes of fame?
Anyhow, yes, it leaves a bad taste when somebody is, as others have characterized it, LARPing as a FOSS core contributor and then just run off.
What you might call a tantrum, I would call "asserting your boundaries." Like cutting ties with abusive parents who keep barging back into your life, by deleting your Facebook account, changing your phone number, and changing the locks on your house (or moving to a different city.) _why's software art projects are the hooks other people had in him, so that's what he had to drop.
And there was nothing going on like an "abusive" relationship at all. Criticism != abuse. Work, commitments, expectations != Abuse. Just say "No. Hey I don't want to do this anymore, but I left all my stuff out on the curb". You don't delete it all out of spite with no warning. Option #1 gets sympathy. Option #2 is a major dick move.
"Immature". Yes that part is right. But we knew that already from reading the crunchy-bacon riddled adventures. And people didn't mind the immaturity and fun of it (I didn't like it too much, but then I'm just an old buzzard).
It didn't go wrong until he bailed and he didn't just bail, he burned it all down. That's the problem. That's the showing of the real person. He didn't just walk away and never look back. He said - if I can't have it, then I'll take it all back and destroy it.
That's not just an "artistic temperament". That's an asshole who didn't like the prize he fairly won and decided to be a dick about it.
Thankfully people who did care stepped up. I personally don't even like the stuff, but I never want to see it destroyed so those folks who stepped up are the heros. The system and idea of FOSS is the hero too.
https://www.nippon.com/en/japan-topics/g00837/digital-minist...
https://en.m.wikipedia.org/wiki/Audrey_Tang
Explains why I've replaced so much inconceivably tortured code over the years
I disagree and I don’t really see how they’re connected.
There's been a few posts on HN that I remember which could be summarised as "I made this cool and useful thing, but I'm worried I'll be criticised because it's not polished enough. Should I just throw it away?" That's the "worry too much" view.
There was no testing framework capable of testing my latest JS library so I built my own; but here's the catch: the testing framework for the library is bootstrapped by the library itself, necessitating building a large amount of the functionality before getting CI in place.
This is stopping me from actually making any meaningful progress on some other challenges in the codebase. (pushing boundaries)
And for the actual problem: is drawing a card actually move with a source and destination?
/player1/draw
/move/player1_deck/to/player1_hand
I keep getting hung up on the fact that move feels “more right abstractly” but now the move endpoint has to know about _all states_ to know if the move is valid.
I don't think it's fair to comment on the person based on one letter - although I will say the tone is reminiscent of some folk in my community who have their own demons.
I can see that as advice to a new programmer, a call to experiment, play around, stretch skills, share small scripts etc is useful.
Once you start building more meaningful, long term, things in a team context, then things like consistency, tests, comments and do on become a lot more important.
I've been lucky enough to work with very bright people over the years. But for some of them, their code is hard to read, somewhat prone to bugs, and generally working with it is "disliked." It is slowly being replaced. I include some of my early code in this.
Over the years personally I've tried to change from writing "clever" code to "clear" code. The latter seems less impressive but ultimately lasts longer.
Wherever _why is, I wish him well.
I have worked with too many programmers that know everything about engineering and process but can't actually DO THE WORK or solving problems, applying data structures, innovating their way out of a corner.
They can go a long way with senior management because they speak all the right lingo.
But when push comes to shove, and a new system needs to be built, or a bug needs to be solved quickly and safely in production without backwards incompatible changes, or business requirements collide against technology options...they are lost.
But the advice in the post doesn't make bad programmers into good programmers - it just makes bad programmers "try to be clever" - which frankly doesn't end well.
Do some of these techniques help bad programmers _become_ good programmers? Sometimes yes. But then it should come with the caveat never to do it in "real" code. It might be a good learning tool, but it's a terrible production tool.
Give it a shot again. I really enjoyed doing so.
Gotta say, last time I checked up on Rails though, it really depressed me how bloated it got. Maybe I'll just use ActiveRecord and ActiveSupport... but there was so much to love about Rails, I'm just really sad all the JS support kinda overwhelmed it from my perspective.
_why's message lands aptly upon those who cannot see the value in experimentalism. It takes a backwards kind of discipline to force yourself to push code you know isn't perfect. Sometimes seeing the whole before each part.
This mentality is what led me to my own methodology: Write everything twice, from scratch".
Of course, in practice there's never enough time for as much experimentation and rewriting as we'd like. Still I believe it's an ideal worth aspiring towards.
Programming has culturally shifted. It's not as fun as it used to be, but it is more accessible and has less mystery about it. That was my time as a young programmer, if you missed out on that then that's too bad, but I missed out on previous and probably even more wild times - both my parents were programmers and I envy their experience. I'm sure there's slices of programming culture now that I have no access to that are again wild and exciting in their own way, just not in web or application programming. So the wheel turns.
Hardware hacking, for example, is "back" in that it's once again in the limelight for beginner programmers after a period of being too expensive and too limiting to be attractive to a lot of people. It never went away, certainly, but in the late 1990s it looked more like this:
https://todbot.com/blog/2006/09/25/arduino-the-basic-stamp-k...
That's a webpage which compares the BASIC Stamp to an Arduino setup. The upshot? The BASIC Stamp was about $120 all-in to buy the hardware plus a proprietary development environment, whereas a comparable setup for the Arduino is $60 (or less) for the hardware plus a more pleasant development environment, especially if you're coming from Python or ECMAScript and don't like the idea of learning a SHOUTY LINE-BASED 1960s CRUFTFEST that isn't even something cool like assembly language.
So in some ways we've circled back around, but it's more like a helix: Yes, kids are Making LEDs Blink Again, but this time it's with a language that isn't a dead-end and it's with hardware they don't have to be so paranoid about blowing up. Experimentation is more fun if you're not afraid of failure. It's the same point in some dimensions, but it's a few miles different in a different dimension.
Speaking of dimensions, Web programming has gained a whole new set of dimensions. Say what you will about webdev as a whole, there's few easier ways to show off your work than being able to give your friends a URL so they can just load and go. Shadertoy alone is, from a 1990s perspective, so cool my teenage self would have gone of the deep end with it.
Python was there first, and took a very long time to gain its hegemony. Pandas and Jupyter could in principle have been built on Ruby: why weren't they? Python suffered massively in the 2->3 transition and has only just begun to essay thread-safety, which both should have given Ruby a leg up.
Was it a core implementation group's superior openness to the needs of such projects?
Ruby metaprogramming made for some write-once-read-never codebases.
> about the size of life peoples let’s say
> live action role playing larger than life sage type of people
> Seems people just about the size of life
??
Statistics folks, data science peeps. Just needing to get things done, and not necessarily interested in--or aware of--programming ergonomics (for example).
> LARP
Personalities, like a Carmack. People we refer to just by name, due to technical agility, charisma, or sheer output.
I liked _why's stuff. The way he left is not how I would expect a persona to depart. There were some shifts in the programming landscape, and it led to a kind of forlorn sadness or mourning.
If I had to list others, Chris Crawford and Mark Pilgrim.
> Seems people just about... what's needed for language to flourish
Folks needing to munge data from CSV or Excel found python (and R, and other data libs) earlier, or more convenient to use; this built momentum as others tried Python instead.
Maybe also academia, python was there so it was taught. Another example could be students learned UNIX and brought it to their jobs. Same with Java.
I did a contract with a Rails shop and refused to renew it. Without Rails there's not a strong reason to use Ruby. It's a beautiful language, no doubt, but other languages fill its niche just fine (Python, PHP, js).
cpython has supported thread safety since last millennium, it's just slow is all
probably ruby, like lisp, is better for experiments to figure out what problem you're solving, but python (or, more so, golang or kotlin or typescript) is better for writing a maintainable solution to the problem once you more or less understand it
i think of python as favoring flexibility a bit more than i'd like, at the expense of comprehensibility and performance, but ruby is even more extreme along that axis
but probably random chance also plays a large role
Ruby had all the mindshare and hype over Python back then. To me as a Python fan, it felt like Python had peaked and wasn't going to grow further.
Then Node came along and stole the bandwagon followers that had flocked to Rails. The Ruby community was mostly the Rails community, so this kinda capped the growth of Ruby.
Python though had lots of competing Web frameworks, and other use outside webdev incl core tooling for Linux distros etc. Ansible (and Salt to a lesser extent) came along and stole back share from Chef/Puppet. Less fashionable Python kept on trucking along and was well placed to pick up machine learning.
AFAIK the .NET MVC setup was pretty influenced by Rails, but don't think Rails people went to .NET
I really doubt many Rails devs went to .NET. In those days Ruby was pretty bad on Windows machines (might still be?), and nearly all Rails devs were Mac users.
I never knew .NET MVC was Rails inspired - I always assumed it would've been closer in style to the older Java MVC frameworks Rails was keen to disrupt in the beginning.
"As someone who maintains _why's code these days, please, write some tests."
His distaste for tests is just a consequence of that.
Edit:
1: Eleven years ago!
Chapter 3^ says (among other things)
> Two chapters from now you'll be writing your own Ruby programs. In fact, it's right about there that I'll have you start writing your own role-playing game, your own file-sharing network (a la BitTorrent), as well as a program that will pull genuine random numbers from the Internet.
Which always sounded cool to me (and still does), but it's never brought up again in the book. Were those meant (and I realize no one can say for sure) merely as examples of projects one could do, or did (a version of) the book walk you through their implementations? Or am I missing something?
^ https://poignant.guide/book/chapter-3.html