The software development process.

All joking aside, this is usually a Really Bad Idea. (Exception: where the underlying language or command structure is so weird it's hardly worth learning.)

I've seen this principle in use - well-intentioned, but wrong-minded. It simply adds another level of complexity and won't be appreciated by those who *do* know the underlying language and wish to see it clearly. And as I've said (a fair few times), good C is readable C. (Substitute "C" for your language of choice.) I do realise that not all extant C is readable, but if you're writing it, and know it well enough to wrap another language around it, you're also able to write clear C.

I worked in a dept once where an earlier staffer had done as you describe - he'd turned C into Pascal via a bunch of macros. He wrote quite a lot of code. He left the company. Others took over what he'd done. The dept grew, and the expertise in C of the dept grew. They were still clearing out the last of the macros about 10 years later, and cursing him a lot. They evolved a (very good) coding standard, and stuck to it. It explicitly forbade such foolishness ;).

If you're working alone, of course, it's up to you. But my advice would still be: learn the language, don't wrap it in something else. Life's too short.

Steve

:) :)

I love it. Take ugly spahgetthi code and convert it to socially acceptable ugly spahgetthi code.

I wonder if there's a special level of hell for those who do things like this? ;)

Robert

BBC Basic was, for its time, superb. A proper structured language running on a "home PC". It was unheard of.

It also had plenty of weirdnesses, but at least you didn't have to use GOTO.

Steve

Ok, so you've broken the code up into virtual lines/chunks, and run a line/chunk despatcher. Man, I'd hate to have to maintain that ;).

(The fact that you've actually used a closed construct was probably for illustrative purposes. If it were not, I'd say that spaghetti code remains spaghetti code, or at least a spaghetti sequence, regardless of how one encodes it.)

Steve

thats about right. I almost failed a 1st year computer science paper by never attending a tutorial. I hassled the HOD, and pointed out my average mark for tests & assignments was 100%. His reply "why are you doing this paper". My reply "prescribed course degree"

The first "real" job I had was at a company whose R&D department had a policy of not hiring (or even interviewing) CS grads; engineers only. s/w for stuff like elevators and cranes is too important to tolerate sloppy programming.

Cheers Terry

Or at least, people who aren't 100% focused on whether the machine *works*.

Do it. After some few hours of frustration and confusion, it will start to be easy, then fun. I whip out a PB program whenever I'd have to do something on a calculator more than a few times.

For little engineering thingies, I still prefer the 16-bit DOS version, where you can write a useful 5-line program in a minute or so. It works fine under XP, graphics and all. The equivalent 32-bit version is the Console Compiler, which retains the bog-simple Input/Locate/Print approach to the user interface.

Go for the 32-bit Console Compiler if you'll be thrashing really big arrays. 640K doesn't go far with some problems.

John

Ever do any system programming on Domain/OS from Apollo? While the underlying code was written in Pascal, they supported C development with an elaborate PASCAL-like macro library.

Shudder.

Kelly

Which is when we all change to Linux - or the new Google OS!

The Burroughs B6700 was also Algol 68 - in fact the OS was Algol 68! Second machine I learned on.

There is none. It depends on what you click first.

Yeah, it ran pseudocode, like RSTS/E and PDS Basic and maybe Visual Basic. I knew that.

John

It's approaching a proper table-dispatched state machine, one of the more bulletproof ways to run realtime code.

John

Yes and no. I use such state machines a great deal. (I posted earlier in response to the example, describing it as a "spaghetti sequence". If, however, there were some task-oriented logic to each state, I would see your point.

I'm explaining this badly. It's 5:18am and I need to fall over in a big heap. I'll disentangle my response later ;).

Steve

A computer without a jump instruction ? That would be usable only if the program restarted after executing the whole code address space to the end and the program counter (a simple hardware up-counter) wraps to zero. Of course, every instruction must be conditional, taking the same time regardless it did some actual work or just operated as a NOP instruction on this iteration. Perhaps handy in some DSP or PLC applications, since fSample = fClock / 2^n where n is the number of bits in the program counter.

Paul

Especially the conditional version is handy:

COME FROM Label1, Label2 IF errno 0

This is a very handy way of adding error checks later onto existing programs, without cluttering the normal program execution path :-).

Paul

There is plenty of competition in software, as you say. But it the corporate sector at least the OS and office software market has been dominated by a monopolistic vendor, and people put up with all sorts of abuse because of it. Personally, I haven't uses MS Word since a brief encounter with version 2 (on Win 3.11), but we non-MS Office users are in a minority (albeit growing a lot recently). People *still* buy MS Office, despite Open Office being freely available (or Star Office, for those wanting support and a few extra features), far safer to install, use and upgrade, and directly comparable in normal use. That's the result of monopoly power.

For certain other sectors, such as the EDA market, you have the strange system of having a number of vendors with their own mini-monopolies. The use of proprietary and undocumented file formats means that, say, Protel has a virtual monopoly on the market of Protel users. Newcomers can choose freely according to price, features, support, and so on, but existing users have great difficulty changing vendors because of compatibility problems with existing design files. So these vendors too can get away with selling buggy software and claiming it will be fixed with the next upgrade.

A long time ago I did some PIC assembly programming, and had a header file with things like this:

#define byte res 1 #define IfBit btfsc #define zero status, 2 #define self 1

Then I could write code as:

counter: byte ... foo: IfBit zero incf counter, self return

Considering the raw PIC assembly version is something like:

counter: res 1 ... foo: btfsc 3, 2 incf counter, 1 return

I think the #defines made a big difference to readability - PIC assembly falls into the category of being particularly weird.

C is known as a language that gives you enough rope to shoot yourself in the foot. When used properly, it is legible enough that there is no need to add much extra. Personally, I use a set of macros for bit manipulation - it allows me a consistent efficient interface that works on the wide variety of compilers and assemblers I use. But too much "personalisation" makes the code unreadable to others - and readability is key.

Yes, such things are foolish - trying to make C look like Pascal is like fitting a square peg in a round hole. And trying to use macros for the job is like using a screwdriver for the job, instead of a ready-made sledgehammer like p2c.

To be fair on Bjarne Stroustrup, I think a lot of people have completely misinterpreted what he was trying to do with C++, and how he expected it to be used. I remember reading his book "The C++ Programming Language" fifteen years ago, and thinking how totally different it was from all the other "teach yourself C++" books I'd looked at. As Steve says, good (or bad) design is language independent, but modern C++ gives so much greater scope for writing truly horrendous code than most other languages.