- Brian Kernighan nhìn lại The Practice of Programming, cuốn sách ông viết cùng Rob Pike, như một nỗ lực vào năm 1999—thời điểm Internet, Python, Perl và Java đang lan rộng nhanh chóng—nhằm bàn về “cách viết chương trình giỏi một cách chuyên nghiệp”
- Một số ví dụ đã trở nên lỗi thời theo thời gian, nhưng các nguyên tắc như phong cách, gỡ lỗi và thái độ khi viết vẫn có thể áp dụng khi ngôn ngữ và môi trường thay đổi
- Việc phân tích CSV vẫn lộn xộn và đặc tả cũng không hoàn toàn rõ ràng; pandas mạnh mẽ nhưng nặng và có mức trừu tượng cao, nên đôi khi mã Python đơn giản lại tốt hơn
- Bell Labs là một môi trường nghiên cứu nhờ tư duy dài hạn, đồng nghiệp xuất sắc và ít áp lực về sản phẩm/doanh thu, giúp những công trình như Unix, yacc và công cụ chuẩn bị tài liệu trở nên khả thi
- Mô hình ngôn ngữ lớn là công nghệ đột ngột tạo tác động lớn từ tháng 11/2022; trải nghiệm Claude tạo gần đúng mã Python liên quan đến spaCy báo trước sự thay đổi trong cách lập trình viên làm việc
Môi trường lập trình năm 1999 và mục tiêu của cuốn sách
- The Practice of Programming là cuốn sách ra đời khoảng 15 năm sau The Unix Programming Environment, tác phẩm trước đó Kernighan viết cùng Rob Pike
- Mục tiêu của sách là bàn về “thực tế chương trình được viết như thế nào” và “làm thế nào để viết hiệu quả, chuyên nghiệp”
- Môi trường điện toán quanh năm 1999 rất khác so với hiện nay
- Internet là một sự hiện diện tương đối mới đối với công chúng, xuất hiện khoảng năm 1995–1996
- Python là ngôn ngữ khá mới, Perl vẫn còn mạnh, và Java cũng phổ biến
- Các ví dụ cụ thể có thể ít trực tiếp hơn với độc giả hiện nay, nhưng ông cho rằng các nguyên tắc chung vẫn có thể được chuyển sang môi trường khác
- Những người dẫn chương trình cho rằng các chương về style guide và debugging đặc biệt vẫn còn giá trị, và thấy ấn tượng khi từ “bug” đã được dùng trước cả giai thoại Grace Hopper với máy Mark, trong ngữ cảnh Thomas Edison và phonograph
CSV, pandas, bộ nhớ và trừu tượng hóa
- Kernighan nói về ví dụ trình phân tích CSV trong sách rằng ngay cả ngày nay vẫn chưa có trình phân tích CSV tốt
- Mùa hè trước, khi cố thêm chức năng CSV vào awk, ông đã mất từ vài tuần đến khoảng một tháng để dùng một “trình phân tích CSV đúng nghĩa”
- Đặc tả CSV không hoàn toàn rõ ràng và theo một nghĩa nào đó không được chuẩn hóa
- pandas được đánh giá là một công cụ nặng dù rất mạnh
- Ông nói trong nhiều trường hợp, tự viết Python đơn giản hơn là hiểu các cơ chế lặp và chọn lựa ngầm theo kiểu pandas
- Người dẫn chương trình nói rằng pandas thường được chọn trong công việc machine learning và data science, nhưng khi cần hiệu năng thực thi quan trọng thì họ cân nhắc cách tiếp cận đơn giản hơn
- Quản lý bộ nhớ hiện đã trở thành lĩnh vực gần như không cần bận tâm trong nhiều hoạt động lập trình
- Trong C, phải tự quản lý bộ nhớ và việc này rất khó
- Trong C++ cũng có thể làm, nhưng khó học được các kỹ thuật để xử lý đúng
- Trong Python, ông mô tả rằng hầu hết mọi thứ hoạt động “như phép màu”
- Trừu tượng hóa lớn không phải lúc nào cũng che giấu hoàn toàn vấn đề
- Khi xử lý một văn bản cỡ một cuốn sách bằng spaCy, ông nhận được thông báo thiếu bộ nhớ vì hạn mức tác vụ mặc định là 1GB, và giải quyết bằng cách tăng cấu hình lên gấp đôi
- Thời Kernighan lớn lên, kilobyte cũng đã là dung lượng bộ nhớ lớn
- Trong cộng đồng nhúng, bộ nhớ và hiệu năng vẫn được coi là cực kỳ quan trọng; ngoài C, các ngôn ngữ như Rust hay Zig cũng được nhắc đến trong bối cảnh đó
Go, Plan 9 và môi trường nghiên cứu của Bell Labs
- Người dẫn chương trình nói rằng các vấn đề mà The Practice of Programming đặt ra có cảm giác như nền tảng cho thiết kế ngôn ngữ Go
- Kernighan cho rằng Rob Pike là một trong ba người tạo ra Go, và “hoàn toàn đáng tin” khi nói những bất tiện được đề cập trong sách có thể đã nằm trong bối cảnh khi nghĩ về một ngôn ngữ mới sau này
- Tuy vậy, ông nói không có ký ức cụ thể rằng Pike khi đó nghĩ “sẽ cải thiện thế giới bằng một ngôn ngữ mới”
- Ông xem công việc về Plan 9 cuối thập niên 1990 và các ngôn ngữ như Limbo, Alef là một phần của phả hệ dẫn đến Go
- Trải nghiệm ở Bell Labs gần như là môi trường lý tưởng với Kernighan
- Khi còn là nghiên cứu sinh Princeton vào thập niên 1960, ông từng hai lần thực tập mùa hè tại Bell Labs, làm việc với nhóm liên quan đến Multics
- Vì trải nghiệm đó rất tốt, khi nhận được đề nghị quay lại, ông không phỏng vấn ở nơi nào khác
- Ông làm ở Bell Labs từ đầu năm 1969 đến khoảng năm 2000
- Khi đó tại Bell Labs có thể tư duy dài hạn, ít áp lực về kết quả theo quý hoặc phải tạo ngay sản phẩm/doanh thu
- Mọi người có thể làm những việc họ thấy thú vị và quan trọng một cách tương đối độc lập
- Vì AT&T đang cung cấp dịch vụ điện thoại cho phần lớn nước Mỹ, đó là một “môi trường nhiều vấn đề”, và cũng có nhiều việc có thể hữu ích cho hệ thống điện thoại
- Ông không từng gặp trực tiếp Claude Shannon
- Ông nhớ rằng Shannon đã rời sang MIT vài năm trước khi Kernighan đến Bell Labs
- Kernighan nói ông thân với Richard Hamming, người từng dùng chung văn phòng với Shannon
Học tập, viết sách và tư duy lập trình
- Việc học ban đầu của Kernighan diễn ra tại Bell Labs, nơi ông tiếp xúc với những con người giỏi, công cụ tốt và các vấn đề thú vị
- yacc là công cụ giúp dễ dàng tạo ngôn ngữ lập trình mới, và Kernighan đã dùng nó không chỉ cho việc tạo ngôn ngữ truyền thống mà còn trong các lĩnh vực như chuẩn bị tài liệu và ngôn ngữ khai báo
- Qua quá trình này, ông học được nhiều về thiết kế và triển khai ngôn ngữ
- Ông cũng quan tâm lâu dài đến các công cụ chuẩn bị tài liệu
- Ông chịu ảnh hưởng từ runoff, chương trình chuẩn bị văn bản tương tác thời kỳ đầu ở MIT
- Tại Princeton, để làm luận văn của mình, ông viết một chương trình chuẩn bị tài liệu tương tự bằng Fortran
- Ở Bell Labs, ông tạo các công cụ giúp sản xuất sách vật lý dễ hơn và đảm bảo các ví dụ chương trình không bị hỏng trong quá trình xuất bản
- Sau khi chuyển sang đại học, việc giải thích những điều mình đã biết cho người không chuyên trở thành một quá trình học tập quan trọng
- Ông phải giải thích cho sinh viên mạnh về văn học hoặc âm nhạc cách số nhị phân hoạt động
- Ông cũng nói rằng trong quá trình đó mình học được Leibniz là người thực sự phát minh ra số nhị phân vào cuối thế kỷ 17, và đã dùng nốt nhạc thay cho chữ cái để tạo ra thứ tương tự ký hiệu thập lục phân
- Động lực viết sách xuất hiện khi có “điều gì đó đáng nói” và “đồng tác giả mà mình muốn cùng nói điều đó”
- Phần lớn sách của Kernighan là đồng tác giả
- Ông cho rằng làm việc chung dễ hơn nhiều so với viết một mình, vì có thể bổ sung và tinh chỉnh nội dung của nhau
Mô hình ngôn ngữ lớn, giáo dục và sách được khuyến nghị
- Kernighan nêu hệ thống chia sẻ thời gian, Unix, sự tiến hóa của ngôn ngữ lập trình, sự gia tăng tài nguyên theo định luật Moore và PC là những bước phát triển quan trọng trong sự nghiệp của mình
- Chia sẻ thời gian là một thay đổi lớn vì cho phép làm việc theo lịch của mình mà không cần có mặt vật lý trước máy tính hoặc chờ người vận hành xử lý
- Ông xem cloud computing là một hình thức lại gần với chia sẻ thời gian, ở chỗ tính toán được tập trung hóa và người dùng có các thiết bị ngoại vi cao cấp để giao tiếp với hệ thống ở xa
- Về công nghệ thú vị nhất hiện nay, ông chọn mô hình ngôn ngữ lớn
- Ông cho rằng điểm đặc biệt là chúng đột ngột xuất hiện khoảng tháng 11/2022 và tạo tác động lớn trong thời gian ngắn
- Khi ông yêu cầu Claude bằng hai hoặc ba câu về một tác vụ liên quan đến spaCy, nó tạo mã Python đúng khoảng 99,9%, và mức sử dụng Python cũng tinh vi hơn chính ông
- Ông cho rằng lập trình viên sẽ không biến mất, nhưng cách làm việc có thể thay đổi
- LLM mở ra cách tiếp cận mới cho sinh viên
- Một sinh viên cho rằng có thể dùng LLM để cải thiện bản dịch tiếng Hy Lạp cổ
- Ông nói kết quả OCR của các tài liệu in cũ từ thập niên 1700 có thể được cải thiện bằng cách tận dụng tri thức ngôn ngữ mà mô hình ngôn ngữ có
- Trong lớp dành cho người không chuyên, ông cố gắng liên kết cách máy tính hoạt động với các vấn đề công nghệ đang diễn ra trên thế giới
- Sinh viên phần lớn thuộc khối nhân văn và khoa học xã hội, nhiều người học để đáp ứng yêu cầu về suy luận định lượng
- Ông bàn các chủ đề như phần cứng, phần mềm, truyền thông, net neutrality, privacy, security, Google antitrust cùng với nền tảng kỹ thuật
- Ông cho rằng tư duy lập trình—chia việc lớn thành việc nhỏ và suy nghĩ theo từng bước—có thể được chuyển sang các lĩnh vực khác như viết luận văn hoặc phân tích vấn đề pháp lý
- Với người mới bắt đầu, điều quan trọng là tìm thứ mình muốn tự làm
- Bắt đầu từ vấn đề mình quan tâm như làm game, cải thiện tài chính cá nhân, phân tích văn bản có thể giảm rào cản tâm lý
- Trong lớp không chuyên, ông dùng bài tập phân tích Pride and Prejudice bằng NLTK, rồi để sinh viên chọn cuốn sách khác mình muốn và khám phá theo cách tương tự
- Các sách được khuyến nghị/nhắc đến và gu đọc rất đa dạng
- Trong sách kỹ thuật, ông thỉnh thoảng đọc lại The Mythical Man-Month; một số phần đã già đi tốt, nhưng một số cách diễn đạt về giới tính hiện nay trông rất phân biệt giới
- Recoding America của Jennifer Pahlka được nhắc đến như một cuốn sách thú vị về lý do phần mềm chính phủ không hoạt động tốt như kỳ vọng và vì sao hệ thống khiến việc cải thiện trở nên khó khăn
- Về sách phi kỹ thuật, ông nhắc đến lịch sử, lịch sử quân sự, tiểu thuyết trinh thám, các tiểu thuyết về đua ngựa của Dick Francis và Chip War về ngành bán dẫn
1 bình luận
Ý kiến trên Hacker News
Cuốn sách này là một cuốn nền tảng, nên mọi lập trình viên, đặc biệt là người mới bắt đầu, đều nên đọc
Đúng phong cách sách của Kernighan, câu văn đơn giản, súc tích và chính xác; không có phần thừa, chỉ gói gọn những điểm cốt lõi trong hơn 200 trang một chút. Chỉ cần hiểu nguyên lý qua các ví dụ rồi áp dụng vào bối cảnh của mình
Điểm mạnh của sách K&P là không áp đảo người đọc bằng lý thuyết, mà cho thấy cách áp dụng kỹ thuật trong thực tế trước, rồi sau đó khiến việc học lý thuyết trở nên dễ tiếp cận hơn
Ví dụ, tôi đọc cuốn này khi đã có kinh nghiệm lập trình mạng và triển khai giao thức; trong chương "Notations", phần trình bày các routine pack/unpack thông điệp mạng dùng chuỗi định dạng kiểu
printf/scanfđể chỉ định layout gói tin thật sự là một trải nghiệm mở mắt. Tôi học được sức mạnh của ký pháp phù hợp và các ngôn ngữ nhỏ; sách cũng có các đoạn mã minh họa ý tưởng về máy ảo, code threading và biên dịch JITCuốn cũ hơn của Kernighan và Pike, "The Unix Programming Environment", cũng rất đáng đọc kèm. Chương "Program Development" trình bày toàn bộ quá trình dùng công cụ phát triển compiler để tạo một compiler cho một ngôn ngữ máy tính bỏ túi nhỏ trong khoảng 50 trang; theo tôi biết, đó là bài viết giải thích cách viết compiler nhỏ gọn và đơn giản nhất
Tóm lại, mọi cuốn sách của Kernighan đều đáng mua và học
Sách về C thì tôi đã đọc trước đây và nhớ là văn phong rất hay. Chắc chắn tôi sẽ học được nhiều tri thức lập trình, nhưng tôi cũng muốn phân tích vì sao sách của Kernighan lại hay đến vậy dưới góc độ viết kỹ thuật
Có vẻ Kernighan đã học rất nhiều về viết lách, hoặc ít nhất đã suy nghĩ rất nhiều về viết lách theo kiểu tư duy từ nguyên lý đầu tiên. Ngay cả tựa "The Elements of Programming Style" cũng tham chiếu đến cuốn sách viết lách nổi tiếng của Strunk và White, "The Elements of Style"
Theo chuẩn hiện nay thì hơi cũ, nhưng vẫn là một cuốn dễ đọc
Không phải mỉa mai đâu; tôi muốn biết vì sao nó vẫn là sách bắt buộc phải đọc ngay cả với người đang đi khá thuận lợi trong sự nghiệp
Tôi thật sự thích "The Practice of Programming"
Trong số các sách lập trình tôi từng đọc, những bài học từ cuốn này là thứ đọng lại mạnh nhất. Dù đã vài năm tôi chưa đọc lại, tôi vẫn cảm thấy nó ảnh hưởng đến thực hành hằng ngày của mình
Một số ví dụ lập trình cụ thể đã khá lỗi thời, nhưng các ý tưởng chung vẫn rất vững
Tôi thích Kernighan. Ông ấy là người thật sự khiêm tốn
Trong một video trên YouTube, ông kể rằng trong luận án tiến sĩ mình đã giải một bài toán khó, và về sau hóa ra đó là một bài toán NP-complete trước khi lý thuyết này được hệ thống hóa
Tôi gửi email xin luận án và nhận được phản hồi khá nhanh; đọc xong thấy thật sự thú vị
Với tôi và nhiều người khác, những suy nghĩ của ông về lập trình thuộc loại thú vị và hữu ích nhất, phần lớn vì ông có thể truyền đạt chúng rất rõ ràng
Ước gì các buổi phỏng vấn ngày nay kiểm tra mức độ hiểu khái niệm như trong cuốn sách này thay vì LeetCode
Trong thế giới mới vô lý này, có khi Brian Kernighan cũng không vượt qua nổi một buổi phỏng vấn LeetCode hard
Tất cả đều là các bài toán lập trình khá thực tế. Stripe có một vòng phỏng vấn trong đó họ fork thư viện Jackson Java, cài sẵn bug rồi yêu cầu tìm và sửa. Khá độc đáo, nhưng gần với công việc lập trình thực tế hơn nhiều
Tôi cũng nhớ đến việc Katalin Karikó, người đoạt Nobel nhờ mRNA, từng bị hạ chức ở UPenn vì không kéo được tài trợ nghiên cứu
Một tác giả khác thuộc cùng đẳng cấp xuất sắc như Kernighan và các sách của ông là Jon Bentley, với hai cuốn Programming Pearls và More Programming Pearls
https://en.m.wikipedia.org/wiki/Jon_Bentley_(computer_scient...
Cuốn này dạy cách suy nghĩ từ trên xuống về hiệu quả, tập trung vào thuật toán và ngôn ngữ, nên hữu ích cho mọi lập trình viên
Các sách hiện đại về hiệu quả của Agner Fog, Fedor Pikus và những người khác chủ yếu bàn về kỹ thuật hiệu năng ở cấp compiler/hệ điều hành/bộ xử lý, nên đọc cùng sẽ có được bức tranh toàn cảnh
Mọi người ơi, chữ g là âm câm
Sẽ rất hay nếu mời Rob Pike xuất hiện. Có lẽ ông ấy chắc chắn sẽ nhắc đến việc chỉnh cách phát âm. Tôi gần như nghe thấy giọng ông ấy rồi
Tôi cũng rất muốn mời Rob Pike. Chúng tôi đang xúc tiến, nhưng liên lạc với ông ấy có phần khó hơn
Tôi mới xem khoảng một phần ba video, nhưng thấy những người dẫn chương trình đặt khá nhiều câu hỏi sâu sắc
Tôi là Carter, một trong những người dẫn video. Rất vui vì mọi người xem thấy thích. Được trò chuyện với Brian Kernighan thật sự là một vinh dự lớn
Vì định dạng này xoay quanh sách, có lẽ nên tổng hợp các cuốn sách đã đề cập, và nếu có thể là danh sách các phương tiện/nội dung, ở phần mô tả hoặc một phần bình luận
Tôi đã thêm "The Bit Player" (phim tài liệu năm 2018 về Claude Shannon) vào danh sách cần xem, và thêm "Recoding America", "Chip War", "Endurance: Shackleton's Incredible Voyage" vào danh sách cần đọc
Sẽ hay nếu thêm Software Tools in Pascal của Kernighan vào danh sách sách sẽ bàn trong podcast
Tôi có cuốn đó và thấy nó hay
Kernighan và Plaugher trước hết viết "Software Tools" bằng RATFOR, rồi sau đó viết "Software Tools in Pascal". Và như một phản ứng trực tiếp từ trải nghiệm đó, Kernighan đã viết bài luận "Why Pascal Is Not My Favorite Programming Language"
Lẽ ra viết bằng Pascal phải dễ hơn rất nhiều so với viết bằng RATFOR, nhưng thực tế lại không phải vậy, và Kernighan đã suy nghĩ về lý do vì sao
Đây vẫn là một bài viết thú vị, ví dụ có thể xem ở đây: https://www.cs.virginia.edu/~evans/cs655/readings/bwk-on-pas...
Tuy nhiên bài này ban đầu nói về Pascal chuẩn. Các phần mở rộng như Turbo Pascal đã sửa được nhiều vấn đề. Dù vậy, như ông ấy nói, giữa các phần mở rộng lại không có tính khả chuyển. Nhưng khi Turbo Pascal trở thành phần mở rộng "chuẩn" trên thực tế, vấn đề đó cũng được giải quyết phần nào
Tôi bị cuốn hút bởi các ý tưởng và cách viết, và từ đó có bàn đạp để tìm đọc các tác phẩm quan trọng còn lại của Kernighan
Kernighan cũng là đồng tác giả của cuốn The Go Programming Language, ít nhất là ở bản in đầu tiên