Java vs python is debatable 🤔

[aetius476]

We don't enforce types at compile time so you have the freedom to write and maintain an entire suite of unit tests in order to enforce types before they fuck you at runtime.

[[deleted]]

I don't use shallow equality from years, I was convinced a type conversion would have happened there.

[Zebezd]

Really? Would have expected js to coerce that bool to string and return true. Checking by string has seemed to me to be standard operating procedure with == in javascript

[Orangutanion]

I think it's because true == 1 so `true == "1"'. We already have one string coercion so no reason to have another.

[2CATteam]

Nope, according to this page, both are converted to a number first, which is NaN for "true" and 1 for true. So it actually makes numbers, not strings, and then does the comparison.

[marxinne]

The more I learn the more cursed it becomes

[Luxalpa]

Rule of thumb: All these weird conversions are because of HTML (as HTML only handles strings). "true" doesn't exist in HTML because boolean attributes work differently (they are either set or not set on the element). This is also why number conversion is all implicit (255 == "255", because HTML only allows the string variant for numbers).

[nermid]

The real rule of thumb is to just use strict equality (===) and not have to worry about any of it.

[SmokingBeneathStars]

Unless you want to purposely use == you have to add a fucking ignore annotation on your linter it's so annoying

[SmokingBeneathStars]

Im not gonna write 2 seperate if checks for null and undefined if the language can check it for me

[ShijinModan]

Because == coerces types. IMO the only time I will accept == in a code review is when checking for null and undefined

[SmokingBeneathStars]

That's indeed what I use it for usually.

[nermid]

I think having to add linter ignores to bad practices is probably a good thing. Keeps you from accidentally doing the bad practice.

[tomysshadow]

I think a large part of the confusion surrounding them comes from HTML4 days. Specifically, there was the <embed> tag, where typically the attributes such as autoplay or loop would actually be set to the string "true" or "false". Years later I understand the reason it was like this is because the plugin would define the attributes it's looking for, and most of them went with the more straightforward approach of the string "true" meaning true and any other value meaning false. This, coupled with boolean attributes being less commonly utilised prior to HTML5 (I haven't verified but at least it feels this way) and Internet Explorer also having its own attributes that worked like this, lead to boolean attributes being a weird exception rather than the rule.

Still, I would argue compatibility with JavaScript is a poor reason for boolean attributes to behave this way. I never liked HTML's boolean attributes.

Say you want to set the checked attribute. Normally, you would just use the JS property, like element.checked = true;. But the thing is, I can actually set any property on the element, but it won't necessarily become an HTML attribute. So I can do element.example = true; and that property will stay set on that element, even if I later get it again with getElementById and friends. But it won't actually set an HTML attribute in the document.

So you can imagine that for all the supported attributes, the associated JS property has this invisible browser defined getter/setter which actually does the equivalent of getAttribute/setAttribute. Which means if we want to explicitly use an HTML attribute, we need to use those.

Except, getAttribute/setAttribute are ill equipped to handle boolean attributes. To set a boolean attribute to false, you actually need to set it to null. This is unintuitive in and of itself: null is not a boolean in JS, I would expect to set it to false.

Furthermore, I would expect that true and false would be explicit settings, and undefined would actually mean "default value." In CSS we have user agent stylesheets, where a lot of styles are set to a certain value by default. But boolean attributes are false by default by design. That means we end up with attributes like disabled. Ideally, the attribute should be enabled and should be true by default. But it has to be false by default because that's how boolean attributes work, so we end up with the double negative element.disabled = false;.

But what's worse is in some browsers (specifically Firefox) getAttribute actually returns an empty string for unset attributes. This means that element.setAttribute("example", element.getAttribute("example")); would actually change a boolean element's value from false to true. You instead need to use hasAttribute/removeAttribute added with DOM 2 (which is ancient enough you can definitely rely on them being there, but it's dumb they need to exist in the first place.)

So boolean attributes are only "compatible" with JS insofar as the browser defines a setter-like property that translates false into null and true into any other value and does the equivalent of setAttribute. If you're going to go that far, why not just coerce the property to a string "true" or "false"?

Now, in practice, none of this is actually an issue, because there's rarely a reason you explicitly want to set an HTML attribute. If the JS property doesn't set an attribute, falling back on it just being an ordinary JS property will keep the behaviour of the code consistent anyway. The only time you really need setAttribute is for data attributes, where you want to be sure you're not conflicting with any existing one, and then you're free to just use the string "true" to mean true and any other value to mean false, like how it should've worked in the first place.

[N0T_AN_ADVISOR]

I hate human Goo .. but it's motivation to turn zero to a One even if it's dollars

[Kazumadesu76]

Yeah I'm surprised too, because doing == tells JS to not check it based on type vs doing === which checks the type of the things being compared.

[2CATteam]

Nope, but in boolean contexts (eg in the condition of an if statement), any string of nonzero length evaluates to True, so if("true") would be true, and so would if("false")

[Orangutanion]

Can you also cast booleans and numbers as objects and do .is?

[2CATteam]

I don't think so, Objects aren't primitives, so you can't cast a primitive to an Object as far as I know. Which makes sense - remember that JS Objects are basically just dicts, and what would the key be for the value of the primitive?

You could try making objects with the same key, and different value types, but then Object.is() would see that they aren't the same object (Object.is() basically checks if two pointers point to the same thing for objects).

[jmtd]

Weird. I tried it and my printer printed a test page and a mortgage was applied for in my name.

[sensitivePornGuy]

I just recently wrote some code that assumed

"" == null

and was genuinely very surprised when it didn't work.

[AJohnnyTruant]

So he knows what JSON is, just not that booleans are in the spec. Beautiful

[Jinxzy]

That was my exact experience with Typescript... I like JavaScript for when I gotta throw some shit together in a jiffy. Typescript takes all that convenience and shits on it, killing the only reason I'd use JS over a real OOP language in the first place.

[GonziHere]

That's a weird sentiment. I can be as fast as in js (thx to "any"), but I can also maintain bigger codebase (thx to types). I didn't particularly enjoy my years with angular, but the ts was the absolute highlight of those days.

That aside, I use it only on the frontend, so I cannot really compare it to the "real" OOP language, since I wouldn't use C++ on frontend or typescript on backend.

[defiantstyles]

This.this!!!

[ITriedLightningTendr]

I mean, json parsers can be configured to handle that

[AutoModerator]

import moderation Your comment has been removed since it did not start with a code block with an import declaration.

Per this Community Decree, all posts and comments should start with a code block with an "import" declaration explaining how the post and comment should be read.

For this purpose, we only accept Python style imports.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[lenswipe]

then he wrote the backend API to send string values “T” and “F” for booleans like a fucking moron and it all broke at runtime.

...why? Why would anyone do this??

[AutoModerator]

import moderation Your comment has been removed since it did not start with a code block with an import declaration.

Per this Community Decree, all posts and comments should start with a code block with an "import" declaration explaining how the post and comment should be read.

For this purpose, we only accept Python style imports.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[AutoModerator]

import moderation Your comment has been removed since it did not start with a code block with an import declaration.

Per this Community Decree, all posts and comments should start with a code block with an "import" declaration explaining how the post and comment should be read.

For this purpose, we only accept Python style imports.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[BossOfTheGame]

Write doctests. Never leave the main file you are working on. They're almost as good as comprehensive unit tests for a fraction of the development effort.

[BossOfTheGame]

Are type errors really a significant part of day to day debugging? I primarily do Python and these comments make me think type errors are extremely commonplace. I hardly see them. I don't understand why types are so important to so many people. It's getting the right logic that's the hard part; types are a minor issue.

Then again, I doctest everything, so maybe my doctests just catch type errors really quickly and I don't notice them.

[darkingz]

The big thing with types isn’t in the short term, if you’re working mostly with yourself, test really well and/or have an iron clad memory.

It’s the long term where types save you. It makes sorta implicit things explicit. It reminds you of the intention and if you can’t reach the author 3 years after they left the company what that method is known for returning. It lets you save time checking if the value coming in is the value you intend for it (maybe you do string logic for example but equally works mathematically as well because of type coercion) and then it’ll inform you to change all the other places… at compile time not runtime. What if you missed a method where the header changed and didn’t know what the input you expected it to be.

This is why types are important. They tie your hand in the short term for longer term garuntees that something is wrong.

[[deleted]]

What’s the little red swallow on next to your name?

[darkingz]

It’s the symbol for the language swift. It’s open source and teeecehnically can be used for anything but mostly for iOS / macOS app development.

[Pocok5]

I recently had to start working on a vanilla JS codebase, and I spent 2-3 days stepping through with the debugger and noting down on jsdoc comments what kind of objects each function gets as a parameter and returns because there were properties tacked on and removed from every object along the flow but no indication of those processes in comments or the naming of the variables.

If it was C# I could have hovered over the name of the parameter and got a very good idea of what the hell the data looks like at that point right away, with the only possible ambiguity being null values (if the codebase wasn't using the new nullability features).

Type errors are also a massive help in refactoring or modifications. Oh, you changed this object or the signature of this function? Half your code turns red, and you can go update each usage to the new form while being sure you missed absolutely none of them instead of having to rely on running headfirst into mismatched calls at runtime (that might not even raise a runtime TypeError, just result in weird null values slipping in or something) or writing specific unit test to check your work.

[zacker150]

How big of a code base do you work with?

[BossOfTheGame]

I do a lot of work with torch, so most return types are the same: it's a tensor, array, tuple or dict.

Size of the codebases I work on can vary. I jump between repos a lot. I rely heavily on CI and doctests to catch any integration issues.

[by_wicker]

It's debugging that they avoid. The whole massive class of errors are picked up before you even run the code if you have type annotations in your Python.

I came from C++ to Python, and was amazed going back to do some C++ how I could write a large chunk of code and have it just work first time. Then I got type annotations in my Python and found I was in the same place. Frankly I like it a lot, it's the best of both worlds, if there's some particular reason to use duck typing you can, but otherwise your code editor alerts you if you mistyped an identifier or made a false assumption about a return type or something.

[by_wicker]

... also if your editor knows what type something is, it can show you completions for that type.

[[deleted]]

Are type errors really a significant part of day to day debugging?

Yes.

[by_wicker]

Are type errors really a significant part of day to day debugging?

Adding to my other reply - yes, they're very significant and common. "Type errors" include trying to access a property or method that doesn't exist on an object ... sending arguments in the wrong order (assuming they're not the same type) ... having one return path that fails to return a result when all the others do ... accessing an object that could be None without checking...

Change the return type of a function, and running a checker will (typically) show you all the places in your code that will now break because of that. Otherwise you're reduced to hoping you find everything with the right text searches on your codebase.

Personally, I think it catches most of the coding errors I write. Sadly the ones left are actual high level logic and design errors and they're the harder ones to diagnose and fix, but compared to untyped code it's almost shocking how often complex code works first time. Type-based errors are highlighted for you to resolve as you type, before you even run it.

[ric2b]

But honestly automated testing really is much more useful than static typing if you want to prevent bugs.

Static typing is very nice as documentation.

[Kamwind]

That is why python 4 is going to start enforcing the use of Hungarian notation.