has reached the end-of-life and is now read-only. Please see the EOL announcement for details

@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?

techy, I can't believe I'm saying this 

Kotlin needs a standard 3-clause for-loop

painting myself into a corner in kotlin 

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

The first part is easy enough: `infix fun 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` :/

Who called it VS Code and not Work From Chrome

really bad rust joke 

a follow-up to yew called crankdat

techy, practices 

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.

food, for all originally from the NY tristate area 

Get yo self some shipped bagels

SCATHING fp take 

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

Show thread

the shortcomings of the unix philosophy 

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)

programming thoughts 

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.

Show thread

programming thoughts 

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.

Show thread

programming thoughts I'll elaborate on someday 

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.

Show thread

programming thoughts I'll elaborate on someday 

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)

Show older

the mastodon instance at is retired

see the end-of-life plan for details: