views:

236

answers:

5

So I know that developers don't always get to pick the languages and platforms that they're working in - but in a sense they do, cause they can always ask, pursue, or leave a job... so with that in mind: why do you end up settling on particular a particular language or platform - what different factors play in to the ultimate decision. Please do not stop at "the right tool for the right job" or a similar phrase - please illustrate with real life examples.

A: 

For most people, go where the money is. If that requires learning Perl for an old Unix system or .NET for a new enterprise solution (correlations aren't exclusive), then ok.

Some may have their own select few "absolutes," but a high enough salary can usually even win that over. There aren't too many elitists who will turn down $200,000/year to put up with their most hated language/platform. ;)

Jonathan Lonowski
+5  A: 

It's all about cost-benefit.

If I just need to do some data processing done really quickly, for a one-off task, I'll use JSDB Javascript (a Javascript shell), it's my alternative to Perl for swiss-army-type computer hacking. I sometimes use it for tasks that I might have to perform again later, but I take more care to document it.

For more robust applications on a PC, I'll use Java, because it's a nice compromise between speed of execution, quickness of development, good toolsets/libraries/documentation (some people call this a software "ecosystem"), and cross-platform support.

For embedded systems I try to use C++, and hope and pray that the debugger is decent. (Some of them are awful, some don't have any debugger and you have to spit data out a serial port or flash an LED. Or create digital pulses to debug timing problems.)

Criteria I generally use:

  • execution speed & other performance concerns
  • debugger/profiler availability
  • cost of toolset (compiler, debugger, etc.)
  • level of community support (compare the # of questions asked on this forum about Java vs. Matlab)
  • obscurity of language (it may do EXACTLY what you want, but what if nobody knows it?)
  • ease of learning the language, libraries, etc.
  • cross-platform friendliness
  • code security (can you compile it to something that is very hard to reverse-engineer, or is it a script that can be easily read?)
  • how much the language facilitatese maintainability/modularity/etc.
Jason S
+3  A: 

As someone who has dabbled in a lot of languages... I now find myself being drawn to the platforms with these as my priorities

1) the kitchen sink libraries - everything is already included
2) the most thought out library structure (and extensible - so the designers can fix mistakes over time)
3) language syntax - I'm doing better - this used to be #1
4) mindshare - can you get help 24/7 online somewhere

I'm going to really get focused on these over the next year to two:
Java, .NET, Groovy, IronRuby, and F#.
I have choosed these because I have a certain level of comfort in the amount of library support there is for .NET and Java.

I have to put other things aside for now... I'm getting too fractured.

tyndall
so - any clear winner based on your priorities - between .NET and Java? I recently transitioned from mostly Java to mostly .NET work - and I'm wondering what others might think about how the two heavy weights stack up...
I like the language features of C# a lot. I do .NET as my day job. You can't beat some of the Microsoft tooling support.On the other hand, Java is on its open source journey now. It is far more portable. If I was to do Java as may day job, I would use Groovy.
tyndall
So in short, I'm happy with .NET, but if I were going into consulting, trying to start my own web start up, etc... any area where cost and portability was a factor I would hop over to Java in a heartbeat.
tyndall
I have to admit that I laughed when you set that you are really going to get focused...and then mentioned five different technologies. I'm just focused on wringing everything that I can out of one!
Mark Brittingham
A: 

Can I think in that language without it clashing with too much of the other thinking I do?

Sometimes a litle distance helps - languages which are too close result in confusion and it helps to have contextual clues when using the language to shift your mindset.

So, for work purposes, I look for languages which are semantically close but the syntax sufficiently different to help me focus on the platform.

As a recent example - I do a lot of work in REALbasic (a very clean OO BASIC). For my Windows work, I'm using C# rather than VB.net, to avoid confusion.

When studying languages to stretch my mind (and decide if I should add them to my toolkit), I look for languages with significant differences. I'm studying Ruby at present, as well as refining my C#. I expect to put some significant time into F# or Haskell later this year. I studied Lisp last year. I believe you have to have used a language for some real programming tasks to be able to decide on its compatibility with the rest of your mental tools - thinking in a language is different from reading about it.

Andy Dent
+1  A: 

I am in the lucky position to be able to work in my dream system, and have been so for a long time now. I do all my work in Smalltalk - period (actually: Smalltalk/X). If there are time critical things (image processing, real time data aquisation, rt-control), I split things into a hybrid, where the critical stuff is done in C, and all of the administration, GUI, webInterface, configuration etc. is done in Smalltalk. That way, we have built even very highly sophisticated control stuff (controlling chemical plants, a power plant, coal mining, paper mills and other industrial factories). On the other end, we do banking, web frameworks, GUI prototyping and communication security stuff - all in Smalltalk. Even replaced multiple existing Java systems (!) by complete rewrites in Smalltalk - and with higher performance.

Smalltalk is my dream environment for the following reasons:

  • completely portable between linux, solaris, hpux and windows (apps run out of the box without a need for a single change).
  • completely independent of ANY other framework (no fiddling around with different versions of Qt or any other widget library).
  • completeley open: there is no place where I cannot fix bugs or enhance a class; there is no such thing like a final String class, which you cannot teach new tricks (aka add your own stuff).
  • reasonable performance; mature VM
  • inline C-code for high performance requirements.
  • Smalltalks have the very best IDE's around - nothing compares to living inside the system and not separating the app from the IDE; nothing compares to having the IDE even in the end user app (ever had to remote debug an app running in china, while its running, and adding a fix while its controlling a factory, without stopping that dam thing ?)
  • Smalltalk has (beside CLOS) one of the best meta-object models around, and one of the best reflection available (even stack frames, code, the scheduler are objects, with interfaces, and are extensible)
  • Smalltalk allows for a much higher productivity due to its incremental nature. (actually ByteCode and JITting originated in Smalltalk systems in the 70's and 80's)
  • exception semantics is MUCH better than all of C++, C# and Java. These offers many new possibilities others would not even think about.
  • Smalltalk's blocks are one of the most beautiful invention ever: semantically, being clusures (which is not new), their syntax is pur fun to write and read. Look at how elegant some code looks and reads (see http://stackoverflow.com/questions/58431/algorithm-for-joining-e-g-an-array-of-strings and compare the C-code against Smalltalk)

Its no wonder, that many inventions were and are done in the Smalltalk community, and that extreme and agile development, pair programming, rapid prototyping etc. all where highly influenced by or even originated in its surroundings.

Some argue that the downside is its funny syntax; I would reply that you probably are not worth a CS degree if you cannot abstract over that. Beside, there is almost no syntax in Smalltalk (its description fits a single page) - most everything is done in the libraries.

Willing to accept comments and bashing (but downvotes are unfair :-)
PS: and yes - I do know and have worked in quite a few other languages...
PPS: If I had to give up Smalltalk, Lisp or Haskell would be my second choice, but both do not offer IDE's which are anyway near to what I am used to these days.
PPPS: I do accept the argument, that there might be not too many "official" consulting jobs for Smalltalkers, these days.

blabla999