Điều gì là tốt hơn cho nguyên mẫu: một ngôn ngữ gõ tĩnh, hoặc một ngôn ngữ gõ động? [đóng cửa]

Khi thực hiện thiết kế cho một hệ thống mới, tốt hơn là bắt đầu với một ngôn ngữ được gõ tĩnh (như Haskell) hoặc ngôn ngữ được gõ động (như Ruby)?

Những lý lẽ tôi có thể nghĩ ra:

• Với một ngôn ngữ tĩnh, bạn có thể nhanh chóng tạo ra một đặc tả và phạm vi cho những gì chương trình sẽ làm. Với ngôn ngữ động, bạn có thể nhanh chóng tạo bản demo hoạt động để trình bày cho khách hàng xem xét.

• Với ngôn ngữ động, bạn thường tránh phải sắp xếp lại cấu trúc dữ liệu và mã cấu trúc lại khi bạn thay đổi thiết kế. Với một ngôn ngữ tĩnh, bạn có thể xác định các loại trước khi thực hiện, giữ cho mã duy trì rất nhỏ.

• Với một ngôn ngữ tĩnh, bạn phải tìm hiểu trước chương trình của bạn sẽ làm gì. Với ngôn ngữ động, bạn có thể bắt đầu viết mã và để thiết kế phát triển một cách hữu cơ. Như Paul Graham nói trong Hacker và Họa sĩ :

  Một ngôn ngữ lập trình là để nghĩ về các chương trình, không phải để diễn đạt các chương trình mà bạn đã nghĩ đến.

• Với một ngôn ngữ tĩnh, trình biên dịch có thể giúp xác định nhiều loại lỗi. Với ngôn ngữ động, bạn có thể bắt đầu thử nghiệm và tìm lỗi sớm hơn.

Gõ tĩnh và động đều có những ưu điểm và nhược điểm khi có liên quan đến tạo mẫu. Tuy nhiên, cả hai dường như đối với tôi như những cách tiếp cận hợp lệ như nhau. Dựa trên kinh nghiệm của bạn, cái nào cuối cùng tốt hơn?

Ghi chú

Tạo mẫu trong ngôn ngữ tự nhiên

Một loại ngôn ngữ thứ ba để xem xét: ngôn ngữ tự nhiên. Thay vì tạo mẫu trong mã, người ta có thể tạo nguyên mẫu bằng văn bản. Sau đó, khách hàng có thể đọc tài liệu của bạn và phê bình thiết kế của bạn, nhưng không thể chơi đồ chơi xung quanh với bản demo hoạt động. Nếu được viết tốt, tài liệu có thể thực hiện bằng bất kỳ ngôn ngữ nào. Hãy cẩn thận:

• Các tài liệu có thể tẻ nhạt để đọc qua, và khó tiêu hóa mà không thể nhìn thấy nó. Tôi suy đoán rằng một khách hàng thà thử nghiệm một cái gì đó hoạt động hơn là đọc một bức tường văn bản (và hình ảnh).

• Tạo mẫu một ứng dụng bằng tiếng Anh thay vì định nghĩa kiểu dài hơn và ít cụ thể hơn.

Các loại Haskell là mô tả

Lưu ý rằng các loại đặc biệt mô tả trong Haskell, nhiều hơn so với nhiều ngôn ngữ tĩnh như C ++ và Java. Ví dụ: giả sử tôi có một hàm có chữ ký loại này trong Haskell:

foo :: forall a. [a] -> a

Một hàm, đối với bất kỳ loại nào a, sẽ lấy danh sách các mục thuộc loại avà trả về giá trị của loại a.

Ngay cả khi không biết tên của hàm, tôi biết một sự thật rằng:

• Nó không thực hiện đầu vào / đầu ra hoặc sửa đổi bất kỳ giá trị nào (tốt, trừ khi nó sử dụng không an toànPerformIO không chính xác), bởi vì Haskell hoàn toàn là chức năng.

• Nó không thể xử lý các mục như, như, số nguyên, bởi vì nó phải hỗ trợ bất kỳ loại nào .

• Nó có để sử dụng danh sách đầu vào (đó, hoặc ném một ngoại lệ hoặc đi vào một vòng lặp vô hạn). Nếu không, nó sẽ nhận được một giá trị của loại atừ đâu?

Do đó, điều duy nhất mà chức năng này có thể làm (trừ thất bại) là trích xuất một mục ra khỏi danh sách đầu vào và trả lại. Mặc dù tôi vẫn không biết nó sẽ sử dụng vật phẩm nào, nhưng hãy [a] -> anói cho tôi biết về mọi thứ khác.

Tôi sẽ sát cánh cùng Paul Graham trong phần này: gõ động là hữu ích nhất để tạo các chương trình một cách hữu cơ, đó chính xác là những gì tạo mẫu nên có. Vấn đề là làm cho một cái gì đó được thực hiện nhanh chóng thể hiện chức năng của sản phẩm cuối cùng, chứ không phải chính sản phẩm cuối cùng. Gõ tĩnh là về tính chính xác chính xác, tốt, bề ngoài; ít nhất nó phải là (như trong Haskell hoặc Agda) kiểu gõ động củabbut là về tính chính xác thực tế, đó là điều quan trọng hơn khi bạn tạo mẫu.

Trong ngôn ngữ phù hợp, các gợi ý loại tĩnh có thể được cung cấp sau khi thực tế là tối ưu hóa (và để cung cấp thêm sự an toàn cho các thay đổi trong tương lai) hoặc nguyên mẫu có thể được viết lại bằng ngôn ngữ được nhập tĩnh khi các yêu cầu đã được làm rõ và củng cố bằng nguyên mẫu .

Tôi nghĩ rằng vấn đề kiểu tĩnh và động không quan trọng bằng nhiều người đưa ra.

1. Tôi sử dụng cả hai. Đôi khi một cái chỉ đơn giản là hữu ích hơn một cái khác trong một tình huống nhất định. Điều này thường xảy ra do cần phải sử dụng một số công cụ / thư viện / công nghệ cụ thể. Vì vậy, tôi đã chọn những gì hoạt động tốt với các thành phần khác mà tôi có.

2. Tôi nghĩ rằng một trong những điều mà mọi người thích về ngôn ngữ động là nhiều thứ được diễn giải; Bạn có thể sửa đổi chúng trong khi chúng đang chạy theo cách tương tác bằng bàn điều khiển REPL . Bất kỳ ngôn ngữ có chức năng eval hoặc một cái gì đó tương đương có thể làm điều này. Vì vậy, ít nhất là đối với khía cạnh này, hệ thống loại thực sự không liên quan.

3. Bạn có thể xây dựng các nguyên mẫu bằng cách sử dụng những thứ không có hệ thống loại chính thức như các kịch bản shell. (Họ có REPL mặc dù ...)

Làm những gì tốt nhất cho bạn và cho những gì bạn đang cố gắng làm. Tôi thấy rằng tôi hiện nguyên mẫu tốt nhất trong một ngôn ngữ tĩnh. Tạo mẫu với một hệ thống loại biểu cảm cho phép bạn thực hiện một số điều thú vị:

• Viết chữ ký hàm mà không thực hiện tương ứng. Mã Haskell giai đoạn đầu của tôi thường có các câu như:

  foo :: Foo -> Thanh
  foo _ = lỗi "không được xác định"

Điều này là bởi vì tôi muốn có một ý tưởng về những gì fookhi tôi viết mã sử dụng nó, mà không cần phải thực sự có một bản sao làm việc foo. Trong các ngôn ngữ khác, điều này được thực hiện với một cái gì đó như throw new Exception(), đó là điều bạn sẽ không bao giờ làm trong mã thực, nhưng giúp rất nhiều ở giai đoạn đầu.

• Viết mã mà không cần viết các loại đầu tiên và sử dụng suy luận kiểu để tìm hiểu những điều về mã của bạn. Tôi thường gọi :tcho GHCi (Haskell REPL) để khám phá những gì tôi vừa viết. Ví dụ, điều này có thể cho bạn biết mức độ chung của một đoạn mã, do đó tiết lộ các yêu cầu của các đoạn mã khác nhau và cấu trúc tương ứng.

Conal Elliot đã mô tả quan điểm của mình về Haskell để giúp phát triển iPhone theo cách này:

"Một khi tôi đang viết Haskell, bộ máy cấp bách mờ dần khỏi tầm nhìn và tôi không thể không bắt đầu nhìn thấy những mẫu thiết yếu. Việc nghĩ đến những mẫu đó đã đưa tôi đến những hiểu biết mới ... gõ tĩnh như một công cụ suy nghĩ, để giúp tôi hiểu rõ hơn và loại bỏ những sai lầm của mình. Đó là một phần thưởng cho tôi rằng ngôn ngữ cũng có thể thực thi được. " Nguồn

Đúng rồi. Một trong những vị thần của lập trình chức năng nghĩ rằng giá trị chính của Haskell là ngôn ngữ mô hình hóa, thay vì ngôn ngữ thực hiện. Các guru khác nghĩ những điều tương tự: Erik Meijer sử dụng Haskell để giúp làm rõ đại số cơ bản và các mẫu cuối cùng đi vào các khung hướng đối tượng.

Lý do quan trọng nhất mặc dù tạo mẫu bằng một ngôn ngữ nghiêm ngặt, đó là phần lớn thời gian những thứ người ta muốn "nguyên mẫu" không phải là các ứng dụng web giai đoạn đầu tiện lợi mà Paul Graham muốn tài trợ. Thường thì bạn cần tạo nguyên mẫu:

1. Mở rộng cơ sở hạ tầng hiện tại
2. API cho một ngôn ngữ cụ thể
3. Kiến trúc, không chỉ là các tính năng mới

Trong mỗi trường hợp này, bạn thực sự muốn sử dụng một ngôn ngữ gần với ngôn ngữ thực hiện cuối cùng theo những cách có ý nghĩa.

Mặc dù vậy

 foo :: forall a. [a] -> a

không có "chính xác" (luôn chấm dứt mà không tạo ra lỗi hoặc undefined). Đó là vì

[] :: forall a. [a]

Nhưng không có chức năng từ []để acó thể tồn tại cho arằng không có trường hợp.

Bạn có nghĩa là nguyên mẫu tính năng hoặc thiết kế ?

Các nguyên mẫu tính năng là về việc hiển thị một tính năng cho khách hàng trước khi bắt đầu phát triển tính năng đó từ đầu bằng ngôn ngữ triển khai cuối cùng, vì vậy vấn đề là viết tính năng đó càng nhanh càng tốt mà không cần lo lắng về lỗi hoặc khả năng bảo trì. Các ngôn ngữ động cho phép đánh đổi năng suất chính xác bằng cách cho phép các bản hack xấu xí mà không có ngôn ngữ gõ tĩnh nào chấp nhận, theo lý thuyết, chúng phù hợp hơn để viết các nguyên mẫu nhanh chóng. Tất nhiên, trong thực tế, kỹ năng của nhà phát triển quan trọng hơn ngôn ngữ, nhưng một lập trình viên có kỹ năng tương đương với cả Haskell và Ruby có thể sẽ tạo ra một nguyên mẫu nhanh hơn trong Ruby và mã kết quả sẽ là một mớ hỗn độn.

Các nguyên mẫu thiết kế là về việc tìm kiếm một thiết kế chương trình phù hợp thông qua thử và lỗi. Hack xấu xí là vô dụng - chỉ có khả năng tái cấu trúc thiết kế nhanh chóng có vấn đề. Một yêu cầu cơ bản cho tái cấu trúc lớn là một bộ các bài kiểm tra tự động. Trong các ngôn ngữ động, đây thường là một bộ các bài kiểm tra đơn vị do nhà phát triển viết, cần một khoảng thời gian hợp lý để viết. Trong các ngôn ngữ được nhập tĩnh, chữ ký loại đóng vai trò kiểm tra tự động và cho phép trình biên dịch phát hiện bất kỳ sự không nhất quán nào gây ra bởi thay đổi mã. Các ngôn ngữ gõ tĩnh tỏa sáng khi tái cấu trúc theo những cách mà không ngôn ngữ gõ động nào có thể đạt được.

Năng động, đặc biệt nếu bạn biết rằng sản phẩm thực tế sẽ phải ở một trong một số ngôn ngữ tĩnh phổ biến để đủ nhanh để giải quyết vấn đề thực sự trong tự nhiên. Làm điều này sẽ tự động bảo vệ bạn khỏi sai lầm khi sử dụng nguyên mẫu làm sản phẩm cuối cùng.

Bất cứ ngôn ngữ nào mà bạn quen thuộc nhất.

Động và tĩnh thực sự không quan trọng. Chức năng so với OO thực sự không quan trọng. Phù hợp nhất, tính năng hoặc bất cứ điều gì chúng thường là vô nghĩa.

Điểm duy nhất của tạo mẫu là tốc độ thực hiện (viết mã) vì bạn cần thay đổi chương trình rất nhiều. Và bạn nên nhanh nhất với ngôn ngữ tốt nhất của bạn.

Nếu bạn có hai ngôn ngữ tốt nhất ở cả động và tĩnh, tôi sẽ đặt cược vào ngôn ngữ tĩnh. Bởi vì một tĩnh thường có thể xử lý sự phức tạp, trong khi một số động bị lỗi tại một số điểm. Và không ai thực sự biết nguyên mẫu lớn sẽ lớn lên như thế nào.