This one is mainly oriented to xterm, following a conversation we had on the irc channel. I'm posting it on the forum so all the programmers here could give their opinions.

xterm was telling me that one of the reasons he stays clear from java is that the code is too verbose, meaning that you write too much to say simple things. This makes the code difficult to understand, so harder to maintain.

My question is: how important is really verbosity?

A simple example in C. These two bits of code do the exact same thing:
int i;
double data[1000];
for (i=0; i<1000; i++)   data[i] = 0.0;
and: 
int i;
double data[1000], *copy, *end;
end = data+1000;
for (copy = data; copy < end; *(copy++) = 0);
The second while a lot more verbose and seemingly complicated, relies on the simple understanding that an array in C is a pointer. The execution time of the second one is faster. (Not entirely true, depending on your compiler, but let's assume it is for now).

And that's not the only case where adding complexity and verbosity boosts performance. Take the quick sort for example.

So where's the exact balance between readability and performance? Is it reasonable to abandon a technology simply based on the fact that it's harder to read?

Python for example is one of the less verbose languages that I know. It doesn't get much simpler than
print "Hello World"
Does it make it an optimal language?


PS: In case you do not understand the second portion of the code, here's a more readable version of the same instructions. 
for (copy=data; copy<end; copy ++)
*copy = 0.0;
;)
Xterm is staying away from Java???
Anyway I know one thing for sure, Java errors are way too verbose, i mean if anyone has seen these errors with traces on Java powered (jsp) website, you know what I mean. Who in their right mind would want to go through the whole trace.
So apparently there is this culture in Java of having everything known, everything has to be defined precisely.
Personally I like more your 1st example. Simply because the syntax is less exotic. You have to find a compromise between exotic syntax and far-thought algorhitms, and too much lines. And if you do something (you think is) really smart, make sure to comment it. Thats my opinion.
Anyway code doesnt exist in a void. The real answer depends on the rest of the project, the aim of the code, who is going to read it, the compiler, who you are trying to impress...
First of all, let me just make this perfectly clear. This is not about language X versus language Y, nor about whether you should choose X over Y.
rahmu wroteMy question is: how important is really verbosity?
The short answer is very.
rahmu wroteSo where's the exact balance between readability and performance? Is it reasonable to abandon a technology simply based on the fact that it's harder to read?
Another issue that needs to be made clear, is that performance should never be sacrificed for the verbosity, atleast to a certain extend.

That said, let's assume that X and Y deliver the result and the profiler has shown you that the performance is pretty much the same in terms of speed yet, Developer A who implemented both scenarios in both language has effectively used 90 lines of code to implement the feature using X and 200 lines of code to implement the feature using Y.

Where was Developer A more productive?

Developers who love to "code" and are not exposed to a quantity of platforms and languages do not really bother with verbosity. We're currently in 2010 where there are a bundle of frameworks/languages that wrap a bundle of features making the tedious and boilerplate code unnecessary.

I'm pro functional paradigm, I despise writing or reading a block of code that does not necessarily require more than three or four lines to implement, being written in much more than that, JUST because the platform or language does not provide the means to do so.

In comes Java, I've linked in the Coffee Break topic, an article that describes the Closures debate. A debate that's been occuring for the past 5 to 6 years. You can refer to that, to see how such a small change can greately enhance the productivity of a developer without sacrificing performance.

Another beef i have, is whether or not a platform or language provides the developer with the flexibility of using extensions. Extensions combined with Closures, would be a total win scenario in terms of how much code you have to write.

If you want to see what java really lacks, you can refer to Scala and Functional Java.

Now concerning python, should one jump to python just because :

print "Hello World" is less verbose than System.out.println("Hello World"); ? Definitly not. Some might argue that you can wrap the java statement in a method print(string) and just call that, ending up with print("Hello World"). In comes, first order functions and closures yet again:

Let's take a very simple example and implement a way to project a list of Person objects to a list of their firstnames, presuming the definition of Person contains the property/variable FirstName.

Java:

public List<String> getFirstNames(List<Person> listOfPersons){
List firstnames = new ArrayList<String>();
for(Person p : listOfPersons){
firstnames.add(p.FirstName);
}
return firstnames;
}

Let's compare it with C# with the use of LINQ extensions:

public IEnumerable<String> getFirstNames(List<Person listOfPersons){
return listOfPersons.Select(person => person.FirstName);
}

Effectively, if you're not bothered by verbosity, you can just ignore what i'm saying and keep coding as you do right now. Though might i suggest reading a few articles about coding in functional style?
rolf wroteSo apparently there is this culture in Java of having everything known, everything has to be defined precisely.
it's a part of the language's honesty.
With code completion, code verbosity is not a problem.

Algorithms and really smart code should not be intermingled with innocent code that's just relaying info around or handling user input and sending it back to models.

Considering code performance at that level is overkill. Your application will usually be bottlenecked at somewhere else completely (DB connection, TCP connection, File Handling), unless you're doing something really realtime like a game or so which then you'll have to use profiling tools to pick your battles.

Performance is an economy for those who know about it, and you would have to pick your battles.

Anyway, code readability is king.

Oh and about an optimal language. There are a lot of factors involved.
Consider for one second why a language is needed, why aren't we writing in machine code, or VM byte code. It's because we're humans. And when humans are involved, science is art at its best.

Anyway, the common trend nowadays is going back to the lisp like languages (with the likes of xml, linq, closures, reflection..)

You shouldn't be comparing languages side by side from the same families, you should only be comparing and learning paradigms (not so sure about comparing, it's a mute endeavor..)
arithma wroteConsidering code performance at that level is overkill. Your application will usually be bottlenecked at somewhere else completely (DB connection, TCP connection, File Handling), unless you're doing something really realtime like a game or so which then you'll have to use profiling tools to pick your battles.
And thus why everything that might affect the state of your code should be refactored, code should always be split into two parts, the part that changes and the part that does not ( if F(3) returns 5 today, when i run it tomorrow or the day after, it should still return 5) . When you write code, you should make sure that you're writing pure code, despite if the language or tool provides you with the flexibility to do so.
Very possible first chunk of code will be optimized by compiler, and can use also superscalar features of modern processors(SIMD instructions+superscalarity can be used in this case by loops unrolling), it is all depends on architecture, second chunk will work seems linearly. Plus seems first code will be more cache coherent.
Code can be written many ways, better to write it way, that compiler authors recommend.
Funny thing gcc enough smart to make assembly of both the same.
080483e0 <main>:
#include <string.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h> 

int main (void) {
 80483e0:       55                      push   %ebp
    int i;                                         
    double data[1000000];                          
    for (i=0; i<1000000; i++)   data[i] = 0.0;     
    return(0);                                     
}                                                  
 80483e1:       31 c0                   xor    %eax,%eax
#include <string.h>                                     
#include <sys/socket.h>                                 
#include <netinet/in.h>                                 
#include <arpa/inet.h>                                  

int main (void) {
 80483e3:       89 e5                   mov    %esp,%ebp
    int i;                                              
    double data[1000000];                               
    for (i=0; i<1000000; i++)   data[i] = 0.0;          
    return(0);                                          
}                                                       
 80483e5:       c9                      leave           
 80483e6:       c3                      ret
int main (void) {
 80483e0:       55                      push   %ebp
    int i;                                         
    double data[1000000], *copy, *end;             
    end = data+1000000;                            
    for (copy = data; copy < end; *(copy++) = 0);  
    return(0);                                     
}                                                  
 80483e1:       31 c0                   xor    %eax,%eax
#include <string.h>                                     
#include <sys/socket.h>                                 
#include <netinet/in.h>                                 
#include <arpa/inet.h>                                  

int main (void) {
 80483e3:       89 e5                   mov    %esp,%ebp
    int i;                                              
    double data[1000000], *copy, *end;                  
    end = data+1000000;                                 
    for (copy = data; copy < end; *(copy++) = 0);       
    return(0);                                          
}                                                       
 80483e5:       c9                      leave           
 80483e6:       c3                      ret             
 80483e7:       90                      nop             
 80483e8:       90                      nop             
 80483e9:       90                      nop             
 80483ea:       90                      nop             
 80483eb:       90                      nop             
 80483ec:       90                      nop             
 80483ed:       90                      nop             
 80483ee:       90                      nop             
 80483ef:       90                      nop
Now concerning python, should one jump to python just because :

print "Hello World" is less verbose than System.out.println("Hello World"); ? Definitly not. Some might argue that you can wrap the java statement in a method print(string) and just call that, ending up with print("Hello World"). In comes, first order functions and closures yet again:
To be precise, I was comparing 
print ("Hello World")
to 
public class HelloWorld
{
  public static void main (String args[])
    {
      System.Out.println("Hello World");
    }

}
I know that you can write a class in Pyhton, but the interpreter would understand a simple print("Hello World") thus making this simple statement a HW program. I think we had this conversation on another tread. But my point is Python as a language is very clear and the code is very understandable. But in some cases I might prefer using C or even ASM.
Considering code performance at that level is overkill. Your application will usually be bottlenecked at somewhere else completely (DB connection, TCP connection, File Handling), unless you're doing something really realtime like a game or so which then you'll have to use profiling tools to pick your battles.
It makes sens. After all, unless you try for a billion iterations, the performance gain is not worth the readability loss. As you said. You have to pick your battles.
xterm wroteAnd thus why everything that might affect the state of your code should be refactored, code should always be split into two parts, the part that changes and the part that does not ( if F(3) returns 5 today, when i run it tomorrow or the day after, it should still return 5) . When you write code, you should make sure that you're writing pure code, despite if the language or tool provides you with the flexibility to do so. What you're refering to are monads. Please refer to Eric Meiyer's interview on Channel 9.
I agree with what you're raising as a point. State code, input code should be seperate from static functions that don't mutate with time (no internal state).

However I wasn't talking about things from an architectural point of view. From a performance point of view, input, and interaction outside the CPU is significantly slower than working with registers (scales from 10 to 10000 times slower). When your application is somewhat like that (a lot of web applications are) worrying about what form of a for loop to use is totally wacko :).
As you said. You have to pick your battles.
Agree.