73 karma · joined February 25, 2021
> The vote on the “Aggression against Ukraine” resolution was 141-5, with 35 abstentions.
> Only Belarus, Syria, North Korea and Eritrea joined Russia in opposing the measure, (...)
https://apnews.com/article/russia-ukraine-vladimir-putin-uni...
I think it might be more valuable to expose beginners to static typing because it's much easier to transition from "objects have distinct types" to "pretty much everything is just a hashmap" than the other way around.
The thing about C as a first language is that you need to not only learn what programming is but you also need to learn manual memory management which raises the bar significantly and it's pretty easy to write code that fails for reasons which are difficult for a beginner to figure out (like segfaults).
The second premise also seems to be true, though I would phrase it in a descriptive rather than prescriptive manners - the choices you make regarding job offers reveal your preferences ("the ordering of jobs").
Having no "job ordering" would result in people taking jobs based on a coin flip, wouldn't it?
Could you elaborate more on this? I'm assuming this is a detail of the US education system of which I don't know anything :)
It's simple, it's portable, it's good enough. You could in theory improve it by having multiple views of the same data (let's say you want to save some notes about "Naturalis Historia" - should you put it under "ancient Rome" directory or under"biology"?) for example by using hardlinks but I don't know if there is a way to create a backup on another filesystem that will keep hardlinks as hardlinks (DAR seems promising http://dar.linux.free.fr/doc/Features.html but I have yet to try it).
"Or" is the name of the "|" operator. From the looks of it it's impossible to overload "||" in groovy.
By the way the "|" operator and the "or" method both call "pipeTo" directly so a third way to write it would be:
"ls".execute().pipeTo("grep -i old".execute()).waitForProcessOutput(System.out, System.out)
("ls".execute() | "grep -i old".execute()).waitForProcessOutput(System.out, System.out)
It can also be written as
"ls".execute().or("grep -i old".execute()).waitForProcessOutput(System.out, System.out)
It's not exactly the same because it uses a thread and a buffer instead of an OS pipe but I guess it's close enough.
Non-nullable types sound great, I wonder if this could be introduced to Java in a backwards-compatible way (I suppose it would follow the same path with introducing explicitly nullable types first, though I guess it could be handled using Optionals?).
Some C# things seemed rather strange (like delegates), some purely cosmetic (like indexers) and there were also things that Java had but C# did not like covariant return types (available from C# 9.0)
*Project Valhalla is supposed to bring it to Java but I wouldn't hold my breath waiting for it.
I mean, we can annotate every observation and every thought ever with "for all we know it could be just an illusion" and live as if we were constantly being tricked by a deceitful daemon Descartes-style but why should we do it, what is there to gain?
I could agree that monism / strict materialism is as baseless as any other view but I think its terseness deserves a bit more respect than being called "comical", if only for the sake of its elegance.
It's trivial to provide a longer description / a more complicated model of reality that will have as much explanatory power as a simpler one. It's much more challenging to find a shorter / simpler one that will work just as well.
Yes, I am aware that my assumption that challenging things are somehow more commendable than non-challenging things is completely baseless too :)
Don't get me wrong - plastic pollution is a serious issue. it just seems to me that the "negativity" of plastic pollution lies in making life more difficult for humans. Appearance of lignin surely influenced whatever forms of life existed at the time, we just don't care that much because we were not around (though carbon deposits from that time were surely useful as a source of easily accessible energy). We are born and we die in a world where lignin is biodegradable and not much of a hassle so we might be inclined not to call it "negative" even though it shares some similarities with plastics.
Things sometimes play out in our favor (like the aforementioned coal deposits providing easily accessible energy) and sometimes they don't (like the CO2 from burning all this coal pushing the chemical composition of our atmosphere outside of favorable range of parameters). I don't really see any advantage of introducing additional beings into the description (I don't think it enables us to make more accurate predictions), though I guess it could be an interesting thought experiment along the lines of the Gaia hypothesis (or the Medea hypothesis for those of more pessimistic inclinations).
I apologize if I made myself unclear or impolite - I tried my best to make this response as understandable as possible while trying to keep it reasonably short.
I don't know what kind of internal representation is used to store tsvector column type in PG, but I think GIN index lookups should be very simple to parallelize and combine (I believe a GIN index would basically be a map [word -> set_of_row_ids_that_contain_the_word] so you could perform them on all indexed columns at the same time and then compute intersection of the results?). But maybe two lookups in the same index could be somehow more efficient than two lookups in different indexes, I don't know.
I'm still sceptical about the LIKE/ILIKE scenario though. "WHERE firstname LIKE 'A%' and lastname LIKE 'Smith' " can easily discard all the Joneses and whatnot before even looking at the firstname column, whereas "WHERE combined_firstname_and_lastname LIKE 'A%SMITH' " will only be able to reject "Andrew Jones" after reading the entire string.
Let's say you know the lastname (Smith) but only the first letter of the firstname (A) - in the proposed scenario only the first letter of the firstname helps you narrow down the search to records starting with the letter (WHERE combined LIKE "A%SMITH"), you will have to check all the rows where firstname starts with "A" even if their lastname is not Smith. If there are two separate indexed columns the WHERE clause will look like this:
WHERE firstname like "A%" AND lastname = "Smith"
so the search can be restricted to smaller number of rows.
Of course having 2 indexes will have its costs like increased storage and slower writes.
Overall the blog post conveys a useful message but the table example is a bit confusing, it doesn't look like there are any functional dependencies in the original table so pointing to normalization as the solution sounds a bit odd.
Given that the query from the post is always about concrete values (as opposed to ranges) it sounds like the right way to index the table is to use hash index (which might not have been available back in 2002 in MySql).
It doesn't seem to change anything other than marking current tab blue.