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.
I think if the team are shipping it in this state then either: they don't have the ability to notice the issues on the core team, or they see the issues and ship it anyway. Feedback like this is unlikely to solve either of those cases.
This isn't complex stuff either. I'm not a designer, I don't even do frontend/UI work, I'm basically just a backend engineer. If I'm spotting this stuff on first glance at the main marketing screenshot, which should be the best possible case, then this stuff must be glaringly obvious and pervasive.
You might have a particularly good eye. I saw none of these problems in the marketing screenshot.
I only see one ... icon in the entire screenshot, nothing is fuzzy, and all text looks aligned. The only weirdness is a misalignment between the sidebar header and the main window header, but those don't need to be aligned anyway.
> Unfortunately moving to Gitlab or Sourcehut doesn't really help, because the underlying model (GPT-x) is trained on the entire internet, so that includes all scrape-able websites. The only way for your data not to be used in GPT (and therefore Copilot) is to not to put it on any website or make it very difficult to access, like encrypting it.
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).
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.
Invariants are not a synonym for mixins, I'm not even sure where that idea might have come from. Invariants are assertions that are true throughout a program or subset of a program (like loop invariants). Where did you get this notion they were synonyms for mixins and what would that even mean?
> Invariants are not a synonym for mixins, I'm not even sure where that idea might have come from. Invariants are assertions that are true throughout a program or subset of a program (like loop invariants). Where did you get this notion they were synonyms for mixins and what would that even mean?
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.
> Thanks for your reply! I will need more research to reflect on the examples you give.
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.
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.
> Are square brackets part of the spec now? I can't get over ((((( for everything with no real easily visible distinguishability between parts of a definition. Clojure gets the Lisp-like syntax as right as possible IMO.
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.
For me the cognitive effort is greater without the use of []. The meaning of the () following a symbol in a (define) is only determined by it's position. With [] you can, at a glance, know the role of that list. It gives some visual separation to the parts of a function definition that most other languages just have automatically.
> How are you a "creator" (in an attribution-worthy sense) if you are producing an unoriginal implementation of an old algorithm that thousands of coders have produced before you?
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.
> Can someone ELI5 what Mozilla did to deserve this derision?
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.
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.
Sticking to ASCII in this day and age is nice and fun if English is your mother tongue, but it's a big middle finger to the rest of the world. Please don't.
You can use Unicode characters in item descriptions, so you can write these texts in Japanese, Finnish, or Greek. Only the “syntactical elements” (like checkboxes, priority, due dates) are made up from ASCII characters, to ensure that they are easy to type.
Perhaps the spec could allow an implementation to support a run-time option to recognize alternate characters for syntactic elements. This would have the downside that one person's data might not be shareable with another person's [x]it installation. But that's not necessarily a bug, especially to people who don't plan to share their todo lists.
This run-time-option-only approach would be much better than the "be liberal in what you accept and strict in what you emit" philosophy that tends to cause fragmentation on lots of different levels.
> Perhaps the spec could allow an implementation to support a run-time option to recognize alternate characters for syntactic elements.
Please don't. The equivalent in programming languages would be localizing the syntactic elements ({}, (), [], '.', etc). Its much simpler for a language ecosystem to have the same syntax regardless of the programmer's language.
As far as I know, international keyboards can still type these characters just fine.
You are right, I didn't wanted to imply that these lists can only be used by speakers fluent in english.
I wanted to imply that grammars of languages are best represented in ASCII.
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 <user text> items within the grammar support unicode but the keywords are ASCII only it can MORE easily adapted than supporting unicode....
-- I don't disagree with your basic point, but I like to be included :). There's a Lot of us around whose native / mother tongue is not English, but we prefer it for computing tasks (and frequently gaming / movies / entertainment too - Forums are littered with folks complaining of having to "enjoy" a horrible localized version of something, instead of the original English)
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!