View this PageEdit this PageAttachments to this PageHistory of this PageHomeRecent ChangesSearch the SwikiHelp Guide
Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007

Cooper Welch

Hey dudes,

If for some reason, you really truly honestly want to know more about me, you can invite me to your FACEBOOK friends list! There's nothing like FACEBOOK for getting to know people right? Of course I'm right. Well then, I'll see you on FACEBOOK. Lata!

(There's no subliminal message in there, I promise....)



DISCUSSION 1




SOURCE: An Introduction to Programming

Every programming language has what are called “types.” Types form the backbone of the structure of a programming language - all objects in any program, no matter how abstract, can be broken down into component types. Types can represent a wide range of primitive data forms…strings, characters, integers, etc. - they are the basic building blocks that all programming languages conform to. However, when it comes to how these types become implemented and accessed in different programming languages, one can begin to see where languages start to differ and how people’s programming becomes affected.

The first argument presented concerns static types as opposed to dynamic types. Statically typed languages such as ML and Eiffel cause variables to be absolutely declared as one of the primitive data forms. Dynamically typed languages such as Lisp and Python don’t necessarily require a definitive type declaration of variables. Both forms of typing are beneficial in their own ways. Statically typed languages allow for certain errors in programs to be detected earlier, due to the rigidity of what will and will not be allowed. Dynamically typed languages allow for more flexibility and compactness of code, and thus might be useful for prototyping a system.

The second argument presented concerns strong types as opposed to weak types. For strongly typed languages, at any point during a running program, the program is able to know what type a particular chunk of data is. For weakly typed languages, variables are “assumed” to be certain types at compile time, but those assumptions may not necessarily be correct. For example, with C (a weakly typed language), variables might point to different types of data, or even random areas of memory, thus causing the program confusion in understanding what type of object is being referred to.

Programming languages differ in how they combine static, dynamic, strong, and weak typing. People’s programming becomes affected in terms of abstraction of code, speed of coding, and level of understandability. Ultimately, typing becomes responsible for how many programming languages function.

I read Tom Filip’s article on memory allocation, garbage collection, and inheritance. The topics of his write-up further emphasize the relevance of different typing philosophies involved with the structure of programming languages. For example, Tom mentions that with C, it is possible (and often necessary) for the programmer to “precisely manipulate memory blocks, from creation to their destruction.” This would make perfect sense, since C is a weakly typed language. He also goes on to state that with Squeak and Java, “…the user does not have to worry about allocation and garbage collection.” This would also make perfect sense, because Squeak and Java are both strongly and dynamically typed languages.



DISCUSSION 2




Resources used:


Question 1: What are the differences between creational, structural, and behavioral patterns?

Creational patterns are involved with how object instantiation takes place. For instance, a creational pattern might allow a program to create objects when necessary, rather than having the programmer instantiate them all directly. Creational patterns can be broken down into two sub-categories: class-creational patterns and object-creational patterns. Class-creational patterns rely on inheritance to get the job done, whereas object-creational patterns use delegation.

Structural patterns concern themselves with how to strategically group and combine classes and objects so as to facilitate the effective creation of large architectures. For instance, a structural pattern might be most useful when planning a complex user interface or large database system.

Behavioral patterns provide useful means of dealing with how objects communicate with one another. In other words, behavioral patterns can help the programmer define object communication and flow control in a complex program.

Question 2: Describe one design pattern or pattern language in your own words. Again, reference your sources. Explain what interests you about this pattern. Does it make sense to you? Can you see using it in your coding? If so, what for? If not, why not?

The Singleton design pattern is wicked cool. It’s incredibly useful for creating simple, yet effective program structures. Often times when I’m writing a program, I’ll write and instantiate unnecessary amounts of the same class, when in fact, only one instance of the class needs to exist at any given time. By using the Singleton design pattern in my coding, I can solve this problem with ease. According to Wikipedia, “The singleton pattern is implemented by creating a class with a method that creates a new instance of the object if one does not exist. If one does exist it returns a reference to the object that already exists. To make sure that the object cannot be instantiated any other way the constructor is made either private or protected.” In other words, by allowing the class to instantiate itself, only a “single” instance of the class exists in the program at any given time. Additionally, the rest of the program has global access to this class. Thus, any part of the program can access the Singleton class, and only one instance of the Singleton class ever needs to exist. Ultimately, the Singleton design pattern seriously reduces the amount of code that needs to be written, thus making for a less cluttered and effective program.



DISCUSSION 3




Part 1


1. Call me an idiot, but the morphic graphic system in Squeak was a rather steep learning curve for me. Up until my experience with Squeak, I hadn’t ever dealt with an object-oriented language where gui objects could be “embedded into” each other to create greater gui units. All the programming languages I’ve used have simply had pre-made gui objects (such as text labels and buttons) that one just slaps into the program and attaches code to (such as action listeners). The whole idea surrounding how morphic structures can be manipulated and combined was incredibly abstract and took me a while to get used to. To remedy the problem I simply stumbled through code, googled, and read various text materials until I thoroughly understood the concept. Needless to say, it was somewhat difficult at times due to the scarce amount of Squeak documentation available.

2. I consider the browser in Squeak to be incredibly useful. It provides an excellent means for code organization and look-up. For example, if I wanted to see what BookMorph’s code looked like, I could simply open up a browser and search for the BookMorph class. Additionally, the ability to click on a morphic object and instantaneously open up a browser to look through its class hierarchy provides a wonderfully systematic and understandable way of seeing its underlying code structure.

Part 2


1. Jonathan Reitnauer's discussion was extremely helpful for me. Up until reading his post, I had no idea how to add pages to a Bookmorph.
2. Hai Phan's discussion provided me with an understanding of how string equality works in Squeak.



DISCUSSION 4




This entry provides a response to the "Write Smalltalk Code" question posed in the Spring 2002 Midterm Review.

The following is a bit of code that would draw the requested figure (2 rectangles nested inside each other with the string 'CS2340' written in the middle):

pen
pen := Pen new.
pen place: 200@200.
pen go: 100.
pen turn: 90.
pen go: 200.
pen turn: 90.
pen go: 100.
pen turn: 90.
pen go: 200.
pen turn: 90.
pen place: 230@190.
pen go: 80.
pen turn: 90.
pen go: 150.
pen turn: 90.
pen go: 80.
pen turn: 90.
pen go: 150.

'CS2340' displayAt: 280@150.



DISCUSSION 5




CATEGORY: Virtual Machines and Garbage Collection

Q: What is a virtual machine, and what are the advantages and disadvantages of using one for application programming?

A: What is a virtual machine?:

A virtual machine is literally what it says it is: a virtual machine. It is a piece of software that creates an emulated environment on a computer's operating system in which a user can run software applications. In other words, a virtual machine is a piece of software that runs other pieces of software, effectively isolating them from the computer itself.

A: What are the advantages of using a virtual machine for application programming?:

There are several major benefits to be had from using a virtual machine. First and foremost, a virtual machine makes object oriented programming much easier. Objects are intrinsically complex things...it thus becomes much easier to let a virtual machine handle storing things in object formats, rather than having to deal with things in primitive types. Secondly, virtual machines grant a great deal of portability, because they allow applications to run platform-independent via binary compatibility between platforms. Third, virtual machines provide the programmer with efficient memory management capabilities, such as garbage collection. And finally, by using virtual machines, applications can often be made safer. Since virtual machines run independent of the computer's core, extra security measures can be implemented that allow for the possibility of avoiding viruses and bugs that would otherwise crash one's operating system.

A: What are the disadvantages of using a virtual machine for application programming?:

While virtual machines have many benefits, they also have several disadvantages. First, there is a distinct speed issue. Every instruction in a virtual machine application must be INTERPRETED rather than directly run on the hardware, thus making VM programs slower. Secondly, because a program running in a virtual machine isn't compiled directly to a real machine's instructions, a VM can often have difficulties with optimizing a program for use with a specific piece of hardware. And finally, compilation of large programs can simply turn out to be a pain. This last point could also be considered a speed issue - there is always a two-stage compilation process: once for compiling a program to the VM instruction set, and another for compiling at run-time to the REAL instruction set.




Link to this Page