On 03/27/2011 02:12 PM, Michael Natterer wrote: > > So when you write code, how much time do you spend writing the > boilerplate? 10%? I would say it's much much less, because writing > the code is a small fraction of the time actually spent on the code, > the rest is debugging, refactoring, reading and reading it over > and over again. The percentage of writing the actual boilerplate > rapidly drops to a few percent. I don't have any exact figures, but it takes enough time to make it annoying. Also don't forget to look at this from the point of view from someone who doesn't know anything about GObject boilerplate code. It is quite an obstacle to climb over, not only to be able to write GObject boiler plate fluently, but also to read it fluently. This becomes especially problematic in the context of "temporary" contributions such as GSoC, where a substantial amount of the initial time in a project is spent on getting students up to speed on how GObject works. > And what are "things that benefit our users" we could do instead? > Thats a complete non-statement. Programming a complex thing > like GIMP is hard, no matter how supposedly "easy" you make > the programming language. I meant that instead writing boilerplate, we and others can write code that adds actual functionality. > The "problem" is not the programming language, or GObject, it's > simply the complexity of GIMP's object system, and that complexity > is unfortunately unavoidable, and is not going to decrease by > adding another layer to it. Vala is not another layer, it's just another way to write GObject code where the boiler plate is taken care of by the valac compiler. And I don't see the GIMP object system as very complex, it is what you'd expect for a program like GIMP. I actually often find myself reluctant to add new classes because of all the extra work the boiler plate requires. This isn't a healthy situation; adding new classes should be effortless. > I often hear how well the GIMP source is structured, and people > point others to GIMP as an example of properly done code. That's > a reputation which is not going to improve by adding another > fringe language. The GIMP code *is* well structured, but I don't see how that is an argument either way. I don't want to add Vala to bring structure into the code, I want to add Vala to get rid of all the boiler plate code. > As to the actual iussue of introducing whatever *additional* > language in GIMP, I strongly doubt that it would help us in > any way. It would increase the complexity of both building and > programming because there would be two languages to learn, > it would complicate the build system (new contributors > would also have to learn to deal with autofoo makefiles dealing > with both C and vala code). It would increase the barrier of > getting new contributors into the project, not lower it. It's funny, because I see it the other way around. With infrastructure for and knowledge about how to use Vala in GIMP, the barriers of getting new contributors is lowered, because they don't need to learn GObject C boilerplate before writing code. Assuming of course that most of our code is in Vala already... / Martin -- My GIMP Blog: http://www.chromecode.com/ "Why GIMP 2.8 is not released yet" _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
