* Re: What is wrong with OO ? @ 1996-12-31 0:00 Ell 1996-12-31 0:00 ` Nigel Tzeng 1996-12-31 0:00 ` Ian Joyner 0 siblings, 2 replies; 19+ messages in thread From: Ell @ 1996-12-31 0:00 UTC (permalink / raw) Ian Joyner (i.joyner@acm.org) wrote: : What made me think of this was that Bill Gates stated in his book that : Boeng designed the entire 777 aircraft using one gigantic electronic : document! Physical engineering disciplines have made good use of : computing technology, it's about time software engineers followed : the same path... better and more productive languages and environments, : and stop defending archaic 25 year old languages from another era. I find some 25 year languages like C++ very useful even today. A lot of following a good OO paradigm is in how tools are used and approached. : And this gets back to a point ... made quite a while ago : in this thread, that analysis and design is programming, and that : these should not be done by different groups. Because Boeing had a super diagram doesn't mean it's highest level was predicated on a single, or even specific set of, technology, i.e. on one or more specific languages, or distribution technologies in our case. For more along these lines one should read Constantine's end column in the latest Object magazine. He advocates _delaying_ implementation as much as possible. Elliott ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: What is wrong with OO ? 1996-12-31 0:00 What is wrong with OO ? Ell @ 1996-12-31 0:00 ` Nigel Tzeng 1996-12-31 0:00 ` Ian Joyner 1 sibling, 0 replies; 19+ messages in thread From: Nigel Tzeng @ 1996-12-31 0:00 UTC (permalink / raw) In article <5a9r1k$e74@news4.digex.net>, Ell <ell@access1.digex.net> wrote: [snip] >Because Boeing had a super diagram doesn't mean it's highest level was >predicated on a single, or even specific set of, technology, i.e. on one >or more specific languages, or distribution technologies in our case. Actually I think that one can make the case that the highest level was predicated on a specific set of technology. I'm going to speculate a little here since I know virtually nothing about the actual 777 design but here goes: Say they started with a specific weight goal for the airframe or they couldn't get the performance they wanted out of the aircraft. They thought they could meet this goal through the use of composites. The choice of composites then bounds the high level airframe architecture because of what you can and cannot do with composites (compare to say conventional airframes made of metal). Likewise they may have started with the assumption that they would use a computer controlled fly-by-wire system. This technology also constrains the overall architecture of the aircraft. I don't believe that you can completely separate the architecture from the underlying technology as cleanly as you imply. For a software example if you decide that your key technology is Java then your overall structure better not be based on having access to multiple inheritance. >Elliott Nigel ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: What is wrong with OO ? 1996-12-31 0:00 What is wrong with OO ? Ell 1996-12-31 0:00 ` Nigel Tzeng @ 1996-12-31 0:00 ` Ian Joyner 1996-12-31 0:00 ` Robert C. Martin ` (3 more replies) 1 sibling, 4 replies; 19+ messages in thread From: Ian Joyner @ 1996-12-31 0:00 UTC (permalink / raw) Ell wrote: > > Ian Joyner (i.joyner@acm.org) wrote: > > : What made me think of this was that Bill Gates stated in his book that > : Boeng designed the entire 777 aircraft using one gigantic electronic > : document! Physical engineering disciplines have made good use of > : computing technology, it's about time software engineers followed > : the same path... better and more productive languages and environments, > : and stop defending archaic 25 year old languages from another era. > > I find some 25 year languages like C++ very useful even today. A lot of > following a good OO paradigm is in how tools are used and approached. And people can still drive model T Fords, and fly WWI planes. The most important tool is the compiler. The problem with C and C++ tools is that many of them are to make up for language deficiencies. With a better designed language, which takes into account what modern computers can do, the need for many of these tools simply disappears. Also as I wrote in another thread, the need for most style rules that programmers are encumbered with also disappears. > : And this gets back to a point ... made quite a while ago > : in this thread, that analysis and design is programming, and that > : these should not be done by different groups. > > Because Boeing had a super diagram doesn't mean it's highest level was > predicated on a single, or even specific set of, technology, i.e. on one > or more specific languages, or distribution technologies in our case. Correct. It would be using the compound document paradigm. > For more along these lines one should read Constantine's end column in > the latest Object magazine. He advocates _delaying_ implementation as > much as possible. Exactly, the point! In fact the implementation should be left up to the compiler. But too much with C++ you are forced to think of how to implement things early. It is rather like flying the WWI plane, where you must think to go left, I must adjust the tail to do so. My paper at: http://www.progsoc.uts.edu.au/~geldridg/cpp/cppcv3.html explains how C++ burdens the programmer with 'early implementation' problems, and explains how good OO languages should remove this burden from the programmer. ------------------------------------------------------------------------ Ian Joyner | "for when lenity and cruelty play | All opinions are Internet email: | for a kingdom, the gentler | personal and are i.joyner@acm.org | gamester is the soonest winner" | not Unisys | William Shakespeare Henry V | official comment ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: What is wrong with OO ? 1996-12-31 0:00 ` Ian Joyner @ 1996-12-31 0:00 ` Robert C. Martin 1997-01-01 0:00 ` Tom Bushell ` (2 more replies) 1997-01-06 0:00 ` drush ` (2 subsequent siblings) 3 siblings, 3 replies; 19+ messages in thread From: Robert C. Martin @ 1996-12-31 0:00 UTC (permalink / raw) In article <32C88BE0.7F2B@acm.org>, i.joyner@acm.org wrote: > The most important tool is the compiler. The problem with C and C++ > tools is that many of them are to make up for language deficiencies. > With a better designed language, which takes into account what modern > computers can do, the need for many of these tools simply disappears. > Also as I wrote in another thread, the need for most style rules > that programmers are encumbered with also disappears. This is undoubtedly true. As engineers we need a CAE system that combines the CASE tool, editor, compiler, documentation tool, debugger, test plan generator, simulator, etc into a single seamless facility. We should be able to browse through our design diagrams, focusing into certain points, double clicking on an adornment or icon to bring up a stretch of "source code" which we could edit. Then build and debug in the same environment. Such a system maintain traceability between requirements, use cases, design artifacts and modules. It would maintain lists of programmer and analysts notes that were germane to each other. It would facilitate communcations between engineers working on the project regardless of their location. It would facilitate configuration management and version control. It would facilitat project management. No such tool exists today. I think it will be a long time before such a tool does exist. But I can dream. > Exactly, the point! In fact the implementation should be left up to > the compiler. But too much with C++ you are forced to think of how > to implement things early. It is rather like flying the WWI plane, > where you must think to go left, I must adjust the tail to do so. Of course, after a little practice, the notion of turning right immediately translates into the corresponding pressures and velocity profiles for the stick and the pedals. No thought is required. The appropriate responses become wired into the brain. So it is with any computer language. Once you have mastered it, its use becomes wired in, and the struggle with the layer between design and implementation disappears. -- Robert C. Martin | Design Consulting | Training courses offered: Object Mentor | rmartin@oma.com | Object Oriented Design 14619 N Somerset Cr | Tel: (847) 918-1004 | C++ Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com "One of the great commandments of science is: 'Mistrust arguments from authority.'" -- Carl Sagan ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: What is wrong with OO ? 1996-12-31 0:00 ` Robert C. Martin @ 1997-01-01 0:00 ` Tom Bushell 1997-01-02 0:00 ` Thaddeus L. Olczyk 1997-01-03 0:00 ` Software Development Environments (Was: " Stephen Riehm 2 siblings, 0 replies; 19+ messages in thread From: Tom Bushell @ 1997-01-01 0:00 UTC (permalink / raw) On Tue, 31 Dec 1996 09:28:08 -0600, rmartin@oma.com (Robert C. Martin) wrote: >This is undoubtedly true. As engineers we need a CAE system that combines >the CASE tool, editor, compiler, documentation tool, debugger, test plan >generator, simulator, etc into a single seamless facility. We should be >able to browse through our design diagrams, focusing into certain points, >double clicking on an adornment or icon to bring up a stretch of "source code" >which we could edit. Then build and debug in the same environment. Exactly. And since we're dreaming, let's take it a bit further. You should be able to edit the system at whatever level of abstraction you are viewing it. For example, adding a new argument to a method call would propagate through the whole system automatically, or create a map of errors where more detailed fixing was required. If the system was runnable before the high level change, and nothing was broken by the change, it should still run - immediately! >Of course, after a little practice, the notion of turning right immediately >translates into the corresponding pressures and velocity profiles for the >stick and the pedals. No thought is required. The appropriate responses become >wired into the brain. Seems to me this kind of eye/body type of learning comes much more naturally to humans than textual "book learning" does. Presumably the parts of our brain that deal with written language evolved much more recently, and are less advanced. >So it is with any computer language. Once you have mastered it, its use >becomes wired in, and the struggle with the layer between design and >implementation disappears. Very true. But my experience has been that "wiring in" to certain languages is easier. Smalltalk especially, Forth, and to a certain extent Visual BASIC seem much more natural and comfortable than C/C++, at least for me. I believe this is because they were concieved as _personal_ computer languages, so are highly interactive and open. C/C++ are FORTRAN descendants, which evolved in a mainframe batch environment. Of course, the supporting development environment can have a very large effect too - I'll take a GUI over a command line any day. It seems much easier to get into a state of flow when using these languages - you just code and test, and everything seems to work. I can hardly ever achieve this happy state in C, even though it's one of my most familiar languages - it's just too much like work. Interestingly enough, this can often be done without a lot of up front design, and rarely results in a mess. Many years ago, I read a very short article by a PC game developer. He talked about programming as "jamming", using the term the same way musicians do. I thought it was a very good analogy - implies a very smooth and natural process of creation. IMO, the more "sensual" (ie see/hear/smell/touch/taste) we can make our development tools, the more efficient and creative the development process will become. Visual programming is just a big step in this direction. -Tom ---------------------------------------------------------- Tom Bushell * Custom Software Development Telekinetics * Process Improvement Consulting 2653 Highway 202 * Technical Writing RR#1, Elmsdale, NS B0N 1M0 (902)632-2772 Email: tbushell@fox.nstn.ns.ca ---------------------------------------------------------- ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: What is wrong with OO ? 1996-12-31 0:00 ` Robert C. Martin 1997-01-01 0:00 ` Tom Bushell @ 1997-01-02 0:00 ` Thaddeus L. Olczyk 1997-01-03 0:00 ` Case Tools for OO (was Re: What is wrong with OO ?) Mark Smith 1997-01-03 0:00 ` Software Development Environments (Was: " Stephen Riehm 2 siblings, 1 reply; 19+ messages in thread From: Thaddeus L. Olczyk @ 1997-01-02 0:00 UTC (permalink / raw) rmartin@oma.com (Robert C. Martin) wrote: >In article <32C88BE0.7F2B@acm.org>, i.joyner@acm.org wrote: >This is undoubtedly true. As engineers we need a CAE system that combines >the CASE tool, editor, compiler, documentation tool, debugger, test plan >generator, simulator, etc into a single seamless facility. We should be >able to browse through our design diagrams, focusing into certain points, >double clicking on an adornment or icon to bring up a stretch of "source code" >which we could edit. Then build and debug in the same environment. >Such a system maintain traceability between requirements, use cases, design >artifacts and modules. It would maintain lists of programmer and analysts >notes that were germane to each other. It would facilitate communcations >between engineers working on the project regardless of their location. It would >facilitate configuration management and version control. It would facilitat >project management. >No such tool exists today. I think it will be a long time before such >a tool does exist. But I can dream. What? You mean emacs can't handle all this ? :) --------------------------------------------- Thaddeus L. Olczyk Net boy, net girl Send your impulse 'round the world Put your message in a modem And throw it in the Cyber Sea ^ permalink raw reply [flat|nested] 19+ messages in thread
* Case Tools for OO (was Re: What is wrong with OO ?) 1997-01-02 0:00 ` Thaddeus L. Olczyk @ 1997-01-03 0:00 ` Mark Smith 1997-01-03 0:00 ` APEX - WAS: " Nigel Tzeng 0 siblings, 1 reply; 19+ messages in thread From: Mark Smith @ 1997-01-03 0:00 UTC (permalink / raw) > rmartin@oma.com (Robert C. Martin) wrote: > > >In article <32C88BE0.7F2B@acm.org>, i.joyner@acm.org wrote: > > >This is undoubtedly true. As engineers we need a CAE system that combines > >the CASE tool, editor, compiler, documentation tool, debugger, test plan > >generator, simulator, etc into a single seamless facility. We should be > >able to browse through our design diagrams, focusing into certain points, > >double clicking on an adornment or icon to bring up a stretch of "source code" > >which we could edit. Then build and debug in the same environment. I will probably get flamed for doing this, but we are beginning to use Rational ROSE/C++, and I _like_ it. If you buy Apex, ROSE, and SoDA, you get the case tool, editor, compiler, documentation,debugger all in one. The test plan generator could be wangled from SoDA & use cases. The browse through diagrams, double click to code works. And it's SOOOO quick for doing design scratchings. However, you need to put a fairly disciplined process around it. We've had problems with multiple solutions to the one problem, and how to combine them all into the 'repository' model. It's a process thing, not a tool thing necessarily. It also does change management, which is very impressive. > > >Such a system maintain traceability between requirements, use cases, design > >artifacts and modules. It would maintain lists of programmer and analysts Ah, ok. Traceability is a process thing with 3.0.6. I don't know about 4.0. > >notes that were germane to each other. It would facilitate communcations > >between engineers working on the project regardless of their location. It would > >facilitate configuration management and version control. It would facilitat > >project management. I don't think so email, and ( erk) MS-Project? > > >No such tool exists today. I think it will be a long time before such > >a tool does exist. But I can dream. > Give it a try... Anybody else got comments? ^ permalink raw reply [flat|nested] 19+ messages in thread
* APEX - WAS: Case Tools for OO (was Re: What is wrong with OO ?) 1997-01-03 0:00 ` Case Tools for OO (was Re: What is wrong with OO ?) Mark Smith @ 1997-01-03 0:00 ` Nigel Tzeng 0 siblings, 0 replies; 19+ messages in thread From: Nigel Tzeng @ 1997-01-03 0:00 UTC (permalink / raw) In article <32CC40F6.1FBC@ssd.neca.nec.com.au>, Mark Smith <mark@ssd.neca.nec.com.au> wrote: [snip] >I will probably get flamed for doing this, but we are beginning to use >Rational ROSE/C++, Okay, we aim to serve ;) >and I _like_ it. If you buy Apex, ROSE, and SoDA, you get the case tool, >editor, compiler, documentation,debugger all in one. The test plan >generator could be wangled from SoDA & use cases. The browse through >diagrams, double click to code works. [snip] I like Rose too...but Apex is really horrid. It literally cost us a man year of development time. The underlying paradigm of Apex is flawed (imports) and I discovered today that the source code control software (RCS) can't do tags because of the utterly braindead Apex layer between us and RCS. Multiplatform development is possible but hardly fun and requires massive duplication of source code...and some fancy rsh script development...which if you have to write you could simply be using normal makefiles. The debugger may or may not be thread safe...I don't recall but there is a reason we aren't using it. That's sort of okay since GDB isn't really supporting threads. Sun's IDE does... The editor isn't any better than emacs and not as good as lemacs. Sniff++ has a much better editor and allows browsing of inheritance trees. And Apex is very expensive. SoDA is based on Framemaker (?) and isn't even vaguely intuitive. Powerful perhaps but not easy to use. There are some very amusing artifacts when you generate using SoDA as well. You should also plan on running SoDA overnight when trying to generate a new document. [snip] >However, you need to put a fairly disciplined process around it. We've >had problems with >multiple solutions to the one problem, and how to combine them all into >the 'repository' model. It's a process thing, not a tool thing >necessarily. > >It also does change management, which is very impressive. It does change management poorly...see the lack of TAG above. DONT use Rose with CVS. Rose files cannot be merged and CVS does not lock. You will clobber each other and end up with a mess (been there...done that). Oh, and Rose and Apex does not seem to really mesh together for CMVC. I used Rose to make my properties file (.prp) file writable and Apex simply ignored it so when I did a save it failed...too bad I was exiting at the time. Whee. Don't select Apex as your CM tool...SCCS has more features as a version control tool. There's also no built in problem report tracking or metrics tools. >> >Such a system maintain traceability between requirements, use cases, design >> >artifacts and modules. It would maintain lists of programmer and analysts >Ah, ok. Traceability is a process thing with 3.0.6. I don't know about >4.0. You can do some tracability with Rose and SoDA but it requires a bit of hoop jumping. You basically add text tags to your class descriptions and scenarios to associate them with requirement numbers. Then someone does some magic in SoDA (we had a Rational guy do this for us) to use the tags in our document. This hardly works all that well for multiple projects using the same code base but it kinda sorta does the job if you're only dealing with one set of requirements. >> >No such tool exists today. I think it will be a long time before such >> >a tool does exist. But I can dream. >> >Give it a try... > >Anybody else got comments? Yeah...don't use Apex unless you intent to slip 2-3 months on top of the month you allocated for the change over. For our next project we're going back to Rose/SoDA, CVS/TkCVS, emacs/gmake and adding either Visual C++ or SparcWorks Impact C++ depending on platform. You are much better off spending money on Purify and Quantify than Apex and if you really lack things to spend money on you're better off hiring a temporary CM person than pouring money into Apex. Nigel Tzeng ^ permalink raw reply [flat|nested] 19+ messages in thread
* Software Development Environments (Was: What is wrong with OO ?) 1996-12-31 0:00 ` Robert C. Martin 1997-01-01 0:00 ` Tom Bushell 1997-01-02 0:00 ` Thaddeus L. Olczyk @ 1997-01-03 0:00 ` Stephen Riehm 1997-01-03 0:00 ` Nigel Tzeng ` (3 more replies) 2 siblings, 4 replies; 19+ messages in thread From: Stephen Riehm @ 1997-01-03 0:00 UTC (permalink / raw) To: Robert C. Martin Robert C. Martin <rmartin@oma.com> wrote: > As engineers we need a CAE system that combines the CASE tool, > editor, compiler, documentation tool, debugger, test plan generator, > simulator, etc into a single seamless facility. > Such a system maintain traceability between requirements, use cases, > design artifacts and modules. > It would maintain lists of programmer and analysts notes that were > germane to each other. > It would facilitate communications between engineers working on the > project regardless of their location. > It would facilitate configuration management and version control. > It would facilitate project management. > No such tool exists today. I think it will be a long time before > such a tool does exist. But I can dream. Exactly, but there's more. The above system would also have to cope with various languages. Especially when dealing with GUI's etc, generators are used to generate C++ code, which then needs to be compiled etc. In this case, you don't want to edit the generated code, but the code that was used to generate it. (other examples include lex and yacc files, scripts etc) Such an "all singing and dancing" system can't possibly cater for ALL possibilities. As Robert said, no such tool exists today, but there is no reason why we can't move in that direction. The Unix view of the world is not a bad one, but one which compiler writer's seem to have discarded. Unix works because programs are expected to communicate with each other, via well defined interfaces, the principle being that the sum of many parts is much greater than could ever be achieved by one whole. Robert's dream could be achieved if the parts (compiler, editor, build system, debugger etc) could be made to really fit together. Someone here said that this "isn't rocket science", and he's right. It just takes a little logical thinking. I'll try to identify some of the problems facing developers, regardless of what language they are using. It would be nice to take the suggested improvements below and integrate them into existing systems, but the way I see it at the moment, the lack of communication from the existing compilers provides a constant stumbling block. So, in classic hacker style, I recommend that we "work around" the problem for the time being, while constantly moving in the direction of Robert's dream. (don't worry Robert - I share your dream too!) One very large problem with software development practices is that they aren't very scalable. What works for a 3 woman team almost definitely doesn't work when you have 30 people working on a piece of software. Unfortunately, in University, you learn the language, and then you write a small program or two to prove that you know the basics, but I have never seen a course where students are exposed to practices which apply to software projects with many developers, huge libraries of code, etc. Students enter the world thinking that they can create a directory, start up their favorite editor and write a program, possibly with the afterthought of doing a little design and testing, documentation may also cross their minds if they've been paying attention. Languages aside, there is the problem of how software gets written. My eyes have been opened by the (mis)fortune of working with teams of 50 developers or more, in which case problems such as code stability, deterministic build mechanisms, communication between developers and other factors become very apparent. One step in the right direction is the introduction of Configuration Management Systems (CMS), like CVS, RCS, SCCS, and the various commercial products available today (I know of 3 very good systems, but this is not the place or time to advertise). These systems can be used to force developers to think a little more carefully about what they are doing, and above all, make it possible to trace what has been done, and sometimes even why. Another big help would be, in my view, the teaching of deterministic development practices. Unfortunately I am yet to have found ANY definitive work in this area, although some people are beginning to see the relevance. I can best describe this with examples of what NOT to do, but I am desperately searching for a mechanism to help improve the situation. In a small project, it is perfectly feasible for each developer to have a complete copy of the software in her private domain ($HOME/project), where she can edit the code, and test it without inadvertently effecting anybody else. When she's finished, she publicises her changes, and moves on to the next task. In small circles this works OK, as communication between developers is simple, and normally verbal confirmation is adequate. Try this with more than about 5 developers and you very soon get chaos. The chances that some (or all!) developers are working with inconsistent code (because they are working with copies) increases greatly. A big help in this regard is the advent of CMS, which provides a central software repository, and which allows no more than one developer to change a file at a time (there are workable exceptions to this, but the CMS needs to be quite clever). The developers still need to copy the files in order to build (in most cases), but we're moving in the right direction. The next problem is that of deterministic builds. Make (gmake etc) is a tragic example of a hammer being used to build the Empire State building (from digging the foundations, to installing the lights)! Make works fine as long as all the files are neatly located in one directory, and as long as no errors occur. In the real world of larger software, source code is (sensibly) distributed throughout a tree of directories, thus related software is kept together, while unrelated code is kept well and truly apart. Errors often do occur (especially during development) and parts of the system are often not even complete. This is where large improvements can be made. In the classic "make" environment, all files must be in the current directory. A good enhancement of this is the introduction of gmake's VPATH, where files can be found elsewhere, ie: in a central repository, but in order to work out what is going to be done by make, you need to be nothing short of a genius (OK, the rules are simple enough, but if I had a cent for each time some one asked my "why did make do that?" I would be a very rich man indeed). The next improvement is to centralise the rules used for generating code. This "can be achieved" via included makefiles, but there is still lots of room for improvement. At the moment I know of Christopher Siewald's "Jam" program, which is a huge step in the right direction, and Bob Sidebotham's "Cons", which extends on the ideas behind Jam, and adds some very interesting concepts for determinability. Cons is still a little young, but when it's completed it could be a major win. So, my point is, that the language is a key factor when considering software development, but the development environment is also very important. What's the point of developing a program if you can't reproduce what you've done? In my view, too much attention is being given to the software lanuages and the source code itself, and not enough to the environment in which the software is being written. Class browsers, CASE tools, CM systems and deterministic build environments can all greatly contribute to the reduction of bugs written in the first place. Finding bugs takes up about half of the software development cycle, and you will never get all of the bugs out of a program, but if you don't put them there in the first place, you end up with more stable, and easier to maintain software. (cheap and reliable!) I would like to hear your comments about production environments, should shadow trees be used to provide simple access to a central software repository? what about using hard or soft links? How do you coordinate the work of 50+ developers all working on the same project? If anyone knows of any seminars, documents, research papers, web sites etc etc that address these problems, I would be most grateful to hear from you. Thanks for your time, this article got a little longer than I had expected. Sorry Steve Software Production Environment Analyst pc-plus, Germany // __________________________ ._ o ________________________________ \\\\ Stephen Riehm / //\. Stephen.Riehm@pc-plus.de //// pc-plus ' \>> | Phone: +49 89 62030 148 \\ 81539 Munich, Germany \\ ` Fax: +49 89 62030 113 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Software Development Environments (Was: What is wrong with OO ?) 1997-01-03 0:00 ` Software Development Environments (Was: " Stephen Riehm @ 1997-01-03 0:00 ` Nigel Tzeng 1997-01-04 0:00 ` "Paul E. Bennett" ` (2 subsequent siblings) 3 siblings, 0 replies; 19+ messages in thread From: Nigel Tzeng @ 1997-01-03 0:00 UTC (permalink / raw) In article <32CD3495.14FE@pc-plus.de>, Stephen Riehm <sr@pc-plus.de> wrote: >Robert C. Martin <rmartin@oma.com> wrote: [snip] >the principle being that the sum of many parts is much greater than >could ever be achieved by one whole. Robert's dream could be achieved >if the parts (compiler, editor, build system, debugger etc) could be >made to really fit together. Someone here said that this "isn't rocket >science", and he's right. It just takes a little logical thinking. It is really too bad that CenterLine is out of the C++ IDE market because they had a great little product called CLIPC (Centerline Interprocess Communication) that is effectively a "software bus" where third party products can be "plug and play" with the core product. It it similar to ToolTalk but ran a lot faster with a much simpler interface. I assume that the original plan was to publish the messages that ObjectCenter used and allow any third party to develop an editor, debugger, or whatever and replace ObjectCenter components. It's too bad that ToolTalk never gained mass acceptance since it is free on most platforms (unlike CORBA) and would do the job. Of course this is the same industry that opted for DCE RPC instead of the widely used and freely available ONC RPC. [snip] >Another big help would be, in my view, the teaching of deterministic >development practices. Unfortunately I am yet to have found ANY >definitive work in this area, although some people are beginning to >see the relevance. I can best describe this with examples of what NOT >to do, but I am desperately searching for a mechanism to help improve >the situation. I would think that SEI and PSP would fall into this category. I think that if you are an SEI level 3+ software house then your development process is fairly well documented and hopefully adhered to. I suppose this is about as "deterministic" as one gets. [snip] >In the classic "make" environment, all files must be in the current >directory. A good enhancement of this is the introduction of gmake's >VPATH, where files can be found elsewhere, ie: in a central >repository, but in order to work out what is going to be done by make, >you need to be nothing short of a genius (OK, the rules are simple >enough, but if I had a cent for each time some one asked my "why did >make do that?" I would be a very rich man indeed). The next >improvement is to centralise the rules used for generating code. This >"can be achieved" via included makefiles, but there is still lots of >room for improvement. Um...we have a mulitplatform project based on a central CVS repository using fairly simple makefiles (and gmake). I'm certainly no Make guru but we came up with it in an afternoon. It correctly finds the right include files and libraries from your local development directory or the integration area or the release area using VPATH and -L. It correctly builds to the right object, library and binary areas. On a previous project we did use included makefiles but we didn't get that fancy this time around. [snip] >So, my point is, that the language is a key factor when considering >I would like to hear your comments about production environments, >should shadow trees be used to provide simple access to a central >software repository? what about using hard or soft links? How do you >coordinate the work of 50+ developers all working on the same >project? Be careful with soft links. At one time we had an explosion of links and a corresponding explosion of confusion. I think that we have 2 left... beta which links to the current integration area and release that points to the latest released tree. Then we release the current version we repoint release to the current beta tree and create a new tree. The old release tree gets moved offline. before: beta -> v2.3 release -> v2.2 after: beta -> v2.4 release -> v2.3 >If anyone knows of any seminars, documents, research papers, web sites >etc etc that address these problems, I would be most grateful to hear >from you. There are a couple of web sites that have some "best practices" info and a host of books on the topic. I tend to suggest buying Yourdon's book simply to get his recommended reading list and he is an easy read on the topic. There is also a cm newsgroup that talks about a lot of CM tools (and bugs with CM tools...) [snip] > >Steve Nigel ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Software Development Environments (Was: What is wrong with OO ?) 1997-01-03 0:00 ` Software Development Environments (Was: " Stephen Riehm 1997-01-03 0:00 ` Nigel Tzeng @ 1997-01-04 0:00 ` "Paul E. Bennett" 1997-01-06 0:00 ` Key Abstraction that is coming Mark Smith 1997-01-06 0:00 ` Software Development Environments (Was: What is wrong with OO ?) Tom Bushell 3 siblings, 0 replies; 19+ messages in thread From: "Paul E. Bennett" @ 1997-01-04 0:00 UTC (permalink / raw) In article <32CD3495.14FE@pc-plus.de> sr@pc-plus.de "Stephen Riehm" writes: > I would like to hear your comments about production environments, > should shadow trees be used to provide simple access to a central > software repository? what about using hard or soft links? How do you > coordinate the work of 50+ developers all working on the same > project? > > If anyone knows of any seminars, documents, research papers, web sites > etc etc that address these problems, I would be most grateful to hear > from you. > > Thanks for your time, this article got a little longer than I had > expected. Sorry Steve, The British Coputer Society have a Configuration Management Specialist Group which is doing work in this area. They held a seminar and tools fair at Heathrow recently. I will try and find out the web address for the group and post it later. Newsgroups such as comp.document.management are also dealing with tis issue and may be a little more relevent. It may be that a comp.config.management group would be useful but that may depend on what others think. A good book is "Configuration Management" by Marion Kelly published by McGraw Hill ISBN 0 07 707977 9 (hardback) UKP 29.95. To obtain direct from the author you can call +44 (0)1252-851448. For one excellent product see SQL Software Ltd's product PCMS Elite. Contact John Palmer <j.palmer@sql.com>. -- Paul E. Bennett <peb@transcontech.co.uk> Transport Control Technology Ltd. +44 (0)117-9499861 Going Forth Safely ^ permalink raw reply [flat|nested] 19+ messages in thread
* Key Abstraction that is coming 1997-01-03 0:00 ` Software Development Environments (Was: " Stephen Riehm 1997-01-03 0:00 ` Nigel Tzeng 1997-01-04 0:00 ` "Paul E. Bennett" @ 1997-01-06 0:00 ` Mark Smith 1997-01-06 0:00 ` John Howard 1997-01-07 0:00 ` Robert Dewar 1997-01-06 0:00 ` Software Development Environments (Was: What is wrong with OO ?) Tom Bushell 3 siblings, 2 replies; 19+ messages in thread From: Mark Smith @ 1997-01-06 0:00 UTC (permalink / raw) Here's my key abstraction for the year Stephen Riehm wrote: > > The Unix view of the world is not a bad one, but one which compiler > writer's seem to have discarded. Unix works because programs are > expected to communicate with each other, via well defined interfaces, > the principle being that the sum of many parts is much greater than > could ever be achieved by one whole. Robert's dream could be achieved The key abstraction here is a well defined interface to make apps talk. ie like DDE, COM, CORBA, pipes and stdin/out etc. These are all fine except they assume that everybody understands the format to start with. Also they have varying levels of impact on your system. pipes/stdin/out are extremely low cost to implement. CORBA - expensive. DDE/COM non scalable. Anyone seen KQML? We need to start putting AI type reasoning into our systems so that they can reason about how to communicate with other apps. making everything talk together is the key thing we all need to work toward, and reasoning about interfaces seems to be a good way of looking at the problem. Alternatively components, and Smalltalk PARTs? but that's interaction at a different level. What do you all think? ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Key Abstraction that is coming 1997-01-06 0:00 ` Key Abstraction that is coming Mark Smith @ 1997-01-06 0:00 ` John Howard 1997-01-09 0:00 ` Robert Dewar 1997-01-07 0:00 ` Robert Dewar 1 sibling, 1 reply; 19+ messages in thread From: John Howard @ 1997-01-06 0:00 UTC (permalink / raw) On Mon, 6 Jan 1997, Mark Smith wrote: [deletions] > Stephen Riehm wrote: > > Unix works because programs are expected to communicate with each > > other, via well defined interfaces, the principle being that the sum > > of many parts is much greater than could ever be achieved by one > > whole. > > What do you all think? OpenDoc parts and part handlers. Possibly created as portable Java applications (not applets or necessarily written in Java language). The OpenDoc environment is well suited for developing software. OS/2 v4.0 has OpenDoc, a Java virtual machine, and IBM VoiceType dictation & navigation. These features should be combined to enable quick advancements in software engineering. For instance, consider a GNU-like compiler system represented by OpenDoc components. The compiler system would allow various programming languages to be used for developing software products. Vendors of OpenDoc parts and part handlers could offer enhancements to the compiler system (unlike GNU this policy should not try to impoverish commercial vendors of compiler components). And the integrated development environment is adaptable to satisfy each user. In a few years it may become commonplace to create and maintain software by speaking a readable language such as Ada and interacting with OpenDoc. ------------------------------------------------------------------------ -- John Howard <jhoward@sky.net> -- Team Ada Team OS/2 -- ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Key Abstraction that is coming 1997-01-06 0:00 ` John Howard @ 1997-01-09 0:00 ` Robert Dewar 0 siblings, 0 replies; 19+ messages in thread From: Robert Dewar @ 1997-01-09 0:00 UTC (permalink / raw) John Howard said "OpenDoc parts and part handlers. Possibly created as portable Java applications (not applets or necessarily written in Java language). The OpenDoc environment is well suited for developing software." Ouch, that's confusing terminology (a Java application not written in Java). How about using the terminology "JVM application" to keep things clear? ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Key Abstraction that is coming 1997-01-06 0:00 ` Key Abstraction that is coming Mark Smith 1997-01-06 0:00 ` John Howard @ 1997-01-07 0:00 ` Robert Dewar 1 sibling, 0 replies; 19+ messages in thread From: Robert Dewar @ 1997-01-07 0:00 UTC (permalink / raw) "The key abstraction here is a well defined interface to make apps talk. ie like DDE, COM, CORBA, pipes and stdin/out etc. These are all fine except they assume that everybody understands the format to start with. Also they have varying levels of impact on your system. pipes/stdin/out are extremely low cost to implement. CORBA - expensive. DDE/COM non scalable." And since one of the newsgroups being cross-posted here is comp.lang.ada, we should add (as another low cost option), the RPC interface provided by the distributed systems annex of the Ada RM, which has been successfully used for both homogenous and hetergenous distrbution, on single machines, and on networks. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Software Development Environments (Was: What is wrong with OO ?) 1997-01-03 0:00 ` Software Development Environments (Was: " Stephen Riehm ` (2 preceding siblings ...) 1997-01-06 0:00 ` Key Abstraction that is coming Mark Smith @ 1997-01-06 0:00 ` Tom Bushell 3 siblings, 0 replies; 19+ messages in thread From: Tom Bushell @ 1997-01-06 0:00 UTC (permalink / raw) On Fri, 03 Jan 1997 17:32:21 +0100, Stephen Riehm <sr@pc-plus.de> wrote: >Another big help would be, in my view, the teaching of deterministic >development practices. Unfortunately I am yet to have found ANY >definitive work in this area, although some people are beginning to >see the relevance. I can best describe this with examples of what NOT >to do, but I am desperately searching for a mechanism to help improve >the situation. Have you seen the book "A Discipline for Software Engineering", by Watts Humphrey? This might be exactly what you're looking for. >Class browsers, CASE tools, CM systems and deterministic build >environments can all greatly contribute to the reduction of bugs >written in the first place. Finding bugs takes up about half of the >software development cycle, and you will never get all of the bugs out >of a program, but if you don't put them there in the first place, you >end up with more stable, and easier to maintain software. (cheap and >reliable!) This is Humphrey's approach - the major focus is on defect reduction. -Tom ---------------------------------------------------------- Tom Bushell * Custom Software Development Telekinetics * Process Improvement Consulting 2653 Highway 202 * Technical Writing RR#1, Elmsdale, NS B0N 1M0 (902)632-2772 Email: tbushell@fox.nstn.ns.ca ---------------------------------------------------------- ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Software Development Environments (Was: What is wrong with OO ?) 1996-12-31 0:00 ` Ian Joyner 1996-12-31 0:00 ` Robert C. Martin @ 1997-01-06 0:00 ` drush 1997-01-06 0:00 ` drush 1997-01-07 0:00 ` What is wrong with OO ? drush 3 siblings, 0 replies; 19+ messages in thread From: drush @ 1997-01-06 0:00 UTC (permalink / raw) Robert Martin wrote lots of really good stuff about configuration management which is IMNSHO possibly *the* main problem facing large software projects (well, one of the biggies anyway). He also gave me a great straight line: >The Unix view of the world is not a bad one, but one which compiler >writer's seem to have discarded. Unix works because programs are >expected to communicate with each other, via well defined interfaces, >the principle being that the sum of many parts is much greater than >could ever be achieved by one whole. Robert's dream could be achieved >if the parts (compiler, editor, build system, debugger etc) could be >made to really fit together. Someone here said that this "isn't rocket >science" No, its Emacs. :) Happy hackin' david rush mailto:kumo@intercenter.net I bill $100/min for reading commercial email. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Software Development Environments (Was: What is wrong with OO ?) 1996-12-31 0:00 ` Ian Joyner 1996-12-31 0:00 ` Robert C. Martin 1997-01-06 0:00 ` drush @ 1997-01-06 0:00 ` drush 1997-01-07 0:00 ` What is wrong with OO ? drush 3 siblings, 0 replies; 19+ messages in thread From: drush @ 1997-01-06 0:00 UTC (permalink / raw) OO-ps! I botched the attribution of the quoted text. I was replying Stepehn Riehm's comments on Robert Martin.... YKYBHTL david rush mailto:kumo@intercenter.net ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: What is wrong with OO ? 1996-12-31 0:00 ` Ian Joyner ` (2 preceding siblings ...) 1997-01-06 0:00 ` drush @ 1997-01-07 0:00 ` drush 3 siblings, 0 replies; 19+ messages in thread From: drush @ 1997-01-07 0:00 UTC (permalink / raw) As a first comment this thread is diverging just like most of the problematic software systems where "OO has failed". However, I am going to continue to propagate the insanity. Tom Bushell wrote in <32ca9f2d.174894569@news.nstn.ca>: >Very true. But my experience has been that "wiring in" to certain >languages is easier. [snip] This is so true *and* it explains the popularity of C++ (spit). At first C++ feels like everything you ever wanted fixed in C. So people feel "wired in" very quickly. Of course, the more you follow its paradigms and explore its semantic space, you notice that it is really really really really weird in there. Lots of irregularities, insanities, and inanities. OTOH, I've been told that the committe has been fixing some of the craziness. Gripping hand is that a simple, regular semantic basis in a language will take you much further than a complex one. >It seems much easier to get into a state of flow when using these >languages - you just code and test, and everything seems to work. I >can hardly ever achieve this happy state in C, even though it's one of >my most familiar languages - it's just too much like work. Absolutely. I love Smalltalk. I spend almost no time working around the language/coding test programs to check implementation behavior. I must admit that "straight" C flows for me very well, too. It's the simple semantic structure of the language, again. I just don't get a sense of the tool inflicting itself upon my design with these tools. Software development is hard enough. I have to design and explain my work in such a way to keep managers, customers, and users all happy (and the above are all whiny breeds of people). I sure don't like dealing with a whiny compiler on top of it all. In the usenet flow... david rush mailto:kumo@Intercenter.net I bill $100/min for reading commercial email ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~1997-01-09 0:00 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1996-12-31 0:00 What is wrong with OO ? Ell 1996-12-31 0:00 ` Nigel Tzeng 1996-12-31 0:00 ` Ian Joyner 1996-12-31 0:00 ` Robert C. Martin 1997-01-01 0:00 ` Tom Bushell 1997-01-02 0:00 ` Thaddeus L. Olczyk 1997-01-03 0:00 ` Case Tools for OO (was Re: What is wrong with OO ?) Mark Smith 1997-01-03 0:00 ` APEX - WAS: " Nigel Tzeng 1997-01-03 0:00 ` Software Development Environments (Was: " Stephen Riehm 1997-01-03 0:00 ` Nigel Tzeng 1997-01-04 0:00 ` "Paul E. Bennett" 1997-01-06 0:00 ` Key Abstraction that is coming Mark Smith 1997-01-06 0:00 ` John Howard 1997-01-09 0:00 ` Robert Dewar 1997-01-07 0:00 ` Robert Dewar 1997-01-06 0:00 ` Software Development Environments (Was: What is wrong with OO ?) Tom Bushell 1997-01-06 0:00 ` drush 1997-01-06 0:00 ` drush 1997-01-07 0:00 ` What is wrong with OO ? drush
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox