Larkin, Power BASIC cannot be THAT good:

Writing bad software is expensive. Bad hardware, too.

James Arthur

Sorry, trying to do too many things at once. The main problem with LabView is that it hides a lot of ultra-important things about your measurement, e.g. when exactly does the sampling occur? I went round and round with National Instruments on that point, and the best they could tell me was that timing information was a device driver function, and there was no way in general of finding it out from the user interface.

That's when I gave up.

Cheers

Phil Hobbs

You need a shift register, so that it's one iteration per 8 pixels rather than one per pixel. And you still only get 32 columns with a

3.25MHz Z-80 (that's the spec. of the ZX80/81, whose video hardware was an 8-bit shift register, with everything else in software).

If you want "pixels" (as opposed to character-sized blocks) on a PIC, you would realistically need to use a 20MHz clock (Fosc/4 = 5MHz), and use either the USART or SSP as a shift register.

Otherwise, you're stuck with using a whole 8-bit port so that you can shift out the bits with consecutive "rrf PORTC" instructions. And you get gaps due to the instruction required to load the next byte.

Intermediate cells can be used for debug. Cells/sheets are named.

Not true. Excel, at least, shows the come-froms.

You haven't seen spaghetti code. ;-) Try running a fab on a pile of APL routines, like the one just North of you was twentyish years ago.

Checking tables form other databases too.

They're wonderful productivity tools. Just like a hammer, they're dangerous in untrained hands.

The difference being that you can't make money with bad hardware.

We made a couple of user demo things, with the LabView option that creates standalone runnable VIs. The result was umpteen megabytes of CD, full of DLLs and registry mucking and other horrors. Which usually didn't work.

We have a guy in Long Island, the best programmer I know, who does wonderful little Java things for us now. He's always broke, hence always available for projects like this.

John

I don't think the culture, in academia or in business, plans for quality. The big issue that Computer Science should be addressing, the issue where they could actually affect society in a meaningful way, is programming quality.

It's my opinion that high-quality software is on average cheaper to make than buggy software.

Consider an X-Y plot: X axis is programmer experience; Y-axis is bug density. The engineering units are admittedly fuzzy, but go with the concept.

I think the popular languages and culture tend to make the droop down fron the initial start, but then flatten out or even start to curve back up. More experienced programmers go faster and use trickier constructs and the newest tools to keep their bug rate up.

Now consider plotting graphs in different colors for different languages: Fortran, Cobol, C, C++, ADA, Perl, Python, Java. Are we making progress?

John

Yes. And management should be able to force software quality, but usually can't.

John

postgresql-8.1.4.tar.bz2

We did our own materials control software, and track ECOs essentially manually. But we're small... about 5000 different parts, 2e6 pieces, and 660 ECOs in the last 20 years.

John

postgresql-8.1.4.tar.bz2

We're pretty small too. 100 employees, mostly on the business side (sales, marketing, BS), and perhaps 20 or 30 in production. Only seven engineers (two hardware, one mechanical, one layout, and three firmware).

Parts? Never counted them, but it's likely not a lot more than that. Our latest ECO number was something like just over 1000 (A RoHS part substitution on a non-RoHS product - just signed off on it). There is no way the owner would allow the business to be run on a cobbled together program. I'm not sure what we have is any better though. In theory it does all the production stuff (BOM control, deviations, etc.) It doesn't link the purchasing database and that's always an amazement (why on Earth did we buy 15000 audio transformers or 6000 wall warts, that we may never use?).

postgresql-8.1.4.tar.bz2

Our system isn't cobbled together. We designed it to do exactly what we want. It's a joy to drive. I can search for a part by keywords, see the search results, pop into the full inventory list with starting point from any of the search results. I can select a part and see all the assemblies it's used on. I can select a parts list, see total parts cost, highlight any one part, and pop back into the inventory or where-used bit. Every part can, usually does, have an attached folder with datasheets, photos, engineering notes, anything useful we want to know.

The part numbers are very, very logical and organized, as are the description fields.

And it's blindingly fast.

ftp://jjlarkin.lmi.net/MAX.jpg

I'm not sure what we have is any better though. In

That's a separate problem. Somebody probably observed 1) we'll sell tons of these and 2) look how good the 10K price is!

One search param we have is called BigBux: type a dollar value, and it shows all the parts that we have that many dollars or more of. This invokes the occasional WTF?! reaction. It also catches the situations where somebody typoed the price of a reel of resistors as $12 instead of $0.012 each.

John

Hey, I did it back in the mid-'90s with only a 4-bit shift register! :-)

20MHz CPU, though.

These days it is more of a fun "trick" than anything useful, though -- unless you're super cost-constrained, these days a small CPLD makes video almost trivially easy.

You want a real write-only language? Try FORTH.

OVER + SWAP DO

I have done plenty of user RPL programming of HP calculators.

These days, with memory so abundant, I've switched from...

1/x SWAP 1/x + 1/x

...to...

"X*Y/(X+Y)"

Much easier (and a skosh more numerically accurate, although realistically if one isn't using 0.01% resistors, I doubt it matters here).

---Joel

Writing readable programs is probably more important than anything else. Unreadable programs are difficult to maintain and will quickly turn to shit upon subsequent modifications.

I also never use constants like 25480. 24*60*60 is far more readable and less prone to error. It doesn't take a pico second more to execute as the calculation is done at compile time, not run time. Even with an interpreted language, it is only parsed once; if the language system isn't shit, the calculated value will be saved in the saved tokenized code.

postgresql-8.1.4.tar.bz2

Our engineering management tools to everything above. The search isn't linear, though. ;-)

Some of that, but mostly an overly aggressive development schedule. We can't make enough widgets now, so I don't know how the ever expected to sell enough to use the inventory in a reasonable time. Parts sitting on the shelf aren't free, either.

;-) There is a field in the database for projected cost, but it's not linked to the purchasing system so it's rarely filled in. Kinda makes

*engineering* difficult.

I just demanded that they order a reel of AD8566s. For the project I only need about 1K parts but the cut tape price (DigiKey) was over 3X the full reel price (Arrow). ...so I designed out another part since the 8566s were free. ;-)

graphics

minimise

I think not. Browse the manual a bit. You may learn something.

graphics

minimise

Not at all, it has 32-bit signed integers as well.

graphics

minimise

video

images,

Only partially true. 32 bit x-y planes with 24 bit clip regions do many things quite nicely.=20

4 Gpixel by 4 Gpixel is a very large plane, 16 Mpixel by 16 Mpixel is still a lot of pixels to scale down to a 2 kpixel by 1 kpixel display or a 2.4 Mpixel by 3.3 Mpixel printer. Of course if you do not have to send 6.9 Mpixel to the printer, printing may well be faster.