3 điểm bởi GN⁺ 2023-10-19 | 1 bình luận | Chia sẻ qua WhatsApp
  • Phần mềm vô dụng là một kiểu chơi đùa giúp lấy lại niềm vui của việc tính toán, thoát khỏi áp lực phải tạo ra kết quả thực dụng, và Hurl cũng là một thử nghiệm bắt đầu từ một “trò đùa”
  • Người làm kỹ thuật dễ bị đặt lâu trong môi trường phải tạo ra kết quả hữu ích, nên tia lửa niềm vui khiến họ bắt đầu lập trình có thể dần yếu đi
  • Trong các dự án để chơi, bạn tự đặt ra việc có viết test hay không, có dùng issue tracker hay không, tiêu chí hoàn thành là gì, và có thể dừng bất cứ lúc nào khi đã học đủ hoặc không còn thấy vui nữa
  • Công cụ cờ vua, kho khóa-giá trị triển khai một phần Redis API, tiện ích Wake-on-LAN, trực quan hóa cờ vua, và cơ sở dữ liệu cờ vua đều là những thử nghiệm để học về GUI·hệ thống·mạng·bên trong DB
  • Đối xử với máy tính bớt nghiêm túc hơn và thử làm những thứ “trông có vẻ vô dụng” là một cách thực tế để vừa học vừa vui

Sự tự do mà tính “vô dụng” mang lại

  • Tác giả từng được hỏi “vì sao lại làm Hurl?”, và câu trả lời ngắn gọn là: để đùa thôi
  • Câu trả lời dài hơn là phần mềm vô dụng cho phép ta trải nghiệm niềm vui và sự khám phá trong thế giới máy tính
  • Người làm kỹ thuật thường bị ràng buộc vào việc tạo ra thứ hữu ích
    • Kỹ sư phần mềm viết mã để giải quyết các vấn đề thực tế
    • Nhà khoa học máy tính nghiên cứu vấn đề để tạo ra kết quả mới mẻ và có tính thực tiễn
    • Người viết tài liệu kỹ thuật làm việc với công nghệ và tài liệu thực tế
  • Nhiều người bắt đầu lập trình vì theo một cách nào đó họ thấy niềm vui trong công việc ấy, và cảm giác đó có thể cũng góp phần vào lựa chọn sự nghiệp của họ
  • Khi cả ngày đều phải làm những việc hữu ích, sự hứng thú rất dễ suy giảm
    • Việc phải làm luôn đi kèm nghĩa vụ và áp lực
    • Mọi hoạt động đều gắn với công việc
    • Trong quá trình đó, ta rất dễ đánh mất yếu tố chơi đùa vốn quan trọng
  • Phần mềm vô dụng là một cách để thoát khỏi những nghĩa vụ đó
    • Bạn có thể tự quyết định mình muốn nhận được gì từ dự án
    • Bạn có thể dừng bất cứ lúc nào
    • Nếu không muốn viết test thì có thể bỏ qua
    • Nếu không muốn dùng issue tracker thì có thể bỏ luôn
    • Khi đã học được điều mình muốn học và không còn thấy vui nữa, bạn có thể kết thúc dự án

Những dự án được làm như một cuộc chơi

  • Một công cụ cờ vua và UI tệ hại có đầy lỗi, nhưng lại là dịp để hiểu sâu hơn về lập trình GUI, lập trình game và cách một chess engine hoạt động
  • Kho khóa-giá trị được dùng để học lập trình hệ thống và cách viết mã hiệu quả hơn trong khi triển khai một phần Redis API
  • Tiện ích Wake-on-LAN là dự án để tìm hiểu cách WOL hoạt động và học lập trình mạng bằng Rust
  • Trực quan hóa ván cờ giúp thử nghiệm cách tạo nghệ thuật bằng mã và trực quan hóa trò chơi yêu thích
  • Với cơ sở dữ liệu cờ vua, tác giả đã học được rất nhiều về bitmap và cấu trúc bên trong của cơ sở dữ liệu
  • Tác giả cũng từng làm một công cụ dùng LLM để “mansplain” xem một lệnh làm gì
  • Việc triển khai giao thức phía máy chủ POP3 vẫn chưa hoàn thành, nhưng quá trình đó rất vui vì được học về giao thức và tưởng tượng xem một ứng dụng dựa trên POP3 sẽ trông như thế nào
  • Tác giả cũng làm theo “Crafting Interpreters” bằng Rust, học được rất nhiều về interpreter và compiler, với mục tiêu không phải là hoàn thành mà là tận hưởng quá trình
  • “Mazes for Programmers” được làm bằng Rust khoảng nửa chừng rồi dừng lại vì nó bắt đầu biến thành công việc, và tác giả không muốn làm tiếp nữa
  • Những script nhỏ cũng được viết ra để nghịch ngợm và thử nghiệm với ý tưởng cùng khái niệm
  • Hurl cũng là một dạng chơi như vậy; dù không hữu ích, quá trình học hỏi và tạo ra thứ gì đó vẫn có thể mang lại niềm vui

1 bình luận

 
GN⁺ 2023-10-19
Ý kiến trên Hacker News
  • Tôi thích làm phần mềm vô dụng. Chỉ riêng những thứ làm trong năm nay đã có uncolouring book ở https://lines.potato.horse, MeatGPT ở https://meat-gpt.sonnet.io, Medieval Content Farm ở https://tidings.potato.horse, You deserve butter ở https://butter.sonnet.io, Mrr ở https://mrr.sonnet.io, và Mrr chính xác về mặt vật lý ở https://mrrr.sonnet.io
    Một vài trong số đó thực ra gần với các bài blog được chế tác cầu kỳ hơn, và vì diễn đạt bằng cách nghịch code dễ hơn giải quyết vấn đề thật, nên chúng đã bị làm quá mức. Danh sách dài hơn có ở https://sonnet.io./projects

    • Món đồ vô dụng tôi thích nhất là https://sc.rollc.at. Cảm giác như cuối cùng cũng tìm được một công dụng biện minh được cho cuộn vô hạn
    • https://meat-gpt.sonnet.io là một trong những thứ buồn cười nhất tôi thấy trên Internet sau một thời gian dài. Đúng là vàng ròng
    • Lấy cảm hứng từ những dự án này và các liên kết khác trong bài, tôi đã tạo một tài khoản Scratch và thử làm đồng hồ kim: https://scratch.mit.edu/projects/910890145
      Đứa con 8 tuổi của tôi chơi Scratch hằng ngày và tôi thường giúp khi nó có câu hỏi; hóa ra làm một dự án ngớ ngẩn, thêm cả hoạt ảnh vô dụng chỉ cho vui, lại khá thú vị. Nhờ đó mà ở nhà giờ câu “Hurry to love! Hurry to love!” đã thành câu cửa miệng
    • Được bài viết truyền cảm hứng, tôi đã tự lập một danh sách: https://untested.sonnet.io/Here's+a+List+of+Toys
      Thực ra tôi đã quên khá nhiều thứ trong đó
    • Nhân tiện, có vẻ liên kết mrrr ba chữ r không hoạt động
  • Hoàn toàn đồng ý. Gần đây tôi đã đi trường hề, và nhận ra mình đã quá ám ảnh với việc làm dự án cho “đúng” hoặc cho “tốt”
    Đời là để sống, và nếu cố làm phần mềm quá “đúng đắn” thì sẽ vắt kiệt niềm vui khỏi nó. Vì vậy dạo này tôi cố viết code vui vẻ hơn, và kết quả là tôi cũng viết nhiều code hơn hẳn, mọi thứ trôi chảy dễ dàng hơn. Gần đây, để thử một ý tưởng về tiến hóa schema, tôi tự làm một thư viện tuần tự hóa nhị phân kiểu protobuf, và hiện đang làm một cơ sở dữ liệu local-first dựa trên CRDT. Hôm qua dữ liệu đầu tiên đã đồng bộ được, và tôi thật sự phấn khích. Trong nhiều năm tôi đã viết rất nhiều code để giải các Serious Problems, cũng như nhiều code làm theo bốc đồng, nhưng trớ trêu là những đoạn code tôi tự hào nhất lại là những thứ làm cho vui. Với các dự án vui, tôi cứ quay lại bảo trì và cải thiện; còn các dự án nghiêm túc thì thường héo úa rồi chết khi tôi rời đi

    • Khái niệm min/maxing trong game dường như cũng áp dụng được cho các lĩnh vực khác của cuộc sống
      Thay vì hòa vào nhịp chơi và tin vào quá trình, người ta bắt đầu đọc hướng dẫn để tạo nhân vật mạnh nhất, tối đa hóa chỉ số và nhắm tới hoàn thành 100%. Cuối cùng, niềm vui khám phá và những cuộc gặp ngẫu nhiên từng làm game hay ho biến mất, và thời gian bị dành cho việc tối đa hóa chỉ số như những lần tung xúc xắc ngẫu nhiên. Các hoạt động khác cũng tương tự: trong khi cố tối đa hóa thứ gì đó, dù là của cải hay chất lượng code, cảm giác kỳ thú và tinh thần “cứ thử xem” sẽ biến mất
    • Trước đây tôi thích vật lý học. Lý do nó vui là vì tôi chơi đùa với vật lý. Tôi làm những gì mình muốn, dựa trên việc nó có thú vị và vui để tôi nghịch hay không, hơn là nó có quan trọng với sự phát triển của vật lý hạt nhân hay không
      https://www.asc.ohio-state.edu/kilcup.1/262/feynman.html
    • Chúc mừng bạn vào Princeton
    • Tôi cũng cảm thấy điều tương tự khi chơi Factorio. Ban đầu tôi cùng bạn làm một nhà máy spaghetti, cứ mỗi lần yêu cầu thay đổi lại liên tục refactor, và việc đó thật sự rất vui
      Nhưng rồi khi sa vào tối ưu hóa, đột nhiên nó trở thành một trò chơi chỉ có một đáp án đúng, và chỉ sau một đêm mọi niềm vui biến mất. Thường thì ta học được nhiều hơn khi làm mọi thứ thật tệ vì kiêu ngạo và tùy hứng. Ý nghĩ “khó đến mức nào chứ?” đã nhiều lần kéo tôi xuống những độ sâu vượt quá khả năng xử lý, nhưng trong quá trình thoát ra tôi luôn học được rất nhiều và cũng tìm thấy niềm vui
    • Việc mọi người đều giả định “trường hề” hoặc là trường hề thật, hoặc là một trường Ivy League, nói lên khá nhiều điều
  • Bất kỳ nghề thủ công/kỹ năng chế tác (craft) nào cũng có những phần trái với trực giác. Cứ làm nhiều hơn thì nhìn chung cuối cùng kỹ năng sẽ khá lên. Hãy viết truyện ngắn dở tệ, nặn đồ gốm xấu xí, vẽ tranh phong cảnh méo mó
    Có tác dụng luyện tập là một chuyện, nhưng còn có xu hướng lớn là ta tự gạt bỏ ý tưởng nếu trong đầu chưa nhìn thấy rõ thành phẩm đáng kỳ vọng. Với người thiên về phân tích, điều đó đặc biệt có vẻ như một quyết định thông minh để giảm thời gian lãng phí, nhưng đồng thời cũng là cách chắc chắn để không làm ra gì cả. Trong các dự án phần mềm “vô dụng”, nhiều thứ vẫn tiếp tục vô dụng, nhưng cũng có những thứ tìm thấy giá trị lớn hơn trong quá trình làm. Rốt cuộc lại dẫn tới câu sáo rỗng kiểu “bạn bỏ lỡ 100% những cú sút bạn không thực hiện”, nhưng chắc bạn hiểu ý

    • “Tôi luôn làm những việc mình chưa biết làm. Đó là cách tôi học làm chúng.” — Van Gogh
    • Hồi đầu tuổi teen khi trượt skateboard, tôi từng tự hỏi liệu việc “cứ tiếp tục thử” một ngày nào đó sẽ giúp mình học được ollie, hay chỉ khiến mình trở nên cực kỳ giỏi trong việc thất bại khi ollie
  • Đây không chỉ là câu chuyện khuyên viết phần mềm “vô dụng”, mà còn là lập luận rằng trong các dự án nhỏ nên tránh những thứ gọi là best practices
    Tôi đã làm một trình tạo site tĩnh cho danh mục item, mà danh mục thì đơn giản và không thay đổi thường xuyên. Sau khi băn khoăn nên dùng cơ sở dữ liệu nào, cuối cùng tôi quyết định nhét tất cả vào một mảng tĩnh trong codebase. Như vậy bớt đi một dependency phải nghĩ tới, và với mục đích của tôi thì nó hoàn toàn phù hợp

    • Tôi nhận ra điều này khá sớm. Khoảng năm 1998, có một dự án dùng Oracle làm kho nội dung chỉ vì “nó có sẵn ở đó”, và khi xem xét hiệu năng, chúng tôi kết luận rằng “tần suất triển khai phần mềm mới còn cao hơn tần suất thay đổi dữ liệu, nên lẽ ra cứ compile nó vào sản phẩm là được”
      Tôi không biết rốt cuộc họ có đổi sang cách đó thật không, nhưng từ đó về sau, mỗi khi nghe nói “cần cơ sở dữ liệu”, đó luôn là câu hỏi đầu tiên tôi đặt ra
    • Cách làm phù hợp luôn thắng best practices
    • Tôi không xem “không dùng cơ sở dữ liệu” là best practice. Best practice đúng hơn là dùng công cụ tốt nhất cho công việc. Cách được mô tả rất khớp với ví dụ đó
    • Tôi cũng đưa ra quyết định tương tự trong một dự án sở thích. Phiên bản hiện tại thực chất chỉ tra cứu dataset, không tạo/xóa/sửa
      Dù sao tôi cũng phải đưa toàn bộ dữ liệu vào bộ nhớ để chạy thuật toán đồ thị, nên tôi nhận ra việc lưu dữ liệu chỉ đọc trong cơ sở dữ liệu gần như chẳng có ý nghĩa gì. Tôi hoàn toàn không có ý định triển khai Bellman-Ford bằng SQL
    • Một người bạn của tôi đưa mọi thứ mình học được vào dự án mã nguồn mở của anh ấy. Ban đầu đó là nơi trình diễn best practices, và giờ các dự án đó đã trở nên khá nổi tiếng
  • Tôi học được điều này khi code cùng một người bạn mà tôi từng nghĩ là lập trình viên tệ hại
    Chúng tôi thân nhau nên cùng làm nhiều dự án thú vị, nhưng anh ấy trông thật sự như không biết mình đang làm gì. Copy/paste khắp nơi, không kiến trúc, không thiết kế, đặt tên tệ, có lẽ một nửa thời gian còn không chắc code thật sự làm gì. Nhưng nó chạy được. Cuối cùng tôi nhận ra anh ấy làm được nhiều thứ hơn tôi. Anh ấy không sa đà vào những chuyện vụn vặt, và làm được nhiều hơn hẳn. Anh ấy không viết unit test, nhưng cứ chơi với sản phẩm như một đứa trẻ và liên tục test thủ công. Rốt cuộc tôi cũng chấp nhận lối nghĩ đó. Vì không có phần mềm danh bạ nào làm đúng chức năng tôi muốn, tôi định tự làm, nhưng thay vì cố tạo UI bóng bẩy, tôi dùng django-admin rồi coi như xong. Tôi đã dùng cái mớ form kinh khủng đó suốt 10 năm nay và nó làm đúng việc cần làm. Hồi chưa có CLI cho TOTP, tôi viết bằng Python và dump seed ra TOML dạng plaintext. Mất 5 năm tôi mới thêm mã hóa, vì chỉ cần symlink file từ một container Veracrypt là đủ và ít việc hơn. Hai tháng trước, tôi muốn có một bộ đếm thời gian: tập thể dục thì nạp ngân sách thời gian, chơi video game thì tiêu hao, nên tôi đã làm nó (https://substackcdn.com/image/fetch/w_1456,c_limit,f_webp,q_...). Tôi ghép vào một đống Tailwind do ChatGPT phun ra, điều khiển bằng HTMX, và thế là đủ. Cho bạn bè xem thì 4 người xin tài khoản, một người còn nhờ cho bác sĩ của chương trình cai nghiện dùng thử. Không có form đăng ký nên tôi hard-code luôn. Tôi muốn nói với bản thân lúc trẻ rằng hãy ngừng ám ảnh với việc làm cho đúng hoặc chỉ làm những vấn đề quan trọng. Dù sao cả đời tôi cũng chưa từng đạt tới cái gọi là “đúng”

    • Vài năm trước, tôi nhận ra nếu cố làm đúng ngay từ đầu những thứ như tên dự án thì thường là hỏng
      Sau khi bắt đầu để nguyên cái tên IDE đặt cho đến khi chứng minh được dự án thật sự thú vị, tôi cảm thấy tỷ lệ thành công của mình tăng lên. Có vẻ nó liên quan đến cùng một nguyên lý gốc
    • Phần mềm cứ tạm thời đóng đinh, chắp vá cho chạy trước; sau khi biết mình muốn gì và cần gì thì dọn dẹp sau cũng được
      Đặc biệt khi dọn code của người khác, có một logic khá kỳ lạ. Vừa chửi “rốt cuộc người này nghĩ gì vậy?”, nhưng đồng thời cũng có sự thật là người đó đã khởi động được nó
    • Trước đây có một người từng truyền cảm hứng cho tôi, dù tính cách thì cực kỳ tệ và code tôi thấy sau này cũng kinh khủng
      Nhưng anh ta kiếm 100 USD/giờ ở một quốc gia có mức lương thấp. Anh ta mua domain và nội dung, viết lại phần mềm, làm những thứ như tối ưu hóa công cụ tìm kiếm, rồi sau 3 tháng bán với giá gấp 10 lần giá mua. Lãi khoảng 7.000 USD cho 3 tháng làm việc thì không tệ, và nhiều khả năng đó còn không phải việc toàn thời gian
    • Tôi từng có trải nghiệm tương tự nhưng kết luận thì hoàn toàn khác. Tôi đã làm việc với những người cứ quăng đại rồi chắp vá như vậy, và cũng thường thấy nó thật sự dính được lên tường
      Nhưng kết luận của tôi là thế này. Thứ nhất, họ thất bại cũng thường xuyên như thành công, không thể dự đoán bên nào sẽ xảy ra, và vì sửa sau khó hơn là làm đúng ngay từ đầu, nó trông như một canh bạc có kỳ vọng âm. Thứ hai, cá nhân tôi ghét làm việc theo cách đó. Thứ ba, vì vậy tôi không muốn dành thời gian cho những việc mà cách đó có vẻ có thể phù hợp. Trải nghiệm này khiến tôi tìm kiếm các dự án sâu hơn và lớn hơn thay vì một chuỗi những việc nhỏ lẻ. Đổi lại, giờ tôi thoải mái hơn nhiều khi chấp nhận rằng người khác có thể có sở thích khác tôi. Tôi nghĩ nhiều hơn về cách phù hợp với mình, hơn là cách đúng để làm phần mềm
    • Hiện tôi đang làm đúng như vậy. Tôi đang tạo một ứng dụng “vô dụng” thú vị bằng công nghệ mình chưa rành, và viết thứ code rác rưởi ngu ngốc nhất, không thể bảo trì nhất
      Nhưng nó chạy được. Khổ thật, nhưng hiệu quả, và tôi học được rất nhiều trong quá trình đó. Tôi biết cách dọn dẹp, trau chuốt, làm cho nó có thể bảo trì và mở rộng về sau, nên tôi sẽ làm sau khi đã có thứ gì đó thật sự chạy được. Đặc biệt khi thử thứ mới, cách tiếp cận này trước đây cũng khá hiệu quả với tôi, nên tôi hoàn toàn ủng hộ
  • Apple từng từ chối ứng dụng của tôi với lý do nó vô dụng. Đội duyệt ứng dụng còn gọi điện trực tiếp để nói rằng ứng dụng này vô dụng và sẽ không được chấp thuận lên Mac App Store
    Khoảng 12 năm sau, ứng dụng nhỏ bé vô dụng đó, KeyboardCleanTool, đã được hàng nghìn người sử dụng. Đây là một ứng dụng miễn phí rất nhỏ, chặn toàn bộ đầu vào từ bàn phím và Touch Bar, nhưng mọi người đã dùng nó theo những cách không ai ngờ tới. Chẳng hạn để trẻ nhỏ thoải mái gõ bàn phím, hoặc để mèo ngủ trên laptop. Cái gì hữu ích thật sự rất chủ quan

    • Tôi từng biết ứng dụng đó. Lúc đó tôi cần vệ sinh bàn phím, tìm cách vệ sinh bàn phím MacBook thì ứng dụng ấy cứ hiện ra mãi. Ban đầu tôi cười cho qua kiểu “một ứng dụng thì vệ sinh bàn phím kiểu gì, giả vờ rung để làm sạch à?”
      Sau khoảng mười lần tìm kiếm nữa, tôi mới hiểu ra khi đọc một bài viết về cách tốt để vệ sinh bàn phím, trong đó khuyên dùng ứng dụng này vì nó có thể khóa bàn phím. Cuối cùng tôi đã tải về, và với một ứng dụng “vô dụng” thì nó khá hữu ích
    • Tôi biết ứng dụng đó. Trông khá tuyệt
      Hồi nhỏ, mẹ tôi từng vô tình bật chiếc Mac IIsi của chúng tôi trong lúc dọn dẹp, và tôi đã vin vào đó để thuyết phục rằng chúng tôi cần trình bảo vệ màn hình After Dark. Chẳng mấy chốc trên màn hình đã xuất hiện những chiếc máy nướng bánh bay lượn. Thật hoài niệm
    • Tôi đã dùng KeyboardCleanTool suốt nhiều năm, và nó truyền cảm hứng để tôi thêm một tính năng tương tự tên là Cleaning Mode vào ứng dụng Lunar: https://lunar.fyi/shortcuts#cleaning-mode
      Khi vệ sinh, màn hình MacBook và màn hình rời cần phải đen hoàn toàn để thấy bụi có thể gây xước, và trackpad cũng phải bị vô hiệu hóa. Tổ hợp phím để tắt chế độ vệ sinh cần khó bấm nhầm nhưng dễ nhớ, nên tôi chọn cách nhấn liên tiếp phím Command ít nhất 8 lần. Cách Apple duyệt ứng dụng lúc nào cũng gây bực bội. Tôi không hiểu vì sao họ lại cố quyết định thay người dùng cái gì là hữu ích. Chưa kể các ứng dụng lừa đảo đã qua duyệt vẫn sống trên App Store hàng tháng trời
    • Tôi muốn lưu lại bình luận này mỗi khi có ai đó bênh vực khu vườn có tường bao của Apple
  • Tôi thích dùng phần mềm giàu tính biểu đạt và thú vị. Để học hỏi và khám phá, và đó là điều đã kéo tôi vào lập trình rồi giữ tôi ở lại
    Đáng tiếc là nhu cầu mưu sinh chen vào. Dưới mối đe dọa của cái đói, ta phải có năng suất. Tôi quan tâm đến những người cùng mình tạo ra sản phẩm, và cảm thấy tội lỗi nếu không sản xuất được gì. Điều đó hút cạn cả động lực trong thời gian cá nhân. Thật đáng kinh ngạc khi có nhiều người có được sự ổn định và tự do để thể hiện bản thân. Tôi vừa ghen tị vừa vui cho những người có thể đến Recurse Center, những người có vô số bài blog chứa đầy dự án cá nhân và các câu chuyện phiêu lưu. Hầu hết có lẽ đã làm việc chăm chỉ để đạt tới vị trí có thể tạo ra cuộc sống như vậy. Tôi cũng muốn làm thế. Nhưng để làm được như vậy, có vẻ phải đốt thêm nhiều đời mình vào năng suất. Nếu hy sinh đủ nhiều năm tháng, may mắn có thể cho phép mình quyền được tận hưởng cuộc sống. Buồn cười thật. Đến lúc đó có lẽ tôi sẽ tận hưởng phần mềm vô dụng nhiều hơn

    • Như nhiều thứ trong đời, nếu cứ trì hoãn “đến khi đủ khả năng”, rất có thể bạn sẽ chẳng bao giờ có được nó
  • Trước đây tôi từng cảm thấy việc tạo ra phần mềm hữu ích là dấu hiệu của một lập trình viên phần mềm giỏi, và không dành thời gian cho những việc không rõ ràng là hữu ích theo cách dễ giải thích
    Đó là một cách rất hay để biến phần mềm thành việc vặt. Giờ thì tôi đã thoải mái hơn với việc tạo ra những thứ vô dụng, và nó rất vui. Tôi cũng làm lại những ý tưởng đã có theo cách mới, không quan tâm ai đã làm trước đó. Nếu chỉ để vui thì làm cùng một thứ cũng được, như cover bài hát của người khác. Học hỏi, tận hưởng, và bản thân việc đó đã có giá trị. Đôi khi cũng tìm ra cách cải tiến. Tôi học được điều này khi bắt đầu viết firmware. Áp lực phải luôn hữu ích là quá lớn, và tôi đã phải hạ cái tôi xuống rồi tránh sang một bên. Tôi nhận ra viết những đoạn mã lỏng lẻo làm những việc ngớ ngẩn cực kỳ thú vị, và nó trở thành một cách tuyệt vời để học và trải nghiệm ý tưởng trong môi trường ít áp lực. Hơn nữa, những thứ vô dụng đôi khi lại trở nên hữu ích đến bất ngờ. Tất cả những thứ vô dụng tôi làm trong vài năm qua đều dẫn tới những đoạn code, hiểu biết hoặc kiến thức hữu ích ngoài dự kiến

  • Từ lâu trước đây tôi từng điều hành một nhóm tên là Houston Recreational Computer Programming Group. Đó gần như hoàn toàn là một nhóm để trình diễn các dự án phần mềm vô dụng nhưng vui, và rất thú vị
    Giờ tôi đã chuyển đi, cũng không biết thành phố hiện tại mình sống có đủ lớn để lập một nhóm như vậy không, hay tôi có còn năng lượng để điều hành lại không. Điều tôi thích về mặt cá nhân là mỗi tháng một lần tôi phải làm một dự án nhỏ để trình diễn, phòng khi không ai mang gì đến. Trong khoảng 2 năm chuyện đó chỉ xảy ra vài lần, nhưng một trong số đó[1] đã ra khá hay và tôi tự hào về nó. Nó cũng không hoàn toàn vô dụng. [1] https://github.com/smcameron/gaseous-giganticus

    • Nhờ góp phần tạo nên văn hóa của TX/RX labs, nơi đó sau này đã phát triển thật sự tốt
  • Tôi vừa hoàn thành một phần mềm vô dụng chỉ vài phút trước, nên bài này rất đúng lúc
    CFR Brackets: https://susam.net/cfr.html
    Demo: https://susam.net/cfr.html#3
    Source: https://github.com/susam/cfr
    Đây là một ngôn ngữ vẽ rất nhỏ, chỉ hỗ trợ 5 lệnh: C(đổi màu), F(di chuyển về phía trước), R(xoay), [(bắt đầu khối), ](lặp lại khối). Các lệnh lấy cảm hứng phần nào từ ngôn ngữ lập trình Logo, còn tính tối giản lấy cảm hứng từ P′′. Tuy nhiên, khác với cả hai, nó không Turing-complete. Tôi không nhắm tới công dụng thực tế nào, chỉ làm cho vui. Tôi định chơi tiếp bằng cách thử vẽ các hình thú vị trong khi giữ mã đầu vào nhỏ nhất có thể. “Tôi nghĩ việc giữ niềm vui của tính toán trong khoa học máy tính là cực kỳ quan trọng.” — Alan J. Perlis