Sunday, September 13, 2020

06 - Môn tin học lớp 11 nên dạy các em ngôn ngữ lập trình nào?

Mới đây, Bộ GD&ĐT đã ban hành Công văn hướng dẫn và điều chỉnh nội dung giảng dạy môn tin học cấp THCS, THPT [1]. Đáng chú ý là môn tin học lớp 11 sẽ loại bỏ, không đưa Pascal vào chương trình giảng dạy. Đặc biệt, từ năm học 2021-2022 các đơn vị chỉ lựa chọn một trong các Ngôn ngữ lập trình: Python, C hoặc C++ để dạy trong chương trình môn Tin học lớp 11. Nếu được lựa chọn một ngôn ngữ lập trình (NNLT) để dạy cho các em, tôi sẽ không chọn Pascal như quy định của Bộ GDĐT và tôi cũng không chọn cả C, C++ và Python mà sẽ lựa chọn Visual Basic for Application. 

Việc đầu tiên chúng ta cần thống nhất là đưa ra các tiêu chí để lựa chọn NNLT. Các tiêu chỉ để lựa chọn dường như cũng chưa được xác định rõ trong các văn bản của Bộ GDĐT. Theo cá nhân tôi thì bộ tiêu chí cho NNLT có thể là:

  • (A1) Là một NNLT đơn giản, trong sáng, không quá phức tạp để giảm tải thời gian học cho các em.
  • (A2) Minh họa và thể hiện được tư duy lập trình cơ bản, có thể giúp các em lập trình giải được các bài toán có trong chương trình phổ thông. Ví dụ như chương trình giải phương trình bậc 2.
  • (A3) Công cụ lập trình đơn giản, dễ cài đặt, trực quan dễ sử dụng.
  • (A4) Dễ dàng tạo ra các ứng dụng có giao diện thân thiện.
  • (A5) Có tính ứng dụng cao, có thể được áp dụng cho nhiều ngành, không chỉ riêng cho CNTT.
  • (A6) Có tính kế thừa, được sử dụng tiếp cho các bậc học cao hơn như lớp 12, đại học, và có thể vẫn được sử dụng trong công việc về sau.

Để đưa ra một lựa chọn, tôi cũng căn cứ vào kinh nghiệm đã có với các NNLT của bản thân, cụ thê tôi đã từng: 

  • Lập trình Turbo Pascal từ năm 1988 với phần mềm tính kết cấu bằng phương pháp phần tử hữu hạn (1988-1990), phần mềm in mã nguồn Pascal Listing (1989)...
  • Lập trình C, C++ từ năm 1990 với các sản phẩm: Bộ biên dịch ngược và xuôi cho Chip Z80, 8085, Vietkey2000, Vietkey Linux...
  • Lập trình Python từ năm 1999-2008, phát triển bộ cài đặt Anaconda cho Vietkey Linux...
  • Lập trình Basic từ năm 1986 với chương trình quy hoạc tuyến tính (Linear Programming), Phần tử hữu hạn (1988), Visual Basic for Application (VBA) cho nhiều sản phẩm Vietkey Office (kiểm tra chính tả tiếng Việt, sắp xếp tiếng việt, chuyển mã văn bản...) năm 1998-2003, chấm điểm khiêu vũ thể thao VKSkating từ năm 2007-2018 và nhiều phần mềm khác.
Trên đây là 4 ngôn ngữ được đề cập đến trong bài này, tôi sẽ không kể đến những kinh nghiệm của bản thân với các ngôn ngữ khác như: FORTRAN, Assembly, Prolog, C#, Java, Perl, PHP, Dart, Golang, Rust, HTML/CSS, LaTeX, Mapple... Nhưng những trải nghiệm từ các NNLT này cũng giúp cho quá trình đánh giá các tiêu chí lựa chọn.

Sau đây là một số phân tích về các NNLT được đề cập đến trong bài:

(Turbo) Pascal

Là một NNLT dạng biên dịch (trước khi chạy chương trình thì cần phải dịch từ NNLT ra mã máy), do Niklaus Wirth thiết kế vào năm 1970, đã có một thời gian Pascal rất phổ biến với phiên bản Turbo Pascal của hãng Borland. Pascal là một ngôn ngữ rõ ràng và trong sáng, ít dùng các ký hiệu tắt như C mà chủ yếu dùng các từ khóa (keyword) bằng tiếng Anh. Pascal có con trỏ (truy tiếp trực tiếp vào ô nhớ vật lý) nhưng hầu như không phải sử dụng đến nên nó ít bị lỗi hơn C. Pascal thành công bởi hãng Borland đã làm ra bộ công cụ soạn thảo và biên dịch Pascal và cả C một cách rất tuyệt vời. Turbo Pascal được phát triển bởi Anders Hejlsberg, một siêu thủ về trình biên dịch mà sau này Microsoft cũng phải mua lại ông về để phát triển nền tảng .NET. Đã một thời tôi từng rất ngưỡng mộ và yêu thích Delphi một nền tảng phát triển ứng dụng cho MS Windows, .NET và cả Linux, ngôn ngữ sử dụng chính của Delphi chính là Pascal. Các app viết bởi Delphi chạy rất nhay và gọn gàng, tất cả các thư viện liên quan đến chương trình đều được gói vào 1 file EXE duy nhất, không cần phải cài đặt, chỉ copy là chạy và nó không bị phụ thuộc vào các phiên bản của các thư viện DLL (Dynamic Link Library) giống như các app được phát triển bởi Visual Studio, và tránh được các lỗi version giống hệt tình trạng trên Linux, mà trong giới lập trình vẫn gọi là "Địa ngục DLL". Đáng tiếc là đến năm 2009, Borland đã bị mua bởi Micro Focus International plc. và không còn xuất hiện trên thị trường, các công cụ phát triển cho Pascal cũng vì thế mà tàn lụi.

Cho đến trước tháng 8 năm nay, Turbo Pascal 7.0 (TPascal) vẫn được dạy ở các trường phổ thông trung học ở Việt Nam trong môi trường DOS hay Command Prompt của Windows. Microsoft càng ngày càng hạn chế chế độ DOS do đó cài đặt và sử dụng TPascal càng ngày càng khó khăn, các ứng dụng được phát triển bởi TPascal cũng là các chương trình chạy trên DOS nên cũng không được hỗ trợ do đó các yêu cầu A3, A4, A5, A6 đều không đáp ứng.

Tóm lại TPascal chỉ có thể được dùng để minh họa cho thuật toán (A1, A2) mà thôi, tính ứng dụng của nó rất thấp và nó cũng không có tính kế thừa, sau này ra đời gần như không có ai sử dụng nó trong thực tế.

C, C++

C là ngôn ngữ được phát triển bởi Dennis Ritchie (Bell Labs) từ năm 1972, là một ngôn ngữ khá súc tích và rất mạnh, nó có thể can thiệp sâu vào kiến trúc phần cứng, cụ thể là có con trỏ có thể truy cập trực tiếp vào các vùng nhớ, cấp phát động và giải phóng động các vùng nhớ rất linh hoạt nhưng cũng vì đây là con dao sắc nên cũng rất dễ gây lỗi, các lỗi tràn bộ đệm chủ yếu đến từ ngôn ngữ C. Cũng có nhiều năm tôi sử dụng ngôn ngữ C để phát triển hàng chục ứng dụng khác nhau, lần gần nhất là năm 2010 với dự án 10 triệu dòng lệnh C sửa nhân Linux Kernel để biến đổi Linux thành hệ điều hành thời gian thực. C, C++ rất mạnh và được sử dụng hầu hết trong các hệ thống lớn như hệ điều hành, các thiết bị nhúng IoT và cho đến tháng 9/2020, ngôn ngữ C vẫn được được xếp thứ 1 với chiếm gần 16% trong tổng các NNLT (Hình 1).

Hình 1: Xếp hạng các NNLT tháng 9/2020 trên https://www.tiobe.com/tiobe-index/
 
Ngôn ngữ C nói chung là khó hơn Pascal nhiều và vì nó cũng súc tích nên không được sáng sủa và mạch lạc như Pascal, nếu dạy trong môi trường DOS thì C cũng gặp phải đa số các nhược điểm như đã kể trên với TPascal, tức tính ứng dụng không cao và tính kế thừa cũng không cao. Để có tính ứng dụng và độ thân thiện tốt hơn thì nên học C# của Microsoft, nhưng có nhược điểm là bộ biên dịch Visual Studio rất nặng, cài bản miễn phí community cũng mất đến hơn 15G dung lượng đĩa cứng, bản thương mại còn có giá thành rất cao nữa.

Tóm lại C, C++ khó hơn TPascal do đó học nó có khi còn thêm tải cho các em học sinh, cài đặt khó với máy cấu hình thấp nếu dùng C#, tính kế thừa cũng không cao và chủ yếu thích hợp với các em sau này có định hướng theo ngành Công nghệ thông tin.

Python

Ngôn ngữ này được tạo bởi  Guido van Rossum năm 1991, Python được thiết kế với triết lý là ngôn ngữ dễ đọc nhất, đơn giản nhất có thể, hạn chế các ký hiệu "{};...", tối giản các quy ước một cách tối đa do đó mã nguồn thường ít dòng lệnh hơn so với C, C++ và các ngôn ngữ khác. Python khác với C,C++ là ngôn ngữ thông dịch dạng script, không được dịch trước ra mã máy, nên nó chậm hơn C++ từ 200-600 lần [2], thậm chí cũng chậm hơn cả VBA 3-6 lần [3]. bộ nhớ cũng tốn hơn do dùng kiểu biến động (dynamic typed). 

Python được thiết kế như là một NNLT phổ quát, có thể được sử dụng cho nhiều lĩnh vực khác nhau, tuy nhiên nó đa phần được sử dụng cho:
  • AI (Machine Learning);
  • Phân tích (data-analysts), xử lý và hiển thị dữ liệu;
  • Được sử dụng với một số framework để làm Back-end web development.
Python do có hiệu năng tính toán khá chậm so với C++ và một số NNLT biên dịch khác như Rust, Golang nên các bộ thư viện và framework đòi hỏi tính toán nhiều thì thường được viết bằng C++ và được wrap lại để sử dụng trong môi trường Python mà ít khi được viết hoàn toàn bằng Python. Đa phần các framework cho AI như Tensorflow, Pytorch, Caffe2 đều được viết bằng C++. Lợi thế lớn nhất của Python chính là cộng động người sử dụng Python rất lớn nên có nhiều người tham gia phát triển các thư viện Python vì thế các bộ thư viện nguồn mở của Python rất phong phú và gần như tìm gì cũng có sẵn và cũng vì thế có sự support kỹ thuật tốt cho những người mới học.

Cũng vì có cộng động Python rộng lớn mà đa phần các chuyên IT và các thầy dạy IT đều thiên về xu thế sẽ thay Pascal bằng Python. Tuy nhiên tôi thì lại có ý kiến khác: Dạy Python có khá nhiều bất cập đối với học sinh lớp 11:
  • Python là ngôn ngữ đa năng, tính ứng dụng khá cao, tuy nhiên điều này chỉ đúng với các em sau này định hướng theo ngành IT, Computer Science, hay Data Science. Các ngành khác rất ít có điều kiện dùng và nhất là các em sau này chỉ dùng ở mức văn phòng, soạn thảo văn bản MS Word và quản lý dữ liệu trên Excel là chủ yếu.
  • Python dễ đọc nhưng không dễ hơn nhiều so với Pascal. Pascal rất trong sáng, so với Python thì chỉ rườm ra hơn, nhưng Python lại dòi hỏi phải học nhiều thứ hơn. Đối với kiểu tổ chức dữ liệu, Pascal chủ yếu chỉ có mảng, bảng, câu trúc thôi thì Python đưa ra nhiều khái niệm của NNLT hiện đại như List, Tuble, Set, Dictionary, nhiều kiểu na ná cách sử dụng nên cũng dễ gây nhầm lẫn. Python còn có thêm các khái niệm lập trình hướng đối tượng, lập trình hàm, và cả những khái niệm hiện đại như lambda khá là trừu tượng với các em học sinh, đó là chưa kể nếu chỉ nói đến các thư viện chuẩn (Standard Libs) thì Python có cả một rừng luôn. Như vậy so với Pascal thì Python đọc cũng không dễ hơn là bao nhưng khối lượng kiến thức để làm chủ nó lại vô cùng nhiều, dễ gây hoang mang cho học sinh. Học mãi không biết đến bao giờ mới biết được hết cơ bản. Vô hình chung Bộ đang muốn giảm tải thì có khi lại chất thêm nhiều tải hơn. Tránh vỏ dưa lại gặp vỏ dửa.
  • Điểm A3: cài đặt và sử dụng có dễ dàng không? Python cài đặt cũng không đơn giản hơn TPascal, cài đặt ở chế độ Terminal, nguyên bản khi chạy cũng ở chế độ Terminal. Tuy rằng người dùng có thể lựa chọn các công cụ phát triển (IDE) như Visual Code, Visual Studio, Pycharm...Nhiều lựa chọn công cụ phát triển và cả các thư viện thì cũng tốt nhưng đôi khi lại gây rối, phân mảnh, không được thống nhất từ triêt lý đến công cụ, điều này sẽ khó cho việc biên soạn giáo trình thống nhất, và các chuyên gia để hô trợ cũng đòi hỏi phải biết nhiều công cụ cho một ngôn ngữ hơn.
  • Do Python không phải là NNLT cho Front-End nên xây dựng các app có giao diện người dùng UI/UX sẽ gặp khó khăn, hầu như không có các công cụ trực quan kéo thả. Mặc dù có gói tkinter để làm giao diện nhưng khá là thô sơ và khó sử dụng. Cao cấp hơn thì cần các framework như PyQt, WxPython, PyGtk...thì lại phải học thêm rất nhiều về các triết lý và nền tảng Qt, WxWork, Gtk.. Để có một report đẹp như các report như Excel có thể làm được thì lại cần biểu diễn dữ liệu trên Web khi đó lại cần học một loạt các công cụ: web framework, basic Python, Pandas, SQL, command line, git, và code deployment. Nói chung là nhiêu khê và cần phải học cũng khá nhiều.
  • Nếu gói gọn chương trình chỉ có input và output từ bàn phím và bắn kết quả ra màn hình như ở chế độ DOS thôi thì chẳng khác gì TPascal. Học sinh học Python sẽ chẳng thấy hứng thú gì, vì không tạo ra được các app có giao diện đẹp, cute, thân thiện và tính ứng dụng cao.
  • Về tính kế thừa (A6), Python không có liên quan gì đến các chương trình của năm trước cũng như năm học sau của các em, tương tự như vậy đối với C, C++.
Tóm lại Python sẽ phù hợp với các em học sinh sau này có định hướng học theo ngành IT cũng giống như với C, C++, và nếu để nắm bắt được cơ bản Python thì dù dễ đọc nhưng học sinh sẽ phải học nhiều khái niệm mới của NNLT hiện đại, như thế thì lại thành tăng tải chứ không hề giảm tải. Ngoài ra Python cơ bản không có hoặc gần như không có các tính năng trực quan, kéo thả, và thường phải làm việc với chế độ dòng lệnh tối tăm không khác gì Pascal.

VBA (Visual Basic for Application)

VBA được phát triển dựa trên ngôn ngữ BASIC (Beginners' All-purpose Symbolic Instruction Code), do John G. Kemeny và Thomas E. Kurtz phát triển từ năm 1964. Ngôn ngữ này ban đầu được thiết danh cho những người mới học, do đó nó cũng trong sáng và dễ hiểu, không có những ký hiệu và dấu ngoặc nhọn '{}' như của C, C++. So với Python nó cũng dễ đọc và không khó hơn bao nhiêu, Python chỉ là tối giản hơn so với BASIC. 

VBA được đưa vào bộ MS Office từ năm 1993, đến năm 1998, nó có cú pháp giống hệt và tương thích với Visual Basic 6.0 trong bộ Visual Studio 6.0 và cũng giống với người em út là VB Script. Sau năm 1998, Microsoft chuyển sang phát triển nền tảng .NET Framework, vì thế VB6 được thay da đổi thịt thành VB.NET và gia nhập gia đình họ biên dịch tương tự như C# và cũng từ đó VBA khác dần so với VB.NET.

Từ năm 1995 tôi cũng đã bắt đầu có một số nghiên cứu về VBA, nhưng đến năm 1998 mới thực sự lập trình trên ngôn ngữ này, ban đầu cũng chỉ sử dụng như là Macro để tự động hóa các thao tác trong bộ MS Office, sau đó chúng tôi phát triển bộ Vietkey Office viết bằng VBA và tích hợp vào MS Word, MS Excel, MS PowerPoint từ năm 1999 đến nay và bộ công cụ sau hơn 20 năm vẫn hoạt động với bộ MS Office 2019, bộ sản phẩm này bao gồm các chức năng: Kiểm tra chính tả tiếng Việt, Chuyển mã font tiếng Việt, Sắp xếp tiếng Việt...(Hình 2, Hình 3).

Hình 2: Giao diện Vietkey Office (VBA Addin) cài trên MS Word 2019
 
Hình 3: Giao diện Kiểm tra chính tả tiếng Việt (VBA Addin) cài trên MS Word 2019

Kể từ đó cho đến tận bây giờ tôi đã viết nhiều phần mềm để phục vụ cho bản thân như: Phần mềm quản lý tài liệu tham khảo, phần mềm quản lý File, phần mềm sửa đổi thông tin cho các file MP3, và một số phần mềm nghiệp vụ quản trị chấm điểm cho một số môn thi đấu thể thao như Dancesport, Aerobic cũng được viết hoàn toàn bằng VBA trong Excel (cập nhật lần cuối năm 2019), hình 4.

Hình 4: Giao diện VKSkating - chấm điểm cho dancesport được viết bằng VBA trên MS Excel 2019.

Sau đây là một số lý do tại sao tôi khuyến cáo nên dạy các em học sinh lớp 11 ngôn ngữ VBA thay vì Pascal. Tôi đã xem tất cả các sách giáo khoa môn tin học tất cả các lớp 6, 7, 8, 9, 10, 11, 12, thì thấy rằng xuyên suốt chương trình đào tạo tin học ở bậc phổ thông từ cơ sở đến trung học, ngoài việc cung cấp các khái niệm cơ bản như máy tính, hệ điều hành, mạng, an toàn thông tin thì từ lớp 6, lớp 7 các em đã được làm quen với bộ soạn thảo văn phòng: MS Word, MS Excel, đến năm lớp 12 thì được giới thiệu tiếp MS Access cũng là một ứng dụng trong bộ MS Office. Về ngôn ngữ lập trình thì năm 11 các em được học sâu về ngôn ngữ Pascal. Thực ra xem kỹ SGK tin học lớp 11 do thầy Hồ sỹ Đàm chủ biên, tái bản lần thứ 4 năm 2014, thì nội dung cũng không phải quá nặng như ý kiến của một số chuyên gia, vấn đề lớn nhất là ngôn ngữ này đã lạc hậu, công cụ phát triển đã chết, không còn được hỗ trợ và phát triển, nên tính ứng dụng, tính kế thừa đều kém. Nếu chỉ để minh họa tư duy thuật toán thì quá lãng phí thời gian và công sức để các em phải lập trình trên công cụ đã chết này. Xây dựng kỹ năng lập trình ngôn ngữ này, nhưng từ đó về sau không bao giờ còn được sử dụng nữa thì quả thực lãng phí.

VBA so với các NNLT đã phân tích ở trên thì thỏa mãn đầy đủ các yêu cầu đã liệt kê ở trên từ A1-A6, và hơn nữa nó có những ưu điểm rất đáng giá và rất đáng lưu tâm sau:
  • VBA là ngôn ngữ dễ đọc, dễ học, số lượng lệnh và thư viện của nó không nhiều và đồ sộ như C, hay Python. Không có quá nhiều các khái niệm của NNLT hiện đại như list, tuble, set, lamda, hướng đối tượng đầy đủ (VBA cũng có hướng đối tượng nhưng là phiên bản tối giản). 
  • Cài đặt và sử dụng VBA khá đơn giản và dễ dàng. VBA được tích hợp sẵn trong các ứng dụng của bộ MS Office (Word, Excel, Access, Outlook, Visio, Publisher...), vì thế không cần phài cài đặt thêm bất kỳ phần mềm nào, chỉ cần nhấn tổ hợp phím ALT+F11 là công cụ soạn thảo và biên dịch VBA được mở ra và có thể bắt tay vào lập trình được luôn. Mọi công việc lập trình có thể chỉ cần xoay quanh công cụ VBA này, tra cứu các thư viện, các object từ menu, không phải thoát ra ngoài cài thêm hay vào Internet để download thêm thành phần nào.
  • Lập trình VBA rất nhanh và hiệu quả, có thể bắt đầu bằng cách ghi lại các thao tác của người dùng muốn thực hiện (Record Macro) và ứng dụng trong bộ Office sẽ sinh ra cho chúng ta một đoạn mã VBA rồi, chỉ cần tùy biến một chút (như thêm vòng lặp) là đã có thể tạo ra công cụ tự động hóa các công việc văn phòng nhằm nâng cao năng suất lao động. Cũng vì điều này mà tính ứng dụng của VBA rất cao.
  • Có thể sử dụng công cụ của VBA dạng kéo thả để tạo ra giao diện rất trực quan và nhanh chóng (Hình 4), trải nghiệm như kiểu kéo thả của Scratch mà các em đã từng học, do đó dễ dàng tạo ra được các ứng dụng giao diện thân thiện và gây được hứng khởi cho các em (khác xa với giao diện Terminal hay DOS Prompt tối đen của Pascal hay Python).
  • Có tính ứng dụng (A5) và kế thừa A6) cao, VBA có trong các công cụ văn phòng của Microsoft như Word, Excel, Access, Outlook, Visio, Publisher, những ứng dụng văn phòng này thì không chỉ các em học CNTT mà gần như các em học các ngành khác đều cần đến. Thực tế VBA được sử dụng nhiều bởi các chuyên viên không phải ngành IT như Finance, HR, Marketing, Project Management professionals, kể cả người học khối C, khối D thì vẫn cần phải có kỹ năng văn phòng và do đó cũng cần có công cụ để tối ưu và nâng cao năng suất các công việc văn phòng. Bên cạnh đó thông qua VBA có thể lập trình để gắn kết và điều khiển các ứng dụng một cách liên hoàn tạo thành một work flow hoàn hảo, ví dụ dữ liệu được nhập vào từ Access qua Excel rồi xuất qua Word và gửi email qua Outlook, một quy trình như vậy có thể được tự động hóa bằng VBA mà không cần phải thao tác của người dùng, VBA như một script để điều khiển cả hệ sinh thái của các ứng dụng văn phòng. Và không chỉ dừng ở công việc văn phòng VBA còn được tích hợp với các ứng dụng của nhiều hãng ông lớn ngành phần mềm khác như đối với các phần mềm thiết kế 2D, 3D: AutoCAD, CorelDraw, LibreOffice, SolidWorks. VBA cũng được tích hợp để lập trình trong  các dứng dụng trong hệ thông tin địa lý GIS rất nổi tiếng và thịnh hành như MicroStation, ArcGIS...
  • VBA đã tồn tại 27 năm và vẫn còn tiếp tục tồn tại đến chừng nào bộ MS Office còn tồn tại, phiên bản mới nhất là VBA 7.1 mới được cập nhật năm 2019. MS đã có nhiều lần định ngừng phát triển VBA và đã có ý định phát triển Javascript để thay thế nhằm tăng khả năng tương thích với các trình duyệt và để tích hợp sâu các ứng dụng MS Office lên Cloud nhưng tiến trình Javascript diễn ra rất chậm và dù có bản Javascript thì MS cũng không thể bỏ được VBA vì suốt 27 năm qua hàng trăm ngàn doanh nghiệp đã xây dựng hệ sinh thái và work flow của họ dựa trên VBA.
  • VBA là một công cụ tuyệt vời cho trải nghiệm lập trình, ngoài khả năng sinh mã nguồn nhanh qua cơ chế ghi lại thao tác user thì, lập trình viên có thể thao tác với dữ liệu text (trong Word), bảng biểu, dữ liệu (trong Excel) vô cùng trực quan, và kế thừa các công cụ phân tích dữ liệu, tạo các report chuyên nghiệp (còn dễ dàng và thân thiện hơn cả Crystal Report). Trong Excel chúng ta có hơn 400 hàm Built-In có thể thao tác trực tiêp với dữ liệu mà không cần phải sử dụng các lệnh lập trình. Một trong những tính năng cũng rất mạnh mẽ mà ít có ngôn ngữ nào hỗ trợ đó là khả năng debug in desgin mode. Mặc dù C# cũng được quảng cáo có tính năng này nhưng thực tế vẫn phải compile toàn bộ mã nguồn mới debug được hoặc chỉ áp dụng tính năng này 1 cách rất hạn chế. Với cửa sổ immediate window thần thánh chúng ta có thể gớ rối hay chạy từng lệnh (debug) với từng function hay sub một cách dễ dành và vô cùng thuận tiện. Ví dụ minh họa tính năng này: bình thường muốn debug chúng ta phải biên dịch và chạy chương trình ở chế độ run-time, giống như muốn uốn nắn chỉnh sửa 1 tác phẩm kim hoàn, chúng ta phải nung nóng để kim loại mềm ra thì mới uốn nắn được, thì riêng với VBA, chúng ta có thể vẫn uốn nắn được kim loại ở nhiệt độ bình thường không phải nung nóng nhiêu khê nữa. Cộng với khả năng lập trình dạng kéo-thả và theo sự kiện và tương tác sống với dữ liệu trên Excel, mà nhiều người thường chọn VBA trong Excel để lập trình Prototype. Bản thân tôi cũng thường dùng Excel VBA để xây dựng và thử nghiệm các thuật toán, ví dụ như chương trình tính tọa độ vĩ độ mặt trời, phần tử bắn cho pháo binh, phần tử phóng cho tên lửa, hay hệ thống chấm điểm, tôi vẫn dùng VBA để xây dựng thuật toán và chạy thử với dữ liệu Uni test là các dữ liệu trong Excel, sau khi thuật toán chạy đúng thì mới chuyển qua Java để viết app cho Android, hay đơn giản có thể chuyển sang VB.NET vì có cú pháp tưởng tự của Visual Basic để phát triển các app có độ chuyên nghiệp cao hơn.
Một tấm huy chương bao giờ cũng có 2 mặt, và mặt trái của VBA là:
  • Dữ liệu không quá 1.000.000 bản ghi.
  • Khó làm việc nhóm, dùlLàm việc cá nhân thì rất tốt.
  • Xử lý đa nhiệm đa luồng kém.
Tuy nhiên với các ứng dụng không quá lớn và đặc biệt đối với lứa tuổi học sinh thì các nhược điểm này hoàn toàn không đáng kể. Tôi đã từng dạy một lớp VBA cho các bạn văn phòng của một nhà hàng, gồm kế toán, thủ kho, nhân sự, chỉ sau 1 buổi họ đã biết lập trình tạo ra các hàm mới, và sau 4 buổi họ đã hoàn toàn tự động hóa được khâu chấm công, tính lương, bóc bill để làm chứng từ thuế, mà trước đây mỗi lần khai báo thuế cả đội văn phòng phải thức thâu đêm nhiều ngày để làm bằng tay, và giờ đây thời gian rút gọn xuống chỉ còn 1 vài giờ.

Kết luận

Không nên dạy Pascal cho học sinh lớp 11, vì NNLT này quá lạc hậu và tính ứng dụng kém, nhưng cũng không nên chọn C, C++ hay Python vì đó là những NNLT dành riêng cho các lập trình viên chuyên nghiệp ngành CNTT, do đó ít có tính ứng dụng và kế thừa cho các em tương lại sẽ làm việc ở nghành khác. Thay vào đó nên chọn VBA vì nó dễ đọc, dễ học, không phải học quá nhiều nhưng lại có thể tạo ra được các ứng dụng rất hữu dụng ngay cho bản thân các em khi đã học Word, Excel từ năm trước và đặc biệt đến năm lớp 12 học Access thì VBA sẽ hõ trợ rất đắc lực (Access mà không dùng VBA thì thà dùng luôn Excel cho rồi). Và ngay cả sau này ra trường dẫu các em không theo ngành CNTT thì các kỹ năng văn phòng, tối ưu tự động hóa văn phòng vẫn luôn là hữu ích, các ngành khác như thiết kế, GIS và nhiều lĩnh vực khác đều có thể ứng dụng VBA vô cùng hiệu quả và hữu dụng.
 
Tài liệu tham khảo

[1] Công văn số 3280/BGDĐT-GDTrH ngày 27 tháng 8 năm 2020 của Bộ trưởng Bộ GDĐT, "Hướng dẫn điều chỉnh nội dung dạy học cấp trung học cơ sở môn tin học", link.

[2] https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/spectralnorm.html

[3] Python loop slower than Excel VBA?

Share:

Tuesday, September 8, 2020

05 - Nên đọc mã nguồn (source code) như thế nào?

Một trong số những người có ảnh hưởng lớn nhất đến ngành Công nghệ thông tin thế giới và đến cả cuộc sống của chúng ta đó là Linus Torvalds (sinh năm 1969 ở Phần Lan). Hàng ngày hàng giờ, hàng tỷ người vẫn đang sử dụng những sản phẩm có liên quan đến đại cao thủ lập trình đó. Hệ điều hành Linux do ông sáng tạo ra vào năm 1991 đã len lỏi trong hàng tỷ thiết bị IoT nhỏ bé cho đến các siêu máy tính có sức mạnh khủng khiếp: "Linux Runs on All of the Top 500 Supercomputers, Again!" (https://itsfoss.com/linux-runs-top-supercomputers/). Hàng tháng có 2.5 tỷ người thường xuyên sử dụng thiết bị Android (điện thoại, máy tính bảng...) theo [1], trong khi đó họ nhà táo chỉ có 1.4 tỷ thiết bị IOS mà thôi. Thị phần hệ điều hành cho thiết bị di động Android: 74.25% và IOS là 25.15% [2]. Android chính là một phiên bản rút gọn của Linux. Linus Torvalds là một người rất đam mê công nghệ và gần 30 năm qua ông vẫn code và chủ trì chính dự án Linux Kernel và Git, đồng thời ông cũng là một người thẳng thắn và có nhiều phát biểu rất sốc. Linus từng nói: "Chém gió chỉ là vớ vẩn, ông hãy trình code ra đi" - “Talk is cheap. Show me the code.” Hôm nay ông giáo sẽ chia sẻ kinh nghiệm đọc mã nguồn của Linus Torvalds: Linux Kernel nói riêng và nghiên cứu mã nguồn của một dữ án mã nguồn mở nói chung. Ông giáo đã từng đọc mã nguồn Linux Kernel có 10 triệu dòng lệnh, Bitcoin: 500 nghìn dòng lệnh và Ethereum: 600 nghìn dòng lệnh.

1. Thách thức khi đọc một dự án mã nguồn mở

Ngày nay có hơn 180.000 dự án mã nguồn mở, trong số đó có rất nhiều dự án đồ sộ, ví dụ như dự án nhân của hệ điều hành Linux phiên bản 5.8.2 đã là 27.8 triệu dòng lệnh [3]. Cách đây 15 năm khi ông giáo nghiên cứu bản 2.4 thì đâu đó mới chỉ có 10 triệu dòng lệnh mà thôi. Bơi trong một biển dòng lệnh như vậy sẽ khiến cho vô vàn code sĩ hụt hơi, choáng ngợp và thường là bỏ cuộc.

Vậy những khó khăn thách thức chủ yếu là gì:

  • Không biết bắt đầu từ đâu: giống như được thả vào một cách rừng bát ngát toàn cây và không biết đi về hướng nào.
  • Ít có tài liệu hướng dẫn chi tiết và mô tả thiết kế, nên không hiểu được logic của hệ thống. Đôi khi xem lại chính code mình viết cách đây vài năm là đã thấy khó hiểu huống chi đọc code của bao nhiêu người khác có văn hóa, trình độ và thói quen hoàn toàn khác.
  • Rất khó theo dõi, đọc code không giống như đọc truyện, không như các trang sách cứ tuần tự từ đầu đến cuối. Trong mã nguồn thường một hàm sẽ gọi nhiều hàm con, trong hàm con đó lại gọi hàm cháu, hàm chắt... Và các hàm này không được viết liền nhau mà sẽ nằm ở một vị trí khác nhau trong file mà thậm chí nằm ở những file khác và ở những thư mục khác, người đọc sẽ phải switch liên tục từ chỗ này ra chỗ khác từ file này qua file khác và qua cả các thư mục khác... 
  • Với nhưng dự án lớn thì thời gian và công sức sẽ là những thách thức rất lớn, đòi hỏi người đọc phải có tinh thần thép, không bị nản, không bị ngợp mới có thể đi được đến cùng.
Để có thể đọc và nghiên cứu mã nguồn của một dự án lớn, chúng ta cần phải trang bị những công cụ hữu hiệu và một chiến lược hay một phương phát đọc mã nguồn hiệu quả.

2. Công cụ phần mềm để đọc mã nguồn

Các công cụ này không nhất thiết phải có tuy nhiên có thì sẽ hỗ trợ công việc tốt hơn và hiệu quả hơn. Các công cụ này cũng là những công cụ mà ông giáo cảm thấy hay ho và lựa chọn chúng hoàn toàn là do sở thích cá nhân, người khác có thể dùng các công cụ quen thuộc khác hoặc không dùng công cụ gì cả.
  • Bộ soạn thảo mã nguồn tích hợp IDE (Integrated Development Environment): thường thì làm việc với ngôn ngữ nào thì sẽ lựa chọn IDE thường được sử dụng để viết ra các mã nguồn đó. Các công cụ này thường tích hợp nhiều tính năng, trong đó quan trọng là soạn thảo, gỡ rối và biên dịch. Có thể kể đến vài IDE phổ biến như: MS Visual Studio, Visual Studio Code, Android Studio, XCode, Netbeans, Eclipse, IntelliJ IDEA, thậm chí là cả VIM, và Notepad.
  • Công cụ soản thảo Text. Có nhiều lựa chọn, nhưng ông giáo rất hay dùng và yêu thích phần mềm PSPad do một lập trình viên người Czech và cũng ở Brno nơi ông giáo từng học 5 năm ở đó. PSPad là một phần mềm miễn phí rất nhỏ gọn, hỗ trợ soạn thảo và hiển thị từ khóa của rất nhiều ngôn ngữ lập trình, có khả năng soạn thảo Unicode Text cũng như soạn thảo file nhị phân Hex Editor, ngoài ra nó cũng là FPT Client để có thể soạn thảo Web HTML và đẩy lên server ngay trong PSPad mà không phải dùng phần mềm khác để upload...
  • Công cụ phân tích và tạo tài liệu cho mã nguồn tự động Doxygen:  "Doxygen is the de facto standard tool for generating documentation from annotated C++ sources, but it also supports other popular programming languages such as C, Objective-C, C#, PHP, Java, Python, IDL (Corba, Microsoft, and UNO/OpenOffice flavors), Fortran, VHDL and to some extent D". Công cụ tạo các tài liệu về mã nguồn rất chuyên nghiệp, tổng hợp các lớp, các hàm có trong dự án. Khi xây dựng tài liệu cho dự án ông giáo cũng hay sử dụng công cụ này. Từ năm 2008, ông giáo đã là người đầu tiên và duy nhất cho đến bây giờ chuyển ngữ phần mô tả tiếng Việt cho Doxygen nhờ vậy chúng ta sẽ có tài liệu mô tả mã nguồn bằng tiếng Việt.
  • Công cụ bóc tách và vẽ sơ đồ thuật toán từ mã nguồn Visustin. Đây là côg cụ cũng khá mạnh để tự động vẽ sơ đồ thuật toán (flowchart) từ mã nguồn. Đối với các dự án cần xây dựng tài liệu một cách chuẩn chỉnh thì ngoài các biểu đồ Use case, biểu đồ UML thì cũng cần phải vẽ cả sơ đồ thuật toán nữa. Visutin là công cụ mạnh nhất tại thời điểm 2011 là lúc ông giáo mua bản quyền phần mềm này. Vì nó là công cụ cũng khá hữu hiệu nên giá khá đắt: 500 USD cho 1 user, riêng nâng cấp cũng mất đến 250 USD.
  • Công cụ ghi chép trong quá triình làm việc Evernote: Đây là công cụ để take notes mạnh nhất cho đến thời điểm này, cho phép viết note đầy đủ các định dạng HTML, có nhiều template rất chuyên nghiệp, có khả năng tổ chức dữ liệu và tìm kiếm nhiều chiều: theo thư mục, theo key word, theo hashtag... Evernote có bản miễn phí và bản có phí (500K/năm), có bản desktop và mobile.
  • Công cụ quản lý tài liệu tham khảo Mendeley: Đây là phần mềm miễn phí tốt nhất cho việc quản lý tài liệu tham khảo và quản lý tài liệu trích dẫn, có addin tích hợp vào MS Word để tham chiếu tài liệu tham khảo ngay trong Word, hoặc cũng có thể xuất ra LaTeX. Có bản Mobile và Desktop và free 2G dữ liệu trên cloud.
3. Phương pháp đọc mã nguồn của ông giáo

Đây là phần chia sẻ, đúc kết kinh nghiệm của ông giáo trong hàng chục năm lập trình và nghiên cứu mã nguồn, các bạn sẽ không tìm thấy trên mạng hay trong các giáo trình hay sách tham khảo đâu nhé. Tùy theo mục tiêu của người nghiên cứu, hoặc phải nắm toàn bộ project hay chỉ cần đúng phần nhỏ mình quan tâm. Nếu chỉ cần nghiên cứu một thành phần thì chúng ta sẽ chỉ tìm đúng phần quan tâm và bỏ qua tất cả các phần khác. Có thể tìm theo thư mục hoặc dùng PSPad hay IDE để tìm theo key word. Giống như khi chúng ta crack phần mềm được bảo vệ bằng số serial number, chúng ta chỉ reverse mã nguòn đến đúng đoạn kiểm tra số serial number để bypass hoặc tìm đoạn mã để tạo genkey tools mà bỏ qua tất cả các mã nguồn còn lại.

Đối với việc cần tìm hiểu một project hoàn chỉnh. thì có thể thực hiện theo các chiến lược và phương pháp như sau:
  • Hãy làm việc như một hacker, chỉ khác là hacker thường phải dùng công cụ reverse engineering để có mã nguồn thì chúng ta có đã có mã nguồn mở, bản đẹp (tên biến tên hàm rất tường minh chứ không bị mất như khi làm reverse). Khi đã hành xử như một hacker thì chúng ta cần thu thập mọi thông tin, mọi manh mối liên quan đến project giống như hacker thực hiện hành vi APT (Advanced Persistent Threat). Tìm hiểu tài liệu của dự án, đọc các commnet trong mã nguồn, tìm kiếm trên google với các key word phù hợp, trang bị các kiến thức nền tảng liên quan, tìm đọc các sách tham khảo...
  • Tìm hiểu cấu trúc thư mục của mã nguồn, các tác giả thường đặt tên thư mục mã nguồn đều có những ý nghĩa gợi nhớ khá rõ ràng và tên các thư mục đó cũng nói lên nhiều điều, hay bản thân tên của các file mã nguồn cũng đều có những ý nghĩa gợi ý rất tốt.
  • Dùng các công cụ tìm kiếm mạnh để tìm sự xuất hiện của các hàm (function, sub) được định nghĩa ở đâu được tham chiếu ở những đâu, Doxygen cũng có thể tạo ra các báo cáo này.
  • Khi bắt đầu hãy tìm hiểu các chương trình chính, các luồng chính. Tìm các hàm main(), hay các thread khởi động...
  • Có thể tìm một phiên bản cũ ngắn gọn để hiểu logic chung, ví dụ khi nghiên cứu mã nguồn của linux kernel nếu chúng ta nghiên cứu ngay vào phiên bản hiện tại 5.8.2 thì sẽ khá là choáng ngợp với 27.8 triệu dòng lệnh, hơn 800M mã nguồn, thay vì như vậy chúng ta tìm bản 1.0 chỉ có vài ngàn dòng lệnh với cỡ 50K mã nguồn mà thôi. Hiểu được kiến trúc ban đầu của Linux Kernel rồi, quay ngược lại tìm hiểu phiên bản hiện hành sẽ dễ dàng hơn nhiều.
  • Có thể cho phần mềm dự án chạy ở chế độ gõ rối (debug) để theo dõi chương trình hoạt động ở một điểm nào đó, rồi cho nó chạy từng dòng lệnh để theo dõi input và các ouput cũng như các giá trị biến trung gian.
  • Và điều quan trọng nhất để cuối cùng đây: luôn luôn phải ghi chép, vì khối lượng công việc lớn, và bộ nhớ của chúng ta có hạn, không thể nhớ được một lượng thông tin khổng lồ, do đó mỗi khi tìm hiểu được một vấn đề gì thì cần ghi chép ngay, hoặc thấy vấn đề nào hay hoặc vấn đề nào cần lưu ý thì cũng phải ghi lại. Cách tốt nhất để ghi (take notes) là dùng phần mềm Evernote. Riêng ghi chép ở Evernote thì cũng cần có các chiến lược sau:
    • Sử dụng lối ghi indent (thò thụt) giống như python để thể hiện các cấu trúc lồng nhau, thậm chí có thể sử dụng cấu trúc thò-thụt này để có thể ghi được bản dồ tư duy (mind map) dạng text có cấu trúc.
    • Ghi làm sao để có thể dễ dàng tra cứu, và khi cần tìm được lại đúng ví trí của mã nguồn gốc.
    • Sử dụng các định dạng: đậm, nghiêng, gạch chân, tô màu để làm nổi các ý cần nhấn mạnh.
    • Khi tìm hiểu 1 hàm, thì cố gắng ghi tất cả thông tin về hàm đó và cả những hàm con của nó cùng ở một chỗ để không phải switch đến chỗ khác và như vậy chúng ta sẽ có một bức tranh toàn cảnh của hàm đó, có thể xây dựng một quy ước riêng, một ngôn ngữ riêng của mình để tạo thuận tiện nhất khi tra cứu và làm rõ thông tin của hàm cần tìm hiểu.
4. Minh họa

Hình dưới đây là minh họa tìm hiểu toàn bộ phần xử lý block trong mã nguồn của Ethereum. Trong hình sẽ mô tả luồng khởi tạo, các hàm quan trọng được tổ đỏ, các hàm cần lưu ý tô đậm, và những đoạn text được đóng khung trong đoạn <<...>> là nguyên bản trong mã nguồn, khi cần copy đoạn text trong khung đó để search lại đoạn mã nguồn gốc.
  • Trong thread sẽ khởi tạo để quản lý các block, với hàm NewBlockchain thông qua lệnh <<go bc.update() >>
  • Phần dưới mô tả hàm  InsertChain và các công việc cũng như các hàm được họi trong nó, trong số đó có hàm  VerifyHeaders  cũng là một hàm quan trọng và được mô tả các công việc liên quan.
  • Với cách ghi chép như vậy chúng ta có thể hiểu khá rõ các thủ tục và các công việc cần làm khi thêm một blockchain (inserChain) một cách tường minh, đầy đủ nhưng cũng rất ngắn gọn...

BLOCK
  • Khởi tạo luồng cập nhật block: <<NewBlockChain>> gọi <<go bc.update() >> trong đó có gọi hàm << bc.procFutureBlocks()>> theo thời gian <<futureTimer.C>> là 5s, trong hàm này sẽ lấy ra danh sách các blocks và sẽ gắn vào chain qua hàm  <<bc.InsertChain(blocks[i : i+1])>>.
  • Hàm <<InsertChain>>:
    • Kiểm tra số của block thứ i phải lớn hơn block thứ i-1 giá trị 1.
    • Kiểm tra giá trị băm của block cha phải bằng giá trị băm hiện tại <<chain[i].ParentHash() != chain[i-1].Hash()>>.
    • Tăng giá trị <<bc.wg.Add(1)>>, waitGroup.
    • Kiểm tra các header của các block. <<bc.engine.VerifyHeaders(bc, headers, seals)>>.
      • Nếu tổng số headers==0, hoặc chế độ ModefullFake thì dừng <<if ethash.config.PowMode == ModeFullFake || len(headers) == 0 >>.
      • Nếu số lượng works lớn hơn số header thì điều chỉnh số workers bằng số header <<workers := runtime.GOMAXPROCS(0)>>.
      • chạy vòng for thực hiện hàm xác thực <<ethash.verifyHeaderWorker(chain, headers, seals, index)>>, hàm này kiểm tra giá trị cha, và kiểm tra tính liên tục của số (number) của block, sau đó gọi hàm <<verifyHeader>>:
        • Kiểm tra header.Extra phải nhỏ hơn  params.MaximumExtraDataSize.
        • Nếu có uncle thì header.Time phải nhỏ hơn 2^256, khi không có uncle thì header.Time < now() + allowedFutureBlockTime (15 s),  header.Time cũng phải nhỏ hơn parent.Time.
        • Kiểm tra độ khó dựa trên tem thời gian và độ khó của block cha (trước đó): <<expected := ethash.CalcDifficulty(chain, header.Time.Uint64(), parent)>>. giá trị tính được phải bằng header.Difficulty.
        • Kiểm tra phải có header.GasLimit < 2^63-1.
        • Kiểm tra phải có header.GasUsed < header.GasLimit.
        • Kiểm tra phải có:  |parent.GasLimit - header.GasLimit| < parent.GasLimit / params.GasLimitBoundDivisor (1024) và header.GasLimit > params.MinGasLimit (5000).
        • Kiểm tra phải có: header.Number = parent.Number + 1.
        • Kiểm tra PoW <<ethash.VerifySeal(chain, header)>> xem có lỗi không.
        • Kiểm tra <<misc.VerifyDAOHeaderExtraData(chain.Config(), header)>> xem có lỗi không.


5. Kết luận

Trên đây là chia sẻ những kinh nghiệp thực tế của ông giáo, có thể nó không phù hợp với một số người hoặc có thể có những người có các phương pháp hay hơn, nhưng đây là cách ông giáo đã tìm hiểu Linux Kernel (10 triệu dòng lệnh), Bitcoin (500k dòng lệnh) và Ethereum (600k dòng lệnh), và qua việc tìm hiểu mã nguồn và ghi chép như vậy mà ông giáo có thể hiểu khá sâu sắc về Bitcoin cũng như Ethereum, khi học viên hỏi bất cứ vấn đề gì liên quan ông giáo đều có thể trả lời chính xác và thực tế nó được triển khai trong mã nguồn như thế nào, và cũng từ đó mới phát hiện ra rằng ngay cuốn kinh điển và nổi tiếng là Mastering Bitcoin của Andreas M. Antonopoulos cũng có 2 lỗi sai cơ bản mà không ai phát hiện ra. Không có thông tin hay kiến thức gì chính xác và chi tiết cụ thể về một dự án bằng chính mã nguồn của dự án đó. Một người lập trình toàn bộ một phần mềm, hay kiến trúc sư của một dự án thành công, thì người lập trình đó có thể được coi là chuyên gia trong lĩnh vực đó mặc dù backround ban đầu của anh ta chỉ là một lập trình viên. Cũng bằng cách như vậy mà ông giáo có thể thao thao hàng tiếng đồng hồ về tên lửa, về pháo, về thiên văn, về virus về các Chip về phương pháp phần tử hữu hạn, và về cả skating cho dancesport.

6. Tài liệu tham khảo

[1] https://venturebeat.com/2019/05/07/android-passes-2-5-billion-monthly-active-devices/ 

[2] https://gs.statcounter.com/os-market-share/mobile/worldwide

[3] https://www.linux.com/news/linux-in-2020-27-8-million-lines-of-code-in-the-kernel-1-3-million-in-systemd/


7. Phụ lục

Một số hình ảnh về công cụ và tài liệu mô tả về Linux Kernel.






Share:

Sunday, June 21, 2020

04-Chứng minh tính chất kết hợp của phép cộng điểm trên đường cong elliptic bằng phương pháp đại số

Mở đầu

Trong cuốn "Elliptic Curves Diophantine Analysis" năm 1978, Serge Lang đã phát biểu gây sốc rằng: “Có thể viết vô tận về đường cong elliptic!”. Đường cong elliptic là một đường cong có phương trình dạng $y^2=x^3+Ax+B$ (Hình 1). Một đường cong không quá phức tạp nhưng ẩn chứa bên trong vô vàn những điều kỳ diệu của toán học và không chỉ có toán học thuần túy mà các lý thuyết về elliptic này cũng đang len lỏi hàng ngày hàng giờ khi hàng tỷ người đang sử dụng Internet một cách vô thức, không biết rằng họ vẫn đang áp dụng thường xuyên các thuật toán của elliptic một cách tự động.
Hình 1: Đường cong elliptic và phép cộng điểm trên đường cong

Đường cong elliptic là cơ sở nền tảng để tạo ra Hệ mật dựa trên đường cong elliptic - Elliptic Curve Cryptography (ECC). Năm 1985, Victor S. Miller công bố bài báo đầu tiên về ứng dụng đường cong EC trong mật mã "Use of elliptic Curves in Cryptography"và sau đó là Neal Koblitz với "Elliptic curve cryptosystem" vào năm 1987. Từ đó cho đến nay đã có rất nhiều công bố nghiên cứu về ECC về lý thuyết và trong thực tiễn càng ngày ứng dụng ECC càng được sử dụng rộng rãi, và đã được đưa thành các tiêu chuẩn. ECC có độ dài khóa nhỏ hơn RSA khá nhiều (6 đến 30 lần tùy theo độ dài khóa), thời gian ký số và xác thực cơ bản cũng nhanh hơn so với thuật toán RSA vì thế ECC đang và sẽ được ứng dụng rất nhiều trong thực tế [4]:
  • Ứng dụng ECC trong các trang web bảo mật: Hầu như tất cả các trang thương mại điện tử, cũng như chính phủ điện tử đều phải dùng giao thức HTTPS và TLS/SSL để mã hóa thông tin trên đường truyền. Để trao đổi khóa, giao thức ECDHE (Elliptic Curve Diffie Hellman Ephemeral) được sử dụng rất phổ biến. Theo [4] trong 100 trang web có lượng truy cập lớn nhất thế giới thì có đến 96% sử dụng trao đổi khóa bằng ECDHE. Hàng ngày chúng ta vào Facebook, Gmail,,,các trang này cũng đều sử dụng hệ mật ECC để trao đổi khóa phiên.
  • Giao thức phân giải tên miền DNS mở rộng (DNS Security Extensions (DNSSEC)) cũng sử dụng chữ ký số dựa trên ECC để xác thực và chống tấn công DDoS [5].
  • Các giao dịch remote access được dùng rất nhiều trong thế giới Unix, Linux là SSH (Secure SHell) cũng sử dụng ECC để trao đổi khóa. 
  • ECC hiện đang được áp dụng trong một loạt các ứng dụng: chính phủ Mỹ sử dụng để bảo vệ thông tin liên lạc nội bộ, các dự án Tor sử dụng để giúp đảm bảo ẩn danh.
  • Chữ ký số dựa trên ECC là ECDSA (Elliptic Curve Digital Signature Algorithm) được sử dụng trong gần như tất cả các nền tảng Blockchain (cả Private và Public). Apple cũng dùng ECDSA để ký số trong dịch vụ iMessage.
  • Trong lĩnh vực IoT và thiết bị di động do tài nguyên phần cứng hạn chế nên hệ mật khóa công khai thường sử dụng ECC thay cho RSA.
  • Về ứng dụng lý thuyết: đường cong elliptic được dùng để chứng minh định lý Fermat cuối cùng. Năm 1637, nhà toán học và vật lý học người Pháp Pierre de Fermat công bố định lý Fermat cuối cùng khi viết trên lề bản copy công trình của Diophant: Phương trình sau đây là vô nghiệm: 
    $x^n + y^n = z^n$
    Hơn ba thế kỷ, đã có rất nhiều nhà toán học cố gắng chứng minh định lý này nhưng đều thất bại, mãi cho đến năm 1994, Andrew Wiles, giáo sư trường Princeton đã gây một tiếng vang lớn trong cộng đồng toán học thế giới vào thời điểm đó khi sử dụng đường cong elliptic có dạng $y^2 = x(x-a^n)(x+b^n)$ cùng với lý thuyết về Modul để chứng minh định lý Fermat cuối cùng.
  • Năm 1987, Lenstra đề xuất thuật toán phân tích số nguyên ra thừa số nguyên tố sử dụng đường cong elliptic, đó là thuật toán nhanh, chạy với thời gian dưới hàm mũ và là thuật toán nhanh thứ 3 trong việc phân tích ra thừa số nguyên tố, sau phương pháp sàng đa thức toàn phương và phương pháp sàng trường số tổng quát.
  • Hệ mật ECC có thể bị bẻ khóa với máy tính lượng tử (Quantum Computer) với cỡ khoảng 1000 qubit (Hiện nay máy lượng tử mạnh nhất mới chỉ có 72 qubit). Tuy nhiên dựa trên lý thuyết về đường cong elliptic có thể xây dựng một hệ mật mã khác có khả năng chống được tấn công của  máy tính lượng tử, đó là Elliptic Curve Isogeny Cryptography [6].
  • Dựa trên lý thuyết về divisor (điểm ước) của đường cong elliptic có thể xây dựng được lý thuyết về cặp song tuyến tính từ đó phát triển được hệ mật mã dựa trên định danh (ID-Based), trong các hệ mật này có thể lấy số chứng minh thư hay địa chỉ email của người dùng làm khóa công khai, nhờ vậy không phải phân phối khóa, quản lý khóa công khai như các hệ mật khóa công khai hiện hành.
  • Thông tư số 39/2017/TT-BTTTT ngày 15/12/2017 của Bộ trưởng Bộ Thông tin và Truyền thông Công bố Danh mục tiêu chuẩn kỹ thuật về ứng dụng công nghệ thông tin trong cơ quan nhà nước quy định Khuyến nghị áp dụng tiêu chuẩn ECC - Elliptic Curve Cryptography và được xếp vào nhóm Tiêu chuẩn về an toàn thông tin.

Cơ sở lý thuyết về đường cong elliptic

Mặc dù đường cong elliptic (EC) được ứng dụng rất nhiều trong Công nghệ thông tin (CNTT), ứng dụng hàng ngày, nhưng có rất ít người hiểu sâu sắc về nó, trong nước chỉ có khoảng 5 tác giả có các nghiên cứu và công bố đến EC, thậm chí nhiều chuyên gia về CNTT còn chưa từng nghe đến Elliptic Curve (EC).

Một trong những nguyên nhân của sự thiết hụt hiểu biết về EC là lý thuyết về đường cong Elliptic (EC) rất khó và đồ sộ, có thể kể ra một số lý thuyết liên quan đến EC:
  • Lý thuyết nhóm, vành, trường trong đại số trừu tượng;
  • Đa tạp Affine, đa tạp Jacobian và đa tạp xạ ảnh trong hình học đại số;
  • Điểm Torsion, Divisor, cặp song tuyến tính Weil, Tate-Lichtenbaum;
  • Lý thuyết trường Galois, tự đồng cấu-ánh xạ Frobenius;
  • Lý thuyết Baker-Feldman, Baker-Tijdeman và lý thuyết Kummer;
  • Số p-adic, Isogenies, hàm Sigma và hàm Zeta;
  • Nhóm đối đồng điều, đối đồng điều Galois và đối đồng điều phi giao hoán (Topo đại số);
  • Nhóm Mordell–Weil, Selmer và nhóm Shafarevich–Tate;
  • Phương pháp hình học và Tựa tuyến tính (Quasilinear).
Lý thuyết quan trọng nhất để tạo ra các ứng dụng trong ECC là định nghĩa về phép cộng hai điểm trên đường cong elliptic. Điều kiện rất quan trọng là các điểm trên đường cong với phép cộng phải tạo nên nhóm (group), khi đó có phép cộng điểm phải có các tính chất sau:
  1. Có tính giao hoán: $P_1+P_2=P_2+P_1$;
  2. Tồn tại điểm 0; $P+0=P$.
  3. Tồn tại điểm đối: $P + (-P) =0$.
  4. Có tính chất kết hợp: $P_1+(P_2+P_3)=(P_1+P_2)+P_3$.
Phép cộng 2 điểm trên đường cong $P+Q$ là điểm đối xứng qua trục $x$ của điểm cắt giữa đường cong với đường thẳng đi qua $P$ và $Q$ (Hình 1). Ba tính chất đầu có thể dễ dàng suy ra từ định nghĩa hoặc dễ dàng nhận thấy. Duy nhất tính chất 4 (tính kết hợp) là phần khó nhất. Tiếp theo chúng ta sẽ bàn về một số phương pháp chứng minh tính kết hợp của phép cộng trên EC. 

Chứng minh tính chất kết hợp của phép cộng trên đường cong elliptic

Có hai phương pháp chính để chứng minh tính chất kết hợp của phép cộng trên EC là a/ Chứng mình bằng lý thuyết về hình học đại số và b/ Chứng minh bằng đại số.

Chứng minh bằng hình học: W. Fulton dùng định lý Bézout (hai đường cong elliptic sẽ giao nhau ở nhiều nhất là 9 điểm): Hai điểm $P_1, P_2$ sẽ cắt đường cong E tại điểm $P_1P_2$ và đối xứng của điểm này chính là điểm tổng $P_1+P_2$ như vậy 4 điểm này nằm trên cùng đường cong $E$, tương tự vậy hai điểm $P_3, P_2$ sẽ cắt đường cong E tại điểm $P_3P_2$ và đối xứng của điểm này chính là điểm tổng $P_3+P_2$ do đó 4 điểm này cũng nằm trên cùng đường cong $E'$, như vậy 2 điểm $P_3$ và $(P_1+P_2)$  sẽ cắt đường cong tại $R$, tương tự vậy $P_1$ và $(P_3+P_2)$  sẽ cắt đường cong tại $R'$. Hai đường cong $E$ và $E'$ đã cắt nhau ở 8 điểm (4+4), thì sẽ cắt nhau ở 1 điểm nữa  và vì thế buộc $R=R'$, do đó 2 điểm tổng này phải bằng nhau (Hình 2).

Hình 2: Chứng minh tính kết hợp của EC bằng hình học

Cách chứng minh này cũng khá khó hình dung và đặc biệt để chứng minh định lý Bézout cần phải có kiến thức nền tảng về hình học đại số (Algebaraic Geometry) và các khái niệm về không gian xạ ảnh và đường cong xạ ảnh (projective plan curves) và các khái niệm về không gian Affine, đa tạp Affine (Varieties). Các khái niệm này đều khá xa lạ với các chuyên gia trong lĩnh vực Công nghệ Thông tin (CNTT).

Ngoài cách chứng minh định lý Bézout của Fulton [7], còn có cách khác của Shafarevich [8] dùng một số định lý và bổ đề liên quan đến khái niệm divisor  (điểm ước) của đường cong elliptic, cũng là những khái niệm khó hiểu đối với sinh viên ngành CNTT.

Chứng minh bằng đại số: đựa vào công thức tính tổng hai điểm trên đường cong elliptic, có thể xem trong [1] hay trong http://j.mp/elliptic20 :
 $P_{12}(x_{12},y_{12})=P_1(x_1,y_1)+P_2(x_2,y_2)$ 
Tiếp theo áp dụng công thức này cho việc tính các tổng  $P_{32}=P_3+P_2$ , $P_{123}=P_{12}+P_3$, $P_{321}=P_{32}+P_1$. Ta phải chứng minh rằng $P_{123}=P_{321}$, muốn chứng minh điều này ta chỉ cần chứng minh $x_{123}=x_{123}$ và $x_{321}=x_{321}$.

Phương pháp chứng minh đại số này người viết đã đăng tải trên Tạp chí Epsilon năm 2016 [1]. Năm sau đó (2017) có 2 nhóm tác giả là K. Fujii, H. Oike [2] và  S. Friedl [3] cũng công bố phương pháp chứng minh tương tự bằng đại số, tuy nhiên các công bố này cũng chỉ nêu các ý tưởng chính, mà chưa trình bày các kết quả cụ thể, vì vậy trong bài viết này người viết sẽ trình bày phần chứng minh một cách đầy đủ bằng phương pháp đại số. Toàn văn file PDF chứng minh có thể download hoặc xem ở đây.

Đây là phần chứng minh rất dài, bao gồm 363 trang A4, có nhiều công thức và biểu thức rất phức tạp, có một công thức dài tới 100 trang A4. 

Hình 3: Công thức đệ lệch tọa độ của điểm $P_{123}$ và $P_{321}

Tuy chỉ là công thức tính tọa độ giữa ba điểm $P_1,P_2,P_3$ nhưng vì trong đó có hệ số góc là các phân số, thành phần mẫu số và tử số của các phân số này lại có tọa độ của các điểm được tính từ trước đó cũng liên quan đến hệ số góc là các phân số, do đó có thể đến 6 tầng phân số khác nhau, khi quy đồng các mẫu số này sẽ dẫn tới bùng nổ các toán hạng, và theo thống kê thì có đến hơn 30 ngàn các phép tính để ra được kết quả cuối cùng.
Hình 4: Tài liệu chứng minh tính kết hợp của phép cộng trên EC ở đây 

Kết luận

Hệ mật dựa trên đường cong elliptic đã và đang được sử dụng ngày càng nhiều trong các hoạt động thực tiễn khi phải trao đổi thông tin trong môi trường Internet cần đến các phương pháp mã hóa dữ liệu. Bài viết này là một trong các nỗ lực để giúp cho các bạn quan tâm tìm hiểu sâu các cơ sở toán học nền tảng phía sau các công nghệ bảo mật thông tin cụ thể là hệ mật đường cong elliptic. Bài viết để cập đến phần chứng minh một trong những tính chất cơ bản nhất của cơ sở toán học và mật mã của đường cong elliptic, phần lớn trong các tài liệu chỉ thừa nhận kết quả này mà ít có phần chứng minh, hoặc các chứng minh đòi hỏi một nền tảng toán học rất xa so với các hiểu biết thông thường của ngành CNTT. Người viết muốn trình bày một cách chi tiết và đầy đủ cách chứng minh tính kết hợp của phép cộng trên đường cong elliptic bằng phương pháp đại số, qua đó cũng cho người đọc thấy đó là phương pháp rất dài phức tạp. Từ những nghiên cứu này người viết đã có một cách chứng minh mới ngắn gọn hơn rất nhiều, chỉ  với 1 trang A4 thay cho 393 trang như cách thông thường đã trình bày ở trên. Cách chứng minh mới này sẽ được đăng tải trên một tạp chí có uy tín trong thời gian tới đây.

Đặng Minh Tuấn, tuanvietkey@gmail.com

Tài liệu tham khảo

[1] Đ. M. Tuấn, “Hệ mật mã khóa công khai dựa trên đường cong Elliptic - Một số ứng dụng (1),” Epsilon Magazine, vol. 9, pp. 17–35, 2016.

[2] K. Fujii and H. Oike, “An Algebraic Proof of the Associative Law of Elliptic Curves,” Advances in Pure Mathematics, vol. 07, no. 12, pp. 649–659, 2017.

[3] S. Friedl, “An elementary proof of the group law for elliptic curves,” Groups, Complexity, Cryptology, vol. 9, no. 2, pp. 117–123, 2017.

[4] R. Harkanson and Y. Kim, “Applications of elliptic curve cryptography: A light introduction to elliptic curves and a survey of their applications,” ACM International Conference Proceeding Series, no. 1, 2017.

[5] Roland van Rijswijk-Deij, Kaspar Hageman, Anna Sperotto, and Aiko Pras. "The Performance Impact of Elliptic Curve Cryptography on DNSSEC Validation". IEEE/ACM Transactions on Networking, pp 99 (Sep. 2016).

[6] Brian Koziel, Reza Azarderakhsh, Mehran Mozaffari Kermani, and David Jao. 2016. Post-Quantum Cryptography on FPGA Based on Isogenies on Elliptic Curves. IEEE Transactions on Circuits and Systems I: Regular Papers 64, 1 (Oct. 2016).

[7] William Fulton, Algebraic Curves - An Introduction to Algebraic Geometry, Wesley, 1969.

[8] Igor R. Shafarevich,Basic Algebraic Geometry 1, Springer, 2013.
Share:

Sunday, May 3, 2020

03-Về một số lỗ hổng bảo mật của Bluezone

Updated: Sau khi đăng bài viết, team phát triển đã có những ghi nhận tích cực đóng góp và để tôn trọng sản phẩm non trẻ đang vì mục đích phục vụ cộng đồng nên tôi đã tạm gỡ bài xuống.

Cảm ơn cả nhà đã ủng hộ.

PS. Bạn nào quan tâm đến vấn đề kỹ thuật có thể liên hệ với mình theo địa chỉ tuanvietkey@gmail.com nhé.

Share:

Tuesday, April 14, 2020

02. Hịch Dancesport 2007

(Đăng lại bài viết từ năm 2007)


Ta thường nghe: Thiết Cương nửa đêm còn làm sàn gỗ, cứu thoát cho mấy giải quốc gia; Vaio chìa lưng chịu giáo trên forum, che chở cho Vận động viên; Khánh Thi nuốt than, báo thù cho nước chủ nhà; The Lead chặt cơ may để cứu nạn cho Hải Dương. Phan Hiển một chàng tuổi trẻ, thân phò La-tin thoát khỏi vòng semi-final; Từ xưa các bậc vũ sư, vũ công hết mình vì nước, đời nào chẳng có? Ví thử mấy người đó cứ khư khư theo thói thường tình suốt ngày nhảy bằng mồm thì cũng đến chết hoài ở xó cửa, sao có thể lưu danh sử sách cùng trời đất muôn đời bất hủ được?

Các ngươi vốn dòng dancesport, không phải salon, nghe những chuyện ấy nửa tin nửa ngờ. Thôi việc đời nay hẵng tạm không bàn. Nay ta lấy chuyện standard, Latin đời xưa mà nói: Marcus Hilton là người thế nào ? Karen Hilton, tỳ thiếp của ông lại là người thế nào ? Vậy mà đem lại 9 lần danh hiệu vô địch thế giới mảng standard, nhiều nhất trong các công cuộc championship hàng năm, khiến cho sinh linh nhà Anh Quốc đến nay còn đội ơn sâu ! Donnie Burns là người thế nào ? Gaynor Fairweather, partner của ông lại là người thế nào ? Vậy mà xông vào chốn lam chướng xa xôi muôn dặm trần gian đánh quỵ các couples mảng Latin suốt 13 năm liền, khiến cho quân trưởng người Scotland đến nay còn lưu tiếng tốt ! Huống chi, ta cùng các ngươi sinh ra phải thời salon còn mạnh , lớn lên gặp buổi dancesport gian nan. Lén nhìn Vận động viên Thái Lan bay lượn nghênh ngang ngoài sàn sea games mấy vụ, cuỗm hết huy chương vàng, bạc, đồng , khiến cho quân ta đi thi thố chỉ là cọ sát, rồi thi xong xuôi tất cả lại về, mà căm. Ta thường tới bữa quên ăn, nửa đêm vỗ gối, ruột đau như cắt, nước mắt đầm đìa; chỉ giận chưa thể bay cao bay xa giật chút vàng, bạc, đồng, để lại chút danh thơm cho liệt tổ liệt tông nơi đất khách quê người; dẫu cho trăm thân ta phơi ngoài công viên nắng nôi luyện tập, nghìn thây ta lăn lộn nhễ nhại mồ hôi mồ kê trong trường múa, cũng nguyện xin làm.

Các ngươi ở lâu dưới trướng liên đoàn IDSF, nắm giữ choreography , không có video thì ta cho video; không có nhạc thì ta cho cả nhạc. Vận động viên cấp cao thì ta cho đi thi; cấp thấp hơn thì cho đi tập huấn. Thi trong nước thì ta cho đi tầu; thi ngoài nước thì ta cho chim sắt. Lâm thi đấu thì cùng nhau sống chết; được huy chương thì cùng nhau vui cười. So với Đại gia đãi kẻ chân dài, Viettel đãi người Thể Công, nào có kém gì?

Nay các ngươi ngồi nhìn nền Dancesport nước nhà yếu kém mà không biết lo; thân chịu quốc sỉ mà không biết thẹn. Làm Vận động viên triều đình đứng dưới quân Miên mà không biết tức; nghe nhạc quốc ca sứ khựa vang lên trong nhà mà không biết căm. Có kẻ lấy việc đánh bóng mặt sàn làm vui; có kẻ lấy việc dậy private làm thích. Có kẻ chăm lo Câu lạc bộ của riêng để cung phụng gia đình; có kẻ quyến luyến gái nhảy để thỏa lòng vị kỷ. Có kẻ tính đường sản nghiệp mà quên việc nước; có kẻ ham trò thi thố mà trễ việc basic. Có kẻ thích tinh tướng; có kẻ mê pi-a (PR) nhảm. Nếu bất chợt có sát hạch ISTD thì cựa giai nhẩy không đủ đi vài bước syllabus; mẹo trên sàn không đủ thi hành vài tổ hợp giản đơn. Còn thi thố nước người không chuộc nổi tấm huy chương đồng; sàn salon lắm không ích gì cho việc Dancesport. Tiền của dẫu lắm không mua được chứng chỉ; múa bụng tuy hay không làm được liên đoàn. Lúc bấy giờ chúa tôi nhà ta đều rặt bachata, đau xót biết chừng nào ! Chẳng những phong trào của ta không còn mà huy chương các ngươi cũng thuộc về tay kẻ khác; chẳng những gia quyến của ta chỉ biết đến Lăm-Vông mà vợ con các ngươi cũng bị Salsa bắt đi; chẳng những thân ta kiếp này chịu nhục đến trăm năm sau tiếng nhơ khôn rửa, tên xấu còn lưu, mà gia thanh các ngươi cũng không khỏi mang danh là vận động viên lởm. Lúc bấy giờ, dẫu các ngươi muốn vui chơi off-ẹp, phỏng có được chăng?

Nay ta bảo thật các ngươi: nên lấy việc "chân tuy dài nhưng gù dưới váy" làm nguy; nên lấy điều "bước tuy nhiều nhưng tuyền sai nhạc" làm sợ. Phải huấn luyện thiếu nhi, tập dượt back to basic, khiến cho ai nấy đều giỏi như Watson, mọi người đều tài như Alessia Betti, có thể bay lượn ở Blackpool, làm rối tinh rối mù lên vì tiếng vỗ tay ở Festival Nhật Bổn. Như thế chẳng những nền Dancesport của ta mãi mãi vững bền mà show diễn của các ngươi cũng vô tư mà tận hưởng; chẳng những liên đoàn sớm ra đời, mà hình ảnh của các người cũng được đăng đầy trên facebook; chẳng những tông miếu forum ta được hương khói nghìn thu mà thứ hạng của các ngươi cũng được bốn mùa thờ cúng; chẳng những thân ta kiếp này thỏa chí, mà đến các ngươi, trăm đời sau còn để tiếng thơm; chẳng những thụy hiệu ta không hề mai một, mà tên họ các ngươi cũng sử sách lưu truyền. Lúc bấy giờ, dẫu các ngươi không muốn đi sàn, phỏng có được không?
Nay ta chọn lọc binh pháp 10 quyển sách đỏ ISTD hợp thành một tuyển, gọi là dancesport Yếu Lược. Nếu các ngươi biết chuyên tập sách này, theo lời IDSF dạy bảo, thì trọn đời là Vận động viên Dancesport; nhược bằng khinh bỏ sách này, trái lời ta dạy bảo thì trọn đời là Salon nghịch tử.

Vì sao vậy? Đạo Salon với Dancesport ta là kẻ thù không đội trời chung, mà các ngươi cứ điềm nhiên không muốn phân biệt, không lo trừ hung, lại không dạy ISTD, chẳng khác nào quay mũi giầy mà xin đầu hàng, giơ tung váy mà chịu thua giặc. Nếu vậy, rồi đây, để thẹn muôn đời, há còn mặt mũi nào đứng trong cõi trời che đất chở này nữa? Cho nên ta viết bài hịch này để các ngươi hiểu rõ bụng ta.

Đặng (kuốk) Tuấn.
Share:

Monday, April 6, 2020

01. Phân tích đề xuất “Chữ Việt Nam song song 4.0” và tại sao không nên cải tiến chữ Việt

Phi lộ:  Qua thống kê sơ bộ trên Google đã có 57 tờ báo điện tử và 218.000 liên kết viết về “Chữ Việt Nam song song 4.0”. Trên Facebook đã có rất nhiều tranh luận về chủ đề này trong thời gian từ 1/4/2020 cho đến nay (6/4/2020), đa phần là các phản đối kịch liệt, thậm chí có nhiều ý kiến khá tiêu cực và có cả những bình luận dùng các từ ngữ mang tính chất thóa mạ tác giả. Các bình luận chủ yếu là: đề xuất mới của chữ Việt không đẹp, rắc rối và gây nhiều tốn kém khi chuyển đổi, rồi cả nước đang phải gồng mình chống giặc Covid-19, sao phải tốn nhiều giấy mực cho chủ đề không có tính thực tiễn như này...Trước đây người viết đã từng nói chuyện trên Facebook với tác giả Trần Tư Bình và nhận thấy anh là một người rất tâm huyết đối với tiếng Việt, qua truyền thông tôi cũng được biết hai tác giả vẫn rất kiên trì theo đuổi mục tiêu đưa đề xuất mới vào cuộc sống. Tiếc là chưa có ai chỉ ra cho các tác giả sự thiếu khoa học (cả về góc độ ngôn ngữ học lẫn chuẩn hóa trong Công nghệ thông tin) và tính không khả thi bằng các lập luận cụ thể và chi tiết. Bài viết này có mục đích nhằm phân tích về đề xuất mới trên các khía cạnh chuyên môn và khia cạnh bất khả thi dựa trên những kinh nghiệm thực tế liên quan đến tiếng Việt của người viết trong suốt thời gian từ năm 1990 đến nay (Bài đã được trích đăng trong Tạp chí Tia Sáng [4]).


I.Sơ lược về "Chữ Việt Nam song song 4.0"- CVNSS4.0


CVNSS4.0 là Bộ chữ Việt do hai tác giả Trần Tư Bình và Kiều Trường Lâm đề xuất, CVNSS4.0 đã được cấp bản quyền sở hữu trí tuệ [1]. CVNSS4.0 gồm 3 thành phần: Chữ quốc ngữ (CQN) hiện hành, Chữ viết nhanh và Ký hiệu dấu.

a. Chữ viết nhanh (CVN) - Tác giả Trần Tư Bình

Gồm 5 nhóm quy tắc: 
  1. Bỏ dấu sắc ở các từ có các phụ âm cuối c,p,t,ch. 
  2. Thay Y ->I và thay UY ->Y
  3. Đổi một số phụ âm đầu 2 ký tự bằng 1 ký tự như PH->F; KH->K; GH->G; NGH,NG->W...
  4. Đổi một số phụ âm cuối 2 ký tự bằng 1 ký tự: NG->G; CH->K. 
  5. Rút gọn 52 nguyên âm có 3-4 ký tự thành nhóm 2 ký tự: uyết->yd, uyên->yl...

b. Ký hiệu dấu (KHD) - Tác giả Kiều Trường Lâm

  1. Quy ước ký hiệu dấu sắc, huyền, hỏi, ngã, nặng->J, L, Z, S, R; khi có dấu mũ thì ký hiệu dấu đổi thành B,D,Q,G,H; khi có dấu trăng thì ký hiệu dấu đổi thành X, K, V, W, H.
  2. Ký hiệu cho dấu mũ trong /â, ê, ô/, là Y, dấu trăng và móc trong /ă, ơ, ư/ là O và không dấu là P.

c. Các khẳng định của các tác giả

  • c1: CVNSS4.0 ngắn gọn hơn chữ Việt hiện hành.
  • c2: CVNSS4.0 chỉ dùng 26 ký tự tiếng Anh để viết nên không cần bộ gõ chuyên dụng như Vietkey, Unikey mà dùng luôn bộ gõ tiếng Anh có sẵn.
  • c3: Gõ nhanh hơn 25-30% so với bộ gõ Telex hay VNI.
  • c4: Có độ chính xác cao.

II. Phân tích chuyên môn về CVNSS4.0


a. Phân tích ngữ âm học

Theo lý thuyết về ngữ âm học, có 2 hệ thống biểu hiện ngôn ngữ bằng chữ viết [3]:

  1.  Loại "Tượng ý":  trong đó từ được biểu hiện bằng một ký hiệu duy nhất không có liên quan gì đến những âm thanh cấu tạo thành từ. Ký hiệu này có quan hệ với cả từ, gián tiếp có quan hệ với ý niệm mà từ biểu hiện. Ví dụ của loại này là văn tự của chữ Hán. Chữ Việt không xếp vào nhóm này.
  2. Loại “Ngữ âm học”, là loại tái hiện chuỗi âm thanh nối tiếp nhau trong từ. Các hệ thống chữ viết ngữ âm học có thể ghi âm tiết hay ghi âm tố, nghĩa là căn cứ vào những yếu tố không chia nhỏ hơn được nữa trong lời nói. Tiếng Việt nằm trong nhóm này.
Có thể dễ dàng nhận thấy CVNSS4.0 không tuân thủ cấu trúc của tiếng Việt theo quy tắc ngữ âm học:
  1. CVNSS4.0 không tuân thủ các hệ thống âm vị của tiếng Việt: Gồm 22 hệ thống âm đầu, 1 âm đệm, 16 âm chính (13 nguyên âm đơn và 3 nguyên âm đôi), 8 âm cuối, 6 thanh điệu, CVNSS4.0 chính xác là phương pháp gõ tắt và quy ước đổi dấu thành ký tự latin. Ví dụ quy tắc CVN.1 loại bỏ luôn thành phần thanh điệu (không có).
  2. CVNSS4.0 không tuân thủ ký hiệu ngữ âm dùng để ký âm tiếng Việt và có khá nhiều nhập nhằng về ký hiệu ngữ âm. /i/ đứng riêng thì ký âm như chữ /i/ hiện hành, nhưng khi viết /id/ thì lại là /yêt/. Cùng là âm /t/ nhưng âm đầu vẫn ký hiệu là /t/ nhưng ở cuối nhiều chữ lúc là /t/ lúc khác lại là /d/.
  3. CVNSS4.0 sử dụng các ký hiệu không theo ký âm của ký âm thông lệ IPA quốc tế, ví dụ /w/ lại dùng để ký hiệu cho /ng/ hoặc /ngh/, ở phần bỏ dấu /w/ lại dùng để ký hiệu cho thanh điệu (dấu móc+ ngã).
  4. CVNSS4.0 không thể biểu diễn được dạng tổng hợp tiếng nói tiếng Việt ví dụ: bình thường chữ /tuyết/=/t/+/uyết/=/t/+/u/+/y/+/ế/+/t/, còn trong CVNSS4.0 thì /tuyết/=/tydb/.
Tóm lại CVNSS4.0 không tuân thủ cấu trúc của tiếng Việt và không thể sử dụng như là hệ thống ký âm tiếng Việt mà chỉ đơn thuần là hệ thống ký hiệu hay là quy tắc để viết tắt, gõ tắt, như vậy nó chỉ là là một phương pháp gõ chứ không thể là hệ thống chữ Việt có thể thay thế được hệ thống chữ Việt hiện hành.

b. Phân tích về phương diện Công nghệ thông tin

  1. Tính đơn trị: Một trong những nguyên tắc khi xây dựng hệ thống ký mã, hay một bộ tiêu chuẩn là phải bảo đảm tối đa tính đơn trị, và hàm số phải là song ánh giữa 2 tập, có nghĩa là hệ thống ký mã phải có tính một-một, ví dụ âm /a/ thì chỉ có mã duy nhất là 97, và 97 là mã duy nhất cho chữ /a/, cũng có nghĩa là chữ /a/ không thể lúc này là mã 97, lúc khác lại là mã 64, hay 97 không thể lúc này là chữ /a/ lúc khác lại là chữ /m/. Ở phương diện này CVNSS4.0 rất không tuân thủ tính đơn trị, riêng dấu thanh thì có đến 3 ký hiệu cho dấu sắc tùy theo nó đi với nguyên âm nào, lúc thì nó là /B/, lúc khác lại là /J/ lúc khác nữa lại là /X/, tương tự cho các dấu huyền, hỏi, ngã, nặng cũng có 3 ký hiệu khác nhau tùy khi nó kết hợp với chữ nào. Ở góc khác, ký hiệu /B/ lúc là phụ âm, lúc lại là dấu huyền. Tương tự cho rất nhiều ký hiệu khác nữa.
  2. Quá rắc rối, rối rắm, quá nhiều quy tắc cho những điều bất quy tắc: CVNSS4.0 vì không có tính đơn trị nên rắc rối và nhập nhằng trong ký hiệu, lúc ký hiệu có ý nghĩa này, lúc khác lại ý nghĩa khác tùy vào các trường hợp, tùy vị trí trong từ, tùy theo đi với chữ nào, buộc người dùng phải nhớ nhiều quy tắc và phải phân tích trong đầu trong khi gõ. Trong khi kiểu gõ Telex hay VNI thì chỉ cần 8 quy tắc đơn giản (5 cho dấu thanh, 3 cho các dấu mũ, trăng và đ) thì CVNSS4.0 cần đến 52 quy tắc, trong đó có nhiều quy tắc khá khó nhớ, buộc người dùng phải xử lý một thuật toán if-then khá lớn, tóm lại CVNSS4.0 khó nhớ, buộc tốn nhiều tài nguyên của trí não khi phải phân tích các trường hợp if-then...
  3. Tiết kiệm không gian lưu trữ và trên đường truyền: điều này đúng bởi CVNSS4.0 dùng quy tắc gõ tắt để giảm bớt 1 ký tự và trong 1 số ít trường hợp có thể giảm được 2 ký tự, ngoài ra do chỉ dùng 26 ký tự nên có thể dùng bộ mã 7-bit để mã hóa, không cần dùng đến bộ mã 16-Bit như tiếng Việt Unicode đang sử dụng. Tuy nhiên để tiết kiệm không gian nếu không tuân thủ các ký hiệu ký âm quốc tế thì có thể dùng mã Huffman thì sẽ tiết kiệm không gian triệt để hơn nhiều, trong thực tế người ta sẵn sàng trả giá về không gian lưu trữ để có tính dễ dàng cho người đọc hơn, vì thế người ta dùng ký hiệu chữ chứ không dùng các con số.
  4. CVNSS4.0 gõ năng suất và nhanh hơn: nếu không dùng các kỹ thuật nâng cao thì đúng là CVNSS4.0 gõ nhanh hơn vì sử dụng nhiều quy tắc gõ tắt (năng suất tăng 25-20% thì chưa có minh chứng), đổi lại người dùng phải trả giá: buộc phải nhớ nhiều quy tắc và phải liên tục phân tích các tình huống vị trí ký tự, kết hợp với ký tự trong từ...Trong thực tế có nhiều cách để nâng cao tốc độ gõ hơn rất nhiều, ví dụ Laban Key và các bộ gõ khác trên điện thoại di động có thể dùng AI hay thống kê xác suất để dự đoán và gợi ý từ thậm chí cả cụm từ mà CVNSS4.0 không thể nào so sánh được về tốc độ, tương tự với bộ gõ cho Desktop cũng có thể dùng kỹ thuật này để nâng cao tốc độ gõ văn bản. Ở một góc độ khác nếu không dùng các kỹ thuật thống kê và AI để dự đoán cả từ thì với một bộ luật gõ đơn giản người sử dụng có thể gõ với tốc độ rất nhanh (do não không phải xử lý thuật toán gõ tắt, if-then). 
  5. CVNSS4.0 chính xác hơn? Điều này cũng không đúng, vì CQN hiện hành nếu gõ đầy đủ dấu thì vẫn chính xác như thế, thậm chí có biểu đạt được nhiều phương ngữ vùng miền hơn, do CVNSS4.0 cũng giống như Bộ chữ của PGS. TS. Bùi Hiền đã cắt đi một số tổ hợp ký tự.
Theo các tác giả thì CVNSS4.0 có thành phần đầu tiên là Chữ Quốc ngữ (CQN) hiện hành và ngay chữ song song cũng có thể hiểu là CQN tồn tại song song với CVNSS4.0, như vậy mục tiêu của đề xuất chưa rõ ràng. Một mặt CQN được coi là tồn tại song song nhưng trong nhiều lập luận CVNSS4.0 lại có thể thay thế CQN vì các tác giả luôn so sánh CQN với CVNSS4.0 và khẳng định những ưu việt của CVNSS4.0, ngoài ra trong nhiều thể hiện chúng ta thấy có phiên bản CQN và phiên bản CVNSS4.0 tồn tại độc lập. Nếu tồn tại song song cả 2 hệ thống thì đó là một điều quá lãng phí, đã có bộ chữ tốt rồi lại thêm một bộ nữa làm gì để tốn kém tài nguyên của xã hội? Nếu không thay thế được thì không nên so sánh và cũng không thể gọi đề xuất là Bộ chữ Việt mới và không nên thể hiện là một phiên bản độc lập. Và như vậy đề xuất mới chỉ đơn thuần là một phương pháp gõ tắt mà thôi.

III. Phân tích về tính khả thi


Có thể khẳng định ngay CVNSS4.0 cũng như các cải tiến khác cho chữ Việt trong vòng hơn 100 năm trở lại đây đều không khả thi vì lợi ít-cập hại.

Đành rằng chữ Việt hiện tại có thể còn một số điểm chưa được tối ưu, còn một số điểm nhập nhằng (rất ít) ví dụ /c-k/, /d-gi/, một số chữ chưa phù hợp với ngữ âm quốc tế, nhưng nói cho cùng ngôn ngữ không phải là hệ thống định lý toán học mà nó là hệ thống quy ước xã hội, nhiều người dùng và nhiều người hiểu được thì đều chấp nhận được và sẽ trường tồn kể cả là chưa hợp lý hoặc kể cả là sai, điều này rất phổ biến trong hầu hết các ngôn ngữ khác trên thế giới.

Những đề xuất cải tiến nhằm tối ưu nhằm tăng năng suất đều mang lại lợi ích rất ít mà phá vỡ rất nhiều. Cải tiến và thay thế mới bộ chữ có thể tạo nên một đứt gãy về văn hóa, đặc biệt là con chữ theo thời gian sẽ trở thành biểu tượng, thành nét văn hóa, quốc hồn, quốc túy của cả một dân tộc. Tại sao các hệ thống chữ biểu ý vẫn tồn tại cho đến ngày nay mặc dù để viết và gõ nó tốn rất nhiều thời gian so với hệ thống chữ cái Latin? nhất là chữ Hán phồn thể, để viết 1 chữ có thể phải dùng tới hàng chục nét vẽ rất phức tạp. Đó là do chữ Hán trải qua hàng ngàn năm nó không chỉ bao hàm nét văn hóa lâu đời mà nó còn là biểu hiện cả tính nghệ thuật thư pháp, cả ý nghĩa triết học sâu sắc trong từng con chữ, vì thế để lưu giữ lại những điều này người ta sẵn sàng hi sinh sự tốn kém về không gian lưu trữ, sự phức tạp để viết-gõ nó.

Ngoài việc nếu sử dụng CVNSS4.0 thay thế CQN thì CVNSS4.0 sẽ không bảo tồn được các nét văn hóa của chữ Việt đã tồn tại hơn 100 năm qua thì giả sử nó có được triển khai thì cũng sẽ cực kỳ tốn kém. Tiết kiệm được một chút thời gian, một chút bộ nhớ lưu trữ thì lại tốn kém không thể kể xiết thời gian, công sức và tiền bạc để chuyển đổi hệ thống cũ sang hệ thống chữ viết mới. Phải thay đổi hoặc phải thêm toàn bộ hệ thống sách giáo khoa tất cả các cấp từ cấp 1 cho đến bậc đại học, phải đào tạo lại toàn bộ 97 triệu người Việt, phải thay đổi hoặc ban hành thêm hàng triệu văn bẳn pháp quy, giấy tờ, phải chuyển đổi hoặc lưu trữ thêm khối lượng cơ sở dữ liệu cực kỳ lớn tích lũy trong hàng chục năm qua, phải chuyển đổi hoặc in lại toàn bộ sách báo trong kho tàng tri thức của nước Việt. Đây chính là những lý do cốt tử mà các hệ thống cải tiến chữ Việt không thể triển khai được. Để có thể vượt qua được các rào cản như vậy thì chỉ có một chế độ độc tài muốn áp đặt với các mục tiêu chính trị, hoặc hệ thống mới phải cực kỳ ưu việt và có những lợi ích cũng cực kỳ to lớn mới có thể cân bằng được những tốn kém to lớn như vậy. Ngay tại Việt Nam mỗi lần đổi tên tỉnh, tách nhập tỉnh hay chỉ đơn thuần thêm chữ số hoặc thay đổi chữ số ở số điện thoại thôi là cũng gây nên đảo lộn rất nhiều vấn đề. Khi tiêu chuẩn về bộ mã ký tự tiếng Việt mới là TCVN 6909:2001 được ban hành thì tự nó vẫn chưa thể đi vào cuộc sống được và vẫn cần phải có văn bản có tính pháp lý cao có tính bắt buộc là Quyết định 72 của Thủ tướng chính phủ, yêu cầu từ ngày 1-1-2003 tất cả các cơ quan Nhà nước phải chuyển đổi sang dùng font chữ Unicode mà đến tận gần 10 năm, chúng ta mới cơ bản chuyển xong, mà đó chỉ là chuyển đổi mã, tất cả cách gõ và hình chữ đều như cũ, còn với CVNSS4.0 không chỉ thay đổi cách gõ, thay đổi dáng chữ mà còn thay đổi một thói quen hàng chục năm. Tóm lại nếu chuyển đổi và thay thế CQN thì CVNSS4.0 sẽ gây lãng phí rất lớn và bất khả thi, nếu nó chỉ là một phương pháp gõ tắt thì không cần phải dành quá nhiều tâm huyết đến như vậy, và sau khi gõ xong bắt buộc nó phải bung về CQN và như thế mọi lập luận về tính ưu việt của CVNSS4.0 không còn đúng nữa, và nếu đã là một cách gõ thì hãy để người dùng lựa chọn như cách họ lựa chọn giữa Telex và VNI vậy.


V. Không cải tiến chữ Việt thì có thể nghiên cứu vấn đề gì trong lĩnh vực ngôn ngữ?


Chữ Việt đã ổn định, các công cụ hỗ trợ tiếng Việt như font chữ, bộ gõ tiếng Việt cho đến nay đã được hầu hết các hãng sản xuất phần mềm và phần cứng tích hợp vào sản phẩm của mình như Windows, MacOS, Android, IOS cũng đều có sẵn bộ gõ tiếng Việt mà không cần phải cài đặt thêm phần mềm bộ gõ riêng (tuy nhiên với các bộ gõ riêng như Unikey, Vietkey thì sẽ có nhiều tính năng hơn: kiểm tra chính tả, chuyển mã, gõ tắt...).

Hiện nay ở Việt Nam có rất nhiều nhóm (viện, trường, doanh nghiệp) nghiên cứu các vấn đề về tiếng Việt và xử lý ngôn ngữ tiếng Việt, có thể liệt kê một vài bài toán cơ bản cho tiếng Việt: tách từ, phân loại tên thực thể từ, phân loại văn bản, tóm tắt văn bản, sinh văn bản, nhận dạng/tổng hợp tiếng Việt, nhận dạng chữ Việt, trích rút thông tin, chính tả tiếng Việt, dịch máy văn bản tiếng Việt sang các ngôn ngữ khác... Một số bài toán trong lĩnh vực tiếng Việt đã được giải quyết khá tốt và vẫn còn nhiều bài toán mới ở bước sơ khởi và còn nhiều thách thức: trích rút thông tin, tóm tắt văn bản, dịch máy...

 Vấn đề rất cần nghiên cứu hiện nay là gì?

Đó là các vấn đề liên quan đến việc giữ gìn và bảo tồn ngôn ngữ của đồng bào dân tộc thiểu số. "Tiếng nói, chữ viết là hồn cốt của một tộc người. Mất tiếng mẹ đẻ cũng tương tự với nguy cơ mất đi hồn cốt, bản sắc văn hóa của tộc người đó.." [2]. Nghị định số 82/2010/NÐ-CP của Chính phủ đã quy định việc dạy và học tiếng nói, chữ viết của dân tộc thiểu số trong các cơ sở giáo dục phổ thông, trung tâm giáo dục thường xuyên. Trong số 54 dân tộc thiểu số, có 24 dân tộc có chữ viết riêng của mình, còn lại nhiều dân tộc chưa có chữ viết. Trong số những dân tộc có chữ viết thì cũng nhiều dân tộc chưa được mã hóa, chưa có font chữ và bộ gõ trên máy tính. Không có chữ viết và font chữ thì rất khó để bảo tồn và duy trì ngôn ngữ đó. Không tạo được văn bản trên máy tính thì sẽ không quảng bá được trên Internet... Có một số đề tài khoa học trong nước đã tiến hành xây dựng cách viết cho một số ngôn ngữ chưa có chữ viết bằng việc sử dụng các ký tự Latin và sử dụng các tổ hợp ký tự tiếng Việt để tạo các ký tự chữ viết cho ngôn ngữ đó, nhằm hạn chế phải xây dựng font chữ và bộ gõ mới cho ngôn ngữ, tuy nhiên phương pháp này không tuân thủ theo ký mã ngữ âm quốc tế, rườm rà, và không bảo đảm tính đơn trị và tính nghệ thuật của chữ viết, cần phải có những nghiên cứu triệt để hơn nữa.

Vấn đề quan trọng nữa là các giải pháp xây dựng cách viết cho ngôn ngữ dân tộc thiểu số hiện nay thực hiện thiếu quy hoạch và đồng bộ, dẫn đến việc chồng lấn mã ký tự và chưa tương thích với nhau và chưa tương thích với tiêu chuẩn Unicode của thế giới. Thêm nữa các ký tự chữ viết dân tộc thiểu số dù đã được mã hóa hay chưa thì đa phần đều chưa được quy hoạch và chưa được đăng ký trong bản đồ ký tự Unicode thế giới, nếu không đăng ký, đề xuất sớm, kho ký tự Unicode càng ngày càng giảm và nếu có cũng phải sang các khu vực không thuận lợi, vì vậy việc làm cần thiết ngay trong việc bảo tồn ngôn ngữ của các đồng bào dân tộc thiểu số là quy hoạch tổng thể về chữ viết, xây dựng chữ mới cho các ngôn ngữ chưa có chữ viết và đăng ký bộ mã ký tự của các ngôn ngữ vào trong bảng mã Unicode.


VI. Kết luận


CVNSS4.0 có ưu điểm là ngắn gọn, chỉ dùng 7-Bit để ký mã, chỉ dùng các ký tự tiếng Anh không dấu và không cần bộ gõ riêng để gõ, tuy nhiên có nhiều điểm thiếu khoa học trong thiết kế, chưa tuân thủ cấu trúc ngôn ngữ tiếng Việt, không tuân thủ hệ thống ngữ âm quốc tế, không bảo đảm tính đơn trị, còn nhập nhằng và khó nhớ, phải xử lý nhiều tình huống theo vị trí trong từ, phụ thuốc vào việc kết hợp với các nguyên âm và cũng như các đề xuất khác có thể làm mất đi những giá trị văn hóa, quốc hồn quốc túy của con chữ đã được xây dựng hàng thế kỷ qua và cuối cùng là vô cùng tốn kém và làm đảo lộn đời sống văn hóa cũng như hệ thống pháp lý hiện hành. Nếu CVNSS4.0 không thể thay thế CQN và tồn tại song song thì giá trị của nó rất ít và nó chỉ đơn thuần là một phương pháp gõ tắt mà thôi.
Để phát huy tính sáng tạo trong lĩnh vực ngôn ngữ thì còn rất nhiều những vấn đề và thách thức đang chờ đợi những người có tâm huyết để giải quyết mà không nhất thiết phải đi cải tiến con chữ đã ổn định đã được cả dân tộc chấp nhận và yêu mến từ bao đời nay.


Thông tin trải nghiệm liên quan của người viếtTừ năm 1995 cho đến nay người viết đã được mời tham gia vào Tiểu ban kỹ thuật của Ban tiêu chuẩn Việt Nam trong lĩnh vực CNTT (Thuộc Tổng cục Đo lường Chất lượng), cũng là người dự thảo Tiêu chuẩn Việt Nam TCVN-6906:2001 Bộ mã ký tự 16-Bit tiếng Việt, và là một trong số những người có nhiều đóng góp trong việc đưa Unicode thành tiêu chuẩn Việt Nam và thống nhất bộ mã dùng chung trong toàn quốc (trước đó có đến 43 bộ mã, bộ font tiếng Việt khác nhau và không thể liên thông được với nhau). Gần như một mình đấu tranh trên truyền thông (trên Tạp chí PCWorld) để bảo vệ phương án ký tự dựng sẵn (mà chúng ta vẫn dùng từ 2002 đến nay) trước sự áp đặt mã tổ hợp từ phía Microsoft và các đối tác như Lạc Việt, VASC (nếu dùng phương án này chữ Việt tổ hợp sẽ chỉ dùng được trên nền tảng của Microsoft không tương thích với các hệ điều hành Linux, MacOS, Android, IOS). Từ năm 1991 người viết đã phát triển bộ gõ đầu tiên cho hệ điều DOS: TVNICP và bộ gõ cho chế bản điện tử TVENL (Dùng cho Ventura phiên bản DOS), sau đó năm 1994 phát triển bộ gõ Vietkey for Windows, năm 1998: Vietkey for Linux; năm 1999: Vietkey 4.0 là một trong các bộ gõ Unicode đầu tiên ở Việt Nam, năm 2000: Vietkey Office (chuyển mã tiếng Việt, kiểm tra chính tả và sắp xếp tiếng Việt tích hợp trong MS Word, Excel, Powerpoint; năm 2001: phát triển Vietkey4Palm (bộ gõ tiếng Việt đầu tiên cho hệ điều hành PalmOS). Người viết cũng đã từng tự vẽ và xây dựng 250 font truetype chữ Việt cho chế bản điện tử và font tiếng Việt cho PalmOS.

VII. Tài liệu tham khảo




Share:

Recent Posts

Definition List