On Mon, May 2, 2011 at 9:15 AM, Nicolas Robidoux <nicolas.robidoux@xxxxxxxxx> wrote:
One way of viewing the issue is:
Do you want to cater to the programmers you want, or the programmers you have?
(With the hope of turning the latter into the former.)
It's worse than that, even. This is a perpetual argument.
People were railing against C in the 70s because people who weren't programming in assembler weren't intimate with the stack, heap, or registers. They hated the subroutine call inefficiency. They hated losing the ability to dynamically change executing code, or freely use instructions as data.
Software development - all engineering, really - is about trades. C imposed a base level of inefficiency for a higher level of productivity.
Today, C is a hindrance to even greater productivity (GObject itself is evidence of this). It's less useful to know how to write a hash table interface with its own unique API than it is to know how or when to use one. If a hash table is part of the language, then it becomes the One True Implementation and Everybody knows it and uses it, and does so mostly-correctly.
FWIW, to me, Vala seems like a reasonable choice for GObject based systems. I don't think it's going to expand the developer base now because Vala prefers an understanding of GObject, which is little used outside OSS systems. The syntax should be familiar to C/C++/C# users, but the trade here is for productivity.
While another language (C++, C# or Java) may have more developers, that language would require an object system be built around GObject, which just raises the question: "Why not Vala?" One would assume that a stable Vala compiler exists or is currently stable enough to use on all target platforms.
Chris
_______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
