Journaling or diarying is writing for myself, and often in a form that will never leave the disk inside the the computer. But I also want to write more complicated things than just what I thought about today, how I solved some problem, or a reminder for three months from now. Why? Because writing as a solitary pursuit is similarily rewarding like reading for pleasure. We can read without growing an audience. We can read without have any extrinsic motivation. We can just do it and leave it at that. But writing is a bit too much associated with communicating (small) and broadcasting (large).

I could probably write a book on the most idiosyncratic topics, something that not even my mother would like to skim the foreword of. Because imagine if that process would help me know myself? How valuable would that be? The writing artifact might be useless, even. But the process could be enriching.

I would never hope to read a book by someone I don't know and be able to absorb their wisdom, not even 10%. Some things cannot be transmitted like that. The printing press probably has not helped us know ourselves more than just, you know modestly more. Some things have to be worked on by you and you alone.

This also translates to more practical subjects than knowing yourself. But that's what I felt like spending the word count here on.

But in terms of public writing. I am currently working on an article-length piece for a niche "publishing". And I find that process to be rewarding.

That agents need something "beyond git" is lost on me but it keeps coming up. For one subject the tool doesn't matter -- in fact it can be obtuse like git or bash and it's fine because agents will handle it. Then for another thing the story is opposite.

Personally (without conventional commits) I tend to put them at the end in parentheses if the commit has something to do with that issue. But if there is a stronger relationship like that it fixes the issue, I put a `Fixes` trailer in the message as well.

I can not say anything nice about conventional commits. The format takes up space in the most-read part of the message. The categories or types have little information. They can be replaced with an honest English verb embedded in the subject like a sentence. It also reads way better with just a sentence instead of three kinds of punctuation (:, (), !). Okay, I can tolerate an "area" in the subject. And that predates this conventio.

At my dayjob we make a webapp for non technical people. I can write a changelog for that just fine (in norwegian). The commit messages are irrelevant to the users. And demanding that all commits should be good enough for an end-user changelog? That's not happening for us anytime soon.

Use footers/trailers instead.

Someone skilled enough should have many original enough problems to work on. But such persons would have to speak on that topic.

   What accessibility settings do you need?

   - [four options/catgories]
   - Remind me Later (or something)

Some years ago I realized that I can just start sending emails to an OSS mailing list. Without introduction just starting to post as if I belonged there. I had already made some grammar fixes more than five years before that but I started to comment and critique submissions. And submitting my own patches. Now checking the mailing list is daily habit. Unfortunately I didn't have time to post the second version of a submission on the bus today (another documentation fix).

People, and especially in my culture, are very good at staying out of places where they do not belong through self-policing alone. Unfortunately to the point where at least I do get stuck in narrow patterns and never even consider certain opportunities.

https://docs.oracle.com/javase/8/docs/technotes/guides/langu...

And I'm pretty happy with its design considering its age.

Notably this is not a function call and indeed things are not called unless you enable it. Contrast with Zig. So I guess you will only suffer from code bloat if you never enable them.

The tutorial mentions the dangers of side effects. But it also mentions how to use them for more complicated assertions. That's natural since you'll want something like that when you need to check a post-condition.

Programming assertions get joked on because of, ahem.

- Step one: Turn on extra checks in test environments where the stakes are low

- Step two: Turn them off in production (with realistic data because prod eq. reality) to save cycles

And that seems to be partially accurate. However the truly interesting assertions can test complex conditions that might break complexity (Big O) contracts. Like a private mininum function that is advertised as O(1) on account of taking a sorted list. But there is no type guarantee that the list is sorted. So you assert that it is sorted. But that breaks the complexity contract.

Overall I have not used assertions in Java for trivial conditions in like five years. They're better deployd for something more complex than that.

Then there is the whole thing about -- and more topics to be sure -- crashing the whole application or not. That's not necessarily great for us regular Java programmers. However we can (though discoraged) catch AssertionError if we want to.

Comments URL: https://news.ycombinator.com/item?id=47976644

Points: 13

# Comments: 5

No one wants to apply diffs in commit messages. But some people use this technique via email:

    Finally fix it

    ---

    Changes in v2:

    - Proper formatting
    - Remove irrelevant typo fix

I would personally use Git notes instead though.

    Finally fix it

    ---

    Notes:
        Changes in v2: ...

This means that it will try to apply any unindented diffs in the commit message. But you’re fine if you indent the diff. (Newschool code fencers will have a worse time here.)

I imagine that this worked fine for changes that were authored by one person and submitted by another person via email, or by their friend, or by someone trying to resurrect a previous attempt at getting something upstreamed. Someone is likely to notice that examples diffs are getting applied. But it won’t work well at all if you are some software distributor who is using patch files to apply modifications to packages.

Recall that git-am(1) will not apply indented diffs. Well have a look at my GNU patch 2.7.6:

    If the entire diff is indented by a consistent amount, if lines end in
    CRLF, or if a diff is encapsulated one or more times by prepending "- "
    to lines starting with "-" as specified by Internet RFC 934, this is
    taken into account.

    Larry Wall wrote the original version of patch.

This command is implemented by just one single (but prolific) contributor. His own idea.

These two commands operate on the same level of abstraction. And they should be equally powerful, which means that whichever you choose to learn will be able to serve all of your restore-content needs. That's what I mean.

Of course there is always the pedagogic cost of having two similar commands.

For a dedicated "restore" it's worth it to me... (who will not maintain it)