The London Java Community’s next free event is – ‘March’s Code Share: First Expressions’  on Wednesday 7th March at 6:30pm.

Please see link for details and to sign up – http://www.meetup.com/Londonjavacommunity/events/52643562/

March’s Code Share: First Expressions.

Code doesn’t just tell a computer to what to do. Code allows us to express ourselves, organising our thoughts and sharing them with others: both humans and machines. Code provides us with three mechanisms to do this: expressions, combination and abstraction.

This month we are going to look at the first of these: expressions.

Expressions represent the stuff that we are manipulating: procedures and data. Different languages provide different expressions. It is believed that the language we use affects the way in which we think. Wilhelm von Humboldt asserted in 1820 that “the diversity of languages is not a diversity of signs and sounds but a diversity of views of the world.” Is this true for software? Does the use of s-expressions in Lisp and Clojure cause the programmer to see the world differently to the Java developer?

Donald Knuth proposed literate programming, with code being read for other humans to read and understand as well as for a computer to execute.

The practitioner of literate programming can be regarded as an essayist, whose main concern is with exposition and excellence of style. … He or she strives for a program that is comprehensible because its concepts have been introduced in an order that is best for human understanding, using a mixture of formal and informal methods that reinforce each other.

http://www.literateprogramming.com/

In recent years this literate approach has made great advancements in the area of testing. Consider, for example, Behaviour Driven Development and the use of simple sentence templates that allow programmers and domain experts to share the same language. Dan North writes:

Developers discovered it could do at least some of their documentation for them, so they started to write test methods that were real sentences. What’s more, they found that when they wrote the method name in the language of the business domain,the generated documents made sense to business users, analysts, and testers.

http://dannorth.net/introducing-bdd/

All languages are designed to help the developer express themselves more clearly (well, nearly all: http://en.wikipedia.org/wiki/Brainfuck). Their designers, however, have taken many different approaches. Paul Graham argues that extensibility is the key to clarity. The programmer is given the ultimate freedom of building a new language for every new problem.

As you’re writing a program you may think “I wish Lisp had such-and-such an operator.” So you go and write it. Afterward you realize that using the new operator would simplify the design of another part of the program, and so on. Language and program evolve together… In the end your program will look as if the language had been designed for it. And when language and program fit one another well, you end up with code which is clear, small, and efficient.

http://www.paulgraham.com/progbot.html

On the other hand the creator of Python, Guido van Rossum, believes that the key to readability is to limit the developer’s choices so that they are forced to adopt a familiar style.

Readability is often enhanced by reducing unnecessary variability. When possible, there’s a single, obvious way to code a particular construct. This reduces the number of choices facing the programmer who is writing the code, and increases the chance that will appear familiar to a second programmer reading it. Yet another contribution to Python’s readability is the choice to use punctuation mostly in a conservative, conventional manner.

http://www.python.org/doc/essays/foreword/

The Diabolic Developer doesn’t care how code can be made clear because he doesn’t want anybody else to be able to read it.

  • Keep information to yourself.
    • Knowledge is power.
      • Think job security. Never provide documentation.
    • Make sure only you can read your code.
      • Don’t put comments in your code. Name your variables A,B,C….A1,B1, etc.
      • If someone insists you format your in a standard way, change a small section and revert it back as soon as they walk away from your screen.
  • The Diabolical Developer: How to Become Awesome

How do you feel about literate programming? Have you discovered a language that allows you to express yourself with ease and clarity? Have you written code that makes a difficult problem comprehensible? Do you have some ugly code that you just can’t clean up? Is there something that others insist on doing in the name of readability that you find incomprehensible?

We would like to hear your thoughts. Better still, we would love to see your code. Please come along and share.

Please see link for details and to sign up – http://www.meetup.com/Londonjavacommunity/events/52643562/