Why I Hate Programming Language Advocacy (2000)

https://www.perl.com/pub/2000/12/advocacy.html/

by smasher164 • 5 years ago

63 72 5 years ago

mikewarot3• 5 years ago

I don't think the problem is with advocacy itself, but the way people always pick apart examples, leaving no effective way to tell stories anymore.

Sometimes type checking is good, other times it gets in the way. It would be interesting if there were a way to compose a program with no typing, in order to quickly get to a MVP. Once done, you could then interact with the compiler/computer in a way to fully specify intent, and result with a fully typed codebase.

Being able to loosen up typing would likely have its uses as well.

rightbyte• 5 years ago

Groovy maybe?

jakobnissen• 5 years ago

This is sort of being done right now, as dynamic languages have begun to adopt gradual typing... at least Python and Julia, that I know of.

If something like [JET.jl](https://github.com/aviatesk/JET.jl) become ubiquitous in Julia, one could add a function that pointed out all the places in the code where types are not fully inferred by the compiler.

It'll never be quite the same level of safety as a static language, however.

BlackFly• 5 years ago

In moving from the untyped lambda calculus to the simply typed lambda calculus, one loses the ability to have non-halting programs. For me this just illustrates a fundamental point of type systems: limit the possibilities to make them understandable. Clearly I cannot describe a typical server with the simply typed lambda calculus, I need some kind of `while true: do()`.

With dynamic typing, it is easy to make programs that work with types that are extremely difficult to describe and comprehend. I think that is what TypeScript has added so much advanced type theory level functionality: it is necessary to describe what people did with dynamically typed javascript. I imagine MyPy and company will have a similar trajectory for python. People did some really incredible things in these dynamic languages, things which are very difficult to describe formally.

Meanwhile, it seems to me at least part of the point of some statically typed languages is to force people to work with simpler type systems to solve their problems. Because those simpler types may be easier to understand even if they require more effort or more code to solve the same problem. I do think Go was far too adamant for far too long about not needing generics (also known as parametric polymorphism); seems sober minds clearly disagree about where to put the boundaries. To me it seems that statically typed languages embrace the notion of "Good enough, but not perfect." They provide enough expression to solve problems, but not enough expression to describe all solutions.

xupybd2• 5 years ago

It seems to me that limiting possibilities is the best way to reduce complexity.

Immutability, strong types, no goto, no global state and the list goes on. These all avoid the complexity of too many possibilities.

cheph• 5 years ago

I do think Go was far too adamant for far too long about not needing generics (also known as parametric polymorphism); seems sober minds clearly disagree about where to put the boundaries.

Adamant is rather generous. Golang maintainers are overly defensive about serious deficiencies in an otherwise mediocre programming language. It is the worst tool for the job in almost any situation.

At the moment it is easier to write correct software in Python than it is to do it in Golang and in almost all cases correctness is more important than performance.

otabdeveloper4• 5 years ago

other times it gets in the way

No, not really.

Once done, you could then interact with the compiler/computer in a way to fully specify intent

Doesn't work that way. Once you went down the path of laziness and started to e.g., dumping data structures into untyped dictionaries or lists instead of properly specifying them, there is no going back without throwing out all the code and rewriting.

mikewarot3• 5 years ago

I come from the strongly typed world of Pascal... I wasn't thinking about dictionaries, but rather the decision to use a Byte, U32, U64, Real, Single, Double, etc. You could always use the longer, more expensive option for prototyping, then slim it down once you have a better idea of what's needed.

Similar to the way the precision of calculations in neural networks is shaved down for performance, but only as long as the output stays reasonable.

foxes3• 5 years ago

There are plenty of languages that let you type without having to "type" out a type definition, auto types in C++, type inference in Haskell. Probably most of my Haskell code I do not need to specify types. So the technology and theory exists to make this happen.

But also, when has typing ever gotten in the way? Actually having to think about the problem and the correctness of your program? It's somewhat amazing that correctness is so easily discarded. People just get stuck in a local minimum.

dgb235• 5 years ago

They don't get in the way in that regard. There are solutions they simply cannot express and sometimes the best solution is one of these.

Correctness has little to do with it. Most type systems cannot express the actually important stuff, so you need to write defensive code anyway and make sure it works.

When you write in a dynamically typed language you are going to miss static typing sometimes and vice versa. The big advantage of static typing is performance and not necessarily correctness.

rocqua2• 5 years ago

Note that there are downsides to type inference. Most notably, with too much type inference you quickly run into undecidability. Specifically, programs for which the question "is this well typed" is not decidable. (Essentially it allows encoding of paradoxes in the type system).

This is why Haskell and C++ do sometimes require types to be mentioned.

lmm8• 5 years ago

The reality is that popularity is hugely important for programming languages. Tooling is important, but you'll only get good tool support if you're popular; there are what, two and a half full IDEs out there, and at least for certain kinds of languages, having first-class support in those IDEs is a much bigger difference maker than anything you can do at an actual language design level. Similarly for things like having big hosted repositories with lots of libraries available, and first-class support in official SDKs.

Don't get me wrong, I wish programming language competition was less zero-sum than it is, but sticking our heads in the sand about it doesn't help.

mjburgess3• 5 years ago

I think this could be a tad outdated.

Given generic language tooling innovation (lang server, llvm, ...) it's possible to launch a language with good tooling.

Given, also, the ability to piggyback on jvm/.net/cpython-vm (cf. julia)/c ffi/.. its also possible to launch with libraries.

I think today language popularity is a lot more about: (1) big name support; (2) killer app/library.

If you can't get (1), and you're in the lang. game, i'd be looking at a (2).

ie., solve some problem better than its being solved anywhere right now, in your language, in a way which naturally suits it. The opportunity cost (on using poorer solns) then forces adoption.

lmm8• 5 years ago

Disagree; generic tooling is improving but it's a long way from being "there" yet, and FFIs have barely improved over the last 10 or so years; they make it possible to use libraries from other languages, but they don't (and maybe can't) make it idiomatic.

CaptArmchair2• 5 years ago

Programming languages have a lot in common with natural languages. The viability of the latter tends to be measured by it's native speakers, daily use, proliferation, adoption,... and so on. Linguists and anthropologists don't consider those metrics in isolation though.

The evolution of language can only be explained by considering context as well: natural languages are intrinsically tied to communities, tribes, culture, shared identities, shared morals and values, geography and so on and so on. In that regard, this evolution is extremely fluid. Billions of people know more then one language. Languages influence each other, as peoples and cultures meet. Sometimes, languages are adopted, like French was adopted by English elites after the Norman invasion, or Greek was the language of Roman elites.

Programming languages share many parallels with natural language. It's a fallacy to assume that programmers are homogeneous group of individuals with no discernible differences. On the contrary, being a programming is just part of one's identity. Most people come to programming because they are interested in solving particular challenges, or contributing to larger goals in specific problem domains or industries. The challenges faced by embedded system engineers in aviation are nowhere near the same as those faced by an frontend engineer specialized in using a particular content management system.

Moreover, many programmers don't reduce themselves to a single language. They might know the nooks and crannies of one or two languages in depth - much like a native speaker is innately wired to their mother tongue - but chances are they know a handful languages which are useful throughout their career and daily life, such as they identify parts of it with programming.

In that regard, I feel that the 'competition' between programming languages is largely perceived, instead of a real thing.

At worst, it leads people into "golden hammer" thinking about the tools they use. The "zero sum" thinking as you've pointed out, then reveals itself for what it is: a self-fulfilling prophecy, self inflicted by tool-centric thinking.

And that's exactly what the article is arguing against.

lmm8• 5 years ago

Programming languages have a lot in common with natural languages.

Can you substantiate this claim? They're not used in the same way, their learning patterns are different; the fact that we use the same word is coincidence more than anything IMO.

At worst, it leads people into "golden hammer" thinking about the tools they use. The "zero sum" thinking as you've pointed out, then reveals itself for what it is: a self-fulfilling prophecy, self inflicted by tool-centric thinking.

Nonsense. The advantages of having good tooling and ecosystem are very real and concrete. If anything, the idea that particular programming languages are useful in particular problem domains is a lot more of an self-fulfilling prophecy - in my experience any halfway decent general-purpose programming language can be used in every domain if you actually try, usually the only reason to prefer a language with a good reputation in that domain is because there tend to be more libraries and so on, but that itself happens for purely circular reasons.

(If you really believe that programming languages are like natural languages, wouldn't you expect programmers to pick one and use it for everything?)

joelbluminator6• 5 years ago

Indeed, when language popularity declines usually the selection of jobs declines; how easy is it for a Perl programmer to get a Perl job? And yes, there is such a thing as a Perl programmer: if the job requires Perl experience they need a Perl programmer, period.

kstenerud• 5 years ago

It's the same old problem of identity beliefs: An "attack" on any part of the belief is an attack upon the person, and elicits an "I must defeat my opponent by any means necessary (fair or unfair)" response. Discussions will take hard turns into logical fallacies and the person making them will be convinced that they're acting perfectly normal, because the lower brain has cut off the rational section as part of the "fight-or-flight" response. It's fascinating to watch the Jekyll-Hyde transformation in real time, but not fun trying to disengage.

We take on identity beliefs in so many areas of our lives (most commonly in religion and politics), and programming languages or text editor preferences are particularly notable areas of identity belief when it comes to programmers.

I've long given up participating in language or editor criticism because it's simply impossible to have a rational discussion about it. We used to have similar problems with RISC vs CISC discussions, but I think that has largely faded into history by now.

MaxBarraclough• 5 years ago

Right. The article boils down to people being personally attached to programming languages, leading to emotion-driven fanboyism rather than serious objective evaluation of languages/paradigms/ideas. It's unfortunate that software developer culture treats this as normal, rather than as unbecoming and, frankly, immature.

pjmlp• 5 years ago

That is bound to happen when certain groups sell themselves as X Developer instead of Software Developer.

So anything that diminshes the value of X is seen as an attack of the valuation of the respective person skills.

klibertp• 5 years ago

rather than as unbecoming and, frankly, immature.

It's natural and normal for young people, I think. It's easy to be entranced by some idea when you're in your teens and early twenties. Older programmers, if they stay active and not transition to management, early retirement, or get burned out and switch careers completely, tend not to be that dogmatic about the tools they use. I wonder what is the percentage of programmers below 30 years old in all active programmers?

On the other hand, getting dogmatic, cult-like even, is sometimes the only reasonable strategy for a language to survive. Languages that offer capabilities way beyond mainstream (which is not that hard...) often have a small, but very dedicated following. The people there have to believe their language is so much better than the others, because otherwise they'd have to admit that the amount of time and effort they pour into it is unreasonable. Such communities are allergic to posts saying that "another language also has this" or "you can do the same in language/tool X", and they demand a level of dedication which, for outsiders, is just creepy. But, without that, the whole project, the language and ecosystem, would simply die, and more often than not that would be a real loss for the programming world. It's hard to interact with such groups as a non-believer, but without them some of the great ideas of the past wouldn't be preserved, and some great new ideas wouldn't be implemented.

So, I think in some cases the fanboyism is a rational stance to take. In most cases, though, it's just immature expression of fascination, and then it indeed serves no real purpose, other than annoying more experienced devs.

scandox• 5 years ago

I had a friend many years ago who was very smart but also quite paranoid. I noticed that even mentioning the name of someone he perceived as his enemy caused him to become very cool towards me. Anything less than a total character assassination of that person when referring to them was interpreted as advocacy for them. It was quite disorienting.

Since then I have seen how this same mentality manifests itself on a grand scale on the net. Now description is advocacy.

goto11• 5 years ago

Programming languages shape the way we think about problems. I know linguists reject the Sapir-Whorf hypothesis for natural languages, but I definitely think it is true when it comes to programming languages.

This means the language you are familiar with will always looks more efficient and a better fit for any particular problem than a language you are not as familiar with. While tribalism and identity certainly plays a part in language wars, I believe the language advocacy is often genuine in the sense that the advocate really believe their preferred language is superior, and just want to help other people realize this. They genuinely don't understand why people would deliberately chose to use an obviously inferior programming language.

A example of this form of advocacy is the classic "Revenge of the Nerds" http://www.paulgraham.com/icad.html

As an illustration of what I mean about the relative power of programming languages, consider the following problem. We want to write a function that generates accumulators-- a function that takes a number n, and returns a function that takes another number i and returns n incremented by i.

Note that the "problem" used to compare language power is not actually a problem. Rather it the solution a particular language would use to solve some problem. Unsurprisingly this particular language "turns out" to be the most powerful in the comparison. If we had chosen a different "problem" like writing a function which was statically guaranteed to return a list of integers, the winner would be different.

pron• 5 years ago

Leslie Lamport said,

Computer scientists collectively suffer from what I call the Whorfian syndrome1—the confusion of language with reality. [1]

And, on comparing languages [2] (paraphrased from "specifying" to "programming"):

Comparisons between radically different formalisms tend to cause a great deal of confusion. Proponents of formalism A often claim that formalism B is inadequate because concepts that are fundamental to [programs] written with A cannot be expressed with B. Such arguments are misleading. The purpose of a formalism is not to express [programs] written in another formalism, but to [program] some aspects of some class of computer systems. [Programs] of the same system written with two different formalisms are likely to be formally incomparable… Arguments that compare formalisms directly, without considering how those formalisms are used to [program] actual systems, are useless.

[1] http://lamport.azurewebsites.net/pubs/deroever-festschrift.p...

[2] http://lamport.azurewebsites.net/pubs/lamport-verification.p...

xupybd2• 5 years ago

Programming languages have strong emotional attachments for me. I remember being stuck in some messy code with deadlines looming, and the frustrations tend to get attached to that language. If I find a language fun and easy to get into a flow I love it. Objective C, was the first I loved. Perl I hated, I always came unstuck by something that I didn't know about the language and felt annoyed. Unfortunately most of my language evaluation are emotionally charged. I don't know if I can give a rational evaluation.

PHP I hated but then we had someone brilliant with PHP come in and fix up the legacy mess we were dealing with. After that I grew rather fond of PHP. F# I really enjoy, but suspect that is because I have never used it under the pressure of a paid project.

5jt• 5 years ago

The next episode of The Array Cast (array cast.com) discusses the rise and fall of the array languages APL, J, k and q.

question000• 5 years ago

I actually love programming language advocacy and programming language partisanship even when it's rooted in ignorance, just because generally peoples efforts are better spent extending existing languages as opposed to trying to solve problems by improving the language it's self.

There needs to a bit of friction in the system or everyone is using discrete languages nobody else understands, even for irrational reasons.

roenxi• 5 years ago

I think the problem is a bit more subtle and much deeper than "we're doing advocacy wrong". The differences between programming languages are, in a sense, trivial. Maybe one language is an order of magnitude more powerful than another. Important, but in the last 50 years identifying the right market sector to be involved with is worth a billion dollars and the wrong one is worth hundreds of thousands. So if the point here is to be effective, programming language is a relatively minor factor. Most of the surviving languages have similar power anyway.

But what is not at all trivial is a lot of people exist who feel they have an 'edge' by knowing their language really well or feel threatened (or, indeed, exasperated) at having to learn a new language. I'm guessing this pool of people is also biased towards marginal programmers and people making money off advocacy.

It makes sense to me that advocacy would generally be of bad quality. The rewards for shepherding the programming community towards a more productive language are low and rare compared to the rewards of convincing people to do X where X is what the advocate is involved with already.

papito4• 5 years ago

If you become a "language zealot", you are really not helping yourself as a software engineer. The day I get referred to myself as "that Node developer" or "that Python guy", I will consider my career to have taken a wrong turn.

Don't get attached to no language, no company, or no lover.

tester342• 5 years ago

maybe "that Python guy" is poor, but "that guy who's proficent at Python internals and stuff" is infinitely better

"that Linux guy" isn't impressive, but "Linux kernel maintainer" is

papito4• 5 years ago

I will bet that a Linux kernel maintainer is a more capable coder than someone stitching together web apps with Rails.

Besides, something like language and kernel design is computer science, not day-to-day software development that most of us do.

joelbluminator6• 5 years ago

How do you survive in this business when you're getting older if you switch stacks every X years? I have somewhat averagish abilities and I think to get a competitive advantage I better stick to my stack. It's not necessarily being a language zealot, just a decision to go all in on something and become an expert.

papito4• 5 years ago

Be careful about becoming an expert. Maybe being "good enough" is a better investment of your time.

I once wrote a business-facing app in ExtJS. I played around with it, and I said, "ExtJS is cool, I am going to get good at it".

Six months of studying the dark corners of ExtJS and becoming really good at performance challenges and corner cases, ExtJS comes out with version 4, burning the bridges with new paradigms and making my "expertise" obsolete.

In general, stick to micro-frameworks. It's much harder to get burned in that world.

WesolyKubeczek• 5 years ago

But frankly, job advertisements that seek a "PHP developer" or "Python developer" or "React guru" don't help. A young developer entering the job market sees those ads, and thinks this is how the things are. I sure was thinking this was normal for a while.

papito4• 5 years ago

Yeah, but to be fair, there is only so much you can learn while entering the market, so you only have the bandwidth to grok one language and framework.

Companies that look for talented and true language-agnostic quick learners tone down their requirements for a specific technology stack, and sometimes don't even mention it.

mybrid2• 5 years ago

TLDR; humans are tribal

American politics has regressed on a scale of civilized to tribal. This is something we can all intuit and I think articles like this are going to become more common place. How do humans overcome base nature to become civilized? This is poorly understood. Religion wants to take all the credit. People like Stephen Pinker point to the Enlightenment being responsible and Enlightenment under attack today is civilization under attack. The fact our culture is coarsening into ever larger degrees of tribalism is disturbing. Computer science will not be able to stay out of the fray. Nor will any human endeavour.

dgb235• 5 years ago

I think it has more to do with the emotional investment into learning a programming language.

If you are a bit experienced and/or educated, you can learn most languages fairly quickly. I'm fairly confident that most programmers will become reasonably productive with using a new language in under a month.

The issue is however that many of us don't want to be just "reasonably productive". We are nerds who really love what we do and take pride in our craft. So we want to dive deeper and deeper, reach competency and expertise and increase the fun we have continuously.

This part of continuous learning and refinement is rewarding but also really hard. A particular language can get in the way of that or help us to become better in some dimension of expertise. There is a mindset behind a language that might fit ours like a glove, it just flows more naturally.

But this emotional investment can sometimes hinder us in the long run, when we invest so much time and effort into something we don't like to hear that our choice was arbitrary or even bad in some way or another.

The antidote do that is to keep learning new languages and technologies at a reasonable pace. Suddenly the emotional attachment fades.

mybrid2• 5 years ago

In a cultural perspective emotional investment is commensurate with tradition, norms and mores. That is human nature that any endeavor will take on the trappings of our evolutionary heritage. Programming languages are no different. Taboos and other tribal patterns apply. It doesn't do the computing community any favor pretending this is just about learning.

ajsnigrutin• 5 years ago

I see programming language advocacy the same as car advocacy, where someone driving a VW will crap on all other cars, and then buy a Toyota, and again say all other cars are crap, including VW, .. and then back to VW, and Toyota is crap again.

And again, languages are also like cars... you usually want a simple enough car, that does the job.... if you go to ikea to buy a pack of curtains, you don't need a huge car, and a motorcyle is a best price/performance selection... if you can drive one. To translate this to languages, if you need to create something, use something that is able to do the job, and that you're actually capable of using to write the code for that job. Need to open a url, get an xml, parse it, and print a number from it to a terminal? Yes, optimized assembly will do it the fastest, perl/python/ruby will do it with the least code, but if you're only familiar with JS, even if it's slow, a a (node)js solution might still be best for you.

bartread• 5 years ago

A brief observation: this style of "advocacy discussion" or "advocacy interpretation/listening" is sadly not limited to programming languages. It's something that I've seen is prevalent in many aspects of technical discussion for the whole of my professional career which, coincidentally, began in 2000, as well as before that when I was at school and university.

Given this is the case I suspect, and here I admit that I'm extrapolating from a very limited dataset, that the root goes back to our early lives and education. There is some flaw in our education or thinking that fails to teach us to hear what somebody is actually saying versus what we want (or assume) they are saying. And that refusal to hear can, whether by accident or by design, come across as both stubborn and wilful, which only further serves to shut down fruitful conversation.

Sadly the issue now infects discussion on all manner of topics (both important and less so) and leads to heated debates and arguments that go nowhere. People literally become angry with eachother and fall out over... well, because they're not meaninfully communicating, they effectively fall out over nothing.

It's both ridiculous and profoundly depressing, but what I think it may indicate is a failure to mature in thinking. How widespread that failure is, is hard to say, but amongst people who use social media (for example) it appears to be at the very least a substantial minority (again, I haven't formally measured this so take the observation with a pinch of salt).

totetsu• 5 years ago

I'm not sure if this trait is gained through education, or mostly innate. Maturation as a critical thinker(and listener) takes a great deal of education.

christophilus2• 5 years ago

I think it goes back much further than that. Humans generally don’t like to hear that they’re wrong. It triggers the fight or flight response. This psychological phenomenon gets triggered easily, with many false alarms.

To someone who likes Walmart, the statement “I prefer Target to Walmart” triggers that part of human psychology, even though it shouldn’t.

You see it everywhere, in every subject, in any time period you choose to observe.

Edit: Charlie Munger understands this well and counteracts it by actively seeking to destroy his own opinions.

miltondts• 5 years ago

"Humans generally don’t like to hear that they’re wrong."

Maybe that binary view is one of the root causes, as being "wrong" is not really a thing in many areas. In fact this has roots in Aristotle's logic. Some years ago, general semantics ("the map is not the territory") tried to offer some push back on that binary view.

Humans do appear to prefer simplifications, with the binary point of view as a possible reflection of that, but we have had some success in evolving our tendencies through education.

Why I Hate Programming Language Advocacy (2000)

Related Stories