PDA

View Full Version : Java? C? or C++?


zylr
20th September 2004, 10:40 PM
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
21st September 2004, 12:10 AM
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
21st September 2004, 12:16 AM
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
21st September 2004, 05:20 AM
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
21st September 2004, 01:53 PM
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 ???????? :eek:

crackers
22nd September 2004, 04:22 AM
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

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
22nd September 2004, 05:55 AM
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
23rd September 2004, 06:11 AM
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
25th September 2004, 07:24 PM
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
25th September 2004, 08:42 PM
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... :D

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
26th September 2004, 02:57 AM
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
26th September 2004, 04:22 AM
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
26th September 2004, 06:08 AM
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.

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... :D

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
26th September 2004, 09:23 PM
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
26th September 2004, 10:42 PM
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... :D)

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.

PompeyBlue
27th September 2004, 03:03 PM
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).

Absolutely, but still, there's stuff you can do to eliminate that. Even stuff, that's not that hard, and when done right you get far superior performance.

I guess PC/VM coders don't really care, since they can leak memory all they want and the VM will catch it. You can use gigs and gigs and gis, and the VM will just handle it.

Maybe all PC code should be FORCED to sit on 128Mb. WE MUST HAVE DISCIPLINE :D

PeTzZz
27th September 2004, 03:48 PM
I think that if you know what are you doing then it's not so hard do make GUI in java, but if you don't then it's very painful. It just needs some experience.

GreyGeek
27th September 2004, 04:32 PM
...
I know Python and PHP. Im looking for a new language that has a big, steady community.
...
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 take it from your Python and PHP experience you already have the fundamentals of programming down, at least with scripting languages.
Java, too, is a scripting language, but after your experiences with the ease, power and speed of Python, you'll be disappointed with Java. I was. For example: one application I wrote, for internal use in our org., was coded several years ago using Visual Fox Pro 6.0. We decided to take our development efforts off of WinXX dependent tools. Our first step was to move the database to Oracle. Then the company sent us all to classes on Java, which were very good, I should add. The instructor's programming environment was a simple text editor, not IDE, not GUI RAD. For simple apps that worked fine, but for complicated tab paging with 30+ controls on a tab it became a nightmare. The default layout didn't cut it and the XYLayout was a total pita. I tried several Java IDE's and GUI RAD tools and settled on trying to develop the app in JDev because Oracle customized it for their databases.

After 20 weeks of development I had an app that approximated the VFP app, but was slow, and hard to use from a data entry POV. Also, much of the functionality I wanted to impliment was thwarted by warnings ("DO NOT EDIT THIS MODULE") in the base modules I needed to modify. MUCH TIME was wasted trying to figure out which, of the nearly 4,000 classes, was the one I needed to solve a particular problem. The JAVA API is not much help in explaining how and in what situations a class's properties and methods can be used. After Python's docs you'll be disappointed with Java's API. Resorting to several big books on Java development for andvanced help and examples which approximate what you want to do is only partially helpful. Basically, give yourself at least 9 months to a year to come up to speed in Java development.

I also tried JBuilder but didn't like Borland's attitude about updates and patches. Nothing had changed since I had purchased Kylix a few years ago and ran into that "support" stone wall head on.

So, I decided to try Python and Boa_Constructor. It was wierd ... the Boa_Constructor GUI RAD tool was looked somewhat similar to the VFP environment, but not nearly as sophisticated. However, within 5 weeks, while learning how to use both Python and Boa_Constructor, I had a lightening fast application that was nearly identical to the VFP app and which ran even faster! It was 5X to 10X faster than the Java app! Further, I could edit base modules and my changes would stay when the module was recompiled, even if I used the GUI interface to change the modules behavior! As an bonus, I discovered that by changing only a couple of lines I could run my app against a PostgreSQL database that was ported from the Oracle db. PostgreSQl ran just as fast as Oracle and was easier to maintain using pgAdminIII (which has both WinXX and Linux versions that look and feel indentical!). Programming in Python using Boa_Constructor is as easy as falling off a log. One neat feature is that the Python code, even for the GUI of the app, is all ASCII and with Subversion or Arch code versioning is a snap. (Try to do code versioning of a VFP GUI app. The STEXT.PRG module still can't pick all of your methods out of the GUI binary, so comparing previous versions and/or branches is a pita too.)

However, one of your requirements causes me to recommend C++, with the very latest version of KDevelop as the GUI RAD tool. You KNOW that GNU C++ is not going away, so the time you invest in learning it will not go away. How do you know that? Because EVERY dev tool you can think of is/was developed mainly with C++ somewhere down the development chain. KDE and KDevelop is not going away. A third component, the QT widget set, is not going away, and if TollTech does die, a licensing agreement makes the QT widget set GPL forever. So, for internal development (otherwise you'll need a QT license) its C++ on KDevelop using the QT widget set. To give you an example of how fast development is under KDevelop: I can develop a data entry screen against that PostgreSQL db I mentioned earlier in under a minute, using a template that QT supplies! Merge that into the framework I selected for the KDevelop project and I have a working ELF execuatable in two or three minutes.

You won't go wrong investing your time and talents in C++, Linux and a good GUI RAD tool. And, IF none of the GUI RAD tools I've mentioned survive, your skill set in C++ will do you well in any other programming environment/OS.

jcstille
27th September 2004, 05:43 PM
I agree with the quote that "You won't go wrong investing your time and talents in C++", but don't discount java. People are moving, college students are learning all of their programming in Java, and so industry might just have to shift (not that I am saying other programming langueges will be gone), So I always recocomend learn both, thats what I did. Just in case.

crackers
28th September 2004, 03:50 AM
Java, too, is a scripting language
Sorry to disappoint you, but Java is not a scripting language. Script-based languages run "as is" with no compilation steps; Java requires compilation before running. It is interpreted, but the JIT and HotSpot compilers really start blurring the line between interpreted and fully-compiled to machine code.

I'm sorry you had a bad time with Java, but it's not a language that you can just jump in and start programming with to create beautiful and super-responsive UIs with. There is a learning curve and you can't learn it from reading the APIs. Your time-line of 9 months to a year is fairly accurate for someone who's not had OO experience. To get to some real UI speed, you'll have to probably invest another 3 months of learning and tweaking to get the real feel for threading, which is usually the major issue with Swing UIs.

I guess PC/VM coders don't really care, since they can leak memory all they want and the VM will catch it. You can use gigs and gigs and gis, and the VM will just handle it.
Until it bites you, that is. Then you get to learn about garbage-collection, weak and phantom references, and all sorts of other esoteric stuff... When you work at "advanced" levels (like in J2EE), you have to keep that information at your fingertips, as well as threads, ClassLoaders, and ... let's just say you get acquainted with the internals of how the JVM works, for better or worse.

PompeyBlue
28th September 2004, 02:48 PM
Until it bites you, that is. Then you get to learn about garbage-collection, weak and phantom references, and all sorts of other esoteric stuff... When you work at "advanced" levels (like in J2EE), you have to keep that information at your fingertips, as well as threads, ClassLoaders, and ... let's just say you get acquainted with the internals of how the JVM works, for better or worse.How can VM bite you ? Surely it's a function of the OS rather than the language you are using ?
The only time it's really hammered me is when I ported VM "assumed" code to a non-VM target. I still bear the scars :(

crackers
29th September 2004, 04:47 AM
How can VM bite you ?
Custom ClassLoaders are a good example - the VM is, after all, just another program and, as such, can be abused by the API itself. As an example, my first home-built custom ClassLoader had a programming error and ended up being recursive, which meant that GC was effectively disabled. This actually happened so quickly the VM literally crashed instead of throwing OutOfMemory errors.

Another "gotcha" is working with JNI - our WebLogic servers kept crashing until we figured out that ImageMagick (which we were using for image manipulations at the servlet level) had a "exit(0)" buried in many places. Hit one of those and *poof* - no more VM.

PompeyBlue
29th September 2004, 12:06 PM
Custom ClassLoaders are a good example - the VM is, after all, just another program and, as such, can be abused by the API itself. As an example, my first home-built custom ClassLoader had a programming error and ended up being recursive, which meant that GC was effectively disabled. This actually happened so quickly the VM literally crashed instead of throwing OutOfMemory errors.

Another "gotcha" is working with JNI - our WebLogic servers kept crashing until we figured out that ImageMagick (which we were using for image manipulations at the servlet level) had a "exit(0)" buried in many places. Hit one of those and *poof* - no more VM.
Ahhh, I guess I work on the assumption that VM works. I.e. if you run out of memory it will return NULL pointers for any further malloc, or that exit(0) doesn't kill VM. Which of course, it shouldn't.....

Yes, buggy VM, or middleware, isn't fun :(

crackers
30th September 2004, 05:38 AM
It's not buggy - it's just not perfect.

The Java VM will start pumping out OutOfMemoryErrors when there's nothing left to allocate off the heap. The nice thing is that, unless you're being extremely dense (like I was), the VM and application can recover from this if you leave 'em alone and don't keep doing stupid things. The GC thread just needs a chance to run - and it needs references to collect for re-allocation.

And an "exit(0)" in any native code actually raises a signal, which by definition cannot be ignored by the process manager, to terminate the process immediately. The VM, in the case I mentioned, simply had nothing to do with it - it did what the process manager told it to do: DIE!

zylr
2nd October 2004, 04:13 AM
ok, its between java and python... argggg, python is nice and simple and becomming widely accepted (YUM and other Fedora thingys are written in it). But java is defently more popular.
AHHHHH!

crackers
2nd October 2004, 05:18 AM
Ain't programming just grand? All these choices...

The really neat thing is after the 4th or 5th language, they all just become "another fscking language to learn." I've forgotten more programming languages than I currently use - couldn't write a line of Fortan to save my life right now... ;)

Jinnah International Airport