For the best experience on desktop, install the Chrome extension to track your reading on news.ycombinator.com
Hacker Newsnew | past | comments | ask | show | jobs | submit | history | terrabitz's commentsregister

It's not inherently contradictory, just like using a calculator could be considered cheating depending on the context. If you're just learning basic arithmetic, a calculator is cheating since it shortcuts the path to learning. OTOH in calculus, a calculator is necessary. You still have to have a deep understanding of the concepts and functions to succeed.

It's still a new tech so I'm not surprised a lot of teachers have different takes on it. But when it comes to education, I feel like different policies are reasonable. In some cases it's more likely to shortcut learning, and in other cases it's more likely to encourage learning. It's not entirely one or the other.


A better example might be physics and math classes. I was learned derivatives and integrals at the same time in those two classes, but the math one required we learn how it all works (using limits to understand why the derivative rules work, without using calculators, for example), while in physics we just memorized the rules and were expected to use the calculator.

I always thought they should teach calculus first.

Why do you need a calculator for calculus?!?

Gotta add up all the curves

Exactly, AI is the next calculator. Right now the consensus is that it just does the work for you, in my opinion that says more about us not having the right questions than actual laziness. In a world where the only questions are basic arithmetic, calculators do all the work for you. My opinion is that the future what used to be done by academics will be done by high schoolers and new academics will be producing work at a rate no one could’ve ever predicted.

For example, the professor who’s leading me in this project had a fellowship at a certain university in England and said he exclusively coded using claude code for a month straight, their purpose was to solve a vaccine for a specific disease and by using AI tools such as claude code they’re several months ahead of schedule.


Yeah I was getting the same feeling. I wonder if an equivalent request to California police agencies that contract Flock technologies would work though.

Probably not, as the law enforcement agencies get a bunch of exceptions to the CCPA.

Sounds like a similar approach to this service: https://addy.io/

I use it all the time in conjunction with Bitwarden to generate unique emails per site. You can have notes in each email, and they show up in a small banner on in the forwarded email. And each one is individually disable-able, so you can easily cut it off if you see spam from it.

I was really interested in this space and made my own homegrown tool for this. I used it for a while until I discovered Addy and switched over. IIRC there are similar services by Mozilla, Apple, and Proton.


The 90-90 rule may need an update for a POST-LLM world

"The first 90% of the code accounts for the first 9% of the development time. The remaining 10% of the code accounts for the other 9000% of the development time"


No, two completely separate players. There was a partnership agreement a while ago, but that got severed a while back

https://www.flocksafety.com/blog/axon-plans-to-sever-apis-wi...


A while ago when I was working with PowerShell a lot, I got spoiled by the easy inclusion of `-DryRun` flags in all my scripts.

Nowadays I still use the technique for a lot of the tools I make. I typically do a Terraform-like approach: create a plan, validate the plan, render the plan to the user, exit early if we're in dry-run mode, and apply the plan as the final step. Whether dry-run is enabled by default depends on the risk of the operations and who will be using the tool.

This makes it exceedingly clear what actions the tool will do. Plus it has the added benefit of being able to split the plan and apply steps into two separate steps. For example, you can create a plan, serialize it to JSON, store it (e.g. in VCS, Jira ticket, whatever) then apply it during a change window.

  plan = createPlan()
  print(plan.string())
  if (dryRun){
   return
  }
  
  plan.apply()


I feel like the distinction between the two is fairly contrived these days. I'm an SRE, and we're constantly building tooling to help us better manage infrastructure, improve reliability, improve DX, etc. On the flip side, we also push a lot of the responsibility for infrastructure management to our devs: we maintain the modules and IaC pipelines, and the developers hook up the building blocks they need. It can actually help avoid burnout because our team doesn't become a bottleneck for infrastructure provisioning.

Say what you want about IaC in Go or other programming languages, but it can definitely help strengthen the whole "developers own their infrastructure" since they don't have to learn an additional language syntax.


> The best rule of thumb is, if you’re not sure whether something needs to be said right now, hold off and see what happens. You can always say it later if it turns out there’s no way for the conversation to move forward without your correction.

From the context, it sounds like it's not so much about "don't correct people" as much as it's about "don't uselessly correct someone to showcase your own knowledge and not advance the conversation".


Nice, that's a big differentiator! I use git sync with my mobile vault, but it's very hacky (using a Termux cronjon) and it's often flaky. Plus I have to open up Termux any time I need to troubleshoot, which is a bit annoying.


I like having my recipes in digital format, but the lack of notes, annotations, and editing history is a big weakness in most of them. I would love one that offered a git-like interface for recipes: it could track the "diff" of a recipe as you tweak it, and you could "commit" each variation along with notes about the outcome.


I'm not much of a cooker, but I helped my spouse organize her recipes into a little site. The backend is just a SMB file share with one text file per recipe. And there's a perl script that looks for changes, generates the HTML, and pushes it out to the web, so it's easy to reference on the go, maybe while at the grocery store or something. The perl script needs to do a bit of magic around character set detection, because windows likes to do dumb things, but otherwise, it's pretty straight forward, other than kqueue is a bit arduious for watching a whole directory tree (I think Linux has a better api for that, but it's doable in kqueue).

No diff tracking, but you can put notes in as you like, it's just text. You could use git as others suggested too. It's just text, git is good for changes in text files.


I started transcribing them. I’ve been using typst, could probably change back to latex or context or something if needed. I have a git repo, organized in to several sections. I found a template and hacked it to my liking, including a section for comments and remarks and then organized the sections in to chapters.

Took an hour or so to kind of get the framework in to place. We do family meals regularly (eat with your kids, it’s a good thing) and I record the ones they like, add notes as we change them. It’s sort of a secret project, I plan on giving it to my kids as a wedding gift or something. Only about 30 in it so far but I add one or two a month, I try to capture some pictures to go with it.


Why not just put your recipies in a text editor and then use git?


A generational git repo of family knowledge is a fun idea to think about.

>Hey grandpa, can you show me the family brisket recipe?

>Sure grandson. But first, let me tell you what git is.


Throw pandoc into the workflow, and have a new edition printed every year or three at your local print shop.


In the editor, make sure to M-x org-mode. Lots of dated annotations, and a lot of results, in my many recipe files.


Honestly, not a bad idea. I'd just have to deal with figuring out a good, standardized text-based format. I already use a git-backed Obsidian markdown knowledge base for most of my notes, so it would make a lot of sense to incorporate recipes too.

I think my current recipes app stores entries in the Recipe JSON Schema format[1]. This format is also useful since many websites will offer recipes in that schema. If I could make a conversion layer that transformed between a markdown version and the JSON recipe schema, that would probably be all I need.

* [1] https://schema.org/Recipe


I've looked at a few and I haven't loved any of them. They all have some kind of shortcoming that makes them not usable.

For example, the schema.org schema puts quantities, units, and ingredients in a single field. Fail, IMO.

Other issues include things like not being able to group ingredients or procedures.

I don't have my notes on what I thought of each of the ones I've reviewed handy, but here are some I've looked at:

- https://cooklang.org/

- http://www.formatdata.com/recipeml/

- https://recipemd.org/index.html

EDIT - for clarity, added examples of standards


> I'd just have to deal with figuring out a good, standardized text-based format

Why? Recipes are for humans to read, and we're good at accomodating a wide variety of formats as long as they are reasonably sane.


That's what the idea was. Something you could diff and fork (heh) other recipes using git.


Consider applying for YC's Summer 2026 batch! Applications are open till May 4

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

Search:

HN For You