cccd, 2

Smart-card – thẻ chip là gì? Ngày xưa đơn giản là một cái thẻ nhớ lưu trữ thông tin, ngày nay là một cái máy tính thực sự, có CPU, RAM, ROM… được tích hợp trên một cái thẻ, chức năng là mã hóa và giải mã! Có nhiều phương pháp mã hóa khác nhau dùng được với smart-card, phổ biến là Private/Public keys (nhưng cũng có thể là những phương pháp khác). Smart-card là phương tiện để lưu trữ những cái keys – khóa này, không cho người khác đọc được! Muốn đọc phải xẻ con chip ra và kết nối vật lý với các mạch bên trong! Vì lý do đó nên từng có loại smart-card bên trong có chứa khí cháy (khi tiếp xúc với không khí), xẻ con chip ra là nó sẽ bắt cháy, hũy chip! Cũng vì đó mà đám tội phạm đã tìm cách xẻ con chip bên trong hộp chân không để nó không cháy!

Dữ liệu gởi vào cho smart-card mã hóa/giải mã, xong gởi ra trở lại, không bộc lộ key ‘B’ lưu bên trong. Nhưng do kích thước vật lý như thế nên thẻ chip chỉ có khả năng xử lý tối đa vài KB dữ liệu một lúc, không có khả năng thao tác đến MB, GB. Nên thực ra khi dùng smart-card, người ta chỉ xác minh một lần đầu, nếu xác minh đúng, các ứng dụng (các bên tham gia kênh thông tin cần mã hóa) sẽ dùng một key khác là ‘C’, và thường là xài một phương pháp mã hóa khác, để xử lý cho nhanh lẹ với lượng dữ liệu lớn, chứ không thực sự dùng đến cái key ‘B’ lưu trong chip. Cứ như thế, định kỳ key ‘C’ sẽ được thay đổi để bảo đảm an toàn, và key ‘B’ có vai trò mã hóa, bảo vệ key ‘C’ khi trao đổi, phân phối ‘C’ giữa các bên tham gia kênh thông tin!

Mã hóa Private/Public keys là gì? Bộ CA sẽ cấp cho mỗi người một mã công khai – public key ‘A’, lưu công khai trên web, ai cũng đọc được, và một mã bí mật – private key ‘B’, lưu trong smart-card – CCCD. Mã hóa Private/Public key có tính 2 chiều: dữ liệu đã được mã hóa bằng public key ‘A’ thì chỉ ai có private key ‘B’ mới giải mã được. Chiều ngược lại cũng đúng, dữ liệu đã mã hóa và có thể giải mã thành công nhờ public key ‘A’ thì xác nhận là chỉ có thể được mã hóa, gởi đi từ người có private key ‘B’ chứ không thể là ai khác! Việc này được gọi là ký – sign, và đó là lý do tại sao Private/Public keys vừa được dùng để mã hóa/giải mã (encrypt/decrypt), vừa được dùng để ký xác minh (sign, authenticate). Muốn xác minh chính chủ thì làm thế nào?

Đầu tiên ứng dụng sẽ yêu cầu thẻ chip mã hóa một thông điệp ngắn, ví dụ như “Are You ABCD?” dùng private key ‘B’, rồi gởi đến trang của BCA yêu cầu xác minh, nếu giải mã bằng public key ‘A’ trả về đúng chuỗi “Are You ABCD?” thì xác nhận đây chính là người có số CCCD là ABCD, cũng là người sở hữu khóa công khai ‘A’ và khóa bí mật ‘B’. Những điều này tương đối đơn giản, nhưng không phải ai cũng hiểu rõ ràng, ngay cả người làm trong ngành CNTT đôi khi đọc cũng thấy hoang mang! Nói ngắn gọn là: mã hóa bằng khóa ‘A’ thì chỉ là… mã hóa, nhưng mã hóa bằng khóa ‘B’ thì gọi là ký – sign, và đây là chữ ký an toàn, không ai khác ngoài người sở hữu khóa ‘B’ có khả năng như thế! Vì sao mã hóa Private/Public keys có khả năng kỳ diệu đến vậy!?

Mã hóa Private/Public keys, cụ thể là ‘phiên bản’ RSA phát minh năm 1977 bởi Ron Rivest, Adi Shamir và Leonard Adleman được xem là một thành tựu lớn trong ngành Khoa học máy tính. Đi sâu vào chi tiết thì có nhiều chuyện phức tạp, nhưng ý tưởng chung đơn giản đến nỗi hầu như ai học hết cấp 3 cũng đều có thể hiểu được! Public key ‘A’ chính là tích của 2 số nguyên tố rất lớn A = a x b, nếu chỉ biết A thì rất khó tìm ra a và b, do năng lực của các hệ thống máy tính hiện hữu không đủ để giải bài toán khai triển lũy thừa này! Mà sao lại nói nhiều về chuyện thẻ chíp và mã khóa Private/Public keys như vậy!? Ở các nước như Trung Quốc, xác minh danh tính online được xem là dịch vụ cơ bản cung cấp cho toàn dân! Ngược lại, ở một số nước như Mỹ…

Việc xác minh (ví dụ như SSL) là khá tốn kém và phải trả một số tiền hàng năm (tiền này là trả cho nhân viên đi xác minh, cũng phải trả cho cả bảo hiểm). Còn ở ta thì… không biết chắc là loại nào, các bạn biết rồi đấy, liên quan đến các vấn đề kỹ thuật thì BCA thông minh vô cùng, họ hoàn toàn không dốt chút nào! Còn khi ta cảm thấy họ “dốt”, khi mà khi ngôn từ cứ nhộn nhạo cả lên, thì chính là… họ ỡm ờ như thế! Như luật PCCC mới, muốn tìm loại vật liệu chống cháy thỏa mãn yêu cầu của BCA thì hơi khó á, mời họ cafe thì họ sẽ chỉ cho, rồi ai bán các loại vật liệu PCCC đó!? Chỉ có ở VN mới có tình trạng dùng thông tin như “hàng hóa”, nên nhiều việc nó cứ trầy trật! Trong khi nhu cầu xác minh chính danh, chính chủ là vô cùng bức thiết!

Nhưng ‘chính danh’ theo em là một cuộc chiến còn khó hơn Một mình chống lại Mafia – Bạch tuộc, nói theo ngôn ngữ bộ phim truyền hình Ý phát hành những năm 80. Vì con “bạch tuộc” này nó vô hình vô ảnh, nó không phải là một cá nhân, phe phái, một tầng lớp hay tổ chức cụ thể nào, mà nó là cái tính “đa nhân cách” của người Việt: luôn có muôn ngàn bộ mặt khác nhau, luôn rình mò la liếm, luôn “ta đây biết rồi”, cứ hở ra là giở trò lưu manh vặt! Như vụ chính chủ với số điện thoại đó, nói tới nói lui rồi đâu lại vào đấy, có làm được đâu, nhu cầu ‘ám muội’ của số đông nó quá lớn mà! Vạn sự khởi đầu nan, chỉ cần đặt được viên đá “chính danh” đầu tiên, khi nền tảng kỹ thuật đã vững rồi thì đến một lúc, người ta có muốn gian cũng không được!

CCCD, 1

Xưa đọc Hồng Lâu Mộng, thích nhất là cái câu: Trần trùi trụi đi về không vướng víu! Bây giờ đi ra đường phải “vướng” đủ thứ, nào là khóa nhà, khóa xe, nào là điện thoại, ví tiền, giấy tờ đủ cả… Trước không đánh giá đúng công nghệ NFC và CCCD, nghĩ rằng các đầu đọc NFC không đủ nhiều! Hiện tại hầu như smart phone nào cũng có đầu đọc NFC, từ iPhone 6 là đã có rồi, hầu hết các máy POS mới cũng có NFC! Tương lai khả kiến: chỉ 1 thẻ thay thế toàn bộ giấy tờ, hồ sơ, thẻ ngân hàng!

Thậm chí tiến tới mở khóa nhà, khởi động xe, mua bán, hợp đồng tất cả chỉ 1 thẻ! Thực ra thì đến đó rồi vẫn còn vướng víu nhiều lắm, chưa “trần trùi trụi” được đâu, hay có khi còn vướng hơn!? Nói xa xôi thì là vậy, nhưng nói gần gần là có thể cưỡng bức chính danh trên MXH: làm ơn làm ra luật phải xác minh nhân thân bằng CCCD trên Facebook!!! Bài báo này hiểu rất sai / đã có nhầm lẫn về sinh trắc – biometric, xác thực CCCD – thẻ chip – smartcard qua NFC không phải là sinh trắc!

tcotlt456@ctkmbbct789

Từ gần 20 năm trước, tôi đã làm việc trên những ứng dụng dùng webcam để theo dõi các cử động 3D của khuôn mặt, và phủ lên đó những lớp skin, mask, avatar, và làm hoạt hình 3D dùng DirectX mô phỏng các cử động, cảm xúc như thật của khuôn mặt! Đó là chuyện của 20 năm trước, giờ đã tiến bộ hơn không biết bao nhiêu lần! Nên qua mặt FaceID không phải là chuyện khó, chỉ cần 2, 3 tấm ảnh và một tay designer dùng Autodesk Maya loại khá là có thể phục dựng mô hình 3D khuôn mặt của một ai đó, thậm chí có thể animate cái mô hình nói năng như thật!

FaceID, phiên bản của Apple làm có thể xem là khá an toàn, là do iPhone / iPad có cảm biến LIDAR có thể dựng mô hình 3D của khuôn mặt rất chi tiết! Nhưng những loại FaceID khác, do những hãng khác hay do các bank tự làm thì chưa chắc nhé! Nói thật, tôi hoàn toàn không có lòng tin vào các loại FaceID. Nói thế này cho dễ hiểu: tôi thà đặt lòng tin vào một thứ ở trong đầu tôi (mật khẩu) là cái tôi biết, nó hiện diện vô hình, vô ảnh trong tâm trí tôi, còn hơn là đặt lòng tin vào những cái hữu hình mà ai ai cũng thấy, và vô cùng dễ làm giả!

Nên cứ để cho chúng nó, những loại thiểu năng cứ ưa tỏ ra nguy hiểm, thử dùng “độc tâm thuật” đọc mật khẩu trong đầu tôi xem có được không?! Việc tạo ra mật khẩu an toàn nhưng dễ nhớ không khó như mọi người nghĩ, dưới đây là một cái mẹo, giả sử bạn nhớ 1 câu thơ: Thiện căn ở tại lòng ta, Chữ tâm kia mới bằng ba chữ tài, thì lúc đó mật khẩu sẽ đặt ví dụ như: Tcotlt456@Ctkmbbct789, là chữ viết tắt của các từ trong câu thơ, thêm vào đó một số chữ số, chữ viết hoa hay ký tự đặc biệt tùy ý! Như thế sẽ có mật khẩu an toàn nhưng dễ nhớ!

Mà cái câu thơ tôi dùng để làm mật khẩu đó, trừ khi bạn đi đến Thư viện quốc gia, tìm đúng cuốn sách cổ đó, lật đúng trang đó, và bạn phải đọc được chữ Hán nữa, thì sẽ thấy nó nằm ở đó, chứ tìm khắp trên internet không có đâu! 😀 Nói dài dòng chút về quản lý mật khẩu, thực sự tôi cũng không có lòng tin với những thứ như LastPass, 1Password, ai đời lại lưu pass của mình ở trên cloud, có ai còn nhớ vụ rò rỉ dữ liệu của LastPass cách đây 2 năm!? Một cách khá hay là dùng công nghệ open – source đã được kiểm chứng kỹ là KeePassX để lưu mật khẩu!

Một phương pháp hiện đại phổ biến những năm gần đây là FIDO – Passkey, dùng khóa bí mật lưu trữ trên thiết bị. Đây là cách mới hứa hẹn rất tiện lợi, bạn thậm chí không cần phải nhớ gì cả! Nhưng một lần nữa, nếu thiết bị – nơi lưu passkey (usb-key, điện thoại) bị mất thì phải làm sao!? Không có giải pháp nào khác là phải có một cái nữa để dự phòng, một cái treo ở móc chìa khóa, một cái… bỏ trong két sắt ngân hàng! Nói tới nói lui, tôi chẳng tin cái gì khác ngoài cái thứ “lai vô ảnh, khứ vô hình” nằm trong đầu tôi, đó chính là… mật khẩu! 😀

faceid

Vài năm trước, có một ku “hàng xóm” chạy đến nhờ cài giúp phần mềm điện thoại! Cầm cái điện thoại Android hàng Tàu lên là mình thấy nó có vấn đề rồi, đèn camera cứ chớp nháy đều đặn, chứng tỏ là máy đang ghi hình! Mở điện thoại lên thì y như dự đoán, toàn ảnh, phim sex… Không phải là tôi không hiểu sự việc đâu nhé, cầm cái điện thoại là tôi đã biết tỏng rồi. Nhưng nói là làm, tôi vẫn giúp người ta cài phần mềm, cài xong còn bảo đừng chơi cái trò “quay lén” thiểu năng thế nữa, chẳng lừa được ai đâu! Còn chuyện chúng nó đem video về cắt ghép chỉnh sửa thế nào tôi cũng éo thèm quan tâm, chẳng chứng minh được cái gì, người ta luôn chỉ thấy điều họ muốn nhìn thấy mà thôi! Về FaceID, đây là một công nghệ rất yếu về an ninh, an toàn, và rất dễ bị qua mặt!

Vấn đề của các hệ thống ngân hàng VN hiện tại bao gồm 2 việc: #1: App và web quá kém về chất lượng, đầy lỗi, chưa có một cái ngân hàng nào ở VN tôi dùng app mà không tìm ra lỗi !!! #2: Khách hàng quản lý mật khẩu kém, và ngân hàng không có biện pháp nào hiệu quả để chấn chỉnh việc này! Nói về các phương pháp xác thực, thì mật khẩu vẫn là cái sẽ không bỏ đi được trong tương lai khả kiến, ít nhất là trong các ứng dụng đại trà! Nên không thể đi sửa một vấn đề yếu kém bằng cách dùng một công nghệ còn yếu kém hơn! Việc bùng nổ các thủ đoạn lừa đảo dùng FaceID là có thể dự đoán được! Thay vì đi sửa vấn đề cũ bằng cách tạo ra vấn đề mới, sai đâu sửa đó, sửa đâu sai đó, thì nên chăng ta quay về làm những chuyện cơ bản cho nó đúng đắn?!

Yếu quyết của việc bảo mật cá nhân, đó chính là tìm cách biến một bí mật lớn thành bí mật nhỏ, và bí mật nhỏ này trở nên dễ lưu trữ, dễ thao tác! Ví dụ như doanh nghiệp dùng USB-key lưu chữ ký số để chứng thực hợp đồng, cái USB chính là bí mật nhỏ! Hay như FaceID, TouchID cũng xem là bí mật nhỏ, có vai trò tạm thời thay thế cho mật khẩu! Tương lai xa thì tôi không dám nói, nhưng trung hạn, các loại FaceID, TouchID sẽ không có ứng dụng lớn, mà hướng đi đúng theo tôi là dùng các App để quản lý pass, ví dụ như KeePassX, Apple đang đi dần từng bước tích hợp tính năng này vào HĐH và tôi đoán là vài năm nữa, châu Âu sẽ ra luật bắt người dùng phải quản lý mật khẩu bằng app, và tìm cách “giáo dục – educate” người dùng có được thói quen tốt đó!

bình độ

Dùng augmented reality (thực tế tăng cường) làm công cụ giáo dục. Trong clip bên dưới, học sinh có thể nghịch cát trên một cái sa bàn, tha hồ nhào nặn thành các địa hình tùy ý. Máy sẽ tự động tính mô hình, chiếu và đè lên đó những đường đồng mức – đường bình độ – contour lines!

Đây có thể cũng là một ứng dụng của LIDAR, thực ra trong video xài Kinect! Đây là cách rất trực quan để hiểu về địa hình! Tôi dám cá là ngoài kia, kể cả dân làm thủy thủ, địa chính, chơi dã ngoại, etc… nhiều người còn chưa có khả năng đọc hiểu bản đồ và hình dung về bình độ!

máy tính tương tự

Những máy tính tương tự – analog computer đang dần dần trở lại, ít nhất trong một vài lĩnh vực hẹp! Thấy các bạn thanh thiếu niên ở Anh, châu Âu toàn bắt đầu học lập trình với các mạch Arduino, Raspberry pi, etc… theo tôi đây là cách tốt, học một điều gì thì nên bắt đầu từ cái đơn giản, cụ thể, đừng biến nó thành vấn đề trừu tượng, to tát, mang tính học thuật! Nhưng như thế nào là một máy tính tương tự, ngay điều này cũng không phải lúc nào cũng dễ hình dung! Giả sử ta làm một mạch điện đơn giản chỉ có biến trở R, được áp một điện thế V!

Dòng điện đi qua được hiển thị bằng đồng hồ đo là I. Vì I tương quan với V và R theo công thức: I = V / R, nên khi thay đổi V và R (bằng cách xoay các núm điều khiển), ta sẽ có được kết quả I hiển thị trên đồng hồ đo, như là kết quả của phép chia V cho R. Như thế, phép chia không được biểu diễn bằng các bít 0, 1 như hệ nhị phân, mà được biểu diễn bằng “vật chất”, tức là dòng điện! Đương nhiên các nhà giáo dục phải bỏ công suy nghĩ về những cách trình bày này, chứ nếu chỉ như câu số 6, đề Toán tuyển sinh lớp 10 tp.HCM thì vẫn còn đơn giản lắm!

Bắt đầu bằng những cái cụ thể, đơn giản, giữ liên hệ chặt chẽ với thế giới xung quanh, làm cho việc học trở thành sự ham thích lâu dài! Nếu không chúng ta chỉ biến học sinh trở thành những cái xác sống, các cỗ máy tụng bài chạy theo các số đo hư ảo, một vọng động nào đó trong “tâm” của những người “đóng vai” phụ huynh và thầy cô mà thôi! Muốn tụi nhỏ thực á, trước hết chúng ta phải tự biết cái gì là thực và phải có bản lĩnh để kiên định cái gì là thực đã! Vì không làm được nên quay sang ép con trẻ chạy theo những cái “bánh” do mình “vẽ” ra!

telecentric

Mỗi ngày biết thêm một tí, trong video là một loại ống kính rất đặc biệt – telecentric lens, vật thể nằm trong trường nhìn của nó có kích thước giống nhau dù ở xa hay gần! Tức nó không tạo ra một phép chiếu phối cảnh (perspective projection) mà kỳ lạ thay, có thể tạo ra một phép chiếu đẳng cấu (isometric projection)! Điều này có vẻ khá là khó tin nhưng phép chiếu đẳng cấu thực ra không xa lạ như mọi người nghĩ! Thậm chí tôi còn cho rằng, bản năng đầu tiên của chúng ta khi diễn họa cấu trúc một vật thể là đẳng cấu chứ không phải phối cảnh. Xem thêm về một bức tranh vẽ trong không gian đẳng cấu ở đây!

Nhưng cụ thể, ống kính này được dùng để làm gì? Nó được dùng trong các ứng dụng đo lường, kiểm định, các ứng dụng computer vision, pattern recognition, etc.. sẽ tránh được nhiều lỗi sai về kích thước, vì dù có chụp gần hay chụp xa thì kích thước vẫn y như thế, xem như đã chuẩn hóa đầu vào! Một ví dụ khác là in vi mạch bằng phương pháp quang khắc đều dùng loại ống kính này để tránh sai số! Một chút suy luận là sẽ thấy ngay, ống kính không thể nhìn thấy được vật thể to hơn nó (lớn hơn đường kính ống), nên quên chuyện dùng để chụp phong cảnh đi, chỉ dùng để chụp những vật thể nhỏ và macro mà thôi!

overclock

Thuê con server của Amazon EC2 cấu hình 32 vCPU, 64 GB RAM, so với con Aquarium-PC của mình: 36 vCPU, 64 GB RAM, con của Amazon chạy nhanh hơn một chút, vì dù sao 2 con CPU Xeon của mình là đời cũ lắm rồi. Nhưng khi ép xung – overclock từ 2.3 lên 3.8 GHz thì con Aquarium-PC cho máy của Amazon “ngửi khói” lập tức! Nhưng ép xung cũng có nghĩa là tăng nhiệt, từ 60°C nhảy lên 75°C thường trực, và cũng phải tăng tốc độ quạt, tăng tiếng ồn. Đây là điều đành phải chấp nhận thôi, hoặc là phải có giải pháp tản nhiệt tốt hơn!

Giải pháp thì có, nhưng… kỳ công, phải học thêm nhiều kỹ năng nữa, nhất là cơ khí và CNC, mà tôi hiện tại chỉ có mấy kỹ năng làm mộc quèn mà thôi! Nói chung, xác nhận là tản nhiệt dầu vẫn có thể chạy tốt với máy ép xung được, nhưng thiết kế khâu tản nhiệt phải thật sự thông minh, thật sự hiệu quả! Viết một cái script nhỏ để bật / tắt việc ép xung cho Linux, chạy script là overclock + overvolt, tăng điện thế cấp cho các thành phần máy, chạy lần nữa là tắt tính năng này đi! Mới có mấy hôm mà kỹ năng viết shell-script của mình tăng lên thấy rõ!

vtables

Trong post trước có nói về v-table, v-table là gì!? Với lập trình procedural truyền thống, gọi hàm thực chất là một lệnh hợp ngữ (Assembly), chỉ cần một lệnh JMP – Jump là nhảy ngay đến vùng nhớ chứa đoạn mã – hàm cần thực hiện! Nên gọi hàm trong ngôn ngữ C có tốc độ nhanh, nhanh đến mức không tưởng. Nhưng sự việc không đơn giản như vậy với các ngôn ngữ hướng đối tượng, như C++. Lấy ví dụ như: a->some_function(), trong trường hợp đơn giản nhất, ta cần nhảy 2 lần, lần đầu đến vùng nhớ chứa đối tượng (object) ‘a’, sau đó mới tìm trong vùng nhớ đó con trỏ đến hàm ‘some_function’ và nhảy thêm một lần nữa. Nhưng sự việc không đơn giản như vậy vì OOP có tính kế thừa, có nhiều phiên bản khác nhau của cùng một hàm ảo, những phiên bản này được chứa trong một cái bảng gọi là v-table, và việc gọi hàm lúc này bao gồm: 1. nhảy đến vùng nhớ bắt đầu đối tượng ‘a’, 2. tìm xem trong v-table của ‘a’ địa chỉ của hàm cần gọi, 3. nhảy đến vùng nhớ chính xác của hàm đó. Và cái bảng v-table này càng ngày càng lớn nếu kế thừa nhiều cấp, 20 ~ 30 cấp cũng là việc đã từng thấy! Sự việc bắt đầu trở nên phức tạp hơn nữa với những ngôn ngữ hỗ trợ đa kế thừa, đối tượng ‘a’ có thể kế thừa từ 1, 2 hay nhiều lớp khác nhau!

Lúc đó, compiler sẽ phải tạo ra nhiều v-table, và việc gọi hàm là một công cuộc tìm kiếm, tra bảng dài lê thê, thay vì chỉ một lệnh hợp ngữ JMP đơn giản! Thời gian tiêu tốn cho việc gọi hàm có thể giao động đâu đó trong khoảng 5 ~ 50% toàn bộ thời gian chạy chương trình. Đến tận ngày hôm nay, mấy chục năm sau khi các ngôn ngữ hướng đối tượng ra đời, bản chất của việc gọi hàm vẫn không đổi, và vẫn chưa có cải tiến nào mang tính cách mạng xảy ra! OOP đúng là một mô hình rõ ràng, dễ hiểu đối với lập trình viên, nhưng cực kỳ đau khổ cho những người làm compiler! OOP sinh ra, đầu tiên và trên hết là cho lập trình UI, mỗi cửa sổ, mỗi nút bấm trên UI là một đối tượng – object, nguyên thủy là vậy, về sau người ta mới mở rộng OOP từ UI sang những lĩnh vực khác! Nên những người làm ứng dụng lớn, cần tính lớp lang, cấu trúc rõ ràng, những người đó sẽ cảm thấy khó hiểu khi những coder ở mức thấp bên dưới chỉ thích procedural mà thôi! OOP đúng là rõ ràng và tiện lợi, nhưng không phải là cách tiếp cận duy nhất đối với các vấn đề lập trình, mọi việc có thể sẽ thay đổi! Và nhiều coder không hiểu vì sao một số người cố sống cố chết bám vào một số phong cách xưa cũ, vì… bản năng mách bảo rằng làm như thế mới là đúng! 🙂

rust

Những cái thuộc về ngôn ngữ, 10 năm là ít, 30 năm chưa phải là nhiều, thời gian để cho một ngôn ngữ trưởng thành, trở nên chính chắn, cẩn trọng từng câu, từng lời, bảo đảm mọi điều nói ra phải có nghĩa chính xác. Nhiều người bảo, chỉ là một tập cú pháp – syntax thôi mà, nói sao không được!? Không phải vậy, đã từng có vô số cú pháp “nhảm” bị đào thải sau vài năm, đơn cử như là C#, C# đã từng có vô số cú pháp nhảm, nhảm đến mức thiểu năng, ngu xuẩn! Và cũng đã có một số cú pháp kiểu “chữa lành – chảnh lừa” như async – await vẫn tiếp tục lừa người thêm độ chục năm, cho đến khi người ta nhận ra chẳng có lợi ích gì ngoài những câu chữ oang oang, trơn tuột! Và cũng đã có những ngôn ngữ đã dùng trên hai mươi năm nhưng rồi cuối cùng thì người ta quyết định: thôi, tốt hơn là… bỏ, không đi tiếp nữa, ví dụ như Obj-C, Flash, thậm chí có thể cả Java! Nhưng chừng đó năm cũng đủ cho người ta mường tượng ra được một ngôn ngữ “tốt” tương lai nó sẽ trông như thế nào!

Đầu tiên là nó phải giống ngôn ngữ C, điều này… đơn giản như chân lý vậy, cứ phải giống C thì mới tốt! Thứ hai, ngôn ngữ phải strong-type, có kiểu rõ ràng và kiểm tra kiểu khi biên dịch, không đợi đến khi chạy. Thứ ba, dù gọi tên gì: reference, optional, thì cũng phải làm cho người ta hiểu rằng đây là con trỏ – pointer, ở điểm này thì C thẳng thắn đến mức trần trụi! Thứ tư là quản lý bộ nhớ bằng reference counting và lần nữa, phải làm từ lúc biên dịch (compile time), đừng đợi đến đến lúc run-time, quên garbage collector và những thứ khác đi! Thứ năm là làm sao để lập trình concurrent, thread, process dễ hiểu hơn! Và cuối cùng, rất quan trọng, là dù thời đại đã đi tới mức zettabyte, nhưng một ngôn ngữ vẫn phải thật sự hiệu quả, hiểu theo nghĩa phải đếm từng bits khi cần. Xét những tiêu chí đó thì có lẽ Rust sẽ là ngôn ngữ phổ thông kế tiếp, dần thay thế C++! Đã nói rồi, phải cải tiến trước rồi hãy dùng, đừng dùng xong mới cải tiến, gọi là ++C có phải đã tốt rồi không!? 😀

Đương nhiên, đây là ngôn ngữ phổ thông (general purpose) ở mức thấp (low level), những lĩnh vực đặc thù vẫn sẽ có những ngôn ngữ riêng! Nhưng với một ngôn ngữ phổ thông cấp thấp, ưu tiên hàng đầu là performance, những thứ khác vẫn chỉ là phụ. Rust thậm chí còn chưa phải là một ngôn ngữ OOP – hướng đối tượng đúng nghĩa, theo nghĩa thường hiểu trong C++ hay Java. Nói cho đúng hơn là mô hình OOP của Rust được thiết kế ưu tiên cho performance, chứ không phải cho sự tiện lợi của người viết code! Thậm chí ta còn có thể đặt câu hỏi rằng, có thực sự cần OOP hay không, ví dụ như glibc chỉ dùng “struct” của C để biểu diễn “class” đó thôi! Nhưng qua đó cho thấy rằng, đã rất nhiều thế hệ khác nhau của C++ rồi, mà vẫn không giải quyết được bài toán vtable – gọi hàm hướng đối tượng làm sao cho hiệu quả. Nên Rust đành phải đổi một cách tiếp cận khác, mang tính chất lai lai, một nửa là OOP và nửa còn lại vẫn là functional theo kiểu C truyền thống!

Quá trình hình thành một ngôn ngữ thực chất phản ánh muôn mặt của cái cộng đồng làm ra và sử dụng nó. Đầu tiên là từ góc độ tương đối hàn lâm, ngôn ngữ phải thể hiện được tính đúng đắn và hiệu quả tính toán! Cái yếu tố “hiệu quả – performance” này là yếu tố quyết định, đôi khi nó phủ quyết (veto) tất cả những yếu tố khác. Tiếp nữa mới đến chuyện cú pháp rõ ràng, tiện lợi, thân thiện với lập trình viên. Kế đến nữa mới là chuyện tổ chức, lớp lang, các hệ thống thư viện phụ trợ để dễ dàng phát triển phần mềm! Phần lớn lập trình viên chỉ tranh luận phía trên bề mặt, cú pháp như thế này, lớp lang như thế kia, họ không hiểu rằng yếu tố tiên quyết của một ngôn ngữ là vấn đề hiệu suất (performance). Những ngôn ngữ bỏ lơ vấn đề này… đều có kết cục thê thảm!!! Như Objective-C, người ta bỏ vì nó đã trở thành một con quái vật, phức tạp đến mức vô lý, hay như một số code React – TypeScript, mới viết có cái app Hello-World là đã chiếm mất hơn 3GB đĩa cứng.