I read that part of the article as being completely oblivious to the scientist's arguments. The scientists said that Brexit would harm British science. Forbes says, "so what, Britain can just import the science like it does jeans."
In other words, Forbes seems to agree that Brexit will harm British science. They just don't think that it's important.
What is it with reviewers and their complete inability to explain that more expensive often means higher performance?
I see it in phone reviews all the time -- "we compared this quite nice inexpensive phone against an $800 phone. The inexpensive phone had a worse display, used plastic instead of metal, and felt less pleasing....". Yeah, not really a surprise.
In this case, they compare the Pi3 against other, more expensive boards and are shocked -- shocked! -- to discover that some more expensive boards have more components and run faster!
So in your mind Astronomy isn't a science?
It's only common within a subset of the community.
I've been a Slashdot reader forever; I own a smartphone; I have been a professional programmer since before they even had smartphones. But until I joined a group that actually had to interact with MDM software (I do email sync; we need to interact with policy managers to support Exchange ActiveSync policies), I had never heard of MDM as an acronym.
My first computer was a ZX80 -- fond memories!
I liked it enough that my hobby Calculator app for Windows is now programmable in BASIC. It turns out that making a BASIC interpreter is pretty simple these days; there's a bunch of parser-generators to make it simple to program up the language, and modern computers are super-fast even when dealing with non-optimized code. In fact, the hard part is that people expect more GUI bits in the code, and getting those to all work took longer than the actual programming.
The downside is that it doesn't emulate any particular computer, and it's missing some nice features like "graphics" and "multiple statements on a line".
Link to app: https://www.microsoft.com/en-us/store/apps/best-calculator/9wzdncrdfd6x/
Link to manual: https://bestcalculator.files.wordpress.com/2015/09/bestcalculatorbasicreference.pdf/
Yes....and no. There are four codes like you say -- T40.8X1,
But you know what? Each of the drug overdose sections includes the same subtypes, and using the same codes (except that actually LSD is an outlier; the other ones in the same section include items for "Adverse effect" and "underdosing".
Doctors (and intake nurses) who use electronic patient records (which should be most by now) should find that their software will guide them through the codes as they enter the patient data.
You go to war with the army you have
What we have is Unicode and a good set of font fallbacks. What we don't have is an unspecified, unplanned, unwritten way to somehow insert a "pictogram" inside my stream of "glyphs".
What we need is a way to draw shapes on a screen or piece of paper where a designer gets to pick roughly what they look like. Unicode does that, and therefore seems like an adequate tool for this job.
Yes, except that they didn't. They took a list of eight items (section 4.2.1.4 of the underlying CODEX STAN 1-1985), and presented a proposal for seven of them. What happened to the last? I don't know: perhaps they didn't figure out how to make a character for "Sulphite in concentrations of 10 mg/kg or more".
They also missed section 5.2.1, irradiated foods, with a separate symbol.
Without a hearing? The hearing happened, and they lost big time. At this point, they are just repeating vague and badly grounded accusations.
I've recently been pawing through my old Basic manuals (I'm implementing a Basic environment for run). And what stands out is how incomplete and limited most of the old environments were (although I did love them at the time).
The Basics were grossly limited. Examples includes the Sinclair AND and OR statements, the very limited FN statements and severe limitations on FOR loops. Given the high expense of disks in those days, it's no surprise that disk handling was uneven at best.
Networking capabilities were trivial to non-existent, and mostly non-existent.
The connection to their environment was deeply weird. From a modern perspective, the first thing we normally do when we see a bit of hardware is to wrap it in a little bit of code to make it simpler to control. The common pattern in the old days was to revel in the POKE and PEEK statements, directly setting hardware registers.
The difference between then and now is that then my plan was to write an program to play lunar lander. My plan today is to write a program that will listen to my mailboxes and change the color of my lights accordingly ("Make it pink!", "Make it blue!")
You'll need some kind of cite for that "was bragged about..." bit. Everything I've read is that it's just not true; that none of the states (for example) realized that by not setting up an exchange that they would be at a disadvantage.
So, of that persons comments, the one about branded actually makes sense. Different companies actually do work on different frequencies (and there's a bunch of other differences; frequency is just part of it). Once we posit that some microwaves cause problems, it's very reasonable that different frequencies would cause more or fewer problems.
There are multiple wineries in Alaska (and they all seem to be new).
I'm going to rephrase what you said, and change it. Don't whine at your boss. Don't complain at your boss.
But do ask for advice ("this other team is delivering really slowly, how should I handle it?", or, "I think I have a better solution for the problem of the day, but I'm having trouble advocating for it, can you help me?")
And let them know when you're behind. My company takes the output of many, many teams and sells the result; there's nothing they hate more than surprises.
The alternative (and I've done it..) is "write once, port everywhere."
What used to be an long, frustrating process (what do you mean, 'unlink' doesn't work?) is now almost trivial.
Without life, Biology itself would be impossible.
