121–130 of 211 posts
Earlier quoted context omitted.
Assuming those variables are all booleans why wouldn't it be?
They're not booleans in ruby, python, js; they're objects that can be null.
So the point of the comment is moot...
The skills cited in the article are: 1. Understanding how the language works. Additionally understanding how the language infrastructure interfaces with the computer. 2. Anticipating problems. Prefer solid foundations over veneers that appear to get the job done. 3. Organizing and designing systems. Essentially, SOLID. Two things on this: First, bad code often results from conflicting goals. Moving goalposts and on t…
>The temptation will be to blame the audience when in fact the failure lies squarely with the programmer doing the speaking or writing. This is a popular claim on HN that I don't think is true. Where does the boundary end? Is it my fault they can't understand my program if they don't know any code at all? What about if they're a Python programmer hired onto a Java project? The point is you should make a good faith ef…
But it’s not. If you want your message to be understood, and the listener is making a good-faith effort but doesn’t get what you’re saying, the onus is on you to communicate in a way the listener understands.
Poor programmers are optimistic: * computers will always run my code fast * infrastructure problems will not happen * our team will always have plenty of time to understand my code * users are not malicious and the libraries I depend on are not malicious * I will always have to plenty of time to diagnose and fix problems in this code The author covers some of that. But you can care about those, and still be a poor pr…
completely agreed, just had a long conversation with a junior engineer about how adding a cache would not solve a complex architectural problem and just add more complexity.
> All those are indicators of coupling unrelated ideas together.
once useful tool i have found is using automated tools to spot indicators like these. In java using checkstyles cyclomatic complexity checks and class fan out is a strong indicator (not proof though).
This article says more to me that the author(s) are inexperienced themselves rather than shed any light on the practice of software development. I'm imagining some recent boot camp graduates attempting to conflate their months of programming experience into something more than that. "Hey old dudes in company I just joined, I found some things I think are basic so I'm going to write an article to indirectly shame you…
>I believe OOP and relational database get a lot of flack because programmers tend to be bad at design, not because they are broken paradigms. OOP has Fundamental and Intrinsic problems that can be described in a very concrete way. If you believe OOP gets a lot of flack just because programmers are bad at design, then you are the one that is also bad at design. I will say this, OOP is bad for many and most design pro…
It's very easy to implement actual actor model style OOP with procedural code. You can get most of the benefits by using a message bus.
Earlier quoted context omitted.
They're not booleans in ruby, python, js; they're objects that can be null.
null (or None) is still a valid Falsey value, and in both examples isDone will be a boolean (strict) value, as it is the result of a boolean operation (and). So the point of the comment is moot...
Maybe give Linus a shout and ask him to call it a day. ;)
Earlier quoted context omitted.
I guess because inside of a then() you can simply return the success case and throw the error case, no need to create a new Promise and call the resolve/reject functions.
Was trying to think of exceptions to this when I read and and could only think of one: When you need to wrap a callback API with unusual callback arguments, where a `promisify` like helper won't work. Then again, I still feel the wrapping function should be defined outside of the `then`, as it feels like this is a separate utility to the work being done in the Promise chain.
Earlier quoted context omitted.
They're not booleans in ruby, python, js; they're objects that can be null.
null (or None) is still a valid Falsey value, and in both examples isDone will be a boolean (strict) value, as it is the result of a boolean operation (and). So the point of the comment is moot...
Python: None and None -> None