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

Re: Making readable modifyable code.

Wed Nov 23, 2016 10:46 pm

I may see about submitting some code in my language of choice.

But on the subject of style: Where do we all stand on that most paramount of issues that's at the top of people's minds?

I am of course talking about BASIC that enforces the use of line numbers. Personally I'm a great proponent, but I've heard in some dark corners of the internet that they may be frowned upon.


Your thoughts?

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

Re: Making readable modifyable code.

Wed Nov 23, 2016 10:58 pm

Heater wrote:DavidS,
Does this seem acceptable to all interested in taking Heater up on his suggestion (including Heater)?
Not really.

My suggestion was to actually do something. Anything. Anyhow. Whatever shakes your tree.

I don't care how many files it takes. I would be happier if the result was interesting/useful to users of any platform not just ARM. GUI is optional, could be a robot control thing or whatever. Never mind the forum attachment, we have github, bitbucket, etc, through which we can share code. Recycling code from others is quite OK if it helps get the job done (Licensing allowing of course).

Go forth and hack!
Sounds good to me.
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

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

Re: Making readable modifyable code.

Wed Nov 23, 2016 11:00 pm

ZXDunny,

Ha! Let's play with that.

The only BASIC I know uses line numbers. Since 1973 or so.

Line numbers are great because it makes it really easy to edit your program without a sophisticated terminal and a horribly complex editor like vim or even nano. You just type the new content of a line into your teletype and there it is. Job done.

Line numbers are the high level language equivalent of addresses in machine code.

Of course if you only have line numbers you need GOTO and GOSUB. Just like jumps and calls in assembler. How simple could it be?!

BASICs without line numbers but using all that new fangled structured programming stuff are not really BASIC at all. They are just pale imitations of Algol or C. They just obfuscate the meaning of your code.

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

Re: Making readable modifyable code.

Wed Nov 23, 2016 11:16 pm

Oh. My. God.

I was not expecting that. And I don't care if you're being facetious, that's exactly how I feel BASIC should be. Yet I meet so much resistance, even from asm coders.

I have spent the last... 6 years? Gosh, really? Writing a BASIC interpreter that uses line numbers, with, yes as you say, a single-line-based entry system. Only recently have I caved in to demand and added an editor that allows the use of the full screen like current IDEs (but I still enforce line numbers).

Line numbers force you to consider your code; to think about the words you write, rather than just throw in keywords and functions willy-nilly any old how you please. They condense your code into its most terse form.

And to a beginner they're a godsend. A logical flow that's easily visible to anyone that can count. Yes, they mirror assembly language beautifully and make the transition from high level to low so much easier. "You see that BASIC code? Well asm is just like that, but the building blocks are much, much smaller. But so much more powerful".

As opposed to say, C - where the first question is usually "why does my code not start at the top of the page?" followed by "why do I need a header file? I've already told the compiler what my function is for!"

Oh, I could go on for days, me.

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

Re: Making readable modifyable code.

Thu Nov 24, 2016 12:34 am

ZXDunny,
Oh. My. God. I was not expecting that...
Full of surprises aren't I? No I was not being facetious.

The way I see it is that young people may have no idea of arithmetic, maths and such, so a simple:

PRINT "Hello"

is an amazing thing that can inspire them as to what a computer can do.

When they know about arithmetic then:

PRINT 123 + 532

Is magical.

When they know a little algebra then:

a = 100
b = 53
PRINT a + b

Is meaningful. And again amazing.

Then we can get down to the real meat of computing, the selection (if, then, else, ..) and the iteration (while, for...)

The simple way to do that is with line numbers and GOTO. Or at least labels and GOTO.

Why, because the whole idea of a loop, an algorithm, is a very far out concept. Never mind the concept of a function.

A language like Algol and it's descendants, C, Java, etc, etc, assume a sophisticated understanding of many things before you can even start.

I believe that is why people were putting languages like Logo in front of young children back in the day.

Mind you, all of that is speaking from my experience many years ago. I have no idea what kids know or do not know today.

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

Re: Making readable modifyable code.

Thu Nov 24, 2016 12:59 am

Heater,

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

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

Re: Making readable modifyable code.

Thu Nov 24, 2016 1:16 am

Heater wrote: I believe that is why people were putting languages like Logo in front of young children back in the day.
By writing a Logo interpreter and linking it a robot, I passed both CS and electronics A level (on a BBC micro).

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

Re: Making readable modifyable code.

Thu Nov 24, 2016 1:44 am

@ZXDunny,

Wow, what machines are they using that Sinclair BASIC on?

@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" :)

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

Re: Making readable modifyable code.

Thu Nov 24, 2016 1:54 am

And to a beginner they're a godsend. A logical flow that's easily visible to anyone that can count. Yes, they mirror assembly language beautifully and make the transition from high level to low so much easier. "You see that BASIC code? Well asm is just like that, but the building blocks are much, much smaller. But so much more powerful".
WOW.

Yes line numbers in BASIC are a great tool for teaching algorithmic programming.

Even though ARM BASIC still uses line numbers, I have been using defined procedures for so long that I have not thought about line numbers in a while.

Though with a subset of BASIC using line numbers, you can do anything. You can construct any kind of loop with just IF cond THEN GOTO line at the bottom of the loop, and what ever is needed at the top of the loop. You can construct subroutines with GOSUB using what ever means of passing parameters you desire (although I am not sure of how you would do local variables in that case, unless you use an array and integer as a stack). And you can do an equivalent to a simple switch case simply using ON expression GOTO line.

I think you may have given me my project to be submitted when done, thank you. That is a very simple recursive decent subset of BASIC interpreter that uses line numbers, and has only the keywords (oops this one may take more than a week [though at least the expression parser, GOTO, IF-THEN and subset of PRINT should be working in a week]):
  • FOR TO NEXT STEP
  • GOTO
  • GOSUB RETURN 'Call subroutine/return from subroutine.
  • SCOPE ENDSCOPE 'Implement limited scope variables.
  • IF THEN ELSE 'Single line IF/ELSE
  • PRINT
  • INPUT
  • INKEY$
  • GETKEY$
  • OPEN#
  • CLOSE#
  • GET#
  • PUT#
  • INPUT#
  • PRINT#
  • READ DATA
  • PEEK PEEKW PEEKD
  • POKE POKEW POKED
  • VARPTR
  • DIM AS INTEGER REAL STRING 'Variable and array declaration.
  • ' 'Begin comment.
  • END 'Quit program.
  • GFX
  • LINE
  • COLOR
  • CIRCLE
  • PSET
  • GET
  • PUT
  • WINDOW 'Like in MS-QuickBasic for Macintosh (the MS-QuickBASIC version I know).
  • TYPE ENDTYPE 'Structured data types.
[/list]
And of course the standard set of 16 operators in most versions of BASIC.
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

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

Re: Making readable modifyable code.

Thu Nov 24, 2016 7:45 am

Can we use yacc (Yet Another Compiler Compiler) or bison (the GNU version of yacc)?

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

Re: Making readable modifyable code.

Thu Nov 24, 2016 11:12 am

Heater wrote:@ZXDunny,
Wow, what machines are they using that Sinclair BASIC on?
Regular PCs, using a utility called "BASin" (BASIC Interpreter) that emulates a ZXSpectrum with ROM hooks to integrate an IDE and tools. So basically, kids are writing simple code in BASIC (with line numbers!) in a very safe sandboxed emulated machine. This is BASin:

Image

Unfortunately it's Windows-only, so not available for the rPI. It's successor (SpecBAS) is available for the rPI, there should be some links to it somewhere on the forums.
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" :)
When I was at school I was told that computers were a passing fad, so I wasn't allowed to study them. It was expected that I would grow up to work on one of the neighbouring farms instead :)
DavidS wrote:Though with a subset of BASIC using line numbers, you can do anything. You can construct any kind of loop with just IF cond THEN GOTO line at the bottom of the loop, and what ever is needed at the top of the loop. You can construct subroutines with GOSUB using what ever means of passing parameters you desire (although I am not sure of how you would do local variables in that case, unless you use an array and integer as a stack). And you can do an equivalent to a simple switch case simply using ON expression GOTO line.
Exactly, which is precisely how it would be done in asm, no? The parallels are obvious, yet BASIC is ignored when teaching beginners. And by "beginners" I mean people who have had absolutely zero exposure to programming. How can anyone be expected to pick up Python or Java with no experience of how BASIC works? They must spend an inordinate amount of time in the classroom before they even begin to start coding. With BASIC, you can start on day one.

User avatar
PeterO
Posts: 4940
Joined: Sun Jul 22, 2012 4:14 pm

Re: Making readable modifyable code.

Thu Nov 24, 2016 11:30 am

ZXDunny wrote: How can anyone be expected to pick up Python or Java with no experience of how BASIC works? They must spend an inordinate amount of time in the classroom before they even begin to start coding. With BASIC, you can start on day one.
Running a code club in a primary school I have to tell you that you are wrong. Children pick up coding scratch much quicker that they could ever do with clunky old basic. Your nostalgia is clouding your vision.

PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

User avatar
DougieLawson
Posts: 35786
Joined: Sun Jun 16, 2013 11:19 pm
Location: Basingstoke, UK
Contact: Website Twitter

Re: Making readable modifyable code.

Thu Nov 24, 2016 11:31 am

I tend to think Edsger Dijkstra was right in his pontification about BASIC.
https://www.brainyquote.com/quotes/quot ... 01164.html

That Dijkstra quote works better when it's in the original context.
https://www.cs.virginia.edu/~evans/cs65 ... wd498.html

Python & Scratch may be insane, but they're in no way as insane as BASIC.
Note: Having anything humorous in your signature is completely banned on this forum. Wear a tin-foil hat and you'll get a ban.

Any DMs sent on Twitter will be answered next month.

This is a doctor free zone.

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

Re: Making readable modifyable code.

Thu Nov 24, 2016 11:37 am

PeterO wrote:
ZXDunny wrote: How can anyone be expected to pick up Python or Java with no experience of how BASIC works? They must spend an inordinate amount of time in the classroom before they even begin to start coding. With BASIC, you can start on day one.
Running a code club in a primary school I have to tell you that you are wrong. Children pick up coding scratch much quicker that they could ever do with clunky old basic. Your nostalgia is clouding your vision.

PeterO
We're moving the kids onto more advanced stuff like Scratch after they've learnt how code flows in BASIC. Exposing them before that just required more pre-code lessons. So far, it's doing pretty well and we have a lot of teachers reporting good results, so I'd say it's working.

User avatar
PeterO
Posts: 4940
Joined: Sun Jul 22, 2012 4:14 pm

Re: Making readable modifyable code.

Thu Nov 24, 2016 11:45 am

I think you are wasting your time with basic though. Scratch is designed to have no prerequisites, and IME it works well in that respect.
PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

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

Re: Making readable modifyable code.

Thu Nov 24, 2016 11:52 am

DougieLawson wrote:I tend to think Edsger Dijkstra was right in his pontification about BASIC.
https://www.brainyquote.com/quotes/quot ... 01164.html

Python & Scratch may be insane, but they're in no way as insane as BASIC.
At uni CS course languages like B were frowned upon because they were typeless. I suspect if a student even mentioned BASIC they would have been thrown off the course. We started with Pascal because it was an elegant, structured, strongly typed language.

There is nothing wrong with BASIC (Beginners All-purpose Simple Instruction Code) except for its age. Early Fortran was nearly as bad.
They have learned the lessons over the last 50 years of language design.

Here is an example of how bad/dangerous these old languages were.
In Fortran, this is a loop;

Code: Select all

do 10 i = 1,5
    ...
    ...
10
This iterates five times down to the label 10.
One day someone miss-typed the ',' in the first line to '.', it became

Code: Select all

do 10 i = 1.5
    ...
    ...
10
Fortran creates new variables on first mention, the type being set by the first letter and spaces are ignored within a variable name.
Fortran had (then) no closed control structures.
So this created a new variable called "do10i" initialised to 1.5.
The loop was executed just once, and the label 10 was ignored.

I think this caused a major spacecraft problem for NASA.

It cannot possibly happen with a modern language for a variety of reasons.

It is at least theoretically possible with some modern languages to prove that a program is correct.
It impossible, and no one would even try, with BASIC.

Dijkstra was right.

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

Re: Making readable modifyable code.

Thu Nov 24, 2016 12:47 pm

That's kinda not the point of BASIC though. People the world over insist that BASIC can be used for production code, and it cannot. It really can't. It has one purpose, and one purpose only - to teach beginners (and by that I mean absolute beginners) how program flow works. It's a sandbox that teaches how variables and loops work, but once you have those concepts down, you must move onto something that requires more rigorous discipline from the student - such as Pascal with its strong typing for example.

But some coders refused to believe that BASIC was just an instructional tool despite the clue in the name, and tried to take it in directions that were fundamentally opposed to that ideal. Hence we ended up with things like VB and actual professional coders writing crucial code in the wrong language.

For me, BASIC is a toy that I like to play around with - I can prototype algorithms much faster with it than I can even in Delphi (and certainly much faster than I can in C++ or asm!) but as far as using it for production code goes? Hell no.

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

Re: Making readable modifyable code.

Thu Nov 24, 2016 12:53 pm

jahboater,

Which is odd because CS departments used to teach in languages like lisp and scheme. No types there.

I wish I could find it again but I watched 20 odd CS lectures on youtube from MIT or Berkeley or somewhere. It was amazing. Using scheme the prof got people going from zero programming skill, and certainly no scheme knowledge, in only a few steps they were building lists, stacks queues, trees, all kind of things. And getting into all kind of funky recursive algorithms, parsers and so. They learned scheme as they went along.

Then I watched 20 odd hours of the new version of the same course. The new prof used Java. It was painful. He had to spend half the course teaching how Java worked before even starting on the actual CS meat of the course. The ideas the course was intended to teach were buried under a morass of irrelevant language detail.

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.

Types are useless. Sure they catch some errors at compile time. But if you are fussy about your code working properly you will be testing it. Covering all the code paths. Any type errors will pop out soon enough.

Your Fortran example, as given, is a case in point. I would argue that the problem there is that they never tested the thing!

Types are useless in other ways. At least as implemented in most languages. For example I can write:

int amps = 10;
int volts = 3;
int result = amps + volts;

See the problem there?

It's that kind of unit mismatch error that types do not catch and famously brought down the Mars Climate Orbiter.

In my dotage I'm having a downer on types. :)

Types lead to classes which leads to the mess that is C++ and Java. See how bad the idea of types is?

Of course you need types, or at least data sizes, in languages like those from Algol to C++ so that the compiler knows how much space to use for them on the stack. Those types are mostly there for performance and efficiency reasons.

I'm not sure Dijkstra's main beef about BASIC was it's types. BASIC is broken in so many other ways that is the least of the worries :)

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

Re: Making readable modifyable code.

Thu Nov 24, 2016 1:10 pm

ZXDunny,
For me, BASIC is a toy that I like to play around with - I can prototype algorithms much faster with it than I can even in Delphi (and certainly much faster than I can in C++ or asm!) but as far as using it for production code goes? Hell no.
Totally with you there.

In that respect Dijkstra was totally on the mark. Problem is you teach a bunch of people BASIC. Perhaps people for who programming and CS is not their main goal in life. They have other things to be getting on with. So when you are done BASIC is what they think computing is. There is nothing else.

And whilst you are doing that, BASIC is hiding from them the big wide computing landscape, thus they never get inspired to explore further.

Then we end up with a world full of VB!

Anyway, Javascript is the new BASIC for many now. Thankfully whilst JS is dead easy for beginners to start with it's also a pretty sophisticated language.

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

Re: Making readable modifyable code.

Thu Nov 24, 2016 1:34 pm

Heater wrote:Which is odd because CS departments used to teach in languages like lisp and scheme. No types there.
No, we were taught lisp as well of course, and Fortran, COBOL, and Ada etc. Our lecturers came from industry - they knew perfectly well that lisp wasn’t used for production code in the real world.
Heater wrote:Then I watched 20 odd hours of the new version of the same course. The new prof used Java. It was painful. He had to spend half the course teaching how Java worked before even starting on the actual CS meat of the course. The ideas the course was intended to teach were buried under a morass of irrelevant language detail.
But lots of code in the real world is written in Java. Far more code is written in Java than Scheme. At uni I guess they are not interested in quick results. Its worth spending the extra time to teach people to program properly in a proper language.
Heater wrote:Types are useless. Sure they catch some errors at compile time. But if you are fussy about your code working properly you will be testing it. Covering all the code paths. Any type errors will pop out soon enough.
Or might not. Even been to a customer demo? The customer says "can it do this?" which the programmers/test dept never thought of - and it crashes.
Heater wrote:Your Fortran example, as given, is a case in point. I would argue that the problem there is that they never tested the thing!
Or they never tested that path. I'm sure NASA tested their code as far as humanly possible.

Thinking you can solve all programming problems by thorough testing is a mistake. The program should be designed and written properly in the first place. Programmers do always make mistakes, the more mistakes that can be caught by the compiler or other static analysis tools the better - and that is enabled by a good modern language. Having said that, there are tools like gcov (see man gcov) for automatic test coverage generation that can help ensure as much of the code as possible is tested.
Heater wrote:Types are useless in other ways. At least as implemented in most languages. For example I can write:

int amps = 10;
int volts = 3;
int result = amps + volts;

See the problem there?
Strong typing only picks up just one class of errors. There are obviously many others - as here. In this case it would fail in any programming language.

You seem to be fixated with types!

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

Re: Making readable modifyable code.

Thu Nov 24, 2016 2:29 pm

jahboater,

I guess it depends what one expects from a Computer Science education. Is it about learning a bunch of languages that may get you a good job at the end of the day? Or is it about, well, computer science?

I could argue that having to teach programming languages to CS undergraduate is as daft as having to teach arithmetic to Mathematics undergraduates. They should already be proficient in a language or two before they even get there. Listening to Eben Upton talking about his time in Cambridge that used to be the case, but then it was noticed that increasingly students were arriving who had no idea and they had to start from scratch. A big waste of time in a CS department. That is what inspired Eben to create the Pi!

I'm all for teaching CS students to program properly. To think about program construction etc. That does not mean having to use the language of the day just because that is what industry is stuck with at the time.

I love a customer demo. You never know what is going to happen !
Or they never tested that path. I'm sure NASA tested their code as far as humanly possible.
Hmm... My experience in testing avionics software tells me that testing 100% of code paths is possible, indeed it was required. It's much easier to do if the code is designed and written in a way, and in a language, that makes it testable. The Lucol language was the best for this. Ada the worst. God help those using C++.
Thinking you can solve all programming problems by thorough testing is a mistake. The program should be designed and written properly in the first place.
Totally with you there. However in the space of all possible errors, type checking only helps in one small corner. A corner that will show up almost immediately in testing anyway.
Strong typing only picks up just one class of errors....
Yes. See above. Strong typing does not buy you much.
You seem to be fixated with types!
Oh yeah. One of the first things you are taught when studying physics is "dimensional analysis". https://en.wikipedia.org/wiki/Dimensional_analysis Such that when you are wading though a pile of mathematics, trying to prove this or that, it's a good idea to check that the units are being used in the right way. If your finished equation ends up adding a time to a mass then you know you have screwed up somewhere along the line.

As such I used to be a great fan of types in programming languages.

Only recently did I start to realize that they don't help at all.

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

Re: Making readable modifyable code.

Thu Nov 24, 2016 2:48 pm

Heater wrote:I guess it depends what one expects from a Computer Science education. Is it about learning a bunch of languages that may get you a good job at the end of the day? Or is it about, well, computer science?
The latter of course, but at the same time they did also want CS students leaving the university to be able to program. Only part of the first year was spent on it.
Heater wrote:It's much easier to do if the code is designed and written in a way, and in a language, that makes it testable. The Lucol language was the best for this. Ada the worst. God help those using C++.
That's a sad insight considering the enormous amount of money and six years the DoD spent developing Ada!
Heater wrote:As such I used to be a great fan of types in programming languages.

Only recently did I start to realize that they don't help at all.
Is that when you started using JS?

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

Re: Making readable modifyable code.

Thu Nov 24, 2016 3:30 pm

jahboater,
That's a sad insight considering the enormous amount of money and six years the DoD spent developing Ada!
Ada is great and all but...

When you are building avionics systems or any kind of control system, you find you are working to tight timing deadlines. Every iteration of a control loop must be done in 100ms or 10ms or whatever. Miss your deadline and you are lost.

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?

That same company switched to Ada. Hmmm...How long do the interrupt handlers and such take to execute now? What is the worst execution time of your control loop? Compiler does not tell me. There is no source analysis tool that can.

So I pull up a logic analyzer or even oscilloscope and measured it. Wow, totally random. Often exceeding the 50% safety margin. Sometimes getting to 90% of the time budget.

So I ask the software team leader: How can we verify that your code will never exceed it's time budget? Stony silence... As he realizes that what has been created over years at great expense is totally unpredictable and impossible to reason about.
Is that when you started using JS?
These things are sort of coincident in time. But I would not say there was a cause and effect relation between them. My use of JS was an accident of necessity at the time. Lucol, a language specifically designed for creating safety-critical, hard real-time, had precious little idea of types. Perhaps I just did not think about it so hard at the time.

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

Re: Making readable modifyable code.

Thu Nov 24, 2016 3:43 pm

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.

Clearly Ada was the wrong language. Much effort went into making it safe as in fewer errors, but not hard real-time.

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

Re: Making readable modifyable code.

Thu Nov 24, 2016 3:57 pm

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.

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.

Return to “General programming discussion”