I have no interest going around belittling people for choices that work for them, but this implicit idea that technological decisions are all a matter of taste and nobody can criticize them is dumb to me.
Do OP thinks that what we accomplished until now with this mindset isn't a great achievement? I understand the point about minorities more commonly get stuck at considered worse technologies -I got stuck with PHP for 7 years - but help them to stay more comfortable with these tools will do no good. They will get siloed.
I too was stuck using PHP for years. Both for career (that's the kind of jobs I was getting) and cultural (exactly what the article is talking about) reasons. Encountering more inclusive peers using other technologies didn't make me feel more comfortable using PHP, it made me feel more comfortable trying new technologies.
On one hand, sometimes languages are bad. More specifically, if we choose to define the utility of a language based not on its features and high points, but on its drawbacks and fundamental failings, then it's very straightforward for a cosmopolitan hacker to develop bad impressions of certain languages. The fact that those same languages show up as punching bags over and over, particularly PHP, JS, Java, and C++, should hopefully indicate to us as a community that these languages should be shunned and avoided.
On the other hand, the people wielding those languages do not deserve any hate, shame, nor prejudice. Attacking people for using a language is like attacking people for any other opinion that they might harbor; it is bigotry. There is no reason to be a bigot when it comes to languages; it should suffice merely to hold the opinion, to have the opinion be well-reasoned, and to always be conscientious of how we treat the people around us.
(I cannot believe that I had to write the previous paragraph, but HN's inability to hold this discussion in a calm and rational way in the past has made it clear that I must directly tell you all to not be bigots. Disappointing.)
It is a recurring pattern that discussions about these low-quality languages turn into us-vs.-them discussions, where one side harbors people who espouse the opinion that the language in question is low-quality, and the other side consists of people who use the language in question on a daily basis. The first side needs to avoid attacking and hurting people on the other side. It is unhelpful and derails the conversation. In particular, trying to communicate an idea of the form, "You need to be aware of the language's failings and flaws, and understand that not all other languages have these problems," is subtle and cannot be done while simultaneously flinging insults.
On the other side, we all must realize that our favorite languages are terrible. Our languages, like almost all facets of computing in this era, are primitive. We have only a few fundamental rules which guide our knowledge of computing, but otherwise we are usually walking blind, exploring and feeling our way through a field which is still largely unlit. When we discuss the failings of a particular language, we are trying to build up our understanding of which linguistic features do not work, and which features should be avoided.
In summary, we should kill PHP and JS, but we should have empathy for those who use these languages, and we should make sure that we learn from the mistakes which these languages embody as we step forward.
I had a Python developer proclaim to me that Java was stupid and Python was great. It was a funny moment for me. You can get a lot of things done faster in Python, but performance is much better with Java. People in glass houses should not throw stones.
You need both statically typed language and interpreted ones. But interpreted languages should only be the glue that is used with restrain and care, it shouldn't be the heart of a system.
You said it yourself, sometimes you need things to be done faster, but most of the time systems should be robust. Python is an excellent companion to Java. Python is one of the most versatile language out there while Java is one of the most robust.
There is a lot of bad technology being pushed via social hacks - examples include PHP, MongoDB, NodeJS and Go. Typically the social hacks are low learning curve + easy tutorials that gloss over important details [1] + rapid setup + culture of piling on tech debt (e.g. rails ignoring how relational DBs work).
Technical superiority, particularly if that superiority requires people to learn new things, has demonstrated an inability to gain traction.
So if we want superior technologies to win, we'll need to engage in some social hacks of our own. Vocal and demonstrable elitism is a valid social hack - if the people who are demonstrably great coders are proponents of Haskell and sneering at PHP, while the code monkeys are all using PHP, that's a pretty clear social signal. Who wants to be part of the code monkey crowd?
When I was younger, and nothing but a BasicA/Visual Basic coder, these attitudes pushed me towards learning C and Perl (yes I'm showing my age). I saw all the better coders using these superior technologies with a higher learning curve. I realized that I had a lot to learn, I put in the effort and I learned it. With the decline of hacker culture, I don't see that happening anywhere near as much these days.
[1] E.g. a while back there were RoR tutorials that used update_attributes (skipping input validation) to show how easy RoR is. Net result was various hacks, I think including Homakov's hack of github.
Here's the thing though: The end user, the one who pays the majority of our bills, doesn't give a shit about your language choice, your code, your DB choice, or any of it. They care if it works, if it's easy to use, and usually if it looks nice and that's about it.
People publish blog posts about how they aren't using MongoDB or aren't using PHP anymore because X and Y and do you know who cares? Pretty much no one aside from the pro PHP people who get mad or the anti-mongo people who point to it as justification for their part in a completely pointless argument.
Yes, low skill and approachable languages attract amateur coders because that's what they're supposed to do. PHP was designed from the get go to be an accessible web server language that anybody could use, that was the POINT so naturally anybody who can will use it.
I've seen brilliant PHP websites and I've seen utterly garbage C code, and both of those reversed too. There is a correlation between use of high level languages and skill but it is far from a fixed relationship, so to parade about someone's use of those to justify their arrogance as a programmer relative to people who are WELL AWARE that they are better than them just makes that person look like a windbag.
They care about bugs, vulnerabilities, and third-party quality issues - all of which a bad language/framework will help you to have.
Human beings are the original proof engines, so I'm sure that a great programmer could perform amazing type checking in any language. I'm sure they could also architect their way around Java's weak points with Abstract Factory Patterns, xor hand-tune their code for the JVM JIT to be only 1.9x slower than a naive C implementation (See: what they had to do for Minecraft).
But, why?
It's easier to learn the syntax for a good compiler than it is to implement one in your head...
Yes, and you can also produce better electrical hardware with a $200,000 fabrication unit than breadboard and a soldering iron, but one of those is a lot more accessible to someone just starting out.
I don't see the raspberry pi people being derided and mocked by Intel's engineers because they use such lowly plebian tools.
"one of those is a lot more accessible to someone just starting out."
Its interesting that this point comes up in a world containing useful google results for "try ruby" "try clojure" "try haskell" "try-python" "try scheme" but there are no useful google results for "try cobol" "try java" "try php" or "try visual basic".
We can play a similar game with Koan style learning with very similar results.
The end user cares when a SQL injection vulnerability takes down their site or when their site turns into a massive pile of tech debt for which any improvement takes weeks.
I agree that PHP was designed to be a bad language but easy for noobs. That's the point. By having a low learning curve it has displaced vastly better choices. And that's why I'm suggesting we need to fight social hacks with other social hacks.
I think you're right on strategy (fight social hacks with other social hacks) and wrong on tactics (contempt and shaming.) While contempt and elitism might have challenged you to try harder languages, they're going to make a lot of people circle the wagons.
I think we see this narrative a lot with Haskell. Although the Haskell community is reportedly very friendly once you actually try to work with Haskell, I've seen a lot of comments by its enthusiasts denigrating "lesser" languages.
So I agree with the OP. There's not a lot to be gained by telling people they're stupid. By and large this just causes them to entrench their positions. (See also: electoral politics.) I think there's much more ground to be gained by deliberately blurring the lines (a different social hack.) Examples of this include Cygwin and optional type systems for dynamic languages.
I'm not so sure it does cause people to entrench their positions.
As an example within tech, sneering and contempt have enabled social justice to spread wildly. Look at how many projects/conferences have codes of conduct now, compared to a few years ago, and at how many technology companies are throwing money at diversity efforts.
I don't know if it's the right strategy, but it's definitively not a strategy I can immediately dismiss.
I see your point about social justice, but I think it isn't a great example. While there were and are some committed racist and misogynist individuals in the world, by and large people as well as organizations were indifferent. They didn't have any position to speak of, and so they were blindsided and easily swayed when the shaming and contempt came around. They said "hey, that's not us, we're not like that!" and fell in line with the social justice position. Programming language communities, on the other hand, have a real investment in their language of choice. It's not that they're indifferent to the issue of whether PHP is a terrible language; they actively choose PHP, so when they're attacked they move to defend.
> The end user, the one who pays the majority of our bills, doesn't give a shit about your language choice, your code, your DB choice, or any of it. They care if it works, if it's easy to use, and usually if it looks nice and that's about it.
The problem is that this doesn't mean every option is equally good for the end user. A lot of software that gets belittled is criticized for being a good way to provide a bad product. These are tools that are great for getting things done quickly and smoothly, in return for kicking the can down the road on reliability, security, or modifiability.
Think of the small insurance companies which offer easy signup at low rates - and then don't come through when you file a claim. When people go out and produce lengthy essays on why Mongo is dangerous, it's often a response to seeing systems that work for now, but are likely to fall over completely sometime after the contract is done. When your database offers high throughput by not actually checking for successful writes, it's easy to hand over a performant system that's going to lose a bunch of medical records the first time a server fails.
So no, the client doesn't know or care, but all too often that's because they're getting immediate benefit in return for delayed, probabilistic risk, and no one is telling them about the tradeoff.
None of that is justification for being a jerk, or mocking actual people (obviously!) Nor is it a reason to pretend that Mongo is never a good database choice, or that PHP is never a good language choice. And you're right about the grossness of mocking beginning programmers for starting with approachable tools.
But I object to the idea that the value of debates should be measured by whether users care about them. I'm not much interested in what my bridges are made of, but that's because I have faith that someone behind the scenes built them reliably. All too often, that's not the case in software.
Sometimes I wonder if a higher learning curve isn't a feature. If it takes some amount of core-competence to simply hello world in a given language, then a code-base that uses that language automatically signals higher general aptitude of the programmer.
Could a language be "better" simply by being harder to learn?
> What is hello-world in Haskell such that it is embedded into a page that you load out of Apache?
With apache configured to run the program as a CGI script? Still the same thing.
That's not a great way to run Haskell on the web, but it's not too far from what's going on with historically common out-of-the-box PHP setups (and I understand that modern PHP setups take a little more code).
No. You will find idiots in every language. C++ is hard to learn and you can do great stuff if you knew what you are doing but there are also plenty of people who create memory leaks left and right.
> If it takes some amount of core-competence to simply hello world in a given language,
But, no matter how complex the language is, it doesn't, unless "hello world" becomes incredibly platform, context, and (e.g.) day-of-the-motnh-on-which-it-is-compiled sensitive.
Because, otherwise, it may take the first person some competence to "hello world", but everyone else can get by with copypasta and memorization.
Enterprise style java is not inherently bad, anyway. Its ideal for padding hours of government cost plus contracts, or megacorporation initiatives that'll be scrapped before deployment anyway.
> If it takes some amount of core-competence to simply hello world in a given language, then a code-base that uses that language automatically signals higher general aptitude of the programmer.
There is a competing force though: if a language is flat out difficult to use, then much of the programmer's ability will be spent getting the damned thing to work.
Passing the ACID3 test suite with a browser written by hand entirely in Brainfuck is a clear indication of a highly skilled programmer. That doesn't mean you should build a business on Brainfuck though :)
I get your argument regarding PHP, MongoDB and NodeJS, but having never used Go I'm wondering what makes it a "bad technology"?
I've mostly heard good things about Go, except for lack of generics and the use of github repos in "import" statements.
Are those the reasons you think it's bad, are there more serious ones? Is Go actually "bad", or does it just bring little to the table? I understand Go's meant to be a middle-ground between Python (dynamic, memory-safe, slow) and C (static, unsafe, fast); do you consider it a step forward in that regard? If a bug-free, non-obfuscating source-to-source translator between two languages appeared overnight, would you prefer those languages to be Python -> Go, Go -> Python, C -> Go or Go -> C?
So by "bad", I mean 20 years behind other languages that live in the same niche. Lack of generics and a modern type system (assuming you go the type system route) is actually a really bad thing.
If you want a middle ground between Python, there are already great options that provide everything Go does and more, for example Java, Scala, Common Lisp, Haskell and Rust. Lisp is a bit closer to the dynamic/slow side, Haskell/Java/Scala are more or less Pareto superior to Go, and Rust is a little closer to the static/fast/unsafe side.
But unlike Go, Haskell/Scala/Java expect you to learn a few things before you can be really productive in them.
While I'm not sure I agree with your entire point I think it's clear that not only do people not appreciate the _generations_ of hard work you're leaving behind when you abandon LLVM/Clang/etc or languages with powerful type systems but they actively resist understanding this. Put simply I don't think people disagree with the "20 years behind" thing, I actually think they don't understand what you mean.
Yes, that's because they are code monkeys who are unwilling to put the effort into learning something new. (An uncharitable, but perhaps effective way to phrase it.) My proposal is simply that we don't treat this anti-intellectualism with kid gloves.
I'm fine with that, though I have noticed in years participating in _this_ community that it vocally penalizes strongly worded criticism. This is, of course, stupid.
I haven't used Go (lack of pattern matching is a non-starter for me), but the lack of generics seems like more of a decision to place it halfway between typed and untyped. I don't think it's valid to assert that any typed language is deficient if it does not have an expressive type system.
(I completely agree with your original point. "Worse is better" is not meant to be an equivalence)
This is a nitpick for sure, but Lisp via SBCL is hardly on the "slow side." This isn't 1970 anymore. Perhaps this is evident of "contempt culture" and how we propagate memes of fast vs. slow, types are good vs. types are restricting, and other non-specific comparisons.
> but having never used Go I'm wondering what makes it a "bad technology"?
The justification for Go is basically "developers are stupid and don't know what they are doing,so we're going to tell them what to do, how to do it and not trust them in any ways". Which is bullshit of course, it's just that Go compiler is bare-bone and so is its type system.
Go is bait+switch . It has just enough features to make it easy to learn/deploy, its standard library has just enough things to get one started quickly when it comes to writing servers.
But as soon as one tries to write something a bit complicated its short comings become obvious and tedious. Some see it as a blessing, some see it as an insult to software development. There is a bit of bad faith in both camps but Go authors have masterfully been able to escape any criticism with dubious arguments.
Imagine Java maintainers refusing to add closures to the language and the Java community would be justifying it by saying "closures are too complicated, slow and a bad practice".
Does it make Go a bad tech ? no, but it sure has a weird community. But Go has great ideas, it's just has horrible ones too. Fortunately, as the language becomes more popular, it will be more exposed to criticism. Which hopefully will lead to a better Go in the future, whether it comes from Google or not.
Go has a seriously good chance of becoming the language of choice for organizations which prefer to employ cheap code monkeys. As far as long-term career 'strategery' goes, specializing in Go development may be risky :)
It's one of the few languages I've seen where a programmer can progress from novice to master in a couple of months because its features are few and its opinions strong. It's easy and fun to learn (it might make an excellent CS 101 language, actually), but spend enough time with it and you will grow to dislike it.
That said, I do occasionally use it when I need to whip up a quick command line utility to do something simple :)
'Superior technology', when talking about a language, is entirely subjective and based on your opinion of why it is superior.
I've seen some amazingly elegant code in all of those things you've dismissed. Facebook is written in PHP, and I'm willing to bet you use an application or two that runs nicely on Node or Go. so what social signals are you talking about?
Why isn't it? If I needed to build a static site for someone wouldn't some tools and languages be better than others? Those same tools and languages may not be useful for building a very high traffic site that perhaps has an ecommerce component.
Tools and languages might (hypothetically) be better for a specific narrow purpose whilst being objectively inferior technology. A hammer is better for some jobs than a CNC machine.
I'm terribly sorry if I upset anyone by sounding arrogant. That wasn't my intention and is probably an unfortunate consequence of making snippy remarks on the internet, particularly ones that seem self-evident to me, even if others have differing perspectives.
That said, I do not see how anyone could not consider Python superior technology to PHP, C superior technology to BCPL and Pascal superior technology to punch cards.
All good - I think the initial short comment and the subtle "hypothetically" really just obscured what you were trying to say in response to the parent's "entirely subjective" comment - that some languages are objectively technologically superior to some others.
I do agree with that. I can think of various languages over ColdFusion as an example. Python versus PHP is not so clear cut if you look at the modern versions.
Anyway, I do think we should be more welcoming to those that use other languages though as the article recommends. It's possible to make a LOT of money these days doing simple CRUD apps. It's a great time to be a developer. We're all very blessed. So shouting about how one language is superior to another is meaningless to a lot of people. Even if you're right, people will feel like you're telling them they wasted their time with the others language(s). And that approach won't convert them if that's your goal.
Many of us also partake in business decisions so even if you think Python is technologically superior to PHP as an example, it won't make sense for many projects. Depending on your client base and/or your in-house skill-set - it may rarely make sense.
After you factor in things like total cost of ownership, what a client's current tech team is capable in, hosting costs, etc, technologically superior can be meaningless in many situations.
Enterprise systems are usually technologically superior and clients often only need or use 25% or less of the capabilities. Most of us could care less about enterprise systems.
For social reasons, not technical ones. PHP is the language of cheap labour. To address the technical issues, Facebook's PHP code gets thoroughly translated in their backend.
And social reasons aren't important? It's classic socially clueless developer mentality to think technical considerations are the only thing that matter.
Assuming you believe social reasons are important (rather than an unfortunate constraint on the world), then my strategy is still valid (if it works). It will make the technically superior languages socially superior as well.
Nice straw man argument. Pointing out that PHP is used for social/economic reasons is exactly saying that there are considerations outside technical merit.
At the same time, Facebook is a big Haskell user, but that is because of its technical merits. (Simon Marlow works for Facebook) On a back-end technology such as a compiler, the technical merits of the language are much more important than the social merits of finding enough low-skilled/low-paid developers.
No, mostly timing ones. Php was the cutting edge yet fully developed technology when they launched at Harvard. Developing CakePHP was in part a technical decision driven by the reality that a full rewrite in a new language is a form of technical debt in and of itself because of the time involved.
People disagreeing doesn't automatically make it subjective. It would be an amazing coincidence if every language and framework happened to be exactly as well-designed as every other, even though they were designed by different people with varied backgrounds, at different times.
> Vocal and demonstrable elitism is a valid social hack - if the people who are demonstrably great coders are proponents of Haskell and sneering at PHP, while the code monkeys are all using PHP, that's a pretty clear social signal.
Sure, but the sneering is totally unnecessary. Being great, and being vocal, and being critical – those are the things that get the job done in a constructive way. Why do we also need to cop an attitude that is unpleasant, socially undesirable more broadly, and aggressive towards people who could end up being valuable members of our preferred tribe?
Exactly. Tribalism is easy and effective, but in the long term it is destructive. It devolves rapidly into troll culture where the loudest voices are mostly parroting whatever aggressive message they've found gets the strongest reaction.
Explaining the advantages and disadvantages of different approaches without falling back on derision takes a lot of effort -especially given that there will never be an end to newbies who haven't heard a good explanation. But, it's necessary to avoid teaching that tech should be evaluated by comparing the insults of the competing communities.
There is no such thing as objectively "superior technology". It does not exist and if you think it does you are cheating yourself as a developer with this mental wall you have erected to block out reality.
A more experienced developer knows that there are only superior decisions; choosing the appropriate technology for the time and circumstances.
> So if we want superior technologies to win, we'll need to engage in some social hacks of our own. Vocal and demonstrable elitism is a valid social hack...
But not one that gets you where you're trying to go. It makes people regard you as an arrogant jerk, and therefore not listen to you. For your claimed purpose, that's counterproductive.
I agree there may be a collective action problem here. Being the first individual to follow this practice may be individually harmful, even though having a culture where everyone does it would be collectively beneficial.
I suppose one way to jump start things would be for some forward thinking company that wants to have a solid tech culture should proactively hire elitists.
First: No, having a culture where everyone does it would not be beneficial. It would be a culture of groupthink, where "right thinking" individuals shame everyone else for not thinking the right things, and everyone else joins in, not because they think the ideas are right, but to avoid being shamed. If you've been watching political correctness on college campuses, it ought to be clear why this is not collectively beneficial.
Second: If you're the first individual to follow this practice, it's not harmful to you (other than turning you into a snob who acts like a jerk). It's harmful to what you're trying to achieve. It makes it take longer to get to the point where you have people using languages you regard as superior, because they avoid talking to you. "Pompous jerk alert; run away! Don't get any of that on you!" That doesn't make it easier to persuade people that the languages you advocate are good on their merits.
Instead, show people why the languages you like are better. Actually listen when they disagree; they may have more of a point than you know.
It cuts both ways, because even more fundamental to Rails' success is the ActiveRecord ORM, which has probably prevented tens of thousands of SQL injection vulnerabilities.
Does it cut three ways? Like the yaml bug? They didn't stop at making it easy for beginners to be secure, but kept pushing past that until it became impossible for experts to avoid insecurities.
I think we may disagree on this, but my position is that such bugs are an unavoidable consequence of too many friendly abstraction layers.
The YAML bug wasn't sui generis (it's a bug class that is very common in Java frameworks), but it didn't follow from any basic design principle of Rails. I generally assume bugs like these are evenly distributed among all frameworks and languages --- or at least, all the platforms where code is easy to write (C doesn't tend to have these kinds of problems, but it would be dumb to opt for C over Ruby for security).
It's easier to get up and started with PHP, which attracts people new to coding. I don't have any contempt for them. It's a language with a very low barrier to entry.
I have INFINITE contempt for professional programmers who (1) use PHP (2) have never used anything else and (3) vociferously defend PHP because it "gets things done" but then (4) leak MD5 hashes of credit card info in an error page.
I remember when this was true but I don't think it is anymore. Whenever someone asks me to teach them how to program from scratch I always introduce them to the REPL first. You know, "1 + 1 prints 2!" The easiest way to do that for some time has been the chrome dev tools.
Well spoken. When I hear people belittling others, no matter how "good" the reason, I think damn, have some respect. And also just, have some dignity.
If you really want to influence someone's behavior, engage them, ask them honest questions, accept them. If you do not want to influence their behavior, leave them alone. Do not drag your own heart through mockery and judgment and scorn because it was done to you, or because others will find it funny. Those marks on your heart will be visible to all, and truly, you will feel them in your dark hours.
The supreme good is like water,
which nourishes all things without trying to.
It is content with the low places that people disdain.
Thus it is like the Tao.
I have always thought that one of JavaScript (or at least the community's) best assets is the fact that no one defends it as "the best" or "the next big thing." Everyone embraces discussing its faults or mocking poorly written JS and admitting that it happens a lot. I think this allows the community to be honest when teaching people how to avoid its pitfalls and puts the spotlight on frameworks and libraries that encourage good patterns.
I think the real problem is being able to distinguish between criticism of a language and criticism of the people using it. The former is ok, the latter isn't.
If we take a criticism of a technology we use as criticism of us, it's a rather unhealthy state to be in. Technologies come and go. They aren't something we should immerse our identity in.
Perhaps some of the contempt is due to suffering at the hands of management who insists that there is one golden hammer (language) that must be used for all problems.
Not being able to switch tools for different tasks is a source of frustration, and this frustration WILL find a vent :-)
When I reach the "Shut. Up." section the article feels more like a re-expression of its subject than an overcoming. These tendencies are harder to overcome than they seem. They're slippery, and there's good in them as well as bad.
88 comments
[ 4.3 ms ] story [ 159 ms ] threadI have no interest going around belittling people for choices that work for them, but this implicit idea that technological decisions are all a matter of taste and nobody can criticize them is dumb to me.
On the other hand, the people wielding those languages do not deserve any hate, shame, nor prejudice. Attacking people for using a language is like attacking people for any other opinion that they might harbor; it is bigotry. There is no reason to be a bigot when it comes to languages; it should suffice merely to hold the opinion, to have the opinion be well-reasoned, and to always be conscientious of how we treat the people around us.
(I cannot believe that I had to write the previous paragraph, but HN's inability to hold this discussion in a calm and rational way in the past has made it clear that I must directly tell you all to not be bigots. Disappointing.)
It is a recurring pattern that discussions about these low-quality languages turn into us-vs.-them discussions, where one side harbors people who espouse the opinion that the language in question is low-quality, and the other side consists of people who use the language in question on a daily basis. The first side needs to avoid attacking and hurting people on the other side. It is unhelpful and derails the conversation. In particular, trying to communicate an idea of the form, "You need to be aware of the language's failings and flaws, and understand that not all other languages have these problems," is subtle and cannot be done while simultaneously flinging insults.
On the other side, we all must realize that our favorite languages are terrible. Our languages, like almost all facets of computing in this era, are primitive. We have only a few fundamental rules which guide our knowledge of computing, but otherwise we are usually walking blind, exploring and feeling our way through a field which is still largely unlit. When we discuss the failings of a particular language, we are trying to build up our understanding of which linguistic features do not work, and which features should be avoided.
In summary, we should kill PHP and JS, but we should have empathy for those who use these languages, and we should make sure that we learn from the mistakes which these languages embody as we step forward.
You said it yourself, sometimes you need things to be done faster, but most of the time systems should be robust. Python is an excellent companion to Java. Python is one of the most versatile language out there while Java is one of the most robust.
There is a lot of bad technology being pushed via social hacks - examples include PHP, MongoDB, NodeJS and Go. Typically the social hacks are low learning curve + easy tutorials that gloss over important details [1] + rapid setup + culture of piling on tech debt (e.g. rails ignoring how relational DBs work).
Technical superiority, particularly if that superiority requires people to learn new things, has demonstrated an inability to gain traction.
So if we want superior technologies to win, we'll need to engage in some social hacks of our own. Vocal and demonstrable elitism is a valid social hack - if the people who are demonstrably great coders are proponents of Haskell and sneering at PHP, while the code monkeys are all using PHP, that's a pretty clear social signal. Who wants to be part of the code monkey crowd?
When I was younger, and nothing but a BasicA/Visual Basic coder, these attitudes pushed me towards learning C and Perl (yes I'm showing my age). I saw all the better coders using these superior technologies with a higher learning curve. I realized that I had a lot to learn, I put in the effort and I learned it. With the decline of hacker culture, I don't see that happening anywhere near as much these days.
[1] E.g. a while back there were RoR tutorials that used update_attributes (skipping input validation) to show how easy RoR is. Net result was various hacks, I think including Homakov's hack of github.
People publish blog posts about how they aren't using MongoDB or aren't using PHP anymore because X and Y and do you know who cares? Pretty much no one aside from the pro PHP people who get mad or the anti-mongo people who point to it as justification for their part in a completely pointless argument.
Yes, low skill and approachable languages attract amateur coders because that's what they're supposed to do. PHP was designed from the get go to be an accessible web server language that anybody could use, that was the POINT so naturally anybody who can will use it.
I've seen brilliant PHP websites and I've seen utterly garbage C code, and both of those reversed too. There is a correlation between use of high level languages and skill but it is far from a fixed relationship, so to parade about someone's use of those to justify their arrogance as a programmer relative to people who are WELL AWARE that they are better than them just makes that person look like a windbag.
/rant
They care about bugs, vulnerabilities, and third-party quality issues - all of which a bad language/framework will help you to have.
Human beings are the original proof engines, so I'm sure that a great programmer could perform amazing type checking in any language. I'm sure they could also architect their way around Java's weak points with Abstract Factory Patterns, xor hand-tune their code for the JVM JIT to be only 1.9x slower than a naive C implementation (See: what they had to do for Minecraft).
But, why?
It's easier to learn the syntax for a good compiler than it is to implement one in your head...
I don't see the raspberry pi people being derided and mocked by Intel's engineers because they use such lowly plebian tools.
Its interesting that this point comes up in a world containing useful google results for "try ruby" "try clojure" "try haskell" "try-python" "try scheme" but there are no useful google results for "try cobol" "try java" "try php" or "try visual basic".
We can play a similar game with Koan style learning with very similar results.
I agree that PHP was designed to be a bad language but easy for noobs. That's the point. By having a low learning curve it has displaced vastly better choices. And that's why I'm suggesting we need to fight social hacks with other social hacks.
I think we see this narrative a lot with Haskell. Although the Haskell community is reportedly very friendly once you actually try to work with Haskell, I've seen a lot of comments by its enthusiasts denigrating "lesser" languages.
So I agree with the OP. There's not a lot to be gained by telling people they're stupid. By and large this just causes them to entrench their positions. (See also: electoral politics.) I think there's much more ground to be gained by deliberately blurring the lines (a different social hack.) Examples of this include Cygwin and optional type systems for dynamic languages.
As an example within tech, sneering and contempt have enabled social justice to spread wildly. Look at how many projects/conferences have codes of conduct now, compared to a few years ago, and at how many technology companies are throwing money at diversity efforts.
I don't know if it's the right strategy, but it's definitively not a strategy I can immediately dismiss.
The problem is that this doesn't mean every option is equally good for the end user. A lot of software that gets belittled is criticized for being a good way to provide a bad product. These are tools that are great for getting things done quickly and smoothly, in return for kicking the can down the road on reliability, security, or modifiability.
Think of the small insurance companies which offer easy signup at low rates - and then don't come through when you file a claim. When people go out and produce lengthy essays on why Mongo is dangerous, it's often a response to seeing systems that work for now, but are likely to fall over completely sometime after the contract is done. When your database offers high throughput by not actually checking for successful writes, it's easy to hand over a performant system that's going to lose a bunch of medical records the first time a server fails.
So no, the client doesn't know or care, but all too often that's because they're getting immediate benefit in return for delayed, probabilistic risk, and no one is telling them about the tradeoff.
None of that is justification for being a jerk, or mocking actual people (obviously!) Nor is it a reason to pretend that Mongo is never a good database choice, or that PHP is never a good language choice. And you're right about the grossness of mocking beginning programmers for starting with approachable tools.
But I object to the idea that the value of debates should be measured by whether users care about them. I'm not much interested in what my bridges are made of, but that's because I have faith that someone behind the scenes built them reliably. All too often, that's not the case in software.
Could a language be "better" simply by being harder to learn?
With apache configured to run the program as a CGI script? Still the same thing.
That's not a great way to run Haskell on the web, but it's not too far from what's going on with historically common out-of-the-box PHP setups (and I understand that modern PHP setups take a little more code).
But, no matter how complex the language is, it doesn't, unless "hello world" becomes incredibly platform, context, and (e.g.) day-of-the-motnh-on-which-it-is-compiled sensitive.
Because, otherwise, it may take the first person some competence to "hello world", but everyone else can get by with copypasta and memorization.
https://www.rosettacode.org/wiki/FizzBuzz/Java
vs fizzbuzz Enterprise java
https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
Enterprise style java is not inherently bad, anyway. Its ideal for padding hours of government cost plus contracts, or megacorporation initiatives that'll be scrapped before deployment anyway.
There is a competing force though: if a language is flat out difficult to use, then much of the programmer's ability will be spent getting the damned thing to work.
Passing the ACID3 test suite with a browser written by hand entirely in Brainfuck is a clear indication of a highly skilled programmer. That doesn't mean you should build a business on Brainfuck though :)
I've mostly heard good things about Go, except for lack of generics and the use of github repos in "import" statements.
Are those the reasons you think it's bad, are there more serious ones? Is Go actually "bad", or does it just bring little to the table? I understand Go's meant to be a middle-ground between Python (dynamic, memory-safe, slow) and C (static, unsafe, fast); do you consider it a step forward in that regard? If a bug-free, non-obfuscating source-to-source translator between two languages appeared overnight, would you prefer those languages to be Python -> Go, Go -> Python, C -> Go or Go -> C?
If you want a middle ground between Python, there are already great options that provide everything Go does and more, for example Java, Scala, Common Lisp, Haskell and Rust. Lisp is a bit closer to the dynamic/slow side, Haskell/Java/Scala are more or less Pareto superior to Go, and Rust is a little closer to the static/fast/unsafe side.
But unlike Go, Haskell/Scala/Java expect you to learn a few things before you can be really productive in them.
(I completely agree with your original point. "Worse is better" is not meant to be an equivalence)
This is a nitpick for sure, but Lisp via SBCL is hardly on the "slow side." This isn't 1970 anymore. Perhaps this is evident of "contempt culture" and how we propagate memes of fast vs. slow, types are good vs. types are restricting, and other non-specific comparisons.
The justification for Go is basically "developers are stupid and don't know what they are doing,so we're going to tell them what to do, how to do it and not trust them in any ways". Which is bullshit of course, it's just that Go compiler is bare-bone and so is its type system.
Go is bait+switch . It has just enough features to make it easy to learn/deploy, its standard library has just enough things to get one started quickly when it comes to writing servers.
But as soon as one tries to write something a bit complicated its short comings become obvious and tedious. Some see it as a blessing, some see it as an insult to software development. There is a bit of bad faith in both camps but Go authors have masterfully been able to escape any criticism with dubious arguments.
Imagine Java maintainers refusing to add closures to the language and the Java community would be justifying it by saying "closures are too complicated, slow and a bad practice".
Does it make Go a bad tech ? no, but it sure has a weird community. But Go has great ideas, it's just has horrible ones too. Fortunately, as the language becomes more popular, it will be more exposed to criticism. Which hopefully will lead to a better Go in the future, whether it comes from Google or not.
It's one of the few languages I've seen where a programmer can progress from novice to master in a couple of months because its features are few and its opinions strong. It's easy and fun to learn (it might make an excellent CS 101 language, actually), but spend enough time with it and you will grow to dislike it.
That said, I do occasionally use it when I need to whip up a quick command line utility to do something simple :)
'Superior technology', when talking about a language, is entirely subjective and based on your opinion of why it is superior.
I've seen some amazingly elegant code in all of those things you've dismissed. Facebook is written in PHP, and I'm willing to bet you use an application or two that runs nicely on Node or Go. so what social signals are you talking about?
No it's not.
That said, I do not see how anyone could not consider Python superior technology to PHP, C superior technology to BCPL and Pascal superior technology to punch cards.
I do agree with that. I can think of various languages over ColdFusion as an example. Python versus PHP is not so clear cut if you look at the modern versions.
Anyway, I do think we should be more welcoming to those that use other languages though as the article recommends. It's possible to make a LOT of money these days doing simple CRUD apps. It's a great time to be a developer. We're all very blessed. So shouting about how one language is superior to another is meaningless to a lot of people. Even if you're right, people will feel like you're telling them they wasted their time with the others language(s). And that approach won't convert them if that's your goal.
Many of us also partake in business decisions so even if you think Python is technologically superior to PHP as an example, it won't make sense for many projects. Depending on your client base and/or your in-house skill-set - it may rarely make sense.
After you factor in things like total cost of ownership, what a client's current tech team is capable in, hosting costs, etc, technologically superior can be meaningless in many situations.
Enterprise systems are usually technologically superior and clients often only need or use 25% or less of the capabilities. Most of us could care less about enterprise systems.
For social reasons, not technical ones. PHP is the language of cheap labour. To address the technical issues, Facebook's PHP code gets thoroughly translated in their backend.
Nice straw man argument. Pointing out that PHP is used for social/economic reasons is exactly saying that there are considerations outside technical merit.
At the same time, Facebook is a big Haskell user, but that is because of its technical merits. (Simon Marlow works for Facebook) On a back-end technology such as a compiler, the technical merits of the language are much more important than the social merits of finding enough low-skilled/low-paid developers.
Or so I've heard
Sure, but the sneering is totally unnecessary. Being great, and being vocal, and being critical – those are the things that get the job done in a constructive way. Why do we also need to cop an attitude that is unpleasant, socially undesirable more broadly, and aggressive towards people who could end up being valuable members of our preferred tribe?
Explaining the advantages and disadvantages of different approaches without falling back on derision takes a lot of effort -especially given that there will never be an end to newbies who haven't heard a good explanation. But, it's necessary to avoid teaching that tech should be evaluated by comparing the insults of the competing communities.
A more experienced developer knows that there are only superior decisions; choosing the appropriate technology for the time and circumstances.
But not one that gets you where you're trying to go. It makes people regard you as an arrogant jerk, and therefore not listen to you. For your claimed purpose, that's counterproductive.
I suppose one way to jump start things would be for some forward thinking company that wants to have a solid tech culture should proactively hire elitists.
Second: If you're the first individual to follow this practice, it's not harmful to you (other than turning you into a snob who acts like a jerk). It's harmful to what you're trying to achieve. It makes it take longer to get to the point where you have people using languages you regard as superior, because they avoid talking to you. "Pompous jerk alert; run away! Don't get any of that on you!" That doesn't make it easier to persuade people that the languages you advocate are good on their merits.
Instead, show people why the languages you like are better. Actually listen when they disagree; they may have more of a point than you know.
I think we may disagree on this, but my position is that such bugs are an unavoidable consequence of too many friendly abstraction layers.
I have INFINITE contempt for professional programmers who (1) use PHP (2) have never used anything else and (3) vociferously defend PHP because it "gets things done" but then (4) leak MD5 hashes of credit card info in an error page.
Why wouldn't I be contemptuous of fraudsters?
If you really want to influence someone's behavior, engage them, ask them honest questions, accept them. If you do not want to influence their behavior, leave them alone. Do not drag your own heart through mockery and judgment and scorn because it was done to you, or because others will find it funny. Those marks on your heart will be visible to all, and truly, you will feel them in your dark hours.
"When you realize where you come from,
you naturally become tolerant,
disinterested, amused,
kindhearted as a grandmother,
dignified as a king.
Immersed in the wonder of the Tao,
you can deal with whatever life brings you,
and when death comes, you are ready."
If we take a criticism of a technology we use as criticism of us, it's a rather unhealthy state to be in. Technologies come and go. They aren't something we should immerse our identity in.
Not being able to switch tools for different tasks is a source of frustration, and this frustration WILL find a vent :-)