2026-02-21 23:01:24

Building a Vision-Based Object Tracking System Using Dual PID Control

Project Repository

View the complete source code on GitHub

Introduction
In robotics, feedback is what makes a system intelligent. Unlike open-loop systems, closed-loop systems continuously measure their output and correct themselves in real time.

In this project, I built a vision-based closed-loop control system using a webcam and dual PID controllers. The system detects a colored object, aligns itself horizontally, and maintains a safe distance using only camera input.

This setup mimics the core logic used in autonomous vehicles, drones, and mobile robots.

Problem Statement
The objective of this project was to design a system that can track a target object using only camera input and respond to it in real time.

The system should:

• Detect a colored object from a live video stream
• Align itself horizontally with the object
• Maintain a safe and consistent distance
• Continuously adjust its motion using feedback

The challenge was to combine computer vision for perception and PID control for decision-making into a single closed-loop system.

Vision Pipeline
The perception layer of the system is responsible for extracting meaningful information from the camera feed.

Each frame from the webcam is first converted from RGB to HSV color space. HSV (Hue, Saturation, Value) is preferred over RGB for color segmentation because it separates color information (hue) from brightness. This makes object detection more robust to lighting variations.

After conversion, a color threshold is applied to isolate the blue object. This produces a binary mask where the detected object appears white, and the rest of the frame appears black.

Next, contour detection is performed on the binary mask. The largest contour is assumed to be the target object. From this contour, two important measurements are extracted:

• The horizontal center of the object (x_object)
• The bounding box height (h_object)

The horizontal center is used to compute alignment error:

Error_steer = x_object − x_frame_center

The bounding box height is used as an approximation of distance. As the object gets closer to the camera, its height in the image increases.

These measurements are then passed to the control layer for PID computation.

Control System Design
The system uses two PID controllers — one for steering and one for maintaining distance.

For steering, the controller checks how far the object is from the center of the frame:

Error_steer = x_object − x_frame_center

If the object shifts left or right, the controller adjusts the steering to bring it back to the center.

For distance control, the system uses the object's height in the frame as an estimate of how close it is. If the object appears too large, it means it is too close. If it appears small, it is far away. The controller adjusts the forward speed to maintain a safe distance.

Each PID controller works using three components:

• Proportional (reacts to current error)
• Integral (corrects accumulated past error)
• Derivative (reduces sudden oscillations)

By combining these two controllers, the system can align itself with the object and maintain distance at the same time.

Closed-Loop Architecture
The system operates as a continuous feedback loop.

1. The camera captures a frame.
2. The vision pipeline processes the image and extracts object position and size.
3. Errors for steering and distance are calculated.
4. The PID controllers compute correction outputs.
5. The system adjusts steering and speed.
6. The process repeats for the next frame.

This constant cycle allows the system to correct itself in real time.

If the object moves, the error changes. The controller reacts immediately and adjusts the motion. Unlike an open-loop system, the output directly influences the next measurement, forming a closed feedback loop.

This feedback-based approach makes the system stable and responsive, which is essential in robotics and autonomous systems.

Experimental Observations
While tuning the PID controllers, I observed how each parameter affected system behavior.

When Kp was too high, the system reacted aggressively and started oscillating around the target. When it was too low, the response became slow and sluggish.

Without the derivative term, the system showed noticeable overshoot, especially during sudden object movement. Adding derivative control helped smooth out rapid changes.

If the integral gain was too high, the system accumulated error and caused instability over time. Careful tuning was necessary to achieve stable and smooth tracking.

These observations helped me better understand how PID parameters influence real-world system behavior.

Real-World Applications
This type of vision-based closed-loop control system is widely used in robotics and autonomous systems.

Similar architectures are found in:

• Line-following robots
• Self-driving vehicles
• Drone tracking systems
• Warehouse automation robots
• Visual servoing systems in industrial robotics

Although this project is a simplified implementation, it reflects the core principles used in real autonomous platforms.

Conclusion
This project demonstrates how computer vision and classical control theory can be combined to build an intelligent feedback-driven system.

By integrating object detection with dual PID control, the system is able to align itself and maintain distance using only camera input.

Through this implementation, I gained practical experience in perception-to-control pipelines, PID tuning, and closed-loop system design — all of which are fundamental concepts in robotics and autonomous systems.

2026-02-21 22:56:50

Choosing your first programming language is like picking your first car: you need to know where you're going before you get behind the wheel. But here's the truth—there's no single "best" language for everyone. Each tool is designed for specific tasks.

In this comprehensive guide, we'll explore all major programming languages objectively, without favoring any particular one. Whether you're interested in web development, AI, mobile apps, or enterprise systems, you'll find the information you need to make an informed decision.

📋 Table of Contents

1. Why Language Choice Matters
2. Key Selection Criteria
3. Python
4. JavaScript
5. Java
6. C#
7. Go (Golang)
8. Rust
9. Swift
10. Kotlin
11. R
12. Zator
13. Comparison Table
14. Final Recommendations

Why Language Choice Matters

When you choose a programming language to learn, your goal should be to start coding, understand programming principles, and build a foundation for future growth. The language itself is just a tool—and like any tool, it works better for certain tasks than others.

Important reality check: The language alone doesn't determine your success. What matters more is mastering fundamental concepts and programming paradigms. Once you learn one language well, picking up another becomes significantly easier.

Key Selection Criteria

1. Area of Application

Different languages are optimized for different tasks. Before choosing, identify what interests you:

2. Learning Curve

For beginners, syntax readability and availability of learning materials matter. Some languages have a gentler learning curve, while others require more time to grasp basic concepts.

3. Job Market

Research job openings in your region and field of interest. The number of entry-level positions varies significantly by language and location.

4. Community & Support

An active community means more answers to your questions, more libraries, and better documentation. This is especially crucial for beginners who will encounter many questions along the way.

5. Long-term Prospects

Technology changes rapidly, but some languages have shown resilience over decades. Consider how your chosen language might serve you 5-10 years down the road.

Python

History & Background

Created by Guido van Rossum and first released in 1991. The name comes from the British comedy show "Monty Python's Flying Circus"—not the snake, as many assume.

Current State (2025-2026)

According to the TIOBE Index, Python continues to be the most popular programming language in 2026, growing its share to 23.28% in 2025. Python 3.14 was released with new features, including a JIT compiler for faster code execution.

Primary Use Cases

Pros

✅ Simple, readable syntax — One of the most beginner-friendly languages
✅ Huge ecosystem — 400,000+ packages in PyPI
✅ Cross-platform — Works on Windows, macOS, Linux
✅ Active community — Millions of developers worldwide
✅ Versatility — Suitable for many different tasks
✅ AI-optimized libraries — TensorFlow, PyTorch, scikit-learn
✅ Async support — async/await for high-load applications

Cons

❌ Performance — Slower than compiled languages (C++, Rust)
❌ Mobile development — Not optimal for iOS/Android apps
❌ Memory consumption — Can be high for certain tasks
❌ GIL (Global Interpreter Lock) — Limits multi-threading
❌ Not specialized for AI pipelines — Requires additional libraries

Career Prospects

• Entry-level salary: $60,000 - $90,000 (US), £40,000 - £65,000 (UK)
• Beginner vacancies: Very high
• Demand growth: Steadily growing due to AI/ML boom

When to Choose Python

Good fit if:

• You're an absolute beginner
• You're interested in Data Science or AI
• You want a versatile language for various tasks
• You plan to work in startups or tech companies

Not ideal if:

• You need maximum performance
• You plan mobile development
• You want to work in system programming

Learning Resources

• Official docs: python.org
• Courses: Coursera, edX, Real Python
• Practice: LeetCode, HackerRank, Codewars
• Books: "Python Crash Course", "Automate the Boring Stuff"

JavaScript

History & Background

Created by Brendan Eich in 1995 in just 10 days for Netscape. Despite the name, it has no relation to Java—it was a marketing move at the time.

Current State (2025-2026)

According to the 2025 Stack Overflow Survey, JavaScript remains the most used programming language—69% of professional developers work with it. In 2025, TypeScript took first place in GitHub usage.

Primary Use Cases

Pros

✅ Runs natively in browsers — No compilation needed
✅ Fullstack capabilities — One language for frontend and backend
✅ Huge ecosystem — npm with 2+ million packages
✅ Constant evolution — Annual ECMAScript updates
✅ Many jobs — Most in-demand language for web developers
✅ TypeScript integration — Static typing when you need it
✅ AI tools — Integration with AI coding assistants

Cons

❌ Dynamic typing — Can lead to runtime errors
❌ Ecosystem fragmentation — Rapidly changing frameworks
❌ Security — Client-side vulnerabilities
❌ Performance — Slower than native applications
❌ Debugging complexity — Async code can be tricky

Career Prospects

• Entry-level salary: $65,000 - $95,000 (US), £45,000 - £70,000 (UK)
• Beginner vacancies: Very high
• Demand growth: Stable, especially with TypeScript

When to Choose JavaScript

Good fit if:

• You want to work in web development
• You're interested in fullstack development
• You plan to create interactive interfaces
• You want to start building visible projects quickly

Not ideal if:

• You're interested in system programming
• You need strict typing without TypeScript
• You plan high-performance computing work

Learning Resources

• Official docs: MDN Web Docs
• Courses: freeCodeCamp, JavaScript.info
• Practice: Codewars, Frontend Mentor
• Frameworks: React, Vue, Angular documentation

Java

History & Background

Developed by James Gosling at Sun Microsystems and released in 1995. The motto: "Write Once, Run Anywhere."

Current State (2025-2026)

92% of Fortune 100 companies continue to use Java for core production systems in 2026. Java remains a key language for enterprise, backend, and cloud development.

Primary Use Cases

Pros

✅ Stability & reliability — 30+ years on the market
✅ Cross-platform — JVM runs everywhere
✅ Strong typing — Fewer runtime errors
✅ Multi-threading — Built-in concurrency support
✅ Enterprise-ready — Frameworks for large projects
✅ Long-term support — LTS versions every 2 years
✅ Security — Built-in protection mechanisms

Cons

❌ Verbose syntax — More code for the same tasks
❌ Memory consumption — JVM requires significant resources
❌ Startup time — Slower than native compiled languages
❌ Less suitable for prototyping — More boilerplate code
❌ Beginner complexity — Requires OOP understanding from the start

Career Prospects

• Entry-level salary: $70,000 - $100,000 (US), £50,000 - £75,000 (UK)
• Beginner vacancies: High in enterprise sector
• Demand growth: Stable, especially in corporate sector

When to Choose Java

Good fit if:

• You plan to work in large corporations
• You're interested in enterprise development
• You want a stable career with long-term projects
• Code reliability and maintainability matter to you

Not ideal if:

• You want to build prototypes quickly
• You're interested in startup environments
• You prefer concise syntax

Learning Resources

• Official docs: Oracle Java Docs
• Courses: JavaRush, Hyperskill, Coursera
• Frameworks: Spring, Hibernate documentation
• Books: "Effective Java", "Head First Java"

C

History & Background

Developed by Microsoft under Anders Hejlsberg and released in 2000 as part of the .NET platform. In January 2026, TIOBE named C# the Programming Language of 2025.

Current State (2025-2026)

C# is well-positioned for cross-platform development and is a key language in the Microsoft Cloud ecosystem. .NET 10 includes AI integration and cloud-native development features.

Primary Use Cases

Pros

✅ Microsoft ecosystem integration — Visual Studio, Azure
✅ Modern features — Pattern matching, records, nullable types
✅ Cross-platform — .NET Core runs on all OS
✅ Game development — Unity uses C# as primary language
✅ Strong typing — Compiler catches errors early
✅ Good documentation — From Microsoft and community
✅ AI integration — AI tools in .NET ecosystem

Cons

❌ Microsoft association — Historically tied to Windows
❌ Fewer freelance opportunities — More corporate projects
❌ Requires OOP understanding — Harder for absolute beginners
❌ Smaller community — Compared to Python/JavaScript

Career Prospects

• Entry-level salary: $65,000 - $95,000 (US), £45,000 - £70,000 (UK)
• Beginner vacancies: Medium, more in enterprise
• Demand growth: Stable, especially in corporate sector

When to Choose C

Good fit if:

• You plan to work in Microsoft ecosystem
• You're interested in Unity game development
• You want to work in enterprise environments
• Strong typing and Microsoft tools matter to you

Not ideal if:

• You prefer open-source ecosystems
• You want to work in startups
• You plan a freelance career

Learning Resources

• Official docs: Microsoft Learn
• Courses: Pluralsight, Udemy, Coursera
• Game dev: Unity Learn
• Books: "C# in Depth", "Programming C#"

Go (Golang)

History & Background

Developed at Google by Robert Griesemer, Rob Pike, and Ken Thompson in 2007, publicly released in 2009. Created to solve scaling problems at Google.

Current State (2025-2026)

Go ranks 4th in JetBrains Language Promise Index and is the 3rd fastest-growing language on GitHub after Python and TypeScript. One of the most in-demand backend languages in 2026.

Primary Use Cases

Pros

✅ Simple syntax — Minimalist, easy to read
✅ High performance — Compiled language
✅ Built-in concurrency — Goroutines and channels
✅ Fast compilation — Seconds instead of minutes
✅ Standard library — Fewer dependencies needed
✅ Static typing — Errors caught at compile time
✅ Predictable performance — Important for production

Cons

❌ Fewer beginner vacancies — Experience often required
❌ Limited ecosystem — Fewer libraries than Python/JS
❌ Generics — Recently added, not everywhere yet
❌ Fewer learning materials — For beginners
❌ Error handling — Verbose (if err != nil)

Career Prospects

• Entry-level salary: $80,000 - $120,000 (US), £55,000 - £85,000 (UK)
• Beginner vacancies: Fewer than Python/JS
• Demand growth: Rapidly growing in cloud infrastructure

When to Choose Go

Good fit if:

• You're interested in backend and cloud development
• Performance and scalability matter to you
• You plan to work with microservices
• You want to learn modern cloud-native technologies

Not ideal if:

• You're an absolute beginner without experience
• You're interested in frontend or mobile development
• You need many ready-made libraries for specific tasks

Learning Resources

• Official docs: go.dev
• Courses: A Tour of Go, Go by Example
• Practice: Exercism, LeetCode
• Books: "The Go Programming Language"

Rust

History & Background

Developed by Graydon Hoare at Mozilla Research, first stable release in 2015. Created to solve memory safety problems in system programming.

Current State (2025-2026)

In 2026, system programming isn't just about speed—it's about safety + stability + performance. Rust has become a popular modern alternative to C thanks to its type system and memory management.

Primary Use Cases

Pros

✅ Memory safety — Without garbage collector
✅ High performance — Comparable to C/C++
✅ Modern features — Pattern matching, algebraic types
✅ Growing community — Active development
✅ High demand — Top salaries ($150K-$300K+ in US)
✅ No data races — Compiler prevents them
✅ Speed + Safety + Stability — Three elements of 2026 system programming

Cons

❌ Steep learning curve — Difficult for beginners
❌ Compilation time — Can be lengthy
❌ Fewer entry-level jobs — Experience required
❌ Borrow checker — Conceptually challenging
❌ Fewer libraries — Than more mature languages

Career Prospects

• Entry-level salary: $90,000 - $150,000 (US), £60,000 - £100,000 (UK)
• Beginner vacancies: Few, experience required
• Demand growth: Rapidly growing in infrastructure projects

When to Choose Rust

Good fit if:

• You're interested in system programming
• Safety and performance matter to you
• You have experience with other languages
• You want to work on infrastructure projects

Not ideal if:

• You're an absolute beginner
• You need quick prototype development
• Web or mobile development is your main goal

Learning Resources

• Official docs: rust-lang.org
• Books: "The Rust Programming Language" (The Book)
• Practice: Rustlings, Exercism
• Community: Rust Forum, Reddit r/rust

Swift

History & Background

Introduced by Apple in 2014 as a replacement for Objective-C for iOS, macOS, watchOS, and tvOS development. Created by Chris Lattner and the Apple team.

Current State (2025-2026)

Over 70% of active iOS apps were created with Swift in 2025. Swift is deeply integrated with SwiftUI, Combine, and declarative UI patterns.

Primary Use Cases

Pros

✅ Official Apple language — Full support
✅ Modern syntax — Safe and expressive
✅ High performance — Compiled language
✅ Safety — Optionals prevent null errors
✅ SwiftUI — Declarative UI framework
✅ Constant updates — Synced with Apple releases
✅ Good documentation — From Apple and community |

Cons

❌ Apple ecosystem tie — Limits opportunities
❌ Requires Mac — iOS development needs macOS
❌ Fewer jobs — Than cross-platform solutions
❌ Rapid changes — Language updates frequently
❌ Smaller community — Than JavaScript/Python |

Career Prospects

• Entry-level salary: $75,000 - $110,000 (US), £50,000 - £80,000 (UK)
• Beginner vacancies: Medium quantity
• Demand growth: Stable, depends on Apple device popularity |

When to Choose Swift

Good fit if:

• You want to develop apps for Apple ecosystem
• You have access to Mac hardware
• You're interested in mobile development focused on iOS
• Performance and native integration matter to you

Not ideal if:

• You don't have access to a Mac
• You want cross-platform development
• Android or web is your main interest |

Learning Resources

• Official docs: Apple Developer
• Courses: Stanford CS193p, Hacking with Swift
• Practice: Swift Playgrounds, LeetCode
• Books: "Swift Programming: The Big Nerd Ranch Guide"

Kotlin

History & Background

Developed by JetBrains and released in 2011. In 2017, Google announced Kotlin as the official language for Android development.

Current State (2025-2026)

Kotlin 2.3 dominates Android development in 2025. The Android ecosystem is evolving rapidly—Compose everywhere, KMP going mainstream, on-device AI.

Primary Use Cases

Pros

✅ Official Android language — Google support
✅ Modern syntax — More concise than Java
✅ Null safety — Built-in null pointer protection
✅ Coroutines — Simplified async programming
✅ Java compatibility — Works with existing code
✅ Kotlin Multiplatform — Code for iOS, Android, Web
✅ Jetpack Compose — Modern UI framework |

Cons

❌ JVM dependency — Requires Java Virtual Machine
❌ Compilation time — Can be slow
❌ Fewer resources — Than Java for learning
❌ KMP still developing — Not all platforms fully supported
❌ Smaller community — Than Java |

Career Prospects

• Entry-level salary: $70,000 - $105,000 (US), £45,000 - £75,000 (UK)
• Beginner vacancies: High in Android development
• Demand growth: Growing thanks to KMP and modern Android |

When to Choose Kotlin

Good fit if:

• You want to develop Android applications
• You're interested in cross-platform mobile development
• You have Java experience and want modern syntax
• Null safety and coroutines matter to you

Not ideal if:

• iOS is your main platform interest
• You're not interested in JVM ecosystem
• You prefer more mature languages with larger communities |

Learning Resources

• Official docs: kotlinlang.org
• Courses: Android Developers, Coursera
• Practice: Kotlin Koans, Exercism
• Books: "Kotlin in Action"

R

History & Background

Created by Ross Ihaka and Robert Gentleman at the University of Auckland in 1993. Named after the creators (R & R) and as a successor to the S language.

Current State (2025-2026)

In 2026, the most advanced data science teams don't choose between R and Python—they use both. R is experiencing a resurgence in statistical analysis.

Primary Use Cases

Pros

✅ Statistics specialization — Best language for statistical analysis
✅ Visualization — ggplot2 is one of the best tools
✅ Academic community — Many research papers published in R
✅ Analysis packages — CRAN with thousands of statistical packages
✅ Python integration — Modern workflows use both
✅ Reproducible research — RMarkdown, Quarto for reports
✅ Free and open-source — Active development |

Cons

❌ Narrow specialization — Not for general programming
❌ Performance — Slower for big data
❌ Syntax — Can be inconsistent
❌ Fewer jobs — Than Python in data science
❌ Learning curve — Specific concepts |

Career Prospects

• Entry-level salary: $65,000 - $95,000 (US), £40,000 - £65,000 (UK)
• Beginner vacancies: Fewer than Python
• Demand growth: Stable in academia and research |

When to Choose R

Good fit if:

• You're interested in statistical analysis and research
• You plan to work in academic environments
• Quality data visualization matters to you
• You work in bioinformatics or finance

Not ideal if:

• You want a universal programming language
• You're interested in web or mobile development
• You plan production ML systems (Python is better) |

Learning Resources

• Official docs: cran.r-project.org
• Courses: DataCamp, Coursera R Specialization
• Books: "R for Data Science", "The Art of R Programming"
• Community: R-bloggers, Stack Overflow

Zator

History & Background

Zator is a specialized programming language for AI pipelines, emerging as an open-source project in late 2025. It's not a Python competitor—it complements Python for specific tasks.

Current State (2025-2026)

Zator was created exclusively for building generative AI pipelines. It integrates with KoboldCpp for text generation and Stable Diffusion for images.

Primary Use Cases

Pros

✅ AI specialization — Optimized for generative AI
✅ Code reduction — 30 lines of Python = 5 lines of Zator
✅ Simple syntax — Optimized for AI content
✅ Easy integration — KoboldCpp and Stable Diffusion out of the box
✅ Open-source — Community can develop the project
✅ Not a Python competitor — Complements existing tools |

Cons

❌ Narrow specialization — Only for AI pipelines
❌ Young project — Less stability and documentation
❌ Few job openings — Specialized tool
❌ Requires experience — Not for absolute beginners
❌ Limited community — Compared to Python/JS |

Career Prospects

• Entry-level salary: Depends on primary specialization
• Beginner vacancies: Very few, specialized tool
• Demand growth: Depends on adoption in AI community |

When to Choose Zator

Good fit if:

• You already have programming experience
• You specialize in generative AI
• You need quick AI pipeline assembly
• You plan to create AI content (text + images)

Not ideal if:

• You're an absolute beginner in programming
• You need a universal language for various tasks
• You plan to work outside the AI sphere
• Stability and long-term support matter to you |

Learning Resources

• Official docs: GitHub repository
• Community: Discord, GitHub Issues
• Examples: Official examples in repository
• Integrations: KoboldCpp, Stable Diffusion documentation

Comparison Table

Final Recommendations

For Absolute Beginners

1. Start with Python or JavaScript — Most entry-level job openings
2. Master fundamental concepts — Algorithms, data structures, OOP
3. Build a portfolio — 3-5 pet projects to demonstrate skills
4. Don't search for the perfect language — Programming principles transfer between languages

For Career Changers

1. Assess existing skills — Domain knowledge can be an advantage
2. Research your local market — Jobs vary geographically
3. Consider enterprise languages — Java, C# for stability
4. Use online courses — Flexible learning without leaving your job

For AI Work

1. Start with Python — Foundation for ML/AI
2. Learn the libraries — TensorFlow, PyTorch, scikit-learn
3. Consider Zator — For specialized AI pipelines
4. Follow trends — AI field evolves rapidly

For Mobile Development

1. iOS: Swift + SwiftUI
2. Android: Kotlin + Jetpack Compose
3. Cross-platform: Flutter, React Native, Kotlin Multiplatform

For Web Development

1. Frontend: JavaScript/TypeScript + React/Vue/Angular
2. Backend: Python, JavaScript, Go, Java, C#
3. Fullstack: JavaScript/TypeScript (Node.js + React)

Wrapping Up

Choosing your first programming language is the beginning of a journey, not the destination. In 2026, the market offers many options, each with its own advantages and limitations.

Key Takeaways

1. No universal answer — The best language depends on your goals
2. Starting matters more than perfect choice — Programming principles transfer between languages
3. Specialization matters — Some tasks need specialized tools
4. Job market varies — Research openings in your region
5. Learning is a marathon — Be prepared for a long growth process

Whether you choose Python, JavaScript, Java, Go, Rust, Swift, Kotlin, R, or specialized solutions like Zator—the most important thing is to start and move forward consistently. Programming opens doors to many interesting fields, and the first step is the most important one.

Happy coding! 🚀

Article accurate as of 2026. Technology evolves rapidly—stay updated on new trends and adapt your learning path accordingly.

👋 About the Author

Feel free to add your bio, social links, and call-to-action here for Hashnode/Dev.to formatting.

📬 Stay Connected

• [Twitter/X]
• [LinkedIn]
• [GitHub]
• [Newsletter]

Did you find this guide helpful? Share it with someone starting their programming journey!

2026-02-21 22:37:49

What if the only thing that changed between English and French code was the surface syntax, not the interpreter?

tl;dr

• 1. One tiny semantic core, many language-specific “frontends”.
• 2. Code written in French, English, etc. maps to the same AST and runtime.
• 3. You can swap surface languages without changing the underlying program.

Most programming languages quietly assume that you think in English.

Keywords, error messages, tutorials, library names – everything is shaped around one language, even when the underlying semantics are universal.

I’ve been experimenting with a different approach: keep a tiny, shared semantic core, and let the surface syntax (keywords, word order) adapt to the programmer’s natural language.

The result is an interpreter where the same AST can execute code written in French, English, Spanish, Arabic, Japanese, and more – without a translation step.

Repository: https://github.com/johnsamuelwrites/multilingual

Why separate surface syntax from the core?

When we teach or learn programming, we often say “syntax is just sugar, what really matters is semantics.”

But in practice, syntax is where beginners feel the most friction – especially if they’re also learning English at the same time.

The idea here is to pull that intuition to the extreme:

• Keep one small semantic core (conditions, functions, variables, blocks, etc.).
• Describe each human language as a thin “frontend” that maps its own keywords and patterns into that core.
• Make these mappings explicit and inspectable, instead of hard-coding English everywhere.

This lets you ask questions like: what would this program look like if all the keywords were in French or Spanish? – while still running through the same interpreter pipeline.

How the interpreter is structured

How the interpreter is structured
At a high level, the interpreter is split into three layers:

• Surface syntax layer – Knows about keywords and word order for a specific human language (e.g., if vs si, print vs afficher). It only parses and normalizes, it never executes.
• Semantic core – A small, language‑agnostic core with expressions, statements, control flow, function calls, and environments. This is where the AST lives.
• Runtime / execution engine – Walks the core AST and evaluates it. At this point, the runtime is completely blind to the human language you used.

Each surface syntax module is responsible for normalizing its input into the same core representation.

That’s where most of the interesting language-design questions arise.

A tiny example

Suppose you want to express a simple conditional and a loop.

In an English-shaped surface syntax, you might write something close to Python-like pseudocode:

if x > 0:
    print("positive")

In a French surface syntax, the structure is analogous but with French keywords (this is illustrative – see the repo for the real examples):

si x > 0:
    afficher("positif")

Both of these are parsed into the same core AST node: a conditional expression with a predicate and a block.

The runtime never needs to know whether the original keyword was if or si.

The same idea extends to loops, function definitions, and so on.

Another tiny example

Suppose you want to write a function that prints numbers from 1 to 3 if a flag is set.

English-shaped surface syntax

if enabled:
  for n in 1..3:
    print(n)

French-shaped surface syntax (illustrative)

si actif:
  pour n dans 1..3:
    afficher(n)

Both programs are parsed into the same core AST: a conditional node whose body contains a loop over a range and a call to a print function. The runtime never needs to know whether the original keyword was if or si.

Why this might be useful

This is still an experiment, but a few potential use cases are emerging:

• Teaching in non-English contexts
  
  Instructors can show code with keywords in the students’ own language, while still having a single, shared semantic model under the hood.

• Research on multilingual PL design
  
  It becomes easier to compare how different natural languages “want” to express the same control structures, and where word-order differences start to matter.

• Accessibility and experimentation
  
  People can prototype their own keyword sets or dialects without forking the whole interpreter, as long as they can map back to the core.

Open questions and limitations

There are plenty of hard questions I’m still exploring:

• How far can you push word-order differences before the surface layer becomes too complex?
• How do you keep each mapping semantics-preserving, and how do you test that rigorously?
• Where do you draw the line between “just syntax” and constructs that really should live in the core language?

Right now, the project is deliberately small and experimental; the focus is on keeping the core minimal and making the mappings explicit, rather than covering every possible language feature.

How to try it, and how you can help

If this idea interests you, you can:

• Check out the repo: https://github.com/johnsamuelwrites/multilingual
• Run the examples and look at how the surface syntax modules map into the core.
• Open issues or PRs with:
  • new language mappings,
  • critiques of the core design,
  • ideas for better ways to specify and test the semantics.

2026-02-21 22:31:10

Apple Music's synchronized lyrics feature feels almost magical: words light up in perfect time with the music, scaling in size with the syllable's emotional weight, fading elegantly as each line passes. Behind that smooth experience is a carefully layered technical architecture that combines metadata standards, signal processing, and precision animation. Here's how it actually works.

The Foundation: Timed Lyrics Formats

The bedrock of any synced lyrics system is a timestamped lyrics file — a plain-text document that attaches a time code to each lyric unit. Apple Music uses two formats:

LRC (Line-synced): The oldest and simplest format. Each line gets a single timestamp — the moment it should appear. This is "line-level sync."

[00:12.45] Midnight rain falls on the window
[00:15.80] I can hear the thunder calling

TTML (Timed Text Markup Language): An XML-based W3C standard capable of word-level and even syllable-level timestamps. This is what powers Apple's "word-by-word" karaoke mode introduced in iOS 16. Each <span> can carry its own begin and end attribute down to the millisecond.

<p begin="00:12.450" end="00:15.800">
  <span begin="00:12.450" end="00:13.200">Midnight</span>
  <span begin="00:13.200" end="00:13.600">rain</span>
  <span begin="00:13.600" end="00:14.100">falls</span>
</p>

These files are produced partly by human transcription (for high-profile releases) and partly by automated alignment pipelines. Apple likely uses a combination of its own internal tooling and third-party providers like LyricFind or Musixmatch, who have built massive catalogs of synchronized lyrics.

Forced Alignment: How Timestamps Are Generated

For services that auto-generate word timestamps, the core technology is forced alignment — a technique from automatic speech recognition (ASR).

The process works in three steps:

1. Get the lyrics text. The lyrics are already known (from the music label or a lyrics service). This is the "forced" part — unlike ASR which must transcribe speech, the words are given. The system only needs to figure out when each word occurs.

2. Generate a phoneme sequence. The text is converted into a sequence of phonemes (the basic units of sound) using a pronunciation dictionary or a text-to-phoneme (G2P) neural network. "Midnight" becomes /M IH1 D N AY2 T/.

3. Align phonemes to audio using a Hidden Markov Model (HMM) or CTC-based neural network. The audio's acoustic features (typically mel-frequency cepstral coefficients, or MFCCs, or log-mel spectrograms) are matched against the expected phoneme sequence using dynamic programming (specifically, the Viterbi algorithm). The result is a precise mapping of each phoneme — and therefore each word — to a start and end timestamp in milliseconds.

Modern systems like Montreal Forced Aligner (MFA) or neural approaches using wav2vec 2.0 or Whisper with forced decoding can achieve word-level alignment accuracy within ~30–50ms on clean studio audio.

The Audio Clock: Staying in Sync at Runtime

Generating accurate timestamps offline is only half the problem. At playback time, the app must track the current playback position with high precision and trigger lyric events at exactly the right moment.

Apple Music uses AVFoundation's AVPlayer, which exposes the current time via CMTime — a struct that stores time as a rational number (value/timescale) to avoid floating-point drift over long durations. The app registers periodic time observers that fire at a defined interval (e.g., every 50ms) and boundary time observers that fire at specific pre-registered timestamps.

The boundary observer approach is ideal for lyrics: you pre-register every lyric timestamp before playback begins. The system fires a callback at each one, triggering the UI transition with minimal latency.

// Conceptual Swift — registers a callback at each lyric timestamp
for lyric in lyrics {
    let time = CMTime(seconds: lyric.startTime, preferredTimescale: 1000)
    player.addBoundaryTimeObserver(forTimes: [NSValue(time: time)], queue: .main) {
        self.highlightLyric(lyric)
    }
}

There's also a playback rate consideration. If the user scrubs or the audio buffers, the system must re-sync. Apple Music's lyrics view re-calculates the active lyric on every seek event by binary-searching the timestamps array for the current position.

The Visual Layer: Tone, Pace, and Weight

This is where Apple Music's implementation goes beyond most competitors. The animated lyrics aren't just "highlight the current word" — they encode musical energy visually.

Word-by-Word Reveal with Progress Masking

Each word isn't simply toggled on/off. Apple uses a gradient mask or clip-path animation that reveals the word progressively from left to right as the word's time window elapses. This creates the effect of the word being "sung" in real-time rather than just appearing.

The technique: a word has a known start and end time. The UI calculates a progress value from 0→1 based on (currentTime - wordStart) / (wordEnd - wordStart). This progress drives the width of an overlay or the position of a clipping mask, revealing the word character by character.

Scale as Emotional Weight

Apple's lyrics animate line scale based on the prominence of the current line relative to surrounding ones. The active line is larger; past lines shrink; future lines are subdued. This is achieved through spring-based scale transforms (using UIViewPropertyAnimator with UISpringTimingParameters), which gives a natural, physical deceleration rather than linear easing.

The spring parameters (damping ratio, initial velocity) are tuned to feel weighty for slow songs and snappy for uptempo tracks. Whether Apple dynamically adjusts these based on audio tempo analysis or uses fixed parameters per "energy tier" is not publicly documented — but the effect is clearly calibrated.

Pace Awareness: Fast vs. Slow Lines

For rapid-fire lyrics (think hip-hop verses), each word's time window is very short, so the progress mask animates quickly. For slow, sustained notes, the window is long, and the mask moves slowly. No special logic is needed — the pace of the animation is the pace of the music, automatically encoded in the timestamps.

Apple also dims lines that have passed and blurs them slightly, creating a depth-of-field effect that keeps the eye focused on the present moment.

Haptic and Spatial Integration

On supported devices, Apple Music adds another layer: haptic feedback timed to the beat (separate from lyrics, driven by beat-detection), and on spatial audio tracks, lyrics can be anchored in 3D space. These are enhancements on top of the core sync system, not fundamental to it.

Summary: The Stack

The key insight is that most of the "intelligence" is baked offline into the timestamps. The playback engine is relatively simple: it just needs to know the current time and fire events accurately. The richness of the experience comes from the quality of the timestamp data and the craft of the animation system layered on top.

Apple has not publicly documented the internal implementation of Apple Music's lyrics system. This article is based on analysis of observable behavior, public Apple developer documentation (AVFoundation, CoreMedia), reverse-engineering research by the community, and well-established techniques in speech processing and forced alignment.

2026-02-21 22:22:41

I’m developing a Bangladesh-based healthcare system, Gooddoktor.
Recently, I deployed my backend in a VPS using Docker.

I don’t have hardcore DevOps knowledge. I mostly:
learn → try → break → fix.
I set up nginx for the subdomain, all is ok. So yesterday I randomly tried a port scan on my own server. And guess what? I found multiple OPEN PORTS. Even worse…

I could access my project using: http://SERVER_IP:PORT. No domain, no SSL, Nothing. Anyone on the internet could directly access my services.

My First Thought
I asked ChatGPT:

• GPT gave firewall rules → I applied them → still accessible.

• Then I Googled → again firewall → again same result.

So clearly, the issue was not the firewall. That means something else was exposing the port.

The Real Problem (Docker Did It)
In my docker-compose I wrote:

ports:
 - "2525:2525"

Looks normal, right? But this line is VERY dangerous in production.

What actually happens
Docker doesn’t just run inside your machine. When you map a port like this:

2525:2525

Docker tells Linux: Bind container port 2525 to ALL NETWORK INTERFACES, Meaning: 0.0.0.0:2525 And 0.0.0.0 means: Accept connections from anywhere in the world

So the firewall allowed 80 & 443 only. But Docker bypassed it by opening its own socket. That’s why I could access:

http://ip:2525
Why the Firewall Didn’t Save Me
Important lesson:

Docker publishes ports BEFORE your firewall filtering in many cases (nat table). So, UFW rules ≠ protection if Docker exposes ports publicly. That’s why even after blocking, it still worked.

The Fix (Actual Solution)
Instead of:

ports:
- "2525:2525"

I changed to:

ports:
- "127.0.0.1:2525:2525"

Now Docker binds to:

127.0.0.1:2525
Meaning:

Only accessible from inside the server. Nginx can access. The Internet cannot. And boom. IP access stopped working.

Why This Works

Network scope difference:

Binding: 0.0.0.0, Meaning: Public internet | Binding: SERVER_IP, Meaning: Public internet | Binding: 127.0.0.1, Meaning: Only local machine

So now the flow becomes:

User → Domain → Nginx → localhost:2525 → Docker → App

Instead of:

User → Directly → Backend (very bad)

What I Learned

Docker is not just a container; it’s a network gateway
Port mapping is public by default
A firewall alone cannot save a bad Docker config
Production server should NEVER expose app ports
Always expose only nginx (80/443)
Final Advice

If you’re deploying backend/services with Docker and nginx:

Never do this in production

ports:
- "3000:3000"

Always do this:

ports:
- "127.0.0.1:3000:3000"

Deployment is not coding…
Deployment is security.

And security mistakes don’t crash your app. They silently make your app public.

2026-02-21 22:22:20

If you have worked with Sitecore AI (XM Cloud), you already know:

• Publishing performance directly impacts delivery speed and author productivity.
• For a long time, Snapshot Publishing (V1) powered Sitecore AI content delivery. It worked but as projects scaled, publishing times increased, CM servers became overloaded, and queues slowed down deployments.

Now, Sitecore introduces a modern, cloud-native approach:

Experience Edge Runtime (Publishing V2)

Let’s explore what changed and why it matters.

The Bottleneck: Publishing V1 (Snapshot-Based)

In Publishing V1, when you publish a page, the CM server performs heavy processing before the content even reaches Experience Edge

• Calculated the entire layout.
• Resolved all data sources.
• Executed Layout Service pipes.
• Created a massive, static JSON blob (a "Snapshot") to send to Experience Edge.

The Result: Publishing a simple page update could take minutes. Even a small content change requires rebuilding the entire page structure.

As your site grows:

• Layout complexity increases
• Datasource relationships multiply
• CPU usage on CM rises
• Publish queues grow longer

What once took seconds can quickly turn into minutes.

And at scale, this affects both publishing speed and authoring performance.

The Solution: Publishing V2 (Edge Runtime)

Sitecore AI introduced a new way to publish content: Publishing V2 (also known as Edge Runtime mode). It sounds technical, but it’s a beautiful simplification of how data moves.

Publishing V2 changes the architecture entirely.

Instead of pre-calculating the full layout JSON on the CM server, Sitecore now:

• Publishes raw item data
• Publishes layout references
• Defers JSON assembly to the Edge runtime

The final JSON response is assembled dynamically on the Experience Edge delivery layer not on CM.

This shifts the workload from the single CM instance to the massively scalable Edge CDN.

The "Cake" Analogy: V1 vs. V2

To understand the difference, imagine you are sending a cake to a friend.

Publishing V1 (Snapshot):

You bake the cake, frost it, box it up, and ship the entire heavy box.

• Technical Translation: Sitecore calculates the entire layout JSON on the CM server and sends a massive static blob to Experience Edge.
• Result: Slow and heavy.
• If you change one ingredient, you must bake the whole cake again.

Publishing V2 (Edge Runtime):

You just send the recipe and the ingredients. Your friend (Experience Edge) assembles the cake instantly when someone asks for it.

• Technical Translation: Sitecore sends only the raw item data and layout references. Experience Edge assembles the JSON at "runtime" when the API is called.
• Result: Lightning fast.
• You only ship the tiny changes.

Architecture Comparison

V1 Flow (Snapshot Publishing)

• CM → Layout Service Processing → Full JSON Snapshot → Experience Edge → CDN → Frontend
• Everything is assembled on CM before delivery.

V2 Flow (Edge Runtime)

• CM → Raw Items + Layout References → Edge Worker Runtime → JSON Assembly → CDN → Frontend
• JSON is assembled at request time by the Edge worker.

Key Advantages of Publishing V2

1). Blazing Fast Publish Times

Since layout JSON is no longer generated on CM, publish jobs typically complete in seconds rather than minutes.

This is especially noticeable on:

• Large component-based pages
• Sites with heavy personalization
• Complex layout structures

2️). Better CM Performance
The CM instance is no longer CPU-bound by layout assembly.

This means:

• Better authoring performance
• Higher concurrency
• Multiple publish jobs can run safely

3️). True Scalability

Processing shifts to the globally distributed Experience Edge runtime designed for high availability and horizontal scaling.

Your publishing performance now scales with Edge infrastructure, not your CM size.

Important Behavioral Change: Strict Dependencies

This is where V2 requires architectural awareness.

In V1:

• The snapshot captured fully resolved data at publish time.
• Previously resolved data could still exist inside snapshots.

In V2:

• JSON is assembled at request time.
• If a datasource item is not published, it does not exist in the GraphQL response.

This can result in:

• Empty components
• Missing navigation items
• Incomplete JSON output

Best Practice:

Always use:

• Publish Related Items
• Or ensure parent and datasource items are included in the publish job.

Caching Behavior in V2

V2 invalidates cache per item ID.

It does not automatically invalidate related items such as:

• Parent navigation
• Sibling teasers
• Shared components

If a shared data source changes, and parents are not published, you may see stale content.

Always plan publish dependency carefully.

How to Implement (The "Switch")

No code changes required. No config patching. No redeployment of frontend.

You can do this directly in the Sitecore AI Deploy Portal

Step 1: Log in to the SitecoreAI Deploy.

Step 2: Select your Project and Environment (e.g., Production, QA, or Development).

Step 3: Go to the Variables tab.

Step 4: Click Create Variable and add the following:

• Name: Sitecore_ExperienceEdge_dot_WorkerStoreEnabled 
• Value: TRUE
• Target: CM

Step 5: Save and deploy your environment.

Step 6: Once deployment completes, Republish all sites in the environment.

Important: Deployment + full republish is required for activation.

To revert to V1:

• Change the variable Sitecore_ExperienceEdge_dot_WorkerStoreEnabled to FALSE.
• Redeploy the environment
• Delete Edge content
• Republish all sites

Frontend Impact: The Best News

This is the "sweetest" part of the update.

Do not need to change your Next.js API endpoints.

Even though the backend architecture has completely changed, the Frontend Contract remains the same.

✔ Your Endpoint: Remains https://edge.sitecorecloud.io/api/graphql/v1
✔ Your Query: Remains exactly the same.
✔ Your JSON Response: Look exactly the same.
✔ Require zero refactoring

Why?

The change from V1 to V2 is purely architectural (Backend/Ingestion). It changes how data gets into the Edge, but it does not change Delivery how read it out.

• V1: Edge reads a pre-baked JSON blob.
• V2: Edge reads references and assembles the JSON blob on the fly.

Real-World Impact

In enterprise implementations, teams have observed:

• Homepage publish time reduced from minutes to seconds
• Massive reduction in publish queue backlogs
• Improved CM responsiveness during large content pushes

For content-heavy, composable architectures, this is a game-changing improvement.

Final Verdict

Publishing V2 (Experience Edge Runtime):

✔ Faster
✔ Lighter
✔ More scalable
✔ No frontend changes
✔ Cleaner architecture

The only requirement?

Be disciplined with publish dependencies.

For most Sitecore AI headless projects, this is a clear upgrade and a rare “win-win” architectural improvement.

Official Documentation

Ready to make the switch? Check out the official guides here:

• Sitecore: Enable Edge Runtime Publishing
• Understanding Publishing Architecture

Closing Thought

Sitecore AI is evolving toward true cloud-native architecture and Publishing V2 is a major step forward.

If you are still on Snapshot Publishing, this is the time to switch.

Happy Publishing.