- "Lập trình hàm (FP) khó học, nhưng sẽ khiến mã của bạn tạo ra ít bất ngờ khó chịu hơn"
- Trong FP, "less is more"
- Giải quyết vấn đề Null Reference (bằng Maybe/Option)
- FP có đường cong học tập dốc
- Tương lai của FP
- Nếu muốn phát triển nhiều hơn với ít lập trình viên hơn, chúng ta phải dùng mọi công cụ có thể, và FP chính là tấm vé cho điều đó
- Những công ty không hào nhoáng như chúng ta gặp khó trong việc tuyển dụng lập trình viên. Nhưng có thể tuyển được các lập trình viên top-tier muốn làm việc với codebase FP
- Việc áp dụng FP sẽ cải thiện chất lượng và độ vững chắc, đồng thời giảm thời gian dành cho các lỗi vốn không xảy ra trong FP
- Việc các tính năng của FP ngày càng xuất hiện trong các ngôn ngữ chủ lưu cho thấy ngành công nghiệp phần mềm đang chuẩn bị cho một sự chuyển dịch mô hình
- Dù vẫn cần rất nhiều việc trước khi toàn ngành chuyển đổi hoàn toàn, nhưng vì lợi ích của cách làm này là rất rõ ràng nên không có gì phải nghi ngờ về hướng đi phía trước
13 bình luận
Có vẻ đúng là độ khó khi học khá cao. Ngay trong phần bình luận cũng có những nội dung cho thấy chưa thực sự hiểu đầy đủ về lập trình hàm, dù tất nhiên cũng có những bình luận được viết bởi người hiểu rất rõ. Lập trình hàm rất khó; bản thân tôi đến giờ vẫn còn đang học hu hu
Chỉ khi xuất hiện những trường hợp mà ngôn ngữ lập trình không còn là sở thích của đội ngũ phát triển mà trở thành vấn đề sống còn của công ty, khi đó chúng ta mới có thể một lần nữa bàn về sự cần thiết của FP.
Để tôi tóm lại. Về quản lý bộ nhớ và một số thuật toán, nó vẫn chưa vượt qua được lập trình hướng đối tượng. Tùy theo tình huống và chi phí mà sử dụng cho phù hợp.
Ừm... tôi không đồng ý với ý kiến cho rằng độ dốc học tập quá cao.
Trước hết là nó просто dễ, giảm bớt khả năng mắc lỗi, và vì thế năng suất cao hơn.
Như vậy là đủ rồi còn gì
Rất khó để mô hình hóa hoàn hảo tư duy và công việc của con người như các ngôn ngữ lập trình hàm thuần túy. Nhìn mấy thứ như free monad thì có vẻ tối đa chỉ chấp nhận được tới mức như rxjs thôi
. FP rồi cũng đến lúc cái phụ lại to hơn cái chính.
Ngay cả hiệu ứng trong FP hiện có cũng chỉ ở mức tách dữ liệu và phương thức,
chỉ nhìn việc
Optionalcòn không được dùng tốt như kỳ vọng cũng thấy trừu tượng hóa kiểu là một dạng trừu tượng hóa không cần thiết (vì phải lo khớp kiểu mà năng suất bị bào mòn quá nhiều).Nếu không đi theo hướng trừu tượng hóa dữ liệu và phép toán hơn nữa như closure thì sẽ có giới hạn khi tận dụng các ngôn ngữ hiện có.
Tính bất biến chỉ là một công cụ thường được dùng trong mô hình lập trình hàm.
Theo hiểu biết của tôi, mô hình lập trình hàm là một mô hình lập trình nhằm kiểm soát “tác dụng phụ” (side effect) ở mức tối đa có thể.
Vì cố gắng kiểm soát tác dụng phụ nên người ta tự nhiên coi trọng những khái niệm như tính trong suốt tham chiếu, tính bất biến và hàm thuần.
Ở góc độ đó, tôi cho rằng ngay cả khi không nhất thiết dùng ngôn ngữ lập trình hàm, việc nhận thức rõ các tác dụng phụ của những hàm hay phương thức mình viết và có thể kiểm soát chúng một cách phù hợp vẫn là điều đáng khuyến khích. Điều này có nhiều lợi ích, chẳng hạn như giảm code smell trong mã nguồn và giúp việc viết kiểm thử đơn vị trở nên dễ dàng hơn.
Cũng có các bài dịch giải thích chi tiết hơn về vấn đề này.
Từ góc nhìn như vậy, có một cuốn sách tập trung vào việc refactor để giảm thiểu tác dụng phụ là Lập trình hàm dễ hiểu: Thuần hóa phần mềm phức tạp bằng mã đơn giản. Vì cuốn sách tiếp cận theo hướng thực tiễn và sát với công việc hơn là lý thuyết, nên với những ai muốn viết code tốt, đây hoàn toàn là một cuốn đáng đọc và đáng học hỏi. Tôi nghĩ chỉ cần sau khi đọc xong mà khi viết code bạn chú ý đến tác dụng phụ nhiều hơn trước rất nhiều, thì cuốn sách này cũng đã xứng đáng với số tiền bỏ ra.
Cảm ơn, tôi sẽ tìm và đọc thử.
À! Hóa ra đã có bản dịch xuất bản rồi nhỉ! Mình phải đọc mới được!
Cảm ơn bạn đã giới thiệu sách!! Tôi sẽ mua và đọc ngay!
Cuốn sách đó thật sự rất hay!
Nhìn từ góc độ refactoring thì nó cũng thực sự dễ áp dụng khi viết.
Tất nhiên tôi cũng nghĩ lập trình hàm là một phương pháp tốt, nhưng có vẻ không nhiều người truyền đạt được các ưu điểm của nó một cách thuyết phục. Chỉ nói là nó tốt thì khó thật sự cảm nhận được, đúng không?
Dưới đây là ý kiến cá nhân của tôi: vì mọi chương trình hiện đại thực chất đều được xây dựng trên nền tảng máy Turing, nên về mặt trừu tượng có thể chia lớn thành hàm và dữ liệu; vì thế tôi nghĩ lập trình thủ tục về gốc rễ cũng mang tính hàm. Vậy ưu điểm thực sự của lập trình hàm so với lập trình thủ tục là gì? Theo tôi, đó đơn giản là “không dùng biến toàn cục hoặc các biến ở phạm vi tương đương”. Nhờ ưu điểm này mà việc “cô lập giữa các hàm” cũng như “tính toán đa luồng” trở nên hiệu quả hơn.
Tuy nhiên, nếu hỏi đây có phải là lợi ích chỉ có thể đạt được bằng lập trình hàm hay không thì không hẳn. Ngay trong các ngôn ngữ thủ tục, thông qua khái niệm dependency injection, việc cô lập theo đơn vị lớp và hàm cũng đã được khuyến nghị (các framework hiện đại về cơ bản đều đã áp dụng sẵn), còn trong ngôn ngữ Rust thì các ràng buộc ở cấp độ ngôn ngữ cũng được thiết kế để hướng tới tính toán đồng thời thuận tiện.
Tóm lại, ngôn ngữ hàm là ngôn ngữ tốt và cũng là một phương pháp luận tốt, nhưng thay vì “ưu việt theo nghĩa tiến hóa”, tôi nghĩ nó đơn giản là một kiểu ngôn ngữ “khó dùng, nhưng đã nỗ lực loại trừ khả năng thất bại ở cấp độ ngôn ngữ”, giống như Go hay Rust.
Ý bạn là ngay cả trong ngôn ngữ lập trình thủ tục cũng có thể làm được những thứ như hợp thành hàm phải không?
Nếu hiểu hẹp định nghĩa của "hợp thành hàm", ta có thể nghĩ rằng nó chỉ làm được trong các ngôn ngữ hàm, nhưng nghĩ kỹ thì việc thực thi đó rốt cuộc cũng vẫn chạy trên ngôn ngữ máy hay hợp ngữ, vốn là ngôn ngữ thủ tục. Tức là đây không phải vấn đề "có thể hay không thể", mà là vấn đề về "mối quan tâm, sở thích và triết lý của ngôn ngữ". Nếu mở rộng định nghĩa của "hợp thành hàm" từ "một tính năng cụ thể của một ngôn ngữ cụ thể" thành "sự kết hợp giữa các chức năng logic", thì hoàn toàn có thể làm được. Và rõ ràng ngôn ngữ hàm có những ưu điểm nhất định, nên các thứ như rxjs hay spark đã tích cực tiếp thu điều đó.
Như mọi người đã học ở khoa CNTT, bên dưới cho ra cùng một kết quả, chỉ khác hình thức biểu đạt mà thôi. Và ký pháp tiền tố thường được xem là mang tính hàm.
Ký pháp tiền tố : + 1 1
Ký pháp trung tố : 1 + 1
Ký pháp hậu tố : 1 1 +