Both the EU and Iceland have proportional electoral systems, with districts having several seats. But the way seats are allocated to the districts in both systems isn't strictly proportional, with less populous districts having fewer electors per seat than the more populous regions.
At a previous job, I debugged a close relative of that exact problem: sorting list views was very slow when you wanted to sort on a column with very few distinct values in a large table. The culprit was of course a quick sort degenerating to n squared performance.
I once made a flight by the slimmest of margins possible (the gate crew stopped closing the check in because they saw me sprinting through the terminal hall), because of this and only one hour difference between where I started from and where I went.
As a group, programmers do seem quite attached to monospaced fonts. For my IDE I have actually gone (I think) even further than you: I use a proportional (serif even!) font for all my programming, not just prose writing. It took a bit of getting used to, but now I've come to much prefer it over monospaced fonts.
The course description and the car is modern, but would this also be helpful for understanding a classic car? I’ve inherited a classic Jag which is great, but being reliant on others for understanding and repairs is sometimes a bit limiting.
I actually replaced my programming fonts with serif fonts in all languages after a few years in Smalltalk. It’s not quite as good in a brace language like Java, but for Python it works really well, I find.
Being human readable is nice, but compared to something like lichess’s Huffman based encoding, it’s something like an order of magnitude larger than needed. If your reference base is several million games, that really adds up.
Carbon dating can help, since it gives an upper bound on the age (a terminus post quem if you want to be fancy; the manuscript wouldn't have have been written while the parchment was still hide on a cow) and the pages would probably have been written on fairly recently after being turned into parchment. Of course parchment can have its initial contents scraped off and reused, or overwritten which complicates matters. But as you say, an expert palaeographer can probably eyeball the age of a manuscript quite often, since the style of handwriting is largely dictated by both time and place. For example, to my (untrained) eye the hand in the manuscript in the article looks a bit like an insular script[0], which is specific to the British isles at time in question. An Italian of French manuscript of similar age would have a different script. And as others have pointed out for some manuscripts record sleuthing can find stuff surprisingly far back.
But that's the thing: dereferencing an invalid pointer is undefined behaviour, which means the compiler is allowed to assume it never happens; a C program executing undefined behaviour is _invalid C_. Thus, any time you dereference a pointer you also implicitly proimise the compiler that this pointer will _never_ be an invalid pointer. Same with signed arithmetic: you are telling the compiler that your arithmetic is guaranteed to never overflow.
Whether this is a good or bad thing is of course a legitimate (and good!) question, but for writing C today that's how the language is specced and a reality the programmer needs to take care to avoid, just like a bunch of other things that C leaves to the programmer like remembering to clean up allocated resources when they're no longer needed.
We’re considering it for a use case at work. In our case, it’s to allow a team of analysts to be more or less self sufficient in publishing some data for external consumption without needing to deal with deployments and the like. This way, changing requirements can be handled by the analysts themselves by updating the tables or views published by PostgRest, without needing to think about changing a REST service and such.
In a previous job I worked on the case management software used by the Norwegian police. It was first put into production in ‘96, based on an earlier system from I think ‘94 (thus the Smalltalk). All criminal complaints in Norway pass through this system.
As a developer, I found the system really nice to work on, despite an antiquated Smalltalk implementation at the base (end of lifed in ‘99). Since the IDE is integrated into the running application, the development process was extremely smooth for a desktop application like that. But the process was an acquired taste, not all the developers got into the groove.
Ablaut is unrelated in this context though. These vowels arise from a much more recent sound change (conveniently called umlaut, because it gave rise to a bunch of umlauted vowels).
It looks similar, but the semantics are quite different. A Raku grammar is a recursive deacent parser, but this is still a regular expression in the end.
It's kind of depressing, honestly. Smalltalk is amazing future technology from the 1980s, and here we are in 2022 with our fancy IDEs still dropping off our (metaphorical) punch cards for batch processing.
From 2016 to 2018 I worked on a complex case management application that was implemented in Smalltalk. It ran on Visual Smalltalk Enterprise (last updated in 1999! But the app was first put into production in 1996...) which is really quite crufty compared to Pharo, but the development experience still blew me away. The Smalltalk way of working takes some getting used to, but once I got into the swing of it, it was the the smoothest development process I've had: you log into the app and do your stuff. Poke some bugs, try to reproduce them, maybe find some completely unrelated error, and whenever you update the code you just save the methods and pick right back up from where you left off.
I once had occasion to implement a sort algorithm in anger, on a platform _with_ a standard library no less!
The project was written in SmallTalk, running on a very old implementation (last updated in 1999 I think) and we had a problem where clicking on column headers in the UI to sort would be very slow if most of the values were equal. The problem was that the standard library array sort was quicksort (which also meant that sorting on several columns broke since quicksort isn't stable), but since SmallTalk makes these things possible when you need to replacing the stdlib quicksort with mergesort was actually a fairly simple operation.
Well, names and titles are still language, but I agree with your actual point: the Indus inscriptions seem to be too short and probably not general enough to allow an in-depth understanding without finding new, longer texts.
Anything IE is extremely unlikely as a language for the Indus seals; it only really fits with an out of India model of Indo-European, which is outright rejected by all serious scholars AFAIK. If we're going to look for contemporary relatives of the Indus language, the serious candidate is Dravidian. The Dravidian family was in India around the right time, and was definitely spoken in a larger area prior to the Aryan invasions.
Yup. The men's world record 10k is the 12:30.74 in the link. I think the longer blades on the skates help reduce overall friction, and modern skates have this detach function in the heel which lets the whole blade stay on the I've for longer, both of which help speed.
Off the top of my head, the only place strict Perl allows a bareword is the left-hand side of the => fat comma operator and pre-declared subroutines (IIRC, I never could quite remember the rules for that).
I had the exact same thought! A custom IDE with all the source stored in a database is extremely smalltalk, although here the source is stored in a shared DB (it seems), rather than a per-user DB as it is with a regular smalltalk image.
There are dozens of us I tell you, dozens! In my case I saw the light after two years of programming in SmallTalk, where our dev images shipped with Cambria by default.
Sure, but the crucial difference is that all the unwraps in your code are then hooks that a linter can find, or simply grepping for unwrap in your codebase and do a manual audit of those pieces of code. In my experiments with Rust that's been a very nice way of working: first build a very barebones version getting the basic happy path right, and then getting all the tedious stuff right afterwards by eliminating all the unwraps. By making it explicit, you now have a concrete thing you can audit specifically, rather than every pointer access in your entire program and every pointer you pass off to a library.
I did some code for an O&G company a couple of years ago and was reasonably happy with pint,but barril looks like it might have been even better. The handling of dimensionless stuff like volume by volume was a point I was never quite happy with in pint.
To add on this, musculus is not only an entirely regular diminutive derivation of mouse (mus + -culus) it's even the same pattern as is used for testicle: it's a small witness (testis, see also latinate English words like testify) of manhood.
`open my $fh, '-|', 'ls', '-l', $dir` should do the trick I think, but apparently it only works on platforms with a "real fork" (so fine as long as you don't care about Windows, probably).
Pinus and quercus are both fourth declination, not second, but there seem to be some elements of the second declination that have been included at some point (pini/pinorum/pinis and querci/quercorum) which muddy the waters a bit.