Programming Languages and Design Principles

In the following, we will discuss the development of programming languages as a means to improve their ability to capture the software design at ever increasing abstraction levels. Or, from another point of view, we discuss why advances in programming language technology are driven by the need to make programming languages capable of capturing higher-level designs.

“Designing” with Pseudo-Assembler

i = 1
TEST:	if i < 4
	then goto BODY
	else goto END
BODY:	print i
	i = i + 1
	goto TEST
END:

i = 1
LOOP:	print i
	i = i + 1
	if i < 4 goto LOOP
END:	

Though both programs just print out "123" the second one is easier to read and comprehend. It has a better style:

• Clear structure
• No crossing gotos
• Better names
• Code structure closer to what we want to express.
  "Print out i, i smaller than 4“

Hence, the second variant, though functionally identical, is easier to understand, debug, change.

Designing with Structured Programming Languages

i = 1
while ( i < 4 ) {
	print(i)
	i = i + 1
}

In the 1960th programming language support for better structuring of code emerged. Gotos were replaced by loops (while) and conditionals (if/else). Furthermore, procedures were introduced to support user-defined abstractions.

New words, new grammars, new abstractions enable developers to directly express looping/conditional computations, instead of emulating them by jumps. Using a – by then – modern structured programming language, it was no longer possible to write crossing gotos!

main () {
draw_label(“Art Browser”)
   m = radio_menu(
      {“Whale”, “Eagle”, 
       “Dogfish”})
   q = button_menu({“Quit”})
   while ( !check_buttons(q) ) {
      n = check_buttons(m)
      draw_image(n)
   }
}
  

set_x (x) {
   current_x = x
}
  

draw_circle (x, y, r) {
   %%primitive_oval(x, y, 1, r)
}
  

set_y (y) {
   current_y = y
}
  

radio_menu(labels) {
   i = 0
   while (i < labels.size) {
      radio_button(i)
      draw_label(labels[i])
      set_y(get_y()
         + RADIO_BUTTON_H)
      i++
   }
}
  

radio_button (n) {
   draw_circle(get_x(),
      get_y(), 3)
}
  

get_x () {
   return current_x
}
  

get_y () {
   return current_y
}
  

draw_image (img) {
   w = img.width
   h = img.height
   do (r = 0; r < h; r++)
      do (c = 0; c < w; c++)
         WINDOW[r][c] = img[r][c]
}
  

button_menu(labels) {
   i = 0
   while (i < labels.size) {
      draw_label(labels[i])
      set_y(get_y()
         + BUTTON_H)
      i++
   }
}
  

draw_label (string) {
   w = calculate_width(string)
   print(string, WINDOW_PORT)
   set_x(get_x() + w)
}
  

In this case, the code is structured, but the procedures are not! It is hard, if not nearly impossible, to maintain or even extend this code.

main()
	

gui_radio_button(n)
	

gui_button_menu(labels)
	

gui_radio_menu(labels)
	

graphic_draw_image (img)
	

graphic_draw_circle (x, y, r)
	

graphic_draw_label (string)
	

state_set_y (y)
	

state_get_y ()
	

state_set_x (x)
	

state_get_x ()
	

Group procedures by the functionality they implement and the state they access, e.g. by naming conventions …

Advantages:

• The code is closer to what we want to express.
  "main calls gui, gui calls graphic to draw, …“
• The code is easier to understand, debug and change.

Designing with Modular Programming Languages

module gui {
    exports:
        radio_menu(labels)
        button_menu(labels)
        check_buttons(menu)
}	

Modular programming introduced modules, higher-level units/modules introduce higher-level abstractions! One can handle a whole module as if it was its interface. Programming language mechanisms for supporting information hiding: interface hides module internals.

Abstraction enables us to:

• look at the overall structure of the system (architectural thinking).
• zoom in on individual units as needed
• with more or less details

Hence, abstraction is the key to managing complexity.

• Makes the code easier to understand, debug and change.
• Allows structured organization of code.
• Ability to ignore details. Makes the code closer to what we want to express.

Modeling variability with modular programming languages appeared complex…

Designing with Object-Oriented Programming Languages

Object-oriented languages are popular because they make it easier to design software and program at the same time.

They allow us to more directly express high level information about design components abstracting over differences of their variants.

Make it easier to produce the design, and easier to refine it later.

With stronger type checking, they also help the process of detecting design errors.

Result in a more robust design, in essence a better engineered design.

Designing with Functional, Object-Oriented Programming Languages

def repeat[T: scala.reflect.ClassTag](times: Int)(f: ⇒ T): Array[T] = {
  val array = new Array[T](times)
  var i = 0
  while (i < times) { array(i) = f; i += 1 }
  array
}

val values = repeat(2) { System.in.read() }

Programming Languages are not a Panacea

• Accessibility of object-oriented programming drives more complex designs!
• Programming languages are powerful tools, but cannot and will never guarantee good designs.
• Programming always needs to be done properly to result in good code.
• Human creativity remains the main factor.

Help is provided through established practices and techniques, design patterns and principles.

Good style can only be recommended, not enforced!

Eventually style rules will have to be turned into language features to be really effective.