Firstly, no, it’s not gone forever. It remains in your onedrive recycling bin for a month. Secondly, that behavior makes sense. One drive is a mirror of your synced folders. If you just want to not have the file downloaded in your computer, just right click on the file and select “free up space”.
It is. Another indicator you get is a status icon next to each file telling you if the file is permanently or temporarily (meaning it will get auto-deleted locally if you don’t use it) dowloaded to your pc or if it’s only on the cloud.
Oh, and you also get a prompt when you delete a file letting you know that it will be deleted from onedrive as well but it will still be in the recycling bin for a while. The only way to not get that prompt is to tick a box to not get reminded again.
Microsoft software has a lot of flaws but this isn’t one of them.
In our head nothing ever was wrong, bugs only came along when you came along! You should have been able to build it in days, what’s so hard about this?
I remember visiting W3S like 10-15 years ago when first learning DOM manipulation etc at uni. But nowadays there’s nothing it can give me that MDN can’t, that I need to know.
Yeah… Then again I just use the DuckDuckGo bang !mdn and it searches MDN directly.
There’s also devdocs.io which can be indispensable when using a lot of popular utility libraries and frameworks in the same project. Just having a single page with all the relevant docs is just a real blessing.
I used to like the action followed by direct object format, until some time ago when trying to find methods or variables related to a specific object. If the action comes first, scanning for the object without an IDE means first reading unnecessary information about the action. That convinced me to opt for $object-$action in situations where it makes sense.
For example in CSS, I often scan for the element, then the action, so $element-$action makes more sense. BEM kinda follows this. When dealing with the DOM in JS, that makes sense too button.fileDialogOpen(), button.fileDialogSend(), … makes more sense when searching.
Of course one has to use it sensibly and where necessary. If you are writing a code that focuses more on actions than objects, putting the action first makes sense.
I find this much easier to follow than if main were defined last, because main is obviously the most important method and everything else is used by it. A flattened dependency tree is how these definitions make sense to me or how I would read them as newbie to a codebase.
So I’m going to say what I always say when people complain about semantic whitespace: Your code should be properly indented anyway. If it’s not, it’s a bad code.
I’m not saying semantic whitespace is superior to brackets or parentheses. It’s clearly not. But it’s not terrible either.
As someone who codes in Python pretty much everyday for years, I NEVER see indentation errors. I didn’t see them back when I started either. Code without indentation is impossible to read for me anyway so it makes zero difference whether the whitespace has semantic meaning or not. It will be there either way.
Python decided to use a single convention (semantic whitespace) instead of two separate ones for machine decodeable scoping and manual/visual scoping. That’s part of Python’s design principle. The program should behave exactly like what people expect it to (without strenuous reasoning exercises).
But some people treat it as the original sin. Not surprised though. I’ve seen developers and engineers nurture weird irrational hatred towards all sorts of conventions. It’s like a phobia.
Similar views about yaml. It may not be the most elegant - it had to be the superset of JSON, after all. But Yaml is a semi-configuration language while JSON is a pure serialization language. Try writing a kubernetes manifest or a compose file in pure JSON without whitespace alignment or comments (which pure JSON doesn’t support anyway). Let’s see how pleasant you find it.
This leads to weird bugs when you change indentation and miss a line or reorder lines. The logic changes. Not too bad when you’re on your own, as Python seems to be intended for. Add multiple developers and git merges and it is a recipe for disaster. With end tags at least you just end up with poorly formatted working code.
It’s probably more prone to mistakes like that, true. But in practice I really never witnessed this actually being a problem. Especially with tests and review.
I think its type system is “okay”, I mean inherently dynamic typing is pretty error-prone. But its type coercion algorithms are bonkers. Also that whole “NaN ≠ NaN” business…
See that’s one of the parts that is actually almost in line with other languages. In Go, for example, nil ≠ nil because nil is, by definition, undefined. You can’t say whether one thing that you know nothing about is at all like something else that you know nothing about. It really should raise an exception at the attempt to compare NaN though.
IIRC, a nil value can be checked against a literal successfully but not against another nil value. Say you want to check for equality of two vars that could be nil. You just need an extra if statement to ensure that you are not trying to compare nil and nil or nil and a non-nil value (that’ll give you a type error or NPE):
<span style="color:#323232;">var a *string
</span><span style="color:#323232;">var b *string
</span><span style="color:#323232;">
</span><span style="color:#323232;">...
</span><span style="color:#323232;">if a != nil && b != nil {
</span><span style="color:#323232;"> if a == b {
</span><span style="color:#323232;"> fmt.Println("Party!")
</span><span style="color:#323232;"> } else {
</span><span style="color:#323232;"> fmt.Println("Also Party!")
</span><span style="color:#323232;">}
</span>
Kinda. nil is a weird value in Go, not quite the same as null or None in JS and Python, respectively. A nil value may or may not be typed and it may or may not be comparable to similar or different types. There is logical consistency to where these scenarios can be hit but it is pretty convoluted and much safer, with fewer footguns to check for nil values before comparison.
I’m other words, in Go (nil == nil) || (nil != nil), depending on the underlaying types. One can always check if a variable has a nil value but may not be able to compare variables if one or more have a nil value. Therefore, it is best to first check for nil values to protect against errors that failure to execute comparisons might cause (anything from incorrect outcome to panic).
ETA: Here’s some examples
<span style="color:#323232;">// this is always possible for a variable that may have a nil value.
</span><span style="color:#323232;">a != nil || a == nil
</span><span style="color:#323232;">
</span><span style="color:#323232;">a = nil
</span><span style="color:#323232;">b = nil
</span><span style="color:#323232;">// This may or may not be valid, depending on the underlying types.
</span><span style="color:#323232;">a != b || a == b
</span><span style="color:#323232;">
</span><span style="color:#323232;">// Better practice for safety is to check for nil first
</span><span style="color:#323232;">if a != nil && b != nil {
</span><span style="color:#323232;"> if a == b {
</span><span style="color:#323232;"> fmt.Println("equal")
</span><span style="color:#323232;"> } else {
</span><span style="color:#323232;"> fmt.Println("not equal")
</span><span style="color:#323232;"> }
</span><span style="color:#323232;">} else {
</span><span style="color:#323232;"> fmt.Println("a and/or b is nil and may not be comparable")
</span><span style="color:#323232;">}
</span>
Thoroughly confusing lol. I think I need to check the spec in order to grasp this. I feel like this has more to do with the typing system rather than nil itself, maybe. I’ll see.
But yeah, this is nothing like null or undefined in JS, but more similar to NaN.
Yeah… It’s weird but I find it useful that it is, in a weird way. Treating it as an uncertainty means that one MUST explicitly check all pointers for nil as part of normal practice. This avoids NPEs.
yeah not ideal, but if the actual functionality of that operator hasn’t changed then I wouldn’t expect the version to matter. Same with searching most ruby stuff and getting old results. it hasn’t changed in decades, it ain’t changing now. But I did scroll down and literally every result was from the postgres docs so that’s a marked improvement from the google results.
Had to test with Kagi also, leads with official documentation, after that tutorials and unofficial things. Nothing obviously irrelevant. The only thing with the Kagi results, was that there were a few very simmilar official documentation links (for different postgresql versions) at top. But, still good search results. Not sure why anyone is still using google, when there are quite a few better alternatives availale
I am just making fun of all those AI doomsayers on Reddit. It’s nowhere close enough to be even called such. It’s just a mindless algorithm, a tool. Math operation. Are calculators smart? Well yes from a certain point of view.
I also missed multiple courses, but I started using vim-visual-multi in my nvim config and it’s been great. There’s a few others I tried that I couldn’t get to work quite right (usually some weird conflict with nvim-cmp) but I’ve had the best success with vim-visual-multi.
I’m gonma bookmark and try this next time I find the courage to mess around my nvim config. That last none_ls breaking change has made me very hesitant to mess around with things that aren’t just colorschemes ngl.
I also tried github.com/smoka7/multicursors.nvim and the experience was horrible. Then I tried github.com/…/multiple-cursors.nvim and I absolutely love it. It has conflict with cmp, but the README has great tutorial on disabling cmp only when using multiple cursors, and dealing with other plugins to maks them work or disable them in the multicursor mode.
This feels like something I also do in neovim unless I’m misunderstanding you completely. Is it highlighting text and having yoir search apply just to the highlighted text?
programmer_humor
Top
This magazine is from a federated server and may be incomplete. Browse more on the original instance.