Posted
by
Soulskill
on Tuesday November 17, 2015 @11:02PM
from the java-abides dept.

Nerval's Lobster writes: While this month's lists of the top programming languages uniformly put Java in the top spot, that's not the only detail of interest to developers. Which language has gained the most users over the past five years? And which are tottering on the edge of obsolescence? According to PYPL, which pulls its raw data for analysis from Google Trends, Python has grown the most over the past five years—up 5 percent since roughly 2010. Over the same period, PHP also declined by 5 percent. Since PYPL looks at how often language tutorials are searched on Google, its data is a good indicator of how many developers are (or aren't) learning a language, presumably because they see it as valuable to their careers. Just because PYPL shows PHP losing market-share over the long term doesn't mean that language is in danger of imminent collapse; over the past year or so, the PHP community has concentrated on making the language more pleasant to use, whether by improving features such as package management, or boosting overall performance. Plus, PHP is still used on hundreds of millions of websites, according to data from Netcraft. Indeed, if there's any language on these analysts' lists that risks doom, it's Objective-C, the primary language used for programming iOS and Mac OS X apps, and its growing obsolescence is by design.

A real programmer does not care about languages. A real programmer does not attempt to write a kernel in perl. A real programmer does not attempt to write a glue script in C . A real programmer cares more about the optimum solution to the problem than which tools to use .

You can write maintainable and well formated Perl programs if you want to. It all depends on the programmer. So crappy formatted programms are only a matter of a pebkac problem and not the problem of the programming language.

If you had some cluse then you would know that you can write object oriented code with Perl. You either use Perl's internal object orientation model and class out all modules in sub packages with a nice packaging convention: e.g. package My::Cool::P

His statement is true if you consider it to mean that a real programmer does not care about any one language to the exclusion of others.

I was at a Cisco event recently that had a discussion on Application Centric Infrastructure, basically using a master controller to do all kinds of fancy on-demand things to switchports at the access layer depending on factors like authentication of the device or user account. The presenter basically said there are two ways to go about it, the first is to use the somewhat crappy GUI/Web interface, and the second is to write stuff in Python that the controller makes use of. As someone that uses a lot of Bash right now the Python approach is definitely more my style than relying on a web page.

This is the problem with PHP. PHP used to stand for Personal Home Page [wikipedia.org]. That's exactly the level of programming it was originally designed to do. Making simple pages for personal use, maintained by yourself.

Since then, it has grown, but many of the things that make it great for small personal home pages make it quite unweildly for larger projects.

Personally, I don't like PHP or Python. PHP is just terrible for reasons I won't get into here. The only thing that really bothers me about Python is that it use

A real programmer certainly _does_ care. The available modules, version dependencies, and API's can vary tremendously. Even simple features like "regexp" have subtly different syntax with different tools, string parsing and processing functions differ fundamentally in the handling of "end-of-line" characters, and even whether a "true" value is "0" or a positive number can differ profoundly and affect binary logic.

I believe the poster meant to say "...does not care about languages subjectively." as in "tools in a toolbox - pick the right one for the job."

Of course, that statement always has to be bounded by the skillset of the engineers involved (e.g. picking C for a *nix systems application/daemon is a clear choice unless no one on your team knows C.)

A real programmer does not care about languages. A real programmer does not attempt to write a kernel in perl. A real programmer does not attempt to write a glue script in C . A real programmer cares more about the optimum solution to the problem than which tools to use.

Your first sentence contradicts the rest of your statement where you very clearly show that a 'REAL' programmer most certainly does care about the language, which is why he isn't writing glue script in C or a kernel in Perl.

And 'REAL' programmers most certainly do avoid shitty languages, of which PHP is one as is Perl (sorry if you still think leaning toothpicks and a language where everyone writes the same one line operation in a different way is a good thing, but that just makes you stupid;)

Some languages are better than others for certain tasks, and some languages, like PHP, are crap. While there are things that PHP will do better than C++, there's basically nothing that PHP will do better than Python.

Busted. We're writers, not developers, so we wrote our XML processing toolchain with XSLT, Bash, Perl, Ruby, Python, and PHP. We only re-publish about 30,000 pages of documentation in about 20 different end-user formats every single day, so it's not like it's a *real* application or anything...

Actually they do.These modern interpreted languages offer many key benefits over the compiled languages such as C/C++, <whatever>.NET, Java.1. No compiled code: Sucks if you are trying to offer a closed source solution. But often in a business environment having your source as your running code, means decades after you leave you will still have the source available, even after they lost the original project. How many pros had came to a work environment where there was at least one legacy (Usually VB

Which seems highly questionable. Seems to me the methodology of using google search metrics for language popularity works to gauge popularity of a language with enthusiasts but not of actual commercial projects.

If you think Dice has any tangible input into Slashdot you're sadly mistaken. I'm an employee of another subsidiary of Dice and there's pretty much zero crosstalk. We're all pretty much separate companies with no idea what anyone else is doing. Dice is headless. Dice is an ok place to work but Dice is not just about the Dice website nor is it that desperate to draw in people.

Indeed. Lisp variants often rank high in Google searches, but are generally skipped for production applications.

"Hobby" languages can be fun to write in and talk about because you can play with powerful abstractions, but such is not always readable by average developers in the field, limiting their industry selection.

Even if it is accurate, it is irrelevant. It in theory would just show what has the most volume, but for the purposes of someone using Dice unhelpful. Why learn C if you're looking for a web job? Why learn javascript if you are doing device drivers?

When I was a Windows C then C++ then C# developer, I used Google all the time to solve platform issues and find API's that worked with each other. Now I am back to embedded C, and I never ever look for anything on Google. It's C. I look in K&R's ANSI C book when I have questions. All the API's and libraries are use are custom in house. All my docs are in house, it's an embedded C platform. There is a realtime OS but we don't hardly use it for much more than scheduling, all the code is writing to r

They used the term "tutorial", which will by definition give higher scores to languages that were invented while the internet existed.Many active C developers will have learned their skill from tutorials in books.

....except you've pretty much just shown us why Perl isn't gaining any popularity - stuff exactly like that gets written in it a lot, and most programmers would prefer not to have their code look like someone threw up on the screen.

You're not supposed to understand that intermediate-level mess just by looking before having learned a bit of Perl, anyway. Like regular expressions, Perl code was never designed to be self-explanatory.

Maybe if you'd written better Perl then you'd be less tired of reading it? I've shared my Perl story, so I'll spare you AND I'll spare you the snarky response. The question was, indeed, a question. It is even a legitimate question.

See, is the problem Perl or is the problem that you're now older, wiser, and able to look back on your old code and realize how much better the code could have been? What if, say, your old code were written in Python and now you were using C or Java? Would you not, probably, look

I use Perl everyday, and when I was learning I searched for what I recognized in the snippet. So 'perl join', 'perl special variables' and 'perl substitute operator' would've been my queries, because the first things you learn in Perl are to identify basic syntax and to match/substitute text.

Perl code was never meant to be self-explanatory, not any more than regular expressions. You learn a bit of Perl *before* reading Perl code.

Perl does not enforce anything from a structural standpoint. That's the problem - it is a terse language and without structure or enforcement it leads to opaque and unstructured code. Code which can be impossible to maintain. That's why it occupies a niche and that's why it is unlikely to go any further than that.

Counting the number of times tutorials are accessed tells you how many people are learning (or considering learning) a language, not how many are using it now. All this can do is tell you if people expect to need it in the future, because for the most part, if you're currently programming in a particular language, you shouldn't need to be going over tutorials.

No, it only says that you want or need to learn something about PHP. It suggests that you might be planning on using it in the future, but you also might learn enough to find out that it's not what you need.

I have been programming for 20+ years. I *still* look things up all the time. Why? Because I have not memorized the documentation on thousands of API calls or that one bit o language one of my fellow co-workers found and I now have to decipher again.

I learned long ago. Even though I think I may know a function it is best to look up the docs and at least re-read them. For example take the well used C standard printf. I can think of the top of my head at least 5 different quirks with that little bad boy depending on which platform you are on. I program in no less than 3 different ones. So I look it up all the time.

Then as you jump around thru different languages you need to remind yourself on the syntax for *this* one. Is it AND or and or And or && or & in this language. Some langs let you do them all some only one or a subset and they have different meanings.

So even if you are fairly proficient sometimes the languages get muddled together. Take 2 seconds look it up and be done with it.

Assumptions are the cause of more fuckups than I can count. Look it up. Once you have read it a few hundred times I may allow you to assume a few things.

I know C really well so I very rarely look anything up online on it. If I do need to remind myself of an API (and printf is a good example, i can never remember the format specifiers), I'll probably use the man pages installed on my computer rather than going to the Web. The same for any language I use regularly, even Java. I'l download the API documentation onto my laptop so I can still use it when offline.

However, I recently had to write some enhancements for a web site written in classic ASP and, pretty

It could also be an indication of how hard it is to find vital information on a particular language. Search for anything in the Win32 API, and the MSDN will be the top result pretty much every time. Search for anything in the PHP language and php.net will be the top result pretty much every time. Other languages are not even remotely as lucky. I personally find that finding even basics of other languages takes a few Google searches and several posts in various StackOverflow boards to get decent answers.

There are other languages with good documentation. Java is a good example that you didn't mention. You mentioned the Win32 API and MSDN, but didn't mention.Net or any of the languages that use it such as C# or VB.Net.

More to the point above about C at on 7.5%, most software engineers already know C and those that don't aren't going to search the web for a tutorial. There are plenty of well written books on the language that are far beyond anything you would find in an online tutorial. I would assume that also applies for other older language like C++ and Perl.

It doesn't even tell you that. I use Python, but I have never looked at a Python tutorial. The language is simple and the syntax is obvious. But when I was learning Objective-C, I had to go thru 3 tutorials just to understand memory management.

You know, as much as I hear that whine, in 16 years of writing Python I've literally never once been bitten by it. Yes, you hate having to indent your code the way you would naturally have indented it anyway, left to your own devices. Sure, writing at-a-glance understandable clauses is torture. Oh yeah, I too hate formatting my stuff the way my coworkers / teachers / project maintainers / colleagues expect to find it. But as much as I love writing the horrible, unformatted mess that you also enjoy, I just c

I'm asking this seriously: what text editor do you use that you can easily not indent? I use Emacs (and Vim and Sublime Text and Atom) and automatically get thr correct indentation just by writing code like I normally would. If I type if foo: and hit enter, the cursor will be placed correctly for the next thing I type. This isn't Python-specific, either. I get the same behavior when writing C, Go, JS, shell scripts, and so on.

I love dealing with a language that's explicit about what I mean. Consider how inc [imperialviolet.org]

Sometimes you want to test something, then you might need to add an if or so. With braces, you just add it, and you can immediately execute it. With python, you have to get indentation right. And you never know where a block ends, unless you look at the indentation level.

And to GP: the next time you have to write something in python for whatever reason (unfortunately python is almost unavoidable), try kate block mode [kate-editor.org].

And sometimes you actually just want to move some inline code out to a new function to fix the code that wasn't done well in the first place. If the language has problems that stops you from refactoring your code in order to improve the code base, then there are serious problems with the language.

Isn't it kind of a strange metric? It measures people who don't really know the language but want to learn it. But did they learn it in the end? Did they end up using it? Was it actual programmers trying to get into a new language / refreshing one for a new project, or was it complete beginners who heard "python is cool" or something like that and search for a tutorial thinking they will be great programmers?And not all languages have an equal basis in this metric. For example who would search google for a perl tutorial? I mean it doesn't even support regex for christ sake! Also it is well known that Perl either comes as an Epiphany, or you are taught by Monks, you don't read a tutorial...

Python provides no true concurrency due to global interpreter lock. Java is not suitable for realtime due to unpredictable GC, while C/C++ is not suitable for anything which should never crash or return random results due to memory corruption. None of mainstream languages make automatic use of multiple cores and GPU - explicit provisions must be made by programmer to parallelize part of the program, often with error prone semantics and a separate language like OpenCL.

Yes, those are hard problems, but it's also 2015 and we can come up with powerful compilers and JIT virtual machines. Going back to less concurrency than plain old shell scripts where '&' starts a true separate process is not an answer.

Python provides no true concurrency due to global interpreter lock. Java is not suitable for realtime due to unpredictable GC, while C/C++ is not suitable for anything which should never crash or return random results due to memory corruption.

Python has multiprocessing for 'true concurrency' if you need itJava is not actually used for anything real-timeC/C++ can be written safely if you are willing to be careful and unit-test (also managed memory with C++11/14 constructs helps the drudgery) with tools like

Programming languages are tools, and all good tools tend to be suited for just a few tasks. If you are going to hang picture on a wall, you'll probably use a hammer and a nail (well, depending on the waill, of course), because that is the simple and efficient way of doing the job. I doubt anybody would ever seriously contemplate making a supertool, that could hammer nails, drill holes, mix cement, lift bricks up to third floor, place roofing tiles etc etc etc, as well as cook your dinner, do the accounting

None of mainstream languages make automatic use of multiple cores and GPU - explicit provisions must be made by programmer to parallelize part of the program, often with error prone semantics and a separate language like OpenCL.

Automatic parallelization for CPUs has been around for a good while (e.g. Fortran 90), so the parallelization per se should not be a huge issue. You need sensible semantics for these concepts, such as vector types, so the compiler can assume things about parallelism.

Saying Java is not suitable for realtime due to "unpredictable GC" shows you haven't read much on the topic. Many Java open-source projects guarantee millions of operations per second on the right hardware. Java has a huge HFT community footprint.

C/C++ is not suitable for anything which should never crash or return random results due to memory corruption.

Yes, it's 2015 and so it would be appropriate to realize that C and C++ are two totally different languages (where one of those is just capable to seamlessly compile most of the code written for the other).

I know it's a matter of taste, but I understand why Python, aside from simply being popular, is used so often. Having spent time using several languages, I can say that brevity bordering on the obscure (often mistaken for elegance) is not something to encourage. Don't get me wrong, it's great if you can reduce the steps used to implement an algorithm (especially if you get big-O benefits as well), but simply reducing line counts isn't anything to brag about. I mean, who cares if you implemented something in a single line of Perl that took 5 lines of Python for me? Eighteen months later, when the code gets dug up for whatever reason, I know which will be far easier to follow and correct if needed.

That, to me, is the real strength of Python: it enforces readability without requiring too many extra characters (Tcl being representative of the other extreme). If using an interpreted language isn't an issue, it almost always seems like the way to go for my tastes.

I especially agree with your point in today's world where compilers are able to do a decent job optimizing. When that brevity does not buy you anything more than a few saved keystrokes, I tend to focus on writing the most readable yet not overly verbose code. There are ways to do that in PERL just as there are in Python. Sometimes with languages with more exotic features and "more than one way to do everything" it is tempting to be as clever as possible.

I agree... over the past five years or so I've migrated to python, both in web development and a lot of scrips I wrote for use in house for special case "things." It's a great combination of brief (as little as 1/10 or less the size of equivalent Java) and yet structured and readable.

Aside from the top dog Wordpress, the next two popular CMS are Joomla and Drupal. Which also use.... php

It's like that in ecommerce also. The #1 ecommerce software is Magento (php). #2 is Woocommerce (php). #3 is Prestashop (php). #5 and #7 and #8 are also in php. Something like 60 to 70% of all ecommerce sites on the internet are in php. 2015 ecommerce platform rankings [aheadworks.com]

Perl. Perl all the way through, and nothing but Perl. Apparently after they canned the guy who took credit for writing it, they didn't feel it was worth while to put any additional money into the code, ever again (and it seems that attitude has continued through subsequent acquisitions).

they didn't feel it was worth while to put any additional money into the code, ever again

Not true. Just recently they came dangerously close to completely ruining this site with an investment in new code. Thankfully, they backed down.

The truth of the matter is, there is no reason to upgrade the code. In fact, I'd prefer if they reverted to one of the older versions from earlier years that has fewer "Web 2.0" stunts and just serves up the damned text.

"no reason to upgrade the code. In fact, I'd prefer if they reverted to one of the older versions from earlier years that has fewer "Web 2.0" stunts and just serves up the damned text."

Here are som reasons to upgrade:

* support unicode,* get workable access to preferences (if you enable "classic mode?, all kind of stuff breaks, including getting back to default D2 mode.).* Get a decent mobile view (Can't access it when logged in and it's unworkable anyway on my quad-core, 2 GB RAM phone). That's why I mainta

I think the text-centric nature of slashdot is a big plus. I wouldn't want it to turn into yet another web forum with inline images, huge sigs, animated smileys, and people writing like 14-year-olds.
When I have a keyboard, I don't mind the html markup either. But on a phone, it's a pain.

Python has been suffering from module dependencies lately, where the "pip install" tool for installing 3rd-party modules deploys a rats' nest of potentially incompatible latest releases of all the dependencies from python.pi.org. This is similar to what happened with CPAN over time, except that CPAN for perl was much, much worse about individual modules introducing incompatible upgrades, and other modules being long unmaintained so they would never b

The problem with the mod_perl update was one of naming and numbering. The version that supported httpd, sometimes called "Apache 2", was _among_ the mod_perl 1.9xxx releases, and it was very difficult to tell which "1.9xxx" release was compatible with what. Older perl modules that were only compatible with the older releases had to all be updated to require a release _less than_ 1.9xxx, or they would break when installed with "cpan install". And if you

Because of the duck typing maintaining, extending and refactoring any non-trivial Python project is a fubar. Make a typo in the variable name and catch this bug 2 months later in the production deployment. Thank you very much, but no unit tests from the whole world will cover this.

Because of the GIL it doesn't scale across the modern hardware so it forces programmer into process-level parallelism and 3rd-party http server with wsgi crap which gives deployment and maintenance headaches.

Index is created by analyzing how often language tutorials are searched on Google

And how should this be related to rise and fall of a programming language popularity?
I would instead say that it shows how hard a programming language is to be learnt or mastered.
This study is completely flawed and aimed to religion wars among programmers!Every one actually knows that C is the king of all languages, you insensitive statistical clod!

I have learnt python this September to teach it to 16 year olds. It is extremely easy to pick up as a language and some of the libraries are very useful and efficient. Loading a text file in one line kind of thing seems easy to learn for kids. I'm disappointed by the lack of an easy GUI, tkinter just seems awful after the simplicity of initial python for kids. I'd much prefer a more visual studio type approach to python, with an easy to drag and drop set of GUI elements, but then again, I teach python in a