Tôi đã dành năm ngoái để phát triển một công cụ trò chơi thương mại ở Haskell, và đối với chúng tôi, trải nghiệm này cực kỳ tích cực. Thế giới trò chơi của chúng tôi rất phức tạp và Haskell đã giúp dễ dàng mô hình hóa quá trình chuyển đổi từ định dạng trình chỉnh sửa sang định dạng công cụ trò chơi. Tôi ghét phải nghĩ rằng mã đó sẽ trông như thế nào trong một ngôn ngữ bắt buộc.
Rò rỉ không gian đã xuất hiện và đôi khi chúng gây ra một chút rắc rối, trong sơ đồ chung, nó chỉ là một lượng nhỏ (ví dụ như so với việc tìm kiếm các bế tắc trong các dự án Java có kích thước tương tự) và một khi chúng đã được sửa , họ ở lại cố định.
Chúng tôi đang sử dụng FRP tương tự như Yampa và chắc chắn có một đường cong học tập liên quan đến nó, nhưng một khi đã kết thúc, trải nghiệm này rất tích cực. Thư viện không phải là vấn đề đối với chúng tôi - mọi thứ chúng tôi cần đều có sẵn. Sự chậm trễ thu gom rác là một vấn đề cụ thể vì nó là một nền tảng nhúng. Chúng tôi đã sử dụng một số C ++ để quản lý hoạt hình. Hiệu suất cũng là một vấn đề với việc đây là một nền tảng nhúng (= bộ xử lý chậm). Chúng tôi đã thực hiện một số C và chúng tôi cũng đang xem xét các công nghệ Haskell mới nổi như tăng tốc. Trình hoạt hình C ++ là một quyết định thiết kế từ rất sớm và những nơi mà mã quá chậm chỉ là những khu vực rất nhỏ. Về lâu dài, chúng tôi muốn dịch tất cả từ C sang Haskell.
Haskell đã làm cho một công việc khó khăn trở nên dễ dàng và tất cả những khó khăn tôi vừa đề cập là rất nhỏ so với số lượng lớn mã phức tạp chúng tôi đã tạo ra sạch sẽ, có thể bảo trì và khá nhiều không thể phá vỡ. Song song sẽ là một vấn đề trong phát triển trò chơi rất sớm, và chúng tôi rất hợp để giải quyết nó. Một số điều tôi đã nói có thể không áp dụng cho các dự án nhỏ, bởi vì chúng tôi đang ở đây trong một thời gian dài, vì vậy chi phí khởi nghiệp như học đường cong, hỗ trợ thư viện, v.v., ít vấn đề hơn.