Hacker Newsnew | past | comments | ask | show | jobs | submit | quibono's commentslogin

Great list, thank you. I recently switched to a Macbook for work and I could feel the difference in speed whenever I used Emacs back on my desktop (Linux).

This helps a bit though magit still feels very sluggish.


Nice, and I understand why using `getAuthorNames` solves the N+1 here.

But... isn't this solving the problem by removing most of what makes it an issue in the first place? I imagine most people use ORMs for the SQL <-> native class data sync capability. And this assumes one would run the Acadia query instead.

FWIW I'm not trying to be negative, it's just my general impression is that these N+1 usually occur because people _want_ direct object access and _want_ to write loops, and _want_ to access fields and have the underlying SQL be sorted by the ORM.


As far as I understand Acadia gives you Acadia <-> Native class data sync, only just Haskell and Elm at the moment unfortunately.

I'd be willing to rewrite queries in some other language that transpiles to SQL if it allows me to do all the queries I want and gives me full compile time type support for db access in return.

The policies look interesting too by the way, but they don't solve a major IMO.


> I'd be willing to rewrite queries in some other language that transpiles to SQL if it allows me to do all the queries I want and gives me full compile time type support for db access in return.

Full typed coverage for db is what I'm doing in Typegres [1] -- including all dialect built-in functions/operators.

And regarding policy, instead of RLS it's all based on ocap: reachability is permission. So: `api.user.posts()` automatically injects a `where` clause on the `users` table and it's composable wherever a SQL set expression is allowed: `api.user.posts().join(...).groupBy(...)`. Since we're building up a SQL expression tree, we avoid the N+1 problem entirely.

[1] https://typegres.com/


This is my experience too. The solution is to train people to stop wanting to solve data query problems in the application layer.


Yes, this does essentially nothing to solve the 1+N query problem. If your solution was to to stuff everything into one query, this was already possible with SQL!


Similar to vomit[0] and claudish-to-english[1].

My general feeling here is that this really needs to be fixed at the model level. All other solutions are mere hacks that work for a bit but all have drawbacks. It's either adding yet more context (which has variable rates of success) or piping to a different model to translate, or using a skill, or mentioning this per each prompt, or....

At this point I think it's in Opus's nature to talk like this, and given enough back-and-forth it will start to drift back to its classic mode, aka this incomprehensible "load-bearing seam" babble.

[0] https://github.com/zachahn/vomit/tree/main

[1] https://github.com/gvzdv/claudish-to-english


I love the information density on that page. Feels like very fresh compared to today's minimal pages.


You'll love this one then:

https://people.idsia.ch/~juergen/

Just, whatever you do, do NOT press the red button!


Old school Japanese sites - same vibe.


Could you provide more detail please? Sounds interesting.

Is this a hardcoded limit or something relative to the input prompt etc.?


I hate the Opus 5 writing style. I’m not sure if it’s just how much exposure I’ve had to it recently but working with it is incredibly tiring.

I know the “instruct model to change output style” is supposed to reduce efficiency - but has anyone experimented with prompts like that? At this point I’m happy to take a slight intelligence/ effectiveness loss for less verbose, artisan and elliptic writing.


"Save in memory to always use ASD-STE100 Simplified Technical English when you talk to me"

Fixed for me. Now the text outputs and comments are pretty easy to follow and read.


Nice! I like this, not a connection I would have thought of!

> Therefore, if the artist did not truly experience the feelings, the piece of work they produce would not be sincere, and hence not art. This also covers malicious attempts to produce a piece of art without having experienced the feelings. As the art is a successful representation of the agreed upon feelings, and the art is a Tolstoyan piece of art, the artist must have truly experienced them.

Isn't that circular? If I "fake" a Jackson Pollock style painting without having any feeling whatsoever AND it manages to evoke feelings in the viewer, who's to say which feelings are the agreed upon ones?


Tolstoy is generally not thought of as a great critic or philosopher.

I don't think it is circular however, if you did not have any feelings and others got feelings from looking at what you did then you did not produce art. If they then went and produced some art based on the feelings they had received from the non-art you produced what they produced would be art.

It's not very well thought out, but not per se circular.


Yes, good point!

I guess what I meant was: the only way for art to meet one of the ZKP criteria is for us to assume it's art.


Yeah this is true, I suppose I sort of swipe it under the rug in the post. Another way to say it is: If the art is Tolstoyan, then we have that it is valid to be used in the ZKP.


> scary rebase -i commands that can leave your tree in a half-broken state if you so much as sneeze

I'm glad to hear it, I thought that was just me. It gets especially hairy when moving commits around...

Plus I have 3-way diffs enabled and I usually get confused by which section is which at least once a day.

Also: does anyone know if `magit` has history support?


Not as such, but out of the box you get reword and fixup as first-class rebase macros. I use them all the time.

If you wanted to split a commit you'd still have to use a magit-assisted rebase.

So if magit added explicit 'history' support I just about wouldn't notice, it would mostly be under the hood.


100% agree, the fixup macro is amazing. It even fails gracefully when unable to commit for whatever reason.

The split one would be handy though.


> Doesn’t mean nothing happend, just that it can be difficult to figure out what is myth and what are actual events.

Sure. Although I'd say that if you want to study history that's _all_ you can do - use different sources, corroborate, cross-check, link and, generally, try to make the different events and interpretation "fit" together. If you have no documentation for it or supporting evidence then you've got nothing to work with.

Otherwise one could just use a semi-apologetic argument: the Exodus story DID happen as outlined in OT but God hid all signs of it so it couldn't be confirmed.


>If you have no documentation for it or supporting evidence then you've got nothing to work with

Sure, but I think 1) a lot of objections in this thread come because people seem to conflate "nothing to work with" and "so obviously it didn't happen" and 2) there's not no documentation for anything people have argued about in here.

A big disagreement that's probably been unsaid in this thread has more to do what counts as corroboration. Speaking abstractly, I think that if a group of people from 500 years ago strongly attest to something that happened 1000 years ago, that is not definitive proof in and of itself, but it is absolutely a form of supporting evidence.


I have a question related to aviation though not the submission itself please.

How often would you say you get to do a non-ILS landing? I often wonder how common these are outside of North America (where I hear visual approaches are apparently way more common than in Europe).

And related to that, how often do you see VOR approaches in the wild?


As for VOR approaches, I have done a handful in my career, especially into some of the smaller airports around Europe (Greek islands!), but these are gradually also being replaced with RNAV approaches generally.

On the A320 which I flew at the time, even VOR approaches were flown using a coded approach path, with the VOR needle itself being used for crosschecking. In the sim, we fly them still to make sure we remember how to, but they are quite rare these days!


Thank you!


Valid question!

The vast majority of approaches are still using an ILS. Pretty much the only time we would use an alternative approach (most often RNAV or LPV, and rarely VOR) would be if an ILS is not available.

That said, in the US especially, controllers are quite keen to offer a "visual approach" as it then relieves them of the duty to maintain separation from the aircraft in front. This is a cultural thing in the US, and the rest of the world does not operate this way. Even when flying a "visual approach" in the US, the ILS is usually still radiating, and we often still fly the approach using the autopilot coupled to the ILS, just maintaining our own separation from other traffic visually.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: