AspectJ, an extension to Java, is the de facto standard for aspect-oriented programming (AOP). It was developed at Xerox PARC by a team led by Gregor Kiczales.

In 2003-2004 he wrote a series of a dozen columns about aspect-oriented programming (AOP) in Software Development.

In 2006, he gave the following Google “TechTalk”

He ended up running out of time. If you’re running out of time, you might want to skip directly to 38:00, perhaps after skimming these slides from 2004 and reviewing the Observer pattern.

He says about AOP consultants and the practical intuition of crosscutting

They’re not bothering to say, “… I have to go live in that code”.
They’re saying, “I’ve got a library of pointcuts that gives me a meaningful abstraction of that code, I can just cut through it, program against those pointcuts, and know interesting things right away.”

More controversially, he disputes Barbara Liskov, saying

Social practice is very clearly at conflict with the story we tell about encapsulation.

and

The current story we tell about modularity is bunk.

He says

One of the classic adoption strategies … is to start by doing architecture enforcement, you don’t write any aspects that ship in the running product.

The abstract from here is

Google TechTalks May 16, 2006 Gregor Kiczales Gregor Kiczales is Professor of Computer Science at the University of British Columbia. His work is directed at enabling programmers to write programs that, as much as possible, look like their design. ABSTRACT Aspect-oriented programming (AOP) is based on a radical exploration of modularity in software development. By presenting new mechanisms that enable better modularization in a number of systems, AOP is driving us to ask fundamental questions about what modularity should mean in our field. In the past, we have tended to think of modularity in terms of hierarchies of crisply defined blocks, where each block or module defines its interface with the surrounding modules. This idea seems attractive but experience tells us that it is hard to actually get the modularity of the software we build just right. Some issues are hard to code (or design) in a single module, others just don’t seem to want to stay where you put them. Work in AOP and other areas suggests a different conception of modularity, based on crosscutting structures and a more fluid notion of module boundaries. The talk will present existing AOP techniques and the problems they solve, as well as open practical and research problems ranging from mechanisms, to applications, to theoretical formulations and to conceptual foundations.

According to Drake Bennett

One of the hottest topics in psychology today is something called “cognitive fluency.” Cognitive fluency is simply a measure of how easy it is to think about something, and it turns out that people prefer things that are easy to think about to those that are hard. On the face of it, it’s a rather intuitive idea. But psychologists are only beginning to uncover the surprising extent to which fluency guides our thinking, and in situations where we have no idea it is at work.

According to Surya Saha

So many features added in SV are very rarely used. And I got feedback from many designers/users that SV is huge, and the people getting frightened to digest the whole.

According to John Michael Williams

My limited experience with SystemVerilog is that it is frustratingly complicated and poorly supported, when comparing tool functionality with the full Std. It’s a “heap big” Std!

and

Reducing the complexity of SystemVerilog by any means would increase its acceptance by designers and project managers.

According to Shalom Bresticker

If we take operator overloading, for example, then it is true that it is not very much implemented, but neither have I heard users complaining about it very much.

Is deprecation sometimes an enhancement?

An important ambiguity in the SystemVerilog standard is what an output direction specifier in a modport declaration means. See, for example, comments in Mantis 2114.

Simulators are consistent with each other that the specifier has little meaning, that writing across a modport-type port is no different than writing across an interface-type port, namely, by reference.

In my opinion, this interpretation is contrary to intuition and to the very first paragraph of the LRM section on modports

To restrict interface access within a module, there are modport lists with directions declared within the interface. The keyword modport indicates that the directions are declared as if inside the module.

My intuition says a modport is just a way to declare a nested interface, implicitly instantiated by the enclosing interface instance.

For example, suppose interface IFC declares

modport mp(input x, output y, import f);

then it’s as if it had instantiated and declared

mp mp(.*);

interface mp(input … x, output … y);
function … f(…) = IFC.f(…); endfunction
endinterface

where the … abbreviates replicated signatures.

If ifc.mp is connected to a down-design, that’s exactly what’s connected — the nested interface instance — and references to the x and y in it are references to those ports x and y. For example, if x is a variable input port, then you can’t assign to it, and so on.

When a down-design port is declared IFC.mp or interface.mp, that just means that references across the port must go to the nested instance.

If GEN[5].mp is a generated modport, then connecting GEN[5].mp or the down-design imposing IFC.GEN[5].mp works out naturally, too.

Aside: There seems to be some vague family resemblance here with the prototype-based inheritance and delegation of JavaScript or Self.

The most dangerous errors are bogus or incomplete requirements

• Don’t solve the wrong problem
• Don’t solve half the problem
• Doing a wrong thing “right” is still wrong

Requirements analysis is difficult

• Don’t jump to easy conclusions
• You can’t read minds
• Make the resolutions explicit
• A conversation with customer
• A form of gentle negotiation

Focus first on the real needs, not on the particular means proposed to satisfy those needs.