Có nhiệm vụ nào yêu cầu công việc với Ruby ít hơn đáng kể so với C # 4.0 không?

Tôi vừa đọc xong chương Ruby của cuốn sách 7 Ngôn ngữ trong 7 tuần . Ngoài một số cú pháp cú pháp ở đây và ở đó tôi thực sự không thể thấy bất cứ điều gì không thể được thực hiện với C # với một cú pháp tương tự. Tôi hiểu cả hai ngôn ngữ vốn đã khác nhau, nhưng câu hỏi của tôi liên quan đến việc sử dụng nó hơn là thiết kế.

Các câu hỏi liên quan khiến tôi tin rằng Ruby cung cấp ít hơn C #:

• Tại sao các lập trình viên c # không thích ruby ​​như các lập trình viên java?
• Khối mã của Ruby có giống với biểu thức lambda của C # không?

Tôi hầu như không làm việc với Ruby và sự hiểu biết về ngôn ngữ của tôi vẫn còn rất hạn chế, vì vậy có lẽ ai đó đã thử nghiệm cả .NET 4.0 và Ruby có thể trả lời bằng các ví dụ cụ thể.

Những tác vụ nào yêu cầu công việc với Ruby ít hơn đáng kể so với C # 4.0?

Ps: Câu hỏi này đã bị đóng trên StackOverflow vì quá chủ quan và lập luận, mặc dù nó đã thu hút một số sự chú ý. Tôi đã hy vọng nó sẽ được hợp nhất vào đây, nhưng thay vào đó tôi sẽ phải đăng lại nó.

Ruby có nghĩa đen cho Biểu thức chính quy và một loạt các phím tắt cú pháp hữu ích để tạo / nội suy chuỗi. Vì vậy, khi (các) tác vụ của bạn chủ yếu liên quan đến việc trộn một bit và chuỗi chuỗi phù hợp, Ruby có thể yêu cầu công việc ít hơn đáng kể (nhưng bên ngoài các tập lệnh trợ giúp ngắn, tôi phải thừa nhận rằng tôi thấy đây là một tình huống rất hiếm).

Liên quan hơn là các cơ sở lập trình meta của Ruby. ví dụ #eval, #define_methodvà bạn bè, trong đó kết hợp với open classes, #includevà #extendcho phép bạn tạo tấn mã soạn sẵn tại thời gian chạy - bạn có thể tranh luận, rằng máy phát điện mã / trình thuật sĩ cung cấp cho bạn một số lợi ích như nhau, nhưng bạn phải sống với - có thể là một lượng rất lớn - của mã tấm nồi hơi được tạo ra, so với một lượng mã lập trình meta tương đối nhỏ mà bạn phải đọc và hiểu.

Một trường hợp sử dụng điển hình cho việc này là, phải giao tiếp với một số loại nhà cung cấp dữ liệu động bên ngoài ứng dụng của bạn. Rails ActiveRecord là một ví dụ tốt cho điều đó.

Trong tương lai, điều này có thể rất có lợi cho việc phát triển GUI, vì bạn có thể tạo các phương thức xử lý các sự kiện từ các thành phần giao diện người dùng bằng cách tạo các phương thức trong thời gian chạy dựa trên ID thành phần UI, loại, giá trị đầu vào, v.v. (như Objective-C trên steroid, có thể chúng ta sẽ thấy một phần sức mạnh này khi MacRuby đáo hạn).

Ranh giới giữa việc sử dụng tốt và lạm dụng khủng khiếp tính năng này mặc dù rất rất mỏng và có xu hướng - từ kinh nghiệm của tôi - là nguyên nhân chính gây đau đầu trong các dự án lớn của Ruby (trên Rails). Vì vậy, hãy cẩn thận khi bạn quyết định phát hành Djinn từ chai của nó :)