충분히 재미있지 않기 때문: 프로그래밍 언어가 실패하는 이유

history language psychology software engineering Andrew Oram wrote a two-part series for the Linux Professional Institute asking why programming languages rise and fall (parts one and two .) It says, roughly, that C, C++, and JavaScript are immortal (for now!), with Java a maybe; COBOL, FORTRAN, BASIC, and Perl lived respectable lives and got sent upstate to retire on a farm; Pascal, Objective-C, PL/I, Ada, and Tcl were false starts, with Ruby somewhere on the bubble. It's a good tour from a man who has been editing this industry's books forever, and near the end of it, Oram quotes Simon Peyton Jones, who observes that a language's adoption is "very weakly connected to its technical merits," and that the social and economic factors do the actual deciding. That quote is the article, and it's a little surprising that it's buried so far into the content; maybe engineering for human nature makes it difficult to make that quote the leading thesis because we don't want to read that quite so bluntly, but it's true. Language adoption is not solely technical - it's technical and human. Everything in the two parts before that quote is evidence for the sentiment, assembled but never organized as evidence. The series sorts languages by outcome: immortal, respectable, and failed. The interesting sort is by cause of death, and the causes come out of a simple observation that Peyton Jones compresses and Oram circles: programming is done by people, and for people it is three things at once. It is a vocation , an art , and a job . A language serves someone practicing all three, and a language or tool that makes any of the three unnecessarily difficult will not survive past the moment it can be replaced. A vocation is a calling the world happens to pay for: something someone would do anyway, paycheck or no paycheck. An art is something someone does out of love and (hopefully) skill, and a job is the daily work, the thing someone does so they can eat and watch TV and sleep under a roof and boring stuff like that. Musicians live this triple identity every working day: the covers set is the job, the originals are the art, and the vocation is what puts an instrument in their hands every day, booked or not. Programmers live it too; we just don't say it out loud as often. Sort the corpses that way and they separate cleanly. Some languages failed as a job: standard Pascal shipped without a usable string type and Tcl couldn't carry programs past a certain weight, so the daily work was harder than it had to be. 1 Some failed as an art: Ada and PL/I were chosen for programmers rather than by them, languages of mandate, and nobody has ever loved a mandate. Some failed as a vocation: Perl's job market walked to Python and didn't come back 2 , and Haskell famously set out to avoid success at all costs , a goal it achieved 3 . Different diseases, one pathology. In every case somebody made one of the three axes needlessly difficult, and the people the language depended on went where it was easier, or more fun, or more workable. A language that makes life hard will not survive past the moment it can be replaced . That statement explains every anomaly on Oram's list. JavaScript fails as an art for a large share of the people writing it, and it survives anyway, because it remains the browser's main general-purpose language 4 . Objective-C was awkward as both art and job, and it thrived for fifteen years because it was the only door into the most lucrative developer ecosystem ever built; the moment Swift existed, it evaporated and now survives as a shadow, preserved in its descendant. COBOL survives because replacing it is too difficult and expensive - something some companies are noticing and trying to address. If they succeed, COBOL is likely gone : a language that works 100% of the time and is about 1% fun to program. Ada survives today where certification regimes made it nearly irreplaceable 5 . Its difficulty is a standing eviction notice. It gets served on the day an alternative shows up, and not one day sooner. Which leaves C++ looming, difficult and immortal, apparently contradicting all of this. Rust too, difficult by design and rising. The thing is that there are two kinds of difficulty, and the series conflates them. One kind of difficulty is the violin's: precise, demanding, and chosen because it is precise and demanding. People do codegolf in C++ for sport. People write essays about the day the borrow checker finally clicked, the way string players talk about the day vibrato stopped being a fight. Difficulty itself isn't fatal; difficulty without sufficient return is . C++ and Rust have that return, just as the violin does. The other kind of difficulty is friction: Ada's compliance apparatus, standard Pascal's missing pieces 6 , COBOL's amazing and precise and demanding structural syntax that doesn't actually create program structure much at all. Nobody ever wrote an essay about the day Ada's paperwork clicked. That difficulty hits all three axes for... what? Nothing. Ada and C++ both read as "hard languages" in a survey. But Ada dies as a standard language and C++ survives today because the "hard" parts were on different axes. And where is Java in all of this? Good question! Java isn't as difficult as C++ or Rust, so it doesn't need their defense: it's sort of immortal from utility AND fun right now, with a lot of passion restored to the ecosystem thanks to the recent improvements in packaging and features. But that's an entirely personal decision on the part of the programmer; I think it's safe to say Java ain't dying quite yet, but it's hard to say why or when: I'm personally living in Java-land day by day. I'm biased. Back to music, then, where the analogy stops being an analogy. A modern sampler can reproduce every note a violin makes. It can reproduce every nuance a violin makes; it is an encyclopedia of techniques, bowings, articulations, the works. And getting it to actually do all of that is more work than just playing the violin itself 7 ! The capability was never the question. It turns out that the best way to get a sound like a violin being played is actually playing the violin . This is also, quietly, why code exists: a program is a compact specification for behavior, and describing behavior in prose costs more than the notation built for the job 8 . I can get a computer to play guitar for me, and I can make it play much as I do on guitar: I know how I play, I understand my own preferences and accents. I can replicate my playing on guitar, gesture by gesture, note by note. And it is no fun. None. The result is fine; the doing is gone, and the doing was the point. There is no life to it, even if I introduce randomization or use my own timings. This fails along the same three axes as everything else we've mentioned here. For the person who only wants the notes, the sampler wins the job outright, completely. It will never play the wrong thing or at the wrong moment. For the person playing , it fails, because driving it costs more than playing, and it never touches the art at all. Which is why, when I want guitar on a track, I still reach for the guitar. Choosing it is the point. The law that sorts programming languages sorts their successors too. No special pleading required... or allowed. So: why do programming languages rise and fall? Peyton Jones already said it, and Oram already quoted it. Languages don't lose benchmark fights. They lose people . They rise when they make the vocation, the art, and the job lighter, and they fall on the day something else can carry the same weight, because at that moment the only question left is... is it fun? 9 An aside on Pascal, because the false start is... slightly misleading. Pascal's commercial life didn't end in the classroom; it moved to Borland, where Turbo Pascal and then Delphi dominated PC development for over a decade. Turbo Pascal's author was Anders Hejlsberg , who went on to build Delphi, then C#, then TypeScr