- Ký pháp (Notation) là một công cụ quan trọng hỗ trợ tư duy, đóng vai trò cốt lõi trong cả toán học lẫn ngôn ngữ lập trình
- Ngôn ngữ APL được phát triển như một nỗ lực kết hợp ưu điểm của ký pháp toán học với tính khả thi khi thực thi và tính phổ quát của ngôn ngữ lập trình
- Đặc điểm của một ký pháp tốt gồm tính cô đọng, tính rõ ràng, tính gợi mở, khả năng ẩn bớt chi tiết và khả năng chứng minh hình thức
- Có thể biểu diễn và biến đổi hiệu quả nhiều cấu trúc toán học khác nhau (đa thức, phép biến đổi, đồ thị, v.v.) bằng APL
- Việc giới thiệu và học ký pháp nên diễn ra một cách tự nhiên trong ngữ cảnh, đồng thời tính cấu trúc và tính đa dụng của ký pháp cũng rất quan trọng
Ký pháp như một công cụ tư duy
- Trong các lĩnh vực khoa học như hóa học và thực vật học, hệ thống danh pháp có tổ chức cũng thúc đẩy sự phát triển của học thuật
- George Boole nhấn mạnh rằng bản thân ngôn ngữ là một phương tiện của tư duy
- Ký pháp toán học là ví dụ tiêu biểu của ngôn ngữ hỗ trợ tư duy, giúp giảm gánh nặng suy nghĩ và nâng cao năng lực tư duy
- A.N. Whitehead và Charles Babbage đã nhấn mạnh tầm quan trọng của ký pháp toán học
Tiềm năng của ngôn ngữ lập trình như một công cụ tư duy
- Ngôn ngữ lập trình có thế mạnh về tính đa dụng và tính rõ ràng
- Có thể thử nghiệm ý tưởng bằng máy tính và thực hiện các thí nghiệm tư duy một cách rõ ràng
- Tuy nhiên, phần lớn ngôn ngữ lập trình vẫn yếu hơn ký pháp toán học khi đóng vai trò công cụ tư duy
- APL được thiết kế như một ký pháp hỗ trợ tư duy, hướng tới tính minh bạch và độ chính xác
Những đặc tính chính của một ký pháp tốt
- Dễ biểu đạt vấn đề: phải có khả năng biểu diễn dễ dàng những cấu trúc nảy sinh trực tiếp từ bài toán
- Tính gợi mở: dạng biểu diễn phải gợi ra những bài toán tương tự hoặc mở rộng
- Ẩn bớt chi tiết: cung cấp cấu trúc giúp đơn giản hóa các chi tiết phức tạp để hỗ trợ tư duy
- Tính cô đọng: phải cho phép biểu đạt phạm vi rộng chỉ với số ít ký hiệu và quy tắc
- Khả năng chứng minh hình thức: ký pháp phải thuận tiện cho chứng minh hình thức và suy luận diễn dịch
Giới thiệu các kỹ thuật ký pháp cơ bản của APL
- Tự nhiên sử dụng các cấu trúc dựa trên mảng như vector và ma trận
- Hàm và toán tử được áp dụng tự động theo từng phần tử lên vector/ma trận
- Biểu diễn tổ hợp hàm bằng các toán tử như reduction(
/), scan(\) và inner product(.) - Có thể tạo nên các biểu thức phong phú bằng những ký hiệu cơ bản như
⍳,⌽,⍴,+,×,* - Mọi hàm đều tuân theo quy tắc ưu tiên bên phải, cho phép viết biểu thức tự nhiên mà không cần ngoặc
Ví dụ về giải quyết vấn đề và thúc đẩy tư duy
- Biểu diễn các dãy toán học như số tam giác và giai thừa bằng những công thức đơn giản
- Xử lý ngắn gọn các phép toán như biểu diễn đa thức, nhân và vi phân theo những quy tắc nhất quán
- Lý thuyết đồ thị (cây, bao đóng bắc cầu, cây khung) cũng có thể được biểu diễn rõ ràng bằng phép toán trên mảng
- Có thể mở rộng sang nhiều lĩnh vực như hoán vị, đại số Boolean và chuyển đổi hệ số (phân tích thừa số nguyên tố)
Chứng minh hình thức và tư duy có cấu trúc
- Mọi phép toán và biểu thức đều được biểu diễn ở dạng có thể thực thi rõ ràng, nên có thể kiểm chứng tự động bằng máy tính
- Đưa ra nhiều ví dụ chứng minh hình thức bằng quy nạp toán học, vét cạn và liệt kê đẳng thức
- Trình bày chứng minh hình thức cho tính phân hoạch (identity) của reduction và scan, cũng như tính kết hợp và phân phối của phép inner product
- Chứng minh trực tiếp các công thức về hàm đối xứng Newton, nhân đa thức và vi phân
So sánh APL với ký pháp toán học truyền thống
- APL cung cấp định nghĩa hàm rõ ràng, phép toán trên mảng nhất quán và hệ ký hiệu phong phú
- Áp dụng quy tắc thực thi ưu tiên bên phải cho mọi phép toán thay vì hệ thứ tự ưu tiên truyền thống
- Giảm độ phức tạp khi sử dụng ký hiệu toán học và hỗ trợ formal manipulation
- Cú pháp cô đọng, quy tắc nhất quán nên có lợi cho cả người mới lẫn người dùng thành thạo
Cách giới thiệu và học ký pháp
- Nhấn mạnh cách giới thiệu tự nhiên những ký pháp cần thiết trong ngữ cảnh, không cần các “bài giảng ngôn ngữ” riêng biệt
- Học trực quan các ký hiệu mới trong những tình huống bài toán cụ thể
- Điều quan trọng không phải là độ khó của bản thân ký pháp, mà là nhận ra những khả năng và tính mở rộng đa dạng mà ký pháp gợi ra
Khả năng mở rộng và đề xuất cho APL
- Đề xuất mở rộng hàm để xử lý cả số phức
- Cần chuẩn hóa hàm unique elements và hàm summary
- Có thể hỗ trợ thêm các chủ đề như giải tích vector bằng cách đưa vào các toán tử tổng quát hơn
- Mục tiêu là nâng cao tính rõ ràng trong thiết kế ngôn ngữ và năng lực suy luận
Cân bằng giữa hiệu quả và tính rõ ràng
- Khuyến nghị trước hết xác định một ký pháp rõ ràng, dễ phân tích, rồi sau đó tăng hiệu quả bằng tối ưu hóa
- Việc làm sáng tỏ thuật toán cũng giúp cho tối ưu hóa về sau và tối ưu hóa ở trình biên dịch
- Biểu đạt cơ bản được viết bằng APL có tiềm năng đóng góp cho cả nghiên cứu học thuật lẫn ứng dụng công nghiệp
1 bình luận
Ý kiến trên Hacker News
Dễ xem ký pháp chỉ như “thay thế một biểu thức bằng một biểu thức khác”, giống như mở rộng shell, nhưng thực ra nó sâu sắc hơn nhiều
Giáo sư của tôi từng giải thích rằng những khám phá vĩ đại thường xuất hiện cùng ký pháp mới; ký pháp mới nghĩa là “một cách mới để suy nghĩ về vấn đề này”
Tôi cho rằng nhiều bài toán chưa giải được ngày nay cũng có thể được giải nếu xuất hiện một ký pháp mạnh mẽ
Điều này thật sự rất mạnh, nhưng gần với kiểu Lisp; còn APL hay Clojure thì nghiêng về việc làm cho các kiểu cơ bản trở nên thật sự hữu dụng
Thay vì 10 cấu trúc dữ liệu, mỗi cái có 10 hàm, thì là 1 cấu trúc dữ liệu với 100 hàm; trong APL, thay vì tạo DSL, nếu thiết kế và sắp xếp dữ liệu thật cẩn thận thì phần còn lại sẽ tự khớp vào
Khi còn là thiếu niên học lượng giác, Richard Feynman không thích ký pháp của sin và cos nên đã tạo ra các ký hiệu toán học riêng để làm công thức đơn giản hơn và giảm nhiễu
Về sau, ông cũng đồng thời tạo ra cách suy nghĩ và cách biểu diễn mới cho vật lý, như biểu đồ Feynman hay slash notation
Một ví dụ nhỏ là khi CoffeeScript xuất hiện, nhờ cách viết tắt lambda và nhiều tiện ích cú pháp khác, cách dùng JavaScript đã thay đổi đáng kể, trở nên dễ nghĩ, dễ đọc và dễ sửa hơn
Các họ SML/Haskell và Lisp cũng cho cảm giác tương tự
Có lẽ bạn cũng sẽ thích đoạn clip ngắn của Brian Greene và Barry Mazur: https://youtu.be/8wQepGg8tHA
Về mặt lịch sử, thứ đẩy APL ra ngoài không chỉ là bàn phím kỳ quặc, mà còn là Lotus 1-2-3 của IBM và MS Excel xuất hiện ngay sau đó
Các kỹ sư, giới học thuật, kế toán và MBA cần một công cụ tốt hơn TI-59 hay HP-12C, trong khi phía khoa học máy tính lại mải mê với xử lý ký hiệu, AI và LISP, cuối cùng ngành công nghiệp đã chiếm lấy vị trí đó
Thật là một sự tình cờ đáng tiếc, vì APL lẽ ra có thể có ảnh hưởng lớn hơn nhiều so với bảng tính và giải quyết được nhiều vấn đề hơn
Tầm nhìn ban đầu là một ký pháp toán học nhất quán, có thể thực thi và viết tay được, nhưng rốt cuộc chưa bao giờ đạt được
Nếu quan tâm, bài này đáng đọc: https://mlajtos.mu/posts/new-kind-of-paper
Bạn có thể giải quyết vấn đề mà không phải trả tiền, và chi phí phát sinh khi phân phối kết quả biên dịch cho khách hàng trả phí
Nếu lời giải khớp với một tập con cụ thể, bạn cũng có thể chuyển sang April và cung cấp qua Common Lisp
Tuy vậy, những người trong giới APL nhìn chung rất học thuật; họ có thể làm công việc kỹ thuật nhanh và súc tích, nhưng nếu trong một công ty phần mềm bình thường mà bạn bắt đầu nói về thứ hạng hàm hay hàm tử Naperian, đồng nghiệp có thể nghi ngờ bạn cần trợ giúp y tế
Một phần đáng kể của phát triển phần mềm là phát minh ra một ngôn ngữ kỹ thuật khá hình thức để biểu đạt cách khách hàng và người dùng nói cũng như suy nghĩ; trong các ngôn ngữ họ Iverson, việc này không dễ
Java trong thời gian dài buộc mỗi phương thức phải nêu rõ những từ ngữ nghiệp vụ nào đi vào và đi ra, và ở điểm đó việc ánh xạ các khái niệm của tổ chức vào mã trở nên dễ hơn
Trong APL cũng có thể đặt tên cho dữ liệu và hàm, nhưng ngay khi đưa các tên dài và cấu trúc namespace vào để ánh xạ tổ chức bên ngoài vào mã, nó sẽ mất đi sự súc tích và thanh nhã
Ngay cả trong các hệ thống kiểu tinh vi của họ ML, lập trình viên cũng gặp khó khi kết nối trực tiếp ontology bán ngôn ngữ do họ phát minh với tổ chức và quy trình, và thường chọn các khái niệm mang tính toán học hoặc học thuật hơn
Nếu có người làm được cả hai phía thì điều đó là khả thi, nhưng thông thường chỉ cần làm tốt việc dịch sang thế giới của khách hàng đã là đủ trong nhiều trường hợp
Năm ngoái The Array Cast đã đăng lại cuộc phỏng vấn Iverson năm 1982: https://www.arraycast.com/episodes/episode92-iverson
Khá thú vị và dễ tiếp cận hơn bài giảng Turing
APL năm 1979 không phải là một ngôn ngữ kỳ lạ và bên lề như ngày nay
Khi đó các ngôn ngữ lập trình chưa phải hiện tượng đại chúng toàn cầu như bây giờ, nên gần như tất cả đều khá kỳ lạ và bên lề; C lúc ấy cũng còn khá mới
Nhìn rộng lượng một chút, APL trông như một mức trừu tượng không quá xa C cô đặc, cho phép lập trình máy tính mà không phải tự triển khai thao tác con trỏ trên mảng
Cũng có khá nhiều giáo trình học toán bằng cú pháp APL [1] hoặc J [2]
Ban đầu Iverson dùng APL như một cú pháp tốt hơn cho toán học, còn bản triển khai lập trình xuất hiện vài năm sau đó
[1] https://alexalejandre.com/about/#apl
[2] https://code.jsoftware.com/wiki/Books#Math_for_the_Layman
Trước đây tôi từng nghe một podcast về lý thuyết kiểu nay đã ngừng, nội dung cực kỳ khó hiểu
Khái niệm cơ bản được nối tiếp với những khái niệm hữu ích khác
Giả thuyết Sapir-Whorf cũng tương tự, nhưng thú vị hơn khi nghĩ theo chiều ngược lại
Trong một ngôn ngữ không hoàn hảo, có những điều không thể nghĩ tới hoặc khó nghĩ tới; nếu vậy, ta sẽ tự hỏi liệu có những điều mà ngôn ngữ ta dùng không thể biểu đạt cũng như không thể tư duy hay không
Ở đây, “ngôn ngữ” và “suy nghĩ” có thể được hiểu rộng hơn bình thường
Ví dụ, liệu các quy tắc tương tác xã hội có quyết định cách chúng ta tương tác không? Trong “Twitter and Teargas”, Zeynep Tufekci nói rằng Twitter khiến flash mob trở nên khả thi, nhưng lại làm cho thay đổi xã hội bền vững trở nên khó khăn
Những cơ chế xã hội như theo dõi ai đó, bình luận hay bấm thích có quyết định hoặc cho phép cách chúng ta tương tác với nhau không? Có thể những cơ chế khác sẽ cho phép tư duy tập thể tốt hơn
Còn có cả âm nhạc nữa. Không phải ký pháp, mà là liệu âm nhạc có biểu đạt điều gì đó khó có thể biểu đạt tốt bằng cách khác hay không?
Với tư cách một người đã học nhiều ngoại ngữ, có rất nhiều điều tôi chỉ có thể nghĩ bằng một ngôn ngữ nhất định và khó nghĩ bằng tiếng Anh, tiếng mẹ đẻ của tôi
Ví dụ, từ “гулять” trong tiếng Ukraina và tiếng Nga mang nhiều sắc thái mà tiếng Anh không nắm bắt được, nên trước khi học các ngôn ngữ đó, tôi chưa từng nghĩ đến những sắc thái ấy
“Гулять” theo nghĩa đen là “đi bộ”, nhưng cũng được dùng với nghĩa đi tìm trải nghiệm, bao gồm cả trải nghiệm tình dục
Người ta có thể phàn nàn rằng ai đó kết hôn quá sớm là “не нагулялся”, tức là “chưa đi bộ đủ”
Trong tiếng Anh cũng có những cách nói tương tự như “sow his wild oats”, nhưng khi một động từ “đi bộ” chứa nhiều ý nghĩa như vậy, chính cách nghĩ về việc bước đi trong đời cũng thay đổi
Khi học tiếng Ả Rập cũng vậy, có nhiều ý nghĩa và suy nghĩ chỉ nảy sinh trong ngôn ngữ đó; không phải vì không thể giải thích bằng tiếng Anh, mà vì không có một ký pháp để diễn đạt ngắn gọn nên cần một bài viết dài
Có người thích du hành sang những suy nghĩ khác thông qua ngôn ngữ, có người lại bị tê liệt trước khả năng đó
Như mọi khi, thành công nằm ở sự cân bằng và ở cả hai phía
Dù đây là một sự thật quá hiển nhiên đối với nhà toán học hay nhà khoa học máy tính, ý tưởng này lại rất gây tranh cãi trong giới ngôn ngữ học và “nhà giáo dục”
Tương tự trong ngôn ngữ học là giả thuyết Sapir-Whorf, cho rằng ngôn ngữ bạn học quyết định cách bạn tư duy
Ngôn ngữ tự nhiên là một đối tượng văn hóa, và việc ánh xạ các nền văn hóa, dù chỉ theo một thứ tự bộ phận yếu, bị xem gần như điều cấm kỵ trong giới học thuật
Điều này cũng có hệ quả lớn với giáo dục, vì có trường hợp học sinh không được học thứ ký pháp giúp họ thật sự suy luận về các vấn đề họ gặp
Thành thật mà nói, tôi không hiểu rõ phần này
Việc người nói bất kỳ ngôn ngữ nào cũng có thể học cùng một môn toán hay chương trình máy tính đã cho thấy điều đó
Cũng đáng nghi ngờ liệu ngôn ngữ nói hay viết có thật sự cần thiết cho tư duy hay không
Ít nhất có những phạm vi lớn của tư duy có thể tồn tại không cần ngôn ngữ; con người cũng từng có thời không có lời nói hoặc có rất ít, và những suy nghĩ cùng ý định muốn giao tiếp đã tạo ra từ ngữ và ngôn ngữ
Vì vậy, xem ngôn ngữ đã học là mô hình cơ bản của tư duy khiến tôi thấy kỳ lạ
Ví dụ, có người lập luận rằng nếu một xã hội gọi màu biển và màu cỏ bằng cùng một từ, thì họ không thể trải nghiệm sự khác biệt giữa hai màu đó
Không chỉ là họ mã hóa trải nghiệm thành ký ức theo cách tương tự, mà là họ không nhìn thấy sự khác biệt
Lập luận rằng những âm không có trong một ngôn ngữ thì hoàn toàn không nghe được cũng tương tự
Cuộc thảo luận về ký pháp ở đây gần với ý rằng từ vựng có thể được dùng để khám phá hơn
Tức là không chỉ nói rằng đã nghe một âm thanh nào đó, mà có thể nói rằng đã nghe âm nhạc, đã nghe một chuỗi hòa âm cụ thể, v.v.
Hiện tôi đang phát triển một dự án bằng APL
Đây là việc đã nằm trong backlog từ lâu, nhưng giờ tôi đang thực sự viết code
Có một khoảng thời gian khá dài giữa lúc tôi bắt đầu quan tâm và lúc có thể viết được nhiều hơn những chương trình một dòng
Ở giai đoạn đầu của quá trình đó, tôi tìm thấy bài luận này và đọc như thể hấp thụ nó; giờ các khái niệm ấy đã trở thành nền tảng hoàn chỉnh cho tư duy của tôi
Thực tế là tôi đang dạy NAATOT trong một chương trình kiến trúc
Không phải kiến trúc phần mềm, mà là thiết kế kiến trúc
Tôi dùng một phiên bản đã biên tập để giữ lại phần cốt lõi của Iverson, còn phần toán học và lập trình thực tế chỉ được giữ vừa đủ để cho thấy điểm chính và thách thức sinh viên nghĩ khác về khả năng của thiết kế và công cụ biểu đạt
Nói cách khác, nó bàn về quá trình hình thành ý tưởng, cách biểu đạt với chính mình và với người khác
Nếu có cơ hội làm trong một chương trình lỏng hơn và cởi mở hơn, tôi muốn thử vận hành một lớp học nơi sinh viên tạo ra hệ thống ký hiệu/ký pháp của riêng họ để áp dụng vào lĩnh vực thiết kế kiến trúc
Tôi tiếc là đã không hoàn thành ứng dụng ghi chú Freeform mà trước đây mình đang làm
Đó là một ứng dụng được biên dịch thành trang web độc lập thông qua SVG, và tôi nghĩ nó là một ý tưởng thật sự tuyệt vời cho các nội dung kỹ thuật thường gặp trong lĩnh vực STEM
Ví dụ ghi chú hóa học cũ ở đây: https://colbyn.github.io/old-school-chem-notes/dev/chemistry-1010---fall-2021/week-14-acids-and-bases.html
Tôi tò mò hiện giờ họ đang dùng hệ thống nào
Trong vài năm, tôi xem APL như một dạng phép thuật, rồi đầu năm nay đã dành thời gian học nó
Điều khiến tôi ngạc nhiên là với APL, bạn có thể nhét một lượng mã cực kỳ lớn vào chỉ một tweet
Thú vị, nhưng khó viết
Viết xong hầu như lúc nào tôi cũng nghĩ “mất lâu thế này để viết cái này sao?” và tự hỏi có lẽ mình nên dùng công cụ khác
Nhưng thực tế là việc dùng công cụ khác sẽ mất thời gian hơn nhiều, điều này lại khá trái với trực giác
Phần khiến nó có vẻ khó và tốn thời gian thực ra là quá trình bị buộc phải sắp xếp đặc tả bài toán theo một cách cô đọng hơn
Giống như leo một con đường dốc hơn nhưng ngắn hơn rất nhiều: cảm thấy vất vả hơn, nhưng thực tế là ít việc hơn
Vì vậy tôi nghĩ mình nên học và dùng APL
Cá nhân tôi không đồng ý với tiền đề của bài luận rằng “ký hiệu toán học thiếu tính phổ quát và phải được diễn giải khác nhau tùy theo chủ đề, tác giả và ngữ cảnh”
Tôi cho rằng ký hiệu tách rời khỏi trực quan hóa vấn đề và công thái học có cái giá rất lớn
Một số học giả ưa chuộng các ký hiệu che giấu nhiều độ phức tạp để có thể tạo ra những khoảnh khắc giác ngộ kiểu “eureka” hoặc các tương đương bất ngờ, nhưng trong một số trường hợp điều đó lại khiến mọi thứ mờ mịt và dễ sinh lỗi
Dù vậy, đúng là nó vẫn là một công cụ quan trọng để truyền đạt quá trình tư duy
Tôi nghĩ việc chỉ có một ký hiệu chuẩn cho một lĩnh vực hoặc các lĩnh vực gần nhau sẽ kìm hãm khá nhiều khía cạnh sáng tạo, nghệ thuật và khám phá trong suy luận và giải quyết vấn đề
Terry Tao cũng có một phần giải thích rất hay về ký hiệu: https://news.ycombinator.com/item?id=23911903
Trong toán học có những nỗ lực xây dựng các hệ thống suy luận “enterprise” như Lean, Coq, và trong những trường hợp như vậy thì một hệ ký hiệu phổ quát là hợp lý
Nhưng nếu là khám phá cá nhân, việc ghép bất cứ thứ gì phù hợp vào có khi lại tốt hơn
Cá nhân tôi thấy điều này khó khăn hơn trong giáo dục
Trong các lớp như đại số, nếu giáo viên không xử lý các quyết định và sở thích cá nhân về ký hiệu một cách nhất quán hoặc thẳng thắn thì rất khó theo, và khi học lý thuyết kiểu cùng lý thuyết chứng minh cơ giới, năng lực toán học của tôi đã cải thiện đáng kể
Tôi nghĩ khái niệm “sự lệ thuộc của chi tiết” trong bài luận chưa được đào sâu đủ
Sau một thời gian dài đọc và viết ứng dụng APL, tôi nhận ra khái niệm này chỉ một cách quản lý độ phức tạp về căn bản khác với trừu tượng hóa
Chúng ta bị bao quanh bởi các rào chắn trừu tượng như API, thư viện, mô-đun, package, interface, và kết quả là những vấn đề quen thuộc như các tòa tháp trừu tượng hóa cao, lập trình viên chỉ ghép API, sự tách rời khỏi phần cứng, và khó suy luận về hiệu năng
APL khiến một cách tiếp cận khác trở nên rất thuận tiện
Thay vì thiết kế các trừu tượng, ta thiết kế dữ liệu một cách cẩn thận để có thể dễ dàng thao tác bằng các biểu thức đơn giản
Tức là dùng trực tiếp các phép toán nguyên thủy ở những chỗ thường sẽ có hàm thư viện hoặc thuật ngữ DSL
Chẳng hạn, có thể tạo một cấu trúc giống hashmap với các giá trị vector và các khóa đã nội hóa bằng bảng chuỗi, mảng khóa, mảng giá trị, rồi xử lý trực tiếp việc chèn, xuất, xóa bằng biểu thức APL
Điểm hay của cách này là mỗi biểu thức không phải là hộp đen, nên có thể điều chỉnh tự nhiên theo nhu cầu cụ thể
Nếu là thao tác chèn hashmap thông thường thì sẽ cần mã để thêm khóa mới, nhưng ở đây ta tận dụng bất biến chung rằng chỉ cần thêm giá trị vào khóa đã có
Nếu là API thư viện, hẳn sẽ cần các nhánh mã không dùng đến, nhiều biến thể hàm chèn, hoặc suy luận kiểu tinh vi để loại bỏ mã chết
Cách tiếp cận như vậy làm các mối quan tâm không liên quan đến miền bài toán rò rỉ vào codebase
Nếu bắt các chi tiết lệ thuộc thay vì che giấu chúng, ta có thể truy cập các chi tiết đặc thù miền ở mức cần thiết, còn các chi tiết không liên quan thì lặng lẽ nằm ở nền cho đến khi cần
Dĩ nhiên phải rất quen với biểu thức APL, nhưng tôi không nghĩ gánh nặng đó lớn hơn nhiều so với việc học sâu một hệ sinh thái như Python
Trên thực tế, các ký hiệu APL dần biến mất vào hậu cảnh, và bắt đầu hiện ra như những cụm cú pháp có nghĩa, giống như đọc tiếng Anh theo từ và cụm từ chứ không phải theo từng chữ cái
Trong hầu hết ngôn ngữ thì điều này là bất khả thi, nhưng nếu ngôn ngữ đủ súc tích và biểu đạt mạnh thì nó lại trở nên khả thi trên một phạm vi khá lớn
Tôi luôn nhớ đến ý nghĩ rằng Arthur Whitney cực kỳ ghét phải cuộn màn hình
Cũng không cần mở 20 file rồi lần theo “đi tới định nghĩa”
Khi toàn bộ chương trình nằm gọn trên một trang, những thứ đó biến mất, và ta điều hướng bằng chuyển động của mắt
Tôi thật sự cảm thấy cần dành thời gian học nó
Nó cũng liên hệ sâu sắc với những khó khăn tôi trải qua trong vài tuần gần đây
Tôi đang xem một đoạn mã Python legacy bị kết dính quá chặt, và mọi nỗ lực “cải thiện” trước đây đều là kiểu chất thêm trừu tượng lên trên một mô hình dữ liệu sai
Đọc mã theo tuyến tính thì không thể biết phương thức nào sẽ thay đổi đối tượng đầu vào
Có cái thay đổi, có cái không, đôi khi còn trả về nguyên đối số đầu vào đó mà không thay đổi gì
Thà có các chuỗi ma thuật có thể phân tích và hiểu được còn hơn là một biển đường vòng nơi factory trả về nhiều calculator thậm chí không chia sẻ cùng một interface
Vì mọi thao tác đều là O(n)
Có thể dùng các toán tử chung, nhưng vẫn phải hiểu cẩn thận các cặp giá trị có nghĩa gì trong logic miền, và làm thế nào để duy trì cấu trúc đúng trong từng thao tác
Người đọc chương trình lần đầu cũng sẽ gặp khó khăn tương tự trong việc hiểu ý nghĩa nghiệp vụ của miền, chứ không phải các phép toán nguyên thủy
Nếu có cải thiện, tôi nghĩ đó không phải vì đặt độ phức tạp ở nơi khác, mà vì mã và các giá trị thực tế cùng lúc hiện ra trước mắt
Điều làm lập trình phức tạp trở nên dễ hơn là thấy dữ liệu lúc chạy và thao tác mã đặt cạnh nhau, vì vậy các công cụ IDE vẫn liên tục cải thiện debugger và inspector để cho thấy chương trình đang làm gì ở từng bước
Trong bối cảnh này, dù trừu tượng hóa một phần thao tác hay một phần cấu trúc dữ liệu, việc tạo ra một trừu tượng mới tốt và súc tích vẫn là điều tốt
Mã chèn trong ví dụ phần lớn không phải là thao tác thêm mong muốn, mà là dọn dẹp dữ liệu để biến dạng mà interpreter cho nhập thành dạng cần thiết
⍪←mới là thao tác thêm thực sự, còn↓⍉↑()()()gần với việc phân tích và chuyển đổi đầu vào để vòng qua giới hạn của APL và parser đầu vào của interpreterMã xóa cũng phải tạo các mảng Boolean không liên quan đến miền vấn đề, chẳng hạn như bọc
'buggy'để tìm nó như một phần tử đơn trong mảng lồng nhauCách nói “tạo hashmap của các giá trị vector” cũng gây hiểu lầm vì thực tế không có hashing
Không có kiểm tra khóa trùng, không thể chọn hash hay điều chỉnh tốc độ và phân bố, và khóa được nối thêm theo thứ tự nên việc tìm kiếm cũng chậm
Dyalog APL cũng có I-Beam 1500, một lệnh interpreter ma thuật để đánh dấu mảng làm đối tượng hashing nội bộ nhằm tra cứu nhanh, nhưng phải luôn nhớ rằng trừu tượng nội bộ đang bị rò rỉ
APL thiếu những ý tưởng tốt trong thiết kế ngôn ngữ và công cụ như “pit of success”, “chỉ có một cách”, “cách đầu tiên nghĩ ra nên là cách đúng”, “việc khác nhau nên trông khác nhau”
Trong Python hay C#, cú pháp như
kv={'a':1, 'b':2}cứ thế hoạt động; nếu quên ngoặc hoặc dấu hai chấm thì nhìn rõ là sai, và trình soạn thảo cùng compiler sẽ hỗ trợTriển khai APL phụ thuộc vào các hàm interpreter ma thuật như
⎕NGET,⎕CSV,⎕JSONcho nhập xuất, và cũng yếu về xử lý lỗi, logging, debuggingToàn bộ biểu thức được chạy như một khối, và do hook cùng fork nên cũng khó tách nhỏ dễ dàng
Cuối cùng, chỉ khi cảm nhận chính xác được nhiều hình dạng mảng khác nhau, vì sao
⊂3trông như không làm gì, khác biệt giữa⊆và⊂, scalar extension, v.v. thì mới có thể thử nghiệm và học đượcNgay cả những pattern có vẻ truy cập tức thì như “nếu có khóa thì cập nhật, không có thì thêm” trong APL cũng buộc phải suy nghĩ lại từ cách rẽ nhánh
Trong Python thì chỉ cần
if/elsevàkey in map, trong C# thìif/elsevàmap.Contains(key), còn trong APL lại sa vào việc nghĩ cách tái triển khai chức năng cơ bảnĐiều này giống với lập luận của Aaron Hsu, nhưng cảm giác như Up-Goer 5 hoặc Toki Pona, nơi không được nói “xe cứu hỏa” mà phải nói “xe của người làm việc dừng lửa”
[1] https://docs.dyalog.com/latest/CheatSheet%20-%20I-Beams.pdf
[3] https://aplwiki.com/wiki/Scalar_extension
[4] https://xkcd.com/1133/