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.
> 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.
See vim-mergetool[1]. I use it to manage merge conflicts and it's quite intuitive. I've resolved conflicts that other people didn't even want to touch.
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.
The challenge for most people is that HTML and Modern CSS are a declarative programming paradigm. You then selectively sprinkle state on top of that.
I use HTML and Modern CSS for frontend. I sprinkle htmx when I want interactivity and a tiny amount of plain JavaScript. That gives me a mostly declarative frontend.
On the backend I use Haskell, which is also declarative unless you opt into other things.
The challenge with web development is that we’ve learned over the years that asynchronous, stateful programming is the most bug-prone programming yet we reach for it first. We should reach for those things last and where they are appropriate.
The thing about cascading style sheets is that it all cascades by default. A web page naturally resizes. It’s when we add all this other stuff that things start breaking and becoming rigid. The key to CSS is knowing when to let go.
Earlier in my career, I found that my employers would often not buy Matlab licenses, or would make everyone share even when it was a resource needed daily by everyone. Not having access to the closed-source, proprietary tool hurt my ability to be effective. So I started doing my "whiteboard coding" in Julia and still do.
Rather than its "decline was", Perl's existence is cultural. All programming languages (or any thought tools) are reflections and projections of the cognitive values of the community who creates and maintains them. In short, the Perl language shares the structure of the typical Perl dev's mind.
A shift to Python or Ruby is fundamentally a shift to a different set of core cognitive patterns. This influences how problems are solved and how sense is made of the world, with the programming languages being tools to facilitate and, more often than not, shepherd thought processes.
The culture shift we have seen with corporations and socialized practices for collaboration, coding conventions, and more coincides with the decline of a language that does in fact have a culture that demands you RTFM. Now, the dominant culture in tech is one that either centralizes solutions to extract and rent seek or that pretends that complexity and nuance does not exist so as to move as quickly as possible, externalizing the consequences until later.
If you've been on this forum for a while, what I am saying should seem familiar, because the foundations have already been laid out in "The Pervert's Guide to Computer Programming", which applies Lacanian psychoanalysis to cognitive patterns present in various languages[1][2]. This explains the so-called decline of Perl—many people still quietly use it in the background. It also explains the conflict between Rust and C culture.
As an aside, I created a tool that can use this analysis to help companies hire devs even if they use unorthodox languages like Zig or Nim. I also briefly explored exposing it as a SaaS to help HR make sense of this (since most HR generalists don't code and so have to go with their gut on interviews, which requires them to repeat what they have already seen). With that stated, I don't believe there is a large enough market for such a tool in this hiring economy. I could be wrong.
Taken at face value, this is engineering negligence. I've done industrial design with plastics and 3D printed parts. Regardless of the forming techniques, with plastics you still need to consider properties like minimum melting temperatures, tensile stress, and so forth. Then you must test that rigorously. This is all standard procedure. That information is in the data sheet for the material.
I did a quick search and found that many plastics are governed by ISO 11357 test standard [1]. Some of the plastics I have worked with used this standard.
I like to do data-oriented programming, and was just thinking about how I want to organize (and search through) the primary data structures/concepts for a project I'm working on. Part of that involved thinking about things like what information I might cache and what representations data might take. That lead me to looking into the nuances of things like B-Trees, AVL Trees, Quadtrees, k-d trees and so forth.
I've found the book "Foundations of Multidimensional and Metric Data Structures" by Hanan Samet to be an excellent resource when looking for a slightly deeper dive than a more introductory algorithms course. It goes in depth on the nuances of these approaches, many of which are highly similar at a cursory glance.
Ruby is a joy to program in. I started exploring it after using Haskell and Smalltalk and was pleasantly surprised when the language would do things like both of them.
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.