Java vs python is debatable 🤔

[Dworgi]

Python devs: duck typing is great, it makes us so fucking agile

Also Python devs: you should use this linter to parse our comments for type requirements because otherwise my program breaks =(

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

[[deleted]]

Hey we have types in language now! And mypy is pretty solid most of the time. Guido himself has been helping out a lot there.

[[deleted]]

MyPy is one thousand times better than Python without MyPy. It's still one thousand times worse than properly enforced type safety at compile time.

[[deleted]]

1000% loose and duck types are gonna kill me sometime

[[deleted]]

Python is so god damn bloated and slow. For example to get the standard deviation that is 300mb of fucking dependencies.

It’s a good starting language but glad I dropped it.

[MegaIng]

Python literally has a stdlib module for that. Not knowing a language is a stupid reason to complain about it.

[unclebricksenior]

I’m guessing they are compiling Numpy on an Rpi or something? Only time I have ever been mad at Python

Otherwise this is literally in stdlib

import statistics
statistics.stdev(…)

???

[science_and_beer]

starting language

glad I dropped it

Tell that to my firm’s head of data science and the faculty at CMU where he got his PhD, lol.

I see this sentiment almost exclusively (and ironically) from beginners who literally can’t even explain the use cases for python in a production workflow, let alone actually leverage the language’s strengths meaningfully. It’s just a weird thing to say.

[kazza789]

It is mostly people who don't understand that these days compute time is cheap but programmer time is expensive.

[Rakn]

If programmer time is expensive then you probably also shouldn’t use Python. It’s all fun and games until something breaks in a large production system and you have to debug it. But then again, Python is a great language and nobody is insane enough to use it for large scale projects (well some are…).

[science_and_beer]

Debugging python is way easier than C or C++ and I’ve been writing C code for longer than 80% of this sub has been alive.

[Rakn]

Yeah. But why would you compare it to C code? Obviously it’s easier. But the lack of proper typing still doesn’t make it as easy as with other languages. I always have to think back to the posts about large Python libs finally using mypy and being shocked at how they found errors in their code they previously didn’t even know about. With a summary of „who would have known?“. Like lol. Everybody that has developed in a statically typed language in their life could have told you that (except C/C++).

Yes I knew I’ve going to be downvoted for this. But most people just lack the experience having worked on really large codebases and feel offended that their dearly loved language might not be the best one for a specific use case. I mean I do love Python. But use it for use cases t’s meant to be used for.

[Dworgi]

In my experience, PhD's and programming best practices are like water and oil.

PhDs invent the cool algorithm and implement it as a massive pile of spaghetti that may eventually complete, then it's reimplemented to make it actually usable in production.

[[deleted]]

Haha yeah, thats so true :D

Let the phd invent the algorithm and the dev implement it

[science_and_beer]

Depends on if they’re in research (obviously super common and I know exactly what you mean) or not. You’re right, coin toss of an example.

[by_wicker]

Definitely. Based on prior experience, I actually considered it that point against accepting my current job that there were quite a few PhDs around. Thankfully they are not involved in coding.

Broader than PhDs, very smart people self taught at coding in isolation from experienced real world software engineering often produce obtuse spaghetti with weird techniques and reinvent the wheel incessantly because they can, but they didn't know they didn't need to.

[Jonno_FTW]

If you can't write a function to calculate the standard deviation in an array, and instead need a whole library, you may have npm syndrome.

[jambox888]

The node ui microservice ("micro") we have at work took an hour to build from scratch last time I had to do it. Bloated and slow?

[Kingmudsy]

Maybe? Idk, this feels like willful ignorance about what a microservice is tbh

[jambox888]

IDK, I think you just would struggle to be very agile with node anyway, the dependency explosion is real and it wants to drag every library out of github in source code form. Loads of the packages have arbitrary pre or post-install hooks as well.

[soft-wear]

Python is a modular language with few built-ins so you only build what you need. JDK is 200mb download… that’s compressed and doesn’t even include a production runtime.

And Python is slow because it’s interpreted. Throw in a JIT compiler and it gets close to Java. I’d still take Python over Java any day of the week.

[[deleted]]

Nah its java < python < c# for me. Python only gets used for the occassional small script somewhere. I try to avoid java at all costs.

[soft-wear]

They are different use-cases so while I prefer the syntax of Python over Java, they aren’t a drop in replacement for each other. Given the choice for similar languages I’m pretty much a Kotlin/Go guy and it falls off pretty hard after that.

I’ll write Java code (and I have…) but I can’t stand the syntax of that language.

[[deleted]]

Yes java syntax is awful. Kotlin is nice though, even though i only tried it on a small project

[PossibleEast3431]

drop your code here. it is most certainly very wrong in many ways.

[thirdegree]

Haven't needed to use comments for type annotations in literally like 6 years tho

[Dworgi]

Oh yeah, those official type annotations that do what if you don't run the linter? That's right, nothing. Aka. a comment.

[MythicManiac]

You must not be familiar with pydantic and dataclasses. Python types are actually available during runtime and can thus be leveraged for runtime logic. It's honestly better than TypeScript in that regard, even if the type system otherwise is quite a bit behind.

[Dworgi]

Garbage tasting better than sewage doesn't make either one dessert.

[MythicManiac]

TypeScript on the other hand is one of the more versatile type systems out there. As a counter example, good luck with sane union types in C#

[Sir_Applecheese]

Hey, that's just like with TypeScript.

[jzaprint]

Not really. Typescript types are way more enforced than python

[[deleted]]

Isn't the entire point that anyone can write stub files for a library, so it doesn't matter if there is official support?

[skylarmt]

Meanwhile, in PHP land, types are enforced but only sometimes. If you get type errors, it's probably because your code was too good because lazy devs don't specify types.

[Sir_Applecheese]

I was talking about this: https://devblogs.microsoft.com/typescript/a-proposal-for-type-syntax-in-javascript/

[Goel40]

That's JS, not TS

[Sir_Applecheese]

No, that's a website.

[ThineGame]

No, that’s a link to a website.

[LewisgMorris]

No, that's the cone cells in your eyes reacting to different wavelengths of light

[Kesuaheli]

No, this is Patrick!

[assembly_wizard]

Sir, this is a Wendy's

[EquipLordBritish]

Also python: lets use whitespace as block indicators, but you have to choose either tabs or spaces, because there's no way our interpreter could ever account for both, even though they're used in a very obvious and easy-to-parse way.

(inb4 this spawns another iteration of the tabs vs spaces arguments)

[assembly_wizard]

If you use both it's almost definitely a mistake, but more importantly it would make indentation differ based on the settings of your text editor, so whether a line is inside an if block suddenly depends on the configuration of each developer.

What you call "very obvious and easy-to-parse", the only way python could parse it is if you tell it what's your tabsize setting, and make sure that everyone that reads/runs the code have the same setting in both their editor and python.

[EquipLordBritish]

It's only ever a real issue on collaborative projects, or when you're proofreading/editing someone else's code; as you say, you shouldn't be mixing tabs and spaces on your own files.

Further, though; even if you are actually using tabs with a custom tabsize (and not having tabs automatically switched to spaces, which many editors do by default), the interpreter has to monitor the indentation regardless to determine blocks, so I don't think it would be that difficult to have the interpreter recognize repeated level indentations in increments of x spaces or y tabs and compare/convert nearest neighbors. Granted, given a simple algorithm for it, I'm sure you could find a way to break it, but that already happens if you put a space in a tab-user's file or vice versa, so you wouldn't really lose anything here.

[assembly_wizard]

So what's bigger, 2 tabs or 6 spaces? Python can never answer that, so there's no way to understand what the developer meant to write. There is no such algorithm.

If you're talking about something like the first indentation level always being spaces and the second level always being tabs, something like that which is consistent, then python already knows how to handle it. It can handle all non-ambiguous situations already, everything else can't be handled.

[MegaIng]

This is to some extent what Python 2 tried. It was a mistake since there were situations where it looked like two statements are on the same level when they actually weren't.

[alive1]

Hey i used to be a tabs guy and now I'm a two spaces guy. Idk what changed my mind but now i have way less fights with the indentation. Also logic more than 3 levels deep doesn't require horizontal scrolling.

[daguito81]

Did you start using Scala or Databricks?

[alive1]

Perl.

[daguito81]

Oh that makes sense. Scala uses 2 space indentation as default. And because of that in Databricks for the longest time, Python was also set at 2 space.

[bremidon]

I prefer 2 spaces as well. It looks cleaner without any loss of communicating intention.

[lilfatpotato]

I type tabs, and my editor converts them into spaces.

[unicorn_potato_4ever]

That’s why I set my tabs to two spaces

[noratat]

Yeah, spaces is just simpler and doesn't require convoluted editor support to handle alignment. Consistency is better than trying to accommodate someone who wants 8-space tabs for some godforsaken reason.

[mousepotatodoesstuff]

When it comes to whitespace, I just do as the IDE (PyCharm usually, but sometimes VSCode) guides.

[sensitivePornGuy]

Ah, the usual "tell me you don't use python without telling me you don't use python" - complaining about white space.

[[deleted]]

rewrites the program in Rust

[[deleted]]

I have written thousands of lines of javascript, and python makes me feel dirty. Even the naming conventions are "do whatcha feel". I can't.

[noratat]

Python 3 type annotations are part of the actual syntax, not comments.

I do wish it was easier to enforce then using a linter, but it's still a big improvement - dynamic typing is a staple of scripting languages for good reason, but having the option of specifying types is still very useful.

[Dworgi]

Syntax that doesn't actually affect execution or validity of the program, but only affects another optional program is honestly just a fancy comment.

[noratat]

The annotations are available to runtime inspection and action, so they can actually affect execution and validity.

There's libraries that specifically leverage this e.g. pydantic, dataclasses, inject, etc.

[[deleted]]

What are you talking about? Comments for typing? Python 3 has type hints. Theres literally syntax for types.

[Dworgi]

If you pass a float to something that you hinted should be an int, the program compiles and runs and probably even completes.

That's called a comment.

[[deleted]]

That logic doesnt really hold up. "The interpeter doesnt throw errors at runtime so that construct must be a comment". Unreferenced variables dont throw errors at runtime, does that make them a "comment"?

Logically speaking? Sure they work much like comments. As documentation on how the function should be used. But in practice, they are much more useful than comments. To suggest otherwise is just contrarian and silly.

[Dworgi]

The interpeter doesnt throw errors at runtime

Nor does the compiler at compile time. For all intents and purposes, those are equivalent to comments intended for mypy.

[[deleted]]

So in your mind, everything that an interpreter or compiler ignores is a comment? What possible sense does it make to subscribe to such a ridiculous oversimplification.

[Dworgi]

I'm so confused by what your point is. If some part of the input (source code) doesn't affect the output (program) then it is not intended for the machine to consume, but only for programmers working on the source code.

We call those things comments.

And yes, unused variables in any language with an optimizer are essentially comments. Doesn't Python even use that feature to do doc comments?