> I like their TLI ideas, but I am honestly a bit alergic against designers who lack the phantasy of realizing that sometimes a UIs complexity is a reflection of the complexity of the problem it helps to solve in conjunction with the level of control you want to give to the user.
I think what's key here, and why I like the direction of the work in the linked post, is that none of the affordances of the UI they're augmenting -- the command line -- are being taken away,* merely made more visible based on context. I think that gets at a hole in the notion that UI complexity mirrors domain complexity -- in the case of Premiere, surely the entirety of what's on the screen doesn't mirror the complexity of the workflow you're executing right now, it's much closer to the sum total of everything you might ever do. Not that a UI based on progressive disclosure would be trivial or maybe even possible to implement effectively for something like a professional video-editing application, but it's worth considering whether something like that is merely a local maximum in the space of all possible UIs.
* I guess in the case where you know exactly what you want to do and the added context might distract or slow you down, that's an affordance being removed, but I think it's outside the scope of what we're talking about here -- especially because, given the scope of the command line, you will inevitably have to do something with it that involves an invocation that isn't right at the tip of your fingers.
Hey, thanks for asking! My interests in it are primarily for quota management -- in my experience, this is inevitably a hierarchical concern, in that you frequently run into the case of wanting to allot a certain cluster-wide quota to a large organizational unit, and similarly subdivide that quota between smaller organizational subunits. Being able to model that hierarchy with namespaces localizes changes more effectively: if you want to increase the larger unit's quota in a flat namespace world, for example, there's no way to talk about that unit's quota except as the sum of all of its constituent namespace quotas.
I suspect I'm in the minority on this, but I would love for k8s to have hierarchical namespaces. As much as they add complexity, there are a lot of cases where they're just reifying complexity that's already there, like when deployments are namespaced by environment (e.g. "dev-{service}", "prod-{service}", etc.) and so the hierarchy is already present but flattened into an inaccessible string representation. There are other solutions to this, but they all seem to extract their cost in terms of more manual fleet management.
In my experience, almost anyone who insists on synchronous, in-person standups is doing so because they want them to function this way, whether consciously or unconsciously.
I also suspect that standups with no active brevity constraint frequently come about not because of a lack of leadership but because they're actually a means for disordered thinkers to feel productive, which I think goes part of the way towards explaining why you see such irrational attachment to standups even among ICs.
> Errors are on your face, instead of having exceptions performing invisible gotos to somewhere far up in call tree. Implicit error handling is more code, but your error handling is going to be much more robust.
Errors as values is a great idea. Errors as values without sum types or pattern matching, though, gives you twice the tedium and a tenth of the benefit, so once again Golang's slavish adherence to "worse is better" really just makes things...worse. The real problem here, though, is that those invisible gotos still exist: because of how limited Go's type system is, it's very easy to cause a panic with e.g. a nil pointer. Of course, the answer is to rigorously check the cases where a pointer could be nillable, but that trivially contradicts the idea that, when reading Go code, you can feel confident reasoning locally about its resilience if it handles all potential error values appropriately. IMO, this false sense of safety is even worse than just making exceptions first class citizens of the language, and it belies the notion that Go is especially maintainable.
I have a music degree but have also engaged in a lot of self-study, so hopefully I can still make good recommendations for someone interested in learning on their own. The general approach I'd recommend is trampolining between on-paper theory and ear training, with the specific goal at each stage being the ability to identify by listening the structures that you're learning about on paper. The text I'd recommend is Aldwell's Harmony and Voice Leading, which is very focussed on the techniques of classical Western concert music but is still, along with its exercises, the best bet I can think of for building a solid foundation of knowledge that you can bring to other musical styles.
The most important thing I can recommend while starting out is to focus your ear training on hearing scale degrees (e.g., if I play a C major chord and then play a random note from the C major scale, you should be able to identify which note that is out of C, D, E, F, G, A or B). A lot of naive ear training resources recommend learning to hear intervals (e.g. a perfect 5th, which is the interval between C and G or E and B), but intervals only really have meaning in the context of a key, and so understanding them in that context is much more important. A good app for training with this on iOS is Politonus: it'll play a few chords to establish a key, and then it'll play a random note from the key and prompt you to guess which one it was. As you improve with this, you can have it play multiple notes at a time, or even notes outside of the key.
The Midwest is far ahead of at least the West Coast on this. I saw much more variety of brewing methods, beer styles, and flavor profiles when I lived in St. Louis than I do here in the Bay Area. A lot of the great breweries from the other side of the Rockies (Left Hand, Odell, Bell's, etc.) are either difficult or impossible to find products from here, too.
One of the biggest conceptual moments in my life was taking an intro class to complex analysis in high school (not through my school itself, this was at a nearby university that runs a weekend program for interested applicants). It's probably not a novel intellectual framework for anyone who's spent time learning math from a theoretical point of view, but the guy who taught it opened with an (admittedly ahistorical, but that wasn't the point) tour of the development of numbers, starting with the intuitive case of counting, moving on to algebra and the question of what type of number could satisfy an equation like x + 5 = 2, and so on. He wasn't taking any philosophical position re the question of discovery vs. invention, but merely inviting us to consider the particular case of operations over a set not being algebraically closed and what it looks like to extend that set to support algebraic closure in a rigorously defensible way. Reading Spivak's Calculus, with the way that it starts off its path of inquiry by showing that, beginning with the basis of a totally-ordered field, the axioms at hand don't suffice to demonstrate the existence of e.g. a number that satisfies x^2 = 2, made me feel right at home again. It's like a detective story.
To stick to the more theoretical interpretation of "computer science," and with a focus on theory of computation/programming languages:
- Discrete Mathematics And Its Applications, Kenneth H. Rosen (this is more foundational, but it's definitely targeted at a CS audience and touches on things like automata theory)
- Types and Programming Languages, Benjamin C. Pierce
If you're able to, would you mind linking to some resources about the case you describe in point three where the kernel need deal with an invalid stack pointer? I'm very curious about the underlying causes.
Also, regarding point two, is the cumulative result of those factors you describe (other NMIs being blocked, lack of kernel control, the unreliable heuristic) that a diagnostic NMI may end up never being run?
Oh, certainly. My assumption was that the GP meant that functors aren't useful on their own _in general_, rather than in the particular context of someone just getting into the typed functional paradigm. And, of course, recursion does work just fine in other languages, but (and I'm saying this more for posterity than as a retort since I assume you're well aware of this point) recursion schemes offer a layer of abstraction over direct recursion that eliminates the need to manually implement various recursive operations for each of the data structures you have at hand. As with a lot of the higher-level constructs in languages like Haskell, that level of abstraction may not have any practical benefits in most domains, but it's nice to have when it does offer a benefit in a particular domain.
Functors enable the Fix functor and, from there, the whole universe of recursion schemes, so I'm not sure that I agree that they're not useful on their own.
There are substantial differences between Clojure's constellation of protocols/records/multimethods and CLOS, but at least the feature of CLOS that you cite is exactly what multimethods in Clojure do, see: https://clojure.org/reference/multimethods
After having gotten a Switch and noticing that I basically never play games on my phone anymore since having done so, I idly wondered if the Switch's release has had any observable effects on the growth of this market. Of course I realized pretty quickly that my experience isn't very generalizable, since I'm in a self-selected group from the outset (i.e. those willing to spend money on a dedicated gaming device) and since I only really ever played non-FTP games in the first place (and refused to ever make IAPs in the ones that I did try out for brief periods before inevitably getting annoyed and/or bored with them). That thought did make me curious, though, as to what sort of product could actually disrupt the FTP game market in the next few years (assuming it doesn't endure an organic downturn in that timespan), if any at all.
> The points in the article are valid, but quirks you learn and get past the first time. I still shoot myself in the foot sometimes even though I don't have a single bare new/malloc without a shared/unique ptr! But that's C++ for you.
I think the article maybe doesn't do enough to outline the full extent of the problem by focussing on a few counterintuitive cases that are present in C++17, because you're right, all of those cases in the article are ones that can be learned and remembered without issue. The real problem, as I see it, is actually that the core language semantics mean that there's no foreseeable end to the foot-shooting treadmill. Since the language is fundamentally permissive of such things, it's likely that further spec revisions will introduce abstractions like string_view that are easy to use unsafely, aren't flagged by static analysis tools, and end up in security-critical code.
Because this feels like a necessary disclaimer, I don't think that fact justifies migrating every active C++ codebase out there to Rust or anything, since pragmatically speaking there are a lot more factors beyond just core language semantics that go into evaluating the best choice of implementation language. I guess my takeaway is neatly expressed by the post title: there's a sense that I get from C++ users (granted, maybe only naive ones) that sticking to the features and abstractions introduced in C++11/14/17/etc basically eliminates all of the potholes of old, and it's evident that that's not true and will probably continue to be not true.
Right, I didn't mean to say that they've made it totally impossible, but that the form factor they're trying to push as the "next thing," wireless audio, is not actually a replacement for that use case ("successor product" refers to wireless headphones, not newer iPhone generations).
But, yeah, I agree that the ecosystem makes it worth it -- it's not like there are any other viable alternatives, anyway.
I don't think they will, or at least they ought not to, because the situations aren't equivalent. At the time that Macbooks started shipping without CD drives, every use case facilitated by CDs was achievable via some other mechanism. Wireless audio doesn't cover all of the affordances of wired audio, since it's incapable of low latency transmission. For me it's noticeable enough to even make watching video with synced sound unpleasant, but what it makes basically impossible is any sort of music creation. Music production is a specialty market to be sure, but it's a non-trivial one, and basically everyone who uses their iOS devices for it is going to remain rightfully annoyed that the proposed successor product is literally unusable for their purposes.
I think what's key here, and why I like the direction of the work in the linked post, is that none of the affordances of the UI they're augmenting -- the command line -- are being taken away,* merely made more visible based on context. I think that gets at a hole in the notion that UI complexity mirrors domain complexity -- in the case of Premiere, surely the entirety of what's on the screen doesn't mirror the complexity of the workflow you're executing right now, it's much closer to the sum total of everything you might ever do. Not that a UI based on progressive disclosure would be trivial or maybe even possible to implement effectively for something like a professional video-editing application, but it's worth considering whether something like that is merely a local maximum in the space of all possible UIs.
* I guess in the case where you know exactly what you want to do and the added context might distract or slow you down, that's an affordance being removed, but I think it's outside the scope of what we're talking about here -- especially because, given the scope of the command line, you will inevitably have to do something with it that involves an invocation that isn't right at the tip of your fingers.