isbjorn16

I think we'll have to agree to disagree on this one.

I hope she has an infinite supply of lipstick because this pig will need it :|

our living room turns into bedlam when we do this. everyone shouting what is about to happen or why it's happening and we're almost always wrong. it's great!

Voila. Channel. You need to know someone in the channel to add you to the channel, but suddenly you can avoid that threaded bullshit.

God I hate using teams

Even if it's tearing it apart and repurposing the guts for a frisbee, I'm looking for ideas.

So, `:wq!`, or as I call it "write the fucking file and quit, _with feeling_"

He's been dead for almost a century, so I don't think he's vetting much of anything at the moment

haste makes waste, but even worse, it can make for blind people with breathing problems

I'm not comfortable not knowing what to do; I've been building on a really stellar foundation for so long that when I need to do something outside of that universe - not situated over that foundation - I tend to flounder, get frustrated, and feel like the dumbest man alive.

Woodworking made me confront the fact that while I may be really good at building scalable systems and high quality code, that doesn't mean I'm the master at everything, and I'm *going* to find things I need to stretch to learn. It's made me get comfortable with making mistakes again (well, as comfortable as I can be, I reckon). It's also made me comfortable with realizing when I'm hitting my patience limit and walking away instead of banging my head against the wall for hours. A bit of distance, let my subconscious chew on it for a while, and revisit it later, rather than just trying to put my head down and shove my way through.

Long story short, you should all pick up woodworking, or metal working, or throw some pottery or paint or something. Get comfortable with being a rank amateur fuckup and revel in the process of learning instead of fabricating without a hitch. I know that I, for one, really needed it.

I know what you're trying to say here, but I just want to note for the record that all presidents communicate primarily with their constituents in a one way fashion.

In other words, that president was unique primarily in platform, not mode.

I'm running pfsense now because I'm nothing if not lazy, but if opnsense makes things nicer in some way, I'd like to hear it!

1. Nanch micro screwdriver / bit kit. I had one previous and I rather liked it but I gifted it to my brother who was just starting out with DIY maker stuff, so I replaced my old magnetic kit with one that has the bits lock into place with a collar. I love the quality on it and I'm glad I'll probably never need to buy another one again.

2. Lutron Caseta switches for my house. I haven't replaced the lot, but I've replaced the most commonly used ones and it's so nice being able to stagger to bed after a movie and just tell siri to turn all the lights off in the house.

3. The last is a two parter; dewalt makes a little cordless screwdriver (not really a drill). That has a ton of utility, but what I like best is that I can combine it with a cordless drill "cleaning attachment" kit that you can get off amazon (or probably other places). Put the two together and you can save so much time and effort scouring things - you still have to manually do some nooks and crannies, but you can get the vast bulk of it out of the way and let technology work for you. A regular drill would work, but it goes too fast and flings shit everywhere, while the screwdriver has a much lower RPM. This combo is just my favorite.

> I commuted by bike for years in hot, humid climate without showering at work. Consider all of the remarkable achievements of humanity. You could figure out something that could work for your situation.

It's called a shower. I weigh 300lbs. Trust me, I am going to be sweating like I was sprayed by the grossest stink hose of all time. Sure, I'd love to believe I'd be closer to 200lbs than 300lbs after a year or two of riding, but that's a year or two smelling like a rank asshole. On behalf of myself and everyone around me, hard pass.

I am not going to make a broad statement saying they don't exist, I'm just saying I haven't found one yet. It's really annoying because I rarely have my phone on me when I'm at home so I have to go track it down. I'd be so happy if they let me use a yubikey :(

The main two things that get me all bent out of shape is having a purposefully disjoint types passed in as the same variable with a bunch of logic around handling either of them, often in very different ways, and never, ever checking types of values or ranges.

If you start throwing in type hinting and make use of mypy, it keeps your own code pretty coherent. If you do need to have disjoint types coming in, spend a lot of time thinking about how you want it to work. It may be reasonably cheap to force everything into a single type from the many possible types coming in, which should simplify things a lot. If that won't work, consider wrapping any of these types in a composite object that unifies the _how_ of accessing the data inside the type into a single low-cost abstraction. Whatever you do, don't let the logic about how to operate over your abstract data input bleed into the logic of how you're building off of it.

This is one of those things that Python makes hard, not because it purposefully stops you, but because it makes it _so very easy_ to spew implementation details through every single function call. It's easy, and programming is hard, and people have deadlines and it's something you can easily convince yourself you don't need to do, and suddenly you're writing bad code and nothing and nobody is there to stop you from it.

I'm a big fan of keeping my type hints in my code and not using typeshed; I WANT people to see what types I'm agreeing to support. You don't have to agonize over documentation or look 14 levels deep in my code to see what I'm handling. The goal here should be for someone to read my function signature and go "oh, okay, I know exactly what I need to provide for use".

Another vexing thing that comes about ALL the time in dsci/ml code is single letter identifiers. A lot of this is because the paper says this variable is `p` or maybe even `epsilon` so... that's what the variables get named. I've even seen `f()`, `g()`, and `h()` in the wild, and of course there wasn't a lick of documentation around it.

Unless your audience is only ever the people who wrote the paper itself, or those who studied it vigorously (more so than just reading it), these are terrible choices.

This advice is not python specific - it's language agnostic, but I notice it most in Python solely because I run into it the most dealing with non-devs taking a stab at writing their first libraries (or, rather, a bit of polish on their initial prototype). But in general, write your code not so that it's easy to write, but so that it's easy to read, easy to reason about, and doesn't require a chain of whitepapers to understand. The goal is so that someone reading this later doesn't have to literally be you, at this exact moment in time, to understand what is going on. You want your code to live long past your current attention on it, so write it in a way that is easy for another maintainer to pick up and run with.

In the end, other languages make some of this table stakes - not the naming, obviously, but the types? Range checking? Handling error conditions explicitly? Python gives you all the rope in the world necessary to bind yourself into a knot with, so it's all up to the developer to do the right thing. When I lament python, it's not because it's inherently bad, but because allowing people to play fast and loose with the rules means you're going to find a lot of people who just don't give a shit.

Good Python looks a lot like what you would get from a compiled language, and every researcher I work with looks at it and goes "holy shit this is so much extra work I don't wanna do it"

And like I said, that's fair. The code is not the point, it's just a tool to get the data - that's the point.

I equate it to the one time use jigs woodworkers use. Some can get pretty fancy and be awesome, but most are just slapped together and will probably get chucked in the bin. I don't mean to shame anyone - there's a reason for it, and it serves it's purpose.

It's when someone hands you that shitty-ass jig, from a language that lets you do some pretty heinous things by design, the frustration builds like crazy! I've seen some pretty gnarly Java and C# in my day too, and all I know is the worst Java still is an order of magnitude easier to handle than the worst Python I see on the regular, it's wild.

All of the reasons we're stuck with it related to datascience and scientific computing are the exact reasons why we hate it. It's exceptionally fast to write code that does a very specific task without sparing a single solitary thought for any sort of software development best practices. It's incredibly approachable, which means it can be used by any keen scientific or mathematical minds who spend more time reading and writing whitepapers than they do writing code. The code, as an entity in and of itself, clearly shows that. But the _output_ of that code also shows that, which is why it isn't going to go away or be swapped out for anything else.

This is like the ideal breeding ground for further scientific or academic pursuits, and since everyone is standing on the shoulders of numpy/scipy/sklearn/pytorch-esquian giants, you're stuck in the scenario of having to replicate all of these libraries in any other language. I can't honestly say it's worth the effort to replace the entire stack, and it's also not going to help when these same researchers continue to use python going forward and start using some other library that you didn't port yet.

And so, they will continue pumping out new papers and prototypes-masquerading-as-quality-libraries, and we'll continue roping them in and duct taping fix after fix after fix on this kaleidoscope of horrors and we'll continue self medicating to dull the daily frustration of python while also accepting that it's the price we're going to need to pay if we want to work with these brilliant minds with all their neat new ideas pushing forth such a breadth of new understanding from the data _we already have_. Or at least that's what we say when we try to ignore the growing bald spot and bursts of incandescent rage every time we get a "quick script that needs a little polish" that clocks in at 2000 loc and literally doesn't have a single function definition in it and variable names that identify up to 14 different types depending on some global state and...

You know, I'm going to stop typing this. It's christmas eve and I wasn't planning on being this angry today

Edit: Some people weren't liking this, it may be because they think I'm being sarcastic when I talk about these brilliant people. I want to just clarify - I am not being sarcastic. They ARE brilliant. They're far more intelligent than I, and they're really pushing the boundaries of human understanding in mathematics and sciences. I acknowledge they're bring a whole hell more good to the table than they are bad, and there's a damn good reason why I am going to be doing this thing I'm doing in perpetuity, or until I can't handle it anymore.

But that doesn't mean their coding practices aren't often _abysmal_, and I won't apologize for my frustrations in this and the language that just _lets_ them do it.

  let x = doRiskyThing();
  match x {
    Ok(x) => x.doThing(),
    Err(e) => ...
  }
  x.get().doThing();

  try {
    MyType x = doRiskyThing();
    x.doThing();
  } catch(CheckedException e) { ... }

In other words, you can be a jackass using either of them, but you can also use them correctly, and when you use them correctly I don't see how they're any different. I also don't feel like the likelihood of using a Result correctly (edit: originally this said _incorrectly_) is substantially higher than a try/catch, but it probably boils down to developer experience and comfort with a particular varietal and not the capabilities inherent in either. Probably. And if not, I'm looking forward to being shown why! :)