thảo luận OOP hay FP

Các Voz Dev thuộc trường phái nào ?


  • Total voters
    604
Có viết nhầm chỗ nào ko vậy, mục đích chính của kế thừa là để reuse mà :surrender:
Thì nó phải quảng cáo vậy người ta mới sài chứ. Có thằng nào chê sp của mình đâu. Bạn tìm hiểu khái niệm monkey hold banada and forest sẽ hiểu oop ko phải để reuse
 
Thì nó phải quảng cáo vậy người ta mới sài chứ. Có thằng nào chê sp của mình đâu. Bạn tìm hiểu khái niệm monkey hold banada and forest sẽ hiểu oop ko phải để reuse
Ý là vụ "“you don’t have to set up a stateful gorilla to hold the banana first.” đó hả?
 
Giờ bác nào ở đây đưa ra 1 số bài toán cổ điển hay bài nào hay hay, rồi viết lời giải bằng cả 2 cách tiếp cận FP hay OOP đi. Rồi để người đọc tự lựa chọn FP vs OOP tốt hơn, tình huống này OOP tốt hơn còn tình huống kia FP tốt hơn v.v.

Tôi thì bị nhồi sọ OOP, UML, Design Patterns(Software Architecture), SOLID principles... các kiểu điểm các môn đều cao rồi mắc công ra ví dụ nó biased. ĐH nó không dạy FP chỉ dạy OOP bài cơ bản là Student - Lecturer - University Course. Thời đi làm thì cái Spring nó nhồi thêm AOP, a better version of OOP!?
 
Last edited:
Vãi bác kia bảo fp dơ. Bác thử tham gia các pj mà code thuần fp thử đi (không có for loop, không có side effect), code bằng scala/haskel mình thấy đẹp hơn cả OOP. Hình như nhiều bác ở đây k phân biệt được FP và imperative programming thì phải. Code FP đúng cực, dài, đẹp chứ k phải ngắn và dơ đâu

Sai rồi bạn ơi, FP = ngắn + đẹp cơ.

Mà FP vs imperative là sao đây nữa bạn, pure FP nó là declarative.
 
Sai rồi bạn ơi, FP = ngắn + đẹp cơ.

Mà FP vs imperative là sao đây nữa bạn, pure FP nó là declarative.
Đẹp thôi. Còn mình không thấy ngắn, so với kiểu code tự do, code có thêm ràng buộc thì nó phải dài hơn thôi.

Mình có nói FP là imperative à ?
 
Sai rồi bạn ơi, FP = ngắn + đẹp cơ.

Mà FP vs imperative là sao đây nữa bạn, pure FP nó là declarative.

tôi đoán thím chỉ coi clip chưa đụng proj fp bao giờ. Mấy cái clip nhìn thì hay chứ làm thật thì khá mệt đó.

fp thì function ngắn nhưng nhiều, code dài hơn. Immutable cũng làm code dài hơn, no early return cũng làm code dài hơn. Follow monad cũng làm code dài hơn (nếu ko có lib hỗ trợ tận răng). Không for loop mà phải recursive cũng làm code dài hơn.

Ví dụ đoạn code đơn giản: func A(n). Nếu n là 0 thì return 0, nếu n%2==0 thì result là 2n, nếu n%3==0 thì result là 5n, nếu cả 2 thì là 10n. Code bình thường chỉ 5 dòng, thím code kiểu immutable - no early return xem có dài ko.
 
tôi đoán thím chỉ coi clip chưa đụng proj fp bao giờ. Mấy cái clip nhìn thì hay chứ làm thật thì khá mệt đó.

fp thì function ngắn nhưng nhiều, code dài hơn. Immutable cũng làm code dài hơn, no early return cũng làm code dài hơn. Follow monad cũng làm code dài hơn (nếu ko có lib hỗ trợ tận răng). Không for loop mà phải recursive cũng làm code dài hơn.

Ví dụ đoạn code đơn giản: func A(n). Nếu n là 0 thì return 0, nếu n%2==0 thì result là 2n, nếu n%3==0 thì result là 5n, nếu cả 2 thì là 10n. Code bình thường chỉ 5 dòng, thím code kiểu immutable - no early return xem có dài ko.
Thế này có được không nhỉ :nosebleed:
Code:
fizzBuzz a
    | a == 0 = 0
    | mod2 == 0 = 2*a
    | mod3 == 0 = 5*a
    | mod2 == 0 && mod3 == 0 = 10*a
    | otherwise = a
    where mod2 = a `mod` 2
          mod3 = a `mod` 3
 
Thế này có được không nhỉ :nosebleed:
Code:
fizzBuzz a
    | a == 0 = 0
    | mod2 == 0 = 2*a
    | mod3 == 0 = 5*a
    | mod2 == 0 && mod3 == 0 = 10*a
    | otherwise = a
    where mod2 = a `mod` 2
          mod3 = a `mod` 3

tất nhiên là đc. Nhưng dòng kết hợp giữa mod2 và mod3 có vẻ thừa nếu dùng mutable vì 2*5=10. Nếu thêm cái mod5 thì nhân 10 nữa thì cách này sẽ tăng số dòng đáng kể, còn mutable chỉ thêm 1 dòng.
 
tôi đoán thím chỉ coi clip chưa đụng proj fp bao giờ. Mấy cái clip nhìn thì hay chứ làm thật thì khá mệt đó.

fp thì function ngắn nhưng nhiều, code dài hơn. Immutable cũng làm code dài hơn, no early return cũng làm code dài hơn. Follow monad cũng làm code dài hơn (nếu ko có lib hỗ trợ tận răng). Không for loop mà phải recursive cũng làm code dài hơn.

Ví dụ đoạn code đơn giản: func A(n). Nếu n là 0 thì return 0, nếu n%2==0 thì result là 2n, nếu n%3==0 thì result là 5n, nếu cả 2 thì là 10n. Code bình thường chỉ 5 dòng, thím code kiểu immutable - no early return xem có dài ko.
Lol cái đề bài này rơi vào đúng điểm mạnh của FP là pure function mà b lại bảo code fp ko ngắn k đẹp á? Tôi tắt máy lên giương r mà code haskell thì sẽ ngắn hơn bạn trên kia, conditional matching luôn ko cần where.

T code fp năm 2018 rồi, hiện tại k dùng 100% fp nhưng nếu được thì vẫn ap vào code.

Ko lại bảo tôi code bằng youtube :)
 
Cái đề trên bạn rẽ nhánh thông thường mới dài chứ matching pattern là đẹp nhất rồi. Nói về khoản ngắn gọn thì haskell vô địch, nhiều khi ngắn quá đâm ra khó đọc
 
Đẹp thôi. Còn mình không thấy ngắn, so với kiểu code tự do, code có thêm ràng buộc thì nó phải dài hơn thôi.

Mình có nói FP là imperative à ?
Thì bạn bảo phân biệt fp với imperative, tưởng bạn nghĩ 2 đứa này chung đường :)). Ý bạn là do immutable nên phải code dài hay gì? Chứ t thấy ngắn, đã từng code java, haskell, rust. Ko biết bạn bảo ntnao thì ngắn?
 
tôi đoán thím chỉ coi clip chưa đụng proj fp bao giờ. Mấy cái clip nhìn thì hay chứ làm thật thì khá mệt đó.

fp thì function ngắn nhưng nhiều, code dài hơn. Immutable cũng làm code dài hơn, no early return cũng làm code dài hơn. Follow monad cũng làm code dài hơn (nếu ko có lib hỗ trợ tận răng). Không for loop mà phải recursive cũng làm code dài hơn.

Ví dụ đoạn code đơn giản: func A(n). Nếu n là 0 thì return 0, nếu n%2==0 thì result là 2n, nếu n%3==0 thì result là 5n, nếu cả 2 thì là 10n. Code bình thường chỉ 5 dòng, thím code kiểu immutable - no early return xem có dài ko.
Nói chung không cần lậm FP quá, for loop thì chẳng vấn đề gì, miền code dễ đọc dễ maintain. Tôi viết C# vốn OOP nhưng áp dụng vài yếu tố FP vào để dễ code, no side effect, no mutation... Ngay cái thư viện Entity Framework nổi tiếng cũng là FP. Rồi mấy cái event, delagate trong C# cũng là FP thôi.
 
Lol cái đề bài này rơi vào đúng điểm mạnh của FP là pure function mà b lại bảo code fp ko ngắn k đẹp á? Tôi tắt máy lên giương r mà code haskell thì sẽ ngắn hơn bạn trên kia, conditional matching luôn ko cần where.

T code fp năm 2018 rồi, hiện tại k dùng 100% fp nhưng nếu được thì vẫn ap vào code.

Ko lại bảo tôi code bằng youtube :)

haskell thì extreme fp rồi, tôi chờ cách của thím để học thêm vậy :D

Hiện tại tôi đang làm phải dùng array reduce(js) khá khó đọc.
 
Last edited:
Ví dụ đoạn code đơn giản: func A(n). Nếu n là 0 thì return 0, nếu n%2==0 thì result là 2n, nếu n%3==0 thì result là 5n, nếu cả 2 thì là 10n. Code bình thường chỉ 5 dòng, thím code kiểu immutable - no early return xem có dài ko.
haskell cheat thành 1 dòng nè.
Code:
a 0 = 0; a n | n `mod` 6 == 0 = 10*n | n `mod` 2 == 0 = 2 *n | n `mod` 3 == 0 = 5*n; a n = n
 
Last edited:
haskell cheat thành 1 dòng nè.
Code:
a 0 = 0; a n | n `mod` 6 == 0 = 10*n | n `mod` 2 == 0 = 2 *n | n `mod` 3 == 0 = 5*n; a n = n
Ngắn gọn quá đâm ra khó hiểu thật. Mình bị dị ứng với kiểu code 1 dòng mà nhiều logic thế này
2y9npcU.png
 
Thì bạn bảo phân biệt fp với imperative, tưởng bạn nghĩ 2 đứa này chung đường :)). Ý bạn là do immutable nên phải code dài hay gì? Chứ t thấy ngắn, đã từng code java, haskell, rust. Ko biết bạn bảo ntnao thì ngắn?
Ví dụ bạn có mảng a gồm 100 phần tử , bạn muốn thay đổi phần tử thứ 23, nếu muốn code immutable mà performance tốt thì sẽ rất cực, trong khi code bt chỉ cần a[23]=... là được.
Java mình thấy dài chủ yếu do cách đặt tên của nó, kotlin tương tự java nhưng khá ngắn. Rust cũng ngắn, chỉ có cái ownership của nó hơi rắc rối chứ cũng k dài.
 
Back
Top