Thoughts on Various Programming Languages

2017-02-10

After reading Metaprogramming Ruby, I discovered that object-oriented programming can be used so flexibly.

Combining this with my previous knowledge of object-oriented concepts in Java, Python, and Golang, I realize that various programming languages are actually very similar.

Organizing Program Elements from Large to Small

Folders

Often called packages (Python, Java) or libraries (Go).

Files

Called modules (Python) or libraries, or encapsulated into classes or interfaces (Java).

Classes

Contain attributes (data) and methods (interfaces). In Go, data and methods are forcibly separated to improve concurrency.

Methods

Functions belonging to an object, defined in a class, and must be instantiated before use.

Functions

Like functions in C, can be called globally in a file, independent of classes, and do not require instantiation.

What are the differences among programming languages? In essence, their core functionalities are similar. After all, they all descend from C and run on a limited number of CPU architectures and computer systems.

Major Differences Among Programming Languages

Keywords

Keywords vary.

Syntax

Such as if/else, whether there is an ’end’ keyword.

Data Structures

For example, strings, arrays (lists), maps (Map/Hash), sets (Python-specific), tuples (Python-specific). Consider aspects like type, fixed/variable length, mutability, iterability, uniqueness, ordering, CRUD operations, sorting, performance, concatenation (using + or join), underlying implementation (reference/non-reference), pass-by-value or pass-by-reference.

These differ across languages, but underlying principles are similar.

Object-Oriented Concepts (Core Ideas Similar)

Access modifiers like private, public, protected vary in usage.

Method Calls

Slight differences in method calls and library usage.

Error and Exception Handling

Minor differences.

Concurrent Programming

Includes multiprocessing, multithreading, coroutines. Main differences are in granularity.

Scope

Folders, files, classes, methods, functions—all relate to scope and encapsulation. Dynamic languages (Python/Ruby) have weak typing and unclear scope boundaries, often causing strange issues and debugging difficulties. As programs scale, they become hard to control.

A core concept: Classes. Classes package scattered data and specific interface methods together to improve extensibility, reusability, and cleanliness.

This introduces complexity and efficiency losses. For humans, it allows maintaining larger projects (more code lines, objects, complex relationships), but for computers, it may not be optimal. From a concurrency perspective, it’s harder to handle and coordinate. Encapsulation also brings access permission issues, like private, public, protected, default in Java, and similar in Ruby. Is such granularity necessary? Worth pondering.

Go forces separation of data and methods, with interfaces implicitly auto-matching for OOP features, improving concurrency. Access permissions are only two types: starting with uppercase or lowercase letters.

Ultimately, programming languages must efficiently (considering both computers and humans) handle and coordinate data and behavior on specific hardware architectures. Managing relationships between object attributes (data) and behaviors (methods) is essentially scope division, permission division, and relationship management.

Dynamic languages have much uncertainty and, in the long run, do not bring real development efficiency gains.

Additional Comparisons

  • Performance: Compiled languages like Go and Rust offer better performance than interpreted ones like Python.
  • Ecosystems: Python excels in data science; Java in enterprise; Go in cloud services.
  • Type Systems: Static (Java, Go) vs. Dynamic (Python, Ruby) – static catches errors early but is more verbose.
  • Modern Languages: Consider Rust for safety, TypeScript for JavaScript enhancement.
  • Choosing a Language: Depends on project needs: web (JavaScript/Node), systems (Go/C), data (Python/R).

References