Trừu tượng hóa phần mềm có đang phá hủy nền văn minh? (2021)
(datagubbe.se)- Mối lo ngại của Jonathan Blow rằng “trừu tượng hóa làm suy yếu năng lực duy trì phần mềm thiết yếu” là hợp lý ở khía cạnh truyền thừa tri thức, nhưng nhiều ví dụ được đưa ra lại hiểu sai lịch sử và bối cảnh
- Tranh luận về “five nines”, phần mềm bền vững, sự đình trệ tiến bộ công nghệ, và sụt giảm năng suất phần lớn dựa vào việc không phân biệt thiết bị tiêu dùng với hệ thống có tính sẵn sàng cao hoặc dựa vào các ví dụ được chọn lọc
- Lo ngại về việc mất đi tri thức cấp thấp có phần xác đáng, nhưng C, assembly, Rust, port hệ điều hành, giáo dục trình biên dịch, và hoạt động mã nguồn mở vẫn là những con đường duy trì năng lực hệ thống
- Những lớp trừu tượng như hệ điều hành, hệ thống tệp, mạng, đa nhiệm, và framework làm tăng độ phức tạp, nhưng cũng giúp đáp ứng thay đổi phần cứng và kỳ vọng người dùng, đồng thời nâng cao tính di động, năng suất và khả năng tiếp cận sáng tạo
- Nguy cơ lớn hơn bản thân trừu tượng hóa là churn liên tục, nền tảng bị khóa, quảng cáo, tracker, telemetry, cùng sự suy yếu của quyền riêng tư và tự do; trong khi nền tảng kỹ thuật để duy trì các hệ thống quan trọng vẫn cần tiếp tục được bảo tồn
Lập trường cơ bản về luận điểm của Blow
- Bài nói chuyện của Jonathan Blow lập luận rằng trừu tượng hóa phần mềm dẫn đến mất mát tri thức lập trình cấp thấp, và cuối cùng có thể khiến con người không duy trì nổi phần mềm thiết yếu, dẫn tới sự sụp đổ của nền văn minh
- Tác giả đồng ý với tầm quan trọng của việc truyền thừa tri thức, nhưng để bảo vệ một kết luận như vậy thì ví dụ và bối cảnh lịch sử phải chính xác
- Phản biện cốt lõi là các ví dụ của Blow phụ thuộc nhiều vào hiểu lầm, ví dụ chọn lọc, và bằng chứng mang tính giai thoại, đồng thời bỏ sót một phần lịch sử máy tính
Tranh luận về “five nines” và độ bền vững
- Blow cho rằng trước đây khi bán hệ thống máy tính, người ta dùng “five nines”, tức 99,999% thời gian hoạt động, như một khẩu hiệu chất lượng, trong khi laptop ngày nay không đạt được mức đó
- Việc five nines tương đương khoảng 5 phút downtime mỗi năm là đúng, nhưng nhận định rằng chỉ số này từng được dùng để bán laptop tiêu dùng hay phần mềm xử lý văn bản thì bị cho là sai
- five nines thường áp dụng cho các lĩnh vực như tổng đài ứng cứu khẩn cấp kiểu 911, hệ thống bệnh viện, hay xử lý giao dịch tài chính
- Nó thường đi kèm các hợp đồng dài hạn quy định rất chi tiết những trường hợp không tính vào downtime
- Các công ty như IBM và Amazon vẫn đang bán những hệ thống và dịch vụ như vậy
- Luận điểm rằng nhiều thập kỷ qua không còn phần mềm bền vững cũng có phản ví dụ
- iPhone có thể chạy nhiều tuần hoặc nhiều tháng không cần khởi động lại
- Từng có máy chủ tệp và in Novell uptime 16 năm
- Các hệ thống turnkey như Unix, Windows, VMS và IBM i cũng được nhắc đến như ví dụ về khả năng sẵn sàng dài hạn
Phản biện về tiến bộ công nghệ và năng suất
- Nhận định rằng “các công ty công nghệ không còn thúc đẩy công nghệ nữa” có phần đúng, nhưng những công ty coi trọng tiền bạc hơn kỹ thuật cũng đã tồn tại từ trước
- Các lĩnh vực “nhàm chán” như hệ thống tệp, web server, cơ sở dữ liệu, và ngôn ngữ lập trình vẫn tiếp tục được phát triển và cải tiến
- Ngay cả những tầng trừu tượng, ảo hóa, và container hóa mà Blow không thích cũng đang được cải tiến bằng rất nhiều nỗ lực; việc không thích chúng không khiến chúng không còn là tiến bộ công nghệ
- Luận điểm rằng năng suất của nhân viên Facebook gần bằng 0 dựa trên tiền đề xem sản phẩm của Facebook chỉ là các tính năng của nền tảng xã hội
- Nhân sự của Facebook bao gồm nhiều vị trí như pháp lý, kế toán, thiết kế đồ họa, quản trị hệ thống, nghiên cứu, HR, quản lý trung gian, v.v.
- Công ty còn có các mảng kinh doanh khác như Instagram, WhatsApp, Oculus VR
- Sản phẩm thực sự của Facebook là một nền tảng phân phối quảng cáo; việc thu thập dữ liệu cá nhân và dữ liệu riêng tư để biến thành quảng cáo nhắm mục tiêu có thể không hiện ra dưới dạng tính năng người dùng, nhưng vẫn thể hiện ở doanh thu
Tri thức cấp thấp và hai mặt của trừu tượng hóa
- Tác giả thừa nhận đúng là nhiều lập trình viên thích làm việc trong môi trường không phải đụng đến cấp phát bộ nhớ và con trỏ
- Việc dùng trừu tượng hóa quá mức, như render một blog đơn giản bằng framework JavaScript không cần thiết hay ứng dụng desktop chạy chậm bên trong một trình duyệt đóng gói, được xem là có vấn đề
- Tuy nhiên, số người biết dùng C và lượng mã C/assembly hiện nay có thể còn nhiều hơn trước
- Linux và NetBSD vẫn tiếp tục được port sang nhiều mục tiêu đa dạng như CPU
- Rust tập trung vào độ bền vững nhưng vẫn cung cấp con trỏ và quản lý bộ nhớ
- Harvard CS50 công khai giảng dạy các nội dung như bố cục bộ nhớ, con trỏ,
malloc(),free()
- Garbage collection và lập trình hàm không phải là những lớp trừu tượng mới
- Lisp đã có cả hai từ cuối thập niên 1950
- Lisp còn được dùng trong những môi trường “hardcore” như NASA Jet Propulsion Lab
- COBOL không xuất hiện trong bài nói của Blow, nhưng đây là ngôn ngữ cấp cao đang tạo nền tảng cho hạ tầng ngân hàng và tài chính, và giữ vai trò quan trọng với trình độ văn minh hiện tại
Trường hợp “Unix 3 tuần” của Ken Thompson
- Việc Ken Thompson làm ra assembler, editor và kernel cơ bản chỉ trong 3 tuần được đánh giá là thành tựu rất xuất sắc
- Tuy vậy, chưa rõ phần mềm ở thời điểm đó bền vững tới đâu, thân thiện với người dùng thế nào, hay có những tính năng gì
- Điều kiện làm việc khi ấy và điều kiện của lập trình viên ngày nay khác nhau rất lớn
- Phát triển hiện đại đi kèm những yếu tố như tài liệu hóa, code review, daily standup, dọn backlog, user story, unit test, yêu cầu khách hàng, A/B test, commit message, tiêu chuẩn coding của doanh nghiệp
- Môi trường bị quấy rầy trong văn phòng mở cũng có thể rất khác môi trường làm việc cá nhân kiểu Bell Labs
- Một ví dụ duy nhất về Thompson không chứng minh rằng toàn bộ lập trình viên thời trước đều năng suất hơn
- Thompson cũng từng tham gia Multics, một dự án nổi tiếng vì chậm trễ
- Các dự án lớn như IBM OS/360 cũng bị kéo dài nghiêm trọng, và Frederick P. Brooks đã viết The Mythical Man-month năm 1975 dựa trên những trải nghiệm đó
Tiến hóa phần mềm và kỳ vọng người dùng
- Máy tính nói chung đã bền vững hơn nhiều so với vài chục năm trước, và lập trình viên cũng được xem là ít nhất năng suất ngang quá khứ
- Dù vậy, trong một số trường hợp, việc bắt đầu đã phức tạp hơn và có thể làm giảm năng suất ban đầu
- Người dùng hiện đại không muốn phải học RPN chỉ để làm phép tính đơn giản, hay viết chỉ thị troff để tạo một tờ rơi
- Giao diện tiện lợi và tính năng cao cấp sẽ làm tăng độ phức tạp và thời gian phát triển ngay cả khi không liên quan đến trừu tượng hóa
- Trường hợp Amiga OS cũ bị crash khi đang sao chép tệp và làm hỏng phân vùng ổ cứng cho thấy hệ thống cũ không nhất thiết ổn định hơn
- Hệ điều hành máy tính gia đình hiện đại có bảo vệ bộ nhớ và hệ thống tệp journaling nên những lỗi như vậy ít xảy ra hơn nhiều
- Windows 10 Home vẫn có khuyết điểm, nhưng cũng bao gồm những tiến bộ đó
Những luận điểm kiểu “ngày xưa cứ thế là làm được”
-
Sao chép và chạy chương trình
- Việc sao chép chương trình từ máy này sang máy khác rồi chạy vẫn còn khả thi nếu cùng kiến trúc đích và cùng điều kiện biên dịch
- Có ví dụ binary liên kết tĩnh của
slack-termbuild bằng Go chạy được trên các Raspberry Pi - Tuy nhiên, để tìm về thời kỳ chương trình độc lập thật sự phổ biến thì phải quay lại tận thời C64 hoặc PC/XT; ngay cả Deluxe Paint IV trên Amiga cũng phụ thuộc vào nhiều tệp phụ trợ và thư viện hàm của bên thứ ba
- Một số game Amiga dùng floppy nạp theo track, bỏ qua hệ thống tệp và hoạt động gần giống container thời đó, nhưng đổi lại cản trở cài lên ổ cứng và đa nhiệm
-
Luận điểm rằng chỉ cần cùng CPU là code sẽ chạy
- Về mặt lý thuyết, đúng là có thể nạp mã máy vào bộ nhớ và trỏ program counter vào đó để thực thi trên cùng một CPU
- Nhưng với các tác vụ thực tế như xuất đồ họa, phát âm thanh, xử lý đầu vào, ghi đĩa, khác biệt phần cứng lại là vấn đề lớn
- Ngay cả các máy tính gia đình chạy Z80 thời xưa cũng dùng cùng CPU nhưng phần cứng ngoại vi khác nhau nên việc port thực tế vẫn khó
- Thực ra các chương trình ở mức trừu tượng cao hơn như Basic còn dễ di động giữa nhiều máy hơn
- Khi Apple ra mắt dòng desktop ARM, cách tiếp cận dựa vào trừu tượng hóa có thể giảm gánh nặng port sang CPU mới hơn là bám trực tiếp vào kim loại
-
Hệ điều hành và truy cập phần cứng
- Hệ điều hành không chỉ lấy đi khả năng của CPU mà còn bổ sung những khả năng như hệ thống tệp, mạng và đa nhiệm
- Những người dùng như streamer trên Twitch, phải chạy game cùng nhiều chương trình khác, cần đa nhiệm để chia sẻ tài nguyên phần cứng theo cách được quản lý và có thể dự đoán
- Một số phần mềm trên Amiga và Atari truy cập thẳng vào phần cứng và bộ nhớ thay vì tuân theo đặc tả và lớp trừu tượng mà nhà sản xuất cung cấp, nên chỉ những nâng cấp nhỏ như thêm RAM hay ổ cứng cũng đủ làm chúng hỏng
- Phần mềm được viết đúng theo đặc tả và lớp trừu tượng có thể tiếp tục được bán sau khi phần cứng thay đổi
-
Đồ họa, chương trình không ký, và LSP
- Việc vẽ pixel lên màn hình vẫn khả thi trong nhiều ngôn ngữ, và Mode 13h cũng được truy cập thông qua VGA BIOS, tức một lớp trừu tượng phần cứng ban đầu
- Mã phụ thuộc vào phần cứng VGA cụ thể thì không di động, trong khi chương trình đồ họa dùng lớp trừu tượng của Windows có thể chạy từ Hercules đến true-color XGA
- Việc chạy chương trình không ký vẫn có thể làm được; có ví dụ tự biên dịch WordGrinder để dùng
- Một phần bất mãn của Blow gần với vấn đề nhà cung cấp phần cứng/phần mềm khóa hệ thống và giảm quyền người dùng hơn là bản thân trừu tượng hóa
- Về Language Server Protocol, tác giả phần lớn đồng ý với Blow, nhưng LSP giải quyết nhiều hơn chuyện “bấm vào phương thức để đi tới định nghĩa”
Game, hiệu năng, và đa nhiệm
- Nhiều ứng dụng năng suất hiện đại có vấn đề về hiệu năng và độ trễ nhập liệu nghiêm trọng
- Một phần nguyên nhân là trừu tượng hóa, nhưng vấn đề lớn hơn là mã tệ và chọn công cụ không phù hợp với bài toán
- Ngay cả các chương trình dùng cùng nền tảng và cùng UI toolkit cũng có thể cho cảm giác hiệu năng rất khác nhau trên cùng một máy
- Vấn đề khôi phục độ phân giải sau Alt-Tab trong game mà Blow nêu ra đúng là trải nghiệm tệ và cần được cải thiện
- Nhưng game DOS ngày xưa đơn giản hơn vì không cần quan tâm tới tiến trình khác
- Muốn chơi Doom trong Windows 3.1 thì phải lưu công việc, đóng chương trình, thoát Windows rồi mới khởi động game
- Nhiều game Amiga cũng boot từ floppy, chiếm trọn máy và không thể quay lại hệ điều hành một cách sạch sẽ
- Tác giả cho rằng đa nhiệm cho game ngày nay tuy chưa hoàn hảo nhưng vẫn tốt hơn trước
Mất mát tri thức và tốc độ thay đổi
- Blow cho rằng tri thức như cách Unity quản lý sprite đang bị biến thành kiến thức tạp nham thay vì hiểu biết sâu
- Tác giả đồng ý rằng tốc độ thay đổi của phần mềm và phần cứng hiện đại nhiều khi nhanh đến mức khó theo kịp một cách có ý nghĩa
- Tuy nhiên, vấn đề này gần với tính nhất quán theo thời gian và mô hình phân phối phần mềm hơn là bản thân trừu tượng hóa
- Nhịp phát hành thứ gì đó mỗi 4 tuần có thể khiến người dùng khó có được trải nghiệm ổn định
- Khi UI thay đổi thường xuyên, người dùng buộc phải liên tục vật lộn với chi tiết của giao diện đang đổi thay thay vì làm việc thật sự
Độ phức tạp là vấn đề do con người tạo ra
- Blow cho rằng nếu con người quyết định giảm độ phức tạp thì có thể giảm được, và rằng nhiều người đang tự đánh lừa mình rằng thêm trừu tượng hóa sẽ tiết kiệm thời gian
- Nếu dùng đúng framework cho đúng mục đích, nó có thể giúp ích lớn cho lập trình viên web
- Đồng thời, tác giả cũng hoài nghi việc cố làm mọi thứ từ xử lý văn bản đến game trong trình duyệt, hoặc thái độ cứ framework mới ra là lập tức chuyển sang
- Độ phức tạp phần mềm không chỉ do lập trình viên tạo ra mà còn do thị trường và môi trường tổ chức
- Chính trị nội bộ, các cuộc họp vô nghĩa, phần mềm chấm công rối rắm, deadline áp từ bên ngoài, yêu cầu khách hàng khó nhằn, quyết định quản lý kỳ quặc, ước lượng tiến độ cho yêu cầu trừu tượng, và debug code legacy đều ảnh hưởng đến lựa chọn của lập trình viên
- Độ phức tạp là vấn đề do con người tạo ra, và nếu giảm được độ phức tạp trong môi trường làm việc thì về lâu dài cũng có thể giảm độ phức tạp của phần mềm
Nhà phát triển trẻ và khả năng tự viết engine
- Luận điểm của Blow rằng các nhà phát triển game trẻ chưa từng tự viết engine và sắp sửa quên mất năng lực đó ở cấp độ tập thể là một dạng suy diễn trơn trượt
- Phần lớn người từng có C64, Amiga hay PC 286 cũng không trở thành nhà phát triển cấp thấp, và nhiều người thậm chí không thành lập trình viên
- Trừu tượng hóa và các game engine dựng sẵn cho phép sáng tạo mà không cần phải học quản lý bộ nhớ cấp thấp, con trỏ hay thuật toán
- Trẻ em ngày nay muốn làm ra thứ gì đó giống game AAA mua ngoài cửa hàng, và kỳ vọng đối với game hiện đại cao hơn rất nhiều so với thời C64 hay Amiga
- Con đường để học kỹ năng cấp thấp vẫn còn đó
- Linux thu hút nhà phát triển trẻ qua cộng đồng mã nguồn mở và dẫn dắt sự quan tâm tới các ngôn ngữ hệ thống như Rust, C, C++
dwmlà một trình quản lý cửa sổ được cấu hình bằng cách sửa trực tiếp mã nguồn C- Vẫn có các nhà phát triển trẻ dùng C và assembly Z80, những người tự dựng Linux distro từ đầu, những người tự làm phần cứng, và các lập trình viên C chạy hệ điều hành nghiên cứu trên phần cứng hiện đại
- Các chương trình khoa học máy tính và kỹ thuật điện tiếp tục dạy các nền tảng như C, assembly, thiết kế trình biên dịch
- Khả năng tiếp cận công cụ lập trình, tài liệu, video giáo dục, và nguồn như MIT OpenCourseWare hiện rẻ hơn và tốt hơn trước
Phán đoán cuối cùng: những vấn đề lớn hơn trừu tượng hóa
- Kết luận của Blow gần với một dạng survivalism áp vào công nghệ, và tác giả đồng cảm với phép so sánh rằng khi mất điện vẫn cần những người biết nhóm lửa
- Xã hội phụ thuộc vào khả năng giữ cho một số chương trình gần như luôn chạy liên tục
- Nếu thất bại, hậu quả có thể nghiêm trọng như sụp đổ kinh tế toàn cầu hoặc thất bại của hệ thống y tế quốc gia
- Hồ sơ lịch sử và hiện đại ngày càng được lưu dưới dạng số nên tương lai cũng phải còn truy cập được
- Độ phức tạp là mong manh, trừu tượng hóa có thể tạo ra kiểu ngu dốt có hại, và không cần shadow DOM để render một blog đơn giản, cũng không cần vỏ trình duyệt cho một IRC client có hình ảnh
- Tuy nhiên, churn nhân tạo và liên tục cũng là nguyên nhân lớn tạo ra tính mong manh
- Phát triển “Agile” có ý định tránh việc phát hành thứ chưa hoàn tất và chưa được kiểm thử kỹ, nhưng trong thực tế lại dẫn đến các bản phát hành dở dang nối tiếp nhau
- Các hệ thống quảng cáo, tracker và telemetry trên thực tế hoạt động gần như backdoor theo thiết kế, làm tăng thêm lỗ hổng và bất an
- Vấn đề lớn hơn của thế giới số là quyền riêng tư và tự do
- Việc con người ngày càng không thể giao tiếp trực tiếp với phần cứng có thể không phải vì chọn trừu tượng hóa, mà vì chúng ta chỉ còn lại những nền tảng ngày càng bị khóa và bị điều khiển từ xa
1 bình luận
Các ý kiến trên Hacker News
Tôi dạy một môn hệ thống ở Montana State, bao quát từ transistor đến các hệ thống điện toán thực tế, và khi bắt đầu môn học có cả những sinh viên không thật sự biết hệ thống tệp là gì
Blow có vài chỗ sai ở chi tiết, nhưng tôi nghĩ với sinh viên khối kỹ thuật thì nên nghiêm túc cân nhắc việc giáo dục kiểu NAND-to-Tetris ngay từ trung học
Chúng tôi dùng các mô hình “cũ kỹ” như Little Man Computer hoặc một trình giả lập MIPS trực quan đơn giản; dù không thực tế, chúng cho người bình thường cảm nhận được chúng ta đã đi từ đâu tới, ở mức độ phức tạp có thể hiểu được
Nhìn vào các giáo trình kiến trúc 64-bit được khuyên dùng hiện nay thì chỉ biết cười, và việc nối công nghệ về tận gốc rễ là một vấn đề khó
Vấn đề là các hệ điều hành di động và công ty phần mềm đang cố biến dữ liệu người dùng thành khu vườn có tường rào trong ứng dụng nhiều nhất có thể
Ngay cả khi bạn đã làm việc với tệp, họ vẫn bắt bạn “nhập” dữ liệu hiện có vào kho lưu trữ riêng của họ, rồi với bản đã chỉnh sửa thì phải tự “xuất” hoặc “chia sẻ” thành một bản sao mới
Tôi đang học thạc sĩ kỹ thuật công nghiệp ở Montana State, và ngày nào cũng phải làm việc với nghiên cứu sinh tiến sĩ không làm nổi đạo hàm riêng đơn giản
Học kỳ trước, trong một môn toán cấp 400, còn có sinh viên không biết cách cộng hai ma trận
Sinh viên năm tư khoa học máy tính không biết hệ thống tệp cũng lạ thật, nhưng so với những chuyện vô lý tôi thấy ở đây thì nó lại có vẻ khá nhẹ nhàng
Bầu không khí khác rất nhiều so với lần đầu tôi học đại học vào thập niên 2000 nên khá buồn, nhưng ngược lại tôi lại thấy tự tin hơn về triển vọng thị trường việc làm vào mùa xuân năm tới
Trái với tên gọi, khoa học máy tính không phải là ngành nghiên cứu về bản thân máy tính; dù máy tính là công cụ thiết yếu, cốt lõi của ngành là trừu tượng hóa miền vấn đề, mô hình hóa bằng ngôn ngữ, và ứng dụng của chúng
Giống như nhà thiên văn chỉ cần biết dùng kính thiên văn đến mức cần thiết, nhà khoa học máy tính chỉ cần biết dùng máy tính đến mức cần thiết
Đặt máy tính ở trung tâm vũ trụ và xem nó là điểm xuất phát của khoa học máy tính là một sai lầm lớn, và về mặt lịch sử cũng là nguồn gốc của nhiều nhầm lẫn
Ngay cả lập trình “cấp thấp” rốt cuộc cũng vẫn là trừu tượng hóa và ngôn ngữ; chỉ là dùng ngôn ngữ của thiết bị điện toán để mô phỏng phần trừu tượng hóa của miền đang được bàn tới mà thôi
Lúc rảnh tôi decompile assembly MIPS, và với các hàm nhỏ thì có thể tự tay chuyển ngược lại thành mã C tương ứng mà không cần công cụ nào khác
Nhưng nó không bị pha loãng. Vì có việc dạy học, sách vở và máy tính, nên ta không cần gọi giáo viên là thi sĩ hát rong
Sau cùng thì đây chỉ là một bài blog khác viết về một bài blog, và tôi không biết các blogger đó “quan trọng” đến mức nào, nhưng nó có mùi blog viết để phục vụ blog
Khi một lập trình viên web lớn tuổi phê phán trừu tượng hóa, họ nhắm vào lập trình viên React; khi lập trình viên Python phê phán, họ nhắm vào lập trình viên web lớn tuổi; khi lập trình viên ứng dụng C++ phê phán, họ nhắm vào lập trình viên Python
Lập trình viên firmware nhắm vào lập trình viên ứng dụng, còn kỹ sư điện nhắm vào lập trình viên firmware
Thật là một thái độ khá ghê gớm khi lấy mức mình biết làm chuẩn để kẻ vạch trừu tượng hóa quá mức, rồi gọi mọi thứ sau vạch đó là “giết chết văn minh”
Có nhiều điểm hay, và vì tôi cũng đã xem bài thuyết trình đó nên tôi nghĩ việc phê bình là quan trọng
Tuy nhiên, điều Blow nói rằng “không thể cứ đơn giản vẽ pixel lên màn hình” là đúng
Tôi làm lập trình viên game engine tại một công ty game cỡ vừa, và việc tuyển người xử lý mã đồ họa đang trở nên cực kỳ khó
Các API cùng thế hệ với DX12 đã nâng yêu cầu đối với lập trình viên lên rất nhiều so với thế hệ trước là DX11, và riêng việc làm được gì đó với API này đã là một khối lượng công việc lớn
Microsoft từng thừa nhận rằng học DX12 khi không có kinh nghiệm với các API đồ họa trước đây là cực kỳ khó, nhưng giờ tôi không tìm thấy trích dẫn đó trong tài liệu nữa
Phản biện rằng “các API kiểu này dành cho lập trình viên muốn đẩy giới hạn card đồ họa và tối ưu hóa ở mức rất thấp” cũng đúng một phần, nhưng nay nó đã trở thành tiêu chuẩn ngành, và gần như không thể dạy cho người không có kinh nghiệm trước đó
Nếu không có gì thay đổi, nguồn ứng viên có thể tuyển dụng sẽ tiếp tục thu hẹp
Khi làm ứng dụng phần mềm, ngay cả việc vẽ một nút bấm lên màn hình cũng trở nên quá khó, đến mức phần lớn mọi người cứ dùng progressive web app chậm hơn hiệu năng khả dĩ tới 100 lần
Thật sự đến năm 2025 mà lựa chọn tốt nhất cho ứng dụng GUI vẫn là Java Swing và Qt sao?
Có những khái niệm lớn kết nối toàn bộ mọi thứ, nhưng trong tài liệu thì hầu như chỉ được ám chỉ; bạn chỉ học được khi tham dự các buổi đào tạo hoặc nói chuyện với người đã biết
Tôi cho rằng những thứ như JavaScript phía server và React đã làm việc phát triển phần mềm web trở nên thật sự hỗn loạn so với những gì chúng thực sự làm
Trong đám trẻ ngày nay, có người thậm chí không biết rằng thứ được render trong trình duyệt là HTML. Họ nghĩ chính React được trình duyệt render
Hơn nữa, CEO của Vercel còn phát ngôn cực kỳ ngớ ngẩn rằng React là Linux kernel của phát triển phần mềm
https://news.ycombinator.com/item?id=42824720
Tôi đã ở đủ lâu để nhớ thời vanilla js, jQuery, Knockout, Angular 1, nhưng ngay cả khi đó sự nhầm lẫn cơ bản vẫn luôn tồn tại
React, đôi khi chỉ riêng JSX thôi, cũng có thể được dùng một cách hợp lý
Thay vào đó, tôi trách các công cụ dựa vào vốn đầu tư mạo hiểm như Vercel, Next, Apollo, Prisma và các influencer phát triển web được trả tiền để nhồi rác lên web
Nghĩ lại thì mọi khâu tạo phần mềm đều đã phình to, từ bảng Notion cho đến những lựa chọn cơ sở dữ liệu đáng ngờ
Nhưng với tư cách một người có thể làm việc tốt mà không cần thư viện, tôi muốn nói thêm rằng DOM là một trong những API tệ nhất mà nhân loại từng phát minh, và “lập trình phản ứng” là một mô hình vượt trội so với cách cũ
NextJS đã đảo ngược nhiều năm cải thiện công cụ và chậm hơn Vite rất nhiều
Trong một trang NextJS build tĩnh không hề có tương tác, nó vẫn tải xuống 100KB JavaScript chỉ để không làm gì cả
Facebook đang cố giải quyết bằng “compiler” cho React một việc lẽ ra chỉ cần mặc định không render lại component một cách vô ích
So với Preact, thứ gần như có thể thay thế nguyên trạng, React là một khối khổng lồ, cho thấy Facebook thiếu quan tâm đến mức nào
HTML là một định dạng tuần tự hóa, và trình duyệt dùng nó để dựng DOM trong bộ nhớ
React không tuần tự hóa bất cứ thứ gì thành HTML mà render trực tiếp vào DOM
Việc điều này sai mà vẫn được upvote cao cho thấy rất rõ thread này mang tính “ông già đấm vào mây”
Theo hiểu biết của tôi, HTML là đầu vào của trình duyệt; trình duyệt chuyển nó thành DOM rồi tiếp tục tới việc vẽ màn hình, xử lý input, v.v.
Khác biệt này quan trọng, vì React hay các thư viện JavaScript kiểu virtual DOM không tạo ra HTML, mà tạo ra các lệnh thao tác DOM bằng JavaScript
Trong các chỉ trích của Blow có nhiều điểm hay, nhưng tôi nghĩ ông ấy bỏ qua việc rất nhiều sự thụt lùi không đến từ trôi dạt giữa các thế hệ hay entropy thông tin, mà từ ác ý trắng trợn của những người ra quyết định
Blow thường chỉ ra những điểm thật sự xuất sắc về phát triển phần mềm, nhưng cũng có lúc hoàn toàn chệch hướng
Ông ấy đạt được nhiều thành tựu và có những ý tưởng đáng nghe, nhưng cũng có nhiều lời nhảm nhí được trình bày lẫn lộn không phân biệt được với chúng
Tôi cảm thấy mạnh mẽ rằng câu chuyện sụp đổ văn minh là một trong những lời nhảm nhí đó; tôi đã nghe hai lần nhưng phần lớn bỏ qua
Cảm ơn bài gốc vì đã đưa ra phản bác có tính nguyên tắc hơn
Tôi thấy Casey Muratori bắt chước Blow nhưng ngay cả những phần hay cũng không làm được cho ra hồn
Muratori cũng không hoàn thành nổi trò chơi đã bắt đầu từ 10 năm trước
Ngược lại, với các game engine hiện đại, kể cả những thứ như Raylib, người ta có thể tạo ra kết quả khá ra dáng ngay trong game jam cuối tuần; còn một game kiểu Sokoban của Blow thì, đặc biệt với đội khoảng 10 người, có lẽ có thể làm trong tầm 6 tháng
Tôi đã xem một phần nội dung của ông ấy, và ông ấy có vẻ khiêm tốn về những chủ đề mình biết nhưng vẫn có quan điểm rõ ràng; tôi cũng nghĩ Handmade Hero được làm rất tốt
Thời gian Jira mất để hiển thị một ticket, thời gian Slack mất để chuyển phòng chat, việc VSCode không theo kịp tốc độ gõ bình thường — thật sự điên rồ
Ông ấy có vẻ chỉ ném ra những phát biểu phê phán rộng rồi lại biến mất để không làm gì cả
Cũng khó nói ông ấy đã đạt được thành tựu lớn; tôi thấy ông ấy làm được ở mức ổn
Ông ấy chỉ phát hành hai game, và chúng giống puzzle hơn là game. Chơi xong một lần thì gần như không cần chơi lại
Braid thì ổn, The Witness thì chỉ giống Flow
Sau đó ông ấy dành 10 năm làm một ngôn ngữ lập trình nhưng không công bố vì “chưa hoàn thiện”
Có vẻ sau khi may mắn kiếm được tiền, ông ấy tự xem mình tài năng hơn thực tế rất nhiều
Môi trường phần mềm hiện đại chắc chắn có rất nhiều vấn đề, và tôi cũng nghĩ trừu tượng hóa quá mức là một vấn đề
Nhưng cực đoan ngược lại cũng tệ, và cũng có xu hướng lãng mạn hóa quá khứ quá mức
Crash và reboot cũng từng là vấn đề; các hệ thống như Amiga có vấn đề tương thích giữa các phiên bản phần cứng, và ngay cả những hệ thống coi trọng tương thích cũng không thoát khỏi bất tương thích
Ngay cả trên Windows 11, hệ thống hiện đại bất ổn nhất, máy tính của tôi vẫn ổn định hơn rất nhiều so với bất kỳ máy tính nào tôi dùng trước năm 2010, và còn có thể chạy phần mềm dành cho Windows 95
Một chiếc máy tính có thể dùng hằng ngày vẫn tốt hơn một chiếc không thể dùng như vậy
Không phải mọi sự đơn giản hóa đều là trừu tượng hóa, và cũng không phải mọi trừu tượng hóa đều là đơn giản hóa
Nhưng trong quá trình theo đuổi sự đơn giản hóa, trừu tượng hóa thường được tạo ra
Tôi không nghĩ trừu tượng hóa giết chết phần mềm hay nền văn minh, nhưng những trừu tượng hóa kém chất lượng được tạo ra nhân danh sự đơn giản hóa ngắn hạn sẽ làm giảm tính linh hoạt, sự nhanh nhạy và khả năng tiếp cận
Nhìn vào cú pháp đường của hầu như mọi ngôn ngữ, sẽ đến một lúc sự đơn giản hóa cục bộ có được từ sắc thái cụ thể đó không còn đủ để biện minh cho việc làm tăng độ phức tạp của toàn bộ công cụ
Trong những ngôn ngữ có nhiều cú pháp, việc mọi người mắc lỗi không phải vì một yếu tố cụ thể nào, mà vì chính việc dùng công cụ để giải quyết tốt các vấn đề phức tạp đã trở nên khó hơn
Độ phức tạp mà async và coroutine trong Kotlin thêm vào trải nghiệm của tôi khi xử lý mã “giống thread”, so với cách Elixir/Erlang xử lý cùng loại vấn đề, là hoàn toàn khác nhau
Cả hai đều cung cấp trừu tượng hóa và đơn giản hóa cho bài toán lâu đời là tính toán song song/bất đồng bộ, nhưng cái trước nhân nhiều lớp đơn giản với nhau để tạo lại thứ phức tạp, còn cái sau gần với một trừu tượng hóa thật sự đơn giản và cứ thế hoạt động
Tác giả có vẻ thuộc thế hệ trẻ hơn, nên dường như đã bỏ lỡ luận điểm của Blow mà không nhận ra
Trớ trêu thay, chính bài viết đó lại giống như một ví dụ mà Blow đang nói tới
Nó giống như khi nói rằng Figma đang bình thường hóa UX, UI và cách quản lý sản phẩm tệ của chính Figma, từ đó phá hỏng thế giới thiết kế ở quy mô chưa từng có, rồi nhận lại phản ứng ngơ ngác từ các designer trẻ rằng mọi thứ vẫn ổn
Kiến thức đó tồn tại vì họ lớn lên trong môi trường ấy, còn những người kia thì không; và cũng không dễ học được những thứ thuộc về văn hóa và trải nghiệm như vậy ở đâu khác
Kiểu công kích cá nhân như thế không đóng góp gì cho cuộc đối thoại
Trái với câu “lập luận rằng phần mềm đang tiến bộ là rõ ràng sai”, hiện tôi vẫn thường dùng những chiếc máy tính Amiga mà mình yêu thích
Vài tuần trước, khi đang sao chép tệp vào ổ cứng Amiga, máy tính đột nhiên bị sập; không phải vì tôi làm gì sai, mà vì hệ điều hành của máy tính gia đình đời cũ vốn không ổn định lắm
Kết quả là phân vùng ổ cứng bị hỏng, hệ điều hành không thể xác minh lại hệ thống tệp, và cuối cùng tôi không còn cách nào khác ngoài định dạng lại phân vùng
Tôi không rành thiết kế, nhưng có thể thấy những tuyên bố về Figma cũng hoàn toàn sai như tuyên bố của Blow
Đó là nỗi hoài cổ đang lên tiếng. Giao diện người dùng lúc nào cũng có rất nhiều thứ lộn xộn, phần mềm cũng vậy, và mọi thứ khác cũng vậy
Người ta chỉ nhớ những ưu điểm của các ví dụ hàng đầu trong quá khứ, còn những thứ rác rưởi và cả thất bại của những thứ từng được thiết kế tốt thì bị quên đi
Vấn đề là những trừu tượng hóa chưa được suy nghĩ thấu đáo
Có rất nhiều trừu tượng hóa rõ ràng chỉ là bản nháp đầu hoặc lần thử đầu tiên, nhưng vì sự sùng bái tốc độ và tính kiêu ngạo của ngành công nghệ mà được tung ra nguyên xi trước khi kịp tinh chỉnh qua nhiều vòng
Khi những trừu tượng hóa đó trở thành một phần của các dự án phổ biến, người khác sẽ sao chép theo tâm lý bắt chước dưới lá cờ mơ hồ mang tên “best practice”
Lặp lại quá trình này trong 10–20 năm sẽ tạo ra một mớ hỗn độn khổng lồ
Tệ hơn nữa, trong một xã hội nghịch lý thay lại bị xã hội hóa quá mức bởi công nghệ, sự đồng thuận xã hội nhằm tránh bị phát hiện là “kẻ lừa đảo” cứ tiếp tục lan truyền các giải pháp chưa chín muồi
Tôi thích bài thuyết trình đó của Jonathan Blow và xem lại ít nhất mỗi năm một lần. Tôi nghĩ ông ấy không nói điều gì gây tranh cãi, mà nhiều lập trình viên nổi giận hoặc thấy nhột vì trong thâm tâm họ biết mình không phát hành sản phẩm với nỗ lực tốt nhất, cũng không dẫn dắt đúng cách thế hệ trẻ
Chúng ta đã đi tới một nền văn hóa nơi việc chạy theo cái mới là thường nhật và đôi khi còn được tán dương
Trước đây, các giải pháp đã được xem xét đầy đủ là chuẩn mực văn hóa, nhưng giờ đây cái mới đã trở thành chuẩn mực, bất kể nó có thật sự tốt hay không
Có thể đào sâu vô tận vào từng chi tiết trong lập luận của Blow, nhưng bằng chứng thì hiện ra trực diện ở khắp nơi
Và trên một trục thời gian đủ dài, điều đó có thể dẫn tới sự sụp đổ của nền văn minh; nhìn vào lượng thứ đang hỏng trên thế giới, cũng có thể xem như chuyện đó đã và đang diễn ra
Thật đáng tiếc khi phải bóc tách chi tiết đến vậy một luận điểm đầy khiếm khuyết
Người theo chủ nghĩa kinh nghiệm thuần túy cũng xa rời thực tế không kém gì nhà lý thuyết thuần túy, và Blow đang dựng lên lập luận chỉ vì nó khớp với trải nghiệm của mình, chỉ chọn những ví dụ phù hợp với lời phàn nàn của mình rồi đẩy các ngoại lệ thành quy tắc