HN user
I remember upgrading from a 4x to 24x, and being excited for the much faster data transfer rate. What I didn't anticipate was the fact that it sounded like a jet taking off when it spun that fast! I figured out how to ratchet it down to 4x and kept it there unless I knew I'd need a fast sustained rate for something like copying hundreds of megs. It wasn't worth the noise for smaller transfers.
I switched to Vivaldi as a result of the removal of this feature from Firefox, because Vivaldi still allows you to choose this behavior. Are there other Unix browsers you're aware of that allow you to disable click-to-select? It'd be nice to at least have some options, although I'm generally happy with Vivaldi.
At least Audacious (in its audacious-plugins package) as well as Qmmp support chiptunes via the Game_Music_Emu library. I'd imagine many other plugin-based players for Linux/Unix have support as well.
In C, it's perfectly legal to do this:
struct S { ... };
typedef int S;
I don't really think changing this in C would break all that much code, but it's definitely not backwards compatible.
If you're at all interested in digging through the Zork code yourself, you no longer need to know Z-machine assembly: the source code for most Infocom games was released/leaked a few years back, and is available here: https://github.com/historicalsource/
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....
As of libpng 1.6.0, a so-called "simplified API" was added, which does not use setjmp/longjmp. A while back I had a C project using the old API, and I converted it to C++, and the interaction of setjmp/longjmp with exceptions was giving me headaches. I switched to the simplified API, and it was a breeze. So much less code, and no hacky C "exceptions". If you can require libpng 1.6 or newer, it's worth looking at the simplified API, if it supports your needs.
It's described here: http://www.libpng.org/pub/png/libpng-manual.txt
There is no reader mode.
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
Am I correct in saying that functions written in C do not get pre-empted like Erlang functions? If that is true, you could write computationally intense code in C within a BEAM app.
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).
I prefer it because it means less fiddling with tabs/the back button. Plus you can collapse comments.
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.
C++14:
auto p = std::make_unique<int>(5);
auto q = std::move(p);
std::cout << *p << std::endl;
Type annotations. They're the sole reason we moved from Python2 to Python3, and it was completely worth it. With mypy, we now have at least some semblance of a type system and type checking, which is a huge win.
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.
The sqlite3 module that comes with python is terrible when it comes to errors. For example, if OperationalError is raised, it could be any of the following SQLite errors:
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.
Anecdotal data to agree with type annotations:
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.
If the interviewer is truly confrontational (as in, you're being asked something like "why did you do stupid thing A when thing B is clearly better"), then you're better off not working there.
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.
Go allows pointers to be sent over channels, so it's up to you to make sure you send copies of data to prevent problems. So no, I'd say Go isn't doing that; or rather, it does require message passing but there's a huge loophole which means you basically can share mutable state unsafely.
Rust, on the other hand, is much closer to what you're describing.