An important distinction, I believe there must always exist a language where that is true to handle cases where it is necessary. That doesn't exclude languages that don't permit it for cases where it won't be needed. It's still a matter of the developer choosing the language wisely, but it might remove temptations to cheat.
A great challenge but probably worth it would be a new function naming convention to facilitate writing libraries in a safer language. Currently C is used a lot because it produces a library that pretty much any other language can cope with linking against. It would be nice to be able to select a safer language without opening a snakes nest of linking trouble.
You do realize there is nothing there even vaguely relevant to the question at hand, right? In fact, it reads like the slimy sorts of weaseling done by sales and marketing. Apparently, they can also be fired if they fix the copper line when according to the document you're so proud of, they could have been switched to wireless. Conveniently for Verizon, the wireless is less regulated. Unfortunately for the customer, wireless is less reliable and limits their options if they later have a need that would like to install an alarm or develop a need for the medical equipment.
They have to see if it's available first? You don't say. All in TFA. The point stands that unless it is absolutely ruled out, they are switching people off of copper and any tech that doesn't cooperate with that is subject to being fired.
And if they fix the copper rather than switching to wireless wherever possible, they are subject to "disciplinary action". So yes, they can be fired for repairing the copper.
Looks like you didn't give Verizon their money's worth.
That's just it, if the feature exists, not abusing it is a matter of programmer discipline because the compiler can't necessarily anticipate when the correct time is to make it available.
For example, I once wrote a proof of concepy exec in userspace function. It would analyse the ELF executable file it was passed, relocate selected helper functions out of the way (including modifying their symbol tables), munmap the original program, then mmap and perform the symbol relocation on the target executable, then jump into it.
I'm sure you can imagine, I had to "break the 4th wall" all over the place to make that work. I had to do that in places a compiler might not expect. C didn't care, of course. At the same time, had I been writing a mail merge program, it would be highly inappropriate to take such liberties.
So somehow or another, there must be a language that permits such crazy stuff. It can be a separate unsafe language, or a #pragma, or a compiler flag that enables unsafe features in a normally safe language. It can even be a language that makes the features available and depends on the programmer to use them tastefully. The latter is just a special case of depending on the developer to only enable the unsafe features when necessary (though perhaps one that offers moire temptation).
Bottom line, there can not be a one true language that both forbids all that void* jackassery AND is suitable for all purposes. Sometimes (not often) void* actually is the right answer.
I agree, it's OK for most purposes if the language does special case a few functions or if del and new are keywords rather than functions. However, in either case, you necessitate some other language without a restriction on void* (or equivalent). If the allocation and freeing isn't handled by a function, you'll need another language to do kernel programming since memory allocation works differently in kernelspace (and so you need to be able to re-write the allocators).
That's just it. At one time software developers were professionals and actually had some ownership of the process. That has been taken in many places./
I agree, it is important not to let perfection be the enemy of good, but some of the code out there is absolute excrement that no self-respecting professional would willingly release.
Promiscuously polymorphic means that literally any object type that can be defined already matches the parameter type for delete (for example). That sounds an awful lot like the void type, does it not? Consider the old adage that given sufficient determination, one can write a FORTRAN program in any language.
If you have a function that does that, it must be possible to specify that if the language is to be self hosting (since it must be able to define and compile the delete function). If it can specify that and compile that, the programmer can (ab)use it. And so there you are, void* in all but name.
You can just decide that self hosting isn't all that important, but then you have justified the need for a less safe language (for example, C) that the new language's compiler is written in.
Note that I am not at all saying that you cannot have a safer language at all, just that you will need a less safe language somewhere and that language will have something that walks, quacks, and swims like a void*.
They can be polymorphic. But if they are promiscuously so, it's just a void* by another name.
If you make them (and perhaps a few more built-in functions) special snowflakes allowed to do that while nothing else is in order to not have a void* equivalent, you are cheating. For one, it can't be self hosting since you can't declare anything with the void* type.
So, what type of pointer does del accept? How about new (and don't say whatever it creates unless you can explain how to implement that without cheating).
Slashdot Mirror
An important distinction, I believe there must always exist a language where that is true to handle cases where it is necessary. That doesn't exclude languages that don't permit it for cases where it won't be needed. It's still a matter of the developer choosing the language wisely, but it might remove temptations to cheat.
A great challenge but probably worth it would be a new function naming convention to facilitate writing libraries in a safer language. Currently C is used a lot because it produces a library that pretty much any other language can cope with linking against. It would be nice to be able to select a safer language without opening a snakes nest of linking trouble.
You do realize there is nothing there even vaguely relevant to the question at hand, right? In fact, it reads like the slimy sorts of weaseling done by sales and marketing. Apparently, they can also be fired if they fix the copper line when according to the document you're so proud of, they could have been switched to wireless. Conveniently for Verizon, the wireless is less regulated. Unfortunately for the customer, wireless is less reliable and limits their options if they later have a need that would like to install an alarm or develop a need for the medical equipment.
Yes, voice is less bandwidth, but it is bandwidth and they insist on adding it even as they cry that their network is overloaded.
I did. Now you re-read it, it doesn't seem to say what you think it does.
They have to see if it's available first? You don't say. All in TFA. The point stands that unless it is absolutely ruled out, they are switching people off of copper and any tech that doesn't cooperate with that is subject to being fired.
We're not getting Chip and PIN, just Chip. And the retailers are expected to foot the bill.
These days voice is data. It's all packets of digital data. It all takes up bandwidth.
You probably didn't notice in TFA, but when they switch someone over to wireless, they don't ever switch them back.
So kinda like a more interesting version of CNN and Fox?
>p>Right, Yahoo does the rifling. The NSA just reads the results.
When asked about raising the data limits on wireless, they cry about how overloaded their wireless is.
And if they fix the copper rather than switching to wireless wherever possible, they are subject to "disciplinary action". So yes, they can be fired for repairing the copper.
Looks like you didn't give Verizon their money's worth.
That's just it, if the feature exists, not abusing it is a matter of programmer discipline because the compiler can't necessarily anticipate when the correct time is to make it available.
For example, I once wrote a proof of concepy exec in userspace function. It would analyse the ELF executable file it was passed, relocate selected helper functions out of the way (including modifying their symbol tables), munmap the original program, then mmap and perform the symbol relocation on the target executable, then jump into it.
I'm sure you can imagine, I had to "break the 4th wall" all over the place to make that work. I had to do that in places a compiler might not expect. C didn't care, of course. At the same time, had I been writing a mail merge program, it would be highly inappropriate to take such liberties.
So somehow or another, there must be a language that permits such crazy stuff. It can be a separate unsafe language, or a #pragma, or a compiler flag that enables unsafe features in a normally safe language. It can even be a language that makes the features available and depends on the programmer to use them tastefully. The latter is just a special case of depending on the developer to only enable the unsafe features when necessary (though perhaps one that offers moire temptation).
Bottom line, there can not be a one true language that both forbids all that void* jackassery AND is suitable for all purposes. Sometimes (not often) void* actually is the right answer.
I agree, it's OK for most purposes if the language does special case a few functions or if del and new are keywords rather than functions. However, in either case, you necessitate some other language without a restriction on void* (or equivalent). If the allocation and freeing isn't handled by a function, you'll need another language to do kernel programming since memory allocation works differently in kernelspace (and so you need to be able to re-write the allocators).
That's just it. At one time software developers were professionals and actually had some ownership of the process. That has been taken in many places./
I agree, it is important not to let perfection be the enemy of good, but some of the code out there is absolute excrement that no self-respecting professional would willingly release.
That's not the sort of ownership being discussed, though it can be related.
And the affirmative claim (implied) is that there is some sort of hypocracy to supporting police body cameras but opposing red light cameras.
So it is your burden to show that they are substantially similar in effect such that one should support both or neither.
My only claim is that he didn't provide a cite. Look at the names on the posts. My citation is this very thread :-)
This isn't a criminal trial.
I'm guessing you have no evidence whatsoever to support your side. You may even know it.
Your implicit claim that accident rates remain the same or go down when red light cameras are used.
As is yours.
The behavior already changed radically and virtually overnight. The only matter up for debate is why.
Promiscuously polymorphic means that literally any object type that can be defined already matches the parameter type for delete (for example). That sounds an awful lot like the void type, does it not? Consider the old adage that given sufficient determination, one can write a FORTRAN program in any language.
If you have a function that does that, it must be possible to specify that if the language is to be self hosting (since it must be able to define and compile the delete function). If it can specify that and compile that, the programmer can (ab)use it. And so there you are, void* in all but name.
You can just decide that self hosting isn't all that important, but then you have justified the need for a less safe language (for example, C) that the new language's compiler is written in.
Note that I am not at all saying that you cannot have a safer language at all, just that you will need a less safe language somewhere and that language will have something that walks, quacks, and swims like a void*.
They can be polymorphic. But if they are promiscuously so, it's just a void* by another name.
If you make them (and perhaps a few more built-in functions) special snowflakes allowed to do that while nothing else is in order to not have a void* equivalent, you are cheating. For one, it can't be self hosting since you can't declare anything with the void* type.
See that link to the story? Don't click.
So, what type of pointer does del accept? How about new (and don't say whatever it creates unless you can explain how to implement that without cheating).