Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
A better way to find bugs?

By krogoth in Technology
Sun Mar 03, 2002 at 03:16:45 PM EST
Tags: Software (all tags)
Software

If you've reported a bug in any software, you probably know that most developers don't want to hear about about bugs that you can't reproduce. This is understandable - unless they're expecting it to happen, they have no way of finding the problem. But the problem is still there, and it won't be fixed. There may be a way to find these bugs and eliminate them (or not...).


This issue interests me, since I use development versions of open source software and I am also working on a game that should soon be open source. I have had a number of crashes that simply can't be reproduced, and as a developer I would want to eliminate as many bugs as possible.

An article by Joel Spolsky describes one way of finding random crashes:

"When I worked at Juno, we had an even cooler system in place to collect bugs "from the field" automatically. We installed a handler using TOOLHELP.DLL so that every time Juno crashed, it stayed alive just long enough to dump the stack into a log file before going to its grave. The next time the program connected to the Internet to send mail, it uploaded the log file. During betas, we gathered these log files, collated all the crashes, and entered them into the bug tracking database. This found literally hundreds of crashing bugs."

Now this sounds very interesting. If the same could be done in Open Source software, maybe collecting core dumps to send to the developers, it could help eliminate bugs. With this much information, it might be possible to fix more bugs instead of ignoring them as random occurences, and the ones that are that hard to find can also hide other problems. Of course, not everything could be fixed:

"[...] you would get crashes there because the r reference was NULL, even though that's completely impossible, there's no such thing as a NULL reference, C++ guarantees it [...]"

This could allow developers to look into the bug reports that are now useless, and hopefully eliminate more bugs. I will certainly try to do this in some way and see if it helps debugging. Is there anything that can help this for Open Source software?

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Related Links
o An article
o Joel Spolsky
o Also by krogoth


Display: Sort:
A better way to find bugs? | 102 comments (102 topical, editorial, 0 hidden)
OLD idea, -1 (4.41 / 12) (#1)
by greenrd on Sat Mar 02, 2002 at 11:31:24 PM EST

Some mozilla builds have this (they use a proprietary solution though - it's called Talkback).

KDE has this (KDE crash handler).

Not exactly an earth-shattering idea.


"Capitalism is the absurd belief that the worst of men, for the worst of reasons, will somehow work for the benefit of us all." -- John Maynard Keynes

KDE crash handler? (none / 0) (#2)
by krogoth on Sat Mar 02, 2002 at 11:33:00 PM EST

That's a new one... I haven't seen it, and I have had a lot of crashes. I did know about talkback though. I didn't say this is a new idea, but it isn't used very much.
--
"If you've never removed your pants and climbed into a tree to swear drunkenly at stuck-up rich kids, I highly recommend it."
:wq
[ Parent ]
Dr. Konqui (5.00 / 3) (#4)
by regeya on Sun Mar 03, 2002 at 12:11:47 AM EST

Dr. Konqui is the name of the krash . . . erm, crash handler, IIRC. I've not seen it in a while, though, now that many of the bugs have been worked out, so I can only guess that it's helped in some way.

GNOME has a crash handler as well (which I have seen recently on several occasions.)


[ yokelpunk | kuro5hin diary ]
[ Parent ]

KDE's Crash Handler (5.00 / 1) (#24)
by Matrix on Sun Mar 03, 2002 at 11:23:13 AM EST

KDE seems to be, perplexingly, both one of the most stable examples of Open Source software and one of the ones with the best crash handler. The only programs I've ever seen trigger it are Netscape plugins in Konqueror (Flash, especially) and LICQ (third party). The handler isn't always very helpful, but sometimes it can be.

I found it much nicer than the GNOME "bug buddy". Sorry, but I'm not going to install and configure sendmail just to send you a bug report. And when you don't present any information I can use to report the problem manually...

Hopefully, GNOME2.0 will have a better thought-out crash handling system. From what I've heard so far, its about as much of an advance over GNOME1.0 as KDE2 was over KDE. (Though its taken them far longer to reach that point.)


Matrix
"...Pulling together is the aim of despotism and tyranny. Free men pull in all kinds of directions. It's the only way to make progress."
- Lord Vetinari, pg 312 of the Truth, a Discworld novel by Terry Pratchett
[ Parent ]

KDE crash handler useless! (3.25 / 4) (#25)
by Pac on Sun Mar 03, 2002 at 11:29:46 AM EST

<irony>
And then they complain when someone calls it bloatware...

The point is, KDE never ever crashed on me. Never once. It is beyond comprehension why people want a crash handler in an uncrashable piece of software. It is like wasting money putting life boats in unsinkable ships or making car insurance when you drive so perfectly.
</irony>

Evolution doesn't take prisoners


[ Parent ]
KOffice (none / 0) (#77)
by sgp on Sun Mar 03, 2002 at 08:53:17 PM EST

KOffice for one would crash on me every time I tried to run it (Standard RH7.2 install, IIRC). The crash-handler dialog popped up, as useful as a GPF, and the software would die. I asked the developers (though not RedHat) why this happened, got no response, and kept on using StarOffice.

There are 10 types of people in the world:
Those who understand binary, and those who don't.

[ Parent ]

Dr. Konqui (4.50 / 2) (#38)
by PresJPolk on Sun Mar 03, 2002 at 03:51:52 PM EST

In fact, for a while KDE was set up to mail the developers the backtraces directly from the crash dialog. This was removed for three reasons:

1. Users and Packagers compile release builds, leading to backtraces that say nothing but (No debugging symbols found)
2. The same crashes reported 50 times each tends to overwhelm the maintainers, and makes the bug tracker less useful.
3. Users would use old versions, and report fixed bugs in old betas.

In short, it's a nice idea, but doing it without user intervention increases not the quality, but the quantity. Making sure the user has to put in alittle effort ensures that what you do receive will usually be useful.

[ Parent ]
This isn't the real problem (4.58 / 12) (#3)
by sigwinch on Sat Mar 02, 2002 at 11:43:47 PM EST

People have been catching error dumps and emailing them back for ages. The real difficulty is properly incrementing version numbers, and correlating dumps with particular versions of the source. Commercial developers can handle this with their version control system, but open source software is built by random people with random patches on random platforms with random compilers, running on random platforms with random libraries.

Getting error dumps is easy. Getting useful error dumps is harder.

--
I don't want the world, I just want your half.

Good rethoric, but probaly wrong (3.50 / 4) (#27)
by Pac on Sun Mar 03, 2002 at 12:44:16 PM EST

For you to be right, one have to accept that all open source software is build the same way (and, as implied, that all comercial software is build the same way too).

No random person touches the Linux kernel. Linus will not have it that way. Larry Wall would be very displeased if someone tried to build Perl development version usin random libraries. No random patch enters an Apache distribution. Version control is in place in each and every serious open source effort.

On the other hand, your faith in the correctness of comercial software development is probably severely overrated. Even the non-randomness of the end-user platform is not a given by a long shot.

I do not see such a big difference between the two modes of development. There are lots of buggy commercial software out there, there lots of buggy open source software out there. And there lots of buggy development methodologies being used in both sides.

Evolution doesn't take prisoners


[ Parent ]
Forks? (4.66 / 3) (#50)
by greenrd on Sun Mar 03, 2002 at 04:55:48 PM EST

No random person touches the Linux kernel. Linus will not have it that way.

Er, Linus doesn't have much say in the matter. Most serious distros do their own branch and implement their own patches. Then there are all the publically-available patches (low latency patch, preemptable patch, etc.) The Linux kernel is probably one of the most "forked" OSS projects out there (although I haven't heard of a really major split like with egcs and gcc).


"Capitalism is the absurd belief that the worst of men, for the worst of reasons, will somehow work for the benefit of us all." -- John Maynard Keynes
[ Parent ]

Still (2.66 / 3) (#56)
by Pac on Sun Mar 03, 2002 at 05:16:49 PM EST

You have an official kernel. The one all major distributions use. You also have a major development kernel.

Now, if you go and install John KernelHacker's Quantum Kernel patch, it would be really unfair if, when things go wrong and your machine along with most of your house disappears into a tiny black hole, you blame Linus and the main kernel development team for the bug.

The original poster was generalizing on OSS development methodologies. Even accusing OSS of having no source control, when CVS is one of the main pieces of infrastructure OSS has built. I think the generalization is unfair, even because there is certainly more unusable commercial software out there than there is free software.

Evolution doesn't take prisoners


[ Parent ]
Build configuration (4.60 / 5) (#78)
by sigwinch on Sun Mar 03, 2002 at 09:02:44 PM EST

You have an official kernel. The one all major distributions use.
1. No! The major distro kernels are *heavily* forked. Red Hat typically puts in dozens of patches (I've seen ~100 in some kernels). And there are dozens (hundreds?) of other patches that people use for various reasons (PCMCIA, wireless networking, MOSIX process migration, etc.)

2. The Linux kernel is *heavily* configurable. There are zillions of options. Modules can be statically built into the kernel, built as run-time loadable modules, or not built at all. Executables can be optimized for different CPU varieties.

Kernels are the worst example of polymorphic builds, but there are many packages that have a lot of build-time options. Knowing which options were selected at build time is critical to making proper sense of bug dumps. You also need to know which dynamically loaded modules participated in the crash. Solving this problem is a general way would be hard, but the rewards would be handsome.

--
I don't want the world, I just want your half.
[ Parent ]

You've missed the point (none / 0) (#87)
by TheSleeper on Mon Mar 04, 2002 at 01:36:38 PM EST

Now, if you go and install John KernelHacker's Quantum Kernel patch, it would be really unfair if, when things go wrong and your machine along with most of your house disappears into a tiny black hole, you blame Linus and the main kernel development team for the bug.

You're right, it would be unfair. Which is exactly the problem with doing this sort of auto-reporting in a heavily-forked piece of OSS like Linux: If the kernel development team puts in an auto-reporting mechanism, there won't be any way for them to tell from the resulting reports that the kernel that generated them included a few weird patches that could potentially be responsible for a crash. They'll be recieving reports for behavior over which (as you point out) they have no control, but determining that this is the case for any particular report won't be easy.



[ Parent ]
fighting an uphill battle (4.51 / 29) (#5)
by turmeric on Sun Mar 03, 2002 at 12:23:22 AM EST

there was already a system within gnome called 'bug buddy' to do something similar . It would take the stack trace after a crash and supposedly input this into the gnome bug tracking system. Only 2 problems. 1. it required you to install sendmail (or equiv) thus making it completely useless to a large portion of the people who would otherwise send in bugs, and 2. the people running gnome did not like bug-buddy. i asked why, on irc, and they blew me off. The bug buddy author came a little discouraged and went on to work on other more "interesting" stuff in gnome. He rejected my patch several times to make bug-buddy not need sendmail anymore so i gave up on it.

Part of the problem is that most programs depend on 15+ libraries, and most of those libraries will not have debugging symbols, so your stack trace isnt going to be all that great.

But also i cannot help but think there is a resistance among open source project leaders to suddenly have 1500 crash bugs with stacktraces show up in their email box.

In essence there are simply not enough 'core developers' to wade through and fix ten thousand obscure crashes that happen on suzie random snowflakes system, it is simply easier to fix 'major' crashes on the major distributions, and ignore the hordes of people who are not linux-zealot enough to stick with the program even though it bombs out. You can see this time and time again in every open source development conversation from irc to the email lists. Developers will blame the crashes on the supporting libraries, the underlying hardware, etc, and so declare it "not their problem." They dont want to program a workaround into their program when 'the other guy should have done it right in the first place'. Or they will declare the crash a 'rare case' and just decide to ignore it. The bulk of the conversations on open source mailing lists are not about fixing crashes, they are tangents about 'cool features' people want added or pie-in-the-sky prognostications about what is possible by using this or that library or this or that structure or adopting so and so's work.

This brings me to the blatant and obvious poverty of automated anti-bug tools on linux.

First of all, there is no decent easy to use memory leak checker. Sure, memprof is not bad, mpatrol is ok once you get past the mind destorying weirdo setup process, but mostly it will give you the results of libraries that have no debugging symbols, so the bugs are harder to track down. And trying to get versions of shared libraries with debugging symbols included, well, it usually means compiling these libraries yourself. And with programs having 15+ libraries, all of whom might have memory leaks, you can see that things get pretty hairy pretty quickly, especially if you are trying to use the CVS updated version of the first progarm, which depends on CVS versions of 5 different libraries, which might not even compile..... This is not helped by the fact that the unix shared library linking technology has more 'congealed' in an undocumented form over the years than ever been designed (to plagiarize douglas adams talking about vogon ships.)

Then there are the source level debuggers. GDB is lovely, DDD is fine, kdb is jolly, when they arent crashing and bringing your whole system down. And these tools are almost invariably way behind the new technology of the languages and systems they are trying to debug. For example, gdb had no support for threads for a long time. I doubt it has support for C++ STL templates, instead spitting out 5 page long jibberish like it did a year or so ago. If you are working with some library like QT or Gnome, similar problems occur, trying to print out the values of variables such as GtkWidgets or whatever.

Then there are the 'test suite frameworks' or lack thereof. They often are complicated and frustrating to use. Take DejaGNU for example. Sure eventually you could figure out how to use it properly, but the very nature of 'test suite' stuff is that it needs to be as easy as hell, just like internationalization of text strings in GNU (the _() function around every "") otherwise programmers are going to blow you off add their feature and say 'screw you, automated testing is a waste of time'. Dont even get me started on how you are supposed to automatically testsuite a GUI toolkit program like gnome or KDE. windows programmers can buy tools to do automated testing of gui interfaces, but the average linux programmer does not have this advantage.

And god help you if you have an 'average' machine, these debugging tools typically take up huge amounts of speed and memory. and since you are running the 'debug version' of the program it will take up at least twice as much RAM and run much slower than usual.

Is this the fault of these tools' authors? Partly, but partly it is that people who bring out new technology for linux/OSS dont give a rats ass about how anyone will debug it. Debugging, for the author of the new gui toolkit or the new framebuffer library or the new threading system, is an afterthought, "someone elses problem." But partly it is because there is very little demand for such tools by OSS project leaders.

Just run a memory leak checker on your favorite open source program, especially gnome programs, see how many improperly destroyed memory allocations there are, and realize that every one of those could potentially lead to a crash, and then see the general attitude of open source project leaders towards checking for memory leaks, crashes, etc, on the mailing lists. It can take 50 hours to find a single memory leak, and when it is fixed there is absolutely 0 appreciable change in the way the program works. The benefit will only be felt indirectly 'down the road' when the thing doesnt crash, but that is hard to quantify. Joe blow developer is going to want to put that 50 hours into something else with a more immediate reward, like reworking the entire API, moving to a new version, putting his favorite pet feature in, or whatever, and naturally this is what gets talked about most in open source programming discussion groups. The idea that you could analyze how you debug things is a bit of a heresy, automating such a process would be against the whole philosophy of total benevolent dictatorship of the project leader.

Supposedly in OSS 'all bugs are shallow' because you have lots of people looking at them. But the way it actually works out is that this doesnt happen. The extremely high 'barrier of entry' for someone to fix a crash bug (download cvs trees, figure out which cvs branch to use, find out which dependencies there are, install this branch alongside 'stable' versions so box is usable, recompile bunches of things that may or may not work, figure out who to talk to, try to figure out how to communicate with them, work around undocumented features that are necessary to even get it to compile) virtually guarantees that this 'labor pool' of people who can eliminate crash bugs will remain small.

You dont theoretically need a 'long term committed developer' nor to learn every nook and cranny of a project to just fix a crash bug, but it winds up happening that due to the overhead and learning curve to get in on the project, the resistance to outsiders of the ledaers, the anti-democratic philosophy inherent in most OSS projects, etc, anyone trying to fix a crash has to put as much time into overcoming the red tape of the project as they do to finding and fixing the crash. From a potential crash fixers perspective, it just seems not worth it. From the project leaders' perspective, they dont want to focus all their time on a bunch of obscure pathces from strangers, they want to deal with their other project gurus and put interesting things in that will directly benefit themselves and their immediate peers.

In general, open source is very 'manual labor' intensive, people like Linus continually decry trying to take their job away with all this horrible 'automation' that 'cant do as good a job as a human being'. Meanwhile commercial software companies are buying expensive analysis tools like rational roses' memory checkers and profilers... which people at Redhat actually use according to what i heard on IRC.... oh well.

I think you are fighting an uphill battle man, one that I pretty much gave up on a long time ago.

Interesting... (3.00 / 1) (#7)
by krogoth on Sun Mar 03, 2002 at 01:01:06 AM EST

Apart from a little worry that my bug reports will be flamed as duplicates or wontfix, I hadn't seen this (mostly because of limited experience). I understand that the learning curve makes things hard - at one point I wanted to make a simple change in KMail but had to give up because learning it was too complicated (fortunately I got an even better solution with a little customization). For fixing bugs, however, I hope to do a lot better than what you report. I do my best to eliminate bugs as soon as possible, but I know that trying to convince others to do this would be nearly impossible.
--
"If you've never removed your pants and climbed into a tree to swear drunkenly at stuck-up rich kids, I highly recommend it."
:wq
[ Parent ]
So what? (2.66 / 3) (#8)
by scanman on Sun Mar 03, 2002 at 01:16:58 AM EST

Everything you say is true. However, it is also true that commercial software has the same problem, only much, much worse. The boss is not likely to "give a rat's ass" if the program could theoretically crash if fixing it will delay shipping the product. Also, the barrier to entry for debugging commercial software is very close to infinite. Yes, it's not ideal, but it's the best thing so far. What we really need is a re-implementation of malloc() that's a little less braindead.

"[You are] a narrow-minded moron [and] a complete loser." - David Quartz
"scanman: The moron." - ucblockhead
"I prefer the term 'lifeskills impaired'" - Inoshiro

[ Parent ]

OpenSource Development: Elitism in Action (4.42 / 7) (#14)
by snowlion on Sun Mar 03, 2002 at 03:05:09 AM EST

Supposedly in OSS 'all bugs are shallow' because you have lots of people looking at them. But the way it actually works out is that this doesnt happen. The extremely high 'barrier of entry' for someone to fix a crash bug (download cvs trees, figure out which cvs branch to use, find out which dependencies there are, install this branch alongside 'stable' versions so box is usable, recompile bunches of things that may or may not work, figure out who to talk to, try to figure out how to communicate with them, work around undocumented features that are necessary to even get it to compile) virtually guarantees that this 'labor pool' of people who can eliminate crash bugs will remain small.

You dont theoretically need a 'long term committed developer' nor to learn every nook and cranny of a project to just fix a crash bug, but it winds up happening that due to the overhead and learning curve to get in on the project, the resistance to outsiders of the ledaers, the anti-democratic philosophy inherent in most OSS projects, etc, anyone trying to fix a crash has to put as much time into overcoming the red tape of the project as they do to finding and fixing the crash. From a potential crash fixers perspective, it just seems not worth it. From the project leaders' perspective, they dont want to focus all their time on a bunch of obscure pathces from strangers, they want to deal with their other project gurus and put interesting things in that will directly benefit themselves and their immediate peers.

Exactly.

Read my first ever post to Kuro5hin. The relevant portion is the middle part, on the three types of OpenSource developers.

I have found that the reality of OpenSource development is much more like commercial development than the movement lets on. That is, the projects seem to be very much team leader and assistant developers, almost impossible to come in after its already started, very elitist, highly centralized.

This is not true in all cases, but in most cases, it is.

For much bigger projects, such as the GNOME project, it is almost impossible to break in, unless you already know exactly what you are doing, or got in at the ground floor, or are prepared to throw away your life. GNOME itself seems to be developed at RedHat, Ximian, and Sun..!

Bah; It's crazy.

I think that as groupware gets better, and as more people get onto the net, and as OpenSource development grows and matures, things will get better. But it is very rough right now. Way more than OpenSource developers want to let on.


--
Map Your Thoughts
[ Parent ]
the best way.. (2.36 / 11) (#6)
by rebelcool on Sun Mar 03, 2002 at 12:55:24 AM EST

is to eliminate bugs from the beginning. Unfortunately this requires tossing out most current programming paradigms and languages. Get rid of C and C++ (lord I could rant for days about the horrors the widespread use of those two languages have caused).

Personally I'd rather see more flow-chart programming. It's and extremely high level concept, but would significantly reduce bugs by changing programming into what it should be - problem solving. Without worrying about syntax, stupid mistakes and other banal programming tasks, the architects can focus on the main issue - how to solve a particular problem.

Sadly though, this is many years away.

COG. Build your own community. Free, easy, powerful. Demo site

How do you know? (4.00 / 3) (#9)
by snowlion on Sun Mar 03, 2002 at 01:57:33 AM EST

I think that this is an interesting claim, have heard it before, and am interested in knowing if it is true.

Would you please tell me how you know this?


--
Map Your Thoughts
[ Parent ]
Experience perhaps? (5.00 / 3) (#13)
by rebelcool on Sun Mar 03, 2002 at 02:45:49 AM EST

I've done alot of coding. Many languages, many projects. Some big, some small. Worked with other programmers, people who dont know how to program but want software to do stuff for them and the like.

C++ is utter, abject, crap. Try using templates, mix it with header files, and the STL. Then screw up somewhere. The compiler will spew out dozens of utterly useless lines of errors that mean NOTHING.

Nevermind that every compiler is different. Some code that compiles fine on Compiler A, won't work on B.

Try and remember your reasoning for certain pointer arithmetic a few months after working on a module.

Try and take a cursory glance at some code (after all, time is precious) and see if you can determine exactly what its doing, all cases, and whether you're forgetting anything.

COG. Build your own community. Free, easy, powerful. Demo site
[ Parent ]

Debugging STL (4.00 / 1) (#16)
by juahonen on Sun Mar 03, 2002 at 03:26:34 AM EST

The messages are useful. I have found no problems working with them. g++ error reporting is screwed for STL projects. But then again, if you want an easy life, you should program with Basic. Preferrably applications with the purpose of displaying odd colours on the UI.

Try and take a cursory glance at some code (after all, time is precious) and see if you can determine exactly what its doing, all cases, and whether you're forgetting anything.
You can very well write obscure code in C, or in any language for that matter. Writing an obscure flow chart is no problem. And some people without flowchart programming experience might claim they understand an obscure chart just because it is "graphical" and "they should understand it."

[ Parent ]

basic works well for many projects. (none / 0) (#26)
by rebelcool on Sun Mar 03, 2002 at 12:37:47 PM EST

For something small, easy to use and pretty simple, basic works fine. Especially if you need it right away.

One must pick the right tool for the job, as always.

I've never seen a flowchart I couldnt understand. If you're using well-designed ones they should be much more obvious in how something works, in less time, than looking at C code.

If we can improve the way and speed GUI's are built through visual development tools, certainly the same idea can be applied to general programming tasks.

At first I see them as code-generating utilities. Simplify generating java classes (or whatever language you wanted), make it easier to see all cases and so on. Then the tool would generate java code for inclusion into a project.

Later versions would increase the integration. Integrate GUI building tools with the algorithmic ones. Eventually the need to rely on other language compilers would vanish.

COG. Build your own community. Free, easy, powerful. Demo site
[ Parent ]

Flowcharts (none / 0) (#30)
by juahonen on Sun Mar 03, 2002 at 02:51:28 PM EST

I've never seen a flowchart I couldnt understand
... is because you've never seen a flowchart that compiles.

At first I see them as code-generating utilities. Simplify generating java classes
We already have UML design tools which do the job. Also, Microsoft Visual Studio has pre-made modules which the programmers can just insert into their projects, like About boxes etc.

Why do people insist on creating new programming languages. They should invest their energies in improving the current languages.

[ Parent ]

apparently you did not read.. (3.00 / 2) (#32)
by rebelcool on Sun Mar 03, 2002 at 03:05:40 PM EST

as i said, the tools at first will be used to generate code in a current language. It's similar to UML, though a little more advanced.

In any case, many of the current languages are inadequate to the task of building onto them (*cough* adding OOP to C thus creating C++ *cough*)

COG. Build your own community. Free, easy, powerful. Demo site
[ Parent ]

HAH! (none / 0) (#18)
by delmoi on Sun Mar 03, 2002 at 03:52:02 AM EST

Dude, seriously it can be nerve-wracking to see fully expanded template's in the error messages, but C++ is designed to let you code however you want. its only a problem if you mix high and low level stuff. You can do anything in C++ the same way you would do it in java.
--
"'argumentation' is not a word, idiot." -- thelizman
[ Parent ]
Templates Are Hell. But What About Flowcharts? (none / 0) (#68)
by snowlion on Sun Mar 03, 2002 at 06:29:07 PM EST

Templates are utter hell. I made a project that used them extensively, and could just not work with the code- Compiling would cause a seg fault in the compiler, and no useful error messages would come out. (This is the infamous gcc 2.96 I'm using.)

I need to go back to that project and approach it just using C with some abstractions to support the effects of templating.

That said, I wasn't so interested in what you had to say about templates or C++ as I was interested in what you had to say about flowcharts as the way to cut out bugs. I've met a lot of programmers, all skilled, who had their own versions of "how to really do it right", and there is a lot of variation. I don't know if the question can be determined without a lot of clever study; I don't know that we can just figure it out on our own.

That said, we all need something that works for us until the researchers figure this out, which may not be for another 1000 years.


--
Map Your Thoughts
[ Parent ]
Templates (none / 0) (#83)
by katie on Mon Mar 04, 2002 at 04:09:31 AM EST

Actually - this concerns me, G++ never used to segfault when hitting template parse errors - I'm finding it does almost every time.

Unfortunately, the only solution seems to be to not write broken template code.

As for the error messages, personally I started writing Perl scripts that run over the error outputs to turn them into more readable stuff. They're a bit hacky and rough-n-ready, but they did help.

On the bright side, at least with g++ it does tell you everything - I can always write perl to cut down the content of a message to make it more readable. When C++ Builder says "erm. No." it doesn't say anything else to help with debugging the templates... and perl can't really expand on that message much.



[ Parent ]
Re: the best way.. (4.00 / 2) (#10)
by juahonen on Sun Mar 03, 2002 at 02:09:35 AM EST

When you say changing programming into what it should be - problem solving, do you mean programmers do not are are not able to solve problems with current programming tools or methods?

Isn't bug fixing problem solving?

I don't know what kind of programming paradigm this flow-chart programming is. Nevertheless, it doesn't make me think, not even for a second, that it would be less prone to bugs. The bugs would just be different; perhaps more on the program logic than memory management.

[ Parent ]

my thoughts. (3.00 / 2) (#12)
by rebelcool on Sun Mar 03, 2002 at 02:39:57 AM EST

current programmers spend far too much time worrying about implementation details and language silliness than on developing solutions to problems. Such as 'we need to do this with data x' or 'if we have this, then do that' and worry far too much about the language specific details.

I'll use C as my whipping boy. Take a look at a complicated loop structure. Just look at it. Can you tell what its supposed to do at a glance? Of course not. You need to take time to study it. Even then, you may miss subtle cases and other non-often occuring logic errors. Mainly because C is difficult to read.

Because of this propensity for human error, we need to simpify. Diagram. Everyone's seen a flow-chart. They tend to be pretty easy to read, right? Good programmers use them alot to diagram what various parts of software should do.

So cut the code out of the loop. Ditch it. Why worry about pointers, type checking and other crap that is a cludgy way of interfacing what we humans want - to be able to do something - and getting the machine to actually do it.

I don't know if its really 'programming' at that point. I consider it more of a software architecture.

And as for bugs in the program logic - you're right. That's where the flow-chart comes in. They're easy to read. You can look at it for a few seconds and see all the cases, all the checks and see exactly what its supposed to do. This will not eliminate bugs entirely - but it will substantially reduce them.

COG. Build your own community. Free, easy, powerful. Demo site
[ Parent ]

Re: my thoughts. (5.00 / 2) (#15)
by juahonen on Sun Mar 03, 2002 at 03:17:32 AM EST

There's a saying wild on the programming field: "Show me your code and I will be confused. Show me your data structures and the code becomes self-evident." Don't know who said it but you can find it with different wordings on the net.

Why worry about pointers, type checking and other crap
Many a modern programming language (e.g. Java) already feature automatic pointers and type checking. Such features are available for C++ also.

I don't know if its really 'programming' at that point. I consider it more of a software architecture.
If writing HTML is considered programming, then writing flow charts is too :)
But how would you program with flow charts? Loops are easy to draw but how about some problem; loops hardly are problems. Would objects be independent flow charts? How would you reuse a part of a chart (ie. a function in C)? How would it access a database and write SQL queries? How would you catch an exception in a flow chart?

A flow chart of a large programming project (say Mozilla, MS Word, etc.) will be much harder to understand than C code. Think of the 2D space required for such a presentation, it's use will become more and more difficult as the project size grows. Flow charts are good for representing isolated program parts, but they cannot be used as the main programming tool.

[ Parent ]

Object Modeling (2.50 / 2) (#39)
by naomi385 on Sun Mar 03, 2002 at 03:53:57 PM EST

There seems to be a big misconception here about these "flowcharts." I think the concept we should be talking about is Object Modeling, e.g. UML. Basically, with UML, the system designer describes the form of every object in the system, along with the relationships among them, in a two dimensional image. Sophisticated modeling software, such as Rational Rose*, takes what the designer has modelled and converts it into C++ or Java class stubs. The developer then fills in the body of the functions for each class. For things like connecting to a database, you would typically implement a "proxy" or wrapper class that communicates between the database and the rest of the system.

This technique does make the development of a system easier in many ways. As has been said before, the functionality of the entire system is usually described within the space of a few screens of UML, rather than thousands of lines of code. Most bugs become apparent in the designing phases, rather than during coding, or worse yet, after the user gets the program. Furthermore, UML enforces an object-oriented design, the modularity of which makes group development much easier.

* This is the only RAD (rapid application development) tool that I have used personally. There may be better ones available.

Propaganda. Questionable Intelligence. The Visitations.


[ Parent ]
Yes. (none / 0) (#54)
by rebelcool on Sun Mar 03, 2002 at 05:15:22 PM EST

You've got the gist. Now imagine if that tool could generate the logic within the classes as well, without needing you to type in the code to fill it in.

COG. Build your own community. Free, easy, powerful. Demo site
[ Parent ]

Sure man (none / 0) (#60)
by juahonen on Sun Mar 03, 2002 at 05:26:41 PM EST

And you would trust that code!

[ Parent ]
uhm, yes. (none / 0) (#62)
by rebelcool on Sun Mar 03, 2002 at 05:30:25 PM EST

You trust your compiler to create assembler code don't you?

COG. Build your own community. Free, easy, powerful. Demo site
[ Parent ]

Only if... (none / 0) (#65)
by juahonen on Sun Mar 03, 2002 at 05:42:07 PM EST

...I've written the source code for it.

[ Parent ]
flwo chart programming (4.25 / 4) (#20)
by kimpton on Sun Mar 03, 2002 at 04:28:15 AM EST

I'm not sure what your talking about when you say flow chart programming but any non-trivial programming problem will not be made simple by using a different language or programming method.

And as for bugs in the program logic - you're right. That's where the flow-chart comes in. They're easy to read. You can look at it for a few seconds and see all the cases, all the checks and see exactly what its supposed to do. This will not eliminate bugs entirely - but it will substantially reduce them.

If an algorithm is complicated you are going to have a complicated flow chart and you will not necessarily be able to 'look at it for a few seconds and see all the cases'. Whenever I've had to flowchart applications it has always taken many pages to detail the highest level functionality let alone in enough detail for a computer to compile a working programming from. You may not be able to tell 'at a glance' what a C program does, but as long it is competently coded and the viewer is a competent coder a few lines of C will display an algorithm much more clearly and compactly than a flow chart.

I don't know if its really 'programming' at that point. I consider it more of a software architecture.

That's about it. Flow charting is good for (if tedious) working out high level functionality and processes.

[ Parent ]
heh, look deeper. (2.50 / 2) (#29)
by rebelcool on Sun Mar 03, 2002 at 12:46:06 PM EST

Simple, no. Easier and more reliable? Quite possibly.

Granted, I havent fleshed out the details in the best way to design a software architecture tool in this manner (the idea for this only came to me a few days ago).

I think the best way to go about it is to have different zoom levels. For example, take netscape. At your highest display level, you'll have a rather simple concept design. Pair a few things together like "Retrieve information -> format -> display to user". Very simple.

Then suppose you zoom in on the Retrieve Information section. It brings up more detail as to how that is accomplished. And you continue doing this until you get the lower levels of the language "open socket connection to server xyz -> retrieve file abc" and so on.

But those are a matter of tool implementation details and not real important to the higher level concept.

The concept is 'Increased Visualization = Less bugs, More reliability'. As the old saying goes, a picture says a thousand words. Or in this case, a thousand lines of code.

COG. Build your own community. Free, easy, powerful. Demo site
[ Parent ]

Natural language parser? (none / 0) (#31)
by juahonen on Sun Mar 03, 2002 at 03:04:10 PM EST

Are you suggesting the flow chart nodes are processed by a natural language parser? If not, how would the compiler understand the nodes?

And then; are xyz and abc parameters or "hard-coded" values? If they are paramters, how does a flow chart declare them? They need to be declared, in case the language is as you described, otherwise you have a hard time tracking typos in parameter names.

[ Parent ]

it was an example. (2.00 / 1) (#37)
by rebelcool on Sun Mar 03, 2002 at 03:48:12 PM EST

Stop thinking so concretely. It's something many CS majors have a big problem with. They get so bogged down in details they lose the whole picture of what they were trying to do.

As far as i'm concerned, you would only need to type the equivalent of parameters once, the tool would keep track of them from then on and you could choose from a list or something. But really though, thats all implementation specific and not important to the general concept.

You wouldnt need a natural language parser. Each node would have a description as to what it accomplishes. This is what would be displayed at top level. Details are available upon further inspection. The details themselves would include descriptions for the various nodes that make them up.

So suppose I have a node which turns a line of text backwards. I label it "Reverse Text". Going to it is a piece of data that contains the text. Coming from it is the reversed text. If I inspect it closer I will see a loop that goes from the back of the incoming text, to the front (mind you, this would be some sort of graphical representation of a loop..how thats represented is a tool detail). Inside of that loop is another node which is the 'Read a character at point X of Text abc' node. If I want to see exactly how it reads that character, I can zoom into that node. Otherwise all that will be hidden from sight.

So as you can see, one can abstract things into little black boxes, really. But if you want to know how a particular black box works (or need to modify it) it is easy to do so.

At some point you'll reach the bottom translation layer. If you're using this tool to generate say, java code, of course you'll need to know java. However you will be working with small, manageable chunks of java code, rather than pages and pages of big ugly code.

If the tool can compile directly from itself to machine code, then all you really need is libraries for it.

COG. Build your own community. Free, easy, powerful. Demo site
[ Parent ]

ermm.. (5.00 / 3) (#33)
by kimpton on Sun Mar 03, 2002 at 03:06:29 PM EST

So how does that help your original contention that you could see all the details in one glance?

The concept is 'Increased Visualization = Less bugs, More reliability'. As the old saying goes, a picture says a thousand words. Or in this case, a thousand lines of code.

You are teasing there aren't you?

[ Parent ]
simple (3.00 / 3) (#35)
by rebelcool on Sun Mar 03, 2002 at 03:37:11 PM EST

I suggest you dig out a standard programming textbook that includes a flowchart next to all the various algorithms. Perhaps it will become clearer then.

Are you saying that its easier to read, say, assembler, than it is C code? C is horribly ugly, but its a magnitude better than assembler is.

Increased visualization is better understanding. Better understanding is less bugs.

COG. Build your own community. Free, easy, powerful. Demo site
[ Parent ]

That works in some cases ... (5.00 / 1) (#40)
by Kalani on Sun Mar 03, 2002 at 03:54:17 PM EST

... but not in all of them (well of course it works but it's not the best way to visualize all problems).

For instance, consider the case of a programmer writing a basic perspective projection system for a 3D polyhedra rasterizer. First you translate/rotate/scale/shear the active view volume to the z-axis aligned canonical view volume with the center of projection at the origin. Then you transform the canonical perspective projection view volume to the canonical parallel projection view volume and clip against it in homogeneous space (for each line in each polygon not completely outside the volume, solve for t where the parametric equation that defines the line intersects an edge of the view volume and 0<=t<=1 -- replace aforementioned point with the point along the aforementioned line at t). Then convert back to perspective camera space, calculate intersections with the view plane, draw the projected 2D polygons or rational surfaces.<br>
You can draw all of that out in a flow-chart, but a regular geometric diagram with a couple of matrix equations and a couple of parametric equations is much simpler.

-----
"I [think] that ultimately physics will not require a mathematical statement; in the end the machinery will be revealed and the laws will turn out to be simple, like the checker board."
--Richard Feynman
[ Parent ]
certainly (2.00 / 2) (#43)
by rebelcool on Sun Mar 03, 2002 at 04:15:13 PM EST

and surely, those methods are easier and cleaner than writing lines of code.

COG. Build your own community. Free, easy, powerful. Demo site
[ Parent ]

What methods? (5.00 / 1) (#46)
by Kalani on Sun Mar 03, 2002 at 04:36:54 PM EST

Drawing geometric diagrams? Yes it really is a lot simpler than writing the code. However, for the rest of the project (making a script manager for your game, handling the general physics, managing resources, drawing stuff) code is simplest. Also, keep in mind that the geometric diagrams for the projection/clipping system I described were aids to describe the *math* (that is, going directly from qualitative to quantitative analysis). Mathematical notation is the most compact way to describe quantitative relationships and it is generally simple to go from equations to code. When I want to express my procedure to draw a line, a picture of "p(t)=p-f*t + (1 - t)*p-o" is no simpler than the actual code.

-----
"I [think] that ultimately physics will not require a mathematical statement; in the end the machinery will be revealed and the laws will turn out to be simple, like the checker board."
--Richard Feynman
[ Parent ]
think about it this way. (3.00 / 1) (#51)
by rebelcool on Sun Mar 03, 2002 at 04:57:41 PM EST

Before tools like mathcad, mathematica and so on existed, how did engineers get the equations they wanted to solve into the computer? They translated them into something the computer could understand (or into a typed-in language, which was then compiled into the machine). A mistranslation resulted in the equations not solved correctly.

But then the GUI became widespread. Applications like mathematica allowed them to enter the equation they had on paper into the computer - exactly as they had it originally written. And then it solved them. Flawlessly. They could enter the equations into the good familiar format and the math software would translate it for them.

No engineer today would give up their copy of MathCAD for anything because of this.

Why not apply that idea of graphical, sensible representation to programming in general?

Lets stop working around the nature of the machine, and make the machine work in a way that makes sense to us.

COG. Build your own community. Free, easy, powerful. Demo site
[ Parent ]

I use Mathematica every day... (none / 0) (#55)
by Kalani on Sun Mar 03, 2002 at 05:16:30 PM EST

... and I used the "pretty print" toolbar for maybe one hour before I got sick of going back and forth between the mouse and keyboard. Typing "Integrate[x^2,x]" is actually less painful than clicking on the correct integral sign (your choice of indefinite integration is implicit in your method of calling the "Integrate" function but if you want to perform an indefinite integration by choosing the symbol out of a toolbar you have to make sure to pick the right one).

Also, the pretty-print stuff is mostly useless when it comes to anything complicated. When I model complex b-spline surfaces, it's easiest for me to just define the class of surface I want in a function. The graphical equivalent of that would have me create a new toolbar button for the surface function (and maybe write the little macro script behind it). I don't want to have to go back to a huge toolbar (or even an ordered set of toolbars) to find the little button that looks like my kind of b-spline surface, I just want to type "KalanisBSpliney[p1, p2, p3, p4, p5, p6 ...]" and draw the thing!

Look, you talk to me like I haven't considered this before and you've got to win me over. I'm afraid to say that you probably won't win me over. Either throw up your hands and call me closed minded or address the points I've raised please.

-----
"I [think] that ultimately physics will not require a mathematical statement; in the end the machinery will be revealed and the laws will turn out to be simple, like the checker board."
--Richard Feynman
[ Parent ]
what point? (none / 0) (#57)
by rebelcool on Sun Mar 03, 2002 at 05:24:22 PM EST

That writing code for some things is easier? Compared to what? What have you tried, besides code?

I can see your point with mathematica. I don't use it daily. I dont do graphics. So, for general programming tasks, what exactly have you tried to do besides tap in little symbols into your keyboard?

COG. Build your own community. Free, easy, powerful. Demo site
[ Parent ]

I've used LOGO, and ... (5.00 / 2) (#63)
by Kalani on Sun Mar 03, 2002 at 05:32:11 PM EST

... I've tried to decipher what ingedients were in the dishes displayed in pictographic form at this quaint little French restaurant down the road. They refused to speak in English so I had to at least try to avoid something that looked like testicles.

There's a reason that society switched from caveman scrawlings to compact ordered characters (and yes, Egypt switched over when their civilization grew very large ... see the whole story of the Rosetta Stone).

I'll tell you what ... you start developing this system and I'll bet you $5 that as you add functions and basic operators, the size of your pictures will shrink to allow more screen space. What you'll wind up with will be a shorthand system (much like formal mathematics) that is not at all simple to decipher upon first glance.

-----
"I [think] that ultimately physics will not require a mathematical statement; in the end the machinery will be revealed and the laws will turn out to be simple, like the checker board."
--Richard Feynman
[ Parent ]
Your idea can be applied to existing languages (none / 0) (#47)
by krogoth on Sun Mar 03, 2002 at 04:45:03 PM EST

It seems that all you're saying is "if we can just say multiply this vector by this matrix" instead of writing the code, things will be a lot faster. But, doing that would require implementing all that functionality and a tool to create, parse, compile, and run flowcharts. Why don't we just forget about the tool and write C++/Java/VB/Perl/Python/C# libraries?
--
"If you've never removed your pants and climbed into a tree to swear drunkenly at stuck-up rich kids, I highly recommend it."
:wq
[ Parent ]
You've missed the point. (none / 0) (#52)
by rebelcool on Sun Mar 03, 2002 at 05:03:42 PM EST

Because those are TEXT languages. Text languages were a good fancy idea back before the GUI existed (I wonder if the designers of the early text languages got flack for suggesting they ditch the old method of flipping switches...)

The whole point is to get rid of the text language, because they are:

Difficult to read.
Prone to human error as a result.
Non-obvious in how they are accomplishing many tasks.

If you were a building architect, you wouldnt try to design the building using words would you? Of course not. You'd draw it.

Same thing applies to procedures for completing steps to something. Humans are visual beasts. We understand things better with pictures than with words. As the saying goes, a picture is worth a thousand words. Or in this case, a thousand lines of code.

Consider the reason programs like MathCAD and mathematica exist. An engineer can take a equation and simply drag and drop it into the software, which will then translate that graphical representation into what the machine understands and solve it.

Now ask yourself, why is that better than writing the equation using lines of C?

COG. Build your own community. Free, easy, powerful. Demo site
[ Parent ]

Text == Pictures! (none / 0) (#67)
by Kalani on Sun Mar 03, 2002 at 06:29:06 PM EST

Architects, using MathCAD at least, don't just use the GUI. MathCAD uses its own impelementation of Lisp for everything (including responding to UI events). Commands that you issue via the GUI are converted to sequences of Lisp code/data that eventually equates to shapes being drawn on the screen (and user input requested if necessary). Now let's say that you want to move every circle within a certain region to some specific point in such a way that all moved circles share the same center. Or let's say you want to line them all up in a row, ordered by greatest area, and fit their vertical offsets to a hermite curve.

The point is that the GUI (in the case of AutoCAD at least) only allows you to go so far before you eventually have to get into the details of manipulating commands/data yourself. Most architects do this.

Now I admit that drawing a line in AutoCAD is much simpler than issuing the command "(line (x1 y1) (x2 y2))" just like writing "for(i=0;i<n;i++)" is simpler than writing the equivalent assembly code for your processor. The point is that you're limited by the applicability of the constructs that you use. Drawing a line has less applications than "for(i=0;i<n;i++)" which in turn has less applications than "mov, cmp, jl, jge, and inc." In order to devise a "flowchart" system that can do the same things that can be done in C, the logical constructs must be equivalent (that is, your system must have equal applicability). This will mean making distinct graphical units for variables, loops, functions (to define and to invoke), and so on.<br>
I just had an idea though. If you did create such a graphical system and did make it equivalent in C (w.r.t. the basic atomic "language" constructs) your programs would look like lists of symbols starting at the top of a canvas, with lines connecting each one as you go down. This would essentially be equivalent to C and there'd be no benefit other than your own subjective aesthetic assessment. However, I do see one specific application of this design that is useful. It would be very easy to describe parallel threads of execution within a single function (or class, etc). You only draw several lines coming out of the function definition, one for each thread. Synchronization issues would be easy to visualize too. Drawing access requests from one thread to another would implicitly create/lock a critical section for that resource.

What do you think?

-----
"I [think] that ultimately physics will not require a mathematical statement; in the end the machinery will be revealed and the laws will turn out to be simple, like the checker board."
--Richard Feynman
[ Parent ]
Arguments (none / 0) (#58)
by juahonen on Sun Mar 03, 2002 at 05:24:31 PM EST

You seem to have a lot of arguments. Do you happen to have any data to back up your arguments?

[ Parent ]
Nope, i sure don't. (none / 0) (#59)
by rebelcool on Sun Mar 03, 2002 at 05:26:29 PM EST

Mostly because it occurred to me about 3 days ago :) This discussion has made me think about a few more details though. And for the most part, I've yet to see a decent argument as to why it WOULDNT work better.

There are plenty of examples of graphical tools increasing software design productivity and reliability.

COG. Build your own community. Free, easy, powerful. Demo site
[ Parent ]

Can you show us your references? (none / 0) (#64)
by juahonen on Sun Mar 03, 2002 at 05:33:05 PM EST

The only help I know graphical design tools give you is in the UI design.

[ Parent ]
As others have mentioned.. (none / 0) (#66)
by rebelcool on Sun Mar 03, 2002 at 05:44:51 PM EST

there is Rational Rose for actual software. It is not by any means the only one (the names of the others escapes me)

Try looking up info on UML, which is a similar concept.

COG. Build your own community. Free, easy, powerful. Demo site
[ Parent ]

Ah, ha! (4.00 / 2) (#48)
by cooldev on Sun Mar 03, 2002 at 04:46:44 PM EST

To commingle your comments from two posts...

1) Granted, I havent fleshed out the details in the best way to design a software architecture tool in this manner (the idea for this only came to me a few days ago).

2) Stop thinking so concretely. It's something many CS majors have a big problem with. They get so bogged down in details they lose the whole picture of what they were trying to do.

Ah, ha! Now it becomes more clear. What I infer from this is that you're a self-taught programmer. One of the other things CS majors are supposed to get out of their education is exposure to a bunch of ideas, so they don't have to reinvent old, hashed-out ideas. One of these is graphical/flowchart programming, which has been "the next big thing" and "the solution to all of our problems" for over 40 years now.

Some progress has been made on such a tool for a few limited cases, but this tool is not applicable for most types of applications. I also hear it sucks to use. :)

Don't take this to mean that CS majors learn that idea XYZ is bad, so they shouldn't work on it. Out of the box thinking is always good, but you should have an idea where other people have tried to go with it, otherwise you don't build on their knowledge and you never get past the basics. I liken it to a layperson talking to a math/cryptography expert, thinking that he has found a unique fast new way to factor numbers: There's a 99.99999% chance that the layperson's idea has been known for ages, but there's still small chance he's thought of something new. Unfortunately the odds are so small that 99.99999 of the real advances are going to be made by people with knowledge in the field.

In other words, don't let it discourage you that thousands of people, from laypersons to programmers to PhDs have tried to do what you describe for over 40 years without success, there's a 0.00001% chance you might be the one who can pull it off. As I said before, the devil is in the details.



[ Parent ]
heh (3.00 / 1) (#53)
by rebelcool on Sun Mar 03, 2002 at 05:09:00 PM EST

You're somewhat correct. Before college, I taught myself how to program. College has honed the skills I learned before into cleaner, better design. And all the good theory fleshed out too.

I havent decided if i'll continue on to grad school yet :)

Anyways, I knew there were previous tools that were similar (though I couldnt think of the name). I never considered a new idea.

Though let me point you to one area where this line of thinking has been EXTREMELY successful: Math software like MathCAD.

COG. Build your own community. Free, easy, powerful. Demo site
[ Parent ]

There is no silver bullet (4.00 / 4) (#21)
by cooldev on Sun Mar 03, 2002 at 04:42:01 AM EST

The harest part about software engineering is debugging the specification. I recommend you read The Mythical Man Month.

Can our tools be improved? Absolutely. But there's a problem with making a blanket assumption that everybody is doing it wrong and ditching proven tools like C and C++ for some vague notion like "flow-charting" is a good idea, or even possible with today's technology; the devil is in the details.

Functional Programming, Aspect Oriented Programming, Intententional Programming, and other ideas will continue to enter the mainstream and make incremental improvements, like OO did, but they won't be a panacea.



[ Parent ]
You can't see silver if you're blind (4.66 / 6) (#22)
by localroger on Sun Mar 03, 2002 at 09:00:54 AM EST

The harest part about software engineering is debugging the specification.

This is why really talented programmers who have a rep for doing a months' worth of work over a weekend don't like to work in teams. They don't use specifications, except in the vaguest sense. Specifications, in case you never noticed, are one of the aspects of modern programming technique that don't work.

There are silver bullets aplenty for those who are willing to use them -- FORTH, Java, and Visual Basic all spring right to mind. All of those are often criticized by people who are trapped in the top-down heirarchal wonk mode which is de rigueur nowadays, but they all have the strengths the original author is calling for in varying measure. Most of all all of them are robust; they are not prone to create buffer overflows, "null" pointers, and similar crap.

Extreme Programming and similar paradigms attempt to leverage what the individual programmer can do in a group environment, with varying (mostly poor) degrees of success. "Refactoring" is the buzzword nowadays, but what happens in an XP group bears little resemblance to what goes on in the head of an individual programmer, who if he is comfortable with his tools is refactoring constantly as he balances end user needs with performance and API requirements. His final effort may lack features in the original spec or include features not called for, but it will be efficient, useable, and robust.

The tools do make a difference. Tell four sculptors they need to make a Greek column and give them all similar pieces of wood to start with. Give one a hacksaw, one a chain saw, one a chisel, and one a lathe, and ask them all if there is a "silver bullet."

I can haz blog!
[ Parent ]

And then after localroger's sermon (4.50 / 4) (#34)
by Kalani on Sun Mar 03, 2002 at 03:33:42 PM EST

What kinds of projects have you been working on? The "fly by the seat of my pants" method of programming might work fine on relatively small projects, but what about projects that are hundreds of thousands of lines and must last for years? All of the successful large-scale systems I've seen were very well documented, so that subsequent additions or just regular old code audits were much simpler. Getting a moderately functional (even completely functional) system up is not usually the biggest problem in a project, and "really talented programmers" who don't need specifications are often as dumbstruck as everyone else when some large block of code marked "// commence execution of voodoo spell" fails to work correctly in an important special case and is, by that time, a mess to reverse engineer.

While I'm on that subject, I'd just like to say that you should never have to seriously reverse engineer source code that you've already got. That's one of the biggest arguments for documentation.

Also, on the topic of "silver bullets," I don't think that Java and VB are adequate solutions to poor programming techniques unless the project is a fairly trivial PC app or servlet. Memory management is not difficult, and when you need to write procedures that can be many times faster by, for instance, working with page-aligned memory blocks to avoid page faults, the more direct control that you have, the better your results will be.

I'm not sure how I feel about all of the "choose the right tool for the job" protests either. Language-agnostic libraries have mostly made that argument dead. Except where a runtime environment provides a unique service (e.g.: Java, Lisp, UnrealScript) or a language feature allows you to do things that would be difficult or impossible with higher-level languages (e.g.: hardware optimizations like the memory page gymnastics mentioned above) most modern languages are equivalent. Writing a little Direct3D-enabled physics simulation for Windows is just as easy in C++ as it is in VB or Delphi (or DJGPP with Windows extensions, for that matter).

What I'm getting at is, to use your analogy, that most sculptors these days work with pretty much the same kind of raw material and their choice of chisel is largely based in personal preference rather than practical necessity. For instance, many people like using Perl to write web programs. The main reason has been the regular expression parser and related features like a built-in hash type. However, pretty much every popular language has these features (not as native language features, but little is lost by having to call regexp.eval(s) rather than directly entering expressions along with the code).

I know that's not specifically the argument that you were making (w.r.t. "the right tool for the job") but it's a rant I've been waiting to let out for some time. Clearly there are cases where other tools are not appropriate, like when I'm writing software for my TI-92 or writing assembly code for one of the PIC microcontrollers [from the fine folks at microchip.com]). Still, I think (without any kind of statistical evidence to back me up in this case) that the majority of programming these days doesn't fall into any of those special cases. I think that universal libraries are much more important in most cases than modern languages.

Well those are my sleep-deprived ramblings. Goodnight!

-----
"I [think] that ultimately physics will not require a mathematical statement; in the end the machinery will be revealed and the laws will turn out to be simple, like the checker board."
--Richard Feynman
[ Parent ]
Misunderstanding (4.00 / 1) (#70)
by localroger on Sun Mar 03, 2002 at 06:39:10 PM EST

While I'm on that subject, I'd just like to say that you should never have to seriously reverse engineer source code that you've already got. That's one of the biggest arguments for documentation.

I did not say, or mean to imply, that any software environment "does the work for you" or that there is an alternative to copious documentation. My point is that languages which try to do things for you -- everything OO, for example -- get in the way as much as they help. FORTH (which contrary to rumors of its demise IS still in use in a lot of control apps) is a notoriously hard language to read, thus it requires extensive and careful documentation; but once you are familiar with its wacky RPN notation it is a blazingly fast and almost bug-free language to write in, because even a very undisciplined style can all but eliminate accidental bugs.

In the last few years I have single-handedly finished six 20,000+ LOC projects, mostly in a mixture of assembly language and VB. (I use a mix of other oddball control languages for smaller stuff.) One recent project was 12,000 LOC in assembly alone, in an environment with no debugging where the only way to run code was to load it into an instrument and observe its behavior. This project would have taken just as long, and probably longer, in C; and it wouldn't have run in the controller I was forced to use, because of code bloat. (FYI C is not portable assembly language.)

Also, on the topic of "silver bullets," I don't think that Java and VB are adequate solutions to poor programming techniques unless the project is a fairly trivial PC app or servlet.

NOTHING is a solution to poor programming technique. However, "good programming technique" in my book is not quite the same as it is in the textbooks; it includes sensitivity to the environment (both user and computer) and constant refactoring with this in mind. My point is, if you do have the skill and understand the tool, does the tool encourage proper results or get in the way? No matter what you use you must document what you did.

I can haz blog!
[ Parent ]

Ah ... (3.00 / 1) (#72)
by Kalani on Sun Mar 03, 2002 at 07:35:29 PM EST

I guess I'm just not straight on how you document.

One thing that I'm really big on doing is (and this works to varying degrees depending on the project):

1) Identify the atomic types of data on which my program will operate (users, physical devices, light scripts, geometric objects, etc).
2) Identify all (or as many as possible) necessary (and distinct) conceptual objects to construct, transform, or register for notification events instances of the atomic types mentioned previously.

I usually do that before I write the high-level application code (I know that many people say it's better to write the program entry-point first, but I think of that as the third step -- after you've fleshed out exactly what your program will be working with). When I'm writing those objects, I document every method in explicit detail (what it does in general, what its inputs signify, what its output(s) signify, whether or not it changes object state and under what conditions, and some general implementation notes if the algorithm(s) to carry out the procedure are not obvious -- for instance my explanation for the final evaluation procedure in my regular expression parser is about a page and a half long: first segment an abstract description of the procedure and the second segment an in-depth explanation of the procedure).

I remember reading a quote by somebody who said "Don't get suckered in by the comments - they can be terribly misleading. Debug only code." That sort of approach leads to failure for any large project. I don't think that huge, lengthy specifications manuals are really necessary if you are very rigorous about commenting the basic code/data aspects of your program (and keeping those comments accurate as you change code).

So that's all that I was getting at really.

I'm curious to know what you might think of this article written by my uncle (David Thielen) a couple of years ago: http://www.sdmagazine.com/documents/s=760/sdm9903h/9903h.htm.

-----
"I [think] that ultimately physics will not require a mathematical statement; in the end the machinery will be revealed and the laws will turn out to be simple, like the checker board."
--Richard Feynman
[ Parent ]
And the "extremes" meet... (2.00 / 1) (#73)
by localroger on Sun Mar 03, 2002 at 07:46:12 PM EST

We actually have pretty similar coding styles.

I'm curious to know what you might think of this article written by my uncle (David Thielen) a couple of years ago

I think I'm glad I work in a one-horse shop where I'm the whole department and we don't do 100,000+ LOC projects. Yet :-)

I can haz blog!
[ Parent ]

Or if it doesn't exist (4.80 / 5) (#42)
by cooldev on Sun Mar 03, 2002 at 04:01:51 PM EST

Sorry for the long post, but IMHO it's worth reading :-)

This is why really talented programmers who have a rep for doing a months' worth of work over a weekend don't like to work in teams.

Yes, there is a documented 10:1 difference in productivity between the best and worst programmers, but I've never seen a claim (and it has not been my experience) that those programmers do not like to work on teams. In fact, one of the factors that contributes to this phenominal productivity is that they work well with not only their own team, but they have a huge knowledge network (inside and outside of the company) from which they can quickly ask for information while other people are looking it up. In my experience these people naturally assume an informal lead-type role in a team and the other programmers fill in the important, but underrated supporting and feature work.

They don't use specifications, except in the vaguest sense. Specifications, in case you never noticed, are one of the aspects of modern programming technique that don't work.

The only thing I've noticed is that specifications are frequently not well thought out, leaving the programmer doing a lot of unnecessary legwork and rewriting of code. I'm not talking about "thrown over the wall" specifications, I'm talking about that thing that describes what the program does, what it will look like, etc. If you don't do specifications up front they're going to get nailed out in the design or coding phases. Unfortunately the later you wait the more expensive it becomes to make changes, which is why it makes sense to have them done earlier. It's much easier to rip out a sentence or a change a screen shot than it is to rewrite 5000 lines of code or redesign all of your dialogs.

If you're working on little C++ tools to do blit or blat, pre-written specifications probably don't help much. But if you're working on an application that's eventually going to grow to dozens of modules, thousands classes and millions of LOC, with interdependencies on databases, servers, etc., you need specifications.

There are silver bullets aplenty for those who are willing to use them -- FORTH, Java, and Visual Basic all spring right to mind. . . . The tools do make a difference. Tell four sculptors they need to make a Greek column and give them all similar pieces of wood to start with. Give one a hacksaw, one a chain saw, one a chisel, and one a lathe, and ask them all if there is a "silver bullet."

Read The Mythical Man Month like I suggested. All past breakthroughs ("silver bullets") have addressed what Brooks calls accidental difficultiles. Accidental difficulties are things that get in the way, but aren't part of the inherent complexity of writing software. Some of the breakthroughs were high level languages and interactive programming (vs. batch or time shared). I stand by Brooks in saying that there's not going to be a silver bullet for at least ten more years. He made his original prediction in 86, and revisited and made the same prediction ten years later. Languages like Java, C#, and VB offer great incremental improvements, but not enough to be a silver bullet; nobody uses FOURTH, so we can see where that went. (BTW: There are many accidental complexities in C++, but even removing them all wouldn't yeild a several-fold increase in productivity.)

IMHO the closest thing to a silver bullet has been component-based design/programming. This is what's made VB, and to some extent Java more productive -- the fact that you can buy ready-made modules and class libraries for a fraction of the cost (and time) it takes to develop them in house. The main problem here is components are of highly varying quality, and there's a glut of simple components (how many grid controls are there?) but few domain-specific ones.

I'll close with a quote from TMMM which says what I was trying to say in the last post, but better:

I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation. We still make syntax errors, to be sure; but they are fuzz compared to the conceptual errors in most systems.

This is absolutely true in my experience. I haven't had a syntax error that stumped me for more than two minutes for a long time. NULL (or dangling) pointer crashes are exceedingly rare in my code and my team's code. Oh, one last thing now that I pulled out the book. Brooks directly addresses "automatic programming" as well as "graphical programming" as silver bullets that have failed to materialize:

. . . Nothing even convincing, much less exciting, has yet emerged from such efforts. I am persuaded that nothing will. In the first place, as I have argued elsewhere, the flow chart is a very poor abstraction of software structure. . . In the pitiful, multipage, connection-boxed form to which the flow chart has today been elaborated, it has proved to be essentually useless as a design tool--programmers draw flow charts after, not before, writing the programs they describe.



[ Parent ]
*plink* (4.00 / 1) (#69)
by localroger on Sun Mar 03, 2002 at 06:29:12 PM EST

The only thing I've noticed is that specifications are frequently not well thought out

You mispelled "never." I have never, in 15 years of programming professionally, had a project that came out (or even could have come out) according to specifications. At the low level seat-of-your-pants is far more efficient; at the high level nobody has a global view of the enterprise, so there is nobody competent to write a specification. Usually the person (hopefully singlular) doing the coding ends up being the only one even capable of writing the spec, and in my case the spec usually ends up as comment statements in the program as it develops.

Favorite example: After four attempts to install a midrange system (~15000 LOC) in a critical area of one plant, the plant manager announced in a meeting of 20 or so of his management staff that I was the only one who knew how his [multiple expletives deleted] facility operated. This became the case after I tracked down multiple information pathways, some of them involving such things as labels stuck onto legal-size sheets of paper and 10-key totalization printouts, which were used for critical interdepartmental communication. Only after I duplicated those pathways could my system go in successfully.

There are many accidental complexities in C++, but even removing them all wouldn't yeild a several-fold increase in productivity.

The only way you can make such a statement is to have blinders on as to just how much of the crap thrown up by modern programming environments is unnecessarily difficult. Even in VB, I spend more time chasing language specifications and obscure dependencies than I do writing code. Why? Because I insist on writing code that works and that means you have to know how the language implements things. Many critical things are not documented. One thing that popped up recently -- is it efficient to build an array by using successive ReDim(Ubound(array)+1)? Doing this a character at a time with strings bogs down the string handler. I had to write test code to find the answer, because it's not documented.

And VB is a relatively benign environment for such things. Now you can churn out crap at an amazing rate in VB which may work more or less, whereas the same effort in C will result in a BSOD; but doing it right in either environment is a massive PITA compared to, say, assembly language where you at least know what you are dealing with.

Oh, one last thing now that I pulled out the book. Brooks directly addresses "automatic programming" as well as "graphical programming" as silver bullets that have failed to materialize

I would agree that there is no such thing as "self-documenting" code and no substitute for copious comments. The problem is that the modern OS and language paradigm forces you to spend more time fighting and schmoozing the development environment than it does coding the actual application.

I can haz blog!
[ Parent ]

RE: *plink* (== *plonk* ?) (4.00 / 1) (#71)
by cooldev on Sun Mar 03, 2002 at 07:05:49 PM EST

You mispelled "never." I have never, in 15 years of programming professionally, had a project that came out (or even could have come out) according to specifications.

Which is exactly why I said that the hard part about software engineering is debugging the specification. The spec always has to be refined, but having a spec to start from is very valuable. The spec should not attempt to go into details that are more easily coded, of course.

At the low level seat-of-your-pants is far more efficient;

Oh, please. As a (quite competent, IMHO) professional developer I can assuredly tell you that for nontrivial applications seat-of-your-pants programming is one of the fastest ways to fail.

. . . Usually the person (hopefully singlular) doing the coding ends up being the only one even capable of writing the spec . . . After four attempts to install a midrange system (~15000 LOC) in a critical area of one plant

I think this is where we're having a disconnect. You're talking about a single person implementing the system, and 15,000 LOC being a "midrange" system. In a language such as C++ or Java that is a small system (many of my college projects were larger than that). I still think specifications are valuable for such small systems, but lack of a specification for a system of this size usually won't prevent it from getting completed.

The only way you can make such a statement is to have blinders on as to just how much of the crap thrown up by modern programming environments is unnecessarily difficult.

Oh, I'm very aware of it. I do nearly all of my development in C++ using Win32, ATL, and STL, and that can get quite nasty. Win32 is complete, but it's not exactly elegant. The problem is that these aren't really flaws in the languages or techniques, but rather inherent complexities that happen because they're created by people. That's where being a professional developer comes in: part of your value is your knowledge about the intricacies and warts of the systems you work with, and techniques to avoid them. No matter which languages or tools you use you'll run into the same problems. Or do you honestly think that your "flowchart programming" idea is immune from this?

The good news is there is a lot of incremental improvement going on in these areas. Java was the first environment I used which I felt had an excellent class library, and now .NET is following suit. There are still plenty of issues, of course, but we're learning from previous experience.



[ Parent ]
No plonk, no flowcharts either (4.00 / 1) (#74)
by localroger on Sun Mar 03, 2002 at 07:54:52 PM EST

Sorry, I meant the *plink* to whimsically imitate the sound of a silver bullet striking -- hmmmm, may be a brick wall?

Or do you honestly think that your "flowchart programming" idea is immune from this?

Check the authorship; that wasn't my idea. I think certain languages like FORTH and VB accomplish some of the things the original author hoped "flowchart programming" would do. None of these approaches is immune from the need to document, though, and in fact the attempt of the language to "self-document" usually just creates redundant work that gets in the way of the real documentation.

There is really no such thing as a 100,000 LOC application, or even a 10,000 LOC application. There are constellations of small routines, procedures, and even "stand-alone" apps which work together. The obstacle which arises at high levels of abstraction is uncertainty in the parameters; but better focus at the low levels of abstraction can clear this up. We have some projects in the 50,000 LOC+ total range coming up but they look no different from where I stand than the other things I've done looked (except I'm returning arrays from functions, now that I've tested that and found it efficient enough, for convenience). Make your bricks strong enough and you don't have to worry about the architecture of your dome.

I can haz blog!
[ Parent ]

Lines of code (4.00 / 1) (#79)
by cooldev on Sun Mar 03, 2002 at 10:35:20 PM EST

The reason I brought up code size is once a program grows to a certain size it can not be understood in whole by a single person. Long before that, it cannot be written (in a timely manner) by a single person. As long as a single person can internalize and work on the entire system you can get away with less specification, design, and even testing.

A lot of the issues in software development are the result of large or complex systems; the nature of software development is that we're constantly pushing the edge of what's possible to do; push too far and the system fails because the tools (or CPU power, etc.) do not yet exist for managing the complexity. The microconcerns such as whether you return an array from a function don't change much for bigger projects, but issues with conceptual integrity, communication, locical flaws, and interdependencies are a lot more common and less forgiving.

Make your bricks strong enough and you don't have to worry about the architecture of your dome.

I disagree with your snazzy statement. Make the bricks strong enough and you don't have to worry about the bricks. You still have to worry about the architecture, but the brick concerns have been abstracted away. This is, of course, what makes software development possible, so I think it's what you meant to say. :)



[ Parent ]
Lines of code? (3.00 / 1) (#80)
by krogoth on Sun Mar 03, 2002 at 11:14:52 PM EST

There are several very large projects that are doing quite well. The Linux Kernel, for example, along with several other popular projects, has a few million lines of code (approx 3M in .c files and 0.7M in .h files as of 2.4.8) and is doing quite well, although most people probably think that the development process could be improved.
--
"If you've never removed your pants and climbed into a tree to swear drunkenly at stuck-up rich kids, I highly recommend it."
:wq
[ Parent ]
So what? (none / 0) (#92)
by cooldev on Mon Mar 04, 2002 at 08:35:27 PM EST

What relevance does the Linux kernel have to this discussion?

If we're still talking about specifications, the Linux kernel (and many other open source projects) had the best spec you can imagine: working systems to copy! Linux is a Unix workalike. I'm not claiming there was no innovation beyond that, but at least in the beginning there was little question about what it should do because POSIX and other Unix standards are clearly defined: the behavior, protocols, APIs, and even many of the core algorithms were already documented and easily available. It's like color by number.


[ Parent ]
No, this is exactly our disagreement (none / 0) (#93)
by localroger on Mon Mar 04, 2002 at 09:47:07 PM EST

I disagree with your snazzy statement. Make the bricks strong enough and you don't have to worry about the bricks. You still have to worry about the architecture, but the brick concerns have been abstracted away.

No, I meant you don't have to worry about the architecture -- except in the broad sense "I want it to look like a dome." The reason is that you're no longer operating at the edge of the possible, so you don't have to constantly check yourself against specifications. You can be approximate without worrying that it will fall down, and pay attention to form and function rather than deflection and compression overloads.

The reason large programs are hard to design is that the pieces-parts either don't exist or aren't fully formed when the high level abstract components are brought together. This creates uncertainties which must be chased out in the specification (what kind of data are we returning here? Is it the same format we're using in module XYZ?) and in the implementation ("Hey, this should have worked, but I'm getting a foo.bar error").

You probably also won't be surprised to hear than I am a tremendous non-fan of top-down programming, for the same reason: It doesn't work. It may, in an extremely large enterprise-level environment, be the only way to coordinate a large number of participants; but that doesn't make it "good" any more than one would say bureaucracy is "good" because it's the only way to make something the size of the government work. In fact, that analogy goes pretty far.

Back in the 80's (before Poppy Bush's First Gulf War) I read a book by a UNICEF worker about mud-dome houses in the desert. These dwellings have a tendency to collapse if it rains, or there is an earthquake, burying and killing their occupants in the bargain. This guy got the clever idea of firing the entire house as a single ceramic structure. Turns out the idea was practical, and the resulting structures not only don't collapse in an earthquake, cannon balls and bullets bounce off of them. The design of the mud house is a delicate thing, prone to collapse if not done exactly right; but if it survives being fired into ceramic it will forgive any multitude of sins against it. You can build software the same way. But you can't do it top-down, and you can't do it with tools that require constant babysitting in order to work right. You must do it with materials so hard they are almost impossible to break, so they won't punish you when you abuse them by collapsing and burying you.

I can haz blog!
[ Parent ]

I disagree that this is our disagreement (none / 0) (#95)
by cooldev on Tue Mar 05, 2002 at 02:57:07 AM EST

So there.

I don't care if your bricks are made of solid diamond, you still have to worry about architecture. A poorly designed building can topple even if all of the component pieces are flawless.

But as for the rest of your message, I think we're mostly in agreement. If the pieces are not well formed and you have to worry about those details in addition to what you're building large systems become very, very complex to manage, and unnecessarily so.

I'm also a strong believer in bottom-up design, although realistically most commercial applications can't be completely written that way because it's too time consuming (you end up building and unit testing a lot of pieces you don't fully use). Interestingly, one of the promises of OO is not that the first or second or even third iteration of developement would go faster, but by the time you get to the fourth and fith iteration you have a robust and flexible object model that serves as a strong foundation.

Still, I fail to see how this negates the need for specifications. Even assuming you can build perfect pieces with bottom up design you still need to specify what you're building, how it will look and behave, how the subsystems will interact, and how it will interact with other systems.



[ Parent ]
You really meant "Ka-PWING!" (none / 0) (#82)
by pwhysall on Mon Mar 04, 2002 at 03:08:51 AM EST


--
Peter
K5 Editors
I'm going to wager that the story keeps getting dumped because it is a steaming pile of badly formatted fool-meme.
CheeseBurgerBrown
[ Parent ]
XP counter arguments (2.00 / 2) (#75)
by lastfish on Sun Mar 03, 2002 at 08:34:31 PM EST

I've been thinking about trying XP but have some qualms. Can you give references to support failings/weaknesses in the methodology?

It seems a pragmatic approach to development in that it doesn't aim for or expect perfection yet keeps programmers happy [less documenting, more doing]; employers safer from knowledge loss and seeks to ensure useful results.

I can't help but think that having two __good__ programmers working separately must be better than pairing them. Of-course few programmers are really, or consistently good - hence "pragmatic".

The literature I've come across is mostly by self-publicising evangelists who assert it's benefits but give little in the way of convincing evidence that the constituent parts work better than the alternatives. That said what I've read sounds plausible.


[ Parent ]
specifications don't work? (none / 0) (#86)
by avdi on Mon Mar 04, 2002 at 11:51:45 AM EST

Odd, I wonder why this company's still in business?

To some degree I sympathize; I'd like to see some XP practices adopted where I work. But when the project encompasses hundreds of KLOC, that must be written by more than one programmer, because of the size of the job, different areas of expertise, etc., you can't just tell them all to make something that works and expect it to integrate. Even if they are constantly integrating, they'll deadlock because nobody will know who is responsible for the grey areas between modules, one group will insist that an interface be one way while another group insists it be another way, and so forth. For large projects that that must meet very specific, set-in-stone custtomer requirements, you must have an overall specificaton, or it will never be finished.

I sometimes think that people who advocate throwing away specifications completely have never worked on a project larger than a few tens of KLOC, with consequence of failure being no worse than some .com's web storefront going down, and with requirements no more specific than "we need a web storefront, can you make us one?".

--
Now leave us, and take your fish with you. - Faramir
[ Parent ]

My experience (none / 0) (#94)
by localroger on Mon Mar 04, 2002 at 09:56:45 PM EST

It's true that I've never done a project of more than about 25 KLOC. OTOH I've never worked in a group, either, and doubt if I could. Old habits die hard.

On Yet Another Hand, however, the projects I've worked on can put whole plants out of business, destroy property, and kill people when they misbehave, so I take bugs far more seriously than is usual in the IT industry. Several people here have already pointed out the differences between this kind of work and, say, web design; like I said, old habits die hard and IMHO the only acceptable level of BSOD-level failures is zero. Anything else signifies incompetence. And while I have had the occasional bug, I have never had a major bug surface more than a few weeks after installation. And I have no doubt that, given the time and inclination, I could create 100 KLOC+ size applications with the same performance.

Now whether I could manage other programmers into turning out that kind of work is an entirely different question...

I can haz blog!
[ Parent ]

Different Domains... (none / 0) (#97)
by avdi on Wed Mar 06, 2002 at 12:02:09 PM EST

Sounds like your skills are well suited to the job at hand. Not everyone has the luxury of working alone though. There are areas where a team is required. More importantly, there are systems consisting of millions of lines of code, that are maintained and upgraded over ten or twenty year periods, in which one does not have the option of having a single godly hacker re-write the whole thing from scratch. New modules written by one team must must integrate with older modules written by other teams. And there are systems where different modules are actually maintained by different departments, or entirely different companies. In cases like this, hard, detailed specifications are absolutely vital.

BTW, when I hear someone who, by their own admission, has not and cannot work with a team, I consider anything they say against software teams deeply suspect. If you haven't worked on a team, you can't really make grounded assertions one way or another about the effectiveness of teams. Personally, I prefer to work alone. But I know from experience that 5 competent hackers working on a project will get farther, faster than one guy working alone. And as long as the specs are well-defined, the end result will equal if not exceed in quality the lone hacker's code. Having 4 people read your code and exercise it in ways you never thought of has a way of turning up lurking bugs.

--
Now leave us, and take your fish with you. - Faramir
[ Parent ]

Modern languages grew out of flow charts ... (4.75 / 4) (#36)
by Kalani on Sun Mar 03, 2002 at 03:40:07 PM EST

... so going back to that would not be very helpful. The constructs we've built up in modern programming languages, type safety, polymorphic classes, exceptions, etc are generalizations of what would be fairly convoluted constructs in a flow chart. You should take a look at automa theory (getting its biggest fanfare today in linguistics -- but also used for formal descriptions of things like regular expression parsers, compilers, etc).

If you've got a program that has some core algorithm(s) then also expressing the algorithm in a flow chart (if it's helpful) would be a useful addition to the repository of information you keep on vital things like that. Plain English can also be useful, and so can geometric diagrams.

-----
"I [think] that ultimately physics will not require a mathematical statement; in the end the machinery will be revealed and the laws will turn out to be simple, like the checker board."
--Richard Feynman
[ Parent ]
ah, but.. (3.00 / 3) (#41)
by rebelcool on Sun Mar 03, 2002 at 03:58:24 PM EST

The reason they grew out of flow charts is because at the time, there was no reasonable method for entering flowcharts into a computer system. If you look at assembler, it really is just a flowchart (a very, very, simple one) using some obscure symbology.

Nowadays though, we have the graphical ability, the user interfacing tools to be able to enter a flowchart directly into the system. No need to translate it first to what the machine understands. (The translation does occur, but thats by software, not the human)

Things like classes, type safety, exceptions and all that grew out of the fact that lines of text - code - introduced alot of big problems.

What I'm suggesting is the near total removal of code. By code, I mean the lines of text that a human interacts with to make a program. Naturally the hardware still needs to be fed opcodes in order.

Now I dont think it can happen in one fell swoop. Certainly, the way I would do it (and might experiment with when i get some more time..) is generating code in a language, from the design charts.

Imagine if you could drag and drop logic pieces together to make an algorithm. Then you drag and drop a few variables. Their types will be checked by the tool. Plus you get the visualization improvement of looking at a large, easy to read diagram of what you're doing.

Click the 'generate code' button, and out it spits some nice java code for inclusion into your project.

Much of this is the same reasoning behind graphical IDE's for interface development.

COG. Build your own community. Free, easy, powerful. Demo site
[ Parent ]

I don't agree (5.00 / 6) (#44)
by Kalani on Sun Mar 03, 2002 at 04:30:59 PM EST

First of all, that's been done. Look at LOGO. Second of all, flow-chart algorithms are equivalent to token lists (which is what code gets translated to anyway). I think that the main reason that it didn't take off was that spatial relationships have no meaning so it only adds confusion (you wind up wasting a lot of screen space for nothing). The "drag and drop" logic that you describe has no benefit over the symbolic logic that you type (specifically, a picture of a digital OR gate doesn't convey any more immediate meaning than the "|" character).

Also, things like classes, type safety, and exceptions are abstractions that are removed from text. If you build up a symbolic system you will eventually build equivalent abstractions (that's because classes, types, and exceptions are all abstractions of logical methods ... which are not necessarily text-bound).

Just because it works best for GUI builders doesn't mean it works best for constructing logical systems. User Interfaces are necessarily constructed out of graphical objects, but the atomic units of logical systems are not graphical objects, they're concepts. Your superficial description of the system ("Imagine if you could drag and drop logic pieces ..." and "Click the 'generate code' button") does not demonstrate any value in the system.

I think you might want to look up case studies on things like the efficiency of purely graphical toolbars versus menus w.r.t. user-issued commands.

-----
"I [think] that ultimately physics will not require a mathematical statement; in the end the machinery will be revealed and the laws will turn out to be simple, like the checker board."
--Richard Feynman
[ Parent ]
LOGO is not a flowchart language (5.00 / 1) (#81)
by fluffy grue on Mon Mar 04, 2002 at 02:04:13 AM EST

LOGO is a simplified form of "functional-imperative," similar to Tcl, Python or Scheme. A true "flowchart-type language" would be Fortran.

LOGO wasn't programmed graphically; it's just that it was designed primarily around doing simple graphical tasks using turtle graphics (which many other languages have provided, such as Comal and early versions of Turbo Pascal).
--
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

Sorry you're right ... (none / 0) (#98)
by Kalani on Sun Mar 10, 2002 at 02:35:42 PM EST

... I mixed myself up. I have actually programmed in LOGO a long time ago, but since it's not appropriate here replace every instance of "LOGO" in my messages with "Lego Mindstorms Programmer" (which I have also used and which I am absolutely certain has a graphical programming environment).

-----
"I [think] that ultimately physics will not require a mathematical statement; in the end the machinery will be revealed and the laws will turn out to be simple, like the checker board."
--Richard Feynman
[ Parent ]
Another reason we don't program with flowcharts (4.50 / 4) (#45)
by krogoth on Sun Mar 03, 2002 at 04:36:44 PM EST

I think the real reason is that most programmers would never accept it. Even if you aren't drawing them by hand, I can't see that being faster than typing code.
--
"If you've never removed your pants and climbed into a tree to swear drunkenly at stuck-up rich kids, I highly recommend it."
:wq
[ Parent ]
what kind of argument is that? (3.50 / 2) (#61)
by rebelcool on Sun Mar 03, 2002 at 05:28:08 PM EST

"we would never accept it" is just goofy.

So, when designing a form, you'd rather write in code than click and drag the various buttons, text fields and so on?

My, one would think that the graphical IDE market would've crashed were that true...

COG. Build your own community. Free, easy, powerful. Demo site
[ Parent ]

Designing a form has nothing to do with flowcharts (5.00 / 2) (#76)
by krogoth on Sun Mar 03, 2002 at 08:52:31 PM EST

As has been said before, flowcharts wouldn't work too well for the actual code. I also doubt that you could specify a user interface as a flowchart - at best it would be a step backwards to CreateWindow().
--
"If you've never removed your pants and climbed into a tree to swear drunkenly at stuck-up rich kids, I highly recommend it."
:wq
[ Parent ]
the worst way... (5.00 / 2) (#85)
by avdi on Mon Mar 04, 2002 at 11:40:08 AM EST

...to deal with bugs is to propagate stupid language bigotry. Quality code can be written in any language, just as buggy code can be written in any language. Among the languages in common use today, the best that can be said of any of them is that they make certain classes of errors easier to avoid. The path to bug-free code is to learn and apply, in a disciplened manner, established best-practices for the language at hand. Whatever the language, educate yourself on the common gotchas of the language, test first, use assertions, check function returns, refactor mercilessly, and review your own code often - these things will go a lot farther toward producing crshless code than mindless devotion to a certain language or languages.

--
Now leave us, and take your fish with you. - Faramir
[ Parent ]
Flowchart programming (4.00 / 1) (#90)
by unDees on Mon Mar 04, 2002 at 05:57:44 PM EST

Personally I'd rather see more flow-chart programming.
Many people in the scientific and research community use LabVIEW, a graphical programming environment whose programming "language," called G, is purely visual. It's not a UML-to-C++ converter or anything like that (egad!). Its only representation is graphical. I use it quite a bit in my job, and it's, well, fun. When I was interviewing for this job, I thought, "This thing is a toy." But this "toy" can compile down to an executable or to a shared library on Mac, Win32, Solaris, and Linux. It can statically link to (modified) object files or dynamically link to shared libraries. It can build simple GUIs quickly. It's got a nice debugger. LabVIEW nearly fulfills juahonen's description of a "flowchart that compiles." Well, it's more of a dataflow diagram than a flowchart, but still...

As with anything else, it's not the be-all and end-all of development tools. It's expensive unless you're a student. Newer features tend to get implemented on Windows first (or Windows only). It's possible to create data structures that bog down your program with slow execution times or large memory consumption (then again, I can write a bad application in any language).

And it's not the only such tool, either. Agilent Vee, whose saved files look eerily LISP-like, and Sanscript spring to mind.

Graphical programming (again, not RAD-to-text generation) can be an elegant way to write software. On the job, I often catch myself smiling in spite of myself. There are still plenty of cases when I use a good C or C++ compiler for better access to system APIs or extreme performance demands, or a good scripting language for quick, one-off projects. But the graphical approach is a good utility to have in the toolbox.

Your account balance is $0.02; to continue receiving our quality opinions, please remit payment as soon as possible.
[ Parent ]

Shiver... sounds like Edify (none / 0) (#99)
by rampy on Mon Mar 11, 2002 at 07:38:55 PM EST

EDIFY programming middleware... it's like programming with lego's but your hands have been lopped off (have you ever tried putting lego's together with your nose before?)

The kids at mcdonalds have pictures on their cash registers and my order still get's munged up. Actually the idea of flow chart programming sounds interesting, I'm just in a facetious mood.

rampy
www.randomdrivel.com -- Fish, plankton, sea-greens, and protein from the sea!
[ Parent ]
oh god, please no flowcharts... (none / 0) (#101)
by joto on Fri Mar 22, 2002 at 05:25:57 AM EST

When comparing a textual representation of a while-loop with two simple if-tests in the middle, resulting in "break" or "continue", and the resulting flowchart, most anyone will prefer the textual representation.

Flowcharts were probably useful before people started using high-level programming-languages like FORTRAN, LISP or COBOL, and maybe even up untill the time when structured programming became fashionable.

But to speak favorably of using flowcharts instead of a real programming language today is completely beyond common sense. There are no programs big enough to need a flowchart to explain it, that are small enough for a flowchart to help understanding it, and there will never be.

Flowcharts are better viewed as a relic from the past, just like the telex. While incredibly useful in it's time, we now have better tools.

[ Parent ]

MSIE (3.83 / 6) (#11)
by webwench on Sun Mar 03, 2002 at 02:35:57 AM EST

Some versions of MSIE do something similar when IE crashes. It will pop a dialog box asking the user if he would like diagnostics of the crash sent to Microsoft before IE shuts down.

There are a couple of problems with this, though:

  • Presumably, this only happens on 'handled' crashes -- whether all, most, some, or fewcrashes prompted this process would depend on the developer and on the type & severity of crash;
  • Depending on the number of users of a product and the extent to which the product was tested before it was shipped, the volume of data could well be overwhelming;
  • This is the epitome, to the user, of a 'fire and forget' process -- at least in the case of IE, the user can expect no confirmation of receipt of the information and certainly no immediate resolution. Most users, after a couple of these, will start unchecking the 'send diagnostics' checkbox.
Still, it's better than nothing -- recipients of this generated info get more accurate and consistent information, rather than garbled user descriptions ("My Internet broke!"), and the quantity certainly must be nice.

Indeed. (4.75 / 4) (#17)
by cooldev on Sun Mar 03, 2002 at 03:51:51 AM EST

This is not a very publicized feature, but the error reporting tool you are speaking of debuted in Office and was quickly adopted by other teams, including Windows XP.

I couldn't find a whitepaper, but a brief description can be found in this KB Article. Basically it sends the stack, registers, local variables, and other interesting data as a smallish (64k) file that can be read by the VS.NET and WinDbg (free) debuggers. This is great for post-mortem debugging and can help track down really hard to repro bugs. It's especially valuable during internal beta testing and stress testing.

You can add this functionality to your own apps, look up the MiniDumpWriteDump() function. You'll have to figure out your own way to send it to your server, if you wish to do so.

To address a couple of your points:

1) It's usually put in the unhandled exception handler (disclamimer: I've never directly hooked this up) which is called by the OS when the app crashes. This catches virtually everything, but yes, there are some things that slip through, such as stack overflows or calling evil functions such as terminate().

2) The volume of data is heavily dependent on the stability of the app and number of users. There are shortcuts you can take on the server to count but not store "duplicate" dumps. Consider that XP sends dumps not only for kernel and driver crashes, but all user-mode crashes for both Microsoft and 3rd party apps. (BTW: I have no idea what the numbers look like, and even if I did I wouldn't say.)

3) Yeah, you have to make it quick and easy. There are also a number of users that will never use it due to privacy concerns, and that's OK. But, even when you have millions of users using an app, the sample size does not have to be that big for your to statistically determine the top crashes. As I mentioned above, this crash analysis is also extremely valuable during the testing phase.



[ Parent ]
One additional comment (3.75 / 4) (#19)
by cooldev on Sun Mar 03, 2002 at 04:10:28 AM EST

I didn't want to editorialize my last comment too much, but I do want to say this:

Modern application should not crash. I have found this to be true for all of the recent apps I use, but I'm careful to stay away from crap.

The reason I call this out is this is what makes online crash reporting possible and valuable: Based on the crash data for the (user-mode) apps I've worked on, there are usually a small handful of bugs that account for 90% of crashes. After you fix those most customers never see a crash again. Many of the remaining crashes are just noise, i.e. out of 10 million users that use the product every day you'll get 5 or 10 hits a month on an obscure bug that "can never happen", and usually these are on Win9X.



[ Parent ]
Bugzilla (2.40 / 5) (#23)
by drquick on Sun Mar 03, 2002 at 10:32:31 AM EST

Bugzilla used in the GNOME and Mozilla projects already do this! Look here and here.

RTFA (4.00 / 2) (#49)
by greenrd on Sun Mar 03, 2002 at 04:52:37 PM EST

No it doesn't! Bugzilla is just a bug database. It doesn't automatically gather crash info. See my other post on mozilla and KDE crash handlers.


"Capitalism is the absurd belief that the worst of men, for the worst of reasons, will somehow work for the benefit of us all." -- John Maynard Keynes
[ Parent ]

BugBuddy (none / 0) (#88)
by Luke Francl on Mon Mar 04, 2002 at 01:45:44 PM EST

I think the poster is refering to BugBuddy (written by Ximian, I believe) which does generate a stack trace and submit a bug report to Bugzilla if an application crashes.

[ Parent ]
I've submitted several bug reports myself (none / 0) (#96)
by drquick on Wed Mar 06, 2002 at 11:52:05 AM EST

Right, I forgot to mention that the databases are used via bug-buddy or like. I've reported several crash bugs myself and indeed the software scans the core file and posts crash data.

I thought of that I forgot to mention bug-buddy, but I still can't find a link to it's homepage. Bug-buddy is part of the Gonme package. Mozilla uses another mechanism to transmit the crash data. They use a special build of the product that includes the "talkback" functions.

[ Parent ]

YOE (3.33 / 3) (#28)
by zephc on Sun Mar 03, 2002 at 12:44:24 PM EST

Yet Another Example:
OmniWeb (and i'm sure other products from the omni group - OS X applications) use the Omni Crash Catcher, which also sends bug reports that include a register dump, etc. to their developers. Kind of a closed solution though.

it's hard. (1.75 / 4) (#84)
by jusx on Mon Mar 04, 2002 at 06:58:25 AM EST

I don't think there's a good way to do this besides logging and collecting crash data.

A much better strategy is probably releasing software with lesser bugs and doing extensive testing as described in XP by Kent Beck. JUnit is a very nice testing framework.


----------
"My worth is not determined by the price of my clothes." - India Arie

Wrong on Null references (none / 0) (#89)
by Shimmer on Mon Mar 04, 2002 at 02:10:59 PM EST

> you would get crashes there because the r
> reference was NULL, even though that's
> completely impossible, there's no such thing
> as a NULL reference, C++ guarantees it

This is just false. Consider the following code:

int *p = NULL;
int &r = *p;
int i = r; // boom!

-- Brian

Wizard needs food badly.
Partly (none / 0) (#91)
by krogoth on Mon Mar 04, 2002 at 06:08:31 PM EST

The article I quoted that from wasn't as wrong as you think - if you look up the context it's not quite as easy to get wrong as you describe.
--
"If you've never removed your pants and climbed into a tree to swear drunkenly at stuck-up rich kids, I highly recommend it."
:wq
[ Parent ]
The point is... (none / 0) (#102)
by Shimmer on Wed Apr 17, 2002 at 11:26:52 PM EST

C++ does not guarantee that references will be non-null.

-- Brian

Wizard needs food badly.
[ Parent ]
this is great! (1.00 / 1) (#100)
by duckya on Wed Mar 13, 2002 at 07:26:03 PM EST

this is great!

A better way to find bugs? | 102 comments (102 topical, 0 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!