Originally posted by Valentin Crettaz in another thread:
Notice that I am not saying the source code is the only document we ever should produce. All I am saying is that writing code is less an activity of construction, but more one of design - and that it is the most authoritative design document we have. Applying a construction metapher to writing code might not be as insightfull as it seems. --Ilja Preuss
Tell me if I'm wrong but what you are saying is that "the code is the design".
To me, the design is something that has the capability of giving an abstract view of the system in a much better way than the code. The design should be something very intuitive to a human being.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Kishore
SCJP, blog
In my last project where we built a custom integration platform, we did something like this -- I started out by sketching the architecture, with the main components enumerated etc., which lasted a couple of days including some superficial product evaluation. Once the development (i.e. testing, coding, refactoring) started, nothing in the original "design" was sacred. And nothing still is. The hard part is that external partners don't like the "nothing is sacred" part too much (but that's why we were prepared with an interface versioning scheme)...Originally posted by Kishore Dandu:
I would prefer design as a separate activity until coding starts. Then once a certain aspect of the overall system is being implemented, design can change or evolve depending on the pitfalls or reality of achieving the system.
Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
As for the "pointless academic debate", I partly agree with you. It is true indeed that this discussion is deeply rooted in personal philosophical beliefs and how everyone sees software development.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Originally posted by Valentin Crettaz:
Well, more of "the code is a design document, and the most authoritative one." --Ilja Preuss
I understand your point but I'm not sure "authoritative" is the most accurate adjective for what you want to express. When I look into the dictionary, I see that authoritative means "of acknowledged accuracy or excellence; highly reliable". I have yet to see code that is highly reliable or close to being excellent![]()
But anyway, I just see that with the increasing complexity of software systems, if we persist on that path we won't be going anywhere because wirting code is far from being a productive activity. There are way too many mechanical things to take into account and to remember when writing code.
Again, going from the fact that a piece of code is one possible realization of a design of a software system, we have currently no reliable way of recognizing where the concerns of the customers are represented in the code. As a consequence, when the requirements change (and they do change), you have a hard time finding all the impacted places in the code that have to be revised.
This boundary between the abstract design and code-level design has been invented (*introduced*) by scientists willing to lower the complexity of constructing software systems. But, if you think about the essence of the software itself, there is actually no such boundary and I think this is one of the key point to look into in order to find a more reliable way of developing software.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Kishore Dandu:
I would prefer design as a separate activity until coding starts.
In a sense, design should be considered as a separate entity that can be changed(or open for a change) depending on progress of the project(that sure includes implementation; i mean coding in your terms).
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Originally posted by Ilja Preuss:
Mhh, I am not sure I follow you.
To me, the design is mainly driven by the needs of the code (actually my need to understand and change the code) and needs to be reflected in the code. So I don't know why you would want to separate it from the code.![]()
Kishore
SCJP, blog
Originally posted by Kishore Dandu:
So, all you guys are suggesting is to start some dummy coding and then think about design. You mean just look at requirements and start writing classes and dummy methods etc.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Stan James:
Should I enter a javadoc that says this method returns a string when left alone javadoc would derive the actual return type from the code?
Originally posted by Warren Dew:
There are things that can be expressed far more succinctly in English than in Java, and those things are candidates for the documentation.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Originally posted by Ilja Preuss:
I agree in general, though I think that many people underestimate the potential expressiveness of code. And code does have one advantage over English - it's unambigiuous.
Originally posted by Valentin Crettaz:
This issue is more related to synchronization between code and the underlying design. Technologies, such as Livesource and the like, should bridge that gap and make sure that everything expressed in a design document is implemented in the code. I agree, though, we are not there yet.
MDA goes into that direction, but as of now, it still looks like a big dream to me.
The programming language is just one means we have invented to communicate our ideas to computers.
I feel that the way we use programming languages these days is very limitative. Maybe I ask too much from them, but you have to agree that as soon as the system grows in size and becomes substantially big (50-100'000 LOC) you cannot have an overall view of the system, and thus, you cannot be sure that your code properly reflects what it has been written for.
All I'm saying is that the code is good but we really lack *something* to assess it against. Nowadays we use test cases, this is good, but still not enough.
I guess that the expressiveness of code is really limited by its grammar and semantics. You can make your code expressive up to a certain point beyond which it will not be possible for the code to be more expressive. I'm asking for much more expressiveness because complexity requires it.
Until technologies for natural language processing are mature enough, using a human language to describe (or implement) software will not be really productive or even doable.
On the other hand, I agree that since software are built by humans (at least in a foreseeable future), we should be able to build (or grow
) software systems using a human-like language. Third generation languages are pretty close to that except that their expressiveness has been reduced from the initial human vocabulary to that of a computer, and this is really limitative.
That's one of the reasons why I *always* first think about how to express something in code, and only if I fail at that make use of other documentation. --Ilja Preuss
This technique is a good one, although, I fear that junior developers would not be able to use it until they become senior.
The fact that you have to ask yourself that question (i.e. do I express that in code or in the documentation?) shows me that something is missing in the software development techniques we use today.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Warren Dew:
what I do put in are mostly summary statements about what the next section of code does.
On the other hand, for nontrivial public functions, I generally write a couple lines before the function declaration describing the purpose of the function. A descriptive function name can be sufficient to understand what's going on when reading code that already uses the function, since there's a lot of context to work with, but I find that when I'm trying to decide whether and how to use the function when writing new code, I often need more information. Sometimes even some detail is justified, such as when null arguments are acceptable and indicate a default condition.
In general, I think well documented interfaces are a great facilitator of code reuse. I use the Java standard libraries a lot more than I ever did the C++ STL, largely because the Java libraries are so well documented.
And I do differ from you in that I tend to write my comments first, before I write my code.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
As Stan already indicated, unit tests are quite good in documenting such things.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
I'm sure many OO folk would object to me saying they're doing FD, but I don't know what else to call it.
Originally posted by Valentin Crettaz:
So you think that the object-oriented languages we use today are less natural to a human than the previous languages (ASM, Lisp, Prolog, ...) that were in use some decades ago?
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Valentin Crettaz:
First, by mapping UML to code, the tools have to reduce the expressiveness of UML. For example, I haven't yet seen a roundtrip tool which was able to handle association classes, let alone custom associatoin stereotypes or the like. --Ilja Preuss
And I don't believe I have ever said that one such tool exists!! BUT, the fact that none is available today does not mean that none will be available tomorrow.
I apologize but I have to believe that tomorrow will be better...
When you say "We *don't want*" you talk for yourself or is it something you gathered from your interactions with other engineers?
Ilja, you cannot seriously pretend that current software engineering technologies will not evolve anymore and that things will always be the same as they are now...
Please don't tell me that you think that object-oriented languages are the final step in the evolution of programming languages.
Moreover, we also have identified many of their shortcomings and that's partly the reason why there is a big rise of aspect-oriented languages which nicely complements object-oriented languages. But, this is just another step in the evolution. The aspect-oriented paradigm will not be the last one either.
What I'm saying since the beginning of the discussion is that tools have to be your partner when you use them for building software systems.
I like testing, too, but I don't think that they are the absolute answer to the problem. Answering that testing will solve all problems (or at least enough so that the system works!!) is a pure illusion. As you know, there is no silver bullet. Test cases sure as hell are not bad, but they will definitely not save the world alone.
Moreover, natural language is much more, well, natural to humans than code.
To me, a test case is nothing else than another piece of code, and thus, I don't see why it would be more easily read.
Basically, I would like to be able to express much more business related things in my code.
I don't think that it ever will be doable, simply because natural language is not unambigiuous. --Ilja Preuss
Techniques actually do exist to make natural language unambiguous.
I don't know about you, but I really enjoy this discussion.
So pardon my insolence but it just appears to me that you always imply that something will never exist simply because it does not exist yet, don't you?
Well, maybe I have badly formulated what I wanted to say. I'm still of the opinion that a language targeted at computers has to be limited in some ways, I'm not saying that the vocabulary or grammar should be infinite. I challenge you to find one single human language that has an infinite vocabulary and/or grammar.
Even if this was not the case, I think any human language can always be sufficiently limited to be useful, comprehensible and unambiguous. Going from that, I don't see why a *pseudo-natural* language would not be appropriate for telling computers what to do and which tasks to carry out.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Warren Dew:
Reading the asserts - presumably from the test case - didn't give me that. The first one is clear, for a single character replacement; I might not have understood it in ten seconds, but it wouldn't take much longer. However, my initial reading of the second one - "assertEquals( "oyx", translate( "one", "xy", "en" ));" - was "replace en with xy", which was incorrect. I didn't notice it was incorrect until I reread the english explanation, though, and I think this illustrates a situation where code doesn't do as good a job of communicating to a human being as it does to a machine.
I suspect Ilya might argue that the function name could be clearer - I myself would use "substitute_characters" or something - but this is a good example of where it's difficult to come up with a function name that's as clear and complete as your two line comment.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Stan James:
I came from COBOL and other procedural languages where good functional decomposition makes things so much clearer. I'm sure many OO folk would object to me saying they're doing FD, but I don't know what else to call it.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Warren Dew:
In some situations, though, the interfaces are broad, and the length of the argument list ends up making the code version much less succinct than the comment version.
Sorry, but I've never yet seen a unit test that I can read and comprehend in less than ten seconds - which I can do with a properly written header comment for a function.
Plus, if I have some nitty edge case that isn't covered by the unit test, it's less convenient to refer to the actual source than if I'm reading a comment two lines away from the actual function.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Ilja Preuss:
Or perhaps the choosen test case is disadvantageous. What about
assertEquals( "1b3", translate( "abc", "ac", "13" ));
Then it's time for some refactoring - for example "introduce parameter object".
If there isn't a unit test for the edge case, what makes you think that it's documented? Or, if it's documented, why did the author choose to not document it in a unit test? (I am not sure what "nitty" means, but it makes me wonder wether it really works when there isn't a test and the source code isn't obviously simple...)
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
True, but isn't the protocol handler (http/https) pretty close to an aspect?Originally posted by Warren Dew:
For example, if you really want security for every http transaction, perhaps it's better to handle the concerns by using https rather than by incorporating something into the same source code base as the business application.
I guess the EJB Container might be a good example of where the AOP solution can be superior to an OOP-only implementation -- the container's aspects can intercept whatever requests the EJBObject receives and takes care of applying any security restrictions and transaction demarcation required.Originally posted by Warren Dew:
Are there good examples of where the aspect oriented approach is superior?
Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Originally posted by Valentin Crettaz:
True, but isn't the protocol handler (http/https) pretty close to an aspect? --Lasse Koskela
Yes, to some extent, we can see a protocol handler as some "aspect" taking care of all networking concerns...
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Been there. Done that. Went back for more. But this time, I took this tiny ad with me:
The Low Tech Laboratory Movie Kickstarter is LIVE NOW!
https://www.kickstarter.com/projects/paulwheaton/low-tech
|