On Mon, May 2, 2011 at 9:15 AM, Nicolas Robidoux <nicolas.robid...@gmail.com
> 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@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Reply via email to