Hacker News new | past | comments | ask | show | jobs | submit | rocqua's comments login

> "Further establishing a welcoming and diverse work environment encouraging synergy and collaboration by committing to a common set of strategic goals."

That certainly is buzzword soup. But I don't think its fully incoherent or bullshit. It essentially says:

Lets continue becoming more diverse. Because doing that will help us work together better and more. We will do this by all agreeing on what our goals are and agreeing that we will follow them.

The core concept is not that bullshitty. Though how exactly agreement on the goals leads to more diversity isn't quite clear. If the workshop were to be about figuring out if / how agreement on goals leads to more diversity in your specific company, then your buzzword soup happened to deliver an accidentally useful discussion.

> Lets continue becoming more diverse

Problem is that diverse doesn't really say anything, it is just a positive word. Diversity is often a bad thing, you don't want to have to build a diverse set of services for one functionality etc. Diversifying your income streams is good, but also not good since it dilutes efforts, you know there is also the "focus on your core business" mantra that goes the exact opposite.

Edit: For example, can you explain what "diverse work environment" means? Do they have no desk standards so that desks don't fit neatly together? Do they lack AC so that you get a diverse temperature over the year? Inclusive work environment would have said more, but diverse? Whatever positive meaning you attribute to it comes from your own imagination, that is the main selling point of these slogans. You don't promise anything but people still feel you said something good.

In a lot of social circles, the word "diverse" has undergone significant semantic narrowing. https://www.nytimes.com/2021/10/01/opinion/language-race-sem... is a decent discussion of the phenomenon.

It does mean the word means totally different things to different people. That may make it a good or bad word to use in a mission statement, depending on your goals.

> Because doing that will help us work together better and more

Not my experience at all. The more diverse, the harder it is to communicate, share values, and achieve goals. We are all products of our cultures. And some cultures are fundamentally incompatible.

Also, it is impossible for everybody to agree on the same goals. Without some sort of social/hidden pressure to comply with the dominant opinions, clearly signalled by who gets promoted/fired by the company.

In other words, I call it for what it is: BS.

You might disagree with the premise. But the statement is meaningful, interpretable, and testable. I don't think that qualifies as "bullshitting" because there is clarity.

I could imagine the content of workshop involving bullshitting. (Regardless of whether diversity is positive) but I don't think the title counts as bullshit.

As for me having a blindspot, I hope you see I wasn't arguing about diversity at all.

But it is bullshit - it just says, "let us do the things that work well, and not do the things that do not work well". It's not wrong, but it doesn't need to be said, either. Of course he was trying to be ridiculous, but it sounds like every other corporate mission statement.

No, it is much more specific.

It identifies a specific goal, a reason to reach that goal, and a way to attain that goal.

The idea could actually be wrong. Whilst "do things that work well" is a tautological statement.

It actually is pretty "bullshitty". Diversity is just cultural zeitgeist that companies parrot to please demographics they want to hire. It's the definition of Mammon.

> Lets continue becoming more diverse. Because doing that will help us work together better and more.

This is a tautology.

I suspect you have a blindspot here, because this specific brand of bullshit is there to please people with your belief system. To others, it's as much bullshit as a company prayer, or talk of how a SAAS startup is "changing the world", would be.

That is not a tautology at all. It is closer to a contradiction.

My point wasn't that I agree with the statement. My point is that the statement has clarity, and that it actually communicates an idea.

The very fact that the statement could be falsified means to me that it is not bullshit as meant in the article. That is not to say the statement is true!

This always makes me think of the 'uncertainty principle' and quantized values in physics. As a layman, it seems to me like both of these combine to limit the amount of information needed to describe the state of the universe.

I don't know enough about quantum mechanics to check if this makes sense. My wild imagination suggests that 'waveform collapse' could be modeled as the result of a simulation being forced to resolve a state of a specific particle for further calculations. I imagine it is hard to come up with a plausible 'simulation model' for this that includes features like probability wave interference and entanglement of particles.

Such a model would be amazing for insight into quantum mechanics, and also have far-reaching consequence for metaphysics. It would strengthen the argument for us living in a simulation, if the peculiarities of quantum mechanics can be modeled as artifacts of a particularly efficient emulation.

Saying X is a pox on Y means saying X is bad for Y.

It originates from the disease 'the pox'.

For the sake of keeping people from doing stupid things.


The test involves placing your phone in the microwave and closing the door without turning the microwave on. I'd unplug the microwave before trying this.

“This is a man who has experienced The Public”


Also, 20-30 Db of attenuation for light is already quite a lot. Whilst for a radio signal it is still very conceivable that 30Db of attenuation still allows for a signal to be received.

Our eyes simply aren't very sensitive instruments. And the visible part of the spectrum is uncharacteristically full of 'noise', so it makes some sense that our eyes don't need to detect any signals that are too far below the noise-floor.

That makes me wonder. How much 'darker' is any given bit of radio spectrum as compared to the visual spectrum earth at night.

> our eyes aren't very sensitive instruments

I take umbrage with that statement! Our eyes are exquisitely sensitive, and most importantly, have staggering dynamic range.

Our eyes are capable of perceiving a single photon [1], albeit noisily (I've been lucky enough to have performed this experiment myself!).

But the greatest thing about our eyes is the dynamic range: the difference in brightness between a moonless, starry night (which we are perfectly capable of navigating by eyesight) and a bright sunny day is nine orders of magnitude. A bright day is a billion times brighter!

Show me an RF receiver or light camera with that dynamic range!

The one place our eyes are limited is in frequency range.

[1] https://www.nature.com/articles/ncomms12172

I knew the dynamic range was large. I did not know about the sensitivity! That is quite impressive.

The magnitude of the dynamic range is even more impressive if converted to 'stops' from photography, yielding about 30 stops (1 stop halves the light). Whereas a really good camera will do about 15 stops. Though I suppose that the camera gets 15 stops in a single 'scene'. Whilst the 30 stop figure for the human eye does not hold up if half your vision is taken up by daylight and the other half by a night sky. For a single 'scene' I think it becomes hard to define the dynamic range of a human eye though.

As well: because of reed solomon a modern digital signal can be reconstructed from flickers and fragments of the radio waves

What does this mean? A fragment of a radio wave is still a radio wave and can carry information irrespective of whether reed solomon or other encoding is used, no?

Think of it like trying to receive morse code:

If the signal gets choppy and you miss some of it, how do you know what you missed?

`..--- -.... ----- -----` (2600) could come through as `..- -. —` (Uno). Uno is a valid word, so passes validation, but it’s the wrong message.

What Reed-Solomon allows us to do is pad the message with n% of error correcting ‘bits’. That way, if >100-n% of the message gets through, the whole message can be reconstructed from whatever bits that made it. And if not enough of the message made it, it immediately fails the validation check and so you know you must resend the message.

It’s so handy and so solid that it’s used almost everywhere. From optical discs to ECC ram to radio communications and a bunch more.

I wonder how the canary image interacts with 'rendering intent'. I could well imagine 'relative colorimetric' or 'perceptual' methods of converting to sRGB color space essentially scaling down how red the square is to allow showing the embedded logo in a redder color than the rest of the square.

Is there a way to do FFI without having languages directly mutate each other's memory, but still within the same process. So all 'communication' between the languages happens by serializing data, no shared memory being used for FFI. But you don't get the massive overhead of having to launch a second process.

You are still depending on the called function not clobbering over random memory. But if the called function is well-behaved you would have a clean FFI.

In practice you run all your process-isolated code in one process as a daemon instead of spawning it per call.

I think you're on the right track in boiling down the problem to "minimize the memory shared between languages and restrict the interface to well defined semantics around serialized data" - which in modern parlance is called a "remote procedure call" protocol (examples are gRPC and JSON RPC).

It's interesting to think about how one could do an RPC call without the "remote" part - keep it all in the same process. What you could do is have a program with an API like this :

    int rpc_call (int fd); 
where `fd` is the file descriptor (could even be an anonymous mmap) containing the serialized function call, and the caller gets the return value by reading the result back.

One tricky bit is thread safety, so you'd need a thread local file for the RPC i/o.

It is inherently a difficult process.

Firstly, true references are very hard to come by. That makes debugging hard already.

Secondly, color is not just a property of light. The same lamp, with the same spectrum of emitted light can appear to have a different color to you depending on the surroundings. During daylight a lamp might look yellow-white, but when looking at the same lamp at night when you have your normal lamps on in your home, it could look blue. That is because your eyes 'adjust' how they see color depending on ambient conditions. This way your eyes always see a white sheet of paper as white. Instead of it looking yellow under warm light, or blue under very cold light.

Things are even worse when considering the color of normal objects. The 'emitted spectrum' of an object depends on the spectrum of light that falls on the object. Take two light sources. One being 'wide spectrum' and white the other being a mix of a few wavelengths also looking white. Two objects could appear to have the same color under one lamp, but look different under the other lamp.

And the above situation is also still affected by the general color of your surroundings.

Hence it is quite hard to even say what 'color' an object has. Or even what color a light source has. Generally the approach is to standardize. For light that means specifying the 'color temperature' (and tint) of your ambient light. To ensure your eyes are adjusted to a known light situation. For the color of objects, if attempts are made to specify a color, it is specified under a specific broad-spectrum light source. But I believe generally they are defined as 'this mix of pigments'.

This means that for objects, it is essentially impossible to take the color of an object and make a second object that has the same color, unless you know how the first object got its color.

If im going to be making code that needs to run fast, works on a bit level, and isn't exposed to the world, then I am picking up C++

It's more convenient than C. It's easier to use (at the cost of safety) compared to Rust.

Perhaps this will change if I know rust better. But for now C++ is where it's at for me for this niche.

It does come with a rather insidious PFAS problem. That problem doesn't have a solution.

Yes it’s a problem but it’s very useful. Do you know of the WD40 has a lower environmental impact?

I guess WD-40 uses fluor-carbons. These wreck the ozone layer.

However, the damage from fluor-carbons solves itself. The damage from PFAS is effectively eternal. So it depends on how much you value current damage vs future damage.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact