lemonwaterlime

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.

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.

[1]: https://github.com/samoshkin/vim-mergetool

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.

I find the inline changes promising. Should provide better git diffs with vimdiff. There's not much about vim I have to complain about. It's stable, does what I need, and over the years, I have extended it in ways I like and those extensions are stable. I grok vi and can do what I need.

I had so many corrupted Time Machine backups over the years that I eventually just wrote an incremental backup script in rsync. I’m much happier.

Something like [1] can be inspiration.

[1]: https://github.com/perfacilis/backup

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.

There's also Julia.

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.

I’m working on a PDF parsing library in Haskell. The ISO spec has a lot of detail; I decided now was the right time to read through all ~1000 pages of it with a fine-tooth comb.

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.

[1] [PDF] -- "The Pervert's Guide to Computer Programming" https://s3-us-west-2.amazonaws.com/vulk-blog/ThePervertsGuid...

[2] [YouTube Vulc Coop]-- https://www.youtube.com/watch?v=mZyvIHYn2zk

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.

A spec sheet for that material is here [2].

[1]: https://www.iso.org/standard/83904.html

[2]: https://um-support-files.ultimaker.com/materials/1.75mm/tds/...

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.

“Discrete-Time Signal Processing” by Oppenheim is another great resource.

coreutils, nix, vim, Haskell (ghc), postgresql, latex

Exactly this. With a comfy life, you can mature later. The more hardships and adversity one must overcome the faster that maturation happens. Particularly so when the hardships put one on an abnormal path.

Losing a close relative or a job is normal adversity that everyone will go through but not everyone has. Going through those other things while having a different philosophy or life ethos than those around you, thus also causing you to prioritize and pursue different things in life adds a different layer of challenge. That causes you to have to figure stuff out on your own and thus contributes to maturing in a different manner and at a different rate.

Ive always just used C. From my recollection, there’s an avr libc library. There’s tutorials online for how to do it. The big thing is once you have that progression path with knowledge like that book I linked, you have a lot of freedom.

Some chips can use Micro Python or even Rust. I have not explored those myself.

Short answer: Yes. And you always could have.

Longer answer: It's been a while since I have thought about Arduino. But last I recall, it is just an Atmega chip connected to IO. Maybe newer ones have moved to ARM M0 or beyond. That's about when I stopped using Arduino.

But it isn't hard to just start from baremetal on those. You need the user manual for the actual chip so you can configure timers and such. Once you know how to set up one chip, you can set up most any chip.

I do think there is use for a plug and play system like Arduino. It is very user friendly to just use that IDE and get started on Arduino. My critique is that there is rarely a followup progression. That followup progression is critical.

Here's a video showing how to make your own "Arduino" [1]. All the hard work is done by the Atmega chip. So Arduino has built this mythos and this IDE that it seems you have to use. It traps people and prevents them from doing the exploration into the chip itself.

[1]"Build your own Arduino for $5" https://www.youtube.com/watch?v=tlh0dBa2bFA

The author was a bit poetic in writing this post and most commenters seemed to have missed the point.

When he starts talking about the “hygiene of the programmer”, he is referring to the concept of a “code smell” rather than making literal statements about the literal cleanliness of programmers.

From there, he is saying that the industry has distanced itself from object-oriented programming because it often causes problems and added “smells” to the architecture of code bases. This is regardless of what your specific definition of OO is.

Finally, he ends by raising awareness around the fact that even if people claim to not use much OO in their codebases, when you look at the total architected solution, those various services like Docker and so on are themselves various Gang of Four style OO patterns. Because we talk about OO in code, we are not watching the OO that happens around the code.