Larkin, Power BASIC cannot be THAT good:

[Nobody]

For some of them, sure... but 25MB in LISP!? Just to print "hello, world!?"
C'mon... Even Pascal, at 107k -- more than 10x what C requires -- is pretty
embarassing.

At that size, my guess is that it's a frozen memory image, containing the
interpreter, the program, the data, and a lot of free space which was
pre-emptively requested from the OS but isn't actually being used for
anything.

 

[krw]

And you can order one, and have it handed to you on a tray with a
Coke, faster than Windows will start up.

Maybe not always:

http://cbs4denver.com/investigates/denver.police.suspension.2.1049330.html

 

[James Arthur]

grml: ~ # resize_reiserfs -s 600G /dev/sda8
resize_reiserfs 3.6.19 (2003 www.namesys.com)

From wiki:
ReiserFS was the default file system in Novell's SUSE Linux Enterprise
until Novell decided to move to ext3 on October 12, 2006 for future
releases. [1] Although the change was rumored to be a result of
principal author Hans Reiser being charged with the murder of his wife
(he was later convicted[2] ) two days earlier, SUSE stated that the
timing of the announcement was coincidental and unrelated.[3]

John

Well, first I managed to get the reiserfs working again...
second I do not give a lot about what side of the bars 'murderers'
are on as long as GWBush, he who murdered a million innocent Iraqis,

A million? I thought it was more like 100,000 lost since the war
started, mostly killed by other Iraqis.

Here, from an anti-war outfit:
http://www.iraqbodycount.org/

 

[Tim Williams]

No two versions of BASIC, even from the same company are compatible.
At one point, microsoft even made visual basic incompatible with it's
last major release. BASIC is only good for throwaway code. Write it;
run it; toss it. Toss anything you learn too.

So what's your obsession over throwaway code, anyway? The whole premise of
"portable code" is silly to begin with. Yes, C _can_ be written to compile
on, say, different compilers and different OSs, but that's just /hiding/ the
throwaway bits inside #defines. That's worse than maintaining individual
copies of the same source, written specifically for their intended
compiler-OS combination, because you have to wade through #ifs, #defines and
..h's to find out what the hell is going on. In seperate copies, everything
is *there* to see, plain and simple. Between copies, the structure is
(presumably) identical, differing only in those key places which would
otherwise be #defined, so it's no harder to compare them.

By the way, I've had excellent success with the small list of programs I've
maintained between QuickBasic and FreeBASIC -qb. There are only small
differences; much of the code is directly useful. All the old stuff still
works; for instance, you automatically get a text console, and you can open
windowed graphics in a single statement.

Finally, since code always has to be rewritten to reuse it anyway, what
difference does it make what language it's in before you rewrite it? From C
to C, or C++, or Java, or to many of the other braces type languages, you
might only need to refactor some keywords to make it fit. But when you have
to rewrite the whole damn thing, it doesn't make much difference what
language it's in -- BASIC, C, Java, etc. all share the same imperative
program flow structure, and share much of the same syntax and control
statements. The program structure and algorithm flowcharts are identical.
Converting BASIC to C is very simple; the standard libraries for both are
even fairly similar (too bad BASIC has more powerful libraries!).

Tim

 

[Nobody]

So what's your obsession over throwaway code, anyway? The whole premise of
"portable code" is silly to begin with. Yes, C _can_ be written to compile
on, say, different compilers and different OSs, but that's just /hiding/ the
throwaway bits inside #defines. That's worse than maintaining individual
copies of the same source, written specifically for their intended
compiler-OS combination, because you have to wade through #ifs, #defines and
.h's to find out what the hell is going on. In seperate copies, everything
is *there* to see, plain and simple. Between copies, the structure is
(presumably) identical, differing only in those key places which would
otherwise be #defined, so it's no harder to compare them.

You have a lot of misconceptions about what portable code looks like. I
regularly write code which works on Windows, MacOSX (x86 & PPC), Linux and
Solaris, and the code very rarely uses macros.

Dealing with architectural differences is mostly an issue of not making
any assumptions about widths of primitive types, byte-order, padding, etc.
Stick to what's valid according to the language rather than "this compiler
on this CPU behaves like this".

For dealing with API differences, I'll just write Unix and Windows
versions of key functions, with the different versions in different source
files.

For the project which is in front of me right now, out of 53 C
source files (not including headers), 2 are Unix-specific, 2 are
Windows-specific, the other 49 are portable. There are precisely 6
#if[def] directives in the entire code (mostly for platform-specific
headers), and no platform-specific macros.

Finally, since code always has to be rewritten to reuse it anyway,

It doesn't. It might have to be modified, but that's not the same as
rewritten.

what
difference does it make what language it's in before you rewrite it? From C
to C, or C++, or Java, or to many of the other braces type languages, you
might only need to refactor some keywords to make it fit.

Or you might (and probably will) need to completely rewrite it. C doesn't
have classes, Java doesn't have pointers, or half of C++'s OO features, or
many of the libraries available to C/C++ code. C and C++ don't have
garbage collection.

But when you have
to rewrite the whole damn thing, it doesn't make much difference what
language it's in -- BASIC, C, Java, etc. all share the same imperative
program flow structure, and share much of the same syntax and control
statements. The program structure and algorithm flowcharts are identical.
Converting BASIC to C is very simple; the standard libraries for both are
even fairly similar (too bad BASIC has more powerful libraries!).

Except that most BASICs are even more primitive than C: not only no OO,
but no structures, unions, pointers, function pointers, dynamic
allocation, threads, ...

If you're used to BASIC, you won't miss these things, but your code
will typically be full of hacks and workarounds (although it won't seem
this way until you've programmed in a language with more structure).

 

[James Arthur]

John Larkin wrote:
From wiki:
ReiserFS was the default file system in Novell's SUSE Linux Enterprise
until Novell decided to move to ext3 on October 12, 2006 for future
releases. [1] Although the change was rumored to be a result of
principal author Hans Reiser being charged with the murder of his wife
(he was later convicted[2] ) two days earlier, SUSE stated that the
timing of the announcement was coincidental and unrelated.[3]

John
Well, first I managed to get the reiserfs working again...
second I do not give a lot about what side of the bars 'murderers'
are on as long as GWBush, he who murdered a million innocent Iraqis,

A million? I thought it was more like 100,000 lost since the war
started, mostly killed by other Iraqis.

Clarification: 100k civilians killed, the great majority of whom were
from Iraqi-Iraqi violence--Sunnis killing Shia & vice versa--not from
US military operations.

So, 1 million is off by more than 20:1.

SH killed over 2 million in his roughly 20-year career, about 100K per
year. About a million alone in the war with Iran.

John

Ah, but how many jobs did he create or save, and did he author a nifty
filesystem?

 

[Tim Williams]

I have some nice key bindings on that eeePC, ctrl Alt C sets up the
network
connection, ctrl Alt O starts Opera web browser, ctrl Alt T starts an
xterm,
etc.
So much faster then rubbing a pad, clicking icons, and working through
menus .
ctrl Alt U starts the Usenet news reader.

I have Windows+I set to open Firefox and Windows+O to open my mail/news
reader (gasp, OE!).

Tim

 

[Tim Williams]

Libraries? Why use libraries, when any decent language has all the
features you need built in? Would you buy a cheap car and add
after-market power steering and automatic transmission and air
conditioning?

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

 

[Nobody]

For the project which is in front of me right now, out of 53 C
source files (not including headers), 2 are Unix-specific, 2 are
Windows-specific, the other 49 are portable. There are precisely 6
#if[def] directives in the entire code (mostly for platform-specific
headers), and no platform-specific macros.

53?! All the programs I've done in the last few years have each had
one source file. The only exception is embedded things that have one
uP code source file and one to four FPGA configuration files, which
all get built into one rom image file.

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.

So the only languages that allow 40-year old programs to be simply
tweaked to compile and run on modern OSs are Fortran, Basic, and Cobol.

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.

 

[Nobody]

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.

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, ...

 

[krw]

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?

How many bits are in a byte? ;-)

 

[Nobody]

And that matters?

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.

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

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.

 

[Anssi Saari]

Oh. I'd have just verified that I have everything backed up, and used
fdisk.

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

 

[krw]

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

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

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
31 bits. And TYPES, which are mixed-type structures.

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.

Slowman might even be able to get a job.

 

[krw]

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 ;-)

Wrong. A bit is a contraction of "binary digit". It, by definition,
can only have two states.

 

[John Devereux]

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?

An "int" is guaranteed by the language to be at least 16 bits wide. (A
"long" is guaranteed to be at least 32 bits wide).

If you want exact widths you can use the (C99) types

int16_t
int32_t

Or the unsigned versions

uint16_t, uint32_t

Etc.

 

[Bob Larter]

Hey! Don't knock Mac's! They're good, nutritious food, and tasty, too!

You poor bastard...

 

[Bob Larter]

WRONG! They are both stack oriented languages but that is the limit
of their similarity.

Bullshit. Pick any standard FORTH command - it works under PS.

 

[Bob Larter]

Not for simple arithmetic, but it starts to get awkward if you're writing
a non-trivial piece of software.

It's probably not so bad if you use either PostScript or Forth day in, day
out, but I find that I end up having to put a comment describing the
current stack contents between every line of code. That, and having every
non-trivial function store its arguments in a dictionary so that I can
reference them by name.

It's not a problem if you're used to doing things the FORTH way. The
trick is to build low level functions into words, test them thoroughly,
then put them together to make your app. If you're used to languages
like C, it's true that it's a difficult hurdle to jump.

 

[Bob Larter]

For some of them, sure... but 25MB in LISP!? Just to print "hello, world!?"
C'mon... Even Pascal, at 107k -- more than 10x what C requires -- is pretty
embarassing.

Well, now you know why nobody writes apps in LISP. ;^)