9 ms·

Why I Hate Programming Language Advocacy (2000)

63 points by smasher164 5y ago

mikewarot 5y 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 5y ago
  Groovy maybe?
- jakobnissen 5y 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 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.
  - deleted 5y ago
    [deleted]
- BlackFly 5y 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.
  - xupybd 5y 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.
    - dgb23 5y ago
      All of those limitations can add complexity, specifically when they are not a good fit and you need to either work around them or break their rules. There are plenty of examples where immutability is not the right fit (or even possible) or when static types are not helpful but just increase verbosity (and complexity). They might be good defaults (especially immutability if you can afford it) but not strictly the best way to reduce complexity in every circumstance.
    - mikewarot 5y ago
      All programs have a global state. Forcing that state onto the stack doesn't always make things simpler.
  - cheph 5y 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.
    - rocqua 5y ago
      > Golang maintainers are overly defensive about serious deficiencies in an otherwise mediocre programming language. It seems to me like a sentence like this is exactly what the article was arguing against.
- otabdeveloper4 5y 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.
  - mikewarot 5y 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.
- foxes 5y 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.
  - dgb23 5y 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.
    - foxes 5y ago
      I would be interested in you giving an example of a problem that is not solvable or expressible in a typed language. I am not able to think of such a thing of the top of my head. I disagree that performance is a big advantage. Perhaps there are certain optimisations that can be done if you have added more constraints? But that seems like an added benefit. I feel like there are a plethora of examples of type errors however. Obviously it doesn't rule out logical errors, but at least at the type level its "correct". You can even lift problems to just be type problems. For example only being able to construct inputs as something in the type system. Seems like that rules out a whole class of possible errors with parsing input.
      - dgb23 5y ago
        > I would be interested in you giving an example of a problem that is not solvable or expressible in a typed language. I meant to say that some of many solutions can better, typically simpler, while being just as correct because you don't need to express it in static types. > Obviously it doesn't rule out logical errors, but at least at the type level its "correct". You can even lift problems to just be type problems. For example only being able to construct inputs as something in the type system. That is orthogonal to a type system though. If you take care of the invariants of a data-structure you are almost always going to need more than what most type systems can express. In fact I would argue that type systems provide immediate documentation of very basic properties, which is often an advantage, but from my experience the errors it covers for you are rare, yet can be severe and confusing. Again, having used both I'm not entirely happy with either. I prefer when static, or more generally developer-time-checks are opt-in and expressive, which seems to be a growing trend.
lmm 5y 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.
- mjburgess 5y 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.
  - lmm 5y 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.
    - mjburgess 5y ago
      I'm thinking of * Piggybacking: Scala/Spark, Typescript/Node, Exlir/OTP, ... * Features: Rust/Saftey, Go/IO, ... * Backers: Go/Google, Kotlin/Google, ... TS/Microsoft, ... You're right that tooling is more important than the intrinsic properties of the language grammer & operational semantics... However I dont think the stories of the above langs have been a story of tooling; in almost every case, quite the reverse.
kstenerud 5y 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 5y 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 5y 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 5y 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 5y 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 5y 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 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 5y 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.pdf http://lamport.azurewebsites.net/pubs/deroever-festschrift.p... [2]: http://lamport.azurewebsites.net/pubs/lamport-verification.pdf http://lamport.azurewebsites.net/pubs/lamport-verification.p...
xupybd 5y 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 5y 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 5y 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 5y 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.
papito 5y 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.
- tester34 5y 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
  - papito 5y 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.
    - tester34 5y ago
      >I will bet that a Linux kernel maintainer is a more capable coder than someone stitching together web apps with Rails. but who's coder? in my opinion definitely Linux kernel maintainer will be better at topics oriented around OSes, low level, hardware, "system" programming, debugging but I doubt he'll be also better at web development, fancy software engineering patterns/architectures (sagas, blabla), microservices, distributed apps, web security I feel like those use different skills / kinds of knowledge. Try using 'goto' around Java/C# people and you'll be considered as a witch, meanwhile I guess it's relatively not rare in Kernel development
    - dagw 5y ago
      I will bet that a Linux kernel maintainer is a more capable coder than someone stitching together web apps with Rails. Unless you actually need a web app. In which case the "Rails guy" will deliver in a couple of days something the kernel maintainer might struggle with for a couple of weeks. Of course given 3-4 month the kernel maintainer could no doubt become a very proficient Rail developer if they felt incentivized to do so. Your average Rails developer probably won't be able to become a proficient kernel hacker in 3-4 month.
mybrid 5y 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.
- dgb23 5y 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.
  - mybrid 5y 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 5y 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 5y 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 5y 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.
- christophilus 5y 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.

63 points by smasher164 5y 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 5y ago
Groovy maybe?
jakobnissen 5y 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 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.
- deleted 5y ago
  [deleted]
BlackFly 5y 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.
- xupybd 5y 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.
  - dgb23 5y ago
    All of those limitations can add complexity, specifically when they are not a good fit and you need to either work around them or break their rules. There are plenty of examples where immutability is not the right fit (or even possible) or when static types are not helpful but just increase verbosity (and complexity). They might be good defaults (especially immutability if you can afford it) but not strictly the best way to reduce complexity in every circumstance.
  - mikewarot 5y ago
    All programs have a global state. Forcing that state onto the stack doesn't always make things simpler.
- cheph 5y 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.
  - rocqua 5y ago
    > Golang maintainers are overly defensive about serious deficiencies in an otherwise mediocre programming language. It seems to me like a sentence like this is exactly what the article was arguing against.
otabdeveloper4 5y 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.
- mikewarot 5y 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.
foxes 5y 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.
- dgb23 5y 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.
  - foxes 5y ago
    I would be interested in you giving an example of a problem that is not solvable or expressible in a typed language. I am not able to think of such a thing of the top of my head. I disagree that performance is a big advantage. Perhaps there are certain optimisations that can be done if you have added more constraints? But that seems like an added benefit. I feel like there are a plethora of examples of type errors however. Obviously it doesn't rule out logical errors, but at least at the type level its "correct". You can even lift problems to just be type problems. For example only being able to construct inputs as something in the type system. Seems like that rules out a whole class of possible errors with parsing input.
    - dgb23 5y ago
      > I would be interested in you giving an example of a problem that is not solvable or expressible in a typed language. I meant to say that some of many solutions can better, typically simpler, while being just as correct because you don't need to express it in static types. > Obviously it doesn't rule out logical errors, but at least at the type level its "correct". You can even lift problems to just be type problems. For example only being able to construct inputs as something in the type system. That is orthogonal to a type system though. If you take care of the invariants of a data-structure you are almost always going to need more than what most type systems can express. In fact I would argue that type systems provide immediate documentation of very basic properties, which is often an advantage, but from my experience the errors it covers for you are rare, yet can be severe and confusing. Again, having used both I'm not entirely happy with either. I prefer when static, or more generally developer-time-checks are opt-in and expressive, which seems to be a growing trend.

lmm 5y 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.

mjburgess 5y 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.
- lmm 5y 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.
  - mjburgess 5y ago
    I'm thinking of * Piggybacking: Scala/Spark, Typescript/Node, Exlir/OTP, ... * Features: Rust/Saftey, Go/IO, ... * Backers: Go/Google, Kotlin/Google, ... TS/Microsoft, ... You're right that tooling is more important than the intrinsic properties of the language grammer & operational semantics... However I dont think the stories of the above langs have been a story of tooling; in almost every case, quite the reverse.

kstenerud 5y 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 5y 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 5y 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 5y 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 5y 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 5y 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 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 5y 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.pdf http://lamport.azurewebsites.net/pubs/deroever-festschrift.p... [2]: http://lamport.azurewebsites.net/pubs/lamport-verification.pdf http://lamport.azurewebsites.net/pubs/lamport-verification.p...

xupybd 5y 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 5y 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 5y 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 5y 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.

papito 5y 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.

tester34 5y 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
- papito 5y 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.
  - tester34 5y ago
    >I will bet that a Linux kernel maintainer is a more capable coder than someone stitching together web apps with Rails. but who's coder? in my opinion definitely Linux kernel maintainer will be better at topics oriented around OSes, low level, hardware, "system" programming, debugging but I doubt he'll be also better at web development, fancy software engineering patterns/architectures (sagas, blabla), microservices, distributed apps, web security I feel like those use different skills / kinds of knowledge. Try using 'goto' around Java/C# people and you'll be considered as a witch, meanwhile I guess it's relatively not rare in Kernel development
  - dagw 5y ago
    I will bet that a Linux kernel maintainer is a more capable coder than someone stitching together web apps with Rails. Unless you actually need a web app. In which case the "Rails guy" will deliver in a couple of days something the kernel maintainer might struggle with for a couple of weeks. Of course given 3-4 month the kernel maintainer could no doubt become a very proficient Rail developer if they felt incentivized to do so. Your average Rails developer probably won't be able to become a proficient kernel hacker in 3-4 month.

mybrid 5y 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.

dgb23 5y 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.
- mybrid 5y 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 5y 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 5y 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 5y 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.
christophilus 5y 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.