1 điểm bởi GN⁺ 2024-12-25 | 1 bình luận | Chia sẻ qua WhatsApp
  • Sau C++11, ngôn ngữ và hệ sinh thái C++ đã thay đổi mạnh mẽ, trở thành một ngôn ngữ khơi lại niềm vui lập trình trong quá trình tự tay xây dựng và thử nghiệm
  • Có thời C++ được nhiều lập trình viên nhớ đến như một ngôn ngữ gây mệt mỏi vì lạm dụng template metaprogramming cùng văn hóa xoay quanh chuẩn và pattern
  • Những thay đổi như auto, nullptr, range-for, lambda, <chrono>, smart pointer và <thread> đã làm thay đổi lớn phong cách viết code của C++
  • C++ hiện đại có rất nhiều lựa chọn, từ filesystem, quản lý package, GUI/TUI, đồ họa, toán học, AI cho đến truy cập API hệ điều hành, nên dễ tự làm thứ mình muốn
  • Các nhược điểm như lỗi compiler, công cụ build, tuân thủ chuẩn, độ phức tạp lịch sử và RAII vẫn còn, nhưng khả năng sáng tạo vượt lên trên những bất tiện đó

Vì sao C++ lại trở nên thú vị trở lại

  • Khi làm một game roguelike nhỏ, tác giả đã dùng thuật toán Dijkstra để sinh bản đồ và triển khai các đường hầm nối các phòng; trong quá trình đó, C++ không cản trở việc thử nghiệm quá nhiều
  • Cũng có thể thử nghiệm vẽ trực tiếp giao diện người dùng FTXUI lên cửa sổ render của SFML, và trong quá trình này học được cách C++ xử lý Unicode
  • Những việc này không dễ, nhưng thực sự làm được; cảm giác “ý tưởng này thật sự chạy được” chính là điều tạo nên sự thú vị của C++
  • Lý do bắt đầu lập trình không phải là để giúp tỷ phú kiếm thêm tiền, vật lộn với rendering engine, hay làm hài lòng tầng trên của các dự án open source, mà là niềm vui biến ý tưởng thành hiện thực

Sự mệt mỏi trong thời kỳ template metaprogramming

  • Từ cuối thập niên 1990 đến đầu thập niên 2000, C++ có xu hướng mạnh mẽ muốn áp dụng template metaprogramming vào mọi thứ, và giai đoạn này được xem là bước ngoặt khiến C++ mất vui
  • Có những tranh luận kiểu cộng hai số bằng template sẽ nhanh hơn cộng trực tiếp, nhưng có ví dụ cho thấy output assembly thực tế là như nhau
  • Nhận thức rằng Ủy ban tiêu chuẩn C++ không tích cực mang lại khả năng sử dụng tốt cho lập trình viên cũng làm gia tăng trải nghiệm tiêu cực
  • C++ thời đó được nhớ đến như một ngôn ngữ có rất nhiều dấu ngoặc nhọn <> và cú pháp phức tạp, nhưng thu lại không được bao nhiêu
  • Java ban đầu cũng trông hấp dẫn nhờ garbage collector và sự thân thiện với developer, nhưng về sau cũng tạo ra cảm giác mệt mỏi tương tự vì boilerplate và lạm dụng design pattern

C++11 đã thay đổi cảm giác về ngôn ngữ như thế nào

  • Các tính năng được thêm vào C++11 được đánh giá là thay đổi lớn ấn tượng về C++
  • Các tính năng chính gồm:
    • auto: từ khóa suy luận kiểu tự động giúp giảm gánh nặng phải viết lặp lại cùng một tên kiểu
    • nullptr: biểu diễn con trỏ null khắc phục vấn đề của NULL trong C
    • range-for: vòng lặp giúp duyệt container đơn giản hơn khi dùng cùng auto
    • lambda expressions: lambda có thể thay đổi lớn thiết kế API và khả năng sử dụng
    • <chrono>: thư viện thời gian type-safe, cho phép biểu diễn như 100ms
    • <regex>: chức năng regular expression được đưa vào thư viện chuẩn
    • unique_ptr, shared_ptr: smart pointer xử lý ownership và reference counting
    • <thread>: tính năng đưa multithreading vào hệ sinh thái ngôn ngữ cơ bản
  • C++11 không vứt bỏ cách làm cũ nhưng đã thay đổi triết lý và phong cách của ngôn ngữ, và ở điểm này được tiếp nhận giống như ES6 của JavaScript

Các lựa chọn trong hệ sinh thái C++ hiện đại

  • C++ mới đã có khá nhiều tính năng mà người ta kỳ vọng ở các ngôn ngữ khác
  • Các công cụ và thư viện được nêu làm ví dụ gồm:
  • Chất lượng hệ sinh thái khác nhau tùy hạng mục, nhưng nhìn chung được đánh giá cao hơn những gì từng trải nghiệm với JavaScript và Python
  • Đặc biệt, FTXUI và STL được nêu như những ví dụ về thiết kế tốt và dễ dùng

Khả năng triển khai rộng tạo nên “sự thú vị”

  • C++ thú vị không chỉ vì có thêm các tính năng hiện đại, mà còn vì khả năng triển khai gần như bất cứ thứ gì
  • Có thể tạo desktop app bằng fenster, SFML, Qt, hoặc tự xử lý trực tiếp OS API
  • Với âm thanh, lựa chọn trải rộng từ những phương án nhanh như SFML đến công cụ thương mại như Wwise
  • Đồ họa 3D có nhiều lựa chọn như OpenGL, Vulkan, Direct3D, Ogre3D
  • Trong mảng toán học có các thư viện như BLAS, Eigen, GMTL
  • Ngay cả khi không có thư viện cần thiết, vẫn có thể tự làm bằng cách truy cập trực tiếp C hoặc C++ ABI và API hệ điều hành; chính quá trình tự chế tạo này cũng là một phần của niềm vui

Tự do sáng tạo của một ngôn ngữ đứng ngoài xu hướng

  • C++ có chất lượng ngôn ngữ và hệ sinh thái cao, nhưng hiện không phải ngôn ngữ đang thịnh hành, nên được đánh giá là ít thu hút kiểu quan tâm có thể làm hỏng ngôn ngữ hơn
  • Cộng đồng C++ được mô tả là có bầu không khí không can thiệp quá nhiều dù bạn làm gì
    • Có thể tự do thử các dự án như thư viện ma trận, thư viện GUI, game engine hay những game kỳ quặc
  • Công việc sáng tạo cần cả giai đoạn đưa ý tưởng ra ngoài trước, lẫn giai đoạn sau đó phê bình lạnh lùng và nâng cao chất lượng
  • Ở các ngôn ngữ khác, tổ chức, leadership và áp lực cộng đồng được đánh giá là cản trở các thử nghiệm ở giai đoạn giữa của sáng tạo
  • Khả năng rộng lớn của C++ và văn hóa tương đối ít áp đặt cảm giác xấu hổ có thể tạo ra trải nghiệm sáng tạo

Điểm mạnh của cppreference.com

  • cppreference.com được đánh giá thuộc hàng tốt nhất trong số các tài liệu ngôn ngữ lập trình từng dùng
  • Các ưu điểm gồm:
    • Mọi keyword và thư viện đều được sắp xếp thành tài liệu tham chiếu
    • Hầu hết mục đều có ví dụ thực sự chạy được
    • Hiển thị phiên bản chuẩn C++ mà từng tính năng được đưa vào
    • Liên kết đến tài liệu chuẩn và tài liệu tham khảo liên quan
    • Có ô tìm kiếm dựa trên DuckDuckGo, nên dễ tìm ngay cả khi gõ sai chính tả hoặc không biết thuật ngữ chính xác
    • Những khái niệm quan trọng như Copy elision cũng được giải thích kèm ví dụ
  • Điểm thiếu là không có hướng dẫn cài compiler trên nhiều nền tảng khác nhau
  • Vì số lượng compiler và nền tảng C++ không quá nhiều, vẫn có dư địa để thêm hướng dẫn bắt đầu

Những vấn đề vẫn còn của C++

  • Điều này không có nghĩa C++ là ngôn ngữ hoàn hảo; giống các ngôn ngữ khác, nó vẫn có nhiều điểm bất tiện
  • Trên Windows, việc cấu hình compiler và công cụ phát triển theo đường dẫn cài đặt không phải của Microsoft là khó, nên tác giả đã tự viết script cài đặt PowerShell cho việc này
  • Các bất tiện chính hiện cảm nhận gồm:
    • Hơn 95% thông báo lỗi compiler bị đánh giá thuộc hàng tệ nhất ngành
    • Công cụ build khó dùng, và Meson cũng từng gặp vấn đề bỏ qua chỉ dẫn về package đã cài rồi dùng thư viện hệ thống bị hỏng
    • Thiếu động lực để các nhà sản xuất compiler tuân theo chuẩn
    • C++ cực kỳ phức tạp vì lịch sử của nó; các phong cách cùng tồn tại gồm kiểu heap allocation và raw pointer cũ, kiểu template metaprogramming, kiểu tập trung vào stack sau C++11, và kiểu mới hơn xoay quanh struct
    • RAII thường gây cản trở trong các tình huống thiết lập thực tế, và được cho là cần một điểm trung gian giữa constructor khởi tạo kiểu các ngôn ngữ khác và RAII hiện tại
  • Dù có những nhược điểm này, sự bất tiện của C++ chưa đến mức phá hỏng niềm vui; C++ đã khác với ấn tượng cũ về một ngôn ngữ xoay quanh dấu ngoặc nhọn và con trỏ
  • Code layout GUI của FTXUI là một ví dụ cho thấy cú pháp hiện đại đến mức nếu không biết đó là C++, nó có thể trông như một ngôn ngữ khác

1 bình luận

 
GN⁺ 2024-12-25
Ý kiến trên Hacker News
  • Tôi gần như là một người ghét C++, nhưng đó là vì tôi ghét phải xử lý C++ trong mã nghiệp vụ cần độ tin cậy, cùng với những đồng nghiệp hoàn toàn không thể tin tưởng được
    Trong các dự án cá nhân, đây thuộc nhóm môi trường lập trình khiến tôi hài lòng nhất từ trước đến nay, và việc có thể kiểm soát quá trình thực thi cực kỳ chi tiết thật sự rất phấn khích
    Tôi đã rời C++ khoảng 10 năm trước và không có ý định quay lại, nhưng với các dự án hiện nay của tôi, độ tin cậy dài hạn là quan trọng nhất nên Rust + CI/CD là rất phù hợp
    Dù vậy, tôi vẫn nhớ cảm giác phấn khích khi thiết kế và triển khai để chương trình chạy đúng như cách mình định, và điều đó là nhờ chuyên môn cùng sự thấu hiểu của bản thân
    Nếu hỏi tôi có muốn người làm cùng mình hành động theo động lực đó không thì tuyệt đối là không, nhưng với cá nhân tôi, đó là một niềm vui khó quên
    Hệ thống build và quản lý gói là ác mộng, preprocessor giống như một trò đùa ác ý, cú pháp thì kinh khủng, và ở runtime có quá nhiều thứ cặn bã đòi hỏi nhiều năm kinh nghiệm mới không tự bắn súng máy vào chân mình
    Nhưng theo một nghĩa nào đó, chính những đau đớn này lại làm niềm vui lớn hơn khi cuối cùng bạn xuất xưởng được một file thực thi được bọc trong sự thông minh và nước mắt máu

    • Đây là một trong những mô tả về C++ mà tôi thấy đồng cảm nhất
      Tôi đã dùng C/C++ trong công việc vài năm và không muốn quay lại nữa
      Tôi đã mất quá nhiều thời gian để debug mã của người khác, gặp các vấn đề tích hợp mơ hồ, và xoay xở với mớ spaghetti của hệ thống build
    • Công việc cũng phải vui như các dự án cá nhân
      Tôi nghĩ ngành công nghệ đã đánh mất suy nghĩ này trong 10 năm qua, và tôi cho rằng nguyên nhân là các công ty công nghệ lớn nhốt những người giỏi nhất vào những nhà tù người lớn có đồ ăn ngon và ghế êm
      Startup cũng đã bớt vui hơn, và khi giới VC thúc đẩy một khung tư duy hẹp, đã có quá nhiều startup sao chép cùng làm một thứ và quá nhiều trào lưu
      Lý do tôi dùng C++ cho mọi dự án mới là vì tôi có niềm tin rằng khi cần tự làm thứ gì đó, tôi có thể làm được
      Framework thường không hoạt động theo cách tôi muốn, đặc biệt khi xử lý phần cốt lõi của dự án, nên tôi không muốn tiếp tục dùng chúng
      Nếu có thể tự làm thì tự làm, còn không thì dùng framework
      Nếu bạn có thể tự làm, C++ là một công cụ tuyệt vời có thể làm bất cứ thứ gì và không cản đường bạn ở những khía cạnh quan trọng
      Những ngôn ngữ như Rust có thể phàn nàn rằng tôi đang làm việc nguy hiểm, nhưng trong C++ tôi có thể trực tiếp biểu đạt mô hình trong đầu mình
      Đôi khi tôi nghĩ bằng con trỏ, và con trỏ thật sự là một công cụ tốt
      Hãy lấy lại niềm vui, không chỉ trong đời sống cá nhân mà cả trong công việc
  • Bài viết này có vẻ hơi rối
    Nó nói đến nhiều điểm, nhưng khó rút ra được vì sao những điểm đó dẫn đến kết luận rằng C++ vui hơn hay kém vui hơn
    Việc vừa nói C++ hiện đại có chất lượng cực kỳ cao, đồng thời lại nói đến hàng loạt vấn đề legacy và công cụ tệ hại, cũng khiến tôi bối rối
    Nói unique_ptr rất tuyệt nhưng lại thật sự ghét RAII, rồi lập luận kiểu metaprogramming ngày trước có ở khắp nơi nhưng giờ thì không còn nữa, cũng khá lạ
    Nhìn vào concepts thì không phải vậy, còn những câu như C++ có thư viện đồ họa tốt nhất hay cài Python khó hơn C++ cũng trông giống nỗi ám ảnh riêng của tác giả hơn là liên quan đến luận điểm
    Rốt cuộc có vẻ tác giả thấy C++ vui vì một tổ hợp các yếu tố cá nhân, và bản thân điều đó thì ổn
    Tôi cũng từng lập trình vui nhất với C++ nhờ hiệu năng và tính kỹ thuật của nó, nhưng trong phát triển phần mềm thực tế, C++ không tốt vì rất nhiều lý do mà chúng ta đều biết
    C++ là một ngôn ngữ đầy mâu thuẫn sâu sắc, bị tổn thương bởi nhiều thập kỷ legacy và chính trị, và sai lầm lớn nhất trong các cuộc thảo luận về C++ là phớt lờ thực tế của C++
    Thái độ của tôi với C++ ngày nay gần với sự mệt mỏi hơn, và tôi không còn muốn nhảy qua những chướng ngại mà C++ đã ném ra trong nhiều năm qua nữa
    Không cần tiếp tục đánh một con ngựa đã chết quá lâu; cứ để C++ là C++ thôi

    • Tôi nghĩ câu đó tóm tắt rất hay ý chính của bài
      Theo tôi, bài viết không hẳn là rối, mà giống như tác giả đang thấy vui và cố gắng chia sẻ niềm vui đó nhiều nhất có thể
      Nó không phải một bài xã luận đúng nghĩa hay một bài cố gắng thuyết phục mạnh mẽ, mà gần với “nếu không cần thuyết phục mà bạn vẫn đồng cảm, có thể bạn cũng sẽ thấy vui” hơn
      Nếu đứng từ góc nhìn đã mệt mỏi vì bị thực tế trong công việc thương mại vùi dập, việc cảm thấy nó vô lý cũng hoàn toàn dễ hiểu
      Dạo này tôi cũng đang rất vui dù lại dùng đúng JavaScript, và nếu tôi viết một bài tương tự, tôi nghĩ với những người đã kiệt sức vì JavaScript thương mại trong 10 năm qua thì nó cũng sẽ bị đọc như một bài tệ không kém
      Dù vậy, tôi mừng vì tác giả đang thấy vui và đã quyết định chia sẻ niềm vui đó
  • Tôi đã mất 3 ngày để liên kết tĩnh một phụ thuộc bên thứ ba trong dự án C++ sao cho chạy được trên Linux/Windows/macOS
    Gói đó không có trên conan/vcpkg, chỉ có một repo GitHub với tổ hợp Makefile/cmake kỳ quặc
    Tôi còn xa mới là chuyên gia cmake/cpp, nhưng trong hầu hết các ngôn ngữ hiện đại, những việc kiểu pip install, cargo add, npm install, go get không thành vấn đề
    Dù có đọc từ đầu đến cuối một cuốn sách về chi tiết ngữ nghĩa của C++, làm việc trên dự án thực tế vẫn rất đau khổ

    • Phụ thuộc và chuỗi công cụ build của JavaScript cũng khó hiểu chẳng kém những Makefile bẩn nhất
      Thật ngạc nhiên là cuối cùng nó đã tiến tới một thứ giống như autotools phiên bản JavaScript
    • Tôi tò mò cụ thể phần nào khó
      Build tĩnh mã của người khác hoặc chỉnh để build được trên nền tảng khác đôi khi khá rắc rối, nhưng bản thân việc link thường chỉ là chỉ định thư mục include, đường dẫn thư viện và thư viện
    • Nhìn ngược lại, nếu muốn dùng bên thứ ba này trong một ngôn ngữ “hiện đại” khác thì liệu có gì tốt hơn không
      Nếu chưa có ai đóng gói cho vcpkg/conan, khả năng cao là nó cũng không có trên pip/cargo/npm
      Nếu đã vất vả trong C++ thì trong ngôn ngữ khác có thể còn vất vả hơn nhiều
      Tuy nhiên, một phần lịch sử của C++, đặc biệt là câu chuyện build, ở tình trạng rất tệ cũng được thể hiện rõ ở đây
      Chỉ cần nó có trong vcpkg thì độ khó cài đặt sẽ giống hệt các hệ sinh thái khác
  • Tôi thỉnh thoảng thử làm việc bằng C++ thay vì C, và lần nào cũng theo một mô-típ tương tự
    Biết được một kỹ thuật C++ mới, viết code vì nghĩ mọi thứ sẽ tốt hơn, gặp lỗi compiler, rồi dành phần còn lại của ngày để học xem vì sao mình không thể làm điều mình muốn
    Thường thì tôi bị kẹt ở C++14, và một số vấn đề đã được sửa ở các phiên bản sau, nhưng vẫn là như vậy
    Tôi rất muốn thích C++, vì trên lý thuyết nó đem lại một thứ C mạnh hơn giúp tăng năng suất, nhưng cuối cùng gánh nặng nhận thức quá lớn nên thường tôi chỉ dùng “C có class” rồi cho qua

    • Có một giai đoạn mà việc học thấy rất vui, và có vẻ tác giả bài gốc vẫn đang ở giai đoạn đó
      Năm 2003 tôi viết rất nhiều C++ thời gian thực và ghét nó, nhưng năm ngoái khi phần lớn code của tôi là C++ thì cuối cùng tôi đã bắt đầu thích nó
      lambda và auto là bước ngoặt khiến tôi không còn ghét C++ nữa
      Tôi cũng dùng template một chút, nhưng chủ yếu là để tránh phải viết cả đống nhánh cho từng biến thể của cùng một hàm
      Nhờ lambda, tôi có thể viết code theo cách được các thầy thuộc họ Lisp, mang màu sắc SICP, dạy từ đầu
      Dùng unique_ptr thì việc cấp phát cũng không còn đáng ghét
    • Tôi đã thấy nhiều đoạn code tệ do người vừa học một tính năng nào đó và muốn dùng nó cho bằng được
      Đừng làm vậy; trước hết hãy nghĩ xem code sẽ được dùng như thế nào, rồi nếu tính năng nào giải quyết được vấn đề thì hãy dùng
      Phải là vấn đề → giải pháp, không phải ngược lại
      Ví dụ template của C++ nhìn chung khá kinh khủng, nhưng duck typing ở thời điểm biên dịch hay tự động thêm padding dựa trên sizeof() đôi khi lại rất hữu ích
    • Trải nghiệm C++ của tôi cũng đúng y như vậy
      Ban đầu tôi là lập trình viên C# đang học C vì một dự án embedded, và diễn biến giống hệt
      C++ có nhiều tính năng hay ho trông rất mạnh nếu khớp chính xác với ứng dụng
      Nhưng mỗi lần thử một tính năng mới, việc tôi muốn làm luôn là trường hợp biên không hoạt động trong tình huống đó; sau vài giờ hoặc vài ngày thử, tôi bỏ cuộc và viết bằng C cho xong
    • C++ cũng như hầu hết công nghệ: nếu bỏ công học cho đúng thì nó hoạt động tốt hơn
      Tất nhiên cũng có những ngôn ngữ nằm ngoài xu hướng này như Python hay Ruby
    • ChatGPT hay Copilot giúp khá nhiều ở những phần đó
      Thường tôi copy phần text lỗi rồi nhờ chúng giải mã
  • C++ thật sự thú vị, và tôi nghĩ những phàn nàn của mọi người phụ thuộc rất nhiều vào ngữ cảnh
    Nhiều lập trình viên C++ ghét ngôn ngữ này, nhưng thực ra đôi khi hướng ghét đó bị đặt sai chỗ
    Trên thực tế, nhiều khi họ đang phải xử lý sản phẩm legacy do những người không giỏi dùng phần mềm cho lắm tạo ra
    Tôi cũng từng gặp chuyện tương tự với Rust: được đưa vào một dự án Rust có sẵn của công ty, và trong codebase cũ có rất nhiều quy ước xung đột nhau
    Có các kiểu xử lý lỗi không kết hợp tốt với nhau, abstraction class tệ, những block unsafe không cần thiết, và đó là một trong những dự án khổ sở nhất tôi từng làm
    Rất dễ đổ lỗi cho Rust, nhưng thật ra đó chỉ là phát triển phần mềm tệ
    Đúng là C++ có khuyết điểm, nhưng phần lớn nỗi đau mọi người gặp phải đến từ việc xử lý code tệ — thứ dù viết bằng ngôn ngữ nào cũng sẽ là một mớ hỗn độn

    • Gần như mọi ngôn ngữ khác ngoài C đều không khiến mỗi lần viết v[x]=y trở thành lời mời gọi làm hỏng bộ nhớ tùy ý
      Với std::optional của C++, nếu v đang rỗng mà gọi *v thì đó là hành vi không xác định
      Mục đích cốt lõi của optional là chứa một giá trị có thể vắng mặt, nên thật khó hiểu vì sao lại đưa hành vi không xác định vào thao tác phổ biến nhất khi optional đang rỗng
      Từ góc nhìn của một người đã dùng C++ nhiều, vấn đề là mọi lập trình viên trong dự án phải hoàn hảo 100% trong 100% thời gian
      Có thể chạy memory checker và STL debug mode, nhưng nếu không chạy chúng cả ở bản release thì bạn phải kỳ vọng test suite chạm tới mọi hành vi kỳ quặc mà người dùng ngớ ngẩn hoặc ác ý có thể làm
      Trong thời đại phần mềm đã trở nên quan trọng đến vậy, khi Rust có vẻ tiến gần hiệu năng của C++, tôi tự hỏi liệu có đáng dùng một ngôn ngữ mà rất nhiều chức năng mặc định cực khó dùng an toàn hay không
      Thậm chí mọi chuyện còn tiếp tục tệ hơn: gọi một std::function rỗng từng ném assert, nhưng std::copyable_function mới lại biến việc này thành hành vi không xác định
    • Tôi khó đồng tình với nhận định này
      Type system thì gây khó chịu, mà cũng không đem lại memory safety đúng nghĩa
      Most vexing parse thật sự rất phiền, và những điểm kỳ quặc kế thừa từ C như pointer decay vẫn còn nguyên
      Trên đó lại chồng thêm các giải pháp mới như std::array mà vẫn không thể loại bỏ cách cũ
      Việc tiếp tục phụ thuộc vào preprocessor để mô phỏng một hệ thống import module thực sự cũng là vấn đề, và vì thế kéo theo các đường vòng như tổ chức code class hay idiom pimpl
      Về bản chất, khuyết điểm quá lớn và quá nhiều đến mức tôi không còn tìm thấy vẻ đẹp bên trong nó nữa
    • Nói đúng, nhưng ngôn ngữ càng phức tạp thì càng dễ tạo ra một mớ hỗn độn không thể hiểu nổi
      Ngược lại, một dự án bằng ngôn ngữ blub đơn giản thường khá dễ giải mã, bất kể tình trạng codebase ra sao
    • Dù đã cũ, C++ FQA khá buồn cười này cũng đáng tham khảo: https://yosefk.com/c++fqa/
  • Thật vui khi có ai đó tìm thấy niềm vui trong C++, nhưng cá nhân tôi thì sau khi chịu đựng hơn 20 năm, giờ tôi nghĩ đã đến lúc chấm dứt với C++
    Nó đơn giản là một mớ hỗn độn
    Nếu thật sự cần kiểm soát cấp thấp thì dù có khuyết điểm tôi vẫn dùng C, còn không thì Rust, Python, v.v. khiến tôi hạnh phúc hơn nhiều

    • Đồng ý
      Dù vậy C++ sẽ vẫn còn tồn tại
      Có quá nhiều mã được viết bằng ngôn ngữ đó, và chắc chắn nếu nắm vững thì đó là một kỹ năng tốt, cũng có những công việc trả rất nhiều tiền
      Với tôi, ngôn ngữ này cản trở quá nhiều và cảm giác quá phức tạp
      Tôi biết luận điểm rằng “C++ hiện đại” rất tuyệt, không cần học các phiên bản cũ, và mỗi phiên bản mới đều đơn giản hơn
      Vấn đề là codebase bạn thực sự phải phụ trách không phải là C++ hiện đại
      Nó dùng mọi tính năng từng xuất hiện cho đến nay, khó nhằn và đầy cạm bẫy
      Người đã làm C++ nhiều năm chỉ trong dự án của riêng mình có thể phát triển được mức chuyên môn nhất định và miễn nhiễm với độ phức tạp, nhưng đó thật sự không phải là một ngôn ngữ tốt
    • Một trong những yếu tố khiến C++ dần dễ chịu đựng hơn theo thời gian là việc phần lớn có thể được thay thế một cách tự nhiên bằng các triển khai hoạt động theo cách mình nghĩ và có hành vi được định nghĩa đủ rõ
      Chẳng hạn thay các kiểu dữ liệu cốt lõi, thư viện chuẩn, v.v.
      Đặc biệt từ C++20 trở đi, nền tảng thay thế này cho cảm giác khá native và giàu khả năng biểu đạt
      Khá nhiều dự án C++ mới mà tôi thấy chọn mạnh theo hướng này
      Việc có thể dễ dàng tạo một ngôn ngữ đặc thù miền ở mức hệ thống cho ứng dụng là một điểm mạnh của C++
    • Trong một dự án phái sinh từ Ultima mà tôi làm bằng C++/SDL2, tôi chỉ dùng vài tính năng của C++
      Tiếc là tôi không hoàn thành nó, nhưng những gì nhớ được là class, std::function, std::unordered_map, std::string, std::unique_ptr
      Tôi khó tưởng tượng nổi việc đọc mã của người khác nếu không theo phong cách tương tự
      Vì không viết các chương trình quy mô lớn một cách chuyên nghiệp, phần khó nhất là vượt qua các mẫu lập trình như Visitor pattern
      Tôi ước gì C++ đã dừng lại ở C++11
      Ủy ban giờ có vẻ muốn đưa mọi thứ vào ngôn ngữ, và C++ trông như một siêu ngôn ngữ khổng lồ hỗ trợ mọi phong cách lập trình ngách
    • C++ hoàn toàn là một mớ hỗn độn
      Nhưng là một mớ hỗn độn thú vị, và tôi thích viết bằng C++
      Đôi khi điều đó quan trọng
      Quan hệ của tôi với Rust thì lạnh nhạt hơn nhiều
      Tôi tôn trọng Rust, và đặc biệt trong những bối cảnh khó biện minh cho việc dùng C++ như công việc, nếu thấy Rust là đúng thì tôi dùng nó, và tôi nghĩ những gì Rust làm là quan trọng
      Nhưng dù đến nay đã làm khá nhiều dự án Rust, tôi vẫn thấy viết Rust nhàm chán
      Về các mặt cốt lõi thì nó tốt hơn, nhưng ít nhất với tôi thì kém vui hơn
    • Rust chẳng phải cũng là ngôn ngữ cố cung cấp mức kiểm soát và tính cấp thấp như C sao?
      Nếu mở niêm phong unsafe, bạn có thể ép kiểu tường minh số nguyên thành con trỏ, và chẳng hạn cũng có thể điều khiển phần cứng bằng I/O ánh xạ bộ nhớ, đúng không?
  • Bài này là một tràng dài lê thê với phạm vi rộng, và chỉ riêng chữ “C++” cũng có thể kích động mọi người khiến nhiều phần bị bỏ qua
    Đôi khi tôi cũng vậy
    Nếu muốn xem phần phàn nàn thì cứ nhảy tới mục “It's Not All Puppies and Butterflies”
    Tác giả rất ấn tượng với C++11, và sau gần 20 năm cố tình phớt lờ C++, tôi cũng cảm thấy tương tự
    Việc giới thiệu các package và thư viện để nghịch là tốt, nhưng việc đưa thư viện khác vào dự án của tôi vẫn thường rất đau khổ
    Tôi nghĩ ngay đến các header một file
    FTXUI khá thú vị
    Và thật sự cppreference.com rất xuất sắc
    Tài liệu Python cũng khá tốt, nhưng tôi chưa thấy tài liệu nào tốt như cppreference.com

    • cppreference.com đúng như tên gọi, là tài liệu tham chiếu cực kỳ tuyệt vời
      Tài liệu Python thì rải rác khắp nơi, không đầy đủ ở nhiều chỗ, và cũng thiếu một phong cách biên tập nhất quán
      Nhưng xét theo framework Diataxis, nó bao quát khá tốt nhiều loại tài liệu chứ không chỉ tài liệu tham chiếu
      Những người viết tài liệu đó có cân nhắc framework này một cách rõ ràng khi tìm hướng cải thiện
      Dù vậy, đó vẫn là một công việc mã nguồn mở dựa trên tình nguyện viên, vận hành gần giống như phát triển mã
    • Sau khi học C++ ở trường phổ thông và đại học, tôi chuyển ngay sang Python/JavaScript trong công việc, và nhờ bài này mà tôi lấp được rất nhiều phần C++ mình chưa biết
      Tôi đã muốn tiến “gần hệ thống hơn” một thời gian, và việc học Rust bên cạnh cũng không dễ
      Đọc bài này khiến tôi có hy vọng rằng có lẽ học lại C++ sẽ giúp làm được điều đó
      Xin chào CMake… à không, có lẽ nên nói là Meson
  • Tôi đồng ý rằng nếu một đội ngũ tài năng biết dùng C++ hiện đại tốt và bắt đầu một dự án mới, thì C++ rất tuyệt
    Đó là một ngôn ngữ vui và mạnh mẽ, hiệu năng tốt, và dù phức tạp nhưng việc debug và tối ưu hóa tương đối trực quan
    Tôi từng có cơ hội làm việc trên một codebase khoảng 5 năm tuổi, được viết theo tiêu chuẩn sau C++11, và vì nhiều lý do mà bài viết nêu, trải nghiệm đó rất thú vị
    Ngược lại, nếu là codebase cũ đã tiến hóa suốt 20–30 năm, hoặc codebase không được những người giỏi bảo trì, thì sẽ là trải nghiệm hoàn toàn khác

    • Tôi bắt đầu đời lập trình viên với PHP, vừa làm vừa học bằng cách tạo các theme WordPress tùy chỉnh có plugin cho những kiểu dữ liệu đặc thù
      Năm 21 tuổi, công ty đề nghị trả học phí nên tôi quay lại học chương trình bằng khoa học máy tính, rồi sau đó chuyển sang ngành tin học
      Ngay ngày đầu tiên của lớp “nhập môn lập trình”, khoảnh khắc chạm vào C++ tôi đã yêu nó
      So với PHP 7 tôi dùng lúc đó, hệ thống kiểu, debug, hệ sinh thái đều tuyệt vời
      Sau khi được quản lý cho phép, tôi tạo các API dựa trên C++ cho một phần ứng dụng intranet hiện có để PHP gọi qua websocket, nhờ đó tận dụng được hệ thống kiểu và hiệu năng
      Những hệ thống đó đến nay vẫn được dùng hằng ngày trong toàn công ty, và việc bảo trì cũng không thành vấn đề
      Ngay cả khi chúng chạy trong một môi trường khá đặc thù tên là IBM Pase for i cũng vậy
      Giờ sau khi đã dùng Rust và Axum, khi xây những API như thế tôi sẽ thích hệ sinh thái Rust hơn nhiều, nhưng C++ cũng xứng đáng được ghi nhận
      Đặc biệt nếu bạn chuyển sang từ các ngôn ngữ web như JavaScript không phải TypeScript, hoặc PHP, thì đó thật sự là một ngôn ngữ tuyệt vời
    • Với điều kiện là một codebase cũ đã tiến hóa 20–30 năm hoặc không được người giỏi bảo trì, tôi không nghĩ ra ngôn ngữ nào khác mà sẽ không kinh khủng
      Thực ra trong nhiều khả năng tôi có thể nghĩ tới, chẳng hạn C, Java, Fortran, có lẽ tôi vẫn sẽ thích C++ hơn
      Ngoại lệ có thể là C#, nhưng tôi không biết nó đã đủ cũ để rơi vào điều kiện đó chưa
  • Trái với nhận định rằng C++ đã có regex tích hợp và khá tốt, khó có thể nói std::regex là tốt
    hiệu năng kém và hỗ trợ Unicode cũng thiếu, nói chung tốt hơn là nên tránh dùng

    • Linter mà công ty chúng tôi dùng cũng bắt buộc không được dùng std::regex
    • Tôi tò mò liệu có vấn đề nào trong đặc tả gây suy giảm hiệu năng hay không
  • Tôi đã học C++ và cũng từng thích nó, nhưng không đi sâu
    Tôi luôn thích C hơn, và vốn dĩ cũng có nhiều codebase thượng hạng có thể đọc để học C tốt hơn, như engine game Dune hay các tiện ích Unix
    Gần đây thử đụng tới Rust một chút thì tôi không còn thấy nhiều lý do mạnh mẽ để dùng C++ nữa
    Sự kết hợp giữa hệ thống kiểu mạnh lấy cảm hứng từ lập trình hàm và hiệu năng có vẻ rất khó đánh bại, gần như là một ngôn ngữ hoàn hảo
    Dù vậy, chắc chắn vẫn có các lý do legacy khiến phải dùng C++
    Có thể là engine game, lập trình nhúng, hoặc các dạng ràng buộc legacy khác

    • Trong công việc tôi dùng qua lại giữa C++ và Rust, và thành thật mà nói trong C++20/23 hiện đại, nhiều điểm đau đang được sửa theo cách gần như sao chép Rust
      Nếu là một codebase C++ mới thì vẫn có thể làm khá gọn gàng
      Nhưng ở thời điểm này tôi không thật sự hiểu vì sao lại tạo phần mềm mới bằng C++
      C++ có rất nhiều điểm phiền phức
      Quản lý thư viện/package không được chuẩn hóa, header là sự lặp mã, còn thư viện chuẩn thì tùy theo implementation và gần như rất khó đọc
      Chuẩn có những hành vi kỳ lạ, người ta dựa vào hành vi không xác định mà không biết, có vấn đề dùng trước khi cấp phát, và rò rỉ bộ nhớ do vấn đề ownership cùng reference count sai phát sinh một cách tinh vi
      Phải biến mọi thứ thành const thay vì mặc định, muốn bảo đảm noexcept thì phải kiểm tra exception của mọi thứ được gọi, và lỗi khi làm việc với thư viện chuẩn thì khó đọc
      Mã nặng hướng đối tượng trên thực tế là nợ kỹ thuật
      LSP của C++ không theo cách có cấu trúc như Rust, vốn kiểm tra cây cú pháp trừu tượng để tìm định nghĩa, nên việc điều hướng và nắm bắt codebase chậm hơn
      Rust hỗ trợ rõ ràng nostd như một công dân hạng nhất, nhưng trong C++ nếu muốn tắt thư viện chuẩn thì cần các flag theo từng compiler và khó xác nhận đã làm đúng hay chưa
      Vì vậy, lý do dùng C++ vì nhúng với tôi không mấy thuyết phục
      Rust cũng có engine game như bevy nhưng vẫn còn mới, và nếu muốn cũng có thể gắn Rust vào scripting của Godot
      Âm thanh cấp thấp trong Rust cũng dễ tương tự, và có thể xử lý cross-platform bằng một crate duy nhất
      Nhìn chung, tôi cho rằng cốt lõi là mã legacy và sự ngần ngại trước thay đổi
    • Legacy không chỉ là các ứng dụng viết bằng C++, mà còn khổng lồ trên nhiều chiều cạnh
      Bao gồm số lượng người dùng, tri thức và tài liệu đã xuất bản và có thể sử dụng, sách, bài giảng, blog, bài viết, video, thư viện phần mềm, cũng như mức tương thích cao với C, vốn là một ngôn ngữ khổng lồ khác
      Với những người đã ở trong lĩnh vực này hơn vài năm, đó gần như là kiến thức phổ thông của ngành phần mềm
      Tôi chưa từng dùng C++ nhiều nên cũng khó gọi là một người mới bắt đầu đúng nghĩa, nhưng trước đây tôi từng mua và đọc các sách C++ kinh điển của Bjarne Stroustrup, người tạo ra ngôn ngữ, Scott Meyers và những người khác, và hiểu được phần nào
      Tuy nhiên, với C thì tôi đã dùng nhiều năm trong production, bao gồm cả các sản phẩm thương mại thành công
      https://www.stroustrup.com/applications.html
      https://www.stroustrup.com
      https://en.m.wikipedia.org/wiki/Bjarne_Stroustrup
      https://en.m.wikipedia.org/wiki/Scott_Meyers
    • C++ có lý khi cần độ trễ thấp nhưng không quá quan tâm đến tính đúng đắn
      Vì vậy tôi nghĩ phát triển game sẽ là lĩnh vực ở lại với C++ lâu nhất
      Nếu game bị chết vì lỗi segmentation fault với 0,001% người dùng thì cũng kiểu: thế thì sao?
    • Giao dịch tần suất siêu cao cũng có khả năng