Ke🅱️in @KevinMGranger@cybre.space

@atoponce Howdy!

Just wanted to say thank you for your excellent ZFS blog posts-- learning ZFS from those was what landed me my first internship, which kickstarted the rest of my career.

Who knows where I'd be without them?

even if it's just for tuples, cmon

add pattern matching to Kotlin, cowards

Kotlin needs a standard 3-clause for-loop

I want to be able to do `Date at Time`.

The first part is easy enough: `infix fun Date.at(time: Time): DateTime`.

But how do I do 24-hour time nicely? If it's normally said in English as "1500 (fifteen hundred) hours", then I can't do `val Int.hours: Time get() = Time(this / 100, this % 100)` because that's already defined for making a `Duration` :/

hecc I like kotlin

Who called it VS Code and not Work From Chrome

a follow-up to yew called crankdat

I'm starting to think that improving your tooling and processes results in linear improvements, but technical debt is just that-- debt. It grows exponentially, compounding on itself.

So if you're not starting improving early, actively, and mindfully, then you're in a bad spot.

Get yo self some shipped bagels

https://abc7ny.com/6193521

It's actually fine if your lang can't represent `Maybe (Maybe a)` because there's never a situation where that isn't confusing and should be replaced with a custom sum type

Granted, those that can't represent that don't usually have sum types... :(

brought to you by someone suggesting vim replace hjkl with wasd

When will someone make vim for

I've been thinking about "evidence" that the unix philosophy was either a lie or not fully realized enough to be useful.

I'd need to find more, but there's one that stands out:

What's the standard way to turn a unix timestamp into a readable date/time, in the shell?

(hint: there isn't one)

This is one of the core tenants of the lang I'm sorta designing.

Perl tried to do this, but looked at the strange syntax of these tools and said "let's make it even stranger".

There's some overlap of "make programs that do one thing, work with text streams, and we'll give you a tool to compose them" and functional programming.

One simple syntax, and terseness accomplished only through the power of composition is the solution.

Now, I'm not a unix zealot. Far from it. I've been in it long enough to understand its warts, and how inaccurate the purity of its ideology was.

I think you ought to solve _both_ pain points:
- make integrating with external programs _easier_ than using the shell
- embed text processing capabilities that are _easier_ than using sed/awk/grep, so you won't shell out unless absolutely necessary.

I'm still thinking about "powerful", because... you can recreate those programs in any turing complete langauge, sure. But there's a power to their terseness and composability that's missing from most langs.

If your programming language doesn't make using unixy programs easy, then it needs to at least include tools that are as powerful as them.

What would typeclasses for rust look like?

Not the syntax or semantics, so much as: how would Category Theory concepts be adapted into a world of safe mutability? e.g. fmap definitely returns a "new" object, but an applicative concat might modify the original (list extending, result chaining)