One trick that I always find helpful is to unroll the subqueries into a long sequence of CTEs. You can do a depth first traversal of whatever data structure produces your subqueries and build a list of CTEs as you go (and track of all the CTE names of course). The ordering 'just works'!

Slightly nicer SQL doesn't seem important at first for stuff like this, but it's actually a godsend for debugging. Every operation in the query gets a name that's accessible in the outermost scope, so you can slap a `select * from cochoice_abc123` on the end and see what's going on.

Figuring out what's going on in those subqueries was no doubt hellish at times.

It's definitely worth learning SQL very well, but you also need to learn the data structures your RDBMS uses, how queries translate into operations on that data, and what those operations look like in a query plan.

You can go surprisingly far with just that knowledge.

A great resource is https://use-the-index-luke.com/

I also came "from above".

In my experience, the average programmer isn’t even aware of the stack vs heap distinction these days. If you learned to write code in something like Python then coming at Go from “above” this will just work the way you expect.

If you come at Go from “below” then yeah it’s a bit weird.

It generally happens when the grammar is highly constrained, for example if a boolean is expected next.

If the model assigns a low probability to both true and false coming next, then the sampling strategy will pick whichever one happens to score highest. Most tokens have very similar probabilities close to 0 most of the time, and if you're picking between two of these then the result will often feel random.

It's always the result of a bad prompt though, if you improve the prompt so that the model understands the task better, then there will then be a clear difference in the scores the tokens get, and so it seems less random.

It's easy to make the case that an LLM 'program' is homoiconic, as the code and the data are all just plain text.

LLMs also offer rich metaprogramming (prompts that write prompts).

They even arguably offer features like CL's condition system.

Of course, they don't operate on symbolic expressions, so it's a stretch to actually call them a lisp (or any other programming language), but they seem to share a lot of the same properties.

Comments URL: https://news.ycombinator.com/item?id=45386691

Points: 6

# Comments: 2

Sadly it's a few decades too late though, and sadly this just fragments the "ecosystem" further.

I reached several quintillion stimulation, at which point I was offered to purchase "go to the beach" for 2 million. This ends the game and plays a relaxing beach video.

You too can get to the beach in just 5 minutes.

There is only one standard of accomplishment and it's set by people like Mozart.

Accepting that is humbling, but it's required to know yourself and grow. My contributions probably won't amount to much, but Mozart (et al) have shown us what good looks like and it's fun to strive.

I think a lot of VC backed founders aren't just in it because they want to get rich though. Sure, we all want that, but we're also all predisposed to irrationally believe that we're the exception. That trait (for better or worse) comes with implications, and many founders I speak to are simply compelled to try because it's hard, and it's theirs, and they're impatient.

I also very much agree with the sibling though. Getting rejected does not carry that much signal, because YC are wrong more than they're right. So just keep trying.

As you say, a lot of YC founders don't have a real business yet, but they're not there because they're well connected. They're there because YC thinks they fit the profile of someone who really wants to build a big business and might pull it off. They're wrong most of the time but it's a numbers game.

We wanted to write abstractions so that we could reuse code. We wanted to bundle those abstractions into libraries. We wanted to statically analyze our models so that we caught more errors before production. We wanted a fast unit test suite that you could iterate on locally without connecting to a data warehouse.

In short, we wanted to use all the same practices we used for building our other software. Tools like dbt made a great start at importing these kinds of practices into analytics, but there are many great aspects of the software engineering workflow that still aren't easy to replicate in data.

We've found it to be a super productive way to work, and we thought others might want to use it too. It's very early days so we've put up a page for to explain it, and we've made some executable examples for people to have a go. Let us know what you think!

FAQ:

Is NASTY an ORM? A SQL builder?

Neither! NASTY is kinda it's own thing. NASTY is more like a minimal relational algebra programming language shipped as a Typescript library. It borrows a bunch of learnings from other programming languages and applies them to OLAP programming / data engineering. It's an important distinction, because it totally changes the way you can think about building transformations.

Why TypeScript? Why not Python?

The 100% honest answer is we had a ton of typescript experience and we had a node/react app with pulumi's TS apis. We like typescript and by being a library instead of a full programming language, we can leverage things like vitest, eslint, node, TS's language server, TSdoc, etc.

Comments URL: https://news.ycombinator.com/item?id=39641713

Points: 47

# Comments: 6

As far as how to conduct these sorts of interviews goes, a few people have mentioned the mom test - it's v short and simple but it is indeed good. People, for the most part, avoid conflict and so don't give you honest feedback. Instead they tend to be complimentary, but non-committal. As a result, you need to be a little indirect in your line of questioning, and pay more attention to what they do than what they say.

When it comes to testing a product, try and deliver the value manually instead. Businesses don't buy software, they buy solutions to problems. Software is just a way to deliver the solution to many customers. If you can't convince someone to pay you to keep their menu up to date by hand, they won't pay for your software to do it either. Perhaps you convince them to give you the relevant credentials to update menus across platforms yourself, and then they email you when something changes, or you give them a google form, or you go into the restaurant every day and ask what's new. Not everyone is open to working with someone in a scrappy way like this, but you'd be surprised.

You can easily serve a handful of customers manually like this, which will give you the data you need to decide if it's worth it, and the data you need to build the product.

Anyway, good luck!