Hacker News new | ask | show | jobs
by vivzkestrel 17 days ago
- stupid question: how do you make a programming language like this from scratch?

- what is the thought process that goes into making a programming language

- what is this field of study or discipline called?

- why do we have so many programming languages? what purpose do they intend to solve and how do we know what purpose a programming language was made for?

- for example, why was swift made if objective c exists and why was objective c made if c++ exists?

7 comments

> how do you make a programming language like this from scratch?

Write a parser from your language’s syntax to an AST (Abstract Syntax Tree) which is the representation of the code in memory. Now write a function from the AST to the compiler output format. That can be some executable binary format (see https://en.wikipedia.org/wiki/Comparison_of_executable_file_...) or some other language, like C (a common target) or something made exactly for that like LLVM (used by clang and Rust), Java or C# bytecode if you don’t mind requiring a VM to run the application. I’ve written Java bytecode generators and it’s surprisingly easy! Getting a simple language off the ground is a lot of fun and not a huge challenge.

When I was in university the course was called compiler construction. Making a language like G# is very simple and about the level that the final project of the course would be if the team was working together really well and went for maximum bonus points.

We have so many programming languages because it's a fun and relatively easy thing to start, and lots of people have differing opinions of how it should be done. Also making a programming language seems like a difficult thing from the outside so it has a certain allure.

Swift exists because objective c has archaic language design that modern developers reject. Objective C exists because as far as I know at the time smalltalk style object oriented programming was hip and C++ made the wrong decisions in their eyes. It could also be that C++ wasn't popular enough yet at that point for Apple to commit to it. In that period basically all major operating systems went different ways. The Unix derivatives went all in on plain C, Microsoft went C++ and Apple objective c, though I think OSX itself is plain C for the most part.

Making new programming languages is something a lot of people do for fun, and it's also covered in most CS degrees too, albeit briefly.

We have so many programming languages because they tend to have a particular niche in which they're useful. Many languages are still in use even though they're very old (C, FORTRAN, COBOL), and others just keep getting updated over time and have a large userbase (Java, Perl, Ruby, Python).

99.99% of all new programming languages never get a critical mass of users. People create a new language to learn something, and they're the only user. e.g. I've written a few FORTHs, have spent the past few weeks on writing a lisp compiler, and in the past wrote BASIC interpeters for fun.

If you want to make your own "crafting interpreters" is a good read:

https://craftinginterpreters.com/contents.html

But there are a million other tutorials on writing a simple lexer/parser/interpreter/compiler, and a lot of academic literature (e.g. The Dragon Book).

- it's easy to prompt an LLM to do it for you, especially if you're targeting a pre-existing runtime like CLR or transpiling to another language. previously you'd have to grind out the parser and compiler for a new language, but a lot of that work is mechanical

- "I want a language that works a little differently"

- programming language theory (PLT), generally

- languages are tools. the authors should explain what their languages are best suited for

- Obj C and C++ were both developed around the same time as extensions of C. Obj C was focused on message passing and Smalltalk's object system, while C++ was focused on adding as many abstractions as possible to C. Neither language has good support for avoiding null pointer dereferences, one of the primary things Swift addresses with its richer type system and Optionals.

For your first two questions, I can't recommend Crafting Interpreters enough, it's probably one of the best entry-level books that goes into that entire process.

https://craftinginterpreters.com/

i have made a language that xompiles to c#. I wrote a lexer. then a parser. then a type checker (hindley milner, function local so that top level functions must have type signatures) a match compiler.

the hardest part was what came next: the code generation. despite producing c# instead of MSIL. The features I use are: static and dynamic traits, pattern matching, and a concurrentML.

It is actually quite simple when you don't have to do closure conversion yourself.

I've done that for transpilation from SAOL (an MPEG 4 historically curious language) to C++. It does make it incredibly easy to write the compiler.

The big drawback that I never managed to sort out is how to integrate with visual debuggers. How to generate GDB source mappings (or .PDB source mappings) that reference the original LanguageX source files.

So you end up with a toy language that is un-debuggable. Which is not nearly as much fun as it should be.

if you compile to c# you can use #line directives to get integration with debuggers. it is really simple. for debug builds you can do an ANF pass and generate debugging locations for every different expression.
Why was c created when we had asm? Actually why even bother with asm when punch cards did the job just fine.