19ylram49

> Seems strange to express displeasure with a corporate policy about a website by being disrespectful to unrelated individuals.

What are you even going on about? Whom have I disrespected?

Allow me to repeat myself: It’s one thing restrict offensive language but it’s a whole different beast to mandate specific language.

If, e.g., you tell me to not refer to a certain group of folks using a particular racially offensive term, that’s fine and pretty reasonable, but if you tell me that I must refer to a certain group of folks using a term that you or they chose simply because you or they said so, as far as I’m concerned, we’re slowly walking ourselves into a dictatorship. For the first option, I can simply not do anything and avoid being a “bad” person, but for the second option, I’m implicitly a “bad” person if I don’t explicitly do as told (in this case, aka, ordered).

There’s no way I could ever accept that. Nope. No way.

> Q9: Do I have to use pronouns I’m unfamiliar or uncomfortable with (e.g., neopronouns like xe, zir, ne... )?

>

> Yes, if those are stated by the individual.

Yikes.

I’m 100% in support of all gender identities, sexual orientations, races, etc., and I’ll fight for everyone’s rights and well-being, but this is insanity.

It’s one thing restrict offensive language but it’s a whole different beast to mandate specific language.

Nope. Nope. Nope. I’m not doing it.

Sorry not sorry.

> The fact that a language compiles down to C doesn't mean it compiles down to efficient C.

Where do you see me claiming otherwise?

> At the simplest level, the compiled code could add a bunch of unnecessary function calls and pointers and other forms of indirection that wouldn't be present in hand-written C.

Again, why are you telling me this? Please quote where I claimed otherwise.

> But for a more extreme example, you could also compile an interpreter or VM to C, and it would still be much slower than the equivalent hand-written C code.

The more that I read your response, the more that it seems that you’re debating yourself, because I’m not sure why you’re telling me this. You started your response by telling me that I’m “missing the point” when, in reality, you seem to have not even read my point. My main point was the following:

> If the code from which the resulting machine code is compiled is C, then it’s objectively “as fast as C” […] your resulting program will perform as fast as a C compiler [worth its salt] can get you.

This is true. I made no claims re efficiency; “as fast as C” and “as fast as efficient hand-written C” aren’t interchangeable claims. Forgive me for not assuming efficiency, because I’ve seen a good amount of inefficient hand-written C code in my years.

> This is why "as fast as C" typically refers to normal, hand-written C code—even though there is no formal definition for what "normal C" looks like, it's still a useful description.

Says who though? I’m professionally experienced in C, and as is very clear by this discussion, it’s down to individual interpretations.

> "As fast as C" would commonly be interpreted as "a program written in it will be as fast as a well-written C equivalent"

That’s your interpretation, which is fine, but the objective meaning stands. Even the idea of “well-written C” is, in my experience, fairly subjective amongst C programmers.

I’m not sure that I understand your argument. If the code from which the resulting machine code is compiled is C, then it’s objectively “as fast as C” … because, at the end of the day, it actually is C. Being “as fast as C” means that your resulting program will perform as fast as a C compiler [worth its salt] can get you.

Your comparison to machine code (or human readable assembly code) is less useful in that such a statement means very little until one knows how said machine code is being produced (e.g., manually, from a IR, etc.).

What you said here was literally my point. Maybe you misunderstood me?

Much needed perspective in the age of overly dramatic headlines and straight up misinformation.

> as fast as C

I mean, it actually is C, since the code is transpiled to C.

Those are valid questions when evaluating an unknown technology. How could anyone consider this trolling? Not to digress but have we become too sensitive?

On the contrary, I feel that the stylistic [and sometimes semantic] separation of primitive and boxed types in languages (e.g., `byte` VS `Byte` in Java) improves the developer experience, in that I can very quickly dissect the type of value that I’m dealing with when reading the code.

To the creator:

I actually just went through the trouble of resetting my Product Hunt account (I haven’t been on there in a long time) just to give you that upvote!

Thank you for this! Cheers.

My popcorn got cold. This train-wreck is taking too long. The suspense is killing me.

Now, wave at your camera to the lovely NSA agent tracing you.

Yikes.

This is part of the reason why I prefer to never let any services/apps/etc. save my bank/card details. If there’s not an option to save the card details that I can uncheck, 9x out of 10, I reconsider the transaction.

The assumption here though is that the services/apps/etc. that do provide the option actually respect it; in other words, unless you use fake/virtual card details (not entirely reliable, in my experience), you can’t be 100% sure that you’re safe either way, which sucks.

Yes, that’s a significant catch, but this is some good work nonetheless.

That said, I’d hope that someone using a C library like this wouldn’t just start using it without understanding the potentially non-trivial consequences/side-effects of that decision.

Whoever you are, seriously, I love you for this commentary. Thank you.

> Set yourself free, and cast off the 24/7 toxic work culture of SV that's keen on producing useless shit for problems no one has. Don't let yourself be consumed by the entropy emamanting from startup land. You don't have much time on Earth. Don't give it to unworthy efforts and assholes.

I’m glad that someone said it!

I’m still stuck on the Chick-fil-A part. Haha.

> But...I think most of us can all agree that consumer data protections are highly lacking.

Yup. Especially here in the U.S.

Bingo. Environments like that seem to be the new “wave” now. I can’t stand them! Maybe it’s just me but I don’t understand how anyone can get any work done in those settings.

Many a time, I’ve hired software engineers without degrees over software engineers with Ivy League or top-10 school CS degrees, and I haven’t regretted it even once.

Nowadays, I don’t even put education “requirements” in job descriptions, and even if you mention your school during an interview, I don’t really care for it, to be quite honest. At the end of the day, our real technical/programming interview (no whiteboard nonsense) will tell me the things that I need to know about your technical abilities.

I remember interviewing one candidate with a CS degree from RIT, and I honestly spent a good portion of the interview genuinely feeling like this poor individual just flushed the tuition $ down the toilet, because he was just failing the interview miserably! Funny thing is, he knew a lot of theory, but when it came time to produce, it didn’t work out too well for him. (He could use whatever set-up that he preferred, Google usage was obviously allowed, he was given space to work without disruption at various points, and most importantly, the problem was a legitimate problem that we had to solve at the company.)

All of this to say: Just apply! If you have the skills and a company doesn’t give you a chance because of a stupid degree requirement, they aren’t a good fit for you and don’t deserve you! Cross them off of your list, move on, and apply to another company.

> By the senior levels you can't really tell the difference between someone with or without a CS degree. Experience definitely beats textbook knowledge after a couple of years.

Agreed. Absolutely correct!

I’ve been wanting to set up something like this, but I’m too lazy. It probably wouldn’t even take that long to set up.

Lol. That’s the spirit!

To be honest, I understand the bit of backlash that I’ve received here and I think it’s well-deserved since I should’ve worded my statement better. Thank you for your comments.

You all are correct re firing someone over mistakes and seemingly trivial matters. I was mostly referring to software engineers who make impactful decisions without good reason and/or without properly assessing the trade-offs.

I think it’s fair to say that we all want performant software, but at the same time, if I have a software engineer on my team who can’t back their decisions with some form of data and/or understanding of the trade-offs, unless they’re at the junior level, they’re not the type of software engineer who I want on my team.

I said “performance reasons” precisely because, over and over and over again in my career, I’ve watched software engineers commit unreadable messes of code that were clearly premature optimizations and/or optimizations where the performance gains weren’t significant enough to justify the costs of the unreadable and hard-to-maintain code enabling them.

I once had a software engineer unexpectedly spend almost a week rewriting a critical part of a Java codebase using the JNI because he thought it’d “make it faster” — and it did — but then all types of new native code-related issues ensued that cost the company, including a major security vulnerability that was just impossible before. On top of that, it turned out that the performance gains that we noticed were mostly significant during the startup period of the JVM, so it really wasn’t worth it. And this was a very brilliant software engineer, but he was consistently making poor decisions like this. To be clear though, he wasn’t fired! I just use that story as a realistic example. (Part of me still thinks that he just wanted to learn/use the JNI and that project seemed like the perfect target. Lol.)

But yes, it’s more complex than simply firing individual contributors for sure and I regret wording my statement that way, but I hope you all can understand the real point that I’m making.

Edit: I’d like to point out that, in my anecdote above, in hindsight, if anything, I was probably the one who looked incompetent when the suits started asking the expected questions re the sudden set of new issues, because I did my best to shield that software engineer from them (or at least I’d like to think that I did). I know the feeling of messing up at that level and I knew that he was most likely already beating himself up, so I couldn’t just let him take the fall, or worse, throw him under the bus. These tend to be complex situations in real life!

I mean, I get it, but I think performance is overrated in this particular case; unless it’s a significant and/or very noticeable difference, stick to object literals, please. I’d probably fire someone if I started to see `JSON.parse(…)` everywhere in a codebase just for “performance reasons” … remember, code readability and maintainability are just as important (if not more).

Very neat. Thank you!

This is why I dig HN. To the creator: Thank you for creating this!

Yikes, my guess is that the linked project most likely isn’t being used for good.

This looks great. I think I might just give it a go!