2,567 karma · joined April 4, 2020
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.
Without launching into a diatribe on all the shortcomings of phonetic alphabets for representing spoken language (for example speakers of the same language can't even agree on the same set of phonemes to use, and they shift over time) there are plenty of examples I can think of, like musical notation, signal flow graphs, type system notation, circuit diagrams, etc, which notate extraordinarily complex and compounded information into terse representations without terrible ambiguity and plenty of flexibility just like alphabets. Without the shortcomings of human language itself. I'd suggest those systems, many of which have been iterated and improved, more "advanced" than the humble alphabets.
In other words, real estate is a great way to preserve wealth.
Because these days every business has to be investing into software products, and the ones that don't recognize that the software is key to all their products are the ones that are dead folks walking. They're also great targets for SaaS consultant vultures.
Trump directed a mob yesterday to storm our Capitol and it sounds like you're being sarcastic about him threatening our democracy. What does he need to do? Burn it down and hang the Vice President for not exceeding his ceremonial powers like his mob chanted?
The claims of the election should be dismissed by rational people, which is exactly what happened in legislatures and courts across the country led by people of every political position except those that want to tear down our democracy for a demagogue and lie to their constituents about reality.
Tangent: I'm very interested in implementations details for ordered key-value stores. B trees and their variants like B+ trees are pretty straightforward conceptually but there seems to be scarce resources on the nitty gritty details past find/insert/delete.
For example I'm interested in redistribution algorithms, duplicate key semantics, and merging. The relative naivety of their implementation can have a large impact on performance/storage depending on how the store is used.