â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…

gày xưa mua một cái thẻ cào điện thoại, nạp sai số là sẽ không nhận được tiền! Làm sao để nó biết số nhập sai hay đúng, về mặt thuật toán cũng không phải là quá đơn giản, đầu tiên sẽ dùng một dạng thuật toán Luhn để kiểm tra xem việc nhập dãy số có đúng hay không! Trong dãy số, thường là số cuối cùng đóng vai trò check – digit! Ngày nay, Luhn và các phiên bản phát triển nâng cao của nó được dùng ở khắp mọi nơi: trên số passport, số CCCD, số mã vạch, số thẻ ngân hàng…

Trên hầu hết tất cả các dạng mã định danh khác như ISIN (International security identification number). Nhưng cần phân biệt rõ đây không phải là một phương pháp bảo mật, chỉ là thủ thuật kiểm tra để phát hiện việc nhập liệu là đúng hay sai! Cơ bản là giờ mạng internet đã rất nhanh, kiểm tra không quá mất thời gian, nhưng ngày xưa khi mạng còn chậm, cần phải kiểm tra ngay tại phía client (web browser, máy POS) để giúp phát hiện lỗi từ sớm mà không cần phải truy vấn server!

eekend 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”! 😀


â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!

ó 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!? 🙁

or…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! 🙂