Larkin, Power BASIC cannot be THAT good:

Yes, libraries. That's how QB did it- your program is linked (real-time, in the interpreter, or by LINK at compile time) with the library that does everything.

BCOM45.LIB 215 KB (220,919 bytes)

BCOM45, BQLB45 and BRUN45 are the three built in libraries for whatever.

Sadly, because LINK is a library level linker, not a module level linker, a simple Hello World program takes 35kB or so. Come to think of it, a Win32 console app compiled in Watcom C takes about that much, too.

YMMV. I don't know how modern BASIC compilers do it. I know generic structures are converted to efficient assembly rather than procedure calls (almost everything in QuickBasic is a CALL, *shudder*!). I would guess the power statements (like, just how much Win32 crap is rolled up into a simple SCREEN 12?) are still compiled in a similar way, although where the 'librariness' shows up may be hidden (my copy of FreeBASIC shows a couple moderately sized executables under /bin, they might have code built in).

Tim

Oh, just checked. PB has data pointers, function pointers, and can call DLLs and system stuff. Not that I would often want to do any of that. It also has threads and nice thread management tools, which look easy to use and might be interesting in some situations.

It does have native string variables, tons of neat string functions, and PRINT USING. Print Using is reason enough to program in PB all by itself.

John

Qb compiled to pseudocode, and (I think) every "compiled" program dragged all of the runtime system with it.

Sure, most modern compilers have the equivalent of compile-time library linking. But PB has it all in one place, under the hood, not a zillion header and include files. At user level, most operations are language inherents, not sub or API calls. Hit F1 for good HELP, including examples, of anything it can do. It's an ideal programming language for engineers who occasionally have to program. It lets you do most anything.

C is 37 years old, and was archaic even by 1972 standards.

John

And BASIC? Want to talk about archaic? A language that doesn't have structured datatypes, doesn't have block statements, can't call subprograms, can't pass parameters to subroutines can is only good for nasty horrible spaghetti code unless you use some proprietary extensions that haven't a prayer of ever working on any other system?

At least programs written in C are transportable. All BASIC is good for is throaway code.

Several vendors' BASICs do all the things you named.

The thing about Basic is that it's not frozen in time like C is. Modern Basics can and do do all that stuff: structs, CASE, WHILE, TRY, THREAD, formal subs, and great inherents like strings and graphics and SORT. PB has great IDE stuff like execution trace, speed profiling, variable watch, single-step, how-did-we-get-here.

Sure. Just spend a pleasant afternoon porting a .NET app to Linux or Apple, or an embedded 8051 program to ARM. Even the meaning of 'int' is ambiguous. And aren't they re-doing .NET right now?

I haven't thrown away any of my engineering apps. I must have spun $100 million worth of sales by now based on Basic engineering apps; I'm sure not going to throw the money away.

How many Windows 3.1 apps still run under Vista or Linux? All my old PB/Dos .EXE programs still run under XP, even the graphics.

You seem to be saying that what you are doing now is not only portable, it always will be, which is absurd. I am saying that I get engineering done in Basic, and it works, which is true.

John

Another package which I work on has ~2500 C files, 60 C++ files, 160 Python files and 550 Makefiles, resulting in 350 executables and 50 libraries. And that's not all that large; the numbers are inflated by virtue of it being composed of many small modules.

Okay, so this isn't "embedded" software, or even "system" software. But the Linux kernel is both of those, and is far bigger (10,000 C files, 1000 assembler files, although not all files will be used on any particular architecture).

At that level, things like structure, abstraction, and the development process matter a lot. You can't rely upon programmers understanding the whole thing, or no-one ever making a mistake (particularly when so much of it is for hardware which is inadequately or inaccurately documented). And testing doesn't help much when much of the bug potential is related to concurrency.

Not at all. You would have just as many problems converting Fortran, Basic or Cobol to each other or to C, C++ or Java. IOW, the claim of "only need to refactor some keywords" is bogus.

And I'd guess that most of it is incompatible with other Basics, and not related to any formal standard.

C has most of this in the standard, so you can use the same code with gcc, icc, msvc, ...

Thank you, Lord, that I was born a humble circuit designer.

John

And that matters?

Why on earth would I want to do that? I'm an electronics designer.

John

For throwawayh code, not one bit.

I never throw code away. I run .EXEs that I compiled 15 years ago. They still give the right answers. How many Win 3.1 apps are still useful? What's the lifetime of a Linux driver? How often are significant (ie, painful) changes made to .NET?

You're just expressing irrational, emotional prejudices for an ancient, messy, chaotic language. I'm just designing electronics.

How many bits wide is an 'int' anyhow?

John

subprograms,

How many bits are in a byte? ;-)

subprograms,

That's the only one that people usually agree on.

PowerBasic has bytes, words (u16), ints (s16), dwords (u32), longs (s32), quadints (s64), single floats, double floats, extended (80 bit) floats, currency, extended currency, and variants.

And variable-length strings, fixed-length strings, asciz strings, field strings, and pointers. And a BIT type that can actually be 1 to

And a lot of spiffy operators.

See what you can do with a language that's not frozen in time by a bunch of dogmatic committees? Imagine if we still had to use 7400 logic and uA709 opamps to design everything.

John

It matters if you need to make the code run on a given platform, rather than being forced to choose the platform according to what the code runs on.

In the few months I've been reading this group, I've seen several posts regarding the need to maintain legacy PCs because of code which won't run on current systems.

I take it that you're not using PowerBasic to write embedded software?

Because you can use C for that (although using it on an 8-bit CPU is pushing it).

With even a little bit of care, you can write code which will work on anything from a cellphone to a mainframe. With more care you can get it to work on an 8-bit microcontroller or soft CPU core.

Not all electronic engineering is at the level of gates and latches. An increasing amount of hardware is designed to communicate with PCs, and the protocols aren't getting any simpler. The line between electronic devices and computers is getting ever more blurred; TVs and video recorders have already got to the point of requiring an OS; another decade or two and anything with a plug on it will have one.

No, we'd never use Windows in an embedded system. But we do use PB for engineering apps, to run test racks, and our company material control system is written in PB.

But we make scientific and aerospace instruments. Real electronics. And once a product is designed, we don't port it to another platform. We sell it and design something else. Our products are analog-centric; FPGAs and uPs and embedded code just push the data around.

This isn't just gates and latches:

I did the hardware and firmware for this. The firmware is 68K assembly; it parses and executes almost 400 distinct serial commands. I wrote some PB programs to help generate some of the assembly source, like waveform tables. I did the rom builder utility, a linker of sorts, in PB too... easy. The test/cal program is PB too. There's also a "virtual instrument" thing we did in Java, which is truly platform independent; well, the same executable works on Windows and Linux after some pounding.

An

We have a bunch of Ethernet-enabled products. One system going together now has Linux on a mini-ITX board buried inside. That will be programmed in C, and not by me. It did take a month to get one Linux driver (furnished by the chip vendor and claimed correct) to work... more time than I usually spend on an entire firmware project. And that's just one driver. It involved recompiling the Linux kernel, of course. Something about different device driver models between 2.1.4.1 and 2.1.4.2 or some such nonsense. So much for portability.

John

Well sure, but just resizing the file system saves time and effort compared to restoring backups.

On a sunny day (Sat, 20 Jun 2009 20:07:18 -0700) it happened John Larkin wrote in :

Imagine if every ua709 had a different pinout.

On a sunny day (Sat, 20 Jun 2009 21:46:23 -0500) it happened krw wrote in :

More interesting, and more philosphical: How many somethings go into a bit?

Bits are not really yes / no , true / false, there is a shady area in between ;-) That is where the mystery of logic could hide ;-)

subprograms,

...and people are usually wrong. ;-)

Slowman might even be able to get a job.