mlavrent

I’m sort of confused on what prediction markets are going for? Polymarket here said they referred this to the DoJ and are trying to catch users using such insider info, but trading on insider info is the whole point of these markets is it not?

They bill themselves as providing accurate predictions, but the accuracy of those predictions is predicated on incentivizing (financially) users with non public info to share it.

They should probably pick a lane- is it gambling or is it incentivized insider trading for public good (accurate predictions)?

This article seems to conflate strong type systems with functional programming, except in point 8. It makes sense why- OCaml and Haskell are functional and were early proponents of these type systems. But, languages like Racket don’t have these type systems and the article doesn’t do anything to explain why they are _also_ better for reliability.

They do actually build internal tooling! They key is that it’s actually good enough that feedback to the limited, targeted, and quickly actionable. Microsoft’s internal was immature enough that the general feedback you’d always have is “this is unusable”, which is something the teams building the tools could probably figure out themselves before making the whole company spend time beta testing the tools.

The main point is that the tools need to be of a certain quality/maturity for dogfooding to be effective.

I was at Microsoft until July of this year until I left for an SF-based company (not AI though).

The difference between the two with regards to AI tool usage couldn’t be more different- at Microsoft, they had started penalizing you in perf if you didn’t use the AI tools, which often were under par and you didn’t have a choice in. At the new place, perf doesn’t care if you use AI or not- just what you actually deliver. And, shocker, turns out they actually spend a lot building and getting feedback on internal AI tooling and so it gets a lot of use!

The Microsoft culture is a sort of toxic “get AI usage by forcing it down the engineer throats” vs the new “make it actually useful and win users” approach at that new place. The Microsoft approach builds resentment in the engineering base, but I’m convinced it’s the only way leadership there knows how to drive initiatives.

The only ones I can really think of are the cloud providers themselves- I was at Microsoft, and absolutely everything was in-house (often to our detriment).

> it exposes that it really was never about emissions or combustion or pollution, you either wanted to control people’s freedom of movement

This isn’t the problem- the real problem is that in dense cities, transporting everyone where they want to go via private vehicles just doesn’t work geometrically- see the traffic and parking needs that grow as cities grow assuming private vehicle use only.You end up needing a more space-efficient form of moving people, namely public transit.

But it can often do so more efficiently than just carrying one container at a time when they're empty - see this company that's solving the "return container" problem by folding up to 4 containers into the space of one for the return trip.

https://4foldcontainers.com/proposition/

Counter-intuitively, yes, in fact. See the great article from Strong Towns, which does a lot of advocacy around building healthy towns: https://www.strongtowns.org/journal/2021/8/6/the-key-to-slow...

To be honest, while I’m not a Tesla fanboy, I don’t think the Cybertruck deserves this hate- as a cyclist I feel worlds safer near a Cybertruck than eg an F150 (though it of course weighs a lot) because of the sloped hood design.

Do I prefer to cycle next to Honda Fits? Of course, but the cybertruck is better than a lot of other truck alternatives

The Brown CS curriculum has in the past few years started including “socially responsible computing” material across intro and non-intro level courses.

See https://responsible.cs.brown.edu/

This is not quite right - a specification is not equivalent to writing software, and the code generator is not just a compiler - in fact, generating implementations from specifications is a pretty active area of research (a simpler problem is the problem of generating a configuration that satisfies some specification, "configuration synthesis").

In general, implementations can be vastly more complicated than even a complicated spec (e.g. by having to deal with real-world network failures, etc.), whereas a spec needs only to describe the expected behavior.

In this context, this is actually super useful, since defining the problem (writing a spec) is usually easier than solving the problem (writing an implementation); it's not just translating (compiling), and the engineer is now thinking at a higher level of abstraction (what do I want it to do vs. how do I do it).

Other common modes of transport that lack fixed schedule, route, or stops: - biking - micromobility (scooter-share, etc.) - walking - dial-a-ride transit options

In my current role, we currently have to think about things like holidays across the world to understand if usage patterns are low due to issues or just holidays. Being an engineer at Spotify adds another layer to the usage patterns, namely artist release patterns. I'm curious if they have a team (multiple?) that work on predicting future load based on news/artist tours/release schedules?

All of this reminds me of the TV pickup [0] phenomenon in the UK that involves kettles during commercial breaks, albeit on a longer timescale and maybe less predictable.

[0] https://en.wikipedia.org/wiki/TV_pickup

There's a difference between parking mandates versus parking built at the developer's discretion. Parking mandates (what the article talks about) are onerous because they force the developer to build more parking they potentially would have otherwise (based on a rational assessment of the opportunity cost of the space parking uses vs. the benefit to their business).

I think few people would argue against allowing developers to build as much parking as they want - but I think many would be surprised to find that developers in urban areas don't generally want to build as much parking as is mandated by the zoning requirements, since they assess that many people don't arrive in cars, so the benefit parking provides is less than the cost of it.

Since moving to Washington, I've discovered just how easy voting can be, and how we can drive voter participation (oh, if only that's what everyone wanted). I always voted when I needed to in person in other states, but now ballots just show up in my mailbox without me even knowing there was an election; it makes having 3-4 elections every year a complete non-issue since all it involves is finding a pen, and making the trek back to my mailbox to drop it off.

I buy that it's rife for abuse in many countries, but the US has such a well-protected (legally-speaking) postal service that it's probably the best country of any I know to do mail-in voting.

The issues with this argument is that pedestrians, transit-users, and cyclists also pay the same sales tax. So if the goal is to have drivers take ownership over the costs they produce, we could also consider only levying the sales tax on people who arrived by car - but that's silly since there's no good way to implement that (how do you know if someone arrived in the city by private vehicle?).

The straightforward answer is to add tolls. Another solution I could see working is adding special sales taxes on parking garages in the congestion pricing zone, but then this wouldn't capture tolls on trucks, and make it harder to implement exceptions for low-income drivers or drivers with disabilities.

This is the right thing to do - it makes drivers pay for the externalities they produce (including pollution, congestion, noise). When a city grows as big as Manhattan has, drivers need to begin shouldering at least some of the costs they introduce to the city, instead of leaving residents dealing with those costs.

Sorry, I should've been clearer. I'm interested if there's any tool that does this kind of thing statically, without running the code. I guess a simple approach is to compile both programs and see if the generated code is the same, but I'd guess reasoning at the generated-code level will probably produce a lot more false positives (i.e. tool will report a change when there isn't one) than if you reason about the original program.

I’m almost not sure why tools like git don’t ship with this as default. Been using difft for about a year now, and my main complaint is that it makes it hard to go back and use other diff tools when I don’t have difft available :).

I am curious if there’s been any work on _semantic_ diff tools as well (for when eg the syntax changes but the meaning is the same). It seems like an intractable problem in the general but maybe it’s doable and/or useful for smaller DSLs or subsets of some languages?

I agree in general that there needs to be at least some level of review (typos, etc.), not necesssarily to catch big but subtle issues.

On the other hand, I've had it where small (single character!) PRs have to wait for several days because I need to keep bothering my team to review them. But this seems like a problem that solvable organizationally somehow (not sure how?) rather than by eliminating an important part of the process.