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

It's a tough game for Perplexity as long as they use Google's search, and with Google now providing "AI Summaries," and with the whole ad ecosystem (invented by Google) designed to turn us into predictable consuming robots, what's a pre-IPO company going to do? Fight the good fight and stick with a subscription model, or knuckle under and start sending us Google ads?

Sucks. I will say this though: as soon as I see ads in my Perplexity search results, I'm cancelling my paid subscription and simply going back to Google. Without any other differentiating feature set, why would I pay Perplexity?

RIP, Perplexity; it was good while it lasted.


Ads are already in the paid subscription (this is a thing they've telegraphed since the beginning of last year?) So you will definitely see them sooner rather than later. But i 100% agree. There's no real reason to pay for the privilege of ads.


How about looking at an ast-based method for making changes across code base? https://www.reddit.com/r/Python/comments/17tvm06/astgrep_and...


I think this is going to be the answer eventually.

Once one of the AI companies figures out a decent (probably treesitter-based) language to express code selections and code changes in, and then trains a good model on it, they're going to blow everyone else out of the water.

This would help with "context management" tremendously, as it would let the LLM ask for things like "all functions that are callers of this function", without having to load in entire files. Some simpler refactorings could also be performed by just writing smart queries.


Bullshit.


Reading these comments after falling asleep to SNL sketch re-runs. They all sound oddly sarcastic and ironic.


Good article. I, too, am fascinated by calculators and how they work, especially the HP scientific RPN calculators. So much so, that I ended up developing this:

https://play.google.com/store/apps/details?id=com.limpidfox....


Reading down further I see this is a follow-up to "40 Algorithms Every Programmer Should Know". So, is this new book the same 40 algorithms from the prior book with 10 added?

If so, perhaps the real book could be called "The One Book Writing Algorithm You Will Ever Need."


Personally I'm holding out for "The ten algorithms that every programmer that needs to know 50 algorithms should know, but are dispensable for programmers that only need to know 40". I feel it could be a real gem, but when will O'Reilly deliver??


> The One Book Writing Algorithm You Will Ever Need.*

* until we publish the next one


The gp means they’ll use the same algorithm to publish the next book.


The android app wants full access to the file system? With the "trust us, we'll only really access the folder you tell us to..."?

Am I reading that right?


You can find an explanation of the Android permissions on the Obsidian Help site: https://help.obsidian.md/Obsidian/Android+app#Storage+permis...

Obsidian can't use scoped storage because:

> 1. Scoped storage doesn't provide a way to watch for external changes, which is critical when using Obsidian with a third-party syncing tool.

> 2. Scoped storage performs many extra permission checks for every single file access, causing significant performance degradation when opening and using Obsidian.


Android has moved to a file system model that generally locks app out of having full control of any folder but the one created for the app. The only way to let your app have read-write-create permissions is to request access to the whole file system. And IIRC, you have to get permission from Google to even request it.

It makes it very difficult to have something like a Git client on Android as well, as the permission to request file system access is not easily granted.


It's like Game of Thrones - without the intelligent intrigue.


Wow. I see almost nothing controversial in the McKinsey article. In a nutshell it addresses hard metrics (DORA) gathered via the repo tooling (commits, MRs, etc) which is enhanced with some outcome metrics, and they combine with soft metrics (SPACE) which are inevitably fluffy on the numbers combined with some other measurements to fill out arguable gaps. But overall, it didn't read like a manifesto.

As far as the criticism from the "ex-finance developers" - yeah, some of whom have done a lot of other noteworthy things outside of "fintech". I don't think it was overly harsh. In fact, maybe just focusing in on certain things that inevitably leave a bad taste - such as assigning numbers to human being's activities or otherwise trying to distill human activity down to hard numbers can lead to abuse - no kidding - almost a tautological argument.

That said, happy people with a shared vision and supportive management delivering a product/idea that is contributing to the team's concept of "the greater good" will always be the sweet spot for productivity.

I would lean more towards the SPACE metrics as the best way to measure, but allow that hard metrics such as DORA can be helpful as alarm bells.


Pair programming can be a productive, even fun, activity in limited situations. Now that we have the option of our pairing partner being human or AI, it sort of highlights a lot of the situations where pair programming is NOT productive, or even fun.


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

Search: