It is faster and more efficient on a long image-heavy page like this, because they're not loading the larger images until the user scrolls to them (try reloading the page and scrolling quickly to see). So it's not entirely pointless.
Even if China retaliates (more than they already have), their economy is way more dependent on physical exports to the US than the reverse. I see more downside risks being exposed to EM than US markets… though I do see US markets catching up soon, esp companies with large exposure to EM revenue flows.
This has been a good year to be short EM and swing in and out of volatility.
We are currently running a $375 billion dollar trade deficit with China. That means each year they receive a net gain of $375 billion in trade with us. And ironically the Chinese already had disproportionate tariffs against numerous American exports. A handy tool on Google is search by date range (wish DDG had this). Search for 'Chinese tariffs' on google with a date range of 2000-2015. You'll find articles such as this [1] referencing China's minimum 25% import tariff on American vehicles contrasted against 5% from the US.
Or articles such as this [2] which I will leave without further comment, since that's an entirely different topic...
Something I've been wondering about this. China is retaliating with tariffs against, for example: Sinograin [1]. What exactly is the point of this tariff when the company being taxed is, like many big companies in China, state owned? Aren't they essentially just taxing themselves?
I'd expect that was just an amusing incident of the left hand not knowing what the right is doing.
Throwing out tariffs on the US farm industry is probably a smart move from a political point of view. Our farm industry is heavily subsidized and controlled by government programs. For instance we literally pay some farmers not to farm lands and in cases where harvests are unexpectedly high farmers can end up being prohibited from marketing some of their harvest. In extreme cases, this means the product -perfectly edible foods- just ends up getting destroyed. It's all about extreme control of supply to try to stabilize prices for the consumer and ensure farmers are a bit more insulated from the swings of the market, and to keep them farming (or potentially farming) year after year.
Anyhow, the point of this is that by imposing tariffs on American agriculture (thus reducing Chinese demand) you stand to force this system to respond very visible ways, such as for instance by increasing the number of farmers being paid not to farm or increasing the amount of harvest that can't be marketed. Imagine a photo of some US farmer surrounded by produce thrown to rot and a headline suggesting this was the product of the tariffs. Great propaganda that makes good headlines against the purpose of the tariffs. That a Chinese state company ended up paying the tariffs, rather than just achieving the end of reducing demand and thus hitting with some bad PR in the states, is something I'd expect is just a hilarious short-term miscalculation.
> Anyhow, the point of this is that by imposing tariffs on American agriculture (thus reducing Chinese demand) you stand to force this system to respond very visible ways, such as for instance by increasing the number of farmers being paid not to farm or increasing the amount of harvest that can't be marketed.
The only thing the tariff forces is Chinese companies paying it. This might in turn incentivize them to not purchase American produce which would lead to the effects you're describing. But why incentivize a company to do something if you're running the company? Can't you just tell them to do whatever it is you want them to do directly? Or are they not, in that sense, running the company?
We can only speculate but in this case I'd expect the order was part of a preexisting (or perhaps even prepaid) contract with the US supplier. Or perhaps this company had demands leaving them unable to cancel the contract even if it was possible. With a country of 1.4 billion and certainly the most expansive government in the history of our species, I wouldn't view the Chinese government as homogeneous. Even in our relatively tiny government one segment regularly engages in action much to the detriment or disagreement of another. In the longterm though I would expect this 'issue' to be 'fixed'.
The people enacting these policies (Trump admin) argue that what we currently have is not trade, given how the Chinese have manipulated the markets, it is a one sided agreement. Free trade requires both sides not place restrictions on the others. Would you say this is true? Sometimes I feel like economic theory is like psychology, it seems real, seems like it has truth, but counter examples are abundant?
It really would not be difficult to move school later - school hours are already out of sync with 9-5 of 9-6 or the other hours parents work, if anything it’d be welcome.
Of course it would. School starts at roughly the same time as normal work hours. Most schools start a little before here to allow parents get to work after dropping off their kids.
You couldn't just change school hours in isolation without causing a lot of disruption.
School hours are 9-3:20 where I live, so they are nowhere near in line with working hours as you need time to get to work and not many jobs finish that early. Most schools run breakfast clubs and after school clubs as a result.
School began at 7:50 am for us. So that time worked well for parents and 9-5 sort of times. It gave enough room for 8-4 or 8-5 parents and long commute parents. Or parents who want to drop off and come back home first. If you make the school start time 9 am as well, if a parent helps their kid get ready and/or has to be around until the kid leaves for the bus and/or has to drop them off, they wouldn’t be able to unless their commute is short.
I don’t think school times can be pushed much. Maybe 30 min max without seriously disrupting parent’s schedules if that’s a concern.
I want to call my Uncle Steve in Melbourne. What time is it there?
Google tells me it is currently 4:25am there, so I'd better not call.
The answer without time zones would be:
It's 18:30 UTC
Google tells me business hours are 23:00 to 03:00, so I'd better not call.
Abolishing time zones would make little difference to this kind of question, it will always rely on knowledge of local hours and on top of that your Uncle's schedule.
It would simplify a lot of coordination though.
Unlikely to happen any time soon IMO as people are attached to the status quo and have no big reason to change.
There's still the issue with a single solar period spanning multiple days in regions.
This alone is a good enough reason to abandon the idea, since whomever gets stuck in the regions with diurnal day changes will absolutely refuse to use it.
In many parts of the world it will e.g. turn from 23:59 Friday 17th to 00:00 Saturday 18th in the middle of lunch.
This means a simple term like "lunchtime on Saturday" is suddenly ambiguous/useless, since it could mean around 00:30 Saturday (shortly after local solar noon) or it could equally mean around 23:30 Saturday (shortly before local solar noon the following solar day).
We do have the midnight problem. Every time I say something like, "Midnight on Saturday" the response is "Friday night or Sunday morning?"
Yes, midnight technically "belongs" to the day that follows, but it's often used informally to mean the end of the day.
Also, "midnight" has a defined time. It's 12:00 AM. "Lunchtime" does not have a defined time. It's sometimes 11:00 AM, or sometimes 12:30PM. It's a fuzzy time of day.
And the problem isn't just with lunch on a "split" day. What about phrases like, "After work on Friday" (when Friday begins at solar 17:00)? Is that gonna be a different day for Suzie who ends her shift at 23:00 UTC vs. Tommy who clocks out at 01:00 UTC?
What would quickly happen is that people would still use the Sun's position to demarcate the days, and we're back to days starting at different times of the clock in different places. And back to confusion when scheduling across large distances.
Look, the Earth is round and the sun rises at different times for everyone. Having discrete time-zones is probably the most elegant way of dealing with that problem. Any attempt to enforce UTC across the world just moves all the math to the shadows. We're still gonna have to do it, though. At least let's standardize it.
For example having local time vs official time. This is what remote cities in western China are using. They've to use same time as east coast, but it makes no sense at all for them. So they plan everything around unofficial local time.
How do you know which was originally Thursday the earlier or later part? Or do you have to calculate it based off old UTC offset? What if you move across the globe? What if you talk to somebody online and they say they're doing smth on Thursday? How do you know which Thursday is theirs?
> Then again, people would develop a convention within days. A month, tops.
That's exactly my point -- the convention they adopt will most likely be to abandon UTC in favor of some local time. At which point, we end up with an ad hoc reinvention of timezones.
In Spain, people typically do stuff at and beyond midnight (some drinks, partying, etc) and this is absolutely a non-issue. Everyone assumes "Saturday night at 12:30" to mean what technically is Sunday, 00:30.
Let's say the world decides to follow UTC. In Hawaii, Midnight UTC is 2pm in the afternoon in our current system. So in the early "solar afternoon" it will switch from Monday to Tuesday.
So if you're working late on Tuesday you'd have to clarify or use some other phrase.
Sure, but for every example there is a perfect mirror example. Say you're on a phone call with your uncle Steve in Melbourne. At the end of the call, Steven says he will call you back at 18:30 tomorrow. If there was one global time zone, you wouldn't need to do any time conversion to know when to expect the call.
That’s what I meant by It would simplify a lot of coordination though, I agree zones don’t help this sort of question, if anything they hinder.
Main problem with getting rid of zones are day boundaries and people getting used to a 24 hour clock and arbitrary hours ( even the proposer here used am and pm!), so days would start at odd hours - at least the term noon would be a lot more accurate :) It would seem odd for Saturday say to start at 23:00 in some places though.
Well, Google would tell you something more like "business hours are 23:00 to 24:00 and 00:00 to 03:00 Monday to Thursday, 00:00 to 03:00 Friday, closed Saturday and 23:00 to 24:00 Sunday".
No. I own one and regret buying it. The fingerprint sensor is the only useful bit of the touch bar, missing esc key is annoying if you use vim, and the keyboard is pretty terrible, even if I hadn't seen different keys come off or come loose. Have another appointment to get it fixed next week.
I explicitly avoided the Touch Bar, so it sucks I had to get the lower specs and fewer ports. I already remap Caps Lock to Ctrl and after playing around the ESC would really bother me. The travel on the new keyboard grew on me pretty quickly, but after almost a year I think I'm getting double-letters on certain keys and I still really really hate the half-height arrow keys. It sounds so silly, but if they released a new version with fill-sized arrow keys and maybe one other gripe (like an updated camera--seriously, this is the same camera on my 6yo macbook) I'd sell this one and buy another. Otherwise I'll probably put up with this for a few years until I'm fed up and find a PC laptop I'm willing to live with...
That's a feature, not a bug. It means I don't have to deal with anyone's 'clever' code.
It's not about saving the compiler work at all, it's about saving the hundreds of humans who have to read your code after you the work of understanding the abstractions you created.
A little duplication is better than the wrong abstraction, and I've seen far more subtly wrong or obfuscating abstractions than duplication in code I have to manage. Go is definitely not perfect, and sometimes it's plain wrong about this (I don't particularly like the go error handling and hope it improves), but there is a reason for discouraging certain types of abstraction and encouraging verbosity and boring code instead, and it's not to save the compiler time.
Abstractions like map and filter that have decades of use and countless pages of research behind them are not the wrong abstraction. You are more likely to get the wrong abstraction by forcing programmers to create their own abstractions instead of letting them use well-known ones that have been refined over many years.
I'm not sure anyone was opposed to map (that wasn't under discussion), not all abstractions are bad, however a flexible language makes code easier to write but harder to read, a rigid language makes code harder to write but easier to read. I prefer ones that are easier to read, even at the expense of a little verbosity.
I'm not saying Go is the best of all possible worlds (I would like to see generic functions like map too, or things like sum types for errors), just that there are good reasons for the decision to exclude some opportunities to build abstractions (for example I'm happy go eschews inheritance), and abstraction is not an unmitigated good. I've seen far more bad abstractions built than code duplicated when reading code in any language, so limiting abstractions is not always a bad thing.
> A little duplication is better than the wrong abstraction
Besides the notion of "The wrong abstraction", which is sometimes used as a proxy for "Abstractions I don't want to learn", we're discussing about language level abstractions here. The article you quote criticizes user level abstractions.
Language-level abstractions have a decent enough track record that we can assess them. Go even uses some of them: GC is, after all, an abstraction.
There would also be a lot to say about what the "little" in "A little duplication" means.
This. Either you check in a DSL, or you try to compile the DSL to boilerplate in your head and check that in, then everyone has to try to read the boilerplate and try to infer what the DSL would have said.
It's always strange watching programmers defend go's obvious deficiencies. I mean, this sort of "appeal to simplicity" could be used to defend anything.
The reality is most go programs are (1) very difficult to understand because error handling swamps their logic and (2) end up reinventing exceptions anyways, albiet poorly and (3) inevitably end up leaking resources because go's "error handling strategy" doesn't ensure resource cleanup.
We can observe this and measure this quite clearly in non-trivial go codebases.
Eventually the go dictatorship will relent and provide exceptions. At that point all the people who praise the existing broken model will happily praise the new approach and denounce the existing brokenness.
I wholeheartedly agree with you. Go got a lot right (concurrency, deployment), but some parts of Go's language design are missing the last two decades of programming language history. To me, arguments supporting Go's error handling approach alway seem a little bit like people are rationalizing a horrible mistake.
