I am worried about the yet another illustration of how the Federal government's control reaches into the crooks and nannies it was never supposed to reach.

But that's just an appeal to authority. I will grant, for the sake of argument, that it is working around the intent of the 10th amendment. I just don't see why I should care. I mean, the 10th amendment made sense when slavery was an sometimes (someplaces) thing; when it took forever to cross a state boundary, and the idea of traversing three states in the course of commuting would be a fanciful idea.

On a second point, I'd further content that cameras on cops are a rights issue - and are fully under the purview of the feds under Amendment 14

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?

You could move the goalposts like that. I explicitly didn't respond because that is trying to derail the conversation.

But what the hell. You've stopped actually responding to the points I make.

So, I would contend that code reuse is helped, not hampered, by compiler-verified interfaces. I would contend that your "code reuse" is so stifling that it is literally inferior to copy-and-pasting... at least with copy-and-pasted code you can improve the module you copied without worrying that it breaks things.

And what happened to unit testing where you should easily enough shake out cases where people called a function they shouldn't have?

Why do you want to re-invent the wheel. Now, unit testing is good, but using unit testing to re implement (imperfectly) interfaces is, well, crazy.

I have argued that the programmer who just takes the IDE's word for it will eventually end up in deep trouble.

No, you've argued that programmers are perfect, that the comments will always be accurate, functions you call will never change, and the comments always need to be read for every getter and setter. And that's just to reject my examples.

And I categorically reject any of the above.

You seem to be arguing that duck typing is bad because shoddy practices rule.

Since the only example you have been able to give as to why duck-typing has any benefit, is as a patch to shoddy use of interfaces, this seems a remarkably dumb statement. I contend that duck-typing hurts the ability of the computer to detect errors, and your only response is that some people didn't properly use interfaces in legacy code. Not that interfaces are somehow a bad way to program. But a shoddy programmer may not have used them.

Well, fuck that. A paradigm that gives up useful features to paper-over shitty work, or allows code reuse between kinda existent modules via unspecified hack code that works 95% of the time is bad. Heck, any code that would need to be papered over like you suggest probably shouldn't be trusted. Duck typing is bad, it encourages bad practices and bad coding, and allows bad programmers to continue programming with silent errors as opposed to either fixing their shit or quitting their job and flipping burgers.

Cops have the authority and discretion to issue verbal or written warnings instead of citations for moving violations, so video recording won't change that.

And indeed, sometimes the requirement. For instance, in a state that shall remain nameless, the state patrol on drunk driving duty is supposed to pull over people who cannot stay between the lines. They don't bother citing the people who spilled soda in their lap, or were distracted, etc. It's not what their job is. But they do give a formal warning. That way, when their patrol is over, their sergeant can see they weren't asleep, or at a strip club.

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.

Right, because you thought that the function was a different one because you misremembered the name. Or because you would assume a function like "getCurrentHealth()" would return the health of a character, and not, I don't know, concatenate two Strings randomly. Especially if that's what similar, or identically named, functions do throughout a library.

But, yeah, it may happen.

And oral lore is really "consulting with collegues" Which totally happens in real situations. If I ask someone, for example, how to get an arctan value outside the -pi/2 to pi/2 range, them explaining quickly how to use atan2f is more valuable than telling me a function name and "GTFO;RTFM".

Bottom line, I'm advocating for computers doing the work instead of comments (which may be unread, or out of date, or literally written after the code that referred to them). I posit many, many, reasons why having a computer check for errors instead of a human being. Your only response is that "Dude, but then I cannot hack two systems together using magic glue that happens to work, and enforces on everyone a requirement of never even optimizing their code, because any change could break my system. And could be avoided if I followed best practices."

When every advantage you suggest can be done in a superior way without using duck typing, I'm blown away. You have argued that perfect programmers don't need the fuckin' IDE, they can check their own work. Well, perfect programmers don't need the fuckin' comments either, they can read the entire code and know what happens.

I can only assume you're trolling, because while I've heard people defend duck-typing before, I've never heard such a malformed argument.

I presume you use the old cut'n'past code 'sharing' method with a significant appearance of the cargo cult antipattern?

Clearly the only reason you would say something like that is a particularly stupid ad homenim. I'm talking about using interfaces and code review. I'm talking about best design practices. Clearly, since I'm advocating for using interfaces, I'm not copy-and-pasting code. But advocating for what you are advocating for is actually really compatible with cut-and-pasted-code.

But that level of intentional misunderstanding may bleed into my responses below.

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!

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".

I talked about an obvious human error (incorrect memory of a name); I talked about being given information from a collegue; I talked about coordination issues where function signatures changed; and I talked about how hard it made code reviews.

The fact that you don't seem to recognize these possible issue makes me question your experience. Because these are all things that happen.

Surely you don't recommend unilaterally changing code used in other projects!

I'm not going to make an argument here, because this is obviously going to lead to a conversation derailing where you don't address my valid points above.

Obviously the threshold of proof for the latter is a lot higher.

You mean like entering into said contract with burner everything, provided in a kit with instructions on how to avoid methods designed to detect a high likelihood of said contract breach?

The thread is about Java being/not being an appropriate mid-point between Pyt hon-like interpreted languages and C++ like compiled languages.

Well, first, C++, Java and Python all have multiple inheritance. Java just only does it with interfaces. Which you objected to by stating no one did multiple inheritance except Python.

But at a higher level, this sub-thread seems to be about your assertions that duck-typed and interpreted languages are superior to compiled languages.

Someone thinking of calling the function should certainly see it.

Really? Cause I can think of a lot of reasons that's not the case. Just in like 2 minutes:

1. 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.
2. 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!)
3. 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".
4. 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.

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.

Further, the only situation you seem to be able to suggest where it is useful is when you have, I'm assuming read-only, access to two modules, and need to create some code that hacks both of them together. And at least one module declines to use the proper method of defining interfaces and using those.

To get that feature, you're willing to jettison a ton of compile time checking, make the codebase fragile and hard to change.

Honest questions: Have you ever worked on a large codebase? Multiple developer? Multi-year? Cause what you write makes me assume that you, in fact, do not. That your big issues are hacking together two JQuery modules, and you make websites where you're the sole coder.

Python does a decent job with multiple inheritance,

Eh, so does C++.

The only time C++ really has trouble is if A and B share the names of methods/variables. And the reason they will have trouble is that there is no solvable way to not have trouble. Not for a computer. Not for a programmer.

Although, I don't see how you can possibly go wrong, if you can write to the module that contains A creating an interface A implements, and changing the code that the module uses to use said interface.. There's no difference for backwards compatibility. (Unless you don't believe in namespaces, and have to worry about truely unique names everywhere.)

"""Here there be dragons, beware"""

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 ***

And if you cannot trust other programmers to use fucking interfaces, you cannot trust them to use the right magic strings.

Then I thought, well perhaps designer spends years designing a game with all sorts of clever ideas then copiers use them all a few days after release. I have to ask, though, is this what happens?

What happens is that the developer has dozens of ideas, and the 30th one actually works. People like it; people play it. It has the right "stuff" that it becomes a success. Finding that combination is what takes years. Actually producing that one game may have only taken the amount of time it takes a copier.

Although tuning very well also takes a lot of time.

Surely a game must spend some time before becoming popular enough to copy, during which it builds a following and has first mover advantage. Copiers can't copy those advantages

Well, I mean, Candy Crush is a cheap knockoff. Sometimes, marketing muscle beats out organic growth. Hell, Zynga used to threaten (and follow through on threats to) to just clone games if they would not sell, and then popularize the Zynga version through their marketing. They then would crush the original.

Hell, there are lists, both in games and in the world, where people think that the original is a cheap knockoff.

My favorite example is Hydrox vs. Oreo, but numerous others exist.

You can also cast things around until the compiler and IDE buy it and wait for the SEGV.

You can do a lot of things. But having a code that says "danger, this code requires a lot of care to touch." is a good thing. Casting things through a void* or something like that is an excellent example of how you can detect that when reviewing or working on code. Plus, that's the exception. So when I see a void*, I know that the documentation is really important.

It's on the developer to know when they can and cannot get away with it.

I don't understand why. Fundamentally, it seems superior to have a computer check for bugs for you. That's what static code analysis is all about.

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.

Because I'm human, and made a mistake? Because when I wrote the code they were compatible, but then someone changed the definitions of one of the classes without knowing it would break my assumed usage because they weren't aware of everywhere that the code would be used in the entire codebase. Because there are multiple developers on a project?

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.

But it actually is pretty well supported, especially in this case. I mean, actual multiple inheritance is always a shitshow. But interfaces are totally well supported and easy to use. I don't understand what issues you think arise from using interfaces. But I can say that what you describe is pretty much what should happen. Although really you should write the module around Aprime, an interface, and then say that both A and B implement interface Aprime.

Duck typing is a mixed bag.

Curious, let's see how.

You can make the requirements clearer in comments and the doc string.

I suppose that's the admitted disadvantage? That I can type more to have limitations enforced by humans instead of machines.

t also has great advantages in being more concerned with attributes than declared type or lineage. It allows modules to deal with classes that weren't even imagined when they were written.

You mean like interfaces would let you do?

Pascal was a good choice of learning language. Now that OOP has proven out, Java is a good choice. Stay away from the rest until you're competent in one of those two.

If you don't start out dealing with hand-managed memory, you don't learn how memory works. Which means you do stupid shit later.

n many sites you'll be met with messages such as: We've noticed that you have an Ad Blocker, as we're depending on advertisement revenue to provide you with free services - we will kindly ask you to turn your Ad Blocker off and reload the page to see your content.

I don't think I've ever seen that message.

And we could still have e-comerce on the web, we could still use sites like Amazon rather than having to drive miles to get to a limited selection and pay higher prices at a local "friendly" bookstore. But somehow there would be no advertising.

The idea that Amazon, or any of e-commerce, would disappear in the absence of ads on the web is really really strange. Do you know that Amazon makes their money off selling things and content, not ads? They buy goods for lower prices then they sell them, and make money on a "markup". And the same is true of all e-commerce sites?

Like, eBay takes a cut of transactions. It doesn't show ads.

Why wouldn't Google exist (as a search engine) without advertising. I mean, they made the engine, and monetized it later. Lacking ads, they could probably get by just fine ala Wikipedia.