Hacker News Reader

Comment by megous | Hacker News Reader

Let's use (C++) something not common, but not all that crazy:

    bool x = false;
    x ||= something();

How many multi-lingual programmers will remember which one of the 7 languages they know does have a boolean assignment operators and which do not without looking it up? Does that make them unprofessional?

How many do remember exact operator precedence rules for all those languages, when in practice you may need just the basic ones and use () to work around the lack of exact knowledge.

Also which version? Something not working in PHP 7.3 may be ok in PHP 8, but company wants you to code in PHP 7.3, or ES5. In practice you get quickly acclimatized to any of the languages you know after working with them for a few days or a week, but good luck remembering exact rules of any of them at any given time when asked.

View on HN

You're not mentioning or alluding to the one obvious syntax error. I don't know how to spoiler it so I will say there is an issue on the second line that, again repeating, I don't know how to call out.

And yes, I work in multiple languages.

also if you can't spot that error, you might not realize a subtle, yet important, detail about that line (if written correctly). contrary to what you might expect, it cannot short-circuit the way || does, leading to possible performance or even correctness issues.

This is very true. I hope that people are not using the short-circuit feature in a way that impacts correctness! I would have an issue with that code for trying to be too clever even if there were no bugs and it worked well.

Performance issues, on the other hand, I can see accidentally arising.

I see short-circuit for correct behavior all the time, most frequently in the format: if (pointer && pointer->member == value)

Where you want to make sure a pointer you've been given isn't null before you try to dereference it. Without short-circuit, this becomes a segfault.

Yes, the "and" pattern is common. I've seen plenty of "ensure this exists before operating on it" chains, where it even goes if ( pointer && pointer->otherPointer && pointer->otherPointer->member == value )

I've never seen someone use an "or" pattern in a non-confusing way.

That is, I've seen "and" patterns that act as a safety/early out. I fail to see the use of an "or" pattern where you want to stop executing if the first value is true (ignoring using nots to invert the logic of an and pattern, and I would criticize that).

That boolean assignment operator was addressed. Whether or not C++ has them (it doesn't) is exactly the point of that code snippet.

They do exist in other languages. ES has it in exactly that form. Java has it in the |= form, not to be confused with the bitwise OR of the same form.

Whether or not these short-circuit is not all that interesting for most boolean logic. (Though it can be useful to know if these are used as hacky error-handling and default-setting. It depends on how you read "something" whether or not that's going on here.)

> That boolean assignment operator was addressed.

Where and when? Because I was the only person alluding to it, and the replies to my post.

> Whether or not C++ has them (it doesn't) is exactly the point of that code snippet.

C++ has boolean assignment operators that operate the way that the code is clearly meant to operate. That code does not have have a valid one. Where do you think Java got them from?

> > That boolean assignment operator was addressed. > Where and when? Because I was the only person alluding to it, and the replies to my post.

The words "boolean assignment operator" are in the first sentence after the code snippet in megous' post.

> C++ has boolean assignment operators that operate the way that the code is clearly meant to operate. That code does not have have a valid one. Where do you think Java got them from?

As far as I can tell the |= operator in C++ is the same as in C, i.e. a bitwise OR operator. It works for booleans due to their bit pattern, but it's not the same. My C++ knowledge is extremely limited, so I looked it up and I may be misinformed though.

Java's |= is different for ints and boolean. There are no bitwise operators for booleans: bool1 | bool2 is a strict logical operation (that doesn't short-circuit). bool1 |= bool2 is a logical operation that will fail when other types are mixed in. int1 |= int2 is a bitwise operation. Java does not have a short-circuiting ||= operation (but ES does).

For the most part these differences aren't that important, but they do trip people up when switching between languages.

> As far as I can tell the |= operator in C++ is the same as in C, i.e. a bitwise OR operator.

This is true.

> It works for booleans due to their bit pattern, but it's not the same.

This makes less sense. A bool in c++ is just an integer value with few inputs. It is, as far as I can tell, the exact same.

> Java's |= is different for ints and boolean.

Java has bool and int as different types. There were versions of C++ compilers that just straight out had bool as a typedef of int.

C++ does not have boolean assignment operator in a sense the ||= syntax works in ES.

https://www.w3schools.com/cpp/trycpp.asp?filename=demo_oper_...

||= will not assign anything unless the LHS variable is falsy. It will not even evaluate the right side unless LHS is falsy.

|= will work the same in C++ and ES mostly (depending on types)

I'm just thrown for a loop. Why is the default to assume I'm familiar with the ||= operator in ES?

The fact that the ||= operator short circuits makes sense from an optimization point of view. I will maintain that there is no good use for the correctness (as opposed to optimization) of the code to depend on that feature.

How many of the multi-lingual programmers that know 7 languages are really good in all 7? As an interviewer and hiring manager I am more impressed of people than know 2, max 3 languages very well than 7 at an intermediate level.

I see this attitude in the corporate world and among people who are newer to programming a lot.

For skilled, experienced programmers, most mainstream languages become an implementation detail. You have to spend time learning idioms, footguns, and generally the way the language manages memory, but you absolutely can be great at 7 languages because they fundamentally do many of the same things.

I haven't hired people based on "their stack" in a long time, and it's been completely fine. Someone with skills can quickly learn your stack and be productive in it. I personally jumped on a project as a coder a few years ago having never written C# before, and I was productive in about a day. All the concepts were familiar, and the stuff I had to learn was mostly syntax.

Exactly. "If a person can drive a Honda, how well can he drive a Mazda?". Duh, just as well as Honda. And just like the natural languages, the more you know, the easier it gets.

   > All the concepts were familiar, and the stuff
   > I had to learn was mostly syntax.

This reminds me how I have learnt to program. I grew up in then USSR, we had no computers at our school but we had programming lessons. So I was introduced to all the fundamental concepts: variables, assignment, loops, control structures, etc. When I went to university I finally got access to the computer (Yamaha MSX). And then it was exactly as you say: "what's MSX Basic's syntax for this particular concept?".

If a pilot is only type-rated to fly an Airbus 320 he is not allowed to even try to fly an 737 nor a different type of Airbus. This attitude of "a car is a car, what can go wrong?" is deadly in some domains.

In my (corporate) role most of the people around me have over 20 years of experience in a very specific domain (manufacturing execution systems) and it takes about 5 years to train a new person. Having someone new productive in month is a dream for us, but it never happened.

If you can be productive in about a day, please explain why a pilot gets ATPL (airline transportation pilot license) after a minimum of 1500 hours of flight. Also please tell if you would board a plane where the pilot has 100 hours - that's an awful more than a day or even a week.

I know what a language ought to be able to do and where the usual foot-guns are. I haven't even attempted to really learn a language thoroughly since my first one (Perl—and yes, that's probably part of where my brain-damage comes from). It's all the same stuff, more or less. Understand pointers and how things like how OO systems are usually implemented, how stacks work, that kind of thing, and all the languages start to blend together.

99% of the pain in a new language usually ends up being the (often god-awful) tools, platform/SDK bullshit, and learning where the clearest path is incorrect (no no no, the official docs and tutorials say to do it this way, but everyone who knows what's what actually replaces that entire part of the language/first-party libraries with this other library developed & open-sourced by some other company, since the official way is obviously so terrible, and you just have to know that, or notice by reading other people's projects—ahem, looking at you, Android). The language itself is typically nothing.

This has worked out fine for me. It does mean I've gradually grown to hate languages that lack static typing. I don't want to remember or look up things when I can make a quick note and then let the computer remember or look it up for me. I thought that was kind of our whole thing, no? Having computers do stuff for us, when they're able?

I think you overestimate the value of being super intimate with any given language. Pretty much no language in common use is so different from the others that you drastically have to change how you express any given thing you're trying to do. Knowing concepts and when and how to apply them is more important in my considered opinion.

In my opinion, if you're hiring for an expert in a specific language, you're not hiring a software engineer, you're hiring X language developer or X language software engineer. The language needs to be explicit in the position listing and perhaps even job title. That's fine if that's what you want but be specific about it so you don't waste people's time looking for a language specialist when most people anymore are generalists that have all sorts of knowledge distributions for any given set of technologies but can most likely adapt and learn to fit your distribution of technology given just a bit of time and opportunity.

Modern development requires juggling too many technologies for most people to specialize in a single language unless their career goal is to niche themselves to that language.

Someone doing webdev fullstack for more than 10-15 years will know at minimum ES + (PHP/Python/Ruby/Java/Go...) + SQL + HTML/CSS and a few utility languages.

So at least 4. If you combine webdev with something low level/embedded, you need at least one systems language, so you're at 5 languages you need to be proficient in.

Add one hobby language or a second web backend or systems language, and you're at 6 major languages.

7 is a lot. But 5 is plausible to be proficient in for someone who switches between webdev and lowlevel stuff to not burn out, or has a FOSS hobby.

I've shipped production code in 17 different programming languages. I wouldn't say I'm proficient in any one of them, they are all just tools to solve a problem and the knowledge of language specifics comes and goes. Need to hyper-optimize a DB query on an Oracle RAC cluster? PL/SQL. Need a shader? GLSL works fine. Need a webpage? HTML/CSS/JS. Need to build a 7' long flying robot fish? C. Programming languages are just tools.

In over 20 years of working in IT I never found a single webdev-type of person that can write an efficient SQL query by himself. Yes, most are able to write a query to bring the correct result, but I saw way too many cases where the perf test on a database with the expected production volume was running in completely inacceptable times and the developer had no idea how to fix that; for each version of SQL perf-tuning is very specific.

Also proficient != expert. I met enough developers that were brilliant in their work to be convinced that 5x developers are not a myth, but they are real, while rare, occurrences. For me a senior developer in X knows the ins and outs of that X to the level that his code is an order of magnitude better in term of efficiency, performance, productivity and security. A regular developer can be just proficient, but it is not what I wrote about.

As a hiring manager for over 15 years I prefer people who can pick up a language based on the need. Good problem solving is language agnostic.

It is an option, but how fast will they be very efficient? It takes years to master something and some people, not all, need to have that mastery level.

Reply on news.ycombinator.com