March's Code Share: First Expressions

This is a past event

15 people went

Details

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 (https://blogs.oracle.com/java/entry/the_diabolical_developer_what_you_need_to_do_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.

March’s Challange: Create a Domain Specific Language.

Martin Fowler has written a lot about Domain Specific Languages:

The basic idea of a domain specific language (DSL) is a computer language that's targeted to a particular kind of problem, rather than a general purpose language that's aimed at any kind of software problem.

http://martinfowler.com/bliki/DomainSpecificLanguage.html

The challenge is to create your own domain specific language. Identify a particular problem, any problem at all, and define a language that specifically targets that problem. The important thing is that the language makes it easy to express a solution.

Bonus points will be awarded to the author of the smallest DSL implementation. Programmers using fancy functional languages should have an unfair advantage here.

ThoughtWorks are delighted to be sponsors of the March Code Share!

Please Note -

At previous events LJC members have found this venue/particular room hard to find.

This event is being held in the Francis Bancroft Building - Room Number - FB 1.13

Please see this map for further information (the building is numbered 26 on this map) http://www.qmul.ac.uk/docs/about/26065.pdf

The actual signs at the building will say 'Bancroft' building only rather than Francis Bancroft.

Directions -

From Mile End Station you will need to turn left out of the station and then continue for 5 mins approx. up the Mile End Road and then cross over the road to the QM campus and go into the East Gate. This is the first entrance to QM you come to when coming from the direction of Mile End Tube. Continue straight on up Westfield Way for a couple of minutes and then bear left at the Curve cafe. The Bancroft Building is on your right (number 26 on the map).