Những vấn đề có thể phát sinh từ các khái niệm mô phỏng từ các ngôn ngữ khác?

Tôi đã đọc nhiều lần trên web rằng nếu ngôn ngữ của bạn không hỗ trợ một số khái niệm, ví dụ: hướng đối tượng hoặc có thể gọi hàm và nó được coi là một cách thực hành tốt trong ngữ cảnh khác này, bạn nên thực hiện nó.

Vấn đề duy nhất tôi có thể thấy bây giờ là các lập trình viên khác có thể thấy mã của bạn quá khác so với thông thường, khiến họ khó lập trình. Những vấn đề khác bạn nghĩ có thể phát sinh từ điều này?

Một trong những vấn đề là bạn có thể thấy mình viết rất nhiều mã để diễn đạt điều gì đó theo cách bạn sẽ làm bằng ngôn ngữ khác, trong khi có một cách đơn giản hơn trong ngôn ngữ bạn sử dụng.

Ví dụ, trong câu trả lời về Stack Overflow , tôi đã giải thích cách các hợp đồng mã, khái niệm được sử dụng trong .NET Framework, có thể được mô phỏng một phần trong PHP mà không hỗ trợ chúng. Cuối cùng tôi đã viết rất nhiều mã, vì điều tương tự là có thể thực hiện được với các mảng đơn giản.

Tổng quát hơn, mỗi ngôn ngữ có văn hóa riêng, cách thực hành tốt nhất, phong cách riêng.

• Nếu tôi bắt đầu viết mã C # giống như C, nó sẽ xấu.

• Nếu tôi bắt gặp Haskell là một nhà phát triển Java, người đã buộc phải sử dụng Haskell, nhưng không muốn hiểu thế mạnh của nó và chỉ muốn sao chép các khái niệm về Java, mã tôi sẽ viết sẽ bị ảnh hưởng.

• Vân vân.

Không có gì sai khi cố gắng nâng cao ngôn ngữ (ví dụ: tăng cường C # bằng cách giới thiệu các đơn vị đo lường như trong F #), nhưng nếu bạn đang làm quá nhiều, bạn có thể nên chọn một ngôn ngữ khác thực sự phù hợp với nhu cầu của mình.

Bản thân việc giảm khả năng đọc là đủ một vấn đề: nó làm giảm đáng kể nhóm người có khả năng duy trì dự án của bạn mà không cần đào tạo chuyên sâu từ bạn.

Ngoài ra,

• Việc thực hiện mô hình nước ngoài có thể tốn kém hơn so với khoản tiết kiệm tiềm năng từ việc sử dụng nó
• Việc điều chỉnh chức năng nước ngoài của bạn có thể có lỗi, làm tăng chi phí bảo trì
• Việc bạn thích ứng với chức năng nước ngoài có thể đẩy công nghệ của bạn đến giới hạn vượt quá những yêu cầu mà việc triển khai nguyên gốc của bạn yêu cầu.

Nó không phải là ý tưởng tốt như nó xuất hiện trên giấy.

Ví dụ 1: Nếu bạn đủ tuổi, bạn có thể nhớ những ngày mà C là đứa trẻ mới ở thị trấn. Các lập trình viên Pascal và Ada không thích niềng răng mở và đóng của C. Họ #d xác định beginvà endđể mở nẹp và đóng nẹp, và voila! CAda! Kết quả không may là xấu từ quan điểm của Ada hoặc C.

Ví dụ 2, cá nhân: Một trong những điều tôi thực sự thích về Hệ thống đối tượng Lisp chung là các phương thức trước, sau và xung quanh. Họ có thể đến rất tiện dụng ở nhiều nơi. Vì vậy, tôi đã mô phỏng khái niệm này trong C ++ ở một vài nơi được chọn. Cách duy nhất để mô phỏng các cấu trúc này trong C ++ là yêu cầu nhà phát triển của lớp dẫn xuất gọi phương thức của lớp cha cùng tên ở đúng vị trí trong mã. Điều này đặt ra một yêu cầu đối với các nhà phát triển xuất phát từ các lớp của tôi hơi xa lạ với lập trình C ++ và có lẽ chống lại các chương trình lập trình C ++. Cho dù yêu cầu này được ghi chép tốt đến mức nào, mọi người vẫn không tuân theo các nguyên tắc vì nó không phù hợp với mô hình C ++.

Những vấn đề có thể phát sinh từ các khái niệm mô phỏng từ các ngôn ngữ khác?

Trừu tượng rò rỉ.

Nó có thể rất khó khăn. Hãy tưởng tượng bạn đang cố gắng triển khai LINQ từ C # vào ứng dụng Java của bạn. Hoặc làm thế nào về việc chỉ thêm các đóng cửa từ vựng vào một ngôn ngữ? Bạn sẽ phải viết một trình biên dịch mới, phần lớn cung cấp cho bạn một ngôn ngữ mới.

Hoặc, đối với trường hợp bạn không phải thực hiện ngôn ngữ của riêng mình, hãy tưởng tượng thử thực hiện các phương thức thu thập bằng các hàm bậc cao hơn (như bản đồ) bằng ngôn ngữ không có khối mã hoặc hàm lambda hoặc đóng hoặc hàm như trước đối tượng lớp. Mọi hàm bậc cao hơn phải được khai báo như một giao diện và được triển khai rõ ràng, và tất cả trạng thái sẽ bị bắt trong một bao đóng phải được lưu trữ rõ ràng trong lớp thực hiện. Nó rất nhiều gõ, và rất khó đọc, đến nỗi nó thường không đáng.