Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007
Major: Computer Science, soon to be Computational Media
Anything else: Nope
Programming Language Comparison
by Jason Voegele
For the discussion, I read a paper entitled, “Programming Language Comparison” by Jason Voegele. In this paper, Voegele compares and contrast the programming languages Eiffel, Smalltalk, Ruby, Java, C#, C++, Python, Perl, and Visual Basic. After providing the reader with a chart containing several of the features of each language, Voegele discusses several aspects of programming, and breaks down the best languages for each.
Voegele begins by studying the object-oriented capabilities of each language. He states the a true object-oriented language should have encapsulation, inheritance, polymorphism, pre-defined types and objects, all operations defined by send messages to objects, and user defined types as objects. After he breaks down each language, he concludes that only Smalltalk, Ruby, and Eiffel are the only pure object-oriented languages. Java claims to be, but the lack of its basic types as being non-objects prevents it from being purely object-oriented.
The Voegele goes on to discuss static and dynamic typing, generic classes, inheritance, method and operator overloading, higher order functions and lexical closures, garbage collection, and access control in depth, as well as several other programming topics. He also doesn’t have a clear conclusion as to which language is the best; he does provide the rankings from the Caper Jones Language Level study which has Smalltalk, Eiffel, and Perl with the highest rankings, 15, versus Java and C++ at only 6. He does site that the study is flawed since it doesn’t research all of the languages and scores the untested ones based off of its closest counterpart (i.e. Java and C++).
In his discussion, Arcadiy Kantor states that the authors of the paper he read find no clear “best language”, but they do “praise C++ for the flexibility of its function and class template features, but they point out that much of what the other languages accomplish with features C++ is forced to leave to documentation”. Much like the author’s of his paper, Voegele does give praises to languages for their strengths, but also cites their weaknesses and shortcomings.
Part 1: Question 1
A pattern language is a method which names a common problem in design, gives a solution based on a goal, helps the designer move through problems logically, and allows a designer to be creative. Pattern languages are a way for experienced designers to give helpful tips to novice designers without giving an entire solution. Basically, a pattern language is a recipe for design that doesn’t give only one solution.
A design pattern is a template on how to solve a problem that can lead to several different design solutions. In OOP, design patterns usually show relationships between classes or objects without specifying the exact ones which are used. A design pattern is generally divided into one of five categories depending on the type of problem it solves. Those categories are: Fundamental patterns, Creational patterns, Structural patterns, Behavioral patterns, and Concurrency patterns.
The difference between the two is that a pattern language is usually more specific than a design pattern. Additionally, design patterns are more like templates whereas pattern languages are more like recipes. Both help users solve problem, but each one has its own way of doing it.
The pattern I choose to write about was Formula Objects. This pattern helps its user create a report application. The application is suppose to allow the user to enter information and get other information based on formulas. For instance, PROFIT is calculated based on EXPENSES and INCOME. However, the user should be allowed to create or edit formulas. The problem comes with being able to edit and maintain these formulas.
One option would be to use methods for each formula, but this would require that the programmer be available each time a formula is created or modified. The next option would be to have the user input the formula each time they run the applications. This option would be time consuming since some formulas don’t need to be changed at run time.
The solution would be to define an object that represents the results of the formula. This object should be the same type as the object(s) used to create it. Afterwards, define basic formula options that would easily create the Formula Objects (e.g +, -, , and /). There is only one problem with using this method: the solution creates extra objects that could be a problem in the application when more complex formulas are used.
The interesting thing about this pattern is that it reminds me of Excel. Since I deal with Excel on a normal basis, the pattern makes sense because in Excel, a user can define functions and have the application carry them out.
If I had to create an application that called for the use of editable formulas, I would consider using this pattern because it helps break down the problem in a way that makes it easier to program. Additionally, since I wouldn’t have to worry about maintaining the formulas, even less programming has to be done to achieve a reliable product.
Wikipedia: Pattern Languageshttp://en.wikipedia.org/wiki/Pattern_language#UsageWikipedia: Design Patternhttp://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29John Brant and Joseph Yoder: Creating Reports with Query Objectshttp://www.joeyoder.com/papers/patterns/Reports/
One of my major problems with squeak came with editing the class files. On Milestone 2, I attempted to save time by editing TextMorph to resize the text instead of creating a new class. However, since I didn’t know that Squeak essentially built itself, my code messed up TextMorph. As a result, I was unable to edit any code or create new code because since my code had flaws, when I saved, it saved the errors into text morph, giving me errors each time I attempted to type a character. Fortunately, since I didn’t save the image, I was able to shut Squeak down and start over.
Therefore, I had to learn my lesson the hard way and create a new class to test and edit my code. Had I done that first, I would not have had this problem. It wasn’t too complicated, but what seems like a shortcuts may actually be a deceivingly prettier long route.
My advice to you is to NOT save the image file if you edit a standard class unless you are 110% sure that the code works, and will not inhibit you in the future. Also, I would suggest only doing it in cases that actually improve the code versus just editing a class for one particular case.
This post was extremely helpful because I encounter that error at least 5 times an hour and it gets frustrating not knowing what caused it. However, after reading this post, I realize that a simple period (.) fixes it. It seems as though several students have a C/C++/Java background and grasping the period concept is harder than one would think. In addition, the post gives helpful tips which may not only solve this problem, but general Squeak coding problems as well.
Discussion 3 - Derek DeRaps
This is a helpful post because I did not realize all of the advantages of using the Inspect feature of Squeak. I’ve been doing everything the hard way and hadn’t realized that Inspect was so powerful, even though Professor Rick mentioned its power in class (sorry for not listening). I guess hearing it from a fellow classmate makes it more real. Talk about a time saver, Inspect may be one of the top 3 features of Squeak, after Transcript of course.
Links to this Page