If you use the git command line (and I do) you should spam git log --graph
(usualy with --oneline
).
And for your filesystem example I sure do hope you use tree
!
If you use the git command line (and I do) you should spam git log --graph
(usualy with --oneline
).
And for your filesystem example I sure do hope you use tree
!
I absolutely agree that method extraction can be abused. One should not forget that locality is important. Functionnal idioms do help to minimise the layer of intermediate functions. Lamda/closure helps too by having the function much closer to its use site. And local variables can sometime be a better choice than having a function that return just an expression.
Good advice, clear, simple and to the point.
Stated otherwise: “whenever you need to add comments to an expression, try to use named intermediate variables, method or free function”.
I never understood why python won agaist ruby. I find ruby an even better executable pseudo code language than python.
It’s so anoying that at $WORK we have multiple git repos with symbolic link that points above their respective .git to each other and need to be in sync. So of course git workree
and git bisect
don’t work that well…
For those who don’t know (I assume you do), you can git bisect run some_command
and git will automatically run git bisect until it finds the falty commit. It’s amazing.
Read your own code that you wrote a month ago. For every wtf moment, try to rewrite it in a clearer way. With time you will internalize what is or is not a good idea. Usually this means naming your constants, moving code inside function to have a friendly name that explain what this code does, or moving code out of a function because the abstraction you choose was not a good one. Since you have 10 years of experience it’s highly possible that you already do that, so just continue :)
If you are motivated I would advice to take a look to Rust. The goal is not really to be able to use it (even if it’s nice to be able able to write fast code to speed up your python), but the Rust compiler is like a very exigeant teacher that will not forgive any mistakes while explaining why it’s not a good idea to do that and what you should do instead. The quality of the errors are crutial, this is what will help you to undertand and improve over time. So consider Rust as an exercice to become a better python programmer. So whatever you try to do in Rust, try to understand how it applies to python. There are many tutorials online. The official book is a good start. And in general learning new languages with a very different paradigm is the best way to improve since it will help you to see stuff from a new angle.
I reread that article every years for a few years. Each time my understanding of git improved significantly.
I reread that article every years for a few years. Each time my understanding of git improved significantly.
It was when I read the git parable.
I have a non-breaking space on my layout since 10 years, and a friend recently added a non-breaking hyphen to his. Appart from search that doesn’t do automatic conversion I didn’t noticed issues.
I would have liked a link to the LKLM thread. Usually they are quite informative
I use a 42 key layout modified from bépo (french dvorak inspired layout) with the altgr layer of ergol. Go check this altgr layer it’s awesome for programming, and there is a version compatible for qwerty and lafayette.
╭╌╌╌╌╌┰─────┬─────┬─────┬─────┬─────┰─────┬─────┬─────┬─────┬─────┰╌╌╌╌╌┬╌╌╌╌╌╮
┆ ┃ ¹ │ ² │ ³ │ ⁴ │ ⁵ ┃ ⁶ │ ⁷ │ ⁸ │ ⁹ │ ⁰ ┃ ┆ ┆
┆ ┃ ₁ │ ₂ │ ₃ │ ₄ │ ₅ ┃ ₆ │ ₇ │ ₈ │ ₉ │ ₀ ┃ ┆ ┆
╰╌╌╌╌╌╂─────┼─────┼─────┼─────┼─────╂─────┼─────┼─────┼─────┼─────╂╌╌╌╌╌┼╌╌╌╌╌┤
· ┃ │ ≤ │ ≥ │ *¤ │ ‰ ┃ *^ │ │ × │ *´ │ *` ┃ ┆ ┆
· ┃ @ │ < │ > │ $ │ % ┃ ^ │ & │ * │ ' │ ` ┃ ┆ ┆
· ┠─────┼─────┼─────┼─────┼─────╂─────┼─────┼─────┼─────┼─────╂╌╌╌╌╌┼╌╌╌╌╌┤
· ┃ │ ⁽ │ ⁾ │ │ ≠ ┃ */ │ ± │ — │ ÷ │ *¨ ┃ ┆ ┆
· ┃ { │ ( │ ) │ } │ = ┃ \ │ + │ - │ / │ " ┃ ┆ ┆
╭╌╌╌╌╌╂─────┼─────┼─────┼─────┼─────╂─────┼─────┼─────┼─────┼─────╂╌╌╌╌╌┴╌╌╌╌╌╯
┆ ┃ *~ │ │ │ – │ ┃ ¦ │ ¬ │ *¸ │ │ ┃ ·
┆ ┃ ~ │ [ │ ] │ _ │ # ┃ | │ ! │ ; │ : │ ? ┃ ·
╰╌╌╌╌╌┸─────┴─────┴─────┴─────┴─────┸─────┴─────┴─────┴─────┴─────┚ · · · · · ·
Usually when people say “I suck at maths”, it means that they are bad at doing manual calculus. Maths is extremely useful in programming, but it’s absolutely not the same kind of math. I don’t think that the grade you had in math at school will influence in any if you will be good or bad in programming.
I would even have said that both throwing and catching should be pure, just like returning an error value/handling should be pure, but the reason for the throw/returning error itself is impure. Like if you throw and ioerror it’s only after doing the impure io call, and the rest of the error reporting/handling itself can be pure.
I’m surprised about this statement, I would have said that exceptions are the consequence of an impure operation (that may or may not fail differently every time you call it).
There take on what they call capabitilites is very interesting. Basically anything that would make a function non-pure seems to be declared explicitely.
A computational effect or an “effectful” computation is one which relies on or changes elements that are outside of its immediate environment. Some examples of effectful actions that a function might take are:
- writing to a database
- throwing an exception
- making a network call
- getting a random number
- altering a global variable
Interesting take but I think you are right. It’s indeed critical to know how you product is used nowadays.
2019, so 4-5 years ago so not that recent but not ancient either. But unfortunately tutorials have not been updated.
I would say that the biggest benefit of git switch
is that you can’t switch to a detached state without using a flag (--detached
or -d
). If you do git co $tag
or git co $sha-1
you may get at one point the error “you are in a detached state” which is ununderstable for begginers. To get the same error with git switch
you must explicitely use git switch --detached $tag/$sha-1
which makes it much easier to understand and remember that you are going to do something unusual.
More generally it’s harder to misuse git switch
/git restore
. And it’s easier to explain them since the only do one thing (unlike git checkout
which is a mess !).
So if it’s only for you git checkout
is fine, but I would still advice to use git switch
and git restore
so you will have an easier time to teach/help begginers.
It’s a question of workflow. Git doesn’t guide you (it’s really workflow agnostic) and I find it easier to taillor CLI to fit my exact need, or use whatever was recently added (like worktrees a few years ago). I have yet to find a GUI/TUI that I’m not frustrated with at one point but everyone has its own preferences.