it's probably because you can still easily revert back to plain old C in your C++ code. And it's easier to find people who can read C than people who can read Ada. As I recall, Ada's objects are limited compared to C++'s (It's been a couple decades since I looked at the language.) The old C standard library gives you full control of the system, at least on a UNIX system. For me at least this is a big selling point. Between boost and the C++11 update to the standard (Which more or less copied a lot of things I use regularly from boost into the language,) it's become a really nice language to use. The level of control it gives you over object lifetimes alone makes it well worth another look.
The only thing I really miss in it right now is C++ integration of some of the old language constructs. Most notably, I'd like to be able to create a stream from a file descriptor or a FILE pointer. That's pretty much how I do all my IPC. Currently I work around it with an object that contains GNU-specific code for that purpose, but it really seems like something that's missing from the language.
Headers define the interface and are documentation to other programmers. If you don't care who sees your code, you could just put everything in classes and put all your code inside those classes, just like a Java class. It'll slow down your compilation, but if you break down your code into libraries and unit test all your libraries, you shouldn't have to compile the main project all that often. Most of your maintenance churn can go on in the libraries and once you're sure all those are solid you can roll them all up for deployment.
I played a game called Conquest on a DEC Vax running VMS, but it was written in fortran. I believe you can still find the code for it and someone might even be running a server for it out there on the Internet. It didn't have an AI but resembled a terminal-graphics version of xtrek. You'd fly around, blow up opponent team ships, bomb and colonize their planets.
Now Xtrek was really where it was at for all that. There was definitely something to be said for 20-30 players wrestling for control of the universe over the course of 2-3 hours or so.
If you're reasonably observant, it can seem like ESP. I've accurately told people the cards they were holding while playing poker, a couple of times. I've also had that done to me a couple of times. That's not magic, that's just deduction and careful observation of your opponent. Once you learn to pay attention to people like that, you get to be a bit more in tune with what other people are thinking and feeling outside the poker room as well. The line between insight and ESP can be awfully hard to find sometimes.
People don't use a lot of the old tools because they're not aware of the old tools. You never see anyone use Lex and Yacc, for example. Slightly more people seem to know about gdb and efence, but only slightly. I've been talking to a relative as he's going through a CS program and most of his work has been either Java/Eclipse or C++ on a Microsoft Visual C++ platform, with not even the cursory look at the UNIX tools that were common back in the '80s.
^z, bg, fg. Most of the time when I'm working around shell mechanics, it's because everything's run in another process. So you can't, for example, change your current environment with a compiled application (You can with a shell script and "source", but that's pretty much the only workaround.) You can also use "screen", which is actually fairly useful for its range of things.
In 1987 I took an assembly language class. We were presented a PDP 11/03 and an 8 inch floppy disk and instructed on how to type the bootstrap sequence into the computer in octal to cause the system to jump to the first instruction on the floppy disk. The GUI is good for one thing and that's standing between you and understanding what's really going on in your computer.
Now I wouldn't even comment on this story, but I have recently been wondering why we haven't seen new developments in command line shells in the last couple of decades or so. The last big advance was tab completion in bash and then we just... stopped. Now I could see the argument that bash does everything we need it to, but I'm not sure I completely buy that. For one thing I'm constantly working around deficiencies in the shell. For another, we have seen OS advances we could be taking advantage of.
The UNIX shell model for the last three decades is, you run a program and the shell finds it in the path, forks a child process, execs the program and waits on the child process. When the child process exits, the shell resumes and has the return status of the child process available for examination. And that does actually have its place. But it doesn't need to be all there is anymore. With threads, there's no reason not to have the ability to initiate a program in parallel in the same memory space. Obviously there are some drawbacks to that -- if the program crashes, you'd lose your working shell. But it'd have some advantages, too -- the program could modify the shell's environment, share or persist objects in local memory, and customize the shell's behavior much more easily than we do today. We'd move from having files on disk to having resources we can take advantage of. Naturally you should still be able to revert to the old fork/exec model for some applications.
I'll probably write some code to explore this when I get my current couple of projects squared away.
Why don't you run? Sounds like you have a better idea. Mount a grassroots campaign on teh internets on a shoestring and see how many votes you get! You want something done, you gotta do it yourself.
They're just setting the catchOnFire flag to be false in all cases. Someone included the flag at some point because they thought catching on fire was something the user might occasionally want. They can't just remove it because many other features of the interface are coupled to it and would have to be completely redesigned.
Fortunately the explodeViolently flag has managed to stay off in most cases so far...
It's a double-down! When you're in over your head there are two things you can do. Apologize, admit you were wrong and hope people forgive you and don't throw you in jail. Or you can double-down on the crazy! They obviously opted for the double-down. Oh, and it's a good one, too. You need huge fucking steel balls to double-down like that!
Or that there's so much broken code that they manage to keep finding new ones? Back in the 90's one of the contracting gigs I did was auditing the C standard library source for Data General, as part of their B2-secure certification process. Fast forward a decade or so and you never see anyone doing that. Someone I mentioned this to said it's because automated tools catch the same problems that people reading the code do, but there's plenty of code out there that obviously has never had those automated tools run against it. Hiring people to audit your code is expensive, licensing security-scanning software and developing processes to scan your code for exploits is expensive, saying you're sorry after someone exploits a security hole in your code is cheap. If no one ever does, or you never actually find out it's happening, it's free.
Seems to me it just points to demand in that arena. If I were to take a wild guess (knowing very little about currency) I'd say people have fairly low faith in government-backed currencies and are looking to diversify. US treasury bonds are still the safe haven of choice for investors worldwide, and with Fox news and the US Government's own actions undermining confidence in that medium, investors are probably desperate for any place else to put their money. I'd guess like any other bubble, it'll pop eventually. The question is, when?
I know what you're thinking. You're thinkiing "His gun's made of plastic! It's going to explode in his hand the moment he pulls the trigger!" Well to be honest, I'm not even sure myself. So the question you have to ask yourself is, do you feel lucky, punk? Well? DO YA?!
Every time I see a news item about supersymmetry, it always seems to be disproving it. Seems like the only thing the hypothesis has going for it is the universe would make a lot more elegantly designed if it was true. It seems like mostly wishful thinking to me.
Now if you want to make it interesting, mandate that the case be made out of C4 and make the kill switch an actual kill switch! When someone in law enforcement pushes it, the user explodes! That'd make the daily commute a lot more interesting!
Wow, I know it must have taken a lot of courage to come out and take a stand against DRM here on Slashdot, but you just went ahead and did it, didn't you? Some day I'm sure there will be an epic song about this event which most of us won't hear because it's protected by DRM.
I'm actually pretty impressed with the LEDs I've been moving to, though. Decently bright, natural colors and they seem like they'll last nearly forever. I guess over the course or their lifetimes they'll more-or-less pay for themselves. If you want extra heat, you can still get a plumber's torch or a radiant heater.
We're afraid if they terk oer guns, some king will come in and try to oppress us again. As long as we have our guns, we're quite happy to live with a corrupt government that's happy to stack the deck in the favor of the wealthiest citizens in exchange for the funding to stay in power. We're quite happy to sit around and watch them dismantle all the social safety nets and worker's benefits that our grandparents' unions negotiated, and the only down side is one or two massacres a day. They're so common now that usually if only two or three people get shot, it won't even be reported on the national news. And we like it that way. Obviously. Anyone who tries to terk oer guns quickly finds themselves un-elected. After Sandy Hook, a couple of Colorado Democrats passed some legislation that stated something to the effect of if you were mentally ill you couldn't get a gun. One of them was recalled and another resigned because it looked as if the recall effort was going to pass. But hey, at least some king isn't oppressing us!
It seems to be working great, even with some of Google's own apps. Comes out the same way whether I don't install an app because I don't think a fucking flashlight app should get network and GPS permissions or because that app breaks when it attempts to request them and it doesn't get them. I'm just less likely to install the app if I think the developer was just being lazy and requesting all permissions. Arguably I shouldn't be installing apps from bad developers anyway. Also arguably Google shouldn't be allowing them on their store in the first place (Including some of their own apps which apparently don't actually need all those permissions either.)
The only thing I really miss in it right now is C++ integration of some of the old language constructs. Most notably, I'd like to be able to create a stream from a file descriptor or a FILE pointer. That's pretty much how I do all my IPC. Currently I work around it with an object that contains GNU-specific code for that purpose, but it really seems like something that's missing from the language.
Perhaps they were paid with a stolen credit card. It's not like those are hard to come by.
Headers define the interface and are documentation to other programmers. If you don't care who sees your code, you could just put everything in classes and put all your code inside those classes, just like a Java class. It'll slow down your compilation, but if you break down your code into libraries and unit test all your libraries, you shouldn't have to compile the main project all that often. Most of your maintenance churn can go on in the libraries and once you're sure all those are solid you can roll them all up for deployment.
Now Xtrek was really where it was at for all that. There was definitely something to be said for 20-30 players wrestling for control of the universe over the course of 2-3 hours or so.
If you're reasonably observant, it can seem like ESP. I've accurately told people the cards they were holding while playing poker, a couple of times. I've also had that done to me a couple of times. That's not magic, that's just deduction and careful observation of your opponent. Once you learn to pay attention to people like that, you get to be a bit more in tune with what other people are thinking and feeling outside the poker room as well. The line between insight and ESP can be awfully hard to find sometimes.
People don't use a lot of the old tools because they're not aware of the old tools. You never see anyone use Lex and Yacc, for example. Slightly more people seem to know about gdb and efence, but only slightly. I've been talking to a relative as he's going through a CS program and most of his work has been either Java/Eclipse or C++ on a Microsoft Visual C++ platform, with not even the cursory look at the UNIX tools that were common back in the '80s.
^z, bg, fg. Most of the time when I'm working around shell mechanics, it's because everything's run in another process. So you can't, for example, change your current environment with a compiled application (You can with a shell script and "source", but that's pretty much the only workaround.) You can also use "screen", which is actually fairly useful for its range of things.
Now I wouldn't even comment on this story, but I have recently been wondering why we haven't seen new developments in command line shells in the last couple of decades or so. The last big advance was tab completion in bash and then we just... stopped. Now I could see the argument that bash does everything we need it to, but I'm not sure I completely buy that. For one thing I'm constantly working around deficiencies in the shell. For another, we have seen OS advances we could be taking advantage of.
The UNIX shell model for the last three decades is, you run a program and the shell finds it in the path, forks a child process, execs the program and waits on the child process. When the child process exits, the shell resumes and has the return status of the child process available for examination. And that does actually have its place. But it doesn't need to be all there is anymore. With threads, there's no reason not to have the ability to initiate a program in parallel in the same memory space. Obviously there are some drawbacks to that -- if the program crashes, you'd lose your working shell. But it'd have some advantages, too -- the program could modify the shell's environment, share or persist objects in local memory, and customize the shell's behavior much more easily than we do today. We'd move from having files on disk to having resources we can take advantage of. Naturally you should still be able to revert to the old fork/exec model for some applications.
I'll probably write some code to explore this when I get my current couple of projects squared away.
Why don't you run? Sounds like you have a better idea. Mount a grassroots campaign on teh internets on a shoestring and see how many votes you get! You want something done, you gotta do it yourself.
Fortunately the explodeViolently flag has managed to stay off in most cases so far...
Then why is it still going on?
They gonna call it "Endor"?
It's a double-down! When you're in over your head there are two things you can do. Apologize, admit you were wrong and hope people forgive you and don't throw you in jail. Or you can double-down on the crazy! They obviously opted for the double-down. Oh, and it's a good one, too. You need huge fucking steel balls to double-down like that!
Or that there's so much broken code that they manage to keep finding new ones? Back in the 90's one of the contracting gigs I did was auditing the C standard library source for Data General, as part of their B2-secure certification process. Fast forward a decade or so and you never see anyone doing that. Someone I mentioned this to said it's because automated tools catch the same problems that people reading the code do, but there's plenty of code out there that obviously has never had those automated tools run against it. Hiring people to audit your code is expensive, licensing security-scanning software and developing processes to scan your code for exploits is expensive, saying you're sorry after someone exploits a security hole in your code is cheap. If no one ever does, or you never actually find out it's happening, it's free.
Seems to me it just points to demand in that arena. If I were to take a wild guess (knowing very little about currency) I'd say people have fairly low faith in government-backed currencies and are looking to diversify. US treasury bonds are still the safe haven of choice for investors worldwide, and with Fox news and the US Government's own actions undermining confidence in that medium, investors are probably desperate for any place else to put their money. I'd guess like any other bubble, it'll pop eventually. The question is, when?
I know what you're thinking. You're thinkiing "His gun's made of plastic! It's going to explode in his hand the moment he pulls the trigger!" Well to be honest, I'm not even sure myself. So the question you have to ask yourself is, do you feel lucky, punk? Well? DO YA?!
Should have a prominent big red self destruct button. This button should not do anything, and it should be booby trapped.
Every time I see a news item about supersymmetry, it always seems to be disproving it. Seems like the only thing the hypothesis has going for it is the universe would make a lot more elegantly designed if it was true. It seems like mostly wishful thinking to me.
They will send us a sternly worded note stating that we really should pay attention to their... *yawn*.... sorry...
Now if you want to make it interesting, mandate that the case be made out of C4 and make the kill switch an actual kill switch! When someone in law enforcement pushes it, the user explodes! That'd make the daily commute a lot more interesting!
Hey! The absence of evidence is not the evidence of absence!
Wow, I know it must have taken a lot of courage to come out and take a stand against DRM here on Slashdot, but you just went ahead and did it, didn't you? Some day I'm sure there will be an epic song about this event which most of us won't hear because it's protected by DRM.
I'm actually pretty impressed with the LEDs I've been moving to, though. Decently bright, natural colors and they seem like they'll last nearly forever. I guess over the course or their lifetimes they'll more-or-less pay for themselves. If you want extra heat, you can still get a plumber's torch or a radiant heater.
We're afraid if they terk oer guns, some king will come in and try to oppress us again. As long as we have our guns, we're quite happy to live with a corrupt government that's happy to stack the deck in the favor of the wealthiest citizens in exchange for the funding to stay in power. We're quite happy to sit around and watch them dismantle all the social safety nets and worker's benefits that our grandparents' unions negotiated, and the only down side is one or two massacres a day. They're so common now that usually if only two or three people get shot, it won't even be reported on the national news. And we like it that way. Obviously. Anyone who tries to terk oer guns quickly finds themselves un-elected. After Sandy Hook, a couple of Colorado Democrats passed some legislation that stated something to the effect of if you were mentally ill you couldn't get a gun. One of them was recalled and another resigned because it looked as if the recall effort was going to pass. But hey, at least some king isn't oppressing us!
It seems to be working great, even with some of Google's own apps. Comes out the same way whether I don't install an app because I don't think a fucking flashlight app should get network and GPS permissions or because that app breaks when it attempts to request them and it doesn't get them. I'm just less likely to install the app if I think the developer was just being lazy and requesting all permissions. Arguably I shouldn't be installing apps from bad developers anyway. Also arguably Google shouldn't be allowing them on their store in the first place (Including some of their own apps which apparently don't actually need all those permissions either.)