What Makes A Programming Language Good

[el muchacho]

Le 18/01/2011 11:45, bearophile a écrit :
> Vladimir Panteleev:
> 
>> So, you want D to force people to do more work, out of no practical reason?
> 
> When you develop a large system, the nice hand holding that works with small systems often stops working (because the whole language ecosystem is often not much designed for hierarchical decomposition of problems). In this situation you are often on your own, and often the automatic features work against you because their work and actions are often opaque. So those programmer develop a mistrust toward a compiler+tools that hold too much your hand.
> 
> A related problem is visible in old automatic pilot systems. They are very useful, but when their operative limits are reached (because some emergency has pushed the plane state outside them), they suddenly stop working, and leave the human pilots in bad waters because the humans don't have a lot of time to awake from their sleepy state and understand the situation well enough to face the problems. So those old automatic pilot systems were actively dangerous (new automatic pilot systems have found ways to reduce such problems).
> 
> To solve the situation, the future automatic D tools need to work in a very transparent way, giving all the information in a easy to use and understand way, showing all they do in a very clear way. So when they fail or when they stop being enough, the programmer doesn't need to work three times harder to solve the problems manually.
> 
> Bye,
> bearophile

My 2 cents:  There is no need for transparency in the compilation and
linking processes if things are well defined. Armies of developers in
Java shops that include banks trust their IDE to do almost everything,
be it eclipse, Netbeans or IntelliJ, sometimes the 3 at the same time in
the same team. This is the case in my team, where some developers use
IntelliJ while others use eclipse, out of the same source code
repository. Both IDEs can compile and debug the software and the final
build is made by a big ant file which can check out, generate code,
build with javac and run tests. So there are 3 build systems in
parallel. One task of the ant file is run once by each developer to
generate the code and then the build is entirely handled by the build
system, is the compiler of the IDE. There is no need to specify any
dependency in the ant file. Of course, the IDE's compiler needs to be
told where to find the library dependencies because we don't use Maven
yet, but apart from taht, there is no need to specify anything else.
This is in contrast with the horrible makefiles that still cripple most
C++ projects, and still prevent C++ shops to benefit from efficient IDEs.

Having worked both on large C++ systems and Java systems, my only
conclusion is: make is a huge waste of time.