When the Web first appeared, I had my first "Programming is fun again!" experience. I had gotten my bearings in programming in Unix and C, and when I was informed that it was possible to include an image in a web page, I anticipated the amount of work that it would take in a C-like environment from scratch to tell how to display an image. I implicitly thought, "Too much work for me." But I was positively astonished to find that an image could be included in a web page with nothing more than <IMG SRC=Portrait.GIF>, and that an image itself didn't need to be embedded in a web page; it could equally gracefully be made available as <A HREF=Portrait.GIF>Click here!</A>. Thus began my first exposure to a language that was declarative rather than imperative. Perhaps it was not strictly programming; certainly, before JavaScript, it was not a Turing approximant. However, it let me easily do things with computers that I hadn't dreamed of.
Some years later, I had my second "Programming is fun again!" experience after a friend suggested that I try Python. By the time that occurred, I was a sort of a language collector; the only languages I wanted to know but didn't were Icon, C++, and some assembler. A common reality for language collectors is that their first project in a new language is slower, more difficult, and more frustrating than any further work. It gets better after that, but for the first project, "It always takes longer than you think, even when you take into account the fact that it always takes longer than you think." However, with Python, my surprise was, "What? Is it working already?" and this was just the tip of an iceberg.
My story of being a language collector, finding Python, and then stopping the effort to learn new languages is not an especially unusual story among Pythoneers. Eric Raymond certainly picked up some deeper notes in his article Why Python? at http://www.linuxjournal.com/article/3882. Python is an enchanted kingdom where the streets are paved with glue, and it's not just masters who can benefit.
What was not mentioned earlier is that if you leave your mouse hovering over the cartoon image at http://xkcd.com/353/, this message appears: I wrote 20 short programs in Python yesterday. It was wonderful. Perl, I'm leaving you... Now Perl is also a good language and, for a time, my favorite, but there's still something about Python.
Finally, my last and greatest "Programming is fun again!" moment came when I began appreciating ReactJS. ReactJS delivers something that XHTML and HTML5 don't, in terms of creating useful components that can be used like tags.
Whatever the "X" in XHTML stands for, it does not mean, "In mainstream use, people will build and deploy lots of interesting new tags." HTML5 offers a number of new components, such as <input type="date" />, but they are not universally supported, and this is not another case of IE having to be the life of a party. The mainstream and current non-Microsoft browsers have very inconsistent coverage of features that were announced loudly and clearly when HTML5 was in the limelight. There are polyfills available, and integrating one of the many JavaScript date pickers that existed before HTML5 may make just as much sense today as it did when they were new. But while a site like http://html5please.com/ is praiseworthy and worth using, it is also a symptom of a major problem.
ReactJS and JSX succeed where these fail. This text has not covered how to make a <DatePicker /> function, but once this has been made, you can include it in your JSX almost as easily as a native HTML tag. If someone nostalgic for fractals draws on an HTML5 canvas and makes scrollable and zoomable <LogisticMap />, <VonKochSnowflake />, <MandelbrotSet />, and <SierpinskiGasket />, these can be as easily included in JSX as the plain old simple <img /> tags. Components defined in ReactJS differ in an important sense from manually configuring and wiring a JavaScript date picker to work with your form. They are like subroutines in classic structured programming, in the sense that they can be readily reused wherever reusing makes sense, and combined to make bigger building blocks.
Moreover, if I may borrow from Robin Martin's "What Killed Smalltalk Could Kill Ruby" and use slightly more polite language, the key metric in a code review (among other things) is the number of times the reviewer has to ask, "What were they thinking?" For the "What were they thinking?" metric, an acceptable score for the code being reviewed is 0. Anything higher than this is unacceptable. Also, this metric is relevant well outside of code reviews.
In Python, such moments are rare: they do exist, as a search for "Python mutable default argument" will show, but they are significant because they are rare. This is different from "What were they thinking?" arguments in JavaScript, such as "You can use variables without declaring them (but if you do, they'll be global)" and "You can write pseudo-classical constructors (but if you forget to use the new keyword when calling them, they'll clobber things in the global namespace.)" The environment in JavaScript is such that a key language advocate, such as Douglas Crockford, sharply warns people to steer clear of large chunks of the basic language, and appears to be getting pickier over time.
Ultimately, it seems that ReactJS and Python have the same heart. Both are, at heart, small and simple. Perhaps both have flaws, but flaws where the "What were they thinking?" moment is the exception and not the norm. Both have, as a sarcastic tweet said when ReactJS was announced, "Facebook: Rethink established best practices." ESR mentioned quite a hang-up about Python's strange choice of significant white spaces.
"And like most hackers, upon realizing this fact, I recoiled in reflexive disgust.
I was barely old enough to have programmed in batch Fortran for a few months back in the 1970s. These days, most hackers aren't, but somehow our culture seems to have retained a pretty accurate folk memory of how nasty those old-style fixed-field languages were. Indeed, the term "free format" used back then to describe the newer style of token-oriented syntax in Pascal and C has almost been forgotten. All languages have been designed that way for decades now, or almost all; anyway. On seeing this Python feature, it's hard to blame anyone for initially reacting as if they had unexpectedly stepped in a steaming pile of dinosaur dung."
ReactJS also has the courage to say that those people who create CSS can create very simple JavaScript, instead of only working in deliberately underpowered templating languages. Now, JavaScript was chosen as a Domain-specific Language to deliberately leave as much power as is needed. However, it is not necessary for designers to summon the full power of JavaScript. They can create the 99 percent of the simple JavaScript that would have been done in an underpowered templating language, and JavaScript developers can create the remaining 1 percent of powerful JavaScript, because this would be problematic to address in an underpowered templating language.
