31 karma · joined August 26, 2014
struct S { ... };
typedef int S;
That's not valid in C++ (so would be a breaking change in C, if it were to adopt this).I don't really think changing this in C would break all that much code, but it's definitely not backwards compatible.
It's written in ZIL, which has a somewhat Lispy feel (for a bit of background, see another post by Plotkin here: http://blog.zarfhome.com/2019/04/what-is-zil-anyway.html). Infocom's own internal documentation for ZIL is here: https://archive.org/details/Learning_ZIL_Steven_Eric_Meretzk....
It's described here: http://www.libpng.org/pub/png/libpng-manual.txt
There is, but as far as I know it's not something you can manually toggle. On sites which Vivaldi deems can be shown in reader mode, you're prompted to switch to it. I don't know what criteria it uses to determine that.
It has to be enabled: Settings→Accessibility→Simplified view for web pages
They cannot be pre-empted, but they must also return quickly, or risk causing lots of problems (see https://erlang.org/doc/man/erl_nif.html for slightly more detail on what this means). As such you can't just write some big function in C to do number crunching.
The NIF documentation mentions some ways around the problem, but all of them take some effort, or have tradeoffs of some sort. I was really excited when “dirty” NIFs were introduced, which can tell the BEAM that they'll run for a while, thus appearing to allow for long-running NIFs with no extra work other than setting a flag. However, it turns out that the BEAM just spins up N threads for scheduling dirty NIFs, and if you have too many such NIFs, too bad, some won't get scheduled till the others have completed. In retrospect it should have been obvious that there couldn't be a silver bullet for this problem, because it really isn't easy.
Erlang may well be my favorite language, but as you imply, it's just not going to be the right approach for everything: in my experience, it's absolutely fantastic in its niche but that niche is quite small. I think that's fine, though. For me, where Erlang does make sense, its concurrency approach makes it unbeatable, and I'll live with the performance tradeoffs. It turns out that basically all the NIFs I've had to write were just to gain access to functionality that Erlang doesn't expose (e.g. network namespaces on Linux, which are supported now, but weren't when I needed them).
But by default it's very difficult on my eyes due to the low contrast, so to make it at all usable I make use of a Stylish script to fix the text color.
auto p = std::make_unique<int>(5);
auto q = std::move(p);
std::cout << *p << std::endl;
Segfault using the “safe” C++ features. I'm a fan of modern C++, but it's not safe (in a Rust sense) even if you stick to C++11/C++14 features.Unicode support is vastly improved.
Finally there are have specific exceptions like FileNotFoundError so you don't have to catch OSError and then check errno. I got so tired of that.
No more old-style classes, which means you know you can use super(), which is now less annoying since you don't need to “remind” Python which class you're in.
Lots of other small changes, most of which do lead to improvements, however minuscule. I would argue that unless you are must use a Python2-only library, just go with 3.
SQLITE_ERROR, SQLITE_PERM, SQLITE_ABORT, SQLITE_BUSY, SQLITE_LOCKED, SQLITE_READONLY, SQLITE_INTERRUPT, SQLITE_IOERR, SQLITE_FULL, SQLITE_CANTOPEN, SQLITE_PROTOCOL, SQLITE_EMPTY, SQLITE_SCHEMA
How do you know which? The only thing you can do is convert the exception to a string and compare error messages. That's absurd.
How about IntegrityError? That's either SQLITE_CONSTRAINT or SQLITE_MISMATCH. Which one? Compare strings again.
If you need to use SQLite with python, apsw actually converts errors to discrete exceptions.
We have a fairly large Python codebase here. I've been wanting to move away from Python for a whole host of reasons, a top one being that it's dynamically typed. However, when mypy was released, that was enough of a reason to port from Python2 to Python3. Now we have a mostly-annotated codebase, and I'm a lot happier.
We'll probably move away from Python eventually (I still don't think it's an especially good language, and type checking with it will never be as useful as with a language where it's built in and required), but it's not as pressing of a concern.
I think type checking turns Python into a bearable language.
However, I'll often ask questions similar to those you posed (without thinking/telling the candidate he's useless, of course).
Let's take the "why not Java 1.8" example. If I asked you that, and you were prone to being defensive, you might think I'm attacking you. In reality, though, I'm just probing for more information. Are you familiar with Java 1.8? What would be the benefits/drawbacks of using it? If you can explain why Java 1.7 is fine for your project (I don't know Java, but I assume there are good reasons not to use the latest version), then I'm satisfied.
Basically, my goal is to learn as much as I can about you. This often involves direct questions. When I'm asking direct questions, I'm not attacking, and I suspect it's the same for many interviewers.
Rust, on the other hand, is much closer to what you're describing.