tdfirth

Great post! I've worked on a few query generating systems of varying degrees of complexity, and SQL is pretty rough as a compilation target. I've spent more time than I'd have liked wrestling with queries as comparably ungodly as the beauty you have presented.

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.

No rename symbol? What am I missing? It seems like a no brainer.

If you do backend web development in 99% of software companies then being very good at whatever your RDBMS is is a superpower.

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/

Ha! I had not intended to imply that one is better than the other, but I am glad that it made you feel good :).

I also came "from above".

I don’t think this is confusing to the vast majority of people writing Go.

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.

American hegemony, and all that.

I believe they change color to express emotion.

You're right. How naive of me.

Google kills Gemini cloud services is the best one. I can't believe I haven't seen that joke until today.

In my experience (I've put hundreds of billions of tokens through structured outputs over the last 18 months), I think the answer is yes, but only in edge cases.

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 should have always worked this way. Without this feature you take the algebra out of relational algebra. That's the root of most of the composition issues in SQL.

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

The best strategy is to write a helper function in the console to click for you. Then invest heavily in the DVDs, DVD bounce rate, stimulation per bounce, and general SPS increases.

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.

This is a beautiful comment, and I couldn't agree more.

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.

You're right that I didn't mean to communicate that, but it's a good point. I agree with you entirely that this is the big downside of YC and frankly all VC backed entrepreneurship. It is not the path of highest expected return for a founder. If you want a high expected return then a FAANG job or a bootstrapped SaaS product you can build yourself are good options. Some days that's what I wish I was doing to be honest.

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.

This is the process. They want people with high agency, a bias to action, and who make progress in the face of uncertainty.

This was not my experience. I have no degree, I'm not American, and I applied back in October 2021 about 3 hours before the dead line and filmed my application video from a coffee shop. I didn't have a good network. I didn't have a product yet. I was accepted first time.

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.

I'm in the UK (Oxfordshire) and have a 1gb symmetrical connection at home. It's provided by Gigaclear - there's a handful of other similar operators that do fibre in more "rural" areas. It costs £79 a month, so it's not cheap to be honest, but I love it.

Don't overthink it, just get out there and talk to people. The more the better. In my experience, the limiting factor on day 1 is a lack of information, so your job is to learn until it's fairly obvious what to do. Thinking doesn't really generate new data, only action can, so walk into every restaurant you come across, write cold emails, etc.

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!

Congrats on the launch! It's a bit early for me to try out something like this but I'm keen on exploring a usage based pricing model for my product... I'll come knocking when the time is right :).

This is similar to what I do (although I use esbuild), however like an idiot I just run tsc manually so obviously I forget sometimes and it takes 10 minutes to realise the build failed.

Not great... I'm ashamed but it's just me on this project atm.

edit: misread parent originally

It's an alternative to the X window system:

https://wayland.freedesktop.org/

Appreciate where you're coming from re the detail. It can be hard to know where to draw the line when explaining projects and it depends on the target audience etc.

In this case, I would say it's ok that they don't explain what Wayland is on the project page. Wayland has pretty widespread adoption now and I reckon the vast majority of people that might be interested in projects like tiling window managers for linux will have heard of it (and that has probably been true for quite some time now, Wayland has been around for over a decade).

If you're keen to dig into it more, another popular project in the space is sway https://swaywm.org/.

Cool, thanks for the reply! I hadn't considered the blueshifting part, that makes a lot of sense though.

I also hadn't heard of Hubble's constant, which I am now learning about :). Very mysterious indeed.

This is probably really dumb but I'm interested to hear people's reactions to yet another amateur dark energy theory.

Could the observation that the universe is expanding actually be the result of a sort of gravitational lensing and not the result of space expanding or bodies moving through space?

My rough line of thinking is:

  - We believe that gravity has a warping effect on spacetime.
  - We believe that this warping can distort light.
  - When we observe light from distant galaxies, it must first exit the gravity well of the source, traverse the universe and then make its way down into our gravity well.
  - Therefore, the light must have been subject to some distortion. It traversed two regions of 'stretched' space time and so became 'stretched' itself.
  - This 'stretching' is interpreted as redshift and is indistinguishable from if the light source had just been moving away quickly.

  - Light would be redshifted in every direction as every bright and distant source (i.e. galaxies) resides in a large gravity well.
  - It would explain a lack of redshift in nearby objects as we sit in a broadly similar part of the Milky Way's gravity well. As such the relative lensing effect would not be apparent.

Most likely I don't really understand gravitational lensing and it wouldn't distort the wavelength of light as I suggested. Alternatively, perhaps someone has done the maths and the impact of any such effect does not align with observations.

edit: formatting

Hope this is not off-topic but I just want to say that Kyriakos (the OP) is a great guy. He gave up some of his time earlier this week to help me and my co-founder prep for our YC interview.

We didn't know him before this so I can only conclude it was a genuinely kind act from someone looking to give back to the community.

All the best and good luck with Terra!

This isn't a criticism - I'm just curious to hear people's thoughts on this. When I look at this code, one of my initial reactions is that it does not seem to be very thoroughly tested. Sure, certain modules have been tested (e.g. `model.quat_affine`) but it's not clear how completely. Meanwhile, other modules, for example `model.folding`, have not been tested at all, despite containing large amounts of complex logic. That kind of code that works with arrays is very easy to get wrong and bugs are difficult to spot.

My experience working with code written by researchers is that it frequently contains a large number of bugs, which brings the whole project into question. I've also found that encouraging them to write tests greatly improves the situation. Additionally, when they get the hang of testing they often come to enjoy it, because it gives them a way to work on the code without running the entire pipeline (which is a very slow feedback loop). It also gives them confidence that a change hasn't lead to a subtle bug somewhere.

Again, I'm not criticising. I am aware that there are many ways to produce high quality software and Google/DeepMind have a good reputation for their standards around code review, testing etc. I am, however, interested to understand how the team that wrote this think about and ensure accuracy.

In general, I hope that testing and code review become a central part of the peer review process for this kind of work. Without it, I don't think we can trust results. We wouldn't accept mathematical proofs that contained errors, so why would we accept programs that are full of bugs?

edit: grammar

Hi, I'm Tom.

I'm based in the UK (Oxford). I'm open to a remote co-founder but I'd prefer someone in the UK so we'd be able to meet in person and get to know each other.

I've got a mixed background, I used to work in finance (did the CFA etc) but have worked as an engineer in the data space since 2016. I got to know the data industry and the analytical challenges that finance and marketing teams face really well, and now I want to solve some of the (many) problems I've encountered.

I have spent the last couple of months talking to as many businesses as I can. The goal has been to learn about how others are working and whether they have experienced the same problems as me. I am now quite confident in a few of my market hypotheses and I think I've got a promising direction to take an MVP in.

I've also been looking for a co-founder! I'm interested to meet anyone who is highly motivated, and who has expertise in the industry - either as an engineer or as a PM or in sales. Ideally you'll know what it's like to work for an early stage business, and you need to be willing to commit full time (for the right idea of course!). I will be putting _all_ of my time into this and I need to find someone who is willing to do the same. I think that there is a big opportunity to be had in the B2B data space over the coming decade, and there are loads of great businesses to be built.

If you're interested in setting up a call to get to know each other and see if there's a fit you can reach me at thomas dot d dot firth at gmail dot com.

Cheers!

Tom

edit: grammar

I always go for a simple lisp interpreter. I think this covers a good range of techniques and gives you a pretty good feel for what is/isn't ergonomic in the language.

I don't generally bother with features like macros etc, I just get enough going to define and evaluate functions in a repl. When you keep the scope small like this it doesn't take very long, and it can be broken up into a few fairly well defined evenings - e.g. lex, parse and eval.

One caveat is that if you haven't written a toy interpreter before then it will take you a bit longer. Once you know a little about the common techniques and patterns it's easy though.

edit: grammar

Thanks for sharing this interview. I've seen about 10 minutes so far and I'm hooked. I just love learning about lives that are/were so different to mine.

Yes that comment is where I first saw it, thanks for reminding me.

Thanks for those pointers and the link to your dotfiles too. I will check that out and maybe steal a couple of ideas!!

I've been using this bare repository approach for a while. I forget where I first saw it, I'm pretty sure it was on HN but it was not this project. I do like it, but I have a few minor issues.

The first is that I have a habit of running `git add .` when I'm working on source code, and as a result I have accidentally added my entire home directory to the bare repo more than once... Easy enough to undo but a bit inconvenient. `dotfiles add -u` is the safe option, or just be explicit about which files you are staging.

The second issue is the 'branch per machine' approach, which I do use. I have two machines I use regularly, and a third occasionally. There are some bits of config (e.g. for vim) that are shared across all the machines, while other bits are not. If I use one machine for a while, then I end up with lots commits that I need to cherry pick when I next use another machine. Depending on how long it has been, this can be a bit of a faff.

Finally, because there is no clear mainline branch, you have to pick commits to/from any of the branches. If you are undisciplined like me, then this will leave you with a 'three way ahead and behind' scenario at some point.

Anyway, I like the approach overall. If anyone has a suggestion to ease those pain points I'm all ears.