rhapsodic

  > “You’re not getting anything,” he said. “You understand?
  > Nothing. You’re getting nothing.” Did he mean about the
  > car, something else, bigger? I didn’t know. His voice
  > hurt—sharp, in my chest.

Probably because some French law mandates it.

And then when school-cafeteria-style open offices became de rigeur in the startup culture, people seemed hesitant to push back on the "but collaboration!" nonsense. It looks like the overton window for that is finally starting to shift.

Yeah, but JS buys you a lot. There are certain things that you can accomplish with JS that you absolutely cannot accomplish without it.

OTOH, anything that you can accomplish with React, you can accomplish without React. I'm with the GP on that one.

Serious question: what the hell are you talking about?

>It's like the flip-side of foobar...

WTF does that even mean?

>avoid like the plague any place where all the tech questions are gotchas or obscure language features. The lead developer is probably someone you do not want to work with.

If you consider those questions "gotchas" or "obscure language features" you don't stand a chance of working with those lead developers. Their process is designed to weed people like you out.

I think, for the book I'm writing, I can build an entire chapter around this subthread. Can I quote you by name, mattmanser?

If that's what he meant, he's flat wrong. Simplicity is neither necessary nor sufficient for correctness.

I made no such assertion. That's a straw man.

But I think I can safely assume that if the patient dies as a result of the software's functioning, that software is not "correct".

You may disagree, but I think it's preferable to have a patient kept alive by an overly-complex system than killed by a simple, elegant, incorrectly functioning one.

Not to be intentionally blunt or snarky, but I think Drew DeVault's post was a bunch of rambling, hand-waving nonsense. Until today, I wouldn't have expected anyone to seriously argue that simplicity is more important than correctness. But he comes along and makes that very argument, with a self-assured, authoritative tone, but very little in the way of concrete reasoning, and to my surprise, the number of people on HN who apparently agree with him is non-zero.

How about this, for example:

The patient lives.

Seriously? That, in your opinion, is simpler?

You should probably mention somewhere that you're the author of the blog post under discussion. And it looks like you're going to make a reputation for yourself as the guy who argues that it's more important for software to be simple than for it to function correctly.

Good luck with that.

Yes. And a lot of self-described Javascript developers don't even know that. Because they've never read a book or any other document that explains those rules. And that's why they struggle, like the person in this thread to whom I originally replied, and they can't produce correct code quickly and efficiently, and they create bugs that they don't understand and can't fix, and they can't correctly understand code written by someone who actually understands those aspects of the language.

I agree that you can't memorize everything there is to know about Javascript. But if you don't know something, you have to at least know that you don't know it, so you can look up the correct information when you need it. But a lot of self-described Javascript developers don't even know what they don't know.

For example, I know that the methods String.prototype.substr and String.prototype.substring both exist and they're both used to extract substrings from a string. But I still, for some reason, unless I've used one or the other within the last day or so, I have to check the API docs to determine which one I want to use and what its parameters are. I know that I don't know what I need to know. What I will never do, is write a loop that extracts the characters I need one at a time and builds the substring from them. But I have seen where people have done that, in production code and in technical interviews. I am of the opinion (not universally shared here on HN, apparently) that that is not acceptable from a highly paid professional software developer.

And certain basic things about JS, like the ones I originally described, I think you should just know. But again, that's just me.

More hand-waving.

  > The reason is straightforward: if your 
  > solution is not simple, it will not be 
  > correct or fast.

And it still amazes me that this position seems to be controversial here on HN. There are people who have expressed unequivocal agreement, to be sure, but a significant number seem to see that stuff as obscure arcana that a developer would not typically need to know.

I don't see those examples as esoteric at all. Ignorance of those basic things can result in all sorts of bugs. If I'm paying someone a six-figure salary, I want them to know those things. But that's just me.

Not necessarily, but it puts you ahead of about 80% of all the other candidates in consideration.

That may well be the best approach in some circumstances. But do you think I'm being unreasonable wanting to hire only someone who knows those very fundamental aspects of the Javascript language?

What absurdity.

By "dealbreaker", do you mean that you will not take a job that requires you to write Javascript at a professional level? If so, kudos for walking your talk.

Based on my experience interviewing candidates with years of alleged "experience", I marvel at how many so-called professionals don't bother to learn Javascript in any depth. I've had more than a few candidates that couldn't demonstrate how to iterate through the elements of an array, for example. Or correctly give the truth value of expressions like:

  "  ";
  "";
  undefined === null;

I'm surprised at the amount of resentment this sentiment of mine generates here on HN, of all places, but it does.

Statements like this are what boggle my mind. I just don't see what's so damn difficult about native Javascript.

Yes, but my team takes the same approach that Facebook or Google takes. We don't try to shoehorn in some general framework made for some other application by someone else. We make our own, that serves our own particular needs. We are the architects and the builders of our software.

That is my argument. It's simple logic. If I can get good results without React, I've proven that React is not necessary to get good results.

I have written huge, complex, graphics-intensive applications with Javascript, and that was not my experience at all. So maybe it's not the language, but the person using it that is responsible for the mess.

> It's similar to WinAPI. Sure, you can write C with WinAPI and it's enough for simple applications.

That is a very far-fetched comparison, in my view.