[subego]

Well folks, I'm becoming a developer, so you have the opportunity to mold me into the type of developer you think i should be.

Most of my recent experience has been with Filemaker, which is a super easy and forgiving development environment, but I think my needs (especially the user interface on my finished product) are going to grow beyond that.

What I like about Filemaker, other than it's simplicity, is its cross-platform nature. Anything I make is going to have a larger market on the Windows side, so I absolutely, positively need a Windows version. I would so much rather learn Cocoa, but I'd be shooting myself in the foot, since I'd also need to learn something on the Windows side and port it.

No one wants to hear me drone on about what I'm developing, so let me sum up by saying the only two factors I'm worried about are interface and cross-platform compatibility. Almost everything else is achievable in whatever language I choose.

What I mean by cross-platform should be obvious, but I'll add a few words about interface. I'm not looking for anything way out there. I just need basic standard interface elements. Pop-up menus, sliders, etc. My interface is going to be pretty, but I'm not doing anything wildly non-standard with it. Filemaker would work fine, but the pop-up menus are rendered internally, and look big time fugly. Sliders are nowhere to be found.

So, I've bit the bullet and decided to go Java. It's got the cross-platform, I can use standard interface elements, and, I've got the truly excellent Head First Java book.

So, considering my primary concerns, is Java the way to go, or is there a different language I should be looking at?

[Chuckit]

I'll state straight off that my experience writing cross-platform GUI apps is somewhat limited, so take what I say with a grain of salt:

Java is an OK choice. It's not great, it's not terrible either. Its greatest strength is widespread support. It's worth noting that Java's cross-platform compatibility is often somewhat exaggerated — it's a common joke that "Write once, run anywhere" actually means "Write once, test everywhere." Java is fairly resource-intensive on many systems, and generally if I have a choice between a Java option and a native option, I will choose the native one without a moment's hesitation. Java apps also often look like somebody broke a standard user interface and tried to put it back together with staples and paste — but I guess that's a matter of how much care you put into it.

As a language, I personally prefer Ruby, which has a large number of GUI toolkits (wxWidgets, GTK, Qt and several others) available. Python is increasingly popular — more so than Ruby — and supports roughly the same set of GUI frameworks that Ruby does. I think they're both better languages than Java, but they're both younger and take more work to set up for cross-platform deployment.

Overall, like I said, Java is OK. It's widely used and has a large community around it. I think there are better languages, but really, your ability as a programmer matters more than the language. No matter what you start off writing in, that doesn't mean you can't write in other languages later if you decide you like one better.

[mduell]

There's nothing about Java that's great and there's a lot thats pretty marginal.

I'd suggest Python or C(++) and Tcl/Tk or GTK. I've become a huge fan of Tcl lately.

[numero]

I'll second Chuckit's opinion on Java and GUI difficulties. I love the language, but hate doing GUI work with Java.

Might I suggest RealBASIC. This isn't "GOTO 10" type of basic. It has a close resemblance to Java. It has classes, inheritance, threads and public, private and protected scope. It has an easy to use GUI layout tool and it even places the event listener stubs in for you. Here's the part you are going to like. For the kind of stuff you are talking about, all it takes is a check of a box to compile for another platform. It will compile for OS X (OS 9 if you still need that), Windows and Linux. It creates native executables without the need for an additional runtime install (like Java or .NET).

The version you will need for cross platform development is $500.

-numero

[jaydon34]

My vote is python, besides with the widely adopted use of the internet make a web application if you can these apps have true platform independence and just work.

[subego]

Excellent thought provoking answers. Keep 'em coming!

Originally Posted by Chuckit 

As a language, I personally prefer Ruby

I did a quick look at the Wikipedia entry for Ruby, and I like the focus on UI. Am I understanding correctly that it aims for a cross-platform situation similar to Java?

I'll take a look at Python too.

P.S. forgive me for asking super-basic questions. My ability to do legwork at the moment has been a bit compromised.

[Chuckit]

Originally Posted by subego 

I did a quick look at the Wikipedia entry for Ruby, and I like the focus on UI. Am I understanding correctly that it aims for a cross-platform situation similar to Java?

Both Ruby and Python are about as platform-neutral as Java. Both are interpreted languages, though Python can be compiled to bytecode similar to Java (this isn't yet supported in Ruby). Both use Tk as their standard GUI library, but like I said, there are several other choices as well.

[goMac]

In general, I just write the backend of my programs in C, and do two GUI's, one in Win32 and one in Cocoa. I feel like in order to provide the best experience for each platform, you should use a native API for the GUI. That said, I am employed to write for the Mac, so I don't have any programs out in the wild in Win32. I've been personally porting some stuff to Win32 mostly as a proof of concept to myself. Deploying my code on multiple platforms is good because it forces me to write nicer code, and tests my back end on other platforms so I am free to deploy on other platforms if necessary.

Usually I try and write my backends in C with Apple's CoreFoundation. It plays nice with Cocoa and abstracts things nicely. CoreFoundation is an Apple API, but it is open source, and mostly ported to Windows and Linux as part of Apple's CFLite project. Apple is shipping several applications that use CoreFoundation on Windows, most notably Safari.

For someone who develops in Filemaker coding in C and Cocoa and Win32 might be a bit of a leap however.

I don't have a good opinion of Java. I feel like it's GUI libraries are hacks. Not to mention, Java actually has TWO gui libraries. The documentation isn't very clean, and I've actually run into times when you have two classes with the same name (which isn't a huge deal if you use name spaces, but still feels like a big no-no coming from a Cocoa/C++ perspective). The other thing that annoys me is Java does not necessarily use native OS X widgets. It tries to kludge in interface concepts from other platforms.

I have similar complaints about GTK, although I've never actually coded in GTK (I have coded in Java). GTK apps always feel a little off to me. On the other hand, GTK isn't as slow as Java and doesn't eat memory like Java does. Nice clean compiled language.

There are a few other options out there. GNUStep aims to make Cocoa cross platform. Last I checked they looked like they had things pretty well covered on Linux but their Windows support was shaky. And also the WINE project lets you compile Win32 on OS X.

[Chuckit]

GoMac's approach of cross-platform backend + platform-specific GUI is a good idea as well, I think. It's a great way to get the most mileage out of your code without having to compromise your UI standards. I believe this is what most companies do (e.g. MS Office and Adobe Creative Suite — someone can correct me if I'm wrong, but that's the impression that I've gotten). It's not as "automatic" as some languages boast, but that kind of magic cross-platformness is iffy in the first place. Though that still doesn't really necessitate any particular language.

[goMac]

Oh, there is also Mono. Mono seems to be the up and coming cross platform language of choice. Novel is backing it, and it works on OS X. It's certainly not as popular as Java or GTK yet, but it seems positioned to replace Java.

While Mono is open, keep in mind it's still an implementation of a Microsoft language. Some people may have a problem with that.

[Chuckit]

Ah, C# — it's just like Java, only from Microsoft! If that ain't the best of both worlds, I don't know what is.

Also, can it make GUI apps for the Mac now? Last I checked, it was command line-only.

[goMac]

Originally Posted by Chuckit 

Also, can it make GUI apps for the Mac now? Last I checked, it was command line-only.

I've run some .Net applications with GUI's on OS X with Mono before, so it would seem it can do GUI's now. I didn't get too far because the .Net application I was running used MSSQL which isn't implemented under Mono.

[subego]

Originally Posted by Chuckit 

GoMac's approach of cross-platform backend + platform-specific GUI is a good idea as well, I think.

Originally Posted by goMac 

For someone who develops in Filemaker coding in C and Cocoa and Win32 might be a bit of a leap however.

Why you...

Seriously though, C isn't really the leap. It's Cocoa and Win32. I've never had to code an interface. Of course, for obvious reasons, I've never had to write any database handling code either, so I have some good times with finds and sorts to look forward too.

Making two distinct versions like you suggest is definitely the "correct" way to do it. Of course, this hits me right in the soft spot in that I'd have to learn two entirely separate languages to do the part I've never done before. Further, since I'm a Mac person (surprise!), the Windows port will forever be the last stage of my development process. In other words, I'm already sick of the project at that point since I've already finished it once.

It's still very tempting to do it this way. Learning Cocoa would make me very happy, but I'm legitimately worried that having to write a port, especially as the last step, is setting myself up never to finish the freakin' thing.

I was going to ask how agonizing it was to make a Win32 port, but I'm almost thinking the only way to figure this out would be to do a port.

C'mon people, this thread was supposed to mean less work for me.

[goMac]

Originally Posted by goMac 

I've run some .Net applications with GUI's on OS X with Mono before, so it would seem it can do GUI's now. I didn't get too far because the .Net application I was running used MSSQL which isn't implemented under Mono.

I remember the catch now. I think I had to run them under X11...

Originally Posted by subego 

Seriously though, C isn't really the leap. It's Cocoa and Win32. I've never had to code an interface. Of course, for obvious reasons, I've never had to write any database handling code either, so I have some good times with finds and sorts to look forward too.

Cocoa is pretty easy to learn IMO. Win32 isn't hard to learn either... It's just painful. Cocoa has some pretty nifty frameworks for dealing with databases, most notably CoreData. I actually get paid to write a Cocoa front end for a MySQL database, and honestly remote databases are the only place I've found Cocoa lacking. I actually just went through and wrote a nice Cocoa/MySQL bridge that lets me use Cocoa concepts like predicates and key/value coding with a MySQL database.

Originally Posted by subego 

Making two distinct versions like you suggest is definitely the "correct" way to do it. Of course, this hits me right in the soft spot in that I'd have to learn two entirely separate languages to do the part I've never done before. Further, since I'm a Mac person (surprise!), the Windows port will forever be the last stage of my development process. In other words, I'm already sick of the project at that point since I've already finished it once.

Generally I build/debug on my platform of choice (Mac), and then every so often move my code to a Windows box and compile it there to make sure it still works. For my software with less complicated GUI's, I just write my code in a way to that the GUI code and backend code is separate.

I think it really depends on the type of application you're writing. If you're writing a utility aimed at a more professional or more geeky audience, they will typically be very forgiving of a Java or GTK program, GTK moreso. At least with GTK, the code is still running natively on the platform, whereas with Java everything is being run in a VM, including your backend.

If you're writing something targeted at your average consumer that's something more complicated than an MP3 player, I would definitely write two different GUI's. Honestly, Safari has to be one of the worst programs on Windows, mostly because Apple forced their GUI in a place where it doesn't belong. Obviously, Safari is a more extreme case. They completely reskinned the app, implemented sheets, and so on, but it still demonstrates my point.

Originally Posted by subego 

It's still very tempting to do it this way. Learning Cocoa would make me very happy, but I'm legitimately worried that having to write a port, especially as the last step, is setting myself up never to finish the freakin' thing.

I think the biggest trap people get themselves into with Cocoa is they write a lot of their backend code in Cocoa using stuff like NSString, NSDictionary, NSArray... I've been working with CoreAnimation and CoreImage recently, so I've been forced to use these types in my backend (It's not like CoreAnimation stuff is portable to Windows anyway), but the best thing you can do is stay away from using Cocoa object types in anything except for your GUI.

That said, Cocoa is a great environment if you do chose to go Mac OS X only and adopt Mac API's like CoreAnimation, CoreData, and others. It might be a more profitable endeavor to put out a really good Mac release than to put out a mediocre Mac and Windows version. I don't know what your situation is though...

Originally Posted by subego 

I was going to ask how agonizing it was to make a Win32 port, but I'm almost thinking the only way to figure this out would be to do a port.

Microsoft has some new tools out that I've seen but not used, and they honestly look like they could make coding on Windows easier. The only issue is that Microsoft's tools always cost and arm and a leg... But I'd take a look at Microsoft Expression. That's the only tool I've seen so far that handily beats Interface Builder.

Microsoft® Expression®

Originally Posted by subego 

C'mon people, this thread was supposed to mean less work for me.

You should know that programming the "right" way is hardily ever the easiest way.

[parallax]

C++ and Qt will allow you to write completely cross-platform code but Qt costs money if you want to write commercial applications.

However, if you're not used to memory management, then I'd stick to Java. A new programmer can learn how to debug Java much more easily than C or Objective-C.

That said, you should learn all the languages mentioned in this thread in addition to LISP. ;-) Every good programmer knows the virtues of several languages.