1,974 karma · joined June 21, 2017
I wonder if it has to do with the scheduler? Desktop linux users sometimes install patchsets to their kernels like zen[1] or ck[2], which effectively enable soft-realtime in order to improve desktop responsiveness and latency, but reduce net throughput. iOS also generally feels more responsive than android, given comparable hardware, for similar reasons: more optimal scheduling algorithm.
Brave is bizarre and terrible. The idea of trying to replace ad-tech as it currently exists is great, and I welcome any experimentation thereunto. That said, brave does it wrong, and I don't think it's a good idea to support that; even without using their ad-tech feature, it still gives them mind- and market-share, and propagates their ad system elsewhere.
#if DEBUG
#define TODO(msg) #warning msg
#else
#define TODO(msg) #error msg
#endifNot particularly relevant, but is there any reason to include that many digits, especially when the source-of-truth fraction is right there?
def a(n):
return lambda: print(n)I have this alias in my .zshrc:
clc() { sbcl --no-userinit --load $1 --eval "(sb-ext:save-lisp-and-die \"$(sansext $1)\" :toplevel 'main :executable t)" }
Sansext is a custom function that strips the file extension from a filename, but you don't need that; you can read output filename from $2, or whatever else.I have a kinesis advantage. There are some things I don't like about it, but I doubt it would be practical for me to make my own keyboard with a bowl shape like kinesis or maltron keyboards. And even if I could figure it out, they've probably done research into exactly what kind of curvature works well for the average hand, so whatever I made would be marginally less ergonomic.
Eh. I'd probably do 'qqA,<esc>j0q', and then '8@q'.
That's also probably not the best example, since that's also trivial if you have an editor supporting multiple cursors.
Or have a separate allocation chain for each thread.
It would increase fragmentation, but not by a lot, and probably increase performance by more than enough to make up for it.
And pressure--i.e. texture.
Not necessarily true. The d compiler runs incredibly fast, for compiling the type of code you'd write in go; and it only slows down if you use a lot of complicated features like templates or CTFE.
Clasp is nice, but SBCL is fast enough that it's mostly extraneous unless you really need to talk to c++ code.
More to the point, kids with affluent backgrounds are far more likely to develop means of their own
Sure it can! Here[1]'s an example of someone using it for html embedded in heredocs.
> [Emacs'] scripting language is a lot nicer to work with.
This is not a fundamental limitation. E.G. neovim uses lua. (I'm not counting python and lua embedded in vim, because afaik they're a total pain to work with.)
I actually recently started transitioning from vim to emacs recently, but I don't think any of your arguments in favour of it are particularly strong. I do, however, agree that vim and emacs are at the cutting-edge of text editing, possibly along with some more niche editors like vis, sam, and kakoune.
1: https://forum.dlang.org/post/bvznmyneecpwgrxmgnby@forum.dlan...