See, a definite answer is hard to give but let's look at it this way. You don't know how to swim and you don't know the depth of the water but you are told to jump into the river. Do you thinking that when you're in that river you'll be able to start learning basic swimming procedures like floating and strokes? I think knowing the basics will help on the way.
Business requirements all the way down to stories and pseudo code should all be language agnostic. There may definitely be technical hurdles depending on the framework you're using, but that should not e issue until you're well and truly neck deep.
Was going to make a long-requested app for in-house use. The "power-that-is" insisted I write it using Visual FoxPro.
His reasoning was, as one might expect, inane. Particularly so since Micro$oft announced they are dropping the language. Furthermore, he insisted that it be incorporated into another application which is already rather monolithic and suffering under its own weight. There is even more to this adventure, and the depravity only gets worse.
Progress was slow and error rate was high, wasting company time (mine and the requester's).
I was wondering: are programmers allowed an occasional summary execution to keep the management herd appropriately culled?
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"As far as we know, our computer has never had an undetected error." - Weisert
"If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
I believe that before actually getting into the coding part, it's good to set some time aside and look at how the language works. Does it look very similar to what you already know or so (Let's think C++ and C#)? Or will it require quite an amount of understanding before something in the task gets done?
I would say that analyzing these would give you a great idea about where you stand. That should give you a headstart on what you need to learn and would prevent any situations where you would have to face your boss at the last minute and say "I need more time". The answer will be "Great. So remind me again why you didn't tell me sooner about this?"
Write a couple small programs on your own first. Find out what the language can do and how to do some of the things that you suspect may be required in your own throw away apps before you have to make it work in an application that you could have a long shelf life. Best to do it outside of the microscope of an actual project.
Also you want to know a little bit more about what you are doing before you have a project manager or owner or sponsor breathing down your neck about deadlines.
The likelihood of having to learn a whole new language from scratch is probably much more rare than having to learn a new technology or technique, but you may go through many of the same pains. Think about learning reflection, regular expressions, jquery, css, wcf, wpf, nhibernate, mvc, etc. In all of these cases, you could still be programming in c# but feel like you have a new language to grapple with.
I learn best by doing. I would agree with the first two options: dive in and learn as you go AND learn before starting. An iterative approach works well. Learn a little, apply a little, learn a little more, apply a little more and so on. Important to take time to learn the language while solve the problem. I've found, even after years of experience, I still need to take time to dive deeper into nuances of a language, especially any new features of the language.
your manager and lead programmers decide that it's best to tackle the new project at hand in a language that you don't know. And you are given a choice to either remain in that team or move to any other team that continues to use the language you are comfortable in.
The answer would very much depend on the circumstances - is that language adoption step in the right direction regarding technology, someone's career aspirations and interests and many other things.
Most people wouldn't react the same way if offered (today) to do the HTML5 of some future Win 8 development (whatever the platform might be) - or offered something along the COBOL/classic VB/ FORTRAN line.
General answer to this question is almost imposible to give.
I absolutelly agree with this opinion.
On the other side, tools are just... tools.If you are an experienced, expert software developer, and you have a clear vision of the solution to the problem you must face... tools come in second place. Solving the problem is the hard part.
In 1997, I was walking around the pond in back of our office in Marlton, NJ while my boss puffed away on his Marlboro beside me as we discussed the state of affairs on one of my projects. I asked him, incidentally, how many programming languages (including OS script languages and assembly languages) he'd used professionally. He'd lost count; by that time, I myself was up to about eight or ten and was busy learning a new one called PL/Trim (a "4GL" used at that time (and maybe still) by Boeing and three other customers, of whom we might have been the smallest). All their software was in PL/Trim except for some library routines written in C.
In 2001, I got a job to develop an interactive voice-response (IVR) application very similar to the one I'd built in 1998 in Visual Basic - only this time, I had to build it in Java, a language with which I was barely familiar, and I had to find a test platform to run it on. I did both, and had a working prototype ready in three months.
Back at the beginning of my programming career, my first permanent programming job required a C programmer, which I had become without benefit of formal training - my debugging technique in C was sufficiently sophisticated that my new boss decided I was worth the risk. So even then, I was working with languages that I was learning as I worked.
It still stuns me sometimes how many programmers out there have never, ever programmed outside of one or two languages, usually their primary development language and the script language used by their primary operating system.
It always amazes me that there are programmers who are afraid of diving in and learning a new language on the fly.
CQ de W5ALT
Walt Fair, Jr., P. E. Comport Computing Specializing in Technical Engineering Software