Upvote for the discussion. “Company Makes Business Decision” is rarely on-topic for Lobsters and often goes off the Rails; I’ve upvoted because I appreciate that we’re not rehashing well-worn licensing arguments here, though this announcement was poorly written.

This is the second time Lobsters has censored my articles by merging them into tangentally related discussions.

Upvoting doesn’t necessarily have to be approval of the content of the post. (though it usually should be)

We’ve spent about half a century refining the email interface: it’s pretty good.

We’ve spent about half a century refining the email interface. Very good clients exist…. but most people still use GMail regardless.

That’s typically the result of a poor email client. We’ve had threaded discussions since at least the early 90s, and we’ve learned a lot about how to present them well. Tools such as gnus do a very good job with this — the rest of the world shouldn’t be held back because some people use poor tools.

I have never seen an email client that presented threaded discussions well. Even if such a client exists, mailing-list discussions are always a mess of incomplete quoting. And how could they not be, when the whole mailing list model is: denormalise and flatten all your structured data into a stream of 7-bit ASCII text, send a copy to every subscriber, and then hope that they’re able to successfully guess what the original structured data was.

You could maybe make a case for using an NNTP newsgroup for project discussion, but trying to squeeze it through email is inherently always going to be a lossy process. The rest of the world shouldn’t be held back because some people use poor tools indeed - that means not insisting that all code discussion has to happen via flat streams of 7-bit ASCII just because some people’s tools can’t handle anything more structured.

I agree with there being value in multipolar standards and decentralization. Between a structured but centralised API and an unstructured one with a broader ecosystem, well, there are arguments for both sides. But insisting that everything should be done via email is not the way forward; rather, we should argue for an open standard that can accommodate PRs in a structured form that would preserve the very real advantages people get from GitHub. (Perhaps something XMPP-based? Perhaps just a question of asking GitHub to submit their existing API to some kind of standards-track process).

…the new PR will lose the history of the old PR.

Why not just link to it?

This is somewhat disingenuous: while GitHub does indeed have an API, the number & maturity of GitHub API clients is rather less than the number & maturity of SMTP+IMAP clients. We’ve spent about half a century refining the email interface: it’s pretty good.

That strikes me as disingenuous as well. Email is older. Of course it has more clients, with varying degrees of maturity & ease of use. That has no bearing on whether the GitHub API or an email-based workflow is a better solution. Your point is taken; the GitHub API is not yet “Just Add Water!”-tier. But the clients and maturity will come in time, as they do with all well-used interfaces.

Github can legally delete projects or users with or without cause.

Whoever is hosting your mailing list archives, or your mail, can do the same. It’s not unheard of.

But of course my own maildir on my own machine will remain.

Meanwhile, the local copy of my git repo will remain.

I think we’re quite aways from the perfect git UI — but I’m fairly certain that it’s not a centralised website.

I’m fairly certain that it’s a website of some sort—that is, if you intend on using a definition of “perfect” that scales to those with preferences & levels of experience that differ from yours.

(author here)

Whether using the web UI or the API, one is still performing the quoted steps

Indeed, but the difference between using the UI and the API, is that the latter is much easier to build tooling around. For example, to start contributing to a random GitHub repo, I need to do the following steps:

• Tell my Emacs to clone & fork it. This is as simple as invoking a shortcut, and typing or pasting the upstream repo name. The integration in the background will do the necessary forking if needed. Or I can opt not to fork, in which case it will do it automatically later.
• Do the changes I want to do.
• Tell Emacs to open a pull request. It will commit my changes (and prompt for a commit message), create the branch, and open a PR with the same commit message. I can use a different shortcut to have more control over what my IDE does, name the branch, or create multiple commits, etc.

It is a heavily customised workflow, something that suits me. Yet, it still uses GitHub under the hood, and I’m not limited to what the web UI has to offer. The API can be built upon, it can be enriched, or customised to fit one’s desires and habits. The difference in what I need to do to get the same steps done differs drastically. Yes, my tooling does the same stuff under the hood - but that’s the point, it hides those detail from me!

(which notably never mention the browser).

Near the end of the article I replied to:

“Tools can work together, rather than having a GUI locked in the browser.”

From this, I concluded that the article was written with the GitHub web UI in mind. Because the API composes very well with other tools, and you are not locked into a browser.

That’s typically the result of a poor email client.

I used Gnus in the past, it’s a great client. But my issue with long threads and lots of branches is not that displaying them is an issue - it isn’t. Modern clients can do an amazing job making sense of them. My problem is the cognitive load of having to keep at least some of it in mind. Tools can help with that, but I can only scale so far. There are people smarter than I who can deal with these threads, I prefer not to.

What he sees as a benefit I see as a detriment: the new PR will lose the history of the old PR. Again, I think this is a tooling issue: with good tools resurrecting an ancient thread is just no big deal. Why use poor tools?

The new PR can still reference the old PR, which is not unlike having an In-Reply-To header that points to a message not in one’s archive. It’s possible to build tooling on top of this that would go and fetch the original PR for context.

Mind you, I can imagine a few ways the GitHub workflow could be improved, that would make this kind of thing easier, and less likely to loose history. I’d still rather have an API than e-mail, though.

This is somewhat disingenuous: while GitHub does indeed have an API, the number & maturity of GitHub API clients is rather less than the number & maturity of SMTP+IMAP clients. We’ve spent about half a century refining the email interface: it’s pretty good.

Refining? You mean that most MUAs look just like they did thirty years ago? There were many quality of life improvements, sure. Lots of work to make them play better with other tools (this is mostly true for tty clients and Emacs MUAs, as far as I saw). But one of the most wide-spread MUA (gmail) is absolutely terrible when it comes to working with code and mailing lists. Same goes for Outlook. The email interface story is quite sad :/

There’s a huge difference between being able to easily download all of one’s email (e.g. with OfflineIMAP) and only being at the mercy of one’s email provider going down, and being at the mercy of GitHub preserving its API for all time.

Yeah, there are more options to back up your mail. It has been around longer too, so that’s to be expected. Email is also a larger market. But there are a reasonable number of tools to help backing up one’s GitHub too. And one always makes backups anyway, just in case, right?

So yeah, there is a difference. But both are doable right now, with tools that already exist, and as such, I don’t see the need for such a fuss about it.

I use & like GitHub, and I don’t think email is perfect. I think we’re quite aways from the perfect git UI — but I’m fairly certain that it’s not a centralised website.

I don’t think GitHub is anywhere near perfect, especially not when we consider that it is proprietary software. It being centralised does have advantages however (discoverability, not needing to register/subscribe/whatever to N+1 places, and so on).

Previous discussions on reddit (8 years ago) and HN (one year ago).

I don’t buy the slippery slope argument. There are published codes of ethics for professional software people by e.g. the BCS or ACM, that may make good templates of what constitutes ethical activity within which to use software.

But by all means, if you want to give stuff to the drug dealing Yankee cop when someone else refuses to, please do so.

What do you use besides icons in that setup? Menus and search/command line?

I know very little about either of these topics, but I wonder if it would be interesting to combine OpenBSD’s security syscalls like pledge and unveil (is there a generic name for these? Privilege-based security?) with Plan 9’s extreme everything is a filesystem approach.

Thanks for idea about the name.

I don’t see the need to distinguish between paths and strings.

They’re different types: a path is a string which is or could be the pathname of a file or directory on disk. Since they’re different types, treating them differently yields all the standard benefits of strong typing.

The social sciences are not “so soft as to border on pseudoscience”. Yes P-Hacking and over reliance on p-values are an issue, but they’re an issue unilaterally. It matters just as much in physics as it does in social science. The idea that social sciences are somehow less rigorous than say physics is I think fallacious and without merit. Physics is still ultimately rooted in experimental evidence which is statistical in nature. You realize you’re discrediting an entire set scientific fields with literally no evidence and likely with very little knowledge of the subject. It’s not like there’s been literally no replication in the social sciences. What an absolutely absurd claim.

Common Lisp uses #o as a prefix, e.g. #o0, which seems fine too.

Yes, same here.

While I agree with you, on further reflection, this does seem like derailing.

when I read a blog post like this that exclusively uses “he” and “his” for unspecified genders, it feels like the author is making a political point of it

I’m the opposite: when I read a post which uses incorrect English, it feels like the author is making a political point of it. In English, the feminine is only used when referring to a specific female; for all other purposes the masculine (or, if you prefer, the ‘general’) is used.

Yup, rms famously doesn’t like Common Lisp’s complexity, but I think that the histories of both elisp & Scheme are used in practice demonstrate the wisdom of Common Lisp’s approach. As an example, elisp has no namespacing mechanism, so folks commonly prepend the package name to variables & functions, leading to variables named e.g. my-package-variable & internal variables named e.g. my-package--private-variable; one has to type those long names everywhere, even in the package defining them, or a package which heavily uses them; in Common Lisp one would have a package my-package & the variables could be referred to as variable & private-variable within the package, and as my-package:variable & my-package::private-variable externally, or as variable inside a package using my-package. Complex? Certainly: I had to write a lot of words there, and maybe the reader doesn’t quite follow. A good thing? Yes, it’s easily learnt and it pays for itself every single time one writes or uses a package.

I can only imagine how awesome emacs would be today had it switched to Common Lisp back in the early 90s.

AFAIK[1], Emacs doesn’t have a module or packages system which also doesn’t help breaking things down into smaller pieces.

[1] I could look this up but instead I choose to comment.

This. I noticed the mandatory JS for rendering nonsense too. I really want to like GitLab, and have tried multiple times to use them as my main, but to me the UX is just inferior to GitHub. The UI is sluggish and feels very bloated.

It’s been a while since I’ve given up on GitLab for the time being, and have been self-hosting Gitea. Now Gitea uses JS too, but also works quite well without it. And it’s nowhere near as slow as GitLab.

It’d be great if we had a language server protocol extension for code review + a gerrit backend. I started taking a look at this a few months ago (I work mostly in Gerrit now) but didn’t have the bandwidth for actually prototyping it. It seems like an obviously good idea, though having to use git hampers some of the possibilities.

Which is why we shouldn’t build decentralised (or centralised) systems without end-to-end crypto any longer.

There’s no reason why something like Mastodon couldn’t have anonymous (unsigned, unencrypted), public (signed, unencrypted), group (signed, encrypted to a group — ‘friends’ is merely one group), and unlisted (signed, encrypted) posts. Yes, there are some key management challenges (particularly around key management & re-encryption as one adds & deletes friends), but they are no insurmountable.

I strongly believe that writing systems without cryptographically-strong privacy in 2018 is an error.

agreed. It seems mostly useful for like novices.

This is a good point, but it’s also an argument against strongly identifying with your tools. If tomorrow you encounter a new tool that does something better than your current tool, it should be as easy as possible for you to abandon your current tools and take up the new ones, and that’s harder to do if being a user of a particular tool is part of your self-identity.

“Oppression” seems like an overly strong word here, maybe…