I don’t think that is the point. The argument is usually that we cannot predict what will be “high impact” 20 years from now but the current system works well enough that it is a net benefit despite a lot of research not being directly applicable in the end.
Well, cmake is there because people did the same thing to autoconf, so it’s hard to be too sympathetic. Cmake is useful, but also terrible, like most build systems.
The difference I see is that Autotools is mainly useful for handling differences between various Unix variants, which isn't a concern now that commercial Unix isn't really a thing besides Mac OS X. CMake doesn't have the years of arcane knowledge about dozens of Unix variants that Autotools does, but it lets you target Windows using the native tooling as opposed to having to do all your development in Cygwin, and it automatically generates IDE projects so you can use IDE provided tooling like debuggers and profilers. Personally, I think this is a more compelling value proposition than what Autotools offers. Obviously, if you're fine with using a text editor and GDB and for some reason need to target SunOS, SCO UnixWare, 386BSD, A/UX, etc but not Windows, Autotools is great for that use case and you should stick with it.
Pretty much all newer languages massively simplify their build processes by establishing a bunch of common-sense conventions: the output directory is always the same, all *.foo files in a directory are automatically considered source files, the output is identical to the directory name, things like that. They also include proper versioning of dependencies instead of "just assume /usr/include/foo/foo.h is the version we want, yolo".
In principle it's very much possible to do all of this in C or C++, which would massively simplify stuff. But both C and C++ being a "design by committee" affair there will be endless fighting over which conventions to choose so I'm not holding my breath.
I don’t buy things online too often (about once a month, I would say), but regularly I buy on AliExpress things that I cannot find elsewhere at a decent price or at all (mostly electronics and specialised hobbyist stuff). On the other hand, yes, Temi is cheap garbage, and so is much of AliExpress. And Amazon as well, to be honest. Real life leaves room for a lot of nuance.
I get stuff delivered from the UK to the EU very regularly and all competent sellers handle VAT and duties just fine without additional processing fees. Smaller companies don’t always bother, though, but most of the time I don’t have to pay customs because everything is declared properly.
> But the processing fee for customs is usually 20-40 USD. Which can exceed the cost of the package in the first place.
It depends on who you are buying from. This is the order of magnitude of the fee if you let the shipping company handle it. It is extortionate and they do it because at this point buyers don’t have a choice if they want their stuff.
Companies that are used to dealing with foreign customers handle taxes themselves and don’t charge processing fees.
If demand is elastic, then the seller has to lower prices (and their margin), otherwise people don’t buy their stuff (because they can do without). In this situation, the seller eats the tariffs, That’s the case for nice-to-have things like luxury goods and entertainment. If the seller cannot do that, e.g. because their margins become negative, they will just stop doing business (in the US or entirely).
The other end of the spectrum is stuff people cannot do without, in which case the seller has no incentive to lower their margins because their customers don’t have a choice. Then, tariffs are entirely paid by the buyer.
In reality, everything is in between and accurately estimating how much everyone will be paying is very difficult. What we can predict with certainty is that prices can only go up, and that some businesses will fold because they cannot absorb the loss.
> Brexit literally just resulted in the UK having lower tariffs
That is, of course, entirely false. In that the UK does not, in fact, have lower tariffs, and even if that would be the case, there are many downsides that don’t have anything to do with tariffs.
> and a probable free trade deal with the largest economy on the planet
The FTA with the US has been "happening soon" for about a decade now. I’ll believe it when I see it. And with a protectionist American government, it would put the UK at a significant disadvantage.
> unlike our friends on the European continent
LOL. Nobody on the continent wants its country in the same position as the UK is. Brexit killed any political movement to leave the EU for a generation.
They were not applied. Tomorrow, they can be 30% or 5.36%. If your only goal was depending on a fluke and a brain fart of a senile old man 10 years after Brexit was voted, then I don’t need to tell you how poorly thought out it was. If that is your measure of success, then Russia and Belarus welcome you.
1. The EU has that reprieve. Given the EU can bite back, it's possible that reprieve becomes permanent.
2. Last time Trump slapped tariffs on UK + EU, Biden prioritised reversing tariffs on the EU first because they're a bigger trading partner than the UK.
As the above poster pointed out, that's to say nothing of the many downsides of not being in the EU.
It always increases in an isolated system. That caveat is almost always missing in pop-sci level of discussions about entropy, but it is crucial.
> Eventually there will be enough entropy that any change may cause it to reduce or oscillate?
Assuming that the universe is actually an isolated system, entropy will reach a maximum (it cannot oscillate). It is interesting to speculate, and of course our theories are imperfect and we are certainly missing something. In particular, the relationship between time and entropy is not straightforward. Very roughly: is the entropy a function of time, which we could define otherwise, or is time a consequence of entropy changes?
In the first case, we can suppose that if the universe reaches an entropy maximum we’d be far enough outside the conditions under which our theories work that we’d just have entropy decrease with time (i.e., the rule that entropy increases with time is only valid close to our usual conditions).
But in the second case, it would mean that the universe reached the end of time. It could evolve in any conceivable way (in terms of the fundamental laws of Physics), and the arrow of time would always point to the same moment. "What comes after?" Would be a question just as meaningless as "what came before the Big Bang?"
In any case, there are a lot of assumptions and uncertainty. The story does not do the subject any justice.
If it’s the rule, everyone knows it. There is no guessing about randomness or hidden variables, and ultimately less favoritism than a line manager coming up with a stack ranking.
Looking at the larger picture, what otherwise tends to happen is that older people get pushed out. Then we have a massive issue of them ending up unemployed because nobody wants to hire them. This is compounded by the retirement age being pushed further and further away.
Because that’s annoying. YAML is often written and read by humans. If you want a verbose and more regular way to do it, there is always JSON. But JSON is really annoying to deal with for humans, although it is much better than YAML for several applications.
I can't tell if it's irony or not given the sentiment in this thread, but that is not a declaration of a multiline Description field, that's a field of User named "Description:>-" that happens to be missing its trailing ":"
Seeing that used systemically, versus just for "risky" fields makes me want to draw attention to the fantastic remarshal tool[1], which offers a "--yaml-style >" (and "|" and the rest) which will render yaml fields quoted as one wishes
> I can't tell if it's irony or not given the sentiment in this thread, but that is not a declaration of a multiline Description field, that's a field of User named "Description:>-" that happens to be missing its trailing ":"
I do agree it’s a bit of a kludge. But if you want data types and unquoted strings then anything you do to the syntax to denote strings over other data types then becomes a bit of a kludge.
The one good thing about this kludge is it allows for string literals (ie no complicated escaping rules).
> Seeing that used systemically, versus just for "risky" fields makes me want to draw attention to the fantastic remarshal tool[1], which offers a "--yaml-style >" (and "|" and the rest) which will render yaml fields quoted as one wishes
I don’t really understand what you’re alluding to here.
Tell us that you didn't try to use that example without telling us you just eyeballed the post
$ /usr/local/opt/ansible/libexec/bin/python3 -c 'import sys, yaml; print(yaml.safe_load(sys.stdin.read()))' <<YML
User:
Name: >-
Bob
Phone: >-
01234 56789
Description:>-
This is a
multi line
description
YML
yaml.scanner.ScannerError: while scanning a simple key
in "<unicode string>", line 6, column 6:
Description:>-
$ gojq --yaml-input . <<YML
User:
Name: >-
Bob
Phone: >-
01234 56789
Description:>-
This is a
multi line
description
YML
gojq: invalid yaml: <stdin>:6
6 | Description:>-
^ could not find expected ':'
That's because, for better or worse, yaml considers that a legitimate key name, just missing its delimiter
$ gojq --yaml-input . <<YML
User:
Name: >-
Bob
Phone: >-
01234 56789
Description:>-:
This is a
multi line
description
YML
{
"User": {
"Description:>-": "This is a multi line description",
"Name": "Bob",
"Phone": "01234 56789"
}
}
This exchange in a thread complaining about the whitespace sensitivity doesn't escape me
As for remarshal, it was the systemic application of that quoting style that made me think of it, since writing { Name: >- Bob} is the worst of both worlds: not as legible as the plain unquoted version, not suitable for grep, and indentation sensitive
The issue is the lack of white space between the : and the >, not a missing : at the end. I’m typing this on my phone so the odd syntax error might creep in but the key pointer is the examples I linked to and the block token I’ve described.
Further to that point, none of the example links I’ve shared have the : at the end and I have production code that works using the formatting I’ve described. So you’re flat out wrong there with your assumption that block keys always terminate with :
> As for remarshal, it was the systemic application of that quoting style that made me think of it, since writing { Name: >- Bob} is the worst of both worlds: not as legible as the plain unquoted version, not suitable for grep, and indentation sensitive
You wouldn’t write code like that because >- denotes a block and you’re now inlining a string.
I mean I’ve shared links explaining how this works and you’re clearly not reading them.
At the end of the day, I’m not going to argue that >- (and its ilk) solves everything. It clearly doesn’t. If you want to write “minimized” YAML using JSON syntax then you’re far far better off quoting the string.
But if you are writing a string in YAML and either don’t want to deal with quotation marks, or need that string to be a string literal (ie not having to escape things like quotation marks) then my suggestion is an option.
It’s not there as a silver bullet but it is a lesser known feature of YAML. Hence me sharing.
Now go read the links and understand it better. You might genuinely find it useful under some scenarios ;)
I enjoy that you're scolding me about 'not reading' after doubling down the accuracy of your initial post, which, yes, I can easily imagine you did from your phone
And yet I brought receipts for my claims, and you just bring "reed the manul, n00b"
Firstly, I didn't say "read the manual", I said "read the links I shared". And that's a pretty reasonable comment to make given I took the time to find examples knowing that I couldn't easily type them out on my phone. And if you bothered to open the links you'd realize they were brief and to the point. I was actually trying to be helpful.
Secondly, your "receipts" were incorrect. Neither of your examples follows the examples I cited, and your second example creates a key named "Description:>-", which is clearly wrong. Hence why ">-" needs to be after the colon.
Here is more examples and evidence of how to use >- and why your "receipts" were also incorrect:
One final point: I don't understand why you're being so argumentative here. I posted a lesser-known YAML feature in case it helps some people and you've turned it into some kind of pissing match based on bad-faith interpretations of my comments. There was no need for you to do that.
reply