The software development process.

In article , Steve at fivetrees wrote: [..code without GOTO..]

Yes, it is much worse than code with GOTOs.

The whole point is to prove that it isn't the GOTO that is the problem. The fact that I can turn code with GOTOs into code without GOTOs by a method that does not address the spaghettiness I think is proof of this.

I think you've missed some of the context.

If the original was a state machine I'd agree (I use state machines a fair amount myself). However, the original was referring to a serving of spaghetti code. However you dress it up it's still spaghetti.

My original comment which originally started this thread referred to legions of gotos. I don't think I've seen code written in a higher level language with a lot of gotos which was not accompanied by a low level of discipline in the control flow. Gotos may not be inheritly evil, it's just that evil is their near-constant companion.

Robert

That should be VB6, how the heck did I make that VIBE?

You have to pick in the project the programs starting point. I've got it here in front of me and that's one of the items you set in the project properties.

Robert

Heck, a FOR loop is just a dressed-up conditional GOTO. ;-)

Cheers! Rich

Microprograms have an intrinsic GOTO in every microinstruction. ;-)

Cheers! Rich

ISTR, years ago, Microsoft C (about 3.1, I think) gave you the option of using "pascal-style" function calling, so your object code could link with compiled pascal code.

Shudder, indeed. :-)

Cheers! Rich

I worked on the DN3000's from Apollo. Their Pascal compiler was probably one of the better I've seen, where I closely examined the assembly output against what I might generate myself by hand.

Jon

Yes it was a very cool OS, written in an Algol-like language, but I suspect MUCH closer to Algol-60.

Algol-68 was what happened when they got together too many language designers and handed out free LSD. I don't think anybody actually ever was able to write a real compiler for the 68 version.

How to you write up a standard that delineates between "bad" #defines and "good" #defines? :-) Or was the prohibition more reasonable in that it stated you shouldn't try to turn one programming language into another?

You realize that C is often considered just a really high level assembler, right? :-)

True, although if you look at the current all-singing all-dancing language-neutral modular linkable code that is COM (and DCOM and COM+ and...), ther'es a lot to be said for simple "call the function directly but just push the arguments onto the stack in the reverse order" approach that was the Pascal calling construct!

(I don't think the Microsoft solution is bad... it actually works pretty well... but it adds a *lot* of overhead and code to the system that has to use it...)

Hello David,

Not with me anymore. I switched to Cadsoft Eagle. Does have bugs but the company is very responsive and the bugs aren't too serious for me. Plus it's very reasonably priced, something that I can't say for many of the other CAD tools.

For individuals, I generally accept this argument.

For corporations, it's a naively simplstic attitude. In companies with hundreds, thousands, or tens of thousands of employees, re-training everyone from Office to OpenOffice, changing the format of all the forms & templates used, and re-writing all the macros used can be *very* expensive. (What many people don't realize is that Word, Excel, etc. all have Visual Basic script built-in for creating macros, and the programs themselves are COM compatible. As soon as anyone starts automating Office using VB or COM, switching over to OpenOffice becames a *much* larger undertaking.)

Realistically, any company that's been using Office for a number of years will have to have a slow migration to OpenOffice. I'm an utter Office rube, and even I create documents that OpenOffice will "mess us" when opening.

When it comes to RF design software, I've been impressed that AWR's claim (with Microwave Office) of being the "most open high frequency design platform" really is legitimate and not just a marketing claim. Many of their file formats are XML, and their scripting (good old VB script and COM again!) gives you full access to the internal design database. You really can "build a schematic" or layout from VB if you feel like it.

In general I agree with you, though. Even some of the more, umm... responsive... EDA vendors out there such as Pulsonix don't document their file formats.

Unfortunately EDA tools aren't popular enough, I suspect, that something like the Open Design Alliance (which contiuously reverse engineers the AutoCAD DXF file format -- even stuff like the encryption in the most recent versions -- and then sells open-source code to read & write it to support themselves) will spring up.

---Joel

My impression has always been that he never intended it to be used as someone's "first" programming language -- it's definitely more targeted towards well-seasoned programmers who aren't going to shoot their foot off the first time you hand them a shotgun --, yet that's what it's become for many people.

Absolutely. The majority of people I've interviewed who put down "C++" experience on their resumes weren't even decent C programmers. (This is hardware designers, though, so we usually aren't emphasizing programming skills that much, but still...)

Heh. Yeah, basically the latter.

I certainly do ;). And I don't mean to say macros are bad - far from it. They can aid readability and promote consistency. But wrapping a goat in a sheepskin doesn't achieve much.

Steve

Ok, I've had a chance to digest this (after my previous two responses), and yes, I agree.

To be real clear: it's not the GOTO, it's the spaghetti. Where program flow is unconstrained (the "how did I get here" problem), issues inevitably arise. Some classic ones: - Will this process ever terminate? - What state will the system be in when it does terminate? - What state will the system be in when it reaches a certain line?

Going back to you code chunk despatcher: good point, well made. I agree that the spaghettiness remains in your example. And yet: I use such despatchers all the time without reservation, and I had to take a step back to really see the essential difference. My code, and my program flow, is not spaghetti - the states, their transitions, and their effects are well-defined. The design is not jumping around all over the place.

There's one more subtle thing: your chunk despatcher was in a tight loop, exited when a certain condition existed. The "will this process ever terminate" problem could dominate - if it's a specific sequence with a definite start and end, fine. If the ending condition, and how to get there, is unclear, I get uncomfortable. Also, because of my tendency to use cooperative multitasking, I would tend to put the whole thing in a loop much higher up the hierarchy - e.g. one iteration of the chunk despatcher per round-robin call. While this doesn't guarantee that the state machine will ever reach a terminal state (a separate issue), it does ensure that the rest of the system stays working.

To go (to) back to the original issue: as I've said, GOTO's per se are not evil. It's open constructs that are evil.

Steve (still rushing about, and probably not as clear as I'd like)

You explicitly state what you can and can't do with defines, then you have code reviews to weed out the creative weirdos. I would be happy with (and may even write) a coding standard that calls out something like #defines can only express constants or pseudo-functions, and must fit on one line. Then when someone wants to have #defines with three open braces, for loops and case statements, that must be matched by other #defines with three close braces you can shoot them.

Hello Joel,

I've had OO do hardcore crashes when trying to open a Word doc. Not good. If Sun could strike a deal and market it right they could slowly gain a chunk of the pie. But they don't.

There are other reasons why companies often don't use open source SW: Liability. Although realistically the EULAs reduce that to cases of underwater carpet fires there is at least a company with lots of cash behind the product and you can make a case that you relied on them doing "the right engineering thing".

My impression is that while all kinds of meetings with ritzy dinners are held, platitudes are published and all that they are not interested in open design.

BTW, did you get your EE position up there filled?

Hi Joerg,

We're working on it. We've hired one retired fellow in a contract position to design an RF power amplifier -- he's a former tech. college professor with lots of consulting on the side, but very much likes his 5th wheel, and therefore wasn't interested in a full-time/office-bound position. We have an in-person interview with another fellow next week (did his phone interview three weeks back, but not everyone has been in the office lately) that looks like it'll turn out pretty well.

The interviews:hires ratio seems to be lower than 3 or 4:1, which seems to be pretty good in my experience.

---Joel

Nowadays they just call it STANDARDCALL, or something like that. It is actually considerably more efficient than the so-called C call. It just doesn't cater to variadic functions.