Validating email is something you will encounter, no?

Anyway, this debate is entirely subjective. BTW even today I write code primarily in C#, F#, VB.NET, Python and PHP. Foe the problem domains I have chosen them ,I find myself perfectly productive.

I'm sure there is a COBOL guy here who will say the same.

Let me now retire my non sober views from this debate.

On Tuesday, June 26, 2012, Martin Chiteri wrote:
@Rad, I think I clarified the statement about clarity and code brevity. 

I also think that the examples you have laid out are not the best ideal, you can give better ones more likely to be encountered in day- to-day life. 

@Peter, the second example is not as readable as the first UNLESS you are accustomed to the ternary operator in C-type languages. Personally, I would use it any day to the ordinary if / else statement. 

If I were a budding programmer, I would stick to the advice given by @Dennis Mbuvi. Its a lot more sobbber. 

Martin.

On Tue, Jun 26, 2012 at 6:05 PM, Rad! <conradakunga@gmail.com> wrote:
Martin here's th example.

First is a one line regex to validate an email address


Second is a multi line one 


Which has more lines of code? The second.

Which is clearer? I dare say the scond


On Tuesday, June 26, 2012, Rad! wrote:


On Tuesday, June 26, 2012, Martin Chiteri wrote:
Hi @Rad, 

On Tue, Jun 26, 2012 at 5:01 PM, Rad! <conradakunga@gmail.com> wrote:
Lines of code is a completely outdated metric.


This still matters, especially when you have to maintain software developed by many people over many years. The first concern is the time it takes to write the program (Man-months / years), and by extension this affects the cost in monetary terms. The lesser the SLOC the better in my opinion, especially for those of us who are not as good at handling complexity as well.

I am inclined to disagree. Fewer lines of code does not necessarily mean easy to maintain. The best example I can give is the POSIX regular expression to validate email addresses. This you can get in a few lines. It is a MONSTER. But to maintain it is hell on earth.
 
And cooling lines of code with maintain ability is a demonstrably false assertion. Maintainability is not a function of lines of code. It is a function of the clairity of code, algorithmic design, control flow, etc


This is also true, but if given two or more programs written with equal clarity, which one would you prefer supposing they solve the same problem in exact measures? It may also help to also note that in the real world, much more time is spent in maintaining software than writing "new" lines of code. 

You're mixing terms here. Clarity and lines of code are not interchangeable terms. Something can have a lot of code and be very clear. Conversely very few lines of code and very unclear. 

On the other hand well written Python and Ruby are sources are *unUsually* readable, don't you think so? Compared to say the same functionality say expressed in JAVA, C# or PHP? Some of the design decisions implicitly built into some of these languages is the ability to make them more readable and maintainable 
 
Finally, if lines of code were a consideration, Lisp and its children (scheme, CAML, etc) areeven more terse


This is also arguably true. Personally, I have never really wrapped my head around LISP, its descendants and its concepts. Maybe it was out of not trying too much .....

Martin.

P.S: The reason the example given are metrics on LISP is that Norvig is probably the greatest LISPer alive (besides Paul Hamming [  www.paulgraham.com/ ] ) and the late John McCarthy.
 
On Tuesday, June 26, 2012, Martin Chiteri wrote:
Well, the article itself does not have "hard" numbers to support their premises. There is an example here [