CHAPTER 2 - R. SEBESTA

Assignment #2
Lecturer : Tri Djoko Wahjono

Review Questions (16-20)
16.  In what way are Scheme and Common LISP opposites of each other?
 Common LISP allows for static scoping and dynamic scoping Scheme only uses static scoping. Scheme is relatively small while common LISP is large and complex .

17. What dialect of LISP is used for introductory programming courses atsome universities?
Scheme

18. What two professional organizations together designed ALGOL 60?
ACM and GAMM

19. In what version of ALGOL did block structure appear?
ALGOL 60

20. What missing language element of ALGOL 60 damaged its chances for
widespread use?
The lack of input and output statements with formatting


Problem Set (14-20)

14.What are the arguments both for and against the idea of a typeless
language?

The main Point is about Typeless language allowing more flexibility but it also can create an ambiguity as to the contents of a variable. Ambigious languages can cause trouble and misunderstanding among people.


Arguments for the idea

Flexibility, Brevity of syntax. It places stricter controls on what objects can receive and send, so making it easier to enforce design strategies throughout the application. When there are errors in types, there can be picked up during precompilation or in the IDE.

Arguments against the idea:

Without type checking, there is no means to verify the integrity of Without type checking, there is no means to verify the integrity of the data without executing the application. The syntax of typed languages can be viewed as overfly long or verbose. Typed languages aren't as flexible as untyped languages, as data structures need to be cast to the correct type before another object can receive them. it is also said that by using typed languages, the compiler spends less time dynamically typing objects and so executes faster. However, this point is a grey are and that the main area of argument is how these language differences play out when designing applications where more then a few people are working on the code.


15. Are there any logic programming languages other than Prolog?
Yes, there are SQL,Visual Basic, etc .

16. What is your opinion of the argument that languages that are too complex
are too dangerous to use, and we should therefore keep all languages
small and simple?

I strongly disagree with that  argument about "Languages that are too complex", I think Programming languages are not dangerous at all – in case that the programmers who use the language knows exactly what he / she is doing. High complexity means that the program will be more than simple coded programs, as complexity is defined as orthogonality. There is no use in keeping all languages small and simple. Since if there’s a languages which we use are complex, people just don’t have to use it as standard. Instead, they can use simple ones as the standard.

17. Do you think language design by committee is a good idea? Supportyour opinion.
Language design by committee definitely has its advantages, with varying points of view from different domains, different programming backgrounds, and even different language backgrounds all contributing for the better of the language.

For example

By 

-- Pat Pitou

FWIW, the Mythical Man Month has a list of things designed by one or two individuals (C, Lisp, Unix were on that list), and a list of things that were designed by committee (MSDOS, COBOL were the only two I could remember) and pointed out that the ones that inspired the most passion were those designed by individuals. I can't remember what Brooks said about the design-by-committee products, though. I thought it was an interesting point.


On the other hand, Haskel l Language was designed by committee, and it's a fantastic language--although others have pointed out that their goal was to consolidate various features from different mostlys-functional languages to create a single purely-functional language.

-- Wayne Conrad
I have seen that exercise done comparing individuals against small groups, rather than small groups against big groups. The official conclusion was more persuasive in that the individuals would themselves agree that the group process had done better. Arguably there is a law of diminishing returns, and most of the benefit comes from having just 2 people in the group. (See also PairProgramming.)

--  Dave Harris
The limp wristed part of that exercise is that the results can't be tested -- you have no clue whose choices were more likely to actually promote survival.
I have always thought that the team determines if a design is good or not. I have worked on projects where two or three folks couldn't get anything done because we just didn't have the knowhow to put it together. I have worked on projects where we had eight people, all contributing their part to a network design that would never have happened without all eight of those people. The right team can mesh together and get fantastic things to happen. The wrong team can be composed of two or even one and still not get a durn thing accomplished. As the saying goes, "been there, done that too."

-- Marty Schrader
I too did this same exercise but the context brought a different conclusion: We had several groups. Individuals did it for themselves first and then carried on to advocate their opinion to the rest of their group. Once consensus had been reached, results showed that individuals in a group performed better individually than their group did. The apparent reason was that individuals with natural leadership and strong personalities influenced the group and diverged from established facts in order to meet consensus. The groups results were therefore much worse than the sum of all individual results.

18. Languages continually evolve. What sort of restrictions do you thinkare appropriate for changes in programming languages? Compare youranswers with the evolution of Fortran.

A good deal of restraint must be used in revising programming languages. The greatest danger is that the revision process will continually add new features, so that the language grows more and more complex. Compounding the problem is the reluctance, because of existing software, to remove obsolete features.


19. Build a table identifying all of the major language developments, together with when they occurred , in what language they first appeared, and the identities of the developers .

    Years 50: Creation of high-level languages ​​(closer to humans).

    Years 60: Expansion of specialized languages​​. Forth. Simula I. Lisp, Cobol. Trying unsuccessfully to impose general languages​​: Algol, PL / 1.

    Years 70: Duel between structured programming with Pascal and efficiency of C language. Basic generalized on personal computers from 1977, until the late 80s.

    Years 80: Experimentating other ways including objects. ML. Smalltalk. On computers, we now use C, Pascal, Basic compiled.

    Years 90: Generalization of object-oriented programming with the performance of microcomputers. Java, Perl, Python languages ​​in addition to microphones.

    2000s: Internet Programming (and future innovations, see end of text).

    Years 2010: Concurrency and asynchronicity. JavaScript and Go languages among others help to create online fluid applications.


Evolution of programming languages

 " see the table here "

20. There have been some public interchanges between Microsoft and Sun concerning the design of Microsoft's J++ and C# and Sun's Java. Read some of these documents, which are available on their respective Web sites, and write an analysis of the disagreements concerning the delegates.


These are the documents
http://msdn.microsof...v=vs.60%29.aspx
http://benhutchison....gates-for-java/
https://weblogs.java...ngly_types.html
http://java.sys-con.com/node/49097

Delegates are a redundancy polluting object-oriented paradigm. Most of the posts on the subject are missing a big picture.