Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Businesses Programming The Almighty Buck Technology

Coders In Wealthy and Developing Countries Lean on Different Programming Languages (vice.com) 92

Stack Overflow data scientist David Robinson published an interesting observation: There exists a small but meaningful divide between the programming technologies used in wealthy countries and those used in developing countries. From a report: To be sure, programmers everywhere tend to build things with the same tools, which makes sense because software is a global industry. The first is in data science, which tends to employ the programming languages Python and R. "Python is visited about twice as often in high-income countries as in the rest of the world, and R about three times as much," Robinson writes. "We might also notice that among the smaller tags, many of the greatest shifts are in scientific Python and R packages such as pandas, numpy, matplotlib and ggplot2. This suggests that part of the income gap in these two languages may be due to their role in science and academic research. It makes sense these would be more common in wealthier industrialized nations, where scientific research makes up a larger portion of the economy and programmers are more likely to have advanced degrees." C and C++ use is similarly skewed toward wealthy countries. This is likely for a similar reason. These are languages that are pushed in American universities. They also tend to be used in highly specialized/advanced programming fields like embedded software and firmware development where you're more likely to find engineers with advanced degrees.
This discussion has been archived. No new comments can be posted.

Coders In Wealthy and Developing Countries Lean on Different Programming Languages

Comments Filter:
  • C and C++ are used more in the U.S. because at one point in time, the U.S. was the only country using those languages. It took other nations to catch up with our IT industry, and when they did they chose more modern languages (I suspect Java and C# are the most popular), while in the U.S. many places were stuck with C and C++.
    • I agree, I believe the simple explanation for this is that the developed countries have been working at software development for a longer period of time. The older programmers in the developed countries use a different set of programming languages. I do not see this as wealth related, it is historical.

    • C and C++ are used more in the U.S. because at one point in time, the U.S. was the only country using those languages. It took other nations to catch up with our IT industry, and when they did they chose more modern languages (I suspect Java and C# are the most popular), while in the U.S. many places were stuck with C and C++.

      that may be(i really don't know, and i haven't seen any computing history book that make those claims).

      but in my humble opinion, ones gets a more fundamental understanding of computer programming and computers by studying c and c++ (or just c actually) than java or any other "modern languages", that are "easier", abstract, and yes, more useful, in some situations .

      if one want to understand, and not just use, one should study c. perhaps assembly too.
      if one's mindset it geared for breaking things apart and p

    • I feel it is more popular vs niche than less or more advanced.

      The market for web development is the biggest one in the world out of all development practices. No wonder that "CMS website in under 1 week" type of outsourcing sweatshops are present all across the world

    • Re:Catching UP (Score:5, Insightful)

      by Dutch Gun ( 899105 ) on Wednesday August 30, 2017 @05:36PM (#55113109)

      The argument for industry-specific biases has some merit, though.

      For instance, C++ is nearly universally used in the game development industry, which is largely centered in the US, Japan, Europe, and various other relatively wealthy countries/regions. C++ is not used only because of historical reasons (although it's partly that, of course). It also has to do with the qualities of the language itself. Game developers require a language with a balance of performance, abstraction / modeling, general ubiquity, and portability. To date, there's *still* no other language that meets all these criteria as well. While there's no denying the influence of legacy's influence on future development, I think it's also inaccurate to depict this as "being stuck with C/C++".

      It's always surprising to me how many people seem to fail to appreciate the fact that different languages have fundamentally different qualities beyond just their syntax, or that the qualities *they* happen to value in a language may not be universally important across all domains. This is the reason that all those articles talking about which programming language is "best" or "most popular" are completely worthless. It's only of use when asking "what is the best language for solving this particular problem, given these specific conditions", and even then, there will still be some subjective opinion thrown into the mix.

      So, kudos to the article for at least providing us with a bit more depth than a simple popularity list of languages.

      • Re:Catching UP (Score:4, Insightful)

        by Xest ( 935314 ) on Thursday August 31, 2017 @03:14AM (#55114947)

        Actually I see a different pattern in the data- it sounds like the languages being used more in Western countries are languages that are used to solve hard problems.

        That does include core game engine development, but it also includes advanced analytics, machine learning and so forth where languages like R and Python are the defacto standards nowadays.

        We often hear about how countries such as India can churn out a thousand first class graduates from their universities for every one mediocre graduate in the West and other such nonsense, but the reality is that of the top 500 universities in the world, the vast majority are in the West. So for example, India doesn't have a single university in the top 100, and in fact, it's first entrant in the top 500 is the University of Delhi as the 316th university in the world and only 4 in total in the top 500.

        There's a reason why the West is so dominant in the services industries and it's precisely because we have the education systems needed to stay ahead in solving difficult problems - it doesn't matter how many graduates countries like India can churn out in sheer volume alone if their best University is the 316th in the world. Compare and contrast to say, the UK, which has only 0.86% of the world's population but 9% of the top 100 universities. India has 17.6% of the world's population with 0% of the world's top 100 universities.

        China is really the only nation that is on the right path to catch the West, but that's because they've spent the last 30 years doing the hard stuff - building infrastructure, skills, and education, but I'd warn that their political system will inevitably become a constraint on ever being able to completely reach parity with the West as the more educated a population becomes, the more liberal they become - that's at complete odds with China's political system.

        The fundamental problem therefore is that many "tech hubs" in poorer nations are largely selling snake oil, the idea that they can always produce the same thing is cheaper, they simply don't have the skills, the talent, and the R&D centres to do so for more complicated tasks, and that's why the West shines in these areas, and that's why languages related to difficult problems are more prominent in the West.

        But a word of warning, there's been a marked trend in the West in recent years against education, against experts, and against knowledge and science, this puts our advantage in these areas fundamentally at risk if it persists, if we want to continue being world leaders in areas such as this, then we have to fight back this wave of populism, and worship of ignorance, else it will leave all that hard earned talent, knowledge, and that research culture ripe for poaching by others who are willing to nurture it more than we have been. Brexit for example puts Britain's top universities at fundamental risk as they can no longer easily draw in the global talent required to make those universities as successful as they are, and if you lose that R&D edge that universities provide then you're just another India - sure you can do GUIs cheap, but you ain't going to be a serious contender as global tech leader doing cutting edge work which is where the money is (i.e. Silicon Valley for tech, the City of London for finance etc.).

    • by Tablizer ( 95088 )

      You should know saying "stuck with" will trigger a language flame-war. (Personally I believe such languages shine in different spots and it's almost comparing apples to oranges.)

  • by Anonymous Coward

    If you are applying for a job and you want less competition from Pajeets and women, study C or C++.

  • I've read that Java was designed to be usable by 'mediocre' programmers. I take it the idea was you could hire people who weren't master programmers and get something working that didn't have a lot of subtle bugs like memory leaks that were going to come back and haunt you later. Also it was supposed to be very portable. I never used Java so I don't know how well it met those goals, but I can see how they would be desirable from a management point of view but not so much from a pure computer scientist's

    • by Archtech ( 159117 ) on Wednesday August 30, 2017 @04:04PM (#55112597)

      The ideal language would probably have to find a balance between various requirements.

      That is exactly what thousands of researchers have been trying to accomplish, designing literally hundreds (if not thousands) of languages in the past 60 or so years.

      But it's not a reasonable goal.

      Falling back on the hackneyed but serviceable "transport" analogy, if you want a cheap, simple conveyance that can easily be operated by a single person, a bicycle is good. Want more power and speed, at the cost of greater weight and cost? Try a motorcycle. If you need to fly, you'll need - at least - a microlight, although a helicopter has its advantages. Want to cross water? Submerge? Resist armour-piercing shot? Carry 50 passengers or 20 tons of freight? Look great and attract new friends?

      I hope you get my drift. There is no "one size fits all", and there can't be. Languages like C let you get down to the bare metal (or as close as you want to), but you have to do a lot of extra work. High-level languages let you program much faster, but may not run as fast, or may limit what you can do in ways you find unduly restrictive.

      From time to time a "local winner" emerges. I don't think anything better than Cobol has ever been created for run-of-the-mill business applications. Come to that, Fortran is still excellent for mathematics, unless you want to give APL a spin. And you'll find, if you look into it, that most avionics nowadays is written in Ada - and I'm very glad of it.

      And then there are the pioneers...

      "The more I ponder the principles of language design, and the techniques that put them into practice, the more is my amazement at and admiration of ALGOL 60. Here is a language so far ahead of its time that it was not only an improvement on its predecessors but also on nearly all its successors".

      - C.A.R. Hoare, "Hints on Programming Language Design", 1973

      • I was typing up a reply very similar to yours, even including the same vehicle-based analogy. Then I looked down and saw your post. So instead I'll just say "yes, this".

        A language that tries to be all things will always lose out to specialist languages designed for a very specific use case. There is some merit in selecting from among a handful of well known languages, simply for the ease of learning and collaboration, but beyond a specific point, too much language consolidation would actively harm specif

    • by AuMatar ( 183847 )

      Haskell is a language where once you get your program to run at all it usually runs correctly.

      That's a dangerous way to even think. Very few bugs are actually programming mistakes- the vast majority, and the harder to fix are design mistakes. Just because it compiles doesn't mean its anywhere close to right.

      • by Anonymous Coward

        Probably true for larger projects at this level of generality, but I have to mention that some small Ada projects I wrote were 100% working and no bugs were found later after I got them to compile. Before you disagree prematurely, you have to write at least a few small or medium-sized projects in Ada, it really is amazing. This won't save you any time, though, because the time spent on debugging in other languages you spend fighting the compiler in Ada.

        • Ada didn't save Ariane 5. If it could have saved Ariane 5 it would have been deemed a theorem prover, not a programming language. Solving things at compile time unfortunately doesn't scale to propositions in large programs.
      • by swillden ( 191260 ) <shawn-ds@willden.org> on Wednesday August 30, 2017 @04:49PM (#55112873) Journal

        Haskell is a language where once you get your program to run at all it usually runs correctly.

        That's a dangerous way to even think. Very few bugs are actually programming mistakes- the vast majority, and the harder to fix are design mistakes. Just because it compiles doesn't mean its anywhere close to right.

        You haven't used Haskell, I see.

        Oh, it's not a panacea by any means. But the nature of the language and its very strict typing really forces you to clarify lots of aspects of your design that you might not think nearly hard enough about in other languages. By the time you get your code to compile it's significantly closer to correct than other languages. Moreover the inherent lack of side effects in functional programming makes writing automated tests of Haskell code a breeze... so if you assume that getting your program to run also includes getting a good suite of automated tests to pass (as it should!), then you really can have pretty high confidence that the code does what you think it does.

        Of course, what you think it does may not be what it should do. No programming language can do anything to find bugs in the requirements.

        The AC who replied to you makes the same claim about Ada, where it is also true. But it's even more true of Haskell than Ada, IMO. I should mention that I've used both languages only on small projects. Ada has proven to scale well, though, and I suspect Haskell would as well, if you could find enough Haskell programmers to staff a large project.

        • Exactly! For those who want to dig deeper, the keyword is "typeful programming". I.e. where one uses a sophisticated type system with type checking, to encode and reason about many of the properties/requirements of ones programme.

          For those programmers who haven't been exposed to it, explaining what it is, is a little like trying to explain the ocean to someone who grew up in the desert. It's a mistake to dismiss it with a: "Sounds like just a lot of water to me". Instead, I encourage getting ones feet wet.

      • Haskell is a language where once you get your program to run at all it usually runs correctly.

        That's a dangerous way to even think. Very few bugs are actually programming mistakes- the vast majority, and the harder to fix are design mistakes. Just because it compiles doesn't mean its anywhere close to right.

        The vast majority of programming and logical mistakes can be represented as syntactical errors by coding standards and types in such a way that makes detectable by a compiler. Consider the old C/C++ safety habit of putting rvalues on the left side of an equality operator: it allows the compiler to catch the programming error of using '=' instead of '=='.

        Higher level languages take such approaches and formalize them into types. Haskell goes all the way out so that syntactical correctness closely implies lo

        • by AuMatar ( 183847 )

          Yeah- you're talking about things that are 1 error in 20. If that. The fact that you actually believe the bullshit you're spouting scares the shit out of me- I truly hope I don't use anything you've ever worked on.

          • Yeah- you're talking about things that are 1 error in 20. If that. The fact that you actually believe the bullshit you're spouting scares the shit out of me- I truly hope I don't use anything you've ever worked on.

            You actually might. But with an absolutist, dogmatic answer such as yours, let's pretend that you are right and that somehow you have hurt my feelings or whatever the fucks that tickles your intellectual fancy.

    • by dargaud ( 518470 )

      One metric that I find appealing is, what language requires the least amount of lines of code. Bugs are often related to lines of code, also, if you're maintaining code, the fewer lines to look at the better. But I can see how a language designed just to be terse could be difficult. (APL anyone?)

      One just need to look at perl one-liner contests to know that this is way wrong.

      • Re: (Score:3, Insightful)

        One metric that I find appealing is, what language requires the least amount of lines of code. Bugs are often related to lines of code, also, if you're maintaining code, the fewer lines to look at the better.

        One just need to look at perl one-liner contests to know that this is way wrong.

        Indeed - but perhaps not for the reason you think. It's not just number of lines of code - it's number of semantic units the programmer has to digest.

        Perl achieves brevity by cramming lots of arcane symbols on one l

    • I think the major unsolved problem of programming languages is: how do you organize the code? OOP is a good attempt, but doesn't quite get there.

      Another unsolved problem is, "How do you prove the code correct?" but that might not be solvable.
    • Re: (Score:3, Interesting)

      by Tablizer ( 95088 )

      I've read that Java was designed to be usable by 'mediocre' programmers. I take it the idea was you could hire people who weren't master programmers and get something working that didn't have a lot of subtle bugs like memory leaks that were going to come back and haunt you later.

      "Mediocre" is a matter of perspective. A Java programmer is more likely to be a generalist and do some degree of analysis work, such as gathering and clarifying requirements with customers.

      C/C++ is used more often where hardware res

  • People in wealthy countries are the ones that are developing the new languages.

    • by tomhath ( 637240 )
      The reason is that students in India and China are being taught Java. That was a great language for offshoring and H2-Bs a few years ago.
  • by 140Mandak262Jamuna ( 970587 ) on Wednesday August 30, 2017 @04:17PM (#55112671) Journal
    They should have taken some other thing that is correlated to affluence. May be per capita meat consumption or access to healthcare. Then they could have come up with even more dramatic headline, "Meat eaters hack in C++ while the lotus eaters struggle with R". "Coders who get annual physical program in C++, while hackers might be sick stick with R".
  • If you are really looking for an "Ideal language", maybe you should pay attention on what's going on in the "old" languages instead of focusing on new ones. Fortran, COBOL, Pascal and others, even C++ itself are all evolving, taking concepts from one another. I would dare to say they are slowly converging, though they will never become one.

    This trend should give you some good clues on what's really good to have in an "ideal" language. If a professional developer community take the task to adjourn their alre

    • I still facepalm for C++ not having a native string type

      Did something happen to std::string while I wasn't looking? Or isn't it native enough for you if it lives in the standard library? What benefits do you believe would have been available if std::string had been part of the compiler instead?

      • The STL is not part of C++. Was added later, rather quickly, when became clear to developers what C++ should have been. Still it was buggy and pretty non-orthogonal, i.e. not every algorithm-container combinations were good and sometimes you were better (or forced to) calling specialized member versions. Things are better today, but STL isn't really fixed yet anyway.

        As a result, today in C++ we work with Cstrings, QTstrings, Ansistrings, UnicodeStrings, WhateverFrameworkStrings... anything but std::strings,

  • Seems a bit odd, I am in the US and do most everything using Bash, PHP and Python with a little XCode/Swift mixed in.

    Also wonder why wealthier countries since PHP and Python have no Subscription/Buy It overhead.

    That is why I stopped doing Windows/Visual Studio work years ago. And yes I do know they let Visual Studio go but have not had the desire to check it out again.
  • The best language, methodology, algorithm, compiler, toolchain, and design pattern is the one you *know*. I swear, there is more "gimme a shortcut to a $$$ job in IT" than I've ever seen (even in bodybuilding people don't lie as egregiously). People always want to find a shortcut. The truth is that the worthy pursuits that build your earning potential and coder-cred require mucho effort. Generally speaking, the folks with the most enthusiasm win because that gives them the most sticking power when they enco
    • by Mr.CRC ( 2330444 )

      The best language, methodology, algorithm, compiler, toolchain, and design pattern is the one you *know*.

      To an extent.

      I made a very careful decision a few years ago to choose to learn Python to compliment my use of C, because I knew that I would soon need to write some programs to accomplish functionality which would be exceedingly tedious in C. But I could certainly have done it in C.

      Python was so easy to get started with it blew my freaking mind. It blew even more when some aspects of the programs I

Never test for an error condition you don't know how to handle. -- Steinbach

Working...