HN user
Every time I can remember that the finance people have become more important to a company, it has led to the disappearance of the internal culture geared towards excellence that got a company to that point in the first place.
Buddhism has bad news for you
I wish my forehead had more headroom for the amount of travel my right eyebrow needs to accommodate this statement.
Interesting and well-executed. But why does the blog post read like it was written by fucking chatgpt?!
I was this close to concluding with a paragraph about Buddhism and the Self. Which is basically the same thing, but from the first-person perspective.
When understanding a new "magic", there's this beautiful moment when you grok it, and the abstraction poofs away.
It's when you take apart a mechanical clock and keep looking for the time-keeping part, until you figure out that there isn't a time-keeping part in there, it's just gears and a spring.
It's when you learn about integrated circuits and full-adders, and keep trying to understand how a bunch of transistors can do Mathematics, until you figure out that there isn't a mathematics-doing part in there, it's just circuits and wires, arranged in a way that makes the voltages come out right.
It's when your understanding of the top-down structure snaps together with the bottom-up mechanics of the building blocks. There's no space left for the ghost in the machine to haunt, and you go "Oh. huh". I live for that moment.
I'm not sure if investors will agree. The general way the stock market works heavily favors shortsighted thinking. They'll say après moi, le déluge and then package the déluge up into sellable financial instruments.
We have to contend with working with people who are sometimes very hard to work with. Watercooler talk gives you the opportunity to remember that the guy who keeps filing badly written tickets has a wife and kids and hobbies, and is likely filing badly written tickets because he's extremely overworked and doesn't have time to write better tickets.
We're social creatures, and having unstructured social interactions greases the wheels when we work together.
I'm sure this also depends on the kind of organization you work at, but I find that being on-site makes a huge difference. Yes, even in the quality of the work.
"Bard won't always get it right"
That's like saying "the imp you summoned and are keeping in a cage won't always tell the truth" or "fever dreams won't always be true prophecies of things to come".
I'd like to thank you for the time and effort it must take to research, write and edit these articles. The tone you strike with these articles is a delight to read, and I find myself gobbling these things up even for topics about which I (falsely, it usually turns out) consider myself fairly knowledgeable.
As a compiler guy, I'd appreciate some look at the layers of abstraction in-between (so, ASM). Microbenchmarks are famously jittery on modern CPUs due to cache effects, branch prediction, process eviction, data dependencies, pipeline stalls, OoO execution, instruction level parallelism, etc.
You have to be really careful to ensure the numbers you're getting are really coming from the thing you're trying to benchmark, and aren't corrupted beyond recognition by your benchmarking harness.
Some of these questions would surely be trivial if I actually knew any Go, but I'm left wondering:
* What does the machine code / assembly look like for this? What does the cast compile down to?
* What's `int` an alias for? I assume 64-bit-signed-integer?
* Are integer casts checked in go? Would an overflowing cast fault?
You've already got that part down pat. "Shaping your mental behavior to minimize surprise" is just a really complicated way of saying "attempting to understand a thing". There's no secret technique here, I was just trying to tie the process of learning back to surprise.
I think there's definitely something to the neuroplasticity thing. Learning does take longer as we age, that's just a biological fact.
Man what a frustrating journey it has been ! I keep telling myself I'm a seasoned senior dev...
This right here, that's something you're misunderstanding. Learning something new is supposed to be uncomfortable. To learn most effectively, you want to shape your mental behavior to minimize surprise (i.e. grok things) while shaping your outward behavior to maximize surprise (i.e. challenge / update your understanding). That's frustrating. Even if you've learned other things before.
The only thing you're missing is a healthy set of expectations. Accept and welcome the discomfort, and you'll learn like you've never learned before. Thinking you should be exempt from this just adds internal resistance to an already uncomfortable process.
Axiom Verge (2015) uses the same trick to avoid the `strings` utility, but with parametrized cheat codes. (Back then I took it apart in a decompiler and looked up all the cheats, see https://trollbu.de/axiomverge/)
By simple statistics, most people are, on average, about average. This is true for any population large enough. I don't buy your assertion that C++ developers are better than Java developers, and all else being equal, bad Java code doesn't blow up in as destructive a way as bad C++ code.
Deliberately keeping a working environment hazardous and unsafe doesn't give you a breed of superhumans that never let accidents happen, it just leads to a lot of unnecessary accidents.
I know you said you didn't want to go into why you needed this, but I am curious: why did you need this (preventing your machine from going to sleep I imagine?), and why didn't `while true; do xdotool click 1; sleep 60; done` do the job? (no logged in user, perhaps?)
If you're interested in this kind of thing, note that Coq can also extract code in Haskell, Scheme and OCaml.
If Coq's not quite your cup of tea, Isabelle/HOL is another proof assistant with amazing (dare I say superior?) tooling and automation, and it supports code extraction in SML, OCaml, Haskell and Scala.
Microsoft Research's Lean theorem prover is also promising in this regard. Work is almost complete on native code compilation (via C code extraction), allowing you to compile all the constructions you can formalize in Lean directly to native code. (see https://github.com/leanprover/lean/pull/1241 for progress)
(Note that none of those code extractors are verified to be correct themselves, lacking a formalization of the target language's semantics. You don't get a mathematical proof that the code you're running does what you specified, but you get pretty damn close.)
Isn't this basically what Google has been doing for years with their DiRT exercises?
Judging by the preview image for the live stream (yeah, I wish I had more to go on, too), this looks to be a long-haul plan for terraforming mars. I wouldn't hold my breath for the first actual settlements up there.
That being said: Yes. Oh yes. Fuck yes. All my yesses.
And thus the student was enlightened.
As a reader of a website, I usually primarily care about what the page looks like when it's rendered, as opposed to how clean the HTML is.
Granted, the current trend to make everything feel like a shitty JavaScript application would be taking it too far, but lwn.net is definitely not a pleasure to read. Yes, it displays "just fine" in links, lynx, elinks, etc., if your definition of "just fine" is Fefe's Blog.
The video's nice and all, but I'd appreciate if people would stop using my Mom as a stand-in for "person who is not competent with technology".
Also, did they really mistake the chrome logo for the google logo?
Good to know StartSSL is just as shoddy as it's always looked. Good thing we have letsencrypt these days.
I'm sorry, but in a time where the US is killing people on the other side of the world using unmanned bomber drones based on just this international spying, I have a hard time believing that any of this should be "fair game".
As someone who doesn't live in the US, I am awestruck by how big of a deal this seems to be for people.
Are you really trying to tell me that surveillance of ~the rest of the world~ is somehow less bad?
Before the site has given me any reason to join, it makes me choose between 7 virtually indistinguishable options of providers with subtle technical advantages and disadvantages.
Ah, GNU projects. Never change.
ahem... "Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp."
You're absolutely right, and I'm a colossal idiot for not making that absolutely clear.
It doesn't really send a signal to your program. It just sets flags inside cpython to make it think so. (pendingbusy and pendingcalls_to_do, to be precise)
Depending on what state cpython is in when you inject, pyrasite may deadlock or segfault the interpreter. All it does is try to get the GIL and then inject the code.
Pyringe first gets to a safe place before injecting by (essentially) faking the delivery of a signal, then waiting for python-level signal handler dispatch to trigger. By doing so, it ensures the interpreter first gets itself into a state in which it can execute arbitrary python code before performing the injection.
Pyrasite has a bunch of features pyringe doesn't, though.