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

Points: 12

# Comments: 2

- Variable scoping https://developer.mozilla.org/en-US/docs/Web/XML/XSLT/Refere...

- Function definition and application https://developer.mozilla.org/en-US/docs/Web/XML/XSLT/Refere...

- Flow control https://developer.mozilla.org/en-US/docs/Web/XML/XSLT/Refere...

- Loops https://developer.mozilla.org/en-US/docs/Web/XML/XSLT/Refere...

- Module system https://developer.mozilla.org/en-US/docs/Web/XML/XSLT/Refere...

Yep, it's a programming language. And not a great one!

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

Points: 2

# Comments: 0

The voter could go to a polling place afterwards and attempt to cast a provisional ballot but my understanding is that this is difficult, varies significantly state to state, and in many cases is not possible given that mail in ballots are detached from the voter identity ahead of Election Day in many states.

You pretty clearly laid out what you meant by server rendered in your original comment:

> Were I forced to write a website today, it’d still end up looking similar to a traditional Django server-side rendering system with pages, and deep links, and all that.

Nowhere did I advocate leaping to SPAs for no reason. I simply made the case - and stand by it - that building with the same set of technologies client and server side leads to more flexibility and less code.

Re: the comment about booting the app, I think that is one of the strongest arguments in favor of server rendered apps, which is why I qualified my comment to "interactions", which happen after the page loads.

I lived through the server-rendering-only days of the original Hotmail client, and the php-plus-jquery spaghetti era. They were terrible for developers and terrible for users. Going backwards would be a huge mistake.

Also think about what actually has to happen when you interact with a server rendered app vs a client rendered app. Once the client app is booted you don't have to pay network latency, html parsing, FOUC etc on every interaction as you would with a server rendered app.

Purely server rendered apps tend to have much slower interactions and exhibit weird behaviors so it is valuable to be able to do some stuff on the client.

Dagster is the data orchestration platform built for productivity. Data engineers all around the world, in every industry, use Dagster to build scalable and maintainable data applications like ETL pipelines, ML training pipelines, data integrations and similar systems.

Data applications are the true core of AI and ML training systems, and our goal is to make Dagster the de facto standard for structuring these systems.

We’re an early stage, well-funded startup team with a proven track record of shipping open source software with global adoption. We put a premium on respectful, clear, and complete communication, and we expect each other to be creative, curious, effective, and empathetic.

More info: https://www.dagster.io/careers

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

Points: 1

# Comments: 0

Spirit was Boeing Wichita until 2005, and today Boeing represents 85% of sales.

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

Points: 2

# Comments: 0

Their founder and CEO created The Algorithm at Instagram. Rest of the team is super strong too. Makes a lot of sense for OpenAI to acquire a team at the intersection of AI and consumer products.

This dumb technique is actually pretty useful for a lot of people though, and has the advantages of being super easy to parallelize and requiring only 1 pass through the data.

The more advanced technique does a pass through large chunks of the transcript to create lists of chapters in each chunk. Then it combines them to a single canonical chapter list with timestamps (it usually takes a few tries for the model to get it right). Then it does a second pass through the transcript, summarizing the content for each chapter.

The end result is a lot more useful, but is way slower and more expensive.

Yes it's a great idea and I have a version that is basically a convolution over the transcript. It works much better than the current version - it can automatically create cohesive chapters and summaries of those chapters - however, it consumes an order of magnitude more ChatGPT API calls making it uneconomical (for now!)