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>

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 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.

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.

To some extent I agree that the upgrade path is lacking.

You began an inappropriate chain of comments by being uncharitable in your initial interpretation of my sentiment. People piled on emotionally as a direct result of your opening sentence even though your second one confirms what I said.

The Maker Movement is more than just Arduino coding. Some of these maker spaces have full-on donated Kuka robots or other heavy equipment with minimal safety mechanisms in place other than "be careful".

Yes, there is. It is called "Introduction to Microcontrollers" by Günther Gridling and Bettina Weiss from the Vienna University of Technology, written in 2007.

Unfortunately, it suffers from having a very generic name. It is short enough while going over concepts to take a person just beyond Arduino-land.

I agree with the outcome of increased fabrication tools availability.

Yet, when the intent is that the population is to be empowered democratically to wield these tools, there needs to be a better pedagogical culture in the communities.

I cannot believe the amount of people replying who seem to think that having a path to improvement is gatekeeping. How are people supposed to actually use these tools to make greater than novelty-level changes in their lives and communities?

The price of Arduino has not only been going up and up, but there have been IP disputes over the years. At the same time, you can get chips for pennies on the dollar. People in this thread are lamenting the possible demise of Arduino, when like Cloudflare, like Github, and like so many other things, they should have never been so invested into a single player.

The result of Arduino going away should be "Ah, it is a sad day that one of our many choices of accessible boards is going away. let's make sure the other ones are robust against that same fate and keep creating with our remaining tools."

Instead, the conversation is "How dare that big corp change the terms and conditions on our only hobby option!"

I certainly see a structural and cultural problem here.

You talk about gatekeeping, when most people don't know the difference between git and GitHub, making your first PR is difficult if you have never done it, navigating a repo to look for your first change is difficult. And yet the status quo is that people should just figure that out.

You also talk about gatekeeping when in the many makerspaces I have been to, there are always highly experienced people who tinker on their own terms but rarely pay it forward, meaning they keep their knowledge. The reason for this is due to the often anarchist structure of maker spaces. Things happen if they do.

Sometimes there is an organized class. Most of the times, not. So you come in every week and people are just sitting around talking about the rules of keeping the space clean and when dues are due.

The concept of the hacker space and maker space is great. The execution leaves a lot to be desired. I consider it a 1.0 of a technical movement.

A young EE is in a degreed program and is getting that progression formally as part of their degree. A person not in that degreed program is taking a random walk through the skills and potential mentors (if and when they exist). That's clearly the issue.

This also goes beyond programming on a microcontroller as the Maker Movement is about more than just electronics.

"Approaching" means to go towards the skillset. A home chef can develop better knife skills when cutting vegetables. That is approaching being a more professional cook, yet it does not mean the person could work in a restaurant. Maybe they could. We're talking about asymptotic.

If you are having understanding this distinction, then that is the exact point I am making about the Maker Movement. It is accepted that people progress if they do, and if they don't, then tough. There is a balance between perpetual tinkering, some sort of progression culture, and a full on degree.