Java? C? or C++?

[zylr]

Ok, another one of those what language questions...
I know Python and PHP. Im looking for a new language that has a big, steady community. I do not want an interpretated language. So, i thought that left me with C, C++ and Java.
So, i want feedback on these languages. Im interested in doing GUIs, and well, JFC looks like 'ugly code', but i have only even seen code, never attempted to write it. But C++ and C have a huge overhead for this (and, an non-platform indenpendent one).
I also need a language that will remain popular... But, i guess thats what everyone wants.
So, what do you think? What other languages match this criteria?

Thanks,
Zylr!

[Twiggy794]

Java has it's weaknesses, speicifically Swing which is ugly imo, and it's pretty slow. However, if you want to be able to develop applications quickly, it's a pretty solid language. Your other alternative from that would be to learn C#/Mono and get into more GTK related developement, all the while maintaining the simplicity and speed of developement of Java.

C/C++ are a bit difficult to learn, but powerful. Personally, I don't like spending hour upon hour writing code and having the least amount of productivity. I love coding in C++, but I'm impatient, so I prefer C#.

[zylr]

i thought that MONO was in early beta...
but, could C# be the next BOOM? Microsoft says yes, and Microsoft has the money to do anything... But i still think that C# is a ripoff of Java.
Can i do GTK from Java?

[crackers]

Originally Posted by Twiggy794

speicifically Swing which is ugly imo

Advantage: custom look and feels. You would not believe how customizable it is. Bad thing is that to get it really popping, you have to get real deep into LnF. Good thing is there are already people hard at work providing some very nice LnFs - heck, there's even one that looks like it was drawn on a paper napkin!

and it's pretty slow

Actually, that's a common misunderstaning and hold-over from previous versions of the JVM. With 1.4+, there was a performance increase of over 25% in Swing. The other part of it is you really have to know how to write the UI, not just slap it together. The OO-ness (for lack of a better term) and the threading behind it have to be well understood - and you can get durn close to "native" performance.

C#/Mono and get into more GTK related developement, all the while maintaining the simplicity and speed of developement of Java.

Minus the pretty-close-to-true cross-platform capabilities of Java. But if that aspect isn't important, then it's a non-issue (I do have doubts about M$ staying quiet forever on this project).

C/C++ are a bit difficult to learn, but powerful.

One word: memory-management. That's where Java and C# kicks C/C++'s arse.

[PompeyBlue]

Originally Posted by crackers

One word: memory-management. That's where Java and C# kicks C/C++'s arse.

Depends how you want to manage memory. If you are running on a system with virtual memory, megs of ram, and a vast harddrive then java does indeed help with this.

However if you are on a lower spec. system, without virtual memory (i.e. the current generation of games consoles) or you want to write efficient real time code, then java's memory management sucks badly. You need to control everything and ensure that it's sat within a memory block, java makes this much, much, harder. It's garbage collection, effectively takes away control.

Personally, I wish PC/VM programmers would learn decent memory management, then my PC wouldn't chug as soon as they start hitting memory. I can understand needing a GIG of memory if you are running LOTS of different applications at once, but to require it for a single app ????????

[crackers]

Remember: use the best language for the job, not vice-versa. If you have limited footprint and/or a real need for speed, then, yes, C is about the best "high-level" language for that. If you want pure number crunching, use Fortran. If you want a scalable, clusterable, "Enterprise" class server, you use Java. If you want really tight system integration, use C#/.Net

Originally Posted by PompeyBlue

ecent memory management, then my PC wouldn't chug as soon as they start hitting memory

That's actually an issue in ANY language. There's all sorts of "gotchas" in terms of bad memory management, both in bloat and "re-use" (long horror story omitted here).

[Shadow Skill]

hehehe, I hope my school teaches me C#, I am definetly not good at teaching myself stuff I get distracted way to easily, I need to force myself to go to a building and learn...(This is the only way I am managing to do so well in college.)If they don't I will need to find a place that offers such a course and go there after I am done with my BA.

I hate Java I took a look at some of the code back in high school and it was coded by a total crackhead only BASIC is worse since there is no real control structure, you can't follow any long programs in BASIC. Java has the control structure but the commands are sometimes overly long..taake a look at the print statement it is something like

 system.out.printf();

would you rather type that or type

printf("...."); or cout<<"...";

come on...

One thing about C++ is that gui programming looks quite scary, it doesn't look very simple or easy to learn after reading it 10 times..(which is normal for me.)

[crackers]

Originally Posted by Shadow Skill

I hate Java I took a look at some of the code back in high school and it was coded by a total crackhead only BASIC is worse since there is no real control structure, you can't follow any long programs in BASIC. Java has the control structure but the commands are sometimes overly long.

Just looking at the code won't teach you a damn thing about the language. And C# is just like Java in many, many respects. Just as Java built on languages like Smalltalk and C++, C# took many concepts and patterns from Java, as well.

You have to understand that:

1) Java is an OO-style language - if you don't know what OO is, then you have a steep learning curve (and the same for C# and C++);
2) it's primary I/O is not console-driven. The same is true for C#/.Net - you're in for a rude surprise.

Just because something appears easier to write doesn't make it that simple in practice.

[Daverz]

Originally Posted by zylr

Ok, another one of those what language questions...
I know Python and PHP. Im looking for a new language that has a big, steady community. I do not want an interpretated language. So, i thought that left me with C, C++ and Java.
So, i want feedback on these languages. Im interested in doing GUIs, and well, JFC looks like 'ugly code', but i have only even seen code, never attempted to write it. But C++ and C have a huge overhead for this (and, an non-platform indenpendent one).
I also need a language that will remain popular... But, i guess thats what everyone wants.
So, what do you think? What other languages match this criteria?

Thanks,
Zylr!

I assume you wanted to pick up something new, or are you dissatisfied with Python? My own preference for GUI apps is PyGTK:

http://www.pygtk.org/

As for JFC (Swing) having ugly code, I think the API is actually pretty nice. Maybe it's Java itself that seemed ugly, something I can understand; it's a somewhat half-assed language, but one with a great community. Swing is slow (I'm judging this by SwingSet2, a demo app written by Sun, running on jdk 1.4.2 or 5rc1; watch the buttons slowly being painted in), not very attractive (though the look & feel is getting better), and a huge memory hog, things that give me pause before subjecting users to it.

There is an alternative: SWT/JFace is simpler, lighter, better looking, and faster than Swing, though it has fewer features. It uses native widgets wherever possible, so you actually get the platform look & feel that users expect. It's the toolkit used by Eclipse, so it works everywhere that Eclipse does.

You can also do Gtk programming with Java. See the bindings page at http://www.gtk.org

For C vs. C++, I'd definitely go for C++ for GUIs. With modern techniques (e.g. the STL), C++ is probably not too bad. But I try not to subject myself to either, so my opinion is not very authoritative.

[crackers]

Originally Posted by Daverz

Swing is slow (I'm judging this by SwingSet2, a demo app written by Sun, running on jdk 1.4.2 or 5rc1; watch the buttons slowly being painted in), not very attractive (though the look & feel is getting better), and a huge memory hog, things that give me pause before subjecting users to it.

I want whatever you're smoking! The SwingSet2 demo dynamically loads everything, so it's not necessarily a good judge of how "fast" Swing is - plus it's loading a lot of crud that you won't always be using - it's a demo of features, not speed. If you want to see a really fast pure Swing app, look at JetBrainz' IntelliJ IDEA development environment.

SWT/JFace is simpler, lighter, better looking, and faster than Swing, though it has fewer features.

It is also an extra download (12 Mb?) over the JRE/SDK (which includes Swing), is a royal PITA to use (and people complained about AWT!), and yes, it has "native" integration - which won't do you a damn bit of good if you want your app to look and work the same across all environments (aka "Look and Feel"). Yes, I use Eclipse as my IDE, but I don't write apps in SWT - I want full control over how the app looks and, being a KDE user, I don't want it to look like GTK...

As far as memory footprint goes, a lot depends on the application. With a good Swing application, the application footprint isn't all that much over the JVM. With SWT, if you exclude the JVM, there's the SWT footprint (a couple of Mb right there), then you add in the app. This technically (yes, it's a nit-pick) means that Swing actually has a smaller footprint.

My main point is it's not necessarily the toolkit you use to do UIs, but how you do the UI itself and work with the toolkit. I've written applications using both Swing and SWT and, because I know Swing better and how to make it work fast, the Swing app has "close to native" response times and the SWT app swallows twice as much memory, just due to the extra loading of the native bindings and their ... interesting ... UI model.

[Daverz]

I can only judge Swing by the apps I've seen, and they tend to have a sluggish feel. I've also seen this special pleading before that all these apps are just coded incorrectly. As for SwingSet being a demo, well I don't see other GUI demos behaving that way.

I plan on writing a prototype app Swing to see if performance is decent enough for my purposes.
It won't matter much to me that some hypothetical programmer can get good performance out of it if I can't.

[jcstille]

I like Java. It provides for easy code management through the forced OO-ness (as stated previously). The code is very reusable, now this can be done in C++, but is more difficult. Embedded systems are using Java more and more. The options contained within Java code are awesome. Lastly, API. What a great resource. That alone can tell you soo much. I am biased, but have programmed in both. If you had this option, you could learn C++ and then go to Java, not too bad of a transition.

[crackers]

I resent the fact that you call it a "pleading." I state what mine own eyes have seen and what mine own fingers and brain have crafted.

As for SwingSet being a demo, well I don't see other GUI demos behaving that way.

I don't see that. Yes, it loads slow (it's loading quite a lot of stuff!), but it's quite zippy once it's loaded on my boxes. And it's not optimized for speed. It's just there to show off the various widgets and what you can do with them.

Originally Posted by Daverz

It won't matter much to me that some hypothetical programmer can get good performance out of it if I can't.

That's entirely fair - but, as I said, there's a difference between just putting a UI together and knowing how to really make it work well. (The trick is understanding and managing threads, by the way.) Don't expect native-like performance without a bit of work.

I'm trying to decide if I should resent being called "hypothetical." I'll get back to you on that...

To build one quickly and make it look almost exactly like you want it, I would strongly recommend the VE plugin for Eclipse. I never could get GridBagLayout to do what I wanted (some sort of mental block I guess), but I've been messing with it for a few days and it does extremely well.

I will grant that it does take more work than being able to construct a fast UI than some native toolkits - heck, you can slap a Tk/Tcl UI together in practically zero time. But, again as I said, if you're more interested in some theoretical speed, it's probably not for you. Just remember that if you're writing a typical UI app, most of the application "time" is not spent in the CPU: it's in the slow response of the human using it.

[Daverz]

Originally Posted by crackers

I resent the fact that you call it a "pleading."

You're being a bit over-sensitive for a guy who says things like "I want whatever you're smoking!".

I'll give VE a shot. I also like the XML approach to doing layout. CookXML looked nice.

As for threading, it doesn't bode well that the O'Reilly monkey book doesn't talk about it until page eleventy hundred something. BTW, is there a better book, that one throws way too many details at the reader.

[crackers]

Originally Posted by Daverz

You're being a bit over-sensitive for a guy who says things like "I want whatever you're smoking!".

Point taken - and, yeah it is a bit of a sore spot. (Although I will *ahem* plead the fact that I followed the remark with a smiley... )

I'll give VE a shot. I also like the XML approach to doing layout. CookXML looked nice.

It'll do the layout and give you the UI framework to work within, but it won't do the threading support you'll need for complex operations. Warning - it does add quite a bit of overhead to Eclipse. Between that and two other monster plug-ins for Eclipse, I have finally managed to slow my Athlon 2100 down enough to justify a mobo/processor upgrade. Oh, darn.

Haven't seen or heard of CookXML - guess I ought to check it out.

As for threading, it doesn't bode well that the O'Reilly monkey book doesn't talk about it until page eleventy hundred something. BTW, is there a better book, that one throws way too many details at the reader.

Well, kinda in their defence, threading is not really a "beginner" topic. Heck, sometimes it still makes my head hurt!

Y'know, I can't honestly recommend any book on Swing - I've been using Java for so long and picking up the stuff on-line for so many years, I never even bothered with a book. Although I have seen excerpts from "Head First Java" and have read some glowing reviews about being able to get into the nuts-and-bolts quickly.