On Sat, 20 Sep 2008, Rolf wrote:

> I guess the implication is that some programmers are able to make the 
> code 'sing'. Some architechts are able to produce buildings that have 
> expression. Some artists are able to convey part of theiur soul in their 
> work. I believe programming is one (of many) possible ways to express 
> oneself.
> 
> OK, perhaps that sounds over the top, but, on the other hand, I work 
> with a dozen other people quite closely, and, I bet I could identify the 
> programmer of some code by looking at a peice of code... Further, 
> looking at code you can tell a programmer with patience, forethought, 
> and 'flair'.
> 
> How about a handwriting expert.... they can determine a lot about the 
> person based on their handwriting. The same could be said about code. 
> Perl is a language that allows for embellished writing.
> 
> There are languages out there that require 'courier - fixed-width' type 
> handwriting, and, with that it is harder to be expressive. Like a 
> painter who can only paint with black and yellow!
> 
> Rolf
> 

A very big cause of problems is *ambiguity*

If I see the following code:

	if (x = y)

is this a mistake, should it actually read:

	if (x == y)

If I find:

	if (expr) x = y; p = q;

is this a mistake, should it read:

	if (expr)
		x = y;
	p = q;

Yes I really dislike 'C's anything goes free format. It causes lots of 
problems and solves very few. Yes the programmer can overcome these by 
being disiplined but surely one of the greatest arguments of using a HLL 
(letting the computer take care of all the boring error prone repetitive 
unnecessary work) also applies to layout. Why should the programmer need 
to worry about how the source code is formatted.

A programmer who is forced to use a strict layout can still create great 
works of art. When I look at someone else's code, I'm not impressed by how 
that person reduced a 10 line segment into 3 by utilising some side effect 
of the 'C' language. But I am impressed if his code is structured and 
clearly shows the solution - removing all ambiguity. This helps him and 
others who come after him understand the problem in more detail and 
potentially find a better solution for it (not just in the 10 line segment 
but in the system as a whole).

Furthermore something that is often not understood is that complicated 
source code can be much harder for a compiler to generate the best 
optimised executable for.

This is the main reason why I decided to implement a non 'C' compiler. The 
XCSB language does not allow multiple statements per line, it requires 
IF...THEN...ENDIF, it doesn't have conditional expressions (?:) or 
pre/post inc/dec, BUT it still allows you to write shiney code and it 
generates very highly optimised executables.

Being an expressive innovative coding artist is not about looking at 10 
lines of code under a microscope but being able to glance at those 10 
lines while looking at all the code. You need to have confidence that 
those 10 lines are not doing something subtle behind your back, that the 
compiler will flag them if they try to. You need to be able to mold your 
"clay" over and over not being afraid of making big changes, step back 
look at the whole (glance at small sections) then mold again.

Regards
Sergio Masci
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist