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 “taxi-ing” 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 đơn giản 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 khi cho rằng nếu tôi là sync, thì những code viết ra trước đây là async! Đây là kiểu 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 production – môi trường chạy thật 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!? :(

For…loop… ăn, ngủ, code, đạp xe, chơi với mèo… và cứ thế lặp lại! Nhàm chán, đơn điệu, nhưng cũng phải tập lại tính kỷ luật một tí! Ku Tom có chỗ nằm mới, cứ thế leo lên nằm ngủ, đôi khi lười biếng và lơ đãng nhìn xuống xem mình coding! Chút suy nghĩ về vòng “for”… theo tôi, luôn có cái gọi là “khoảng cách thế hệ – generation gap” bên trong thế giới coder, chiều sâu suy nghĩ, độ chính chắn hoàn toàn khác xa nhau! Từ xưa, như với ngôn ngữ C, người ta điều khiển “for” bằng một biến số nguyên “i”, chỉ đơn giản là như thế!

Có nhiều phép toán số học có thể làm được với “i”, đây mới là điều quan trọng nhất! Thế nhưng các ngôn ngữ mới không chịu, cứ phải đẻ ra cái “for in stride”, rồi những thao tác lặp phức tạp trở nên rất khó thực hiện! Chỉ đọc spec một ngôn ngữ, ví dụ như Swift, tôi có thể hiểu được khá rõ độ sâu, độ chính chắn trong suy nghĩ của tác giả! Mấy người “sáng chế” ra các ngôn ngữ mới này cũng chỉ là những coder bình thường như chúng ta mà thôi, chưa đạt đến tầm như của Donald Knuth, Edsger W. Dijkstra, Robert Sedgewick, etc… ngày xưa đâu!

I started with Turbo-C on DOS, then move on to different dialects of the C language: Watcom C, Borland C++, C++, glibC, Obj-C… For me, the most important thing in programming is… crashes. It crashes right away to tell you that you’ve done something wrong! It crashes when you access a null pointer, it crashes when you use an API the wrong way, it crashes when you allocate an infeasible amount of memory, it crashes when you access a dangling pointer referencing to an object which has gone out of scope, just because you can’t track on the life-cycle of that object. It doesn’t even throw an exception and try going on until the situation is unmanageable. Simply put, there’s NO exception, you’re punished immediately, as soon as you’ve done something wrong!

I strongly advocate the use of ARC for memory management, in fact, I would call it the most brilliant feature of the Obj-C language for the last 25 years or so, ARC makes life much more easier. But I also advocate the use of crashes as a “graceful” way to tell that you’ve done something wrong with the deallocated blocks. It crashes right away when you allocate an unbearable amount of memory so that you would know that your algorithms and data – structures are not efficient enough, and you will need to improve, to do tuning, optimization! For me, modern languages are good and friendly, the down side is that it’s also too friendly to the developers, without punishments, how can the devs’ skills could be improved!

Thus, by the interacting between you – the coder and the computer & compiler combination, the reward – punishment model will help greatly boost the devs’ skills over time, and help producing good code. There’re huge differences between an experienced programmer who write good code, and foresee possibilities of bugs, and a novice one who only try to make it… just run. I really want to emphasize here, that the “reward – punishment” model of programming is what made a good programmer! Also by learning to handle memory problems by yourself give you opportunities to follow and understand the life cycles of objects, of memory blocks, understand the precise flows of code, understand the cost-and-benefits of each coding approaches.