You haven't been reading the news if you don't realize that cops have been beating innocents, lying in court, claiming peaceful protesters are violent, and other such violations of rights that won't be so easy to get away with if the cop has to wear a camera.
I could as easily pick apart your arguments. I find it hard to imagine never using code that is shared with other projects for example. Why re-invent the wheel? Are you declaring code re-use dead? What about the system libraries? Do you hack those without notice too?
And what happened to unit testing where you should easily enough shake out cases where people called a function they shouldn't have?
I have argued that the programmer who just takes the IDE's word for it will eventually end up in deep trouble.
You seem to be arguing that duck typing is bad because shoddy practices rule.
It's easily solved if the law requiring the cameras also requires that 'missing' video for any reason is to be treated as destroyed evidence in court. That is that it shall be assumed that the video was favorable to the other party's position.
So if the plaintiff in the civil suit says he was beaten unprovoked and the video is missing, then as far as the court is concerned, it would have shown an unprovoked beating.
At this point, I wonder how your "everything in comments" system architecture works, since you seem to have issues reading. I mean, nothing I wrote says "call functions randomly".
No, you just called whatever the IDE autopopulated with, apparently without bothering to check what it was. Or at least that's what you said may happen.
You also talked about calling functions based on oral lore that has changed over time. That sounds pretty cargo-cultish to me especially since you apparently believe that might be a fair reason to have never looked at the doc string.
By making it happen through gas taxes, it prevents really key roads from charging rapacious rent seeking tolls. It also prevenmts the building of two roads where one will do.
As an added benefit, your position cannot be tracked through gas taxes.
Then there's the right-of-way situation. Roads need to have right of way cleared and it isn't going to happen without eminent domain. Surely that's not the sort of power that any private corporation should ever wield.
It got autopopulated in my IDE, and *sounds like* the function I intend to use. Possibly even one I've used before and am mis-remembering the name of.
The "Here be Dragons" got added later, when the signature of the function didn't change (or it did, but duck-typing, so no-errors, let's go!)
I was told about the function verbally, so I never read the docs. I then told someone else. At some point, the oral tradition drops the "Here be Dragons".
In a less formal code review (maybe someone in charge of many programmers, who cannot do a full read of all of their code) there is no way to easily have them find it all using grep.
If any of that happens, you absolutely positively deserve everything you get. DO NOT call a function if you don't know what it is!
My actual assertion, BTW is that duck typing has advantages to go with the disavantages.
I have worked on a number of large projects with multiple coders. I presume you use the old cut'n'past code 'sharing' method with a significant appearance of the cargo cult antipattern?
Your solution is really fragile. It requires never changing classes once they are created (at least the public members thereof) because you never know if they are used. Which, in some languages, or with some programmers, is all the members.
You need to RTFC as well. Surely you don't recommend unilaterally changing code used in other projects!
Sometimes the casting is actually the right thing though. An unfortunate side effect is that the IDE can't hold your hand anymore, you have to actually understand the code.
The thread is about Java being/not being an appropriate mid-point between Pyt
hon-like interpreted languages and C++ like compiled languages.
See, that's not something that is easy to search for in code reviews. Because, there is no validation that I did not write: *** Off the edge of the world: Sea Serpents Around ***
Someone thinking of calling the function should certainly see it.
Ideally, it would then lay out the necessary attributes of the object if it's
non-obvious.
Or it means the system has grown and evolved over time in ways not anticipated when it began. That is the nature of software. In fact, some of the most useful bits of software are that way (of course, so are some of the most useless).
Or just pointing out that the girl did science and (in the same sense as saying Sir Issac Newton did not discover radium) the other scientists didn't do that particular science.
So when I see a void*, I know that the documentation is really important.
def pickymethod(self, pickyobject):
"""Here there be dragons, beware"""
Although really you should write the module around Aprime, an interface, and then say that both A and B implement interface Aprime.
Problem is, A and the module that handles it is existing code used in multiple projects. IO don't want to do a cut/paste job and I don't want to risk breaking the other projects. B is from another existing module used by other projects. I REALLY just want to derive a Bprime that can serve as an A or a B as needed by the legacy modules.
Python does a decent job with multiple inheritance, but even so, it can get ugly so I might prefer duck typing and a compatible class.
Based on the assignment and the response, flippancy is clear. Or did you suspect his neighbors somehow opened a rift in time to acquire a pet dinosaur? Perhaps they are witches?
Me lot? How many of me do you think there are? How about they blow the dust from their brains and act on credible threats rather than obvious non-threats? How about they do their job? How about they actually handle the situation like real adults instead of calling the cops every time someone sneezes?
You can also cast things around until the compiler and IDE buy it and wait for the SEGV.
It's on the developer to know when they can and cannot get away with it.
If you don't KNOW if class A and Bs X methods are actually compatible, what in the hell are you doing passing them around? You're supposed to know that. If you have a case where it may or may not be true and it's all OK, wrap it in a try..except and pick up the pieces at runtime.
This would be a lot less of an issue if multiple inheritance was better supported, but it's not.If it was, I could write the module explicitly around class A. Later, given a class B that should work fine with the module, I could derive Bprime inheriting from A and B and it would be fine.
Slashdot Mirror
That could be solved with a different heat exchange design. For example, one that transfers from metal to a gas loop then to water.
You haven't been reading the news if you don't realize that cops have been beating innocents, lying in court, claiming peaceful protesters are violent, and other such violations of rights that won't be so easy to get away with if the cop has to wear a camera.
These responsibilities have been with local authorities all along. What has changed? Technology? Funding?
A combination of rampant failure to uphold that responsibility and technology becoming available to address the situation.
The 4th, 1st, and 6th amendments. All of which have been regularly violated when nobody was looking.
I could as easily pick apart your arguments. I find it hard to imagine never using code that is shared with other projects for example. Why re-invent the wheel? Are you declaring code re-use dead? What about the system libraries? Do you hack those without notice too?
And what happened to unit testing where you should easily enough shake out cases where people called a function they shouldn't have?
I have argued that the programmer who just takes the IDE's word for it will eventually end up in deep trouble.
You seem to be arguing that duck typing is bad because shoddy practices rule.
Rule it destroyed evidence and therefor presumed to favor the other party.
For once though, the Feds would be acting within the Constitution by requiring this.
While plausible, your scenario plays out pretty much the same way now without the camera.
It's easily solved if the law requiring the cameras also requires that 'missing' video for any reason is to be treated as destroyed evidence in court. That is that it shall be assumed that the video was favorable to the other party's position.
So if the plaintiff in the civil suit says he was beaten unprovoked and the video is missing, then as far as the court is concerned, it would have shown an unprovoked beating.
At this point, I wonder how your "everything in comments" system architecture works, since you seem to have issues reading. I mean, nothing I wrote says "call functions randomly".
No, you just called whatever the IDE autopopulated with, apparently without bothering to check what it was. Or at least that's what you said may happen.
You also talked about calling functions based on oral lore that has changed over time. That sounds pretty cargo-cultish to me especially since you apparently believe that might be a fair reason to have never looked at the doc string.
By making it happen through gas taxes, it prevents really key roads from charging rapacious rent seeking tolls. It also prevenmts the building of two roads where one will do.
As an added benefit, your position cannot be tracked through gas taxes.
Then there's the right-of-way situation. Roads need to have right of way cleared and it isn't going to happen without eminent domain. Surely that's not the sort of power that any private corporation should ever wield.
It got autopopulated in my IDE, and *sounds like* the function I intend to use. Possibly even one I've used before and am mis-remembering the name of. The "Here be Dragons" got added later, when the signature of the function didn't change (or it did, but duck-typing, so no-errors, let's go!) I was told about the function verbally, so I never read the docs. I then told someone else. At some point, the oral tradition drops the "Here be Dragons". In a less formal code review (maybe someone in charge of many programmers, who cannot do a full read of all of their code) there is no way to easily have them find it all using grep.
If any of that happens, you absolutely positively deserve everything you get. DO NOT call a function if you don't know what it is!
My actual assertion, BTW is that duck typing has advantages to go with the disavantages.
I have worked on a number of large projects with multiple coders. I presume you use the old cut'n'past code 'sharing' method with a significant appearance of the cargo cult antipattern?
Your solution is really fragile. It requires never changing classes once they are created (at least the public members thereof) because you never know if they are used. Which, in some languages, or with some programmers, is all the members.
You need to RTFC as well. Surely you don't recommend unilaterally changing code used in other projects!
Sometimes the casting is actually the right thing though. An unfortunate side effect is that the IDE can't hold your hand anymore, you have to actually understand the code.
The thread is about Java being/not being an appropriate mid-point between Pyt hon-like interpreted languages and C++ like compiled languages.
See, that's not something that is easy to search for in code reviews. Because, there is no validation that I did not write: *** Off the edge of the world: Sea Serpents Around ***
Someone thinking of calling the function should certainly see it.
Ideally, it would then lay out the necessary attributes of the object if it's non-obvious.
Or it means the system has grown and evolved over time in ways not anticipated when it began. That is the nature of software. In fact, some of the most useful bits of software are that way (of course, so are some of the most useless).
Exactly. Especially when the reset to factory requires physical presence. In most cases it is exactly the right thing.
And yet, I see it happen. Nice to have a good clean recovery.
Or just pointing out that the girl did science and (in the same sense as saying Sir Issac Newton did not discover radium) the other scientists didn't do that particular science.
Yess, because of the HR and management problems I mentioned. There is no good technical reason for that.
So when I see a void*, I know that the documentation is really important.
def pickymethod(self, pickyobject):
"""Here there be dragons, beware"""
Although really you should write the module around Aprime, an interface, and then say that both A and B implement interface Aprime.
Problem is, A and the module that handles it is existing code used in multiple projects. IO don't want to do a cut/paste job and I don't want to risk breaking the other projects. B is from another existing module used by other projects. I REALLY just want to derive a Bprime that can serve as an A or a B as needed by the legacy modules.
Python does a decent job with multiple inheritance, but even so, it can get ugly so I might prefer duck typing and a compatible class.
As I'm sure we all know, a badly designed program in either kind of language can make the grass on the other side of the fence look greener.
True enough. As they say, it is possible to write a Fortran program in any language.
You sound bitter.
Based on the assignment and the response, flippancy is clear. Or did you suspect his neighbors somehow opened a rift in time to acquire a pet dinosaur? Perhaps they are witches?
Me lot? How many of me do you think there are? How about they blow the dust from their brains and act on credible threats rather than obvious non-threats? How about they do their job? How about they actually handle the situation like real adults instead of calling the cops every time someone sneezes?
So why didn't the hard scientists already know where the fungus was coming from?
That's right, because they didn't do the science. The girl in TFA did.
You can also cast things around until the compiler and IDE buy it and wait for the SEGV.
It's on the developer to know when they can and cannot get away with it.
If you don't KNOW if class A and Bs X methods are actually compatible, what in the hell are you doing passing them around? You're supposed to know that. If you have a case where it may or may not be true and it's all OK, wrap it in a try..except and pick up the pieces at runtime.
This would be a lot less of an issue if multiple inheritance was better supported, but it's not.If it was, I could write the module explicitly around class A. Later, given a class B that should work fine with the module, I could derive Bprime inheriting from A and B and it would be fine.