codesections

> (Beeminder is primarily based on API integrations)

This strikes me as a significant mischaracterization of Beeminder. I've used Beeminder for 5+ years[0] and I've never used an API integration — Beeminder supports manually entering data for any goal. (And basically none of my goals have been digital; I'm not sure where you got the impression that Beeminder exclusively targets digital goals).

[0]: https://www.beeminder.com/codesections/gallery

This story was also entertainingly told on Episode 73 of the wonderful Half Arsed History podcast, https://halfarsedhistory.net/2019/11/17/episode-73-uss-willi...

Thanks for sharing these ideas. Raku is actually in the process of migrating to a new package ecosystem, so this could be an ideal time to get something like this set up. I'm not sure how much work would be involved from a technical standpoint, but I've opened an issue[0] to ask the maintainer of our ecosystem package repository; hopefully we'll be able to implement a system somewhat along these lines.

[0]: https://github.com/tony-o/raku-fez/issues/50

> Trusting any single author is a single point of failure — eventually the author of one of the packages you depend on will get compromised and an attacker will publish a malicious package.

Thanks, this is exactly the sort of thing I had in mind when writing the "Making _ trustworthy"[0] section and exactly the sort of conversation I was hoping my post would prompt. One benefit I'm hoping to get from keeping the `_` sub-packages as simple/self-contained as possible is that that sort of supply-chain attack will be easier to spot (e.g., with a 0-dependency file, you couldn't use an attack like the event-stream incident, where a dependency was swapped out for a malicious copy – the malicious code would have to be in the repo itself).

Of course "easier to spot" ≠ "won't happen", which is where your other point comes in:

> To combat this, you need package validation by multiple independent identities. The classic ways to do this are to have multiple people sign a package using PGP

Someone else made a similar point in an r/programminglanguages comment[1] in response to part 1:

> One thing I'd like to see package managers adapt, though, is quorums for publishing. A simple majority quorum of amongst 3+ people would naturally make hacking much more difficult

Do you happen to know any details about how something like that could be put into practice? I agree that it seems like something that'd be worth investing in, as an ecosystem and would be interested in any info/thoughts other care to share.

[0]: https://raku-advent.blog/2021/12/11/unix_philosophy_without_...

[1]: https://www.reddit.com/r/ProgrammingLanguages/comments/raau0...

> I never seen people locking the dependencies to an exact version

This depends heavily on the language/ecosystem. For example, golang's Minimal Version Selection[0] basically requires libraries to specify an exact version – the only way they'd get a higher one is if another library in the dependency graph had manually upgraded to the higher version.

But yeah, if the source is hosted externally and you don't have a local copy somewhere, then that's going to hurt. Which is (part of) why "should I vendor my dependencies" is such a perennial topic.

[0]: https://research.swtch.com/vgo-mvs

Thanks.

I took a (somewhat quick) look and I'm pretty sure that Raku has equivalents for all of the Enumerable methods except for partition. (We could do basically the same thing with our classify[0] method by converting the Hash to an Array. Or do it manually with a reduce. But there are times when a partition method would be handy.

[0]: https://docs.raku.org/type/List#routine_classify

The String methods might be offer a few more options, but I'll need to think more carefully about that. It's idiomatic (and supported with syntax) to use Regexes for at least some of those tasks in Raku. Plus, Raku's strings aren't directly iterable/indexable (though it's trivial to convert them to a list of characters), and Raku doesn't have a direct equivalent to a symbol (something that I do miss). I suspect that, even with those factors, there might be some ideas worth stealing in there, so thanks for the pointer.

(Oh, and I know that it's "just" syntax, but for some reason I *really* like the idea of having an sprintf operator. I hadn't thought of a language doing that, but I just might borrow that one!)

I just saw the code you added; here's a pretty literal translation into Raku in case you're curious (I'm assuming that `<blog posts objects>` is a stand in for omitted code)

    my @arr = [blog_post_objects];
    
    # Author may be Nil
    my $author-count = +arr.map(*<author>).grep(*.defined).unique;

(Though note that this would only exclude undefined authors. In most situations, I'd probably either know that all defined authors are truthy (e.g., an object) or would want to exclude the falsy ones as well (e.g., empty string). in that case I'd use `.grep(?*)` save a few characters.)

Thanks, those all seem useful.

Assuming I'm following you correctly, Raku already has equivalents to each of those built in: we have code blocks[0], List.map[1] (or `for list -> $el { [codeblock]}`[2] which is a `for` loop, but not a C-style one), and the Iterable/Iterator Roles[3].

So I don't think those features give me any ideas for items to add to the library – but I agree that I'd be sad in a language without them!

[0]: https://docs.raku.org/language/control#index-entry-control_f...

[1]: https://docs.raku.org/routine/map

[2]: https://docs.raku.org/syntax/for

[3]: https://docs.raku.org/language/iterating

> (3) ["write programs to handle text streams"] definitely makes no sense outside of CLI commands

I'm not sure I'd say that. In the web development world, you'll definitely see people arguing to "JSON all the things" (text) but others arguing to "protobuff all the things" (binary). And they raise many of the same simplicity-vs-performance issues that came up for Unix CLI commands.

As for (1) and (2) being too ill-defined/a matter of taste – well, I agree, but I don't think that means they're useless. I think of them as being in the same category as advice for writing prose ("Use short sentences where possible", "Avoid cliches"): helpful goals to keep in mind, even if I can't pin down exactly what they mean.

Separating the question of "functional units" from "packaging units" is a good point – you're right that there's nothing non-Unix-y about packaging coreutils together.

I might add a third category, though, maybe "development units"? Something like Python's batteries-included standard library strikes me as a bit less Unix-y – not because it packages things together but because they (as I understand it) develop things together and do so in a way that creates barriers to outside packages integrating quite as well as standard library packages. (Or at least that's what I've understood from the outside, looking in)

> Maybe published package versions should be immutable.

They are in many languages. Of those I'm familiar with, Raku, Rust, and JavaScript all have immutable package repos. (npm wasn't when left-pad was pulled but has changed since then).

Of course, in each case they're only "immutable" in the sense that some organization (with varying degrees of centralization) has promised to host them forever; people clearly vary in their willingness to believe promises of that nature.

> Ruby has truly ruined me for stuff like this. Most basic functionality and some non-trivial functionality is covered in the standard library.

Ruby is one language I haven't had the chance to explore yet. Are there any Ruby functions you particularly miss in other languages? Any that aren't built in to Raku might be ones I consider for the `_` utility library.

> I'll rather use a really small, static (as in never changing) package [instead of one] that get updates every day and breaking changes from time to time.

That's an entirely fair point and, as I got into a bit in the versioning[0] section, something that I'm giving a good deal of thought too.

I'm currently leaning towards tracking the Rakudo[1] compiler releases (~monthly), so updates wouldn't be anything like daily. As far *breaking* changes go – well, again, I'm still thinking about/discussing what guarantees to make, but I'm hoping to be able to promise to (try to) provide strong backwards compatibility. One thing I mentioned in the post is that Raku's strong support for multiple dispatch[2] makes backwards compatibility a bit easier: `_` can add a new version of a function without impacting the existing one.

That still leaves _accidental_ breakage (i.e., bugs) – which is the area I'm currently most concerned about. If not handled correctly, a utility package risks creating its own sort of internal dependency hell: if there's a bug in one sub-package that you use, it could potentially block you from using that version – even if a different sub-package has a feature you want. I'm not sure of the best solution yet, but I'm exploring a few Raku options that I think may let me provide versions at the sub-package level (or maybe even the function level?). That's very much a WIP for now, but it's something that'll happen before a 1.0.0 release.

[0]: https://raku-advent.blog/2021/12/11/unix_philosophy_without_...

[1]: https://rakudo.org/

This is the followup to Following the Unix philosophy without getting left-pad, https://raku-advent.blog/2021/12/06/unix_philosophy_without_...

> It starts up in seconds so you can begin working immediately

They and I have a very different idea of what the word "immediately" means

> What’s wrong with 3?

You may have missed the "[that] they leave on the bottom" part of 3. It sounds like you don't leave your terminal open/visible unless you press ^v

Though note that Cunningham disavows the law attributed to him:

> Cunningham himself denies ownership of the law, calling it a "misquote that disproves itself by propagating through the internet."

https://en.m.wikipedia.org/wiki/Ward_Cunningham

> Published online 2007 Jan 11.

> This honeycomb is sent to an illegal smelter, where the precious metals are extracted, distilled, and sold to manufacturers.

Does anyone know any details about this part of the operation? The article doesn't provide any, and I'm surprised to learn that "illegal smelters" are a thing — I've never thought of smelting as especially subtle

Discussed at the time: https://news.ycombinator.com/item?id=4365255

I'm a bit confused by the terminology here. I thought "autoloading" referred to deferring the loading of a constant until it is first used (as described in this post[0]). But the author seems to be talking about loading code without an "import/use/require" statement.

Are those two different meanings for "autoloading"? Or do the two go together in Ruby? (As is probably obvious, I'm not a Ruby dev)

[0]: http://www.rubyinside.com/ruby-techniques-revealed-autoload-...

> I had the realization that there are practically two different Americas after I took a road trip through the south after having lived in the Northeast for ~20 years.

I've lived in ~8 states and can tell you that "two" is a significant undercount of the number of Americas. (And I suspect the same is true for most countries — it certainly is for India).

I'd also be careful about drawing that line in too purely a geographic way. Geographic differences exist, but parts of Alabama and parts of upstate New York have more in common than their geographic locations might suggest (to pick two places I've been lucky enough to have lived in)

This varies tremendously by city/county within Europe. For example, there are some German cities where crossing a road anywhere other than at a marked crossing not only risks a fine but also will earn disapproving looks from other pedestrians (something I haven't encountered in the states, though I'm not ruling out the possibility that it could occur somewhere).

> a Belgian friend of mine often crossed the streets of Brussels without stopping to look at the traffic, with blind faith they would just stop -- and they did.

In some cities/countries, there's also the fine art of looking without looking like you're looking — some drivers will yeild to you when you have the right of way and they aren't sure you've seen them, but will cut you off if they can tell that you know that they're there.

> I imagine this couldn't be possible in the states due to the absolute vastness of it all

No, this absolutely happens in the states too — just on a smaller scale. Roads often have the name of the next town they run through. (One mountain town I'm familiar with in North Carolina has only 4 roads leaving town, each named for the town you'll arrive in if you take that road).

The county that applies that to pretty much every road (or at least used to) is Italy. I have vivid memories of trying to navigate the Italian highway system pre-satnav when none of the signs used the highway names on my map; instead, they listed the next city the highway would hit — frequently one that I wasn't familiar with. (And no, apparently all roads do not lead to Rome)

> When I go back home to India, the very first cab from the Mumbai airport to home is like a dangerous roller coaster ride.

Somewhat oddly, I had exactly the opposite experience the one time I visited Mumbai — but I was coming from a few weeks in Ahmedabad, where traffic lights were basically a (typical ignored) suggestion.

> I've yet to see a single thing here that is physically smaller than its version in India.

Statues sure are. https://en.m.wikipedia.org/wiki/List_of_tallest_statues

> you could just replace any of the letters in 'user' with a different, but almost-identical looking unicode symbol and you'd still have an exploit.

The post mentions that exploit (and Rust's already existing defense) in the appendix.

Here are the details, as explained in a previous post:

> The compiler will warn about potentially confusing situations involving different scripts. For example, using identifiers that look very similar will result in a warning.

    warning: identifier pair considered confusable between `ｓ` and `s`

https://blog.rust-lang.org/2021/06/17/Rust-1.53.0.html

The BLS doesn't provide a "software engineer" option, though.

(Well, they provide "17-2061 Computer Hardware Engineers", but I assume that's not what you had in mind)

Source: https://www.bls.gov/soc/2018/major_groups.htm#15-0000

Part of what I find odd is that these definitions seem to envision a separation between designimg software and actually writing the code — but, in my experience, it's much more common for those roles to be combined (and has been for quite a number of years)