naysayers have a look at codefutures.com. not exactly UML, nor MDA, but what i’ve referred to as DDD, Database Driven Development (they don’t). for those of us in the “usual” application development world, learning what Dr. Codd had to say, and riding it to its ultimate conclusion (the data is the model), can be enlightening.

or think of it this way: all the data needed to guarantee its mutual integrity can either be in the datastore, or scattered as hardcode in your programs. olde folk, who learned before Dr. Codd did his work, and java kiddies who think that XML is modern (it isn’t; it’s just an amateur IMS) both like to ignore this reality.
as to the UI, generator rules can make that look anyway which doesn’t violate data constraints: html, css, javascript, AJAX. the View is separate from the Model, yes?? with DDD, the Model is also the Control, cute.

while there are XML driven generators galore which are based on user views, the systems that come out are based on naive data structures (usually just files mapped from the screens images), Flat File City.

takeaway–> there is a better way, and while that better way may vary across humans, it will always be founded in the integrity constraints supported by the RM. code is emitted solely to provide some UI which provides update. start with a solid data model approach, and the rest comes out in the wash. it has to.

Or for GUI’s, graphical designers (like VB’s) aren’t always the best. They can lead to a lot of fiddling for forms that change often. For example, database-driven text program created GUI screens can be big time savers.

And I wonder if anyone here has worked in a manufacturing environment. AutoCAD is not a modeling program, it’s a drafting program. The mechanical design world seems to be going to domain-specific programs, with 2-D programs still used for some things (e.g. road layout), specialized 3-D programs for architecture, 3-D solid modelers (SolidWorks, Solid Edge, Inventor, Pro/E, NX, etc) for designing machines. The 3-D solid modelers are a big improvement over AutoCAD, but still really don’t model the machine.

And going from a 3-D solid model to manufacturing, translating to CNC isn’t automatic; it’s still commmon to use 2-D prints as the intermediate step. Even if a part is to be machined, there are often various ways to make it. And there are many other methods that can be used.

Once the machine is made and put together, then there is debugging and fixing the problems. Oh, and specifications–well, the lack of good specifications from the customer–are typically a big problem.

So electrical and mechanical analogies aren’t very good for software. I think higher-level, mostly text-based languages, are the way forward. But software will always be hard, just as chip design is hard (hmm, chip designs are often late, masks have to be re-spun, and sometimes the chip is scapped. Just like software projects failing, but probably not as common).

I know we have had issues in the past with CASE tools and with earlier versions of UML and other code generation tools. But, I have software developers that I have worked with that won’t even give it a thought – they immediately get out their favorite source code editor and start writing code - so much for design.

I haven’t read Mitch’s book list and I’m basically just a glue layer guy but the only value I’ve ever found in UML is for documentation, and even then, sparsely used with disclaimers that it should not be trusted as an up to date API reference.

The main issue is I don’t find them useful to help design - it’s a theory / practice thing. Given a dynamic language I can put together a prototype of what I’m trying to do faster than I can draw it. In building the prototype, I’m confronted with real issues which need to be factored in e.g. specific error condition handling or quirks in a data structure. Time spent working on a theoretical model is time wasted in my state of mind.

In theory I can see the point for CASE tools for when designing “big systems” but in practice I don’t believe in “big systems”, just many small parts who’s interactions evolve over time.

That said, right now I’m half convinced by BPEL: been seeing stuff done with Tibco while checking out ActiveGrid on the side. Even so, the sceptical side tells me nice as it may be, there’s a bunch of specific concerns related to the systems involved in any given business process which will nullify any benefits of the of a pointy clicky high level view. There’s some smart remark here I can’t find the words for but something like “software project success is governed by specifics not generalizations” - in a way, exactly the point you make about adding paths in VS.

At the extreme end, what if the whole notion of “software industrialization” is bogus? That requirements and current conditions will always be one step ahead of design and that, apart from foundation libraries, code is either work in progress or about to die. That we’re missing the point of that word “soft”?

An alternative angle might be that software should be doable by anyone rather than just engineers, as Sam Ruby argues in Homesteaders of the 21st Century

we need to enable a future where everybody can be a switchboard operator.

How many of you have actually used AutoCAD or any CAD tool for that matter? Did you know that CAD stands for Computer Assisted Design? The keyword being design, which is what this entire discussion of modeling and code generation is about, but completely lost on all of you.

I think Mitch is only focusing on one aspect of CAD systems, which is that they provide a medium for engineers to express product design, with the designs created being then able to guide manufacture. The obvious point to make here is that physical realization of a design is generally rather trivial. (If you’re aiming at mass production and realization isn’t trivial, then that’s a design flaw.) In programming, realization of a design is rarely trivial in quite this way: either its completely automatic - in which case “designing” is in reality programming - or it isn’t - in which case you’ll most likely run into trouble if you think of it as unskilled grunt-work.

But CAD systems do more than merely allowing designs to be created. The CAD file is a digital model of the eventual product, and can be used in verifying the design. The point of modelling is to identify issues prior to manufacture (and use). Trivially, if a design has solid components intersecting - physically impossible - this can be determined through their geometry. The outline of a car design can have a one-off realization in clay that can be used in wind-tunnel tests. Obviously there are more examples, but the point is that particular sorts of model can be used to give real information about the final product well before it exists.

In software this sort of thing is more rare. There are cases: a user-interface for a non-existant application can be faked up in order to see how usable it might be. But generally, in software engineering, “designs” and “models” tend to indicate pious hopes rather than anything more directly useful; and implementational issues generally only become apparent in, uh, the implementation.

[Incidentally, I work as a software engineer for a CAD company.]

I think the terms software development and software factories are horribly misguided. I’m not criticizing it in terms of what it does for the workplace, there are good arguments for the use of all this, .e.g. UML pictures seems to have utility in communicating to managers that work is being done and these also help the logging industry ( sorry Ryan I just couldn’t resist :) I’m critical in that I think it’s flawed from the standpoint of programming and computer science.

I come down on the side of programming as craft. Incidentally this is not new. Progamming as craft and/or art is the topic of Don Knuth’s turing award address. It’s a good read. As Aristotle, Glyph and others have remarked the building of “jargon” and DSLs is important for reducing the complexity of large programs by creating layers of abstraction. This is most eloquently put by Paul Graham in his book On Lisp. Of course Lisp, being beautiful, is the best language for this.

In some sense the use of UML is tied to OOP which itself has been perhaps too successful as a programming paradigm as it has fostered the illusion that we can model reality with objects. Perhaps the original post referred to has it backwards. A programming language doesn’t model a CPU. The CPU executes the code of a machine language, just as a JVM or CLR executes bytecode. A programming language has syntax and semantics, though it a task of researchers to work out semantics. But the semantics are the model. For instance venn diagrams and truth tables help us model classical logics, the model being a boolean algebra. The machines that run programs verify that the statements of the program are true in the model. As a simple example, if I write x + y = y + x we all think of that as true, but of course that’s only so with respect to real numbers, integers rationals and so forth. It’s not true everywhere, only in structures where + commutes. For a programmer this is silly statement but to a mathematician x = x + 1 is downright absurd. As was commented on above abstraction works well in declarative systems like mathematics but when we throw in time and state it gets ugly. This creates the tension between imperative and functional languages. In my opinion when syntax and semantics are close to one another better languages emerge.

Sorry for the digression, the point being that languages have syntax and semantics and between the programmer writing a J2EE app and the CPU there are many, many languages, all the way down, each with it’s own syntax/semantics, and at the bottom you have this accursed boolean algebra of zeros and ones which can’t even deal with real numbers without a boat load of software. The fact that it all works still really amazes me though as Glyph points out what we are trying to do in software is even more complex. Truth is not two valued in the real world, if it were programming would be a piece of cake.

Not to be too harsh or blunt, I think boxology is very useful when used in small groups of programmers collaborating to help understand how to carve up the tasks for the day. Pictures on the whiteboard work very well. I believe it was Minsky who said that programming is the best medicine for sloppy ideas. Let the cleaning folks always erase the board at the end of the day. Go off and write the pieces of code, integrate them and test, come back the next day and draw the picture again and see if it looks the same. If so then you might be on to something. Infrastructure has never been better in terms of refactoring IDEs and so forth but in many ways it’s all been around for many years. Documentation is only useful when it’s part of the code and done well. Code generation is very hard, especially for compilers. To do it at the application level and do it well requires simple syntax, imho, which is why Lisp macros work.

Visual approaches work well when a DSL is already in place, .e.g. Lego Minstorms, or Excel.

In the beginning was the cons

p.s. I’m writing this using this new Flock browser, it’s neat!

(Overall, I have to say I am very disappointed with
the direction the material on lesscode.org has been taking.)

Email me for an account (rtomayko@gmail.com). I’d love to have you posting here if you can free up some time. I’d rather some of your comments be posts with more exposure anyway and I’ve been reading your blog for some time now with delight.

But text based programming languages are prolific for a reason and I’ve seen nothing (even after reading the portions of material you’ve provided that I can find online) that suggests that is going to change any time soon. Text is simple, malleable, robust. It offers a common interface and set of interaction techniques regardless of domain/vocabulary. Don’t underestimate the value in that. Text is not a problem we need to solve, it is an amazing example of the power of simplicity and the advantages of systems that follow the principle of least power. If people who have been programming for a long time have grown an attachment to text it is not due to lack of value.

When I say I want to “raise the level of abstraction” and reduce code, I’m not saying I want to get rid of text. I don’t see text as being the problem. I’m saying I want a more expressive language that doesn’t require needless syntax or GUI wizards to accomplish the simplest of tasks. I want to be able to express my intent quickly and cleanly, preferably without leaving the language. If I must leave the language in order to express something, it is a deficiency of the language. If there is something I cannot express quickly or cleanly, I should be able to build libraries or build up the language directly (i.e. DSLs) so that I can express something quickly and cleanly. There are languages that allow these types of activities (Ruby, Python, Lisp, Smalltalk, etc.) and those that do not (Java, VB.NET, C#, etc.). The latter tend to grow a large crop of static code generators, GUI wizards, and language manipulating IDE features. The former do not. The reason isn’t because people using Ruby or Python are junior programmers incapable of understanding the features these tools provide, it’s because their languages are sufficiently powerful to not require them. You are assuming that because C#, VB.NET, and Java require additional apparatus to reduce code and keep the programmer productive that all languages do. That just isn’t so.

The feeling I get is that your issue is with programmers who refuse to consider graphical tools where they make sense; that’s completely understandable. Saying that all graphical tools are worthless is something you’re likely to hear only out of the greenest wannabe unix hacker trying to be cool. Ignore them and move along. But you seem to be taking the opposite position - that text is some kind of legacy technology and that we should be trying to do everything graphically without stopping to consider that many people don’t subscribe to that line of thinking. Text is amazingly powerful. I, and from the looks of things few of the people that read lesscode.org, are in any hurry to be rid of it.

I’m not sure how else to say it, this just isn’t what we’re talking about here. We’re using simple, proven technologies (text, the web), dynamic languages, and very old techniques that have been around since the dawn of computing to get real shit done right now. We’re not trying to figure out new and revolutionary methods of writing programs because we’ve been down that path and been sold that story 100 times before and its never worked out. What has worked is small and simple improvements to existing tools that are already working. This isn’t a conclusion you come to through lack of experience, it’s the conclusion you come to having been beat up by experience.

Lastly, I have to ask that you consider the responses you’re receiving from the regular readers of this site with respect and not respond with such hostility when they take the time to leave their thoughts on what you’ve presented. I don’t mind you posting stuff that’s a bit different because I think the discussion that follows can be healthy but I won’t tolerate the attacks (e.g. “uneducated”, “junior programmers”, etc.)

wish you could be more specific in why you would say stay away from code generation, from hands on experience.

Fair enough. My experience with code generation has been:

1 - Generated code is skeleton and needs to be modified
2 - Generated code is intended to be complete, doesn’t need modification

In the case of 1, I’ve found the generation of skeleton is generally not very useful. Typically the skeleton is just laborious decoration, symptom of a highly verbose language (J2EE comes to mind). My preference would then be to use a higher level language.

In the case of 2, I’ve found the tools either buggy, or not capable enough and the generated code in need of extension / modification. Bugs in generated code is an absolute nightmare, should never happen, but has happened frequently for me (SWIG being the only notable exception, although that has its hiccups too). Extending the generated code is also a nightmare, because you typically lose the ability to go back to the tool that you generated the code from.

Basically I’m saying that unlike scripting languages, the code generation mechanism typically doesn’t have a way of creating extensions (tieing in c/c++ code). That turns out to be very painful.

Any case, I invariably end up with my hands in the generated code, cursing and crying.

For the record, I am not flogging any product here. Glyph asked specifically if I had any data to support the notion of modeling and code generation is a good idea - rather then quote some scriptures, I would rather use a personal real world example - which I did share and which people took as flogging a product. I don’t work for that company anymore and nor do I get any financial benefit from product sales. The point is that I believe that modeling (using DSL’s specifically or generically called model-driven development) can be used for more than just pretty pictures. The many references to several commercially available DSL’s, code generators and extensive reference books out there support this belief. However, I am not a proponent of UML for modeling code for generation.

Even if you do vehemently disagree with some else’s postulations, at least have the common courtesy to back up your comments with some actual facts and/or personal experience. Parand, I thank you for at least saying that you have had some actual experience with the domain subject, but wish you could be more specific in why you would say stay away from code generation, from hands on experience. So what was that experience? That’s what I was hoping to hear and learn from my peers on this forum.

It says in the about box that “lesscode.org is a place to advocate, discuss, and practice the art of using less code to get more done. We shun complexity and challenge the status-quo when it impedes our ability to simplify our development tools and processes.” That’s what my original post was about.

All I hear is everyone’s uneducated opinion and no facts. Someone said code generation is just plain BAD. Well, so is smoking, but so what! Give me facts and real hands-on experience, not just your holier than thou opinions.

I believe that’s a crack at me? For what it’s worth, I’ve written 3 compilers in my life. I’ve done a fair bit of code generation. I’d recommend against code generation from hands-on experience. I’ve also created a couple of higher level languages. Not so bad there. I also created a commercial product that allowed visual programming. Neat, very useful for specific domains, but ultimately pretty limited.

And I’m spreading FUD because I have a company or product to shill here… Oh wait, I don’t. Hmm.

Any case, very entertaining thread.

My point is simply that I’ve never found UML useful other than for communicating high level design across teams. I am certainly no UML expert - barely a beginner in fact. If there are better tools, I’m all for it, but I haven’t heard anything here that sounds like a solution.