Mọi người thấy điều gì hấp dẫn về ngôn ngữ động? [đóng cửa]

Có vẻ như mọi người đang nhảy vào một nhóm nhạc năng động, không biên soạn gần đây. Tôi hầu như chỉ làm việc với các ngôn ngữ đã biên dịch, được gõ tĩnh (C, Java, .Net). Kinh nghiệm tôi có với các ngôn ngữ động là những thứ như ASP (Vb Script), JavaScript và PHP. Việc sử dụng những công nghệ này khiến tôi cảm thấy khó chịu khi nghĩ về các ngôn ngữ động. Những thứ mà trình biên dịch thường mắc phải như tên biến sai chính tả và gán giá trị không đúng kiểu cho một biến sẽ không xảy ra cho đến thời gian chạy. Và thậm chí sau đó, bạn có thể không nhận thấy lỗi, vì nó chỉ tạo một biến mới và gán một số giá trị mặc định. Tôi cũng chưa bao giờ thấy intellisense hoạt động tốt trong một ngôn ngữ động, vì các biến không có bất kỳ kiểu rõ ràng nào.

Điều tôi muốn biết là, những gì mọi người thấy hấp dẫn về các ngôn ngữ động? Những lợi thế chính về những thứ mà ngôn ngữ động cho phép bạn làm mà không thể làm được hoặc khó thực hiện trong ngôn ngữ biên dịch. Đối với tôi, dường như chúng tôi đã quyết định từ lâu, rằng những thứ như các trang asp không được biên dịch ném các ngoại lệ thời gian chạy là một ý tưởng tồi. Tại sao lại có sự trỗi dậy của loại mã này? Và tại sao với tôi, ít ra thì Ruby on Rails không thực sự giống bất cứ thứ gì bạn không thể làm với ASP 10 năm trước?

Tôi nghĩ lý do là mọi người đã quen với các ngôn ngữ được gõ tĩnh có hệ thống kiểu rất hạn chế và không thể diễn đạt. Đây là các ngôn ngữ như Java, C ++, Pascal, v.v. Thay vì đi theo hướng hệ thống kiểu biểu cảm hơn và suy luận kiểu tốt hơn, (ví dụ như trong Haskell và thậm chí là SQL ở một mức độ nào đó), một số người chỉ muốn giữ tất cả thông tin "loại" trong đầu họ (và trong các bài kiểm tra của họ) và loại bỏ hoàn toàn việc đánh máy tĩnh.

Điều này mua cho bạn những gì cuối cùng là không rõ ràng. Có rất nhiều quan niệm sai lầm về việc đánh máy, những quan niệm mà tôi thường gặp nhất là hai quan niệm này.

Ngụy biện: Các ngôn ngữ động ít dài dòng hơn. Quan niệm sai lầm là thông tin kiểu tương đương với chú thích kiểu. Điều này là hoàn toàn sai sự thật. Tất cả chúng ta đều biết rằng kiểu chú thích là khó chịu. Máy sẽ có thể tìm ra những thứ đó. Và trên thực tế, nó có trong các trình biên dịch hiện đại. Đây là QuickSort được nhập tĩnh trong hai dòng Haskell (từ haskell.org ):

qsort []     = []
qsort (x:xs) = qsort (filter (< x) xs) ++ [x] ++ qsort (filter (>= x) xs)

Và đây là QuickSort được nhập động trong LISP (từ swisspig.net ):

(defun quicksort (lis) (if (null lis) nil
  (let* ((x (car lis)) (r (cdr lis)) (fn (lambda (a) (< a x))))
    (append (quicksort (remove-if-not fn r)) (list x)
      (quicksort (remove-if fn r))))))

Ví dụ Haskell làm sai giả thuyết được nhập tĩnh, do đó dài dòng . Ví dụ LISP làm sai lệch độ dài của giả thuyết , do đó được nhập tĩnh . Không có hàm ý theo cả hai hướng giữa việc nhập và độ dài. Bạn có thể bỏ điều đó ra khỏi tâm trí một cách an toàn.

Sai lầm: Các ngôn ngữ được nhập tĩnh phải được biên dịch, không được thông dịch. Một lần nữa, không đúng. Nhiều ngôn ngữ được gõ tĩnh có thông dịch viên. Có trình thông dịch Scala, trình thông dịch GHCi và Hugs cho Haskell, và tất nhiên SQL đã được nhập và thông dịch tĩnh lâu hơn tôi còn sống.

Bạn biết đấy, có thể đám đông năng động chỉ muốn tự do để không phải suy nghĩ kỹ càng về những gì họ đang làm. Phần mềm có thể không chính xác hoặc không mạnh mẽ, nhưng có thể nó không cần thiết.

Cá nhân tôi nghĩ rằng những người sẽ từ bỏ kiểu an toàn để mua một chút tự do tạm thời, không xứng đáng với sự tự do cũng như kiểu an toàn.

Đừng quên rằng bạn cần viết phạm vi mã 10x trong các bài kiểm tra đơn vị để thay thế những gì trình biên dịch của bạn làm: D

Tôi đã ở đó, làm điều đó với các ngôn ngữ động, và tôi hoàn toàn không thấy lợi thế.

Khi đọc câu trả lời của người khác, có vẻ như có ít hơn ba đối số cho các ngôn ngữ động:

1) Mã ít dài dòng hơn. Tôi không thấy điều này hợp lệ. Một số ngôn ngữ động ít dài dòng hơn một số ngôn ngữ tĩnh. Nhưng F # được nhập tĩnh, nhưng cách nhập tĩnh ở đó không bổ sung nhiều, nếu có, mã. Tuy nhiên, nó được đánh máy ngầm, nhưng đó là một điều khác biệt.

2) "Ngôn ngữ động yêu thích của tôi X có tính năng chức năng yêu thích của tôi là Y, do đó động tốt hơn". Đừng trộn lẫn chức năng và động (tôi không hiểu tại sao phải nói điều này).

3) Trong các ngôn ngữ động, bạn có thể thấy kết quả của mình ngay lập tức. Tin tức: Bạn cũng có thể làm điều đó với C # trong Visual Studio (từ năm 2005). Chỉ cần đặt một điểm ngắt, chạy chương trình trong trình gỡ lỗi và sửa đổi chương trình trong khi gỡ lỗi. Tôi làm điều này mọi lúc và nó hoạt động hoàn hảo.

Bản thân tôi, tôi là một người ủng hộ mạnh mẽ cho việc nhập tĩnh, vì một lý do chính: khả năng bảo trì. Tôi có một hệ thống với vài 10k dòng JavaScript trong đó và bất kỳ quá trình tái cấu trúc nào tôi muốn thực hiện sẽ mất nửa ngày vì trình biên dịch (không tồn tại) sẽ không cho tôi biết việc đổi tên biến đó đã gây ra lỗi gì. Và đó là mã do tôi tự viết, IMO cũng có cấu trúc tốt. Tôi sẽ không muốn nhiệm vụ được giao phụ trách một hệ thống động tương đương mà người khác đã viết.

Tôi đoán tôi sẽ bị bỏ phiếu đồng loạt vì điều này, nhưng tôi sẽ nắm lấy cơ hội.

VBScript thật tệ, trừ khi bạn đang so sánh nó với một hương vị khác của VB. PHP là được, miễn là bạn lưu ý rằng đó là một ngôn ngữ tạo khuôn mẫu phát triển quá mức. Javascript hiện đại là tuyệt vời. Có thật không. Rất vui vẻ. Chỉ cần tránh xa bất kỳ tập lệnh nào được gắn thẻ "DHTML".

Tôi chưa bao giờ sử dụng một ngôn ngữ không cho phép lỗi thời gian chạy. IMHO, đó phần lớn là một con cá trích đỏ: các trình biên dịch không bắt được tất cả các lỗi chính tả, cũng như không xác nhận ý định. Nhập rõ ràng là tuyệt vời khi bạn cần các loại rõ ràng, nhưng hầu hết thời gian, bạn không. Tìm kiếm các câu hỏi tại đây genericshoặc câu hỏi về việc sử dụng các loại không dấu có phải là một lựa chọn tốt cho các biến chỉ mục hay không - phần lớn thời gian, nội dung này chỉ cản trở và giúp mọi người có thể xoay sở khi họ có thời gian. .

Nhưng, tôi chưa thực sự trả lời câu hỏi của bạn. Tại sao ngôn ngữ động lại hấp dẫn? Bởi vì sau một thời gian, việc viết mã trở nên buồn tẻ và bạn chỉ muốn triển khai thuật toán. Bạn đã ngồi và làm việc tất cả bằng bút, lập sơ đồ các tình huống vấn đề tiềm ẩn và chứng minh chúng có thể giải quyết được, và điều duy nhất còn lại cần làm là viết mã cho hai mươi dòng thực hiện ... và hai trăm dòng bảng soạn sẵn để biên dịch . Sau đó, bạn nhận ra rằng hệ thống kiểu bạn làm việc không phản ánh những gì bạn thực sự đang làm, mà là ý tưởng cực kỳ trừu tượng của người khác về những gì bạn có thể đang làm, và bạn đã từ bỏ lập trình từ lâu để sống một cuộc đời tinh chỉnh. ám ảnh cưỡng chế rằng nó sẽ xấu hổ ngay cả thám tử hư cấu Adrian Monk.

Đó là khi bạn đi được dán bắt đầu tìm cách nghiêm túc ở các ngôn ngữ động.

Tôi là một lập trình viên .Net toàn thời gian hoàn toàn thích thú với C # được gõ tĩnh. Tuy nhiên, tôi yêu thích JavaScript hiện đại.

Nói chung, tôi nghĩ các ngôn ngữ động cho phép bạn thể hiện ý định của mình ngắn gọn hơn so với các ngôn ngữ được nhập tĩnh vì bạn dành ít thời gian và không gian hơn để xác định các khối xây dựng của những gì bạn đang cố gắng diễn đạt khi trong nhiều trường hợp, chúng tự hiển nhiên.

Tôi nghĩ rằng cũng có nhiều lớp ngôn ngữ động. Tôi không muốn quay lại viết các trang ASP cổ điển trong VBScript. Để trở nên hữu ích, tôi nghĩ rằng một ngôn ngữ động cần phải hỗ trợ một số loại tập hợp, danh sách hoặc cấu trúc kết hợp ở cốt lõi của nó để các đối tượng (hoặc những gì chuyển cho các đối tượng) có thể được thể hiện và cho phép bạn xây dựng các cấu trúc phức tạp hơn. (Có lẽ tất cả chúng ta chỉ nên viết mã trong LISP ... đó là một trò đùa ...)

Tôi nghĩ rằng trong vòng kết nối .Net, các ngôn ngữ động có một đoạn rap tệ vì chúng được liên kết với VBScript và / hoặc JavaScript. VBScript chỉ là một cơn ác mộng được nhớ lại vì nhiều lý do mà Kibbee đã nêu - bất kỳ ai cũng nhớ thực thi loại trong VBScript bằng cách sử dụng CLng để đảm bảo bạn có đủ bit cho một số nguyên 32 bit. Ngoài ra, tôi nghĩ JavaScript vẫn được xem là ngôn ngữ trình duyệt cho các menu thả xuống được viết theo một cách khác cho tất cả các trình duyệt. Trong trường hợp đó, vấn đề không phải là ngôn ngữ, mà là các mô hình đối tượng trình duyệt khác nhau. Điều thú vị là C # càng trưởng thành, nó càng trở nên năng động hơn. Tôi thích biểu thức Lambda, các đối tượng ẩn danh và kiểu suy luận. Nó giống như JavaScript hàng ngày.

Đây là QuickSort được nhập tĩnh trong hai dòng Haskell (từ haskell.org):

qsort []     = []
qsort (x:xs) = qsort (filter (< x) xs) ++ [x] ++ qsort (filter (>= x) xs)

Và đây là QuickSort được nhập động trong LISP (từ swisspig.net):

(defun quicksort (lis) (if (null lis) nil
  (let* ((x (car lis)) (r (cdr lis)) (fn (lambda (a) (< a x))))
    (append (quicksort (remove-if-not fn r)) (list x)
      (quicksort (remove-if fn r))))))

Tôi nghĩ rằng bạn đang thiên vị mọi thứ với lựa chọn ngôn ngữ của bạn ở đây. Lisp nổi tiếng là nặng về dấu ngoặc kép. Một tương đương gần hơn với Haskell sẽ là Python.

if len(L) <= 1: return L
return qsort([lt for lt in L[1:] if lt < L[0]]) + [L[0]] + qsort([ge for ge in L[1:] if ge >= L[0]])

Mã Python từ đây

Đối với tôi, lợi thế của ngôn ngữ động là mã trở nên dễ đọc hơn nhiều do ít mã và kỹ thuật chức năng hơn như khối của Ruby và khả năng hiểu danh sách của Python.

Nhưng sau đó tôi loại bỏ việc kiểm tra thời gian biên dịch (lỗi đánh máy xảy ra) và tự động hoàn thành IDE. Nhìn chung, số lượng mã và khả năng đọc ít hơn sẽ mang lại lợi ích cho tôi.

Một ưu điểm khác là tính chất thường được thông dịch / không biên dịch của ngôn ngữ. Thay đổi một số mã và xem kết quả ngay lập tức. Nó thực sự tiết kiệm thời gian trong quá trình phát triển.

Cuối cùng nhưng không kém phần quan trọng, tôi thích thực tế là bạn có thể khởi động một bảng điều khiển và thử một thứ gì đó mà bạn không chắc chắn, chẳng hạn như một lớp hoặc phương thức mà bạn chưa bao giờ sử dụng trước đây và xem nó hoạt động như thế nào. Có rất nhiều cách sử dụng cho bảng điều khiển và tôi sẽ chỉ để bạn tìm hiểu.

Lập luận của bạn chống lại các ngôn ngữ động là hoàn toàn hợp lệ. Tuy nhiên, hãy xem xét những điều sau:

1. Các ngôn ngữ động không cần phải được biên dịch : chỉ cần chạy chúng. Bạn thậm chí có thể tải lại các tệp tại thời điểm chạy mà không cần khởi động lại ứng dụng trong hầu hết các trường hợp.
2. Các ngôn ngữ động thường ít dài dòng hơn và dễ đọc hơn : bạn đã bao giờ nhìn vào một thuật toán hoặc chương trình nhất định được triển khai bằng ngôn ngữ tĩnh, sau đó so sánh nó với Ruby hoặc Python tương đương chưa? Nói chung, bạn đang xem xét việc giảm các dòng mã theo hệ số 3. Rất nhiều mã giàn giáo là không cần thiết trong các ngôn ngữ động và điều đó có nghĩa là kết quả cuối cùng dễ đọc hơn và tập trung hơn vào vấn đề thực tế đang diễn ra.
3. Đừng lo lắng về vấn đề nhập : phương pháp chung khi lập trình bằng ngôn ngữ động là không lo lắng về việc nhập: hầu hết thời gian, loại đối số phù hợp sẽ được chuyển cho các phương thức của bạn. Và thỉnh thoảng, ai đó có thể sử dụng một kiểu lập luận khác cũng có hiệu quả. Khi có sự cố, chương trình của bạn có thể bị dừng, nhưng điều này hiếm khi xảy ra nếu bạn đã thực hiện một vài thử nghiệm.

Tôi cũng thấy hơi sợ khi bước ra khỏi thế giới an toàn của việc nhập tĩnh lúc đầu, nhưng đối với tôi những lợi thế vượt xa những bất lợi và tôi chưa bao giờ nhìn lại.

Tôi tin rằng "tình yêu mới được tìm thấy" đối với các ngôn ngữ được gõ động ít liên quan đến việc liệu các ngôn ngữ được nhập tĩnh là tốt hơn hay tệ nhất - theo nghĩa tuyệt đối - hơn là sự gia tăng phổ biến của một số ngôn ngữ động nhất định . Ruby on Rails rõ ràng là một hiện tượng lớn gây ra sự hồi sinh của các ngôn ngữ động. Điều khiến rails trở nên phổ biến và tạo ra rất nhiều chuyển đổi từ trại tĩnh chủ yếu là: mã và cấu hình rất ngắn gọn và KHÔ. Điều này đặc biệt đúng khi so sánh với các khuôn khổ web Java đòi hỏi hàng núi cấu hình XML. Nhiều lập trình viên Java - những người thông minh - cũng đã chuyển đổi, và một số thậm chí còn truyền bá ruby ​​và các ngôn ngữ động khác. Đối với tôi, ba tính năng khác biệt cho phép các ngôn ngữ động như Ruby hoặc Python trở nên ngắn gọn hơn:

1. Cú pháp tối giản - điều quan trọng là loại chú thích không bắt buộc, nhưng nhà thiết kế ngôn ngữ cũng thiết kế ngôn ngữ ngay từ đầu để ngắn gọn
2. cú pháp hàm nội tuyến (hoặc lambda) - khả năng viết các hàm nội tuyến và chuyển chúng xung quanh dưới dạng biến làm cho nhiều loại mã ngắn gọn hơn. Đặc biệt, điều này đúng với các hoạt động danh sách / mảng. Nguồn gốc của những ý tưởng này rõ ràng là - LISP.
3. Siêu lập trình - siêu lập trình là một phần quan trọng của những gì làm cho đường ray đánh dấu. Nó đã tạo ra một cách cấu trúc lại mã mới cho phép mã khách hàng trong thư viện của bạn ngắn gọn hơn nhiều. Điều này cũng bắt nguồn từ LISP.

Cả ba tính năng này không dành riêng cho các ngôn ngữ động, nhưng chắc chắn chúng không có trong các ngôn ngữ tĩnh phổ biến ngày nay: Java và C #. Bạn có thể tranh luận rằng C # có # 2 trong các đại biểu, nhưng tôi sẽ tranh luận rằng nó không được sử dụng rộng rãi - chẳng hạn như với các phép toán danh sách.

Đối với các ngôn ngữ tĩnh nâng cao hơn ... Haskell là một ngôn ngữ tuyệt vời, nó có # 1 và # 2, và mặc dù nó không có # 3, nhưng hệ thống kiểu của nó rất linh hoạt nên có thể bạn sẽ không thấy thiếu meta để được giới hạn. Tôi tin rằng bạn có thể thực hiện lập trình ẩn trong OCaml tại thời điểm biên dịch với phần mở rộng ngôn ngữ. Scala là sự bổ sung gần đây và rất hứa hẹn. F # cho trại .NET. Tuy nhiên, người dùng các ngôn ngữ này chỉ chiếm thiểu số, và vì vậy họ không thực sự đóng góp vào sự thay đổi này trong bối cảnh ngôn ngữ lập trình. Trên thực tế, tôi rất tin rằng sự phổ biến của Ruby đã ảnh hưởng đến sự phổ biến của các ngôn ngữ như Haskell, OCaml, Scala và F # theo một cách tích cực, bên cạnh các ngôn ngữ động khác.

Cá nhân tôi nghĩ rằng hầu hết các ngôn ngữ "động" mà bạn đã sử dụng chỉ là những ví dụ kém về ngôn ngữ nói chung.

Tôi cách hiệu quả hơn bằng Python hơn trong C hoặc Java, và không chỉ bởi vì bạn phải làm điệu nhảy chỉnh sửa-biên dịch-link-chạy. Tôi đang làm việc hiệu quả hơn trong Objective-C, nhưng điều đó có lẽ nhiều hơn do khuôn khổ.

Không cần phải nói, tôi sử dụng bất kỳ ngôn ngữ nào trong số những ngôn ngữ này hiệu quả hơn PHP. Chết tiệt, tôi thích viết mã trong Scheme hoặc Prolog hơn là PHP. (Nhưng gần đây tôi thực sự làm Prolog nhiều hơn bất cứ điều gì khác, vì vậy hãy coi đó là một hạt muối!)

Sự đánh giá cao của tôi đối với các ngôn ngữ động gắn liền với chức năng của chúng. Khả năng hiểu danh sách của Python, các bao đóng của Ruby và các đối tượng nguyên mẫu của JavaScript đều là những khía cạnh rất hấp dẫn của các ngôn ngữ đó. Tất cả đều có các chức năng hạng nhất - thứ mà tôi không thể nhìn thấy nếu sống mãi.

Tôi sẽ không phân loại PHP và VB (script) theo cùng một cách. Đối với tôi, đó hầu hết là những ngôn ngữ bắt buộc với tất cả các nhược điểm của kiểu gõ động mà bạn đề xuất.

Chắc chắn, bạn không nhận được cùng một mức độ kiểm tra thời gian biên dịch (vì không có thời gian biên dịch), nhưng tôi hy vọng các công cụ kiểm tra cú pháp tĩnh sẽ phát triển theo thời gian để giải quyết ít nhất một phần vấn đề đó.

Một trong những lợi thế được chỉ ra cho các ngôn ngữ động là chỉ có thể thay đổi mã và tiếp tục chạy. Không cần biên dịch lại. Trong VS.Net 2008, khi gỡ lỗi, bạn thực sự có thể thay đổi mã và tiếp tục chạy mà không cần biên dịch lại. Với những tiến bộ trong trình biên dịch và IDE, có thể điều này và những lợi thế khác của việc sử dụng ngôn ngữ động sẽ không còn nữa.

À, tôi không thấy chủ đề này khi tôi đăng câu hỏi tương tự

Ngoài các tính năng tốt, những người còn lại được đề cập ở đây về ngôn ngữ động, tôi nghĩ rằng mọi người đều quên một điều cơ bản nhất: lập trình ẩn.

Lập trình chương trình.

Nói chung, nó khá khó thực hiện trong các ngôn ngữ biên dịch, lấy ví dụ như .Net. Để làm cho nó hoạt động, bạn phải tạo tất cả các loại mambo jumbo và nó thường kết thúc với mã chạy chậm hơn khoảng 100 lần.

Hầu hết các ngôn ngữ động đều có cách thực hiện lập trình siêu ứng dụng và đó là thứ giúp tôi ở đó - khả năng tạo bất kỳ loại mã nào trong bộ nhớ và tích hợp hoàn hảo nó vào ứng dụng của tôi.

Ví dụ: để tạo máy tính trong Lua, tất cả những gì tôi phải làm là:

print( loadstring( "return " .. io.read() )() )

Bây giờ, hãy thử làm điều đó trong .Net.

Lý do chính của tôi để thích các ngôn ngữ động (được đánh máy, vì đó dường như là trọng tâm của chuỗi) là những ngôn ngữ tôi đã sử dụng (trong môi trường làm việc) vượt trội hơn nhiều so với các ngôn ngữ không động mà tôi đã sử dụng. C, C ++, Java, v.v ... chúng đều là những ngôn ngữ khủng khiếp để hoàn thành công việc thực tế. Tôi rất muốn thấy một ngôn ngữ được gõ ngầm có thể lập trình với càng nhiều ngôn ngữ được gõ động.

Điều đó đang được nói, có một số cấu trúc tuyệt vời trong các ngôn ngữ được nhập động. Ví dụ, trong Tcl

 lindex $mylist end-2

Việc bạn chuyển vào "end-2" để chỉ ra chỉ mục bạn muốn là cực kỳ ngắn gọn và rõ ràng đối với người đọc. Tôi vẫn chưa thấy một ngôn ngữ được nhập tĩnh nào thực hiện được như vậy.

Tôi nghĩ rằng kiểu lập luận này hơi ngu ngốc: "Những thứ thường sẽ bị trình biên dịch bắt giữ như tên biến sai chính tả và gán giá trị không đúng kiểu cho một biến sẽ không xảy ra cho đến khi chạy" vâng điều đó đúng như một Nhà phát triển PHP Tôi không thấy những thứ như biến bị gõ nhầm cho đến khi chạy, NHƯNG thời gian chạy là bước 2 đối với tôi, trong C ++ (là ngôn ngữ biên dịch duy nhất mà tôi có kinh nghiệm) đó là bước 3, sau khi liên kết và biên dịch.

Chưa kể rằng phải mất tất cả vài giây sau khi tôi nhấn lưu đến khi mã của tôi sẵn sàng chạy, không giống như trong các ngôn ngữ đã biên dịch, nơi có thể mất hàng giờ đồng hồ. Tôi xin lỗi nếu điều này nghe có vẻ hơi tức giận, nhưng tôi thực sự mệt mỏi với việc mọi người coi tôi như một lập trình viên hạng hai vì tôi không phải biên dịch mã của mình.

Lập luận phức tạp hơn điều này (đọc bài báo của Yegge "Đánh máy yếu là đủ mạnh" để có cái nhìn tổng quan thú vị).

Các ngôn ngữ động cũng không nhất thiết phải thiếu kiểm tra lỗi - suy luận kiểu của C # có thể là một ví dụ. Theo cách tương tự, C và C ++ có các kiểm tra biên dịch khủng khiếp và chúng được nhập tĩnh.

Ưu điểm chính của ngôn ngữ động là a) khả năng (không nhất thiết phải sử dụng mọi lúc) và b) Định luật lặp lại của Boyd .

Lý do thứ hai là rất lớn.

Mặc dù tôi không phải là một fan hâm mộ lớn của Ruby, nhưng tôi thấy các ngôn ngữ động là những công cụ thực sự tuyệt vời và mạnh mẽ.

Ý tưởng rằng không có kiểm tra kiểu và khai báo biến thực sự không phải là một vấn đề quá lớn. Phải thừa nhận rằng bạn không thể bắt gặp những lỗi này cho đến thời gian chạy, nhưng đối với các nhà phát triển có kinh nghiệm thì đây không thực sự là một vấn đề và khi bạn mắc lỗi, chúng thường dễ dàng được sửa.

Nó cũng buộc những người mới làm quen đọc những gì họ đang viết cẩn thận hơn. Tôi biết việc học PHP đã dạy tôi chú ý hơn đến những gì tôi thực sự đang gõ, điều này đã cải thiện khả năng lập trình của tôi ngay cả trong các ngôn ngữ biên dịch.

Các IDE tốt sẽ cung cấp đủ intellisense để bạn biết liệu một biến đã được "khai báo" hay chưa và chúng cũng cố gắng thực hiện một số suy luận kiểu cho bạn để bạn có thể biết biến là gì.

Sức mạnh của những gì có thể được thực hiện với các ngôn ngữ động thực sự là điều khiến họ rất vui khi làm việc theo quan điểm của tôi. Chắc chắn, bạn có thể làm những điều tương tự bằng một ngôn ngữ biên dịch, nhưng sẽ mất nhiều mã hơn. Các ngôn ngữ như Python và PHP cho phép bạn phát triển trong thời gian ngắn hơn và nhận được cơ sở mã chức năng nhanh hơn hầu hết thời gian.

Và để lưu ý, tôi là nhà phát triển .NET toàn thời gian và tôi thích các ngôn ngữ đã biên dịch. Tôi chỉ sử dụng các ngôn ngữ động trong thời gian rảnh để tìm hiểu thêm về chúng và hoàn thiện bản thân hơn với tư cách là nhà phát triển ..

Tôi nghĩ rằng chúng ta cần các loại ngôn ngữ khác nhau tùy thuộc vào những gì chúng ta đang cố gắng đạt được hoặc giải quyết chúng. Nếu chúng ta muốn một ứng dụng tạo, truy xuất, cập nhật và xóa các bản ghi khỏi cơ sở dữ liệu qua internet, chúng ta nên làm điều đó với một dòng mã ROR (sử dụng khung) hơn là viết nó từ đầu bằng ngôn ngữ nhập tĩnh. Sử dụng các ngôn ngữ động giúp giải phóng tâm trí khỏi băn khoăn về

• biến nào có kiểu nào
• cách phát triển một chuỗi động khi cần
• cách viết mã để nếu tôi thay đổi kiểu của một biến, tôi không phải viết lại tất cả hàm tương tác với nó

cho những vấn đề gần gũi hơn với nhu cầu kinh doanh như

• dữ liệu đang lưu / cập nhật, v.v. trong cơ sở dữ liệu, làm cách nào để sử dụng nó để thúc đẩy lưu lượng truy cập vào trang web của tôi

Dù sao, một lợi thế của các ngôn ngữ được đánh máy lỏng lẻo là chúng ta không thực sự quan tâm nó là kiểu gì, nếu nó hoạt động như những gì nó được cho là. Đó là lý do tại sao chúng tôi có tính năng gõ vịt trong các ngôn ngữ được nhập động. đó là một tính năng tuyệt vời và tôi có thể sử dụng các tên biến giống nhau để lưu trữ các loại dữ liệu khác nhau khi có nhu cầu. Ngoài ra, các ngôn ngữ được nhập tĩnh buộc bạn phải suy nghĩ như một cái máy (trình biên dịch tương tác với mã của bạn như thế nào, v.v.) trong khi các ngôn ngữ được nhập động, đặc biệt là ruby ​​/ ror, buộc máy phải suy nghĩ như con người.

Đây là một số lý lẽ tôi sử dụng để biện minh cho công việc và kinh nghiệm của mình trong các ngôn ngữ động!

Tôi nghĩ rằng cả hai phong cách đều có thế mạnh của họ. Theo quan điểm của tôi, suy nghĩ này đang làm tê liệt cộng đồng của chúng ta. Tôi đã làm việc trong các kiến ​​trúc được nhập tĩnh từ trên xuống dưới và nó ổn. Kiến trúc yêu thích của tôi dành cho kiểu gõ động ở cấp giao diện người dùng và gõ tĩnh ở cấp chức năng. Điều này cũng khuyến khích rào cản ngôn ngữ thực thi sự tách biệt giữa giao diện người dùng và chức năng.

Để trở thành một người hay hoài nghi, có thể đơn giản là các ngôn ngữ động cho phép nhà phát triển lười biếng hơn và hoàn thành công việc khi biết ít hơn về các nguyên tắc cơ bản của máy tính. Điều này là tốt hay xấu là tùy thuộc vào người đọc :)

FWIW, Việc biên dịch trên hầu hết các ứng dụng sẽ không mất nhiều giờ. Tôi đã làm việc với các ứng dụng từ 200-500k dòng mất vài phút để biên dịch. Chắc chắn không phải giờ.

Bản thân tôi thích các ngôn ngữ biên dịch hơn. Tôi cảm thấy như thể các công cụ gỡ lỗi (theo kinh nghiệm của tôi, có thể không đúng với mọi thứ) tốt hơn và các công cụ IDE tốt hơn.

Tôi muốn có thể đính kèm Visual Studio của mình vào một tiến trình đang chạy. Các IDE khác có thể làm được điều đó không? Có thể, nhưng tôi không biết về chúng. Tôi đã làm một số công việc phát triển PHP gần đây và thành thật mà nói, nó không phải là quá tệ. Tuy nhiên, tôi thích C # và VS IDE hơn. Tôi cảm thấy như tôi làm việc nhanh hơn và gỡ lỗi các sự cố nhanh hơn.

Vì vậy, có lẽ nó là một thứ của bộ công cụ đối với tôi hơn là vấn đề ngôn ngữ động / tĩnh?

Một nhận xét cuối cùng ... nếu bạn đang phát triển với lưu máy chủ cục bộ sẽ nhanh hơn biên dịch, nhưng thường thì tôi không có quyền truy cập vào mọi thứ trên máy cục bộ của mình. Cơ sở dữ liệu và chia sẻ tệp ở nơi khác. Sẽ dễ dàng hơn khi FTP vào máy chủ web và sau đó chạy mã PHP của tôi chỉ để tìm ra lỗi và phải sửa và ftp lại.

Năng suất trong một bối cảnh nhất định. Nhưng đó chỉ là một môi trường tôi biết, so với một số môi trường khác mà tôi biết hoặc đã thấy sử dụng.

Smalltalk trên Squeak / Pharo với Seaside là một nền tảng web hiệu quả và hiệu quả hơn nhiều so với ASP.Net (/ MVC), RoR hoặc Wicket, cho các ứng dụng phức tạp. Cho đến khi bạn cần giao diện với thứ gì đó có thư viện ở một trong những thứ đó nhưng không phải smalltalk.

Các tên biến sai chính tả có màu đỏ trong IDE, IntelliSense hoạt động nhưng không cụ thể. Lỗi thời gian chạy trên các trang web không phải là một vấn đề mà là một tính năng, một cú nhấp chuột để hiển thị trình gỡ lỗi, một cú nhấp chuột vào IDE của tôi, sửa lỗi trong trình gỡ lỗi, lưu, tiếp tục. Đối với các lỗi đơn giản, thời gian khứ hồi cho chu kỳ này là dưới 20 giây.

Ngôn ngữ động Đình công

http://www.youtube.com/watch?v=tz-Bb-D6teE

Một bài nói chuyện thảo luận về Ngôn ngữ động, một số mặt tích cực là gì và bao nhiêu mặt tiêu cực không thực sự đúng.

Bởi vì tôi cho là ngu ngốc khi phải khai báo loại hộp. Loại ở với thực thể, không ở với vùng chứa. Nhập tĩnh có ý nghĩa khi loại hộp có hệ quả trực tiếp đến cách các bit trong bộ nhớ được diễn giải.

Nếu bạn nhìn vào các mẫu thiết kế trong GoF, bạn sẽ nhận ra rằng một phần tốt của chúng ở đó chỉ để đấu tranh với bản chất tĩnh của ngôn ngữ và chúng không có lý do gì để tồn tại trong một ngôn ngữ động.

Ngoài ra, tôi cảm thấy mệt mỏi khi phải viết những thứ như MyFancyObjectInterface f = new MyFancyObject (). Nguyên tắc DRY ai?

Hãy đặt mình vào vị trí của một lập trình viên hoàn toàn mới đang chọn ngôn ngữ để bắt đầu, người không quan tâm đến động so với staic so với lambdas so với điều này so với điều đó, v.v.; bạn sẽ chọn ngôn ngữ nào?

C #

using System;
class MyProgram
{
    public static void Main(string[] args)
    {
        foreach (string s in args)
        {
            Console.WriteLine(s);
        }
    }
}

Lua:

function printStuff(args)
    for key,value in pairs(args) do
       print value .. " "
    end
end
strings = {
    "hello",
    "world",
    "from lua"
}
printStuff(strings)

Tất cả điều này phụ thuộc vào một phần những gì phù hợp với các mục tiêu cụ thể và sở thích cá nhân chung là gì. (EG Đây sẽ là một cơ sở mã khổng lồ được duy trì bởi nhiều người hơn là có thể tiến hành một cuộc họp hợp lý cùng nhau? Bạn muốn kiểm tra kiểu.)

Phần cá nhân là về việc loại bỏ một số kiểm tra và các bước khác để phát triển và tốc độ kiểm tra (trong khi có thể làm giảm một số hiệu suất của cpu). Có một số người cho rằng điều này là giải phóng và tăng hiệu suất, và có một số người cho rằng điều này hoàn toàn ngược lại, và vâng nó cũng phụ thuộc vào hương vị cụ thể của ngôn ngữ của bạn. Ý tôi là không ai ở đây nói rằng Java là đá để phát triển nhanh chóng, nhanh chóng hoặc PHP là một ngôn ngữ vững chắc mà bạn sẽ hiếm khi mắc lỗi đánh máy khó phát hiện.

Tôi yêu cả ngôn ngữ tĩnh và ngôn ngữ động. Mọi dự án mà tôi đã tham gia kể từ khoảng năm 2002 đều là ứng dụng C / C ++ với phiên dịch Python nhúng. Điều này mang lại cho tôi điều tốt nhất của cả hai thế giới:

1. Các thành phần và khuôn khổ tạo nên ứng dụng, đối với một bản phát hành ứng dụng nhất định, là bất biến. Chúng cũng phải rất ổn định và do đó, được kiểm tra tốt. Ngôn ngữ được gõ tĩnh là lựa chọn phù hợp để xây dựng các phần này.
2. Việc kết nối các thành phần, tải các tệp DLL thành phần, tác phẩm nghệ thuật, hầu hết các GUI, v.v. có thể khác nhau rất nhiều (ví dụ, để tùy chỉnh ứng dụng cho máy khách) mà không cần thay đổi bất kỳ khung hoặc mã thành phần nào. Một ngôn ngữ động là hoàn hảo cho việc này.

Tôi thấy rằng sự kết hợp giữa ngôn ngữ nhập tĩnh để xây dựng hệ thống và ngôn ngữ nhập động để định cấu hình nó mang lại cho tôi sự linh hoạt, ổn định và năng suất.

Để trả lời câu hỏi "Tình yêu với ngôn ngữ động là gì?" Đối với tôi, đó là khả năng nối lại hoàn toàn một hệ thống trong thời gian chạy theo bất kỳ cách nào có thể tưởng tượng được. Tôi thấy ngôn ngữ kịch bản là "chạy chương trình", do đó ứng dụng thực thi có thể làm bất cứ điều gì bạn muốn.

Tôi không có nhiều kinh nghiệm với các ngôn ngữ động nói chung, nhưng một ngôn ngữ động mà tôi biết, JavaScript (hay còn gọi là ECMAScript), tôi vô cùng yêu thích.

Chờ đã, cuộc thảo luận ở đây là gì? Biên dịch động? Hay gõ động? JavaScript bao gồm cả hai cơ sở vì vậy tôi đoán tôi sẽ nói về cả hai:

Biên dịch động :

Để bắt đầu, các ngôn ngữ động được biên dịch, việc biên dịch chỉ đơn giản là tạm dừng cho đến sau này. Và Java và .NET thực sự được biên dịch hai lần. Một lần đối với các ngôn ngữ trung gian tương ứng của chúng và một lần nữa, động, đối với mã máy.

Nhưng khi quá trình biên dịch tạm dừng, bạn có thể thấy kết quả nhanh hơn. Đó là một lợi thế. Tôi thích chỉ cần lưu tệp và thấy chương trình của tôi hoạt động khá nhanh chóng.

Một ưu điểm khác là bạn có thể viết và biên dịch mã trong thời gian chạy . Liệu điều này có thể xảy ra trong mã được biên dịch tĩnh hay không, tôi không biết. Tôi tưởng tượng nó phải như vậy, vì bất cứ thứ gì biên dịch JavaScript cuối cùng đều là mã máy và được biên dịch tĩnh. Nhưng trong một ngôn ngữ động, đây là một việc nhỏ cần làm. Mã có thể tự viết và chạy. (Và tôi khá chắc rằng .NET có thể làm điều này, nhưng CIL mà .NET biên dịch thành luôn được biên dịch động nhanh chóng và nó không quá tầm thường trong C #)

Nhập động :

Tôi nghĩ rằng gõ động biểu cảm hơn gõ tĩnh. Lưu ý rằng tôi đang sử dụng thuật ngữ biểu cảm một cách không chính thức để nói rằng nhập động có thể nói nhiều hơn với ít hơn. Đây là một số mã JavaScript:

var Person = {};

Bạn có biết Người bây giờ là gì không? Đó là một từ điển chung. Tôi có thể làm điều này:

Person ["First_Name"] = "John";
Person ["Last_Name"] = "Smith";

Nhưng nó cũng là một đối tượng. Tôi có thể tham khảo bất kỳ "chìa khóa" nào như thế này:

Person.First_Name

Và thêm bất kỳ phương pháp nào tôi cho là cần thiết:

Person.changeFirstName = function (newName) {
  this.First_Name = newName;
}

Chắc chắn, có thể có vấn đề nếu newName không phải là một chuỗi. Nó sẽ không bị bắt ngay lập tức, nếu có, nhưng bạn có thể tự kiểm tra. Đó là vấn đề giao dịch sức mạnh thể hiện và sự linh hoạt để an toàn. Tôi không ngại thêm mã để kiểm tra các loại, v.v., và bản thân tôi vẫn chưa gặp phải lỗi loại nào khiến tôi đau buồn nhiều (và tôi biết điều đó không nói nhiều. Có thể là vấn đề thời gian: )). Tuy nhiên, tôi rất thích khả năng thích nghi nhanh chóng đó.

Bài đăng trên blog hay về cùng chủ đề: Python khiến tôi lo lắng

Chữ ký phương thức hầu như vô dụng trong Python. Trong Java, nhập tĩnh biến chữ ký của phương thức thành một công thức: đó là tất cả những gì bạn cần để làm cho phương thức này hoạt động. Không phải như vậy trong Python. Ở đây, một chữ ký phương thức sẽ chỉ cho bạn biết một điều: bạn cần bao nhiêu đối số để nó hoạt động. Đôi khi, nó thậm chí sẽ không làm được điều đó, nếu bạn bắt đầu chơi với ** kwargs.

Vì đó là niềm vui thú vị vui vẻ. Thật thú vị khi không phải lo lắng về việc phân bổ bộ nhớ, cho một. Thật là vui khi không phải chờ biên dịch. vv vv vv

Ngôn ngữ được nhập yếu cho phép bạn linh hoạt trong cách quản lý dữ liệu của mình.

Tôi đã sử dụng VHDL vào mùa xuân năm ngoái cho một số lớp và tôi thích phương pháp biểu diễn bit / byte của chúng và cách trình biên dịch bắt lỗi nếu bạn cố gắng gán một xe buýt 6 bit cho một xe buýt 9 bit. Tôi đã cố gắng tạo lại nó trong C ++ và tôi đang gặp phải một cuộc đấu tranh công bằng để làm cho việc đánh máy hoạt động trơn tru với các kiểu hiện có. Tôi nghĩ Steve Yegge đã làm rất tốt khi mô tả các vấn đề liên quan đến hệ thống loại mạnh.

Về tính chi tiết: Tôi thấy Java và C # nói chung là khá dài dòng (chúng ta đừng chọn các thuật toán nhỏ để "chứng minh" một điểm). Và, vâng, tôi đã viết cả hai. C ++ cũng gặp khó khăn trong cùng một lĩnh vực; VHDL chịu thua ở đây.

Parsimony dường như là một ưu điểm của các ngôn ngữ động nói chung (tôi trình bày Perl và F # làm ví dụ).