While I agree witht he author, I think retro will make huge comeback.
See, we started out with only integer units in 2 dimentional space. As time progressed, we got into bigger 2D space (from 4 bits to 32, now 64) We also got floating points thanks to FPUs. (Games were why FPUs became standard issue). But we were still in 2d space. Some were side scrollers, some were top-down, some were persective. Then Wolfenstien 3D came out. Doom then Quake pushed 3d accelerators to the desktop. But then we could interact in a world that we relate to in very real ways.
Next up we'll find theres more challenge in moving in 2 dimensions than 3. That'll help preserve the novelty. But they must remain challenging.
That brings me to the non-retro gaming success story. Masting 3d space is easy, master 2d space a easier (as a subset of 3d space) but 4d and 5d space will be where the fun is.
Video games a are all about challenge. Once you get your physics model and coordination down, you are left with one thing: solving the intelectual challenges. This is why so amny people play RPS still. Generally it's kill, loot, goto kill, level, repeat. EQ has quests which are mildly intelectually challenging.
All of 3d gaming can be rendered easy via circle-strafing. Strafe side-to side while turning and you'll always face your target and circle them. I have not seen a 3d shooter that isn't rendered easy by this technique. Once it no longer works, I'll be intelegtualy challenged to find the bug in the AI or physics model (grenade jumping) that trivializes the game. (I used to be a sniper in Quake - TF - and a good one at that, but what I did became proceedural, nd I lost intrest. Grenade and rocket jumpers were all the same. I'd get them in mid-air 99% of the time.)
Indeed the industry has been relying on glitz and glamor to sell, much like a hot whore. But no one marries a whore, they marry people that are intelectually stimulating. ANd that's going to be the next games. The mind-puzzles. Tomb Raider, Tetris, etc. They all have sppeal for a long time, until the *DESIGNERS* turn it proceedural. It's not the fault of the tech, it's because the designers get lazy.
Escapr from reality, the use of imagination, is why people turn to video games. I predict in 10 years that no video game will ever do the same game twice (like they do today) I bet they won't keep staff around either. Every game is a new team, and no one is allowed to be on the same type of game project as they were on in the past 5 years. This will keep innovation and imagination high.
The other idea is working with other people. When C&C has IPX multiplayer, we played it non-stop weekends at a time. Quake was plaued for weekends at a time. I spent most of my nights on TF maps with my clan. Human interaction is unpredictible (well, a lot less than a computer) (Imagine basketball vs chess, what is more popular)
Killer app of today: The Sims Online. Features imagination, creativity and human interaction. Runner Up: EQ.
Killer app of tomorrow: solving puzzles with other humans online. But the puzzles can't repeat, not even the same type. Maybe a puzzle is to make a puzzle for others to solve - taking turns between puzzlemaking and solving. (An offshoot of this is OpenSource... )
If hubble can see into the distant past by pointing it to the center of the universe, we should be able to poit it outward and see into the distant future. Given the high visual acuity of Hubble, it should be able to see the outcomes of future horse races. Then NASA can bet on that and gamble to get the extra cash needed to keep it operating.
Put these users on their own vlan. Give them access to their web email servers and send them a message with a download link to fprot or whatever virusscan package is out there. Let them download it. Once the spamming stops, put them back on the regular internet.
1: if the harpoon doesn't get a good hold, the probe probably will drift away from the comet. Getting the probe that close in the first place will still be a huge achievement, and it'll still return useful data. We've already done that. Flybys and collect dust, it's no big deal these days!
2: It's a comet. An orbital ice-berg that's been bashed around for billions of years. A little harpoon isn't going to break it in half. Might smash a small chunk off, but it won't split the comet in half.
Right Shoemaker-Levvy was supposed to hold together, but got ripped apart from tidal forces. Those forces are not that great, and are very small and smooth in comparison to being harpooned. harpooning is a rather sudden and aburpt force.
3: The lander's heading toward the comet already, the harpoon launch recoil (assuming there is any) is unlikely to overcome the probe's momentum. And it is probably a small rocket harpoon, with practicaly no recoil.
Well this is the eastting to plan for.. knowing the mass of harpoon and probe, we can provide specific amount of force to acheive exactly what we want.
As for the drill-and-screw...a harpoon would be far more likely to get the initial hold. It's a quite well understood technology. On Earth, drilling typically requires rather firm support for the machinery doing the drilling. For the probe, it would require maneuvering up to the comet and holding position next to it while it attempted to drill in an anchor, at a distance from any human which makes real-time remote control impossible. Plus, it would be far more mechanically complex, a lot heavier, and a lot more power-hungry. The harpoon could use a small solid-fuel rocket, the drill would require a motor and power supply to run it. Not to mention the fuel required to hold the probe in place while drilling.
It's all realtively easy. Get out infront of the thing, activate retro rockets and constantly decel against the ting to keep you planted. While tou do that you drill ing several CM (It doesn't take my dewalt long to drill through solid ice (Particualrly if the bit is heated). Using several small bits, each one at a differnt angle ('toed' in) you'd have yourself a very stable base in seconds.
This idea is just sooo bad. You're going to launch harpoon at a block of ice and hope it sticks? What is to say that: 1) The harppon doesn't glance off 2) the harpoon fractures the ice in 1/2 (or less) 3) The launch of the harpoon sends the lander flying backwards, the impending jerk at the end of the cord pulls it back out of the ice (assuming it attaches securely in the first place) or damages the lander.
It just sounds like a 1 in a billion shot to me. (No pun intended. I'd think a drill-in and screw-in would me more reliable.
It's a bunch of BS to get people to let this big brother in the car.. then ZAM it'll start to be abused.. Just like OnStar was. OnStar gor saved via a tecnical detail, but if they had multiple audio out channels, it's still be abused today.
The fact is, it's US thats the problem. We employ a greedy and not cooperative strategy on the roads. They did research around here, and they found that all the highways were completely cpable of handling the volume of traffic at rush hour. It's out driving that creates backups.
And don't get me started about RUBBERNECKERS! ARH.
People here are some tips: 1) Don't rummberneck, mangled metal is fun, but it's none of your business. 2) Don't tail gate, leave good room. Tailgating makes you slam on your brakes, so the guy behind you needs to slam arder, and so on, until people are locking up anc causing more accidents. 3) When in a backup let the gap be made. Don't floor it to the next guys bumper then brake hard 1) it wastes gas 2) you repeat #2. I've seen "averagers" - peopel who average the flow out create a huge difference. And I think we all rather me slow and steady rather than stop-and -go. If you are a stop and go person: remember: 1) all that gas used to get up to speed gets wasted when you put on your brakes, 2) you waste more brakes killing the effect of overusing gas 3) you create more changes in speed which is more changes for a rear-end collision by another unattentive driver. We handle things if they are steady. 4) Get over early. You having to slow down your lane so you can get over in a hurry, slows down your lane and causes others to change lanes. 5) minimize lane changes. Each one is a time when you a leagally vulderable. When you change lanes, right of way is with the person who is already there. And we all know about 2 people, one moveing left, the other right, that don't see each other.
That shoudl take care of 90% of the problems on the road.
Darl said he is there to increase and protect the shareholder value. This since they "legally" have NUMA and such, they then have to prevent otehrs from having it, including Linux. BUT they can only benefit if they have their own product to ship with it.
While I can see people thinking they just want to tax linux, it can't ever come to that. If SCO drops their own unix distributions, then Linux is the only source for that technology. They could right fully tax it, however I don't think any kernel developer would allow that to happen. If it did, I'd expect the kernel developers to rip out the contested peices and force SCO to actually sell and maintain something themselves. If this trend continues then they won't be selling much at all. Eventually, they'd go bankrupt just like they are now, and as soon as that happens and there's no hostile legal entity, the developers would put it back in.
But this all assumes they have a right to what they claim.
I think Big Blue knows this, which is why they are not trying to resolve this switftly. The longer SCO flounders, the closer to bankruptcy they get. Which means IBM will buy them up at the last minute for cheap or let them die completely, rather than buying them at todays much inflated price. SCO is on stilts, on a ledge. It's just time before they crash. We're in the death-throws of a company.
MMM a big steaming pile of crap. SCO forgot that an OS is nothing without apps. So as these apps start revoking themselves fromt he SCO distrib, the value of their product falls, along with the stock price, which is the exact opposite of what Darl wanted to do...
Looks like he'll prove himself the fool. I do feel bad for his family. He could have been something some day.
Why don't you write and use a library for this? It's not that difficult to do and if most platforms you deal with have the same byte order and alignment conventions then you can optimise for that case. Perhaps you could have the library juggle the bytes in-place and, if sending, optionally juggle them back before returning. The juggling would be a no-op on most platforms.
Eaiser said than done. Use the Communication task must then know everydata format there is, then have code to patch it up. It's CPU cyles being wasted completely unessessarily, plus it adds complexity. The more time you spend fixing up your data, the less time you spend oding whatever the real function of the device is.
It really sucks when you have to waste cycles going through 1M of ram swapping bytes around, for the mere sake of intel. Plus do you know what that does to the schedular? 2.6 isn't so bad, but 2.4 it obliterates responsiveness.
In embedded space we neither have time time nor resources to do this, yet we do. The biggest cost is finding and fixing the software bugs because of it. It's not a file format issue, it's a communication issue, Serial, Network, etc. I massively hurts not being able to alloc a block of mem and just dump it over the wire- one side wil write big endian out, and the other will read it in as little endian.
Until you work with these problems first hand you won't appreciate how dumbit is that everone but x86 does big endian.
Ah, I remember PPC being able to do both too now that you mention it. So IA64 supports it, but does x68-64?
Well it _CAN_ do big or little endian, its up to the whim of the designer. Which only drives my point.. we need to stardardize our endians! Network byte order is already big endian...
Everting as ALL & (~Intel) MIPS, PPC, ARM, ALPA, SPARC, SH, the list goes on to include everything still being made, minus x86.
I work with big-endian CPUs all day, and we always have to work aoround this. It's be great if we could just do a binary transfer of data, but no, we have to go back in, find the numbers, and swap it all around. Then swap it back before going to the device. x86 is the only architecture being manufactured and used that is little endian.
While they add new opcodes, why not throw one in there (or use a bit) for byte-swapped data? You could use one pit of instruction to indicate to run it through a byte-swapper (easy to implement) before and after math/compare is done with it.
Seriously people, everything but x86 is Big endian, and we (embedded software people) have endian issues all the time. Wil there finally be 32 and 64 bit big endian instructions?
I highly doubt the vehicle is that autonomous that they can say, "heay, head off bearing 110 deg, for 50m and take photos of interesting things along the way"
I always figured that mission control would give it vector commands like that, but that any kind of inspection would be manually done by instructions from mission control?
I can understand that it might have some self-preservation features, like slow down if too much wobble, or if grade is steep, but it seems like that things is really calling the shots.
Maybe we're not as far as logn as we thought, a la Stanly Kubrik's 2001 space oddesy.
AEM makes a product called the EMS. It's a swap-out replacement for your ECU. Most models are supported, and it can run 4-10 cylinder cars. EVERY engine parameter is configurable, plus you can program it to do new things, like turn up the radio when the windows go down.
It willalso add throlle control, mathing spedomerter w/tach to prevent slippage.
BUT BE WARNED. HACKING AN ECU IS NOT LIKE HACKING CODE. THE CODE CONTROLS REAL LIFE MECHANICAL PARTS AND THEY CAN BE DAMAGED.
For isntance, running too lean will destroy an engine. Running too rich won't.
I was thinking about the same axact thing the other day. It's 2004, where are our common primatives?
glibc is 'it' but it still gets updates, bug fixes, etc. It is not used on every platform. Yet it gets recreated over and over again.
Then I thought about.Net. Finally any language an interface to any other language's compiled objects. So we're getting closer.
But I think the biggest problem is the lack of software engineering from flow-charting. As mentioned, flowcharts allow us to map out or learn the most complicated software.
I think we can accomplish all she describes inside an OOP language, be it Java or C++ or Python. The master-slave relationship is easily done. The cooler thing that I would like to see more of is the state.
Rather than a process starting off in main(), and ini code run in constructors, each process and object need to have a state associated with it. This state is actually a stack, and not a variable.
my_process {
resister state handler 'begin' as 'init' resiter state hander 'end' as 'exit' state change to begin }
all_are_one() {// special state state change to 'in_special_case' do_something_else();
pop state if (exit_condidtion) exit() }
exit(){ while (state_stack.length) pop state }
What I'm tring to do is model the logical process with the execution of code, but in an asyncrounous manner. Sort of like a message pump, but its been extended to take process stages and custom events.
All crystal latticies are a result of molecular polarity between molecules. Water crystalizes and so do metals, for the same reason. Nuff said. (Because I'm at the end of my knowlege)
Slashdot Mirror
Bah, none of you know humor when you see it!
While I agree witht he author, I think retro will make huge comeback.
See, we started out with only integer units in 2 dimentional space. As time progressed, we got into bigger 2D space (from 4 bits to 32, now 64) We also got floating points thanks to FPUs. (Games were why FPUs became standard issue). But we were still in 2d space. Some were side scrollers, some were top-down, some were persective. Then Wolfenstien 3D came out. Doom then Quake pushed 3d accelerators to the desktop. But then we could interact in a world that we relate to in very real ways.
Next up we'll find theres more challenge in moving in 2 dimensions than 3. That'll help preserve the novelty. But they must remain challenging.
That brings me to the non-retro gaming success story. Masting 3d space is easy, master 2d space a easier (as a subset of 3d space) but 4d and 5d space will be where the fun is.
Video games a are all about challenge. Once you get your physics model and coordination down, you are left with one thing: solving the intelectual challenges. This is why so amny people play RPS still. Generally it's kill, loot, goto kill, level, repeat. EQ has quests which are mildly intelectually challenging.
All of 3d gaming can be rendered easy via circle-strafing. Strafe side-to side while turning and you'll always face your target and circle them. I have not seen a 3d shooter that isn't rendered easy by this technique. Once it no longer works, I'll be intelegtualy challenged to find the bug in the AI or physics model (grenade jumping) that trivializes the game. (I used to be a sniper in Quake - TF - and a good one at that, but what I did became proceedural, nd I lost intrest. Grenade and rocket jumpers were all the same. I'd get them in mid-air 99% of the time.)
Indeed the industry has been relying on glitz and glamor to sell, much like a hot whore. But no one marries a whore, they marry people that are intelectually stimulating. ANd that's going to be the next games. The mind-puzzles. Tomb Raider, Tetris, etc. They all have sppeal for a long time, until the *DESIGNERS* turn it proceedural. It's not the fault of the tech, it's because the designers get lazy.
Escapr from reality, the use of imagination, is why people turn to video games. I predict in 10 years that no video game will ever do the same game twice (like they do today) I bet they won't keep staff around either. Every game is a new team, and no one is allowed to be on the same type of game project as they were on in the past 5 years. This will keep innovation and imagination high.
The other idea is working with other people. When C&C has IPX multiplayer, we played it non-stop weekends at a time. Quake was plaued for weekends at a time. I spent most of my nights on TF maps with my clan. Human interaction is unpredictible (well, a lot less than a computer) (Imagine basketball vs chess, what is more popular)
Killer app of today: The Sims Online. Features imagination, creativity and human interaction. Runner Up: EQ.
Killer app of tomorrow: solving puzzles with other humans online. But the puzzles can't repeat, not even the same type. Maybe a puzzle is to make a puzzle for others to solve - taking turns between puzzlemaking and solving. (An offshoot of this is OpenSource... )
If hubble can see into the distant past by pointing it to the center of the universe, we should be able to poit it outward and see into the distant future. Given the high visual acuity of Hubble, it should be able to see the outcomes of future horse races. Then NASA can bet on that and gamble to get the extra cash needed to keep it operating.
Put these users on their own vlan. Give them access to their web email servers and send them a message with a download link to fprot or whatever virusscan package is out there. Let them download it. Once the spamming stops, put them back on the regular internet.
When you run out of memory, just add a 'scratch pad' and malloc some more 'pages'.
'Scratch space' wasn't meant to be taken littlerally!
That last PH is mine.. whoops, runaway itallics...
Anyway, You get several core samples at the same time. (Collect the ice out of the flutes of the bit)
If the consistancey is closer to that of snow, then drilling will need to go deaper but will be much easier
1: if the harpoon doesn't get a good hold, the probe probably will drift away from the comet. Getting the probe that close in the first place will still be a huge achievement, and it'll still return useful data.
We've already done that. Flybys and collect dust, it's no big deal these days!
2: It's a comet. An orbital ice-berg that's been bashed around for billions of years. A little harpoon isn't going to break it in half. Might smash a small chunk off, but it won't split the comet in half.
Right Shoemaker-Levvy was supposed to hold together, but got ripped apart from tidal forces. Those forces are not that great, and are very small and smooth in comparison to being harpooned. harpooning is a rather sudden and aburpt force.
3: The lander's heading toward the comet already, the harpoon launch recoil (assuming there is any) is unlikely to overcome the probe's momentum. And it is probably a small rocket harpoon, with practicaly no recoil.
Well this is the eastting to plan for.. knowing the mass of harpoon and probe, we can provide specific amount of force to acheive exactly what we want.
As for the drill-and-screw...a harpoon would be far more likely to get the initial hold. It's a quite well understood technology. On Earth, drilling typically requires rather firm support for the machinery doing the drilling. For the probe, it would require maneuvering up to the comet and holding position next to it while it attempted to drill in an anchor, at a distance from any human which makes real-time remote control impossible. Plus, it would be far more mechanically complex, a lot heavier, and a lot more power-hungry. The harpoon could use a small solid-fuel rocket, the drill would require a motor and power supply to run it. Not to mention the fuel required to hold the probe in place while drilling.
It's all realtively easy. Get out infront of the thing, activate retro rockets and constantly decel against the ting to keep you planted. While tou do that you drill ing several CM (It doesn't take my dewalt long to drill through solid ice (Particualrly if the bit is heated). Using several small bits, each one at a differnt angle ('toed' in) you'd have yourself a very stable base in seconds.
This idea is just sooo bad.
You're going to launch harpoon at a block of ice and hope it sticks? What is to say that:
1) The harppon doesn't glance off
2) the harpoon fractures the ice in 1/2 (or less)
3) The launch of the harpoon sends the lander flying backwards, the impending jerk at the end of the cord pulls it back out of the ice (assuming it attaches securely in the first place) or damages the lander.
It just sounds like a 1 in a billion shot to me. (No pun intended. I'd think a drill-in and screw-in would me more reliable.
It's a bunch of BS to get people to let this big brother in the car.. then ZAM it'll start to be abused.. Just like OnStar was. OnStar gor saved via a tecnical detail, but if they had multiple audio out channels, it's still be abused today.
The fact is, it's US thats the problem. We employ a greedy and not cooperative strategy on the roads. They did research around here, and they found that all the highways were completely cpable of handling the volume of traffic at rush hour. It's out driving that creates backups.
And don't get me started about RUBBERNECKERS! ARH.
People here are some tips:
1) Don't rummberneck, mangled metal is fun, but it's none of your business.
2) Don't tail gate, leave good room. Tailgating makes you slam on your brakes, so the guy behind you needs to slam arder, and so on, until people are locking up anc causing more accidents.
3) When in a backup let the gap be made. Don't floor it to the next guys bumper then brake hard 1) it wastes gas 2) you repeat #2. I've seen "averagers" - peopel who average the flow out create a huge difference. And I think we all rather me slow and steady rather than stop-and -go. If you are a stop and go person: remember: 1) all that gas used to get up to speed gets wasted when you put on your brakes, 2) you waste more brakes killing the effect of overusing gas 3) you create more changes in speed which is more changes for a rear-end collision by another unattentive driver. We handle things if they are steady.
4) Get over early. You having to slow down your lane so you can get over in a hurry, slows down your lane and causes others to change lanes.
5) minimize lane changes. Each one is a time when you a leagally vulderable. When you change lanes, right of way is with the person who is already there. And we all know about 2 people, one moveing left, the other right, that don't see each other.
That shoudl take care of 90% of the problems on the road.
Thank you.
Then you don't really understand.
Darl said he is there to increase and protect the shareholder value. This since they "legally" have NUMA and such, they then have to prevent otehrs from having it, including Linux. BUT they can only benefit if they have their own product to ship with it.
While I can see people thinking they just want to tax linux, it can't ever come to that. If SCO drops their own unix distributions, then Linux is the only source for that technology. They could right fully tax it, however I don't think any kernel developer would allow that to happen. If it did, I'd expect the kernel developers to rip out the contested peices and force SCO to actually sell and maintain something themselves. If this trend continues then they won't be selling much at all. Eventually, they'd go bankrupt just like they are now, and as soon as that happens and there's no hostile legal entity, the developers would put it back in.
But this all assumes they have a right to what they claim.
I think Big Blue knows this, which is why they are not trying to resolve this switftly. The longer SCO flounders, the closer to bankruptcy they get. Which means IBM will buy them up at the last minute for cheap or let them die completely, rather than buying them at todays much inflated price. SCO is on stilts, on a ledge. It's just time before they crash. We're in the death-throws of a company.
MMM a big steaming pile of crap. SCO forgot that an OS is nothing without apps. So as these apps start revoking themselves fromt he SCO distrib, the value of their product falls, along with the stock price, which is the exact opposite of what Darl wanted to do...
Looks like he'll prove himself the fool. I do feel bad for his family. He could have been something some day.
In getting the drive to work outside the Ipod. though. check slickdeals for a $255 pre-order deal through Target.
In my Journal
Maybe I'll finally get some comments...
Why don't you write and use a library for this? It's not that difficult to do and if most platforms you deal with have the same byte order and alignment conventions then you can optimise for that case. Perhaps you could have the library juggle the bytes in-place and, if sending, optionally juggle them back before returning. The juggling would be a no-op on most platforms.
Eaiser said than done. Use the Communication task must then know everydata format there is, then have code to patch it up. It's CPU cyles being wasted completely unessessarily, plus it adds complexity. The more time you spend fixing up your data, the less time you spend oding whatever the real function of the device is.
It really sucks when you have to waste cycles going through 1M of ram swapping bytes around, for the mere sake of intel. Plus do you know what that does to the schedular? 2.6 isn't so bad, but 2.4 it obliterates responsiveness.
What swap only 1/2 the bytes?
In embedded space we neither have time time nor resources to do this, yet we do. The biggest cost is finding and fixing the software bugs because of it. It's not a file format issue, it's a communication issue, Serial, Network, etc. I massively hurts not being able to alloc a block of mem and just dump it over the wire- one side wil write big endian out, and the other will read it in as little endian.
Until you work with these problems first hand you won't appreciate how dumbit is that everone but x86 does big endian.
Ah, I remember PPC being able to do both too now that you mention it. So IA64 supports it, but does x68-64?
Well it _CAN_ do big or little endian, its up to the whim of the designer. Which only drives my point.. we need to stardardize our endians!
Network byte order is already big endian...
Everting as ALL & (~Intel)
MIPS, PPC, ARM, ALPA, SPARC, SH, the list goes on to include everything still being made, minus x86.
I work with big-endian CPUs all day, and we always have to work aoround this. It's be great if we could just do a binary transfer of data, but no, we have to go back in, find the numbers, and swap it all around. Then swap it back before going to the device. x86 is the only architecture being manufactured and used that is little endian.
While they add new opcodes, why not throw one in there (or use a bit) for byte-swapped data?
You could use one pit of instruction to indicate to run it through a byte-swapper (easy to implement) before and after math/compare is done with it.
Pretty easy actually.
Seriously people, everything but x86 is Big endian, and we (embedded software people) have endian issues all the time. Wil there finally be 32 and 64 bit big endian instructions?
PLEASE SAY YES!
I have trouble with my alarm/keyless entry outside the Mars in Cockeysville, MD. Anyone havr the same problem? It doesn't matter when I go either.
I've also got a Clifford Concept 600, if that makes any difference.
I highly doubt the vehicle is that autonomous that they can say, "heay, head off bearing 110 deg, for 50m and take photos of interesting things along the way"
I always figured that mission control would give it vector commands like that, but that any kind of inspection would be manually done by instructions from mission control?
I can understand that it might have some self-preservation features, like slow down if too much wobble, or if grade is steep, but it seems like that things is really calling the shots.
Maybe we're not as far as logn as we thought, a la Stanly Kubrik's 2001 space oddesy.
AEM makes a product called the EMS. It's a swap-out replacement for your ECU. Most models are supported, and it can run 4-10 cylinder cars. EVERY engine parameter is configurable, plus you can program it to do new things, like turn up the radio when the windows go down.
It willalso add throlle control, mathing spedomerter w/tach to prevent slippage.
BUT BE WARNED. HACKING AN ECU IS NOT LIKE HACKING CODE. THE CODE CONTROLS REAL LIFE MECHANICAL PARTS AND THEY CAN BE DAMAGED.
For isntance, running too lean will destroy an engine. Running too rich won't.
I was thinking about the same axact thing the other day. It's 2004, where are our common primatives?
.Net. Finally any language an interface to any other language's compiled objects. So we're getting closer.
// special state
glibc is 'it' but it still gets updates, bug fixes, etc. It is not used on every platform. Yet it gets recreated over and over again.
Then I thought about
But I think the biggest problem is the lack of software engineering from flow-charting. As mentioned, flowcharts allow us to map out or learn the most complicated software.
I think we can accomplish all she describes inside an OOP language, be it Java or C++ or Python. The master-slave relationship is easily done. The cooler thing that I would like to see more of is the state.
Rather than a process starting off in main(), and ini code run in constructors, each process and object need to have a state associated with it. This state is actually a stack, and not a variable.
my_process {
resister state handler 'begin' as 'init'
resiter state hander 'end' as 'exit'
state change to begin
}
init() {
do_something();
register handler condition (x=1, y=1, z=1) as 'all_are_one'
}
all_are_one() {
state change to 'in_special_case'
do_something_else();
pop state
if (exit_condidtion) exit()
}
exit(){
while (state_stack.length) pop state
}
What I'm tring to do is model the logical process with the execution of code, but in an asyncrounous manner. Sort of like a message pump, but its been extended to take process stages and custom events.
Everseen the parking lot at the EPA? Nearly all SUVs.
All crystal latticies are a result of molecular polarity between molecules. Water crystalizes and so do metals, for the same reason. Nuff said. (Because I'm at the end of my knowlege)