Fog Creek Software
Discussion Board

Enterprise app. languages

Question: what would be the recommended language to develop an enterprise-class app. in?

One thing I've actually considered is Java, almost entirely for the massive class libraries including decent support for RMI, serialization, and other stuff that will be useful.

I considered C++ very highly, and I like it and it's fast and efficient. The downside there is that I have to do a lot myself.

I'm not sure what else would be out there that'd be appropriate.


Mike Swieton
Thursday, December 5, 2002

Why not go with .NET & C#? Class libraries for .NET is pretty good too.

I know you can do a bit with RMI, but I think XML, SOAP is the way to go.

would love to hear everyone's thoughts on this.

Prakash S
Thursday, December 5, 2002

um... VB? Delphi? Powerbuilder? Cobol? X86asm? Emacs?

It doesn't really matter what language you program in, as long as:

1. It can satisfy your problem domain requirements (most languages)
2. Is accepted and is productive with your team.


James Wann
Thursday, December 5, 2002

I should have mentioned this before, but I intend this application to run on Unix first, and Windows second. Of course, I intend both, but I'm developing under Linux, so .NET is not at the top of my list.

I know there's a lot of support there, which I am investigating, I was just wondering what people thought.

James: Yeah, I could write it in fortran or mindfuck if I wanted to, but if I'm going as low level as the assembler that you mention, I'll write it in C++.

The question is not of whether it can do it:  most languages can do it.

It's also not as much a question of productivity of the team: I know C++ and java both extremely well, but Java's class libraries are great. But will they both scale well enough to support hundreds of concurrent connections?

I'm willing to sacrifice ease of development for scalability and efficiency in the end result, but if Java scales well, for example, then why not take advantage of its strengths?

And the team is me: Right now I have no helpers, which I'm OK with. I'll learn whatever I need to know to do what I want quickly and with high quality. That's the important thing.

In this context, what would you guys pick?

Mike Swieton
Thursday, December 5, 2002

Java is designed for scalability, and if you need to hop down to C++, you can write Java code to call C++ code.

Like you say, Java comes with very substantial class libraries and there are a lot of open source, free, shareware, cheap, etc libraries you can use.

If you know Java and C++ equally well, you should be more productive with Java (this is similar to Joel's C++ programmers are more productive in VB argument).

Walter Rumsby
Thursday, December 5, 2002

> I'm willing to sacrifice ease of development for scalability
> and efficiency in the end result, but if Java scales well, for
> example, then why not take advantage of its strengths?

Excellent, some details. Of course, this begs more questions:

1. What "scale" are you talking about? I'm assuming you mean the number of users? Or is it the number of write transactions? Or is it read-modify-write transactions?

2. If you're concerned about large #'s of concurrent connections, then either COM+/.NET or J2EE/EJB's scale equally well, since they essentially have the same transaction/pooling model.

3. Are you planning on taking a multi-tiered approach?
4. What is the expected source of the "hot-spot"? In other words, what are you afraid of not scaling well?

Apologies for the terse earlier response, but it initally sounded way too open ended :-P


James Wann
Thursday, December 5, 2002

From what you say, you would be better off with Java.

Prakash S
Thursday, December 5, 2002

i would use Java. at some point you will want a break (an "enterprise" app is a 24/7 affair) and everyone else is doing it in java, so it is easier to hire someone else to take up where you left off. ;-)

if it is really "just you" , you could use whatever you wanted. however, java has the best libraries for unix-based enterprise-y stuff.

Thursday, December 5, 2002

why not try Python and Kylix(Delphi for linux)?!

there both great languages and the combination is great imho.

And of course there both perfectly portable!

my 2 cents

Thursday, December 5, 2002

Without knowing what the app was intended to do its tricky.  There might well be a middle ware product that does most of what you want already, or you might want to build it from scratch.

In the end its the platforms that you want to support that matter.  It sounds like you don't care what the clients are and so its a matter of what server platforms you want.

Choosing Java is not a bad choice, if I was writing it from scratch I'd probably choose Perl unless I was supposed to be distributing objects (which doesn't appeal to me), rather than messaging,

Simon Lucy
Friday, December 6, 2002

If it is a business app, I don't really have the experience base to recommend. However, since you want to run first on Unix it seems likely that it isn't necessarily a straight IT-style app, so...

User interaction layer with wxPython (which is cross-platform), and application data management (persistence, undo/redo, etc.) with C++.

General advice: unless your intent is to experiment, don't jump on the latest bandwagon. If your intent is for long-term production use stable, proven technology.

Jeff Kotula
Friday, December 6, 2002

Some remarks:

Developing gui in Java environment is not as fast as in .NET or Delphi (swing or browser).

On the other hand, there are indeed lots of interesting libraries around for the Java platform. Quality is higher then i have seen for Delphi or VB.

Another interesting issue is finding developers that are qualified to develop enterprise software. In my personal experience there are more developers on the Java front than on the MS platform who are knowledgeable. Maybe this is because the barrier for J2EE is higher?

Finally, there is the issue of cost: app servers like WebSphere or WebLogic are expensive. JBoss and Linux are for free. Leaves the database; maybe MySQL is an option, but i heard that it doesn't run flawless on Windows.

Stephan Westen
Friday, December 6, 2002

For free open source production quality (or at least proven technologies), have a look at Firebird (the open source version of the commercial Interbase) and the famous postgresQL (Windows support is not as great)

Robert Chevallier
Friday, December 6, 2002

This model may not work in your current environment but a good approach is to use a messaging system as the backbone for your Enterprise App. Good messaging systems include Tuxedo, Tibco, MQSeries (and MSMQs if you are on Unix) or you could always role your own.

The messaging system essentially sends messages and requests back and forth between what are, otherwise seperate systems.

The advantages of this model are:

1. You can use any and all the languages you want. Java in some places, C++ in others. The messaging system will hide each unit from the details of the other. This allows you to specialize by using Java for certain stuff but using C++ to handle intensive or low level stuff. I know one site that even attached perl for doing reports.

2. Scaleable. Allows the load to be spread over many differant processes and even servers.

3. Fault Tolerant. Allows whole servers to be killed without crashing the system.

Disadvantages are, of course, cost and complexity. They can also increase response times but then that is often the case for scalability.

Sunday, December 8, 2002

*  Recent Topics

*  Fog Creek Home