That doesn't mean you can't debug. You can step through the code step by step in the debugger, or add more and more logging around the bug, until you figure out which expression has a meaning unintended by its author. But that means that, if we're working in a language someone knows well, you're likely to spend hours debugging a problem that they can just see immediately when they're reviewing a merge request. That's an orders-of-magnitude difference in productivity when it's important for code to be correct, precisely due to what you call "precise syntax memorization".

Most of programming isn't writing code. It's reading code.

It's possible to go overboard with this. There are other skills that are more important than being able to look at some code and immediately see what it means. There are excellent programmers with severe dyslexia who will just never be able to do this. But it's foolish to think that gaining this skill is "a waste of time" for those who can.

There are languages I've used where I don't know the syntax that well. PHP, Ruby, x86 assembly, OCaml. There are languages where I know the common syntax well, but there are plenty of obscure corners of the syntax that I don't: C++, Perl, bash. But I regularly switch between C, Python, and JS, and I'm pretty confident that I know their syntax, as well as numerous other languages like Tcl, Lua, Prolog, PostScript, and arguably Scheme and Elisp, which I don't use regularly but still wouldn't have any trouble spotting syntax errors.

Luckily I never fucking ever have to do that in my actual job. If I did, I might well get good at it. Since I don't, I... don't. I also haven't gotten much better at driving semi trucks or framing a wall, in my over-a-decade career writing software. Go figure.

Last time I saw one of those test-ish pieces of code, though, an IDE+static analysis would have caught about 1/2 of the problems; the other half required actual thinking (not statistical pattern matching, aka AI): "don't trust user data, that should not go there even though the call signature matches, you're holding it backwards."

Good type systems do this, although it's beside the point.

The point I was making is that the IDE remembers unimportant things so that my only concern is the actual thinking part. It abstracts away the minor and sometimes very important syntax differences.

IDE tools are great performance enhancers, but they can also be crutches.

I would always expect a professional software developer to be able to parse some code on a page and point out its syntax errors (as well as suggest edits).

edit; here I am thinking about something more substancial then just a missing ';' or a lack of a closing "

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

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.

And yes, I work in multiple languages.

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

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.

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).

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.)

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?

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.

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.

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)

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.

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.

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

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.

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?

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.

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.

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.

Yes, they are absolutely crutches. All great tools, libraries, and abstractions are crutches. I want programming to be easier for myself and my employees.

The only problem with a crutch is that you might end up not having it when you need it. That's not an issue in this case.

> here I am thinking about something more substancial then just a missing ';' or a lack of a closing "

The original example that I was responded to was about an interviewer who expected their code to compile. That would include incredibly pedantic things.

For example, if you're the kind of person who uses single quotes in JavaScript and then you're suddenly writing a different language where '' is different from "" and `` and $"" and whatever, you could easily make an unimportant mistake that prevents compiling.

When did I claim that the IDE absolves you of needing to know the syntax?

It doesn't. But between autocomplete, hinting, linting, and any other static analysis, it makes it close to painless to switch between languages without making horrifying mistakes. The top-tier JetBrains IDEs (IntelliJ and Rider come to mind) will even tell you ways to make your code more efficient or modern, like changing a bunch of if/else to pattern matching.

Why should I have to remember the full truthiness table of JavaScript? Why should I have to remember what all the different string delimiters do in every language? It's not important. My IDE can (and does) know that I'm trying to do some kind of string interpolation and will just fix it for me.

I remember thinking what you're writing about there, that there's a lot of people to be filtered out, and that good candidates wouldn't be offended.

So we had this simple two-part quiz question for people, starting with "what is the expectation of a dice roll?". Amazingly a lot of people can't figure this out.

But also a lot of people know the answer immediately and will wonder WTF you are asking such a simple question for. I remember this one lady who interviewed with my firm, the look on her face when she realized we weren't asking anything complicated. You could just tell she thought we were a bunch of amateurs, and she'd better be on her way to see some other proper hedge funds.

But I think the point in this thread is the Google question about Linux inodes was actually part of a pre-screen interview done by an outside agency.

In contrast, I've been stuck in a giant multi-language integration-fest, and... well, there are definitely languages on my resume that I would not be comfortable being pop-quizzed on, simply because I've been using others for the past two years.

_Can_ I make sure the code is 100% correct before even compiling? Sure, but I'll spend an hour checking every detail, while intellisense does it while I type.

Let's turn this around: if I were interviewed by someone who flagged down my code for missing a #include or lambda capture (both very easy mistakes to make), I'd know that the people I'm interviewing with are idiots with no understanding of the thing they claim to be testing me on. Would I want to work there? Nope.

But yeah, I think I've seen questions like that for an intern positions. It's basically a "have you ever seen this language?" to weed out people quickly.

It's not that. People who constantly use multiple languages in an IDE will not be able to point out most syntax errors outside the IDE. So it's not a "have you ever seen this language" filter.

But I'm curious what position would this question make sense?

I was once asked a similar but better posed question: I was given some code and asked what I'd point out if asked to do a code review on it.

And the code had loads of things wrong with it, from bad variable names and incorrect comments, through unit tests that didn't have any assertions and loops that weren't actually loops, all the way to choosing a non-secure random number generator in an application that needed a secure one*

In other words, it was a test of my ability to code review, with some glaring issues to give me some easy marks and set me at ease, and some subtle issues where talented people could really set themselves apart. It was fair and relevant to the job because I was presenting myself as a senior programmer with lots of experience doing code reviews and coaching junior developers.

It's possible trinovantes's interviewer intended to give the same sort of test - but either didn't explain the question clearly enough, or trinovantes misheard or misremembered.

* A bug right out of puzzle 94 in 'Java Puzzlers'

At a different interview, this one with Microsoft, the lead engineer showed me a page of actual code from their app and asked me what I thought. Luckily the bug instantly leaped off the page to me, although many people would not see it. That was a good way of proving that I have a useful ability, and a better use of time than whiteboard coding or quizzes. I got the job and they were glad they hired me.

Coding is a mostly solitary activity that you probably don’t want candidates spending more than ~60 minutes on, ideally on something that resembles the actual day-to-day instead of sucking all the Leetcode possible out of them. Even just quickly pair programming on something nets you more data points in the same time.