lemonwaterlime

I use those tools nearly every day. Instead of heavy LSPs and IDEs using the RAM that could be otherwise used, I grep and ctags through my codebase for instant navigation. For deterministic changes if I haven’t already done it in vim, I awk and sed, though usually I do buffer-wide changes in vim for such things. When troubleshooting CLI outputs, especially for binutils and other tools I didn’t write, I still use combinations of awk, sed, and grep.

Not everything is thrown together code churn. Some tools have earned their keep and don’t need to be in the constant spotlight because they do their job silently and effectively for people such as myself on a daily basis.

The issue with all of these schemes is less about the format and more about the semantics itself. What are all the actions that can be done to a codebase and what is a controlled vocabulary that encapsulates those? Then it doesn’t matter what system you use.

I spent some time recently coming to the conclusion that I did not prefer CC, but wanting some reliable structure. In the end, I found I was coming up with convoluted schemes that were getting in the way of actually solving my real problems and just settled on the tried and true:

    “When applied this commit will...”

    - Add <functionality>

    - Update <existing>

    - Refactor <while keeping same boundary behavior>

    - Remove <some subsystem or functionality>

    - Cleanup <documentation or style>

I don’t consider this to be a complete taxonomy, but it does let me get on with my day and covers most things, especially when combined with thoughtful commit messages.

You should look into `update-refs` functionality. By default git treats each branch independently, but with update-refs, git tracks pointers to branches and creates a dependency chain.

I understand your point. The paper is more about the depth of the tree to represent and audit a model versus the raw CPU clock cycles. It takes the exponent and logarithm as given since for all practical purposes, in a scientific context, they are.

To represent something like sin(x) with f(x,y) requires infinite steps. Conversely, with eml you get an exact result in around 4 using identities and such.

One could argue that we do Taylor Series approximations on the hardware to represent trigonometric functions, but that highlights the key aspect of the eml approach. You can write a paper with those four steps that describes an exact model, here sin(x). And people can take that paper and optimize the result. This paper is about an auditable grammar that you can compute with.

I’m fairly certain that the difference between the approaches is that the f(x,y) function you mentioned requires limits to represent certain concepts while the eml approach is essentially a tree or a chain of computations meant to represent a model of a system.

My view is more in line with your statement.

> Prefer do notation if the effects of the flow are more important than the data structure, and prefer using Applicative style if the data structure layout is more important to understand than the effects to build i.

It’s about demonstrating via the diligence that you are a good steward of a fork. This is a requirement of any fork for it to take and be stable.

I understand it is an ideological project. My point is that given their intent, there are things they should do to make their case. They should provide the evidence in the README etc.

If they are correct and things must be done, they aren’t providing the evidence. That’s not the same as saying there’s no evidence or reason to take this stance. Do you see the distinction I am making?

The issue with that stance, practically speaking, is that anyone could have hand-submitted generated code at any time, so why this January cutoff date?

I would expect a decrease in code quality in a specific part of the repo or at least a quote/link to a changelog stating that generated code is being used as part of the fork making its case.

It would be nice if specific offending portions of the codebase were highlighted. As of now, it’s hard to see why one should use this fork. Also, since the source is available, anyone can just compile a past version of vim.