The goal of teaching binary trees is not that you can write binary trees in your sleep, the goal is that you train your ability to derive algorithms and data structures. If you look at what a world class soccer player does during training, most of it will never be applied identically during games. The same is true for university studies, if they focus on fundamentals.
Do you have source for this? Because as you write I've always read to derive protein intake from the overall weight. That would indeed be a very important distance.
Yep, it is often repeated bad advice that was originally aimed at healthy weight adults and athletes and then misunderstood by people attempting to lose body fat. It is incorrectly repeated on hundreds of exercise sites and articles. Cite:
> Protein intake should range between 1.0-1.5 grams/kg of adjusted body weight. To calculate adjusted body weight, first calculate excess weight: Excess weight = current weight — ideal body weight (IBW). Adjusted body weight = IBW + 0.25 of excess body weight. This amount generally accounts for 20% to 30% of total caloric intake.
So a slightly more complex way of calculating roughly the same thing. I'd argue that for most people getting your ideal weight is a good enough approximation, and that using your overweight/obese body fat in your protein calculation is wrong by a lot no matter which calculation you use.
In every trade or art you start as an apprentice. That is the time when you learn the basics, the rules, the best-practices. When you have mastered the state of the art, you are a master. You know when to apply which rule and tactic to create masterful artifacts. The next step is to learn when you should break the rules and general wisdom. That is where true wisdom starts.
I've tried perhaps one third of the samples. All of them ran in 120 fps in 3840x2160 px in Firefox on Linux on my machine. Perhaps it is a configuration problem. My screen has a 120 fps refresh rate, so it probably is capped there.
But you can use `first`, `rest`, etc. in new code. CL and Scheme are stuck with the old names for backward compatibility reasons going back over 60 years.
Clojure had a chance to do better because they were starting a new thing.
It's not necessarily a flaw with the language, in any case, just something I've noticed in Clojure articles.
I suppose I'm agreeing with the author - refactoring Clojure to make it more readable is a good idea.
> Clojure had a chance to do better because they were starting a new thing.
And it did. The seq abstraction is way more practical than the old-school list obsession in other Lisps. You get to treat collections uniformly while keeping the performance benefits of each implementation. Pretty smart move, honestly.
That sounds like something someone unfamiliar with the subject would say.
While Common Lisp does have sequence functions, Clojure's seq abstraction is fundamentally different and more comprehensive: Clojure's seqs work uniformly across all data structures (vectors, maps, sets, strings, etc.), not just sequences; Clojure seqs are lazy by default; The seq abstraction is built around immutable data structures from the ground up; In Clojure, everything implements the seq interface - it's the primary abstraction, not just a library feature.
Common Lisp's sequences are more limited - they work on lists, vectors, and strings, but the interface isn't as pervasive or as foundational to the language design. Clojure made the seq abstraction central to how you work with any collection.
Don't forget the self-documenting aspect. The manual is included, the api documentation is included, you can ask emacs which command is executed when you click somewhere or when you press a button. I recently tried to do the same thing in Intellij, pita. Not only, can you find documentation, you can jump to the source code, inspect variable values at runtime, and debug or profile everything. All of that from inside the environment.
Seems like the conceptual design helped with that too, reducing the activation energy needed for clear, interactive documentation. The code and the UI are both designed against the same set of consistent concepts, which naturally brings them together and, in turn, makes it so much easier to tie them from one to another. Simplest example: every interaction in the UI is a "command" and commands are reflected in elisp, so having a way to jump from an interaction to the corresponding code and documentation just makes sense. The documentation can be organized along the same conceptual lines as the code and the UI.
Dynamic scoping is a feature in the Emacs ecosystem. It plays a similar role to dependency injection in other languages. It is what allows you to change global state for some function call. Dynamic scoping together with buffer-local, file-local, directory-local variables is similar to scopes in dependency injection libraries --- a powerful organizational tool.
