Poor man's runtime "dynamic" version. AKA: A much worse version.
In advanced cases, you'd need dependent types, but the only place where that almost shows up is in the "amount <= balance" assertions. That's also silly because if you typed "amount" and "balance" correctly, then "balance -= amount" has to produce a runtime error because the resulting balance would be negative and not a valid value for the type. So, it's a very natural place anyway to force the programmer to properly handle errors anyways.
"Contracts" has been around a long time and has not caught on. That's usually a good sign that better approaches are prevailing.
In other words: refinement types are a better solution.
> Poor man's runtime "dynamic" version. AKA: A much worse version.
Contracts don't have to be evaluated dynamically, that's just one way they're implemented. See SPARK/Ada for an example of contracts being used to prove programs statically, not just test them dynamically.
contract is way wider than simple refinement types. Refinement types are just a very specific group of invariants.
Contracts are an attempt to include formal specification languages into the implementation languages. You can enforce valid and invalid state changes, enforce relationships across the program state, or even enforce some level of correctness in behaviour.
> around a long time and has not caught on. That's usually a good sign that better approaches are prevailing.
That is completely not true. Plenty of dumb things prevail for faar too long for no other reason than momentum. Plenty of great things remain academic forever. It took decades to get algebraic types or basic functional programming somewhat accepted.
Design by contract is in theory a good idea but suffers from being a pain to use effectively. (making actually useful invariants that help the program more than an assert already would have)
Adding them to languages not built around them also results in quite nasty boilerplate or runtime overhead which further discourage their usage.
I was literally just catching up on this issue on Zulip yesterday. Amazing timing!
I like this framing a lot. I'm a huge fan of tiered abstractions. Ideally, you start with the highest level where it's cleanest and you work your way down to lower levels as required. Automated expansion for a lower level.
There isn't a language that achieves C's performance, access to hardware and portability while also having superior syntax. The reason C is hard is because it makes sacrifices to enable the above. A Rust (for example) compiler targeting many microcontrollers (8/16-bit word size (not all), Harvard architectures like AVR, non-8-bit byte) simply can't be written due to assumptions made by the spec. Many such architectures are still in use.
I don't know how many more examples people need to see of big tech not respecting privacy... it's just becoming a farce now. Big tech tracking woman's cycles? Of course they are. (sigh) If this doesn't gross people out enough to seriously pursue alternatives, I literally don't know what will.
Thank you Michael Rabin for your excellent work. Rest in Peace.
Rabin Fingerprinting is one of my favorites of his contributions. It's a "rolling hash" that allows you to quickly compute a 32-bit (or larger) hash at *every* byte offset of a file. It is used most notably to do file block matching/deduplication when those matching blocks can be at any offset. It's tragically underappreciated.
I've been meaning to write up a tutorial as part of my Galois Field series. Someday..
I recently found his fingerprint algorithm and wrote a utility that uses it to find duplicate MIPS code for decompilation[0] and build unique identifiers that can be used to find duplicates without sharing any potentially copyrighted data[1].
This replaced some O(n²) searches through ASCII text, reducing search time from dozens of seconds to fractions of a second.
Important to note that FastCDC is about an order of magnitude for block deduplication and is generally considered the state of art for such an approach (speed of computing the hash is more important than absolutely optimal distribution of hashes).
I'm working on a data annotation system based around Rabin fingerprints. They're a really neat idea.
I especially like how if you end up with hash characteristics that you don't like, your can just select a different irreducible Galois polynomial and now you've got a whole new hash algorithm. It's like tuning to a different frequency.
For me it means I don't have to worry about cases where there aren't enough nearby fingerprints for the annotation to adhere to, I can just add or remove polynomials until I get a good density.
I wrote a Rabin—Karp implementation in ~2006 as part of the spam and threat scanning stack for the MX Logic mail service. It was incredibly performant, letting us test {n} bytes against an essentially unlimited number of string signatures in O(n) time.
I live in a town in the Midwest that just voted down a data center project.
Personally I think it's mostly a proxy vote against bigtech/social-media. People are pretty fed up with their practices but don't have power to act at a national level. But, they DO have power at the local level to show up to town council and talk directly (in-person) to their representatives.
I think the other side of this is that there's this old idea (mostly correct) that municipalities partnering with businesses is good for the community because it brings positive side-effects: jobs, more cashflow in the local economy, etc. This is much less true for data centers. It's just a building that uses power and produces heat/by-products. Generally, employment gains are tiny compared with the old "automaker" labor model of the 1960s-1980s
People recognize this and they're not happy. They don't think it's a good deal for their communities.
One argument I've heard that people try to use as proponents of these datacenters is that they bring in employment in construction and electrical engineering even if it's temporary. Their argument falls apart very quickly when it's pointed out that because of the specialization many owners of these locations hire specific firms and contractors willing to travel across the nation for the work instead of hiring a local construction company or an on-site engineer. Some locations are managed entirely remotely where one engineer handles multiple sites, and the only people actually there are security, maintenance, and cleaning staff who might also be traveling contractors that move between locations in a circuit. That's like six people for something with a footprint the size of fifty family homes.
Even if it were true, I don't understand how this argument makes sense: So assume the construction were entirely done by local businesses/hires. That gets a short-term employment boost while the facility is being built. And then what? The construction is finished, the employment dries up again, but the data center is still there, with all the downsides.
Also, you could get the exact same short-term boost by building something else, e.g. housing.
Offsetting long-term costs with short-term benefits doesn't seem like a good strategy.
If your local governments are funded by property taxes, Data centers can bring in new revenue while requiring few services. Which could be used to shore up stressed public budgets or fund other economic development activities to bring in jobs.
These projects can be developed and located responsibly, and every project is different. I don't think a blanket ban is good policy.
"The person seems to have low self-esteem, displays introversion, poor honesty, low emotional stability, very little adventurousness and poor self-control hence we can target them with both niche and common products and services."
Amusing to me how wrong this is... I don't know how you can determine such characteriatics from a photo in any direction. I will admit that my appearance though tends to throw mixed and incorrect signals (not an accident). I find the entire concept of appearance signaling pretty off-putting so I guess this is a great result.
The only thing Google Lens has succeeded at for me is age, race, and location. Basically everything else has been very wrong.
Maybe you need to spell out what you're implying because it's not very clear. I don't understand what's so bad about wrong inferences. I've been living with wrong inferences my whole life - it's usually others that are made the fool.
In this particular case it means that you end up with really bad ad targeting. I'm happy with that, it's much easier to dismiss and roll your eyes at scam junk ads than ones that actually know how to manipulate you...
What if some of these ancient mysteries simply weren't logical. Investigations always assume that there was some very rational reason but still in our modern society we have exuberance and economic bubbles. The phenomenon is well-documented. What if it was something like that? The hole digging just got out-of-control?
In advanced cases, you'd need dependent types, but the only place where that almost shows up is in the "amount <= balance" assertions. That's also silly because if you typed "amount" and "balance" correctly, then "balance -= amount" has to produce a runtime error because the resulting balance would be negative and not a valid value for the type. So, it's a very natural place anyway to force the programmer to properly handle errors anyways.
"Contracts" has been around a long time and has not caught on. That's usually a good sign that better approaches are prevailing.
In other words: refinement types are a better solution.
reply