It's also worth taking a look at the author's website: https://100r.co/ - ORCA is just one of many projects and explorations that they do while living on a boat.
that talk, where they discuss their experience living on and maintaining a sailboat, resonates with me very well right now. In quarantine, I'm having to learn how to fix things and basically be able to take care of the household. It feels like we are on a space ship, drifting through time, but basking in peace and solitude.
it's worth noting that they had a fantastic session at xoxo 2019, talking about the trials and successes of living on a boat. having lived on top of a mountain with satellite internet (not nearly as bad as their connection), I was able to sympathize with the unhappiness of Xcode updates.
Great to see Orca on here! Really really fun to play with for generative music; I made a song with it last year that I posted: https://www.instagram.com/p/BzVjW7LBv1K/
Orca is fascinating because it is so limited compared to most "programming languages", and trying to figure out how to express ideas 1) compactly, 2) without abstraction or recursion, and 3) flexible enough for real-time editing, is a great, rewarding challenge.
This is a cool project I've been watching for a while.
But off topic from this, what is with all the sourcehut links on HN lately? Where did this suddenly come out of? Looks like a lot of cool projects are starting to host their code here. Wondering how it got the traction.
> 2. The e-mail based workflow is (in my opinion) superior; I don't have to use some clunky web interface.
Yeah but my email client can't show me nice diffs and let me comment on line numbers like GitLab/Hub can... Plus I
I don't really understand SH's decision not to support PRs, which seem fundamental to most workflows.
I think PRs are far superior than spamming up my inbox and using esoteric git email commands
To be fair, I've never actually tried an email-based workflow, but in my mind it involves a lot of emails and reply-alls and just general clutter and an absence of syntax highlighting, pinpoint line commenting, side-by-side diff and all the other nice things the GitLab/Hub provide with PRs.
> But at the end of the day, if this workflow is not for you, there are a half-dozen other platforms you could be using.
I've never actually used an email-based workflow, but I'm trying to understand why people might prefer it over PRs.
SourceHut gets a lot of love on this site and I feel like I am missing out. But every time I look into it, I feel like there is something I'm not quite grasping.
I like email because it's very efficient, both as a contributor and a maintainer. It can fire off a patch with a single command, and reviewing lots of patches is easy, too. It's also distributed and federated by its very nature, which makes it fault tolerant and keeps your data from being locked up in a centralized/proprietary database.
I use Github and Gitlab on a daily basis, and participated (and still follow) in a project with an e-mail based workflows, the notmuch[1] project.
I find that the following are better in an e-mail based workflow:
- Reviewing
Threaded e-mail discussions are the best for following and/or discussing pull requests. Commits or comments no longer relevant can be hidden/collapsed to allow you to focus on what you are interested or is left to review. This is still not possible fully in either Gitlab or Github.
- Multiple versions of a pull request
Only Gitlab has support for multiple versions of a merge request. In Github there is no history of what the previous versions of the code were (or at least you cannot not explicitly compare them as in Gitlab)
- Merging into multiple branches
Though not enabled directly by an e-mail based workflow, with Gitlab/Github there is no way to ask the same set of changes to be merged into different branches in the same MR, you have to open two, and then you might issues with tools that integrate with them as they might have done the assumption that one branch is not used in two different MRs. So, even though daggy fixes[2] are possible, the norm seems to be to cherry pick.
- Custom styling
This varies with the e-mail client, but still is way better than any web interface.
The site recently got discoverability of projects (less than a week ago); it's had a bunch of projects laying about for a few months now, but you'd have to use site:*.sr.ht on a search engine to find anything. It's more navigatable and has far fewer ethical problems than both Gitlab and GitHub, which makes it more enjoyable to search through.
The site itself has actually had many links over the course of the past two years:
It's proprietary software with extra steps to trick people into giving a company the respect that comes with free software. To quote Andrew Miloradovsky:
The reason why many companies insist on using "permissive" licenses is because they're having an "open core" business model, and want to be able to include the work of external contributors into their proprietary versions, without asking the contributors to sign any kind of agreement.
I know multiple people working on multiple projects who would have been entirely willing and able to pay for the enterprise feature-set, were it not proprietary. It's not even a good business model! Solely aimed at large companies, GitLab has no regard for individual users or foundations & groups producing free software. Some people make the argument that because they offer the proprietary patches to free software projects at cost of nothing more than freedom, they do have regard for them, but that's a ridiculous argument: BitBucket was gratis for free software too.
Drew is ethical, unlike the other two, and it seems very, very unlikely that will change. Have you seen his rants? He cares more about software freedom than most GNU contributors. He also has been contributing to free software for years as his main occupation, which is something that can't be said of the founders of the other two.
If Drew somehow has a complete change of personality and ethics, that's when it'll be "It's not GitHub, GitLab, or SourceHut." But as it is, he's basically the only trustworthy business-owner on this site.
He even reps a "competitor" that actually supports software freedom as well: Codeberg.
mmm, the founder of Sourcehut is about as far from typical startup founder as you can get. He’d have to blow up his whole schtick if Sourcehut started down a ethically questionable path.
There is an excellent overview of how to use the interface by a YouTube channel called Allieway Audio[0]. It was the explanation that made this software make sense for me personally.
"Conlang" for a constructed language (Esperanto, Klingon, Dothraki) has been around for about 30 years.
I think the confusing part here isn't the informal abbreviation, it's the general concept that a programming language made to be intentionally inefficient/confusing/hard is "esoteric".
Making up a phrase to give a language a label based a vague notion of popularity is pretty nonsensical. If people start using it, is it no longer an 'esolang'?
Aside from the thought that it's effete, precious, and obnoxious, it makes the headline incomprehensible just to save six letters (or to seem trendy). Ugh.
No, there's no audio at any point within the system, it's less an audio programming language and more of a language whose output primitive is a MIDI note generator.
