views:

162

answers:

5

I've noticed on a few Flash vs. Silverlight threads that familiarity with .NET amongst back-end developers is being given as a plus for Silverlight. But realistically, how many devs are going to switch from back-end to front end development? Isn't it actually more likely that it will be Flash and Flex guys learning Silverlight, as they already understand the RIA problem domain - gui development, usability, etc?

This got me thinking about the more general question - is it harder to switch languages, or problem domains?

+1  A: 

I'd guess that it's easier to 'switch' languages. If by switch, you mean 'learn to an equivalent level of potency as with your current equivalent language', because I doubt people will very often out-right switch to a new language out of the blue, or even because of a new tool like Silverlight.

Problem domains, well, I'm not exactly sure what that even means in this context. But If you mean going from being a developer of X level of skill to being a designer/UI-developer of X level of skill, that seems like something that would be extraordinarily difficult. They're entirely different areas of expertise, and unless you set out from the start of your programming career to be a full-stack developer, as interested in usable UIs as efficient backends, I doubt you could easily become such.

elliottcable
+1  A: 

I would think that changing problem domains is the most difficult. Then again changing to a completely different programming language is quite a challenge too.

I guess the sort of depends, changing the problem domain while maintaining the same programming language helps a lot. But overall I think switching programming languages tends to be more simple than changing the problem domain.

Megacan
+3  A: 

"Switching languages" can be ambiguous. I can switch from C# to Java or Java to C# without much effort since the two languages are similar in terms of Programming Paradigm. By the way, having a pure C# programmer learn how to program Prolog, which is logic programming language, is much harder.

A programming paradigm is a fundamental style of computer programming. (Compare with a methodology, which is a style of solving specific software engineering problems). Paradigms differ in the concepts and abstractions used to represent the elements of a program (such as objects, functions, variables, constraints, etc.) and the steps that compose a computation (assignation, evaluation, continuations, data flows, etc.).

"Switching problem domains" seems to be superset of "Switching languages" to me. And I think it is a lot more harder.

m3rLinEz
A: 

It depends on what domains you know already and what languages you know already.

There are basically 4 types of language - imperative (eg C, Cobol, Perl), Object-Oriented (Java, C# Smalltalk), logic (Prolog) and functional (Haskell, LISP, Scheme ...). There are others and crossovers but that covers most of what I'd consider the main types. If you know one of each of these learning any other language is pretty easy. Learning your first functional or OO language can be hard, and sometimes much hard than switching domains. Learning Java if you know C# is very easy.

As far as learning domains go, it depends a lot on the domain. So for example most computer vision is done in Matrix oriented code by engineers, so swapping to computer graphics is similar and so not too hard. Swapping from real-time embedded code to corporate banking large scale database code can be tricky.

This question is like asking is it easier to learn French or car maintenance. It depends on what you know already, and your aptitudes.

Nick Fortescue
A: 

Switching between front-end and back-end is not really a switch in problem domain. That is only a switch between narrow parts of the solution domain. Switching from writing avionics software to writing video poker machine software is a switch in problem domain.

But realistically, how many devs are going to switch from back-end to front end development?

I don't understand why more don't. If you don't know how to write front-end stuff, how can you effectively develop a back-end to support it? And if you don't know anything about back-end stuff, how can you develop a front-end that uses it efficiently?

All developers should continuously strive to broaden their skill sets. Specialization is for insects.

Kristopher Johnson