Các ngôn ngữ được nhập động và tĩnh cho các trang web [đã đóng]

Tuyên bố này cho thấy rằng các ngôn ngữ được nhập tĩnh không lý tưởng cho các trang web:

Tôi sẽ tương phản với việc xây dựng một trang web. Khi kết xuất trang web, thường thì bạn có rất nhiều thành phần tương tác trên một trang web. Bạn có các nút ở đây và các vật dụng nhỏ ở đó và có hàng tá trong số chúng trên một trang web, cũng như có thể hàng chục hoặc hàng trăm trang web trên trang web của bạn hoàn toàn động. Với một hệ thống có diện tích bề mặt thực sự lớn như thế, sử dụng ngôn ngữ gõ tĩnh thực sự khá không linh hoạt. Tôi sẽ cảm thấy đau đớn khi lập trình trong Scala và kết xuất một trang web với nó, khi tôi muốn tương tác ấn xung quanh các nút và không. Nếu toàn bộ hệ thống phải mạch lạc, giống như toàn bộ hệ thống phải gõ kiểm tra chỉ để có thể di chuyển một nút xung quanh, tôi nghĩ rằng điều đó có thể thực sự không linh hoạt.

^{Nguồn: http://www.infoq.com/interviews/kallen-scala-twitter}

Điều này có đúng không? Tại sao hay tại sao không?

Tôi hoàn toàn không đồng ý. Khi các hệ thống phát triển lớn hơn, các ngôn ngữ gõ tĩnh đảm bảo sự mạnh mẽ ở cấp độ thành phần và do đó linh hoạt ở cấp hệ thống.

Ngoài ra, ví dụ được đưa ra bởi tác giả không thực sự có ý nghĩa. Có vẻ như anh chàng này không biết rằng đa hình có thể đạt được bằng các cách khác ngoài gõ vịt.

Có một số người cho rằng các ngôn ngữ động là vượt trội, nhưng điều đó thường dựa trên sự thiếu kinh nghiệm của họ với các hệ thống loại biểu cảm, ví dụ như hỗ trợ phân nhóm cấu trúc, các kiểu dữ liệu đại số và các hàm bậc nhất.

Trước hết, hãy nhớ rằng tác giả của tuyên bố trên đang nói về phát triển trang web. Vì vậy, anh ấy lo lắng về sự phát triển của bài thuyết trình , và đó là nơi anh ấy nghĩ Scala sẽ không phải là một lựa chọn tốt ...

Phải nói rằng, tôi có một kinh nghiệm tốt về phát triển web. Tôi đã làm việc ít nhất 8 năm với nó, 5 trong số đó trong các cơ quan kỹ thuật số.

Và, vâng, theo kinh nghiệm của tôi, một ngôn ngữ được biên dịch tĩnh, được biên dịch ở lớp trình bày có thể là một trở ngại lớn. Nội dung cần được thay đổi liên tục, thường xuyên hơn nhiều so với yêu cầu kinh doanh. Và thông thường, điều này cần được thực hiện bởi một nhóm riêng biệt (các nhà phát triển "front-end"). Họ thường biết rất nhiều về HTML, JavaScript, tiêu chuẩn web, CSS, nhưng không biết nhiều về các ngôn ngữ phía máy chủ như Java và C #. Họ cũng cho rằng bất kỳ loại thay đổi nào trong mẫu đều có sẵn ngay lập tức ; chúng không được sử dụng để biên dịch và gõ lỗi. Và họ đã đúng: các ngôn ngữ gõ tĩnh rất tốt cho các yêu cầu khó, phức tạp, như truy cập dữ liệu và quy tắc kinh doanh, nhưng không tốt cho phát triển giao diện.

Trên thực tế, đó là một trong những lợi ích chính của việc sử dụng ngôn ngữ mẫu chuyên biệt và được diễn giải như Velocity . Nó dễ sử dụng, sức mạnh và tính linh hoạt là đủ cho các nhà phát triển lớp trình bày. Và sau đó những kẻ ở phía máy chủ có thể tự do sử dụng một ngôn ngữ được gõ tĩnh, nghiêm túc ở mọi nơi khác ...

Tuy nhiên, tôi cũng đồng ý rằng Scala có phần khác biệt. Đồng thời ít dài dòng và biểu cảm hơn nhiều so với Java, tôi tin rằng nó có thể được sử dụng để phát triển bản trình bày - vì vậy có lẽ nó có thể được sử dụng thành công như một ngôn ngữ mẫu. Và nếu nó cũng có thể được kết hợp với một khung như Play (sẽ biên dịch trang web một cách tự động sau mỗi thay đổi), thì đó có thể là một IMHO chiến thắng. Tuy nhiên, ngay cả Play cũng đã chọn ngôn ngữ mẫu giống như Groovy (động), đây không phải là một dấu hiệu tốt.

Tóm lại: vấn đề với Scala liên quan nhiều hơn đến thực tế là nó được biên dịch. Trong thực tế cơ chế suy luận kiểu của nó làm cho bạn gần như quên nó cũng là tĩnh đánh máy.

(Và xin lỗi về tiếng Anh của tôi. Hãy cho tôi biết nếu có gì đó không rõ ràng, tôi sẽ cố gắng sửa nó.)

Tôi nghĩ rằng văn bản (và hầu hết các câu trả lời) đang trộn lẫn các ngôn ngữ được gõ tĩnh và các ngôn ngữ dài dòng quá mức . Tất nhiên, giao lộ là rất lớn (đặc biệt khi chỉ xem xét các ngôn ngữ chính thống nhất); nhưng có một số ví dụ thú vị về các ngôn ngữ không dài dòng, gõ tĩnh: Go, Haskell, Scala, Rust mộc

Tôi khuyến khích bạn đọc Đánh máy mạnh của Bruce Eckel so với Kiểm tra mạnh . Đối số chính của nó là chất lượng phần mềm hoàn toàn có thể kiểm tra. Bạn có thể kiểm tra theo nhiều cách khác nhau. Trình biên dịch kiểm tra một số thứ tại thời gian biên dịch: cố gắng lưu trữ một chuỗi trong một biến int và nó có thể sẽ sủa vào bạn. Trong các ngôn ngữ động, rất nhiều thử nghiệm xảy ra trong thời gian chạy. Cuối cùng, nó không thành vấn đề khi thử nghiệm xảy ra. Nó chỉ phải xảy ra. Thời gian bạn đạt được không biên dịch bằng ngôn ngữ động là mất kiểm tra khi chạy. Bạn mạnh mẽ kiểm tra mọi thứ, phải không?

Cho rằng, một ưu tiên cho các ngôn ngữ được biên dịch với các hệ thống loại cứng so với các ngôn ngữ động chỉ là điều đó - một ưu tiên. Kiểu như võ sĩ so với quần đùi hoặc quần so với quần lót Pháp. Không có câu trả lời đúng hay sai. Mặc chúng với thái độ đúng đắn và chỉ có tuyệt vời.

Tôi đồng ý với điều đó trong hầu hết các trường hợp, bởi vì hãy đối mặt với nó, khi bạn giao dịch với khách hàng trên một biểu đồ web, tính linh hoạt là điều bắt buộc.

Các ngôn ngữ được nhập tĩnh sẽ mạnh mẽ hơn và an toàn hơn so với ngôn ngữ được gõ một cách ngẫu nhiên, nhưng khi bạn bắt đầu điều chỉnh mã để hành động theo cách không có nghĩa và bạn cần nó nhanh, các giải pháp có vẻ phức tạp và cứng nhắc.

Vì vậy, nếu bạn có sự thay đổi để hợp nhất các công nghệ, tôi khuyên bạn nên tạo lõi bằng ngôn ngữ được nhập tĩnh (lõi không thay đổi nhiều) và sử dụng một cách ngẫu nhiên cho tương tác người dùng.

Tôi nghĩ rằng tác giả của bài viết này đã không nhìn vào Scala mình. Mặc dù tôi đồng ý rằng Java và C # có những hạn chế và hơi không linh hoạt để phát triển web, Scala là một ngôn ngữ được gõ tĩnh hoàn toàn khác với những gì bạn thường nghĩ khi nghe thấy điều đó. Scala cho phép gõ vịt cũng như một phiên bản vá khỉ an toàn (Thông qua chuyển đổi ngầm). Điều đó làm cho các thư viện lập trình phức tạp hơn một chút vì bạn sẽ phải suy nghĩ về các loại, nhưng nếu bạn chỉ sử dụng một thư viện như Nâng thì cảm giác rất giống ngôn ngữ động ngoại trừ trình biên dịch sẽ thông báo cho bạn về các lỗi rõ ràng mà bạn không sử dụng đúng. Cá nhân tôi nghĩ rằng khung web nâng không phải trốn khỏi ruby ​​trên đường ray hoặc tương tự. Hãy xem các ví dụ mã ở đây hoặc ở đâyvà tự quyết định. Bây giờ tôi đã phát triển thang máy và chưa bao giờ gặp phải tình huống tôi gặp lỗi loại và mặc dù "Ah anh bạn, nếu điều này là năng động thì nó sẽ hoạt động" ... bởi vì nếu nó là động thì nó sẽ không nói với tôi rằng có một lỗi cho đến khi nó bị lỗi trong thời gian chạy.

Cá nhân tôi nghĩ rằng những gì họ nói là đúng với bất kỳ hệ thống nào, không chỉ trang web. Bạn sẽ cần gõ tĩnh khi bạn nói chuyện với phần cứng, vì mọi thứ khác, gõ động đều có những nhược điểm và lợi ích giống nhau cho dù bạn làm gì, thực sự, và điều gì là tốt nhất phụ thuộc vào sở thích và các vấn đề cụ thể cho từng dự án.

Thực hành Trả lời nhanh: Nó phụ thuộc vào kích thước và độ phức tạp của kích thước web. Trang web nhỏ, progr năng động. lang., Complex trang web lớn, progr tĩnh. lang.

Câu trả lời nhàm chán mở rộng: Nhiều nhà phát triển nhấn mạnh rằng một trang web nên được thực hiện với một chương trình động. langr. nhưng sự thật là, cuối cùng, các công cụ phát triển web có xu hướng sử dụng hoặc mô phỏng các ngôn ngữ gõ tĩnh.

Tôi đã làm việc với PHP nhiều lần và sớm hay muộn, chúng tôi đã phải thêm rất nhiều mã để xác minh các loại dữ liệu đã cho, được ẩn trong một progr gõ tĩnh. lang.

Đánh máy Lagn. cũng giúp sử dụng IDE (s), yêu cầu nhiều xác minh loại.

(được cung cấp bởi progr. & trình thiết kế trình biên dịch của bạn ;-))

Tôi đồng ý. Khi tôi nhìn vào hầu hết mã C # front-end web, có rất nhiều lần truyền từ chuỗi và tuần tự hóa dữ liệu thành chuỗi. Về cơ bản, HTTP là một giao thức phù hợp với các ngôn ngữ động.