Unfortunately comments on a social media network are not sufficient for discussing nuance so I decided to put this blog post together. In my view she is very right about a lot of things but there are some major areas where I disagree and therefore wanted to put together a full blog post explaining what I see as an alternative to what she rightly condemns.
To start out, I think she is very much right that there often exists a sort of tribalism in tech with people condemning each others tools, whether it be Perl vs PHP (her example) or vi vs emacs, and I think that can be harmful. The comments here are aimed at fostering a sort of inclusive and nuanced conversation that is needed.
The Basic Problem
Every programming culture has norms, and many times groups from outside those norms tend to be condemned in some way or another. There are a number of reasons for this. One is competition and the other is seeking approval in one's in group. I think one could take her points further and argue that in part it is about an effort to improve the relative standing of one's group relative to others around it.
Probably the best example we can come up with in the PostgreSQL world is the way MySQL is looked at. A typical attitude is that everyone should be using PostgreSQL and therefore people choosing MySQL are optimising for the wrong things.
But where I would start to break with Aurynn's analysis would be when we contrast how we look at MySQL with how we look at Oracle. Oracle, too, has some major oversights (empty string being null if it is a varchar, no transactional DDL, etc). Almost all of us may dislike the software and the company. But people who work with Oracle still have prestige. So bashing tools isn't quite the same thing as bashing the people who use them. Part of it, no doubt, is that Oracle is more established, is an older player in the market, and therefore there is a natural degree of prestige that comes from working with the product. But the question I have is what can we learn from that?
Some time ago, I wrote a the most popular blog post in the history of this blog. It was a look at the differences in design between MySQL and PostgreSQL and was syndicated on DZone, featured in Hacker News, and otherwise got a fairly large review. In general, aside from a couple of historical errors, the PostgreSQL-using audience loved the piece. What surprised me though was that the MySQL-users also loved the piece. In fact one comment that appeared (I think on Reddit) said that I had expressed why MySQL was better.
The positive outpouring from MySQL users, I think, came from the fact that I sympathetically looked at what MySQL was designed to do and what market it was designed for (applications that effectively own the database), describing how some things I considered misfeatures actually could be useful in that environment, but also being brutally honest about the tradeoffs.
Applying This to Programming Language Debates
Before I start discussing this topic, it is worth a quick tour of my experience as a software developer.
My PostgreSQL experience grew out of my Perl experience. And about 3 years ago I was asked to start teaching Python courses. I rose to this challenge. Around the same time, I had a small project where we used Java and quickly found myself teaching Java and now I feel like I am moderately capable in that language. I am now teaching myself Haskell (something I think I could not have done before really mastering Python). So I have worked with a lot of languages. I can pick up new languages with ease. Part of it is because I generally seek to understand a language as a product of its own history and the need it was intended to address.
As we all know different programming languages are associated with stereotypes. Moreover, I would argue that stereotypes are usually imperfect understandings that out-group people have of in-group dynamics, so dismissing stereotypes is often as bad as simply accepting them.
PHP as a case study, compared to C.
I would like to start with an example of PHP, since this is the one specifically addressed in the talk and it is a language I have some significant experience writing software in.
PHP often is seen to be insecure because it is easy to write insecure software in the language. Of course it is easy to write insecure software in any language, but certain vulnerabilities are a particular problem in PHP due to lexical structure and (sometimes) standard library issues.
Lexically, the big issue with PHP is the fact that the language is designed to be a preprocessor to SGML files (and in fact it used to be called the PHP Hypertext Preprocessor). For this reason everything, PHP is easy to embed in SGML PI tags (so you can write a PHP template as a piece of valid HTML). This is a great feature but it makes cross site scripting particularly easy to overlook. A lot of the standard library in the 1990's had really odd behaviour, though much of this has been corrected.
Aurynn is right to point to the fact that these were exacerbated by a flood of new programmers during the rise of PHP, but one thing she does not discuss in the talk is how software and internet security were also changing during the time. In essence, the late 1990's saw the rise of SSH (20k users in 1995 to over 2M in 2000), the end of transmission of passwords across the internet in plain text, the rise of concern about SQL injection and XSS, and so forth. PHP's basic features were in place just before this really got going, and adding to this a new developer community, and you have a recipe for security problems. Of course, today, PHP has outgrown a lot of this and PHP developers today have codified best practices to deal with a lot of the current threats.
If we contrast this with C as programming language, C has even more glaring lexical issues regarding security, from double free bug possibilities to buffer overruns. C, however, is a very unforgiving language and consequently, it doesn't tend to be a language that has a large, novice developer community. At the same time, a whole lot of security issues come out of software in C.
There is no such thing as a perfect tool (database, programming language, etc). As we grow as professionals, part of that process is learning to better use the strengths of the technologies we work with and part of it is learning to overcome the oversights and problems of the tools as well.
Instead of attacking developers of other languages, my recommendation is, when you see a problem, to neutrally and respectfully point it out, not from a position of superiority but a position of respectful assistance and also to understand that often what may seem like poor decisions in the design of a language may in fact have real benefits in some cases.
For example, Java as a language encourages mediocrity of code. It is very easy to become a mediocre Java developer. But once you understand Java as a language, this becomes a feature because it means that the barrier to understanding and debugging (and hence maintaining!) code is reduced, and once you understand that you can put emphasis instead on design and tooling. This, of course, also has costs since it is easy for legacy patterns to emerge in the tooling (JavaBeans for example) but it allows some really amazing frameworks, such as Spring.
So what I would recommend that people take away is the idea that in fact we do grow out of hardship, and that problems in tools are overcome over time. So for that reason discussing real shortcomings of tools while at the same time respecting communities and their ability to grow and overcome problems is important.