Hưng Đặng > Recent Status Updates

Tách 1 method lớn thành các methods nhỏ hơn có thể ko làm code trở nên dễ hiểu hơn. Tác giả nhắc người đọc tránh các metric đơn giản kiểu method dài hơn 20 dòng là phải tách, yêu cầu người đọc tìm ra sự cân bằng vừa đủ mà method cần truyền tải. Có điều nếu đọc method này mà phải đọc thêm methods khác để hiểu thì nó cũng là điều thường thấy

clean code thì coi việc số dòng là 1 metric nhưng nếu 1 file hoặc 1 class bị ngắn quá thì nó bị tủn mủn và "noisy" vì phải nhảy qua lại để hiểu. Tác giả gọi là bệnh classitis

Bản TA có thêm phần bình luận từ A Tỳ Đàm nên các kinh có thêm bối cảnh hơn bản TV. Có điều có thể mình sẽ bị khép vào suy nghĩ của các luận sư chấp tác A Tỳ Đàm

Khi đọc xong, hãy nhớ đọc lại các bài kinh tự có phần highlight bằng Tiếng Anh

Matthew có vẻ có triết lý sống kiểu Kierkegaardian khi ông ấy tin rằng Chúa là đấng sáng thế nhưng mỗi con người đều có quyền tự do lựa chọn tốt hay xấu

Some claims in this book need more archeological evidence but it is very much likely those evidence don't exist anymore. If it is the case, then I want to have the most informed speculation about the life and death of this monk

Start to read "The lost chapter". It is about macro. Macro treats code as data, not text. When lexing, the input we receive is text but when parsing, we convert tokens to AST nodes. These AST nodes are different from text, are treated as data to be passed around so they are the macro system

This part is about Hash data structure and it is quite interesting. This is the first time I know that a hash key is converted into a number and its modulo will offset its position in an array. Under the hood, the hash is an array.

Adding builtin functions and some common data structure to the language. This is good to remind me how to work on things from the start to the end. Lexing/tokenizing -> Parsing to AST -> Turn things to object for evaluation

Environment is exciting! I have some guesses that variables in env will be saved in the memory and soon enough, Ball will have to talk about GC. Can't wait for the part about the GC

This is an artwork because Ball made me feel that things were so simple

Coming to conditionals. it seems like this one is harder than evaluating boolean or integer

Note: Ball has a great habit of writing tests before writing the features. I feel like we have even more test code than feature code

Each section was encapsulated well in their part of the codebase so that they don't affect one another. I feel it very easy to extend

In term of performance, executing machine code > executing bytecode > executing AST

I think I might want to rewrite the monkey programming language in JS

This part explained inner working of Pratt parser. I think the key lies in the way we structure precedence so that we can control how a token is bind to its right or left. In the book, Ball called it "right-binding power" and "left-binding power"

I finished writing Pratt parser but I still don't quite understand it

Thorten organizes this book really well, every section is the next logical step for the previous section. Each section has a test that was written in the middle and passed when the section ended. Each section feels like a fully functioning unit

Parsing with Vaughan Pratt method. Associate 2 parsing functions with each token