maweki

I think the intent is clear. We could just enumerate all strings in size and lexicographical order. Then the task is only to filter, which strings are programs we desire.

It's the same sentiment as "the typing itself is not the issue, it's the order of the button presses that's difficult."

Of course, by Rice's theorem, all interesting questions are undecidable anyway...

Society doesn't owe me over $500k/year

No it doesn't. But as a human being, you and everybody still deserves a decent living. And our current system clearly does not provide that for a lot of people.

it is inherently resistant to false positives

By Rice's Theorem, I somehow doubt that.

In light of that, I am wondering why the article opted to go for "However, determining the optimal join order is far from trivial.", when there are hard results in literature.

I was also missing mentioning "sideways information passing", though some of methods are exactly that.

I am wondering whether the company consults literature or whether they fiddle about, mostly reinventing the wheel.

While tedious, you can do the rewrite block-wise from the insertion point and only store a an additional block's worth of the rest (or twice as much as you inserted)

ABCDE, to insert 1 after C: store D, overwrite D with 1, store E, overwrite E with D, write E.

What do you like to call Hungarian notation?

I had a lot of contact with computer science students coming from the other side, meaning they used Z3 or other (SMT) solvers as blackboxes which they just use at a certain point in their algorithm without having thought what theories they are using (the T in SMT) and what's undecidable in general or in that theory.

So I had quite a few "groundbreaking" approaches end in disappointment.

It's important to know the capabilities and limits of your tools.

I'm not a rust or systems programmer but I think it meant that as an ABI or foreign function interface bitfields are not stable or not intuitive to use, as they can't be declared granularily enough.

I think core of the problem in property-based testing that the property/specification needs to be quite simple compared to the implementation.

I did some property-based testing in Haskell and in some cases the implementation was the specification verbatum. So what properties should I test? It was clearer where my function should be symmetric in the arguments or that there is a neutral element, etc..

If the property is basically your specification which (as the language is very expressive) is your implementation then you're just going in circles.

Incremental automatic grounding to SAT works fine for ASP.

The range can be a product type, as can the domain. Most languages are expressive enough that you can create the product type (struct). You're right on point.

valuing where papers are published over what they contribute

And who is the arbiter of that? This is an imperfect but easy shorthand. Like valuing grades and degrees instead of what people actually took away from school.

In an ideal world we would see all this intangible worth in people's contributions. But we don't have time for that.

So the PhD committee decides on exactly that measure whether there are enough published articles for a cumulative dissertation and if that's enough. What's exactly the alternative? Calling in fresh reviews to weigh the contributions?

We found yaml to be a great exchange format for electronic exam data. It allows us to put student submitted answers and source code into a yaml file and there is no weird escaping. It's very readable with a text editor. And then we just add notes and a score as a list below and then there's the next submission.

For readability of large blocks of texts that may or may not contain various special characters and newlines the only other alternative we have seen was XML, but that is very verbose.

So what the author finds as a negative, the many string formats, are exactly what drew us to yaml in the first place.

Who doesn't own the third edition of the LaTeX Companion book?

pods (i guess 2 to 4 passengers) simply do not scale. It doesn't matter whether you put them underground or not. The only solution is for people to not use them.

One part of the solution is bikes, the other is mass transit. What self-driving EV pods may be able to do is be people mover for the last mile to a mass transit hub. But for individual traffic across longer distance it simply does not scale.

Isn't the author just proposing GraphQL?

Splitting the presentation into multiple fragments makes it more difficult to generate/alter a presentation using xslt.

Cisco is incredibly (in)famous for having hardcoded backdoor accounts in their products.

It's nice to see more semantic web experiments. I always wanted to do more reasoning with ontologies, etc., and it's such an amazing idea, to reference objects/persons/locations/concepts from the real world with uris and just add labeled arrows between them.

This is such a cool schemaless approach and has so much potential for open data linking, classical reasoning, LLM reasoning. But open data (together with RSS) has been dead for a while as all big companies have become just data hoarders. And frankly, while the concept and the possibilities are so cool, the graph databases are just not that fast and also not fun to program.

It's just a course about database design and in the first seminar we look at different news stories that have something to do with databases, like trump putting some random Italian chef on an international sanction list should make us think about primary keys and identifying people.

And the horizon post office scandal is the last and most poignant example that real people are affected by the systems we build and the design decisions we make. That sometimes easy to forget.

I teach the horizon post office scandal in my database courses. And my takeaway is, that software fails. And if people's lives are involved, an audit trail is paramount.

In slowly killing software the audit trail might be faster than the killing. In fast killing software, the audit trail isn't.

Slow killing software can be made more secure by adding the possibility for human review.

Fast killing software is too fast for that.

But there is still a difference here. Provenance and proper traceability would have allowed the subpostmasters to show their innocence and prove the system failable.

In the Therac-25 case, the killing was quite immediate and it would have happened even if the correct radiation dose was recorded.

Datalog does not need/do unification for rule evaluation, as it is just matching variables to values in a single direction. Body literals are matched against the database and the substitutions are applied to the rest of the rule and the head.

Prolog does unification of the proof goal with the rule head. It's necessary there but not with datalog.

I am about finished with my CS PhD and I taught databases at the university during covid. I, personally, would have failed in the remote learning environment we were providing.

I am amazed at those wo fought or even flourished through that.

The horizon post office scandal is the first thing I taught in my "database design" course, to show that we're not creating self-serving academic exercises. We are creating systems that affect people's lives.

I try to give the legal and ethical perspectives. These systems should be auditable and help and not hurt people.

They didn't just click a link. They contacted the supposed authors for comment. That would be a reason for not checking all of them.

I don't really understand what the difference is to syncthing (or value over syncthing, as it is very mature and also works across the Internet). You share folders and other devices are discovered locally and you decide which devices to trust and to share with.

Why didn't toolbox fit your needs? I found toolbox to be a very reasonable way to install development dependencies on a per project basis while not managing multiple hidden filesystems.

It is nice to see a core group of Datalog enthusiasts persist, even though the current Datalog revival seems to be on the decline. The recent Datalog 2.0 conference was quite small compared to previous years and the second HYTRADBOI conference was very light on Datalog as well, while the first one had a quarter of submissions with Datalog connection.

I'm encouraged by the other commenters sharing their recent Datalog projects. I am currently building a set of data quality pipelines for a legacy SQL database in preparation of a huge software migration.

We find Datalog much more useful in identifying and looking for data quality issues thatn SQL, as the queries can be incredibly readable when well-structured.