The worst programming language of all time

[440bx]

That's the title of a youtube video at:

https://www.youtube.com/watch?v=7fGB-hjc2Gc

The title winner is C++.  The author of that video makes a really good case and, it is genuinely objective.  It's not an emotional thing. The author is obviously very well versed in C++.

Two things you should know upfront:

1. it's a 2 hour video, i.e, you might want to watch it in "pieces"
2. some parts are genuinely hilarious while being 100% accurate.

A question that is often pondered here in the forum is how to make Pascal more popular, I think an objective point by point comparison of Pascal against C++ could be helpful (that video provides quite a few bullet points for comparison.)  Another thing that might be helpful in the long run is to remove the flaws the two have in common (there are a few.)

Anyway, I recommend watching it.  Very educational and even fun in some parts.

Enjoy!.

[Zvoni]

On a side note: look for a video by the same title, but by Mark Rendle
It‘s parody, but completely hilarious

[avra]

it's a 2 hour video, i.e, you might want to watch it in "pieces"

I didn't have 2 hours, so I asked AI to "Read transcription of https://www.youtube.com/watch?v=7fGB-hjc2Gc and using it provide objective point by point comparison of Object Pascal (as in Free Pascal) against C++", and the result can be seen below. Not necessarily agree with all said, but it was fun to read, and it took just 2 minutes. 


Based on the transcript of "The worst programming language of all time" and the technical specifications of FreePascal (Object Pascal), here is an objective, point-by-point comparison.

The comparison focuses on the specific flaws of C++ highlighted in the video—such as build complexity, inconsistent syntax, and cognitive load—and how FreePascal handles the same engineering challenges.

Executive Summary
The video characterizes C++ as a language burdened by 40 years of legacy decisions, resulting in "atrocious" syntax, slow compilation, and dangerous footguns. In contrast, FreePascal (FPC) utilizes a modular Unit system and a rigid syntax designed specifically for readability and compilation speed. Where C++ relies on developer discipline to avoid pitfalls (e.g., "Modern C++" rules), FreePascal enforces safety and structure at the language level.

1. Project Architecture & Compilation
The video argues that C++'s reliance on header files is its single greatest design flaw, causing massive compilation overhead and "psychological anguish."

Feature	C++ (Per Video Transcript)	FreePascal / Object Pascal
Dependency Management	Header Files (.h): A "copy-paste" mechanism. Requires manual include guards (#ifndef) or non-standard #pragma once. Changes in private members force global recompilation.	Units (.pas, .pp): True modularity. A Unit has an interface (public) and implementation (private). The compiler handles dependencies automatically. No include guards needed.
Compilation Speed	Extremely Slow: Because headers are parsed repeatedly for every file, build times are "unacceptable." A string header might be compiled 1000 times in one project.	Extremely Fast: FPC is a single-pass compiler. Units are compiled to .ppu (precompiled units) automatically. The compiler only parses the interface of dependencies, resulting in lightning-fast build times.
Symbol Pollution	High: Including a header dumps all its symbols into your file, polluting autocomplete and causing name clashes (e.g., windows.h importing a million symbols).	Controlled: The uses clause imports symbols, but conflicts are resolved strictly by Unit order or explicit qualification (UnitName.Symbol). No macro preprocessor exists to hijack code.

2. Syntax & Verbosity
The video criticizes C++ for making simple tasks (printing, random numbers) unnecessarily complex compared to Python or Java.

Operation	C++ Complexity	FreePascal Equivalent
Printing to Console	Verbose: Uses overloaded bit-shift operators <<. std::cout << "Hello" << std::endl;. std::print (C++23) arrived 40 years late.	Simple: WriteLn('Hello');. A standard, built-in procedure available since the 1970s.
Random Numbers	Convoluted: Requires a random_device, an engine (mt19937), and a distribution just to get a number. Difficult to memorize.	Simple: Randomize; to seed, then Random(100) to get a number. Complexity is hidden behind the standard library.
Casting	Ugly & Verbose: static_cast<int>(value). Required to avoid "bad practice" C-style casts. The video calls it a "terrible eyesore".	Functional: Integer(Value) for reinterpretation or value conversion. Safe casting for objects uses the as operator (Obj as TMyClass).
Formatting	Inconsistent: "Every C++ codebase is a different language." Arguments over east-const vs. west-const, brace placement, and indentation.	Uniform: Pascal enforces a stricter structure (begin/end). The community standard (Borland style) is almost universally followed, reducing cognitive load when reading foreign code.

3. Type System & Initialization
The video highlights C++'s ambiguous types and dangerous initialization rules as major sources of bugs.

Feature	C++ (Per Video Transcript)	FreePascal / Object Pascal
Integer Types	Ambiguous: int and long vary by OS (Windows vs Linux). long is 32-bit on Windows but 64-bit on Linux. Suffixes _t (e.g., int32_t) are ugly.	Precise: Has generic Integer (usually 32-bit), but standard fixed types are clean built-ins: Int8, Int16, Int32, Int64. No _t suffix required.
Initialization	Chaos: "20 different ways to initialize a variable." Rules are so complex they fill a 300-page book.	Deterministic: Global variables and object fields are zero-initialized (0, nil, '') by default. Local variables warn if uninitialized. Constructors (Create) are explicit methods.
String Types	Confusing: std::string, std::wstring, char*, wchar_t, unsigned char. Confusion over byte representation.	Integrated: String (or AnsiString) is a native, reference-counted, copy-on-write type. UnicodeString handles UTF-16. No manual memory management for strings is required.

4. Semantic Clarity & Naming
The video claims C++ keywords and library names are often misleading, "pretentious," or repurposed confusingly.

Concept	C++ Issue	FreePascal Solution
Keywords	Overloaded: static has 3-4 different meanings (persistent, private, class-shared). inline no longer means inline.	Distinct: class var for shared fields. implementation section for private visibility. static is rarely used; concepts have their own dedicated keywords.
Library Names	Misleading: vector (should be array/list), remove (doesn't actually remove elements), monostate (pretentious). stoi (cryptic abbreviation).	Clear: TList or Dynamic Array. Delete removes items. StrToInt converts strings. Names are typically full English words (Free, Create, Add).
Namespaces	Fragile: Symbol lookup rules allow deep namespaces to hijack function calls silently. "Nested namespaces increase risk".	Flat: Units act as namespaces. Circular or ambiguous references are resolved explicitly (UnitA.MyFunc). No complex lookup hierarchy hijacking.

5. Safety & Modernization
The video concludes that "Modern C++" is a moving target, where best practices (like Smart Pointers) constantly change, leaving codebases in a "messy transition period."

• C++: Managing memory requires understanding ownership, move semantics, unique_ptr vs shared_ptr, and RAII. The video notes, "If you like C++, you don't know it well enough".
  
• FreePascal: Uses a stable manual management model (Create/Free) or ARC (Automatic Reference Counting) for interfaces/strings. While manual management has risks, the rules have not changed in 30 years, meaning 20-year-old Delphi code often compiles and runs perfectly today without refactoring for "Modern Pascal."
  

Verdict Based on User Context
The comparison highlights why FreePascal remains a strong contender:

• C++ offers "zero cost abstractions" but demands a massive tax on development time and mental energy due to the issues cited (header sync, build times, initialization edge cases).
• FreePascal offers fast iteration (compilation speed), stable syntax (no "modern" churn), and safe defaults (strings, distinct types), aligning with the need for reliable, cost-effective solutions.

References

• https://www.youtube.com/watch?v=7fGB-hjc2Gc
• https://www.reddit.com/r/pascal/comments/1km1orr/pascal_advantages_over_ccjava/
• https://learncplusplus.org/what-are-fixed-width-integer-types-in-modern-c/
• https://smartpascal.github.io/help/assets/randomrange.htm
• https://www.geeksforgeeks.org/cpp/static_cast-in-cpp/
• https://blog.digitaltundra.com/2015/01/19/everything-thats-wrong-with-the-c-and-object-pascal-languages/
• https://stackoverflow.com/questions/11225580/does-freepascal-really-use-far-less-memory-than-gcc
• https://stackoverflow.com/questions/57141453/when-should-i-use-the-c-fixed-width-integer-types-and-how-do-they-impact-perfo
• https://www.freepascal.org/docs-html/rtl/system/random.html
• https://stackoverflow.com/questions/1609163/what-is-the-difference-between-static-cast-and-c-style-casting
• https://betterprogramming.pub/kotlin-native-vs-c-vs-freepascal-vs-python-a-comparison-part-2-1be9007ecf41

[440bx]

@avra,

I watched the entire video and can say that, that summary is quite good.

I am also impressed with the nice formatting of its conclusions (I presume you had the A.I thing do that too.)

[Thaddy]

@Avra

If you try to simply cast a float value to an integer (as above) you will be in for a big surprise....
That merely indicates a shortcoming of Freepascal: it is not the bit pattern, but the value pattern.

[CM630]

This reminds me of https://en.wikipedia.org/wiki/Pepsi_Challenge
Blind test showed that Pepsi tasted better than Coca-Cola, but the sells showed the opposite.
That was once, of course, when Pepsi was still potable.

[440bx]

Taste is subjective. 

Glaring flaws in a language are not.

[Martin_fr]

Glaring flaws in a language are not.

"Glaring"...

Apparently that can be fixed by dark theme/mode... SCNR

[440bx]

but it wouldn't fix the non-glaring flaws... that's a flaw in the theme.

I tried to set VS up with a dark theme, never could manage to end up with something I found tolerable, much less usable for extended periods of time.   Just the fact that it cannot use bitmapped fonts is, IMO, a significant problem.  I am yet to find a TrueType font that is anywhere close to Borland's BorTE bitmapped font (which is the one I use.)

[dbannon]

Wow avra, you have nailed it. I have not watched the video but have been using (sort of) c++ recently on a project using an esp32 chip. While I once, long ago, was a C programmer, I never really made the transition to c++, Delphi saved me from that.

I wish I had read avra's summary before I started said project, I wasted a lot of time saying, "no, it cannot be that [hard, complicated, slow]". cmake is evil, it allows the build process to be totally incomprehensible.

Davo

[440bx]

It really is surprising that a language with so many deep flaws and problems can be so popular.

Personally, my extent with C++ is to use it as a "better" C compiler.  IOW, I don't use C++ features, I just use it as a version of C that knows about type checking, which is a nice and welcome improvement to the language.

Unfortunately, that means I often experience difficulties when trying to understand C++ code that uses the features that are specific to the language.

Even building some C++ programs using setups tailored for VS can sometimes be a nightmare.  To build some of Pavel Yosifovitch's programs, I had to _manually_ edit the project files (equivalent to manually editing a Lazarus .lpi file but quite a bit more convoluted - I've edited those too! )

On a related note about the build process, the last nail in the coffin of the editor I use (Multi-Edit) was that no one could figure out how to _build_ the editor.  The _one_ guy who knew how to build it unexpectedly passed away as a result of a heart condition and, apparently some parts of the build were done manually.  (This is what I learned when investigating the reason why the editor that is so close to my heart is no longer commercially available.)

[domasz]

I like how I open a Delphi or Lazarus project, click Compile and get and exe while when I try to compile a C++ program I learn I cannot because I don't have the right C++ compiler or OS. And I like how C++ programmers claim it's portable. Please compile a C++ Builder GUI app with your GCC on Linux.

[LV]

It really is surprising that a language with so many deep flaws and problems can be so popular.

While I don't consider myself a C/C++ apologist, it's important to note that there are highly optimized compilers available for these programming languages. When it comes to high-performance computing tasks, the choice of language can be crucial.
My limited experience has shown that, in some cases, comparable performance can be achieved with additional effort with FPC. However, it is often easier to write a heavy math kernel in C or C++ or to use a pre-existing library and then integrate it into an application created in Lazarus.
At the same time, I appreciate the elegance and beauty of the Pascal language, as well as the charm of the somewhat old-fashioned Lazarus environment.

[440bx]

it's important to note that there are highly optimized compilers available for these programming languages. When it comes to high-performance computing tasks, the choice of language can be crucial.

Yes, that and the fact that some features are hard to come by in other languages, e.g, simply aligning records and fields in FPC on boundaries that exceed a qword is as convoluted as it can get. 

[Xenno]

And then that spaghetti gets cooked by different chefs and served as C#, Java, D, Rust, and so on. The fans say, “See? It’s still tasty—you can even feel the yummy texture after all this time. Well, they actually taste much better, you may forget the original recipe.”

Okay, but I prefer Pascal and Rendang.