lesscode.org

27 Responses to “Code is Model”

1. assaf:

   It used to be that you would write the source code as a blueprint for what needs to be manufactured. And someone would use that source code to produce a piece of working code based on that blueprint.

   Then we got rid of punch cards.

   We’ve streamlined the whole production process, we took it down from hours to nanoseconds, with almost perfect reproduction quality. So the question is really, can we look at something other industries still call design, and turn that into production and streamline it.

   comment at 19. October 2005

2. Alex Bunardzic:

   Good rant, and long overdue. I was thinking myself along the similar lines for some time now, and I must say that you hit the nail on the head. We do need to raise the level of abstraction, big time. There’s no two ways about it. However, I think that the AutoCAD-equivalent level would still be aiming too low. In other words, we need much higher abstractions than the software equivalent of the AutoCAD blueprints.

   So what’s up with our software world? Why do we refuse to adapt the successes of other industries, like the engineering design world, and leverage those successes in our software world? What are we afraid of? Why are we stuck using (still) low level programming languages that we toil with at all hours of the day and night to produce inferior software products? If we were designing and constructing commodity cars by hand and even fabricating the tools used to build the cars by hand, we would be laughed out of the industry. How come software development seems to be different? Where is our AutoCAD for software development?

   I think the issue here boils down to the subtle, or not so subtle differences between modeling and designing a software solution. Yes, if modeling is our final goal, I agree, AutoCAD paradigm fits in beautifuly. But the real challenges are, in my view, still in the world of designing a solution. Once the solution is designed properly, then there’s more than one way to skin a cat. And I fully agree with you that having the AutoCAD-equivalency models that would assist in predictability of the final product would be nice. Sort of what the previous commentator wrote about the punch cards. Punch cards were the AutoCAD prototypes in the software world. And they worked beautifully for the intended purposes.

   But if the design is shoddy, no amount of AutoCAD compliance would ever be able to save our asses. And that’s where the real point of contention lies.

   However, I am probably as frustrated as Mini-Microsoft’s quest to make Microsoft a leaner meaner machine in my quest to make software development more of a predictable and repeatable process. It seemingly ain’t going to happen over night and may not happen in my lifetime!

   You are, again, right. It will be proven impossible to make the design process predictable and repeatable. We’re now slowly starting to discover that software design is actually more of an art than science, more of a craft than engineering. Again, no amount of AutoCAD compliance could help us there.

   Unlike real life components (electric circuits, mechanical parts, patterns of fabric and so on), software components are not passive. They are not brain dead. They tend to behave. As such, they may not fit so obediently into the AutoCAD world.

   comment at 19. October 2005

3. Glyph Lefkowitz:

   Software addresses problems an order of magnitude more complex than engineering design; even the simplest program treats the hundreds of thousands of man-years that went into something as complex as a CPU too trivial to even bother having a representation for. I’d say that’s a good indication that we’re doing something right.

   The reason there is no “universal” notation is because different programming languages have similar concepts that mean different things, and for good reason. It is therefore impossible to be equally precise. A resistor is a resistor is a resistor, but a java.lang.Object is not a builtin.object is not a void* - what’s the physical analogue to automatic vs. manual garbage collection?

   If you’re interested in improving the state of software, don’t do it with metaphors, do it with real techniques. Do you have any data on software modeling to suggest it’s a good idea?

   As a member of the younger generation of programmers you mention, I can explain my reaction to software modeling: I don’t believe it’s a first-class software artifact because it’s not part of software. The process goes like this: you write some effectively meaningless diagrams that have only vague meaning to other people and no meaning whatsoever to the machine, then you go and mechanically translate that into code — except when the translation doesn’t work because current modeling techniques encourage sloppy thinking, and the model isn’t complete. After all, if you knew what you were going to say in C++ you would have just written it in C++ in the first place, not drawn some boxes and lines!

   I have seen software models written over and over and over again in my relatively brief tenure in the software industry, and every single time it has been a colossal waste of resources before the project, and if the models weren’t immediately destroyed, maintaining and updating them as the actual process of development pointed out their shortcomings was an even bigger chore.

   comment at 19. October 2005

4. Anonymous:

   I think the problem with CASE, UML, et al. is that they all try to use pictures to represent a software model. Pictures may work well for architecture, engineering, and interior design, but they don’t work well for logic and algorithms.

   Mathematics has been around for millennia. It has probably even been around longer than engineering. Yet, they still use a basically text-based format to describe their theorems and lemmas. Why haven’t they figured out a way to describe them using pictures yet? I’d wager that it’s because pictures to don’t work well for logic and algorithms.

   So yes, we have created a fair number of abstractions; they just aren’t represented by pictures. To see how far we’ve come, consider that it’s much easier to deal with “Sets”, “Lists”, and “Maps”, than to deal with pointers into a memory array. It is far easier to deal with functions (sometimes even as first-class values), than to deal with GOTOs.

   And yes, we aren’t at the end of the road yet. We can still continue to invent even more abstractions, just like mathematicians can.

   comment at 19. October 2005

5. Alex Schroeder:

   Previous posters have essentially tried to demonstrate that software deals with problems that are more complex than engineering problems. My explanation for this is that the physical world has physical constraints. Gravity will always pull you down, and you can rely on that. So there’s an aweful lot of tolerance that makes building roads easier, for example. When implementing “roads” in software, you’re modelling out in the void: You’re building the road, the earth, the air, forces of nature such as gravity. So yes, software allows us to build roads that float, explode, crash, disappear, etc. All approaches to making things more predictable will involve adding constraints: Either you provide higher-level abstractions that are ready-to-use such as roads, planets, and gravity, or you go one step further and implement something akin to a virtual environment that provides higher-level abstractions with basic interactions predefined for you. In a way, Ruby on Rails is one such solution. Domain-specific game engines are another genre of such solutions. With the level editor of game X, you can easily produce more variants of game X, but you can’t build webshop Y. This is ok, you can’t take a road and build a car in real life, either. The problem is that we have this relatively new thing called software, and we could build anything with it. We have a hard time calling a level editor a higher-level programming tool. We don’t like to call the configuration of a wiki the “programming” of a wiki. Once we accept that such simple things are also “programming”, then I think that the riddle is solved: Any piece of software that can be adapted to different situations is in fact a domain-specific abstraction of “processing” that allows us to do “high-level programming”. Usually we just don’t realize that programming and configuring and level-editing are different aspects of the same thing: Process modelling at different levels of abstraction.

   comment at 19. October 2005

6. beza1e1:

   I second that. Abstraction is possible today, but it is not done by UML. RSA is just math and there is no way you can model that with UML. UML is great for OOP architecturing, which is widely used.

   I assume you speak of this kind of “industrial programming”, where dozens of Javaprogrammers are needed. I have no experience with such projects and i can’t think of reasons, why they should be that much harder to build.

   This plug and play pieces are also possible today. I recently made a news feed aggregator. Getting the feed takes two lines.

   import feedparser
   feed = feedparser.parse(url)

   Mark Pilgrims Universal Feedparser is an excellent piece, which is instantly useable. I don’t know, what to expect further?

   comment at 19. October 2005

7. Mitch Barnett:

   Very interesting responses. Thank you!

   Glyph asked:

   “If you’re interested in improving the state of software, don’t do it with metaphors, do it with real techniques. Do you have any data on software modeling to suggest it’s a good idea?”

   Yes Glyph, I do have real data and not just someone else’s examples, which I could just list out here, but actual hands on, personal experience to suggest that modeling software for code generating solutions is not only a good idea, it’s real and it works!

   In fact, a company called Bridgewerx that I co-founded, has invented a product that code generates (actually it is a software factory) application integration solutions from a modeling tool. It’s a real product from a real company based upon 4 years of developing application integration solutions by hand, which then took the patterns from these learning’s and reused them by embodying them into a modeling tool.

   The modeling tool is a domain-specific language for describing application integration scenarios, which then produces an XML specification that our code generator then uses to assemble pre-built components (and some custom built components) and various other software artifacts (schemas, maps, assemblies, etc.) which then gets compiled and packaged as an installer which is then run on the target platform and installs the entire working application integration solution.

   For the skeptics, try it out yourself, on-line at: http://www.bridgewerx.com/loading.htm?testdrive=true

   Or if you don’t want to try it on-line but see actually how it works with a real live demo (no smoke and mirrors here guys), you can view this presentation that shows the actual bits behind the scenes and generating a real working application integration in 1 hour flat at:
   https://www119.livemeeting.com/cc/microsoft/view?id=857PK6&pw=D2HNWT

   I know people have tried modeling tools or visual designers or whatever you want to call them before, with less than desirable results. I was one of those people so frustrated with these tools, that I co-invented my own in the domain I was working in.

   I will introduce you to the philosophy that drove my company to do this. Sure it is from Microsoft, but who cares, it is the approach to modeling, DSL’s and software factories that help raise the level of abstraction for dealing with software complexity to is what’s useful and maybe, just maybe something that other people can learn from.

   Visual Studio 2005 Team System Modeling Strategy and FAQ

   Btw, I didn’t drink the kool-aid, but I do love Guinness :-)

   comment at 19. October 2005

8. MThorn:

   The main reason why I often don’t model out my code before I code it is lack of sufficient tools to do so. I have yet to find software as useful as a plain whiteboard and marker.

   I also don’t think it is important on modeling out how the project works. What is important is modeling out how the project will be used. Without seeing the big picture of how all your modules interact and are used, it’s hard to make the modules work together. Otherwise you end up with modules that are over engineered and can do way more than you really need to. Thus adding to complexity and wasting code time.

   You should model the big picture, what does what, not how. Your code is the blueprint for how.

   comment at 19. October 2005

9. Parand Tony Darugar:

   Oh oh. I like lesscode.org a lot, generally resonates with my own badly flawed brain, but now I hear a yearning for … UML? Code generation?

   Hmm. Generated code is a horrible thing. Because eventually you have to debug that generated code, and sometimes even change it. Don’t generate code, create a higher level language. If you do generate code, it should be so deep under the covers I should have no way of getting to it even if I have a psychotic need to.

   Domain specific language on the other hand is a reasonable thing.

   UML is fine, does create pretty pictures, but doesn’t do much for me. I’ve found the best way to model software is to … write it. I’m not the young guy, and I’m not quite the old school guy either. I’m in no way opposed to anything that makes my coding life easier. The problem is, UML doesn’t actually make it any easier.

   Perhaps the reason the two groups you mention haven’t embraced the tools you mention is because the tools don’t offer enough value yet.

   The AutoCAD analogy doesn’t quite work for me either. In that world, AutoCAD is what you do. When you’re finished with the AutoCAD part of your work, you’re done with that task. You don’t have to pick up a second tool to make things actually work. UML, on the other hand, produces little other than decoration that you now have to go fill out.

   comment at 19. October 2005

10. Dan Hatfield:

    +1 to the mathematics/logic comments - spot on!

    comment at 19. October 2005

11. Dan Hatfield:

    Have you ever worked in an engineering discipline? I went to an engineering school, and both my parents are architects. I can tell you that CAD is a very small part of what it takes to create any building or physical device from scratch. Before ever touching AutoCAD or other modeling tools, the engineer or architect will reach for a sketch book, or try building small-scale physical models or prototypes.

    CAD is often just a tool to formalize and test the designer’s work, and turn it into instructions for manufacturing a final product.

    In software, we don’t have this intermediate stage between creator and manufacturer. Our medium is flexible enough that we can start by sketching or prototyping, and gradually transform our initial sketch into the final product. When I “immediately get out my favorite source code editor”, I am an engineer reaching for a sketch book.

    comment at 19. October 2005

12. Matt Brubeck:

    P.S. That last comment was by me (Matt Brubeck), not Dan Hatfield. For some reason I ended up with Dan’s name in my comment form.

    comment at 19. October 2005

13. Aristotle Pagaltzis:

    Parand Tony Darugar:

    If you do generate code, it should be so deep under the covers I should have no way of getting to it even if I have a psychotic need to.

    This is a reasonable stance, but experience shows that you can never bury the code generation deep enough.

    We already have such code generators: compilers. And for the most part, you never fiddle with the generated code. But practice has shown that code generators alias compilers have bugs too; so in some rare cases, your perfectly correct code breaks because the machine code generator is broken. If, in that case, you really had no way of diving into the generated stuff, you would never be able to find out why what you wrote doesn’t work.

    Joel Spolsky is right: you cannot afford to be ignorant about the lower layers. You can and should use abstractions to make your work faster, absolutely, but you cannot remain ignorant about the nitty gritty that is abstracted away for you.

    Code generation is dangerous. It works for compilers because most of the time, you can spend all of your time above the abstraction layer. (Ie your code is all written in the high-level language.) If the abstraction is only partial, ie you were expected to write half your code in assembler and half in the high-level language, and compilers transmogrified the whole thing into an input for an assembler, there would be innumerably more problems.

    But that is how modelling tools work.

    Until you can create the entire program from start to finish within modelling tools, they will always be counterproductive. But then they’re no longer modelling tools anymore; they’d have become a programming environment of their own.

    In other words, the entire premise of modelling is BAD.

    comment at 19. October 2005

14. Chui Tey:

    I doubt mechanical engineering is in any better state than software engineering. Want to know whether gears will fit well together or wear themelves out? Not much chance, unless you build the real one, or use an existing set. In software, you have static typing.

    Want to know which part of your engine block will suffer the most stress? Finite element modelling comes to the rescue. In software, you have load testing tools.

    What to know much load that part will bear? Only if you deal with known materials. In software, you use COTS components.

    The lowest hanging fruit in software at the moment, is unified access to names and address database. If there is such a thing, most applications would already been halfway there.

    comment at 19. October 2005

15. Aristotle Pagaltzis:

    Another thing that just struck me is this quote from the original article:

    what can we learn from looking at the success of mainstream text-based programming languages to help us in the development of higher abstraction modeling languages that are actually useful. [Bolding mine.]

    Excuse me? These languages are “text-based” in the same way a UML tool is “line-and-arc-based.” The difference is the medium of communication: linguistic vs visual. To describe “linguistic” representation as “text-based” makes me wonder whether the author even understands the medium.

    And I posit that graphical tools will never be very helpful at programming, although they can be very useful as configuration aids. Visual representation is awesome at conveying spatial relationships, but it is more hindrance than help at conveying temporal relationships—a programmer’s livelihood—, and completely incapable of expressing abstract concepts. There’s a reason only three-year-olds read picture books.

    Among humans, the key to more efficient communication is jargon: an enlarged vocabulary that recognises common, complex concepts as distinct entities and names them, allowing those familiar with the jargon to communicate with fewer circumscriptions and thus decreased verbosity. A single sentence can then effortlessly convey as much meaning as would require a couple of pages of paper to express without the jargon.

    Why would the key to increased efficiency in communicating with the machine be any different?

    Indeed, is this not what Rails does? It gives the computer and the programmer a greater shared vocabulary, so the latter can communicate his intent to the former with lesscode. And look, you can build a simple but useful CRUD application within a few hours, where it would take a week with less expressive systems. Less expressive: less shared jargon.

    The key to lesscode is not morecode-but-hey-it’s-generated-automatically, it is morejargon.

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

    comment at 20. October 2005

16. Mitch Barnett:

    Aristotle says he is disappointed. I could not agree more. I thought you guys were smart, but this discussion on modeling and code generation clearly shows me you don’t know what you speak of.

    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. Honestly, I think I am dealing with a bunch of junior programmers infatuated with their text editors. Show me you got brains and actual experience in this domain when you make your comment.

    First let’s see if any of you are actually educated on the subject matter.

    How many of you have read:
    Generative Programming: Methods, Tools, and Applications

    Or Code Generation in Microsoft .NET

    Or Code Generation in Action

    Or Eclipse Modeling Framework

    Or Convergent Architecture: Building Model Driven J2EE Systems with UML

    Or Model Driven Architecture: Applying MDA to Enterprise Computing

    Or Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools

    In fact there are 100’s of books on this subject matter. I just listed the ones I have read so at least I can say I am somewhat educated as to what I am discussing.

    Now to answer a few other questions. Someone said software development is more complex than anything else. So how long would it take for you to build a 747 jet from scratch? Give your head a shake.

    Someone said that mechanical engineering does not fair any better than software engineering. Gentleman, our software delivery success rate is ABYSMAL. Read some factual history on the topic and give your head another shake.

    Then there were several comments about AutoCAD. 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.

    Someone said that once you have done your AutoCAD you move onto something else. Huh? How do you think all of the engine components in your car that you all drive everyday got manufactured? The output of virtually any CAD drawing usually goes into a Computer Numerical Control device (CNC) which mills out the piston you just designed in your modeling (CAD) tool. Get the code generation analogy?

    Finally, millions of software programmers have used a windows form designer tool to create windows forms. The windows forms designer is nothing more than a domain specific language that generates code every time you drag and drop a UI widget onto the form canvas (just like AutoCAD). I have yet to hear anyone (out of those millions of users) having the need to edit or modify the generated code over the last several years these tools have been in use. Why do some of you think that you need to modify the generated code? I smell FUD!

    What does this all mean? It proves the points I was making in my original post – most developers, for what ever reason (give me some real factual and experiential reasons guys, not your uneducated hearsay) would not touch code generation with a ten foot pole. All of your posts have proved me correct.

    I thought lesscode was indeed about writing less code and focusing more on real-world design issues using modeling tools and code generation to automate the rote tasks that we do on a daily basis. Or how about the use of design patterns and frameworks that were discovered and built by someone other than you. Lesscode, eh? It appears not.

    comment at 20. October 2005

17. Zero Zero:

    This is incredible nonsense, Mitch. Go plug your company someplace else. This piece so misses the point of “lesscode” it borders on trolling.

    comment at 20. October 2005

18. Parand Tony Darugar:

    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.

    comment at 20. October 2005

19. Mitch Barnett:

    Parand - I am certainly not taking cracks at anyone, however, I can’t say the same for myself.

    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.

    comment at 20. October 2005

20. Parand Tony Darugar:

    Dear Mitch,

    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.

    comment at 20. October 2005

21. Ryan Tomayko:

    Mitch, I think you’re making a bad assumption about what most programmers that read this site are after. I personally don’t have anything against visual designers, modeling tools, IDEs, etc. when they’re used where they make sense. For instance, window/GUI design tools that let you drop widgets on a canvas, arranging things just so, toggle visible configuration, etc. make perfect sense. You’re designing something visible and a graphical tool can assist in that. Some may generate horrible code but that’s something that can be improved. Modeling tools that let me describe a process so that I might use it as an illustration to better explain something to another person are also valuable. When working with Java, C#, VB.NET, C++, and other languages that lack expressiveness, graphical tools for managing the mess of code you accumulate are also often valuable.

    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.)

    comment at 21. October 2005

22. Ryan Tomayko:

    Aristotle said:

    (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.

    comment at 21. October 2005

23. Bob Dionne:

    This is a wonderful thread, a classic one, that I enjoy reading every time it comes up. It sometimes devovles into tag team wrestling but that only speaks to our passions as programmers. I think Ryan’s comments, about languages that we build IDEs and guis around to make life easier, is very accurate. Part of this stems from the economics of software development. Bill de hOra wrote a wonderful piece on this topic some time ago, Better is Better that elaborates on this.

    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!

    comment at 21. October 2005

24. Bob:

    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.]

    comment at 21. October 2005

25. Harry Fuecks:

    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.

    comment at 23. October 2005

26. TonyB:

    Text has many advantages, as Ryan Tomayko has noted. One good example is that the EDA (Electronic Design Automation) industry has moved from visual modeling (e.g. schematics) to text (Verilog, VHDL).

    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).

    comment at 02. November 2005

27. robert:

    (parachuting in while looking for MDA threads):

    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.

    comment at 01. December 2005

Leave a Reply