jmcomets · HackerTrans

3 miesiące temudiscuss

From NewPipe : https://github.com/woheller69/FreeDroidWarn?tab=readme-ov-fi...

I wouldn't consider this "a few buttons", it's enough to turn off the less savvy users

jmcomets

8 miesięcy temudiscuss

Obvious caveat: pushing this a bit further it can quickly fallback to the default case. The optimizer is a superpower but you still need to try to write efficient code.

    unsigned add_v5(unsigned x, unsigned y) {
      if (x == y) return 2 * x;
      return x + y;
    }

Results in:

    add_v5(unsigned int, unsigned int):
      lsl w8, w0, #1
      add w9, w1, w0
      cmp w0, w1
      csel w0, w8, w9, eq
      ret

(armv8-a clang 21.1.0 with O3)

If compiler folks can chime in, I'm curious why incrementing in a loop can be unrolled and inspected to optimize to an addition, but doubling the number when both operands are equal can't?

jmcomets

10 miesięcy temudiscuss

Still is. It's a French/Lebanese corp based in Paris/Beirut. I worked there for a few years early in my career.

jmcomets

3 lata temudiscuss

1) C++: 7+ years; Rust: 3+ years.

2) C++, my employer's choice. Their rationale: easier to hire people with experience, internal codebase is mostly C++ so tooling/people more versed.

3) Rust. For me it's just easier overall to work with. It takes me an hour or so to get my head back into Rust's standard library and idioms/quirks, but afterwards it feels much better to work with: dev. workflow, testing, expressiveness. Plus it catches programming errors for me every once in a while.

4) I wish Rust had wider adoption by the industry. It's always compared to C/C++/Java/Go and the usual argument boil down to "not enough people use it".

5) I wish C++ had better compiler error messages. I have to rely on instinct when it's not scrolling through nested template/SFINAE errors to understand what's happening. Rust tells me "here's what's wrong" 99% of the time.

jmcomets

3 lata temudiscuss

Another fact not mentioned in this article is the WWII historical locations found in the unofficial Catacombs. Back when I lived in Paris, I was lucky enough to know someone who had access to one of the Cataphiles' maps (yearly-updated with notes on entrances and potential police patrols, with closest exits and dangerous passages).

We visited an old school basement, which was used as a bunker for members of the Resistance. The school itself was razed and rebuilt over at some point, but the Catacombs still hold traces of this period. Being there felt very...intimate. Nothing like you'd see in a museum or a documentary, we were in the same place as those back then.

jmcomets

3 lata temudiscuss

My pet theory is that programmers are exposed to many business areas during their career, either directly or hearing it from other programmers. This desacralizes these jobs, and since we spend most of our days working though complexity (requirements, bugs, ...), you end up with "what's so hard about X?" statements.

jmcomets

3 lata temudiscuss

+1, the link to Joel Spolky's post on Unicode is probably the most interesting read I've found this year: https://www.joelonsoftware.com/2003/10/08/the-absolute-minim...

jmcomets

3 lata temudiscuss

> Work relationships matter, sharing 3D space allows people to be more creative and collaborative, and companies are recognizing that. Google seems like the last company that would make people come back to the office without doing their homework, there’s clearly data showing that fully remote employees are falling behind.

A couple things I wanted to point out when reading this:

- RTO does not imply sharing a 3D space with those you collaborate with (e.g. distributed teams).

- There is no data that proves that in-person work is more "creative" or "collaborative", simply because it's not measurable.

- You assume Google's intentions to always driven by data rather than appealing to stakeholders.

jmcomets

3 lata temudiscuss

It's a mix of bikeshedding (many people experienced remote work during the COVID lockdowns) and there being no data available for this.

Also consider who would be more likely to respond in this thread: people heavily invested in or against remote work (since there is no actual data). Always-relevant XKCD: https://xkcd.com/386/

jmcomets

3 lata temudiscuss

2022 headcount was estimated at ~1850[0], so that would be 150 employees (allegedly).

[0]: https://en.wikipedia.org/wiki/HashiCorp

jmcomets

3 lata temudiscuss

FWIW, most DBMS have built-in index usage stats, and it's not too difficult to query. In my previous job we had a Postgres health dashboard that notably showed `log10(index size) / index hits`, making it pretty clear when some recently added index was useless.

My opinion is that indexes should be either logical (ex: used for exclusion constraints) or purely for performance (tradeoff space for better QPS). Query patterns change, specs change, so monitoring your DB's performance is the way to go.

jmcomets

3 lata temudiscuss

In my experience these type of abstractions end up bloated with too many concerns which adds maintenance overhead. It's a lot simpler to simply add a `HashMap<Book.title, Book>` and cover with tests, than use an abstraction.

I want languages to do less magic, not more, since I read code more than I write it.

jmcomets

3 lata temudiscuss

> Why does writing in the morning (anecdotally so far) seem to be so effective for writers, even ones who are not morning persons? While programmers, which seems like a similar occupation, are invariably owls?

Also anecdotal, but I've met my share of early bird programmers. I often wonder how much of these habits are driven by ~~stereotypes~~ culture, since theoretically your energy level depends mostly on your lifestyle.

jmcomets

3 lata temudiscuss

To add some praise on this topic, I like (in no particular order): - having dedicated no-meeting days to work on stuff I'm paid to build - being able to talk vision with my PMs (and be listened) - having a budget for software maintenance and developer QoL - not having to do all the software testing on my own - run live experiments with users to test out new ideas

jmcomets

4 lata temudiscuss

Disregarding the "code is doc" position, it's still common to have an overview or index for documentation, which points readers in the right direction instead of dumping pages of detailed docs on them.

Now, you could also have a well organized test suite that goes from most obvious to most detailed, split into sections for each use-case, but this sounds a lot more tedious than "write a one-line comment describing the unit test".

jmcomets

4 lata temudiscuss

For me it was a watch.

I bought a Fitbit Charge 4, originally to track my heart rate/steps since I've never owned one and always relied on my phone for time.

With my phone generally on silent and by not checking it so often, I've found my use of social media/apps has reduced drastically this year. To the point that I recently forgot my phone at home, something that I didn't imagine possible.

jmcomets

4 lata temudiscuss

Just adding to this for the uninitiated-but-curious: the German army invaded by going around the line. This meant taking tanks through the Ardennes, a bordering region consisting of mountains and forests, not quite the Panzer's ideal terrain...

Nowadays it's still used as a French expression to describe a "seemingly impassable defense that's useless in the end".

jmcomets

4 lata temudiscuss

This is what you'd do in a classic OOP approach. Allows for different behavior across variants by pulling out the shared interface. (I think this is what the author mentions when they speak of "different level of abstraction"?)

The downside of this approach is that for subtrees of shared behavior you can go the multi-level inheritance route (risky if you're not sure the leaves will hold their parent's contract) accept the extra boilerplate for similar behavior.

It's interesting to me how this happens quite often and polymorphism is still our go-to solution.

jmcomets

5 lat temudiscuss

With my very basic understanding of orbital mechanics, higher orbits require more dV simply because it's further from Earth.

The more interesting bit is that subtle orbital adjustments require much less dV in higher orbits than in lower ones.

I like to think of it like pushing a barrel uphill: it takes more effort if the slope is steep, but then once it's up there, it's a lot easier to get the barrel moving downhill.

Anyways, the "de-orbit" cost follows the same rule of higher being more costly in dV, the big difference with an ascension being that the atmosphere slowing you down is what you want (aerobraking is the word, I think?). So the difference in dV between a high orbit and a low orbit descent isn't proportionate to that of the ascent, if that makes any sense.

jmcomets

6 lat temudiscuss

Sphere packing was my 3rd year internship project (summer of 2013), so happy to see what is quite the fascinating topic mentioned on HN! I'm a bit sad I don't have a lot to show for it, other than an old undocumented GitHub repo[1]...

Glad to hear there were breakthroughs in the field, thanks for the heap of links for me to delve into. :)

[1]: https://github.com/dcoeurjo/ThicknessDiag

comments