Lucol was totally brilliant for it's simplicity, timing determinism, and ease of analysis. Rock solid.
I don't know about "key to the future". That was two or three decades ago. Lucol is extinct now. As far as I know it was an in house language and only ever used within that one company.
Programmers pretty much all hated it, "What, no loop constructs, that's nuts...and where are my pointers...and why can't I write recursive functions....". Only a few of them seemed to really understand why it was designed that way, with so many restrictions, and appreciate the brilliance of it. They all wanted contracts writing C++ and Java!
I bet Lucol would have been easy to present to a novice, though.
The real-time problem needs some kind of timing-determinant solution. None of the methodologies today are heading in that direction, as far as I can tell, but I don't know a lot.
It's like the whole world has gone in one direction and that direction has created unspoken strictures that people can't seem to think around, as they suppose they are aware of all that is, or could be. It's like political correctness, where control of language results in control of thought, which controls outcomes.
It would be neat if there was some compelling real-time programming solution for the Prop2. I wonder if it's becoming almost impossible, though, as too many things that must be connected to, already, cannot be made real-time, and are inescapable weak links.
What, no loop constructs, that's nuts...and where are my pointers
Funny, they had all of those things in their data, if they chose. As the data gets processed from state to state, counters, loops, pointers to other data, all possible. Just not as explicit program statements. An easy way for me to visualize that is that "game of life" where simple, unchanging rules operate on data, and it's in the data where all the states, etc... emerge.
What, no loop constructs, that's nuts...and where are my pointers
Funny, they had all of those things in their data, if they chose. As the data gets processed from state to state, counters, loops, pointers to other data, all possible. Just not as explicit program statements. An easy way for me to visualize that is that "game of life" where simple, unchanging rules operate on data, and it's in the data where all the states, etc... emerge.
Yeah. I think to do real-time programming, you have to embrace some stricture and go with it. Loops and things are 'fantasy land' in real-time circumstances. You have to move to states. It's work, but the code works like a machine, afterwards. That VocalTract PASM code was completely like that. It was one of the most rewarding and fun things I've ever programmed.
I'll have to go back and look at that one. States are often hard for me to visualize. Or maybe, it's just hard, because the other things are there, more obvious, explicit?
I seem to visualize loops, pointers, etc... fairly easily. It's a lot harder for me to see those things in state terms. That's one of the nifty things about that "game of life" automata. That stuff emerges, and the first time one sees it happen, it's very thought provoking.
Well done you found something, even if it is misnamed, it's "LUCOL" not "LUCOR". What a blast from the past.
I'm surprised that paper does not emphasis the timing analysis and guarantees provided by LUCOL so much, I always though that was one of it's key features. Unique to this day as far as I can tell.
From the paper:
"The function of a module must be sufficiently
simple to enable it to be tested automatically by
setting inputs and reading outputs without resorting
to breakpoints or checking intermediate calculations. "
There we have it. State in, new state out, no local storage in a module, no secret loop counters, no side effects, etc. Purely Functional Programming. Makes testing dead easy. Ensuring 100% test coverage is possible. Makes getting those execution times a doddle for the compiler to calculate.
Having worked for a year or so on the other side of the fence, testing, I was amazed how we could write unit tests, from the design documentation, that could cover every possible execution path in the entire program without ever seeing the source code we were testing.
Interesting times, one project was a smart actuator upgrade for the Lockheed C130 (I think it was). One Monday morning I arrived at the office a hour late and everybody seemed to be working a lot harder than normal for a Monday morning. Story was we had shipped a new version of our code that had not had all the new feature tests run or even written yet. The deal was it was to be using for taxi testing only. Crazy Yanks were fly the the thing. Panic!
Then there was the Rolls Royce Trent engine ECU.
Other guys there were building an ECU for Volvo cars, forget which model, they explained to me how they put tweaks into the code to detect when fuel consumption tests were being run on the car and lean the fuel mixture accordingly....does this sound familiar?...
...
Other guys there were building an ECU for Volvo cars, forget which model, they explained to me how they put tweaks into the code to detect when fuel consumption tests were being run on the car and lean the fuel mixture accordingly....does this sound familiar?...
Hehe, so this has been done for generations ? ( Compilers that spot benchmark code anyone ? )
This whole issue is more a reflection of poorly designed testing, than anything else, as all engines are adaptive these days.
If the wallies have a test that is not properly reflective of real road conditions, then they can hardly feign shock when the results are not the same as real road use.
If the wallies have a test that is not properly reflective of real road conditions, then they can hardly feign shock when the results are not the same as real road use.
I kind of agree. The tests and regulations are pretty dumb.
But I don't see how one would devise "real road use" tests that are not rigorously specified in minute detail. As they should be to ensure fairness between manufacturers, repeatability and generally sound scientific principles.
At which point a manufacturer can always get his software to detect when such a test is in progress.
It does not help.
It would have been better if the regulators said "show us the code" and "prove to us that the code we see is what gets built into the cars".
I suspect this will come to pass eventually. In cars and other products.
If the wallies have a test that is not properly reflective of real road conditions, then they can hardly feign shock when the results are not the same as real road use.
I kind of agree. The tests and regulations are pretty dumb.
But I don't see how one would devise "real road use" tests that are not rigorously specified in minute detail. As they should be to ensure fairness between manufacturers, repeatability and generally sound scientific principles.
At which point a manufacturer can always get his software to detect when such a test is in progress.
It does not help.
I'm not sure it is that hard.
The test failure, as I understand it, seems to be to not load the engine (thus allowing leaner fuel), so if they plotted emissions against horsepower, on a common dyno test system, that seems hard to game.
I believe they are moving, somewhat belatedly, to such tests.
One could say a shift to leaner fuel in light loading, is not a failure at all, but exactly what the engine should do.
It's kind of a mess. One trouble I see is the testing is done by the vehicles to a large degree. In my state, they just take the vehicle data, perform a cursory test, like "hey, it smokes!" and off you go.
I have a Ford and Kia that have the OBD2 system, and they log a lot of stuff. Fun stuff. Frankly, I thought I knew how to drive both cars efficiently. A few runs with the laptop improved my MPG by a lot. Measured in miles per full tank, not the car.
Anyway, a while back, the State did actually do independent tests. Cars were failing all over the place! People went nuts, and it all got ripped out.
Jmg is right about the dynos. Those are what the independent test group here used. Failed a ton of cars. Even really new ones. Some off the lot. Maybe now we know a little something about why.
The test was aggressive too. There was this speed plot you could follow, or you could have them do it. Was kind of fun.
You watch the plot, and a dot moved along it and you kept it in the zone. Mostly. A little error was OK, and they claimed to factor it out.
That plot had a nice ramp up, sustained load, then two or three rapid up down, drop, load segments, an idle and another more rapid ramp, ending in a quick drop to idle. I recall it being 3 to 5 minutes long, with a full minute if idle, no load at the end.
Put car in drive, and operate the gas.
The rapid section was the major fail for most cars. When you drive, watch for the little puffs in hard traffic. A ton of cars do it.
Thankfully I live in a area of California where you just need to do the emission tests on change of ownership.
But working remote for most of my life I do not drive much anyways. Say 1.500 miles per car and year, or so. All of them cars are 20+ years old.
No problems with rust here in California. Just the paint burns off...
But them Mercedes V8 Engines (M119) out of 199X' are kind of picky anyways until they run really neat, and if you tune them right, you can pass emission test any time, if it would be needed.
But the 500SL or SL500 series of roadster from MB where the high end of MB products in 199X. No need to cheat, plenty of horsepower anyways. But being old cars I decided to get more then one of each, just to have spare parts if needed.
The only problem is that my single leftover Irish Wulfhound does not fit in, in either of them roadsters.
Heater mentioned functional programming, and I found most entry references obtuse. Carmack lays the foundation ideas out here in a pretty useful to think about way. My realization here is those ideas can be applied in many contexts, and in many languages and environments.
Even when those ideas aren't the focus of said environments.
Certainly seems that Functional Programming has been an impenetrable idea for ages. It's supporters tend to be very academic and insistent on one using their super weird Function style only (pure) languages.
One can adopt Functional programming practices in many languages. Perhaps all. But like Object Oriented Programming it helps a lot if your language has support for it and enforces it.
As Carmack says, one can do FP in C++. C++ offers great support for Objects with internal state, totally the opposite of FP. How to balance FP with OOP in your programs?
I'm writing a simple game in PASM, and managing state is something I always find difficult. This one uses lists and a single display buffer. I know Baggers is going to drop some insane great sprites on us, so I thought a nice blitter would be fun in the meantime. Works with the almost free bitmap display support we have now. (Thanks for the color engine and streamer Chip)
This time, I made it work on lists, and in a way, doing that is a lot like the 3D world and GPU being discussed here, but much simpler.
In the past, managing those was always a pain. When to render them, when to change them, etc... race conditions and clock speed dependencies abound, when the truth is it should just go slower on a slower clock when done in a more functionally pure way, but the reality is failure.
The functional path means the list is given, or is created by a function. I might just type in the start screen list, because it is always the same, and the player function would give me the player list, given input a, b, c... for example.
The display always looks at it's pixel list, a bitmap. The bitter will always draw from a static list, etc... it is either a new list, or the same list, never a changed one, which introduces list state problems. I did not understand that before. Cool beans.
The order and state of things becomes much more clear and easy to reason about.
So I will, this time, never change one. It is either useful, or a new one gets created, and the old one is discarded, or just overwritten for memory management reasons. I can see now how much simpler having multiple COGS do things, if this exercise requires that, can be. I may just do it anyway to explore this some.
This does take more working RAM, and involves making copies more.
So, it's interesting. On the tiny P1, doing it all dynamically makes sense. There isn't much room to be functional, which means timing and constantly changing data may be the norm for performance reasons.
Fair enough, the pure cannot be the enemy of the possible. But the possible can benefit from the pure.
On the P2, for this project, there is room to be more functional as the upper limits are much higher.
Obviously, one point Carmack made on purity is the need to talk to the world, and sometimes the need to perform magic will break the paradigm. That is OK. But where it can be more pure, there are gains to be had, even in something basic and close to the metal like PASM is.
Neat!
(I'll share the gory mess at some usable point)
I also think the concept of a COG is pure. Or more pure than just having multiprocessing in a shared memory environment. The COG makes a copy of the state it finds in the HUB. And a COG is not really any different from the other ones. In a way, this is functional, due to how the COG workings are packaged, and how data and parameters can get passed.
If we think of a bit of code intended for a COG in a functional sense, it, and it's data could be processed by any number of COGS, which is easy parallelism.
Or, easy reuse too. I will attempt this with little support routines and see what I learn.
When you can't decide on a programming paradigm, try Falcon.
Falcon provides six integrated programming paradigms: procedural, object oriented, prototype oriented, functional, tabular and message oriented. And you don't have to master all of them; you just need to pick the ingredients you prefer, and let the code follow your inspiration.
Thinking through the functional ideas did very quickly get me to a place of minimum change of both state and list data. Now, this program is PASM, so it is not a direct application.
Can it even be? I don't know.
But what I experienced was a lot like a code refactoring early on. There is a fair amount I thought I needed to write. IMHO, this isn't a bad way to think. Now I'll see what comes of it. But the project looks smaller and simpler to me right now.
Comments
I bet Lucol would have been easy to present to a novice, though.
The real-time problem needs some kind of timing-determinant solution. None of the methodologies today are heading in that direction, as far as I can tell, but I don't know a lot.
It's like the whole world has gone in one direction and that direction has created unspoken strictures that people can't seem to think around, as they suppose they are aware of all that is, or could be. It's like political correctness, where control of language results in control of thought, which controls outcomes.
It would be neat if there was some compelling real-time programming solution for the Prop2. I wonder if it's becoming almost impossible, though, as too many things that must be connected to, already, cannot be made real-time, and are inescapable weak links.
Funny, they had all of those things in their data, if they chose. As the data gets processed from state to state, counters, loops, pointers to other data, all possible. Just not as explicit program statements. An easy way for me to visualize that is that "game of life" where simple, unchanging rules operate on data, and it's in the data where all the states, etc... emerge.
Yeah. I think to do real-time programming, you have to embrace some stricture and go with it. Loops and things are 'fantasy land' in real-time circumstances. You have to move to states. It's work, but the code works like a machine, afterwards. That VocalTract PASM code was completely like that. It was one of the most rewarding and fun things I've ever programmed.
I seem to visualize loops, pointers, etc... fairly easily. It's a lot harder for me to see those things in state terms. That's one of the nifty things about that "game of life" automata. That stuff emerges, and the first time one sees it happen, it's very thought provoking.
So, I googled this thing, and came up with a pretty nice PDF describing the system, and how it's implemented.
Well done you found something, even if it is misnamed, it's "LUCOL" not "LUCOR". What a blast from the past.
I'm surprised that paper does not emphasis the timing analysis and guarantees provided by LUCOL so much, I always though that was one of it's key features. Unique to this day as far as I can tell.
From the paper:
"The function of a module must be sufficiently
simple to enable it to be tested automatically by
setting inputs and reading outputs without resorting
to breakpoints or checking intermediate calculations. "
There we have it. State in, new state out, no local storage in a module, no secret loop counters, no side effects, etc. Purely Functional Programming. Makes testing dead easy. Ensuring 100% test coverage is possible. Makes getting those execution times a doddle for the compiler to calculate.
Having worked for a year or so on the other side of the fence, testing, I was amazed how we could write unit tests, from the design documentation, that could cover every possible execution path in the entire program without ever seeing the source code we were testing.
Interesting times, one project was a smart actuator upgrade for the Lockheed C130 (I think it was). One Monday morning I arrived at the office a hour late and everybody seemed to be working a lot harder than normal for a Monday morning. Story was we had shipped a new version of our code that had not had all the new feature tests run or even written yet. The deal was it was to be using for taxi testing only. Crazy Yanks were fly the the thing. Panic!
Then there was the Rolls Royce Trent engine ECU.
Other guys there were building an ECU for Volvo cars, forget which model, they explained to me how they put tweaks into the code to detect when fuel consumption tests were being run on the car and lean the fuel mixture accordingly....does this sound familiar?...
This whole issue is more a reflection of poorly designed testing, than anything else, as all engines are adaptive these days.
If the wallies have a test that is not properly reflective of real road conditions, then they can hardly feign shock when the results are not the same as real road use.
This is business we are talking about, you know, capitalism, profit, do whatever it takes to sell your stuff and get money.
There is a reason why Richard Stallman has been harping on about open source, Free, software for decades.
But I don't see how one would devise "real road use" tests that are not rigorously specified in minute detail. As they should be to ensure fairness between manufacturers, repeatability and generally sound scientific principles.
At which point a manufacturer can always get his software to detect when such a test is in progress.
It does not help.
It would have been better if the regulators said "show us the code" and "prove to us that the code we see is what gets built into the cars".
I suspect this will come to pass eventually. In cars and other products.
The test failure, as I understand it, seems to be to not load the engine (thus allowing leaner fuel), so if they plotted emissions against horsepower, on a common dyno test system, that seems hard to game.
I believe they are moving, somewhat belatedly, to such tests.
One could say a shift to leaner fuel in light loading, is not a failure at all, but exactly what the engine should do.
I have a Ford and Kia that have the OBD2 system, and they log a lot of stuff. Fun stuff. Frankly, I thought I knew how to drive both cars efficiently. A few runs with the laptop improved my MPG by a lot. Measured in miles per full tank, not the car.
Anyway, a while back, the State did actually do independent tests. Cars were failing all over the place! People went nuts, and it all got ripped out.
Maybe those tests were competent...
The test was aggressive too. There was this speed plot you could follow, or you could have them do it. Was kind of fun.
You watch the plot, and a dot moved along it and you kept it in the zone. Mostly. A little error was OK, and they claimed to factor it out.
That plot had a nice ramp up, sustained load, then two or three rapid up down, drop, load segments, an idle and another more rapid ramp, ending in a quick drop to idle. I recall it being 3 to 5 minutes long, with a full minute if idle, no load at the end.
Put car in drive, and operate the gas.
The rapid section was the major fail for most cars. When you drive, watch for the little puffs in hard traffic. A ton of cars do it.
But working remote for most of my life I do not drive much anyways. Say 1.500 miles per car and year, or so. All of them cars are 20+ years old.
No problems with rust here in California. Just the paint burns off...
But them Mercedes V8 Engines (M119) out of 199X' are kind of picky anyways until they run really neat, and if you tune them right, you can pass emission test any time, if it would be needed.
But the 500SL or SL500 series of roadster from MB where the high end of MB products in 199X. No need to cheat, plenty of horsepower anyways. But being old cars I decided to get more then one of each, just to have spare parts if needed.
The only problem is that my single leftover Irish Wulfhound does not fit in, in either of them roadsters.
Enjoy!
Mike
Heater mentioned functional programming, and I found most entry references obtuse. Carmack lays the foundation ideas out here in a pretty useful to think about way. My realization here is those ideas can be applied in many contexts, and in many languages and environments.
Even when those ideas aren't the focus of said environments.
Certainly seems that Functional Programming has been an impenetrable idea for ages. It's supporters tend to be very academic and insistent on one using their super weird Function style only (pure) languages.
One can adopt Functional programming practices in many languages. Perhaps all. But like Object Oriented Programming it helps a lot if your language has support for it and enforces it.
As Carmack says, one can do FP in C++. C++ offers great support for Objects with internal state, totally the opposite of FP. How to balance FP with OOP in your programs?
This time, I made it work on lists, and in a way, doing that is a lot like the 3D world and GPU being discussed here, but much simpler.
In the past, managing those was always a pain. When to render them, when to change them, etc... race conditions and clock speed dependencies abound, when the truth is it should just go slower on a slower clock when done in a more functionally pure way, but the reality is failure.
The functional path means the list is given, or is created by a function. I might just type in the start screen list, because it is always the same, and the player function would give me the player list, given input a, b, c... for example.
The display always looks at it's pixel list, a bitmap. The bitter will always draw from a static list, etc... it is either a new list, or the same list, never a changed one, which introduces list state problems. I did not understand that before. Cool beans.
The order and state of things becomes much more clear and easy to reason about.
So I will, this time, never change one. It is either useful, or a new one gets created, and the old one is discarded, or just overwritten for memory management reasons. I can see now how much simpler having multiple COGS do things, if this exercise requires that, can be. I may just do it anyway to explore this some.
This does take more working RAM, and involves making copies more.
So, it's interesting. On the tiny P1, doing it all dynamically makes sense. There isn't much room to be functional, which means timing and constantly changing data may be the norm for performance reasons.
Fair enough, the pure cannot be the enemy of the possible. But the possible can benefit from the pure.
On the P2, for this project, there is room to be more functional as the upper limits are much higher.
Obviously, one point Carmack made on purity is the need to talk to the world, and sometimes the need to perform magic will break the paradigm. That is OK. But where it can be more pure, there are gains to be had, even in something basic and close to the metal like PASM is.
Neat!
(I'll share the gory mess at some usable point)
I also think the concept of a COG is pure. Or more pure than just having multiprocessing in a shared memory environment. The COG makes a copy of the state it finds in the HUB. And a COG is not really any different from the other ones. In a way, this is functional, due to how the COG workings are packaged, and how data and parameters can get passed.
If we think of a bit of code intended for a COG in a functional sense, it, and it's data could be processed by any number of COGS, which is easy parallelism.
Or, easy reuse too. I will attempt this with little support routines and see what I learn.
Lots of fun ideas in that Carmack piece, IMHO.
It's always about taking the ideas and working with them anyway.
Can it even be? I don't know.
But what I experienced was a lot like a code refactoring early on. There is a fair amount I thought I needed to write. IMHO, this isn't a bad way to think. Now I'll see what comes of it. But the project looks smaller and simpler to me right now.