DEV Community: Somenath Mukhopadhyay

With the fall of Windows and the rise of Linux, Computer Science is gradually crawling back to its most rightful community...

Somenath Mukhopadhyay — Fri, 13 Mar 2026 04:00:00 +0000

1. The “Windows era” of computing

During the dominance of Microsoft Windows in the 1990s–2000s, personal computing became mass-market consumer technology. The focus shifted toward:

Ease of use
Graphical interfaces
Office productivity
Gaming and consumer software

Companies like Microsoft built ecosystems aimed at millions of everyday users , not primarily scientists or engineers.

As a result, a large part of software development became application programming and enterprise IT , rather than deep systems engineering or scientific computing.

2. Linux and the return of engineering culture

The rise of Linux—started by Linus Torvalds—brought back a culture closer to traditional engineering and scientific computing:

Open source collaboration
Systems-level programming
High-performance computing
Research computing environments

Today, Linux dominates areas like:

Supercomputers (almost all of them run Linux)
Scientific computing clusters
Cloud infrastructure
AI/ML systems

Even platforms like Google, Amazon, and Meta Platforms run their infrastructure largely on Linux-based systems.

3. The deeper historical perspective

Originally, computer science was indeed a scientific and engineering discipline :

Numerical simulations
Physics modeling
Aerospace computing
Mathematical computation

Think of fields like:

Computational Physics
Computational Fluid Dynamics
Scientific Computing

My own interests—like studying OpenFOAM, Mantaflow, GPU programming, simulation, and Julia programming language —fit exactly into this tradition.

4. What is really happening

A better description might be:

Consumer computing and engineering computing are diverging again.

Consumer layer → mobile apps, web, AI tools
Engineering layer → Linux, HPC, simulation, GPUs

And the second layer is increasingly driven by engineers, physicists, and mathematicians , especially in areas like:

simulation
AI
computational science
scientific visualization

Exactly the ecosystem I am exploring with OpenGL, Mantaflow, OpenFOAM, Julia, etc

💡 A deeper observation:

The biggest shift is not Windows → Linux.

It is “Software as product” → “Computation as science and infrastructure.”

That shift naturally brings computer science closer again to physics, mathematics, and engineering.

From My Computer to This PC - you will own nothing and be happy - the rise and fall of Windows PC...

Somenath Mukhopadhyay — Thu, 12 Mar 2026 13:53:00 +0000

1. The Era of “My Computer” (1980s–2000s)

The early PC era was about personal ownership and control.

Companies like

Microsoft
IBM
Intel

created a system where:

You bought hardware
You installed software locally
Your files lived on your machine

Operating systems like:

Windows 95
Windows XP

reinforced the concept of “My Computer.”

You had:

Local control
Offline capability
Permanent ownership of software licenses

This was the golden age of personal computing sovereignty.

2. The Shift Begins (2010s)

The model started changing.

Major shifts:

Cloud Computing

Platforms like:

Microsoft Azure
Google Drive
Dropbox

moved data from personal machines to remote servers.

Software Subscriptions

Traditional purchase → subscription model

Example:

Microsoft Office → Microsoft 365

You no longer own the software — you rent it.

3. The Rise of Platform Lock-In

Modern ecosystems increasingly control the user environment.

Examples:

Windows 11 requiring Microsoft accounts
Cloud-based authentication
Telemetry and data collection

The PC becomes less independent and more connected to corporate infrastructure.

4. The New Model: “Your Computer Is a Terminal”

The trend now is toward:

Cloud desktops
Streaming applications
Web-based software

Examples:

Windows 365 (Cloud PC)
Google ChromeOS

In these systems:

Your apps run in the cloud
Your data lives on company servers
Your device becomes just an access terminal

5. The Counter-Movement

Many technologists push back with open and local computing.

Alternatives include:

Linux
FreeCAD
Blender

These emphasize:

Local ownership
Open source transparency
Offline capability

Interestingly, my own interest in FreeCAD, OpenGL, and simulation sits squarely in this “sovereign computing” movement.

6. The Big Question

The future may split into two computing worlds :

Consumer world

Cloud apps
Subscriptions
Locked ecosystems

Engineering / research world

Local computing power
Open software
Full system control

High-end engineering (CFD, simulation, graphics) still needs local compute sovereignty.

In short:

The PC is evolving from “my computer” → “their platform.”

But in domains like simulation, graphics, and scientific computing , the traditional power-user PC is far from dead.

Usefulness of Julia in engineering syllabus - we must include it in the engineering curriculum...

Somenath Mukhopadhyay — Sun, 08 Mar 2026 08:11:00 +0000

Hey guys... today I want to write about the basic hindrance of engineering college studies. You know the problem - modern-day industries want engineers who can code, who are right at the juncture of engineering and software. Engineering education is beyond just a few theories, complex mathematical formulae, and examinations to test you on such areas. It's also about visualizing and simulating the results of such theories.

So far, the system in engineering colleges is somewhat like

MATLAB for modeling
Python for data
C++ for performance
Simulink for block diagrams

And now comes the Julia... it collapses all these layers.

You can:

Write high-level control logic
Drop to numerical linear algebra
Move into differential equation solvers
Even implement custom integrators

All in one language...

With sophisticated libraries in Julia, like differentialequations.jl and many such, the engineers have got the right tool for modelling and visualizing the maths and engineering problems...

Let's welcome Julia to the engineering colleges.

Today I was playing around with my college days' engineering education, namely RLC circuits, and found how Julia can transform it through intuitive visualization of the output - a damped waveform. We can visualize the output waveform by varying R, L, and C, yielding a powerful visual tool for a better understanding of basic circuitry theorems.

Here's the video of today's Julia experimentation - RLC series circuit...

Fig 1: RLC series circuit visualization

And here's the simulation of an RLC parallel circuit.

Fig 2: RLC parallel circuit simulation

I hope Julia transforms itself from a niche area of scientific modelling and simulation tools into a larger ecosystem of software - SciML is already happening...

A Simple Cloth Simulation in Julia — Inspired by My Son’s Blender Experiments

Somenath Mukhopadhyay — Fri, 06 Mar 2026 11:52:00 +0000

Four years ago, I watched my son Ridit, in class V back then, experimenting with cloth and soft-body simulations in Blender. At that time, he was deeply interested in learning how modern graphics tools simulate physical behaviour such as cloth, smoke, and rigid body dynamics.

One of his experiments is captured in this video:

Watching him explore Blender’s simulation tools sparked a thought in my mind:

Could I reproduce a simplified cloth simulation myself using code?

Years later, while exploring scientific computing with Julia , I decided to attempt exactly that.

The result is a small but interesting Verlet-integration based cloth simulation written entirely in Julia.

Why Verlet Integration?

In physics simulations used in games and graphics engines, Verlet integration is very popular because:
• It is simple

• It is numerically stable

• It does not explicitly require velocity storage

Many cloth simulators in early game engines relied on this technique.

The basic idea is:

x_{new} = x_{current} + (x_{current} - x_{previous}) + a \Delta t^2

Where:
$x_{current}$ → current position

$x_{previous}$ → previous position

$a$ → acceleration (gravity, wind etc.)

Representing Cloth as a Grid

A cloth can be represented as a grid of particles connected by constraints.

Each particle stores:

Current position
Previous position

Neighbouring particles are connected by distance constraints that maintain the cloth structure.

o---o---o---o
| | | |
o---o---o---o
| | | |
o---o---o---o

Some particles are pinned so the cloth does not fall entirely.

The Julia Implementation

Below is the Julia program that simulates the cloth.

using LinearAlgebra
using Plots

nx = 25
ny = 20
spacing = 0.2
dt = 0.02
steps = 300
gravity = [0.0,-9.8]

# Create grid
pos = [ [i*spacing, j*spacing] for j in 1:ny, i in 1:nx ]
prev = deepcopy(pos)

# Pin top row
pinned = [(i,ny) for i in 1:nx]

constraints = []

for j in 1:ny
    for i in 1:nx
        if i < nx
            push!(constraints, ((i,j),(i+1,j)))
        end
        if j < ny
            push!(constraints, ((i,j),(i,j+1)))
        end
    end
end

function verlet_step(step)

    wind = [2*sin(0.05*step),0.0]

    for j in 1:ny
        for i in 1:nx

            if (i,j) in pinned
                continue
            end

            temp = pos[j,i]

            accel = gravity + wind

            pos[j,i] = pos[j,i] + (pos[j,i]-prev[j,i]) + accel*dt^2

            prev[j,i] = temp
        end
    end
end

function satisfy_constraints()

    for ((i1,j1),(i2,j2)) in constraints

        p1 = pos[j1,i1]
        p2 = pos[j2,i2]

        delta = p2 - p1
        dist = norm(delta)

        rest = spacing
        diff = (dist-rest)/dist

        if !((i1,j1) in pinned)
            pos[j1,i1] += delta*0.5*diff
        end

        if !((i2,j2) in pinned)
            pos[j2,i2] -= delta*0.5*diff
        end
    end
end

anim = @animate for step in 1:steps

    verlet_step(step)

    for k in 1:6
        satisfy_constraints()
    end

    x = [pos[j,i][1] for j in 1:ny, i in 1:nx]
    y = [pos[j,i][2] for j in 1:ny, i in 1:nx]

    scatter(x,y,legend=false,xlim=(0,6),ylim=(-5,6),markersize=3)
end

gif(anim,"cloth.gif",fps=30)

A sinusoidal wind creates cloth fluttering.

What the Simulation Does

The simulation includes:

Gravity

gravity = [0.0,-9.8]
Every particle experiences downward acceleration.

Wind Force

wind = [2*sin(0.05*step),0.0]
A sinusoidal wind creates cloth fluttering.

Constraint Relaxation

Multiple iterations enforce distance constraints so the cloth maintains its shape.

for k in 1:6
    satisfy_constraints()
end

This technique is commonly used in Position Based Dynamics.

Visual Result

The script generates an animated GIF showing a cloth hanging from the top row while wind and gravity deform it dynamically.

Even with a few dozen lines of code, we get a convincing physical effect.

What Makes Julia Interesting for Graphics Simulation

Working with Julia gives several advantages:
• Fast numerical computation

• Simple array operations

• Easy prototyping for physics simulations

• Smooth transition from mathematics to implementation

This makes it attractive for engineers exploring scientific computing , graphics , and simulation together.

A Personal Reflection

This small experiment reminded me of the moment I watched my son exploring cloth simulation in Blender years ago.

Back then, he was experimenting visually.

Today I tried to rebuild the physics underneath that visual tool.

Sometimes inspiration in engineering does not come from textbooks — it comes from watching curiosity in the next generation.

And that curiosity often pushes us to explore deeper layers of science and software.

How Rebuilding My Old FFT Spectrum Analyzer Opened a New Railway Safety Perspective - magic of julia

Somenath Mukhopadhyay — Thu, 26 Feb 2026 15:01:00 +0000

Back in 2012, I wrote a small experimental piece on building a simple FFT-based spectrum analyzer:

Read here...

(https://som-itsolutions.blogspot.com/2012/01/fft-based-simple-spectrum-analyzer.html)

At that time, it was more about curiosity. FFT fascinated me. The idea that a signal in time could reveal its hidden structure in frequency felt almost magical.

Fast forward to today.

I am revisiting that same idea — but this time using Julia , and not just for visualization, but for building something that could contribute to modern railway track safety systems.

And that’s when I realized why Julia is becoming so popular among the SciML (Scientific Machine Learning) community.

The Shift: From Scripting to Scientific Computing

In 2012, building a spectrum analyzer was largely:

A signal processing experiment
A learning exercise
A visualization tool

But today, with Julia, the same FFT analyzer becomes:

A condition monitoring prototype
A vibration diagnostics engine
A predictive maintenance building block

That shift is profound.

Why SciML Engineers Love Julia

The SciML ecosystem — led by projects like SciML — is not just about machine learning. It’s about merging:

Differential equations
Physics-based modeling
Optimization
Machine learning
High-performance computing

Julia allows all of this in one language.

1️⃣ Performance Without Leaving the Language

FFT in Julia uses FFTW under the hood.

You write:

fft(signal)

And you get near C-level performance.

No bindings.

No external compilation workflow.

No switching between Python and C++.

For someone who enjoys going deep into engineering mathematics, that matters.

2️⃣ Multiple Dispatch Feels Like Engineering Thinking

As someone who loves system design and patterns, I noticed something interesting.

In C++ or Java, you think in terms of classes and inheritance.

In Julia, you think in terms of:

Mathematical structures
Generic functions
Behavior based on types

It feels closer to how engineers think about systems.

Not "object owns behavior" —

but "system responds based on physical type."

That mental alignment is powerful.

3️⃣ From FFT to Railway Safety

Let’s connect this back to my spectrum analyzer journey.

A railway track under load behaves like a vibrating beam.

When a crack develops, stiffness changes.

That produces high-frequency bursts in vibration signals.

With Julia, I can:

Simulate the rail as a mass-spring-damper system
Inject a stiffness drop
Perform FFT
Detect high-frequency anomalies
Add ML-based classification

All in one environment.

Modern railway systems, including those used by Indian Railways and Deutsche Bahn, rely heavily on:

Vibration analytics
Spectral energy monitoring
Predictive maintenance

What began as a simple FFT experiment now becomes a prototype for rail crack detection.

That evolution mirrors Julia’s evolution.

SciML Is More Than Machine Learning

SciML is about:

Embedding physical laws into ML
Solving differential equations efficiently
Combining simulation with learning

Using Julia, I can go from:

\ddot{x} + c \dot{x} + k x = F(t)

to spectral fault detection

to anomaly classification

without leaving the language.

That continuity is rare.

Why This Matters for Engineers

Many engineers hesitate to enter machine learning because:

Python feels high-level but slow
C++ feels powerful but heavy
MATLAB feels proprietary

Julia sits in a sweet spot:

Scientific syntax
High performance
Open ecosystem
Growing SciML community

And most importantly:

It lets you experiment at system level.

My Personal Realization

Rebuilding my old FFT-based spectrum analyzer in Julia was not nostalgia.

It was a rediscovery.

The same math.

The same Fourier transform.

But now:

Faster
Cleaner
Extensible
Connected to real-world safety applications

That is why Julia is becoming popular among SciML engineers.

Because it doesn’t just let you code.

It lets you think in equations and deploy in production.

Final Thought

What started as a simple blog post on FFT years ago has evolved into a small predictive maintenance prototype for railway safety.

Julia didn’t just make it easier.

It made it natural.

And when a language feels natural to scientists and engineers —

that’s when it starts becoming popular.

Here's the source code...

############################################################

# Rail Vibration Monitoring Prototype

# CASE B: Rail Crack Simulation

############################################################


using FFTW

using DSP

using Plots

using Statistics

using LinearAlgebra


# -------------------------------

# 1️⃣ System Parameters

# -------------------------------


fs = 5000# Sampling frequency (Hz)

T = 2# Signal duration (seconds)

t = 0:1/fs:T-1/fs

N = length(t)


println("Sampling Frequency = $fs Hz")

println("Total Samples = $N")


# -------------------------------

# 2️⃣ Normal Rail Vibration

# -------------------------------


f\_mode1 = 50

f\_mode2 = 120


signal = 0.7\*sin.(2π\*f\_mode1\*t) .+

0.3\*sin.(2π\*f\_mode2\*t)


# -------------------------------

# 3️⃣ Inject Crack Fault (High-Frequency Burst)

# -------------------------------


crack\_time = 1.0# crack at 1 second

crack\_index = Int(round(crack\_time \* fs))


burst\_length = 200# samples (~40 ms)

crack\_freq = 800# high-frequency crack signature


if crack\_index + burst\_length <= N

 signal[crack\_index : crack\_index + burst\_length] .+=

2\*sin.(2π\*crack\_freq\*t[1:burst\_length+1])

end


# Add background noise

signal .+= 0.2randn(N)


println("Simulated Crack Frequency = $crack\_freq Hz")


# -------------------------------

# 4️⃣ Time Domain Plot

# -------------------------------


p1 = plot(t, signal,

 xlabel="Time (s)",

 ylabel="Amplitude",

 title="Rail Vibration Signal (Crack Simulation)",

 legend=false)


# -------------------------------

# 5️⃣ FFT Processing

# -------------------------------


window = hanning(N)

signal\_w = signal .\* window


fft\_result = fft(signal\_w)

freq = fs\*(0:N-1)/N

magnitude = abs.(fft\_result)/N


halfN = div(N,2)


# -------------------------------

# 6️⃣ Spectrum Plot

# -------------------------------


p2 = plot(freq[1:halfN],

 magnitude[1:halfN],

 xlabel="Frequency (Hz)",

 ylabel="Magnitude",

 title="Frequency Spectrum",

 legend=false,

 xlim=(0,1000)) # Extended to show 800 Hz


# -------------------------------

# 7️⃣ Side-by-Side Display

# -------------------------------


p3 = plot(p1, p2, layout=(1,2), size=(1200,400))

display(p3)


# -------------------------------

# 8️⃣ Crack Detection Logic

# -------------------------------


println("\n🔍 Running Crack Detection...\n")


# Detect energy in high-frequency band

high\_freq\_indices = findall(freq .> 600 .&& freq .< 1000)

high\_freq\_energy = sum(magnitude[high\_freq\_indices])


println("High Frequency Energy = ", round(high\_freq\_energy, digits=4))


if high\_freq\_energy > 0.02

println("⚠️ Possible Rail Crack Detected (High-Frequency Burst)")

else

println("✅ No crack signature detected")

end


# -------------------------------

# 9️⃣ RMS Indicator

# -------------------------------


rms\_value = sqrt(mean(signal.^2))

println("\nRMS Vibration Level = ", round(rms\_value, digits=4))


println("\n--- Rail Crack Monitoring Simulation Complete ---")


wait()

And here's when we run the application...

📈 Time Plot

A sharp disturbance around 1 second.

📊 Frequency Plot

A strong peak near:


800 Hz

🖥 Console Output


⚠️ Possible Rail Crack Detected (High-Frequency Burst)

Design patterns - beyond syntaxes. Julia - a chance to mix and visualise engineering skills with software...

Somenath Mukhopadhyay — Mon, 23 Feb 2026 06:49:00 +0000

CS != Programming...

Initially, learning CS appears to be like learning many seemingly unrelated subjects together. But with maturity and experience, you will be able to understand that these subjects are all connected.

C++, Java, Python - you name any object-oriented language - they seem to be different, but only to those who don't deep dive. Once you master the fundamental object-oriented part of these languages, you will realize that they are all the same.

Design patterns help you get to the core of any object-oriented language. Once you master the Design Pattern, you will never say how to write this program, but how this program should be designed to hold the basic object-oriented principles and how it will interact with the outside world. So you will never say that we will pick up the correct implementation of a system during runtime. Rather, you will exclaim - can't we use Strategy Design Pattern here?

However, we must understand that software or computer science is not that useful unless we apply it to real-life engineering problems. There lies the satisfaction of a scientist and an able engineer. At this juncture, the true maturity of a Computer Science guy is judged.

Many ecosystems split engineering work across tools:

MATLAB for modeling
Python for data
C++ for performance
Simulink for block diagrams

Julia collapses these layers.

You can:

Write high-level control logic
Drop to numerical linear algebra
Move into differential equation solvers
Even implement custom integrators

All in one language.

For so many years, the process of engineering computer science was that the scientists modeled an engineering solution, and then software engineers would realize it through code. But what if we want the scientists themselves model and write code to execute that model - all by themselves? For that to happen, we needed to develop a language with a deep binding with the engineering Maths and Physics.

Enter the world of Julia - and you got it - model any scientific problem and then produce the code all alone - the beauty of julia.

As my journey to know WhoAmI continues, my respect for the julia programming language is increasing day by day. So when I can model a PID control or a dipole antenna in Julia, the joy is natural.

I never thought I would be able to delve into hardcore engineering subjects after so many years of engineering graduation.

But this is the reality.

My exploration continues.

Below is the output of a PID control developed using Julia.

And here's the far-field radiation pattern of a dipole antenna...

The greatest job satisfaction is always to be at the juncture of software and engineering.

And I am loving it.

The Engineer in Me is Jubilant — Julia, A Language for System-Level Experimentation for engineers...

Somenath Mukhopadhyay — Sat, 21 Feb 2026 14:44:00 +0000

There are moments in an engineer’s life when a tool just clicks.

For me, that moment came while implementing a simple PID-controlled DC motor model in Julia.

Not because PID control is revolutionary.

Not because DC motors are exotic.

But because the process felt frictionless.

And that matters.

From Equation to Experiment — Without Friction

In classical control engineering, we begin with mathematics:

G(s) = K / (Js + b)(Ls + R) + K^2

This is not just a formula.

It represents inertia, friction, electrical dynamics — physics captured in Laplace space.

In many languages, translating this into working simulation code involves:

Verbose syntax
Data structure boilerplate
External tools for plotting
Type mismatches
Build steps

But in Julia, using ControlSystems.jl, the translation from equation to executable model feels almost poetic:

using ControlSystems

s = tf("s")
motor = K / ((J*s + b)*(L*s + R) + K^2)

pid = Kp + Ki/s + Kd*s
closed_loop = feedback(pid * motor, 1)

Look at that.

The code mirrors the mathematics.

No impedance mismatch between theory and implementation.

For an engineer, that is deeply satisfying.

System-Level Thinking — Not Just Coding

Engineering is not about syntax.

It is about:

Modeling
Interconnection
Feedback
Stability
Response
Iteration

Julia allows you to move from:

Transfer function
→ Closed-loop interconnection
→ Step response
→ Parameter tuning

in minutes.

With Plots.jl, visualizing behavior is immediate:

y, t = step(closed_loop, 0:0.01:2)
plot(t, vec(y))

Change Kp.

Re-run.

Observe overshoot change.

Change Ki.

Re-run.

Observe steady-state error vanish.

This is experimentation at the speed of thought.

Why This Feels Different

Many ecosystems split engineering work across tools:

MATLAB for modeling
Python for data
C++ for performance
Simulink for block diagrams

Julia collapses these layers.

You can:

Write high-level control logic
Drop to numerical linear algebra
Move into differential equation solvers
Even implement custom integrators

All in one language.

For someone who enjoys digging into source code, understanding numerical methods, and experimenting at system scale — this coherence is powerful.

Engineers Think in Systems

When I modeled the PID loop, what struck me was not that it worked.

It was how naturally system interconnections are expressed:

feedback(pid * motor, 1)

That single line captures decades of control theory.

This is not scripting.

This is system architecture expressed symbolically.

Performance Without Compromise

Unlike prototyping languages that eventually require rewriting in C/C++, Julia compiles to efficient machine code.

That means:

Rapid experimentation
No performance guilt
No "rewrite later" tax

For control engineers dealing with:

High-order systems
State-space models
Optimization loops
Model predictive control

This matters enormously.

The Quiet Joy

There is a quiet joy when:

Mathematics maps directly to code
Systems behave as predicted
Tuning becomes interactive
The tool does not get in the way

That is what I felt implementing the PID example.

Not hype.

Not trendiness.

Just alignment between engineering thought and computational expression.

Julia as an Engineering Workbench

Julia is not just a language.

It feels like:

A modeling lab
A numerical toolbox
A systems sandbox
A research instrument

For engineers who think in equations, dynamics, and feedback loops — it feels native.

Final Thought

The engineer in me is jubilant.

Because experimentation should be easy.

Modeling should feel direct.

And computation should not stand between idea and insight.

With Julia, system-level experimentation feels natural again.

And that, for an engineer, is everything.

Here's the source code of the PID Control...

Enjoy...

using ControlSystems

using Plots


# ----------------------------

# Motor Parameters

# ----------------------------

J = 0.01# inertia

b = 0.1# friction

K = 0.01# motor constant

R = 1.0# resistance

L = 0.5# inductance


# ----------------------------

# Transfer Function of Motor

# G(s) = K / [(Js + b)(Ls + R) + K^2]

# ----------------------------

s = tf("s")


motor = K / ((J\*s + b)\*(L\*s + R) + K^2)


println("Motor Transfer Function:")

display(motor)


# ----------------------------

# PID Controller

# C(s) = Kp + Ki/s + Kd\*s

# ----------------------------

Kp = 100

Ki = 200

Kd = 10


pid = Kp + Ki/s + Kd\*s


# ----------------------------

# Closed-loop System

# ----------------------------

closed\_loop = feedback(pid \* motor, 1)


println("Closed Loop Transfer Function:")

display(closed\_loop)


# ----------------------------

# Step Response

# ----------------------------

t = 0:0.01:2

y, t = step(closed\_loop, t)


p = plot(t, vec(y),

 xlabel="Time (s)",

 ylabel="Speed",

 title="Closed-Loop Step Response",

 legend=false)


display(p)

wait()

Here's my PID study - an implementation using Java that was done many years ago.

One thing you will understand - Julia is a boon for engineers.

(https://som-itsolutions.blogspot.com/2019/11/engineering-college-study-revisited.html)

Paradigm shift - from behaviours inside objects in OOAD to Julia's multiple dispatch...

Somenath Mukhopadhyay — Fri, 20 Feb 2026 11:29:00 +0000

OOAD Thought Processing

Concept → Owner

Behavior → Object
Polymorphism → Virtual methods
Extension → Subclassing
Encapsulation → Methods inside class

Julia Thought Processing

Concept → Owner

Behavior → Generic function
Polymorphism → Multiple dispatch
Extension → Add new methods
Encapsulation → Types + modules

OO Design Thinking

Identify entities (classes)
Attach behavior to them
Use inheritance for variation

Julia Design Thinking

Identify operations (functions)
Define data types
Implement methods for combinations of types

Worldview Comparison

OOP worldview

The world is made of interacting objects.

Julia worldview

The world is made of operations applied to data.

The State Pattern in Pure Julia Style

Enjoy the State pattern written in Julia.

Note that this works without the context class of the original State Pattern, which is typically implemented using object-oriented languages like C++, Java, or Python.

# 1. Define the State Hierarchy
abstract type ChickenState end

struct Uncleaned  <: ChickenState end
struct Washed     <: ChickenState end
struct Marinated  <: ChickenState end
struct Cooked     <: ChickenState end

# 2. Define State Transitions (Multiple Dispatch)

# --- Washing ---
function wash(::Uncleaned)
    println("Chicken is getting cleaned → Washed")
    sleep(2)
    return Washed()
end

wash(s::ChickenState) = s  # Default: no change if already washed/cooked

# --- Marinating ---
function marinate(::Washed)
    println("Chicken is being marinated → Marinated")
    sleep(2)
    return Marinated()
end

marinate(s::ChickenState) = s

# --- Cooking ---
function cook(::Marinated)
    println("Chicken is being cooked → Cooked")
    sleep(4)
    return Cooked()
end

cook(s::ChickenState) = s

# --- Serving ---
function serve(::Cooked)
    println("Chicken is being served. Final state.")
    return Cooked()
end

serve(s::ChickenState) = (println("Can't serve yet, chicken is $(typeof(s))"); s)

# 3. Execution Flow
state = Uncleaned()

state = wash(state)
state = marinate(state)
state = cook(state)
state = serve(state)

And here's the State Pattern in Python...

Feel the difference - Pythonian way and Julian way

https://dev.to/sommukhopadhyay/the-state-pattern-in-python-205

Horns of the dilemma - C++ & Python binding or Julia - implementation of strategy design pattern in Julia...

Somenath Mukhopadhyay — Tue, 17 Feb 2026 00:54:23 +0000

Aah… I am at the crossroads - tried-and-true marriage (C++/Python) or solo act (Julia).

For the past few months, I delved into many tools that act as a glue between C++ and Python, like nanobind, pybind11, SWIG, Boost.Python, etc. All of these looked good. This is the industry-wise power couple for performance and ease of use.

Yesterday, while trying to understand why so many top-level AI scientists are leaving bigtech, I got a clue about scientific AI and Julia, the programming language especially made for this field.

Yes, I am not talking about LLM - because I am sure AI ≠ the next word suggestion. There is a vast field in AI to cover vis-à-vis Scientific AI and simulation. In fields like climate modeling, drug discovery, or fluid dynamics, we aren't just predicting tokens; we are constrained by the laws of physics.

This is where Julia has carved out a unique, dominant niche through a movement called SciML.

While Python and C++ can do this, Julia has structural advantages that make it the "lab equipment" of choice for this decade.

To train an AI, you need gradients (derivatives). In Python, you can only differentiate through code written in specific frameworks like PyTorch or JAX. In Julia, the entire language is essentially differentiable. You can take the derivative of a complex simulation, a CAD model, or a custom physics engine without rewriting it in a "tensor" format.

Remember, scientific models are often written by scientists, not software engineers.

The Old Way: A scientist writes a model in Python; it’s too slow for the Supercomputer, so a software engineer rewrites it in C++.

The Julia Way: The scientist writes high-level code that is automatically compiled to LLVM (machine code). The prototype is the production code.

Some important use cases for Julia…

Climate Modeling: The CliMA project (MIT/Caltech) is rebuilding global climate models in Julia to better integrate satellite data with fluid dynamics.

Pharmaceuticals: Pumas is a Julia-based tool used for "quantitative pharmacology" to predict how drugs move through the body.

Aerospace: Organizations like NASA use Julia for trajectory optimization because it handles the massive matrix math of orbital mechanics at C++ speeds

Julia isn't a "Python killer" for building a website or a simple chatbot. But for Scientific AI—where you need to solve a partial differential equation while training a transformer—it is currently the only language that doesn't make you choose between your sanity (Python) and your performance (C++).

So… here we go… my exploration of Julia has begun today. The way I learn new software languages is by doing the same thing for Julia - using Julia to implement some of the GoF Design Patterns, here the Strategy Pattern.

Here is the source code of the Strategy Pattern developed using Julia.

abstract type JourneyToTheAirport end

struct Bus <: JourneyToTheAirport end
struct Metro <: JourneyToTheAirport end
struct Auto <: JourneyToTheAirport end

gotoairport(::Bus)   = println("🚌 Journey by bus... hope there's no traffic!")
gotoairport(::Metro) = println("🚇 Journey by metro... fast and efficient.")
gotoairport(::Auto)  = println("🛺 Journey by auto... hold on tight!")

# 1. Create a mapping of strings to Type Constructors
choices = Dict(
    "bus"   => Bus(),
    "metro" => Metro(),
    "auto"  => Auto()
)

function run_app()
    println("How do you want to get to the airport? (bus, metro, auto):")

    # 2. Get user input and clean it up (lowercase and strip whitespace)
    user_input = lowercase(strip(readline()))

    # 3. Look up the strategy in our dictionary
    if haskey(choices, user_input)
        strategy = choices[user_input]
        gotoairport(strategy)
    else
        println("❌ Sorry, '$user_input' is not a valid transport option.")
    end
end

run_app()

Enjoy…

nanobind: the bridge between C++ and Python...

Somenath Mukhopadhyay — Thu, 05 Feb 2026 06:13:00 +0000

Python is where ideas move fast. C++ is where performance lives. For years, gluing the two together meant choosing between power, safety, and sanity. Enter nanobind —a modern, minimalist bridge that lets C++ and Python talk to each other cleanly, efficiently, and without ceremony.

nanobind is a C++17-first binding library , inspired by pybind11 but redesigned with a sharper focus on performance, compile times, and modern C++ practices. It’s built for developers who care about control—over lifetimes, memory, ABI stability, and error handling—without drowning in boilerplate.

What makes nanobind special is how unapologetically low-level it is, while still feeling elegant. It avoids heavy template metaprogramming where possible, compiles fast, and produces smaller binaries. If you’re working on large C++ codebases—CAD kernels, physics engines, solvers, graphics pipelines—this matters a lot.

Memory management is another strong point. nanobind gives you explicit control over object ownership between C++ and Python, making it ideal for systems where Python is embedded inside a C++ application (think Blender, FreeCAD, game engines, or simulation tools). You’re not just exporting functions—you’re designing an API boundary.

Compared to older tools like SWIG, nanobind doesn’t try to “auto-magically” generate bindings. That’s a feature, not a bug. You write bindings intentionally, so the Python API feels Pythonic, not like a leaked C++ header. And compared to pybind11, nanobind is leaner, stricter, and more future-facing.

In short:

Python for orchestration and scripting
C++ for performance-critical logic
nanobind as the clean, modern handshake between them

If you’re building serious software where Python is a first-class citizen—but not the performance bottleneck—nanobind is one of the best bridges you can choose today.

Here's my today's exploration on nanobind - the Factory pattern written in C++ being given a python interface using nanobind.

Enjoy...

The Factory Pattern is written in C++.

/*
 * Food.h
 *
 *  Created on: Mar 10, 2021
 *      Author: som
 */

#ifndef FOOD_H_
#define FOOD_H_
#include <string>

using namespace std;

class Food {
public:
    virtual string getName() = 0;

    virtual ~Food(){

    }
};


#endif /* FOOD_H_ */

\* Biscuit.h

\*

\* Created on: Mar 10, 2021

\* Author: som

\*/

/*
 * Biscuit.h
 *
 *  Created on: Mar 10, 2021
 *      Author: som
 */

#ifndef BISCUIT_H_
#define BISCUIT_H_

#include "Food.h"

class Biscuit: public Food {
public:
    Biscuit();
    string getName();
    ~Biscuit();
};

#endif /* BISCUIT_H_ */


/*
 * Biscuit.cpp
 *
 *  Created on: Mar 10, 2021
 *      Author: som
 */
#include <iostream>
#include "Biscuit.h"
using namespace std;


Biscuit::Biscuit() {
    // TODO Auto-generated constructor stub
    cout<<"Biscuit is made..."<<endl;

}

Biscuit::~Biscuit(){}


string Biscuit::getName(){
    return "It's a Biscuit";
}

/*
 * Chocolate.h
 *
 *  Created on: Mar 10, 2021
 *      Author: som
 */

#ifndef CHOCOLATE_H_
#define CHOCOLATE_H_

#include <iostream>
#include "Food.h"

class Chocolate: public Food {
public:
    Chocolate();
    virtual ~Chocolate();
    string getName();
};


#endif /* CHOCOLATE_H_ */


/*
 * Chocolate.cpp
 *
 *  Created on: Mar 10, 2021
 *      Author: som
 */

#include "Chocolate.h"


Chocolate::Chocolate() {
    // TODO Auto-generated constructor stub
    cout<<"Chocolate is made..."<<endl;

}

Chocolate::~Chocolate() {
    // TODO Auto-generated destructor stub
}

string Chocolate::getName(){
    return "It's a Chocolate";
}

/*
 * Factory.h
 *
 *  Created on: Mar 10, 2021
 *      Author: som
 */

#ifndef FACTORY_H_
#define FACTORY_H_

#include <nanobind/nanobind.h>
#include <iostream>
#include <string>

#include "Biscuit.h"
#include "Chocolate.h"

using namespace std;

class Factory{
public:
    static Factory* instance;
    static Factory* getInstance();

    Food* makeFood(const string& type);

private:
    Factory(){}

    // Delete copy constructor & assignment operator (Singleton pattern)
    Factory(const Factory&) = delete;
    Factory& operator=(const Factory&) = delete;
};
//Factory* Factory:: instance =  NULL;


#endif /* FACTORY_H_ */


/*
 * Factory.cpp
 *
 *  Created on: Jan 30, 2025
 *      Author: som
 */
#include "Factory.h"
Factory* Factory::instance = NULL;

Factory* Factory:: getInstance(){
        if(Factory::instance == NULL){
            Factory::instance = new Factory();
        }
        return Factory::instance;
    }

Food* Factory::makeFood(const string& type){
        if(type.compare("bi") == 0){
            return new Biscuit();
        }
        if(type.compare("ch") == 0){
            return new Chocolate();
        }

        return NULL;
    }

The bindings.cpp - defining the bridge...

#include <nanobind/nanobind.h>
#include <nanobind/stl/string.h> // Required for std::string support
#include "Factory.h"

namespace nb = nanobind;

// Use NB_MODULE to define the extension
NB_MODULE(foodfactory, m) {
    // 1. Wrap the Base Class
    // We use nb::class_<T> and provide the name it will have in Python
    nb::class_<Food>(m, "Food")
        .def("getName", &Food::getName);

    // 2. Wrap the Subclasses
    // Note: We specify the base class <Biscuit, Food> so Python knows the relationship
    nb::class_<Biscuit, Food>(m, "Biscuit")
        .def(nb::init<>());

    nb::class_<Chocolate, Food>(m, "Chocolate")
        .def(nb::init<>());

    // 3. Wrap the Singleton Factory
        nb::class_<Factory>(m, "Factory")
            .def_static("get_instance", &Factory::getInstance, // Renamed to snake_case for Python idiomatic style
                        nb::rv_policy::reference)

            .def("make_food", &Factory::makeFood, // Match your Python script's call
                 nb::rv_policy::take_ownership);
}

## And here is the CMakeLists.txt for compiling and creating the shared object

cmake_minimum_required(VERSION 3.15)
project(FactoryPattern_nanobind)

set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)

# 1. Find Python
find_package(Python 3.9 COMPONENTS Interpreter Development REQUIRED)

# 2. Get nanobind paths manually to bypass the "Target Not Found" bug
execute_process(
    COMMAND "${Python_EXECUTABLE}" -m nanobind --cmake_dir
    OUTPUT_VARIABLE NB_DIR OUTPUT_STRIP_TRAILING_WHITESPACE
)
execute_process(
    COMMAND "${Python_EXECUTABLE}" -m nanobind --include_dir
    OUTPUT_VARIABLE NB_INC OUTPUT_STRIP_TRAILING_WHITESPACE
)

# 3. Load the nanobind logic
list(APPEND CMAKE_PREFIX_PATH "${NB_DIR}")
find_package(nanobind REQUIRED CONFIG)

# 4. Create the module
nanobind_add_module(foodfactory
    LTO
    Biscuit.cpp
    Chocolate.cpp
    Factory.cpp
    bindings.cpp
)

# 5. MANUALLY fix the missing target link
# This bypasses the error by providing the includes and libraries directly
target_include_directories(foodfactory PRIVATE "${NB_INC}" "${Python_INCLUDE_DIRS}")
target_link_libraries(foodfactory PRIVATE Python::Module)

# If nanobind still complains about the target, we define it as an alias
if(NOT TARGET nanobind::nanobind)
    add_library(nanobind::nanobind INTERFACE IMPORTED)
    set_target_properties(nanobind::nanobind PROPERTIES
        INTERFACE_INCLUDE_DIRECTORIES "${NB_INC}"
    )
endif()

After compiling and creating the shared object, you need to put it inside the Python project and import it.

The Python code looks as follows.

import foodfactory
# Access get_instance THROUGH the Factory class
factory = foodfactory.Factory.get_instance()
biscuit = factory.make_food("bi")
print(biscuit.getName())
chocolate = factory.make_food("ch")
print(chocolate.getName())

Enjoy...

It's neither strength nor intelligence but resilience creats champs - a timeline of Bharat from 2014 to 2026...

Somenath Mukhopadhyay — Fri, 30 Jan 2026 08:00:00 +0000

2014 | The Psychological Reset

This wasn’t about policy first — it was about mindset.

“Make in India” reframes manufacturing as strategic, not menial
Space, defence, digital get political backing
Bureaucracy is told: delay is more dangerous than failure

Shift: From risk-avoidance to attempting scale

2015 | Digital Foundations

Jan Dhan–Aadhaar–Mobile (JAM) stack stabilizes
India begins building public digital rails instead of private monopolies
Direct Benefit Transfer reduces leakages massively

Shift: Infrastructure > schemes

2016 | Shock as Discipline

Demonetisation causes pain, but forces digitisation
UPI launches quietly — underestimated, underreported
Cyber, fintech, digital identity ecosystems accelerate

Shift: Informality → traceability

2017 | Systems Thinking Emerges

GST implemented — messy, painful, but irreversible
ISRO cryogenic engine reliability improves
Tejas edges toward operational clearance

Shift: One market, one system

2018 | Strategic Patience

Defence procurement rules rewritten
Indigenous content prioritised
AI, robotics, and data policy discussions begin

Criticism continues, but direction is set.

Shift: Policy lag accepted in exchange for autonomy

2019 | Quiet Capability

Mission Shakti (ASAT) proves space deterrence
Chandrayaan-2 attempts high-risk landing
Semiconductor vulnerability officially acknowledged

Shift: Signalling without chest-thumping

2020 | Crisis as Accelerator

COVID stress-tests everything.

Digital infrastructure holds
Vaccine manufacturing scales at unprecedented speed
Supply chain nationalism becomes global reality

Shift: Resilience becomes measurable

2021 | From Slogan to Structure

Atmanirbhar Bharat policies deepen
PLI schemes target electronics, pharma, defence
API and chip dependencies mapped sector-by-sector

Shift: Strategic self-reliance, not isolation

2022 | Manufacturing Re-enters the Room

Mobile phone manufacturing explodes
Defence exports cross psychological thresholds
Semiconductor Mission formally launched

Shift: Assembly → ecosystem thinking

2023 | Validation Moment

Chandrayaan-3 lands near lunar south pole
Global admiration for Indian engineering discipline
UPI exported diplomatically
AI compute access discussed as national infrastructure

Shift: Confidence without explanation

2024 | Hard Tech Focus

GaN, compound semiconductors prioritized
AIRAWAT & iKosha scale sovereign compute
GPU access democratized for researchers
Sanskrit, Indian language AI pipelines emerge

Shift: From users of tech → builders of tech

2025 | Strategic Convergence

Defence, space, AI, semiconductors align
Dual-use technologies openly encouraged
Export control resilience improves
Indigenous IP creation accelerates

Shift: Civil + military tech convergence

2026 | The New Normal

By now, a pattern is undeniable:

Indigenous systems are the default
Failure is tolerated if learning is visible
Long-term national missions outlive political cycles

Bharat is no longer “catching up”.

It is choosing what to build, what to ignore, and what to defend.

The Core Insight

2014–2026 wasn’t about sudden brilliance.

It was about staying in the game long enough.

Strength intimidates.

Intelligence impresses.

Resilience wins championships.

Lesson from Russia Ukraine war - why Starlink possess a threat to national security because hundreds of Leo satellites may...

Somenath Mukhopadhyay — Tue, 30 Dec 2025 13:52:00 +0000

The Russia-Ukraine war has fundamentally rewritten the rules of modern warfare, specifically through the "democratization" of satellite communications. While Starlink was initially hailed as a lifeline for Ukraine, it has evolved into a complex national security threat for several reasons.

The core of the threat lies in the fact that Low Earth Orbit (LEO) constellations like Starlink provide the high-bandwidth, low-latency connectivity required to operate sophisticated drones over vast distances—capabilities once reserved for superpower militaries.

1. Enabling Long-Range "Kill Webs"

Traditionally, drones were limited by line-of-sight radio links or expensive, laggy geostationary satellites. Starlink’s LEO satellites (hundreds of which are overhead at any given time) allow for:

Beyond Line of Sight (BLOS) Control:

Operators can sit hundreds of miles away from the front lines and control FPV (First Person View) or strike drones via the satellite link.

Real-time Video Feedback:

The low latency (under 50ms) allows for precise, real-time maneuvering of "kamikaze" drones, making them as accurate as guided missiles but at a fraction of the cost.

Autonomous Swarming:

Thousands of satellites enable the coordination of drone "swarms," where multiple units communicate and strike simultaneously without relying on vulnerable ground-based towers.

2. The "Dual-Use" Dilemma & Adversary Adaptation

The war has proven that commercial technology is difficult to "gatekeep."

Russian Integration:

Recent reports indicate Russian forces have begun integrating Starlink terminals directly into their own strike drones (e.g., the Molniya-2). By using black-market terminals, Russia can bypass its own lack of high-speed satellite infrastructure.

The Geofencing Problem:

It is extremely difficult for SpaceX to disable Starlink for Russians without also disabling it for Ukrainians in contested "grey zones." This creates a scenario where a private company effectively dictates the "digital borders" of a war.

3. Resilience Against Electronic Warfare (EW)

LEO constellations are inherently harder to jam than traditional systems:

Narrow Beams:

Starlink uses phased-array antennas that create very narrow, directed beams.7 To jam it, an enemy must be almost directly between the dish and the satellite.

Redundancy:

Because there are thousands of satellites, if one is jammed or destroyed, the terminal simply "handshakes" with the next one in the mesh network. This makes "denial of service" nearly impossible through conventional means.

4. Sovereignty and the "Private Actor" Risk

A major national security concern is that a nation's military effectiveness now depends on a private corporation’s terms of service.

Unilateral Veto Power:

We saw this when Elon Musk reportedly denied a request to activate Starlink near Crimea for a Ukrainian naval drone strike. This highlights a "threat" where a private individual can interfere with a nation's strategic military objectives based on personal or political views.

LEO Satellites vs. Traditional Military Comms

Feature	Traditional Military Satellite (GEO)	Starlink LEO Constellation
Latency	High (600ms+) Bad for real-time applications like drone piloting	Low (<50ms) Enables real-time piloting and responsive control
Visibility/Vulnerability	Single point of failure Easily targeted and jammed	Thousands of nodes Nearly impossible to fully disable
Accessibility	Restricted to high-budget militaries	Available to anyone with ~$500 hardware and a subscription
Mobility	Requires large, static ground stations/dishes	Highly portable Can be mounted on vehicles, drones, or carried

Bottom Line:

The threat isn't just that the satellites "operate" the drones, but that they provide a ubiquitous, un-jammable internet layer that turns any cheap civilian drone into a precision-guided strategic weapon.