jlundborg

My favourite aspect of this is that the name EPA is coming from a long-since closed chain of stores selling low-quality products, and the teenagers driving these vehicles have for sure never seen one.

What I expect from leading experts is to give clear opinions and recommendations based on their best assesment of the situation given available data. I also expect them to quickly and humbly adapt to new evidence when it is found, while keeping in mind that new is not always better.

I don't expect experts to always be right, sometimes the best prediction turns out to be incorrect. This does not change the fact that it was the best prediction at the time it was made, given the available data.

I personally feel that this is exactly what Tegnell is doing in public discourse, he is very quick to point out when there are uncertainties and what the nature of it is, but is still able to present clear advise. He has also demonstrated willingness to change when new evidence is found. This is a far cry from what I see many politicians are doing, and I think this is the reason he is enjoying very high trust from the Swedish general population.

I'm very sorry to hear you are not following the recommendations of Swedish authorities, I would strongly recommend you do, because they are contrary to what you claim here, not actually based on Tegnells personal whims or vanity, but based on the many experts employed at the agency, and more importantly adapted to local circumstances in Sweden, such as the current stage of the epidemic, which areas are most affected and so on. As long as the German recommendations are stricter this is of course not that problematic, but it could mean you pay less attention to things that are more urgent to adress in Sweden.

I think this is decidedly unfair critizism, and is based on cherrypicking statements out of context especially regarding timing. The statement about the Alps/Southern europe has for sure been shown to be false in retrospect, but when it was made nobody knew there was an outbreak brewing there, so it was very much based on what was known at the time. I don't think any epidemiologist could have predicted the big outbreak in the alps/northern Italy specifically, and as far as I know, the advise from Tegnell was not different from that of the German authorities at the time. Basing your judgement of Tegnell only on this statement seems very ill-advised.

I think the most obvious examples are:

* Closing borders when we already have a pandemic in all countries. Swedish borders are still open.

* Closing schools when most evidence shows that it is not effective. Swedish schools are still open.

There is of course lots of debate about this in Sweden, some are worried that Sweden is not taking enough decisive action. There is however a wide-spread general support that the more measured approach in Sweden is a good one. Anders Tegnell has become a very popular public figure for his low-key bureaucratic but yet humoristic way of explaining the uncertainties involved and why Sweden is doing things this way.

I believe that the reasons these measures are taken in other countries is because it is a way to show strong political leadership in a time of crisis. I think this approach works less well in Sweden because people have very high trust in experts and (well-managed) authorities.

This is an excellent example, the chief epidemiologist in Denmark had a clash with the Danish PM about this, because evidence does not support closing borders as an effective policy when we already have a pandemic. In Denmark, the measure was intruduced despite this, presumably because the government wanted to demonstrate forceful action. Sweden still has open borders (not that it makes much difference since most other countries have closed them :) ).

Swede here. There is lots of disinformation about the Swedish approach to the epidemic. Sweden is following the same basic strategy as other countries, which is to slow down the spread by mitigating actions so the health care system can cope and to protect people in risk groups. The primary difference in Sweden compared to outher countries are:

* Sweden decided early on that an evidence-based approach should be followed. Many policies that are implemented in other countries do not have a lot of evidence showing their effectiveness

* Policy is still primarily dictated by the experts at Folkhälsomyndigheten (where Anders Tegnell is from), and not by politicians. Most actions taken by the Swedish government has been pretexted by "as requested by FHM we have...". State epidemiologist Anders Tegnell is generally seen as "being in charge" of the actions taken, even though technically he has very little legal authority.

* Sweden has a very strong history of indepenent government bodies. In Sweden, there is specific legislation preventing government officials from intervening in specific cases if there is a government authority in charge of the issue. The legal term for this is "ministerstyre", "ministerial rule", and even if an action is not technically in violation of this legislation, it is often used if politicians try to intervene in cases without creating general legislation.

* Being a high-trust society some measures that have been implemented as strict laws in countries other than Sweden are instead communicated as recommendations with a very high compliance rate.

I have only encountered public SQL APIs in the wild once, and at that time it made me very happy. I was building a scraper for a manufacturer of bicycle parts that shall remain unnamed. Scraping the whole database using a single SQL query was way better than hacking XPaths. I am not sure if their DBA appreciated it as much as I did.

The tagline of Datasette is "A tool for exploring and publishing data", to me it makes a lot of sense that SQL (with appropriate restrictions) is a suitable API for the kinds of things you want to do with datasets. This is not really the typical web API usecase, you normally have much more specialized and restricted use scenarios.

While I have also seen many poorly secured GraphQL API:s, this seems like an unfair criticism. To me GraphQL is mostly an alternative to REST, which also has no authorization or authentication by default, that is a orthogonal concern, but you can hardly blame REST for that.

I responded in a twitter thread[1], unrolled here here:

As all good things in life, and programming, this is a tradeoff. GraphQL is better when what you are requesting is best expressed as a tree (or a "graph", though only the DAG variety). This is not always the case, but it very often is when building API:s for production use.

Of course, you can express tree structures in table form, but it is not very convenient for clients to consume. In particular if your client is rendering nested component views, what you want is very often something hierarchical.

Another aspect of GraphQL that is better for us production people is that the performance is more predictable, exactly because the language is more restricted. You can't just join in all the things, or select billions of rows by accident. The schema dictates what is allowed.

Of course, again, it is possible to restrict this in SQL, just configure your schemas, limits etc appropriately, but SQL is anything-goes by default, whereas GraphQL is nothing is allowed by default. Whitelist vs Blacklist.

This said, as a language, SQL is clearly superior. It is the most (only?) successful 4GL (declarative) language. I wish more languages were this well-designed, and that there would be more language innovation in this direction.

The way I see it, GraphQL is a DSL for flexibly requesting hierarchical data from API:s in JSON format, optimized for complex evolving API:s. SQL is a full-fledged generic language for relational data transformation. They have different niches, but SQL has a much bigger one.

[1] https://twitter.com/joakimlundborg/status/125091692202945740...

The author makes a benchmark that compares a go program that explicitly buffers many "hello world" strings, and compares this to an assembly program that does not do this, then goes on to argue that this shows that high level languages can be faster. This can certainly be true, but this particular example is not a great way to show it, because the same optimization can be done in an obvious way in assembly, (just allocate enough space with brk or mmap2, write your strings and send the right memory address to ). This would of course be harder to do in assembly than in Go, but it is still quite straightforward to see what is the optimal way to do it. Furthermore, this would probably still outperform the optimized Go version by a wide margin.

A better example could be where a compiler picks an obscure but faster parallelization operation, or unrolled a loop appropriately in a way that is both faster and unlikely to be written by a competent human, or a complex memory management scenario etc etc.

I think this is not the point of the original article though. I think we all understand that abstractions can in theory bring great benefits, but we do need to scrutinize the cost they add. The hello world examples shows that even with the simplest program we can imagine, the result is extremely far from optimal in popular programming environments. If this is the case, why should we assume that these same compilers are doing an excellent job in situations that are actually hard?

In my team, we have started using these rules to address the code review lag-time:

* While you are waiting for code review, review someone else's code

* Aim for reviewing two CR:s per CR you submit.

This has helped us both keep on top of the CR queue and to have something that is not too distracting to do while waiting for review.

I am actually very excited about this direction for Gtk. If Qt is the stable and serious cross-platform UI library for corporate stuff, why not let GTK be the awesome experimental UI library that breaks everything every 6 months, and keeps pushing the limits on what a free software UI can be? I'm a very happy Gnome 3 user, and I hope they keep pushing to build a usable, simple and pretty user experience, despite the endless stream of this kind of grumpy know-it-all attacks.

Hey, if it was so easy to design an API that is "thought through properly", show us the spec already - there are plenty of hackers around to build it. If it actually worked like that.

The simple explanation is that Semantic Versioning is not at all the only way to do versioning, it is just one standard amongst others. Of course semver is progress in the sense that it has a specification that means you can assign meaning to the versions, but hey, so does the proposed versioning scheme for GTK. It is just not semver.

I think it is interesting to think about what the versioning scheme says about the development model and methodology of the project:

Linux currently uses even-odd versioning, but regardless tries to never break APIs or ABIs https://en.wikipedia.org/wiki/Linux_kernel#Version_numbering After much debate, Linux switched from a model where the major number never changed, which is kinda inline with semver. But since this seemed increasingly silly, to have a 3 there forever, they decided to just throw this overboard and start incrementing the version number more often. (This discussion was much more interesting in reality, read LKML for details).

Android uses an interesting brand-version and actually-useful-version scheme (API level) https://en.wikipedia.org/wiki/Android_version_history This very much reflects how versioning and releasing a new version has become a PR event. It is really funny how this distinction is even reflected in code.

And then of course there are the funky oddballs: https://en.wikipedia.org/wiki/TeX This asymptotically more precise number is suitable for a project that has the idea that it is approaching perfection without changing much. Not sure if every TeX user out there would agree, but it indeed says something about the author =).

There are plenty others, and of course it can be confusing if you think that semver is the only game in town. Perhaps the ideas expressed in the semver spec simple does not suit everyone.