Khủng hoảng phần mềm
(wryl.tech)- Thuật ngữ “software crisis” xuất hiện tại hội nghị NATO Software Engineering năm 1968 nay ít còn được dùng, nhưng gánh nặng do độ phức tạp và sự trừu tượng hóa của phần mềm tạo ra vẫn còn nguyên
- Trong bài giảng nhận giải Turing năm 1972, Edsger Dijkstra cho rằng hiệu năng phần cứng và độ phức tạp đã tăng vọt, trong khi các phương pháp có tính tổ chức để xử lý chúng lại không theo kịp
- Việc thương mại hóa điện toán cá nhân và chu kỳ phát hành nhanh khiến người dùng muốn dung lượng lớn hơn trước khi kịp nắm vững công cụ, và “abstract it away” trở thành phản ứng mặc định
- Các lớp trừu tượng lồng nhau tạo ra chi phí hiệu năng và những mô hình tinh thần bị méo mó, đồng thời khiến việc tiếp cận các chức năng cơ bản của máy như đồ họa và âm thanh trở nên khó khăn
- Giải pháp không phải là quay lại các nền tảng bị ràng buộc của quá khứ, mà là giảm số lớp trừu tượng và giữ lại thông tin giữa các lớp để trao lại quyền chủ động cho người dùng công cụ
Mối vấn đề được nêu ra từ năm 1968 vẫn chưa kết thúc
- Thuật ngữ “software crisis” được đặt ra tại hội nghị NATO Software Engineering đầu tiên năm 1968
- Các hội nghị này là một trong những nỗ lực ban đầu nhằm sắp xếp và hệ thống hóa thực tiễn lập trình cho các máy tính tự động
- Ngày 16 tháng 7 năm 1969, sứ mệnh Apollo 11 được phóng lên, và đến tháng 10 cùng năm, hội nghị NATO Software Engineering cuối cùng được tổ chức
- Trong bài giảng nhận giải Turing năm 1972, Edsger Dijkstra truy nguyên nguyên nhân của cuộc khủng hoảng từ những cỗ máy ngày càng mạnh hơn và sự thiếu vắng các phương pháp có tổ chức để gánh vác chúng
- Ông để lại một phát biểu với ý rằng “khi chưa có máy tính thì lập trình không phải là vấn đề, khi chỉ có vài máy tính yếu thì đó là vấn đề nhẹ, còn khi xuất hiện những máy tính khổng lồ thì lập trình cũng trở thành một vấn đề khổng lồ”
- Ngày nay, trong thực hành lập trình, cụm từ “software crisis” không còn xuất hiện thường xuyên
- Sự phát triển của các ngôn ngữ mới và các phương pháp có tổ chức, cùng với khoảng cách thời gian với những vấn đề quá khứ, khiến ngành có được cảm giác yên tâm rằng phần nào đó đã giải quyết xong
- Nhưng cảm giác yên tâm đó vẫn gần với sự đầu hàng và chấp nhận hơn là sự thoải mái thực sự
Trừu tượng hóa khiến quyền chủ động của người dùng ngày càng xa vời
- Sự phát triển của điện toán thời kỳ đầu và các lĩnh vực lân cận diễn ra trong những cỗ máy và môi trường mà việc chồng thêm tháp trừu tượng phải trả giá trực tiếp
- Khi không thể lách qua các giới hạn, một chu kỳ tăng trưởng sẽ diễn ra cùng với việc nâng cấp phần cứng
- Trên thực tế, người ta lại muốn dung lượng lớn hơn trước khi hiểu đủ về các giới hạn hiện tại
- Sau khi điện toán cá nhân được thương mại hóa, các công ty bán thiết bị không chờ người dùng nắm vững hoàn toàn sản phẩm của họ, và chu kỳ tăng trưởng tiếp tục tăng tốc
- Cùng với chu kỳ phát hành phần cứng nhanh, “abstract it away” trở thành lối tư duy mặc định
- Khi đẩy những chi tiết không vừa ý vào trong một cấu trúc có thể kiểm soát, ta có được một mức độ độc lập nào đó, nhưng phải trả giá bằng hiệu năng
- Nhiều lớp trừu tượng và cơ chế che giấu thông tin đã đẩy bài toán xây dựng phần mềm lên các tầng cao hơn
- Các lớp này được tích hợp vào cả phần mềm cần thiết để sử dụng máy tính lẫn phần mềm vận hành đời sống
- Ngành công nghiệp phần mềm rộng lớn hơn đã đẩy nhanh ảnh hưởng của chu kỳ phát hành và tư bản, làm suy yếu không gian mà các nhà phát triển cá nhân có thể dễ dàng tiếp cận
- Khủng hoảng phần mềm không chỉ là vấn đề của nhà phát triển mà còn kéo dài tới người dùng phần mềm
- Người dùng gần như không có quyền kiểm soát ngoài những chức năng mà tác giả phần mềm cho phép
- Việc tạo ra và sử dụng phần mềm đều là hoạt động của con người, nhưng điều đó ngày càng bị làm mờ đi
Nơi cần hướng tới không phải quá khứ mà là các lớp nông hơn
- Giải pháp được đề xuất không phải là quay về các nền tảng bị giới hạn hơn
- Cần giới hạn số lượng lớp trừu tượng được phép tồn tại
- Cần bảo toàn thông tin giữa các lớp
- Mô hình lập trình, giao diện người dùng và phần cứng nền tảng cần nông hơn và có thể kết hợp được
- Những phong trào như Handmade, Permacomputing và cộng đồng retrocomputing đang dẫn tới một làn sóng nâng cao nhận thức về khủng hoảng phần mềm
1 bình luận
Ý kiến trên Hacker News
Xin chào, tôi là tác giả bài viết. Tôi nghĩ cần làm rõ một số điểm thường bị hiểu lầm trong bài này. Tôi không phản đối bản thân sự trừu tượng hóa, mà phản đối việc áp dụng nó không giới hạn
Giải pháp cũng không phải là quay về các nền tảng có nhiều ràng buộc hơn, hay lập luận kiểu người dùng nên “chịu đựng và trở nên kỹ thuật hơn”. Cốt lõi để hiểu cuộc khủng hoảng phần mềm là các đường cong của “mức độ thành thạo nền tảng” và “chu kỳ tăng trưởng/phát hành”. Trong hơn 40 năm qua, ngoại trừ vài lĩnh vực, các đường cong này đã tách xa nhau; chúng ta đã không giải quyết được khi chúng còn gần nhau, nhưng thời điểm tốt thứ hai chính là bây giờ
Cũng có phản ứng cho rằng bài này là clickbait, nhưng đây là bài đầu tiên trên log của tôi và chứa những suy nghĩ về tình cảnh của tôi với tư cách lập trình viên. Tâm trạng tương tự có thể thấy dưới nhiều hình thức ở nhiều cộng đồng, đặc biệt là một số cộng đồng dựa trên phản văn hóa. Tôi cũng định viết bài tiếp theo “tôi sẽ cho thấy cách làm” để trình bày một phần lời giải. Đây là việc tôi làm một mình, nên mong mọi người cho tôi chút thời gian và không gian
Khi có hàng triệu người làm phần mềm, không thể sửa triệt để vấn đề này. Chắc chắn sẽ có một phần trong số đó bất đồng quan điểm, và cũng không phải ai cũng có thể thành thạo như tác giả. Vì vậy, cuối cùng tôi đọc bài này như một lập luận rằng tiêu chuẩn cho “trừu tượng hóa chấp nhận được” cần được nâng cao hơn hiện nay
Nói chung chung thì dễ, nhưng nếu thật sự nhìn vào một lĩnh vực cụ thể mà ta cho là “bị trừu tượng hóa quá mức”, rất có thể ta sẽ khiêm tốn hơn. Những “trừu tượng hóa quá đà” như vậy thường cũng có lý do khá chính đáng, và các kỹ sư trong lĩnh vực đó cũng cảm thấy tình trạng trừu tượng hóa rất lộn xộn, nhưng họ cho rằng nó cần thiết hoặc không thực tế để sửa
Ví dụ, nhiều phần mềm được xây bằng cách đặt một lớp trừu tượng hóa tốt lên trên các trừu tượng hóa trung gian được dùng rộng rãi. Kubernetes nằm trên Linux, runtime container, và cấu trúc truyền thống gồm control plane/lớp cấu hình/data plane là một ví dụ. Ta cũng có thể triển khai trực tiếp toàn bộ logic này trong một hệ điều hành mới, nhưng khi đó sẽ phát sinh vấn đề tương thích với người dùng. Có thể xây được, nhưng có thể không có người dùng; và khi đó ta lại phải triển khai lại những trừu tượng hóa tệ mà mình muốn tránh. Hơn nữa, cách giải như vậy khó triển khai hơn rất nhiều. Tôi không thích thiết kế của Kubernetes nên muốn giải quyết vấn đề này, nhưng tôi xem kết cục là làm theo “cách đúng” quá khó hoặc quá đắt đến mức không còn đáng nữa
Tùy vào thời điểm và bối cảnh bạn bước vào lĩnh vực này, rất có thể các trừu tượng hóa của thế hệ trước đã được đưa vào như những thông lệ mặc nhiên được chấp nhận. Chẳng hạn, đã có thời việc dùng một hệ điều hành có hệ thống tệp đa dụng trở thành tiền đề hiển nhiên
Tôi nghĩ vấn đề đang được nói tới hiện nay gần với những khó khăn khi gia nhập lĩnh vực này. Nếu giả định rằng phải hiểu tường tận mọi trừu tượng hóa đang được dùng thì mới có thể đóng góp, lượng kiến thức nền cần có là rất lớn. Có thể cảm thấy bị choáng ngợp, nhưng cũng có con đường là chấp nhận các trừu tượng hóa cho đến khi có thể hiểu sâu hơn
0 - https://en.wikipedia.org/wiki/Clarke's_three_laws
Tuy nhiên, tôi cho rằng lý do tình trạng này không thay đổi là hoàn toàn mang tính kinh tế. Điều đó không có nghĩa phần mềm tệ rẻ hơn. Nhưng nếu cắt góc, cá nhân hoặc tổ chức có thể tiết kiệm chi phí ngay bây giờ, còn chi phí lớn hơn sẽ được tổ chức đó, khách hàng và toàn xã hội gánh chịu về sau, nên có động lực rất mạnh cho các thực hành rẻ và tệ. Hơn nữa, với phần mềm rất khó áp dụng các tiêu chuẩn của những ngành kỹ thuật khác, nên cũng khó tạo ra hợp đồng hoặc quy định yêu cầu phần mềm đạt một tiêu chuẩn hay chất lượng cụ thể
Giải pháp duy nhất có thể hình dung là một cuộc cách mạng công nghệ cho phép tạo ra phần mềm rẻ hơn và tốt hơn bằng cùng công nghệ, đồng thời khiến việc tạo ra phần mềm rẻ hơn nhưng tệ hơn trở nên bất khả thi
Có quá nhiều phần mềm trên quá nhiều nền tảng, và địa hình bị phân mảnh đến mức khó nói điều gì mang tính tổng quát. Một số dự án thì lung lay và sụp đổ, trong khi một số khác vẫn chạy tốt
Có những phần mềm thù địch với người dùng, nhưng đó là chủ ý thiết kế. Đằng sau là sự hoài nghi và lòng tham. Không phải vì lập trình viên không biết mình đang làm gì, mà vì họ làm theo những gì được yêu cầu
Chính người dùng cũng góp phần thúc đẩy điều này. Dù bạn làm ra phần mềm tốt, họ cũng không quan tâm; người dùng đòi hỏi những thứ khác, không phải phần mềm tốt. Một người dùng muốn phần mềm tốt trở thành nạn nhân của năm mươi người dùng không muốn như vậy. Phần mềm thị trường đại chúng giờ đã là văn hóa đại chúng
Word thời đó cũng không thiếu thốn quá nhiều so với phiên bản hiện nay. Thế nhưng giờ Windows và Office cần 50–100GB dung lượng đĩa chỉ để hoạt động. Chúng ta đã nhận được gì để đổi lấy mức tăng gấp 1000 lần đó?
Đây là chuyện hoàn toàn điên rồ, nhưng chúng ta cứ bỏ qua. Các hệ thống hiện đại có dung lượng đĩa, RAM và CPU tăng khoảng 5000–10000 lần, còn Internet gia đình thì nhanh hơn modem thời kỳ đầu đúng nghĩa là hàng triệu lần
Bài viết này đặt tiền đề rằng khủng hoảng phần mềm thực sự tồn tại hoặc là một vấn đề nghiêm trọng. Các yếu tố của khủng hoảng được nêu gồm vượt ngân sách, trễ tiến độ, kém hiệu quả, chất lượng thấp, không đáp ứng yêu cầu, dự án không thể quản lý, mã khó bảo trì, không bàn giao, v.v.
Nhưng nếu bỏ từ “phần mềm” ra khỏi đây, có bao nhiêu hoạt động của con người không gặp ít nhất một trong những vấn đề này? Ngược lại, thực tế cũng có rất nhiều phần mềm khá tuyệt vời. Chúng ta chỉ muốn nhìn vào thất bại và khiếm khuyết, còn thành công thì dù vẫn tiếp tục tốt lên cũng bị xem nhẹ như một mức chuẩn hiển nhiên
Từ lúc nhấn nút nguồn máy tính cho đến khi vào được desktop, ta đã đi qua hàng trăm lớp trừu tượng. Chỉ riêng desktop đó đã là thứ phức tạp nhất trong số các cỗ máy mà chúng ta tương tác suốt cả ngày. Việc này diễn ra hàng chục tỷ lần mỗi ngày trên toàn thế giới, và nhìn chung là không có vấn đề gì. Đây cũng chỉ là một ví dụ rất nhỏ
Tuy vậy, tôi cho rằng động cơ thực sự của những bài viết kiểu này không phải là các mục đó, mà là cảm giác mọi thứ trở nên quá sức chịu đựng. Một lập trình viên có kinh nghiệm phải cân bằng cảm giác choáng ngợp đó với những việc cần làm. Để đi đến đây mất thời gian, nhưng tôi tin điều đó quan trọng. Sẽ không bao giờ có chuyện mọi thứ được sắp xếp hoàn toàn gọn gàng, và ta phải chấp nhận sự thật đó
Với phần mềm, ngoài các ràng buộc về hiệu năng và bộ nhớ, gần như không có giới hạn nào như vậy. Nhưng cả hai thứ đó đều dư dả đến mức người ta có thể cứ đắp thêm rác vô tận mà vẫn vượt qua được. Tất cả chúng ta đều từng có lúc nghĩ hoặc nói: “Thứ này rốt cuộc chạy được kiểu gì vậy?” Trước khi người dùng đạp phải một điều kiện biên sai, ta không biết đoạn mã bên dưới mong manh đến mức nào
“Bạn đã thử tắt đi bật lại chưa” chính là bằng chứng. Các hệ thống phần mềm thường rơi vào một trạng thái xấu quá tinh vi và khó hiểu, đến mức giải pháp duy nhất là xóa sạch mọi thứ và dựng lại từ đầu. Kiểu như điện thoại vẫn tiếp tục rung sau khi nhận cuộc gọi cho đến cuộc gọi hay tin nhắn tiếp theo, hoặc trong web app có phần không tải đủ 100% khiến tùy chọn biến mất, hay Bluetooth pairing hoạt động thất thường
Giao tiếp là cách lan truyền sự thấu hiểu và sửa chữa sự thiếu hụt của nó, còn thấu hiểu là nền tảng của thành công trong bất kỳ việc gì. Nếu không có thấu hiểu, một hoặc nhiều triệu chứng ở trên sẽ xuất hiện. Có thấu hiểu thì chúng vẫn có thể xuất hiện, nhưng ít nhất sẽ có một con đường dẫn đến thành công
Theo kinh nghiệm của tôi, phần lớn vấn đề trong ngành kỹ nghệ phần mềm là vấn đề con người. Không phải công nghệ, không phải bản thân kỹ thuật, cũng không phải quy trình. Vì vậy giao tiếp và thấu hiểu là điều thiết yếu để thành công
Khi nhìn vào lý lịch của ban lãnh đạo ở các công ty kỹ thuật hay công ty ô tô, ta thấy những nấc thang trong đó họ đảm nhận trách nhiệm ngày càng lớn hơn về thiết kế linh kiện, component, sản phẩm hoặc vận hành cơ sở sản xuất. CEO vẫn nhấn mạnh kiến thức kỹ thuật, và ngay cả nhân sự phi kỹ thuật ít nhất cũng giả vờ như vậy
Ngược lại, trong phát triển phần mềm Agile, năng lực kỹ thuật thường dừng lại ở tầng thấp nhất. Trong Scrum team có những người làm ra phần mềm, và chỉ có vậy. Nhiều Scrum Master và business analyst rất có thể chưa từng code nhiều, còn người sếp thực sự đầu tiên trong hệ thống cấp bậc thì phần lớn làm công việc thư ký, quản lý nên hầu như không xem code
Vấn đề không chỉ là phát triển phần mềm diễn ra theo đơn vị kích thước ticket, khiến khó suy ngẫm một cách triết học về số tầng trừu tượng mà mình tạo ra và duy trì. Lập trình viên thậm chí không có ghế ở bàn ra quyết định. Họ được Scrum Master “chăm sóc”, phải thỏa hiệp trong code review, chịu áp lực không nghĩ ra ngoài ticket, và thường cũng không có lộ trình thăng tiến nào đưa năng lực kỹ thuật lên tầng lãnh đạo
Vì vậy, phong trào muốn cảnh báo về “khủng hoảng phần mềm” có vẻ nhiều khả năng sẽ chỉ nằm trong các lĩnh vực sở thích như Handmade, Permacomputing, retro computing, đúng như cách diễn đạt ở cuối bài. Tôi nghĩ Hollywood cũng có một phần trách nhiệm khi liên tục khắc họa người làm phần mềm/IT theo cách bẽ mặt, trong khi lại không ngừng trao vai chính cho bác sĩ và luật sư, biến các thuật ngữ chuyên môn phức tạp thành câu chuyện hấp dẫn. Phía chúng ta thật sự là bất khả thi sao? Có lẽ sắp tới AI viết kịch bản sẽ làm được điều gì đó
Phát triển phần mềm là công việc cả ngày đối thoại một cách nghiêm ngặt với máy tính. Nó giải quyết những việc bình thường đã có lời giải trong một ứng dụng mới, hoặc những vấn đề mà nếu không có nền tảng kỹ thuật thì thậm chí khó nắm bắt. Dù tôi là lập trình viên đã code cho vui hơn 20 năm, phần lớn công việc vẫn chán đến phát điên. Tôi còn không cố giải thích cho người không phải lập trình viên. Nó kém thú vị như kế toán, và có lẽ nhiều người sẽ thu được thông tin hữu ích hơn từ một câu chuyện khác
Công ty đắm chìm trong Agile nhất mà tôi từng làm coi junior và senior như những bánh răng có thể thay thế cho nhau. Khác biệt chỉ là senior phải xử lý nhiều point hơn mỗi sprint. Có sự kìm hãm chủ động rằng đừng nghĩ ngoài phạm vi ticket, và bầu không khí là cúi đầu xuống, ngậm miệng lại
Tuy nhiên có hai vấn đề. Họ không thể đi sâu vào chi tiết triển khai, và cũng bị ràng buộc bởi các động lực méo mó: tạo ra phức tạp thì được thưởng. Tất nhiên cũng có người chống lại điều đó, nhưng những người như vậy khó có khả năng được thăng chức. Bạn sẽ không được thưởng vì cắt giảm nhân sự dưới quyền mình hay làm cho vai trò của mình biến mất
Nói ngắn gọn lý do lập trình viên chỉ xử lý phần yêu cầu thực tế ở mức kích thước ticket là vì họ quá ngốc. Họ không giữ được toàn cảnh trong đầu, cũng không hiểu nó. Nghe bực bội không? Đúng vậy. Nó thật sự khó hiểu. Xin lỗi
Bài viết này mô tả trừu tượng hóa như một điều ác, nhưng để tạo ra phần mềm do con người làm có năng lực trên một mức nào đó, đây là công cụ không thể tránh khỏi
Rich Hickey từng nói đại ý rằng “người tung hứng mới tập có thể xử lý hai, ba quả bóng, nhưng ngay cả người tung hứng giỏi nhất thế giới có lẽ cũng chỉ giới hạn ở khoảng chín quả. Năng lực con người không chênh nhau theo bậc độ lớn, và rất nhanh chạm trần”. Muốn vượt qua giới hạn đó thì không còn cách nào ngoài trừu tượng hóa
Tất nhiên trong từng trường hợp cụ thể có thể tồn tại trừu tượng hóa tệ hoặc quá nhiều trừu tượng hóa, và tôi nghĩ phần khiến tác giả tức giận cũng nằm ở đó. Nhưng sự phân biệt ấy rất quan trọng
Phần nói rằng “giờ đây không dễ làm phần mềm, và chẳng có thứ gì đi kèm tài liệu hướng dẫn” rõ ràng là sai. Việc làm phần mềm đã dễ hơn bao giờ hết, và tài liệu cũng được chuẩn bị tốt hơn
Để hiểu một tổng thể phức tạp, không nhất thiết phải cần gián tiếp hóa. Muốn xử lý độ phức tạp, ta phải gỡ những thứ đan rối ra để có thể hiểu từng phần một cách độc lập. Nếu dùng gián tiếp hóa để che giấu độ phức tạp, sẽ xuất hiện khoảng cách giữa chúng ta và đối tượng mà chúng ta cần suy luận
Trừu tượng hóa tốt cho người dùng. Vì dù là lập trình viên hay không, họ không cần bận tâm đến chi tiết. Nhưng nó không làm cho công việc tạo ra thứ đó của chúng ta trở nên dễ hơn
Trái với câu “giờ làm phần mềm không còn dễ nữa”, nếu biết đúng công cụ cho đúng công việc thì việc đó rất dễ. Chỉ là thông tin về những công cụ như vậy bị kìm nén nên hầu như chúng ta không nghe đến
Hệ sinh thái công cụ kỹ thuật mà đa số mọi người hình dung rất khác với thực tế. Phần lớn công cụ chúng ta biết đều tệ hại. Chúng cố tỏ ra như giải pháp vạn năng, nhưng thực tế lại chẳng thật sự tốt cho việc gì. Vậy mà chúng vẫn là những công cụ phổ biến nhất. Như bài viết ám chỉ, tôi cho rằng đó là do ảnh hưởng của tư bản
Ví dụ, với công cụ tôi đang dùng hiện nay, tôi đã quay một video tạo từ đầu một ứng dụng marketplace tương đối phức tạp, có đăng nhập, kiểm soát truy cập, kiểm chứng schema và các view lọc phức tạp, chỉ bằng trình duyệt, không tải bất kỳ phần mềm nào, serverless, trong 3 giờ. Toàn bộ ứng dụng có chưa đến 700 dòng HTML markup và 12 dòng JavaScript. Lượt xem khoảng 10
Trái với cú twist kiểu thuyết âm mưu đó, các công cụ hiện đại linh hoạt và dễ dùng hơn bao giờ hết. Chúng có khiếm khuyết, nhưng chẳng là gì so với những gì lập trình viên vài thập kỷ trước phải trải qua. Không có một âm mưu khổng lồ nào nhằm chôn vùi công cụ của bạn cả
Tôi rất tin vào no-code/low-code và các công cụ có thể chạy ở mọi nơi. Chỉ là ý tôi có thể khác với điều bạn đang nghĩ. Dù sao thì việc bạn làm ra được nó cũng đáng ghi nhận
Khi bắt đầu xem video, câu hỏi đầu tiên của tôi là: Codespaces là gì? Bảo mật thế nào? Ứng dụng cuối cùng chạy ở đâu? Tôi có thể chạy nó trên phần cứng của mình không? Có thể chạy mà không cần truy cập cloud không? Cloud nào? Nó có còn tồn tại tuần tới, tháng tới, năm sau, hay 10 năm nữa không? Tất nhiên, đừng quá bận tâm chỉ vì một mẫu như vậy
Tình hình no-code/low-code có thể ví với chế bản điện tử. DTP không có pipeline CI/CD. Bạn bấm in là xong. Đó là một môi trường tích hợp hoàn toàn. Ngược lại, gần như mọi môi trường “tích hợp liên tục” theo nghĩa đen trông như đang tự nuốt chửng chính mình vì cố gào lên quá mức. Ở đâu đó chắc sẽ có các công cụ để tách màu, đặt lề, nhập phông chữ, dùng thư viện header PostScript hoặc tạo LaTeX, nhưng phần lớn mọi người không nhìn thấy cũng không dùng chúng. Ở đâu đó cũng có thể có người in đa bản bằng các sắc tố đa dạng hơn CMYK rất nhiều, chỉ rực rỡ dưới ánh sáng tự nhiên, nhưng đa số chỉ xem những ảnh chụp nhanh tệ hại trên điện thoại nên không thấy việc đó có ý nghĩa
Đây không chỉ là vấn đề của người sáng tạo. Người tiêu dùng không biết điều gì là khả thi, và cũng không có thiết bị để phơi bày toàn bộ phạm vi khả năng đó. Thiết bị tiêu dùng chủ động làm suy giảm phạm vi ấy vì vô số lý do hệ sinh thái đóng và vì sự cẩu thả, thiếu hiểu biết tầm thường
Vài năm trước tôi nhận được một chiếc Cadillac khi thuê xe, và tôi sẽ không bao giờ mua Cadillac hiện đại, thậm chí nếu có thể thì cũng tránh lái. Tôi không điều khiển được cần gạt nước, còn màn hình console thì nhiều lần hiện cảnh báo nổi bật nhất rằng tôi không nhìn đường. Có lẽ nó không nhận ra là tôi đang đeo kính. Vì đang đi giữa dòng xe tốc độ cao trên con đường lạ nên thực ra tôi không nhìn màn hình, mà hỏi người đi cùng: “Cái màn hình nhấp nháy kia rốt cuộc đang nói gì vậy?” Làm tốt lắm, Cadillac
Cấu trúc nông và có thể kết hợp là điều ai cũng trải nghiệm khi dùng các công cụ UNIX
GUI thì sụp đổ ở điểm này. GUI đúng nghĩa là những hòn đảo, không giao tiếp với nhau theo cách có thể kết hợp
Tôi đang thử nghiệm việc trộn ý tưởng GUI với pipeline shell bằng một công cụ tên là guish
https://github.com/williamcotton/guish
Tôi tò mò liệu có ai biết công cụ tương tự hoặc cách tiếp cận GUI có thể kết hợp nào không
https://hisham.hm/userland/
https://arcan-fe.com/2021/04/12/introducing-pipeworld/
http://conal.net/papers/Eros/
Tôi cũng đang làm một số ý tưởng liên quan đến việc này, và nhìn bề ngoài có vẻ giống của bạn. Tuy nhiên, tôi khuyên bạn nên xem cách việc này hoạt động trong emacs. Tôi chưa tìm hiểu sâu, nhưng cách tiếp cận của bạn trông không “có thể kết hợp” cho lắm
Nếu bạn chưa biết thì cái này cũng có thể truyền cảm hứng: https://gtoolkit.com/ Đây là một môi trường Smalltalk, nơi đúng nghĩa là mọi thứ đều có thể lập trình như emacs, nhưng gần như theo hướng ngược lại. GUI không phải là kết quả của lệnh, mà là chính ngôn ngữ đó
Nhưng vấn đề lớn hơn không phải là GUI. GUI cũng là vấn đề, nhưng vì nó buộc phải nằm ở đỉnh của stack abstraction nên các vấn đề không tiếp tục được kết hợp thêm nữa. Thú vị là vì nó là vấn đề quá lớn nên rốt cuộc lại không còn là vấn đề nữa
Con voi khổng lồ ngày nay là các hệ thống phân tán
Tuy nhiên GUI từ lâu đã là điểm yếu. Có lẽ vì việc UI có tốt hay không có nhiều cân nhắc mang tính “toàn cục”, nên đó không phải là một thuộc tính kiểu mô-đun
Cá nhân tôi muốn có nhiều UI hơn nhưng vẫn giữ được khả năng tự động hóa. Tức là thuộc tính cho phép lưu những gì đã gõ trong shell vào file để chạy lại sau, chỉnh sửa rồi chạy lại, và sao chép lệnh gửi email cho bạn bè
Để nói thêm bối cảnh, tôi đã xây một shell từ đầu trong nhiều năm và có headless mode cho GUI. Cũng có vài demo thực tế do người khác viết, nhưng hiện không ai làm tiếp nữa
Ảnh chụp màn hình:
https://www.oilshell.org/blog/2023/12/screencasts.html#headl...
https://www.oilshell.org/blog/tags.html?tag=headless#headles...
Có thêm nhiều liên kết ở đây - https://github.com/oilshell/oil/wiki/Interactive-Shell - cũng có các dự án thú vị nhưng không còn hoạt động như Xiki
Nếu bạn cần một shell tương thích tách khỏi terminal, hoặc một shell mới như vậy, hãy cho tôi biết qua email hoặc https://oilshell.zulipchat.com
Về cơ bản, tôi cần người thử nghiệm giao thức headless và cho biết các điểm cần cải thiện. Tôi cho rằng nên xây một GUI cho shell “sở hữu” terminal nhưng không phải “chính” terminal. Điều đó có vẻ cũng liên quan đến thứ bạn đang làm
Hiện tôi chủ yếu làm ngôn ngữ YSH mới, nhưng cũng muốn hồi sinh phần GUI. Tôi không có nhiều kinh nghiệm làm lập trình viên UI, nên sẽ rất tốt nếu có góc nhìn khác
Và tôi rất vui vì bạn thích ggplot nên đã đưa nó vào. Thực ra ggplot chính là điểm khiến tôi tiếc rằng shell không có đồ họa
Câu cuối “Nó có thể tốt hơn. Tôi sẽ cho thấy cách làm” trông chỉ như phần mở đầu để câu clickbait
Câu nói “những mô hình này rất hiếm khi phản ánh thực tế. Nếu có thì đó là một sự trùng hợp tốt đẹp, còn nếu không thì là thảm họa” không khớp với trải nghiệm của tôi
Nhìn chung, phần lớn phần mềm trên thị trường không mang tính sống còn. Rất nhiều web app cồng kềnh, tệ hại có thể hút vô ích một lượng lớn tài nguyên suốt cả ngày, bộc lộ lỗi thất thường khắp nơi, nhưng vẫn thực hiện một cách tệ hại việc mà người dùng kỳ vọng. Tất cả đều đúng
Nhưng chúng không mang tính sống còn như phần mềm điều khiển máy tạo nhịp tim hay tên lửa vũ trụ. Phần lớn phần mềm có thể lộn xộn cũng được. Vì hầu hết dự án liên quan đến những thất thường của con người, và kịch bản tệ nhất của việc thiếu chất lượng cũng chỉ là đôi chút bực bội, chứ không dẫn đến thảm họa hay cái chết
Hơn nữa, phần lớn lập trình viên có lẽ cũng không làm việc trong kiểu động lực tiền bạc của Silicon Valley, cũng không kiếm sống bằng những dự án họ muốn làm vì đam mê. Phần lớn phần mềm được đưa ra thị trường được tạo ra thông qua các cấu trúc thưởng phạt tệ hại từ bên ngoài. Bạn còn mong sản phẩm của quá trình như vậy là gì ngoài rác?
Tôi thật sự ghét những bậc thang bị thiếu
Chúng ta ở rất xa việc sử dụng thực tế phần mềm do mình tạo ra, và chỉ trải nghiệm những tín hiệu ngắn hạn, có thể hành động, dùng để định hướng quy trình phát triển. Trừ khi có thể hoán đổi thân thể với một người dùng mới, rất khó cảm nhận đúng nỗi đau thực sự của kiểu “cái chết bởi một nghìn vết cắt” này
Tôi xem lập trình là một nghề, và cho rằng chúng ta có sức mạnh để quản trị chất lượng phần mềm. Chỉ là có những động lực, dù tài chính hay không, khiến chúng ta ngoảnh mặt đi
Tôi không nghĩ có khủng hoảng phần mềm. Hàng triệu lập trình viên trên toàn thế giới đang tạo ra những chương trình hữu ích ở mức nào đó, và gần như mọi thứ, kể cả máy nướng bánh mì, đều chạy phần mềm đủ thành công. Cộng đồng cũng đã tạo ra các chương trình mà từ trẻ 5 tuổi đến ông bà đều có thể tiếp cận. Khủng hoảng ở đâu trong chuyện này?
Nhưng có một khủng hoảng quản lý dự án. Nó không chỉ giới hạn trong phần mềm, mà là vấn đề người lập kế hoạch và người giao sản phẩm ngày càng xa nhau. Và dường như chúng ta không thể lấp khoảng cách đó. Agile, Scrum, v.v. là những chỉ dấu của khoảng cách này, nơi các “guru” coi tất cả chúng ta như kẻ ngốc, và chính chúng ta cũng chưa tạo ra được thứ gì tốt hơn
Việc hàng hóa hóa phát triển phần mềm cũng góp phần vào sự hỗn loạn này. Do đặc thù của một lĩnh vực dễ gia nhập, người ở mọi trình độ đều có thể tham gia với tỷ lệ thành công khác nhau. Đây không phải vấn đề tốt hay xấu, mà là bản chất của hiện tượng. Không khác mấy việc ngành ẩm thực có cả nhà hàng sao Michelin lẫn MacDonalds, và cả hai đều có khách hàng. Nhưng vì thế mà không gọi là khủng hoảng nhà hàng
Điều này làm giảm tuổi thọ của máy nướng bánh mì. Ngày xưa có thể từng có máy nướng bánh dùng được 10 năm. Giờ đây, vì phần mềm tệ và có lẽ cả kết nối WiFi hoặc Bluetooth bị ép buộc, khi nhà cung cấp ngừng cập nhật thì sau 2 năm nó thành rác. Có thể ngay từ đầu đã chẳng có bản cập nhật nào. Chỉ là cuộc khủng hoảng không phải lúc nào cũng thấy rõ vì nó không trực tiếp hiện ra, hoặc vì tình trạng tiêu dùng quá mức hiện nay và việc mua sản phẩm mới không ngừng
Máy nướng bánh ngừng chạy sau 2 năm thì chúng ta vẫn cho là ổn, và có thể không quan tâm hoặc không biết vì sao. Nhưng có thể nó từng là một phần của botnet Mirai https://www.cloudflare.com/learning/ddos/glossary/mirai-botn...
Máy nướng bánh mì có lẽ dùng chip đơn giản hơn nên chắc không phải, nhưng ai mà biết được
Nhân tiện, máy nướng bánh Dualit của tôi không chạy phần mềm
Đoạn “chúng ta đã xây dựng các lớp trừu tượng lồng nhau và phát triển cách che giấu thông tin ở nhiều cấp độ. Chúng ta đã biến vấn đề xây dựng phần mềm thành những tầng lớp cao chót vót” khiến tôi liên tưởng đến trừu tượng bị rò rỉ và Tháp Babel
https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...
https://en.wikipedia.org/wiki/Tower_of_Babel
https://en.wikipedia.org/wiki/Hierarchy
https://en.wikipedia.org/wiki/Abstraction
https://en.wikipedia.org/wiki/Abstraction_(computer_science)
Những mục này đáng để so sánh với nhau