History and Comparing Programming Languages – by Dennie Van Tassel
http://www.gavilan.edu/csis/languages/history.html
Composed with many personal research data about the differences between major programming languages of modern day, Dennie Van Tassel presented a four section paper about the history and comparison of currently popular languages. With his comparisons on comment symbols, the use of literals, and parentheses, we can see that there is a great variance between different programming languages which can pose certain disturbances to young programmers like me, who is trying to memorize the right syntax for an error-free executable block of code.
For instance, while assembly languages use semicolon (;) as an end-of-line comment syntax, C++/Java use double slashes (//) and TCL/mySQL use hash sign (#). Most of the time, we can just use a reference book to pick out the right syntax for the desire language we want to code in. However, if we want to crunch out a 100 line of codes in mySQL after having inspected a 400 line long Java program, we may have a headache pretty soon. Moreover, in many functional languages, such as LISP in particular, the use of parentheses may also confuse beginning programmers and/or the code inspectors a like. Unlike Java/Visual Basic where methods are enclosed neatly within visible blocks, a simple method in LISP may end up with 7 seven sets of closely packed parentheses as in the following example:
(defun factorial (x) (if (eql x 0) 1 (x (factorial (-x 1))))) ))
This can bring nightmares to a novice programmer who may have mistakenly misplaced a closing parenthesis somewhere in the code when come the time for debugging.
Overall, there are numerous acceptable reasons for differences in syntaxes of many today popular programming languages. Some blamed on missing characters of those old keyboards back in the early days of their creations, and some blamed on mathematical notations they inherited. Nevertheless, their distinct different representations for similar syntaxes among them make learning and mastering programming languages harder, if not impossible. I think we should have a set of standards for these, so called user-friendly, programming languages to extend from so that learning these languages in the future can be easier (that is easier to remember their syntaxes).
As Pree, Coplien, Schmidt and Buschmann, described design patterns, they are a set of common rules which used to describe how to accomplish certain tricky tasks during a software development’s process. In particular, they focus more on reusing recurring architectural design themes which could help to simplify many detailed designs and implementations. Bushmann said that “a pattern [addressed] a recurring design problem that [aroused] in specific design situations and [presented] a solution to it.” In my personal experience, design patterns do prove to have some crucial roles in helping a developer in the process of updating his design for higher efficiency and easy implementation.
On his WikiWikiWeb page, Joe Bradley described twenty-three of well-known patterns as three distinct categories of patterns (namely GangOfFour caterogories). Those included creational, structural, and behavioral patterns. Even though he had many extended pages described those 23 patterns, his descriptions for the 3 categories are somewhat vague and too hard to picture the differences between them. Here are additional information I found on the internet and my understanding about their unique characteristics.
According to Joe, creational patterns made up a category of
design patterns discussed in the GangOfFour which is
used to organize patterns that portray “a system based on the classes of object
[they created].” In other words, they are “patterns for dynamically selecting
the class of created objects.” What does this mean? Well, according to a few
short descriptions of patterns categorized under this group written by Data
& Object Factory, it is just a group of patterns which housed the following
characteristics: being able to create a unique instance of several related
classes, derived classes, and/or a singleton class that can exist throughout a
project. It also involved in the process of separating the object’s
construction from its representation and being able to initialize an object’s
instance which can be copied and cloned latter as needed. To demonstrate these
patterns, the following diagram is taken from a Factory Method’s description
page. A factory method can be used to give the program an ability to create
instances of existing classes at will.

The second
category is composed of structural patterns. All patterns in this group use
various mechanisms to construct code and assemble their objects such as using
matching interfaces, tree structures, and mirror objects for presenting an
entire subsystem or just to improve efficiency in data sharing between classes.
For instance, a bridge pattern can be applied to separate “an object’s
interface from its implementation.” On the other hand, a decorator can be used
to give additional responsibilities to currently active objects of a system in
a dynamical way. With a composite design, clients can treat individual objects
uniformly since they are structured as a tree hierarchy where each child’s
object must modify a certain operation in a component class.

The third
category is behavioral patterns. Some patterns in this group are designed so
that the formations can describe how their objects collaborate to perform some
tasks that required a group effort. Others use inheritance to display their
flows of control throughout an execution process. For instance, accessing
elements in a collection sequentially and being able to capture and restore an
object’s internal state are the two key characteristics of iterator
and memento designs. Also, a state design can change an object’s behavior
according to its state change, and an observer design can be used to update
information throughout all of its related classes when there is a change
triggered by one of its objects.

Singleton
pattern was a design I had used in the past with great success. This pattern is
a design which used only on static class to let the program initialize one and
only one instance of that class throughout the whole execution process. By
creating an instance of this static class, multiple classes can access any
information and methods that are provided by the class without worrying about
any restriction of access, especially in the case where there are multiple
levels of control take place in a program’s hierarchy. This pattern can give
the developer a great freedom in designing a system where there is a central
control point which information can be distributed throughout any other clients
without the complexity of multiple inheritances. This design can be used in a network
based structure. In this situation, a server can have multiple running programs
which require access to a single communication channel can send and receive
data from different clients without worrying the holding up of com link unexpectedly
by an object somewhere. Also, for a central database, a singleton class can
also be very useful. This design could provide global access to its database to
multiple applications without the lost of accuracy and updated information.

References:
http://c2.com/cgi-bin/wiki?DesignPatterns
http://www.cs.colostate.edu/~bieman/Pubs/McnattBieman01.pdf
http://www.dofactory.com/Patterns/Patterns.aspx