For me I am C# and Java person. I find these 2 languages are quite similar so its easier for me to crossover each other. I'm not sure if its good idea to pick up other different languages. Any thoughts?
I can think of at least five reasons to learn a language, and it seems like you should eventually learn one for each of these.
- One language to get your first job - likely Java/C#/C++
- One language to get things done - likely Bash/Perl/Python/Ruby
- One language to bend your mind - likely Haskell/Clojure/Scala/F#
- One language to get your hands dirty - likely C/Assembly
It's not about how many languages you learn. It's about learning new concepts. Some languages might be able to teach you many concepts, while others might be able to teach only one.
If you know C#, you probably wouldn't learn anything terribly new by learning Java. But you would if you learned Haskell.
So when you pick a new language to learn, pick something that will teach you concepts you don't already know.
I'd say the most important thing is the ability to learn fast. That said it's important to know different languages that are used for different purposes. For example I know:
1) Python and Perl for the scripting languages category
2) C++ as "framework" language
3) Java for mobile application
4) C for the huge amount of legacy code
5) Some obsolete languages I used to know when I was young (Basic, Pascal, Clipper etc)
I'd say that you need at least a main language and a scripting one. Knowing C# I'd say you need to learn Python or Perl or Ruby next. (I'd go with Python but that's just a matter of preference).
You should concentrate on the languages you need and use for what you're doing. Really learning a language comes from practice, so you get the benefit of that language when you're practicing it. If you are going to learn a new language in your spare time, then do it by implementing it in tasks of increasing complexity, so that you really get a handle on it.
concentrate on none. focus on learning and writing clean code; clear, expressive, simple and, most important, not duplicated.
go for the principles of that type of programming, the basics (for example, encapsulation for OOP; what is means and what it implies) and learn some principles
this stuff will make your job easier. this will even make it easier for the people that work with your or after you.
ya, you have to know the syntax pretty well, too. but that not something what takes your focus a long time
and ya, you must understand pretty well the technologies you use, too. but those can be prioritized according to the level of complexity your business requires.
the last two are not of a main focus, but of some focus
I don't think you can necessarily master a language without having enough understanding of other languages to see that language "from the outside" as it were. Each different language brings something else to the table and the concepts they bring are things you can take back to the main languages you work with.
So time spent learning to use other languages is never wasted even if you are not planning to use them commercially.
The old adage is to learn a language every year and I'd certainly say for the first ten years or so you need to do that. Maybe beyond that you could choose between exploring some of the ones you already know in more depth ( perhaps updating your knowledge of ones you learned a few years back ) or working with particular libraries rather than just accumulating new languages endlessly, but keeping an eye on exploring the practice of programming through working with different languages is certainly an aid to your development as a programmer.
Popular programming languages like C# and Java will keep you gainfully employed most places, but neither are different enough from each other to learn new ways of solving problems. I think there are some languages that you eat with (the ones you use to do your job), and others that you play with. Both have their purposes.
I've found that by learning new programming languages, I've also learned new and more elegant ways to solve problems. It's not about the number of languages, or how often you pick them up. Each programming language worth learning has a unique point of view, which forces you to approach your problems with a new mindset. Many times the value comes from learning that mindset.
I've played with Smalltalk, and I loved it. The language was just a pleasure to develop with. Once you got used to the idioms, they helped you be more expressive with your code. I didn't miss the static typing you have in Java/C++/C# at all. The generics we live with in our statically typed languages are really constructs to work around the limitations static typing imposes.
I use Ruby and Ruby on Rails regularly, although not for paying jobs right now. Ruby's designing principle was "increasing programmer happiness". You gotta love that sentiment, and for the most part I think it delivers.
Eventually Java will go the way of lisp and Smalltalk, and C# will follow suit. What will be there to take their place remains to be seen. At the end of the day, if you know how to solve problems, and you have a number of ways to slice and dice the problem, you will be able to find a job and pick up whatever language you need for it.
When it comes to keeping skills up to date, and flexible, I think you should try to learn at least one completely new programming language every 6 months or so. And I mean a language that is very, very different.
So while learning more of the .net framework while using C# or the Java frameworks helps in keeping limber, learning Haskell, Smalltalk, Scala, Clojure or Ruby will expand your technique and help you think in different ways, some of which you may take usefully back to your main language, and some of which may help you move on if Java ceases to be king of the hill.
If you've never learned C, then although it's syntax has been brought to Java, the mindset can be quite different. It is worth knowing it, in depth, and even better, understanding how OO code can be written in this language which seems only procedural.
I recommend reading Bruce Tate's book "Beyond Java", which highlights only too well the dangers of being only on one language, noting the rise and fall of C++. Although C++ is far from dead yet and has decades left, it is becoming restricted more and more to use only in situations that cannot benefit from productivity gains in other languages. To contrast, Sinatra, a ruby framework, allows you to build a simple web service in about 6/7 lines of code, the C++ equivalent may be an order of magnitude larger than this.
When you're not a native English speaker, at least you must concentrate in improving your English. I'm saying that based on my experience. Understanding that language helped me a lot.
All good materials(books, articles, code, etc.) for learning programming languages, technologies and new concepts are written in English.
Languages are tools to get work done. Some languages are good for some types of problems, others are generally good at all sorts of problem solving. I recommend learning new languages as they come out. Don't get obsessed with what is fashionable this month, but learn what they can do, what they are good at. My advice is 1 new language per year. They come out faster than that, but you are looking to put new tools in your toolbox, not be the fashionable new kid on the block.
One essay that talks about the differences in languages is Paul Graham's "Beating the Averages." I recommend reading it, but one important part is here (he uses "Blub" as a hypothetical language so that you don't go arguing about what your favorite langage can do):
Or how about Perl 4? Between Perl 4 and Perl 5, lexical closures got added to the language. Most Perl hackers would agree that Perl 5 is more powerful than Perl 4. But once you've admitted that, you've admitted that one high level language can be more powerful than another. And it follows inexorably that, except in special cases, you ought to use the most powerful you can get.
This idea is rarely followed to its conclusion, though. After a certain age, programmers rarely switch languages voluntarily. Whatever language people happen to be used to, they tend to consider just good enough.
As long as our hypothetical Blub programmer is looking down the power continuum, he knows he's looking down. Languages less powerful than Blub are obviously less powerful, because they're missing some feature he's used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub.
When we switch to the point of view of a programmer using any of the languages higher up the power continuum, however, we find that he in turn looks down upon Blub. How can you get anything done in Blub? It doesn't even have y.
By induction, the only programmers in a position to see all the differences in power between the various languages are those who understand the most powerful one. (This is probably what Eric Raymond meant about Lisp making you a better programmer.) You can't trust the opinions of the others, because of the Blub paradox: they're satisfied with whatever language they happen to use, because it dictates the way they think about programs.
Most of the applications we ship are written in C# or VB. When we needed to add scripting to an application, we chose Python (Lua was the runner-up choice). We're learning F# because that can do some hairy new things that are hard to explain and understand if all one knows is C#/Java/VB.
it is also a good idea to know a duck-typed scripting language...e.g. one of perl, python, ruby, lua etc. these are incredibly useful for a huge array of problems including automating much of your own daily drudgery
for better or for worse you will also likely run into c# and/or java at some point too, they're quite pervasive.
in any case, don't limit yourself artificially. those coders i know who explicitly avoid picking up interesting tools seem to have cloistered worldviews and limited impact.
This could become another specialist vs generalist debate in a sense. Some people may spend a long time knowing one language to great depths which works fine for them. Other people may like to know a little about a bunch of different languages which works fine for them. Most people are between these two extremes.
If you want suggestions of languages to explore here are a few ideas:
Functional programming - Haskell or Lisp would be examples here and the paradigm shift can be a bit of a head turner to some extent.
Database specific - PL/SQL or T-SQL come to mind as something that may be useful if you want to do more back-end work with systems that require a database for some of its functionality.
These are just ideas and depending on where you want to be these may be useful or useless to you. Good luck with whatever choices you make.
A programmer needs to know three languages: C, English, and Something Else.
C is very much a core language, it's close to the machine and has syntax rules that are common to several high level languages. C forces you to think about things like data structures in a very different way than Java. Also, the Python and Ruby vms are both built in C, and you can inline C into both languages when you want to boost your speed.
English is the common language of programming. Most books, technical reports, technical websites, and journal papers come out in English first, and sometimes English exclusively. Furthermore, if English isn't your first language, learning English will expand your toolkit for manipulating concepts (this goes for English speakers learning some other language as well, of course).
The Something Else should be a language that isn't procedural, or isn't statically typed, or is strongly object oriented, or in some way is just fundamentally different from C. Haskell, Scala, Python, Ruby, some Lisp dialect, whatever.
After that, you can learn whatever your specific situation calls for, likely C# or Java.