|
No doubt promoting happiness in the development community is a worthy goal, but there is a lot of variety in what makes different software developers happy, and inevitably their priorities will sometimes conflict. For example, the principle that a programming language should be optimised for the programmer and not the computer seems reasonable. However, what if a programmer works on projects where performance matters, and we haven’t figured out how to implement certain language features in an efficient way yet? It may be true that under some conditions saving a programmer time is more valuable than shaving a few seconds off at run-time, but there are many situations where this is not the case. More subtly, programming languages that are easy to parse, that represent their source code in a well-structured way, and that have clean semantics are friendly to tool developers. I imagine many programmers are happier with a language that has good refactoring, debugging, profiling and testing tools available, and which plays nicely with their favourite editor, diff and version control systems, and code review tools. Again, there might be a trade-off between adding a new language feature, which in itself might be useful for the programmer, and keeping the language simpler or more cleanly structured, which might encourage effective automation and tooling. |