Kissaki @ Kissaki @programming.dev

[@GitHub](https://github.com/Kissaki), [website](https://kcode.de/)

---

Read more

Posts

27

Comments

450

Joined

2 yr. ago

In your own description you added a bunch of considerations, requirements of following specific practices, having specific knowledge, and a ton of environmental requirements.

For simple scripts or duck tape schedules all of that is fine. For anything else, I would be at least mindful if not skeptical of bash being a good tool for the job.

Bash is installed on all linux systems. I would not be very concerned about some dependencies like sqlite, if that is what you're using. But very concerned about others, like jq, which is an additional tool and requirement where you or others will eventually struggle with diffuse dependencies or managing a managed environment.

Even if you query sqlite or whatever tool with the command line query tool, you have to be aware that getting a value like that into bash means you lose a lot of typing and structure information. That's fine if you get only one or very few values. But I would have strong aversions when it goes beyond that.

You seem to be familiar with Bash syntax. But others may not be. It's not a simple syntax to get into and intuitively understand without mistakes. There's too many alternatives of if-ing and comparing values. It ends up as magic. In your example, if you read code, you may guess that :- means fallback, but it's not necessarily obvious. And certainly not other magic flags and operators.

As an anecdote, I guess the most complex thing I have done with Bash was scripting a deployment and starting test-runs onto a distributed system (and I think collecting results? I don't remember). Bash was available and copying and starting processes via ssh was simple and robust enough. Notably, the scope and env requirements were very limited.

Let's put a story point estimation on that. Then we can extrapolate time range and risk.

There are two very distinct ways of developing software:

I read this as a claim that there is only two. Which seems to match the overall flow of the document, describing only two, and then arguing between those two as if only those two exist.

No, that's wrong. Especially those two bleak, described extremes. They're not the only ways to develop software.

The thing is, most humans are laughably bad at architecting software without actually writing it first. […] Agile development "fixes" this. You get to discover your spec on your user's time and end up releasing faster. In the end (and oddly so if this were the 90s), fast food is indeed faster to make. But is it worth it?

What the heck are they even talking about anymore. Now one is the only feasible one. But then neither are.

Now, by the end, I have no idea what this was even trying to argue. Meant as entertainment, following two theoretical development process extremes? Formulating in the extreme to make a point? None of it seems to apply. No conclusion is made at the end, instead falling further into anecdotes and unrelated, far away equivalences that make the whole thing even more confusing.

The pyramids didn't respond very well to input either. So maybe the notes app should be running without responding to any modification requests.

That's the kind of thing I suspect as well. Thank you for sharing your insight/experience. It's always interesting and valuable to hear others experiences.

How's it going so far?

The solution to this problem. . .

is that they have to create a support ticket with you, that you then put in progress, and you walk them through your documentation, and then log your time spent onto that ticket. (/s)

There's an alternative to creating too many tickets that only add overhead and then make it harder to get into the project. Creating a good amount of tickets.

I took the OP reference as demand for ticket creation when they don't make sense and only hinder development through unnecessary overhead. E.g. creating a ticket before a quick analysis, or creating individual tickets when one story/feature ticket would be enough. Or more specifically in this case, having to create one before fixing a critical blocker.

EoD? End of December? End of Death? (reference to world going to end)

One table of percent increase/decrease written into SEVEN worded paragraphs. That's how you add bloat and reduce overview and comparability.

The percent numbers aren't telling. They don't explain the methodology of how interest has been measured. Which could have added value to just writing out the numbers. The huge numbers of multiple hundred percent indicate to me that they're worthless numbers.

The title is bullshit too. They say interest in C and C# was up, contradicting their claim that traditional programming language interest is declining. Clickbait non-content.

The note on Googles CEO claiming 25% of their internal code is now AI generated was surprising and interesting to me. I don't know if I find it surprising, shocking, or implausible (suspecting the CEO misunderstands or misattributes what is happening; sourcing is not applied code).

Maybe automated conversion as an upgrade path would be a lower effort with not the same, but similar usefulness.

The suggested solution is flawed and infeasible.

They criticize search engines ranking and moderating their content. Splitting one search engine into an unfathomable amount does not improve that. It complicates it.

Offloading assessment and decision-making of choosing trustworthy to the user is infeasible. They choose a search engine because they trust them. Very very few people would actually explore and assess alternatives and create a ranking of rings and servers/providers. What you would end up with for most users is centralized meta-search-engines and you have your first problem again anyway, but much more convoluted.

The criticized SEO would still be a thing.

Search engines work well because keywords serve as "keyring" selectors, and a single engine can index all kinds of content.

None of this solves their problems. And the closing sentence shows that very well. Now there's more problems then were listed as the premise.

Now the issue is moderating web-rings, users, web-ring sorting, web-ring federation, server ranking, server and user blocking, and more.

You're much better off choosing your search engines.

Given the prevalence of NodeJS and its compatible tools and platforms, I can't see it as a mistake.

Through compatibility, Deno established an upgrade path.

However since 2022, Deno is trying to imitate Node more and more, and this is destroying Deno’s ecosystem.

My impression was that Deno specifically does not try to nor want to imitate Node. They specifically announce and document their intended tooling and ecosystem which is different from the NodeJS and NPM ecosystem.

Their reasons for NodeJS support is for compatibility and enabling users of those platforms to use Deno.

Without it, I don't see Deno replacing NodeJS in a considerable manner. Now, it's a possibility. (But the sheer volume and prevalence still makes it seem unlikely.)

I've read interesting argumentation against nesting. I'm not confident in whether it's more useful or not, in some situations or in general.

praise thy

I like to tinker, I like to implement and improve things for myself, I like the idea of collaborative and public good efforts being to the advantage of everyone, I'm a very good systematic and structured thinker, I like learning, I'm good at it, I like efficiency, I like creativity, I like some stuff that you can get out of it. And for better or worse; honestly worse; I have nothing "better" to do, so I end up with projects even after work.

It was not a conscious decision to get into it. I slid into it. Using software and web, contributing content, changing websites, themes, game scripting, hosting, and then more and more development.

I can certainly understand and relate to loneliness within the job. I've been fully remote for a long time now, with social anxiety, which at the same time makes it more sustainable but also not a good or healthy situation.

I'm lucky to have a very small and good team, work environment, and customer. Such a good situation makes it hard to leave as well.

Do you think that applies to this question?

Null coalesce operator vs comparison operator precedence? Both questions are about that. I don't see one having a different answer to the other. In that case, duplication would only lead to spread out partially outdated information, instead of one place being updated.

I asked 1 high-quality question in 2024, and it was closed almost immediately, and I haven't engaged with the site since.

If someone with 20,000+ karma has their nicely-formatted questions closed so quickly, what must the newbies and rank-in-file encounter? This is probably a big reason why it's declining.

It's a high quality question, yes.

The close as already answered elsewhere is valid though. It's not saying that the question is wrong; at least a decade ago StackOverflow explicitly allowed and encouraged asking the same question in different ways so they and their answers can be found.

It's about operator precedence. And the referenced question asks the same thing, about ?? and a comparison operator.

The head note says:

This question already has an answer here:

Notably, it refers to answers, not the invalidity or duplication of a question.

The header also mentions [previously] opinion based, so I looked into the question edit history. It most certainly was not a "high quality" question at the beginning - at the very least to the degree it looks like now.

Exactly. It's a matter of barrier and interest. Signup requirements are a barrier to drive-by improvements and reports, and them as entry points to further contributions.

PDF is a broad format with various standards and formats. Which ones does PdfDing support?