aWidebrant

Documentation of interfaces between components that are owned by different organizations get my full attention and care.

Everything else is best effort.

I think this is required reading on IQ and g:

http://bactra.org/weblog/520.html

http://bactra.org/weblog/523.html

On efficient markets, I'd recommend:

https://economics.northwestern.edu/docs/events/nemmers/2004/...

"Why did such a bland observation resonate with so many people?"

Asked and answered.

The study in the topic seems to contradict this, although the summary is a bit confusing:

"Considering gender inequality, the authors report that “in countries of higher gender inequality, women’s stronger preference for working with people versus things compared to men was smaller.” However, this effect disappeared when cultural dimensions were taken into account.

"Instead, it was those countries with greater uncertainty avoidance that had larger differences in interests in people/things between men and women. Uncertainty avoidance refers to the degree to which a culture teaches its members to feel unpleasant in situations that are new, not previously known, surprising, or generally just different from usual."

It seems to me that the main reason to learn C would be to be able to dive deeper into the low-level implementation details of some hardware platform.

With that in mind, I would suggest picking a piece of hardware you want to learn more about, and using C programming to see what makes it tick.

"From my experience, what works incredibly well is a partnership between biologists and software engineers: the biologists first come up with the first concept of the tool, which is purely focused on ensuring good results. After this first iteration is completed, engineers then come in and rewrite the tool using modern engineering practices with things like speed and reliability in mind."

Like others have pointed out, this really makes the engineer's end of the bargain sound like janitorial work. There's no lack of fields where researchers and engineers both sit at the table from the beginning to pick which projects to pursue and how to implement them.

It's hard to imagine that a powerful self-modifying AI would continuously pass up on the obvious optimization of just giving itself the maximum perceivable reward without doing any further work.

I guess computers just can't learn how to cheat.

Swedish public television has covered this story quite extensively:

https://www.svt.se/nyheter/granskning/

Presuming that a large part of those 100 W go to the power amps for uplink transmissions, it seems that it should be possible to make at least that part scale with how much outgoing data the terminal is actually sending. But that may require new hardware, and it may conflict with the ambition of reducing cost per unit.

Is this just the second coming of cellular automata?

In terms of the OSI model, I've gone from working with software on top of layer 7 to working on software and hardware at the bottom of layer 1.

It's been a fun and challenging transition, but my job satisfaction has mostly been determined by the people I work with rather than the subject matter.

Specifically to your points, I haven't really seen any major difference in the ratio between routine and creative programming at the high and at the low level. The amount of politics and business requirements has also been quite similar.

Personally, I'll have the former style of business jargon over the latter. Sure, "leverage the innovative" doesn't mean anything, but at least it's not actively infantilizing.

In practice, the American revolution did not come about through open debate:

https://thebaffler.com/salvos/on-the-rudeness-of-mobs-pogue

'On October 25, the freemen of Essex County, New Jersey, proclaimed that anyone who adhered to the Stamp Act should be cast out of polite society, that decent people should have “no Communication with any such Person, nor speak with them on any Occasion unless it be to inform them of their Vileness.” This was not an isolated view. One writer to a Pennsylvania paper suggested, in language typical of the time, that a man paying stamp duties should be “branded with eternal infamy and reproach,” and cast out. “Let him be alone in the world—let him wish to associate with the wild beasts of some dark loathsome cave.”'

Putting a CPU core in your hardware accelerator seems more useful when it's stuck on the wrong side of a memory bottleneck. That way, you could run longer programs in local accelerator memory before you have to take the hit of communicating with the rest of the system.

Apple's M1 seems designed to give all types of cores equally fast access to the same memory pool. At that point, it might make more sense to make your accelerator cores as simple as possible and program them from the CPU.

I guess what's really not clear to me is why, if you're building your main CPU on ARM, you would pick RISC-V for your programmable accelerators in the same SoC, rather than using one of the smaller ARM cores available.

For an approachable but not shallow introduction to philosophy via Plato, try Holbo and Waring's Reason and Persuasion, available as a free book and Coursera lecture series:

https://www.reasonandpersuasion.com/

N+1 and The Baffler both seem to be constitutionally incapable of releasing a bad issue. Highly recommended.

Jacobin is uneven, but if you read Reason et al you owe it to yourself to pick up a copy now and then to keep up with ideological writing in the land of the living.

The Economist is an incredibly well written magazine that unfortunately - editorials aside - can't escape the compulsion of not even being wrong. Save your money and just sign up for a couple of Axios newsletters for the same effect.

I have not read Edge in years, maybe decades, but it deserves a mention for treating video games as digital art rather than consumer electronics.

ECDO sounds cooler.

I think a better approach is back-front-back, or front-front-back; or front-front-back and then side-to-side.

Good job!

I recommend that you learn how to speak slowly.

This not only makes you easier to understand, but also makes it easier for people to interrupt and ask questions.

And as others have said, listen carefully to questions and suggestions and try to answer them at length.

Bonus points if you can carry this over into writing, too.

I like this a lot. It feels like a much healthier starting point than diving head first into the discovery feeds of the platforms.

The main thing that C provides over other languages is direct hardware access. So study the hardware, find out what you want to do with it, then use C to implement it.

When it comes to documentation, be realistic about how much time - in terms of product features delayed or not delivered - you have to spend on creating documentation and on keeping it fresh.

Also be realistic about how the documentation will be used. I found this paper and its references useful:

https://news.ycombinator.com/item?id=20471577

Lightly edited: https://rentry.co/zq4r6

Attention conservation notice: Lengthy somewhat tendentious history of Soviet Leninism, followed by an assertion that the confusing twists of cancel culture is down to the woke masses being in thrall to a Hiddden Lenin, and a rapid exit.

"Write like you talk" is bad advice twice: It encourages rambling, which - unlike in a conversation - the reader has no means to interrupt, and it offers no clear rules to follow while writing. Orwell's six[1] are, in my experience, much more useful:

  (i) Never use a metaphor, simile, or other figure of speech which
      you are used to seeing in print.

  (ii) Never use a long word where a short one will do.

  (iii) If it is possible to cut a word out, always cut it out.

  (iv) Never use the passive where you can use the active.

  (v) Never use a foreign phrase, a scientific word, or a jargon
      word if you can think of an everyday English equivalent.

  (vi) Break any of these rules sooner than say anything outright
       barbarous.

[1] https://www.mtholyoke.edu/acad/intrel/orwell46.htm