Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007
Discussion 1 - Amro Mousa
Since the article is rather long, I'll focus on just a few of its main points:
- Built-in Security
- Memory Management/Garbage Collection
Interestingly, Each of the languages discussed support multithreading capabilities except for two: Perl and Visual Basic. Of the others, all of them either offer support inherently, based on implementation (i.e. some versions of SmallTalk do not), or via external libraries, such as C++. Ruby, in particular, offers completely self-contained threading capabilities, allowing it to exhibit these features in platforms that do not support threading, such as MS-DOS. This does, however, have the major side-affect of halting the terminal if a system-level call is made. This has the potential of lifting a slight burden off a programmer required to code for an older platform, such as those working to produce software for industrial fields.
Java, Ruby, and Perl provide "out of the box" functionality in this area, preventing many of the security mishaps that have been exploited in other languages, such as ActiveScript. This again lifts the burden off the programmer and allows them, to some extent, to focus less attention on security when coding particular applications, such as Java applets, and more on the functionality of those applications.
Memory Management/Garbage Collection
C++ forces the developer to handle all memory management. This is a mixed blessing. It allows for a developer to write a lower-level application while maintaining a pseudo-object oriented structure. It also has a speed benefit, but can cause issues when used improperly (i.e. reading past the end of an array, etc.). Both SmallTalk and Java offer garbage collection, this functionality lifts the majority of the burden off of the programmer regarding memory management. It is, however, still possible to generate a memory leak through the improper handling of references to objects no longer in use, so this functionality is not 100% effective and it cannot be.
http://www.jvoegele.com/software/langcomp.html receives credit as the source of my information.
Reflections on other posts: Derek DeRaps' post
"During initialization, C and C++ run three to four times faster than Java, and five to 10 times faster than the scripting languages."
I would venture to say that the author's experience is anecdotal (not Derek, but the author of the article). I work as a part-time developer for a major telephony company here in Atlanta. Our software is mainly Java based, and our competitor's software is mainly C++ based. Our software performs just as well as theirs, call to call, etc. This maybe anecdotal evidence as well but my point is that while C++ is certainly faster, 300-400% is not likely in the majority of applications and that much of the performance burden lies on the application design and implementation strategies used in the application.
This discussion post is also available at my Who's Who page: http://coweb.cc.gatech.edu/cs2340/4330
Links to this Page