Larkin, Power BASIC cannot be THAT good:

The advantage of Linux is that many, many eyeballs review the code, and the authors know that their code will be seen and criticized in public. That probably encourages them to be more careful. Plus, the code is debugged by many, many people.

Most programmers work on their bit of code alone. Nobody checks their source code but themselves. They don't comment because they figure they will remember their design intent forever, or because they were never taught to document their own code.

What do you mean by "real design"? I do real products in assembly. Most truly mission-critical, lives-depend-on-it programming (like the stuff that flies airplanes) is done in Ada.

BASIC is great for people like engineers who just want to get the computing done, correctly. PRINT USING alone is a good reason to program in BASIC.

Absolutely. PB has all the modern constructs, WHILE, CASE, TRY/CATCH, graphics, all that. But I still think in state machines, and GOTO is a perfectly good way to structure state machines. Nothing flow-charts as nicely as a program based on GOTOs. The anti-GOTO nonsense was started by Dijkstra, who didn't program much himself and didn't have regular access to a computer.

Software should be like hardware: do it the cleanest way, take your time, document it thoroughly, get it right the first pass.

It rarely is. If you consider all the components of a complex system, software is the least reliable, the hardest to manage, the hardest to maintain, the most likely to destroy the company, and usually the most expensive.

John

Reply to
John Larkin
Loading thread data ...

That is why I import projects from others into Eclipse (with CDT). Eclipse gives me a nice list with classes/functions. And Eclipse has an excellent text search function. Very easy while digging into a C/C++ project.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
 Click to see the full signature
Reply to
Nico Coesel

values

Drowning in uncontrolled complexity? Add more automation tools!

John

Reply to
John Larkin

As someone recently said, most programmers are by definition mediocre programmers. They are like beginning drivers with bad eyesight given Formula 1 cars to drive. Of course really good programmers - like the authors of C - can - if they're in the mood - write reliable, secure, bug-free code in C.

Of course. But the language and the culture of C provide too many ways for mere mortals to code junk.

It's interesting that the best programming languages, from an outcomes standpoint, are Cobol and Ada.

Used Adobe Reader, or IE, or Word, or Vista lately? Crap, produced by the best programmers money can buy. Fly on a plane or use an ATM lately? Did you lose your money or your life?

John

Reply to
John Larkin

Right. But this isn't C's fault. You will see more crappy code written in C than in most other languages simply because you will see more code written in C than in most other languages.

If you need to tackle a wide range of programming tasks, you need to know C. There is no other language with such a wide range of applicability (with the caveat that C++ is essentially a superset of C). You don't see OS kernels being written in Ada or Python or BASIC.

And once you know C, you don't really *need* to know anything else. Sure, there are lots of cases where other languages might be more suitable, but C is usually "good enough". But there are plenty of cases where C/C++ is the only language which is good enough.

There are a lot of half-baked programmers whose knowledge of languages started with VB or JavaScript, maybe a couple more languages are learnt for specific tasks, then they learn C and never need to learn another language.

Assembly is a non-starter if you need the code to run on multiple architectures (or if you suspect that it may need to do so in the future). It's also unrealistic for large applications.

That kind of software development is only feasible if you have the kind of customer who pays $2000 for a screwdriver. IOW, the DoD, NASA, ... er just those two, really. Most software development is rather more price-sensitive.

routine.

nice

Dijkstra was right, though; "goto" is the antithesis of structured programming. It's hardly ever used in high-level languages. The main use of "goto" in C is to clean up on errors, which is done using exception handling, constructors, and destructors in C++.

That's because it accounts for 99% of the system. Think about implementing a PC with a dozen substantial applications using dedicated logic rather than a CPU and software. You would be lucky to fit it onto a silicon wafer, and even the DoD wouldn't be able to afford one.

Reply to
Nobody

Catching an error at run-time is too late. Much of the time, the biggest difference between using Java and using C is that the former provides a slightly more verbose error message when it terminates the program and loses all of your work due to an out-of-bounds array access.

In that regard, code written in interpreted languages is often worse than that written in C, as even the most obvious errors can go undetected if the code doesn't get run (error-handling code is a prime target).

Reply to
Nobody

programming,

values

Looking for something to drive a nail in the wall? Get a hammer!

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
 Click to see the full signature
Reply to
Nico Coesel

runtime in C on a 2.4Ghz "intel core2 duo" machine is about

3 seconds. about 2 when multithreaded.

dunno about that, those beasts are maninly focussed on floating point performance, and this is an integer problem.

here's the multithreaded one I used

#include #include #include #include static long S[64000000]; static short A[64000000];

typedef struct argstype { short *a_start; long *s_start; long count; } argstype;

static void *thread_func(void *vptr_args) { argstype *arg=vptr_args; { long *sp=arg->s_start; short *ap=arg->a_start; long x=arg->count; do *sp++ += *ap++; while (--x); } return NULL; } int main(int argc,char **argv) { long y,n; n=10; if(argc>1) n=atoi(argv[1]); for(y=0;y

Reply to
Jasen Betts

seconds on my eeePC.

It looks like it, with -O4 optimisiation on dual-threaded and single-threaded versions both run in 1.9 seconds here.

Reply to
Jasen Betts

On a sunny day (17 May 2009 11:39:34 GMT) it happened Jasen Betts wrote in :

Cray was (maybe still is?) a vector processing hardware platform. With vector processing I mean this:

memory add memory memory address counter

So basically clock from one memory into the next via the adder. That is very very fast for huge data sets that all need the same operation.

I have done some hardware like that :-) No memory has 'float', it is all integers of some size :-)

OK, I tried that, gcc -o test10 test10.c -lpthread but it wont run on the eeePC, it simply says: Killed Looks like 512 MB is not enough :-) And only one core of course. On an other PC with 385964k RAM it starts swapping: ~# nice -n -19 ./test10 nice -n -19 ./test10 19.25s user 0.63s system 99% cpu 20.046 total

Reply to
Jan Panteltje

seconds on my eeePC.

Yes. It is bandwidth limited on the external ram because of the way it hits sequential locations once per loop. Using DDR2 ram execution is roughly 2s and older DDR ram is about 3s in execution. The absolutely dire code generated by debug mode with all optimisation disabled is only

4s. So it isn't really a test of PowerBasics code generation at all.

The real test of an optimising compiler is how well it can exploit cache aware alogrithms with multiple nested loops. A cache aware version of this vector add and accumulate (without using SIMD instructions) is about 15% faster than the simple loop on a good optimising compiler (actually that is measured on MSC I haven't checked its code generation for optimisation - too tedious). I suspect gcc might be better.

The optimisation totally disabled version compiled by MSC is:

for (i = 0; i < ARRAY_SIZE; i++) {

004010BE mov dword ptr [i],0 004010C5 jmp main+0D0h (4010D0h) 004010C7 mov ecx,dword ptr [i] 004010CA add ecx,1 004010CD mov dword ptr [i],ecx 004010D0 cmp dword ptr [i],3D09000h 004010D7 jge main+0F7h (4010F7h) s[i] += a[i]; 004010D9 mov edx,dword ptr [i] 004010DC mov eax,dword ptr [a] 004010DF movsx ecx,word ptr [eax+edx*2] 004010E3 mov edx,dword ptr [i] 004010E6 mov eax,dword ptr [s] 004010E9 add ecx,dword ptr [eax+edx*4] 004010EC mov edx,dword ptr [i] 004010EF mov eax,dword ptr [s] 004010F2 mov dword ptr [eax+edx*4],ecx } 004010F5 jmp main+0C7h (4010C7h)

And takes 4s on P4 3GHz with DDR ram. Optimiser turns it into something like

mov esi, a mov edi, s mov ecx, ARRAY_SIZE xor edx, edx forloop: movsx eax, word ptr[esi+2*edx] add dword ptr[edi+4*edx], eax inc edx loop forloop

And this extremely tight optimised loop code still takes 3s with DDR ram and just under 2s with DDR2 ram.

MSC has changed the way it does this. My oldest compiler generates a pointer implementation for array access whereas newer compilers exploit the additional scaled indexing features of later CPUs. The oldest compiler generates very slightly faster code for the loop (at least it does after a manual reordering of the generated instructions).

forloop: movsx eax,word ptr[esi] add esi, 2 add dword ptr[edi], eax add edi, 4 loop forloop

Code snippets above subject to typos. Be interested to see what code gcc -O4 generates.

Regards, Martin Brown

Reply to
Martin Brown

I do all my programming in C++ for things that I need to be fast, and REXX for other stuff. Coding in REXX is about 10x faster. I wouldn't touch BASIC with a barge pole nowadays, though I used to love HP Basic (for the 9816), mainly for its beautiful GPIB integration. I'd still write instrument code that way if I could--but I'd do the fancy stuff in C++.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal
 Click to see the full signature
Reply to
Phil Hobbs

if

routine.

nice

It isn't GOTO that's horrible, it's named labels. Every time I come across a named label in code, I have to go figure out every single place in the code where the jump could have originated. Ugly ugly ugly. For a state machine, it would be very unlikely to come from more than 100 lines away, which is barely acceptable. A switch statement in a while(1) loop [or for(;;), which is more idiomatic] is the way to go for state machines. That way you know where the code begins and ends, and the machine code is equivalent.

There was a joke article many moons ago proposing a COMEFROM statement, which would silently put a jump anywhere you liked--not very different from a named label!

Cheers

Phil Hobbs

Reply to
Phil Hobbs

On a sunny day (Tue, 19 May 2009 18:16:53 -0400) it happened Phil Hobbs wrote in :

C++ is no language, but a speech disability. Only idiots use C++.

Reply to
Jan Panteltje

Gee, Jan, for a neural net you sure have a lot of strong opinions. ;)

Cheers

Phil

--
Dr Philip C D Hobbs
Principal
 Click to see the full signature
Reply to
Phil Hobbs

if

in

routine.

nice

Subroutines have the same horrible problem: they have names, and can be called from all over the place.

John

Reply to
John Larkin

You don't need a $2000 carbon fiber fishing pole to catch fish. You just need to know how to fish.

John

Reply to
John Larkin

many if

in

routine.

me nice

It isn't the same, though--the routine has a well-defined beginning and end, and unless the coder is a moron, it does some well-defined thing that is at least vaguely suggested by its name. Also cross-referencing tools (e.g. docxx) do a great job of showing you the program flow.

Cheers

Phil Hobbs

Reply to
Phil Hobbs

On a sunny day (Tue, 19 May 2009 15:33:25 -0700) it happened John Larkin wrote in :

Yup, Yogi Bear does it by hand :-)

Reply to
Jan Panteltje

On a sunny day (Tue, 19 May 2009 18:28:53 -0400) it happened Phil Hobbs wrote in :

It comes from experience (they call that training the net). I was sort of asked to read Stroustrup's book in one job. It became clear to me after a few pages that he did not know how to program, and tried to 'fix' that by inventing a new language (or rather cluttering C with nonsense). This person is responsible, among other things, for the mess MS has made:

formatting link

Even C++ compiler writers could at one point no longer agree what it was about :-) In my view you must be complete idiot if you invent 'operator overloading', and write needlessly long things with :: in between.

But ... as with many things, many went for it, many cannot do anything else. Maybe my strong opinion comes from the fact that I started with hardware, then BASIC, then asm...., and then finally C. A bit of php too, nice for websites. Never ever needed the ++ in C for anything, never.

Reply to
Jan Panteltje

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.