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.
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.
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.)
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.