8 tháng dùng OCaml sau 8 năm dùng Haskell trong production (2023)

 (chshersh.com)
1 điểm bởi GN⁺ 2024-12-04 | Chưa có bình luận nào. | Chia sẻ qua WhatsApp
  • Một lập trình viên so sánh cảm nhận phát triển thực tế của hai ngôn ngữ hàm dựa trên kinh nghiệm dùng Haskell 8 năm và OCaml 8 tháng trong production
  • Haskell cung cấp cú pháp cô đọng hơn và các tính năng kiểu dữ liệu mạnh mẽ, nhưng vì có quá nhiều lựa chọn nên dễ bị phân tâm vào thiết kế và trừu tượng hóa
  • OCaml dù có ít tính năng hơn nhưng được đánh giá là dễ tập trung vào việc triển khai nhờ first-class modules, tính mutable thực dụng và phong cách mã dễ đoán
  • Hệ sinh thái của Haskell lớn hơn, nhưng việc chọn thư viện đôi khi giống như một kỹ năng riêng; còn OCaml dù nhỏ hơn nhưng các công cụ cần thiết lại hoạt động tốt hơn mong đợi
  • Cả hai ngôn ngữ đều nhỏ hơn các ngôn ngữ chủ lưu và thư viện chuẩn đều gần mức tối thiểu, nhưng nếu không phụ thuộc nặng vào một SDK cụ thể thì vẫn hoàn toàn đủ dùng để phát triển ứng dụng công nghiệp

Điểm xuất phát của phép so sánh

  • Tiêu chí dựa trên kinh nghiệm dùng Haskell 8 năm và OCaml 8 tháng trong production
  • Các trục so sánh là cú pháp, tính năng ngôn ngữ, hệ sinh thái, công cụ, thông báo trình biên dịch và thư viện chuẩn
  • Cả hai ngôn ngữ đều đã phát triển đủ để hỗ trợ các yêu cầu công nghiệp thực tế, nhưng hiện tại mức độ ưa thích nghiêng về OCaml hơn

Cú pháp: Haskell cô đọng hơn, còn OCaml cũng có ưu điểm của họ ML

  • Haskell có thể biểu đạt ý tưởng bằng rất ít ký tự nên đem lại cảm giác thanh nhã rõ rệt về mặt cú pháp
  • OCaml cũng là một ngôn ngữ thuộc họ ML rất xuất sắc, nhưng Haskell cung cấp phong cách ngầm định (tacit) nhiều hơn
  • Trong ví dụ cộng tổng các số trong chuỗi, Haskell diễn đạt ngắn gọn bằng sum . map read . words, còn OCaml dùng pipeline để tường minh các bước tách chuỗi, chuyển đổi và gấp
  • Ví dụ định nghĩa kiểu cây nhị phân cho thấy cả hai ngôn ngữ đều biểu đạt algebraic data types một cách tự nhiên
  • Ví dụ parsing cho thấy cả hai đều dùng pattern matching và giá trị option, nhưng Haskell dùng ký pháp do và guard, còn OCaml dùng Option.bind và match tường minh

Tính năng: Haskell phong phú hơn, OCaml ít gây xao nhãng hơn

  • Haskell có số lượng tính năng rất lớn, đến mức cảm giác như C++ mới là đối tượng so sánh phù hợp
  • Nhiều tính năng là công cụ để giải quyết vấn đề một cách tinh vi, nhưng cũng có thể khiến người ta phải băn khoăn về chính cách thiết kế lời giải trước khi bắt tay vào triển khai
  • Trong Haskell, rất dễ sa vào việc cân nhắc giữa các lựa chọn như TypeFamilies, DataKinds, GADTs
  • Tình trạng xấu trong một dự án OCaml có sẵn thường chỉ là tên biến kém, thiếu tài liệu, hoặc các hàm dài hơn 200 dòng, tức vẫn ở mức có thể xử lý được
  • Ngược lại, trong một dự án Haskell có sẵn, ngay cả với 8 năm kinh nghiệm vẫn có thể gặp mức độ phức tạp khó mà chuẩn bị trước được
  • Vì khác biệt này nên cảm giác làm việc hiệu quả trong OCaml cao hơn

  • Các tính năng hai ngôn ngữ cùng chia sẻ

    • Cả hai đều cung cấp cú pháp hướng biểu thức, bất biến mặc định, hàm bậc cao, hàm ẩn danh, algebraic data types và pattern matching
    • Cả hai cũng đều có đa hình tham số, suy luận kiểu, cú pháp đường cho monad, garbage collector, multithreading và GADTs

  • Các tính năng nổi bật hơn ở phía Haskell

    • Haskell có tính thuần khiết mặc định, lazy evaluation có thể kết hợp, type classes, higher-kinded types và các mở rộng ngôn ngữ tùy chọn
    • Vì sở hữu nhiều tính năng mạnh nên cách trừu tượng hóa có thể khác biệt rất lớn giữa các dự án

  • Các tính năng nổi bật hơn ở phía OCaml

    • OCaml có first-class modules, polymorphic variants, object, class và inheritance, cùng với khả năng mutable dễ dùng
    • Dải tính năng hẹp hơn Haskell, nhưng đổi lại codebase dễ đoán hơn

Hệ sinh thái: Haskell lớn hơn, OCaml vẫn có các lời giải cần thiết

  • Cả hai đều là các ngôn ngữ lập trình hàm ngách nên khó kỳ vọng được hỗ trợ hạng nhất từ các framework mới nhất
  • Dù vậy, phần lớn các tác vụ phổ biến vẫn có lời giải, và trong một số trường hợp chỉ cần tự viết thêm binding
  • Trong OCaml vẫn có thể tìm được các package phục vụ công việc thực tế như sau
  • Hệ sinh thái Haskell có nhiều package và lời giải dùng ngay hơn
  • Thư viện client cho Stripe API có 13 thư viện ở Haskell, còn OCaml chỉ có 1, mà phía OCaml lần cập nhật cuối đã từ 8 năm trước nên gần như có thể xem là 0
  • Trong Haskell, sau khi tìm ra lời giải vẫn còn phải quyết định nên chọn thư viện nào giữa quá nhiều lựa chọn
  • Việc chọn thư viện được xem gần như một kỹ năng riêng đến mức còn có bài viết tổng hợp cách đánh giá thư viện
  • Nhiều thư viện Haskell mới xuất hiện không phải để giải quyết vấn đề khác, mà vì muốn viết lại theo một kiểu trừu tượng khác hoặc với tính năng mới
  • Việc thiết kế logger bằng comonads có thể trở nên hấp dẫn hơn cả chuyện tạo client GitHub API và parsing nhiều JSON

Công cụ: Haskell mạnh mẽ nhưng thất thường, còn OCaml thì hoạt động tốt

  • Công cụ của Haskell vừa có ưu điểm mạnh mẽ vừa tồn tại vấn đề về khả năng sử dụng
  • Hoogle là công cụ rất mạnh cho phép tìm kiếm toàn bộ hệ sinh thái chỉ bằng type signature
  • Ngược lại vẫn có các vấn đề như thông báo lỗi từ build tool, tình huống không tìm ra build plan ngay trong dự án đang hoạt động, IDE phải biên dịch lại sau khi thay package, hay thiếu tài liệu cho thư viện chuẩn của một số phiên bản cụ thể
  • Trải nghiệm dùng công cụ Haskell vừa có những lúc ngạc nhiên không hiểu các ngôn ngữ khác làm sao dùng được nếu thiếu những công cụ như vậy, vừa có lúc ngạc nhiên không hiểu người dùng Haskell sống chung ra sao với những thiếu sót lớn về usability
  • OCaml có hệ sinh thái nhỏ hơn nên mỗi lần thấy một thứ hoạt động tốt lại gây bất ngờ
  • Plugin VSCode OCaml dựa trên LSP hoạt động mà không cần tinh chỉnh riêng và không gặp vấn đề gì
  • Dù trải nghiệm bắt đầu với công cụ OCaml chưa phải dễ chịu nhất có thể, nó vẫn trực quan, chắc chắn và trong đa số trường hợp hoạt động đúng

  • So sánh công cụ

Thông báo trình biên dịch: Haskell dài dòng, OCaml ngắn gọn

  • Trong ngôn ngữ hàm, trình biên dịch là công cụ cốt lõi để hiểu vì sao đoạn mã không thỏa mãn những giả định mà người viết dự định
  • Vì vậy, thông báo lỗi cần hiển thị thông tin cần thiết theo cách dễ tiếp cận
  • Thông báo của trình biên dịch Haskell thường có nhiều ngữ cảnh, dài dòng và có xu hướng chứa thông tin lặp lại hoặc gây xao nhãng
  • Thông báo của trình biên dịch OCaml khá ngắn gọn, đôi khi quá ngắn gọn
  • Chương trình lỗi ví dụ là đoạn mã cố cộng một số nguyên với một danh sách, như x = 1 + [3, 1, 2] trong Haskell và let x = 1 + [3; 1; 2] trong OCaml

Thư viện chuẩn: cả hai đều tối giản, nhưng chất lượng tài liệu của Haskell nổi bật hơn

  • Thư viện chuẩn định hình trải nghiệm từ chương trình đầu tiên đến quá trình sử dụng lâu dài của một ngôn ngữ
  • Một thư viện chuẩn tốt là nền tảng cho thành công của ngôn ngữ lập trình, còn thư viện chuẩn thiếu hụt có thể kéo dài mãi các cuộc tranh luận về thư viện chuẩn thay thế
  • Quan điểm ở đây là thư viện chuẩn lý tưởng nên gần với kiểu batteries-included
  • Thành phần mong muốn bao gồm kiểu tương tự Option, chuỗi UTF-8, Map và HashMap, parser JSON và XML, cùng các primitive bất đồng bộ
  • Nếu không muốn phải học cách triển khai build tool và dependency tracker thì thư viện chuẩn cần có nhiều chức năng hơn
  • Build Systems a la Carte là tài liệu phân tích lĩnh vực dependency tracker và build tool
  • Cả Haskell lẫn OCaml đều có thư viện chuẩn tương đối tối thiểu
    • Haskell không bao gồm Map và HashMap
    • OCaml không có non-empty lists và Bitraversable
  • Thư viện chuẩn của Haskell là base, còn OCaml dùng OCaml standard library
  • Chất lượng tài liệu của Haskell đôi khi tốt đến mức ngay cả lập trình viên giàu kinh nghiệm cũng thấy ngạc nhiên
  • Tài liệu Haskell còn có những ưu điểm như chức năng nhảy tới source code, và tác giả nói rằng đã nghe OCaml cũng đang chuẩn bị tính năng tương tự

  • Ví dụ tài liệu

    • Ví dụ tài liệu List của Haskell
    • Ví dụ tài liệu List của OCaml
    • Ngay cả với các hàm có kết quả hiển nhiên, tài liệu thiên về ví dụ vẫn giúp nắm nhanh cách sử dụng API

Kết luận: cả hai đều dùng được cho công nghiệp, nhưng hiện tại ưu tiên là OCaml

  • Cả hai ngôn ngữ đều đã phát triển rất nhiều để đáp ứng các nhu cầu công nghiệp thực tế
  • So với các ngôn ngữ chủ lưu, chúng vẫn thuộc nhóm ngôn ngữ nhỏ
  • Nếu không phụ thuộc sống còn vào sự hiện diện của một SDK cụ thể, chọn ngôn ngữ nào trong hai ngôn ngữ này cũng có thể giúp bạn phát triển ứng dụng tiếp theo một cách hứng thú
  • Ở thời điểm hiện tại, OCaml được đánh giá là dễ tập trung hơn vào việc thực sự tạo ra thứ gì đó

Bài viết liên quan

Chưa có bình luận nào.

Chưa có bình luận nào.