The TIOBE Programming Community Index has it wrong : C# is the language of the year, not Objective-C. Indeed, according to the PYPL index, C# had the biggest growth in popularity this year : +2.3 %. Over a 5-year period, Python is the language whose popularity is growing the fastest; it is already the second most popular in the US.[s]

The PYPL PopularitY of Programming Language index is created by analyzing how often language tutorials are searched on Google : the more a specific language tutorial is searched, the more popular the language is assumed to be. It is a leading indicator. The raw data comes from Google Trends, so that anyone can verify it, or make the analysis for his own country.

If you believe in collective wisdom, the PyPL Popularity of Language index can be used to decide which language to study, or which one to use in a new software project. Click on a language in the table below to perform your own popularity analysis for your country.

It strikes me that the number of times tutorials are sought out via Google may be indicating something other than "popularity". It seems more likely that an enormous number of Google searches for a language tutorial may be an indication of 1) how difficult the language is to master i.e. those using it are having to refer to tutorials far more frequently than more intuitive languages and/or 2) how few learning resources exist for the language.

I mean, developers may not be doing Google searches on say VB.NET tutorials because Microsoft makes it so easy to find resources.

it makes sense to choose a language for each situation based on what fits best with the requirements, needs, people, resources and objectives of situation. "Popularity" is a subjective term that is largely meaningless in a discussion of language-use metrics.

Sorry, if this is not the right place to post this, but I thought I'd re-post to see if you had any comments or websites I could visit to help.

====

@ Brian Keller This might not be the right place for this but I thought I would post this here as well as on Robert Greene's show.

I'm a longtime follower and have enjoyed your programs for a while now; keep up the good work.

I have a problem I'm going to post here. I'm trying hard to make the Test Driven Design approach. I use VS2012 all day every day but I only use 30% - 40% of the stuff that I know is there. It's also hard to gain traction in the organization with no other subject matter experts.

I would like to use 80-90% of VS but it's not currently possible without knowing the best practices.

What I mean by 80%-90% is

a) Identify all of my problems / items that are needed to produce a piece of software

b) Create the items in TFS as Requirements / work items / Bugs

c) Create a project inside TFS

d) Tie the software to the Requirements

e) Complete iteration 1 using Kanban board

f) Be able to use Test Cases / Unit Tests

g) Be able to use the Test Manager

My problem is such, I can get started on most if not all of these, but I don't have a series of videos that I can watch for 1 or 2 days take about 3 to 4 hours to familiarize my self with how to tie them all to gether as a ONE MAN shop and complete 1 or 2 projects, so that I can become the subject mater expert and then start implementing this across multiple teams.

Is there a series out there that will point me in the right direction or can you can give me on this or website references?

Secerely,

I have all of the pieces but I'm having trouble bringing it all together.

Sorry I'm not aware of a single resource to get everything you're asking for in an end-to-end fashion. I've written a couple of books and have some others listed on the right side of my blog which might help: http://blogs.msdn.com/briankel

But again these are really focused at each individual tool and less on one comprehensive process. The problem with trying to write and maintain the latter is that many different shops have their own unique way of doing things so trying to invest in writing about one specific pattern would be of narrow interest and possibly discouraging to others who look at it and realize it doesn't match with the way they want to use the tools. Instead in my speeches and books I try to focus more on how the tools work and how they can be adapted based on the needs of the team/person/situation.

Remove this comment

Remove this thread

Comments Closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation,
please create a new thread in our Forums, or
Contact Us and let us know.