Four bendy buses managed to enter a roundabout at the exact same time from four different directions in Oslo yesterday afternoon and get properly stuck, each bus blocking the exit for the one behind it. #BigBusStuck
@rowan @eclairwolf I’m so glad you liked it so much! 💙 Bambara is amazing and so is this whole album
Talking to a co-worker about the ADHD tendency to keep too many photos on your phone.
Mendie: ... And then, I actually keep this photo in my phone, itself, so I don't know what that says about me.
@liese oohh I haven’t but that sounds great for me! I have been meaning to try F# at some point - I think you might’ve been the one who originally recommended it
although now that I look at it a little more, it looks intimidatingly similar to Haskell on the surface. it looks like it has much better documentation though omg - so that’s a huge plus that I really appreciate
I’ll definitely give this site a look when I get the chance, and thanks for mentioning it
I got nerdsniped by your shitpost into trying to write a Forth interpreter in RNA. It didn’t actually take that long to get it working, at least in a simulator. Then I started looking at how to get my code into a prokaryotic ribosome. Imagine my surprise when I found **very** similar structure already there. #Tootfic #MicroFiction #PowerOnStoryToot #BonusEdition
I’ve been thinking about the concept of pure functions a lot lately. at first I wanted to dismiss them but knew that I didn’t have enough experience with them to really make a judgement, but now I think that I’ve tried them enough to be able to give my thoughts
so first of all, pure functions are useful because they can be easily tested as self-contained code, which makes both debugging and unit-testing easier
but, I would argue that a codebase full of thoroughly unit-tested impure functions is actually much easier to debug than a codebase full of non-unit-tested pure functions. simply because you can immediately rule out all unit-tested functions as the cause of the bug (unless the unit-tests are missing something important, which I’ve never run into personally)
pure functions are very easy to unit-test, but impure functions with simple and well-documented side-effects are roughly as easy, and IMO they tend to be much more ergonomic overall: they’re generally easier to write, read, understand, and use (assuming that this is a function where one would be tempted to have side-effects, of course)
the one exception to this IMO is when you’re mutating shared state that isn’t neatly contained inside of an abstraction like an object. for example if a function takes a data-structure and then mutates that data-structure, you have to trust the caller to know that it’s okay for all references to that data-structure to be mutated. but in that case my solution would just be to make a class for that data-structure instead. because then it’s much easier to conceptualize what that state represents, and when it’s appropriate to make a copy of it instead of changing the original
I feel like there are plenty of potential footgun situations for a caller thinking that they have the only reference to some data-structure, mutating it, and then realizing that some code somewhere else was relying on the same assumption (that they have the only reference to that data). but again I think that the best solution is often just to make a new class to hold the data instead of treating the data itself as immutable
so basically I think that limiting the un-abstracted complexity of a function’s side effects is often a very good idea. but I think there are diminishing returns to limiting side-effects, and trying to maximize the number of pure functions in a codebase is more trouble than it’s worth - both for the caller and for the function-writer
Avoiding public WiFi, QR codes, or public USB chargers doesn’t prevent you from being hacked. Happy to sign onto this open letter alongside 80+ cybersecurity veterans urging a shift from folklore to guidance that actually helps people avoid the most common attacks. https://www.hacklore.org/
@liese this totally makes sense! and it’s actually how I do this in Python too. I’ll start by writing the types and parameter names of the function, then I might write a docstring (which I use almost like pseudocode to tell myself what I want the function to do) and then I write the function itself
although… I’m not exactly an expert at typing yet lol and sometimes I just can’t figure out how to type something so that the typechecker is happy, and I just use Any instead, or some other shortcut hehe. so I feel pretty lost in a language that insists that I figure its type system out
@tropicaltrevor yep that’s exactly how I feel! I love typechecking and type annotations in Python and whenever I’m in a language that doesn’t have that I tend to feel a little lost. but it’s really important for me to be able to opt out of that too
the reason why I made my first post was because I ran into a situation where I had written a Haskell function that I was 100% certain would work, but I just could not explain it to the Haskell type system in a way that it could understand. and it kept giving me really arcane type errors - even if I let it infer the type itself
if I were using Python I could just opt out of having type annotations for that function, but Haskell insisted that I figure out what would please it, and I just couldn’t :/
I might give up on Haskell tbh. everything about the language - from reading it, to writing it, to installing and managing its tooling, to looking up documentation - takes so much effort. it’s exhausting to work with