Type-C Design and Philosophy

It is my belief, that type-c is a like-it or leave-it language. While the project is in early development, the core of features and design choices will most remain the same.

Interface Oriented Programming

Modern programming has primarily leaned towards Object Oriented Programming (OOP), a paradigm that, while revolutionary, comes with its own set of drawbacks. Inheritance in OOP, for example, often results in rigid, tightly-coupled systems that become burdensome to extend or modify. Encapsulation, while safeguarding data, poses challenges concerning data ownership and leads to murky accessibility rules. Type-C addresses these issues by moving from an object-centric to a behavior-centric model. Behaviors are defined through interfaces, much like in Java, which helps to tackle some of the inherent limitations of traditional OOP. Let's talk about the advantages of such a model:

• Enhanced Code Modularity: Final classes provide a stable foundation for defining predictable and maintainable behaviors.
• Enforced Design by Contract: Type-C's focus on interfaces and behaviors naturally lends itself to a Design by Contract methodology. Interfaces act as contracts that concrete classes must fulfill, thereby boosting code reliability and predictability.
• Reduced Complexity: The focus on behaviors and interfaces simplifies Type-C's constructs, leading to straightforward, less complex code.
• Code Reusability: The use of interfaces enables code reuse. Multiple classes can implement a single interface, allowing for polymorphism and greater modularity.
• Encouraging Composition: Type-C promotes composition over inheritance. Rather than inheriting attributes and methods from a base class, developers can compose objects from multiple interfaces, resulting in a flexible, loosely-coupled code structure.
• Stateless Encapsulation: Unlike traditional OOP, where encapsulation is often tied to the object's state, Type-C's interface-oriented paradigm encourages encapsulation through behavior. Interfaces define what actions can be performed but not how data is stored, reducing conflicts over data ownership and providing clearer accessibility rules, while still giving the developer the possibility to cast the interface to its actual class and modify the state if needed.

In conclusion, while behavior-driven programming in Type-C does not fix all programming challenges, it offers a robust alternative to traditional OOP paradigms. It brings about increased modularity, contract-driven development, and a focus on behaviors, among other benefits. However, the power of Type-C comes with its own set of responsibilities. Best practices are still critical to harnessing its full potential, lest any misuse of its features turn into liabilities. Let's also review some the drawbacks of this model.

• Potential for Contract Violation: While interfaces define contracts, they can't enforce them at runtime. Therefore, a class that poorly implements an interface can lead to unexpected behavior.
• Increased Initial Complexity: The focus on defining behaviors through interfaces can increase the initial development time and may require a deeper understanding of the domain.
• Dependency on Good Design: A poorly designed interface can be as problematic as a poorly designed class in OOP. Effective use of behavior-centric programming relies heavily on well-designed interfaces.
• Versioning Issues: As with any contract, changes to an interface can break existing implementations, leading to versioning challenges.
• More Boilerplate Code: Interfaces can lead to more boilerplate code, especially when multiple classes implement the same interface. This can increase the codebase's size and complexity. A solution to this is still being thought of.

No User-defined Runtime Exceptions

Type-C diverges from many contemporary programming languages by disallowing user-defined runtime exceptions. This design choice is underpinned by several considerations aimed at enhancing code clarity, predictability, and developer discipline.

• Unpredictable Control Flow: Runtime exceptions interrupt the regular flow of a program, leading to non-linear and harder-to-follow logic. This complexity increases debugging time and can make code maintenance more challenging.
• Debugging Difficulty: Exceptions can be unpredictable both in terms of when they occur and where they are caught. This unpredictability complicates debugging, as developers must not only trace the exception but also understand the various conditions that led to its occurrence.
• Lack of Transparency: Using exceptions can make the code less transparent by hiding error-handling logic, making it more difficult to reason about the program’s behavior.

To explain even further the motivation behind this design choice, a quote is presented, by Martin Sústrik, the author of ZeroMQ, from his blog post: "Why should I have written ZeroMQ in C, not C++ (part I)":

As you fix individual bugs you'll find out that you are replicating almost the same error handling code in many places. Adding a new function call to the code introduces that possibility that different types of exceptions will bubble up to the calling function where there are not yet properly handled. Which means new bugs.

Type-C encourages a proactive approach to error handling. It requires that errors be explicitly communicated through robust type constructs. For example:

Mutability, Immutability and Pure Functions

In Type-C, variables are mutable by default. However, the programmer can define an immutable entity through explicit declarations. Here's how you declare immutable and mutable variables and functions in Type-C:

Additionally, once you construct an immutable constant, any object used to reference it also becomes inherently immutable afterwards. This design choice offers a balanced approach to mutability and immutability, reaping several benefits:

• Clarity, Readability, and Efficiency: Immutable variables by default could introduce overhead, as each modification would require creating a new variable instance. Type-C balances programmer expectations and performance needs by making mutability the default.

• Flexibility: Type-C allows for explicit immutability, giving programmers the power to enforce it in critical parts of the code.

• Pure Functions by Default: Functions in Type-C are expected to be pure, encouraging functional programming practices.

• Improved Code Quality: By offering optional immutability and encouraging pure functions, Type-C helps developers produce higher-quality, easier-to-test, and more maintainable code.

• Consistency: Type-C enforces a consistent approach to mutability and immutability, reducing potential confusion and encouraging best practices.

Strong Typing and Type Compatibility

Type-C emphasizes strong, static typing with structural equivalence:

• Flexibility through Structural Equivalence: Types that are structurally identical are considered compatible, enhancing code reusability.
• Robustness and Safety: All type checks occur at compile-time, minimizing runtime errors related to type mismatches.
• Clarity and Self-Documenting Code: Despite the prevalence of anonymous types, naming data types is encouraged for maintainability.
• Optimized Type Inference: Type-C's type inference engine reduces verbosity, eliminating the need for explicit type annotations in many contexts.

This strong typing philosophy ensures a balance between flexibility and robustness, fostering a development environment conducive to producing high-quality, maintainable software.

Concurrency

Concurrency is still undergoing development and is not yet fully implemented.