Các ngôn ngữ đánh máy năng động có xứng đáng với tất cả những lời chỉ trích? [đóng cửa]


35

Tôi đã đọc một vài bài viết trên Internet về lựa chọn ngôn ngữ lập trình trong doanh nghiệp. Gần đây, nhiều ngôn ngữ gõ động đã được phổ biến, ví dụ như Ruby, Python, PHP và Erlang. Nhưng nhiều doanh nghiệp vẫn ở lại với các ngôn ngữ gõ tĩnh như C, C ++, C # và Java.

Và đúng vậy, một trong những lợi ích của các ngôn ngữ gõ tĩnh là các lỗi lập trình được phát hiện sớm hơn, vào thời gian biên dịch, thay vì vào thời gian chạy. Nhưng cũng có những lợi thế với các ngôn ngữ đánh máy năng động. ( thêm trên Wikipedia )

Lý do chính khiến các doanh nghiệp không bắt đầu sử dụng các ngôn ngữ như Erlang, Ruby và Python, dường như là do chúng được gõ động. Đó dường như cũng là lý do chính khiến mọi người trên StackOverflow quyết định chống lại Erlang. Xem lý do tại sao bạn quyết định "chống lại" Erlang .

Tuy nhiên, có vẻ là một lời chỉ trích mạnh mẽ chống lại gõ động trong các doanh nghiệp, nhưng tôi không thực sự có được nó tại sao nó lại mạnh mẽ.

Thực sự, tại sao có quá nhiều chỉ trích chống lại việc gõ động trong các doanh nghiệp? Nó thực sự ảnh hưởng đến chi phí của các dự án nhiều, hoặc những gì? Nhưng có lẽ tôi đã sai.


3
Tôi nghĩ rằng gõ tĩnh với kiểu suy luận và gõ vịt có thể là cách tốt nhất có thể để làm việc. Nó cũng rất phức tạp
Casebash

2
Tôi mới xem qua cách gõ vịt của C # (tôi không sử dụng ngôn ngữ) và trong khi nó dường như hoàn thành định nghĩa về cách gõ vịt, thì độ dài cần thiết dường như đánh bại mục đích. Điều đó không có nghĩa là đôi khi nó không hữu ích.
Chinmay Kanchi

3
Có phải chỉ mình tôi hay có nhiều chỉ trích về ngôn ngữ gõ tĩnh hơn so với ngôn ngữ gõ động? Ngoài ra, theo kinh nghiệm của tôi, các lựa chọn ngôn ngữ / công nghệ của các "doanh nghiệp" lớn dường như bị quyết định bởi xu hướng hiện tại / lựa chọn an toàn hơn là bất kỳ giá trị kỹ thuật thực sự nào.
MAK

2
@ChinmayKanchi: Độ dài? Bạn chỉ cần khai báo một cái gì đó như dynamicvà bắt đầu sử dụng nó. Nó không dài dòng hơn các cuộc gọi phương thức thông thường hoặc quá tải toán tử.
Joey

4
Tôi không thể đếm số giờ tôi đã lãng phí tại các lỗi gỡ lỗi của công ty hiện tại trong mã Groovy trên mã Grails, mà trình biên dịch sẽ phát hiện ra ngay lập tức nếu chúng tôi sử dụng Java.
WKS

Câu trả lời:


46

Vâng, tôi tin rằng họ làm.

Có một vài lý do cần được xem xét trong việc lựa chọn ngôn ngữ cho một dự án mới:

  • Tốc độ thời gian chạy. So với C / C ++ / Fortran, Perl và Python quá chậm, thật buồn cười.
  • Tốc độ khởi tạo. So với các ngôn ngữ nhanh ở trên, Java rơi xuống và khóc khi JVM tiếp tục tải và tải và ... while(1)....
  • Nguyên mẫu-khả năng. Việc sử dụng triệt để và thực hiện công việc khai báo / định nghĩa cần thiết cho C ++ hoặc Java làm tăng LỘC, đây là số liệu duy nhất được biết có tương quan đáng tin cậy với số lượng lỗi. Nó cũng mất rất nhiều thời gian. Nó cũng đòi hỏi một chút suy nghĩ về các loại và kết nối.
  • Khả năng vận hành nội bộ. Tự động làm rối tung nội bộ của bạn là tuyệt vời cho đến khi bạn bắt đầu gỡ lỗi mã tự sửa đổi của mình . (Python, Lisp, Perl)
  • Xác minh chính xác. Một trình biên dịch có thể cung cấp một lần nhanh chóng vượt qua tính chính xác của mã của bạn trong C ++ và điều này có thể thực sự tốt.
  • Chi tiết phân tích tĩnh. C và Java có phân tích tĩnh khá tốt. Perl không hoàn toàn có thể phân tích tĩnh ở cấp độ lý thuyết (Có thể cả Python nữa). Tôi chắc chắn rằng Lisp cũng không.
  • Các nền tảng kỳ lạ chỉ mất C, nói chung.
  • Chuỗi hỗ trợ. Nếu bạn có thể có một hợp đồng mà bạn sẽ nhận được các lỗi của mình và xem xét, thì đó là rất lớn .

Nếu bạn có thể cho rằng tổ chức bạn đang làm việc có nguyên tắc "Tiến lên" (Có một thuật ngữ kế toán cho việc này) và sẽ không quyết định ngẫu nhiên không hoạt động trên phần mềm, thì bạn có trường hợp tốt hơn nhiều cho sử dụng phần mềm. Vì không có doanh nghiệp chính bán hàng (mang hàm ý chịu trách nhiệm duy trì nó) Python / Perl / $ Dynamic_lingu, nên nó giảm đáng kể rủi ro.

Theo kinh nghiệm của tôi, các nhà bảo trì nguồn mở thường gặp vấn đề với việc chịu trách nhiệm hoàn toàn về các lỗi và phát hành các bản cập nhật. "Nó miễn phí, BẠN làm việc trên nó!" là không một câu trả lời đó là chấp nhận được đối với hầu hết các doanh nghiệp (không compentencies cốt lõi của họ, trong số những thứ khác).

Tất nhiên, tôi không nói về thế giới webapp / startup, vốn có xu hướng chơi theo các quy tắc có rủi ro cao / phần thưởng cao và rất cởi mở để luôn đi đầu trong công nghệ.


16
"Nó miễn phí, BẠN làm việc trên nó!" <- Vấn đề lớn nhất với F / OSS nói chung, tôi +1 nhưng tôi không có phiếu bầu :(
Billy ONeal

4
Tóm tắt tốt đẹp. Tôi sẽ giải quyết các loại được xây dựng tốt đó truyền đạt ý nghĩa ngữ nghĩa (tôi có thể nhìn vào một loại và hiểu nó làm gì, sử dụng nó như thế nào) và có thể được sử dụng để thực thi tính chính xác (Tôi có thể xây dựng một loại chỉ chấp nhận inpus bị ràng buộc ) và tôi không nhận được các lỗi ngớ ngẩn từ lỗi chính tả (tôi ghét khai báo biến tự động)
smithco

4
Bạn có thể nhận được hỗ trợ thương mại cho bất kỳ dự án nguồn mở lớn nào. Các công ty lớn sử dụng PL được gõ động cho các phần lớn (chắc chắn phù hợp), Facebook sử dụng PHP (UI) và Erlang (trò chuyện), Twitter sử dụng Ruby (UI), Google sử dụng Python (tôi không biết vì điều gì) và Lisp và Python là đang được sử dụng trong nhiều dự án nghiên cứu tinh vi. Lưu ý: Tôi là nhà phát triển C # Tôi (hầu như) không bao giờ sử dụng ngôn ngữ được nhập động; Tuy nhiên, những điểm này không có giá trị mở rộng đáng kể.
Kaveh Shahbazian

4
Tôi thích câu trả lời của bạn nhưng Java không được gõ động ...
Mehrdad

2
@PaulNathan: Bạn đang suy nghĩ quá nhiều. Câu hỏi được hỏi về các ngôn ngữ được gõ động và câu trả lời này đề cập đến Java như thể nó được gõ động.
Mehrdad

24

Bạn đang nhường quá nhiều tín dụng kỹ thuật cho những người ra quyết định Doanh nghiệp. Có một câu nói cũ, "Không ai bị sa thải vì mua IBM." Nếu bạn đi một con đường khác và mọi thứ trở nên khó khăn (họ luôn làm thế), không ai muốn mạo hiểm bị đổ lỗi. Bám sát các tiêu chuẩn và đổ lỗi cho người khác.

Có rất nhiều công ty trẻ cuối cùng sẽ trở thành doanh nghiệp của ngày mai và sẽ sử dụng các ngôn ngữ đó.

Và đừng quên các dòng mã được viết bằng VBA!


1
+1 cho "... các doanh nghiệp của ngày mai [và] sẽ sử dụng các ngôn ngữ đó."
ndmueller

6
"Có rất nhiều công ty trẻ cuối cùng sẽ trở thành doanh nghiệp của ngày mai và sẽ sử dụng các ngôn ngữ đó.": Bạn dường như ngụ ý rằng các ngôn ngữ động còn khá mới và cần nhiều thời gian để được nhiều công ty chấp nhận. Mặt khác, các ngôn ngữ động đã tồn tại từ lâu.
Giorgio

17

Lý do doanh nghiệp sử dụng C, C ++, C # và Java không phải vì chúng được nhập tĩnh (ít nhất là không trực tiếp). Những người ra quyết định doanh nghiệp không đưa ra những lựa chọn này trên cơ sở so sánh khách quan các hệ thống loại, tôi đảm bảo với bạn.

Các doanh nghiệp làm dịch vụ chăm sóc về:

  • Chi phí bảo trì dài hạn : bạn có thể mong đợi một cách hợp lý mọi thứ sẽ tiếp tục hoạt động tốt trong thời gian 10 năm không? Đó thực sự là một điều tốt nếu tiến hóa ngôn ngữ là bảo thủ và tương thích ngược (như với Java). Kiểu gõ tĩnh rất hữu ích ở đây vì nó bắt được một loại lỗi lớn tại thời điểm biên dịch trước khi chúng xâm nhập vào hệ thống sản xuất của bạn .....
  • Tài năng sẵn có - bạn sẽ có thể tìm nhà phát triển để duy trì hệ thống mới sáng bóng của mình chứ? Điều gì xảy ra nếu nhà phát triển ban đầu rời đi, mọi người khác có hiểu mã không? Điều này đặt ra một trở ngại lớn trong việc giới thiệu bất kỳ ngôn ngữ "mới" nào (đặc biệt là nếu nó cũng tạo ra các yêu cầu mới để triển khai, xây dựng hệ thống, hỗ trợ vận hành, v.v.). Điều này mang lại lợi thế lớn cho các ngôn ngữ được sử dụng rộng rãi (C, C ++, C # và Java)
  • Chi phí tích hợp : có dễ dàng kết nối / tích hợp với các công nghệ khác mà bạn đã có hoặc có khả năng mua lại không? Nếu bạn đã có một chồng các hệ thống J2EE cũ thì bạn cần tích hợp với chúng. Một giải pháp Java EE mới có thể thực tế hơn nhiều cho việc này hơn là Python.
  • Dự đoán / rủi ro thấp : nền tảng / ngôn ngữ đã được chứng minh và tôi có thể chắc chắn rằng nó sẽ hoạt động không? Điều này thường là nhiều quan trọng hơn năng suất đơn giản. Người quản lý dễ dàng thuyết phục sếp của mình cho anh ta một ngân sách lớn cho nhân lực để xây dựng một hệ thống mới hơn là để anh ta quay lại sau và nói rằng nó không hoạt động .....
  • Hỗ trợ / hỗ trợ doanh nghiệp - các tổ chức quốc tế lớn có cam kết hỗ trợ ngôn ngữ và nền tảng không? Họ sẽ ký hợp đồng hỗ trợ tôi để tôi có người gọi nếu gặp sự cố?
  • Tính trung lập của nhà cung cấp / tính độc lập của nền tảng - tôi có bị khóa với một nhà cung cấp không? Hoặc tôi có sẵn một loạt các tùy chọn nhà cung cấp / đường dẫn chuyển tiếp trong tương lai không? Bạn không muốn bị mắc kẹt trong ngõ cụt kiến ​​trúc, không thể đạt được tiến bộ trong khi các đối thủ cạnh tranh ăn bữa trưa của bạn. Nếu bạn đang làm công việc của mình đúng với tư cách là một kiến ​​trúc sư doanh nghiệp, bạn cần phải suy nghĩ ít nhất 5-10 năm trước về công cụ này.

Cá nhân, tôi nghĩ rằng nếu bạn muốn sử dụng các ngôn ngữ động trong Doanh nghiệp, thì cơ hội tốt nhất của bạn cho đến nay là sử dụng thứ gì đó cõng trên hệ sinh thái doanh nghiệp hiện có. Đáng chú ý nhất là các ngôn ngữ JVM động mới: ví dụ: JRuby, Groovy, Clojure. Theo như quản lý CNTT, đây là những lựa chọn ngôn ngữ động "an toàn" vì chúng hoạt động bên trong và hoạt động tốt với phần còn lại của hệ sinh thái doanh nghiệp Java.


1
Tôi không thể tin rằng không ai nêu lên câu trả lời của bạn.
Sebastian N.

11

Lý do chính khiến các doanh nghiệp không bắt đầu sử dụng các ngôn ngữ như Erlang, Ruby và Python, dường như là do chúng được gõ động.

Tôi nghĩ rằng đây chỉ là lý do chính của họ. Lý do thực sự là các doanh nghiệp không thực sự coi trọng họ và cảm thấy rằng họ có thể hơi nghiệp dư. Java và .NET là những tên doanh nghiệp lớn của Việt Nam, có tiếp thị thương mại tốt, hỗ trợ khách hàng thương mại và do đó thực sự được coi là rất nghiêm túc.

Thật không may là thực tế không có ngôn ngữ gõ tĩnh mà bất cứ nơi nào gần như phổ biến như các tên doanh nghiệp lớn. Tại sao các môi trường lập trình mã nguồn mở / phần mềm miễn phí hầu như luôn được gõ động? Điều này có thể chỉ ra rằng một ngôn ngữ gõ tĩnh thực sự không dễ thực hiện và việc gõ động là hack hack của một người đàn ông lười biếng. Nếu đó là trường hợp, các doanh nghiệp quyết định chống lại các ngôn ngữ gõ động có thể thực sự có một điểm.


8
Có thật không? Lần cuối cùng tôi thấy, Google đã bỏ ra khá nhiều sức nặng và nỗ lực phát triển đáng kể đằng sau Python, bao gồm cả việc thuê người tạo ra Python và cho phép anh ta dành 50% thời gian để làm việc với ngôn ngữ này. Google cũng đóng góp một lượng mã tốt cho Python, đặc biệt là bây giờ việc nuốt không được nhập vào cây nguồn Python 3. Điều đó làm cho Python trở thành một "tên doanh nghiệp lớn" đối với tôi.
Chinmay Kanchi

13
@Chinmay Kanchi: Thật thú vị khi bạn rút ra kết luận của mình từ một thống kê với cỡ mẫu là 1.
Timwi

6
Touché. Tuy nhiên, một số kết luận của bạn là thiếu sót. Thực hiện tốt một ngôn ngữ năng động là xa khó hơn việc thực hiện một ngôn ngữ tĩnh gõ. Gõ động chắc chắn không phải là "hack người lười biếng" như bạn nói. Nó cho phép các nhà phát triển lười biếng, nhưng không phải là người viết trình biên dịch / trình thông dịch. Trên thực tế, việc tối ưu hóa một ngôn ngữ được gõ động rất khó đến nỗi tôi chỉ có thể nghĩ về một ngôn ngữ mà trong thời gian gần đây đã nhận được sự đối xử rộng rãi này (JavaScript), mặc dù có các dự án tối ưu hóa / JITting cho các ngôn ngữ khác (Python, PHP).
Chinmay Kanchi

2
Ngoài ra, nếu bạn nghĩ rằng các ngôn ngữ được gõ động là ngôn ngữ được sử dụng phổ biến nhất trong môi trường nguồn mở, thì điều này còn lâu mới rõ ràng. Tùy thuộc vào số liệu bạn chọn, điều này có thể đúng, nhưng thường thì không. Đo dòng mã, C thắng bằng một cú sút xa. Nếu bạn đo lường ngôn ngữ nào được sử dụng trong các dự án nguồn mở, bao gồm cả ngôn ngữ đa ngôn ngữ, các ngôn ngữ phổ biến nhất là JavaScript, C, C ++ và PHP theo thứ tự đó. Nếu bạn chỉ đo ngôn ngữ chính, các ngôn ngữ phổ biến nhất là Perl, Java, C # và JavaScript. bit.ly/C6xTB
Chinmay Kanchi

7
Tất nhiên, viết một trình tối ưu hóa cho các ngôn ngữ được gõ động là khó, nhưng không phải là trình thông dịch : bạn có thể loại bỏ tất cả các loại kiểm tra và phần còn lại là như nhau. Không có nhà sản xuất ngôn ngữ nghiệp dư nghĩ về việc viết một trình tối ưu hóa. - Về các bit cuối cùng, tôi đã không có ý nghĩa để ngụ ý rằng phần mềm mã nguồn mở hầu hết được viết bằng một ngôn ngữ lập trình tự động, đánh máy, nhưng đúng hơn là hầu hết các ngôn ngữ lập trình mã nguồn mở (tôi nói “môi trường” vì tôi đang nói về trình biên dịch / trình thông dịch, IDE, v.v.) được gõ động.
Timwi

9
  • Các ngôn ngữ được gõ động có xu hướng chậm hơn so với anh em họ gõ tĩnh của chúng.
  • Lỗi khó bắt hơn và có thể khó gỡ lỗi hơn
  • Trình biên dịch / trình thông dịch có xu hướng ít khó tính hơn về những gì bạn có thể và không thể làm. tức là, bạn khá nhiều chỉ bắt lỗi cú pháp ở giai đoạn biên dịch
  • Nếu bạn không phải là rất cẩn thận với thiết kế của một ngôn ngữ động gõ, bạn kết thúc với Javascript, đó là những ngôn ngữ của mã mùi

EDIT: Tôi nên đề cập rằng ngôn ngữ lập trình chính của tôi tại thời điểm này là Python, được gõ động. Cá nhân, tôi thích sự tự do đi kèm khi không phải khai báo trước các biến, nhưng đôi khi, sẽ tốt hơn nếu chỉ định (ví dụ) loại tham số nào mà hàm cần để bắt lỗi sớm thay vì muộn.


1
Mặc dù trình biên dịch không khó tính, nhưng trình thông dịch thường là. Đối với hầu hết các phần, thông dịch viên phát hiện các tình huống có vấn đề và lỗi tín hiệu.
Winston Ewert

17
Tôi thích gõ động nhưng tôi ghét không phải dự đoán các biến! Vì vậy, nhiều lần tôi vô tình giới thiệu một biến mới vì tôi viết sai một tên biến.
Frank Shearar

1
@Frank: Tôi vô tình thích rằng Perl có một cài đặt để buộc khai báo biến. Theo ý kiến ​​của tôi, đó là một trong những lợi thế của Perl.
Paul

8

Các ngôn ngữ được gõ động được nhận biết (bởi một số lập trình viên / ông chủ) để tạo ra mã không hoạt động tốt. Thực tế là một chương trình gõ động được biên dịch cho bạn biết rất ít về tính chính xác của nó. Thực tế là một ngôn ngữ gõ tĩnh biên dịch cho bạn biết nhiều hơn nữa. (Mặt khác, vẫn còn một khoảng cách dài giữa các trình biên dịch và thực hiện đúng, vì vậy điều này có thể ít ý nghĩa hơn)

Các ngôn ngữ được gõ động được coi là ngôn ngữ script. Bạn sẽ không bao giờ viết một ứng dụng trong bash hoặc một tệp bó. Tất cả các ngôn ngữ được gõ động có xu hướng được lặp vào danh mục đó (không công bằng).

Các ngôn ngữ gõ động chậm hơn các ngôn ngữ gõ tĩnh. (Nhưng chúng ta sẽ thấy JIT thay đổi tốt như thế nào)


2
"Được cảm nhận bởi" một số lập trình viên. Khi tôi tranh luận với các lập trình viên về cách gõ động, họ thường thừa nhận rằng họ chưa bao giờ thực sự sử dụng loại ngôn ngữ đó.
Frank Shearar

1
@Frank bạn đang nói rằng những người tranh luận về sự thấp kém của kiểu gõ động thường không sử dụng nó?
Winston Ewert

2
@Frank: Tôi đã sử dụng loại ngôn ngữ đó và hầu hết thời gian kết quả là sự lộn xộn không thể nhầm lẫn. (Công bằng mà nói, đó là PHP và PHP có vấn đề khác ngoài việc gõ động)
Billy ONeal

@Billy: Tôi nghĩ điều này là phổ biến. Tôi đã thất bại trong việc gõ động trong nhiều năm vì kinh nghiệm của tôi với VB - khi cuối cùng tôi nhận ra rằng việc thực hiện đánh máy động lực khủng khiếp này là điển hình, ý kiến ​​của tôi đã thay đổi đáng kể.
Shog9

@Winston: Tôi đang nói rằng những người mà tôi đã tranh luận không có. Đối với tôi, đó là một trường hợp "gõ động không thể hoạt động được" ... nhưng họ sẽ vui vẻ sử dụng nhiều kỹ thuật được phát triển đầu tiên, bằng và cho các ngôn ngữ động (IDE, tái cấu trúc, ngoài đỉnh đầu của tôi). Ngoài ra, các câu hỏi như thế này: stackoverflow.com/questions/2317579 chỉ ra rằng trong khi có lẽ không phổ biến, trường hợp của tôi để tranh luận với các lập trình viên không thể làm việc nhưng tôi không cố gắng không bị cô lập. (Tôi, tôi nghĩ cả hai cách tiếp cận đều có giá trị.)
Frank Shearar

8

Lưu ý: điều này chủ yếu là chủ quan và dựa trên kinh nghiệm và ấn tượng của tôi.

Các ngôn ngữ gõ động rất khác với các ngôn ngữ gõ tĩnh. Những khác biệt này có thể trở nên quan trọng hơn trong phần mềm doanh nghiệp nặng hơn so với hầu hết các ứng dụng khác.

Các ngôn ngữ gõ tĩnh có xu hướng rất quy định. Một phương thức sẽ chỉ lấy đầu vào khớp chính xác với chữ ký của nó. Các cấp truy cập có xu hướng rất quan trọng và các giao diện được xác định rõ ràng, với các hạn chế dài dòng nhưng rõ ràng để áp đặt các định nghĩa đó.

Mặt khác, các ngôn ngữ gõ động rất thực dụng. Chuyển đổi loại thường xảy ra ngầm, các chức năng thậm chí có thể phát cùng nếu bạn cung cấp loại đầu vào sai miễn là nó hoạt động đủ tương tự. Trong các ngôn ngữ như Python, thậm chí các cấp truy cập sẽ dựa trên hợp đồng thay vì các hạn chế kỹ thuật (nghĩa là chỉprivate vì bạn được bảo không sử dụng nó và nó có một cái tên ngộ nghĩnh).

Nhiều lập trình viên thích ngôn ngữ động vì chúng (được cho là) ​​cho phép tạo mẫu nhanh. Mã thường kết thúc ngắn hơn (nếu chỉ vì thiếu khai báo kiểu) và nếu bạn muốn vi phạm giao thức thích hợp vì bạn cần một giải pháp nhanh và bẩn hoặc muốn kiểm tra một cái gì đó, điều đó có thể dễ dàng.

Bây giờ, lý do mà các công ty "enterprisey" thường thích các ngôn ngữ được gõ tĩnh chính xác là chúng hạn chế hơn và rõ ràng hơn về những hạn chế đó. Mặc dù trong thực tế, ngay cả mã được gõ tĩnh có thể bị phá vỡ bởi những kẻ ngốc với trình biên dịch, nhiều vấn đề sẽ được nhìn thấy rõ hơn nhiều trước đó trong quá trình (tức là trước khi chạy). Điều này có nghĩa là ngay cả khi cơ sở mã lớn, nguyên khối và phức tạp, nhiều lỗi có thể dễ dàng bị bắt, mà không phải chạy mã hoặc gửi nó đến bộ phận QA.

Lý do lợi ích không vượt quá nhược điểm đối với nhiều lập trình viên ngoài môi trường đó là vì đây là những lỗi thường sẽ dễ dàng bị bắt gặp khi kiểm tra kỹ mã hoặc thậm chí bằng cách chạy nó. Đặc biệt là khi làm theo một phương pháp dựa trên thử nghiệm, những lỗi này thường trở nên tầm thường để dễ nắm bắt và dễ sửa chữa. Ngoài ra, với nhiều công ty như vậy có chu kỳ phát hành ngắn hơn nhiều, năng suất thường quan trọng hơn độ cứng và rất nhiều thử nghiệm (cơ bản) đang được thực hiện bởi chính các nhà phát triển.

Một lý do khác mà các tập đoàn enterprisey không sử dụng nhiều ngôn ngữ được gõ động là mã kế thừa. Có vẻ ngớ ngẩn như chúng ta có vẻ mọt sách, các tập đoàn lớn sẽ thường bám vào các giải pháp hoạt động, ngay cả khi chúng đã quá hạn sử dụng. Đây là lý do tại sao rất nhiều công ty lớn thực thi Internet Explorer 6 và rất chậm để nâng cấp hệ điều hành của họ. Đây cũng là lý do tại sao họ sẽ thường viết mã mới bằng các ngôn ngữ "cũ" (ví dụ: các phiên bản Java cổ): việc thêm một vài dòng mã vào một phần mềm chưa phát hành sẽ dễ dàng hơn nhiều so với việc chấp thuận viết lại hoàn toàn trong một ngôn ngữ mới ngôn ngữ.

tl; dr: các ngôn ngữ tĩnh cảm thấy giống như quan liêu hơn, vì vậy các nhà quản lý enterprisey thích chúng tốt hơn.


3
Các ngôn ngữ với các quy tắc đánh máy loosy-goosy tạo ra nhiều cơ hội cho những điều sai trái trong công việc sắp xếp. Ví dụ, trong JavaScript, việc chuyển một số sang mã dự kiến ​​một chuỗi sẽ thường hoạt động như thể một chuỗi đã truyền đại diện cho chuỗi đó, nhưng không phải lúc nào cũng vậy. Cố gắng ví dụ nối 456 đến 123 sẽ không mang lại 123456, nhưng thay vào đó sẽ mang lại 579. Trừ khi rõ ràng ai chịu trách nhiệm chuyển đổi số thành chuỗi, có thể được thực hiện dự phòng hoặc không thực hiện được.
supercat

1
@supercat, tôi nghĩ rằng PHP và JavaScript là những ví dụ điển hình cho hai cách xử lý vấn đề đó (liên quan đến các toán tử): trong các toán tử PHP không rõ ràng - +lấy số và thêm chúng, nếu bạn muốn sử dụng phép nối .; trong JS, cả hai hoạt động đều chia sẻ cùng một toán tử - nếu bạn không biết các giá trị của mình sẽ hoạt động như thế nào, bạn sẽ chuyển đổi chúng một cách rõ ràng. Tất nhiên điều này cũng phải thực hiện với việc gõ lỏng so với gõ nghiêm ngặt (Python thậm chí còn nghiêm ngặt hơn), nhưng về cơ bản, bạn phải đảm bảo các giá trị của mình có đúng loại hoặc làm cho các hoạt động của bạn thực thi các loại mong đợi.
Alan Plum

1
Tôi không quen thuộc lắm với PHP, nhưng có vẻ như nó sử dụng cách mà tôi sẽ gọi là cách tiếp cận "đúng". Javascript là đáng ghê tởm theo nhiều cách, nhưng tôi nghĩ rằng hành vi của "+" là một trong những điều tồi tệ nhất. Trên thực tế, tôi không tin rằng kiểu gõ động loosy-goosy sẽ có nhiều lợi thế hơn so với hệ thống loại mạnh hơn cho phép một giao diện tuyên bố rằng những thứ thuộc một loại lớp hoặc loại giao diện khác nên được coi là thực hiện hoặc xuất phát từ nó, với các quy tắc cụ thể về cách yêu cầu sẽ được ưu tiên. Hạn chế lớn mà tôi nhận thấy với các khung cấu trúc hiện tại là ...
supercat

1
... Nếu hai người độc lập phát triển các giao diện tương tự nhau, không có cách nào để bên thứ ba viết mã có thể sử dụng chúng thay thế cho nhau. Nếu một bên thứ ba có thể xác định giao diện mới và tuyên bố rằng việc triển khai một hoặc cả hai giao diện hiện tại sẽ tự động triển khai giao diện mới (sử dụng trình bao bọc được cung cấp trong giao diện mới nếu cần) Tôi nghĩ rằng sẽ xử lý 99% về mặt ngữ nghĩa giỏi về đánh máy năng động.
supercat

3

Không, tôi không nghĩ các ngôn ngữ gõ động đáng phải chịu tất cả những lời chỉ trích. (Hoặc nếu bạn thích, họ đáng bị chỉ trích nhiều như các ngôn ngữ được nhập tĩnh.)

Theo kinh nghiệm của tôi (và tôi không cố gắng khái quát hóa tuyên bố này), các lập trình viên chỉ trích các ngôn ngữ động đã không sử dụng chúng. Cuộc hội thoại thường diễn ra "nhưng với kiểu gõ tĩnh, trình biên dịch bắt được rất nhiều lỗi!" và tôi nói "tốt, đó không phải là vấn đề, theo kinh nghiệm của tôi". (Thông thường các lập trình viên khác từ Java, Delphi hoặc nền tương tự; Tôi không biết bất kỳ lập trình viên Haskell hoặc ML nào.)

Điều duy nhất thực sự thu hút tôi là khi ai đó tuyên bố rằng kỹ thuật Foo không thể thực hiện được (hoặc có thể rất khó thực hiện) bằng ngôn ngữ được gõ động ... khi kỹ thuật đó được phát minh, và bằng cách gõ động ngôn ngữ. IDE? Smalltalk. Tự động tái cấu trúc? Smalltalk. Người gọi-của / người thực hiện? Smalltalk.


Tôi không muốn làm lộn xộn câu trả lời của mình với lập trường cá nhân, đó là: công cụ phù hợp cho công việc phù hợp. Bất kỳ loại ngôn ngữ nào bạn sử dụng đều phù hợp hơn cho một số nhiệm vụ và phù hợp với những ngôn ngữ khác, hơn là loại ngôn ngữ khác.
Frank Shearar

6
Khi lập trình viên khác đến từ Haskell, anh ấy / cô ấy đã biết đó là ngôn ngữ ưu việt hơn cả ngôn ngữ Java và ngôn ngữ động;)
Andres F.

0

Các doanh nghiệp chỉ không áp dụng ngôn ngữ và công cụ mới đủ nhanh và có lý do chính đáng cho nó. Nhưng, khi một trong những công cụ chính như C # triển khai một số tính năng này, thì chúng sẽ gặp khó khăn trong các doanh nghiệp chính thống ....


Tôi không biết tại sao điều này bị hạ thấp, nhưng đó là một tuyên bố sâu sắc. Doanh nghiệp chậm và bảo thủ. Mọi người cũng thích thay đổi dần dần (như từ khóa động trong C #, cho phép bạn thỉnh thoảng sử dụng kiểu gõ động trong ngôn ngữ được nhập tĩnh) để thay đổi đột ngột (như Ruby).
Vaddadi Kartick
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.