Hacker Newsnew | past | comments | ask | show | jobs | submit | arnsholt's commentslogin

If I had to guess, they probably have some ideas. In Your inner fish (an excellent book, BTW) Neil Shubin has an afterword where he describes roughly how they went about deciding where to look for Tiktaalik. Basically, you start with whatever thing you want to find out more about; in the case of Tiktaalik, the transition of tetrapods from aquatic to terrestrial living. So you start by finding out where you have exposed sedimentary rocks of the correct age likely to be contain fossils. Next, you also need to the rocks to expose the right kind of environment: desert sands or deep ocean environments aren't going to help you find Tiktaalik, for that you need shallow waters and intertidal zones. Finally, it needs to be somewhere you can get to. So in this case, I wouldn't be surprised if they were purposefully looking for soft body preservation (especially since I think Cambrian fauna generally was quite soft and squishy).

From memory, to get fossilised soft tissues you want the remains to be buried extremely rapidly in an environment where the soft tissues don't decay (typically an anoxic environment, so for a shale basically covered in mud). So a mudslide is one option, and I think there are some lovely fossils North American from the end of the Cretaceous that are hypothesised to have been buried by the tidal wave caused by the Chicxulub impact.

Edit: After some googling, the Cretaceous fossils I was thinking of is Tanis,[0] which is in fact plausibly (but not universally) thought to be covered by the earthquake caused by the impact, before the tidal wave arrived.

0: https://en.wikipedia.org/wiki/Tanis_(fossil_site)


Start with whatever thing you want to know more about. Then draw the rest of the owl

I worked as a Smalltalk developer for a few years, and it spoiled to such an extent that I’ve tried to make an extension for IntelliJ to replicate the browser for Java development. Maybe I should revive that project, actually…


Please do. I would love it for Python and TypeScript as well. It could use data from where the "Structure" pane gets its contents


How about the Spyder IDE for Python? https://www.spyder-ide.org/


The core system at my previous employer (an insurance company) worked along the lines of the solution you outline at the end: each table is an append only log of point in time information about some object. So the current state is in the row with the highest timestamp, and all previous stars can be observed with appropriate filters. It’s a really powerful approach.


So basically something like this?

(timestamp, accountNumber, value, state)

And then you just

SELECT state FROM Table WHERE accountNumber = ... ORDER BY timestamp DESC LIMIT 1

right?


Yeah, basically. The full system actually has more date stuff going on, to support some other more advanced stuff than just tracking objects themselves, but that's the overall idea. When you need to join stuff it can be annoying to get the SQL right in order to join the correct records from a different table onto your table of interest (thank Bob for JOIN LATERAL), but once you get the hang of it it's fairly straightforward. And it gives you the full history, which is great.


Sounds cool! Do you keep all data forever in the same table? I assume you need long retention, so do you keep everything in the same table for years or do you keep a master table for, let's say, the current year and then "rotate" (like logrotate) previous stuff to other tables?

Even with indices, a table with, let's say, a billion rows can be annoying to traverse.


I wasn’t involved in the day to day operations of the system, but it had records going back to the 90s at least I think. I think data related to non accepted offers were deleted fairly quickly (since they didn’t end up being actual customers), but outside of that I think everything was kept more or less indefinitely.


This is also a recurring pattern when using bigtable.


Lichess uses a scheme which is probably more efficient on average, described on revoof's blog[0]. Basically, it's a variable length scheme where the first 64 bits encode square occupancies, followed by piece codes (including castling, side to move, and ep with some trickery), followed by half-move clocks if necessary.

0: https://lichess.org/@/revoof/blog/adapting-nnue-pytorchs-bin...


It also can encode chess960 positions. With the article's encoding, uncastled rooks can only be decoded if their starting position is known, which it isn't in chess960.


It’s mathematically dissatisfying, but often the most optimal storage (or algorithm) solutions involve clever heuristics that are dynamically applied.

Some systems just have to be observed in order for solutions to be optimally designed around how they actually behave, rather than how they theoretically behave.


For about two and a half years I worked on a Smalltalk system, written in a quite old Smalltalk, which gave me two idiosyncrasies editor-wise: I no longer care very much about syntax highlighting (though I don't really bother to turn it off), and I now prefer to use proportional fonts for my programming. The only syntax highlighting I missed in the Smalltalk was a fading out of comments (which would in fact have prevented a stupid issue similar to the comment thing shown in the OP).


Good PBT code doesn't simply generate values at random, they skew the distributions so that known problematic values are more likely to appear. In JS "__proto__" is a good candidate for strings as shown here, for floating point numbers you'll probably want skew towards generating stuff like infinities, nans, denormals, negative zero and so on. It'll depend on your exact domain.


I'm pretty sure the publishers are alleging that a crime has been committed. In that case, private parties can't open a suit (at least if Swedish criminal law is at all similar to Norwegian law), so this asks the police to open a criminal investigation into the matter. What happens next in the Norwegian system at least is that the police will conduct their investigation, and at some point when the police consider their investigations complete the prosecutor's office will decide what to do next. Next steps can be concluding that no crime has occured, to ask the police to investigate further, that a crime has been committed but the evidence are insufficient for a trial, or that someone should be tried.


Surely you can still sue separately through the civil process even if you choose to not pursue criminal charges?

If someone causes you damage through non-criminal negligence, surely you can sue them?

The idea that you couldn’t bring a civil suit over possibly criminal conduct seems unworkable. It’s possible that my neighbour was drunk when he crashed into my parked car late at night, but surely that can’t preclude me from seeking compensation through civilian courts.

It’s possible, but tremendously unlikely that Facebook is committing fraud here. In Sweden you have to prove intent to defraud, which is a tremendously high bar.

Which, again, makes the idea that you couldn’t bring a civil suit seem ever more bizarre. How could you possibly know if Facebook has committed fraud here? You presumably can’t read Zuckerbergs toughts.


In that particular example (drunk neighbour damaging your property with reckless driving) is really — in most of Europe, I would guess as Serbian laws are largely copied over from different EU country laws — handled by the insurance.

Basically, insurance against damage to others is obligatory for anyone to get the car registered and on the road.

If someone drives an unregistered, uninsured vehicle, a consortium of all insurance companies pay for the damage, and sue the perpetrator in a civil case.

In general, you can argue your level of damage with the insurance company, and can even take them to court.

In Serbia, drunk driving actually precludes the liability of the insurance company too, but they still need to pay out the damages first, and bring a civil case against the driver to get compensated. For that, they need a criminal conviction.

(I've had the unfortune to be hit by a drunk driver, luckily no other harm than to the property as both cars have been totalled, and his insurance argued a lower value for my almost new car)

I am guessing here the "intent" can also be "aware of it but did not invest enough to curb it while it is profiting off it".


Yeah, I know how car insurance works and just figured it’d be overly verbose to specify some scenario where the neighbour was driving some uninsured vehicle like a tractor and the incident happened outside of public roads.

I do think I still managed to make my point though, preventing civil lawsuits arising from possibly criminal behaviour is unrealistic. That would make it extremely difficult for individuals to seek compensation for almost any damage they might suffer, they’d have to first wait for months or years before the police gets back to them.

>I am guessing here the "intent" can also be "aware of it but did not invest enough to curb it while it is profiting off it".

Fraud by negligence is a fairly exotic concept and to my understanding usually specifically relies on laws regarding negligent misrepresentation. I’d be surprised if that would work in Sweden.

I did find this government report which is related even if it discusses a slightly different kind of fraud https://bra.se/download/18.3433db6019301deaa6b8132/173142652...

>For liability for fraud to come into question, the prosecutor has to be able to prove that the crime is deliberate. This means that the criminal act has been committed consciously or intentionally. Liability for fraud is conditional on the objective requisites being covered by the perpetrator’s intent. It is not possible to judge a person to be liable for fraud because someone has been paid too much compensation as a result of negligence, or because the person did not know about certain obligations in conjunction with the compensation. Carelessness is thus not sufficient. It must be possible to prove that the perpetrator has committed the act intentionally. This intent must cover all elements of the criminal act. The great problem with fraud crime is to prove the intent. The actual circumstances surrounding what really occurred are often a lesser pro- blem. The assessment of the intent is complicated by the fact that the rules concerning social insurance can be difficult to understand. The difficulty in proving intent has meant that several assessors have considered that the fraud regulations do not work quite as they should. Proposals have therefore been made that negligence should be sufficient for judging that a person has misled the Social Insurance Agency or some other payment-issuer within the compensation and benefit systems (Örnemark Hansen, 1995). This criticism against the intention require- ment has led to the new Benefit Crime Act (2007:612).


Generally legal system has negligence, and once someone is provably informed of the negative consequences but keeps being negligent, "willful negligence", which is much closer to intent (I see it defined as "intentional disregard...").

IANAL, but common sense tells me there should be a link to willful harm.


I found the Smalltalk way of working in the running environment to be very programmer efficient too, and that it was by far the smoothest development experience I’ve had, even in a pretty dated and clunky Smalltalk at that point. And debugging wasn’t really a problem in my experience, but we stored application state outside of the image in an SQL database (initially Sybase, then MSSQL), which probably removes some «haha, the image has some weird data saved in the dark and dusty corners» issues.


I worked on a Smalltalk system which ran on Visual Smalltalk Enterprise, and in that system the image opened its windows as native Windows GDI windows, which made the application quite seamless in the OS (except this was in 2016-2018 and VSE was last updated in ‘99, so the look and feel was a bit dated :D).


I've only used PBT a few times, but when it fits it's been extremely useful. A concrete example from my practice of what has been pointed out in this thread, that you want to properties of your function's output rather than the output itself: I was implementing a fairly involved algorithm (the Zhang-Shasha edit distance algorithm for ordered trees), and PBT was extremely useful in weeding out bugs. What I did was writing a function that generated random tree structures in the form I needed for my code, and tested the four properties that all distance functions should have:

1. d(x, x) = 0 for all x 2. d(x, y) >= 0 for all x, y 3. d(x, y) = d(y, x) for all x, y 4. d(x, z) <= d(x, y) + d(y, z) for all x, y, z (the triangle inequality)

Especially the triangle inequality check weeded out some tricky corner cases I probably wouldn't have figured out on my own. Some will object that you're not guaranteed to find bugs with this kind of random-generation strategy, but if you blast through a few thousand cases every time you run your test suite, and the odd overnight run testing a few million, you quickly get fairly confident that the properties you test actually hold. Of course any counterexamples the PBT finds should get lifted to regression tests in addition, to make sure they're always caught if they crop up again. And as with any testing approach, there are no guarantees, but it adds a nice layer of defense in depth IMO.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: