jahboater
Posts: 3027
Joined: Wed Feb 04, 2015 6:38 pm

Re: Making readable modifyable code.

Thu Nov 24, 2016 4:08 pm

Thats interesting, I have learned something. Thanks!
Heater wrote: But Lucol was more than that. It was possible to know every possible execution path through a module.
Which also helps with the 100% test coverage I guess.

Heater
Posts: 9970
Joined: Tue Jul 17, 2012 3:02 pm

Re: Making readable modifyable code.

Thu Nov 24, 2016 4:13 pm

Exactly.

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

Re: Making readable modifyable code.

Thu Nov 24, 2016 5:14 pm

jahboater wrote:
Heater wrote: In the Lucol language this was easy to verify. The compiler reported the maximum execution time of every module or a collection of modules. So you knew if there were problems with the time budget looming without ever running it. Runing out of execution time was an error the same as any syntax error!

Have you ever used a programming language system that can do that?
No - that's amazing.
I am guessing that was long time ago - modern CPU's are astonishing unpredictable in this respect - out of order execution, speculative execution, instruction fusing, clever optimisations by the decoder (some insns have zero latency on x86) and so on.
zero execution time instructions are also true of the ARMv6/7/8. The difference that the ARM does not need to use speculative execution or other archane means to achieve zero execution of many instructions, and it is predictable, so long as you rely only on cache and RAM as your sources.
Clearly Ada was the wrong language. Much effort went into making it safe as in fewer errors, but not hard real-time.
26-Bit R15 to 32-bit. 16-bit addressing to 24-bit. ARM and 65xx two CPU's that continue on, and are better than ever. Assembly Language forever :) .

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

Re: Making readable modifyable code.

Thu Nov 24, 2016 5:24 pm

Heater wrote:jahboater,

Indeed, modern processors make exection time almost unkowable. In the extreme an instruction fetch can require data from cache which is not there, which then causes a fetch from memory that is not there, which then causes a fetch from a file system that is not there, which ends up going over the net, which may never get a respnonse...Your execution time is unbounded!

More realistically, in an embedded system, with everything set up right your instruction execution time will have an upper limit. A compiler could assume that worst case.
P8X32A

But Lucol was more than that. It was impossible to write loops that you could not know the execution time of. It was possible to know every possible execution path through a module.
26-Bit R15 to 32-bit. 16-bit addressing to 24-bit. ARM and 65xx two CPU's that continue on, and are better than ever. Assembly Language forever :) .

jahboater
Posts: 3027
Joined: Wed Feb 04, 2015 6:38 pm

Re: Making readable modifyable code.

Thu Nov 24, 2016 6:24 pm

DavidS wrote: zero execution time instructions are also true of the ARMv6/7/8. The difference that the ARM does not need to use speculative execution or other archane means to achieve zero execution of many instructions, and it is predictable, so long as you rely only on cache and RAM as your sources.
I meant things like "sub r,r" - the result is known (zero) and there are no dependencies, so why bother executing it? It never enters the pipeline. Same with register to register moves and other obvious things like xor r,r (eor).

I think you meant 'arcane' not 'archane'.

ejolson
Posts: 2008
Joined: Tue Mar 18, 2014 11:47 am

Re: Making readable modifyable code.

Thu Nov 24, 2016 10:37 pm

ZXDunny wrote:It's successor (SpecBAS) is available for the rPI, there should be some links to it somewhere on the forums.
The source code for SpecBAS itself appears to be written in Pascal, actively developed and a reasonable example of readable and modifiable code.

Over 50% of the people in the world are multilingual. If this same ability to learn new languages carries over to programming languages, there should be no problem learning a teaching language such as BASIC or Scratch first. On the other hand, just under 50% of the people in the world are monolingual, so maybe learning a more expressive programming language first is better in general.

ZXDunny
Posts: 80
Joined: Sun Jul 08, 2012 7:57 pm

Re: Making readable modifyable code.

Thu Nov 24, 2016 11:31 pm

ejolson wrote:
ZXDunny wrote:It's successor (SpecBAS) is available for the rPI, there should be some links to it somewhere on the forums.
The source code for SpecBAS itself appears to be written in Pascal, actively developed and a reasonable example of readable and modifiable code.
That's very kind of you to say so, I'm rather flattered :D
Over 50% of the people in the world are multilingual. If this same ability to learn new languages carries over to programming languages, there should be no problem learning a teaching language such as BASIC or Scratch first. On the other hand, just under 50% of the people in the world are monolingual, so maybe learning a more expressive programming language first is better in general.
Now, I know this may be a very unpopular thing to say, but I'm fairly certain that the number of people capable of learning to code is probably less than 50% of the population. And of those that do go on to become proficient in the craft, I'd say that pretty much all of them can code in more than one language, or at least read more than one.

ejolson
Posts: 2008
Joined: Tue Mar 18, 2014 11:47 am

Re: Making readable modifyable code.

Fri Nov 25, 2016 1:02 am

ZXDunny wrote:Now, I know this may be a very unpopular thing to say, but I'm fairly certain that the number of people capable of learning to code is probably less than 50% of the population. And of those that do go on to become proficient in the craft, I'd say that pretty much all of them can code in more than one language, or at least read more than one.
It is not surprising that people who go on to become professional programmers know and are able to learn many programming languages. This is also the case with linguists who are typically proficient in 5 to 10 natural languages.

I don't know what the percentages really are, but there are a surprising number of college students who seem unable to write a proper English paragraph. Maybe your observations about programming languages are also true for natural languages. Independent of ability is the idea of opportunity. Providing opportunity is important out of love for neighbor and because society benefits greatly from those with little ability who have learned everything they can.
Last edited by ejolson on Fri Nov 25, 2016 3:12 am, edited 3 times in total.

asandford
Posts: 1996
Joined: Mon Dec 31, 2012 12:54 pm
Location: Waterlooville

Re: Making readable modifyable code.

Fri Nov 25, 2016 1:38 am

Heater wrote:@asandford

That sounds great. When I did my CS A level in 1974 the course was 30% statistics, 30% numerical analysis and only 30% anything about computers. Only a small part of that was about programming. Luckily that small part was not just solving equations in BASIC but also a bit of assembler. You know, the "real stuff" :)
The London exam board weighted practical parts so highly that if you failed it (only worth about 10%), you failed the whole exam. My biology A level was classed as an O level as although I passed the written exam with flying colours, I failed the practical (again worth only 10%). I passed it 6 months later by taking the AEB exam instead.

At the time, my school only had RML 380Z machines, so I had to bring in my BBC micro to demonstrate.

Also, my electronics teacher was totally colour blind, so how he read resistor codes amazed me.

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

Re: Making readable modifyable code.

Sat Nov 26, 2016 10:17 am

This is gonna have a load of quotes taken pretty much at random from the thread, and some of those quotes will be deliberately taken out of context to make a point. Sorry about all of that in advance.
Heater wrote:… Dijkstra was totally on the mark
Dijkstra was famously rude. Some of his other quotes are fantastic. In this case, it's very easy to take it as a frontal attack on BASIC (which it is), but it's also an attack on the absurdly stupid concept of teaching programming using a deliberately dumbed down language, which cannot (or, rather could not) express "modern" concepts. And he was right in both respects.
Heater wrote:So when you are done BASIC is what they think computing is. There is nothing else … they never get inspired to explore further.
Exactly. And without wanting to be rude, DavidS is a shining example of this.
Heater wrote:Anyway, Javascript is the new BASIC for many now.
And Dijkstra's famous comment holds.
Heater wrote:Indeed, modern processors make exection time almost unkowable. In the extreme an instruction fetch can require data from cache which is not there, which then causes a fetch from memory that is not there
Which is a fault, and <something happens here, dependent on operating system>. As far as the processor side of things goes, the time for the fetch to execute is bounded by the time to clear and fill a / many cache line(s), but may fail.
Heater wrote:But Lucol was more than that. It was impossible to write loops that you could not know the execution time of. It was possible to know every possible execution path through a module.
That's an exceptionally interesting language / toolset. Especially given the emphasis on guaranteed correct parallel processing. A cynic might point at the fact it was developed by Lucas, who couldn't get even make car and motorcycle headlights work correctly, and laugh, but that would be unkind. *cough* Prince of Darkness *cough*.
jahboater wrote:It is at least theoretically possible with some modern languages to prove that a program is correct.
That's always been possible, but only for "a" program, and not for "any" program. You must restrict some combination of the type of things you can do with the language, the type of programs you accept, the data you can accept for a given program. Otherwise the Turing tarpit will drag you down every time, and Gödel will kick you in the nuts. The main difficulty is making the subset you're restricted to useful.
Heater wrote:like lisp and scheme. No types there.
Paaaarp! No. There's types all over the place in lisp and scheme, it's just that you don't have to explicitly state them. The type of cons, for example, is pair <- *, *. A major part of making a performant lisp interpreter / compiler is to do with static type analysis, and in particular where you can discard dynamic type checking.
Heater wrote:Java … I started to realize that type are stupid. They get in the way. They obscure what you want to say with a mass of syntactic junk
No, that's a syntactic issue with Java, caused by a desire for provable type-correctness at compile time. And yet, as you point out
Heater wrote:

Code: Select all

int amps = 10;
int volts = 3;
int result = amps + volts;
… but the problem there isn't types, it's inadequate types. For starters, as "typed" above, if you'll forgive the pun, it's a problem with languages that chain their type systems to very light abstractions over underlying machine types. But there's more to it than that. Semantics and representability are two separate things.

The solution is to deal with semantic types, so for a given simulation, volt is a type for a continuously variable numeric value, perhaps between two bounds. Likewise amp, and the add operator is then only defined for amp <- amp, amp and volt <- volt, volt. The multiply operator, then, might be defined as watt <- volt, amp.

None of this means you necessarily have to annotate the types all over your source, either. Hindley-Milner is pretty powerful, and there's all sorts of extensions to it; most type checking can be done at compile time (we can consider an interpreter as a special case of JIT compilation). That said, a certain amount of annotation generally makes type errors much easier to read and localise.

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

Re: Making readable modifyable code.

Sat Nov 26, 2016 5:48 pm

tufty wrote:This is gonna have a load of quotes taken pretty much at random from the thread, and some of those quotes will be deliberately taken out of context to make a point. Sorry about all of that in advance.
Heater wrote:… Dijkstra was totally on the mark
Dijkstra was famously rude. Some of his other quotes are fantastic. In this case, it's very easy to take it as a frontal attack on BASIC (which it is), but it's also an attack on the absurdly stupid concept of teaching programming using a deliberately dumbed down language, which cannot (or, rather could not) express "modern" concepts. And he was right in both respects.
And I would agree that BASIC is a terrible production language, hence why BASIC is pretty much dead, except in teaching environments.

This is why I prefer languages that are either Pascal, or very similar to Pascal. There are a few things in the Pascal language that could be better done by algorithmic means (such as subsets), though the language itself is a great structured language with good rules to help ensure the usability of the language.
Heater wrote:So when you are done BASIC is what they think computing is. There is nothing else … they never get inspired to explore further.
Exactly. And without wanting to be rude, DavidS is a shining example of this.
I dissagree with the idea that a first language would be the key way to how a person views programming. Even though I often talk of the old Commodore BASIC as a starting point, in fact the first language I did anything real in was Pascal (forget the implementation, though compiled to native machine language on the Commodore 64).

I do think that you may be confusing one language that I do still use with BASIC. I do use ARM BASIC, though that is very far from BASIC, as far removed from BASIC as C, B, BCPL, or Pascal are from BASIC. I like ARM BASIC because it has many of the advantages of both C and Pascal, has nothing to do with the misleading name of the language.
Heater wrote:Anyway, Javascript is the new BASIC for many now.
And Dijkstra's famous comment holds.
Heater wrote:Indeed, modern processors make exection time almost unkowable. In the extreme an instruction fetch can require data from cache which is not there, which then causes a fetch from memory that is not there
Which is a fault, and <something happens here, dependent on operating system>. As far as the processor side of things goes, the time for the fetch to execute is bounded by the time to clear and fill a / many cache line(s), but may fail.
Heater wrote:But Lucol was more than that. It was impossible to write loops that you could not know the execution time of. It was possible to know every possible execution path through a module.
That's an exceptionally interesting language / toolset. Especially given the emphasis on guaranteed correct parallel processing. A cynic might point at the fact it was developed by Lucas, who couldn't get even make car and motorcycle headlights work correctly, and laugh, but that would be unkind. *cough* Prince of Darkness *cough*.
And this is a language that I first heard of in this thread. I actually had to look it up. Very interesting though.

jahboater wrote:It is at least theoretically possible with some modern languages to prove that a program is correct.
That's always been possible, but only for "a" program, and not for "any" program. You must restrict some combination of the type of things you can do with the language, the type of programs you accept, the data you can accept for a given program. Otherwise the Turing tarpit will drag you down every time, and Gödel will kick you in the nuts. The main difficulty is making the subset you're restricted to useful.
No, the main difficulty is making a corect program by correctly coding it, and doing good module testing. The language should not provide restrictions, as there are many cases where doing things in a way that some languages would restrict is far from the best way to do it. That is why many Pascal implementations have some kind of variant type (different from implementation to implementation unfortunately), and C has unions and type casts.
Heater wrote:like lisp and scheme. No types there.
Paaaarp! No. There's types all over the place in lisp and scheme, it's just that you don't have to explicitly state them. The type of cons, for example, is pair <- *, *. A major part of making a performant lisp interpreter / compiler is to do with static type analysis, and in particular where you can discard dynamic type checking.
Heater wrote:Java … I started to realize that type are stupid. They get in the way. They obscure what you want to say with a mass of syntactic junk
No, that's a syntactic issue with Java, caused by a desire for provable type-correctness at compile time. And yet, as you point out
Heater wrote:

Code: Select all

int amps = 10;
int volts = 3;
int result = amps + volts;
… but the problem there isn't types, it's inadequate types. For starters, as "typed" above, if you'll forgive the pun, it's a problem with languages that chain their type systems to very light abstractions over underlying machine types. But there's more to it than that. Semantics and representability are two separate things.

The solution is to deal with semantic types, so for a given simulation, volt is a type for a continuously variable numeric value, perhaps between two bounds. Likewise amp, and the add operator is then only defined for amp <- amp, amp and volt <- volt, volt. The multiply operator, then, might be defined as watt <- volt, amp.

None of this means you necessarily have to annotate the types all over your source, either. Hindley-Milner is pretty powerful, and there's all sorts of extensions to it; most type checking can be done at compile time (we can consider an interpreter as a special case of JIT compilation). That said, a certain amount of annotation generally makes type errors much easier to read and localise.
Never rely on the language to catch your errors, that is a poor way around things, always.

It is much better to rely on your module testing, and usually produces much more reliable code, that is much better than relying on a language or static analysis tool.
26-Bit R15 to 32-bit. 16-bit addressing to 24-bit. ARM and 65xx two CPU's that continue on, and are better than ever. Assembly Language forever :) .

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

Re: Making readable modifyable code.

Sat Nov 26, 2016 5:55 pm

The project I chose to work on in responce to the chalenge layed out by Heater is written in Pascal, and compiles with GPC. The choice of language should be what the programmer is comfortable and is best for the project.

I do admit that my normal trouble in dealing with xlib or xcb is a bit of a slow down, though that is off point.
26-Bit R15 to 32-bit. 16-bit addressing to 24-bit. ARM and 65xx two CPU's that continue on, and are better than ever. Assembly Language forever :) .

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

Re: Making readable modifyable code.

Sat Nov 26, 2016 7:11 pm

DavidS wrote:Never rely on the language to catch your errors, that is a poor way around things, always
*Whooosh*

That's the sound of the point going entirely over your head.

I wasn't suggesting that every programming language should have, and check, a full range of semantic types. That would be absurd. What I'm trying to say is that semantic types, despite mostly being checked at compile time, are as much part of your code as the rest of your code. If you're writing an electrical simulator, then it makes sense to define semantic types for the Amp, Volt, Watt, Farad, Ohm, and so on. Your code can be viewed as a domain specific language defined in terms of the (semantic) types used by your simulator.

By doing this, a whole lot of boring, error-prone rubbish, the stuff dealing with mapping between the semantic types and the underlying machine types, is taken out of the hands of the programmer, leaving her time to spend on doing the actual programming. For example, still in terms of a hypothetical electrical simulator, one might define the voltage type as being a continuously variable numeric value between two runtime defined bounds. If we're doing this in, for example, C, we might represent voltage as a floating point value. The runtime bounds thing is a bit of a pain, though, as we have to write a bunch of bounds checking code. Now, we are aware that not all values are representable exactly at a machine level, so, as we're doing simulation, we might want to have an indicator of exactness and error range for any given calculation. Yet more code to implement. And we might want to, rather than simply using a float, use exact values where possible, with seamless "gear shifting" from exact to inexact to exact. Suddenly, what sounded pretty simple starts looking enormously complex (try looking at the code for the GMP library, for example), and it still doesn't stop us multiplying voltage by the number of resistors in a shipping spool.
DavidS wrote:It is much better to rely on your module testing, and usually produces much more reliable code, that is much better than relying on a language or static analysis tool.
No it's not, no it doesn't, and no it's not (not that testing shouldn't be used in conjunction with language and static analysis tools, mind).

Testing, and test-driven development, are a fantastic tool. Unfortunately, the reality of testing is that something uphill of 90% of tests are ineffective, incomplete, out of date with respect to requirements, or just flat wrong.
Last edited by tufty on Sat Nov 26, 2016 7:43 pm, edited 1 time in total.

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

Re: Making readable modifyable code.

Sat Nov 26, 2016 7:30 pm

tufty wrote:
DavidS wrote:Never rely on the language to catch your errors, that is a poor way around things, always
*Whooosh*

That's the sound of the point going entirely over your head.

I wasn't suggesting that every programming language should have, and check, a full range of semantic types. That would be absurd. What I'm trying to say is that semantic types, despite mostly being checked at compile time, are as much part of your code as the rest of your code. If you're writing an electrical simulator, then it makes sense to define semantic types for the Amp, Volt, Watt, Farad, Ohm, and so on. Your code can be viewed as a domain specific language defined in terms of the (semantic) types used by your simulator.

By doing this, a whole lot of boring, error-prone rubbish, the stuff dealing with mapping between the semantic types and the underlying machine types, is taken out of the hands of the programmer, leaving her time to spend on doing the actual programming. For example, still in terms of a hypothetical electrical simulator, one might define the voltage type as being a continuously variable numeric value between two runtime defined bounds. If we're doing this in, for example, C, we might represent voltage as a floating point value. The runtime bounds thing is a bit of a pain, though, as we have to write a bunch of bounds checking code. Now, we are aware that not all values are representable exactly at a machine level, so, as we're doing simulation, we might want to have an indicator of exactness and error range for any given calculation. Yet more code to implement. And we might want to, rather than simply using a float, use exact values where possible, with seamless "gear shifting" from exact to inexact to exact. Suddenly, what sounded pretty simple starts looking enormously complex (try looking at the code for the GMP library, for example), and it still doesn't stop us multiplying voltage by the number of resistors in a shipping spool.
Alright, I see your point.
DavidS wrote:It is much better to rely on your module testing, and usually produces much more reliable code, that is much better than relying on a language or static analysis tool.
No it's not, no it doesn't, and no it's not.

Testing, and test-driven development, are a fantastic tool. Unfortunately, the reality of testing is that something uphill of 90% of tests are ineffective, incomplete, out of date with respect to requirements, or just flat wrong.
WOW, talking about a point going over someones head.

NO NO NO, not what I meant at all.

Module testing does not use any tools.

Module testing is about making test code to run through the code with values that will run every possible path within the code, and validate the results each step of the way. This is done in small steps as the code becomes more and more complete.

In module testing you also attempt to break the code, that is you test with out of bounds values, invalid parameters, etc. Now this catches 99% of the errors that are not caught by "hand running" the code (part of the standard way of writing any code), once all syntax errors are caught (mostly by the compiler).

There are still bugs that can make it past module testing, this is a given, though it greatly reduces the number of bugs that make it to the pre-alpha release of a project.

That is what I am talking about by module testing, this is first year CS stuff that is well known (or was when I attended CS courses). And it is a bit of a bore in school, as it is something learned long before attending any CS courses :) .
26-Bit R15 to 32-bit. 16-bit addressing to 24-bit. ARM and 65xx two CPU's that continue on, and are better than ever. Assembly Language forever :) .

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

Re: Making readable modifyable code.

Sat Nov 26, 2016 7:59 pm

OK, when I said testing was a fantastic tool, I meant it in terms of "part of the toolkit every developer worth their salt has at their disposal". I thought that was fairly evident from the wording, but apparently not.

The real world issues found with testing approaches are largely caused by developer testing ("unit" testing, usually) tending to be enormously low level - aiming at hitting every code path is a laudable goal, if prone to combinatorial explosion, but does little to show that the code paths themselves are correct. Look at most real world test suites, and you'll find loads of code checking that 2 + 2 = 4 - effectively checking that the processor hasn't gone wrong - and very little code checking the functional requirements of the code. Going back to the simulation example, all the testing in the world won't stop you adding volts to amps. You'll find even less tests using input the program is likely to encounter in "live" usage - etaoin shrdlu is good enough for anyone, right?

And that's when you do find tests. Mostly, management see time writing tests as time that would be better spent meeting requirements / squashing bugs, and even the best developers, the ones who should know better, see it largely as boring drudge work that serves little purpose.

ejolson
Posts: 2008
Joined: Tue Mar 18, 2014 11:47 am

Re: Making readable modifyable code.

Sat Nov 26, 2016 8:19 pm

DavidS wrote:
tufty wrote:it's very easy to take it as a frontal attack on BASIC (which it is), but it's also an attack on the absurdly stupid concept of teaching programming using a deliberately dumbed down language, which cannot (or, rather could not) express "modern" concepts. And he was right in both respects.
And I would agree that BASIC is a terrible production language, hence why BASIC is pretty much dead, except in teaching environments.
According to this survey of programming languages taken November 2016, the popularity of Visual Basic .NET has been increasing on average since it's introduction and now sits at sixth place with the ordering being Java, C, C++, C#, Python and then Visual Basic .NET. Furthermore, if you add the scores for the NET and non-NET versions of Visual Basic together, then Basic ranks higher than C# or Python and almost the same as C++. The fact is that modern versions of Basic are not dumbed down teaching languages. Therefore, Dijkstra's criticism doesn't apply. On the other hand it applies quite clearly to Scratch.

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

Re: Making readable modifyable code.

Sat Nov 26, 2016 8:34 pm

tufty wrote:OK, when I said testing was a fantastic tool, I meant it in terms of "part of the toolkit every developer worth their salt has at their disposal". I thought that was fairly evident from the wording, but apparently not.

The real world issues found with testing approaches are largely caused by developer testing ("unit" testing, usually) tending to be enormously low level - aiming at hitting every code path is a laudable goal, if prone to combinatorial explosion, but does little to show that the code paths themselves are correct. Look at most real world test suites, and you'll find loads of code checking that 2 + 2 = 4 - effectively checking that the processor hasn't gone wrong - and very little code checking the functional requirements of the code. Going back to the simulation example, all the testing in the world won't stop you adding volts to amps. You'll find even less tests using input the program is likely to encounter in "live" usage - etaoin shrdlu is good enough for anyone, right?
Ok it was a double missunderstanding.

Using the simulation example you mention, and the error of adding amps to the count of components on a roll, well done module testing would catch that, do to a wrong value in a variable after that code path.

Yes well done module testing takes time, as you need to write each and every test at least 3 times using different algorithms each time, and not referencing the other tests in order to assure that an error is unlikely to be because of the test, and that the test is less likely to miss something.

Though the biggest key is to keep the test code as simple as possible while still being complete, this reduces the probability of error in the test code.
And that's when you do find tests. Mostly, management see time writing tests as time that would be better spent meeting requirements / squashing bugs, and even the best developers, the ones who should know better, see it largely as boring drudge work that serves little purpose.
That is unfortunate.

The ideal, and best way to squash a bug is not to have the bug in the first place. Now this is not 100% possible, so when a bug is found, you create new module tests to run the relevant code paths, and make sure that everything related to the bug is caught (as much as humanly possible)


It seems a much better usage of time to do correct testing of code than to waste time squashing the many bugs that would never have existed if it were done correctly in the first place. Then what ever bugs made it past all the testing are likely to be easier to fix, as it is known that it is something that the tests used missed.
26-Bit R15 to 32-bit. 16-bit addressing to 24-bit. ARM and 65xx two CPU's that continue on, and are better than ever. Assembly Language forever :) .

ZXDunny
Posts: 80
Joined: Sun Jul 08, 2012 7:57 pm

Re: Making readable modifyable code.

Sat Nov 26, 2016 10:53 pm

I dunno, I find the best way to get my testing done is to release the thing.

Then the users come back with bug reports. I fix them, release updates, and then carry on with more fun stuff.

Works for me :)

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

Re: Making readable modifyable code.

Sat Nov 26, 2016 11:52 pm

ZXDunny wrote:I dunno, I find the best way to get my testing done is to release the thing.

Then the users come back with bug reports. I fix them, release updates, and then carry on with more fun stuff.

Works for me :)
And that is how you find the bugs that all of your own testing missed. If you have caught most of the bugs before the initial pre-alpha release then it is that much less work to deal with bug reports later, as they will be fewer, and you will know what you have already done for testing.
26-Bit R15 to 32-bit. 16-bit addressing to 24-bit. ARM and 65xx two CPU's that continue on, and are better than ever. Assembly Language forever :) .

Heater
Posts: 9970
Joined: Tue Jul 17, 2012 3:02 pm

Re: Making readable modifyable code.

Sun Nov 27, 2016 9:34 pm

@tufty,
Unfortunately, the reality of testing is that something uphill of 90% of tests are ineffective, incomplete, out of date with respect to requirements, or just flat wrong.
Hmm... Not where I come from. When you are creating software where it matters if it works or not, like avionics controls, or military or satellites, it's a different world:

1) There is a specification of what the software should do.

2) A team writes the software to do that.

3) Another team, working from the spec. writes the unit tests and integration tests.

4) There is full traceability from the specification to the source code.

5) There is full traceability from the specification to the tests.

6) If the spec. ever changes, so does the code, so do the tests. The whole thing has to be tested from top to bottom again.

@ejolson
Therefore, Dijkstra's criticism doesn't apply.
Perhaps true. His claim was about BASIC. These new BASICs model themselves after ALGOL. A totally different thing.

@tufty,
I dunno, I find the best way to get my testing done is to release the thing. ...Then the users come back with bug reports.
Yep, that would work. Release the fly by wire code for whatever Boeing of Airbus. Then, when the thing crashes and kills 400 people, their relatives can report the bug and we can fix it!

ZXDunny
Posts: 80
Joined: Sun Jul 08, 2012 7:57 pm

Re: Making readable modifyable code.

Sun Nov 27, 2016 10:12 pm

Heater wrote: @tufty,
I dunno, I find the best way to get my testing done is to release the thing. ...Then the users come back with bug reports.
Yep, that would work. Release the fly by wire code for whatever Boeing of Airbus. Then, when the thing crashes and kills 400 people, their relatives can report the bug and we can fix it!
I suspect that was aimed at me, rather than Tufty - there's quite a difference; I don't have a lathe for one thing.

But anyway, I believe that there's a world of difference between me writing a small BASIC interpreter for people that loved one particular dialect and me writing Avionics code - I can get away with letting the users do the bug testing. If it were revealed that Boeing were doing that then I suspect their business would be toast within minutes of the news hitting the regulating authorities :)

ejolson
Posts: 2008
Joined: Tue Mar 18, 2014 11:47 am

Re: Making readable modifyable code.

Mon Nov 28, 2016 1:15 am

ZXDunny wrote:Then it may amuse you to hear that currently many thousands of schools in the UK today are using Sinclair BASIC (yes, that one!) to teach their 7 year-old pupils to code :)
I've been wondering about the above statement. Thousands of schools using BASin and specBAS implies the existence of well-written educational resources that incorporate Sinclair BASIC into the curriculum. Are these reprintings of texts from the 80's or new materials?

ZXDunny
Posts: 80
Joined: Sun Jul 08, 2012 7:57 pm

Re: Making readable modifyable code.

Mon Nov 28, 2016 10:33 am

ejolson wrote:
ZXDunny wrote:Then it may amuse you to hear that currently many thousands of schools in the UK today are using Sinclair BASIC (yes, that one!) to teach their 7 year-old pupils to code :)
I've been wondering about the above statement. Thousands of schools using BASin and specBAS implies the existence of well-written educational resources that incorporate Sinclair BASIC into the curriculum. Are these reprintings of texts from the 80's or new materials?
I have no idea - I just wrote the software. I suspect that they're using re-purposed 80s texts at present once they've finished with the lessons that were created specifically for BASin, though there are plans for more to be written. Schools aren't using SpecBAS to the best of my knowledge (though they may well be) - officially, in RC's every child can code effort, it's BASin and soon to be a new product that's still in development.

Heater
Posts: 9970
Joined: Tue Jul 17, 2012 3:02 pm

Re: Making readable modifyable code.

Mon Nov 28, 2016 4:08 pm

I have been wondering about that too:

Are you saying that after over 3 decades of software development the best they can find is to teach kids programming is a rude and crude BASIC from the 1980's?

I'm impressed that it works for 7 year olds. From what I can recall when we were 7 we could hardly do arithmetic.

What are these RCs of which you speak?

ZXDunny
Posts: 80
Joined: Sun Jul 08, 2012 7:57 pm

Re: Making readable modifyable code.

Mon Nov 28, 2016 4:20 pm

Heater wrote:I have been wondering about that too:

Are you saying that after over 3 decades of software development the best they can find is to teach kids programming is a rude and crude BASIC from the 1980's?

I'm impressed that it works for 7 year olds. From what I can recall when we were 7 we could hardly do arithmetic.

What are these RCs of which you speak?
The company that started it off - RetroComputers Ltd.

Most of the kids that got Speccys when they were about that age managed to learn coding pretty easily with it, so I guess it's not all bad.

Return to “General programming discussion”