Baku is actually slightly further than Aktau, according to Google maps.
2,241 karma · joined May 2, 2017
> how would we know if the calculation was completed before the exception was thrown without adding another 8 lines of boilerplate?
You can't, exceptions or not. With exceptions, you need try..catch blocks. With return values, you need ifs.
But with exceptions, you have an option of not handling an error where it originated, without completely ignoring the error.
With error results, you can handle the error (which usually means just returning it to the caller) or ignore it (potential bugs). In languages with not-so-strong typing, it can be very easy to ignore the error. In languages with strong enough typing, you must handle the error. This can be made nicer with syntax sugar, but still leads to boilerplate. This also has an unfortunate consequence of more branching in the generated assembly, which can lead to poorer performance on the "happy path". Exceptions also have cost, of course, but it's geared more towards making the happy path fast and exceptional path slow, which seems like a better tradeoff in most cases.
> If both the display() and log() functions might throw IO exceptions, then how would we know whether or not the error was logged
But without exceptions, your code is simply ignoring any potential errors in display(). And in log() for that matter. If they threw exceptions, it would be impossible to just "swallow" an error silently.
> In conclusion, we don't know with certainty which path was taken through the code's execution, and this is tantamount to non-deterministic behavior.
I would disagree with that. People sometimes see exceptions as somehow "breaking" the program or leading it to an inconsistent state, but that's simply not true.
All you need to realize is that...
1. Every line can throw an exception unless proven otherwise.
2. You don't need to handle an exception close to where it was thrown in most cases. Corollary: you shouldn't use exceptions for control flow. If you notice that your callers use try..catch directly around your function, that might be a sign you should use return values, not exceptions. Return values are not forbidden in languages with exceptions!
3. But you do have to dispose of unmanaged resources. This is probably the main sticking point and does require some discipline.
...and suddenly exceptions stop being awkward and become quite nice to work with.
That’s not non-deterministic. It’s just not statistically typed.
- The Death of Intel: When Boards Fail
https://www.fabricatedknowledge.com/p/the-death-of-intel-whe...
https://www.intc.com/financial-info/income-statement
So whatever their problems are, throwing more money at R&D is unlikely to solve them.
Also, Intel has committed to not doing stock buybacks and has stopped the dividends completely. They may resume at some point, but it's unlikely to be soon.
I disagree with that too. Did I ever say otherwise?
I do believe, however, that there are problems for which a SPA offers the best trade-off. Not the only solution, but the best trade-off.
> This is an orthodoxy which people buy into but there are always a few different approaches possible.
Like the orthodoxy that "nobody needs an SPA"?
> What do SPAs actually offer which is unique?
Interactivity. Good luck keeping your focus or scroll position while reloading a page. If done carefully, performance can also be on that list, though I agree it is often not done carefully.
> Just because you want to load code and data dynamically doesn’t mean you need to buy into SPAs
Agreed. Though you can load both code and data dynamically from a SPA, if you need.
Perhaps our definitions of a "SPA" differ? SPA is when you don't do reloads, hence "single page". But there are many ways to do that, some of them involving React.
Everything is a trade-off, and SPAs offer a trade-off that is right for some cases and wrong for others.
Indeed, if your needs are more static, a SPA is probably not a good solution. But if you really do need a SPA, React is a sensible choice and can perform well assuming good engineering.
The tragedy of commons is that if everyone bought a lighter car, everyone would be safer, not just the drivers but pedestrians and cyclists as well. Especially if "crash compatibility" was regulated and enforced.
That's, at least, how it seems to me while not actually living in the US - feel free to let me know if I'm completely off.
Some early BLOB implementations had performance problems, which is where this notion that "you shouldn't store files in BLOBs" seems to come from. But modern DBMSes have fast BLOBs, especially if used properly through their streaming API (don't materialize the entire file in memory!).
We have a system in production that stores millions of files in BLOBs, some of them reaching multi-GB sizes, being accessed across the globe (a big enterprise company) by thousands of engineers, and never had performance problems with BLOBs.
pgPDF: The actual PDF parsing is done by poppler.
Poppler is a PDF rendering library based on the xpdf-3.0 code base.
Xpdf is based on XpdfWidget/Qt™, by Glyph & Cog.
XpdfWidget is based on the same proven code used in Glyph & Cog's XpdfViewer library.
The XpdfViewer® library / ActiveX control provides a PDF file viewer component for use in Windows applications.
Any licensing complications? Is it cross-platform? XpdfViewer seems to be propriatary and Windows-only.
Anecdotally, when I write code, I don’t “talk in my head”. The structures that I have in my brain are in fact difficult to put into words, and I can only vaguely describe them as interconnected 3D shapes evolving over time, or even just “feelings” and “instincts” in some cases.
The code that comes out of that process does not, in fact, describe the process fully, even though it describes exactly what the computer should do. That’s why reading someone else’s code can be so difficult - you are accessing just the end product of their thinking process, without seeing the process itself.
"There are only two kinds of languages: the ones people complain about and the ones nobody uses."
Here is the full(er) quote:
Postgres will happily add padding to the underlying data in order to make sure it is properly aligned at the physical layer. Having the data aligned ensures faster access time when retrieving pages from disk.
SQLite made the opposite tradeoff.
Having the data aligned ensures faster access time when retrieving pages from disk.
Only after these bytes have reached RAM does the byte-level alignment play a role, because CPU works slower on misaligned data.
The article itself then goes on to illustrates the above (and seemingly contradict itself):
SQLite does not pad or align columns within a row. Everything is tightly packed together using minimal space. Two consequences of this design:
SQLite has to work harder (use more CPU cycles) to access data within a row once it has that row in memory.
SQLite uses fewer bytes on disk, less memory, and spends less time moving content around because there are fewer bytes to move.According to Investopedia:
"From January 1994 to June 2023—through both bull and bear markets—the passive S&P 500 Index outperformed every major hedge fund strategy by over 2.8 percentage points in annualized return."
In recent times, multi-chiplet architecture has added its own layer of complexity to that process.
See also: OSAT.
TSMC's oldest plant still in operation (Fab 2) started production in 1990. So far, the only fab they have closed is Fab 1.
Reference: https://en.wikipedia.org/wiki/List_of_semiconductor_fabricat...
Admittedly, leading-edge process is where all the excitement it, but the old fabs are fully depreciated and can remain profitable for decades.
How rare, though?
QuickSort has fundamentally unpredictable branches, and it’s a pretty widely used algorithm. Binary search, B-trees also come to mind.
UI = f(state)
The problems come when you modify state in response to rendering the UI. This seems deceptively natural (and in fact seems encouraged by on-line tutorials), but leads to "spaghetti fetching" when composing components together - it creates a "feedback loop" that modifies state just because some component happens to mount, which can then modify state further, then cause further mounting/fetching etc...
A better approach is to treat fetching as an explicit state change. If user clicks on a button, you do the fetch and modify the state. If that causes some components to be mounted - so be it, but does not cascade any further.
Microsoft prioritizes userspace compatibility, but their driver models have changed (relatively) frequently.
Obviously, this has ramifications for data write perf, but may well be worth it depending on the use case. Technically, you could also make the integer alternate (and leave UUID as primary), but that may not de desirable for clustered / index-organized tables (for DBMSes that support them).
If that’s the case, I’ll hazard another guess: you lived in an environment where you couldn’t just go out and play whenever you wanted?
I might be completely wrong in my guesses, and I apologize if I am. But I strongly believe that all kids are naturally predisposed for physical activity, and it’s the duty of the society to let them do that in an easy and safe way.
Sorry, this does not make much sense. Why would you need a timing attack to read memory from your own address space? Just a regular code execution exploit should do it.
Here, I found the relevant info (that I was too lazy to find before I posted my first comment, apparently):
> While programs are typically not permitted to read data from other programs, a malicious program can exploit Meltdown and Spectre to get hold of secrets stored in the memory of other running programs.
> In the post-Spectre world you must have site isolation. The JS for a site (roughly, eTLD+1) must have its own OS address space separate from other sites.
Wasn't the whole point of Spectre/Meltdown to read the virtual address space of a different process?
In fact, the choice is between natural and natural+surrogate key.
- If you have a natural key, you have to enforce it, otherwise you risk data corruption. The question is do you also need a surrogate key? Sometimes you do, sometimes you don’t.
- If you don’t have an obvious natural key, then your surrogate becomes meaningful. You have to use something to distinguish between two “equal but not identical” rows, so you end-up showing the surrogate in the UI etc. In other words, it is no longer “pure” surrogate.