For a long time, quantum computing sounded like one of those topics people mention to sound futuristic: Qubits. Superposition. Entanglement. Big words, big promises, very little intuition.

Before taking a Quantum Programming course at my master in Stockholm University, I kept coming back to two simple questions:

1. What is all the fuss about?
2. And more importantly, what does quantum programming actually mean?

This article is my attempt to answer those questions in a concrete way, based on what finally clicked for me during the course. It is written for curious beginners, engineers, and anyone who wants a mental model that goes beyond buzzwords.

From “Faster Computers” to “Shaping Probabilities”

One of the first misconceptions I had was thinking that quantum programming meant writing code for faster computers. It does not.

Quantum programming is about designing quantum circuits that control qubits so that the physics of superposition, interference, and entanglement pushes probability toward the right answer. There is no free speedup.

You earn it by carefully structuring the circuit so that, when you finally measure the system, the probability distribution favors the outcome you want.

Qubits and Superposition: Not Both Answers at Once

A classical bit is either 0 or 1.

A qubit can exist in a combination of both, but that description becomes misleading if taken too literally. When you measure a qubit, you always get a definite 0 or 1.

The real power is not in “having both answers”. It is in interference.

Quantum algorithms use interference to amplify the probability of desirable outcomes and suppress the rest. Superposition is the starting point, not the end goal.

Measurement Is Not Reading Memory

This was one of the most counterintuitive lessons for me.

In classical computing, reading memory does not change its content. In quantum computing, measurement fundamentally alters the system.

Measurement is not observation. It is sampling.

You are sampling an outcome from a probability distribution that you have deliberately engineered through gates and interference.

Once you measure, the quantum state collapses. There is no going back.

Entanglement: One System, Not Many Parts

Entanglement is often described as mysterious, but thinking of entangled qubits as separate objects misses the point.

Entangled qubits behave like one system.

Measuring one qubit immediately gives you information about the other, regardless of distance. Many quantum protocols rely on entanglement as a computational and informational resource.

Measuring one qubit gives you information about the other, regardless of distance, though this does not enable faster-than-light communication.

Gates and Circuits: Programming with Reversible Operations

Quantum programs are built from unitary gates, which are reversible operations.

Some of the most common gates I learned and used were:

• H (Hadamard), to create superposition
• X and Z, quantum analogs of classical bit flips and phase flips
• Controlled gates like CNOT, essential for entanglement

Unlike classical code, a single misplaced gate can completely change the final probability distribution. Debugging becomes less about syntax and more about reasoning through linear algebra and phase.

It is precise, unforgiving, and unexpectedly elegant.

Algorithms That Changed My Intuition

Several algorithms helped solidify these concepts.

Grover’s Search: Often summarized as a quadratic speedup, Grover’s algorithm is really about amplitude amplification. Each iteration uses an oracle and a diffusion operator to gradually push probability mass toward the correct solution.

Bernstein–Vazirani: A clean example of extracting global structure efficiently. It also taught me why problem framing and oracle design matter so much in quantum algorithms.

Quantum Fourier Transform (QFT): QFT forced me to think in terms of phase, not just probability. It feels familiar to classical Fourier transforms, but the circuit-based implementation changes how you reason about it.

The Reality of Today’s Quantum Hardware

The course also removed any remaining illusions.

• Noise is the default
• Shots matter because results are statistical
• Circuit depth matters because each additional gate introduces error
• Simulators and real hardware can behave very differently

Quantum computing today is powerful, but fragile. Understanding its limitations is as important as understanding its potential.

Will Quantum Computing Break All Cryptography?

This is one of the first questions people ask when quantum computing comes up.

Will quantum programming make today’s security keys useless? Will it break all cryptography? Are we close to that moment?

The honest answer is no, not in the dramatic way it is often portrayed.

Quantum computing does not threaten all cryptography. It threatens specific cryptographic assumptions.

What Is Actually at Risk

Some public key cryptographic systems rely on mathematical problems such as:

• Factoring large integers, as used in RSA
• Discrete logarithms, as used in elliptic curve cryptography and Diffie-Hellman

A sufficiently large and fault-tolerant quantum computer running algorithms like Shor’s could solve these problems efficiently.

The key phrase here is sufficiently large and fault-tolerant.

What Is Not at Risk

Symmetric cryptography, such as AES, is not broken in the same way.

Quantum algorithms like Grover’s offer a quadratic speedup for brute force search, but this does not collapse security. It simply reduces the effective key strength.

In practice, this is handled by increasing key sizes. AES 256, for example, is still considered safe even in a quantum-aware world.

Are We Close to a Cryptographic Collapse?

No. We are very far from it.

Breaking real world cryptographic keys would require:

• Millions of high-quality physical qubits
• Large-scale quantum error correction
• Extremely low noise and long coherence times
• Stable execution of very deep circuits

Current quantum hardware is orders of magnitude away from that reality.

Why Is This Taken So Seriously Then?

Because security planning works on long timelines.

Some data must remain secure for decades. This creates a real concern known as harvest now, decrypt later, where data is collected today and decrypted in the future.

That is why the cryptography community is already migrating toward post-quantum cryptography, based on mathematical problems for which no efficient quantum algorithms are known.

This transition is already happening.

What is next?

Quantum is a hot topic in the technology world today, alongside AI and robotics. I cannot wait to explore the intersections between all of them. What about you?

For those who want to learn more, the best path combines theory with hands-on practice. I have left a few references next.

References

• Nielsen, M. A., & Chuang, I. L. (2010). Quantum Computation and Quantum Information. Cambridge University Press.
• IBM Quantum. IBM Quantum Experience Documentation. Available at: https://quantum.ibm.com/
• Qiskit Documentation. https://qiskit.org/documentation/
• IBM Quantum. (n.d.). IBM Quantum Learning: Courses. Available at: https://quantum.cloud.ibm.com/learning/en/courses
• Preskill, J. (2018). Quantum Computing in the NISQ era and beyond. Quantum, 2, 79. https://doi.org/10.22331/q-2018-08-06-79

Introduction

Understanding how people perceive a brand is essential for businesses in today’s digital and highly connected world. Public sentiment reflects trust, reputation, and customer experience, factors that directly influence a brand’s market performance. Natural Language Processing (NLP) provides tools to analyze these sentiments automatically and at scale.

As part of the NLP course at Stockholm University, our team developed BrandLens, a system designed to classify public sentiment about brands using two different approaches: a classical machine learning model (Logistic Regression) and a transformer-based deep learning model (BERT). This article summarizes our methodology, results, and reflections from the project.

Objective

The goal of BrandLens is to build an AI-powered NLP system capable of classifying brand-related public opinions into positive, neutral, or negative categories. The system leverages data from the Twitter US Airline Sentiment dataset, with over 14,000 manually labeled tweets related to U.S. airline companies.

In addition to developing the sentiment analysis pipeline, we sought to compare the performance of two contrasting approaches: Logistic Regression with TF-IDF vectorization and BERT fine-tuned on the same dataset.

Methodology

To ensure fair comparison, both models were trained and evaluated using the same train/test split and identical preprocessing steps.

Logistic Regression Pipeline

• Text vectorization using TF-IDF (max 5000 features)
• Model trained using scikit-learn
• Evaluation through precision, recall, F1-score, and accuracy

BERT Pipeline

• Tokenization using the cardiffnlp/twitter-roberta-base-sentiment tokenizer
• Fine-tuning via Hugging Face Trainer API (1 epoch, reduced batch size)
• Sentiment output mapped to the same label schema

Additionally, we implemented:

• Named Entity Recognition (NER) with SpaCy
• Keyword extraction with NLTK
• Model prediction analysis for selected example tweets

Results

Both models were evaluated based on classification metrics and qualitative predictions. Below is a summary of the results:

As seen in the chart, BERT outperformed Logistic Regression in all metrics. It showed particularly strong improvements in identifying positive and neutral sentiments, which tend to be more difficult to classify due to language subtlety.

It becomes clear why BERT laid the foundation for the large language models (LLMs) that dominate the field today, such as RoBERTa, ALBERT, T5, GPT-4, and Claude.

Qualitative Predictions

To validate the models, we tested three real-world-style tweets:

Tweet 1: “I love how Delta treats its passengers!”

• Logistic Regression → Neutral
• BERT → Positive (Confidence: 0.98)

Tweet 2: “Worst experience ever with United Airlines.”

• Logistic Regression → Negative
• BERT → Negative (Confidence: 0.99)

Tweet 3: “Flight was delayed but I finally made it.”

• Logistic Regression → Negative
• BERT → Negative (Confidence: 0.88)

These examples demonstrate BERT’s superior ability to capture emotional tone, context, and nuance in informal text such as tweets.

Challenges

Despite the promising results, several challenges were encountered:

• Data imbalance, with significantly fewer positive samples compared to negative ones
• Detection of sarcasm and irony, which often mislead models
• Ambiguity in neutral statements, which can contain mixed tones
• Social media noise, including abbreviations, emojis, and inconsistent grammar

Future Work

BrandLens has the potential to evolve beyond tweet analysis. Future extensions may include:

• Integration with real-time streaming APIs for live brand monitoring
• Support for multilingual classification across global markets
• Development of a dashboard interface for business stakeholders
• Improved handling of sarcasm, humor, and emotional shifts in text
• Exploration of zero-shot or few-shot classification with larger models like GPT-4 or DeBERTa

Conclusion

The BrandLens project showcased the power of NLP in extracting structured insights from unstructured text. Our comparative approach highlighted how classical models provide quick and interpretable results, while modern transformer architectures like BERT offer superior accuracy and context understanding. BrandLens stands as a scalable framework for brand sentiment monitoring that can be adapted to broader business and research applications.

References

• Bird, S., Klein, E., & Loper, E. (2009). Natural Language Processing with Python. O’Reilly Media.
• Devlin, J., Chang, M. W., Lee, K., & Toutanova, K. (2019). BERT: Pre-training of Deep Bidirectional Transformers for Language Understanding. arXiv preprint arXiv:1810.04805.
• Vaswani, A. et al. (2017). Attention is All You Need. Advances in Neural Information Processing Systems. Crowdflower. Twitter US Airline Sentiment Dataset. Available at: https://www.kaggle.com/datasets/crowdflower/twitter-airline-sentiment
• Wolf, T. et al. (2020). Transformers: State-of-the-Art Natural Language Processing. arXiv:1910.03771.
• SpaCy Documentation. https://spacy.io/
• NLTK Documentation. https://www.nltk.org/

Concurrent and distributed computing has become essential in our digital age. Modern systems must handle multiple tasks simultaneously in an efficient and secure way without compromising data integrity or system performance. In this context, the actor model emerges as a powerful approach to structuring concurrent systems, and the Erlang language stands out as a robust implementation of this model.

Erlang is a functional language developed in the 1980s by Joe Armstrong at Ericsson. It was designed to create fault-tolerant and highly concurrent systems. The language naturally implements the actor model, where each Erlang process can be considered an actor.

The Actor Model

Created by Carl Hewitt and later refined by Gul Agha, the actor model is a paradigm for concurrent computing where actors are the fundamental units of execution. These actors are independent and communicate exclusively through message passing, ensuring a high level of encapsulation and eliminating the need for locks to synchronize state.

Key features of the actor model:

• Total encapsulation: Each actor has its own state, which can only be modified through received messages.
• No locks required: Since actors process one message at a time, there is no competition over internal state.
• Asynchronous communication: Messages are sent without requiring an immediate response, promoting a continuous flow of execution.
• Scalability: Actor-based systems can scale horizontally by distributing workload across multiple machines.

Erlang and the Actor Model

With the goal of implementing the Actor Model, Erlang has this key characteristics:

• Lightweight and isolated processes: Unlike traditional threads, Erlang processes are extremely lightweight and independent.
• Efficient message passing: Communication between processes occurs through asynchronous messages with no shared memory.
• Robust fault tolerance mechanisms: The “Let it crash” philosophy allows processes to fail and be restarted without affecting overall system stability.

Real-World Applications

Erlang’s adoption has grown exponentially in applications requiring high availability and massive concurrency. Some companies and systems using Erlang include:

• WhatsApp: Handles millions of simultaneous connections with low latency Erlang Solutions.
• Facebook Chat: Ensures efficient and scalable communication Facebook Engineering.
• RabbitMQ: One of the most popular messaging systems, built on Erlang.
• Amazon SimpleDB: A distributed database service from Amazon Web Services.

How to Compile and Run an Erlang Program

It is very easy to execute an Erlang program, although its functional syntax can be a little scary in the beginning. To write and run a simple Erlang program, follow these steps:

1. Install Erlang from https://www.erlang.org/downloads.

2. Create a file named hello.erl with the following content:

-module(hello).
-export([start/0]).

start() ->
    io:format("Hello, Erlang!~n").

3. Open the Erlang shell by running erl in your terminal.

4. Compile the module:

c(hello).

5. Run the function:

hello:start().

This will print “Hello, Erlang!” to the console:

Ok, it looks simple somehow. Where is the catch?

Erlang makes concurrency easy, but it has a steep learning curve due to its functional paradigm and unique syntax. Developers accustomed to imperative languages like Python might struggle initially with pattern matching, immutability, and recursion, which replace traditional loops and variable assignments. Additionally, debugging can be challenging in highly distributed systems where processes communicate asynchronously.

Main Differences Between Erlang and Python

✅ Paradigm

• Erlang: Functional, with an emphasis on concurrency.
• Python: Multi-paradigm (object-oriented, procedural, and functional).

✅ Concurrency Model

• Erlang: Actor model with lightweight processes.
• Python: Threads and multiprocessing, limited by the Global Interpreter Lock (GIL).

✅ State Management

• Erlang: Immutable data, no shared state.
• Python: Mutable state, object-oriented approach.

✅ Error Handling

• Erlang: “Let it crash” philosophy, with supervisor processes.
• Python: Traditional try-except exception handling.

✅ Performance

• Erlang: Optimized for concurrent and distributed systems.
• Python: Better suited for single-threaded applications and general scripting.

✅ Use Cases

• Erlang: Telecom, messaging systems, real-time applications.
• Python: Web development, data science, automation.

Conclusion

The actor model and the Erlang language provide powerful solutions to the challenges of concurrent and distributed programming. Developers can create more resilient, scalable, and efficient systems by adopting this paradigm. With the growing demand for distributed applications, Erlang remains a relevant and innovative choice for modern architectures.

Have you ever worked with concurrent programming? What was your approach?

References

• Agha, G. A. (1985). Actors: A model of concurrent computation in distributed systems. Massachusetts Institute of Technology. Link
• Armstrong, J. (2007). Programming Erlang: Software for a Concurrent World. Pragmatic Bookshelf. Link
• Erlang Solutions. (2016). How WhatsApp Scaled with Erlang. Link
• Facebook Engineering. (2010). The Architecture of Facebook Chat. Link
• Hamilton, J. (2007). Amazon SimpleDB: A Highly Available, Scalable, and Flexible Data Store. Link
• Hewitt, C., Bishop, P., & Steiger, R. (1973). A universal modular actor formalism for artificial intelligence. Proceedings of the 3rd International Joint Conference on Artificial Intelligence. Link
• Videla, A., & Williams, J. (2012). RabbitMQ in Action: Distributed Messaging for Everyone. Manning Publications. Link