Ruby use is up 40 per cent amongst North American software developers since 2008, according to a new study from Evans Data. Despite the jump in popularity, Ruby still occupies a relatively small niche in the developer community as a whole, the company says. Only 14 per cent of developers polled in North America use Ruby at least …
Not great stats
10% of 400 respondents is ~40 developers used Ruby at least some of the time last year. Now there are 40% more; i.e. 56 developers. Is an increase of 16 respondents in the sampled population of developers statistical significant?
Without looking at the base data properly, it could just be that within the 400 respondents, perhaps 100 change language as projects come and go in any given year, meaning that this is just a blip one way or another.
Oh.. and "commercial SQL databases are [tow] and a half times more likely to be used as a primary database than open source SQL databases"? I find that a little strange as most commercial database vendors also offer free versions; so I would suspect that many developers (such as myself) use open-source RDB' like MySQL for many small projects, but might still consider a commercial SQL database like Oracle or MSSQL as a 'primary' for larger production sites.
Never seen Ruby in the workplace. Python on the other hand...
I've never worked in a place that used Ruby, but I have had the good fortune to have worked at several places where Python's been used, and I have to say that I absolutely love programming with it. The most recent of these places used it for web development with the Django framework which I understand compares very favourably with Ruby on Rails.
@ nick 58
I've not used modern Python recently (it's on my "must do" list) but I've been using Ruby for a while, both within Rails and standalone, and it is a really pleasant language to develop in. It's a little different from many others, it is *very* object oriented, taking much from SmallTalk and Objective-C (although thankfully not the hideous syntax).
I've also heard lots of good things about the current Python from friends.
Interestingly, they are both taking good ideas from each other, it's been a good example of competition spurring innovation. However, it's been spurring efforts to make the languages "nicer" and "cleaner" rather than try and shoe-horn features in.
I experimented with Python about 7 years ago, but I found some of it deeply hacky (syntactically speaking), however I believe things are much better now. I was very impressed that the Python guys were willing to dump backwards compatibility in version 3 rather than go down the Perl route and turn it into a giant ugly ball of muck (I code in Perl mostly).
This survey on the other hand is meaningless.
What language would you choose if there were no baggage ?
e.g. what would you choose to teach a teenager ?
When I was a teenager, there was BASIC and a bit of assembly (via POKE statements).
Universities seem to have opted for Java as the primary development language for Computer Science courses.
Smalltalk beats most languages because the syntax looks nothing like C and there is so little syntax to remember and type in. It also beats most languages because it avoids the out dated and inflexible currency of source files, instead using the flexible and powerful concept of in-memory images which can be usefully snapshotted at any point in time.
Smalltalk is an enabler. It doesn’t get in the way of writing code by overloading you with syntax and masses of typing. Anything you type in Smalltalk does something rather than just being there to pacify the compiler. It also beats all other languages by encouraging the development of code during a live debugging session. You never have to stop, edit, compile and re-run because everything is done in a live image. The sheer productivity of Smalltalk is amazing in comparison to other languages.
As a Smalltalker by profession, having come from a C/C++/Java background, I can honestly say I would never like to go back to any other language full time, they are all so primitive by comparison. Unfortunately I still have to C++ quite a bit for interfacing with other tools.
I will be teaching my little boy Smalltalk when he's old enough. Get him into good habits at the start.
See http://www.whysmalltalk.com/ and to get your hands on a great Smalltalk for free, get yourself a copy of Dolphin Community Edition from http://www.object-arts.com/content/navigation/products/dce.html.
BTW I am nothing to do with OA but I am a big fan of Dolphin Smalltalk. Even to the extent of buying my own copy of Dolphin Professional Edition.
Not sure I would teach a language, as such. What is a programming language, after all? Local syntax 'for if...then... else', 'do...while', and so on? It is core concepts, that are needed.
I work for a company that has done a lot of acquisitions, over the years, and as such my working week can take me from COBOL, through .NET languages, to PHP, Python or Perl. I can point to truely appaling examples of bad coding in all of those languages (with some of the more recent ones - with the best object-oriented support - being the greatest culprits).
But all of that wrapping is only a means of getting other stuff done: pushing data into and out of databases or files, evaluating connections, sending bytes down encrypted tunnels, perfoming scheduled work, and testing regular expressions. These are the areas younger programmers are often weakest in. You could write a piece of Perl to wrap around a bunch of queries, a n XSLT transformation and a few regexes and get the same work done, as if you'd written it in C# or whatever. But without the queries, the transformation and the regexes, all that other code is just so many loops and conditionals, regardless of the language.
Good languages only abstract you from themselves: they cannot abstract you from the work that is being done, and there's no point abstracting yourself from a badly-written SQL query, an inefficient Regular Expression, a poorly worked-out XSLT transformation. While companies continue to write (or acquire) so many roll-your-own approaches to data, then it's these things that offer greatest efficiency potential, and are the greatest asset in an employee. The stuff that loops around the outside of it is fairly incidental, in my experience.