mrbrowning

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.

Sibling commenters got it. Sorry for the jargon, I've clearly been here too long!

The whole exercise felt like taking attendance.

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

- Semantics of Programming Languages, Carl Gunter

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

No, thank you for that!

This is wonderful, but I am a little disappointed that it wasn't about mechanical watch movements.

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.

For what it's worth, I don't particularly have a cross to bear with respect to Java. I cited it just because its invocations as a Bad Language bogeyman are common in the Go-focused writings I've found, and those are far out of proportion to its inherent flaws (of which I believe there are many!). I completely agree that it's a matter of preference, which I think is supported by the fact that I found Go to be the best choice of language in the context that I'm operating in whatever my reservations.

I'm confused about your assertion that the Java ecosystem has a similar problem, though, because my sense is both that it has a much less identifiable orthodoxy by virtue of being so widely used across so many domains, and that the new guard, such as it is, is very much in favor of creating libraries and utilities that favor simpler implementations and interfaces contra its "architecture astronaut" baggage.

This attitude, which I'll paraphrase as "needing any feature that I personally consider unnecessary is a code smell," is endemic to the Go community and a big reason why I still find myself frustrated by it on a daily basis even after a month of using it for a greenfield project. I don't like the language itself, since I'm generally in favor of a language offering more affordances rather than fewer, but it's fine to write in and I'm ultimately concerned with making the pragmatic choice. When I go to look for what the idiomatic way to do something is, though, wow! It's rarely just "this is the way to do it, since the language optimized for a particular use case by making the tradeoff of omitting the usual features for this": instead, it frequently goes on to assert that those features are unnecessary in nearly every case and languages that provide them are wrong, or old-fashioned, or too Academic, or the people that use them don't care about Getting Things Done. Also, throw in a few cargo-culted potshots at Java for good measure! I've used a good number of languages professionally at this point, and the Go orthodoxy is easily the most off-putting I've ever encountered. I don't know why it's become so aggressively totalizing, but it's not a good thing.

I grew to really hate annotation-based magic when I worked on a project that used Jackson for JSON serialization. Not only does it circumvent the type system entirely, it also makes errors incredibly hard to track down by virtue of the fact that there are next to no static constraints on how annotations are used. Something as simple as adding a serializable field to an interface or object often ended up requiring a ridiculous amount of trial and error to get right. I think annotations are valuable if used judiciously, but unfettered annotation-based metaprogramming only ever leads to pain in my experience.

I feel the same. I keep Chrome around, though, because it seems to be the new IE in the sense that I frequently encounter sites that simply don't work properly in either WebKit- or Gecko-based browsers. It's also the new IE in the sense that I get incessant reminders about how I should be using Chrome when I access Google-administrated services, which feels like a surprisingly blatant if still implicit admission on their part that an open web simply isn't a concern or interest of theirs. I never really believed otherwise, but still.

I don’t remember where I saw it, so it could be apocryphal, but I saw an admission from an Ableton developer that the difficulty in implementing MPE support is down to the fact that MIDI implementation details are baked into a bunch of disparate components across levels of abstraction within Live, which seems pretty plausible to me. I don’t envy the effort involved in rectifying that, but it does have me looking at Bitwig more and more.

I think your first paragraph is on the money, this is indeed how many engineers and engineering managers think. You seem to throw in your cards with that viewpoint in your second paragraph, though, and I think the logic there is circular. Engineers and engineering managers persistently devalue the skillset behind being an excellent technical writer, and the value that an excellent technical writer brings to a project, which in turn weakens the “bargaining foundations” of technical writers artificially. It’s been my experience as an engineer that this artificial devaluation is harmful to projects both directly and indirectly, because technical writers are inevitably aware of the fact that it’s happening. That technical writing maybe has a greater foundation in so-called “soft skills” doesn’t mean that it’s less valuable, and especially in cases like Rust where the documentation can very reasonably be considered part of the product, it’s a huge mistake to undervalue the work of someone like Steve Klabnick that way. In general, I can’t imagine being resentful of a technical writer earning as much or more than me as an engineer: a perfect gem of software engineering that no one uses is a failed product, and it’s very much because of the work of technical writers that good projects see widespread use.

"Appeal to authority" is a fallacious rhetorical tactic only in an extraordinarily rigorous epistemological context, in which all truths need to be established from first principles. In practice, especially given the information asymmetry between the people that have devoted rigorous study to a thing and the people that think they know about it because making computers do things means they're smart (which is an intellectual pathology that I think ought to bother anyone who cares about the process of modeling physical phenomena accurately and honestly, even if it doesn't bother you), an argument like "physicists uniformly agree on this physical property" is a perfectly adequate assertion in favor of the claims made in the article. It would for sure be bolstered by the inclusion of sources, but you have to admit that you're throwing away a lot of relevant information towards the end of supporting your intuitive sense about how the optics here work. It's not impossible, in the absence of an argument from first principles to counter, that you're correct and that people who have formally studied physics and/or are familiar with the literature are wrong or misguided, but it sure isn't the most likely case by a wide margin. In that context, your certainty ("I don't think the details of his argument can be [correct]") seems much less well-founded.

Less top speed, which is governed by many factors (consider that maintaining any constant speed in a vehicle requires some minimum power output to counter losses to heat/friction throughout the drivetrain and between the vehicle and oncoming air, not to mention the maximum safe operating speed of the drivetrain components themselves), but rather the potential for acceleration. If you look at the torque curve for some power plant, where the independent variable is oscillation speed and the dependent variable is output torque, you'll find that (for some fixed gear ratio between the power plant speed and the wheel speed) the maximum acceleration occurs at the point along that curve where torque is maximized. Electric motors have a much flatter torque curve with respect to rotor RPM than do combustion engines with respect to crankshaft RPM, but they still see a nontrivial drop in torque as rotor speed approaches its operating maximum. Transmissions exist to maximize the driver's access to torque: if you're traveling at 60mph on the highway with your engine spinning at 2K RPM, but your engine makes maximal torque at 4K RPM, you can shift downward to maintain your same vehicle speed while increasing the speed at which your engine turns over, thus giving you enhanced ability to bring your car up to speed before you merge with the lane to the left of you where everyone is driving much faster. A car that loses available torque at high power plant speeds and that lacks the ability to use such gearing to take advantage of optimal power plant torque will be unable to produce as much acceleration at high speeds as a car that has several gear ratios available.

Caveat: I'm just an automotive hobbyist, so if an automotive engineer rolls in and calls bullshit on anything I've said above, they're almost certainly correct.

I’m a committed manual driver, but I fully grant that dual-clutch transmissions and EV powertrains handily outclass manual transmissions from the perspective of effectiveness (although my casual understanding is that an electric motor without a gearbox is still going to be limited in its ability to provide torque at high rotor speeds). I would consider driving a car relying on either of those technologies, even though I favor the subjective experience of a manual transmission, but I still can’t imagine driving any vehicle with a torque converter or a CVT (CVTs sound great in theory, but as far as I know they’re still pretty limited in terms of torque tolerance). I’ve driven some nice autos and still find their response to torque demand from the pedal to be unacceptably slow, plus I find the way that throttle mapping works in manual transmission cars to be much more intuitively close to what I would expect from direct throttle control. Flooring it to induce a downshift feels like a crude distortion of the input space in a way that inhibits the development of an intuitive connection with the vehicle’s operation.

Anyway, if you’re a performance vehicle enthusiast on a budget, you’re going to have trouble finding a suitable car that isn’t equipped with a manual.

I think what the grandparent is getting at is that music is a culturally-mediated perceptual phenomenon, and so the geometric interpretations here are an artifact of the model rather than of how our minds organize pitch into some musical Gestalt. I both agree with that (I love Coltrane, but as the article accidentally implies, this is about as meaningful as numerology) and find the artifacts to be pretty cool, so I’m not so down on it as an intellectual lark as that poster.