I don't know how it worked in Sweden, but in Norway I know that one of the most common conventions was for the surname to be the farm where you were born (so my great grandfather had a different surname from his younger siblings, because the family moved). But when farmers started moving into the cities, these names were looked down on so many country people took patronymics when they moved to the cities to obscure their background.
I worked on a system implemented in Smalltalk for a few years, and the truly integrated development process possible in a ST is a high I've been chasing ever since. And this was in a setting that had so many things going against it: I started working on it in 2016, and the last update of the runtime environment was from '99. We had a custom HTTP client, and home-brew bindings to OpenSSL that I cooked up with some mad science Python that parsed C headers to generate Smalltalk code. I even had to fix a bug where Winsock fds rolled over if you opened more than 8k sockets, because the runtime FFI bindings assumed a 16 bit wide return value (I assume the code dates back to the Win 3.11 days).
By all rights, it should have been _awful_. But in reality we were able to iterate quickly and actually make stuff, because the technical foundations of the system were rock solid, the team was good, and because the truly integrated Smalltalk development enviroment enables a super-tight development cycle. A joke I have with a former colleague from those days is how all modern languages are still fundamentally no different from the punch card days: You take your sources off to the batch processing center, and the results come out at the other end, while Smalltalk is future techonology from the 80s.
This is basically how Smalltalks work. In addition to the application, an image will generally include a development environment and all the sources to your application. I think Lisp machine Lisps were a lot closer to this too.
The corollary to Greenspun’s rule is that any sufficiently complicated Common Lisp program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Prolog.
In this context, it's not terribly hard to divine that they probably mean EPSG:4326 coordinates. I was going to comment that one of the ETRS89 UTM zones might be easier to work with, but on second thought the data almost certainly includes the DOMs if not the TOMs, so a global coordinate system is probably best.
I’m not convinced it’s cheaper to surveil the entire country than to simply assess claims when they are reported and dismiss those that are due to lack of maintenance.
I think the details around this vary a lot from country to country. I work for a Norwegian insurer, and I’m pretty sure that we couldn’t cancel a contract like this short of something like fraud. OTOH, contracts are renewed annually, and I think declining to renew would be an option. But damages due to lack of maintenance are not covered anyways, so I’m not sure if there’s much incentive for this kind of thing in our market.
The genius of TeX is that it’s a programming language for document production, that can mostly look like markup. The further genius(?) is that the language works in such a way that you can do more or less arbitrarily complex things, while still exposing an interface to the user that feels like markup. This makes for a language that is sometimes, honestly, completely bananas. But when wielded correctly, it’s great.
Gnuplot is fantastic. And with the epslatex terminal, it sets the graphics in EPS and the text elements in TeXsobtgat you can get everything typeset juuuuuust right.
Or simply building fire insurance, so you’re not massively in the hole with no collateral if your house burns down. Which is why lenders require a house to at least be fire insured in my market, as a condition of the mortgage.
What is it about the story that puts you off? I might agree it’s not a masterpiece of interactive storytelling, but given the subject matter I’m hard press to find a different kind of story you could tell with it.
In syntactic problem, this is called the PP attachment problem. Basically, should the sentence read (get into the problem) (with the GH team) or (get into (the problem with the GH team)). Turns out to be a very hard thing to do correctly.
I mean, in some sense it's never too late to change? But I do think that as technical people our profession has a strong tendency to underestimate (and undervalue!) the social component of this kind of change. If you have agreement on a path forward, getting it done is mostly a question of elbow grease. The hard part most of the time is getting an agreement on which path to choose out of many mutually exclusive options. And the Linux Rust effort is a good example of this: I think getting agreement that this is good and desireable is at least as hard as the technical work of writing the code. As the LWN article notes, there's been lots of change in this over just the last few years but there's still quite strong resistance it seems.
I'm sure there are lots and lots of options in the design space here that would have been viable, but for better or worse this is the one we got. I dunno why Pascal didn't happen (but large portions of developers scoffing at the language shouldn't be discounted: this is as much a social consenus building exercise as a purely technical one), but for the "simpler C" versus Rust question it seems to me that there's some kind of local optimum around C, in the sense that the people interested in safety wanted more than is possible with small changes to C and the people who wanted to keep C weren't sufficiently motivated to actually make the changes (Regehr touches on this in the first part of the article, getting any kind of consensus on what Friendly C should actually be turned out to be very hard).
I reread John Regehr's "The Problem with Friendly C" [0] a while back, and a comment towards the end made me think of the Rust in Linux effort. He speculates that "an influential group such as the Android team could create a friendly C dialect" which in turn can drive adoption and consensus on what a better C language should look like. Of course, we know that hasn't happened since 2015 when that article was written, but what has happened is the Android team's rewrite of the Binder in Rust. So I think the main thrust of the argument is correct: interested parties are converging on an answer to the challenges of writing secure C. It's just that rather than evolving C itself, the consensus that seems to be developing is that Rust is a better answer.
As I read it, these physicists came across the notion of windkessel in some medical/physiological literature and realized that this is an understudied physical phenomenon. So I think the claim is less that they’re doing something revolutionary for understanding the circulatory system but rather that they’ve come across something whose underlying physics are a lot less studied than they expected.
Normally they do, but some implementations (notably GNU SmallTalk) are so afraid of the SmallTalk way of doing things that they use source files instead, which IMO removes a large part of the attraction of using SmallTalk at all.
It is. In this case though, we're talking the wholesale lifting of entire passages of text from other people's theses. I think the tally is up to 22% currently of her thesis being copied without attribution from other sources.
The problem for Python with type checking is that the language has essentially no compile-time constructs at all, just a bunch of assignment operators with different syntax: `def` assigns a function object to a variable when it's executed, `import` assigns a module, `class` assigns a class object. This means that everything involving names in Python is just a variable lookup (incidentally, this is why a function call must follow the declaration in Python: the variable is unbound if you haven't executed the function definition yet). The reason `Sequence` fails in the example in the article is simply that the code is trying to read an unassigned variable, no different from writing `vairable` instead of `variable` in your code.
Smalltalk works this way: an object's instance variables can only be accessed directly in methods called on that object (and not in methods defined in subclasses either). And method calls aren't magical function calls, if mostly because methods are the only way of executing code: you do have blocks, but they're invoked by calling a method on them, so...
Code as data is interesting, but mostly orthogonal to S expressions. For example, Prolog code has the same property without S expressions, and more esoterically TeX (which is succinctly explained to a lisper as programming with defmacro but not defun).
Python does actually have a single instance of sub-function scopes: When you say `try: ... except Exception as e: ...` the `e` variable is deleted at the end of the `except` clause. I think this is because the exception object, via the traceback, refers to the handling function's invocation record, which in turn contains a map of all the function's local variables. So if the variable worked like normal variables in Python it'd create a reference cycle and make the Python GC sad. So if you need that behaviour, you need to reassign the exception to a new name [0].
The mechanism, as I understand it, is that higher temperatures drives increased evaporation which leads to increased droughts. But the evaporated water in the atmosphere has to come back down again, which it will tend to do in a great big splash. These torrential rains, I’m led to believe, don’t really penetrate deep enough into the soil to alleviate the increased evaporation (too much too fast), and they also drove erosion which aggravates the droughts I think.
At a guess (this is kinda far away from my own linguistics education), it serves some kind of pragmatic/discourse function. Basically, it means something along the lines of "I am now going to tell a story", which is probably useful information for interlocutors to know how to modulate turn-taking when interacting with the speaker.
With a background in linguistics and a descent understanding of Unicode, I thought I had something of a grip on the complexities of text. But then I read Text rendering hates you[0] and realized I had no idea how hard rendering text really is. The most striking example for me is the Arabic example where allh (Allah) is styled with different colours on each of the four characters, because this particular character sequence is a mandatory ligature if memory serves, and how do you figure out the colour changes when you're layout out a single glyph from the font?
The same thing happened with the Epic implementation in Copenhagen (which might have been before Finland? I forget). But it also happened in Trondheim in Norway at the end of last year: everyone said it was a terrible idea, both technical and medical people, they did it anyways, and everything when straight to hell.