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.
Fat chance of this changing anything. Berkeley is liberalism run amok. Unless you already own property in one of the shrinking "nice" parts it's not that nice of a place to live, and loosely committing to allowing multifamily zoning is not going to change that.
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.
To me, there's an irony that the nationalist desire to sever Britain from the EU is the best way to hasten the dissolution of Great Britain. Now that Brexit is done with, reunification of Ireland and Scottish Independence are in the conversation.
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?
I haven't seen these calls for surveillance. I have seen calls for sedition charges against the politicians that encouraged it and law enforcement that ignored the evidence of coming insurrection.
Interesting how the decline of child labor in Korea is followed by a booming high tech economy while regions that remain affixed to the practice havent
VSCode extensions are driven through "commands" that are exposed through the package.json of the plugin (which can be parsed by other plugins if you wanted) and issuable through another plugin, or using a task (this is kind of annoying though and not a first class use of tasks).
I'd question why you're running code in a meeting. That's some morning standup stuff for your team which can be done at your desk or placed in a gif in an email, not hauled off to a separate room.
I don't know how this should be structured but there has to be some principle of "use it or lose it" for IP protections, and some limitations on transference of IP.
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.
I think the answer is to look at things that can't be done by executing code from a library. In other words, think about something you can compile that isn't executable code.
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.
I don't think it's even technically true, they're fundamentally different circuit elements that just share a principle of operation. Diodes allow current to flow in one direction (rectification), triodes provide a proportional increase in the energy of a signal (amplification).
Their shared implementation details mean you can wire a triode as a diode but I don't think it's even a better diode.
The story I've heard is that the original lightbulbs filled with soot and darkened well before they burnt out. Edison guessed the soot was coming from the filament and was charged, so he placed a charged plate across from the filament to attract the soot before it could stick to the glass. It worked, but the bulb was much darker than before as the charged plate siphoned a lot of current off the filament.
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.
Type inference is great and undeserving of the "bah humbug" type comments. Not a fan of it in function return types but that's easy to avoid in code review or linting (both of which you need plenty in C).
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.
Why ship a desktop app when you can ship a browser product?
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.