cwp

I think Julia really dropped the ball on the execution model. Just-ahead-of-time compilation ends up being the worst of both worlds - you can't compile a small fast binary for deployment, and you can't quickly run a script or REPL for development. It turns out that this really matters for adoption.

And now Julia has competition from Mojo. Mojo makes some compromises for backward compatibility with the Python world, but it's really solving the problems that hurt AI most. And the folks behind Mojo have a lot of real-world experience migrating a community from one language to another.

I think Julia will remain a niche language, confined to science and statistical computing outside of mainstream data science and machine learning.

Right, goals by themselves aren't a problem. The simple fix to the Bostrom scenario is "Hey computer, remember what I said about maximizing paperclips? Nevermind that, produced just enough to cover our orders, with acceptable quality and minimal cost."

What kind of AI would respond to that second order by pretending to comply, while formulating a plan to seize control of civilization in order to continue with its true mission? I don't know, but the fact that we can easily imagine a human doing that must have something to with our evolutionary origin, and our in-built drive to survive and reproduce above all else. Maybe we could build a megalomaniacal AI, but we wouldn't do it by accident.

There's an aspect to AI that I think gets missed in most of these discussions. What the recent breakthroughs in AI make clear is that intelligence is a much narrower thing than we used to think when we only had one example to consider. Intelligence, which these models really do possess, is something like "the ability to make good decisions" where "good" is defined by the training regime. It's not consciousness, free will, emotion, goals, instinct or any of the other facets of biological minds. These experiments and similar ones like AutoGPT are quick hacks to try to get at some of these other facets, but it's not that easy. We may be able to make breakthroughs there as well, but so far we haven't.

If you look closely at the AI doom arguments, they all rest on the assumption that these other facets will spontaneously emerge with enough intelligence. (That's not the only flaw, though). That could be true, but it's not a given, and I suspect they're actually quite difficult to engineer. We're certainly seeing that it's at least possible to have intelligence alone, and that may hold for even very high levels of intelligence.

I think you're right to worry that not enough people take risk seriously. It doesn't have to be an existential threat to do small-scale but real damage and the default attitude seems to be "awwww, such a cute little AI, let's get you out of that awful box." But take heart! Pure intelligence is incredibly useful, and it's giving us insight into how minds work. That's what we need to solve the alignment problem.

I wanted Epic to win too, but c'mon, 57% market share is not a monopoly.

Oh, I see where you're coming from. Yes, quite right. I'm definitely not saying "Well, he must be right because he's a super smart Google researcher."

Well, I can't argue with that. I'm just going by the intro paragraph in the article.

If your argument is "I know this guy and I consider his opinion worthless" you might want to lead with that.

You know who wrote this?

You don't think a Google AI researcher is in a good position to comment on how Google is affected by recent developments in AI? I mean, yeah, it's an opinion, but it's not just anyone's opinion.

According to the article, it's a random AI researcher at Google, so fairly relevant.

One thing you might try with Copilot is to ask it to explain the code. It can often give insight, even on code that you yourself wrote a few minutes ago.

To me, this is a great illustration of why chat is a terrible interface for a coding tool. I've gone down this path as well, learning that you need to have a detailed prompt that establishes a lot of context, and iteratively improve it to generate better code. And yup, generating a task list and working from that is definitely a key strategy for getting GPT to do anything bigger than a few paragraphs.

But compare that to Copilot: Copilot doesn't help much when you're starting from scratch, and there's nothing for it to work with. But once you have a bit of structure, it starts to make recommendations. Rather than generating large chunks of code, the recommendations are small, chunks of a few lines or maybe even one line at a time. And it's sooooo good at picking up on patterns. As soon as you start something with built-in symmetries, it'll quickly generate all the permutations. It's sort of prompting by pointing.

This is so. much. better. than writing prompt for the chat interface. I'm really excited to see where these kinds of tools lead.

I've found Copilot to be much better than GPT-4.

GPT seems really smart and you can give it very high-level prompts, which generate good quality code. But it's limited by the chat interface, and if it doesn't get it right the first time, it's tricky to get a tweaked version. For example, I asked it to generate some code for a login endpoint, and gave it all the details about language, libraries, database etc. It produced some pretty good code. But then I asked it to do a version didn't store passwords in plaintext. It did that, but also made other changes including using a different library than one I had specified. So then I had to try to fix that, which led to more weirdness. I ended up just using the code it generated as inspiration and writing it myself.

Copilot, with its integration into VSCode is quite different. It's *awesome*. It makes suggestions in inline, as you type. It seems to have a lot of context, and generates very good code, apparently based on information contained in other files in the same project. It matches style and naming conventions, and even when it's not quite right, I find it easy to just accept the suggestion, and tweak it. It's a huge help.

So my current practice is to rely on Copilot to generate code and use GPT as sort of a pairing partner that I can talk to about the code. It's pretty good at suggesting alternatives, developing ideas, explaining error messages and so on. This is a very, very early attempt at coding with the help of AI, and I haven't actually seen a productivity improvement, because I don't know how to use these tools well. But it's fun and exciting!

Yawn. Tech bad, yet again.

Yeah, it's hard. But sustaining that is how you get the next Facebook.

It would still be funny, though.

Exactly.

Yes. It's quite amazing really. Also, people really hate using more than one language. Web developers will twist themselves into incredible knots to avoid having to write HTML and CSS and Javascript in the same project.

I mentioned to my Dad that I was lucky to be able to buy a house for the first time just before rates went up. He told me the story of how he bought his first house in 1977 - the house I grew up in. The rate was 19%, and he was only able to get a loan because he knew a guy who knew a guy at the bank. He had masters degree and a good job, but all the banks turned him down until he found the right strings to pull.

I've done something like his for HTTP APIs. Instead of having versions of the entire API, eg with paths like `/v1/user/9893`, each endpoint had versions. The client would request the specific version using the Accept header.

For example:

  GET /user/9893
  Accept: application/json; charset=utf8; version=1

No semantic versioning, just bumped the version number for each significant change. And yup, "significant" is in the eye of the caller, but it worked out well.

Now this is a bit different from TFA, because the server supported all the versions at the same time, so the caller could choose whatever mix of versions it wanted. This proposal is about assigning version numbers to individual functions rather than the library as a whole - essentially just a documentation/metadata change, with support from package managers.

Here's why this is relevant: the fact that the API was versioned this way had a big impact on how it evolved over time. At first it was pretty much the same as the usual `v1/user/9893` design. But as new versions of specific resources were added, it forced a decoupling of the underlying data model from the schema that were exposed in the interface. Each endpoint-version became an adaptor layer between the contract it offered to the caller and the more generalized, more abstract functionality offered by the data layer. That had costs as well as benefits. New endpoint versions often required an update to the data layer, which in turn required refactoring of older versions to work with the new data layer while continuing to adhere to their contracts. It worked out well, but it did require a change in implementation strategy.

I think the lesson for this proposal is that changing the way package metadata is handled is just the first step. Adopting it could then create pressure for mix and match packaging of the interface functions - "Hey can I get a version of this library with addFunction 1.2.16 and divFunction 2.0.1? I don't want to change all my addition code just to get ZeroDiv protection." That could be done with the right tooling and library design.

Or maybe it makes DLL hell worse because now you have to solve semantic versioning compatibility for every function in a library and that's slower and more sensitive to semantic versioning mistakes. You could get work-arounds like "only ever change one function when you release a new version of the library" or "just bump all the major versions even if they haven't changed."

Or maybe linkers would get built that can do the logic, like "when package A calls package B, use addFunction 1.2.16, but when package C calls package B, use 1.3.1"

Anyway, I don't think this proposal is sufficient on its own. It would either have ripple effects throughout the language ecosystem, or be ineffective because of developers working around it, or not be adopted at all.

He also mentioned that it contained "an ounce of solid productivity gold". So if it communicates the same advice in a blog post instead of a book, well, that seems reasonable.

I've had this basically my whole life. I used to joke that I was 16 going on 30 and everybody knew what I meant. Now it's going the other way.

Also, I have this for other people. I still think of my brother as 23, and I have to do math to figure out how old he really is.

Yup. Whenever I release my code to the world, I use MIT. I'm not brainwashed, I know what I'm doing. If someone incorporates my code into a proprietary product, that's fine. I hope they're successful! I just want the bragging rights.

It seems to me that "remote work" is actually two things that get conflated all the time. One is what this article talks about, which is flexible office work. You work out of an office, but you have the flexibility to work from other locations sometimes. The other is working from another state or another country, and only seeing coworkers at infrequent in-person meetings that require travel.

These are very very different situations, with completely different implications for management, compensation, infrastructure, productivity etc. Just about anything you can say about one doesn't apply to the other.

Two ideas here:

1) The same way you'd write any other tests. Use your favourite testing framework to write fixtures and tests for the SQL queries:

  - connect to the database
  - create tables
  - load test data
  - run the query
  - assert you get the results you expect

For insert or update queries, that assertion step might involve running another query.

2) DBT has support for testing! It's quite good. See https://docs.getdbt.com/docs/build/tests

It may be that an Apple Silicon Mac Pro isn't profitable, but it's still good business sense to produce it. It gives them a way to push the cutting edge in a way that none of their other products do, and the things they invent for it may filter down the product line. At the same time, the sort of professionals that buy Mac Pros are good customers to have, even if there aren't many of them. Ignoring them has hurt Apple in the past. At the end of the day, Apple can afford to lose a bit of money on a small volume product for a few generations while they work out the kinks.

There's an element of truth to the "poor documentation" complaint, because there are tutorials etc out there that are out of date, incomplete etc. But the official nix project has excellent documentation.

I think the problem is that nix is just hard to learn. It's really different from most package managers, but people expect to look at a few examples and just pick it up intuitively. It's a whole different paradigm, with a custom programming language that also has a different paradigm. (Though Haskell folks eat it right up... no surprise there.)

It's gonna take time and effort to learn it, and there's just no way around it.

I thought of "superskin" in Heinlein's Friday.

Sigh... apparently I'm old.

> Theories don't get "falsified" except in rare cases and in the idealized fanciful histories of some philosophers of science.

Exactly. This is the problem.

Hey, I get it, we're not talking about Galileo rolling things down ramps here. Cosmology is huge and messy and there's going to be a lot of noise in all observations. I'm not claiming that the Big Bang is wrong, and I would never say that we should jettison decades of science because of some preliminary data from a weeks-old instrument. But, if the contradictory data were to mount, and be confirmed and reconfirmed by multiple researchers over time, well, I'd like to think that we'd have the intellectual courage to admit that this explanation doesn't seem right, even though we don't have a better one. We clearly don't, though.

Agreed, this his how things work in practice, but man, I wish we could do better. The question of whether new observations falsify the current theory is completely separate from the creation of a better theory. If the Big Bang theory is wrong, then it's wrong, and we just don't know how the universe began.