funnymony
> Not if distinct is the default.
If that works for you, great, but let’s agree to disagree here.
Primary reason: distinct on every select shows either lack of knowledge of schema, in particular which columns make rows unique, or unfortunate schema design. (Apart from niche cases, schema should be somewhat normal. I.e. column parent_name belongs in the table parent, not in the table student)
Select a from x where myuniquekey=1; —- guaranted to return 1 or zero rows, if myuiniquekey is actually unique.
Select a from x join y on x.parent_id = y.y_id —- guaranteed to return same amount of rows as exist in y, never more, never duplicates y rows. (N-to-1 relation)
If distinct is used in any of above, then question “why?” naturally arises.
In more severe case, leads to bugs:
Select distinct student.student_name, parent.parent_name from student join parent on student.parent_id = parent.parent_id —- silently discards rows, where by accident student/parent name combo matches several times.
Technically sql allows comparing unrelated columns (colour=last_name), but for vast majority of cases, when joining, one of the side should be joined using it’s unique key, and other side should be using it’s foreign key, which ensures that duplicates don’t appear randomly, and thus distinct is not needed.
If for ten years you always indented the code this way
Void F()
{ Foo();
Bar();
Baz();}
Void F()
{
Foo();
Bar();
Baz();
}
I saw similar, catchy phrase: “parse, don’t validate”.
https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...
That will be part of lib documentation, which should be read & understood regardless of existence of checked exception.
They all use library for file reading.
As author of file reading library you don’t know how critical is the failure to open a file or how it should be handled. My point was that You know those things only at application level.
So it feels a bit misguided to decide at library level which failures are important. (I.e. which are checked vs which are unchecked)
> But as API authors how can we make sure
First thought: documentation. (which is required for both, checked and unchecked exceptions).
But overall, it’s not library author’s responsibility or ability to “ensure”. You can’t force correct handling of exception. At best one can make it a bit more annoying to ignore, and convenient to do the right thing.
My view:
- all exceptions should be unchecked
- assume all code throws
- if “log and exit/continue” is not enough and you need to know exact exception types, dig into the docs.
- read docs during lib version upgrades
My naive take on this would be “just use raii/closable”. (But easily and likely, I misunderstood)
But importance of the failure is determined completely by the program, not the library.
Grep fails to open a file for reading -> message the user and exit
Nuclear reactor controller fails to read important a file -> initiate reactor shutdown or something.
If file read is critical, you have to handle failure no matter what the interface is. Because you know that disk can fail.
We all do.. its always that other guy who is at fault :)
Review and testing.
Reviewing is easier when there is less code (i.e. libraries are in use)
Over time, hydrogen damages the tank. (Which is undesirable combo with “explosive gas when mixed with air”)
I would like some breakthrough in material sciences here.
If I remember video correctly, summary would be: not yet
Yes, lot of people would not reject idea of having it, but at the same time actual demand (i.e. actual number of people who would think price is worth it, is quite lower compared to spagetti which is much cheaper but has many more buyers)
All in all. high price does not necessarily mean huge demand.
Though if forever growth is assumed, and goal post is moved to co2 total instead of per km, then some options exist to eat up that 1000x saving: Owning more than one vehicle per person, buying new automobile more frequently, moving to bigger, better and powerfuler cars.
Lets say number of cars in total follows exponential progression, 5% growth per year.
It follows that after 100 years due to growth co2 gets back to original level. (Log100/log1.05=94)
EVs are required bandaid, but degrowth will come eventually. (Possibly due to climate change supply will decrease and so will consumption)