I tried to use ruby for a while, but ended up back with C++. I couldn't live without static typing, as it turned out, and also C++ had more libraries leading to faster development (for me, at least).
C++ is the worst language, excepting every other language I have tried. And I am happy about the new features, they should make coding much nicer.
What I don't get is that the freedom-loving Americans are so crazy about such a restricted and tied-down product. Must be one of those opposites attract.
While I agree that changing the functionality of a library function underneath users in a non-backward-compatible way is bad, this has nothing to do with monkey-patching. What you describe would be the same in any language supporting library function, even if it was named "char* camelize(const char* input);" and written in C.
Actually,I believe you can do exactly this with tools like oprofile. But of course, if it was not written in Java you wouldn't need 10 seconds, would you?;)
Indeed. All Java needs is a way to handle general resources (e.g. file handles) in a sane way, ditch the sillier C syntax relics (e.g. case fall-through), ditch some of the sillier introduced syntax wrinkles (like package private default), get support for function(al)s, typing, inheritance, static polymorphism and then we are getting there except for the stuff I forgot;)
Calculation would show that "forever" is somewhat about 1000 years, so I don't expect a huge balooning effect from this. But yeah, technically you could have the same rule as above and then use the deficit rules for all babies.
The obvious choice would be to limit the number of offspring to 1/person (or 2 per woman, since that would be easier). Transgressors could be sentenced to a fine + sterilisation or something. The birth deficit could be handled by auction, lottery, or some queue-based scheme.
I have never had any success with that. On the other hand, theoretically my SaaS game could still be working.
More importantly, it is upfront: I know what I'm getting with SaaS. And if you're lucky, you know what you're getting shrink wrapped. I prefer not to pay for other people's piracy, and to have it just work, and thus would prefer a streaming service, all other things being equal. In the few cases where I have wanted to go back and play an old game, it has never worked for me anyway.
Indeed. It's not like it is a secret. Of course, the only reason you can play monkey island is due to a major effort by OS developers reimplementing the SCUMM system. What happens when I want to run my non-supported games on my N900? Right, you're screwed:P
As far as I can tell, it brings a lot of cost savings to the developer+publisher (no need for anti-piracy, multiple platforms, distribution). That could mean better and/or cheaper games. Of course, that rather relies on the internet being able to grow with the demand; as you correctly outline above it is only partially there yet.
But that leaves you with upgrading headaches (each app will have to be upgraded individually), and with security problems (dependencies might be old and have defects... especially common deps like libjpeg, libssl, libdbus and stuff like that)
Installing a repository is just one click in a browser. Installing an application is just one click. Both could be improved, imho, with a database so that uninstalled but available application could be suggested at launch time.
Bundles have their place --- I have used them myself, the deb toolchain makes this rather easy --- but desktop computers are not one of them.
Lockstep they do not have to be, but of course some updating might be needed if you are depending on packages which have been retired (but I suppose a repository ideally should provide all dependencies). Lockstep is only required if you are providing packages that the repository is also providing, and you want the main repository and yours to interact dynamically with this. That is, if you are doing more than provided old versions for compability reasons.
Really, we use this at work, and it is no trouble. Of course, you need a repository per distribution, and that IS a real bother, though I see no easy solution for it.
There has been or is bounds checking in gcc. STLport offers similar facilities for STL. I seem to recall both initializing and null-checking compilers, but I can't seem to find them now. Perhaps it was an IBM-internal thing from back when I had a job there. Indeed, it should be possible to have C++-compilers output bytecode --- it is, after all, just another platform.
As I said, such projects seem to gather little or no interest, probably because they don't offer enough real-world value for the performance hit. For the user, a crash is a crash is a crash, and the hypothetical "able to clean up and leave all data in a good state" turns out to be infeasible expensive.
Compilers can and do offer "undefined behaviour = crash/assert/exception" (with the corresponding performance hit), but there seems to be little or no interest.
And this, I believe, is C++ big strength. Did Swing++ suck? Well, leave it behind. The smaller the standard lib, the more unnatural selection can work its magic.
Where C++ mostly fails is it silly syntatic heritage (Some examples: hard to parse, switch defaulting to fall-through, return value going before the parameters) and its lack of closures (that will be fixed, though).
Really, there is no excuse for not providing closures if you provide objects.
Most other VM machines have closures, which can also work. Java is pretty unique in having no RAII, no goto and no closures. At least, this was my experienced in the 3 attempts I have made at getting Java and GUI into the same sentence.
As an aside: all languages that have objects really should have closures... it is really just a matter of syntax at that point. At least C++ will *finally* get that now.
Slashdot Mirror
I tried to use ruby for a while, but ended up back with C++. I couldn't live without static typing, as it turned out, and also C++ had more libraries leading to faster development (for me, at least).
C++ is the worst language, excepting every other language I have tried. And I am happy about the new features, they should make coding much nicer.
What I don't get is that the freedom-loving Americans are so crazy about such a restricted and tied-down product. Must be one of those opposites attract.
While I agree that changing the functionality of a library function underneath users in a non-backward-compatible way is bad, this has nothing to do with monkey-patching. What you describe would be the same in any language supporting library function, even if it was named "char* camelize(const char* input);" and written in C.
Actually,I believe you can do exactly this with tools like oprofile. But of course, if it was not written in Java you wouldn't need 10 seconds, would you? ;)
Indeed. All Java needs is a way to handle general resources (e.g. file handles) in a sane way, ditch the sillier C syntax relics (e.g. case fall-through), ditch some of the sillier introduced syntax wrinkles (like package private default), get support for function(al)s, typing, inheritance, static polymorphism and then we are getting there except for the stuff I forgot ;)
Ah. I did wonder why all Blueray players are so freaking slow and uncomfortable to use. Thanks for clearing that up!
Calculation would show that "forever" is somewhat about 1000 years, so I don't expect a huge balooning effect from this. But yeah, technically you could have the same rule as above and then use the deficit rules for all babies.
The obvious choice would be to limit the number of offspring to 1/person (or 2 per woman, since that would be easier). Transgressors could be sentenced to a fine + sterilisation or something. The birth deficit could be handled by auction, lottery, or some queue-based scheme.
I especially remember Severance: Blade of darkness. I have tried it in windows and wine to no avail.
I have never had any success with that. On the other hand, theoretically my SaaS game could still be working.
More importantly, it is upfront: I know what I'm getting with SaaS. And if you're lucky, you know what you're getting shrink wrapped. I prefer not to pay for other people's piracy, and to have it just work, and thus would prefer a streaming service, all other things being equal. In the few cases where I have wanted to go back and play an old game, it has never worked for me anyway.
How do I port an engine I don't have access to? I really fail to see any real difference.
Sure, and thank you. I was talking about some random non-SCUMM game I used to enjoy, say Civilization or Savage.
Piracy.
Indeed. It's not like it is a secret. Of course, the only reason you can play monkey island is due to a major effort by OS developers reimplementing the SCUMM system. What happens when I want to run my non-supported games on my N900? Right, you're screwed :P
As far as I can tell, it brings a lot of cost savings to the developer+publisher (no need for anti-piracy, multiple platforms, distribution). That could mean better and/or cheaper games. Of course, that rather relies on the internet being able to grow with the demand; as you correctly outline above it is only partially there yet.
But that leaves you with upgrading headaches (each app will have to be upgraded individually), and with security problems (dependencies might be old and have defects... especially common deps like libjpeg, libssl, libdbus and stuff like that)
Installing a repository is just one click in a browser. Installing an application is just one click. Both could be improved, imho, with a database so that uninstalled but available application could be suggested at launch time.
Bundles have their place --- I have used them myself, the deb toolchain makes this rather easy --- but desktop computers are not one of them.
Lockstep they do not have to be, but of course some updating might be needed if you are depending on packages which have been retired (but I suppose a repository ideally should provide all dependencies). Lockstep is only required if you are providing packages that the repository is also providing, and you want the main repository and yours to interact dynamically with this. That is, if you are doing more than provided old versions for compability reasons.
Really, we use this at work, and it is no trouble. Of course, you need a repository per distribution, and that IS a real bother, though I see no easy solution for it.
All package managers I know of can and do handle multiple repositories.
Scott Meyer's: Effective C++ and Effective STL are classics, but doesn't cover Boost. Boost itself has rather nice docs, though.
It would not be hard to make, I think. Just walk through the standard...
There has been or is bounds checking in gcc. STLport offers similar facilities for STL. I seem to recall both initializing and null-checking compilers, but I can't seem to find them now. Perhaps it was an IBM-internal thing from back when I had a job there. Indeed, it should be possible to have C++-compilers output bytecode --- it is, after all, just another platform.
As I said, such projects seem to gather little or no interest, probably because they don't offer enough real-world value for the performance hit. For the user, a crash is a crash is a crash, and the hypothetical "able to clean up and leave all data in a good state" turns out to be infeasible expensive.
Compilers can and do offer "undefined behaviour = crash/assert/exception" (with the corresponding performance hit), but there seems to be little or no interest.
Indeed. C++ lacked a big marketing department ;)
And this, I believe, is C++ big strength. Did Swing++ suck? Well, leave it behind. The smaller the standard lib, the more unnatural selection can work its magic.
Where C++ mostly fails is it silly syntatic heritage (Some examples: hard to parse, switch defaulting to fall-through, return value going before the parameters) and its lack of closures (that will be fixed, though).
Really, there is no excuse for not providing closures if you provide objects.
Most other VM machines have closures, which can also work. Java is pretty unique in having no RAII, no goto and no closures. At least, this was my experienced in the 3 attempts I have made at getting Java and GUI into the same sentence.
As an aside: all languages that have objects really should have closures... it is really just a matter of syntax at that point. At least C++ will *finally* get that now.