Re: Larkin, Power BASIC cannot be THAT good:

On Sat, 20 Jun 2009 08:43:46 -0700, John Larkin wrote:

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.

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.

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.


.

Relevant Pages

  • Re: #include question
    ... > (translation units as I found them called in Bjarne Stroustrup's book). ... > I know about multiple inclusion guards, ... Correctly written headers, which includes standard ones and should ... classes and structs do nothing until a source file instantiates them ...
    (alt.comp.lang.learn.c-cpp)
  • Re: Subroutine header
    ... I used to write headers like those, these days I lean more on my ... compilation and linking details. ... build for production release I (in line with site standards) strip out ... this unsuitable for source file headers anyway. ...
    (comp.lang.fortran)
  • Header include order
    ... - include system headers ... include application headers ... include the header associated with this source file ... Does anyone have a reasonable justification for the standard include ...
    (comp.lang.c)
  • Re: java 101 question - how to run a java program
    ... Go back and rename the source file from .class to .java, then STRQSH, cd /home/srichter/java, and do "javac java01.java". ... After you've corrected your source error (need to call the class "java01" if it's in file "java01.java"), you will end up with a ..class file in the same directory as the .java file. ... After the compile the /home/srichter/java ...
    (comp.sys.ibm.as400.misc)
  • Re: #include "string.h"
    ... since any program does use some standard headers anyway. ... if you put string.h into the folder next to the source file, ... more than what it's talked about in 7.1.2p1 (or the intent for it ...
    (comp.std.c)