Slashdot Mirror
Code Generation in Action
Overview Code Generation in Action, CGiA to its friends, is presented in two parts. The first part is four chapters, and covers a code generation case-study, the basic principles of code generation, including the different types of code generation strategies together with reasons why you would or would not use each strategy. The book's chosen toolset for building generators is presented next, and then some walk-through examples of building simple generators wraps up the first part.
The second part is a kind of a cross between a cookbook and a list of engineering solutions. There are nine chapters with the breadth of solutions covered being quite impressive, covering the gamut of generation of user interfaces, documentation, unit tests and data access code. Each chapter presents a couple of solutions within its topic area, often for different technologies within that topic. For example, the user interface chapter covers the generation of Java ServerPages, Swing dialog boxes and then Microsoft MFC dialog boxes. No favouritism here!
What's To Like There's a lot to like with this book. The writing is very clear and of good prose. I found the introduction to be very compelling, and I felt completely drawn in by the opening case-study. The four chapters of part one are a concise case for code generation, and would be very useful information to help persuade co-workers and management of the positive risk/benefit ratio with trying code-generation on a live project.It would be impossible to try enough of any solution from part two in a time-frame short enough to make this review useful, but in the solutions that match my areas of knowledge, I found myself admiring Herrington's straight-forward and pragmatic approach.
What's To Consider There are two aspects of this book that I want to flag. One of these aspects, some will love and others will hate, and that is the choice of generator language for CGiA. The author has chosen to use Ruby as his working language. This is an interesting choice. Ruby is certainly a language that is inspiring a lot of admiration these days (in fact, it's hard to get Dave Thomas to stop talking about it :-), but with the majority of the code-generation examples being for Java-related technologies, I wonder why Java was not selected instead.I also found myself wondering about the lack of discussion of how to integrate these Ruby tools into a typical Java build process. Many developers I know use ant to bring automation and consistency to their builds, yet the book doesn't mention this. (JRuby anyone?) Certainly something to consider for the second edition or future code-generation authors.
SummaryThis is a masterful tome that inspires and delights, although the two issues raised above did cost it a perfect score of ten.
Table Of Contents- Code generation fundamentals
- Overview
- Code generation basics
- Code generation tools
- Building simple generators
- Code generation solutions
- Generating user interfaces
- Generating documentation
- Generating unit tests
- Embedding SQL with generators
- Handling data
- Creating database access generators
- Generating web services layers
- Generating business logic
- More generator ideas
You can purchase Code Generation in Action from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Richard Hell and Codeoids
Code generation is definitely something programmers of large/complex projects should look into. There's a lot of different forms of it, and I'd be surprised if people haven't used on form or another already.
My personal favorite trick at the moment is describing interfaces in XML, and getting multi-language bindings and docs out of it with a few XSLT scripts. Techniques like that makes script language bindings easy as pie (as do other systems like Swig).
Software Engineering is not just there yet. It is a nice concept, but not pratical. Rational Rose does it to a certain extent.
Consensus is good, but informed dictatorship is better
Code generation is a time-saving technique that helps engineers do better, more creative, and useful work by reducing redundant hand-coding. In this world of increasingly code-intensive frameworks, the value of replacing laborious hand-coding with code generation is acute and, thus, its popularity is increasing.
Why not put a little bit about code generation in the review. Even a little blurb like "It builds the mundane portions of coding" would have helped out a bit.
to ask this question?
It's a book review for crying out loud. People like to know the specifics of what is covered, and the table of contents helps out. I find it encouraging that the chapters stick to the topic in the title. I'd probably not buy the book if there was a chapter entitled: 10. The F6 key, right between F5 and F7.
-- Fighting mediocrity one bad post at a time.
Froogle Price comparision for this book.
Nero-burning ROM for Linux!
This book looks like a poor excuse for management drivel! If we could just get rid of those pesky programmers ... ah! Code Generation! Couple this with the move to push everything offshore ... and voila! no more pesky programmers. Now if we could just get them to finish the powerpoint compiler the development team was working on ....
PHB
coding's not hard. just create these dots and we'll connect them for you. just press a button.
And Lisp has been doing it for years, as has, to a lesser extent, C++ (and Ada) templates. And the good thing about Lisp metaprogramming is that it is in the one language - lisp.
Having 1 language generating another - Ruby and Java - is the recipe for confusion and complexity.
Other option:
You can use external tools (perl scripts,etc..) to generate some really boring files that withouth this tools need to be by hand.
Code write by hand can have really hard to fix bugs, its better to do it automatically.
And if everything is sync with "make", you have a beaty machine.
-Woof woof woof!
They make the visual of some pale, skinny nerd with a "Got Root?" shirt on, banging away on a keyboard in a poorly lit dorm room sound exciting.
My rule of thumb is if I find myself writing code that bores me silly and thinking "a frigging monkey could be taught to code this piece", I will strongly consider writing a program to write the program for me. Be warned about the maintenance and readability issues though in larger development projects where there are a lot of mediocre programmers around. You can always assign those mediocre programmers to hack on monkey-easy code, but you can't get them to hack on a code generator, so carefully consider the nature of the development organization you are dealing with, and the tradeoff between available "high-value" time and resources vs. "low-value" (i.e. monkey coder) time and resources. This perspective has been brought to you by my pointy-haired side.
if you ever read the "Pragmatic Programmer" book about software developer practices, it mentions that they used code generation for many things. Code generation definitely helps when you have many similar but not same implementation.. But, in Java or any other object oriented languages, inheritence can be used to avoid similar looking code (which is what code generation would do).
But, even here, I think the UI pages, or template based generators definitely help. There was a tool by DevelopMentor which used to generate code for ATL. It was based on templates..
Why doesn't it cover the infinite number of monkeys on typewriters method that Microsoft is clearly still debugging?
Turkeyphant
But apparently, it is not. I, for one, wasn't too happy seeing the term "code generator" applied to superficial software that generates HTML/user level code for standard dialog boxes etc. HTML isn't code in the first place, anyway.
Maybe I'm being too fussy about this, but a code generator, traditionally has always meant a part of the compiler back-end which actually translates intermediate code to machine-level instructions. VB and other UI tools generate stubs for the most part...well maybe they are code generators, but I'm just not too happy about the choice of terms.
An Indian-American Hindu committed to non-violent thought/speech/action alarmed by the global explosion of radical Islam
if i want to see code generation in action i do /usr/src/linux && strace -F make
cd
just VS .NET. it does all the work for you. or so the ads say.
Too many buzzwords!
I wrote a generator that took a sql file and generated a light java database persistance layer. My reasons for doing this, in Ruby and not Java ,boiled down to the horror of manipulating Strings in java vs. the ease of it in Ruby.
The other advantage using one language to generate another is that there is less confusion about what code is part of what. In my case I had ruby in the generator and java and MS sql in the text blocks that were being generated so it was easy tell thing apart.
Oh really?
Code Generation is for people who don't understand or are too lazy for abstraction, and it will ALWAYS have the problem of, what if you want to go through all your projects and change one single thing about the generated part of your code? What if you have a hundred tiny projects, each of which contains the generated code snippet that needs to be changed? Let's hope either the change you want to make is very simple or you are very good at regular expressions.
If you are able to clearly separate your code into "You can edit here" and "You cannot edit here" chunks, you can DEFINITELY seperate your code clearly into local chunks and delegated chunks-- i.e., "you cannot edit here" means you just do stuff, "you can edit here" means you talk to a delegate object or method. If EJBs are so frigging complicated that you have to do a bunch of repetitive grunt work that's the same every time you do it, you should somehow be building a slightly higher-level abstraction off of the things you do in common on each EJB and working from there. If EJB does not make this possible you should perhaps not be using EJB. There's always some way to do these things through abstraction, and it will ALWAYS in the end wind up more flexible then either generated or cut and paste programming.
If you've got a code generator sitting around, then sure, go ahead and use it. But I cannot think of any case in an object-oriented language where it would be both less work and more maintainable to write a code generator than to just abstract away the parts that would be autogenerated..
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
When I saw the term "code generation," I immediately expected it to be about compilers. That's how the term has been used for, hmmm, 40+ years now. And it kinda is about compilers, sorta, in a bizarre, "charts & diagrams" software engineering kind of way. But you have to hunt to find a solid definition of the modern buzzword "code generation" that doesn't reference other unexplained acronyms and terms. And the review doesn't explain it either!
This is one of those depressing, faux engineering, topics like "patterns" and "factoring." Once you dig behind all the buzz and feelgood articles, you find out that it's simply a popular renaming of what's been standard practice since before most of us were born. ("Factoring" was a key topic in most Forth books from the early 1980s, but it has been reinvented and rebranded as a cool 21st century thing.)
And also Perl provide some features that where very cool to generate Perl. Sooo cool that you can have a Perl app that generate his own source. You can do that with Lisp?
-Woof woof woof!
I use XDoclets a LOT. I mean A LOT. It does some really cool stuff for us, from dealing with MBean interfaces to just about anything else that you can think of.
It's also very tightly integrated with ant and maven, the two build tools that are used in just about every project I'm involved in.
You can find out more about it here.
$0.02 (CDN)
I did some code generating in my program xkbset, which is a CLI program to set various parameters of the XKB features of X Window. The program is a bit like xset, and so one might write a line like:
# xk bset
xkbset bouncekeys 4 -mousekeys sticky -twokey
to set various parameters. Well basically the program is a loop that goes through argv interpreting the arguments using a bunch of if statements (just like the internal structure of xset). It seemed like way to much work to write all these if statements, so I wrote a "configuration" file that defines the various arguments, and a perl script that turned the configuration file into a C program.
It was a home grown code generation attempt. I really am quite pleased with it, and it is the only open source program I have written that people actually seem to use (mostly people with Toshiba laptops that need to get rid of key bouncing problems).
http://www.math.missouri.edu/~stephen/software/
(Somehow there is an extra space added in the URL between the k and the b - it shouldn't be there.)
All of these generators had two things in common: they used Bison as the parser and Flex as the lexer. Since the book uses Ruby in its examples I doubt that it covers Bison and Flex, which is a shame since they are extremely useful tools.
Another thought I had is this: where is the line drawn between code generation and compiling? Are they the same thing? The Dragon Book (Compiler - Principles, Techniques, and Tools), says "...a compiler is a program that reads a program written in one language - the source language - and translates it into an equivalent program in another language - the target language." They seem like the same thing to me.
Honk if you're horny.
The author has chosen to use Ruby as his working language. This is an interesting choice. Ruby is certainly a language that is inspiring a lot of admiration these days..., but with the majority of the code-generation examples being for Java-related technologies, I wonder why Java was not selected instead.
I think the author makes it pretty clear why he chose Ruby instead of Java. Essentially, in order to parse text (which is one of the primary functions in code generators) you would have to write 2 to 3X more code in Java than you would in Ruby. Java is not an optimal text parsing language - first off you have to find a regex engine for it. That leaves you with choosing one of the scripting languages: Ruby, Perl or Python.
Here's what the author says about the cons of using Java for code generation (page 41):
* Java is not ideal for text parsing. (I would agree)
* Strong typing is not ideal for text processing application (again, I would tend to agree, strong typing only gets in your way)
* The implementation overhead is large for small generators. (you'll be writing a lot more java code than you would in Ruby to get the same thing done)
Overall, I'm finding it to be a great book, and the use of Ruby for implementing the examples is a plus as far as I'm concerned.
As far as integrating Ruby into the build process goes, I recall hearing something about a project that uses Ruby to drive Ant.
The linked article on devx.com really makes me not want to use code generation :-). Let's pick out some fun quotes:
;-).
"Even if code generation could build 100 percent of the application, there will still be an endless supply of boring meetings about feature design."
----
" For example, when a lot of code needs to be written to perform relatively simple tasks, engineers can smell bad design. The EJB platform requires the construction of a bunch of classes and interfaces for each database table. Some consider this a design smell."
----
Wow. So I have boring meetings and a really bad platform to look forward to. Yowza, bring it on!
OK, I'm partially joking here. But I think it's worth considering... when we're glad that we have a tool to alleviate the hassles of using a technology (like EJBs), maybe the technology and platform needs to be reconsidered? Shouldn't the platform perhaps do more to "hide" the complexity from us?
I'm struggling with this in a similar form right now with SOAP. I'm deploying a set of SOAP services in Java using Apache AXIS implementation. It does a lot of the 'heavy lifting' for you, but I'm still struggling with the particulars of how to deploy a service, serialize/deserialize my classes, ensure this API works well across a variety of clients (I'm testing with Perl, PHP, and Java), etc.
It can be a bit daunting. But... simple things *are* simple, and the level of code generation available is just about right. I don't *have* to generate a bunch of "helper" classes to put a SOAP service out there, the Axis implementation hides most of those details. I *can* generate additonal classes, and customize my WSDD and WSDL files to handle more complex situations, though. So, it's not perfect, but maybe it hits the mark a little closer.
Anyway, code generation can be great. I've done it before with things like interface creation (take an interface description and go to either HTML or Swing), and it can be very handy. But I wouldn't want to implement a system that is unusuable as a platform without those tools. Real programmers use vi
It's a strange world -- let's keep it that way
Huh? Software engineers use more software than anyone else. We have tools for our tools. I found the above statement bordering on the ludicrous, and almost stopped reading at this point.
Code that is copied and pasted to multiple places is difficult to maintain properly across all of the copies. Active code generation does not suffer from the same maintainability issues as copy-and-paste coding. When you need fix something, you apply the bug fix to the templates used to generate the code, which then propagates the fix to all of the code maintained by the generator. This design ensures that no code that needs fixing is left scattered around and forgotten.
That's why we use functions and classes. Then, when you change your function, the changes are magically propagated to all the places in your code where that function was called! Copy and paste programming has been frowned upon pretty much since the days when the goto was declared bad programming practice.
It really sounds like this book is just putting on a fancy name for an incomplete set of good programming practices. Really, what is covered here that Design Patterns doesn't cover in a much more thorough and professional way?
No, Thursday's out. How about never - is never good for you?
I became a code-generation convert about two years ago when I first encountered Perl Data Language -- what made PDL development feasible was a code generator by Lukka, Glazebrook, and Soeller: their generator ("PP") writes all the loops and conditionals that do vectorized processing of large arrays.
Of course, PP has its limitations -- the age old complaint of engineers is that they will eventually outgrow any code generation framework -- but it's simple enough to augment the generation language or, in extreme cases, to sidestep the parts of the functionality that you're not using.
There are usually two cases:
1. The need to automate the generation of some type of code or script for a large number of test cases, where the scripts would otherwise be generated manually.
2. The need to generate tests to excercise implementations from what can best be described as a machine readable description of interfaces and exchanged data types.
The second case is rather interesting in that all the information in most client/server IDLs is usually sufficient to describe the objects that can be passed (via the building of the stubs for their marshalling/demarshalling), as well as the interfaces themselves.
Of course, compilers for more traditional languages generally the structural information for object classes directly, and could output this for the benefit of automaticallly generating test clients for a particular interface, but getting that data out of the compiler's symbol table is often like pulling teeth.
You could've hired me.
I work on a large Java project where we use entity EJBs. Code generation isn't an _option_ here, it's a necessity. We have hundreds of tables (over 500) and each of them has an EJB. Writing out the infrastructure for each and every one by hand would be a huge and boring waste of time. I think the necessity for code generation actually points to a problem with design of EJB itself, but that we're pretty much stuck with.
You might want to check out XDoclet next time rather than write your own parser/generator. It's pretty widely used now and has lots of tags for many common uses like EJBs, Hibernate, web.xml generation for all the major appservers, etc. It's also integrated with Ant and it looks like Sun is going to be borrowing some ideas for use in Java 1.5+.
...it's really important to use them properly. "No pretense of ambivalence," indeed! What, are reference materials supposed to be ambivalent?
e nt :
From http://www.hyperdictionary.com/dictionary/ambival
1. [adj] uncertain or unable to decide about what course to follow; "was ambivalent about having children"
2. [adj] characterized by a mixture of opposite feelings or attitudes; "she felt ambivalent about his proposal"; "an ambivalent position on rent control"
Is that really what anyone would expect from a reference material? I think the poster wanted "...no pretense of objectivity."
Not that I care that much, of course.
Cheers
-b
I worked at a telco where we generated C code on the fly from high level Structured Definition Language for the main call control processing.
It was a great idea... in theory. In theory, it was impossible for the implementation to get out of sync with the detailed design (the SDL). In theory, there's no difference between theory and practice, but in practice there is. Some of the features that we had to add simply couldn't be modelled in SDL, plus there were performance issues, and it produced ugly source.
It was used for fifteen years (yeah, pre-ANSI), but it eventually collapsed under the weight of all of the hacks that were required to work around the limitations. We eventually had to admit that the behaviour of the complete source (generated plus all the stuff around it) was now so different from that defined by the SDL that it was no longer worth putting up with the limitations of the SDL.
In the end, we just took a snapshot of the generated code and set developers free to actually fix it rather than hack around it. At that point, there were only a few people left who even knew SDL, so there were very few tears shed. The rest of us cheered, and the product got significantly cleaner as we refactored the bejeesus out of all the generated C and removed the hacks.
I'd recommend giving code generation a try, but don't be ruled by it. Once the product is mature, if the code generation is limiting you, then don't be afraid to drop it and fix the lower level generated code.
If you were blocking sigs, you wouldn't have to read this.
Is there a party when you break 100?
That is a fucking good site. I think I'll switch from /. to there!!
Most of the examples of code generation I've seen around are basically kludges around insufficiently powerful high-level programming languages. Datatypes and representations should be able to be generic in the programming language; this enables directly coding at the desired level of abstraction. Check out ML or Haskell for one cut on these ideas.
That said, I've been doing CG for a long time :-). The M4 macro preprocessor is a fine tool for this task. See e.g. my student's M4 CG for XCB: a classic example, as we were stuck with C as the implementation language (indeed that was the whole point).
Try writing it in Java, and I'll wager that you'll find out why. It'd probably be quicker to write a code generator to write it for you. Use the right tool for the job.
pb Reply or e-mail; don't vaguely moderate.
My website at http://www.pdrap.org uses code generation. All my pages are static html, and are generated by a Python script that I wrote from a source+template. The source directory is organized the same way that the site is organized.
When I want to add a new page or section, I just make a new directory and drop a document into it. When I want to add photos to my photo album, I just make a directory and drop my photos into it. The script takes care of everything else. It reads the source directory, generates new pages into a cache area. Then I use the unison program (rsync protocol) to put all the changed pages into the web server directory.
The end result is that I can add whatever I want to my website without having to write html, or run any CGI, javascript, or anything like that on the webserver.
If tits were wings it'd be flying around.
Why would you ever create redundant code? With or without code generation? Isn't that why we have modular programming languages? Functions and sub routines? Templates and header files? Am I missing something here? This is the first I've heard of it, maybe I should do a little more reading?
Unlike other generation engines, the Sandboss engine concentrates on the application requirements + not the implementation technologies (EJB/XML/etc). Using Sandboss, you can plug in new generators (to change the persistence layer from EJB to straight JDBC) without modifying your app's code *at all*. Generators like XDoclet embed technology dependencies right into your app's code, which makes switching technologies harder. I'm a developer on the project so perhaps I'm biased, but I think it's pretty damn cool.
The parent is right to warn about maintenance. Meta-progamming of any kind requires a little more thought + understanding than many coders are used to. Generators are basically power tools, and as with any power tool if you're not paying attention you're likely to get yourself into trouble.
I also found myself wondering about the lack of discussion of how to integrate these Ruby tools into a typical Java build process. Many developers I know use ant to bring automation and consistency to their builds, yet the book doesn't mention this. (JRuby anyone?)
;-) ]
Just a heads up about integrating Java and Ruby:
There is a tool called rjni (Ruby JNI), from the README:
"What is rjni?
rjni exposes the Java Native Interface to Ruby. This allows the programmer to instantiate Java objects, manipulate them, define Java classes, etc... from Ruby. " [and that's the way it should be, use Ruby to drive Java
You could probably use this to drive ANT from Ruby.
You can find rjni at:
http://www.thekode.net/ruby/rjni
It only recently became available (in July) so it wasn't available in time to be included in the Code Generation book.
A quote from the Sun web site:
J2EE technology and its component based model simplifies enterprise development and deployment.
But now I hear that we need code generation to keep up with all the mundane tasks made necessary by the use of EJBs.
So we build a code generator and we have to maintain that.
This is on top of all the J2EE design patterns you are supposed to do because the world would come to an end if you just accessed a database table using JDBC directly.
Once in a while someone should look at the assertion that it would be harder to maintain a lot of imbedded JDBC code in your application than it would be maintain the 5 or so classes you need for each business object in order to maintain architectural purity.
"We can't solve problems by using the same kind of thinking we used when we created them." -- Albert Einstein
Surprise! It's Yet Another Cross Compiler (but it's not a yacc) :-P
Oh I don't know. Is this progress or not? I can't tell. One of the articles linked to says that code generation is not a symptom of bad design, but I'm reluctant to start using language two to write the code I originally intended to write in language one to be compiled an executed on computer A.
But then, on the other hand, we have yacc/bison and (f)?lex. These programs are used for generating C code for certain pieces of (or sometimes all of) a compiler. In a sense, this is the "code generation" that the book is talking about. This means that the idea proposed by the book is not wholey (bad sp) new and this increases the chance that the "code generation" idea is not indicative of a slippery slope into an evil hell of overcomplex code and languages.
So I ask again: Is this progress? I still can't tell.
Furry cows moo and decompress.
How big a pool of contributors do you think we need to pay NP to give set us up the goat?
Like I said, I have no idea what people are doing these days, this was back during EJB 1.1 days, pre-2.0, and we had a primarily message-based system that used JMS or other non-JMS compliant messaging systems like TIB. Thank god I don't have to touch EJB/Enterprise Java with a 10 foot pole anymore, since it's one of the most poorly designed systems imagineable - I love a lot about the Java language, but Enterprise Java needs to die a slow death.
For those who are saying that the term "Code Generator" isn't applicable - it is. Consider a C++ compiler. It may generate asm code, which then gets converted into machine code.
(generic) C++ -> (specific) asm -> executable bits
(obviuosly, the C/C++ compiler doesn't need to generate asm, but it's still code generation if it does)
Code generators just take this a level higher, so the code "life cycle" looks like this:
(generic) Diagram / CG description -> (specific implementation) C++ -> (specific machine) asm -> machine code.
Code generators have a great potential for easing coding and documentation. Just like GCC has many backends to generate code for different processor architectures, the code compilers can have different backends to make source code in different languages (C, C++, Fortran, whatever). Even better, you can run a different translator and get documentation out of the "source" - in HTML, DocBook, XML, or any other format you want.
There are tools to let you make UML diagrams (Google for "Executable UML" for great goodness), and generate real-time C code for an application, a C++ app simulator that runs on a PC, and documentation for the system, all from the same diagram. The tools are expensive (like $15k-$30k), but for large projects, they can be a great savings.
I saw a program called BridgePoint (from Project Technologies), which was able to generate embedded, real-time code that was as efficient (more in some areas, less in others, but it averaged out the same) as hand-optimized code done by expert programmers. It all depends on how goo dyour translator is (and this program lets you write your own).
Some books on the subject:
"Executable UML: A Foundation for Model-Driven Architecture", by Stephen J. Mellor and Marc J. Balcer
"Executable UML: The Models are the Code", by Leon Starr
"Real-Time UML: Developing Efficient Objects for Embedded Systems, Second Edition", by Bruce Powel Douglass
- The Sigless Wonder
I wrote a 'software generator'. It worked so well, they laid of 3 coders, and yes I was one of them.
"Hey, this guy figure out a way to increase productivty to a point we can let three programmers go!"
"Well then, lets be sure one of them is the guy who figures out how to save us money!"
The Kruger Dunning explains most post on
Could be a little OT...
Generating a lot of repetitive code can be done by the computer, but can't that be taken care of at a layer that the end user need not worry about -- by defining the higher level concepts at the language level?
Here is an example: In Perl, there is a module called Class::ObjectTemplate. It is a template that can be used to define classes. A code can work as follows:
package MyClass;
use Class:ObjectTemplate;
require exporter;
@ISA = ("Class::ObjectTemplate");
attributes("a", "b", "c", "d");
That's it. Now, MyClass has accessor methods, a constructor, and so on...
my $m = MyClass->new();
$m->a("Hello");
my $x = $m->a();
and so on.
The difference between this and the Code Generation utilities is that there is no intermediate code for the programmar to tweak. Everything is right there.
S
The .NET Framework has great built-in support for code generation, called the CodeDOM model. It is the mechanism used by all of the Visual Studio IDE wizards.
What is great is how they abstracted out the target language. Once you build a CodeDOM graph in your generator, you can pass it to any language generator (C#, VB.NET, J#, write your own) to create the result.
I worked on a project where we had a family of classes that obviously shared a common parent class. The child classes were similar to each other -- they each had a large-but-unique subset of a common pool of attributes. For example, Class1 had attributes A, B, and C, while Class2 had attribute B, C, and D.
There was no obvious class hierarchy to put the classes into, yet there were common methods (getA() and setA()). So I wrote a Perl script that generates the code for the classes, based on the attributes that each class should have.
Everyone I talked to about this problem said "inheritance should solve this problem, you silly fool!", but as I explained the problem in more detail, each person agreed that a code generator was called for. So, object-oriented languages and inheritance alone don't allow you to avoid similar-looking code, at least in my experience.
My question is, wouldn't developers rather use purely object-based packages, if they could, rather than code generators? I believe purely object-based packages could work for most Object/relational tasks and simple compilers. The code becomes more portable and maintainable and doesn't require the extra training for use of the code generator.
What is the concensus on this? Especially in corporate development environments?
From a link in the post....
For those not in on the new lingo, a design smell is a heuristic experience-based signal to an engineer that bad decisions about the logical or physical design of the system have been made upstream from the implementation..
and
Why do people use computers? We use computers because they make us more productive. Using a word processor is more efficient than writing a manuscript in pencil. An electronic spreadsheet is more efficient, accurate, and valuable than its paper counterpart
The guy is a genuis...
Delphi generates just the right amount of code.
world was created 5 seconds before this post as it is.
Instead, XDoclet should let you specify what you want accomplished, not how you want it accomplished. The code generation engine should be smart enough to figure out how to accomplish the specific tasks. For example, you should be able to tell the generator "this object gets persisted," not "this object should have a corresponding entity bean named Foo that can be found in JNDI as FooEJB." That way you can switch to straight JDBC by swapping out your generator, instead of changing all those javadoc tags.
Granted, this approach isn't appropriate for all projects (especially legacy apps). It makes writing new apps much easier though, and if you ever have to switch app servers or web frameworks you'll be thrilled.
... people round these parts don't take kindly to any positive talk bout things from redmond.
yer liable ta start a fight with that kinda talkin.
// "Can't clowns and pirates just -try- to get along?"
Comment removed based on user account deletion
Metaprogramming can be a useful and time-saving technique. It can also really mess up maintenance and future refactoring of a project. The time saved one developer isn't a good measure of the utility of a technique.
When I first learned lex and yacc, I got tempted to turn every single useful C/C++ library into a scripting language. "Think how much time I could save!" I thought.
Well, while I still think developing an application specific language (to basicially make pseduocode functional) is an occasionally useful technique, what I found was that it usually made project transfer and maintenance more difficult and more expensive.
Using XML and XSLT to do the same thing as lex and yacc doesn't inherently add much. The exception would be the evolution of an industry standard DTD for, for example, common UI constructs. I can see value there. But rolling your own metaprogrammer strikes me as rarely of real benefit. The metaprogram becomes another thing that must be documented, explained, maintained, and transitioned. It adds something that may not be easy to integrate into a present or future automated build process.
I guess I'm coming down firmly on both sides here. My point is that the cost/benefit analysis for a single developer doesn't necessarily align well with the cost/benefit analysis for the project as a whole. I think we have all seen projects that are in "tool and library hell" where developers have included their favorite libraries and tools willy-nilly (a technical term I like very much -- so concrete, so precise) so that no one can actually get the project to build. The GnuCash project was like that for the longest time (and it is still a bit messy if you ask me).
Faster isn't always better or cheaper.
In other words, I have seen metaprogramming do more harm than good in my experience. And the few successes come when the metaprogrammed portion was well analyzed and understood, and a standard could be made that would apply to an entire enterprise and not merely to a single project. More often than not, the inclusion of metaprogramming became the first reason to rewrite an application -- no one wanted to figure out or maintain the metaprogram. So they chucked it.
Generating code from database schemas and the like can be acceptable in my book. However, generating code just because it is repetitive and clunky is *not*.
...
:-).
In theory, good programmers never write repetitive code: they factor out functions, classes. Still, there are things that cannot be factored out easily, patterns of code that just do not map well into functions or cannot be abstracted away in whatever way the language provides.
Some languages are better at abstraction than others, but not many provides the ability to generate code (think of syntactic abstraction). This is where Lisp macros shine. They can hide ugliness I'm forced to do in the name of performance, define new control structures,
Think of the number times you were forced to go out of your way to solve a problem because while it was more correct or efficient it was less easy on the eyes. True macros would have helped. Well, divide that number by 10, the rest was probably your fault
A language needing a code generator for reasons above lacks power and for this lack a thousand small tools will appear all trying to plug some holes.
I started writing Visual Basic programs that generate VHDL code about 8 years ago. If I could get my act together and tighten up (read: productize the GUI) the program that generates Viterbi decoders, I could probably sell the thing.
--- Ban humanity.
Code generation is a practical, efficient tool for solving many problems where OO-style abstraction need not enter the picture. One such class of problems is building interfaces and glue code from external specifications.
A few years ago, I wrote a simple code generator that reads the SQL DDL for a large database and generates an object-based interface to the database. Client coders could then use the object-based interface to access the database. The advantages of this approach proved to be numerous:
- Single, authoritative reference specification.
The object interface was always in sync with the reference, which for
this project was the database schema.
- Richer compile-time error detection. The
projection of the schema into the object interface was fully available
to the type system so that many kinds of client errors could be caught
at compile time, not run time.
- Reduced opportunity for errors between subsystem
boundaries. Because the object-based interface was generated
by machine from the actual database -- and not derived from some
programmer's understanding of the database -- there were
fewer opportunities for impedance mismatch across the boundaries
of the application code and the database. (Studies of errors in
complex projects have shown that errors are more common between
subsystem boundaries, and so this benefit is important.)
mcc further states: If you can't think of any such cases, it's because you're thinking too small. Look at the bigger picture. For starters:- When the number of variables affecting the desired code characteristics
is large enough to make hand-coding (at any level of abstraction)
impractical. E.g., FFTW: "FFTW
uses a code generator to produce highly-optimized routines for
computing small transforms."
- When your code must conform to an external reference specification
that changes rapidly enough to make hand coding (at any level of
abstraction) impractical. (See my example above.)
- When the requirement for correctness is so stringent as to make
hand-coding methods impractical, mandating code generation from
a formal specification.
- When you must target an output language whose native abstraction
capabilities are too crude to capture directly the degree of abstraction
that is merited. Believe it or not, most popular OO languages
fall into this category for many commonly occuring problems. Hence the popularity of design patterns. (Compare, e.g., with the abstraction capabilities of modern
functional programming languages like Haskell and O'Caml.)
Make no mistake about it, code generation is a practical, effective tool that every programmer should understand. To dismiss it out of hand is a costly mistake.Easy, automatic testing for Perl.
Someone mentioned Lisp macros? Here's the obligatory Paul Graham links, posted AC to avoid karma-whoring:
Isn't this the same idea as using lex and yacc? Granted, most folks think of using those for compilers, but they can be used to do anything.
In fact, one of the chapters in Lex and Yacc from O'Reilly is a "menu generation language" to automate the tedious task of writing curses interfaces.
Am I missing something? Lex and Yacc have been around for decades.
-- Hello_World.c: 17 Errors, 31 Warnings
Code Generator, n.: A program for generating code that is buggier than itself.
How do you folks convert database objects to code, you mean you actually write this stuff out by hand over and over again:
getThing() { return thing }
setThing(arg) { thing = arg }
I have better things to do!!
One thing I don't really like about code generation is that the code generator/templates are outside the language as an "extra step" Dynamic languages like Perl and Ruby *really* make this a useful feature because you can bake it right into the language using runtime creation of methods and/or introspection.
For instance *all* my Perl DB code looks like this:and then usage:In Ruby it's even more elegant since the language is designed for this sort of thing:Really, if you're EVER programming and you find yourself repeating the same steps over and over, don't sit there, AUTOMATE them!
JBuilder and Eclipse, arguably two of the most popular Java IDEs, do tons of code generation for you.
Seriously, what kind of programmer is wasting their time writing accessors and mutators anyway?
This goes doubly so for generating skeletons of implemented interfaces or extended subclasses. Java coding benefits so strongly from this that it's almost unimaginable to do it any other way.
I'd guess the author chose ruby not java for pragmatic reasons inherent to interpreted languages over the rigidness of a compiled ones. You dont need the speed of a compiled language in the context of the article. Besides 'harnessing tools' was not the subject - but i'd bet ruby has similar fascilities that were not mentioned. Belittling the author's choice of tools assumes that you understand the problem more so than he.
my other sig sucks less
I've spent the past 7-10 years working with different code generation approaches. My latest R&D efforts meld a variety of the techniques I'd used in previous efforts to provide a code generation engine that has proven flexible enough to produce RDBMS schema scripts, C++, Java, etc.
Even better, I've been able to work towards a higher level abstraction which allows me to change the architectural "glue" while maintaining a consistant application developer API. (i.e. Choose amongst different RDBMS servers, different network interface technologies, different system architectures, etc.)
In a sense, I've spent years trying to "teach" my computer to produce code the same way I do by hand. With any luck, it'll be production ready in another few months, and used to service a few early adopters as a test replacement for the offshore junior coders that write the same code by hand.
The question isn't whether the technology is feasible, but whether I can make a living by providing code factory services.
I do not fail; I succeed at finding out what does not work.
If the complexity of your generator is too much for people to maintain, it sounds like you're still working with ad-hoc hard-coded generators. It's helpful, but as you say, it creates a whole new set of code to maintain.
There are better approaches.
I do not fail; I succeed at finding out what does not work.
Code generation has its place, but one needs to be ever watchful of the dangers presented by anything that claims to make programming easier. In summary, it risks creating a bunch of code you don't really understand and can't debug. Ellen Ullman's 1998 article "The dumbing-down of programming" is still good reading.
Everything in moderation.
Search 2010 Gen Con events
Thank you; that was the most insightful comment I've seen here all day.
Code generation, like design patterns and such other trendy things, is just a technique you can use with weaker languages or designs to gain some of the power of stronger ones, if you don't have the option to use something more expressive directly. As such, it merits serious consideration as a tool in the toolbox, but if you find yourself writing generator code too often, you're probably using an underpowered and/or overcluttered language to start with.
The type-safe enum idiom in Java, which several people on this thread have mentioned, is a great example. In a language with native support for enumerated constants, such as C, the generator and idiom would be unnecessary; you'd simply write the code. In turn, in a language with stronger support for disjunctive types and pattern matching, a lot of the hackery you see with enums and switch in C is also unnecessary. But some people have to use Java and would find enums useful, and some people have to use C and would find pattern matching useful, and for these people, code generation can be a way to simulate the real thing acceptably well.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
dynamic code generation and compilation is a good thing when it is used for things dynamic page compilation. But it can also lead to really bad habit that result in un-maintainable code.
is "write programs that write programs". Is it because GNU is not UNIX that people don't know this? ;-)
Sig pending!
1: Thanks to read my post. With bad karma I think is really hard to be read by somehome.
2: Very interesting your post. I dont know that Lisp feature, black magic. Sad that Lisp have these crippling ((( )))) [[[]]]] here and there. Most langs dont have that because is something complex. I dont think is something good.
3: My post whas about to quote strings, because mixing langs (code that generate code) is something hard because you end with very very complex escape sequences. The q() and other nice Perl features able to nicely write a Perl app that write Perl code.
4: I am a old Forth user. I know about langs that build langs. Its funny, but somewhat ofuscated itself. IMHO.
-Woof woof woof!
Object relational bridge packages commonly require code generation or xml files in order to be used. I have been working on one that doesn't use code generation or xml files. My question is, wouldn't developers rather use purely object-based packages, if they could, rather than code generators? I believe purely object-based packages could work for most Object/relational tasks and simple compilers. The code becomes more portable and maintainable and doesn't require the extra training for use of the code generator. What is the concensus on this? Especially in corporate development environments?
The main reason is the insane drive towards features, the disinterest in the quality of software, the heavy bureocracy and the unrealistic schedules.
In other words: nothing else matters except having feature sets x, y and z. Also a, b, c and d. And e. And we want f too. And it's due in two weeks, fully documented, tested (when there's practically no time to test), and bug free of course. And remember, you have to dick around doing other stuff too, effectively cutting the time into 60 % of the original.
Process means shit if it's just to satisfy some obscure checklist with no real purpose.
Why can't people understand the simple truth: the easier you make it for programmers, the more high quality and timely your software will be!
* End of whine *
But I'm not very clear on the advantages of code generation versus descriptive code. One example I like to use is glade versus libglade. The advantage of being able to convert a descriptive file at run-time seems to outweigh the benefits of doing it at compile time. You can change the GUI without having to compile at all. Which allows non-programmers to more easily make changes. (And since it's descriptive, non-programmers are often better at doing the work.)
Besides efficiency, you've given the only reasonable explanation that I've seen for code generation versus dynamically doing the work from the description. I.e. compile-time error checking and info in the object code. But I don't find that to be all that helpful either. If the descriptive file has errors, it's not going to work either way. And you're going to have to do your error checking on the descriptive code the same way, whether you're doing it at compile time or run-time. Compile-time checking of the generated code really doesn't give you much either, except to debug the code generator.
Software sucks. Open Source sucks less.
As engineers we build time-saving applications for others...
Writing code does not make you an engineer. Official certification and certain burdens of legal liability that extend far beyond what most (if any) programmers, and webmonkeys especially, face doth an engineer make. With software written today in such a sorry, buggy state, you can hardly call yourselves engineers anyway.
Code generation can have a legitimate place. I guess there are two logical ways to use it. Given a processor that transforms "metasource" into "source", either you maintain the metasource and never hand-edit the source, or you run the generator just once to create a rough framework, and then discard the metasource and maintain the source. I've done both, saving time and aggravation.
But code generation can be a sign that the wrong language is being used. The author recognizes this, but points out that the individual programmer may not be able to make that choice. True, but the example he gives of generating EJB's seems to show how flawed the Java/EJB idea is in handling database-backed apps.
Perl inherently supports a more generic approach to data that mates more seamlessly with relational databases. For example:
my $user = $dbh->selectrow_hashref(
"select * from user where id=?",
undef,
$userid,
);
# now the user record is a hashref we can manipulate:
$user->{ favorite_color } = 'blue';
# store it
update_row('user', $user);
(I'm not recommending this particular sequence of events, of course - slight concurrency problem.)
update_row() is not standard, but most Perl programmers can see how it's written. It's generic, so it can update any table as long as the primary key is called 'ID'. And it leverages Oracle's caching so the SQL is not recompiled.
Their webpage says you can create simple business rules as well, but I have yet to try this feature.
(Somehow there is an extra space added in the URL between the k and the b - it shouldn't be there.)
k bset
The space is due to Slashdot's lameness filter. It inserts spaces into very long unbroken lines of text so that they will wrap in your browser window and not make the window too wide. For the links, the easy fix is just to create a clickable one like this:
http://www.math.missouri.edu/~stephen/software/#x
Then it doesn't matter if a space is inserted because you can just click it to follow.
--
Promoting critical thinking since 1994.
Then out of protest, don't use "make xconfig" if you rebuild a kernel. That is done using "tkparse":
The use I've seen for code generators is performance. They've all been in C, writing C code. One avoids a swarm of if-statements by generating 64 different routines for 64 different cases, then the caller calls one of them based on the current input. Another writes a perfect hash for a tokenizer based on the current set of tokens. Without generated code, we'd have to use slower code instead.
To be polite: "Bullshit" (The impolite version, well, best it remains unexpressed.)
I have a program that has a bunch of base classes and that I specialize with a set of fairly simple java classes to generate domain specific programs. These java classes look very much alike, but vary in as many as 20 lines per class - this includes the name of the class (both the class name and a string representing it) and some executable code. I also generate a list of the classes as a step in building an interpreter.
So, I wrote a short python program that reads a file describing all the classes to generate and that produces a java class for each such file, a list of the classes, and an executable code segment that loads all the classes and properly initializes them.
This step makes it possible to generate all these classes quickly when I move the program to work in a new domain.
There are other ways to do this, but this seems to me by far the most simple and it has saved me much work over time.
In any case, what is a programming language in general but a code generator for a specific domain (or large connected set of domains)?
Deciding which method is better, like most programming decisions, depends on the situation. In the case of user interfaces, it is advantageous to be able to change the UI after the code has been compiled; therefore, run-time derivation is probably a better choice. In the case of my object-based database example, compile time derivation allows the compiler to do the important and otherwise expensive job of ensuring that the back-end database and the overlying application are in sync, and so it was a better choice.
Later, booch wrote:
You're missing something important here. The point of using an external specification (i.e., a descriptive file) instead of hand-written code is that you can create extremely high-level abstractions that are ideal for the job at hand, and then use those abstractions to "write" your specification.Once you have a suitable specification, then you can begin to weigh the differences between the compile- and run-time methods: By doing the derivation at compile time, you are free to use tools and languages beyond your ultimate target language. For example, even if Java is your target language, you can use Ruby or Haskell to convert your specification into Java. This lets you choose the tools and languages that are best suited for representing powerful abstractions and translating your specifications into code. With run-time derivation, however, you're limited to your target language, even if it's a poor choice for your desired abstractions.
The problem with this thinking is that, if you use run-time derivation, you're more likely to use weaker abstractions in your specifications because you're tempted to constrain your abstractions to those that are easiest to represent in your target language. When you use weaker abstractions, you place a higher burden on the people who must write the specifications, and that burden results in a greater chance for error.Easy, automatic testing for Perl.
Is GSL (aka GSLgen), part of the RealiBase OSS toolset from iMatix.
/>
Yes, I'm biased, I use it extensively. Extensively.
Write your metamodel in XML, build code generation scripts, generate anything from interfaces to database layers to entire applications.
I took some of the examples from CGIA (which is an excellent book, I read it and I like it and I recommend it heartily) and converted them to GSL - simpler, clearer, more obvious.
If you are a professional programmer you need code generation. This is simply a basic technique, like editing text with a visual editor and not edlin. And of all the code generation tools out there, GSL is by far the most flexible and powerful, mainly because it was designed from the ground up, and has been used and evolved over about 10 years specifically as a code generation tool (unlike XSLT which does the job but with more weight and less elegance).
In my journal, I include a GSL script that generates a complete C interface layer for MySQL, turning a simple description like this:
<table name = "history" description = "Message History" >
Holds all messages received and sent. The command and body are parsed
from the smstext.
<field name = "id" domain = "recordid" >Record id</field>
<field name = "groupid" domain = "id" >Parent group</field>
<field name = "userid" domain = "id" >Parent user to/from</field>
<field name = "incoming" domain = "boolean" >Incoming message?</field>
<field name = "appl" domain = "msisdn" >Application MSISDN</field>
<field name = "text" domain = "smstext" >Message text contents</field>
<field domain = "audit"
</table>
Into a complete abstract interface.
Whatever: code generation is a cult technique that deserves a place at the center of every serious developer's toolbox, and this book is possibly the first one that I've seent that may achieve this.
Enjoy.
Ceci n'est pas une signature
If "code generation" isn't a familiar term to you, this enthusiastic overview on devx.com is a concise introduction to what code generation is about, though it makes no pretense of ambivalence about its importance as a programming tool.
Of course it's an "enthusiastic overview" on devx.com.
That article was written by Jack Herrington.
The author of the book being reviewed is Jack Herrington!
Hardly an objective overview!
..your code generator can refactor generated code when it recognizes duplication.
TallGreen CMS hosting
Ah, you're right -- I did miss the point of having more language tools to do the "conversion" at compile-time. I do realize that the choice of methods is situation-dependent. I just think that like most modern programming situations, programming time is more important than program efficiency. And compile-time code generation tends to take more programmer time. Really this is just the same old compiler vs. interpreter argument applied to descriptive code instead of procedural code. Today, it seems that the best answer is usually somewhere in between (Java, Perl, Python). Unfortunately, I still don't see descriptive "code" being given first-class status by most people.
I'm not buying your claim about run-time derivation and abstraction levels, since the target language is likely to be the same either way, even if the translation language is different. In other words, if your target language is Java, you're going to have to implement the resulting executable code in Java either way. I suppose there may be a top-down versus bottom-up distinction in the abstraction development process between the two methods though.
BTW, is there a well-used term to distinguish run-time derivation from code generation?
Software sucks. Open Source sucks less.
HTML was envisioned to be exactly what you describe. A description of how the data should be displayed with the details left up to interpretation by the browser.
That was a huge mistake. It turns out that people want their pages to look EXACTLY like they want, ALWAYS. So every large site today used tables within tables within tables, frames or other add on control mechanisms to make their pages do exactly what HTML was never supposed to do, define exactly, to the last detail, how the data is to be displayed.
I would really hate to see a GUI system that was at liberty to decide the optimal arrangement or display of controls for my app (And of course different on every system). I find systems that do even the tiniest amount of that (Such as the auto-layout features of the Tk in Tcl/Tk) to be extremely dissapointing. The layout always has problems that cannot be gotten rid of with more description.
In the end, it's the details that make you come rocketing back to hand coding to exact specifics.
Contrary to popular belief, coding is not all free blow-jobs and beer. Those things cost MONEY!
Generating SQL on the fly ...
...
Who haven't done this at one point or another ?
You can even make SQL generates SQL !
I think this is one of the most common example of generating code
Intelligence shared is intelligence squared.
Well, to be fair, there's a bit more to that. Hell would likely *enoy* people knowing where he cribbed from.
Java is the blue pill
Choose the red pill
Since I believe in Ousterhout's dichotomy, my favorite code generator is SWIG. It automatically create bindings for calling C and C++ libraries from scripting languages like Python, Lua, Perl, Ruby, PHP, and Tcl.
Second, the code that is responsible for the run-time derivation must be written in the target language, and if the target language makes the derivation difficult (because, e.g., it is too low level), you will do more work than necessary -- or fall back to weaker abstractions in your specifications.
Third, in the run-time case, all of the code that executes the derivations (e.g., an interpreter) must be written by hand and hence be readily understandable by humans. Compile-time code generators need not suffer this higher burden: They can generate incomprehensible output code because no human is meant to maintain it.
To convince yourself of the merits of my counterpoints, consider the case of parsers. The specification is a file defining a grammar. Your job is to create a parser for the specified grammar, and you know that the grammar will change occasionally. Now, you can generate the parsing code at compile time (in effect, writing something similar to yacc or antlr), and this task is straightforward.
Or, you can try the run time approach. Of course, at run time you won't have the facilities of the target language's compiler at your disposal. Therefore, you'll have to code -- by hand -- a general-purpose parsing apparatus that you can reconfigure at run time based on the input grammar.
Spend a few moments thinking about how you might approach this coding problem. It's much harder than the equivalent compile-time problem. Why? Because at run-time you're operating at a much lower level of abstraction. You can no longer leverage the abstractions provided by the compiler. You're stuck at the level of run-time abstractions, which is a subset of what you can do with the compiler. For example, it's easy to create new classes at compile time but very difficult at run time.
Finally, booch asked:
Not that I know of.Easy, automatic testing for Perl.
Another code-generation tool is CodeCharge. It generates database-driven web apps.
I see the review and read some of the links, other links are just to slow ATM....
But doing my own general automation tool set
to be updated this weekend
Surprising. Check out http://codegeneration.net/ , one of many sites on this OMG standard.
http://www.bookpool.com/.x/tc6nwfv10m/ss/1?qs=gene rative&Go.x=0&Go.y=0
It's quite scholarly.
There are examples of code generators that will save you heaps of time. Similar to compilers, they often take the form of translating between languages.
Java to XML
http://www.castor.org/
Java to Relational Database
http://jaxor.sf.net
Here is a link on c2.com with a skeptical debate about code generation:
i gn Smell
http://www.c2.com/cgi/wiki?CodeGenerationIsaDes
Basically, it is saying that code generation is converting info from a compact, well-factored, form to a less compact less well-factored form. In some cases I can see where it may improve run speed, but not code maintanance. One should generally remove duplication of patterns from code and data, not add to it.
Table-ized A.I.
Even better, since I wish to put the power into the hands of the designer, I would like to have dynamically (but again pre-runtime) generated tables and other "static" cheat-sheets without EVER having to compile. Think world/level/rule design tool suite. Basically I want to avoid the runtime script interpretation or even file reads into memory... saving as much time as possible (even if using the "preload" level trick at the beginning) while retaining as late a binding as possible.
Is this an unreasonable request?
What I am talking about is the act of planning ahead but understanding the need to adapt. Take the military for example. History has shown that it was not just a matter of technological empowerment but ability to adapt that defined sucessful armies (and leaders). Take the best weapons in the world but no plan, direction, adaptability, or process of fighting and eventually the peasants will defeat you. The peasants here can be seen as competitors... or just flaws and lack of consumer interest in shelling out dough to you. In feudal Japan the wise Daimyo's understood that there should not be a confusion of statescraft and warcraft. War is expensive and the statesmen that is concerned with fighting must understand that up front. He must also stand back after dictating his desires and let the general do his job... don't micromanage especially in things you are not adept in.
Foolish marketroids and suits are those who set schedules for things they don't understand. Scott Adams has had a field-day with these PHB's. Engineering is the process of creation... without process you will at best have a bridge that is 10 times over budget, 3 times pastdue and only fails 20% of the time. This is not even considering maintenance as if the bridge were built like most software then the architect and all the workers would be put to death without ever having written down the plans and building methods (much less materials). This worked great for giant stone pyramids where maintenance was not an option (you built it then moved on) but a bridge is actively USED and thus will need to be maintained.
Bill Gates made his infamous comparison of the auto industry to computers in terms of innovation and advancement. He was rightly ridiculed for this even if the majority of flamming idiots didn't realize (or care to discover) the real comments and what they really were about. However, if the auto industry really was conducted like the software industry then you can bet that there would be a lot more Pinto-like vehicles around today and a lot fewer drivers.
Oh, one thing more... isn't it funny (not haha... well maybe it is) how the IT industry has such a hypocritical attitude towards innovation and problem solving? Shouldn't a consumer be a BIT concerned when the developers not only do not use their own system in house for their needs but do not apply even the most rudimentary elements of the underlying philosphy behind that implementation in their daily development activities? I recently worked for an organization (but yet that implies being organized which it never was) that built a collaboration suite. Not only was this not used in house to collaborate the development and other business needs throughout, but in fact the whole idea of collaboration was as foreign to them as if you had asked Hitler to head up the Organization for the Advancement of Jews, Polish and Russians.
One thing that is evident from reading reviews from any entertainment media is that most reviewers and even most paid reviewers simply do not understand WHAT MAKES A GOOD REVIEW. Lets say I can't stand first person shooters. They make me dizzy, are too twitch oriented and frankly are embarrasingly stupid as far as "realism" goes. If some game comes out that is first person but in no way is a FPS then a comparison by some "cool dude" idiot reviewer (using phrases like "mad skills" and other monkey speak) to being like Quake in some ways is going to turn me off. However, that is a good thing! If it were just a review of it being so awesome and giving some weak examples of liking the gameplay... that doesn't help me make an informed decision. I want to know the reviewers slant. I want to know WHAT the gameplay is like. What the goal of the game is and what to expect from playing it.
I want to say, "Well if I liked that type of game it is apparent from these reviews that I would most likely enjoy this particular title... however as I don't like that type I will move on." While the content (opinion) of the review is obviously subjective you at least provide what your criteria were.
Now imagine people using this method to judge and review political situations. You JUST MIGHT end up with less monkeys playing "My team is better than your team" crap.
It all about choosing the right tool for the job. Arguing that you should use Java to generate Java is like asking a carpenter to use a board of wood as the only tool to make a table.
Using Ruby (or, Perl, etc.) makes the code generator a lot simpler.
-larsch
Okay, so I read the article, and the concepts sounds interesting. The thing I'm struggling with is that I read about how laborious it is to write the same type of EJB database access code over and over, and the solution is to have the code generated for you. I may be missing something, but I think NeXT solved this problem quite a while ago with Enterprise Objects Framework.
So, yes, you could write code to write code, but I'd personally prefer having less custom code to begin with. At least in the case of database access, EOF does just that, and I'm not clear what advantages code generation hold over the EOF approach in this scenario. Can anyone familiar with both approach shed light on this?
- Scott
Scott Stevenson
Tree House Ideas
``My Partner Is a Total Loser'' and Other Excess Ego Problems
When you are sure of something, you probably are wrong (search for "Unskilled and Unaware of It").
If you enjoyed this book then you should probably have a look at Generative Programming by Eisenecker and Czarnecki as well.
Thanks