Slack and email are for talking to people who I'm not on the phone/video conference with or are away from their desk when I'm working. That is an orthogonal problem from the "Maker" tools you listed.

Jira is for specifying future tasks and goals, it's also an orthogonal problem to the tools you listed.

I'll bet money that even if the commitment turns into law in 2022, it will still cost north of $1,000,000 to actually construct or convert a multifamily property due to ridiculous permitting costs that you can't see up front.

I'm also not British so I don't know how serious those conversations are. But the assured economic and political disaster of Brexit wasn't enough to stop that ridiculous idea, so who's to say the same won't happen to the marginally less ridiculous proposition to reunify Ireland and establish an independent Scotland for the first time in centuries?

Meetings are for collaboration, not demos...

Obviously there are a lot of negatives to implementing some kind of legal framework around those ideas but something has got to give here, the existence of patent trolls and defensive patent strategies is offensive to the notion that we should encourage innovation.

Some examples: hardware description languages (VHDL, Chisel), human readable graphics languages (shaders, SVG), languages for describing music or instruments (super collider, SOUL, Max/MSP, Pure Data), other creative coding, generative art, etc. Essentially think about all the things that programs arent, and think of how a DSL can represent them - be it abstract information like art, physical things, or other things not readily represent able as digital data.

But to the first part of your question: it's not hard to make a DSL. It's hard to make one that people will use. The hardest problem in developing one is dogfooding it, you need users from Day 1 to give feedback on what works and what doesn't make sense. Another way to think of it is that the technical problems of DSL development are straightforward, the social problem of making one that's useful isn't.

Their shared implementation details mean you can wire a triode as a diode but I don't think it's even a better diode.

That device would have three conductors, which you can see in the photos. Two for the filament, one for the "plate." Later, a fourth conductor called the "cathode" was added to be heated by the filament (rather than pulling charge directly from the filament) to make the first diodes.

There's something funny about how modern active components are designed to reduce how much heat they consume, but the first active devices required an active heating element to function at all.

The closure proposal is much more interesting. I skimmed the discussion and it points out many of the benefits and some syntax proposals, but I'm wondering about memory management.

In C++ a lambda may not be convertible to a function pointer if the captured context is non zero sized, and if the captured context is larger than the size of a pointer it must use some kind of dynamic allocation. C++ has scoped destructors, making implementation of that relatively straightforward (free the context when the lambda goes out of scope), but what would C require? Defer statements? Require a free() without matching call to malloc?

Closures in C are still possible using void* as a user context, which is common both for closure semantics in libraries as well as implementing closures in languages transpired to or interpreted in C. The memory management is explicit, the types remain explicit (except for the closed over context), albeit a bit verbose.

As much as I love functions as types and programming with them I'm confused how this is a positive feature for C, which lacks some of the semantics that other languages have making closures sensible.

But I haven't seen a "well documented" one either. There's a lot of arcane knowledge in targeting MacOS.

The business incentives often outweigh the technical benefits of desktop apps. DRM and payment processing are easy. Discoverability is a shit show but the only competitive advantage to app stores is exclusivity. No need to worry about provisioning user machines, DLL hell, whatever.

And whatever you do you're going to pay a couple of release engineers anyway.