SiriusHardware
Posts: 502
Joined: Thu Aug 02, 2012 9:09 pm
Location: UK

Re: BASIC - more harmful than useful?

Thu Oct 10, 2013 10:43 pm

DavidS wrote:
Languages that are not BASIC and should be avoided by BASIC Programers include:
VB, BBC BASIC Windows, BRANDY BASIC, GAME BASIC, etc.

Again just my opinion. I feel that the attempts to oversimplify BASIC and in some cases add some OO style constructs have thus far been a complete failure. I want to be able to program without the language getting in the way.
Interesting that you included Visual Basic. I used BASIC all the way up to and including QB45 to write all my workaday PC utilities, but when VB came along I couldn't afford it so I suffered years of PC BASIC famine, until I finally noticed that a 'lite' free version (VB Express) had been made available by Microsoft. I installed it with great anticipation, then discovered that it bore no resemblance at all to anything that I would have described as BASIC. I honestly did not have a clue where to start. I did eventually find a good 'How To' guide for complete VB novices like me ('Programming - a beginner's Guide' by Richard Mansfield) but even he could not entirely conceal his distaste for the way the IDE / interface had been put together.

Anyway - now we have Python, which is almost as friendly as old-style BASIC - close enough to keep old dinosaurs like me happy, at any rate.

User avatar
jojopi
Posts: 3085
Joined: Tue Oct 11, 2011 8:38 pm

Re: BASIC - more harmful than useful?

Thu Oct 10, 2013 10:54 pm

DavidS wrote:I think the fact that C encourages the use of goto more than a modern BASIC is a problem with C. Though that is just my opinion.
C has while and do…while, as well as for(;;). You have not demonstrated that it is a fact that C encourages the use of goto, so your opinion on whether it is a problem seems premature.
Languages that are not BASIC and should be avoided by BASIC Programers include:
VB, BBC BASIC Windows, BRANDY BASIC, GAME BASIC, etc.
Why do you like BBC BASIC V, and not BBC BASIC for Windows, when they are largely compatible?

User avatar
rurwin
Forum Moderator
Forum Moderator
Posts: 4258
Joined: Mon Jan 09, 2012 3:16 pm
Contact: Website

Re: BASIC - more harmful than useful?

Thu Oct 10, 2013 11:18 pm

I haven't written, or seen, a GOTO in C code for twenty years.

GOTO can be a good paradigm. However, it isn't usually, and any time it seems like a good idea it is usually a better idea to reconstruct the code to avoid it.
Ninty nine times out of a hundred, it is better to write code for maintainability than for efficiency. GOTO can help in very rare cases where the efficient block structuring makes the code harder to understand.

In my experience it was always necessary in BBC BASIC, but it is always possible to write C to avoid it. Almost certainly, modern BASICs with true block structured IFs don't need it either.

Multiple RETURN statements in a function are hidden GOTOs. Programmers who avoid GOTO like the plague, think nothing of having multiple RETURNs. Both should be avoided except where doing so makes the code harder to understand or more prone to error. For example they can avoid duplicating code.

Code: Select all

def fib (x)
    if x < 2:
        return 1
    else:
        return fib(x-1) + fib(x-2)
As against:

Code: Select all

def fib (x)
    if x < 2:
        r = 1
    else:
        r = fib(x-1) + fib(x-2)
    return r

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: BASIC - more harmful than useful?

Fri Oct 11, 2013 12:45 am

jojopi wrote:
DavidS wrote:I think the fact that C encourages the use of goto more than a modern BASIC is a problem with C. Though that is just my opinion.
C has while and do…while, as well as for(;;). You have not demonstrated that it is a fact that C encourages the use of goto, so your opinion on whether it is a problem seems premature.
Maybe so. Though beings that until recently there were a large number of goto statements in the Linux kernel, and I think there still may be a few, I am not sure.

Though as stated this is my personal opinion, yours may very.
Languages that are not BASIC and should be avoided by BASIC Programers include:
VB, BBC BASIC Windows, BRANDY BASIC, GAME BASIC, etc.
Why do you like BBC BASIC V, and not BBC BASIC for Windows, when they are largely compatible?
BBC BASIC for windows is a good language as long as the extra crud that has been added is avoided. The problem is it becomes difficult to use the GUI with out using the slow down crud.

Also last time I checked BBC BASIC for Windows does not have a built in assembler. And I never could get inderection of an absolute adress to work correctly in BBC BASIC for windows.

In RISC OS with BBC BASIC V (the only widely distrubuted OS with BBC BASIC V available), directly calling the OS to do things like Window management is a simple task. For me it is easier than doing the equilivelent in any BASIC that provides windowing functions. I do not even bother with the WIMP BASIC library on RISC OS for this reason.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: BASIC - more harmful than useful?

Fri Oct 11, 2013 1:00 am

rurwin wrote:I haven't written, or seen, a GOTO in C code for twenty years.
Look at the Linux source code. At least up till version 2.6, possibly still there. That is with in the last ten years.

GOTO can be a good paradigm. However, it isn't usually, and any time it seems like a good idea it is usually a better idea to reconstruct the code to avoid it.
Ninty nine times out of a hundred, it is better to write code for maintainability than for efficiency. GOTO can help in very rare cases where the efficient block structuring makes the code harder to understand.
Agreed. It is just rarely of good use, and to often missused. Now if only C and BASIC supported multiple entry points to procedures :) . Oh well that is part of why we have Assembly.
In my experience it was always necessary in BBC BASIC, but it is always possible to write C to avoid it. Almost certainly, modern BASICs with true block structured IFs don't need it either.
Not sure what version of BBC BASIC you were using (an older 8-bit version perhape?):
Though I have never used a single GOTO in BBC BASIC V.

And I have only rarely seen code by others that does.

BBC BASIC V is the version of BBC BASIC that is part of RISC OS, and it supports all of the control statements that C does, as well as procedures, and functions.

Not to mention that !ABC still does a good job of compiling BBC BASIC.
Multiple RETURN statements in a function are hidden GOTOs. Programmers who avoid GOTO like the plague, think nothing of having multiple RETURNs. Both should be avoided except where doing so makes the code harder to understand or more prone to error. For example they can avoid duplicating code.

Code: Select all

def fib (x)
    if x < 2:
        return 1
    else:
        return fib(x-1) + fib(x-2)
As against:

Code: Select all

def fib (x)
    if x < 2:
        r = 1
    else:
        r = fib(x-1) + fib(x-2)
    return r
[/quote]
Well I would not go that far. While a return is a transfer of control, so is a function call. Niether of these is strictly a goto, though a function call is closer to a goto than a return and your examples both use multiple function calls.

Though only in that with a function call you specify the target of the branch, where with a return the return address is in lr (with the previous being linked back through the stack). So realy a return in C is equilivelent to a RETURN in BASIC. And a function call in C is equilivent to a Function or Procedure call in BASIC.


I am guessing that the last time that you used BBC BASIC was on a 6502 based 8bit computer. Is this accurate?

You realy should try BBC BASIC V, it is a modern language.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

DaveW75
Posts: 19
Joined: Fri Oct 11, 2013 1:50 am

Re: BASIC - more harmful than useful?

Fri Oct 11, 2013 2:15 am

rurwin wrote:In my experience it was always necessary in BBC BASIC, but it is always possible to write C to avoid it. Almost certainly, modern BASICs with true block structured IFs don't need it either.
Perhaps the use of GOTO was *sometimes* necessary with old 8-bit versions of BBC BASIC (for example, BBC BASIC II on the BBC Micro), but certainly not since ARM BBC BASIC V came out in the late 80s which allowed for much more structured programming (multi-line IF...THEN...ELSE statements, CASE...ENDCASE structures, WHILE...ENDWHILE, etc.). BBC BASIC has always provided for functions (FNs) and procedures/subroutines (PROCs), so even with the earliest versions of BBC BASIC, I think GOTO was nearly always avoidable. I've been programming in BBC BASIC since around 1987, and I've barely used GOTO since 1992 (even if I have used it occasionally out of sheer laziness, it's always avoidable!).

DaveW75
Posts: 19
Joined: Fri Oct 11, 2013 1:50 am

Re: BASIC - more harmful than useful?

Fri Oct 11, 2013 3:14 am

DavidS wrote:BBC BASIC for windows is a good language as long as the extra crud that has been added is avoided. The problem is it becomes difficult to use the GUI with out using the slow down crud.
Long-time user of BBC BASIC for Windows here. What precisely is this "crud" you're referring to? Would it include Richard Russell's extremely welcome introduction of structures to BBC BASIC (for Windows)? If so, then you're quite mistaken. I'm sure that if you were to ask the majority of experienced BBfW users their opinion on structures, they'd say that they couldn't live without them! They do make life so much easier. I've used them in practically every BBfW program I've written since they were introduced to BBC BASIC.
DavidS wrote:Also last time I checked BBC BASIC for Windows does not have a built in assembler.
Not correct. BBfW has *always* had a built-in assembler (I've written games and other stuff with it):

Code: Select all

REM Example using BBC BASIC for Windows' built-in assembler:
DIM code% 511
FOR pass% = 0 TO 2 STEP 2
  P% = code%
  [OPT pass%
    MOV EAX, 12345678
    RET
  ]
NEXT pass%
PRINT USR( code% )

David.

User avatar
jojopi
Posts: 3085
Joined: Tue Oct 11, 2011 8:38 pm

Re: BASIC - more harmful than useful?

Fri Oct 11, 2013 3:37 am

DavidS wrote:Though beings that until recently there were a large number of goto statements in the Linux kernel, and I think there still may be a few, I am not sure.
There are gotos in the Linux kernel, and you could perhaps argue that some of them are due to deficiencies in C, such as the lack of exception handling. But your anecdotes do not really support the claim that C encourages goto more than modern BASIC does.
Also last time I checked BBC BASIC for Windows does not have a built in assembler. And I never could get inderection of an absolute adress to work correctly in BBC BASIC for windows.
It certainly does have a built-in (x86-32) assembler.
BBC BASIC V is the version of BBC BASIC that is part of RISC OS, and it supports all of the control statements that C does, as well as procedures, and functions.
BBC BASIC V does not have all the control statements that C does. Most significantly, it lacks equivalents of break¹ and continue. Admittedly these are hidden gotos, but they are therefore very useful to avoid actual gotos.

Because of the way BBC BASIC implements loops on a stack, you can not safely jump in or out of one. In that sense, maybe it discourages goto more than C does, simply by having a goto that does not work properly.

¹ BBC BASIC for Windows 5.6+ has EXIT FOR/REPEAT/WHILE.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 23688
Joined: Sat Jul 30, 2011 7:41 pm

Re: BASIC - more harmful than useful?

Fri Oct 11, 2013 8:17 am

I don't have a problem with goto in C in the right circumstances - which is usually handling error conditions to avoid nasty spaghetti code. In most circumstances there are better alternatives.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

Steve Drain
Posts: 105
Joined: Tue Oct 30, 2012 2:08 pm
Location: Exeter UK

Re: BASIC - more harmful than useful?

Fri Oct 11, 2013 10:10 am

jojopi wrote: Because of the way BBC BASIC implements loops on a stack, you can not safely jump in or out of one. In that sense, maybe it discourages goto more than C does, simply by having a goto that does not work properly.
¹ BBC BASIC for Windows 5.6+ has EXIT FOR/REPEAT/WHILE.
I am not going to engage with DavidS, because he is saying some very strange things about various versions of BBC BASIC that I, too, am very familiar with.

You are right that there is no built-in exit from loops, but you can contrive one fairly simply by putting the loop in a procedure and using ENDPROC as an exit keyword. This clears the stack of all the loop parameters. For many years I have been supplementing BBC BASIC V with my Basalt (BASIC Alternative Keywords) module. One of my early addtions was an EXIT keyword, but it is not as flexible as that in BB4W.

User avatar
rurwin
Forum Moderator
Forum Moderator
Posts: 4258
Joined: Mon Jan 09, 2012 3:16 pm
Contact: Website

Re: BASIC - more harmful than useful?

Fri Oct 11, 2013 10:28 am

DavidS wrote:Well I would not go that far. While a return is a transfer of control, so is a function call. Niether of these is strictly a goto, though a function call is closer to a goto than a return and your examples both use multiple function calls.

Though only in that with a function call you specify the target of the branch, where with a return the return address is in lr (with the previous being linked back through the stack). So realy a return in C is equilivelent to a RETURN in BASIC. And a function call in C is equilivent to a Function or Procedure call in BASIC.
A RETURN is not just a RET assembler instruction. Generally it has to unwind the stack-frame, and it may have to destroy local objects. In many architectures that is multiple assembler instructions, albeit handled by the compiler. But that is just a special case of the more general condition.

Consider a procedure that allocates several large chunks of memory in multiple places, maybe grabs a semaphore or two along the way, and also calls various other procedures which may fail. At various points in the procedure, you need to exit with an error indication or otherwise. However at each exit point, you need to free any of those memory chunks that have been allocated and unlock any semaphores that have been acquired.

You could use multiple RETURN instructions, but every time you do so, you need to check which clean-up operations need to be done, and which semaphores need to be freed. Modifying the code requires great care to keep all of those clean-up sections up-to-date. Failure to do so correctly may not be noticed except for a memory leak or hang that only occurs very infrequently.

Or you could use GOTOs instead of RETURNs and put this at the bottom of the function:

Code: Select all

Exit:
    if memory_chunk_1 != Nil:
        free(memory_chunk_1)
    if memory_chunk_2 != Nil:
        free(memory_chunk_2)
    if got_semaphore_1:
        unlock(semaphore_1)
    if got_semaphore_2:
        unlock(semaphore_2)
    return return_value
I am guessing that the last time that you used BBC BASIC was on a 6502 based 8bit computer. Is this accurate?
Actually it was a 65C102 ;-) I did say I expected modern BASICs would be better.

tufty
Posts: 1456
Joined: Sun Sep 11, 2011 2:32 pm

Re: BASIC - more harmful than useful?

Fri Oct 11, 2013 11:41 am

rurwin wrote:However at each exit point, you need to free any of those memory chunks that have been allocated
Only if you're working with one of those backward languages that require you to deal with the trivia of memory allocation and (above all) deallocation. Garbage collection, automatic or otherwise, goes a long way to making for safer programming practices. Obviously, though, new technologies like that take some time to catch on*.

Exception handling is similar - it is, in fact, far from exceptional, and yet languages either pretend it doesn't exist, or pay lip service to it. C makes it significantly harder to write correct exception handlers than incorrect ones, so most people say "fsck it" and don't bother at all. And despite what the BASIC fanatics will have you believe, no, ON ERROR GO(SUB|TO), although slightly better, doesn't cut it either (it's merely syntactic sugar over C's approach, in fact). Like GC, exception handling is a well known and largely solved problem, but most implementations are way below par.

* Let's be honest with ourselves, GC's only been in use since the 1960s, so let's cut those language designers some slack, eh?

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: BASIC - more harmful than useful?

Fri Oct 11, 2013 12:03 pm

Davew75 wrote: Long-time user of BBC BASIC for Windows here. What precisely is this "crud" you're referring to? Would it include Richard Russell's extremely welcome introduction of structures to BBC BASIC (for Windows)? If so, then you're quite mistaken. I'm sure that if you were to ask the majority of experienced BBfW users their opinion on structures, they'd say that they couldn't live without them! They do make life so much easier. I've used them in practically every BBfW program I've written since they were introduced to BBC BASIC.
The Structures are a possitive, in so far as it is slightly simpler than using Indirection to deal with Structurs.

That is the one feature that BBfW has that I would like to see in BBC BASIC V.
DavidS wrote: Also last time I checked BBC BASIC for Windows does not have a built in assembler.
Not correct. BBfW has *always* had a built-in assembler (I've written games and other stuff with it):
I stand corrected on that one. Not wure why that stuck in my head. Though I still find the RISC OS WIMP a lot simpler than M$-Windows.

-------------------------------------------------------------------------
jojopi wrote: here are gotos in the Linux kernel, and you could perhaps argue that some of them are due to deficiencies in C, such as the lack of exception handling. But your anecdotes do not really support the claim that C encourages goto more than modern BASIC does.
Ok fair enough.
BBC BASIC V does not have all the control statements that C does. Most significantly, it lacks equivalents of break¹ and continue. Admittedly these are hidden gotos, but they are therefore very useful to avoid actual gotos.

Because of the way BBC BASIC implements loops on a stack, you can not safely jump in or out of one. In that sense, maybe it discourages goto more than C does, simply by having a goto that does not work properly.
Ok I was not thinking about break So I will rephrase:
BBC BASIC V has almost all of the control structures of C, and some that C does not.

-------------------------------------------------------------------------
jamesh wrote: I don't have a problem with goto in C in the right circumstances - which is usually handling error conditions to avoid nasty spaghetti code. In most circumstances there are better alternatives.
Agreed. My main reason for pointing it out is that so many use the fact that BASIC supports GOTO as a reason to talk down about BASIC.

-------------------------------------------------------------------------
ruwin wrote:
DavidS wrote: I am guessing that the last time that you used BBC BASIC was on a 6502 based 8bit computer. Is this accurate?
Actually it was a 65C102 ;-) I did say I expected modern BASICs would be better.
That explains alot :) .

BBC BASIC V is a lot better. At least as capable as C.

You have missed the newer loops, the procedures, and a few other things.

You realy should try BBC BASIC V.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 23688
Joined: Sat Jul 30, 2011 7:41 pm

Re: BASIC - more harmful than useful?

Fri Oct 11, 2013 12:06 pm

tufty wrote:
rurwin wrote:However at each exit point, you need to free any of those memory chunks that have been allocated
Only if you're working with one of those backward languages that require you to deal with the trivia of memory allocation and (above all) deallocation. Garbage collection, automatic or otherwise, goes a long way to making for safer programming practices. Obviously, though, new technologies like that take some time to catch on*.

Exception handling is similar - it is, in fact, far from exceptional, and yet languages either pretend it doesn't exist, or pay lip service to it. C makes it significantly harder to write correct exception handlers than incorrect ones, so most people say "fsck it" and don't bother at all. And despite what the BASIC fanatics will have you believe, no, ON ERROR GO(SUB|TO), although slightly better, doesn't cut it either (it's merely syntactic sugar over C's approach, in fact). Like GC, exception handling is a well known and largely solved problem, but most implementations are way below par.

* Let's be honest with ourselves, GC's only been in use since the 1960s, so let's cut those language designers some slack, eh?
Never been a fan of garbage collection in embedded devices that require vaguely predictable response times. Causes too many weird effects that you really don't need when trying to encode H264 or run an image through a pipeline. So you really shouldn't be calling languages you don;t like backward - that just shows an ignorance of the requirements.

Interestingly, Google have some interesting things to say about exception handling as well - and I reckon they know what they are talking about. http://google-styleguide.googlecode.com ... Exceptions
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: BASIC - more harmful than useful?

Fri Oct 11, 2013 12:26 pm

tufty wrote:
ruwin wrote: However at each exit point, you need to free any of those memory chunks that have been allocated
Only if you're working with one of those backward languages that require you to deal with the trivia of memory allocation and (above all) deallocation. Garbage collection, automatic or otherwise, goes a long way to making for safer programming practices. Obviously, though, new technologies like that take some time to catch on*.
Sorry I must dissagree with that. Garbage collection has made for some very bad programming practices. And has made it so that many programmers do not bother to look at the way the are allocated memory, or bother to track it in there code, the way they should.

That is almost as bad as Bounds checking done by the language implementation, the programer should be responcable for that, not the language. Learning to do it correctly helps avoid errors.

I have seen many programs where they expect the language implementation to baby them like you suggest, and end up with big bugs that they can not track down, because the bugs are related to how there code interacts with the languages Garbage collection, and bounds checking.

Sorry a bit of a pet peive of mine.
Exception handling is similar - it is, in fact, far from exceptional, and yet languages either pretend it doesn't exist, or pay lip service to it.
Now I agree with you on that point. And three of the worste are C, C++, and Java. Oh well that is the way the world works and so many like it. At least C is a little better than C++, or Java (Though at least in C++ you can use the C method of error handling).
C makes it significantly harder to write correct exception handlers than incorrect ones, so most people say "fsck it" and don't bother at all. And despite what the BASIC fanatics will have you believe, no, ON ERROR GO(SUB|TO), although slightly better, doesn't cut it either (it's merely syntactic sugar over C's approach, in fact). Like GC, exception handling is a well known and largely solved problem, but most implementations are way below par.
I do not know about that. In interpreted BASIC using something like ON ERROR is the best way to wrapp the call back.

The problem is usually that most people do not bother writing a callback, or do not know how to correctly do so.

That is not a problem of the language per se. Though languages that provide alternative error handling like the throw stuff encourage people to do it wrong. As they are not encouraged to write the needed call back functions.
* Let's be honest with ourselves, GC's only been in use since the 1960s, so let's cut those language designers some slack, eh?
I must admit that I have not used Go, so can not say much about it. Though I avoid garbage colection and language based bounds checking like the pleuge, as it is better to do these things your self.


And yes BASIC does have some of both, still avoidable. These were big things in the 1960s when these languages came about. While I like BASIC I do not like automatic garbage collection, and language implemented bounds checking. These things belong in the 1960s and early 1970s. Leave the good ideas, that do not work out in practice, to rest in peace.


Again a bit of a pet peive of mine.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

tufty
Posts: 1456
Joined: Sun Sep 11, 2011 2:32 pm

Re: BASIC - more harmful than useful?

Fri Oct 11, 2013 2:57 pm

jamesh wrote:Never been a fan of garbage collection in embedded devices that require vaguely predictable response times. Causes too many weird effects that you really don't need when trying to encode H264 or run an image through a pipeline. So you really shouldn't be calling languages you don;t like backward - that just shows an ignorance of the requirements.
The main problem with GC is the moving of deallocation work (which remains constant regardless of whether we use garbage collection or not) away from the point where what was once live data becomes "garbage", and thus more work is required to determine if a particular reference is really garbage or not. This does not, however, mean that garbage collection is necessarily non-deterministic; it's perfectly possible to have a real-time garbage collecting implementation (for example, Baker's treadmill), the main trade-off against manual memory management being additional space requirements vs safety. Even manual reference counting[1][2] as used in Objective-C provides a safe environment (although with a little programmer effort required), and is usually bounded in time when "garbage collecting" happens (and when it's not, the programmer can not only see what's going on, but also fix it). In short, GC != Boehm (although Boehm, and generational collectors in general, are usually "performant enough" for general usage, particularly on modern computers which have gobs of memory and processing power to spare). On the other hand, try to to anything real-time with Android[3].
DavidS wrote:Garbage collection has made for some very bad programming practices. And has made it so that many programmers do not bother to look at the way the are allocated memory, or bother to track it in there code, the way they should.

That is almost as bad as Bounds checking done by the language implementation, the programer should be responcable for that, not the language. Learning to do it correctly helps avoid errors.
I'm never sure if you're trying to be provocative or just - well - ...

I'll try and reply anyway, I know I shouldn't, but hey.

Bad programming practices regarding memory allocation have existed forever. They are part of why Windows requires rebooting every now and then, they are part of why games on modern consoles don't run at a steady 60fps although the hardware is capable of doing so, they are a fact of life. They are also, along with lack of bounds checking, part of why there are massive security holes in almost every piece of software out there. "Modern"[4] concepts such as bounds checking and garbage collection go a long way towards fixing that, moving programmer time away from the minutia of managing the machine and spending it, instead, on implementing actual functionality.

Crappy programmers will produce crappy code no matter what.
jamesh wrote:Interestingly, Google have some interesting things to say about exception handling as well - and I reckon they know what they are talking about. http://google-styleguide.googlecode.com ... Exceptions
Yeah, but they're talking about C++, which has a substandard exception model largely built on C's. I largely agree with what they are saying, in that context, but the downside[5] is more programmer effort being expended on writing safe code rather than producing functionality.

Simon

[1] Which was used in the NeXTStep driver model, reference counting garbage collection at the driver level on 30MHz 680x0 machines, and that seemed to work pretty damn well.
[2] Also Microsoft's COM, Apple's IOKit, etc
[3] Actually, don't. At least if you value your sanity.
[4] Again, garbage collection has been around since the '60s
[5] With C++ you don't have a choice, of course, but I would class C++ as defective by design.

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: BASIC - more harmful than useful?

Fri Oct 11, 2013 5:25 pm

tufty wrote: Crappy programmers will produce crappy code no matter what.
That is definitely true. This is why I prefer to see programers that actually know what they are doing on some level (seems to be a rare thing any more).

Also know that I never post someting intended to be provocative. I am aware that my social skills are nearly non existent. Though I only wish for the positive exchange of thought. Just to aid in understanding I am not able to hold a verbal conversation with any one in person.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

OtherCrashOverride
Posts: 582
Joined: Sat Feb 02, 2013 3:25 am

Re: BASIC - more harmful than useful?

Fri Oct 11, 2013 7:35 pm

jamesh wrote:nterestingly, Google have some interesting things to say about exception handling as well - and I reckon they know what they are talking about. http://google-styleguide.googlecode.com ... Exceptions
I take exception to Google's Exception policy! ;)

Like anything else they can be used improperly. Exceptions should only be thrown when something exceptional has happened like you passed a null parameter that should never be null or you tried to open a file that does not exist. The latter is a good example for abuse. A "file not found" (or any other) exception should only occur if there is a bug in your code, not as part of its normal operation. The proper way would be to explicitly test for a file's existence before attempting to open it rather than relying on exception try/catch to create it.

tufty
Posts: 1456
Joined: Sun Sep 11, 2011 2:32 pm

Re: BASIC - more harmful than useful?

Fri Oct 11, 2013 7:54 pm

OtherCrashOverride wrote:A "file not found" (or any other) exception should only occur if there is a bug in your code, not as part of its normal operation. The proper way would be to explicitly test for a file's existence before attempting to open it rather than relying on exception try/catch to create it.
And what, pray, happens when the file becomes inaccessible between testing for its existence and actually opening it? Or, as a more likely state of affairs, between opening it and reading it, or between separate reads? etc etc.

How many C++ programmers bother to deal with std::ifstream::bad(), or anything other than std::ifstream::eof()?

OtherCrashOverride
Posts: 582
Joined: Sat Feb 02, 2013 3:25 am

Re: BASIC - more harmful than useful?

Fri Oct 11, 2013 8:03 pm

tufty wrote:And what, pray, happens when the file becomes inaccessible between testing for its existence and actually opening it? Or, as a more likely state of affairs, between opening it and reading it, or between separate reads? etc etc.
Then you would get an exception that indicates there is a bug in your code due to a condition that you did not anticipate. A file that is there and then not between 2 lines of code indicates a truly exceptional condition that should be resolved.

Where, hypothetically, this is normal behavior the solution would be to implement a "bool TryOpen(filename, out fileHandle)" function that would acquire a lock on the file when testing for its existence.

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: BASIC - more harmful than useful?

Fri Oct 11, 2013 10:41 pm

Qerhaps a little humer breake things up a bit:
ruwin wrote: A RETURN is not just a RET assembler instruction. Generally it has to unwind the stack-frame, and it may have to destroy local objects. In many architectures that is multiple assembler instructions, albeit handled by the compiler. But that is just a special case of the more general condition.
Ok I oversimplified.

Though I would like to know what CPU you are using on your RPi :) ? The ARM does not have a RET instruction (uses mov to R15, or load R15 instead). :lol:

Also the stack is software defined (can use any register, though most use R13 [it is good to agree on a convention]).
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

tufty
Posts: 1456
Joined: Sun Sep 11, 2011 2:32 pm

Re: BASIC - more harmful than useful?

Sat Oct 12, 2013 6:03 am

OtherCrashOverride wrote:
tufty wrote:And what, pray, happens when the file becomes inaccessible between testing for its existence and actually opening it? Or, as a more likely state of affairs, between opening it and reading it, or between separate reads? etc etc.
Then you would get an exception that indicates there is a bug in your code due to a condition that you did not anticipate.
A bug, yes, but you wouldn't necessarily get an exception. On file / socket reading in C, for example, read() would return 0 for EOF and -1 for an error condition. In the real world, it is rare to see coders handling both. Likewise, for C++, where almost nobody bothers to set badbit or failbit on an std::iXstream's "exceptions" member (C++'s exception handling isn't really good enough to handle it properly anyway), and so stream failure is identical to eof. Consider also that C++ "good practice" is to chain stream operators together, as follows:

Code: Select all

foo_stream >> std::hex >> a >> std::dec >> b >> std::hex >> c;
Now suppose that foo_stream fails somewhere within that chain. Even assuming you're catching an error condition, how in the name of all that's holy are you expected to work out what you have to fix? After all, it might be possible to retry (EAGAIN, EINTR, some cases of EIO, ECONNRESET, etc). Yeah, it's crappy coding, and more than likely a bug not to handle those cases, but there's a huge amount of effort required to handle them properly.
OtherCrashOverride wrote:A file that is there and then not between 2 lines of code indicates a truly exceptional condition that should be resolved.
No it's not. In C / C++, all input is streams, so your file might be a network connection, or any other "prone to failure" stream. Even a "file" might be remotely mounted, or on a removable drive, or on a failing device. You cannot trust any device or stream to be there from one instant to the next.

OtherCrashOverride
Posts: 582
Joined: Sat Feb 02, 2013 3:25 am

Re: BASIC - more harmful than useful?

Sat Oct 12, 2013 8:53 am

I think you are describing deficiencies in the library API, not exceptions deficiencies. Its entirely possible to have APIs that throw and alternate functions that do not (see "TryOpen" example in previous post) for scenarios where exceptions are likely rather than exceptional.

[Edit]
I think an example might be good:

Code: Select all

int main()
{
  CreateAFileWithRealtimeData();
  UpdateSomethingBasedOnDataInFile();
  DeleteTheFile();
}
With exceptions, if the operation fails, the program does not delete the file. Without exceptions the file is deleted and integrity is compromised since the data was never considered. Since the coder has failed to take into consideration that something could happen to the file and does not check error codes, the bug goes undiscovered.

Failure to check error codes is quite common. You can look at the Pi hello_triangle samples for proof. The opengl C API requires coders to explicitly call glGetError() after every function (with some exceptions - no pun intended), yet few ever do.

tufty
Posts: 1456
Joined: Sun Sep 11, 2011 2:32 pm

Re: BASIC - more harmful than useful?

Sat Oct 12, 2013 3:17 pm

OtherCrashOverride wrote:I think you are describing deficiencies in the library API, not exceptions deficiencies.
Well, I'm describing an underlying flaw in the way exceptions are handled in C++; without ignoring the C++ exception model entirely and either falling back to manual error-checking, or implementing something better on top of C's setjmp() etc, it's not possible to handle exceptions in a complete way. Of course, the first is tedious (and, as you point out, never done in a complete manner), and the second requires a rewrite of most of the C++ standard library.

Exceptions done properly enable the programmer to concentrate on what's actually going on, rather than, again, micromanaging the minutia of program flow.

OtherCrashOverride
Posts: 582
Joined: Sat Feb 02, 2013 3:25 am

Re: BASIC - more harmful than useful?

Sat Oct 12, 2013 7:08 pm

tufty wrote:Exceptions done properly enable the programmer to concentrate on what's actually going on, rather than, again, micromanaging the minutia of program flow.
This is the "nightmare" scenario with exceptions that the google document does not actually state:

Code: Select all

int main()
{
  while(true)
  {
      try
      {
        CallSomthingThatThrows();
      }
      catch
      {
         // I caught the exception so everything should be good!
        // unfortunately, what is actually happening is that we are leaking memory
      }
  }
}

void CallSomethingThatThrows()
{
  SomeThing* pointerToSomething = new Something();
  OpenAfileAndDoSomething(); // when this throws, the next line is never executed
  delete pointerToSomething;
}
There are two modern solutions to this:
1) A garbage collector
2) C++ smart-pointers (expanded in C++11 r-value references and move semantics which produces new API capabilities)

Return to “Staffroom, classroom and projects”