Lâu lắm rồi mới quay trở lại với HĐH ưa thích, Debian Linux, đương nhiên không thể mượt mà, bóng bẩy như MacOS được, nhưng cũng có những điều thú vị riêng mà những HĐH khác không thể nào có được! Về lập trình, tôi vẫn rất thích Linux ở cái “performance – hiệu suất” của nó, xử lý files, gởi nhận dữ liệu qua mạng, giữa các máy với nhau nhanh như chớp, xử lý tiến trình, tiểu trình cho các hệ thống client / server rất hiệu quả! Ngoài ra thì thích phá gì thì phá, tha hồ thay đổi tùy thích. Đầu tiên là build gói CoreCtrl từ source (do Debian vẫn chưa hỗ trợ gói này trong repo chính thức). Open-source vẫn có những cái rắc rối, phiền phức riêng của nó, mà phổ biến là code thường lỗi, không build được, phải sửa một hồi rồi make, make install, etc…

Chạy CoreCtrl kiểm tra nhiệt độ CPU, GPU, đếm số vòng quay của các quạt tản nhiệt! Rồi dùng phần mềm để disable luôn cái quạt, tháo ra dẹp qua bên, cái card màn hình giờ chỉ còn tản nhiệt, không còn phần nào chuyển động (no moving part)! Phần vì không có nhu cầu xài đồ họa mạnh nên nhiệt độ GPU hiếm khi vượt quá 50C, phần là muốn xác minh cái “tin đồn”: nếu tháo quạt, hệ thống sẽ tự động tắt card màn hình nếu bị quá nhiệt! Hình như “tin đồn” không được đúng cho lắm, ít ra là trên Linux! Tiếp đến, build gói OpenRGB cũng từ source để điều khiển mấy cái đèn LED trang trí, LED bàn phím, có hàng chục “kịch bản chiếu sáng” khác nhau: đổi màu, đổi độ sáng, nhấp nháy, tất cả đã được lập trình sẵn, chỉ cần load lên và chạy!

Đã hơn 15 năm không xài PC, chỉ xài Mac, nay thử quay lại xem sao, đem về một con con Dual Xeon. Lần cuối cùng tự ráp để xài một con PC là cách đây cỡ 25 năm, lúc đó hãy còn là bộ VXL Pentium II, riêng con CPU là đã to gấp đôi cái điện thoại iPhone 7 á! Tôi còn nhớ rõ thời đó, máy chủ của khoa KNTN, đại học KHTN chạy song song 2 con VXL Pentium III, phải 4 người khiêng 4 góc mới đem đi được! Đem Dual Xeon so với con MacMini M2Pro, đáng ngạc nhiên là phần mềm PassMark cho điểm 2 hệ thống xêm xêm nhau, đều khoảng 23000. Về hiệu năng tính toán số nguyên, số thực thuần túy thì DualXeon vượt trội, nhưng M2 hơn ở khá nhiều khoản tính toán khác!

Đương nhiên so sánh vậy chả công bằng chút nào, một bên chỉ là hệ thống “mini”, bé có chút xíu và chỉ xài một con CPU. Còn bên kia là hệ thống “lớn”, dùng đến 2 CPU loại mạnh chạy song song với nhau, chưa kể lượng RAM nhiều hơn gấp 4 lần! Hai cái tản nhiệt nước, 7 cái quạt gió cỡ lớn, toàn bộ cái máy nó hú như máy bay đang chạy “taxiing” vậy! Ai xài Mac thì sẽ thấy kích thước nó vừa nhỏ xinh, vừa mát mẻ, chạy hầu như không phát ra tiếng động! Haizza, còn cái kia to như khủng long, hú cũng gần như động cơ phản lực! Đem so PC với Mac cũng như so phim VN với phim TQ vậy: ăn nói oang oang, thô lỗ, bỗ bã, hàm hồ, thiếu hẳn sự ý tứ, tinh tế!

Lâu rồi mới trở về những “bài tập lập trình” cơ bản, như thời ĐH, những vấn đề thú vị, nhưng cần sự tập trung cao và kéo dài khi coding. Bài toán như sau: hầu hết các hệ điều hành đều cung cấp cho người dùng hệ thống tập tin (file), các thư mục lồng nhau (nested) và chứa trong đó những thư mục con, tạo thành một hình cây (tree)! Nhưng đó là với người dùng, thực chất, hệ thống tổ chức bên dưới dạng flat – list, một danh sách phẳng, hiểu đơn giản là một cái mảng lớn không phân cấp chứa tất cả các tập tin! Mỗi tập tin ở mức quản lý thấp của HĐH chỉ có số (inode) chứ không có tên, đọc từ đầu đến cuối đĩa chỉ là cái mảng một chiều có rất nhiều phần tử. Tiếp theo đó, ở lớp (layer) kế trên, người ta mới đề cập đến tên của tập tin (file name, path).

Ví dụ như: ~/Downloads/aaa.pdf hay /System/Library/CoreServices… Từ những đường dẫn đầy đủ này truy vấn từng cấp, ra được số inode và tìm đến các khối lưu trữ thực bên dưới! Nhưng lưu và tìm thế nào cho nhanh, không phải duyệt cái mảng quá lớn? Tên tập tin, đường dẫn thư mục thực chất được tổ chức thành dạng cây AVL – AVL tree! Độ phức tạp của thuật toán tìm kiếm sẽ giảm từ O(n) xuống thành O(log(n)). Ngồi đọc lại bài xuất bản năm 1962 của hai nhà bác học Liên Xô: Georgy Adelson-Velsky và Evgenii Landis, lâu lắm rồi mới được trở lại code C đúng nghĩa! Đơn giản là tự ra bài tập để làm cho vui, tìm lại cái cảm giác lập trình chân chính, thực sự, sau nhiều năm tháng toàn code lảm nhảm Swift, Python, etc…

Weekend humor, picture created by me using GIMP! About programming languages, just for fun, don’t take it too literally and seriously! There’re a lot, a lot more stuffs like JavaScript. It reminds me just that: what users really want is a smoothly-run “program”, not some mis-reading, mis-interpreted “scripts”!

L
âu lắm mới có hứng nói về vấn đề kỹ thuật, lần này mạnh dạn đưa ra một nhận định: async/await là một trò bịp lớn trong các ngôn ngữ lập trình – async/await is just a big scam in programming languages! Mọi người chờ 5, 10 năm nữa xem nhận định này đúng không nhé! Lâu về trước có làm một chút với async/await trên C# và JavaScript, là đã thấy nó không được đúng lắm! Gần đây làm với async/await trên Swift lại thấy càng không đúng! Những cái về threading – process – synchronization – tiến trình, tiểu trình và đồng bộ hóa là phải đọc giữa các dòng chữ – read between the lines! Còn cái mindset của những người làm ra async/await nó giống kiểu bắt chết vào ngôn từ hình thức, họ chấp vào ngôn từ bề mặt!

Async/await chỉ là vấn đề, và cũng chỉ là giải pháp của… riêng JavaScript! Khởi thuỷ xa xưa, JavaScript chỉ được phép có đúng một thread, nên để không block thread này thì họ đã tìm cách offload các hàm sang thread background của hệ thống, và vì làm việc này theo kiểu tuỳ tiện nên phải sinh ra cái async/await để “đánh dấu”, thuận tiện hơn cho việc đồng bộ hoá! Vấn đề này là của riêng JavaScript, các ngôn ngữ khác… không thấy có! Async/await khi đem một cách khiên cưỡng sang những ngôn ngữ khác không tạo ra lợi ích nào đáng kể, ngược lại làm phức tạp hoá vấn đề và hiệu suất – performance… rất tệ! Những newbie chưa hiểu sự phức tạp của hệ thống mới thần thánh hoá và cho rằng async/await là cái gì đó siêu việt!

Async/await nó mang cái mindset 2 threads: foreground & background, xuất phát từ hạn chế chỉ được phép có một thread của JavaScript! Với những ngôn ngữ như C, C++, Obj-C, etc… thì bản thân cái không gian tính toán nó đã là n-thread, từ ngàn xưa là đã dã man, phức tạp và đa năng rồi! Chuyện với async/await không biết phải nói làm sao… nó giống như câu: “màn hình cong (curved monitor) có rất nhiều vấn đề, mà vấn đề đầu tiên là nó… cong”! Tương tự vậy, async/await không đúng đầu tiên là ở chính 2 từ khoá đó, một kiểu chấp niệm vào hình thức, cho rằng nếu tôi là sync, thì những code viết ra trước đây là async! Đây là chấp niệm, thực ra code block bản thân nó không sync, cũng chẳng async, là do cách xài mà thôi!

Tại sao nói async/await là vấn đề của riêng JavaScript!? Với các ngôn ngữ khác, tuyệt đại đa số các lời gọi hàm hệ thống là sync về mặt bản chất, điều này nhằm giúp cho coder hiểu rõ cái cost – chi phí gọi hàm! Chỉ một số ít hàm hệ thống là async, và coder phải hiểu rõ điều đó khi sử dụng! Trong trường hợp có nhu cầu không block main thread thì họ sẽ chạy code block trong một thread khác, chuyện này y hệt như vai trò của Task vậy! Nên async/await không đưa ra được một điều gì mới, càng không phải là cách giải quyết vấn đề mới! Nó đơn giản là cách vá lỗi lầm cũ của quá khứ, bằng cách đặt ra một cú pháp, và cú pháp này… rất thừa thải trong nhiều ngôn ngữ khác ngoài JavaScript, thêm phức tạp mà không giải quyết được chuyện gì!

Nên async/await là vấn đề của riêng JavaScript, thứ mà một lập trình viên nghiêm chỉnh còn… chưa xem là ngôn ngữ lập trình! Khi đem sang các ngôn ngữ khác, bản thân người thiết kế tính năng này chắc chắn là không hiểu được cơ bản về điều phối tiến trình, tiểu trình, đặt ra một thứ hoàn toàn không cần thiết! Async/wait hoàn toàn không phải là công cụ dùng để điều phối tiểu trình, tuyệt đối không có tính năng thay thế mutex, semaphore, critical sections, locks, etc… và do đó không thể dùng để giải các bài toán đồng bộ phức tạp như Producer/Consumer, Dining Philosophers, Sleeping Barber, etc… Đừng nhầm lẫn giữa một cú pháp “lảm nhảm” với các bài toán đồng bộ vốn rất phức tạp, và nên đầu tư thời gian học về căn bản!

Có một dạo thời còn đại học, bị ám ảnh với những thứ 3D, nên tự đi viết một cái 3D-engine: phối cảnh vật thể trong không gian 3 chiều! Mà tôi biết thừa là chỉ làm cho vui, chứ những engine 3D đã có như OpenGL, DirectX nó làm tốt hơn tôi một triệu lần! Nhưng xem như bài tập, cứ làm thử xem sao! Nhờ đó mà đọc qua các lý thuyết về một tá các phép chiếu (projection) khác nhau, ôn lại một mớ Toán vector, ma trận. Cái engine tôi viết ra hiển thị tốt các đối tượng 3D phức tạp, nhưng chưa có đổ bóng hay các thao tác advanced khác!

Bạn bè cùng lứa là toàn dùng ngôn ngữ và công nghệ cấp cao, kéo thả, cắt dán các kiểu rồi, còn tôi vẫn lập trình DOS với Turbo C++ sơ đẳng như thế! Và cực kỳ ghét những câu chữ bóng bẫy, trơn tuột (catching, slippery phrases) kiểu: Don’t reinvent the wheel – Đừng phát minh lại cái bánh xe! Không làm được cái đơn giản, sao làm được cái phức tạp!? Mà điều đó thấy rất rõ ở những coder trẻ: cái gì cũng biết, mà không làm được những điều đơn giản! Mà những điều đơn giản nó không có đao to búa lớn, không huênh hoang chữ nghĩa!

Và thế rồi đi chê Trung Quốc toàn chỉ biết copy (mà mình thì đến copy vẫn chưa làm được)! Copy hay không không quan trọng, quan trọng là bắt đầu với việc đơn giản đã! Và họ cứ “trường kỳ copy” như thế hàng chục năm, trước khi có được khả năng sáng tạo cái mới! Cũng như hoạ sĩ học vẽ thôi, trước khi tạo thành phong cách, thành danh thì hàng chục năm trước, họ đã dày công học hỏi, copy hết phong cách này đến xì-tai khác! Tự dưng mới sinh ra đã thành phong cách, đã thành sáng tạo, đã có kết quả thì chỉ có “cuội VN” thôi!

Nhưng nói điều đơn giản, làm điều cơ bản, ở cái thời gian và không gian này, có khi bị coi là ngu và ngố á! Đồ dở người, đồ hâm hấp, cứ mấy cái đơn giản, cơ bản đem ra nói hoài, chả có cái gì “cao siêu” cả, toàn cộng trừ nhân chia, toán hình toán số cơ bản thôi, xem có làm được không đã! Bữa xài cái app trả tiền điện nước, mới thấy mấy cái dòng tô đỏ bên dưới, nào là “Simulate”, nào là “Giả lập”, đem cả code test vào trong production như thế, có mỗi một dòng “#if DEBUG” cũng không thêm vào được, chả hiểu làm gì để ăn!? :(