acomar

it's also remarkably intuitive. like I laughed and then realized that would be a fairly pleasant way to control the volume for anyone with decent vocal control.

whomst among us doesn't love a vampire that mainlines the blood of teenagers?

this is a poor analysis. different factions of capital frequently go to war with each other - always over the question of who gets to profit. (in fact, in the final analysis, these irreconcileable schisms within the bourgeoisie are a necessary, though insufficient, precursor to revolution.)

I agree with you that she will probably fail but I think that's more about this project moreso than whether this project hurts capital. remember, the true point of vulnerability of the system is the point at which wages are paid and profits are earned. labor must strike to starve capital because anything else can be recuperated and commidified.

lastly, yes, the intent of the law is to preserve existing capital, but as this board can attest, "existing capital" is a term constantly in flux, and laws change quickly to support the changing makeup of capital. otherwise, what has happened with uber would be impossible as governments fought to protect taxi companies - this happened but now uber no longer resides in a gray area. you'll note that what actually happened here was that finance capital extended it's reach and no new capital was actually created - it merely changed forms. that should also tell you how scihub might go from blacksheep of the bourgeois family to darling, especially once it's purchased and brought under the aegis of existing capital entities. however, for this to happen, Alexandra must play ball with investors, the legal system, etc., and as she has thus far resisted doing so, she will likely fail. projects like hers must either have secret and undiscoverable provenance, or be so distributed that legal force can only be brought to bear on a multitude of actors of no significance to the operation of the project - the hydra with many heads.

so it's not legal tenets I look to but rather an analysis of capital itself.

I've never in my life worked on a professional project I could describe this way. this might be the most common path but it's far from the only one.

it's one industry while others stand to reduce costs if she succeeds. the relatively warm welcome she receives here should indicate how willing other bourgeois segments are to support her platform. free access to information is not by itself anticapitalist, though it sure does make it easier. but recuperation is ever a threat (free software vs open source for a topical example).

what does unemployment have to do with it? if you're 22 and paying off loans and suddenly find yourself unable to work as much but a barista, continued employment isn't exactly a perk. meanwhile, the benefits of the increased productivity brought by new technology do accrue somewhere - it's just not with workers. the trends on that are also quite clear. productivity growth has been high over the past 40 years but real wages have at best been stagnant. and on the wheel turns, finding souls to grind beneath it's weight, anew.

here's the difference: the farmers are large industrial companies that lobby the government for subsidies, such that they can continue to produce food that can, by law, never be eaten.

programmers, on the other hand, are wage laborers, individually selling their labor to employers who profit by paying them less.

industry is sitting on the opposite side of the equation here. I wonder what will replace "learn to code". whatever it is, the irony will be almost as rich as the businesses that profit from all this.

you need fmap as well.

the terms actually do come from an intuitive place if you look at the underlying math. it's called a functor because it does something function-like - mapping arrows in the domain category to arrows in the codomain. in programming, we think of this as a higher-order function that lifts a function on a category (of types) to a function on a different category (of types). it's only when you try to elide that explanation that the name appears to come from nowhere.

similarly, monads bear a strong resemblance to monoids - in fact, it's the same relationship as functions and functors and it's quite precise. these intuitions only become available to you with the math, though, and programmers have a strange aversion to mathematics for people who do it day in and day out.

what was true centuries ago is no longer true. "he" is not gender neutral in English, in any sense of the term. it's only used as such in historical writing - languages evolve over time. "she" connotes as much knowledge as "he".

> Don't transition unless...

ancient trans proverb

I mean, we knew it was malware and installed it anyway. I'd warn friends' parents about it and they'd shrug not really understanding why they should care.

> On editors in general: I’d like to have an editor as a library for which I could create modes/cli/behaviors myself.

this is what emacs is and what makes everything else feel so poor by contrast.

and in emacs you can just redirect the command output to a buffer. or honestly, 99% of the time, I don't even bother redirecting and muck with the output directly in the eshell buffer.

q another character begins recording a macro. press q again to finish recording.

IME they fail at all 3.

when capitalism ends.

you can drop the resulting binary in a scratch container that has no shell, etc.

there's a negation preceding that.

the bigger issue is around the combination of closures, generic parameters, and traits. because higher-rank types can't be expressed and closures are all `impl Fn()`, you start to get an explosion in the complexity of managing the types and implementing the trait. try implementing something in the "finally tagless" style for an example of the kinds of things that can go wrong really fast. `Box` and `Rc` don't get you out of it and the resulting implementation is brittle and boiler-plate heavy in actual use.

from memory:

    trait Prop<'a, T> {
        fn p<F: Fn(&'a T) -> bool>(f: F) -> Self;
        fn eval(&self, &'a T) -> bool;
    }

    enum LiftedBool<'a, T, F: Fn(&'a T) -> bool> {
        Base(Box<F>),
        And(LiftedBool<'a, T, F>, LiftedBool<'a, T, F>),
        Or(LiftedBool<'a, T, F>, LiftedBool<'a, T, F>),
        Not(LiftedBool<'a, T, F>),
    }

    impl<'a, T, F: Fn(&'a T) -> bool> Prop<'a, T> for LiftedBool<'a, T, F> {
        fn p<F: Fn(&'a T) -> bool>(f: F) -> Self {
            // this fails because `F` in the impl doesn't necessarily unify with `F` in the trait definition
            // it can be made to work with `dyn` for the function argument but requires boilerplate to actually use
        }

        fn eval(&self, &'a T) -> bool {
            // obvious evaluation by cases
        }
    }

this example can be fixed to work via `dyn` for the argument on the trait function and the struct itself but it becomes increasingly painful to actually work with. this kind of generic work is not at all ergonomic but very easy in Haskell.

treestyle tabs and container tabs are the others I can think of. they also integrate very well with each other.

the orbitals aren't neat rings but there are definitely orbitals. they're shaped weirdly as they represent the space two electrons will probabilistically occupy. you can't pinpoint an electron and say it is precisely here in the orbital but there are fairly high odds that it's in the orbital.

there's a moment with the language where you go from trying to do things the way you would have done them in another language and instead, your brain adapts, and you learn to do them the functional way. because it's Haskell, you learn that you can quickly simplify things -- a little glue, a better understanding of the various functions you can pull out from the standard library, etc. -- and something that seemed incredibly complex reduces (like, for a very strong definition of like, algebra) to a few simple terms. many parts of the language come together and make it all click in this way: the syntax, the automatic currying of functions, the purity, and the type system. you start to look at all code differently. you start to see it as a bunch of puzzle pieces that can be fit together just so. and when you go back to try and use something else, you find yourself reflexively reaching for tools that aren't there, or that, removed from their original context, no longer have the support that made them quite so useful or so pleasant in Haskell. you even feel it going to other functional languages -- sticking all these parantheses into this lisp is obscuring the simple details, the puzzle pieces extended with decoration that makes them fit together less well.

i don't mean to suggest Haskell is without flaws. but i do think you'll experience the paradigm shift as something concrete. there are almost no languages like it, after all.

people usually can't articulate what they want and they always want to skip the hard bits. look to what they do rather than what they say and find a way to slowly pull them towards what they ought to want. it takes a long time but you can make things better under conditions like that.

This is much, much better on Emacs 27 with native json parsing. Once the language server is fully loaded (which can take a little while sometimes), input lag becomes insignificant again. Strongly recommend upgrading.

definitely. i agree with all of that. i have high hopes for remacs.

honestly, with lsp-mode, it's pretty dang close to vscode, at least for the languages I care about. and the benefits of evil + a fully configurable editor are too much to pass up. a drop-in replacement for newcomers? no way. but if a powerful environment is valuable for you, like say if you spend a lot of time in an IDE and the shell, emacs's ability to integrate those things and a lot more is too good to pass up.

I think it's possible to implement this as an extension on top of evil? trigger a bookmark when the user starts scrolling, jump back to the bookmark on keystroke in insert mode.

but yeah, there's generally a problem with the UI/UX -- like as a consequence of the problem you're describing, you have to clear your current selection before scrolling to paste from the kill buffer. it's all foibles you learn about and adjust to but it makes the environment feel unpolished on a first impression.

spacemacs and doom have a better impression out of the box but there are just some core problems that they can't fix with a clever configuration. one that frustrates me regularly is auto-complete (company) triggering a network call that's bound to time out (because of user error) and the whole editor hanging for the duration because the completion call happened in the same thread as the UI. actually, the single threaded nature of most of emacs is probably my biggest complaint...

I've started using hyphens to offset clauses that nest inside of other comma-separated syntactic structures for this reason. It keeps my intent way more clear without forcing the reader to reparse the sentence if they incorrectly guess how the commas are supposed to line up.

> accurate ratios between parameters, and matched pairs of components, and inaccurate - but long-term stable - parameters that can be calibrated out.

is much easier to follow at a glance.

there's an element of "what will people actually do". 6 feet gets the idea across while not coming across as "don't be in the same room as other people", which people will ignore.