Dù bạn có nhận ra hay không, khả năng cao là mỗi ngày bạn đều đang chạm tay vào những di sản của Anders Hejlsberg. Ông chính là người đã tạo ra Turbo Pascal, Delphi, kiến trúc sư trưởng của C# và là người định hình nên TypeScript.

Trong một cuộc trò chuyện chuyên sâu gần đây, Hejlsberg đã nhìn lại sự nghiệp lẫy lừng của mình. Ông chia sẻ về cách một ngôn ngữ vận hành khi sự hào hứng ban đầu qua đi, khi các giới hạn hiệu năng xuất hiện, và cách AI đang thay đổi cuộc chơi. Những gì rút ra được không chỉ là lý thuyết, mà là một bộ quy tắc để xây dựng những hệ thống có thể tồn tại bền vững qua thời gian.

Dưới đây là 7 bài học quý giá mà mình đã chắt lọc được từ vị huyền thoại này.

1. Phản hồi nhanh quan trọng hơn bất cứ thứ gì khác

Bản năng của Hejlsberg được hình thành trong kỷ nguyên của những cỗ máy 64KB cực kỳ hạn chế. Thời đó, không có chỗ cho những thứ trừu tượng rườm rà. Ông nhớ lại: "Bạn phải giữ tất cả mọi thứ trong đầu mình".

Sự thành công của Turbo Pascal không đến từ bản thân ngôn ngữ Pascal, mà đến từ việc rút ngắn vòng lặp phản hồi (feedback loop). Viết code, biên dịch, chạy, lỗi, rồi làm lại—tất cả diễn ra tức thì mà không cần chờ đợi ổ đĩa hay công cụ nạp dữ liệu. Sự tốc độ đó chính là cách tôn trọng thời gian và sự tập trung của lập trình viên.

Nhiều thập kỷ sau, tư duy này vẫn hiện hữu trong TypeScript. Giá trị lớn nhất của TypeScript không chỉ là cú pháp, mà là bộ công cụ đi kèm: kiểm tra lỗi ngay lập tức, trả kết quả từng phần và dịch vụ ngôn ngữ phản ứng cực nhanh ngay cả trên các project khổng lồ.

Bài học ở đây rất thực tế: Công cụ nào rút ngắn được khoảng cách giữa việc "viết code" và "hiểu kết quả" sẽ giành được lòng tin. Những công cụ gây trễ, dù mạnh mẽ đến đâu, thường sẽ bị gạt sang một bên.

2. Mở rộng phần mềm đồng nghĩa với việc buông bỏ cái tôi

Khi Hejlsberg chuyển từ làm việc độc lập sang dẫn dắt các đội ngũ lớn, đặc biệt là trong những năm làm Delphi, điều khó khăn nhất với ông không phải là kỹ thuật, mà là tâm lý.

Ông chia sẻ rằng bạn phải chấp nhận việc mọi thứ được thực hiện theo cách khác với sở thích cá nhân của mình. Miễn là kết quả cuối cùng vẫn đúng, việc ép buộc mọi thứ theo ý mình là không cần thiết.

Bất kỳ hệ thống nào muốn phát triển quy mô lớn đều cần sự chuyển dịch từ "gu cá nhân" sang "kết quả chung". C# không ra đời từ một lý tưởng thuần khiết trên trang giấy trắng. Nó là kết quả của sự dung hòa giữa những yêu cầu trái ngược: Lập trình viên Visual Basic muốn sự dễ tiếp cận, dân C++ muốn sức mạnh, còn Windows thì đòi hỏi tính thực dụng.

Ngôn ngữ thành công không phải vì nó được thiết kế hoàn hảo, mà vì nó thích nghi được với cách các đội ngũ thực sự làm việc.

3. Tại sao TypeScript lại kế thừa thay vì thay thế JavaScript?

TypeScript ra đời vì JavaScript đã thành công ở một quy mô mà hiếm ngôn ngữ nào đạt tới. Khi trình duyệt trở thành môi trường thực thi đa nền tảng, các dự án bắt đầu lớn đến mức kiểu dữ liệu động (dynamic typing) không còn gánh vác nổi.

Thay vì tạo ra một ngôn ngữ hoàn toàn mới và yêu cầu mọi người từ bỏ hệ sinh thái cũ, Hejlsberg chọn cách tiếp cận thực dụng: Mở rộng JavaScript ngay tại chỗ. TypeScript chấp nhận những khiếm khuyết của JavaScript nhưng thêm vào đó khả năng quản lý các dự án quy mô lớn.

Đây là một bài học lớn về sự thỏa hiệp. Những cải tiến tôn trọng quy trình làm việc hiện có thường dễ lan tỏa hơn. Trong thực tế, sự tiến bộ có ý nghĩa thường đến từ việc làm cho hệ thống bạn đang phụ thuộc trở nên tốt hơn, thay vì cố gắng đập đi xây lại từ đầu.

4. Sự minh bạch là chìa khóa của mã nguồn mở

TypeScript không bùng nổ ngay lập tức. Những phiên bản đầu tiên dù là mã nguồn mở nhưng quá trình phát triển vẫn diễn ra trong "phòng kín".

Mọi thứ chỉ thực sự thay đổi vào năm 2014 khi dự án chuyển sang GitHub và công khai toàn bộ quá trình. Các tính năng được đề xuất qua Pull Request, các cuộc tranh luận về đánh đổi (trade-offs) được diễn ra công khai.

Điều này giúp các lập trình viên hiểu được không chỉ là "cái gì" được ra mắt, mà là "tại sao" lựa chọn đó được đưa ra. Khi quyết định trở nên minh bạch, niềm tin của cộng đồng sẽ được củng cố vững chắc.

5. Chuyển đổi trình biên dịch sang Go: Một quyết định thực dụng

Trong nhiều năm, trình biên dịch TypeScript được viết bằng chính TypeScript và chạy trên JavaScript. Điều này giúp việc thử nghiệm rất dễ dàng, nhưng theo thời gian, các giới hạn về hiệu năng bắt đầu lộ rõ. JavaScript là đơn luồng, không có bộ nhớ dùng chung (shared-memory concurrency), khiến các project lớn bị nghẽn.

Đội ngũ đã đưa ra một quyết định gây tranh cãi: Chuyển trình biên dịch sang Go.

Tại sao không phải là Rust? Theo Hejlsberg, Rust dù rất hot nhưng đòi hỏi cấu trúc dữ liệu phải thay đổi quá nhiều do các quy tắc về quyền sở hữu (ownership). Trong khi đó, Go với cơ chế Garbage Collection và cấu trúc tương đồng đã giúp đội ngũ giữ nguyên được hành vi của trình biên dịch cũ (semantic fidelity) mà vẫn mở khóa được sức mạnh đa luồng.

Đôi khi, lựa chọn có trách nhiệm nhất không phải là chọn công nghệ "xịn" nhất, mà là chọn thứ bảo toàn được hành vi hệ thống và giảm thiểu sự gián đoạn cho người dùng.

6. Trong kỷ nguyên AI, sự xác thực quan trọng hơn việc tạo code

Hejlsberg khá hoài nghi về ý tưởng xây dựng các ngôn ngữ lập trình "ưu tiên AI". Ông cho rằng các mô hình AI hoạt động tốt nhất trên các ngôn ngữ phổ biến mà chúng đã được học qua hàng tỷ dòng code như JavaScript hay Python.

Tuy nhiên, AI đang thay đổi mối quan hệ giữa lập trình viên và công cụ. Thay vì bạn viết code và công cụ hỗ trợ, giờ đây AI viết code và bạn là người giám sát. Trong thế giới đó, giá trị của các công cụ kiểm tra kiểu (type checkers) không phải là sự sáng tạo, mà là sự chính xác.

Rủi ro lớn nhất không phải là AI tạo ra code dở, mà là nó tạo ra code trông có vẻ đúng nhưng thực chất lại sai lệch với thực tế của project. Những hệ thống kiểu dữ liệu mạnh mẽ sẽ đóng vai trò là "lan can bảo vệ", giúp chúng ta kiểm chứng và chỉnh sửa code AI một cách hiệu quả thay vì tin tưởng nó một cách mù quáng.

7. Giá trị của ký ức tập thể

Một điểm mình thấy rất tâm đắc là cách Hejlsberg nói về "trí nhớ của tổ chức". Với 12 năm lịch sử trên GitHub, mọi cuộc thảo luận, mọi quyết định bị từ chối và những đánh đổi đều có thể tìm kiếm được.

Bối cảnh (context) không bị mất đi trong các email cá nhân hay hệ thống nội bộ. Với những người mới gia nhập dự án sau này, việc hiểu được "tại sao hệ thống lại trở nên như thế này" đôi khi còn quan trọng hơn cả việc đọc hiểu chính mã nguồn đó.

Lời kết

Xuyên suốt 40 năm thiết kế ngôn ngữ của Anders Hejlsberg, có những mô típ luôn lặp lại: Vòng lặp phản hồi nhanh quan trọng hơn sự hoa mỹ; sự tương thích quan trọng hơn sự thuần khiết về kiến trúc; và sự minh bạch tạo nên niềm tin.

Hy vọng những chia sẻ này từ một "lão làng" trong ngành sẽ giúp bạn có thêm góc nhìn mới cho hành trình phát triển phần mềm của riêng mình.

Bạn nghĩ sao về quan điểm chuyển sang Go thay vì Rust của đội ngũ TypeScript? Hãy chia sẻ cùng mình ở phần bình luận nhé!

Nguồn: 7 learnings from Anders Hejlsberg: The architect behind C# and TypeScript