Skip to main content

3 1/2 out of 10 Languages You Should Learn Right Now

Yes, I do believe a good developer has to know more than a handful of languages. Ten sure is an arbitrary number to pick, but whatever!


Read the list, I don't want to recap it.

Of the ten languages listed, I don't find three and a half of them compelling choices.
  • C#
  • Python
  • JavaScript
  • AJAX (this is the half)
Some people might find that an odd list. If you know a little about any of the languages, you might find it even odder. If you know a lot about the languages, you'll have no trouble agreeing, I feel confident.

C# is largely what Java should have been. Python is, of course, a fantastic language for most purposes. JavaScript is essential for web work, and web work is essential for getting the rent paid, these days. AJAX, much the same.

C# and JavaScript get some crap from the OSS communities. People look down their noses at C#, having such a distaste for all things wearing the brand of Gates. JavaScript can be an ugly, incompatable-with-anything mess, but it can be elegant and powerful, as well. Both languages can play very nicely with Python, via good web services and toolkits.

Python gets some cruft from the communities who normally work with C# and JavaScript. C# developers are often not open source fans, and they don't know what these weird hippies are talking about, because Visual Basic is just fine. JavaScript users often work exclusively in the web industry, where languages like PHP reign supreme. Python and PHP do not clash, so the JavaScript world hasn't had a great past with respect to Python. A lot of this is changing with the work being done at Mozilla getting Python support into the platform, adopting Python features for JavaScript 2.0, and PyPy being able to compile a python interpreter to JavaScript (crazy!).

And, quickly, why the other 6 1/2 languages just don't make the cut, or under what circumstances you might justify learning PHP, for example.
  • PHP
    So many of us hate it, but we work with it day in and day out. Sometimes you hate what you do, but you the bills it pays. Do many people enjoy PHP? No, but many of those people get paid for it.
  • Perl
    Very little perl these days is used off the web, and if you don't have the freedom to use something fun like Python, then PHP is even a more fitting choice than Perl.
  • Ruby and Ruby on Rails
  • Ruby on Rails isn't really a language, unless you buy into the idea that Ruby allows for use as a DSL engine. Ruby was around for a long time with no fan real fanbase, until Rails stole the scene and we are largely just waiting for the tidal wave to subside. Ruby isn't a terrible language, but I find it odd and there is little weight in a language that is effective carried by a single product.
  • Java
    The promise this language once showed has waned just in time to see Sun almost get the picture before its flame is extinguished. The niche Java fit is filled nicely with languages like Python and Ruby.
    There is a long held stubborn view in the Java world that all things must be Java. Look at their toolkits written entirely in Java, and even prefering low-level work done in Java, rather than wrap existing libraries. Much of this is in the name of portability, but in the end it just means that I have to wait longer for Eclipse to load than it took my machine to boot up in the first place.
  • VB.Net
    I have not used the .Net versions of Visual Basic, but its ancestor is not a fun thing to live with. Even given its improvements (so I hear), it looses a lot of its weight anymore.
    These statements should be taken with salt, because I haven't worked with VB.Net, but here they are anyway. Being a .Net language, it shouldn't matter what language you use, so long as it utilizes the CLR. That means you could even use C# or Python to write the code for Excel and Access, which was one day the only reason anyone had to touch Visual Basic. So with the advent of IronPython, and the myriad of languages that can take VB's place in any given project, where is the need for this language anymore?
As Johnny Storm says, "Flame on!"

PS - That was a punny reference to flamewars. ... get it? ahem. I'm leaving.

Comments

dado1945 said…
AJAX isn't really a language but in general I must agree.

C/C++ will not dissapear for a long time as well. At least for low level stuff. While PyPy is not complete :-)
Anonymous said…
Java niche place?

When browsing job search engines Java fits more than 40% of software developer vacancies, while next on the list C++ is less than 15%.

I tried C# once, but it is years behind Java in many important areas (no JPA, no JMS, poor performance).

And be realistic, Eclipse load fast, really fast and run fast, really fast if you have enough RAM -512 MBytes-. It's just that Eclipse stores "everything in an inmemory relational database" (http://en.wikipedia.org/wiki/Eclipse_(computing) )
Jonathan Allen said…
VB.Net appears to be the only language that plays well with COM.

It is really hard to use COM with C#. Since C# doesn't support late binding, you have to write a lot of reflection code. This is especially true with the libraries that only offer late bound access to some of their methods.

C# also doesn't handle reference and optional parameters very well. Since you cannot cast away the refence behavior, you have to create a bunch of temporary variables of type object. Often these end up holding a pointer to Reflection.Missing.

C#
object missing = Reflection.Missing;
wordDocument.PrintOut(ref missing,ref missing,ref missing,ref missing,ref missing,ref missing,ref missing);

VB
wordDocument.PrintOut()
Jonathan Allen said…
> I tried C# once, but it is years behind Java in many important areas (no JPA, no JMS, poor performance).


JMS: MS Message Queues was released a long time ago.

JPA: LINQ is the MS answer to JPA and related technologies. Alas, that is at least a year away.

You need to be more specific about your performance concerns. I know the VS IDE sucks, but where are you seeing
Anonymous said…
>> MS: MS Message Queues was released a long time ago.

The case is that a Message system is just as usefull as the number of different platforms it support. And while JMS is industry standard that interact with main ones (IBM, SAP, Oracle...) MS Message Queue just interact with itself. And if your soft. doesn't interact with IBM, SAP and Oracle your soft. is out of business.

>> JPA: LINQ is the MS answer to JPA and related technologies. Alas, that is at least a year away.

That's probably why so many people prefer NHibernate (the mate of Hibernate, that preceded JPA).

Popular posts from this blog

On Pruning Your Passions [MOVED]

We live in a hobby-rich world. There is no shortage of pastimes to grow a passion for. There is a shortage of one thing: time to indulge those passions. If you're someone who pours your heart into that one thing that makes your life worthwhile, that's a great deal. But, what if you've got no shortage of interests that draw your attention and you realize you will never have the time for all of them?

If I look at all the things I'd love to do with my life as a rose bush I'm tending, I realize that careful pruning is essential for the best outcome. This is a hard lesson to learn, because it can mean cutting beautiful flowers and watching the petals fall to the ground to wither. It has to be done.

I have a full time job that takes a lot of my mental energy. I have a wife and a son and family time is very important in my house. I try to read more, and I want to keep up with new developments in my career, and I'm trying to make time for simple, intentional relaxing t…

The Insidiousness of The Slow Solution

In software development, slow solutions can be worse than no progress at all. I'll even say its usually worse and if you find yourself making slow progress on a problem, consider stopping while you're a head.

Its easy to see why fast progress is better: either you solve the problem or you prove a proposed solution wrong and find a better one. Even a total standstill in pushing forward on a task or a bug or a request can force you to seek out new information or a second opinion.

Slow solutions, on the other hand, is kind of sneaky. Its insidious. Slow solution is related the Sunk Cost Fallacy, but maybe worse. Slow solutions have you constantly dripping more of your time, energy, and hope into a path that's still unproven, constantly digging a hole. Slow solutions are deceptive, because they still do offer real progress. It is hard to justify abandoning it or trying another route, because it is "working", technically.

We tend to romanticize the late night hacking…

Finding "One Game A Month"

I was really excited about the One Game A Month challenge as soon as I heard about it.
For about two years I've struggled in fits and starts to make my way into game development. This hasn't been productive in any of the ways I hoped when I started. Its really difficult to be fairly experienced as a developer, which I believe I am in my day job as a web developer, while struggling really hard at an area in which your experience just doesn't exist.
Its like being a pilot who doesn't know how to drive.

But this challenge provided a new breath to this little hobby of mine. It gave me a scaffolding to experiment, to learn, to reflect on finished projects. I had spent far too much time on game projects that stretched on far past their exciting phases, bogged down by bad decisions and regret.
And it has worked.
I have a lot to learn. I have a lot of experience to gain through trial and error and mistake and discovery. I have a lot of fun to be had making more small games t…