On Mon, Apr 15, 2013 at 10:40 AM, Loup Vaillant-David <l...@loup-vaillant.fr>wrote:
> On Sun, Apr 14, 2013 at 04:17:48PM -0700, David Barbour wrote: > > On Sun, Apr 14, 2013 at 1:44 PM, Gath-Gealaich > > In real systems, 90% of code (conservatively) is glue code. > > Does this *have* to be the case? Real systems also use C++ (or > Java). Better languages may require less glue, (even if they require > just as much core logic). > Yes. The prevalence of glue code is a natural consequence of combinatorial effects. E.g. there are many ways to partition and summarize properties into data-structures. Unless we uniformly make the same decisions - and we won't (due to context-dependent variations in convenience or performance) - then we will eventually have many heterogeneous data models. Similarly can be said of event models. We can't avoid this problem. At best, we can delay it a little. > > Also, much of the need for glue is caused by unnecessary impedance > mismatch in the first place. If everyone in the project would use > this *or* that, we wouldn't have to translate from this *to* that. > Indeed. But while such impedence mismatch is 'unnecessary', it is still 'natural'. You can't escape it without losing other valuable properties (freedom, flexibility, the ability to improve things). > > Size. > By that definition, OMeta and Maru are mere little toys. If they > mature correctly, they may even look *more* toyish. 'Size' is measured differently for frameworks, languages, or programming models - in terms of effectiveness in big systems, not big definition. Simple vs. simplistic is the difference between encapsulating essential complexity vs. pushing it to each user. If you have only one user, there is no obvious difference between simple vs. simplistic. If you have a hundred users, then 'simplistic' will multiply essential complexity by a hundred. Simplistic models - the 'toys' - thus become ineffective or frustrating in larger systems. Consequently, it is difficult to evaluate models before 'serious' use. The complexity multiplier might not become obvious until it's been scaled up a few orders of magnitude. And as models gain serious use, they tend to evolve a bit to address widely needed features. We want things simple, but not *too* simple.
_______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
