We're a labeled group now!

Did you know the people who think code generation is worth a shot are now officially a labeled group? 'We' are now called the 'code generation crowd' and we seem to be at it again.

This debate between realists (the 'code generator crowd') and the anti's (the 'Elitists') gets funnier with the day :).

15 Comments

  • :)





    It's the religious nature of it all that I find amusing. I have no problem with code generation and the stuff I've read here about generating and regenerating database layers is great. I just don't think that it's going to take over entire application areas like Ian Wij's seems to in his "Writing Code is Stupid" piece. Evolutionary language improvements and tools to handle the mundane areas sure, but gather requirements and build from a requirements model? Nah.





    Writing code is hard. Anything that makes it less hard is good; that includes code generators, testing, decent clients, etc, etc. But none of them are a silver bullet.





    And I'm sorry but that quote of yours over on James' Avery's blog "People who do not understand that code generation is the future will be the first who will not be able to keep up with the rest who do." made me smile and kinda makes me feel that it's you guys that are the elitists - I'm glad it didn't end "will be the first against the wall when the revolution comes" ;)





    And... How does questioning Ian's idea that code gen can replace "the "small army of generally not well skilled developers" that can be found in most organisations and who are "churning out a mass of ill-specified code through a poorly managed process" with some nirvana in which we "capture the requirements of the model" and have a code generator that can "consume the new model and generate appropriate code".


    make me anything but a realist?





    Keep up the good work, and prove us doubters wrong.


  • Here I come with a lot of comments only to find that Len has already written such a good one! Typical.


    :-)





    There's no single way, of course. Code gen is great to improve productivity. But we have to understand what to generate (or what has been generated).

  • This debate is almost an unrealistic as the "paperless society" debate.





    What more can be said?

  • I absolutely agree with Len. People who think that writing code will go away are crazy. I also think that generating entire applications is rediculous and will never happen. What will happen is that things will continue to be abstracted to higher and higher levels, but at the same time requirements will become more and more complex. So there will always be programmers out there writing code in one form or another.

  • Ebenezer Ikonne: what has a paperless office idea to do with generating executable code from models? A paperless office doesn't work because the people IN the office want everything on paper so they print and print and print. If everyone starts using email and not a fax, it might become a reality. But that's another story.





    All: What most people seem to think is that code generators should generate sourcecode. NO. They should generate executable instructions. Do not stick with a 'programmer language', because those things are invented for humans. No true code generator should generate plain sourcecode but should generate MSIL or other directly executable instructions.





    Programming and developing software have NOTHING to do with programming languages and typing texts in a text-editor. Programming languages and typing texts are related to the implementation of the programming RESULTS. If you pick ANOTHER way of implementing the results of programming, you end up with another method of implementing it, but the end result should be the same: runnable functionality.





    Forget 'OO', C#, loops, if then else and other program language related elements. Think in what a program should DO, and image the formulation of those functional elements in readable diagrams which can be drawn easily. Imagine then that those diagrams are fed to a tool which produces an executable. Such a tool can exist (there are already several btw) of hundreds of smaller similar tools. No programming language, no if then else for next switch case while wend, just a model as input and executable code as output.





    Diagram quicksort for yourself, not in terms of C or VB, but in terms of plain logic. It's very easy.

  • "I also think that generating entire applications is rediculous and will never happen. What will happen is that things will continue to be abstracted to higher and higher levels, but at the same time requirements will become more and more complex."


    Two mistakes. One is that you can now think it is rediculous that generating a whole application is silly, but perhaps you should use MS Access for a change and build an application with it. 10 to 1 you don't need a single line of code. In the future this will only expand, because if you focus on FUNCTIONALITY and the end result, an executable program (or better: a set of logical components glued together with logic), you'll see that hammering in the code by hand is nothing more than a (often very bad) way of translating the functionality descriptions into a programming language which is transformed into another programming language and so on till executable instructions are produced. Now, the mistake is that you shouldn't follow the same route when you want to generate executable instructions from functional descriptions. You should follow to route which makes it possible in the most elegant, fast way.





    The other mistake is that although applications tend to become more complex as a whole, this is not a delimiter for using code generators at all. The reason for this is that if application complexity was a delimiter for a computer, it certainly would for a human. People forget that you can build the most complex applications with the most simple logical building blocks. Once logical elements which contain ready to use functionality are available for generators, you have a layer of elements you can address from within your generator. If you can then generate new logic from your generator with those blocks, you get new blocks, new functionality you can re-use.





    Nothing complex at all. Step aside from the programming language paradigm, generators shouldn't think in a language that is ment for humans.

  • In the late 80's, 4GL was so hot. But the problem all the time was that the last 20% of the apps were actually hindered by the 4GL tools so the total result was often not very good at all. (I know, evolution and development...<g>)





    And talking about Access, that gives me several really bad flashbacks from old applications of mine... Brr...





    Even so, I guess you have a good point. Just as everybody else writing comments here.


    :-)





    For now, code generation serves me really well when they spit out code too.


    :-)





    Best Regards,


    Jimmy


    ###

  • Does code generation add another tool to my arsenal? Most certainly. But will it ever replace the bulk of my work? Absolutely not.





    First off, for my job, source code is an absolute must. This is not negotiable. I'm not some entry level grunt, I'm the go-to guy when nobody else around here knows how to accomplish something. Jimmy put it very well. Currently I'm wrestling with SAP.... let's see, can I declare a PARAMETER in my ABAP program and create a simple selection screen? Sure. But when I wish that selection screen to ONLY contain plants which are designated as shipping points for a portion of one division, AND this varies depending on authentication.... 4GL can't cut it.





    Another point here. Ever see the monstrosity of code the ABAP table grid wizard gives you? Yeah right. Since this code generator has no clue what things I need to accomplish with this grid it has to create each and every hook possible - leaving me to wade through the various sections of code to whittle it down to something maintainable.





    Which brings me to my final point. MS Access? ROFL. Forget about the murderous SQL it automatically creates for queries. Forget about the pain in the butt scalability and truely robust security are. Just look at this: what's the outcome of all this code generating?





    Yes, it DOES simplify many things. (I began by saying there is a place for code generating.) But it also has a truely disasterous effect....





    Ever try to maintain a website written by some secretary who took a FrontPage course and so now deems themself a website developer? MS Access is like that. These non-technical people tend to know just enough to make themself dangerous. TO me, that is the REAL cost of code generation.

  • Dave: Ah, so current implementations of 'generators' are an argument why it will never work? MS Access was an example, a metaphore.





    I developed in a 4GL for 2 years, I know what it is like, and I also know that it is stupid to not use a 4GL or a generator when you are developing an application which is database driven (and... whoa, that's about a hell of a lot of applications)





    Your example about frontpage illustrates enough: "These non-technical people tend to know just enough to make themself dangerous. TO me, that is the REAL cost of code generation.". Then you really do not understand what I'm talking about. The attitude illustrated in your remark is what I refered to with 'Elitism'. Programming should be possible for everyone who can think logical and can design software. Today it's only possible for people who know their way in a given IDE/Editor, a language, some API's etc. (in other words: stuff you can look up).





    Why should a 'technical' person be necessary to create a webgui? I don't see that. Today it is necessary because of the crappy state of most tools, however in theory it shouldn't be. That's not because the concept of a generator sucks, but because the people who wrote the current crop of generators did not understand what a generator should do or they made it that way so the market would buy it, otherwise it was too far fetched.

  • That was my point, source code will never go away..just like the fax machine.





    But then again time will tell, like it always does.

  • Sourcecode will go away, but when is a blur of course. I think the first places where it will be used less and less is in the average business apps which, excuse me, are most of the time structured the same. And then eventually the other parts. I don't see humans hammering code in 2100.

  • Frans, to be honest that is that first time in 25 years I've ever been accosed of elitism. :-)





    Seriously, to be totally objective, code generator - and I already said this - have their place. But they most certainly are not the be all or end all. Exactly what high level concept is so dramatically new here? Nothing. Before .NET OO you had 4GL. Before 4GL you had MS Access. Before MS Access you had 3GL. SO on and so forth.





    Truely eliminating the need for people to write programming code will simply never happen. Never.





    So what does this mean? It means that the better a code generator becomes, the more dangerous someone who doesn't understand why a code generator works becomes. Right now I have to deal with people who have no clue why they shouldn't just import their 20 column spreadsheet into MS Access. I mean "it works", roght? Normalization? Fergitaboutit.





    Can you optimize code generators to (a) make my job as the technical lead on a project easier and (b) eliminate costs of having someone fresh out of college who can't do anything but write simple SQL? Most definitely. But there ain't no free lunch. There are costs. And those costs sometimes pile up on guys like me.





    Elitism? No way. Realistic. If code generators - and let's agree right now this concept has existed for decades now - were realistically as great as you claim, then why hasn't one come along now to eliminate my job?





    Do I believe my job in it's current capacity will exist in 2100? Nope. But not because of some code generator, rather, something much more simpler.... evolution.

  • What is used to create them? Normal programming languages. Like normal programming languages are used to create compiler generators which then generate themselves based in the input of an (E)BNF syntaxis specification.





    I don't know when it will be that for every problem domain there will be a generator. If you look at the level of stubborness that is in the developer community at the moment for adapting even dumb generators, I think it will take a long time before the majority of developers is chosing a generator over the option to hammer it all in by hand.

  • Personally, I side with the CG’ers and buy into that vision, though I think it may take many decades--if not centuries--to get “there”. Where is “there”? To me, it is the point where over 90% of all programming is via specification rather than coding.



    To those defending the need for a seasoned developer I say that they are 100% correct, but for the wrong reasons. Creating correct specifications for a code generator to generate any non-trivial application will remain a specialized skill for a long-long-time to come. This kind of executable specification becomes just another higher level of programming.



    The point is NOT that code generators eliminate programming. Rather, the point of MDA, code generation, and executable-model initiatives is that (1) in the short-term they eliminate a lot of tedium (and errors) in writing with our current crop of relatively low-level programming languages (Java, C#, VB, XSLT, PL/SQL -- T-SQL, ABAP, etc.) and (2) in the longer-range vision, allow for developers to remain at a higher level of abstraction--much closer to the actual problem domain--rather than constantly dealing with the particulars of the implementation platform.



    Will we always need lower-level systems programmers? Into the foreseeable future, yes, probably. However, our profession has already evolved from designing circuits and flipping switches (ENIAC), to bit twiddling in machine language (punch-cards anyone?), to assembly languages, to lower level procedural languages such as C and Forth, to OO such as C++, Java, and C# and now the massive frameworks/environments supporting business apps (J2EE App Servers/.Net). It seems only reasonable to observe that the bulk of programming will continue to evolve to higher-and-higher levels of abstraction as the tools and the basic building blocks become more refined.

  • One more point: remember that if you program in anything other than raw machine language, you are already using a code-generator -- the compiler or VM!



    The "code generation crowd" is simply adding another layer of compilation/interpretation on top of the multiple layers which already exist. There is no reason for me to believe that this layering needs to stop at the current state-of-the-art.

Comments have been disabled for this content.