So let's ask the obvious question, if we have powerful languages, and/or
powerful libraries, is not an application comprised primarily of glue
code that ties all the "piece parts" together in an application-specific
way?
David Barbour wrote:
On Tue, Apr 16, 2013 at 2:25 PM, Steve Wart <[email protected]
<mailto:[email protected]>> wrote:
> On Sun, Apr 14, 2013 at 1:44 PM, Gath-Gealaich
> In real systems, 90% of code (conservatively) is glue code.
What is the origin of this claim?
I claimed it from observation and experience. But I'm sure there are
other people who have claimed it, too. Do you doubt its veracity?
On Mon, Apr 15, 2013 at 12:15 PM, David Barbour
<[email protected] <mailto:[email protected]>> wrote:
On Mon, Apr 15, 2013 at 11:57 AM, David Barbour
<[email protected] <mailto:[email protected]>> wrote:
On Mon, Apr 15, 2013 at 10:40 AM, Loup Vaillant-David
<[email protected] <mailto:[email protected]>> 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.
I should clarify: a potential answer to the glue-code issue is
to *infer* much more of it, i.e. auto-wiring, constraint
models, searches. We could automatically build pipelines that
convert one type to another, given smaller steps (though this
does risk aggregate lossiness due to intermediate summaries or
subtle incompatibilities). Machine-learning could be
leveraged to find correspondences between structures, perhaps
aiding humans. 90% or more of code will be glue-code, but it
doesn't all need to be hand-written. I am certainly pursuing
such techniques in my current language development.
_______________________________________________
fonc mailing list
[email protected] <mailto:[email protected]>
http://vpri.org/mailman/listinfo/fonc
_______________________________________________
fonc mailing list
[email protected] <mailto:[email protected]>
http://vpri.org/mailman/listinfo/fonc
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
--
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
