If you differ between AI source code and engineer source code say so. "Getting things done" is a business need. Which things get translated to a deterministic language executable by a computer is code.

There are entire languages dedicated for lesser engineers/domain experts to formulate business requirements.

Anyhow; What's your point? That we received a framework for "soft algorithms" where the output does not need to be correct and deducible? What's even the point of putting it into software. Just forward your input to the reader and let him judge on its own.

To me, your FAQ quickly addressed all questions I had to get a first grasp of the capabilities. It appears to me that you had a determined scope and I very much like that!

Your professional input may be desired. Though I did not contribute to Thunderbird either (, yet?). Thing is, your critique may result in guidance to make part of these changes according to your skillset! But I am just a hopeless dreamer in the good of many things.

Having the entire git history decorates specific chunks (at least entire commits) with context by the commit message. So you may not only process the entire repo at one specific state in time, but the entire history in at this point in time. There is valuable knowledge while making sense of it; But this is not accessible to us. It relies in the knowledge base of one company (or two).

Please note my sibling answer which shows I am opinionated. I have memorized my own takes from such terms so researching about my answer may be time not used well. Sorry.

> - https://www.eiffel.org/doc/solutions/Design_by_Contract_and_...

Does indeed overlap. I only read about contract-based programming; contract by design via API documentation in a java environment.

> and it seemed to me the main concern was program correctness/consistency

It is. There are multiple factors to deploying correct software though.

> Maybe I mix up different concerns and good interface design is more about satisfying use case?

Apparently your are on the right track. But I would strongly agree on the latter. Such formal correctness proves didn't cross my career yet. But I am assuming safety-critical systems or systems haed to update may benefit here the most. Which would explain my lack of certainty.

Keep it up; Sorry.

It was my own understanding; Thanks for suggesting clarification. I falsely associated such mixins with encapsulated behaviour. It was my take on mixins and may have translated the term invariant wrong. Appreciated.

No. One need a specification of the intended behaviour. Behind this specification lays the interface (data type, here a Object-class). This data type on the other hand can have different representations.

Design by contract is a term i didn't read as an agreed scientific term. It is used in OO-languages for some pattern, where you "generate" (read imply) a specification. E.g. two unrelated services use the same data type within their communication. This may be injected or included within their dependencies. To me its related to code generation. It may aid the collaborations between multiple developers across multiple projects to 'move faster'. I have limited and bad experience with this.

> If so, what about invariants? Are invariants related to good interface design?

Invariants in my book are then a synonym for mixins. Which in OO-Design would be represented via dependency inversion. Invariants can be necessary at best. Its no measure for a good interface. If your data types are specified such that invariants do not missbehave, they can be used.

But don't trust me on this.

Square brackets are replaced by normal parenthesis to my knowledge.

Though I have to admit that I strongly dislike them. They put more cognitive effort into the syntax than they aid.

We shouldn't raise any questions but leave participations to themselves.

So your requirements are pseudo-code which you simply have ti translate. I see. No creativity required. Jepp.

> Most coding is not innovative, and that is the kind of code that these tools are producing and derived from in most cases.

I see what you want to suggest. Then it woulnb't be required to learn on these datasets and simply build a "fair use" product which covers these cases with a snippet engine.

Don't be naive.

Assumption: People have troubles with certain web applications like MS teams, goto-meeting,.. or youtube. Mozilla has to adapt to undocumented changes. There are an increasing amount of applications which do not support firefox (strange, because the web should be browser independent). People think Mozilla is responsible for this.

Mozilla does not generate income with Firefox (besides dontations!). Why is it so important to have the biggest market share with a browser? I suppose there is data to be collected by the other players.

There are languages written from right to left or top to bottom. No standard I know of are supporting such flexibility in syntax. And it shouldnt be necessary - if the items within the grammar support unicode but the keywords are ASCII only it can MORE easily adapted than supporting unicode....

That's a good thing. Its also unicode, not utf-8. Your plugin can display it with a unicode character. Having a simple ASCII char set helps portability _a lot_. No benefit in supporting unicode code points.

> - doesn't support nested lists

If you can tick all items within a nested list, why bother writing it with dedicated TODO items? Additionally, you can just create more files for elaboration. Your file system is at your dispense. Additionally, that can be implemented in your plugin of choice. Goes with your first point in hand.

> - specifies a specific space character when a character class would be better

ASCII has no official character class. If your are refering to tabs; I don't think this is bad or good. Maybe you can follow uo on the use case..

> - not clear what "item must not contain blank lines" means

Probably that a blank line is used as a separator

> - description indentation limit of four space characters is a problem for nested items

I don't see why. The fixed amout of four characters obviously lines up to the start of the text from an item. This helps readability a lot. And is a simple standard for identation rules.

> - description supporting blank lines (properly indented) would be useful for longer descriptions

I disagree. A TODO list should be simple to grasp. Details and elaborations can be put in a dedicated directoy and refered to. Also, it is a _very bad_ idea to work with invisible lines. Users are dump and quick to judge.

> - date should support an ISO or other standard date format

This is the most portable standard, but extended for human editing..

> - timezone is necessary for events happening in specific timezones or across timezones

I tend to agree. But the person hosting the list should probably be the one defining the time zone. But I haven't read anythinf about time zones in the primer. Nothing stops one to simply append it to a time. No need for the standard to define such.

I think it is well put and the first one which checks all the boxes for me. Congratz to the author.

I don't see why such a comment is #1.

E(very) S(ingle) W(ord) S(hould) be (no [ACCEPTED] completion here) W(ritten) W(ith) C(onscience). You should be responsible for your code submitted. Are your feeling confident?

Won't touch Co-Pilot. Probably you are spending equal time proof reading than _understanding what needs to be written_ in advance. At least that is what I am hoping about. Of course you don't have to proof read, and most things can probably be grasp in a glance. But you rely on a black-box. From a corporation. To me that sounds like agreeing with a dictator.

Wouldn't promise my craftmanship for things I didn't grasp in advance. But maybe that's a culture hindrance. I like it though. I want to know the code I am corrected about. I want to archive mastery.

You are right; This underlines the thought and care some distributions put into their package management system...

> The whole point of APIs is that we do not need to understand the inner workers of code that we're calling. How many of us use bcrypt and couldn't tell you anything about the underlying algorithm?

That is right, but code written by unknown developers can be a huge risk. Of course you are not assumed to read up upon any dependency, but from external sources. A quick glimps on the imports and dependencies goes a long way, I think. In the end your team is responsible for security issues, even if they appear in an external dependency. Companies with direct customer sales are spending tons of money for mitigation strategies. Maybe a chunk of this money should be spend on validating this beforehand.

Imo the line is not arbritary. You are including an library/framework for a purpose. The code path for this purpose should be explored. Recently I allowed a friend of mine to DDOS my server. He used unvisited software. Now my server suffers from thousand wild guesses daily. Previously, I had ten visitors a day. Therefore I conclude that the software leaked my server. And his learning: Don't trust any software; Exspecially if the software is for malicious purposes in the first place..

> A basic web application at this point is going to import at least 10k lines of other people's code. A React app probably uses millions.

I think it is a valid assumption to increase the trust in frameworks with a giant user base. React is from Facebook, isn't it? So I would have read the path _and_ random internals to picture the trustworthiness.

> There's just no way around this. We all trust code we haven't read and have to continue doing it.

It shouldn't be black-and-white thinking. When introducing a _new_ dependency I see myself responsible for estimating the trustworthiness. But yes, with an increasing amount of dependencies the process of updating such needs more effort as well. But then, we can postpone such updates, if the application under development is safety critical...

> Reading code doesn't even guarantee finding security flaws. Most of us aren't security researchers, and none of us can understand an entire project's source code the first time we read it.

Well, one should be able to judge about the workings imo. Otherwise maintainability can get painful in the long run. So better grasp it before deciding to build upon it.

Another comment stated that we are trusting cars we drive, etc. etc. This is about the users running our code. A proper craftsman will inspect its material, before using it in quality products. When building a throwable tool for his work, he doesn't spent to much time worrying, of course.

Here is the link: https://aquamaniac.de/rdm/

I integrated all my accounts of Kreissparkasse and DKB. Works flawlessly. I also tried all alternatives to connect to these institutions. I wouls recommed this setup.