killthebuddha

Yeah my setup is pretty basic, but it's absolutely killer IMO :)

- Cmd + Ctrl + <I|O|U> -> Move active window to monitor I, O, or U, respectively

- Cmd + Ctrl + <H|J|K|L> -> Move active window to <left|bottom|top|right> half of screen

- Cmd + Ctrl + <C|V|T|...> -> Open heavy-use application denoted by C, V, T, ...

That plus vim mode in Chrome, VSCode, and Obsidian has me _flying_.

One way that I've been framing this in my head (and in an application I'm building) is that gpt-3 will be useful for analytic tasks but gpt-4 will be required for synthetic tasks. I'm using "analytic" and "synthetic" in the same way as in this writeup https://github.com/williamcotton/empirical-philosophy/blob/m...

I feel similarly about hammerspoon [1] on macOS. Not a GUI tool, but Lua is a very easy language to learn.

[1] https://github.com/Hammerspoon/hammerspoon

I think I agree, and am doing something similar as well. Even the adapters approach does require some amount of consistency across prompts. For example, if you have one prompt that says “you are a very helpful assistant” and one prompt that says “you are a very lazy assistant”, then even if those prompts are otherwise written to be as orthogonal as possible you will still probably see degradation in completion quality.

Follow-up thought I just had: It seems that prompt structure standards are going to have to emerge if any of these tools have a shot at interoperability. I don't have hard data, but IME if a prompt is structured

MEMORY EXAMPLE INSTRUCTION [COMPLETION]

it will basically not work to wrap it in a prompt that's structured

INSTRUCTION MEMORY EXAMPLE [COMPLETION]

One thing that I really like about the approach you took with clownfish is that it doesn't constrain or modify the structure of the prompt.

One of the primary difficulties with writing LLM applications is that prompts are basically not composable, and any LLM library that modifies your prompt is going to be a nightmare to work with.

I think this makes sense and my initial comment may have been incorrect. I guess the idea is something like:

- a general purpose API is insufficient for any particular application, each application will require a special-purpose API alongside the general API

- assuming that you are going to have an application-specific API, it makes sense that the application-specific API should serve data specifically-tailored to that application (in this case hypermedia)

That said, it seems like the most interesting discussion would be about the tradeoffs between the two-JSON-API solution that they reference and the one-JSON-API + one-HTML-API solution that they suggest.

I could be misunderstanding of course, but IMO this article is basically misleading or incorrect. If everything else is the same, a JSON API is strictly more flexible than the corresponding HTML API because JSON is a strictly more flexible serialization format than HTML. You have a database on one side of a network and clients on the other side. If you bind your data to a specific client on the database side of the network, your system is less flexible.

N.B. I am not making any claims about whether any particular HTTP API should serve JSON or HTML, I’m just saying that JSON is a strictly more flexible option.

This is not a direct answer to your question, but performance is better in terms of the _quality_ of completions but not in terms of price, latency, or uptime.

People have already started writing the languages. Here's an example that I think is really neat: https://github.com/jbrukh/gpt-jargon.

I haven't really looked into either. So far I've tested pinecone, Redis, chroma, elasticsearch, and pgvector. I'm not really considering performance at all, just looking for something dead-simple to deploy and use. At the moment it looks like pgvector on supabase is the winner.

FWIW supabase recently added support:

https://supabase.com/docs/guides/database/extensions/pgvecto...

I'm currently evaluating different vector stores and passed on Redis today after spending about a half day looking into it. Here's my reasoning

    1. The Node.js client is designed to be just a thin wrapper around Redis commands. The client's docs basically just point you straight at the Redis docs.

    2. The `@redis/search` API is slightly different than the FS.SEARCH Redis command's api. The difference is not documented and cost me ~20 minutes. This is a pretty big problem given item 1.

    3. The `@redis/search` TypeScript types didn't allow some valid FS.SEARCH calls.

One thing to note is that for some use cases (IMO probably a large fraction of use cases right now), the vectors are derived data, so you don't necessarily need a super robust/battle-tested "database", you just need something with a simple happy-path API.

> 'Juice' was our wet little term for constant & bountiful user feedback. A juicy game element will bounce & wiggle & squirt & make a little noise when you touch it. A juicy game feels alive & responds to everything you do - tons of cascading action & response for minimal user input. It makes the player feel powerful & in control of the world, & it coaches them through the rules of the game by constantly letting them know on a per-interaction basis how they are doing.

I feel like really high-quality software systems have this same feel, they allow a developer to dive in and splash around and get tons of salient feedback.

It sounds like you might have it backwards. The API spec is published by you and the AI consumes it.

LLM infrastructure is the spot to be right now for startups.

I mean yeah, you'll have to provide a data model (and data) that other people don't have.

Ironically, LangChain is basically DOA with OpenAI's plugins release. LangChain would still be useful for multi-model applications, but every other sufficiently powerful model will probably just build the same thing.

I don't think this is the case. You provide an API spec but you also have to provide the implementation of that API. ChatGPT is basically a concierge between your API and the user.

IMO you won't even need to build the app, you'll just provide a data model and some natural language descriptions of what you want your product to do.

Related: I've been seeing a ton of news/references to LangChain recently. My own team is working closely with LLMs, and my non-technical cofounder is pushing hard for us to adopt LangChain as one of our core tools. So I spent a couple days diving into the LangChain codebase and I just don't understand why I would use LangChain. It feels to me like almost all of the LangChain codebase is dedicated to solving non-complex problems or interfacing with dozens on dozens of third-party APIs.

All that said, the LangChain team looks solid, they've definitely been shipping code fast, tons of people have committed to the ecosystem, they raised a bunch of money, and I'm a huge believer in just going with standards.

Has anyone here worked through this same dilemma, or a similar one, and could maybe help me with how I should be thinking about it?

The number of people on HN b****ing about people shipping MVPs that build on OpenAI is hilarious and makes me feel like HN has definitely jumped the shark.

If you already have a decent understanding of Docker you could implement this without learning anything more about Docker. GitHub secrets, actions, `ssh`, and a simple VPS (like an EC2 instance) would work here, no?

I agree she was being unreasonable. The article claims that 3%-5% of people are "terrible" and "just wanted to be mean, nasty, selfish brutes" and the quote I used was used by the author as evidence for that claim. The author takes a situation where someone was being unreasonable and then throws in a hypothesis based on tenuous reasoning.

In my experience people who express this kind of view (a slightly-sweeping, slightly-cynical take on the prevalence of shitty people) also tend to be epistemically overconfident of their grasp on social situations. For example, my opinion of the following quote is that it sounds contrived (Not contrived for the blog post, but contrived in the sense that the "brought the hair with her" hypothesis is itself contrived).

> My experience serving/bartending in restaurants was the same... As an example: one time a lady threw a huge fit about a 2-3 inch smooth brown hair being in her meal when her server was a blond girl and the entire kitchen staff were 35+ year-old Mexicans/ African Americans with completely shaved heads. Now I'm not saying this woman brought the hair into the restaurant and planted it in her meal... but I know for a fact it couldn't have been from any of our staff in the restaurant, so you can make your own decision.

My take is that there's less shitty people and more shitty Bayesians :)

Oooh boy, big boots to fill. Related/aside: I've had this silly whimsical idea for a couple years of a Broadway adaptation of Neuromancer starring (and with music written by) Logic.

This is where my thoughts went as well: it's like a data structure that includes 2 numbers and their sum. Then I thought that this particular operation is not just a sum and having the memoized value could make sense: using GPT to generate the commit message for a few thousand commits would be pretty expensive.

Look for an email from achilles@relay.cc :) I'm building https://github.com/relaycc/receiver, and we're hiring.

One piece that is for some reason insanely undervalued right now is: a global key sharing system with a baked-in reputation mechanism (you can burn cash to prove to the world you care about your public key). Combined with a human-readable naming system (like https://ens.domains/ or https://www.lens.xyz/), you've got the world's simplest and most useful auth system. SIWE (https://login.xyz/) is going to be the de-facto auth standard for all new web applications at some point in the near-ish future.