Programming Questions

1. Moving from Punch Cards to Programming Languages

I didn't know a lot about punch cards, so I needed to search about them, and the first time I heard about them was in this class on our last session from Professor Ryan. In my 15-112 class, making a simple syntax error in Python is already frustrating, so imagining physical cards makes me appreciate how much smoother software development has become. While I am still uncertain about all the physical quirks of vintage mainframes, studying early batch processing helped me understand why this transition was necessary. The reasons I think we moved from punching cards are:

• High Physical Error Rates and Slow Feedback: Punch cards were physical paper cards where data was encoded using punched hole patterns. A single typing mistake meant manually re-punching the card on a keypunch machine or facing failed batch execution jobs that took hours to run.
• Need for Human Readability: Early programmers had to write raw binary instructions or hardware mnemonics, which made code dense and hard to debug. High-level languages like FORTRAN allowed developers to write algebraic formulas.
• Portability Across Hardware: Punch card decks and early assembly code were bound to specific machine architectures. High-level programming languages enabled code portability by allowing compilers to translate unified source code for different target machines.
• Complexity of Expressing Algorithms: Expressing control structures like loops and conditionals with physical cards led to unstructured code organization. Higher-level languages provided structured control flow mechanisms that reduced logical errors.

2. The Need for Hundreds of Programming Languages

When I started learning to code, I wondered why developers created so many different languages when Python seemed to handle so many tasks. After attempting small C++ projects alongside JavaScript, I realized that different problems demand different trade-offs. I am uncertain about the full scale of software engineering in massive industries; however, observing distinct runtime requirements clarified why a single language cannot rule everything.

From searching online, I found that:

• Domain Optimization: Different industries require specialized toolsets. For instance, C is tailored for operating system kernels, JavaScript dominates browser environments, Python excels in data science, and C++ handles high-performance graphics engines.
• Diverse Programming Paradigms: Languages offer different mental frameworks for structuring code. Developers can choose imperative, object-oriented, functional, or event-driven paradigms depending on how they prefer to model system logic.
• Performance versus Productivity Trade-offs: Interpreted languages with automatic memory management offer rapid development velocity, whereas compiled languages with manual memory control provide raw execution speed.
• Target Platforms and Runtimes: Hardware environments dictate language constraints. A browser runtime needs lightweight asynchronous event handling, while embedded microcontrollers require predictable low-level hardware access.

3. Drawbacks of Languages I Use and How I Would Change Them

In my coursework and personal projects, I primarily use Python and JavaScript. I also have limited exposure to C++. Because I am still a freshman, I might lack full appreciation for historical design decisions; nonetheless, I frequently encounter language behaviors that cause frustrating bugs.

Key Drawbacks in My Main Languages I Noticed

JavaScript Drawbacks

• Implicit Type Coercion: JavaScript automatically converts types during operations, which leads to unintuitive bugs. For example, evaluating "5" + 3 results in the string "53", whereas "5" - 3 results in the number 2.
• Single-Threaded Main Loop: JavaScript runs on a single main execution thread using an event loop. If a program performs heavy CPU computation, it blocks the main thread and freezes the application.

Python Drawbacks

• Global Interpreter Lock (GIL) Overhead: Python utilizes a Global Interpreter Lock that prevents true parallel execution of multiple CPU-bound threads.
• Execution Speed Limitations: Python is dynamically typed and interpreted, introducing runtime performance overhead compared to compiled languages like C++.

Specific Changes I Would Implement

• Native Strict Typing Mode for JavaScript: I would like JavaScript to include an opt-in runtime keyword, such as "use strict types", disabling implicit type coercion completely.
• Built-In Parallel Processing Engine for Python: I would like Python to feature built-in multi-threading without GIL restrictions for CPU-heavy tasks.

4. Designing a New Programming Language

Creating a brand-new programming language sounds equal parts fascinating and intimidating to me. I am really curious about how computers turn plain text into actions because up until now, I have only taken language syntax for granted. I do not know all the advanced compiler mechanics yet; regardless, reading about language design made me realize how structured the parsing pipeline is.

Steps and Definitions Required to Build a Language

1. Define Syntax and Language Goals: I would begin by deciding what my language should look like and what problem it attempts to solve. I would need to specify keyword syntax, operator rules, variable scoping, and dynamic or static typing rules.
2. Build a Lexer (Tokenizer): The first technical component is a lexical analyzer. The lexer reads source code text character by character and groups them into meaningful tokens such as keywords, numbers, string literals, and math operators.
3. Build a Parser (Abstract Syntax Tree): Next, the parser converts the flat token stream into a hierarchical structure called an Abstract Syntax Tree (AST). The parser checks if the code follows grammar rules and organizes operator precedence.
4. Construct an Execution Engine: Finally, I would need an execution backend. I could build a tree-walking interpreter that executes the AST directly, or write a transpiler that converts the AST into JavaScript code.

References

1. Wikipedia. Computer programming in the punched card era. https://en.wikipedia.org/wiki/Computer_programming_in_the_punched_card_era
2. Pyatagouda, S. The Evolution of Programming Languages: From Punch Cards to Modern Code. Medium. https://medium.com/@sreekanthpyatagouda/the-evolution-of-programming-languages-from-punch-cards-to-modern-code-afa752a6b4ae
3. Quantum Zeitgeist. Programming Languages: From Punch Cards to Python. https://quantumzeitgeist.com/from-punch-cards-to-python-the-evolution-of-programming-languages/
4. ResearchGate. An Insight into Programming Paradigms and Their Programming Languages. https://www.researchgate.net/publication/400187367_An_Insight_into_Programming_Paradigms_and_Their_Programming_Languages
5. IBM. What is a Compiler? https://www.ibm.com/think/topics/compiler
6. Bailey, J. Fundamentals of JavaScript. https://jeffbailey.us/blog/2026/03/20/fundamentals-of-javascript/