# Get Better At Being Sh*t
## 2024-02-16
### 2 min read

Get better at being sh\*t; An interesting philosophy I've began to develop throughout my journey in CS.
For those of you who don't know me, I'm Damian, currently a 2nd year student at The University of Toronto doing a CS Specialist & Math Major. Sounds like a thrill, **I know**. I'm currently doing an 8-month Internship at JDRF Electromag Engineering which has honestly surpassed my expectations and my interest in  software has grown exponentially since starting at the beginning of January. Anyways, I've come to realize that Computer Science, at least the software engineering side, isn't all about being the best and knowing everything. It's about being the best at being sh\*t. Let me explain.

You aren't going to know every single trick in every language or framework, especially with the state of modern JavaScript and the entirety of Web Dev for that matter. You aren't going to know how to solve a problem right away, or even after a week of angrily spamming ChatGPT to give you the answer. Trust me, I've tried. However, what you can master is the ability to set aside the ***CS Ego*** and just solve the problem. Arriving at a solution as quick as possible isn't always the most important part, especially at the beginning of your journey. Take the time to be confused and have no idea on how to approach it, try to come up with **your** solution and learn from it. This is how you are going to become a better engineer. Don't get locked into following tutorials and copying code from online resources. Start developing your own style/approach to solving problems and writing code, and iterate. Just like the software you write, you should be constantly updating and improving yourself and still be garbage. 

The best advice I can give to anyone in the field is to once again, drop the ego, and start small. I used to think project oriented learning is the best way to start off with a new language or framework, but I've come to realize that it is actually the **worst** way to start. I've found that I just become stuck in a position where I don't actually develop any techniques and that first project just becomes a sort of lookup table where I go back and refer to how I did it the first time. You need to start with the fundamentals of the language and go from there, regardless of how much experience you have working with things. I'm going to be going into more detail on my approach to learning new languages and frameworks in a future post.


 There's a quote from an senior engineer at Netflix that I can only loosely paraphrase:

> "You aren't going to understand why something is important until you've shot yourself in the foot a hundred times doing it the wrong way." - ThePrimeAgen

If this doesn't hit your heart like a bad childhood memory, I question your experience level in the field. 

It is so important to make mistakes and learn from them. It's the only way to grow. So, get better at being sh\*t, and you'll be the best engineer you can be.


Drop the CS ego, and become a better engineer. 

Get Better at Being Sh*t

# AtLeastItsNotjs | Starting the Journey of Writing a Language in GO

A couple months ago, I was introduced to GO, an extremely simple and concise language which claimed to be the messiah of modern concurrency. This was shortly after I was introduced to writing **actual** concurrent code in Swift, which was keyword hell, however, it's actually quite powerful with the use of the Combine framework. Anyways, For those of you who don't know what concurrency is, I'll explain it as simple as possible with the following image:

<img src='https://i.imgur.com/WFS2zg1.png' alt='Concurrency vs Sequential'/>
<br>

Thats pretty much all you need to know for now. Anyways, I decided to take a look at Go and see what all the fuss was about. I was quite impressed with the simplicity of the language and how easy it was to write concurrent code. I had gone through the normal things I do when picking up a new language: go through docs, implement some key data structures, build a simple http server, etc. I had written the backend (article server) for this website as a part of that practice. After doing these things and a variety of other small tasks, I had really started to like programming in Go. I'm able to do everything I need with the standard library, there isn't more keywords than use cases, and the way in which programs tend to be structured is very clean and intuitive to someone who is new to the language.

The next obvious step was to create a language, including an interpreted and compiled version, as well as a fully functional LSP. Well, I'm partially joking here. The compiler and LSP are coming soon... ish. What I have started to work on is the interpreter. Prior to starting this, my understanding of how a programming lanugage actually worked was probably the same as most people: you write code, the computer reads it, and then it does what you told it to do. I had no idea how the computer actually read the code, how it knew what to do, or how it knew what to do with the any of the garbage code it was executing. So I decided to try and see what it would take to implement something like this, and what better way to do that than to write a language in a language I'm still learning. Right? Well, yea actually. My goal here isn't to create a spring off of Rust that allows you to be a normal person and still write safe and performant code. It is to just figure out how things work "under the hood".

I did some looking around and figured a purely theoretical book isn't going to do me much justice as my understanding of Go is nowhere near where it would need to be to follow that sort of path. I did end up stumbling upon a book called "Writing an Interpreter" by Thorsten Ball. This book takes a hands on approach to writing an interpreter and goes over an ample amount of the theory/ fundamental concepts of how an interpreter works. It does leave out quite a bit of functionality and uses some questionable syntax in the language they choose to create however thats where I come in! My strategy has been to use the book as a reference more than a guide and fill in all the gaps it doesnt cover as well as correcting the syntax to be more alligned with how I like to write code.

Before I jump into some of the decisions I've made and the progress I've made so far, I want to give a brief overview of what an interpreter is and how it works. An interpreter is a program that reads code and executes it. It does this by reading the code, parsing it into a data structure, and then executing that data structure. The data structure is usually a tree, where the root node is the program and the children are the statements in the program. The interpreter then traverses the tree and executes the statements in the order they appear in the tree. This is a very high level overview of how an interpreter works, but it should give you a good idea of what an interpreter is and how it works.

How does the code get read? Well the most basic part of an interpreter is the concept of 'tokens'. Tokens are essentially the 'keywords' of the language, such as `for`, `in`, `func`, etc. Also including all identifiers/operators (+/-< etc). The next step up is the 'lexer'. The lexer takes the raw code and turns it into a list of tokens. This has so far, included the most complexity. This layer is responsible for making all those tough decisions of what token means what. For example, knowing when its lexing an `Int` vs a `Float`, or determining the use of brackets in a statement like: `let x = (5 * 3) + ((add(3, 9) + 4) * (87/7))`. Statements similar to the last pose the problem of identification. The brackets parenthesis surrounding the `5 * 3` are clearly not meant to be treated the same as the ones surround the arguments supplied to the `add` function. The lexer is responsible for making these decisions and creating the list of tokens. The next step up is the 'parser'. The parser takes the list of tokens and turns it into a data structure, usually a tree. The final step is the 'interpreter'. The interpreter takes the tree and executes it. This is a very high level overview of how an interpreter works, but it should give you a good idea of what an interpreter is and how it works.

Now, as you all know, the most important part of any language is the name of course. I belive that the one chosen is perfect and requires no further explanation. (I love Javascript (we all know js is essentially ts at this point) and it is used everywhere, its just a joke...). As of when this article was written, I have made some solid progress on the lexer, parser, and the ast (Abstract Syntax Tree). I am still getting a hang of the whole interpreter thing works and constantly iterating on what's already been written as I find flaws.

To anyone who has made it this far, I hope you enjoyed the read and I hope you stick around for the next article where I will go over some of the decisions I've made and the progress I've made so far. I will also be going over some of the challenges I've faced and how I've overcome them. I'm planning for that one to be a bit more technical with a stronger focus on the implementation details. I hope to see you there!

How I got into Go and what led me to write my own language in it