Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007
Blake Israel 2 Discussion 1
Smalltalk-80 vs. C++ vs. Java
The article I chose can be found at: http://www.approximity.com/ruby/Comparison_rb_st_m_java.html
Because the article appears to be from a Ruby biased site, I have chosen to use the information they provide and compare anything but Ruby.
Therefore, I will compare/contrast Smalltalk-80, C++, and Java.
- Java and Smalltalk both provide access to the names of Objects, variables, etc. during Run-Time, whereas C++ does not.
- The main reason for C++ not prividing this support is Speed. Though the flexibility that Smalltalk and Java gain by supporting this feature may outweight the speed benifit in some instances (i'm thinking code that writes code).
- Smalltalk provides only for single inheritence, C++ provides openly for multiple inheritence without protection, and Java provides a unique blend, allowing only a single truly inherited object, but allowing for the definition of interfaces which provide requirements for the new Object to implement, but leave out the implementation.
- Once again, C++ does what it does for speed, it also does multiple inheritence because that can actually be more flexible, though dangerous. Java and Smalltalk are going for a more pure OO approach, Java achieves multiple inheritence throught the Interface trick, and still protects from badly used multi-inheritence.
- Both Smalltalk and Java have a root object (i.e.: Object), whereas C++ does not have any root type object.
- I can't really find exactly why this is, but it is interesting to think about. I'm sure C++ is only this way because it came about as an extension to standard C. It does have some interesting implications in that no object is ever gauranteed that any other object outside of their tree will be able to support any method.
- While all 3 may have hidden (private) data variables, only Smalltalk-80 may not have privatized methods.
- First of all, you are not allowed to have public variables inside Smalltalk objects. This is because that would violate the encapsulation principle of OO.
- Secondly, from what i've seen you can play nasty tricks to get smalltalk objects to change themselves and become other objects that don't have certain methods. But I don't really understand why Smalltalk lacks private methods, and I haven't been able to find secondary sources on the issue either.
- Here is a good article on a theory http://wiki.cs.uiuc.edu/VisualWorks/Smalltalk+and+private+and+public+methods
- C++ also lacks garbage collection capabilities, whereas they are abundant in the others.
- This is also somewhat due to speed concerns of the designers, also because they were extending C which already had a whole memory management scheme going on. They wanted normal C code to comple in a C++ compiler and therefore needed to keep intact malloc, et. al.
- C++ and Java support primatives, whereas in Smalltalk even integers are objects.
- C++ goes for speed. (and was extending C)
- Java was mimicking C++, but at the same time also probably desired speed.
- Smalltalk tries to be as OO as possible, and this wouldn't be possible without making the numbers objects. Though the compilre/interpreter has to do some magick to actually get some computation done. But to the programmer they appear as Objects.
I think David Shirley does an excellent job of describing the impact of encapsulation on the programmer. The fact that Smalltalk enforces very strict OO policies can be somewhat of an annoyance, but overally may lead to better design. Where languages like Java and C++ let you run wild with the scope of everything. Unfortunately, Smalltalk excludes certain design patterns by doing this. Such as singletons, where the programmer needs to hide the ability of another to instantiate that class, and provides a method instead that retrieves a single instance. In this way Java and C++ are more flexible in the design patterns they can produce, but at the same time, can be much more destructive in the way they are used (i.e.: in creating sloppy, bad designs).
Respond to my discussion:
Links to this Page
- Fall 2005 Discussion 1 last edited on 21 October 2005 at 9:47 am by penguin.cc.gatech.edu
- Blake Israel 2 last edited on 30 September 2005 at 12:43 pm by lawn-199-77-209-58.lawn.gatech.edu