thảo luận OOP hay FP

  • Người tạo chủ đề Người tạo chủ đề Quynh 123
  • Ngày bắt đầu Ngày bắt đầu

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


  • Tổng số người bình chọn
    684
Các pro FP cho hỏi, làm thế nào để ngôn ngữ thuần FP đạt hiệu quả tốt.
Ví dụ đơn giản là tính fibonaci thứ n: f(n) = f(n-1) + f(n-2)
Với ngôn ngữ ko thuần FP, thì việc dùng đệ quy thay cho for (theo nguyên tắc immutable var) sẽ:
1. Luôn tạo thêm biến tham chiếu mới, nhồi vào stack -> dùng nhiều mem hơn.
2. Khi tính f(n) thì f(n-2) được tính, khi tính f(n-1) thì f(n-2) lại tính tiếp -> chậm hơn.
Cần được khai sáng.
Cache nhé , bản chất fp khiến việc cache rất dễ dàng , nó tham chiếu đã tính thành công trước đó nên ở bài toán nhiều phép tính thì nó tối ưu bộ nhớ hơn
 
Tớ không nghĩ là OOP làm ra để tận dụng cái kế thừa. OOP nâng cao sự chặt chẽ, dễ đọc dễ hiểu, mọi thứ phải vào đúng chỗ của nó mới vận hành được.

Ví dụ nếu định nghĩa đầu bao gồm mắt, mũi, mồm, miệng chẳng hạn, thì ở OOP giao cho bạn mắt chẳng hạn thì bạn phải lắp đúng nó vào cái đầu thì mới ok, chứ lắp vào chân thì không được. Trong khi FP thì mắt lắp vào chân vô tư.

Monkey Banana and Forest, thực ra design tốt thì sẽ không bị tình trạng đấy. Bạn hoàn toàn có thể làm y chang FP với OOP, có gì là khó.

Đến câu FP thể hiện đúng bản chất vạn vật tớ chỉ cười thôi. Với tớ OOP mới là thể hiện đúng bản chất của vạn vật. Ví dụ 1 người chẳng hạn, ở FP chỉ đơn giản là mấy cái bộ phận chân tay mặt mũi. Nhưng với OOP thì người không chỉ là các bộ phận rời rạc như thế mà còn bao gồm cả những tương tác ràng buộc giữa các bộ phận ấy với nhau nữa. Đó là lý do người ta thấy FP không đủ nên mới phải nghĩ ra OOP. Chờ nghe phản biện của bạn.
Nó ko phải bản chât sự vật nhé, chỉ là con người cố gắng áp dụng suy nghĩ lêch lạc của mình cho cái họ thấy, nó sẽ sai hoăc ko còn phù hợp vào 1ngày nào đó , chỉ có các phép toán mới là chân lí
 
Cái này thì liên quan với OOP đây bạn?
Bạn có biết Typeclass của Haskell, Trait của Rust cũng cho phép bạn design by contract được ko?
Nó còn làm tốt hơn cả mớ bùi nhùi abstract class với cả interface trong OOP.

Còn cái kế thừa chính là 1 cái nguyên nhân dẫn tới cái meme ngta hay chê bana in jungle của OOP đó.
Làm sao mà nó làm tốt hơn được. Như tớ đã nói, để làm được đúng mắt chỉ có thể lắp được vào đầu mà không phải vào chân, thì mắt cần phải có thông tin về đầu. Bất kể bạn dùng cái khỉ gì đi chăng nữa thì nó cũng phải là như thế.

Tớ đọc ví dụ về Monkey in Jungle thấy rất buồn cười khi các bạn đổ tại nguyên nhân là do kế thừa. Cá nhân tớ cho rằng nguyên nhân không phải như vậy. Nếu bạn muốn dùng Monkey độc lập, cũng như Monkey thuộc về Jungle nào đấy, thì cách làm đúng phải là
C#:
Public Class Monkey
{
    //Monkey Properties Only
    ...
}
C#:
Public Class Jungle
{
    //Jungle Properties Only
    ...
}
C#:
Public Class JungleMonkey : Monkey
{
    Public Jungle MonkeyJungle {get;set;}
}

Nhưng ví dụ về Monkey Jungle bạn nói thì nó đặt tên Monkey thay vì JungleMonkey và muốn chỉ sử dụng 1 cái class bản chất là class Monkey trong ví dụ của tớ. Thế thì làm gì mà chả nát, và nguyên nhân nát là do người modelling data làm sai. OOP rất chặt chẽ, mọi thứ đòi hỏi phải chính xác.

Bạn bảo FP tốt hơn thì minh họa cụ thể như ví dụ của tớ đi, làm thế nào để thể hiện chuẩn xác quan hệ JungleMonkey là Monkey + thông tin về Jungle?
 
Làm sao mà nó làm tốt hơn được. Như tớ đã nói, để làm được đúng mắt chỉ có thể lắp được vào đầu mà không phải vào chân, thì mắt cần phải có thông tin về đầu. Bất kể bạn dùng cái khỉ gì đi chăng nữa thì nó cũng phải là như thế.

Tớ đọc ví dụ về Monkey in Jungle thấy rất buồn cười khi các bạn đổ tại nguyên nhân là do kế thừa. Cá nhân tớ cho rằng nguyên nhân không phải như vậy. Nếu bạn muốn dùng Monkey độc lập, cũng như Monkey thuộc về Jungle nào đấy, thì cách làm đúng phải là
C#:
Public Class Monkey
{
    //Monkey Properties Only
    ...
}
C#:
Public Class Jungle
{
    //Jungle Properties Only
    ...
}
C#:
Public Class JungleMonkey : Monkey
{
    Public Jungle MonkeyJungle {get;set;}
}

Nhưng ví dụ về Monkey Jungle bạn nói thì nó đặt tên Monkey thay vì JungleMonkey và muốn chỉ sử dụng 1 cái class bản chất là class Monkey trong ví dụ của tớ. Thế thì làm gì mà chả nát, và nguyên nhân nát là do người modelling data làm sai. OOP rất chặt chẽ, mọi thứ đòi hỏi phải chính xác.

Bạn bảo FP tốt hơn thì minh họa cụ thể như ví dụ của tớ đi, làm thế nào để thể hiện chuẩn xác quan hệ JungleMonkey là Monkey + thông tin về Jungle?

Tôi đang nói đến cái câu châm biếm " Bạn muốn một con khỉ, nhưng OOP sẽ đưa cho bạn một con khỉ đang cẩm quả chuối kèm cả khu rừng mà nó đang đứng trong đó". Lúc bạn muốn re-use cái gì trong OOP bạn sẽ gặp trường hợp tương tự phải mang cả class cha class con class chú theo.

Còn cái ví dụ của bạn tôi còn chẳng biết mục đích bạn viết ra để làm cái gì nữa bạn bảo tôi minh hoạ cái gì nhể. Bạn đưa ví dụ hay muốn tìm hiểu thì đưa bài cụ thể ra đây, đưa dăm ba cái class define vớ vẩn làm gì.
 
Cái việc mô phỏng của OOP ở trên có bạn giải thích rồi, ngta cố trừu tượng hoá bài toán cụ thể cùng input output function bằng mô hình object, cái này ngay từ đầu đã ko đúng với bản chất của Software Program rồi, bạn tin vào OOP như con vẹt ấy rồi tưởng nó là vạn vật gì đó -)).
 
Cái việc mô phỏng của OOP ở trên có bạn giải thích rồi, ngta cố trừu tượng hoá bài toán cụ thể cùng input output function bằng mô hình object, cái này ngay từ đầu đã ko đúng với bản chất của Software Program rồi, bạn tin vào OOP như con vẹt ấy rồi tưởng nó là vạn vật gì đó -)).
Bạn gay gắt quá rồi đó, đừng cố tranh luận theo kiểu mỉa mai công kích như vậy. Thay vì chỉ nói chung chung thì hãy cho 1 ví dụ bằng coding thật sự tạo ra sự khác biệt khiến bạn "OOP vẹt" tâm phục đi.

Bạn chê người khác tin OOP như con vẹt. Nhưng chính bạn cũng đang tin vào FP mù quáng. Chê bôi theo kiểu, ồ à đọc được vài bài anti OOP xong lên đỉnh với FP, nghĩ OOP như rác rưởi. Hiện có rất nhiều trào lưu kiểu phá cách như vậy, lật đổ nền móng cũ. Dù bạn có chửi như thế nào, thì ngoài kia hàng tỉ project design theo OOP vẫn đang vận hành tốt, nhiều hơn FP rất nhiều. Nếu nó thực sự tệ, thì đã sụp đổ từ lâu rồi.

Cái vấn đề banana money, tại sao phải reuse code theo kiểu clone từ project cũ sang project mới vậy ? Chứng tỏ proj cũ tệ đến mức ko thể reuse theo kiểu dependency, người viết cũ ko đủ khả năng. Tôi tin là với FP, người viết ko thuần thục thì kiểu gì cũng sẽ gặp rắc rôi mà thôi.

Nhân tiện, bạn có thể nói rõ hơn về "bản chất của Software Program" là gì không ?
 
Fp gần với tự nhiên , vì nó gần với tính bất biến của toán học, opp sinh ra do suy nghĩ lệch lac của con người thuở mới lập trình vote fn
theo bạn một bức tranh vẽ bằng vector vs 1 cái vẽ bằng bút chì màu cái nào tự nhiên, dễ hiểu hơn?
 
Cái việc mô phỏng của OOP ở trên có bạn giải thích rồi, ngta cố trừu tượng hoá bài toán cụ thể cùng input output function bằng mô hình object, cái này ngay từ đầu đã ko đúng với bản chất của Software Program rồi, bạn tin vào OOP như con vẹt ấy rồi tưởng nó là vạn vật gì đó -)).
Tranh luận nhưng bạn nói mồm ko à. Chưa thấy đưa dẫn chứng cụ thể như bác oop kia.

via nextVOZ for iPhone
 
Các pro FP cho hỏi, làm thế nào để ngôn ngữ thuần FP đạt hiệu quả tốt.
Ví dụ đơn giản là tính fibonaci thứ n: f(n) = f(n-1) + f(n-2)
Với ngôn ngữ ko thuần FP, thì việc dùng đệ quy thay cho for (theo nguyên tắc immutable var) sẽ:
1. Luôn tạo thêm biến tham chiếu mới, nhồi vào stack -> dùng nhiều mem hơn.
2. Khi tính f(n) thì f(n-2) được tính, khi tính f(n-1) thì f(n-2) lại tính tiếp -> chậm hơn.
Cần được khai sáng.
https://rosettacode.org/wiki/Fibonacci_sequence#Elixir

thực ra thì nếu các bạn học quy hoạch động các kiểu rồi sẽ không bao giờ còn thắc mắc cái (2), thêm nữa thường FP nó có hỗ trợ tail cail optimization, chỉ cần bạn viết function hợp lý nó sẽ biến cái recursion thành loop. Đấy là tôi còn chưa nói vì FP phần lớn là immutable cho nên compiler có nhiều cách optimize hiệu quả hơn, mấy cái trivial example dạng này nó replace function call thành constant hết.

tất nhiên constant folding thì cái nontrivial compiler nào cũng làm, bàn về optimization thì mấy thằng ít tài nguyên như haskell các kiểu còn lâu mới so được c/c++ có mấy cái compiler như gcc hay clang đã được đầu tư vài triệu giờ phát triển vào.

btw, về chuyện tại sao mấy thằng dùng FP lại cocky hơn mấy thằng dùng OOP, thì ngay cả câu thắc mắc này đã làm tôi coi thường các bạn rồi. Bởi vì thực ra nó đơn giản vãi ra: thằng đíu nào dùng FP cũng đã từng dùng OOP, thấy không thoả mãn với công cụ mình dùng mới chuyển sang dùng các công cụ khác nó thấy hợp hơn. Ngược lại thì mấy thằng khen OOP phần lớn là được học sẵn OOP ở trường, ra ngoài đời làm code monkey mấy chục năm đéo phát triển, đéo tự học được cái gì, nếu có học thì cũng là do công ty ép học, hoặc là vì miếng ăn.

Tất nhiên bỏ miếng ăn vào mồm được là không sai, thâm niên OOP đúng là lương cao hơn mấy thằng chơi FP nhiều, cơ mà đến rosettacode các kiểu cũng đéo biết thì xin phép cho tôi khinh bỉ các bạn tiếp.
 
Tôi đang nói đến cái câu châm biếm " Bạn muốn một con khỉ, nhưng OOP sẽ đưa cho bạn một con khỉ đang cẩm quả chuối kèm cả khu rừng mà nó đang đứng trong đó". Lúc bạn muốn re-use cái gì trong OOP bạn sẽ gặp trường hợp tương tự phải mang cả class cha class con class chú theo.

Còn cái ví dụ của bạn tôi còn chẳng biết mục đích bạn viết ra để làm cái gì nữa bạn bảo tôi minh hoạ cái gì nhể. Bạn đưa ví dụ hay muốn tìm hiểu thì đưa bài cụ thể ra đây, đưa dăm ba cái class define vớ vẩn làm gì.
Vấn đề ở chỗ tớ thấy bạn nói không đúng. Chuyện muốn 1 con khỉ nhưng nhận lại là 1 con khỉ cầm quả chuối kèm cả khu rừng tớ chửi hoài à. Nhưng chửi là phải chửi đúng, nguyên nhân không ở kế thừa. Nguyên nhân là do cái thằng code đầu tiên thay vì việc chia ra làm nhiều thành phần nhỏ rồi tổ hợp lại với nhau thì nó lại làm 1 cái bự dính vào nhau để rồi sau đó nếu chỉ cần 1 bộ phận nhỏ ở trong đấy thì không reuse lại được.

Minh họa là minh họa cho việc biểu diễn mọi thứ của vũ trụ tự nhiên dễ hiểu với OOP và hoàn toàn không bị vấn đề cần khỉ được khỉ với cả khu rừng. Ví dụ là bài toán cụ thể để từ từ tớ nghĩ đã.
 
https://rosettacode.org/wiki/Fibonacci_sequence#Elixir

thực ra thì nếu các bạn học quy hoạch động các kiểu rồi sẽ không bao giờ còn thắc mắc cái (2), thêm nữa thường FP nó có hỗ trợ tail cail optimization, chỉ cần bạn viết function hợp lý nó sẽ biến cái recursion thành loop. Đấy là tôi còn chưa nói vì FP phần lớn là immutable cho nên compiler có nhiều cách optimize hiệu quả hơn, mấy cái trivial example dạng này nó replace function call thành constant hết.

tất nhiên constant folding thì cái nontrivial compiler nào cũng làm, bàn về optimization thì mấy thằng ít tài nguyên như haskell các kiểu còn lâu mới so được c/c++ có mấy cái compiler như gcc hay clang đã được đầu tư vài triệu giờ phát triển vào.

btw, về chuyện tại sao mấy thằng dùng FP lại cocky hơn mấy thằng dùng OOP, thì ngay cả câu thắc mắc này đã làm tôi coi thường các bạn rồi. Bởi vì thực ra nó đơn giản vãi ra: thằng đíu nào dùng FP cũng đã từng dùng OOP, thấy không thoả mãn với công cụ mình dùng mới chuyển sang dùng các công cụ khác nó thấy hợp hơn. Ngược lại thì mấy thằng khen OOP phần lớn là được học sẵn OOP ở trường, ra ngoài đời làm code monkey mấy chục năm đéo phát triển, đéo tự học được cái gì, nếu có học thì cũng là do công ty ép học, hoặc là vì miếng ăn.

Tất nhiên bỏ miếng ăn vào mồm được là không sai, thâm niên OOP đúng là lương cao hơn mấy thằng chơi FP nhiều, cơ mà đến rosettacode các kiểu cũng đéo biết thì xin phép cho tôi khinh bỉ các bạn tiếp.
Mình không cùng đạo có lẽ không nên bình luận về nhau. Với cá nhân tớ thì sự phát triển chỉ đơn giản là vị trí tốt hơn, lương cao hơn mà thôi và tớ tin đa phần mọi người ngoài kia là giống tớ. Nhưng chỉ vì như vậy mà bạn đánh giá éo phát triển, éo tự học được cái gì thì tớ nghĩ là quá phiến diện. Biển học vô bờ, ngay cả OOP mình còn chưa biết hết thì tại sao lại không tiếp tục học nó để có lương cao hơn mà phải đi dành thời gian cho cái khác?

Bạn khinh bỉ là ở góc nhìn của bạn thôi. Chứ ở góc nhìn của tớ, bất kể bạn khinh bỉ thế nào, nếu lương không cao hơn thì tớ cũng éo học, éo cần biết .Ngược lại cũng vậy, nếu nó lương cao, việc nhiều thì bất kể tớ thích hay ko thích , bạn thích hay không thích thì tớ cũng sẵn sàng lao đầu vào học ngay.
 
https://rosettacode.org/wiki/Fibonacci_sequence#Elixir

thực ra thì nếu các bạn học quy hoạch động các kiểu rồi sẽ không bao giờ còn thắc mắc cái (2), thêm nữa thường FP nó có hỗ trợ tail cail optimization, chỉ cần bạn viết function hợp lý nó sẽ biến cái recursion thành loop. Đấy là tôi còn chưa nói vì FP phần lớn là immutable cho nên compiler có nhiều cách optimize hiệu quả hơn, mấy cái trivial example dạng này nó replace function call thành constant hết.

tất nhiên constant folding thì cái nontrivial compiler nào cũng làm, bàn về optimization thì mấy thằng ít tài nguyên như haskell các kiểu còn lâu mới so được c/c++ có mấy cái compiler như gcc hay clang đã được đầu tư vài triệu giờ phát triển vào.

btw, về chuyện tại sao mấy thằng dùng FP lại cocky hơn mấy thằng dùng OOP, thì ngay cả câu thắc mắc này đã làm tôi coi thường các bạn rồi. Bởi vì thực ra nó đơn giản vãi ra: thằng đíu nào dùng FP cũng đã từng dùng OOP, thấy không thoả mãn với công cụ mình dùng mới chuyển sang dùng các công cụ khác nó thấy hợp hơn. Ngược lại thì mấy thằng khen OOP phần lớn là được học sẵn OOP ở trường, ra ngoài đời làm code monkey mấy chục năm đéo phát triển, đéo tự học được cái gì, nếu có học thì cũng là do công ty ép học, hoặc là vì miếng ăn.

Tất nhiên bỏ miếng ăn vào mồm được là không sai, thâm niên OOP đúng là lương cao hơn mấy thằng chơi FP nhiều, cơ mà đến rosettacode các kiểu cũng đéo biết thì xin phép cho tôi khinh bỉ các bạn tiếp.
Thắc mắc cái (2) là vì đó là define của fibonaci, còn muốn đệ quy kiểu đi tiến thì nó chả khác gì QHD. Đệ quy mà đi tiến như vậy lại không thể hiện rõ được ý nghĩa của functional đó có chức năng tính fibonacci. Kiểu đệ quy gượng ép.
Nói OOP hay FP, thì nó ko chỉ là coding, mà từ design -> coding. Các bạn tự hào là nắm rõ OOP hết rồi, thấy ko thỏa mãn nên mới nhảy sang FP. Chúng tôi đang rất open để lắng nghe xem FP hay ho ntn, mà đọc mấy page chưa thấy các bạn đưa ra 1 cái ví dụ hoàn chỉnh nào từ design đến coding theo FP mà nó vượt trội hơn OOP, ngoài việc chửi đổng :))
 
Bạn gay gắt quá rồi đó, đừng cố tranh luận theo kiểu mỉa mai công kích như vậy. Thay vì chỉ nói chung chung thì hãy cho 1 ví dụ bằng coding thật sự tạo ra sự khác biệt khiến bạn "OOP vẹt" tâm phục đi.

Bạn chê người khác tin OOP như con vẹt. Nhưng chính bạn cũng đang tin vào FP mù quáng. Chê bôi theo kiểu, ồ à đọc được vài bài anti OOP xong lên đỉnh với FP, nghĩ OOP như rác rưởi. Hiện có rất nhiều trào lưu kiểu phá cách như vậy, lật đổ nền móng cũ. Dù bạn có chửi như thế nào, thì ngoài kia hàng tỉ project design theo OOP vẫn đang vận hành tốt, nhiều hơn FP rất nhiều. Nếu nó thực sự tệ, thì đã sụp đổ từ lâu rồi.

Cái vấn đề banana money, tại sao phải reuse code theo kiểu clone từ project cũ sang project mới vậy ? Chứng tỏ proj cũ tệ đến mức ko thể reuse theo kiểu dependency, người viết cũ ko đủ khả năng. Tôi tin là với FP, người viết ko thuần thục thì kiểu gì cũng sẽ gặp rắc rôi mà thôi.

Nhân tiện, bạn có thể nói rõ hơn về "bản chất của Software Program" là gì không ?

Ai trào lưu thì trào lưu chứ tôi code OOP 3 năm và bắt đầu học FP năm 2016, đây thực tiễn tôi thấy OOP lởm khởm hơn FP chứ trào lưu gì bạn? Tỉ project OOP, ôi hèn gì trong thớt này gạch tôi nhiều thế, hóa ra do tỉ a dev cũng code OOP vào gạch. Tôi chả quan tâm tỉ anh dev OOP hay 2 tỉ anh code Js, đông thì tốt á hả?

Bản chất của software tôi nói ở trên rồi thích thì lục lại mà đọc.
 
Tranh luận nhưng bạn nói mồm ko à. Chưa thấy đưa dẫn chứng cụ thể như bác oop kia.

via nextVOZ for iPhone
Dẫn chứng đek gì define cái class với signature?

Thích vọc code thì đưa hẳn đề bài.
Như cái đề gì tôi có trả lời trên kia kìa, đọc code FP có phải dễ hiểu dễ nắm hơn code immutable chưa? Chưa kể còn ngắn + đẹp nha.
 
https://rosettacode.org/wiki/Fibonacci_sequence#Elixir


tất nhiên constant folding thì cái nontrivial compiler nào cũng làm, bàn về optimization thì mấy thằng ít tài nguyên như haskell các kiểu còn lâu mới so được c/c++ có mấy cái compiler như gcc hay clang đã được đầu tư vài triệu giờ phát triển vào.


Tất nhiên bỏ miếng ăn vào mồm được là không sai, thâm niên OOP đúng là lương cao hơn mấy thằng chơi FP nhiều, cơ mà đến rosettacode các kiểu cũng đéo biết thì xin phép cho tôi khinh bỉ các bạn tiếp.

Glassgow của Haskell thua gcc như nào, tôi thấy GHC thông minh vãi r còn gì :))

+1000 gạch cho các thanh niên ko biết tới rosettacode.
 
Vấn đề ở chỗ tớ thấy bạn nói không đúng. Chuyện muốn 1 con khỉ nhưng nhận lại là 1 con khỉ cầm quả chuối kèm cả khu rừng tớ chửi hoài à. Nhưng chửi là phải chửi đúng, nguyên nhân không ở kế thừa. Nguyên nhân là do cái thằng code đầu tiên thay vì việc chia ra làm nhiều thành phần nhỏ rồi tổ hợp lại với nhau thì nó lại làm 1 cái bự dính vào nhau để rồi sau đó nếu chỉ cần 1 bộ phận nhỏ ở trong đấy thì không reuse lại được.

Minh họa là minh họa cho việc biểu diễn mọi thứ của vũ trụ tự nhiên dễ hiểu với OOP và hoàn toàn không bị vấn đề cần khỉ được khỉ với cả khu rừng. Ví dụ là bài toán cụ thể để từ từ tớ nghĩ đã.

Lại nguyên nhân do dev à :)), các anh khôn thế, paradigm các anh nghĩ ra xong đem vào thực tiễn nó có vấn đề cồm cộm ra đó, 10 project hết 7 bị dính cái mớ bòng bong inheritance các anh lại bảo do dev. Giống kiểu bọn đi dạy Agile Scrum, ngta chửi cho thì bảo do mày làm ko đúng, thế mà vẫn ăn chửi ngập đầu.

Tôi chờ bạn nghĩ bài toán đây, đem bài nào bạn code hằng ngày vào đây càng tốt.
 
Dẫn chứng đek gì define cái class với signature?

Thích vọc code thì đưa hẳn đề bài.
Như cái đề gì tôi có trả lời trên kia kìa, đọc code FP có phải dễ hiểu dễ nắm hơn code immutable chưa? Chưa kể còn ngắn + đẹp nha.
It ra ngta còn có cái để dẫn chứng. Còn anh chê đủ thứ nhưng nói mồm chửi đổng ko à.
calc 0 = 0
calc n
| n mod 6 == 0 = 10 * n
| n mod 3 == 0 = 5 * n
| n mod 2 == 0 = 2 * n
| otherwise = n

Còn cái bài anh nói dẫn chứng ngắn gọn kia là bài này ở mấy page trước á hả? Thôi chứ hài vkl. Bài đó nhảm nhí có nói đc thế mạnh hay rõ ràng chỉ thuộc về fp đâu. Vì bài này mà anh anti mù quáng OOP luônn hở? Cực đoan vkl.

Công nhận là nó ngắn gọn , tôi cũng thích. Tôi vẫn xài FP bình thường, chỉ ko anti OOP cực đoan như anh thôi.
 
It ra ngta còn có cái để dẫn chứng. Còn anh chê đủ thứ nhưng nói mồm chửi đổng ko à.


Còn cái bài anh nói dẫn chứng ngắn gọn kia là bài này ở mấy page trước á hả? Thôi chứ hài vkl. Bài đó nhảm nhí có nói đc thế mạnh hay rõ ràng chỉ thuộc về fp đâu. Vì bài này mà anh anti mù quáng OOP luônn hở? Cực đoan vkl.

Công nhận là nó ngắn gọn , tôi cũng thích. Tôi vẫn xài FP bình thường, chỉ ko anti OOP cực đoan như anh thôi.

Thích thì chê thôi.

Cái bài trên kia tôi code để cm với bạn kia là code fp ngắn + đẹp (và expressiveness cao chưa kể vào). Cái tôi muốn nói là cho đề bài cụ thể mới nói ch đc chứ cho 3 cái class define bảo tôi phản biện cái gì trong đó -))

Mà bạn ko hiểu ý tôi cứ quote lạc đề làm gì?
 
Thích thì chê thôi.

Cái bài trên kia tôi code để cm với bạn kia là code fp ngắn + đẹp (và expressiveness cao chưa kể vào). Cái tôi muốn nói là cho đề bài cụ thể mới nói ch đc chứ cho 3 cái class define bảo tôi phản biện cái gì trong đó -))

Mà bạn ko hiểu ý tôi cứ quote lạc đề làm gì?
Riêng bài đó ngắn nhưng nó đủ để anh anti cực đoan thì khác nào có thằng như anh, nó cuồng OOP rồi anti cực đoan FP.

Quay về vấn đề lúc đầu a mang: cần con khỉ mà nó đưa con khi cầm chuối vs rừng j j đó. Ông kia ít ra manng 1 luân điểm thiết kế và cách xài sai . Chưa bàn đến đúng sai, nhưng ít ra ngta có ý. Anh có ý j nói lại thì nói ra để thảo luận, chứ chửi đổng thích thì chê ai mà ko làm đc.
 

Thống kê chủ đề

Ngày tạo
Quynh 123,
Người trả lời cuối
HIL,
Trả lời
593
Lượt xem
97.285
Quay lại
Lên đầu trang