avgcorrection (u/avgcorrection)

avgcorrection commented on The Law of Leaky Abstractions (2002) joelonsoftware.com/2002/1... · Posted by u/skm

bxparks · 2 years ago

Your criticism that a broken wire is outside the scope of the TCP protocol was clear and valid.

The subsequent paragraphs about garage collection are tough to follow. You have multiple parenthetical remarks, a quotation which I think is used as emphasis, italics used as emphasis, compound sentence fragments joined by an em-dash and a colon in the same sentence, rhetorical questions which presumably have obvious answers but not obvious to me, terms that aren't clear (e.g. what is an "amortized push"?), and concepts that don't seem to be related to GC (e.g. an "abstract list" can be implemented without GC, so why is that included in that paragraph?).

I've read those paragraphs 4-5 times now, and I don't think I understand what you are trying to say.

avgcorrection · 2 years ago

I’ll try to do better in the next life.

avgcorrection commented on The Law of Leaky Abstractions (2002) joelonsoftware.com/2002/1... · Posted by u/skm

samatman · 2 years ago

> There are leaky abstractions I guess but not all are. A garbage collector that can cause memory errors would be leaky. I don’t know anything about garbage collectors but in my experience they don’t.

Garbage collectors are a rich source of abstraction leaks, depending on what you do with the runtime. If you color within the lines, no surprises, the garbage collector will work. Unless it has a bug, and hundreds of GC bugs, if not thousands, have shipped over the decades; but while a bug is an abstraction leak, it's not a very interesting one.

But go ahead and use the FFI and things aren't so rosy. Usually the GC can cooperate with allocated memory from the other side of the FFI, but this requires care and attention to detail, or you get memory bugs, and just like that, you're manually managing memory in a garbage collected language, and you can segfault on a use-after-free just like a Real Programmer. It's also quite plausible to write a program in a GC language which leaks memory, by accidentally retaining a reference to something which you thought you'd deleted the last reference to. Whether or not you consider this an abstraction leak depends on how you think of the GC abstraction: if you take the high-level approach that "a GC means you don't have to manage memory" (this is frequently touted as the benefit of garbage collection), sooner or later a space leak is going to bite you.

Then there are finalizers. If there's one thing which really punctures a hole in the GC abstraction, it's finalizers.

avgcorrection · 2 years ago

> But go ahead and use the FFI and things aren't so rosy. Usually the GC can cooperate with allocated memory from the other side of the FFI, but this requires care and attention to detail, or you get memory bugs, and just like that, you're manually managing memory in a garbage collected language, and you can segfault on a use-after-free just like a Real Programmer.

Now you’ve stepped beyond the walled gardens of the managed memory. How is that an abstraction leak?

> It's also quite plausible to write a program in a GC language which leaks memory, by accidentally retaining a reference to something which you thought you'd deleted the last reference to.

That the user just thought they had gotten rid of? If the memory is technically reachable then that doesn’t sound like its fault. I’m reminded of the recent Rust Vec thread on how the so-called space leak of reusing allocated memory lead to unreasonable memory consumption. But to my recollection that wasn’t a leak in the sense of unreachable-but-not-freed. I do agree however (with those that made this point) that the Vec behavior was too clever. Which goes to show that Vec should probably just stick to the front-page abstraction advertised: will amortize allocations, can shrink to fit if you tell it to, nothing much more fancy beyond that.

(The memory leak topic seems very fuzzy in general.)

avgcorrection commented on The Law of Leaky Abstractions (2002) joelonsoftware.com/2002/1... · Posted by u/skm

bxparks · 2 years ago

I unflagged you by vouching for you. I found your post difficult to understand and couldn't figure out what you are trying to say, but I agree it was not deserving of a flag.

avgcorrection · 2 years ago

What was difficult about what I wrote?

avgcorrection commented on The Law of Leaky Abstractions (2002) joelonsoftware.com/2002/1... · Posted by u/skm

avgcorrection · 2 years ago

> Back to TCP. Earlier for the sake of simplicity I told a little fib, and some of you have steam coming out of your ears by now because this fib is driving you crazy. I said that TCP guarantees that your message will arrive. It doesn’t, actually. If your pet snake has chewed through the network cable leading to your computer, and no IP packets can get through, then TCP can’t do anything about it and your message doesn’t arrive.

The argument is disqualified at this point. The whole world is a leaky abstraction because <freak meteor hit could happen>. At this point your concept is all-encompassing and in turn useless.

There are assumptions: this computation will finish eventually [assuming that no one unplugs the computer itself]. This does not make things leaky.

There are leaky abstractions I guess but not all are. A garbage collector that can cause memory errors would be leaky. I don’t know anything about garbage colletors but in my experience they don’t.

Then someone says that a garbage collector is leaky because of performance concerns (throughput or latency). That’s not a leak: that’s part of the abstracting away part—some concerns are abstracted away. To abstract away means to make it something that you can’t fudge or change. To say that “this is implementation-defined”. An abstract list is an abstraction in the sense that it has some behavior. And also in the sense that it doesn’t say how those behaviors are implemented. That’s both a freedom and a lurking problem (sometimes). Big reallocation because of amortized push? Well you abstracted that away so can you complain about it? Maybe your next step is to move beyond the abstraction and into the more concrete.

What are abstractions without something to abstract away? They are impossible. You have to have the freedom to leave some things blank.

So what Spolsky is effectively saying is that abstractions are abstractions. That looks more like a rhetorical device than a new argument. (Taxes are theft?)

EDIT: Flagged for an opinion? Very well.

avgcorrection commented on Radicle: Open-Source, Peer-to-Peer, GitHub Alternative app.radicle.xyz/nodes/see... · Posted by u/aiw1nt3rs

9dev · 2 years ago

Yes! That's exactly what I would like to see - come together as a working group, create a PR on git itself, and implement standard support for issues, PRs, discussions, projects, votings, project websites, what-have-you. The community will take it from there.

The alternative to that would be the git project itself coming up with an implementation. They have reasonable experience working with the Kernel, and the creation of git itself seems to have worked reasonably well -- although I'm not sure I would want to use something Linus considers ergonomic :)

avgcorrection · 2 years ago

Ok. That could work if you found a group of people who are interested in such an all-in-one package. Gitlab is apparently working on a sort of cross-forge protocol (probably motivated by connecting Gitlab instances) and it seems that some Gitlab employees are working full time on the Git project. So those are candidates. You probably need a group which both have recognition within the project and are active enough to drive such a project forward without it fizzling out.

Without such a group you might just send a few emails to mailing list, get shrugs about how that plan “looks good” with little real interest, and then have to discuss this big plan in every future patch series that incrementally builds such a thing into Git itself. Mostly why such code should be incorporated and how it will pay off when it’s all ready.

The Git tool itself—and the project by extension—is per now very unopinioated about whole-project solutions like this. The workflow that they themselves use is very loosely coupled and pretty much needs bespoke scripting by individual contributors, which I guess is telling in itself.

avgcorrection commented on Git Worktrees and GitButler blog.gitbutler.com/git-wo... · Posted by u/chmaynard

avgcorrection · 2 years ago

I think that you (like me) prefer to use commits in places where many others prefer to stash. Personally I think the stash command is too primitive to bother with for all things except maybe an push+pop that happens within half a minute. Anything more and I risk forgetting about it. A WIP commit however is just there, on the branch, for me to deal with however I want later.

I don’t want to fiddle with dropping the stash one too many times, forgetting what they were about and so on. Merge conflicts because I didn’t pop before resuming..

It’s just a mostly useless additional “thing”.

avgcorrection · 2 years ago

Amendment: I just found out that I do have at least one use for git-stash, which is when I am stuck in the middle of a rebase somewhere and made an edit intended for another point (commit).

avgcorrection commented on Radicle: Open-Source, Peer-to-Peer, GitHub Alternative app.radicle.xyz/nodes/see... · Posted by u/aiw1nt3rs

9dev · 2 years ago

Yeah, exactly. Radicle doing it this way, Fossil another - see here why that is a problem: https://xkcd.com/927/

avgcorrection · 2 years ago

And Fossil is an entirely different VCS.

What’s the alternative? That at least N projects cooperate and agree on a common design before they do the implementation? (Then maybe someone can complain about design-by-committee.)

avgcorrection commented on Git Worktrees and GitButler blog.gitbutler.com/git-wo... · Posted by u/chmaynard

robertlagrant · 2 years ago

> Git is in a sense a primitive tool: only about snapshotting, not about high-falutin things like “passes the tests”, “is okay with Bob”, and so on. It’s just about tracking state.

Git might be, but how many people want to use git is to provide useful commit histories, both for any reviewers at the time and any code spelunkers 10 years into the future. Having a tool that tries to make that easier isn't a bad idea.

avgcorrection · 2 years ago

My comment was totally unclear. By primitive I mean that it scales from very primitive operations (just snapshot) to supporting high-level workflows (refactoring, testing, verifying).

And by primitive I mean that I want to be able to commit whenever I feel like I want a snapshot. For any reason. Not hindered by concepts like does-it-build. That’s the low level. Then at the higher level are things like “public history” and “tested history”. That’s facilitated by the low/mid-level history rewriting tools.

Some people I know use Intellij’s “shelve” feature or whatever it is called. Interestingly it does provide some features that Git does not seem to have—and overlaps with GitButler—but it’s own bespoke thing, not integrated with Git.

And using these extra concepts on top of (or under?) Git doesn’t make sense for my workflow. Because the VCS is already there. So I don’t need to think about if I’m ready-to-commit—just make a WIP or a TEST commit, maybe discard later or maybe rewrite them.

For me, Git covers everything from snapshotting some private notes I have on the work that I’m currently doing to making a nice:

> useful commit [history], both for any reviewers at the time and any code spelunkers 10 years into the future.

It provides that whole range.

avgcorrection commented on Git Worktrees and GitButler blog.gitbutler.com/git-wo... · Posted by u/chmaynard

MaulingMonkey · 2 years ago

> "commit your halfway feature work/.../come back to the feature and amend/squash/soft reset"

...this is just by-hand stashing with alternative commands and extra "WIP" commit messages.

Which, uh, is admittedly an option. One that won't easily preserve your index independently from your working tree - awkward if you're in the middle of painstakingly separating out changes to add to the next commit with `git add -p` - and one that risks "WIP" commits ending up in your tree... but it is an option.

avgcorrection · 2 years ago

IMO you don’t need anything more than commits. The by-hand is writing WIP in the commit message. If that is an inconvenience then I’ll make a commit alias.

The index + commits is flexible enough. The stash concept is not needed for me.

See: https://news.ycombinator.com/item?id=39606525

avgcorrection commented on Git Worktrees and GitButler blog.gitbutler.com/git-wo... · Posted by u/chmaynard

coldtea · 2 years ago

>I mean, that's option 2 of what you're quoting,

No, option 2 is to stash.

Their three weird options are:

(a) fix the bug on the feature branch and "try to get them both deployed together"

(b) git stash, fix the bug in a new branch, come back

(c) locally clone the repository

At least (b) is somewhat sane, but it's still weird that the even more code-managementy option of "commit your halfway feature work/create new branch for the bugfix/come back to the feature and amend/squash/soft reset" isn't even mentioned.

Your cases are more involved than the contrived scenario you give, where their weird options don't make sense.

avgcorrection · 2 years ago

I think that you (like me) prefer to use commits in places where many others prefer to stash. Personally I think the stash command is too primitive to bother with for all things except maybe an push+pop that happens within half a minute. Anything more and I risk forgetting about it. A WIP commit however is just there, on the branch, for me to deal with however I want later.

I don’t want to fiddle with dropping the stash one too many times, forgetting what they were about and so on. Merge conflicts because I didn’t pop before resuming..

It’s just a mostly useless additional “thing”.