Hard Core Tech Talk Interview with Jack Greenfield


News: Hard Core Tech Talk Interview with Jack Greenfield

  1. Hard Core Tech Talk Interview with Jack Greenfield (16 messages)

    In this interview, Jack Greenfield, former Chief Architect of the Practitioner Desktop Group at Rational, talks about current software design methodologies, the next wave in application design, and custom languages. He talks about Model Driven Development, the future of J2EE software development and takes a look at Aspect Oriented Programming.

    Watch Jack Greenfield's Interview Here.

    Editor's Note (Dec. 12)
    In October 2002, Jack joined Microsoft, where he is now Architect for Enterprise Frameworks and Tools Groups in Visual Studio.

    Threaded Messages (16)

  2. Interesting.
    There are signs of a mutation in the industry: AOP, code generators, use of meta data. However, I was a little surprised by Mr. Greenfield's claim, that we'll have automated "handcoding" away in the next 12-24 months. If he is right then we'll better start preparing ourselves for this mutation. Any thoughts?
    One comment on 'custom languages'. So, 3GL is/are not up to the task. But then what will we use to express custom languages? DAML+OIL or Topic Maps?

  3. Budy is positioning for his products. I don't buy it.

  4. I'd like to believe he's right, but I know it's not going to happen. Even if J2ee manages to get a leverage on these new areas, there are still other languages that probably won't in the next 10 years. Will this make Java #1? Not really. It'll just promote an ever greater seperation between the 2 technologies and those that use those other languages will have some serious problems understand j2ee (it's complex enough as it is).

    I think we need to work on simplifying what is there right now rather adding more stuff on top of it. It's not the right way to go.
  5. In the 15 years that I've been developing software, pundits
    that don't have the faintest clue about actually writing code
    have claimed that my job is going to disappear in 12-18 months.

    It used to be 4GL, then GUI builders, then code generators, now code automation.

    And as another poster has said, he's pushing his products.
  6. I agree, he is pushing the product.

    Try writing a generic code generator, with gui and mid tier and db and workflow....that also caters for the demands of a marketing lady and a senior techie who likes globally centralised logging, with the option to replicate the db.

    You can't do it. Not without making your proprietary technology at least as complicated as the programming languages you are 'replacing'. All you can do is select a few architectures which you recon are good and code for those. But just because you like them does not mean everyone will. End result, vast swathes of folks do not use the product.

    Also, the rate of change undermines all these abstractions, take struts as an example. I give it another year before it is swept away by something else. So the tool has to keep supporting it for legacy systems, and also support the new 'thing'. So the tools age or bloat.

    Or a more concrete example, design an abstraction tool that lets me place a button at pixel postion 3,10, unless dealing with data value 34 where it should be replaced with an animated graphic, with sound sample. and so on.

  7. I think the most we are ever going to see (at least for a long time) in terms of actual value derived from code generators is software that generates snippets, boilerplate code, and class heirarchies. By snippets, I mean those things that are easily automated -- SQL queries displayed in a web page, input field processing, etc.
    One thing to keep in mind is that we are already surrounded by much more code generation than we were even five years ago -- especially in our development environments. I wish we could automate even more, but I am highly skeptical about ever being able to generate dynamic business logic based on declarative statements. As always, the result will end up falling between the two extremes - no code generation whatsoever, and total model driven code generation. I don't ever expect to see accounting down the hall take a UML model and generate the app that he needs. At least not without my help. ;-)
  8. Hi,
    >Also, the rate of change undermines all these abstractions,
    >take struts as an example. I give it another year before it is
    >swept away by something else. So the tool has to keep
    >supporting it for legacy systems, and also support the new
    >'thing'. So the tools age or bloat.
    I think the rate of change currently undermines application developers/maintainers. An application of MDA for struts would be that you would just use an activity diagram to model the flow between your pages. If for example the DTD of struts.xml or anything like that changes, the only thing you've got to update is a central mapping. You would use a template IDE (OptimalJ calls it a pattern IDE, ArcStyler calls it an MDA cartridge IDE) for this purpose. The tools do not age this way, the only thing that can happen is that your mappings age, but the same is true for hand-written struts code if you do not touch it after the platform changes.
  9. I would like something to read my requirement analysis and produce the software automatically.
  10. I am waiting for Star Trek programming:

    Programmer: "Computer, build me an accounting software, and make sure it works this time!"

    Computer: "No problemo!"

  11. FYI, Jack Greenfield is now working for Microsoft as a .NET Architect. Notice the word "former" in the title.

    - mike
  12. Man, he's a traitor to his own his own advocacy.
  13. What happened to the interview with Floyd Marinescu(?) ?
  14. Found it :)
  15. Greenfield is a little behind the curve on the automated coding statement. . .by about 5-7 years. Automated code generation is already here in the form of Genetic Algorithms, which are designing everything from jet engines to I-Beam support structures for the Space Station.

    If automated coding processes could have adapted for coding business applications, it would have happened by now. The reality is it hasn't and for good reason - it's very difficult to do. Even if you could get the GA engine to generate some of the code, it wouldn't be much different than what we see already - frameworks, templates, etc.

    Greenfield needs to be a little more circumspect when he makes these kind of "Brave New World" statements.
  16. There is too much ignorance involved about code generation. I often hear comments saying code generation ONLY produces boiler-plate code, or that it's just revisting 4GLs. Project ACE should dispell this myth.

    Code generators should be compilers for business specifications.

    However, if you take full UML [despite it's complexity] it's still not rich enough in either business information to generate a working applications. I can't see the UML Model Driven development working. I say this from personal experience of having written JGenerator (www.javelinsoft.com/jgenerator) and generated out many *real-world* (as opposed to petstore) systems.

    I agree with some of the comments on this website that these ivory-tower architects should start writing generators for real business users so that they can find that the semantic atoms that their 'enterprise' frameworks provide are objects of their own imaginations, and insufficent to cater for real business needs. (e.g. EJBQL).

    Component and domain oriented languages make good bed fellows in this problems space. Component oriented languages seperate the type (data) from the modules (architecture), whilst Domain oriented languages provide a business basis for the specification. A synthesis of these two languages produces a language that can specify architecture neutral applications using business specifications. A stronger statement would be that different working applications should be able to be generated from the same business specification, without significant technical input.

    Once you have a working application it should be possible to supplement it with specific technical information to render it and optimize it for a specific technical implementation. I agree with Jack that architects jobs should be to specify architectural design patterns, in generators, and that the next generation of languages should enable them to do that.

    As an aside project ACE isn't Component-Oriented as it doesn't seperate type from modules (i.e their objects are more entity beans than pure beans), which (in my experience) will trip them up when they start trying to integrate multiple implementations.

    I think Jacks' reply on Aspect Oriented programming could be better. In my experience, aspect Oriented programming comes into it's own when you have standard components that you want to supplement. For example, Aspect-Oriented languages allow you to modify a beans setProperty (for example to convert empty strings to nulls - if you want to start using the bean in a JSP). But Aspect-Oriented programming conflicts with Pattern-Oriented programming which would advocate a transform pattern on the setter.

    There are a number of articles on this subject on http://www.softwarereality.com/design/domain_oriented.jsp
  17. I think the proof of the pudding is in the eating. If the tools Jack is talking about actually ever become available, if they turn out to be cheap (or better free), easy to use, robust, non-invasive and pretty like Eclipse, everybody will jump on the wagon. I'll take all the help I can.

    And another thing. With these custom languages, I think, we are finally stepping away from the notion that abstractions are a good thing. We are now hiding those abstractions under some syntax. Good. I think that's the right thing to do. I bet dealing with abstractions directly is fun for some, but not for the most of us. I spent the last 10 years trying to understand objects and I am still not sure I fully grok them. Don't give us abstractions - we want instructions.