Timor: adding "qualifying" and "attribute" types to the OO realm.

I'm currently learning about somebody's home-grown distributed object system in Java, which makes lots of use of source-code augmentation; you run your code through a processor that adds magic code to your .java file to support distributivity. It kinda sucks because there's all this extra gunk that is either missing and you don't realize it, or is there and is in your way and has scary comments around it saying it is auto-generated code and shouldn't be touched. Timor will supposedly help make component-based reuse a reality and lets you augment things without disturbing the originals, so that sounds nice to me just now. (Not that I will get to use it any time soon, probably.) Maybe it is all just fancy-talk for AOP?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

No technology will make

No technology will make component based reuse a "reality". Reuse is a *social* problem, not a technical problem.

How does a programmer find which reusable components are available?
How do they find out how closely they fit their specific application domain?
How do they work with the teams developing the code they wish to reuse?
How do they judge whether it's cheaper to reuse existing code or write new code from scratch?

Social problem?

I consider all your points to be technical problems. Consider your first question:

How does a programmer find which reusable components are available?

Ask the same question, but apply it to the web: How does a person find the information he is looking for on the web? Google and other search engines have gone a long way to solving that problem. The amount of usable information at your fingertips is just incredible.

Sure, you can apply some

Sure, you can apply some technical *help*, such as a search engine, but that in itself is not a solution. To be visible in a search engine, code that can be reused needs to firstly be identified by the author as useful to whoever is searching and then described clearly in a way that can be picked up by search engines. That's difficult.

How does someone writing an application know which parts of the application will be useful to people who he has no contact with?

If he did know, where's the benefit for him in documenting the possibly reusable bits of the code? In a large organisation, he'll spend his budget documenting things that other people might or might not find useful, but anybody who does make use of that work will save money from *their* budgets and not contribute back to the developer of that code so he gets no benefit.

An organisation could set up some form of central oversight -- an enterprise reuse project or architecture board -- to foster reuse. But in a large organisation, the enterprise architects and IT management have only a vague idea about what development is going on and what is actually being written by who. The people in those positions are not technical enough to track source commits and understand what is being written, and if they could they would be overwhelmed by the volume. (To give you an idea of scale, I work in a multinational organisation; there are over 1000 IT staff at our site alone and the company has sites in every major country in the world).

Alternatively, an organisation could set up some form of internal market for code reuse to encourage teams to document their code for search engines. But how can a team know which parts of their application other people will need in the future, before they search for it? And how are the savings of reuse quantified?

All of these are social problems that are created, not solved, by a search engine. And what technical solutions are available to the other points?

PL related?

Are these issues really PL related? We discussed these issues before (e.g., CPAN, standard libraries), but the general issue seems to be more relevant for software engineerig forum than for LtU. If you think otherwise, and have interesting language related suggestions (e.g., module systems, PLaneT etc.) it would be great to discuss them since these are important issues.

While on this topic, I recommend reading McIlroy's "Mass Produced Software Components" and the classic discussions on reuse myths by Tracz.

In this case, I think so.

If a language is being presented as a "solution" to reuse, then a discussion of the problems inherent in reuse are on topic I feel. There's no point in discussing languages without discussing the context in which they are intended to be used and the problems they are intended to solve.

Sure. But if it's not a

Sure. But if it's not a language issue than the point is moot. Since this fundamental question was discussed many times (here and in the literature), I think previous discussions should be taken into account. No need to reinvent the wheel...