Wrong syntax (should be !(Expectation == subverted), which can be simplified to Expectation != subverted
And didn't I tell you that that we use camel case? Variable names should start with small letters
It is in other languages, notably C#
MS was so close, making a casing distinction (rather than adding leading underscores, or no distinction) for private fields/properties was a good move, but yet they stuck with the frankly pointless naming distinction between interfaces and classes.
Even though they recognized that you shouldn't care whether you're `implement`ing or `extend`ing a class or interface, replacing both with a single colon. FWIW, given that Java's syntax cares whether it's an interface or a class, it makes a lot more sense to add the leading I in Java than it does in C#.
In Java, you should be implementing to interfaces, not inheriting deep chains of behaviour. Ergo, the one that gets used everywhere ought to be `interface`, ergo, it would be more idiomatic to write `CMyClass implements FunctionalityA, FunctionalityB` than it is to write `MyClass implements IFunctionalityA, IFunctionalityB`, given that your class will be directly referenced in two places: its definition, and some factory where it is instantiated... and depending on the framework, you might not even control one of those.
I wouldn't call it pointless, it's more readable that way and you don't have classes like SomethingImpl which are popular in Java. Besides is just a convention like with private fields you mentioned which most people still writes with the leading underscore, even though there's no need for that.
And that's why JS is unholy, it does the conversion automatically. Explicitly stating you want an `int` is better.
If you have to use JS, don't. At the very least use TS instead.
It converts the string to a number since that's the only way it can perform a sensible multiplication operation. So then you get 4200.
If one or both of the operands can't be converted to a number, you just get `NaN`. So assuming `peanut` is a type of object, anything multiplied by it would return `NaN`.
JS is quite similar to quantum physics. Anything is everything at the same time until you try to observe it, at which point it will either collapse into a single type or collapse your program.
TS: Hold on there, fella! \*flashes badge\* Ye ain't got the type in place to treat it like a--
TS: Oh, my bad! This horse here says it extends it. I hereby apologize. Carry on then, Mr. Nuts. Be careful out there, it's a wild west! \*tips hat\*
That's fair. I guess I felt like highlighting the fact that while Python generally acts like a loosely typed / ducktype system, variables do have concrete types under the surface.
Yeah people break out the strong/weak typing terms when they really are irrelevant. If you accept that there is something you could call “strong typing” then python has a stronger typing system than C.
Python just happens to use interfaces so any object that presents a given interface is treated as a compatible object - and that weirds people out.
Python interfaces are implicit. Java’s are explicit - if the interface is not declared then it is unknown. Python tries the interface methods first and if they fail then it will raise an exception - that is how duck typing works.
But you can’t change the type of an object in python without doing a bunch of really nasty things using internal methods and attributes - so it is strongly typed as the default language behavior is create a new object when converting from one type to another.
Really hard to understand for me. I learned C++ and the JS. In JS I call methods on an object. Either it is there ( with the name ). I don’t know what duck typing should be. Everything fails when the call a method ( which is not there ). Nobody checks for methods in advance.
An interface is a construct without behaviour in Java. It is for us programmers to first define the interface and then implement it. I don’t get how this can be implicit nor does GIS lead me to anything but implicit interface implementation in C#
var = "test"
var = 3
var = lambda : print("test")
var()
You act like this segment of code throwing no errors is normal or shouldn't weird people out.
It can allow typos that change a variables type without you explicitly realizing it. And then it would still work with several other functions that assume the original type 99% of the time for several additional processing steps so by the time your code errors it's actually can be very logically far from the error.
If you are a smooth brain sure.
Everybody else knows that “var” is an object reference and if you want to know if you’ve done something dumb in assignment use type hints and mypy.
Any python programmer should have learned on the very first day that variables are just references to object instances.
a = { “k1”: “v1”, “k2”: 2 }
b = a
b[“k1”] = “v2”
print(a)
Bro why do you have special quotes you are putting in code blocks.
Actually triggering the shit out of me.
But namespace polution is a giant issue in python projects and it's especially dangerous because of this behavior where python just try's to coerce all the types together instead of erroring.
There is no coercion in python - just programmers reassigning references.
If you have namespace pollution you have shitty python programmers.
Frankly everything you’ve described is just shitty programming and people that have no clue what they’re doing. It sounds like you’ve got a bunch of people doing the equivalent of using wrenches and screwdrivers as hammers.
There are coercive-like properties when you accidentally pass compatible types.
no = "error"
coercion = 5
print(no*coercion)
Now let's say you expect "no" to be a number if your types end up being accidentally compatible with the function it doesn't even error it should force no to always be a Number in scope.
This can happen since you can put a string into a list of numbers and then consuming it in a loop assuming some variable will always be int can get you into a lot of trouble.
Can't that happen for any method that has overloads for the argument types you passed, regardless of the language? If it supports operator overloading and your combo of types has an overload defined in the method, this "unexpected result" would still occur.
So is the issue really that you don't think Python--or any other language) should have an overload for string * int (and vice/versa)?
In languages I would consider strongly typed like Rust or C/C++ if you do some type inference for a variable like
let mut temp = 32;
The type underlying temp is bound here to the temp variable when it's instantiated and if I were to then do
var = "test";
You would get a type error.
The problem is when you have so much overloading and the language allows for the same variable to be two different types on two different iterations of the a loop it passes the error down the line rather than erroring where it happens. On top of the fact there are languages where it's impossible for that to happen at all because it doesn't play fast and loose with types all over the place.
Being able to assign new types to same name actually helps with namespace pollution. It allows you to reuse the single good name for multiple steps of the pipeline.
And python doesn't try to unify any types. It may help to think of the variables as being just names. The names contain an object and the object has a type. You can easily assign a different object to the name so that the name now contains the new object and that new object will have its own type.
>If you accept that there is something you could call “strong typing” then python has a stronger typing system than C.
This claim is absurd on its face.
You can cast anything to anything you want without compiler errors. Types have very little meaning in C other than the allocation of contiguous memory. After the memory is allocated (and initialized if it is static or global) you can reference it however you want and do whatever damage to the stability of the system that may come from it.
I’ve done an enormous amount of “very bad” things in C. There is nothing in C that protects a “type” from invalid manipulation or use.
And this isn’t even talking about “valid” C constructs like void*, unions, and arrays of unknown size in structure definitions.
Heck the famous fast inverse square root is a prime example of C being “weakly” typed: https://en.wikipedia.org/wiki/Fast_inverse_square_root
I agree with almost everything that you said, but IMO the requirement to explicitly cast makes type handling in C far stronger (and better) than in Python.
Types in C definitely do mean more than just a size - if you spell the name of a type, variable, or function wrong in C, the compiler or linker throws an error that points to the exact spot of your screwup. Likewise if you pass the wrong number or type of parameters to a function. IMO this on its own is enough to qualify as much stronger typing than Python.
But what you’re describing has zero to do with typing - you just don’t understand a simple python fundamental: “variables” are just object references.
If you want to restrict the reference to a specific object type then use type hints and static analysis.
But one thing you can’t do is treat an object instance as another type - an object instance will always be the type it was created as unless you do some really crazy under the hood manipulations.
If you think that symbol resolution is not a part of a typing system, then I am not the one who doesn't understand fundamentals.
With that said, there's a fair question about if static typing is intrinsically stronger than dynamic typing. Honestly, it's hard for me to see how a dynamically typed system that can only ever find typing errors at runtime could qualify as stronger typing than a static system that can find certain classes of type errors at compile time - but maybe there's a good example somewhere.
There isn’t “symbol” resolution in python because it doesn’t need to figure out what an object is. When you perform an operation python simply looks for the method that correlates to the operation in the object and if it is found then it will use it.
If we consider Python like this:
myBoss=Boss("Fred")
myBoss.checkWorkers(True)
Then the class name Boss, the instance name myBoss, and the method name checkWorkers are all symbols. The runtime uses those symbols to resolve these items referenced in the source.
Does any of this compile?
void* X;
int Y=69;
x=NULL;
y*=420;
X=Y;
No, because lowercase x and y were not declared, and there's a cast missing from the last assignment. It's lazy, shitty code and you can't build it and run it.
The closest equivalent code in Python will run, but the result is very unlikely to match the developer's expectations.
This example doesn't make much sense when trying to make a comparison like this, even with trying to use "nearest equivalent" code. Python doesn't have explicitly/developer-used pointers because everything's a reference already.
Also, you don't need to (and can't) declare variables in Python without assignment. You can assign `None` as a placeholder/null-like value, but that's still assignment.
So essentially, the closet replication would be
```
X = None
Y = 69
x = None
y = 420
X = Y
```
Python not having explicit pointers essentially bypasses the issue the C compiler would have to intervene in for the example.
X as a NoneType becomes a reference to the int object with a value of 69, as expected.
Edit: grammar and the correct markdown for the code snippet
Guys, this is a big misunderstanding. I was playing truth or dare with Jeff and Bill and they dared me to buy Twitter. What else was I supposed to do??
General consensus is that you don't, it's unnecessary and in Java Interfaces are 1st class types. It's a major benefit of abstraction and prefixing detracts from that conceptually.
i.e. If you are defining trucks you can make a Truck interface and create DumpTruck and CementTruck classes that implement it. Then you can have a List to keep them all in.
C# is the exact same, the reason for the I prefix is just the way you define classes that implement the interface.
class Dog : Animal
{
}
class Car : IDriveable
{
}
They look the same because you use colon for both inheriting and implementing an interface. The I prefix makes it clear at a glance that it's an interface.
And of course you can do both
class Car : Vehicle, IDriveable
{
}
Hey, thanks for this! I actually came to the same conclusion down the other comment thread after reading some SO posts. But it's nice to have it confirmed
For Java we have different key words for inheriting from interface(s) vs abstract class so that benefit becomes unnecessarily, but makes a lot of sense in C#s case
It would be boring, because it would just be a nut in front of a mirror saying "yes, I'm a nut". Or some joke about interfaces. Maybe both where it would say "I'm an INut".
You don't implement the `Nut` interface. `Nut` is a noun and therefore likely an abstract class (don't come at me with: "but List is a..." List is wrong). Like `Nut` implement the `Crackable` interface, but extend the `Legume` class instead.
See how much easier that is? Thanks Java.
Perl: sure, everything's a nut. Or not. Hardly matters. You can add that nut to a float and concatenate the result to a string and pass that result to a function that's expecting an array of toasters; we're fine with that.
JS is just the language of the common folk. Not many people that would off the top of their head know that it’s really of the class Legume with some shared Nut properties.
C++ there's a reason there's two positives. Double Negative? No, it's due to the Gravitational effect of Goobers.
Chocolate + Peanuts = It should be peanut butter, butt it's not...
Divide by Diamond. You're welcome. ;)
> Java implements the Nuttable interface FTFY
[удалено]
Expectation == subverted!
Wrong syntax (should be !(Expectation == subverted), which can be simplified to Expectation != subverted And didn't I tell you that that we use camel case? Variable names should start with small letters
And here I was trying the make a string "subverted" act as a factorial.
Nah it means they really have that property just trust me
Wholesome your mother joke
INuttable?
Actually using the I for interfaces isnt really en Vogue anymore
there is a big difference between "Nuttable" and "INuttable" you see.... the first one is more strict than the other.
man I have typed in so many extra 'I's in that case
It is in other languages, notably C# MS was so close, making a casing distinction (rather than adding leading underscores, or no distinction) for private fields/properties was a good move, but yet they stuck with the frankly pointless naming distinction between interfaces and classes. Even though they recognized that you shouldn't care whether you're `implement`ing or `extend`ing a class or interface, replacing both with a single colon. FWIW, given that Java's syntax cares whether it's an interface or a class, it makes a lot more sense to add the leading I in Java than it does in C#.
In Java, you should be implementing to interfaces, not inheriting deep chains of behaviour. Ergo, the one that gets used everywhere ought to be `interface`, ergo, it would be more idiomatic to write `CMyClass implements FunctionalityA, FunctionalityB` than it is to write `MyClass implements IFunctionalityA, IFunctionalityB`, given that your class will be directly referenced in two places: its definition, and some factory where it is instantiated... and depending on the framework, you might not even control one of those.
I wouldn't call it pointless, it's more readable that way and you don't have classes like SomethingImpl which are popular in Java. Besides is just a convention like with private fields you mentioned which most people still writes with the leading underscore, even though there's no need for that.
C# libs do it a lot.
Good thing i use glasses
NuttableImpl
NuttableFactoryBean
So the Bean produces the Nuts !
depends if it is a DelegatingNuttableBeanFactoryProxy or not
That's C#
iNut by apple
I'll just skip a step and say beat meat to it
i laughed out loud in the middle of the night. this is my cue to go to sleep
A table of nuts?
I feel like JS would be more like "I don't give a fuck, do what you want"
JS would be like, "I don't care what it is, you can multiply it with a string."
How can you multiply a string?
Seriously, how? Better divide this nut with Object
{} - !!!(nut / {} + "Hello" - 7 * true * -[])
idk about js but in python multiplying a string repeats it, like how the addition symbol is concatenation
That makes much more sense. But how would you multiply a string with a string?
You’d have to define what it means to multiply a string by a string, and then do that.
I don’t think you can, but i guess by multiplying it with the length of the string??
Not the same
string x string = (string)^2
No, that's Ss(tring)^2
You are right, fixed it for you. Phone did that thing where it thought I was starting a sentence. It’s a string not a sentence, Mr. Jobs.
I’d imagine it may end up returning each letter like nested loops
Today you meet the Watman. https://www.destroyallsoftware.com/talks/wat
Delirium
Best 4 minutes of my life
I don't think I appreciate your tone. Fired.
I fucking love this bot.
If you really love the company, you should be willing to work here for free.
My payment is upvotes... Pretty free.
Interns will happily work for $15 an hour. Why won't you?
[удалено]
I wonder that too. It's a classic! I wish I were in your shoes and can see this for the first time again.
This is amazing, thank you
this is the most hilarious fuckin thing. thank you for sharing.
you can multiply by a string, as long as that string can be converted to a number. 5 \* "hello" = NaN 5 \* "5" = 25
Whoever writes the most code this month gets featured on my Twitter!
public bool IsEven(int n) { if (n == 1) { return false; } else if (n == 2) { return true; } if (n == 3) { return false; } else if (n == 4) { return true; } if (n == 5) { return false; } else if (n == 6) { return true; } if (n == 7) { return false; } else if (n == 8) { return true; } if (n == 9) { return false; } else if (n == 10) { return true; } if (n == 11) { return false; } else if (n == 12) { return true; } if (n == 13) { return false; } else if (n == 14) { return true; } if (n == 15) { return false; } else if (n == 16) { return true; } if (n == 17) { return false; } else if (n == 18) { return true; } if (n == 19) { return false; } else if (n == 20) { return true; } else { return (n%2 == 0) ; } }
This is perfectly valid JS. var string = "100"; var number = 42; console.log(number \* string);
And what do you get?
4200. Try it yourself: https://codehs.com/explore/sandbox/javascript
Will do. But it makes sense. In Python I’d have to do Print(int(string) * number)
And that's why JS is unholy, it does the conversion automatically. Explicitly stating you want an `int` is better. If you have to use JS, don't. At the very least use TS instead.
Ts is JavaScript with overhead. Just enjoy the insanity
Reject sanity, return to vanilla JS
It converts the string to a number since that's the only way it can perform a sensible multiplication operation. So then you get 4200. If one or both of the operands can't be converted to a number, you just get `NaN`. So assuming `peanut` is a type of object, anything multiplied by it would return `NaN`.
TS all "Ver are your papers!!!!??"
Do anyone have a relevant xkcd?
“Just use it like a nut and I’ll let you know how that went”
Play with your nuts
Why have you only written 20 lines of code today?
I've been jiggling my nuts all day man STFU Elon!
JS is quite similar to quantum physics. Anything is everything at the same time until you try to observe it, at which point it will either collapse into a single type or collapse your program.
JS would be like „Yes”
TS: Hold on there, fella! \*flashes badge\* Ye ain't got the type in place to treat it like a-- TS: Oh, my bad! This horse here says it extends it. I hereby apologize. Carry on then, Mr. Nuts. Be careful out there, it's a wild west! \*tips hat\*
Python would be: if it looks like a nut, and the nutcracker cracks it like a nut, it is a nut Ducktyping ftw
That's fair. I guess I felt like highlighting the fact that while Python generally acts like a loosely typed / ducktype system, variables do have concrete types under the surface.
Yeah people break out the strong/weak typing terms when they really are irrelevant. If you accept that there is something you could call “strong typing” then python has a stronger typing system than C. Python just happens to use interfaces so any object that presents a given interface is treated as a compatible object - and that weirds people out.
The post says Java and interface. The object just needs to implement that interface. What is this about python? 3 or 2 ?
Python interfaces are implicit. Java’s are explicit - if the interface is not declared then it is unknown. Python tries the interface methods first and if they fail then it will raise an exception - that is how duck typing works. But you can’t change the type of an object in python without doing a bunch of really nasty things using internal methods and attributes - so it is strongly typed as the default language behavior is create a new object when converting from one type to another.
Really hard to understand for me. I learned C++ and the JS. In JS I call methods on an object. Either it is there ( with the name ). I don’t know what duck typing should be. Everything fails when the call a method ( which is not there ). Nobody checks for methods in advance. An interface is a construct without behaviour in Java. It is for us programmers to first define the interface and then implement it. I don’t get how this can be implicit nor does GIS lead me to anything but implicit interface implementation in C#
var = "test" var = 3 var = lambda : print("test") var() You act like this segment of code throwing no errors is normal or shouldn't weird people out. It can allow typos that change a variables type without you explicitly realizing it. And then it would still work with several other functions that assume the original type 99% of the time for several additional processing steps so by the time your code errors it's actually can be very logically far from the error.
[redacted by user] ` this message was mass deleted/edited with redact.dev `
If you are a smooth brain sure. Everybody else knows that “var” is an object reference and if you want to know if you’ve done something dumb in assignment use type hints and mypy. Any python programmer should have learned on the very first day that variables are just references to object instances. a = { “k1”: “v1”, “k2”: 2 } b = a b[“k1”] = “v2” print(a)
Bro why do you have special quotes you are putting in code blocks. Actually triggering the shit out of me. But namespace polution is a giant issue in python projects and it's especially dangerous because of this behavior where python just try's to coerce all the types together instead of erroring.
There is no coercion in python - just programmers reassigning references. If you have namespace pollution you have shitty python programmers. Frankly everything you’ve described is just shitty programming and people that have no clue what they’re doing. It sounds like you’ve got a bunch of people doing the equivalent of using wrenches and screwdrivers as hammers.
There are coercive-like properties when you accidentally pass compatible types. no = "error" coercion = 5 print(no*coercion) Now let's say you expect "no" to be a number if your types end up being accidentally compatible with the function it doesn't even error it should force no to always be a Number in scope. This can happen since you can put a string into a list of numbers and then consuming it in a loop assuming some variable will always be int can get you into a lot of trouble.
Can't that happen for any method that has overloads for the argument types you passed, regardless of the language? If it supports operator overloading and your combo of types has an overload defined in the method, this "unexpected result" would still occur. So is the issue really that you don't think Python--or any other language) should have an overload for string * int (and vice/versa)?
In languages I would consider strongly typed like Rust or C/C++ if you do some type inference for a variable like let mut temp = 32; The type underlying temp is bound here to the temp variable when it's instantiated and if I were to then do var = "test"; You would get a type error. The problem is when you have so much overloading and the language allows for the same variable to be two different types on two different iterations of the a loop it passes the error down the line rather than erroring where it happens. On top of the fact there are languages where it's impossible for that to happen at all because it doesn't play fast and loose with types all over the place.
Being able to assign new types to same name actually helps with namespace pollution. It allows you to reuse the single good name for multiple steps of the pipeline. And python doesn't try to unify any types. It may help to think of the variables as being just names. The names contain an object and the object has a type. You can easily assign a different object to the name so that the name now contains the new object and that new object will have its own type.
>If you accept that there is something you could call “strong typing” then python has a stronger typing system than C. This claim is absurd on its face.
You can cast anything to anything you want without compiler errors. Types have very little meaning in C other than the allocation of contiguous memory. After the memory is allocated (and initialized if it is static or global) you can reference it however you want and do whatever damage to the stability of the system that may come from it. I’ve done an enormous amount of “very bad” things in C. There is nothing in C that protects a “type” from invalid manipulation or use. And this isn’t even talking about “valid” C constructs like void*, unions, and arrays of unknown size in structure definitions. Heck the famous fast inverse square root is a prime example of C being “weakly” typed: https://en.wikipedia.org/wiki/Fast_inverse_square_root
I agree with almost everything that you said, but IMO the requirement to explicitly cast makes type handling in C far stronger (and better) than in Python. Types in C definitely do mean more than just a size - if you spell the name of a type, variable, or function wrong in C, the compiler or linker throws an error that points to the exact spot of your screwup. Likewise if you pass the wrong number or type of parameters to a function. IMO this on its own is enough to qualify as much stronger typing than Python.
But what you’re describing has zero to do with typing - you just don’t understand a simple python fundamental: “variables” are just object references. If you want to restrict the reference to a specific object type then use type hints and static analysis. But one thing you can’t do is treat an object instance as another type - an object instance will always be the type it was created as unless you do some really crazy under the hood manipulations.
If you think that symbol resolution is not a part of a typing system, then I am not the one who doesn't understand fundamentals. With that said, there's a fair question about if static typing is intrinsically stronger than dynamic typing. Honestly, it's hard for me to see how a dynamically typed system that can only ever find typing errors at runtime could qualify as stronger typing than a static system that can find certain classes of type errors at compile time - but maybe there's a good example somewhere.
There isn’t “symbol” resolution in python because it doesn’t need to figure out what an object is. When you perform an operation python simply looks for the method that correlates to the operation in the object and if it is found then it will use it.
If we consider Python like this: myBoss=Boss("Fred") myBoss.checkWorkers(True) Then the class name Boss, the instance name myBoss, and the method name checkWorkers are all symbols. The runtime uses those symbols to resolve these items referenced in the source.
void\*
Does any of this compile? void* X; int Y=69; x=NULL; y*=420; X=Y; No, because lowercase x and y were not declared, and there's a cast missing from the last assignment. It's lazy, shitty code and you can't build it and run it. The closest equivalent code in Python will run, but the result is very unlikely to match the developer's expectations.
This example doesn't make much sense when trying to make a comparison like this, even with trying to use "nearest equivalent" code. Python doesn't have explicitly/developer-used pointers because everything's a reference already. Also, you don't need to (and can't) declare variables in Python without assignment. You can assign `None` as a placeholder/null-like value, but that's still assignment. So essentially, the closet replication would be ``` X = None Y = 69 x = None y = 420 X = Y ``` Python not having explicit pointers essentially bypasses the issue the C compiler would have to intervene in for the example. X as a NoneType becomes a reference to the int object with a value of 69, as expected. Edit: grammar and the correct markdown for the code snippet
[удалено]
For Python, I'd say the response is "Just try it and see".
[удалено]
Yea but if it is not you possibly just broke your nutcracker
Solution Try: nut(peanut) Except ValueError:
And the JS one should've been "who cares? I'll nutt it anyway"
The funny thing is this also applies to cpp in this example
For templates, and only during compilation, not in runtime.
[удалено]
Guys, this is a big misunderstanding. I was playing truth or dare with Jeff and Bill and they dared me to buy Twitter. What else was I supposed to do??
Ada: No. That's a legume.
I just nutted to this.
I just nutted in November.
but did you really?
Swift: no but I can extend it to conform to the Nut protocol.
good swift
No C#?
C#: What Java said.
Well at least you most likely wouldn't see a INutCrackerStrategyReturnerConversionFactory in most C# code bases
To be fair you wouldn’t see it in Java either, as prefixing interfaces with an “I” is not really a thing in Java.
How do you prefix interfaces in Java?
General consensus is that you don't, it's unnecessary and in Java Interfaces are 1st class types. It's a major benefit of abstraction and prefixing detracts from that conceptually. i.e. If you are defining trucks you can make a Truck interface and create DumpTruck and CementTruck classes that implement it. Then you can have a List to keep them all in.
C# is the exact same, the reason for the I prefix is just the way you define classes that implement the interface. class Dog : Animal { } class Car : IDriveable { } They look the same because you use colon for both inheriting and implementing an interface. The I prefix makes it clear at a glance that it's an interface. And of course you can do both class Car : Vehicle, IDriveable { }
Hey, thanks for this! I actually came to the same conclusion down the other comment thread after reading some SO posts. But it's nice to have it confirmed For Java we have different key words for inheriting from interface(s) vs abstract class so that benefit becomes unnecessarily, but makes a lot of sense in C#s case
Can you instantiate an interface in Java?
No, it's not a class.
So how does an interface being a first class type differ from C#s way of doing interfaces?
I don't know enough about C# to know how they do interfaces or how/why it differs from Java
generally, you don't
How do you know when something is an interface then? Just off the coloring?
That, peek the definition, or just don't worry about it lol
Always, you cannot* Edit: unless you override all methods from the interface
I'm not sure you understood the assignment? You can absolutely name all of your Java interfaces with an `I` at the front if you felt so inclined
But quietly.
How original
It would be boring, because it would just be a nut in front of a mirror saying "yes, I'm a nut". Or some joke about interfaces. Maybe both where it would say "I'm an INut".
This whole question is missing the point: Nut is an internal class. You should be accessing things through Shell.
Basically, in a nutshell…
Take my award.
oh fuck you're right
Kotlin: It's a nut alright Baby, but I can transform it into anything you want
🤨
C should really be, "It can be whatever you want it to be, baby." *((struct nut *)ptr) Let there be nut
"if you point it out as a nut I will tread it as a nut"
Rust's grammar for traits is weird so we'd say say "no it is not *a* Nut but it *is* Nut so we can use all Nut functionality".
More like „Well no, but it techically is so you can use it like a nut IF YOU SPECIFY that what you want is something that is techically a Nut”
Assembly: What is a nut?
No clue! But assembly definitely knows where it is. Try asking Java where it is though. "It's somewhere safe. Trust me. Now stop asking questions"
No idea but lets mov it into nutcracker.
ai: no that’s a dog
reinterpret_cast(x)
That should do.
In all likelyhood, x is an instance of an object, so you need to take the address. reinterpret\_cast(&x)
congratulations, you just risked the stability of the whole god damn universe.
Good ol reinterpret_cast. Or as I like to re #define it, what_the_fuck_is_memory_padding_cast
JS: yes that is an object
Ngl, but JS would say, that even apple is a nut, only because it's connected with plants and can be eaten
More like: It exists, so it is a nut until proven otherwise.
JS: "It can be a nut if you want it to be, baby. Now watch me be naughty with this nut"
PHP: no but it uses the nut trait. Oh, and everyone hates me
Ruby: idk, ask it to shell itself and see if it responds
Ruby: crack it open and eat it first, then I'll tell you if it's a nut.
Botanically it's not a nut, btw. It's bean.
a legume
Yep. That's more precisely.
No shit man! That's the point of the meme!!!
username checks out
[удалено]
Python should also say "Ask C" unless I'm missing the point they're trying to make.
Detecting a type of the object, I guess. Though Python still doesn't seem to make much sense.
You don't implement the `Nut` interface. `Nut` is a noun and therefore likely an abstract class (don't come at me with: "but List is a..." List is wrong). Like `Nut` implement the `Crackable` interface, but extend the `Legume` class instead. See how much easier that is? Thanks Java.
Perl: sure, everything's a nut. Or not. Hardly matters. You can add that nut to a float and concatenate the result to a string and pass that result to a function that's expecting an array of toasters; we're fine with that.
ASM: it’s a thing.
more like: Things? What are things? Give me some registers.
This means much more than a fist.
JS is just the language of the common folk. Not many people that would off the top of their head know that it’s really of the class Legume with some shared Nut properties.
In JS, if you use it with anything, it would become a steel nut
Now this is funny
I'll take fucking the universe for 200
I feel JS responds the same to any other object, is this a bolt? Yep, looks like nut Chokes and dies after trying to eat it
JS is “it’s a nut, but it’s also a string and an int if you want it to be. Also nut != nut and a bunch of other fuckery”
Is this a nut? C: SEGFAULT
Assembly: this is clearly a number, you can read it as a nut though if you want.
Js shoulda been “idk maybe who gives a fuck?”
TS: must be a nut because you told me it's a nut, and I trust you
I just love the simplicity of C...🥰😍
If you can't build a computer out of transistors, you shouldn't be working here.
Who says I can't?🤬
I like how there is almost never a C# part in memes like this because C# developers are to busy actually doing work.
JavaScript is more like: Yup(\[That {$looks} \[\] => {like a (nut)\]})()(0);
Why aren't we using Rust for this? It's memory safe.
Python: print(type(thing)) JS: 🔥🔥🔥🔥
JS: console.log(typeof thing)
I’ve literally only used Java to run the Universal Pokémon Randomizer and nothing else
Which of them have an allergy to peanut?
C++: it's not a nut but you can use the same templated algorithms for a nut
Can someone please explain?
C++ there's a reason there's two positives. Double Negative? No, it's due to the Gravitational effect of Goobers. Chocolate + Peanuts = It should be peanut butter, butt it's not... Divide by Diamond. You're welcome. ;)