What language do you chose to write an application

[Pat Farrell]

I know, this may be far too meaningful for MD, but it really doesn't fit in any other forum, and I know that the world's smartest forum members are here.

I'm taking over a project written in Java with JavaFX. Lets be gentle and say it has lots of issues. So many that the proper software engineering decision is to consider it a prototype of the functionality, and re-implement it.

The problem is, once you open the door to re-implementing it, you must ask which language and framework should you use to implement it.

For most of the past two decades, I've written professional web applications. Usual code that runs on a server talking to a browser. Modern implementations of this actually spilt the code in two, with some running on the webserver side, and some in the browser. This application is not like that. Its an application that runs on a PC (or Mac or Linux). The application talks to some specialized hardware. The application is the control for the specialized hardware.

Think about a PC talking MIDI to a musical instrument. A "sequencer" program is an application that talks MIDI real time to the synthesizer in both directions.

The current PHB wants Windows, OS-X and Linux. I expect that next month, we'll hear that IOS and Android are required as well.

Should I stay in Java?
or use node.js
Scala?
Python?
some new language that I've never heard of?
maybe write my own language and framework?
???

[Jesper de Jong]

You could invent your own programming language and framework for this. And why not invent your own operating system as well? You could even go further, and design your own hardware which perfectly fits the job, and which is super-efficient for your particular application.

Ofcourse you'll have to tell your client that it's going to be ready in 2024 and that it's going to cost millions. But he's going to get the best possible solution, and you'll have work for 10 years and you'll learn so much about programming language design, operating systems and hardware design. I'd say it's win-win!

[Jeanne Boyarsky]

Node.js isn't going to help you if there is a requirement for it to run as a desktop client. I think you should challenge that requirement though. HTML 5 lets you run in an offline mode for when the internet isn't available.

[K. Tsang]

Looking at the variety of platforms or devices, using somewhat a web-based language (eg HTML5) is probably best. This way you can cater for mobile (Android, iPhone etc), desktop (GUI), and web. The only difference is the screen size. Everything else is look and feel (eg not too much space here and there etc).

Another way I can think of is XML. Define your own schema and such and put everything in XML. But then this probably going towards developing your own language route somewhat.

JavaFX is another option since it supposed to be able to run online and offline. Oh Java Web Start (JNLP) - click and download and run (given client/user has java runtime).

Or combination of languages depending on what app/web server you plan to use.

[Pat Farrell]

Jeanne Boyarsky wrote:Node.js isn't going to help you if there is a requirement for it to run as a desktop client. I think you should challenge that requirement though. HTML 5 lets you run in an offline mode for when the internet isn't available.

I can challenge any requirement, but if you extend "desktop" to really mean "controlling computer" so it can include tablets (say a Nexus 7 or iPad) as well as more traditional desktops and laptops, I think that is the real requirement.

This is about controlling the external device that is physically connected by a cable. There is nothing about this application that deals with the Internet.

I thought that node.js is "server side" and since everything that I consider a computer is a 'server' I'm not seeing how this is a conflict.

[Pat Farrell]

K. Tsang wrote:Java Web Start (JNLP) - click and download and run (given client/user has java runtime

Or combination of languages depending on what app/web server you plan to use.

I've found that JNLP doesn't deliver 100% of the time. Its got to be a pure download, and click.

I don't follow your question about app/web server? What web server?

[Ulf Dittmer]

I think there's something to be said for using a language you're well versed in, i.e. Java. The "hardware, MIDI, real time" part makes it sound as if parts will need to be native anyway, and JNI (or a library like JNA) makes that fairly painless.

Because of the interfacing with a local device I don't think that something browser-based would be a good choice (unless you're willing to create a browser plugin for the native part - which is still just an assumption by me).

The interesting part is the GUI, IMO. If you haven't done much work in any major GUI framework (Swing, KDE, Gnome, Win32 etc.), Swing/JavaFX may well win because of familiarity of the underlying language, and least cross-platform hassles.

A fun alternative to consider would be to create a double-clickable Java app that starts an embedded servlet container: it would let you use technologies you're familiar with, the Java code can interface with JNI and the host machine without restrictions, and the GUI would be cross platform with no extra work.

[Pat Farrell]

Ulf Dittmer wrote:If you haven't done much work in any major GUI framework (Swing, KDE, Gnome, Win32 etc.), Swing/JavaFX may well win because of familiarity of the underlying language, and least cross-platform hassles.

I've done Windows API since Windows 286 2.11. Both AWT and Swing on Java. A bit of pure X-windows back in the day.

Yes, there has to be a shim that can talk to the hardware, this is true of any high level language. That is not a worry, the serial communications technology is well understood. (That is all USB is in most cases, a different flavor of 1980s vintage serial communications).

I've been in the webserver talking to browser world so long that I really don't know what modern cross platform stuff can do. But in general, talking HTTP to a browser-like interface is a PITA, its not "native" and its really hard to get a proper native look and feel, let alone seamless integration with other applications on the platform.

I don't like the JavaFX usage that the existing code has. Perhaps there is a better way to do it, but I see huge amounts of coupling between modules with all the callbacks for every possible UI event. Since there are similar callbacks for framework that talks serial communications, about 90% of the existing code base seems to be handling callbacks.

[Martin Vashko]

Pat Farrell wrote:Perhaps there is a better way to do it, but I see huge amounts of coupling between modules with all the callbacks for every possible UI event.

I haven't had an opportunity (or better, I missed one) to use Guava's EvenBus, but if I understood your concerns correctly, you might be interested in it.

[Pat Farrell]

Yes, I love Guava's stuff and the event bus may be a solution if I stay in Java.

Now, I'll grant that here in the Java Ranch, we'll get mostly Java folks, but I sure expected some folks to argue for python or scala or some new language that I've never heard of.

[Ulf Dittmer]

Python (and some other languages) would imply installing the runtime on the client machine, whereas Java is generally available. That would be OK?

[Pat Farrell]

We have found with our current Java based version that you can't assume that the machine has a JVM. We build a package that includes a JVM so we can do the "click to run". So another thing like a JVM is not an issue here.