Sự vỡ mộng về phần mềm
(tonsky.me)- Phần mềm hiện đại, thay vì trả lại những tiến bộ phần cứng dưới dạng hiệu quả, gọn nhẹ và mức độ hoàn thiện, lại dựa vào giả định “máy tính đã đủ nhanh” và bình thường hóa sự kém hiệu quả
- Ngay cả những tác vụ cơ bản như cuộn web, mở email trong Google Inbox mất 13 giây, cập nhật Windows 10 mất 30 phút, hay độ trễ nhập liệu trong trình soạn thảo văn bản cũng cho cảm giác chậm hơn kỳ vọng
- Android system 6GB, Windows 10 4GB, Google Keyboard 150MB, các ứng dụng Electron và trường hợp Slack cho thấy sự phình to của ứng dụng và nền tảng dẫn đến chi phí về hiệu năng, độ phức tạp và độ tin cậy
- Như các bản cập nhật OS, ứng dụng, trình duyệt và việc iOS 11 ngừng hỗ trợ ứng dụng 32-bit, phần mềm từng hoạt động tốt cũng có thể chậm đi hoặc hỏng theo thời gian
- Để tạo ra phần mềm tốt hơn, kỹ sư cần hiểu hiệu năng, cấu trúc và giới hạn của hệ thống mình tạo ra, đồng thời tạo ra kết quả nhanh và có thể dự đoán với ít tài nguyên hơn
Phần mềm lãng phí hiệu năng
- Phần mềm hiện đại thường được chấp nhận ngay cả khi chỉ chạy ở 1% hoặc 0,01% hiệu năng khả dĩ
- Trong khi ô tô, kiến trúc và máy bay tiến gần tới giới hạn vật lý hoặc hình dạng tối ưu, phần mềm lại biện minh cho sự kém hiệu quả bằng câu “máy tính đã đủ nhanh”
- Câu cách ngôn “thời gian của lập trình viên đắt hơn thời gian của máy tính” có thể che khuất thực tế rằng thời gian máy tính đang bị lãng phí ở mức chưa từng có
- Tweet về việc viết lại một chương trình Python chạy hằng ngày sang Rust, giảm thời gian từ 1,5 giây xuống 0,06 giây nhưng phải mất hơn 41 năm mới bù lại được 6 giờ bỏ ra, được dùng như một ví dụ tiêu biểu trong tranh luận về hiệu quả
Trải nghiệm cơ bản chậm đến mức không chịu nổi
- Máy tính xách tay hiện đại mạnh hơn máy tính thời kỳ đổ bộ Mặt Trăng hàng nghìn lần, nhưng ngay cả trên MacBook Pro mới nhất cũng khó cuộn trang web mượt ở 60fps
- Inbox do Google tạo ra mất 13 giây để mở một email trong Google Chrome
- Cách animate một ô trắng trống thay vì nội dung gần như là sự thỏa hiệp với giới hạn hiệu năng mà trang web có thể đạt được
- Ngay cả khi màn hình 120Hz đã trở nên phổ biến, tác giả cho rằng việc xem một phản hồi trong cộng đồng web thậm chí còn không ổn định ở 60Hz
- Cập nhật Windows 10 mất 30 phút, và được so sánh rằng trong khoảng thời gian đó có thể định dạng SSD, tải bản build mới và cài đặt nhiều lần
- Trình soạn thảo văn bản hiện đại có độ trễ nhập liệu lớn hơn Emacs 42 năm tuổi
- Tác giả chỉ ra rằng ngay cả tác vụ chỉ cần cập nhật một vùng chữ nhật nhỏ sau mỗi lần gõ phím cũng không xử lý được trong 16ms
- Trong cùng 16ms đó, game 3D thực hiện render toàn màn hình, xử lý nhập liệu, tính toán thế giới và quản lý tài nguyên
- Phần cứng nhanh hơn rốt cuộc được dùng để chạy phần mềm làm cùng một việc nhưng chậm hơn, thay vì phần mềm tốt hơn
Ứng dụng và nền tảng phình to
- Ứng dụng web có thể nhanh hơn 10 lần chỉ bằng cách chặn quảng cáo; AMP gần với một giải pháp theo lẽ thường là loại bỏ phần phình to hơn là một công nghệ mới
- Android system chiếm 6GB ngay cả khi không có ứng dụng nào, Windows 95 là 30MB, còn Windows 10 là 4GB
- Windows 10 lớn hơn Windows 95 133 lần nhưng các chức năng cơ bản không khác nhiều
- Android còn lớn hơn Windows 10 1,5 lần
- Google Keyboard thường chiếm 150MB, Google app 350MB, Google Play Services 300MB
- Tác giả phê phán bằng cách hỏi liệu Google Keyboard, một ứng dụng vẽ khoảng ba mươi phím trên màn hình, có phức tạp gấp 5 lần toàn bộ Windows 95 hay không
- Google Play Services không thể xóa dù không dùng
- Tình trạng sau khi cài các ứng dụng cơ bản chỉ còn khoảng 1GB dung lượng lưu ảnh được đối chiếu với thời kỳ lưu cả OS, ứng dụng và dữ liệu trên đĩa mềm
- Một ứng dụng Todo dựa trên Electron có thể bao gồm cả driver tay cầm Xbox 360, render đồ họa 3D, phát nhạc và chức năng chụp bằng webcam
- Slack là ứng dụng gần với chat và trình soạn thảo văn bản đơn giản, nhưng vẫn bị xếp vào nhóm ứng dụng nặng vì tốc độ tải và mức dùng bộ nhớ
- Khi ứng dụng càng lớn, mất kiểm soát, chi phí độ phức tạp, tổn thất hiệu năng và nợ độ tin cậy càng tăng; không nên chấp nhận ứng dụng quá nặng nề như điều bình thường
Phần mềm mục ruỗng theo thời gian
- Ba năm trước, điện thoại Android 16GB vẫn đủ dùng, nhưng đến thời Android 8.1, các ứng dụng cứ lớn gấp đôi mà không có lý do đặc biệt, khiến việc sử dụng trở nên khó khăn
- iPhone 4s được công bố cùng iOS 5 nhưng chạy iOS 9 rất chật vật, và tác giả chỉ ra rằng iOS 9 cũng không vượt trội căn bản đến vậy
- iOS 11 ngừng hỗ trợ ứng dụng 32-bit, khiến các ứng dụng không còn nhà phát triển hoặc không được cập nhật có thể biến mất mãi mãi
- Bài viết trích một tweet rằng chương trình DOS vẫn chạy trên nhiều máy tính từ thập niên 1980 mà không cần sửa đổi, còn ứng dụng JavaScript có thể hỏng ngay ở bản cập nhật Chrome tiếp theo
- Một trang web hôm nay còn hoạt động bình thường có thể không còn chạy đúng trên bất kỳ trình duyệt nào trong vòng 10 năm tới
- Chúng ta mua điện thoại mới và MacBook mới để làm cùng một việc, nhưng cuối cùng lại lặp lại tình trạng chạy cùng ứng dụng đó chậm hơn
Kỳ vọng về chất lượng đã hạ thấp
- Khi trang web gặp vấn đề, người dùng được yêu cầu bấm tải lại thay vì xem xét nguyên nhân
- Ứng dụng web có thể phun ra lỗi JavaScript “ngẫu nhiên” ngay cả trên trình duyệt tương thích
- Tác giả phê phán rằng thiết kế trang web và cơ sở dữ liệu SQL được xây trên hy vọng rằng dữ liệu sẽ không thay đổi trong lúc người dùng đang xem trang đã render
- Tính năng cộng tác thường chỉ dừng ở mức “nỗ lực tối đa”, chứa đựng những kịch bản thường ngày có thể làm mất dữ liệu
- Hộp thoại kiểu “Bạn muốn giữ phiên bản nào?” gần như có nghĩa là chọn một trong các sản phẩm công việc để phá hủy
- Linux là hệ điều hành phổ biến nhất trên máy chủ dù có thiết kế tùy ý giết tiến trình
- Các ví dụ về màn hình Dell, AirDrop và Bluetooth cho thấy phần mềm bên trong thiết bị và các đặc tả phức tạp tạo ra trải nghiệm phụ thuộc vào reset định kỳ hoặc may rủi
- Để cung cấp thứ gì đó hoạt động ổn định, cần hiểu đối tượng mình tạo ra từ trong ra ngoài, nhưng điều đó rất khó trong các hệ thống bị thổi phồng quá mức
Sự hỗn loạn của công cụ lập trình và thực hành phát triển
- Ngay cả ở các yếu tố cơ bản như quản lý package, hệ thống build, compiler, thiết kế ngôn ngữ và IDE cũng khó thấy được mức độ hoàn thiện nhanh, hiệu quả và bền lâu
- Hệ thống build, dù có toàn bộ thông tin thay đổi, vẫn định kỳ yêu cầu xóa sạch rồi làm lại từ đầu
- Tác giả cho rằng không có lý do gì để không thể làm nó đáng tin cậy, có thể dự đoán và tái lập được
- NPM được mô tả là đã ở trạng thái “thỉnh thoảng mới chạy” trong nhiều năm
- Bài viết trích một tweet rằng
rm -rf node_modulestrông như điều không thể tránh khỏi trong phát triển Node.js/JavaScript
- Thực tế compiler và các bước tiền xử lý/hậu xử lý mất vài phút hoặc vài giờ mà vẫn được chấp nhận mâu thuẫn với câu “thời gian của lập trình viên là quan trọng”
- Việc vẫn chọn Hadoop ngay cả trong tình huống chậm hơn chạy trên một PC duy nhất cho thấy lập trình viên không phải lúc nào cũng đưa ra quyết định hợp lý
- Tác giả phê phán rằng machine learning và “trí tuệ nhân tạo” đã đưa phần mềm sang kỷ nguyên của những phỏng đoán không đáng tin cậy
- Bài viết trích một tweet rằng khi thấy một ứng dụng/dịch vụ dùng “trí tuệ nhân tạo” hoặc “machine learning”, nên hiểu là nó không đáng tin cậy, không thể dự đoán và khó giải thích kết quả
- Cách chạy VM trên Linux rồi đặt Docker trong VM được diễn giải là dấu hiệu cho thấy ta không biết cách dọn dẹp gọn gàng chương trình, ngôn ngữ và môi trường chạy
- Thực tế một file thực thi duy nhất của Go được xem là lợi thế lớn cho thấy chỉ cần không lộn xộn cũng đã được coi là thành công
- Dependency kéo theo chi phí tích hợp và thêm dependency khác khi cố giải quyết vấn đề đơn giản bằng “giải pháp package trọn gói”
- Tác giả chỉ ra rằng khó dùng chương trình trong nhiều năm mà không khởi động lại, đôi khi vài ngày cũng khó
- Khởi động lại tiến trình, khởi động lại cơ sở dữ liệu, watchdog restart ứng dụng mỗi 20 phút, đóng gói trùng lặp tài nguyên và truyền nén là cách bỏ qua thật nhanh thay vì sửa chữa
- Những thực hành này không phải kỹ thuật mà là lập trình lười biếng; kỹ thuật là hiểu sâu hiệu năng, cấu trúc và giới hạn của thứ mình tạo ra
Độ phức tạp chồng chất và sự thờ ơ của thị trường
- Phần mềm hiện nay là trạng thái mã chỉ vừa đủ chạy được chồng lên mã cũng chỉ vừa đủ chạy được, tiếp tục lớn lên và phức tạp hơn, khiến cơ hội thay đổi ngày càng ít
- Một hệ sinh thái lành mạnh đôi khi cần lùi lại rồi tiến lên, nhưng tác giả chỉ ra rằng suốt 25 năm qua không thấy kernel OS mới nào, và giờ mọi thứ đã quá phức tạp để viết lại
- Trình duyệt cũng khó viết lại layout engine từ đầu vì các edge case và vấn đề lịch sử
- Tiến bộ ngày nay trông như đổ thêm dầu vào lửa: đưa microservices vào để giải quyết vấn đề monolith, đưa Docker vào để giải quyết vấn đề microservices, rồi đưa Kubernetes vào để giải quyết vấn đề Docker
- Bài viết trích một tweet rằng chúng ta đã chuyển từ cấu hình khai báo dựa trên XML sang cấu hình microservices dựa trên YAML, nhưng ít nhất XML ngày xưa còn có schema
- Người dùng không có lựa chọn nào khác ngoài chấp nhận những gì kỹ sư cung cấp, và gần như không có lựa chọn trước các tình huống như ứng dụng Android 350MB, cuộn giật, hay “không chạy thì reboot”
- Nếu các sản phẩm cạnh tranh đều chậm, lớn và chất lượng thấp, áp lực cạnh tranh khó xuất hiện
- Tác giả cho rằng đôi khi có những sản phẩm tạo ra căng thẳng như iPhone/iOS so với các smartphone khác, Chrome so với các trình duyệt khác, nhưng điều đó không kéo dài
- Nhiệm vụ của kỹ sư phải là cho thấy với máy tính hiện đại, điều gì là khả thi về hiệu năng, độ tin cậy, chất lượng và tính sẵn sàng
Vẫn có những lựa chọn thay thế
- LMAX Disruptor, SBE, Aeron của Martin Thompson được nêu như những ví dụ ấn tượng, đơn giản và hiệu quả
- Xi editor của Raph Levien được đánh giá là được tạo ra với các nguyên tắc đúng đắn trong đầu
- Jonathan Blow đã tạo một ngôn ngữ cho game của mình, và trên laptop của ông có thể compile mới hoàn toàn 500.000 dòng mã chỉ trong 1 giây
- Đây là kết quả compile mới toàn bộ, không phải incremental build hay cache trung gian
- Viết chương trình nhanh không cần thiên tài hay phép thuật; chỉ cần đừng xây trên một đống rác khổng lồ như toolchain đang thịnh hành
Yêu cầu cho phần mềm tốt hơn
- Software engineering không nên dừng lại ở hiện trạng mà phải trở nên tốt hơn; không cần lặp lại cùng một thứ theo hình thức chậm hơn và lớn hơn
- Phát triển ngày nay gần với trạng thái chỉ vừa đủ đáp ứng mục tiêu kinh doanh trên những công cụ rệu rã hơn là tiến bộ thực sự
- Tác giả chỉ ra rằng do mắc kẹt trong tối ưu cục bộ, chúng ta đã quen với trạng thái phình to và kém hiệu quả
- Kỹ sư có thể và nên tạo ra ứng dụng tốt hơn bằng công cụ tốt hơn, dùng ít tài nguyên hơn nhiều lần, nhanh, có thể dự đoán và đáng tin cậy
- Để cung cấp sản phẩm chất lượng cao, đáng tin cậy và có thể dự đoán, cần hiểu hoàn toàn mình đang làm gì và vì sao; không thể chấp nhận cái cớ “thứ được giao vốn là như vậy”
2 bình luận
Bài này trước đây đã có bản dịch tiếng Hàn, nên bạn chỉ cần xem bản đó là được.
https://tonsky.me/blog/disenchantment/ko/
Tôi đã đổi hẳn sang liên kết bản dịch.
Ý kiến trên Hacker News
Dĩ nhiên là hoàn toàn có thể viết mã nhỏ hơn, sạch hơn, ít lỗi hơn, an toàn hơn, nhanh hơn và bền lâu hơn. Nếu chúng ta đã làm được điều đó từ những ngày đầu của kỷ nguyên thông tin, thì không có lý do gì giờ đây, với hàng chục năm kinh nghiệm và các công cụ mạnh mẽ, lại không làm được
Lý do không làm như vậy là vì ở đó không có tiền; thực ra gần như ngược lại. Startup được VC đầu tư phải ra thị trường trước mới sống sót, còn ngay cả trong các tổ chức trưởng thành, chi phí và sự phình to không phải là vấn đề mà vận hành như một chức năng làm tăng uy tín của nhà quản lý. Cuối cùng chi phí được chuyển sang khách hàng
Lý do “các nguyên lý thị trường tàn nhẫn” không sửa được sự lãng phí này có vẻ là vì, dù một codebase tốt hơn một ngày nào đó có thể nắm được chìa khóa vương quốc, môi trường cạnh tranh trong thực tế lại quá dễ bị tổn thương trước bệnh lý và trào lưu
Tuy vậy, điều có thể làm dễ hơn so với các công ty nhận vốn VC là dành thời gian cho refactoring và xử lý nợ kỹ thuật. Thực tế hiện tại chúng tôi đang phanh gấp việc phát triển tính năng mới trong 45 ngày để xử lý các vấn đề kỹ thuật lớn. Nếu kỳ vọng năm sau sẽ được mua lại thì rất khó đầu tư như vậy, và nợ kỹ thuật trở thành vấn đề của người khác
Chừng nào sản phẩm còn tiếp tục được phát triển, lỗi và vấn đề mới sẽ tiếp tục xuất hiện. “Mã hoàn hảo” chỉ có thể có trong một bối cảnh đóng, nơi không còn tính năng mới nào được thêm vào
Tôi nghĩ mô hình đầu tư VC đã đẩy ngành này đến mức như vậy. Startup nhận hàng triệu đô la, rồi phải kiếm tiền đủ nhanh để trả cho nhà đầu tư, nên phải vắt tiền từ ứng dụng càng nhanh càng tốt. Những việc không gắn với chỉ số ROI thì chẳng ai quan tâm
Về cơ bản từng có truy cập mở, không có mật khẩu hoặc mật khẩu ngắn, lưu mật khẩu không an toàn, mọi thứ đều ở dạng văn bản thuần, bỏ qua việc làm sạch đầu vào, những thứ như telnet
Một lý do khác khiến phần mềm phình to hơn cũng nằm ở đây. Chúng ta bắt đầu thấy các tương tác và rủi ro, và một khi đã thấy thì không thể giả vờ như không thấy. Các điều kiện biên cần xử lý không giảm mà tăng lên, và phần cứng cần hỗ trợ cũng nhiều hơn
Quy trình viết mã hiệu năng cao có thể được cải thiện, nhưng đồng thời đường chuẩn đang tăng nhanh hơn tốc độ chúng ta đạt tới. Việc giờ đây chúng ta đang dần đi theo hướng không dùng mật khẩu trở lại cũng khá thú vị
Độ bao phủ unit test cao khiến refactoring trở nên đau đớn thường cản trở việc phát hành tính năng, và tôi nghĩ chuyện đó xảy ra thường xuyên hơn nhiều so với mức các tín đồ phát triển theo hướng kiểm thử muốn thừa nhận. Nhiều “best practice” trong ngành giống giáo điều phi thực tế do những người ở các công ty đã tìm được product-market fit và tiền tự in ra đặt ra hơn
Tôi vẫn có một chiếc HP MS200 all-in-one còn dùng tạm được. Năm 2017 tôi mua rẻ ở một buổi bán đồ garage sale, và khi cài Linux lên thì sau khi Chrome tải xong, nó vẫn có thể gọi video toàn màn hình bằng bản web của Skype hoặc xem YouTube toàn màn hình
Gần đây tôi nhận lại nó, và trước khi biến nó thành máy tính cho trẻ con, tôi cài FC38 cùng Chrome mới nhất thì video YouTube biến thành slideshow. Dù chỉnh đủ mọi thiết lập vẫn không được, nên tôi tăng RAM từ 2GB lên 3GB, và nó quay lại mức phát 720p toàn màn hình như 6 năm trước
Tức là để làm cùng một việc giờ cần bộ nhớ gấp 1,5 lần, thêm 1GB. Tôi cũng hiểu câu 16GB là mức tối thiểu, nhưng ngay cả trên cái máy tệ hại này, Chrome gần như chỉ là một trình duyệt web nhàn rỗi mà vẫn hiển thị memory footprint khoảng 30GB. Phần lớn có lẽ là các tệp được mmap, nhưng dù vậy vẫn là 30GB
Ngược lại, trên phần lớn thiết bị, thời lượng pin tăng, nhiệt độ thấp hơn, yêu cầu RAM/đĩa nhỏ hơn là những cải thiện rõ ràng. YouTube cũng có thể giữ bản mã hóa cũ trùng lặp trên máy chủ, nhưng trong bối cảnh đa số người dùng truy cập bằng thiết bị hiện đại, đó sẽ là lãng phí dung lượng
Phần lớn mức tăng sử dụng RAM của Chrome đến từ sự phát triển của kiến trúc sandbox. Bộ nhớ dùng chung và không gian tiến trình có thể bị dùng trong các cuộc tấn công thoát sandbox, nên mức cô lập được bổ sung nhiều hơn; việc Chrome mở một tiến trình độc lập mới cho mỗi tab và tiện ích mở rộng cũng là nguyên nhân lớn
Ngày nay trình chặn quảng cáo cũng ảnh hưởng nhiều. Khi web trở nên tệ hơn, việc tạo trình chặn quảng cáo hiệu quả trở nên khó hơn và cần nhiều tài nguyên hơn. Phần mềm chậm không phải chậm chỉ để làm người dùng khó chịu; trong nhiều trường hợp đó là kết quả của việc biến các hack nguy hiểm thành triển khai tốt và yêu cầu đã thay đổi. FLV không còn đủ nữa, và h264 cũng có vẻ khó trụ lâu sau 5 năm nữa khi h265 và AV1 phổ biến
Chuỗi công cụ hiện đại tập trung vào “đừng phát minh lại bánh xe”, nhưng nếu mỗi dependency chọn một phiên bản bánh xe khác nhau, thì chỉ cần kéo vào vài dependency là đã có thể mang theo sáu triển khai của cùng một chức năng cấp thấp
Chỉ có điều thứ được cài là Flatpak, và cảm giác khá phình to. May là Chrome hiện vẫn có thể cài native trực tiếp bằng RPM, và thực sự dùng các thư viện dùng chung của OS
Bài này thậm chí còn không chạm tới nỗi đau cốt lõi là bug. Gần như mọi phần mềm đều có cảm giác đầy bug hết mức có thể. Mỗi khi phải dùng phần mềm theo một đường đi ít phổ biến hoặc luồng bất thường, tôi lại thấy sợ, và hầu như lần nào cũng thất bại
Cách đây không lâu, khi bán xe cho Carvana, tôi phải xoay xở qua lại giữa Chrome và Firefox mới xử lý xong. Trên Chrome, trình hướng dẫn tải ảnh lên ném ra ngoại lệ JS; phần đó thì bằng phép màu chỉ chạy được trên Firefox, nhưng phần còn lại của trang lại có nhiều vấn đề đến mức rõ ràng là họ không hề test Firefox
Tệ hơn nữa là khi người dùng không rành kỹ thuật gặp bug, họ nghĩ mình đã làm sai gì đó. Giờ đây, nếu phần mềm ổn định và chắc chắn, dù phình to và chậm, tôi cũng sẵn lòng chấp nhận
Mặt khác, tôi cứ liên tục thấy mọi thứ đầy bug đến mức nào, và không biết là chúng thật sự nhiều bug hơn, hay càng lớn tuổi và càng biết chuyện bên trong thì tôi càng ít kiên nhẫn hơn với kiểu phát triển phần mềm ở các công ty lớn. Tôi bực với hình ảnh người phụ trách sản phẩm tưởng tượng cứ bảo “phải ra mắt tính năng X ngay” dù những bug UX hiển nhiên vẫn dễ dàng bị bắt gặp
Tôi cũng hiểu và phần nào đồng ý với các lập luận về chi phí, chi phí cơ hội, chủ nghĩa thực dụng, nhưng đôi khi thật khó gạt bỏ cảm giác rằng chúng ta đã mặc nhiên chấp nhận sống trong một thế giới chỉ được xây dở nửa chừng
Bây giờ cũng không có vẻ gì là khá hơn. Khi trẻ nhỏ cầm điện thoại hoặc laptop, chỉ bằng cách bấm nút quá nhanh hoặc theo một thứ tự không ngờ tới, chúng vẫn có thể khá ổn định làm thiết bị hiện đại treo, đơ và crash. Chẳng phải phá hỏng vật lý gì cả, vậy mà đó là tình trạng của công nghệ hiện đại
Tôi hiểu vì sao chuyện này không được sửa. Người ta đã quen kỳ vọng rằng thỉnh thoảng cần khởi động lại, trong các trường hợp này thì dễ đổ lỗi cho đứa trẻ, và khởi động lại là xong. Dù vậy, xét theo vòng đời hệ điều hành, tôi đã hy vọng đến giờ mọi thứ phải tốt hơn
Trong bài viết về C tôi không nói ra, nhưng một trong những lý do lớn khiến tôi dùng C là vì rất khó làm phần mềm phình to. Bạn có thể thêm tính năng, nhưng ngay cả việc một tính năng đơn lẻ làm file thực thi tăng thêm 100KB cũng không dễ
Hiện tôi không ở trạng thái được thuê làm việc, nhưng vẫn dùng một cỗ máy mạnh cho “công việc”. Dù vậy, tôi dùng Neovim và tmux thay vì IDE, dùng Gentoo đã chỉnh sửa nhiều thay vì một bản phân phối Linux thông thường, dùng OpenRC thay vì systemd, và dùng trình quản lý cửa sổ dạng tiling tên Qtile thay vì cả một desktop đầy đủ
Tôi giữ máy không bị phình to đến mức khi khởi động và vừa đăng nhập chỉ có 40 tiến trình. Hiện tôi thực sự đang engineering phần mềm. Tôi đang cố giảm nhẹ hiệu quả các vấn đề của C đồng thời giữ phần mềm nhỏ và nhanh, và hy vọng một ngày nào đó có thể xây dựng một doanh nghiệp trên nền đó
Có lẽ tôi sẽ xem được liệu vẫn còn thị trường cho phần mềm gọn nhẹ, không phình to hay không
https://gavinhoward.com/2023/02/why-i-use-c-when-i-believe-i...
https://gavinhoward.com/2020/12/my-development-environment-a...
https://gavinhoward.com/2023/06/an-apology-to-the-gentoo-aut...
https://gavinhoward.com/2023/09/lessons-learned-as-a-user-3-...
Các chương trình thập niên 1980 như WordPerfect, Lotus 123, MS-DOS 1.0, SubLogic Flight Simulator trước khi được Microsoft mua lại đều được viết bằng assembly. Những người quan sát ngành khi đó cho rằng vì MS Word và MS Excel được viết bằng thứ C “cồng kềnh”, Microsoft có thể lặp tính năng mới nhanh hơn WordPerfect và Lotus 123, cũng như port sang các kiến trúc khác nhanh hơn. Đó là vì các đối thủ ở lại với assembly quá lâu
Tôi cũng thấy cùng một sự đánh đổi trong phần mềm cá nhân. Nếu dùng C#/Python ở mức cao hơn và “cồng kềnh” hơn thay vì C/C++ gọn hơn, bạn có thể hoàn thành một số việc nhanh hơn nhiều. Tôi thành thạo C++ hơn và thích file thực thi nhỏ, nhưng nếu C# giúp xong việc mình muốn nhanh hơn thì lợi thế đó không còn ý nghĩa. Tôi cũng là một phần của vấn đề phần mềm cồng kềnh
“Tôi sẽ xây cây cầu mạnh nhất và nhẹ nhất thế giới” là một việc kỳ diệu, còn “tôi sẽ xây một cây cầu đủ nhẹ và đủ chắc với chi phí khách hàng có thể chịu được” mới là engineering
Tôi mới đọc hơn một nửa rồi dừng, nhưng lập luận cốt lõi có vẻ là phần mềm phải nhanh, và phần biện minh cho triết lý đó thì tôi không nhớ gì ngoài hàm ý rằng “đó đơn giản là chân lý”. Bài có thừa nhận phản biện rằng có những trường hợp phần hiệu quả tăng thêm không bao giờ bù được chi phí thời gian bỏ ra để theo đuổi hiệu quả, nhưng lại bỏ qua mà không thật sự vật lộn với lập luận đó
Một đặc điểm cốt lõi khác của bài là chọn lọc dữ liệu có lợi và đơn giản hóa quá mức các lĩnh vực. Bài nhiều lần dùng lời kêu gọi cảm tính kiểu “rốt cuộc phần mềm dùng ngần ấy thời gian và không gian để làm gì?”, nhưng không cố trả lời câu hỏi đó một cách nghiêm túc, mà dùng việc không có câu trả lời như thể đó là bằng chứng cho một câu trả lời sai. Bài cũng so sánh nhiều phần mềm không tương đương về chức năng như thể chúng chỉ khác nhau về hiệu năng
Có rất nhiều điều để nói về chi phí xã hội, môi trường, kinh doanh của sự kém hiệu quả và về phần mềm hiệu quả hơn, nhưng cũng đáng bàn rằng phần mềm hiện đại cho phép cả những người vốn chẳng thể tạo ra thứ gì cũng tạo được những thứ “tệ” mà họ cần. Giống như kỹ sư kết cấu chọn thứ “đủ bền”, các nhà phát triển hiện đại cũng thường nhắm tới thứ “đủ nhanh”
Có rất nhiều điểm có thể tranh luận phong phú, nhưng bài này dừng ở sự phẫn nộ cảm tính và không xử lý được lý trí cũng như lập luận thực sự. Một số luận điểm có phần đúng, nhưng tôi cho rằng bản thân bài viết đã cho thấy rõ là nó không có ý định tranh luận
Mạng cũng nhiều khả năng là 5G hàng trăm Mbps hoặc cáp quang, chứ không phải 2G vài kbps. Rốt cuộc hành động có sức nặng hơn lời nói, và nếu toàn xã hội tuân theo tiên đề “phần mềm nhanh hơn”, thì có thể chấp nhận nó là sự thật
Đặc biệt đây là một tiên đề xuất phát từ cùng nơi với lập luận “thời gian của lập trình viên có giá trị hơn”, khác biệt chỉ là tiết kiệm thời gian của ai mà thôi
Nếu nhà phát triển không kiểm thử cả trên thiết bị cấu hình thấp, họ sẽ hoàn toàn không biết vấn đề này. Vấn đề thật sự, hơn là khía cạnh kỹ thuật, là thái độ phòng thủ và tranh luận trước tiên của một số nhà phát triển khi đối mặt với sự thật khó chịu rằng mã của họ quá chậm. Cần ngồi với quản lý sản phẩm để dành thời gian profiling và tối ưu hóa, rồi xem có thể giảm nhẹ vấn đề hiệu năng như thế nào mà không phải làm lại từ đầu
BASIC và SQL từ lâu cũng đã có mục đích cho phép mọi người tạo ra một thứ “tệ” nào đó, Fortran cùng nhiều ngôn ngữ/công nghệ nay đã biến mất cũng vậy
Python hay Java, nói rộng lượng thì cũng khá bảo thủ, và nếu nghĩ đến sự phát triển của ngôn ngữ lập trình trong thập niên 70 thì thật ra nên gọi là lỗi thời. J hay Prolog về mặt khái niệm đi trước Rust hay Go rất xa, nhưng lại được tạo ra sớm hơn. C tích lũy từ C89 đến C23 thì là ngôn ngữ hiện đại, hay chỉ C23 mới hiện đại, và liệu giữa C89 với C23 có thật sự khác biệt lớn không cũng là điều mơ hồ
Nếu không dựa vào thời điểm được tạo ra hay một cây tiến hóa tưởng tượng, tôi tự hỏi liệu có cách nào khác để định nghĩa tính hiện đại không
Đây là lời than phiền cũ. Rất nhiều tiện ích mà chúng ta xem là hiển nhiên đều có chi phí, và chi phí đó cộng dồn rất lớn. Màn hình 4K có số pixel gấp 17 lần 800x600 và dùng màu 32-bit, nên kích thước thô của đồ họa dành cho màn hình hiện đại lớn hơn khoảng 68 lần
Trước đây ảnh tĩnh là đủ, nhưng giờ hoạt ảnh chất lượng cao, tốc độ khung hình cao đã là tiêu chuẩn. Arial Unicode là một phông chữ 15MB, và có lẽ còn không vừa bộ nhớ của hầu hết máy tính chạy Windows 95
Kiểm tra chính tả ở khắp nơi đã trở thành điều hiển nhiên, và những thứ như vậy cứ tích lũy lại. Dù vậy, chúng khiến máy tính dễ chịu hơn rất nhiều. Tôi không nhớ nhung chế độ video 16 màu, hay cái thời không thể dùng đồng thời hai ngôn ngữ không phải tiếng Anh nếu không có những cách né vòng rất khó chịu
Nhưng tôi không muốn hoạt ảnh chỉ có lý do là khiến thời gian chờ trông bớt nhàm chán. Unicode thì đáng trả chi phí
Dù vậy, cũng như năm 1981, glyph vẫn phải được vẽ lên màn hình trong vài mili-giây một chữ số. Pixel và glyph đã nhiều hơn, nhưng việc đó là khả thi, chỉ là không được ưu tiên mà thôi
Nó giống như trả 100.000 USD cho một chiếc BMW hiệu năng cao, rồi kỹ sư nói rằng xe mất 30 giây để tăng tốc 0-60mph, và người dùng vì không phải chuyên gia hiệu năng nên phải chấp nhận như vậy
Tôi cũng đã thấy một xu hướng tương tự trong tổ chức hiện tại. Lúc đầu, khi đội còn nhỏ, các chi tiết rất quan trọng. Không được chậm, animation phải mượt, tốc độ cuộn và thời gian tải đều quan trọng, và chúng tôi cố tạo ra sản phẩm hiệu quả nhất để nâng cao hiệu suất của người dùng
Khi đội lớn lên, giá trị chuyển sang hướng nâng cao hiệu suất của lập trình viên. Nhiều abstraction, layer và framework hơn được đưa vào, và người ta chấp nhận sự đánh đổi: tiết kiệm một ngày của lập trình viên bằng cái giá là tiêu tốn hàng triệu giây của toàn bộ người dùng
Khác biệt nằm ở tính hiển thị. Ban lãnh đạo có thể thấy chi phí phía phát triển, nhưng không thấy lợi ích của thời gian chạy nhanh hơn một chút, caching tốt hơn, hay cuộn mượt hơn. Vì chúng không được đo lường. Khi tổ chức đi đến điểm chỉ quan tâm đến những con số đo được, xu hướng này trông có vẻ tự nhiên
Tất nhiên, đó là cho đến khi AI đạt tới điểm có thể sửa mọi thứ chúng ta viết sai, hoặc AI viết sai, và cả chính AI cực kỳ kém hiệu quả như bài gốc dự đoán
Ô tô chỉ được tối ưu sau khi có cú sốc dầu mỏ từ bên ngoài, và ngay cả thế cũng rất không đồng đều. Trên thực tế, sản phẩm kém hiệu quả thường sinh lời hơn vì khách hàng phải thay thế thường xuyên hơn. Một sợi cáp iPhone tệ hại nứt sau 1 năm cho phép Apple tính tiền phụ kiện thay thế hết lần này đến lần khác. Đồ gia dụng trắng hỏng thường xuyên hơn nhưng được sản xuất rẻ hơn, làm tăng lợi nhuận trên mỗi đơn vị. Điều quan trọng là hiệu suất sản xuất, chứ không phải hiệu suất sử dụng sau khi bán
Trong phần mềm, chủ nghĩa tư bản vận hành bằng cách tung ra tự động hóa mới nhanh nhất có thể, rồi bắt người tiêu dùng gánh lãng phí năng lượng và thời gian. Chuỗi sản xuất ngày càng được chuẩn hóa và tối ưu, đến mức có thể thay thế lập trình viên React hay quản trị viên Kubernetes như công nhân kho, kéo theo áp lực lương. Một số tự động hóa gần giống sự tự biện minh, như làm thuật ngữ kế toán trở nên khó hiểu để biện minh cho nghề nghiệp; phần còn lại là về lợi nhuận
Mọi thứ đều có chi phí. Nếu chi phí tính toán hoặc trải nghiệm người dùng tệ đi đủ lớn, người ta sẽ tối ưu hiệu suất. ML model là ví dụ. Trong các trường hợp khác thì không tối ưu, vì người dùng cuối không muốn điều đó đến mức phải chấp nhận ít tính năng hơn
Ô tô trước đây cũng ngốn nhiều nhiên liệu, nhưng đã thay đổi khi chi phí nhiên liệu và lo ngại môi trường khiến khách hàng muốn thứ khác. Nhiều kỹ sư quên mất rằng họ được trả tiền để làm sản phẩm cho khách hàng
Ngoài ra, tác giả bài gốc có vẻ chưa từng phải chờ một máy Windows hay Linux đời cũ khởi động hoàn toàn. Các phiên bản hiện đại khởi động nhanh hơn nhiều vì khách hàng muốn vậy. Điện thoại luôn bật 24/7, nên việc vài tháng mới khởi động một lần và mất lâu không phải điều khách hàng bận tâm
BIOS của tôi mất khoảng 20 giây để POST, và người ta bảo như vậy là bình thường. Sau đó OS khởi động mất khoảng 10 giây
Có thể nói bác sĩ hay kỹ sư cũng được trả tiền để phát triển thuốc mới hoặc nguồn điện mới, nhưng vì các lĩnh vực này nhạy cảm và quan trọng nên có nhiều tầng kiểm soát của chính phủ. Phần mềm vẫn chưa có mức kiểm soát như vậy
Họ có sức mạnh định hình chính môi trường, nên có thể bẻ hướng đáng kể kết quả của “nhu cầu khách hàng”
Bài này được viết năm 2018, và đã có vài cuộc thảo luận trước đây
https://news.ycombinator.com/item?id=18012334 (Sep 2018)
https://news.ycombinator.com/item?id=21929709 (Jan 2020)
https://news.ycombinator.com/item?id=31798580 (Jun 2022)
Tôi rất đồng cảm. Là lập trình viên, điều quan trọng là nhớ rằng chúng ta có quyền lựa chọn. Không thể lựa chọn mọi thứ, nhưng ta có thể chọn phương án ít tệ hơn
Không nhất thiết phải dùng Node. Trong hệ sinh thái .NET hay JVM, ta vẫn có thể viết phần mềm tốt, tương thích ngược, và kỳ vọng nó vẫn chạy sau 10 năm mà không cần sửa
Cũng không nhất thiết phải làm trang web single-page. HTML kiểu cũ tải lại toàn bộ trang sau mỗi lần click vẫn hoạt động tốt, và ở thời điểm này thậm chí có thể có độ trễ thấp hơn
Cũng không nhất thiết phải làm app desktop bằng Chromium. Khởi động một UI framework có thể tốn thêm chút công, nhưng chất lượng xứng đáng với điều đó. Không phải lúc nào ta cũng có quyền quyết định, nhưng khi có, ta nên thoát khỏi những lựa chọn tệ