Introduction

I want to give an introduction on several physics topics at a level understandable to laypeople (high school level physics background). Making physics accessible to laypeople is a much discussed topic at universities. It can be very hard to translate the professional terms into a language understandable by people outside the field. So I will take this opportunity to challenge myself to (hopefully) create an understandable introduction to interesting topics in modern physics. To this end, I will take liberties in explaining things, and not always go for full scientific accuracy, while hopefully still getting the core concepts across. If a more in-depth explanation is wanted, please ask in the comments and I will do my best to answer.

Previous topics

Bookmarkable meta post with links to all previous topics

Today's topic

Today's topic is the dual nature of light and matter, the wave-particle duality. It is a central concept in quantum mechanics that - as is tradition - violates common sense. I will first discuss the duality for light and then, in the next post, for matter.

The dual nature of light

In what terms can we think of light so that its behaviour becomes understandable to us? As waves? Or as particles? There are arguments to be made for both. Let's look at what phenomena we can explain if we treat light as a wave.

The wave nature of light

Let's start with an analogy. Drop two stones in a pond, imagine what happens to the ripples in the pond when they meet each other. They will interact, when two troughs meet they amplify each other, forming a deeper trough. When two crests meet they do the same. When a crest and a trough meet they cancel out.

Now if we shine light through two small openings and observe the resulting pattern, we see it's just like ripples in a pond, forming an interference pattern. When looking at the pattern formed on a screen placed at some distance from the openings, we see a striped pattern Light can be described as an electromagnetic wave, with crests and troughs. It sure seems like light is wavey! The wave nature of light allows us to describe phenomena like refraction and diffraction.

The particle nature of light

When we shine light on some metals, they will start tossing out electrons. This is called the photoelectric effect. How can we understand this process? Well we know light is a wave, so we imagine that the wave crashes into the electron that is chilling out near the surface of the metal. Once the electron has absorbed enough of the light's energy it will be able to overcome the attractive forces between itself and the positively charged atom core (remember, an electron has negative charge and so is attracted to the atom cores). So a higher intensity of light should make the electron absorb the required amount of energy more quickly. Easy, done!

However, there's something very peculiar going on with the photoelectric effect. If we shine low frequency light on said metal, no matter how intense the light, not a single electron will emerge. Meanwhile if we shine very little high frequency light on the metal, no matter how low the intensity, the electron will emerge. But how can this be? A higher intensity of light should mean the electron is receiving more energy. Why does frequency enter into this?

It seems that the electron needs a single solid punch in order to escape the metal. In other words, it seems it needs to be hit by something like a microscopic billiard ball that will punch it out of the metal in one go. The way physicists understand this is by saying light is made up out of particles called photons, and that the energy a photon carries is linked to its frequency. So, now we can understand the photoelectric effect! When the frequency is high enough, the photons in the light beam all individually carry enough energy to convince an electron to leave the metal. When the frequency is too low, none of the photons individually can knock an electron out of the metal. So even if we fire a single photon, with high enough frequency, at the metal we will see one electron emerging. If we shine low frequency light with a super high intensity at the metal, not a single photon will emerge.

So there you have it! Light is made out of particles. Wait, what? You just told us it's made out of electromagnetic waves!

The wave-particle duality of light

So, maybe light is just particles and the wave are some sort of emerging behaviour? This was a popular idea, one that Einstein held for some time. Remember the experiment where we shone light through two small openings and saw interference (commonly known as the double slit experiment)? Let's just take a single photon and shoot it at the openings! Because light is particles we'll see the photon just goes through either opening - like a particle would. Then all the non-believers will have to admit light is made out of particles! However, when we do the experiment we see the photon interfere with itself, like it was a wave. Remember this picture which we said was due to wave interference of light? When a single photon goes through the openings, it will land somewhere on the screen, but it can only ever land in an area where the light waves wouldn't cancel out. If we shoot a bunch of photons through the openings one at a time, we will see that the photons create the same pattern as the one we said is due to wave interference!

Implications

So it would seem light acts like a particle in some cases, but it acts like a wave in some others. Let's take a step back and question these results. Why are we trying to fit light into either description? Just because it's convenient for us to think about things like waves and particles - we understand them intuitively. But really, there is no reason nature needs to behave in ways we find easy to understand. Why can't a photon be a bit wavey and a bit particley at the same time? Is it really that weird, or is it just our intuition being confused by this world we have no intuitive experience with? I would love to hear your opinions in the comments!

Observing photons

To add one final helping of crazy to this story; if we measure the photon's location right after it emerges from the slit we find that it doesn't interfere with itself and that it just went through a single slit. This links back to my previous post where I described superpositions in quantum mechanics. By observing the photon at the slits, we collapsed its superposition and it will behave as if it's really located at one spot, instead of being somehow spread out like a wave and interacting with itself. The self interaction is a result of its wavefunction interacting with itself, a concept that I will explain in the next post.

Conclusion

We learned that light cannot be described fully by treating it simply as a wave or simply as a bunch of particles. It seems to be a bit of both - but neither - at the same time. This forces us to abandon our intuition and accept that the quantum world is just fundamentally different from our every day life.

Next time

Next time we will talk about the dual nature of matter and try to unify the wave and particle descriptions through a concept known as the wavefunction.

Feedback

As usual, please let me know where I missed the mark. Also let me know if things are not clear to you, I will try to explain further in the comments!

Addendum

The photoelectric effect is actually what gave Einstein his Nobel prize! Although he is famous for his work on relativity theory he was very influential in the development of quantum mechanics too.

I've posted a few lengthy topics here outside of programming challenges, and I've noticed that the ones that seem to have spurred the most interest and generated some discussion were ones that were directly related to code quality. To avoid falling for confirmation bias, though, I thought I would ask directly.

Is there generally a greater interest in code quality discussions? If so, then what kind of things are you interested in seeing in those discussions? What do you prefer not to see? If not, then what kinds of programming-related discussions would you prefer to see more of? What about non-programming discussions?

Also, is there any interest in an informal series of topics much like the programming challenges or the a layperson's introduction to... series (i.e. decentralized and available for anyone to participate whenever)? Personally, I'd be interested in seeing more on the subject from others!

I've tried using search (both by keyword and by tag) but I couldn't find anything about this. What's Tildes opinion about posting old news that haven't been discussed yet? I'm not talking about your regular news post from a newspaper that is already too late to be discussed about, I'm talking about things such as software releases or old blog posts that have never been posted but would be interesting to discuss about. How would one tag them? Where should we post them if allowed?

Edit: I'm sorry but I won't be here for discussing this tomorrow or during the weekend. I'm not staying at home, but I hope I can come back to some good responses next week.

Welcome to week 22! Here we've got this week's user-voted record: Survival by Bob Marley & The Wailers!

Taken from @koan's pitch:

Does Bob Marley have gold and platinum records? Definitely. Survival is not one of them, but in my opinion it is by far his greatest album -- hands down, no competition. Everybody has an opinion about Bob Marley, whether you've actually given him a shot or not. Reggae can be polarizing. Some love it, some think it's corny. But Survival is not corny. It's Marley's greatest roots reggae record.

While some Bob Marley songs might make you want to relax on a beach and sip cold cocktails, the songs on Survival make you want to get up and do something about shit. When I was absolutely stewing in dissatisfaction with my corporate job, listening to Survival on my commute in the morning inspired me to change my life. Be careful, because listening to it too much might turn you into a revolutionary.

If you're unfamiliar with reggae in general, or you think it's silly, give this record a chance. It might change your perspective about a very deep and varied genre of music.

Here's the place to discuss your thoughts on the record, your history with it or the artist, and basically talk about whatever you want to that goes along with Survival. Remember that this is intended to be a slow moving thing, feel free to take your time and comment at any point in the week!

If you'd like to stream or buy the album, it can be found on most platforms here.

Preface

Occasionally I feel the need to touch on the subject of code quality, particularly because of the importance of its impact on technical debt, especially as I continue to encounter the effects of technical debt in my own work and do my best to manage it. It's a subject that is unfortunately not emphasized nearly enough in academia.

Background

As a refresher, technical debt is the long-term cost of the design decisions in your code. These costs can manifest in different ways, such as greater difficulty in understanding what your code is doing or making non-breaking changes to it. More generally, these costs manifest as additional time and resources being spent to make some kind of change.

Sometimes these costs aren't things you think to consider. One such consideration is how difficult it might be to upgrade a specific technology in your stack. For example, what if you've built a back-end system that integrates with AWS and you suddenly need to upgrade your SDK? In a small project this might be easy, but what if you've built a system that you've been maintaining for years and it relies heavily on AWS integrations? If the method names, namespaces, argument orders, or anything else has changed between versions, then suddenly you'll need to update every single reference to an AWS-related tool in your code to reflect those changes. In larger software projects, this could be a daunting and incredibly expensive task, spanning potentially weeks or even months of work and testing.

That is, unless you keep those references to a minimum.

A Toy Example

This is where "wrapping" your external libraries comes into play. The concept of "wrapping" basically means to create some other function or object that takes care of operating the functions or object methods that you really want to target. One example might look like this:

<?php

class ImportedClass {
    public function methodThatMightBecomeModified($arg1, $arg2) {
        // Do something.
    }
}

class ImportedClassWrapper {
    private $class_instance = null;

    private function getInstance() {
        if(is_null($this->class_instance)) {
            $this->class_instance = new ImportedClass();
        }

        return $this->class_instance;
    }

    public function wrappedMethod($arg1, $arg2) {
        return $this->getInstance()->methodThatMightBecomeModified($arg1, $arg2);
    }
}

?>

Updating Tools Doesn't Have to Suck

Imagine that our ImportedClass has some important new features that we need to make use of that are only available in the most recent version, and we're several versions behind. The problem, of course, is that there were a lot of changes that ended up being made between our current version and the new version. For example, ImportedClass is now called NewImportedClass. On top of that, methodThatMightBecomeModified is now called methodThatWasModified, and the argument order ended up getting switched around!

Now imagine that we were directly calling new ImportedClass() in many different places in our code, as well as directly invoking methodThatMightBecomeModified:

<?php

$imported_class_instance = new ImportedClass();
$imported_class_instance->methodThatMightBeModified($val1, $val2);

?>

For every single instance in our code, we need to perform a replacement. There is a linear or--in terms of Big-O notation--a complexity of O(n) to make these replacements. If we assume that we only ever used this one method, and we used it 100 times, then there are 100 instances of new ImportClass() to update and another 100 instances of the method invocation, equaling 200 lines of code to change. Furthermore, we need to remember each of the replacements that need to be made and carefully avoid making any errors in the process. This is clearly non-ideal.

Now imagine that we chose instead to use the wrapper object:

<?php

$imported_class_wrapper = new ImportedClassWrapper();
$imported_class_wrapper->wrappedMethod($val1, $val2);

?>

Our updates are now limited only to the wrapper class:

<?php

class ImportedClassWrapper {
    private $class_instance = null;

    private function getInstance() {
        if(is_null($this->class_instance)) {
            $this->class_instance = new NewImportedClass();
        }

        return $this->class_instance;
    }

    public function wrappedMethod($arg1, $arg2) {
        return $this->getInstance()->methodThatWasModified($arg2, $arg1);
    }
}

?>

Rather than making changes to 200 lines of code, we've now made changes to only 2. What was once an O(n) complexity change has now turned into an O(1) complexity change to make this upgrade. Not bad for a few extra lines of code!

A Practical Example

Toy problems are all well and good, but how does this translate to reality?

Well, I ran into such a problem myself once. Running MongoDB with PHP requires the use of an external driver, and this driver provides an object representing a MongoDB ObjectId. I needed to perform a migration from one hosting provider over to a new cloud hosting provider, with the application and database services, which were originally hosted on the same physical machine, hosted on separate servers. For security reasons, this required an upgrade to a newer version of MongoDB, which in turn required an upgrade to a newer version of the driver.

This upgrade resulted in many of the calls to new MongoId() failing, because the old version of the driver would accept empty strings and other invalid ID strings and default to generating a new ObjectId, whereas the new version of the driver treated invalid ID strings as failing errors. And there were many, many cases where invalid strings were being passed into the constructor.

Even after spending hours replacing the (literally) several dozen instances of the constructor calls, there were still some places in the code where invalid strings managed to get passed in. This made for a very costly upgrade.

The bugs were easy to fix after the initial replacements, though. After wrapping new MongoId() inside of a wrapper function, a few additional conditional statements inside of the new function resolved the bugs without having to dig around the rest of the code base.

Final Thoughts

This is one of those lessons that you don't fully appreciate until you've experienced the technical debt of an unwrapped external library first-hand. Code quality is an active effort, but a worthwhile one. It requires you to be willing to throw away potentially hours or even days of work when you realize that something needs to change, because you're thinking about how to keep yourself from banging your head against a wall later down the line instead of thinking only about how to finish up your current task.

"Work smarter, not harder" means putting in some hard work upfront to keep your technical debt under control.

That's all for now, and remember: don't be fools, wrap your external tools.

If you've been following tech news somewhat recently, you've surely heard about Article 13- the one where the EU essentially requires all content hosts to have extremely strict copyright checking tools and have automated takedown of any potentially copyrighted works.

That got put on the backburner for a little bit, but now it's back with a vote being held in early 2019.

YouTube, being one of, if not the largest content hosts in the world, is greatly affected by this motion. In fact, they have a whole website designed to encourage their creators to talk about A13 in their videos. The page very subtly hints at massive service changes that will happen in the EU if this actually ends up passing.

The CEO of YouTube, Susan Wojcicki, has also written an op-ed for Financial times (linked to official YT blog since it's free there) about the issues facing YT if A13 passes.

I haven't heard anything from official sources, but I've heard on the rumor mill that YouTube will completely suspend creators in the EU, not allowing them to upload any content, and potentially even removing their existing content from YouTube.

What if this passes? YouTube is one of the biggest sources of free knowledge and entertainment we have today, and it's become engrained into the internet as it is today.

With all this, I simply ask, "what's next?"

Filling in again this week.

What have you been listening to this week? You don't need to do a 6000 word review if you don't want to, but please write something!

Feel free to give recs or discuss anything about each others' listening habits.

You can make a chart if you use last.fm:

http://www.tapmusic.net/lastfm/

Remember that linking directly to your image will update with your future listening, make sure to reupload to somewhere like imgur if you'd like it to remain what you have at the time of posting.