Composition Languages
started 11/20/2002; 12:41:39 PM - last post 11/26/2002; 12:44:57 PM
|
|
Ehud Lamm - Composition Languages
11/20/2002; 12:41:39 PM (reads: 1996, responses: 12)
|
|
Composition Languages |
Isaac posted some good links about this topic, to the LtU discussion group.
I think we need better programming language support for components, rather than having separate composition languages, but that's just me.
Still, keep in mind that the best tools we have to specify behaviour are inside expressive programming languages. Specifically, the best tool for the job is a good type system, that allows you to specify important logical properties. Indeed, isn't this the reason why functional programming matters?
Posted to Software-Eng by Ehud Lamm on 11/20/02; 12:42:23 PM
|
|
|
|
Isaac Gouy - Re: Composition Languages
11/20/2002; 5:13:19 PM (reads: 1143, responses: 1)
|
|
Component Libraries and Language Features
Previously you expressed concern about where-to-draw-the-line between libraries and language features. I'm interested in hearing your ideas.
programming language support for components
Having recently read Towards a New Model of Abstraction in Software Engineering, Gregor Kiczales, I'm struck by how Smalltalk white-box reuse evades the "basic discrepancy between our existing view of abstraction and the reality of day-to-day programming."
How do other programming languages provide for both black-box reuse and open implementation?
|
|
Luke Gorrie - Re: Composition Languages
11/22/2002; 10:03:06 AM (reads: 1064, responses: 1)
|
|
Ehud, what do we have to do to actually download your paper? I just get a login/password prompt.
Also, to me that paper by John Hughes suggests that what matters is higher order functions and lazy evaluation, not fancy type systems :-)
|
|
Patrick Logan - Re: Composition Languages
11/22/2002; 2:51:19 PM (reads: 1014, responses: 0)
|
|
|
Ehud Lamm - Re: Composition Languages
11/24/2002; 5:03:19 AM (reads: 1042, responses: 0)
|
|
You need a Springer subscription to download the paper. If you don't have one, email me, and I'll send you the paper.
John Hughes suggests that what matters is higher order functions and lazy evaluation
Sure. But if we want safety and h.o.f, we need fancy type systems.
|
|
Ehud Lamm - Re: Composition Languages
11/24/2002; 5:14:12 AM (reads: 1013, responses: 0)
|
|
Actually, none of them do (including Smalltalk). Nor does AOP solve the problem (which is not to mean AOP is not important or interesting).
The open-closed principle and careful use of inheritance is supposed to help. In my experience (and most papers I read agree) inheritance all to often causes more trouble than it solves.
|
|
Isaac Gouy - Re: Composition Languages
11/24/2002; 2:24:40 PM (reads: 960, responses: 1)
|
|
When you use composition in Smalltalk, you can still look past the interface to see what the code actually does. Black-box is fairly notional, most often you also get to look at the implementation - that's all I meant by white-box (I didn't mean inheritance).
Although I expressed myself badly with black-box / white-box, the Evolving Frameworks pattern was a nice refresher. (But visual builders can become part of the problem - if they hinder automation.)
|
|
Patrick Logan - Re: Composition Languages
11/24/2002; 4:46:08 PM (reads: 962, responses: 1)
|
|
Just because you have a visual builder that does not imply the only way to construct systems is using the visual builder.
|
|
Isaac Gouy - Re: Composition Languages
11/25/2002; 7:47:17 AM (reads: 986, responses: 0)
|
|
that does not imply the only way to construct systems...
I agree. The design might provide a clean API separate from the ApplicationModel; or it might not.
|
|
Ehud Lamm - Re: Composition Languages
11/25/2002; 11:04:33 AM (reads: 974, responses: 0)
|
|
I am familiar with this, but I still think the important notion here is inheritance (and delegation etc.) The problem arises where reuse requires "openning" the box.
|
|
Isaac Gouy - Re: Composition Languages
11/26/2002; 11:18:19 AM (reads: 875, responses: 1)
|
|
As-you-might-say breaking the abstraction
The high-level view of making, breaking, remaking abstractions really highlights the absence of explicit signals of abstraction breaking within a programming language.
Maybe I just need to catch-up with ideas about static typing?
Moving from passive type-checking to active manipulation of types as data at compile time. In-other-words, "a parametric type system offers a limited functional programming language for manipulating static types at compile time" Kris De Volder.
There's more, of course, I'm still thinking in terms of what an abstraction provides without thinking about what it requires - Three Concepts of System Architecture.
|
|
Ehud Lamm - Re: Composition Languages
11/26/2002; 12:33:43 PM (reads: 910, responses: 0)
|
|
The high-level view of making, breaking, remaking abstractions really highlights the absence of explicit signals of abstraction breaking within a programming language.
I recall publishing this observation in 2001
|
|
Isaac Gouy - Re: Composition Languages
11/26/2002; 12:44:57 PM (reads: 875, responses: 0)
|
|
Perhaps in a paper titled Component Libraries and Language Features?
Sorry, I forgot to add the link.
|
|
|
|