You have got to be kidding right? Any reading about Watson will quickly reveal that the subtleties of language (specifically English metaphors, similes, and irony) as well as the ingrained underpinnings of Western culture have been its two biggest obstacles since day one, and that's precisely why IBM chose Jeopardy as their next grand AI challenge.

Having dozens of Chinese colleagues, I can assure you that the hidden meanings and references we bury in the English language are completely lost to them even though they know the English words. Do you really think I will understand their jokes, movies, books, etc, just because I flipped a switch and heard a word-for-word translation from Chinese to English? (Even that situation is absurd, actually, because Chinese-English translators have to see a sentence and translate holistically, where many colloquialisms and phrases lose their meaning in translation)

Here's a quick example:
(Exact translation from Chinese to English) "Watchful caution! Avatar come!"

If you thought that meant a blue creature or a virtual representation of a person was coming for you, you'd be wrong. Chinese gamers call a bombing helicopter/hovercraft an "Avatar," because they first saw one in the movie Avatar. If Watson got that right, he'd have to know a very subtle fact about Chinese culture, and Jeopardy is replete with these cultural landmines.

If IBM can prove a machine understands the deep underpinnings of our language AND culture by correctly answering very apocryphal questions better than a Jeopardy champion, then the company will have effectively demonstrated the world's best language and cultural interpreter to bridge the gap between man and machine.

It is worth noting that much (silicon included) doesn't scatter electrons over such a short range, so a great many materials could technically be quantified as superconductors on this scale.
The reason such small things aren't normally touted as "superconducting" is because the contact resistance with something so small becomes so amazingly large that the whole reason of having a superconductor is destroyed. This is precisely why the superconducting regimes of graphene and nanotubes aren't practical: forming a decent contact is not doable at present.

Because of this, it is far more important to create a superconducting wire of substantial length to save power, as resistance scales with length anyway.

Yes, this is true: IEEE has recently been very lax in separating programming from engineering, further exacerbating this problem.

It was particularly frustrating when the IEEE consultant group in Silicon Valley morphed over time into a bunch of software experts with almost no engineering knowledge.

That's when I finally decided my Optical Society of America membership was worth renewing over my IEEE membership.

I interviewed over 100 applicants, and not a single programmer by trade satisfactorily knew more than 2 answers, while the 10 engineers I found got roughly half of them right. I did find it interesting that almost all of the programmers thought they knew the answers and had gotten them right when they clearly did not.

It is also worth noting that several people were clearly abusing Wikipedia during the phone interviews, as you could hear the rapid keystrokes followed by pauses and that they could not answer simple follow up questions probing their knowledge of the subject matter.

Ultimately, the person who got the job was an Electrical Engineer who deeply understood all of these questions, their follow-ups, and more engineering questions I didn't post, as well as some programming questions like "what's the difference between the heap and the stack?"

Turns out he only got the programming questions right because he was forced to be a Computer Science TA for a semester.

An increasing number of programmers over the years have started calling themselves engineers, and it truly bothers me. This source of ire came to a head 2 years ago when I needed to hire engineers that also knew how to program. Being in Seattle, 99% of the applicants advertised themselves as engineers, and while many of them were intelligent and very well versed in programming principles and practices, not a single one of them knew anything about what would be learned in engineering school.

Here are some examples of interviewing questions I made to lend understanding of the distinction I had to make between programmers and engineers:
What is a Fourier (or Laplace) transform?
What is a convolution?
What is an RMS mean compared to an average?
What is a duty cycle?
How do you apply Kirchoff's law to a circuit?
What is the time constant of an RC circuit, and what does it mean?
What is the resonance frequency of an RLC circuit?
What is the nyquist frequency?
What does a PID controller do?
What is a normal force?
What is Colomb's Law?
What conditions are needed to change 2 sandwiched diodes into a transistor?
Explain what a conduction band is.
What is a triple point for a material?
What happens to the orbitals of atoms as they are brought closer together?
How can you make steel conduct heat better, and what are the drawbacks?
What is metal fatigue on the micro or nanoscopic level?
What is Newton's Law of Cooling?
What does the Reynolds number tell you?
What is a Carnot engine and why is it special?
What should the flow velocity be directly on a surface experiencing laminar flow?

Programmers had a higher chance of answering the few questions at the top compared to the bottom, but one thing was painfully clear: those who had learned engineering knew most of the answers, and programmers calling themselves engineers usually knew none. This particular list covers many disciplines, but this list actually covers what you'd need to know as a COMPUTER ENGINEER to pass the fundamentals of engineering exam. Computer Scientists simply do not learn an engineering background to have this kind of knowledge.

As a practicing engineer that has seen programmers severely injure people, blow up objects, and burn circuitry due to their lack of engineering knowledge, the fundamental distinction I draw between an engineer and programmer is that a programmer mostly deals with concepts and ideas entirely created by humans, where engineers are forced to understand and deal with nature itself on an everyday basis.

To clarify this point, I usually liken programmers to mathematicians: Good ones are usually scientists and have to constantly utilize the scientific method to get their job done, and their work is constantly invoked by the world on a regular basis, but generally their work routinely deals with abstractions and hierarchies, and they can do their job quite well without understanding how the physical world works. Indeed, some of the best programmers I've ever known have built amazingly efficient "engines" without ever knowing how the physical components they rely upon are designed or operate on a physical level.

I will grudingly admit that there clearly is a fuzzy line between engineer and programmer, but it falls squarely within the Computer Engineering discipline. Some of us "code" in hardware, where the chip physics is our syntax, making us much more in the engineering camp, and some of us move entirely into the machine/instruction language regime, where an understanding of the computer science of creating an abstract algorithm and less of the physics come more into play, making those of us closer to computer science. By the time you get beyond chips reading machine language, the man-made abstract meaning of the 1s and 0s are what fill your mind entirely, leaving the physics to someone else, and that science of crafting a decently run representation is called programming.

The fact that you could go on to craft entire systems using black boxes that operate as you command means that while your efforts are certainly complex and necessary, it is not engineering.

The elements are not really "there," unfortunately, as this demands electrode implants, which are a long ways off from being reliable/safe. As an electrical engineer who built electrode devices to read muscle commands, I can also tell you with confidence that invasive methods are the only possibility, as noninvasive brain/nerve scans are simply too weak to make confident guesses on what you're thinking. 95% is the absolute best I've ever seen for non-invasive in very unrealistic settings (thinking of a single word or looking at a particular picture for tens of seconds), and while 95% sounds great, it means it would do the wrong thing for you in 1 out of 20 commands. Granted, there is a lot of work on invasives, but most engineers won't touch it with a 100 foot pole, as invading a person's skull = FDA regulation until you drown. Because of this, progress is glacial instead of the frantic pace of innovation people are used to in the electronics industry. If you get your technology wrong in even a very subtle way, the class action lawsuit you face from incapacitated customers will dwarf the $10 million prize.

This should be good news. The best DA year will be when there are no awards, indicative that the previous deaths actually went to a decent cause.

My college roommate/best-friend was in the same scenario with EQ and was already flunking his classes, so I offered to play with him for 1-2 hours in exchange for 30 minutes of studying outside. I slowly ramped up the study time outside without changing the 1-2 hours online together. Within 3 weeks, he was studying over an hour a day with me again. (We had the same major, so that was perhaps more fortuitous than your situation) It took a lot of my time and effort, but he at least passed his courses and graduated.

Game Devs not listening to their player base has to be the biggest downfall for the current overall stagnation in gameplay. I may not like Vendetta's play-style, but I'm definitely trying it now that it's obvious their devs care about their playerbase. They deserve that much support.