Deciding what programming language to use for the next project

+2 A:

If time-to-market is a consideration, then stick with Java.

You already know it, and with all the factors you list above the answer is in the affirmative either all the time or many times (but dependent somewhat on the problem domain).

Joel has written about how being a specialist in a language is more important than which language it is, and that learning a langauge/framework at the same time as creating a new product is probably a bad idea.

Then again, he invented a new language just to make a web-based bug-tracker, so...

Jason Cohen 2009-03-15 17:02:27

+1 A:

One very important argument for me is IDE-support. Things i can do in Jave with Eclipse (Debugging, Refactoring, Plugin-availability), i won't miss anymore. Especially dynamic languages can't give you lots of this features, instead they offer other nice things, so you have to weight your preferences.

Mork0075 2009-03-15 17:03:49

But many smart tools are built nowadays to make it easier to work even dynamic languages like groovy eclipse plugin.So even choosing a dynamic languages should be easy to develop given its freedom in types,conciseness,support and other many benefits for enterprise

2009-03-15 17:16:50

Developing with a language in Eclipse doenst mean that you have all the cool features Java gives you. In PyDev (Eclipse IDE for Python) you can't use code suggestion - because if the compiler/interpreter doesnt know a variable is a string, it can't suggest you anything. That's only one example.

Mork0075 2009-03-16 08:44:10

A:

Pick the tool your team thinks is the best tool to use for the project. It's as simple as that.

If there are disagreements, call a vote. If that doesn't work, list features and advantages you are going to use of each language in question. (You may want to do this anyway.)

strager 2009-03-15 17:05:42

Listing the features and advantages is one thing, but another thing to consider is how the Prog Lang fits nicely is and solves the problem in hand like for e.g. persistence problem can be solved using ORM (HIbernate) or Active record approach (RoR).

2009-03-15 17:44:12

@sunnyjava, I'd say that is covered by "features and advantages you are going to use". E,g, an advantage of using (whatever language) is that persistent is abstracted using an ORM easily. An advantage of using Perl is its great regexp support to perform string manipulations. Stuff like that.

strager 2009-03-15 18:51:04

+1 A:

More than the language, and as efficiency goes, it's the tools and libraries that comes with it that will matter from a strictly technical point of view.

Learning a new language is not that big an issue. Re-inventing the wheel is.

Julian Aubourg 2009-03-15 17:06:12

Good point. However, I don't think the OP is after creating software in a vanilla form of a language (? like plain PHP without a framework).

strager 2009-03-15 17:15:55

Of course not, but given the application's domain some languages will have better helper libraries than others and this has sadly nothing to do with the language itself.

Julian Aubourg 2009-03-15 17:35:19

but how well a library can be constructed is determined by language .isn't it? Or you are just thinking in terms of API's?

2009-03-15 17:40:57

Save for special limitations (like javascript in a browser), you can code anything in any language. Now if you have a library for language A that solves 80% of your problems and another in much more well-designed language B you're fluent in that solves only 40%, then you should definitely go for A.

Julian Aubourg 2009-03-15 17:52:32

i really don't agree that "you can code anything in any language".Actually i would hate a language that can do anything because than it means its not efficient and optimized to anything.Well thought and designed libraries can be easily ported to any language like Lucene,iText,Log4X,Hibernate,etc.

2009-03-15 18:39:39

Julian Aubourg 2009-03-15 22:48:45

(...) See, if such libraries exist, are widely used and solve problems in the same domain as your project, then it is safe to infer the language itself is adapted to your problem. (...)

Julian Aubourg 2009-03-15 22:51:17

(...) as an example, it's perfectly possible to code a 3D game in PHP. But you'd have to code a lot (mainly to communicate with OpenGL or DirectX). No, you'd rather go with C/C++ or even Java. See, it's about the libraries, not the language itself. (...)

Julian Aubourg 2009-03-15 22:54:33

(...) Now you can take performance into consideration but chances are you won't see a solid OpenGL interface library in a language that's "too slow" to make 3D. As for libraries being portable in every language, yes, that's my point.

Julian Aubourg 2009-03-15 22:56:30

A:

I'm bewildered by your intentions.

If you don't have a preference for any new language based on real benefits, I'd suggest you shouldn't switch. A polyglot installed based is not a particularly desirable thing, especially if it's only there for variety.

If there were a good reason for a new language, the reason should be based on your own evaluation of your context and resources, none of which are enumerated here. You don't even mention what your "next project" is. And if you don't know, then there's not much to be said.

Or is this some kind of Community Wiki question, and you're asking for pure speculation?

le dorfier 2009-03-15 17:42:39

there is no reason to be bewildered. i have seen the sales and technical teams switching technology overnight before client proposals and demos. i am just trying to figure out the rationale behind this from an engineering view point.

2009-03-15 17:48:45

Then it sounds like "not a real question".

le dorfier 2009-03-15 17:49:49

+1 A:

Well fortunately we have Java and .NET, which means we don't have to give up on everything to use a new or better language.

For example, on our .NET projects, we've started moving to developing using F# whenever possible. We get to keep:

Visual Studio (F# has plugin support)
Team Foundation Server / msbuild (seamless)
.NET (framework + 3rd party libraries we know and use)
Existing code (full, easy interop (seamless most of the time))
Backcompat - F# compiled code can be used with other .NET, seamlessly if we desire

Where things don't work out (F#'s quotations-to-Expression isn't really finished, and there's no GUI designer support), we can quickly drop back to C# and use the parts we need.

Now compare that to picking something off the platform. We'd be changing everything at once. If the platform is missing support for something (and you wouldn't necesarily know beforehand), you're gonna get slammed. By staying with Java/.NET, you significantly reduce your risk, while still being able to get most (sometimes all?) of the benefits of using another language.

So, look at some Java languages. I've heard Scala does near seamless interop with Java's existing OO system.

Edit

As to why C#->F# or Java->Scala, in both cases (as far as I know), the new language is pretty much a superset of the old one. So any place that C# or Java are working fine, F#/Scala should handle it just as fine, as a minimum. All the extra benefits are a bonus.

MichaelGG 2009-03-16 22:04:06

A:

I say "python", beacuse I know and love it and stick with whatever falls out of the large flamewar/meeting when the PHB slams his fist on the table and chooses one by dart arrow.

Tetha 2009-03-16 22:14:51

A:

Surely future support should be factored in, if you have a history of C# and then decide that for this project you are going to use F#, and then VB for the next project, will you not find issues with supporting the product in the future (ok maybe that's based on my experiances with my company where if your the expert, you get all the support issues)

Do not most companies have tool policy ? Or is it down to teams to decide ? I've only ever worked for for development companies not freelanced

spacemonkeys 2009-03-16 22:23:00

ansaurus

tags:

views:

answers:

Deciding what programming language to use for the next project

related questions