jesseduffield

I found this chapter to be a good primer on DOD and how OO runs into trouble whenever changes need to be made

I've thought about this too: different people have different values and I think I've found myself in a situation where Go simply doesn't align with my values. I'm not claiming that Go's values are therefore wrong, just that they're at odds with mine.

Thanks for the feedback: I've found that most of the learning I've done has been thanks to feedback from reddit/hackernews so I'm very much dependent on it to know whether I'm off the mark. In terms of authoritative tone, I agree: some posts are stated in confident terms because I _am_ confident, but of course I'm learning to adjust that confidence level based on feedback.

the article itself compares Go's error handling to Rust's, so mentioning Rust in the comments is quite appropriate. Even if the article did not mention Rust, it makes no sense to evaluate a language's feature in a vacuum: comparisons with other languages ground the analysis in reality

I'm not sure what you mean when you say closed: the proposal is clearly open, and the latest comment asking if anybody has issues with the proposal has no downvotes. That sounds promising to me.

At the very least, it's clear that the language maintainers see an issue with the current error handling, given how much time they've spent working on proposals. The community also clearly cares: see https://twitter.com/_rsc/status/1146129898383302656

Also, I see you amended your original comment with a jab against me for the type keys post. Not sure what to tell you there, I posted something, absorbed the feedback, and incorporated that into the blog. If you have specific issues with the latest post please let me know.

I see value in wrapping the error at the source, but I don't see the value in wrapping it beyond that point, unless there's there's genuinely new context to add at some boundary.

You can still be explicit without being verbose, as we've seen with rust's `?` operator

That definitely sounds like Rob Pike. As for changing how Go does error handling, there is actually a proposal in motion to do exactly this, with support among both devs and the language maintainers: https://github.com/golang/go/issues/21182#issuecomment-54241...

wrapping the error at the source is sensible, but if you need to pass the error five levels up before reaching the function that's actually responsible for handling it (e.g. retrying after a period), I find the wrapping becomes superfluous and further obscures the intention of the function. Rust's `?` operator works well here.

using `var err error` at the top is a sensible solution, I'm surprised this isn't the norm. As for dealing with the errors, there is value in wrapping an error with a message at the source of the error, but much of what follows is just passing the error up to whichever function is responsible for handling it (which may be, as you say, retrying after a period), analogous to rust's `?` operator. There is a proposal for defining a general error handler (see https://go.googlesource.com/proposal/+/master/design/go2draf...) but iirc that's in limbo at the moment

I'm afraid I'm not smart enough to deliberately use sleight of hand in one of my posts, but I take your point. I'll update the post to address your criticisms and others from this thread.

My main motivation for writing the post was seeing type keys used for truly no good reason and leading to code that was impossible to understand, but the post could spend more time considering when type keys are appropriate and the downsides of alternatives.

Looks like a pretty cool product. To play devil's advocate I'd like to poke holes at two things:

Product team caring about quality: Devs need to balance quality with speed, and feel appropriately ashamed when something breaks on prod. To the extent that devs optimise for speed, I don't see why product would be any different. The product team has a large backlog and many important deals blocked by certain features. The incentive to optimise for speed is just as strong. The tension you get between a dedicated QA team and a dev team arises precisely because the QA team cares _only_ about quality. So by moving the responsibility to product you'll either see more corner cutting due to product optimising for speed, or more tension due to product optimising for quality. I don't think you can have your cake and eat it too.

Feasibility of no-code testing: having your browser interact with the page in the way you would like is a good fit for a no-code approach. But most of the effort in writing tests, I've found, is setting up the data (e.g. with factories or fixtures). I'm not so sure that you can no-code that side of QA as easily. If I'm right about that, it means product will end up dependent on devs to write the tests.

After getting sick of using Golang in all my other side projects I decided to learn me some Rust and lazycli is the result!

I've always found it annoying to run something like `docker ps`, copy the container id, then type `docker stop <id>`. This tool lets you interact with `docker ps`, or any other command that spits out a static table or list of contents, as an actual TUI where you can select items and run commands on those items with keybindings.

Interested in people's feedback!

I couple of weeks ago I did a deep-dive into JavaScript scoping and learnt a lot about how closures work under the hood and why we the `this` keyword exists in the first place. I wrote a guide that explained everything to my two-weeks-younger self and made a video covering most of it too!

I try my best to back up everything I claim experimentally via chrome dev tools but there are a couple of things that are specific to ECMAScript. Let me know your thoughts :)

Those brackets get me every time. Fixed :)

If you want to split a file into 5 horcruxes _and_ you require all 5 horcruxes must be present to reconstitute the original file, then each horcrux will be one fifth the size of the original. However if you allow a subset of horcruxes to reconstitute the file then each horcrux will be as big as the file :)

Hi all, I thought I'd share this guide that I wrote after coming across some weird applications of array functions in my workplace. Hopefully you like it, and I'm interested in feedback :)

I just came across the term of https://en.wikipedia.org/wiki/Leaky_abstraction. I think that term captures what we're talking about, do you agree?

I agree with your distinction, however I'd say that it's abstraction all the way down: the code you write is an abstraction of the business requirements, which is itself an abstraction of the business domain, and when you're dealing with legacy code that nobody understands, it ends up being treated as a defacto domain unto itself.

So I don't think the term 'abstraction' should only be reserved for use in reference to the domain because abstraction is already happening at every level anyway.

I disagree about the primacy of naming and metaphor here. From my perspective, the only reason the unix pipe is intuitive to people is that it actually behaves like a pipe. I don't think that the abstraction of 'pipe' started by thinking of the metaphor, but rather it started by thinking about how best to reduce complexity when it comes to IO operations, and it just so happened that the best way to do it was with something resembling an actual pipe.

That is to say, the first step is to find the representation of something which reduces overall complexity, and the next step is to think about naming. In my experience, one of the signs that you've found the right abstraction is that it's easy to find a name for it, because the intrinsic complexity of most things is low (or at least lower than I thought when I started programming), and so it's not hard to find metaphors when your abstraction brings the extrinsic complexity of a system down towards the level of intrinsic complexity of its requirements.

In my mind, abstraction is finding a single representation for various things that share traits. If those things happen to be chunks of code all performing the same task in the same way, then factoring the code into a method would be an example of abstraction. I'm not sure that this definition conflicts with the idea of abstraction being about higher-orderness as another commenter suggests, but I don't think it does.

I disagree with your claim that the 'bad' `average` method is an example of indirection rather than abstraction. Indirection, afaik, is about decoupling two things via an interface so that one isn't directly dependent on the implementation of the other. In this case you are still directly calling the method which will directly execute the code. Maybe the dispute here is around whether we should call these things 'the wrong abstraction' or 'a failed attempt at abstraction' but I think it's a spectrum where you can have a good abstraction but with some parts that don't really belong, and in that case it's still an abstraction.

I consider abstraction to be about giving various concrete things the same representation. In this case I'm saying that we're over-abstracting by pulling too much of the dissimilar code between the examples into the one representation (i.e. the method). I would also say with the `average` methods it's not quite the same operation, despite having the same name. The over-abstracted method had quite a bit more going on internally than the minimal abstraction, and had a different interface.

With your dog walking example, I'd say each of your listed abstractions would be 'the right abstraction' because you're not bundling up dissimilar things into a single representation as if they were similar. Specifically with dogs/humans, my example about circles/squares is the same: both might conform to the same interface, but you wouldn't want to represent them with the same class. I agree that doing so is perhaps a special kind of mistake for which there may be a better term than 'over-abstraction', though it's not obvious to me what that term would be (over-specified doesn't quite sound right to me).

Hello all! Based on the feedback I've received in the last day I've made some improvements:

I'm now making use of Samir's Secret Sharing Scheme meaning you can now specify a threshold of horcruxes required to resurrect the original file (hopefully putting me in better standing among the HP crowd)

If your threshold equals the total number of horcruxes, I'll divide the content evenly between each horcrux to reduce file size. Otherwise each horcrux will contain the same encrypted content

As I've mentioned in another comment I no longer load files into memory so the program runs pretty fast

Thanks for the valuable feedback everyone!

wow that is very similar indeed. I suppose the advantage of mine is having no requirement for GnuPG but that solution is quite impressive

Originally I was using n separate keys, however switched to splitting the key based on advice from a redditor. I'll switch back to n keys and see if it slows things down much.

I'll also have a look into ssss, thanks :)

I've just released a new version which works better with light backgrounds, so feel free to give that a shot and let me know your thoughts :)

Thanks :) As for TUIs vs web UIs, I believe so. The closer the UI is to the command line, the shorter the feedback loop and the more options for customisation. I'm someone who struggles to context switch so if I can do something without having to leave my terminal it helps keep me focused

Hey guys thanks for all the feedback so far! I whipped up a quick tutorial for anybody who wants to know the basics https://www.youtube.com/watch?v=VDXvbHZYeKY