Gerald Sussman: Lập trình phải vui (2022) [video]
(youtube.com)- Gerald Sussman cho biết từ năm 1962, khi đi qua các môi trường điện toán sơ khai như IBM 7094, PDP-6, Mac Hack 6 và Maxima, ông vẫn luôn giữ lấy niềm vui nội tại của việc lập trình
- Lập trình không phải là việc mã hóa theo kiểu cơ học, chuyển đặc tả thành mã, mà gần với thiết kế kỹ thuật trừu tượng hơn: cùng lúc tìm ra đặc tả khả dĩ và cách hiện thực trong bối cảnh mục tiêu còn chưa hoàn chỉnh
- Khi đặt cạnh nhau cấu trúc eval/apply của Lisp và sự tương tác trong các phương trình Maxwell, ông xem lập trình là một hoạt động sáng tạo xử lý những vấn đề khái niệm sâu sắc như vật lý, toán học và triết học
- Bug không chỉ là thất bại đơn thuần, mà là cơ hội học hỏi nảy sinh khi con người hữu hạn giải quyết vấn đề bằng các kế hoạch đã được đơn giản hóa, và là một phần của “giải quyết vấn đề bằng cách gỡ lỗi cho một kế hoạch gần đúng”
- Vi phân tự động, việc mở rộng các phép toán generic trong Scheme, và kinh nghiệm biểu diễn cơ học cổ điển thành chương trình có thể thực thi cho thấy lập trình có thể làm sáng tỏ các ngành học khác; đồng thời ông nhấn mạnh rằng niềm vui ấy chỉ trọn vẹn khi được chia sẻ qua free/libre software
Thiết kế và khám phá vượt ra ngoài coding
- Sussman bắt đầu dùng máy tính từ khi còn là học sinh trung học vào năm 1962, và tiếp xúc với điện toán thông qua Columbia Science Honors Program
- Các máy tính đời đầu như dòng IBM 7094 có giá hàng triệu USD, chỉ có thể định địa chỉ 2^15 từ 36-bit và hoạt động với chu kỳ khoảng 2 microgiây
- Sau khi vào MIT, ông tiếp cận những máy như DEC PDP-6, với khả năng định địa chỉ 2^18 từ 36-bit
- Bộ nhớ lớn là điều cần thiết cho các hệ thống thao tác ký hiệu sơ khai như Maxima
- MIT đã đặt Fabritek làm một bộ nhớ lớn, mất một năm để chế tạo, với chi phí được ghi nhận khoảng 380.000 USD
- Vì bộ nhớ này khi đó rất lớn nên nó được đặt biệt danh là Moby, theo tên một con cá voi
- Ông từng tham gia vào AI, thiết kế máy tính mới, phát minh ngôn ngữ lập trình, mô phỏng số trong cơ học thiên thể và viết các hệ thống ký hiệu quy mô lớn, nhưng cốt lõi vẫn luôn là tình yêu với lập trình
- Lập trình không phải là công việc cơ học biến một đặc tả đã được xác định rõ thành mã có thể chạy
- Một đặc tả tốt thường không tự nhiên từ trên đưa xuống
- Người ta phải khám phá cái gì có thể hiện thực được, rồi viết đặc tả phù hợp với điều thực sự có thể đạt tới
- Vì vậy, lập trình là một cuộc khám phá đồng thời để cùng tìm ra đặc tả và hiện thực khả dĩ hướng tới một mục tiêu mới chỉ được xác định một phần
- Khác với kỹ thuật vật lý, lập trình bị giới hạn bởi khả năng tổ chức tư duy nhiều hơn là bởi các ràng buộc vật lý như dung sai, độ cong khi cắt gọt hay sai số điện trở
- Lập trình viên chọn cách biểu đạt, thuật toán và mức độ trừu tượng khi làm việc với những cỗ máy ảo khổng lồ
Lập trình như một nghệ thuật sáng tạo
- Để diễn tả cảm giác của việc lập trình, Sussman trích dẫn bài viết trong đó Edgar Allan Poe giải thích ông đã viết "The Raven" như thế nào
- Poe nói rằng tác phẩm không được tạo nên nhờ ngẫu hứng hay trực giác, mà được hoàn thành từng bước như giải một bài toán, qua một quá trình phức tạp gồm lựa chọn, loại bỏ, chèn thêm và chỉnh sửa
- Quá trình này gần với cảm giác thật của lập trình hơn là việc đơn thuần chuyển đặc tả thành mã
- Lập trình gần với nghệ thuật sáng tạo như kiến trúc, âm nhạc, toán học và vật lý lý thuyết
- Toán học là hoạt động phát minh ra những định lý đẹp
- Vật lý lý thuyết là hoạt động phát minh ra những cách giải thích thế giới vật lý
- Lập trình cũng là hoạt động phát minh và mài giũa ý tưởng cùng cấu trúc
Cấu trúc được hé lộ qua eval/apply và các phương trình Maxwell
- Trải nghiệm học Lisp 1.5 và interpreter eval/apply khi là sinh viên năm nhất MIT là bước ngoặt làm thay đổi cuộc đời Sussman
- eval nhận một biểu thức và môi trường, đánh giá toán tử và toán hạng để tạo ra procedure và đối số; còn apply nhận procedure và đối số, bind đối số vào các tham số hình thức rồi quay lại đánh giá phần thân
- Sussman cho rằng cấu trúc này cũng áp dụng cho mọi ngôn ngữ máy tính và cho cả cách máy tính vận hành
- Cùng thời gian đó, ông học các phương trình Maxwell trong lớp điện từ học và lại có thêm một ấn tượng mạnh
- Maxwell đã thêm hạng dòng điện dịch để giải quyết sự bất nhất giữa bảo toàn điện tích và các phương trình sẵn có
- Kết quả là phương trình sóng điện từ xuất hiện, tạo nên mối liên hệ rằng ánh sáng là sóng điện từ
- Có một sự tương đồng sâu sắc giữa tương tác eval/apply và cấu trúc trong các phương trình Maxwell, nơi điện trường và từ trường tạo ra sự biến thiên của nhau
- Sự tương đồng này còn nối sang quan hệ giữa các biến đối ngẫu như vị trí và động lượng, năng lượng và thời gian
- Lập trình hằng ngày chạm đến những vấn đề triết học
- Cái tên
Chicagotrong một chương trình không đơn giản là chỉ thẳng tới thành phố ngoài đời như thế nào - Hai đối tượng có giống hệt nhau hay không bộc lộ qua việc thay đổi một đối tượng có làm đối tượng kia đổi theo không; mutation gắn với vấn đề đồng nhất
- Chương trình thuần hàm không có thay đổi trạng thái, nên phải nhìn vấn đề đồng nhất theo cách khác
- Bên trong các biểu thức được trích dẫn, nguyên tắc “cái giống nhau có thể thay thế cho nhau” có thể bị phá vỡ
- Những mệnh đề như “mọi con quạ đều màu đen” làm cho ý nghĩa của bằng chứng trở nên phức tạp, như trong Hempel's Raven Paradox
- Cái tên
Cách đối diện với bug
- Sussman xem bug không phải là thất bại đáng xấu hổ mà là cơ hội học hỏi
- Việc debug bằng công cụ tốt có thể thú vị như một cuộc phiêu lưu, và bug nên có tên gọi như fencepost error hay reader-writer bug
- Bug cũng là kết quả của một chiến lược thiết kế mạnh mẽ
- Con người không thể nghĩ mọi thứ cùng một lúc nên phải lập kế hoạch
- Kế hoạch đòi hỏi sự đơn giản hóa, và sự đơn giản hóa sẽ tạo ra những phần bị bỏ sót
- Từ đó bug xuất hiện, và debug trở thành quá trình chỉnh một kế hoạch gần đúng theo hướng mong muốn
- Sussman gọi cách này là “giải quyết vấn đề bằng cách gỡ lỗi cho một kế hoạch gần đúng”
- Ví dụ về thiết kế bộ lọc điện cho thấy rõ chiến lược này
- Để tạo ra một bộ lọc có đáp ứng trong khoảng 30Hz đến 3kHz, người ta phân tích hàm hệ thống thành các nhân tử
- Kết hợp điện trở và tụ điện để tạo thành các mạch con cần thiết
- Nhưng mỗi mạch con lại giả định rằng “không có dòng điện đi ra”, nên khi nối lại với nhau sẽ sinh ra loading bug
- Một miếng vá bằng bộ khuếch đại có thể giải quyết vấn đề này trong một số tình huống
- Không phải mọi bug đều vui
- Sussman phê phán C và C++ là đầy rẫy cạm bẫy
- Tình trạng thường xuyên phải có kernel mới vì bug quản lý bộ nhớ cũng được ông liên hệ với mã viết bằng C
- Ông cũng nêu các ví dụ thiếu nhất quán trong Python:
{}là dictionary nhưng{1}là set, còn tuple được định nghĩa bằng dấu phẩy chứ không phải dấu ngoặc
Vi phân tự động và vật lý học có thể thực thi
- Năm 1992, Sussman ở Caltech cùng nhóm của Kip Thorne để học thuyết tương đối rộng, và ông nói rằng mình dùng chương trình như một phương tiện lưu trữ tri thức
- Khi cùng Dan, một nhà thiết kế chip dấu phẩy động của Hewlett-Packard, suy nghĩ về đạo hàm của hàm số, ông đã độc lập tái phát hiện vi phân tự động chế độ thuận (forward-mode automatic differentiation)
- Mục tiêu không phải là vi phân ký hiệu bằng cách nhìn vào bên trong hàm, cũng không phải xấp xỉ số
- Trọng tâm là chain rule
- Nếu mở rộng số thành các differential object có phần hữu hạn và phần vô cùng bé, thì trong hợp thành hàm, chain rule sẽ tự động vận hành
- Vì dùng Scheme, ông có thể định nghĩa lại các phép toán số học nguyên thủy để phù hợp với differential object, và Sussman nói mình đã triển khai chuyện này xuyên đêm như một “hack attack”
- Sau đó nhiều người tiếp tục tinh chỉnh đạo hàm của hàm bậc cao, đa đạo hàm và việc mở rộng động các phép toán nguyên thủy trong Scheme
- Abelson đã giúp làm rõ lý thuyết đúng cho đa đạo hàm
- Jeff Siskind, Barak Pearlmutter và Alexey Radul đã debug những bug tinh vi trong đạo hàm của hàm bậc cao
- Hansen đã nghĩ ra cách mở rộng động hiệu quả các phép toán nguyên thủy của Scheme
- Công việc này sau đó dẫn tới hệ thống Scmutils, được ông dùng cùng Jack Wisdom để giảng dạy và nghiên cứu cơ học cổ điển cùng hình học vi phân
- Cuốn Structure and Interpretation of Classical Mechanics của Sussman và Wisdom là nỗ lực làm sáng tỏ việc hiểu cơ học cổ điển bằng các kỹ thuật tính toán
- Ký pháp phương trình Lagrange truyền thống mơ hồ nếu không có tri thức văn hóa đi kèm, và cũng có vấn đề nếu nhìn từ góc độ kiểu của hàm
- Khi viết bằng ký pháp hàm và mã Scheme, các ý tưởng toán học trở thành chương trình rõ ràng và có thể thực thi
- Trong ví dụ dao động điều hòa, hệ thống tính ra đúng phương trình chuyển động và quan hệ tần số góc theo khối lượng, hằng số lò xo và vị trí
Niềm vui chỉ trọn vẹn khi được chia sẻ
- Sussman tổng kết niềm vui của lập trình theo nhiều nhánh
- Niềm vui khi phát hiện những sự tương đồng sâu sắc giữa các thế giới khác nhau
- Niềm vui khi gặp trong công việc thực tế những vấn đề mà các triết gia đã trăn trở từ lâu
- Niềm vui săn tìm bug
- Niềm vui khám phá những ý tưởng và trừu tượng hóa tốt
- Niềm vui dùng chương trình để làm sáng tỏ các ngành học khác
- Niềm vui của lập trình chỉ trở nên trọn vẹn khi chia sẻ công việc với người khác, và ông khuyến khích sử dụng cũng như viết free/libre software
- Sussman lấy làm tiếc vì buổi nói chuyện phải được ghi lại qua Zoom, và nói rằng ông muốn có phần mềm mà người ta có thể đọc, chỉnh sửa rồi chia sẻ lại
- Về phần mềm tự do và quyền tự do phần mềm, ông khuyên nên đọc triết lý phần mềm tự do của GNU, đồng thời kêu gọi tham gia và quyên góp cho Free Software Foundation
1 bình luận
Các ý kiến trên Hacker News
Tôi rất thích đoạn này: “Viết chương trình như một cách ghi nhớ điều gì đó. Ký ức của tôi là những chương trình tôi viết. Khi học những thứ như toán, vật lý, sinh học rồi viết chương trình để biểu đạt chúng, sau này đọc lại vẫn không mơ hồ và dễ hiểu, nên có thể xem đó là cách lưu trữ tri thức”
https://www.infoq.com/presentations/Expression-of-Ideas/
Chủ đề rất gần với trích dẫn trên, bàn về việc lập trình giúp hiểu sâu hơn các đối tượng như toán học và vật lý như thế nào
Ví dụ, cách thuốc giảm đau hoạt động có thể giúp hiểu keylogger hoặc tấn công man-in-the-middle, còn nhìn vào việc “kiểm tra ngữ pháp” DNA trong quá trình nguyên phân có thể học được nhiều điều về biên dịch nói chung
Việc chó con nuốt bất cứ thứ gì chúng thấy giống như cung cấp cho hệ miễn dịch đủ dữ liệu thử nghiệm về môi trường xung quanh, nên cũng tương tự machine learning; khá nhiều khái niệm an ninh mạng cũng có thể hiểu qua sinh học
Tôi có xu hướng suy nghĩ bằng hình ảnh nên rất khó thật sự hiểu toán, nhưng lập trình cho phép tôi tạo ra các hình ảnh và mối quan hệ trong đầu
Thật may mắn khi biết được điều này từ nhỏ; nếu không có nó chắc tôi đã lạc lối
Vấn đề, quyết định, lý do, các sự kiện làm căn cứ, những phương án thay thế đã xem xét đều là tri thức; và mỗi lệnh nhập vào bằng ngôn ngữ lập trình cũng là một quyết định
Thiết kế phần mềm có thể kéo dài đủ lâu để ta quên mất các quyết định trước đó và bối cảnh của chúng, cũng có thể kéo dài đủ lâu để người rời đi làm tri thức biến mất, người mới vào lại thiếu tri thức
Làm cho máy tính hiểu mã nguồn không phải phần khó; khó hơn là giúp người khác hiểu điều gì đã được thực hiện để họ có thể làm việc tốt hơn và nhanh hơn
Khi chỉ cái đầu và trí nhớ là không đủ, ta phải nhờ đến các công nghệ như viết, in ấn, phần mềm để ghi nhớ và tổ chức những khối tri thức lớn hơn
Vấn đề lớn nhất trong toán học với tôi cũng là không thể tin rằng mình sẽ không mắc lỗi, và cũng không thể tin rằng mình sẽ phát hiện ra lỗi
Trình biên dịch hoặc trình thông dịch buộc tôi phải nhận ra
Trước đây tôi từng nghe Sussman giảng dưới tầng hầm NYU cùng khoảng 20 nghiên cứu sinh tiến sĩ ngành thần kinh học
Ông đã nói về chủ đề khả diễn giải của AI từ rất lâu trước khi nó trở thành xu hướng
Tôi hỏi một câu, và ông lập tức nhận ra trong phòng có người học kỹ thuật điện, rồi đi sang bảng bên cạnh và cho thấy có thể suy ra cách một bộ khuếch đại thuật toán hoạt động từ các nguyên lý đầu tiên
Ông ấy có năng lượng và trí tuệ phi thường, và chắc chắn đã để lại ấn tượng sâu sắc
Tôi chưa xem video, nhưng lập tức nhớ đến câu trích của Alan J. Perlis mà Sussman và Abelson dùng trong lời đề tặng SICP
Nội dung nói rằng việc giữ gìn niềm vui của tính toán trong khoa học máy tính là rất quan trọng, và thuở ban đầu nó thật sự rất vui
Khách hàng đôi khi cũng chịu thiệt hại, và chúng ta đã bắt đầu nghiêm túc lắng nghe những phàn nàn đó, nhưng quan điểm là chúng ta không thấy mình có trách nhiệm bảo đảm việc sử dụng những cỗ máy này một cách thành công, không lỗi và hoàn hảo
Thay vào đó, điểm cốt lõi là chúng ta có trách nhiệm thúc đẩy cỗ máy, đưa nó theo những hướng mới và giữ cho nó thú vị; hy vọng khoa học máy tính không đánh mất cảm giác vui thích, và đừng hành xử như thể mình là nhà truyền giáo hay người bán Kinh Thánh
Đừng cảm thấy chìa khóa của tính toán thành công chỉ nằm trong tay chúng ta; thứ chúng ta nắm trong tay là trí tuệ, tức khả năng nhìn cỗ máy như một thứ lớn hơn so với khi ta lần đầu gặp nó, và khiến nó trở nên lớn hơn nữa
Với phần lớn những người còn lại, những người đang làm các chương trình đếm hạt đậu, thì từ góc nhìn của bên trả lương, không làm mất một hạt đậu nào quan trọng hơn rất nhiều so với việc chúng ta vui đến đâu hay mở rộng khả năng được bao nhiêu
Không phải bug, mà là một cục vui nho nhỏ /s
Tiêu đề hay hơn có lẽ nên là “khoa học máy tính học thuật thì thú vị, hoặc nên thú vị”
Ý chính là việc phát hiện phép loại suy, suy tư triết học, gỡ lỗi, nảy ra ý tưởng hay và đạt được sự rõ ràng đều thú vị; nhưng đó chủ yếu là sự xa xỉ của các giáo sư được trả tiền để làm những hoạt động ấy, và dường như không mấy phù hợp với thế giới “khách hàng muốn cái này trước cuối tuần này”, ngoài niềm vui tranh luận trong việc debugging
Phần lớn “lập trình” có lẽ nên được nhìn gần với một môn trường nghề như hàn
Nếu muốn phát triển kỹ thuật hàn mới thì đúng là đề tài nghiên cứu ở trình độ sau đại học, nhưng phần lớn thợ hàn và lập trình viên làm việc với các công cụ đã được biết rõ và các hệ thống tương đối đơn giản
Sinh viên trường nghề có thể không muốn lãng phí thời gian học MIT/GNU Scheme rồi không bao giờ dùng lại trong đời nghề nghiệp, nhưng với sinh viên học thuật thì điều đó có thể đáng giá như việc một sinh viên ngôn ngữ học học đọc và viết Linear B
Việc gì cũng có thể thú vị, nhưng cuối cùng các điều kiện như năng lực và sự ổn định cảm xúc của đồng nghiệp và quản lý, thiết kế và độ an toàn của không gian làm việc, mức lương đủ sống, và văn hóa tổ chức có bỏ qua công việc làm cẩu thả hay không mới tác động lớn hơn; các nghề chuyên môn khác như lập trình hệ thống điều khiển công nghiệp cũng vậy
Bạn sẽ thấy rằng người tò mò, chín chắn và có học, dù tự học hay không, đều làm việc tốt hơn người không như vậy trong mọi nghề
Ngày xưa khi tôi làm thợ hàn, những người thông minh, có động lực và tò mò cũng làm tốt hơn những người chỉ giết thời gian
Vì vậy tôi đồng ý rằng lập trình giống hàn, nhưng theo một nghĩa khác với điều bạn định nói
SICP đã thay đổi hoàn toàn cách tôi nghĩ về code, abstraction và tính mô-đun, khi ở cạnh những đồng nghiệp đang hack bằng Pascal hoặc C
Trong khi tôi có thể xây dựng mô hình tinh thần của vấn đề bằng Lisp/Scheme, các đồng nghiệp phải thực hiện phần abstraction trong đầu rồi triển khai bằng những ngôn ngữ đòi hỏi phải tập trung vào mức thấp
Vì vậy tôi mãi biết ơn vì đã tiếp cận SICP từ sớm
Việc lập trình bằng ngôn ngữ nào có thể khiến mọi thứ thú vị hơn hoặc thoải mái hơn
Có lẽ tôi sẽ không bao giờ thấy thoải mái với C++
Thật hay khi được nghe góc nhìn về lập trình từ một trong các tác giả của SICP, và những giai thoại trong vài phút đầu cũng khá thú vị
Tôi nói rằng ngày hôm sau sẽ gặp Sussman nên nhất định cần cuốn đó, và nhân viên đã gọi cho Harvard co-op; họ nói còn một cuốn trong kho, nên tôi bắt Uber tới hiệu sách Harvard và mua SICP
Hôm sau tôi đến văn phòng của Sussman ở MIT thì tình cờ Abelson cũng ở đó và vừa chuẩn bị rời đi, nên cả hai người đều ký vào cuốn SICP của tôi
Sussman nói thêm: “Nếu cậu đến sớm hơn 15 phút thì vợ tôi cũng đã ký rồi!”; đến lúc đó tôi mới biết vợ ông ấy là người hiệu đính SICP
Tôi cũng có một bức ảnh rất tuyệt chụp cùng hai vị phù thủy này và cuốn sách màu tím vừa được ký
Tôi rất muốn xem video này sớm
Tôi vẫn chưa thực sự học SICP một cách bài bản, nhưng đã mượn sách và nghe các bài giảng trong lúc sửa nhà
Trong các bài giảng SICP, câu trích dẫn của Sussman về việc hiểu những thứ phức tạp là thứ tôi thường đưa vào các bài thuyết trình liên quan đến kiến trúc; đó luôn là slide khiến mọi người hối hả ghi chép
Thành thật mà nói, tôi đã yêu thích lập trình trong nhiều năm, và có thời nó còn là sở thích chính của tôi
Tôi từng thử các ngôn ngữ hoặc phần mềm mới, đọc sách lập trình và tham gia nhiều kênh chat như libera/freenode
Nhưng khi trở thành freelancer và tập trung vào việc nhanh chóng bàn giao code đủ tốt trong những bối cảnh nhỏ hơn, niềm đam mê đó giảm dần
Nhìn chung điều đó có thể tốt cho tôi với tư cách kỹ sư, nhưng rất nhiều niềm vui và sự học hỏi đã biến mất khỏi công việc hằng ngày
Freelance và consulting thường là giải quyết vấn đề, thậm chí giống như bắn hạ vấn đề: loại bỏ vấn đề càng nhanh càng tốt, còn sự tao nhã không phải điều bắt buộc
Nếu muốn trở thành một builder tạo ra công cụ thì có lẽ freelance khó xảy ra, còn chuyển sang vai trò consultant thì có thể khả thi
Vì consultant giống một mối quan hệ dài hạn hơn, nên có thể đáng cân nhắc như bước tiếp theo