The presenter compares some of the functionality to Leap.nvim

Trey Hunner writes:

This article is primarily meant to act as a Python time complexity cheat sheet for those who already understand what time complexity is and how the time complexity of an operation might affect your code. For a more thorough explanation of time complexity see Ned Batchelder's article/talk on this subject.

Read Python Big O: the time complexities of different data structures in Python

Isaac Harris-Holt writes:

Modern software engineering can be a bit of a nightmare. You've got all these different third-party services to keep track of, and often many first-party microservices too! As it turns out, things can be made more simple using Gleam. Let me show you how.

In the command-line window the command line can be edited just like editing text in any window. It is a special kind of window, because you cannot leave it in a normal way.

There are two ways to open the command-line window:

1. From Command-line mode, use the key specified with the 'cedit' option (default CTRL-F).

2. From Normal mode, use the "q:", "q/" or "q?" command.

• This starts editing an Ex command-line ("q:") or search string ("q/" or "q?"). Note that this is not possible while recording is in progress (the "q" stops recording then).

When the window opens it is filled with the command-line history. The last line contains the command as typed so far. The left column will show a character that indicates the type of command-line being edited

Pedro Domingos summarizes 12 key lessons that machine learning researchers and practitioners have learned. These include pitfalls to avoid, important issues to focus on, and answers to common questions.

• 1. Learning = Representation + Evaluation + Optimization
• 2. It's Generalization that Counts
• 3. Data Alone Is Not Enough
• 4. Overfitting Has Many Faces
• 5. Intuition Fails in High Dimensions
• 6. Theoretical Guarantees Are Not What They Seem
• 7. Feature Engineering Is The Key
• 8. More Data Beats a Cleverer Algorithm
• 9. Learn Many Models, Not Just One
• 10. Simplicity Does Not Imply Accuracy
• 11. Representable Does Not Imply Learnable
• 12. Correlation Does Not Imply Causation

I'm sharing this Discord Message from someone that was doing their best to fill in their gaps in understanding Odin after reading the Overview documentation on odin-lang.org.

This was somewhat confusing, I could change the package foo at the top of the file and it makes no difference and everything works.

From reading this Server, I learned a lot, like this:

• 1 - The package is only linked to the directory name (folder) and nothing else, except;
• 2 - The files in the package directory must all have the same package foo header with the same name, but it does not have to be the same as the package directory name, just unique (see below); and
• 3 - No two packages can have the same directory/folder name (globaly unique); and
• 4 - No two packages can have the same package foo header names (i.e., must be globally unique but not tied to any package (directory) name needed - but would be a good idea, I mean why not...);
• 5 - You cannot have cyclical imports - ever;
• 6 - The package foo header seems powerless for the most part as far as programmer use, but I read it is used by the ABI as a prefix for symbols in the final binary;
• 7 - Sub-packages do not exist, so even nested directories are standalone packages and also do not infer dependence;
• 8 - In Odin you should put as much in one package as possible and do not use packages for namespaces since it will not work (see using) and do not use packages to organize your files, see 9 for proper reason to use packages;
• 9 - Use separate packages only as reusable (stand alone) libraries;
• 10 - Organize files within a package directory by their filenames (ala Java) and not subdirectors for all the reasons above; which is what I will do using snake case for the file names.

If I blew it above let me know.

imho the Overview would do better to include a little more detail like some of the stuff above. When I searched this server I found a huge amount of the above and just cobbled it together from 6-7 posts. I think what was not clear from the overview was: 1, 5, 6, 7 (its there but not clear), 9. It is clear that many people are confused by this, but on the bright side searching the Discord was very useful.

gingerBill indicated this is a common source of confusion for newcomers to Odin:

package name has nothing to do with the thing you import.

This is probably one of the most confusing things about Odin's packages. The exist for stable ABI and consistent linking names.

Hopefully, I can create a minimum working example that can be illustrative for others and have a PR merged into the Overview documentation. Until then I just want something that can be found outside of Discord for other learners.

Niklas Gray writes:

I often find that when I work on the low level implementation of something I discover ideas that I can bring back and use to inform the high level design — to make it easier to work with, more performant, more orthogonal, etc. Thus, the flow goes back and forth from high-level to low-level, instead of just in one direction. If I’m stuck in some part of the high-level design, starting to work on the implementation is often the best way to get unstuck.

One such idea, which is really simple, but tends to lead to better and simpler code, is the idea of defaulting to zero. I.e. to always use 0 as the default or nil value. For example...

Read Defaulting to Zero

Bayman, Emine Ozgur PhD*; Dexter, Franklin MD, PhD, FASA†. Multicollinearity in Logistic Regression Models. Anesthesia & Analgesia 133(2):p 362-365, August 2021. | DOI: 10.1213/ANE.0000000000005593