chapel

Someone using an LLM to code isn't calling themselves a great coder just because the LLM is writing good code. Being a software engineer/developer (whatever you want to call it) is not defined solely on your ability to write code.

To go back to your point, before the F1 driver (LLM) was hired the owner was the driver, mechanic, and everything else. Now that they have a driver they can focus on all the other roles and just ensure the driver is not crashing.

Read the first paragraph could tell it was AI written. Maybe if it was hand edited to be less AI I would have read more but it looked like the laziest Claude prose.

That'll be a no from me dawg.

I agree on the point of linking it, which the HN thread linked before supposedly had a link to the blog post in question but it did not have any content. So thanks for sharing nonetheless.

I've done similar, even to the point of a discord gateway integration that is very similar to the one Hermes ships with.

I still use Hermes because it's not a problem I care about solving right now and am spending my time and tokens on more important problems. I don't plan to always use it, and if anything it gives me ideas for what the ideal shape of what I want would be.

Also to add, having a unified space to chat with an agent that has a local system it can work with is quite liberating because I use it to drive my agent orchestration system. So I'm no longer bound to my computer or any one providers harness and whatever mobile solution they provide if any. It's been quite freeing and I don't use Hermes that differently than I would chatgpt, except it know exactly how I like to do my work and that means I have to remind it less.

Did you read it? Given it's all AI slop I wouldn't be surprised if not, but the claim is basically "I had this idea first, I think they stole it from me."

Not that they stole code or even copy, just the idea from a completely open source project (at the time).

Given how many people have posted and released similar systems over the time skills came out and even before, that's a huge claim with no substance to back it.

Those Python issues are things I had to deal with earlier last year with Claude Sonnet 3.7, 4.0, and to a lesser extent Opus 4.0 when it was available in Claude Code.

In the Python projects I've been using Opus 4.5 with, it hasn't been showing those issues as often, but then again the projects are throwaway and I cared more about the output than the code itself.

The nice thing about these agentic tools is that if you setup feedback loops for them, they tend to fix issues that are brought up. So much of what you bring up can be caught by linting.

The biggest unlock for me with these tools is not letting the context get bloated, not using compaction, and focusing on small chunks of work and clearing the context before working on something else.

This isn't mine, I found it posted on a gaming forum and thought it would be interesting to others here.

Having read the post, I feel the title here doesn't do it justice. It is also missing half of the title.

Title on HN at time of comment: "Silicon Valley Could Learn a Lot from Skater Culture"

As far as the article, I wasn't aware of the schism in the 80s around skateboarding culture. I was too young, but even looking back through documentaries and other media about the history, it seems to have been revised to ignore it.

I think the article is overall positive, in that there are things to learn so long as we don't ignore the context and the bad side of what has happened in the past.

In the case of the JS solution, it runs horribly and is highly inefficient.[0]

For non-hot code, it is perfectly fine, but in this case, inside of a main loop like this it is a waste of cpu cyles. Compare the amount of forests here:

   $ node orig-magicForest.js 117 155 106
   total forests: 1522899
   { goats: 0, wolves: 0, lions: 223 }
   total time: 816ms

   $ node new-magicForest.js 117 155 106
   total forests: 428
   { goats: 0, wolves: 0, lions: 223 }
   total time: 6ms

[0] https://gist.github.com/chapel/1c038b2bf64b3037aaea

The code is very inefficient to say the least.

I made some modifications (diverging further from the "functional" nature, if you could call it that) and as you can see it is much faster[0].

Output:

  $ node new-magicForest.js 2017 2055 2006
  total forests: 6128
  { goats: 0, wolves: 0, lions: 4023 }
  total time: 20ms

[0] https://gist.github.com/chapel/1c038b2bf64b3037aaea

I think there is a disconnect between what an artist might expect to receive and what a listener would actually pay.

Even before streaming radio became the standard way of listening to music, people didn't pay every time they played a song. They paid for the rights to listen to it as much as they wanted, but they only paid that once.

Now that we have streaming, consumption is different, and artists actually get paid per listen. They can't expect to get the same amount per listen that they got per song on a CD years ago.

You really shouldn't get into music for the money, because there isn't money anymore. The fact that there was money ever was a blip on the radar due to new technology allowing an industry to explode. Technology continued on though, and made the scarcity of music artificial.

This blog post is way off. The issue isn't that Google Maps couldn't find Sambisa Forest, it is that it has an issue with how it handles auto complete and pressing enter without selecting the choices it brings up. It quite frankly looks like a bug. You can see for yourself here: http://i.imgur.com/vX1xqp2.gif

What if they already get a placement fee? That would mean they make money on the front and backend, which if they dropped their tuition fees, would drop their income.

That centralized party is a weak link, and in the case of SR, compromised all BC wallet ids that were used as well as the bitcoins stored.

I see there is no information about cost. Are there any plans to charge, and if so what would you charge?

Maybe a $25-$35 year plan would make sense depending on how often the wakeup calls are needed.

This is essentially how I have been writing JavaScript and Node.js code for some time. I actually flatten the code even more, like in these examples[0].

For some people, callbacks take more cognition than other solutions, but for someone who has been using callbacks through and through, this is a natural progression and makes sense. It is more straightforward and you don't have to understand further abstractions like in a compile to JS language or with promises.

[0]: https://gist.github.com/chapel/6255720