throwawayjava

But when I shop around for jobs in those areas, two things stick out:

1. While they'll generally do better than 58k for non-entry-level positions, midwestern employers won't touch 1/3rd of my coastal salary. Housing doesn't even come close to compensating. Even if someone straight up gifted me a house in the midwest, I'd still net close to 6 figures better on the coast.

2. More importantly, and 100% related to #1, midwestern employers have no idea how to leverage my skills. Therefore, the work is generally less interesting (lots of not-so-challenging implementation roles and a lot of that is web stuff; very little industrial R&D) with no room for growth (except perhaps into vaguely technical mid-level management at a particular type of company, which I'm not interested in).

3 (This one is admittedly purely about personal taste). The local support for public schooling k-12+ is spotty. Some of the best schools in the country, but also some of the worst. And you basically have to live in sprawlville to use the good schools. Meanwhile, the interesting jobs are still mostly where you'd expect and the bike/transit infrastructure connecting wealthy suburbs to downtown areas with interesting jobs just doesn't exist... so, better buy a comfortable car.

IMO this won't change for at least one more decade. The tech talent for one type of computer science will begin to fill in just as demand shifts to a different type of computer science. I'd be unsurprised if that continues indefinitely. The only way out is for these communities to build out their own talent pipelines a la Pittsburgh or Chicago. But Chicago is Chicago, and Pittsburgh can pull on its rich institutions from a glorious past. So, IDK how you bootstrap that sort of thing.

What does that mean?

The point of outside time for a pet is to get a ridiculous serotonin high and pee where-ever they want.

The point of outside time of a guide dog is to do work.

If you compare me while I am at work to a person who's out at a bar with friends, I probably look "miserable". That doesn't mean I'm being abused at work. It just means that animals who work for a living (me, the dog) sometimes need to tone down the hormone rush in order to do our jobs.

Does this dog look miserable when in public, or does the comparison set (all the other dogs in public) simply look like the peak of hormone high?

Although in practice the answer is that instructors have to lean heavily on the learner and the university's resource center.

> and wasn't clear to virtually anyone who agreed to it

Virtually everyone who agreed to it never bothered to even try to read the policy in the first place. So, really, what difference does that make?

Again, the fundamental point is that chasing ToS clarity/readability/length is a losing battle. The majority of consumers don't care enough to read, no matter how simple you make things. Improving this metric won't make a difference. This issue is a red herring. Focus efforts elsewhere: consumer education and consumer rights.

I'll try to explain.

Your definitions of Ring and PolynomialRing are incomplete because neither specifies the appropriate set of axioms. Because you do not specify those axioms, your type signature is underspecified. As Sussman puts it, "It is probably impossible to prove very much about [the] program" (at least, without inspecting the implementation itself).

To give a concrete example, the type signatures of Ring and CommutativeRing are the same in System F. And as Sussman puts it, "a program that depends on the commutativity of numerical multiplication will certainly not work correctly for matrices."

Now, this doesn't so much matter for human-written code, because us humans will implicitly fill in the details and never pass a mere Ring into an algorithm that expects a CommutativeRing, even if the two types are structurally identical. However, this does matter a lot if you want to use the structures of types (or their programs) to direct automated program mutation/construction.

And automated program mutation/construction is exactly the sort of thing that this note is about ("The most robust systems are evolvable").

Of course, there do exist type systems which fix this problem by allowing you to specify the axioms to which a Ring or CommutativeRing must conform. But using those systems is a crap load of work, requires a PhD's worth of effort to become efficient at, and of course now you have to do full-blown theorem proving. Which, IMO, introduce the same "brittleness" that Sussman talks about at the beginning of the essay". Data propagation and decorated values are Sussman's proposed alternative, from what I can tell.

So 1) it's true that type theory provides one solution to Sussman's problem. But that type theory is something much more expressive than System F. And 2) given the difficulty of using those systems (eg CIC) in practice, I think Sussman's proposed alternatives are worth seriously considering.

Or, to put emphasis on the important things:

"we may (read: WILL) collect ANY device information you give permissions to access to do [reasonable thing A], [reasonable thing B], or for ANY other business purposes. Examples of device information include: [insert list of benign things you should totally ignore]"

But here's the problem with the "AI tell us all" approach. If you use ML to mine examples from existing policy texts, you'll end up showing the user all of the benign stuff that the companies put in to reassure users, because that's what the corpus contains. Therefore, your AI will emphasize exactly the wrong types of examples.

Also, notice that this isn't even a legalese thing. There are no legal terms of art or long-winding difficult grammatical constructions. It's just plain old good rhetoric. And it's hard/impossible to legislate away persuasion.

Right here, clear as day: "We collect information from or about the computers, phones, or other devices where you install or access our Services, depending on the permissions you’ve granted"

Also notice that if they have that data, you explicitly gave permission to access phone/SMS data in the app install process; i.e., you granted those permissions.

> ...steal...

Again, that's the problem! Facebook didn't STEAL that data. They took it with your permission. And they were actually very clear in their policies about the fact that they could take pretty much anything you gave them device premissions to access.

This is NOT a "users can't understand legalese" issue. It's very clear from the above sentence in the data policy that Facebook has the right to record arbitrary shit off of your phone/computer.

This IS a "users don't care and don't have any data clawback rights" issue. Or perhaps a "users are too trusting" issue. But any high schooler could interpret the above sentence as meaning that Facebook does, technically, have the right to collect any information from your phone if you give device permissions.

The distinction is important because it determines appropriate solutions. The solution is NOT making ToS easier to read. The solution is stronger consumer data rights (aka a mechanism to clawback data after the fact) and better consumer education (aka be paranoid)

If you think that merely making ToS easier to read and understand will substantially change consumer behavior, you're in for lots of disappointment.

But before making this argument, one should go read FB's ToS and data policy. Here they are:

https://www.facebook.com/terms.php

https://www.facebook.com/policy.php

Facebook data policy: https://www.facebook.com/policy.php

I agree Lindsay Graham is a skilled orator and politician. But if he blew up the font size until those pages required two inches of 8x11 paper, he must have just terrible eyesight ;-)

Also, neither of those documents is terribly difficult to understand. Like... where, specifically, is Graham getting horribly confused?! Point to the concrete line in one of those two links that requires something beyond a high school education!

Now, I'm sure there's nuance I don't pick up on. But I definitely feel I can understand the ToS and privacy policy without consulting a lawyer.

I don't think some of the terms are fair. But that's a consumer rights issue, not a "legalese" issue.

More generally, on two occasions I've had to get in front of a real judge in a "real" courtroom and make an argument based upon some written piece of law I had to look up and interpret myself. In both cases, I was able to successfully convince a judge that I was on the right side of the law without the help of a lawyer. I'm certainly not saying that's always possible, but I do believe there is a lot of "learned helplessness" when it comes to digging through legeal code or contracts and reading legalese. It's a PITA sometimes, but in many many cases it doesn't require years of training.

Investors can lose money on bad code bases. Technical due diligence is a real thing. And getting a third-party opinion on "if your CTO dies, does your business also die?" is EXACTLY the sort of thing that comes up in those conversations. E.g., https://dave.moskovitz.co.nz/2016/08/29/technical-due-dilige...

If a technical audit comes back with "the CTO is the only person who can maintain this code base", and if the code base itself is a major asset the buyer is interested in, that can kill or substantially modify the terms of a deal.

> Demonstrating such a lack of awareness and understanding does explain why you are a junior programmer and not an investor.

(e: removed silly speculation)

> ...go and buy some stocks, etfs, mutual funds

This provides zero insight into what technical due diligence looks like or how that plays into the overall decision to purchase or invest in a company?

I've found that this is generally less true than I imagine it to be. A lot of law is not actually so difficult to understand. Legalese is still English, and Google is great for figuring out the odd meanings of certain terms of art.

Most of the exceptions I've come across (e.g., buying a house) are IMO actually intrinsically complex transactions. I could undestand, but it'd take so long. And the time taken would happen even if we only had the laws we needed and all those laws were written in plain english. In software terms, lots of essential complexity.

Going back to the article, the problem with Facebook's terms and conditions is definitely not understandability -- see https://www.facebook.com/policy.php. The average high schooler could understand. The problem is people caring enough to 1) find, 2) read, and 3) inconviencance themselves if they don't like the policies.

That's unfair. Most people who are advocating for deference when first joining a team.

And the common justification isn't politics! The most common justification is that there are a lot of "unknown unknowns". Therefore, sitting back and learning the social and technical history that led to the current system is actually the correct place to be in the exploration-exploitation axis during the probationary period.

Both for social reasons, as well as for technical reasons.

That's very different from "put up with office politics". The point is not that you should be likable during the probationary period. The point is that people who go way the hell too far to the "exploitation" side of the axis so quickly are demonstrating poor engineering judgment.

Characterizing that poor judgment as "well I guess I'm just not PC enough" is just icing on the cake.

> The team "criticisms" are to the person who is actually doing his job, instead of the ideas this person expresses, falling at the very bottom of "Graham's Hierarchy of Disagreement."

According to this account.

I submit that it's not even obvious that the engineer in this story was even making the correct engineering decision. Engineers are not scientists:

> In such situation, leadership should have had created a secure context for the team to consider their gaps in process that produce results with reduced quality.

I think the core problem in this story was wasting a bunch of the company's time arguing over a heuristic that's "good enough" in practice. Both solutions would have been "good enough"; the engineer put his ego above producing value for the company.

> Organizations that need to move fast cannot afford such conformism and dysfunctional communication.

Organizations that need to move fast cannot afford engineers spending time to prove they were correct when going with the established heuristic would've produced a good enough result with far less engineering time involved.

If the story included a thorough cost/benefit analysis showing that the change saved the company $N0,000 with N > (cost of engineering time) then you might have a more cogent argument.

Maybe. But high-risk. See Perl 6.

No, not at all! TOR is fully encrypted, but there are somewhat regular vulnerability reports about various parts of the stack. Including criticial vulnerabilities that can and have been exploited by nation states, for example.

> This is no worse than Facebook though

This is not at all clear to me. The attack surface for Scuttlebutt is much larger, and I trust Facebook's security team to audit and patch much more than I trust any random friend.

I'm not sure where I stated otherwise? Swarm is putting their satellites in LEO.

> Some proposed constellations in LEO number in the thousands of satellites, which is unprecedented

Which is much more analogous to today's highly-regulated airsplace than 1903's empty skies.

Do all employees of Swarm live in international waters?

1. Why?

2. What's a better alternative? Shooting stuff out of LEO with lasers...?

> the company will just move elsewhere, or have a subsidiary or contractor "own" the satellite.

So what? Those things are only magic check-mate cards if the government lets them be. And... why the hell should any government let them be?

> And practically speaking, they have no enforcement capabilities in this realm.

We can't bring people back to life, but that doesn't mean that a country can't punish people for murder the moment they step foot inside that country's borders.

You realize that satellites are not a new technology, right? There are literally thousands of them up there. Sputnik was launched in 1957.

Let's compare to mandatory pilots licensing. The first flights were in 1903 or so. Air traffic was regulated in various ways at the federal level by the 1920s. So about 20 years from first flight to regulation.

It has been over 60 years since the first satellite launch.

Also, airplanes have a distinct advantage: they are easier to track and always come down within a few minutes of breaking down. If anything, satellites should be more regulated.

The idea that putting satellites in LEO is some sort of brand new never-before-done thing that deserves wide latitude for greenfield engineering is crazy. Hell, I've owned a GPS receiver for about 20 years! Space is a frontier. LEO, however, has been a crowded commons for at least a decade or two.

> Why does reading this sound like a prequel to 1984?

Who knows, but this seems common enough that it deserved a name. I propose "1984 disease" as a new colloquialism for the act of comparing reasonable regulation to dystopian authoritarianism.

IDK if those people exist in high numbers within city centers. Those folks are all clustered along transit lines just outside of city city centers, right?

I doubt prices in cities will change much, though. People who want to live in burbs are already living there. And there are lots of people living along transit lines who would rather be living somewhere else, if only they had access to trasnit.

If prices drop anywhere, it will not be in city centers. It will be in the inner suburbs along transit lines.

Again, for this customer...

I'm moving soon and seriously considering not signing up for internet at my new address (new job, I'll be at work a ton, and the common area has free wifi I could use for the occasional email or weekend netflix download). But I won't cancel my prime subscription. That's what made me realize how sticky amazon is: I will pay 3 figures for access, even without instant access to the network that lets me get to them!

The courts already have a way of doing this that doesn't involve slavery.

1. Those command line programs weren't necessarily designed with an adversarial user in mind! Sanitizing input to prevent shell escape sequences is not enough. You really need to sandbox well.

2. For some tasks, it might be easy for a malicious user to guess which command-line tool you are using. You might be getting way less depth out of obscurity than you think you are.

Sounds like what Microsoft tried to do with the .NET ecosystem, but with cloud integration (which Microsoft should be doing for their own cloud) and API validation.

Someone needs to actually succeed at doing this. Most of the type-checking/inference problems in this domain are decidable -- it's really a tooling/tooling integration problem. Creating a single unified tool instead of having developers clobber together libraries (JSON schema validator, ORM, MVC framework, deployment workflow for all of that, etc.) would be a huge value-add.

Suggestion: code example/screenshot/workflow video on your homepage, and a link to your homepage in the advert. Nearly every programming language/library out there has a concise "hello, world" example on their homepage. Nearly every software development tool has a screenshot of sorts on their homepage. Those examples are worth a million words. Even an appropriately caveated "Wizard of Oz" (https://en.wikipedia.org/wiki/Wizard_of_Oz_experiment) demo would go a long way.

Yes, the model itself is part of the backend, not the code used to generate the model. But the website explicitly mentions "machine-learning __models__" as an example of something that's "not backend".

> Back-end has always meant the CRUD/API portions of a CRUD app.

This is not true. Compilers have backends. Speech processing pipelines have backends. The dragon book, which pre-dates the advent of the WWW, distinguished frontend from backend (and in those words).

Web-based CRUD apps inherited the terminology.

Yes, it's clear enough that they don't want you to be a member of that list. But what characterizes the elements of that list?! In any grammatical or intuitive reading of

"This probably isn't a good fit if your product is not backend-heavy, such as: ..."

the "..." is a list of things that are "not backend-heavy". And the first element is "iPhone game", which is certainly an example of something that is "not backend-heavy"!

> (Your product is (not (backend-heavy, such as: ...machine-learning models)))

Oh no! That's horribly confusing and not how lists are used in English! If that's what they meant, the post needs rewording. The correct way to say something like that is e.g., "Your product is back-end heavy but is not [insert delineating characteristics], such as: [insert original list here]".

To return the substance instead of grammar, IMO the "[insert delineating characteristics]" portion of that sentence is exactly what's missing from this advert!