CodeFutures News & Industry Commentary Blog

Tuesday, August 16, 2005

Why CodeFutures probably won't be doing a .NET version of FireStorm/DAO

CodeFutures is asked if we're considing adding .NET support to FireStorm/DAO. The answer is: probably not. In theory, FireStorm/DAO could generate .NET code. Ignoring the fact that CodeFutures does not have the appropriate technical knowledge of .NET (or the market knowledge), the real reason for not adding .NET support is explained by two independent blog entries:

From Malcolm Davis's Blog

http://weblogs.java.net/blog/malcolmdavis/archive/2004/09/conflicting_min.html

NAnt and NUnit are just a few of the .NET open source counterparts to the Java toolset. However, instead of embracing, enhancing, and integrating the tools into their product line, Microsoft has created their own counterpart called Visual Studio Team System. Change gears for a moment, and imagine if you can, any Java IDE saying, "we are not going to support JUnit or Ant, we are going to construct our own tool set". Hard to imagine? You now understand the different mindset between Java and dotNET. One embraces the realities of developers constant strive for productivity, while the other strives to provide their vision of a single integrated solution.

From Aaron Johnson's Blog:

http://cephas.net/blog/2004/09/21/conflicting_mindsets_of_c_vs_java_part_ii.html#000805


.NET developers look to Microsoft to provide the tools they need to do their jobs... and if they look elsewhere or copy something else, Microsoft will eventually come in and make a product of their own that does the job, thereby negating any work the developers do in the meantime. Microsoft drives the bus. Java developers look at the products and specs that Sun puts out and then go and build their own tools or frameworks or applications to do the job.

To paraphrase:

In the Java ecosystem, there's always room for one more product, because no vendor dominates the market. In the Microsoft ecosystem, there's always the risk that you will be wiped out overnight.

PJ Murray
CodeFutures Software


Friday, August 12, 2005

Code Generation

Some interesting code generation resources:

Writing Code is Stupid:

http://ianwij.com/weblog/articles/Writing_Code_Is_Stupid.aspx

The author is ex-Microsoft, which means he worked in a results driven environment, and best part is:

It’s Not Art

Some developers like to promote the notion of the “Art of Programming” with the implication that they are artists. I agree that you can find elegance and art in software programs but it’s an exception. Artists like to follow a nebulous artistic process. I agree ground-breaking software needs this approach.

The majority of enterprise software development is not art. They are typically CRUD information systems with a small amount of domain logic. Many developers want to find creativity and art in their development since there is joy in the craft. This is misguided and enterprise software doesn’t need it nor does a business value it.

Automated Code Generation: The fastest way to write software?

http://www.softwarereality.com/programming/code_generation.jsp#id2

Code Generators help you deliver high quality code

http://techrepublic.com.com/5102-6329-5035011.html

Are you missing out on code generation?

http://www.devx.com/java/editorial/15511

Tools for code generation

http://www.adtmag.com/article.asp?id=7850

A new strategy for code generation

http://portal.acm.org/citation.cfm?id=512954

In Code Generation versus Frameworks, Andy Grove compares the motivations behind developing frameworks and why code generators are often a better choice.

PJ Murray
CodeFutures Software