Ngôn ngữ lập trình nào tạo ra ít lỗi khó tìm nhất? [đóng cửa]

54

Theo bạn, ngôn ngữ nào cho phép lập trình viên trung bình xuất ra các tính năng với ít lỗi khó tìm nhất? Tất nhiên, đây là một câu hỏi rất rộng, và tôi quan tâm đến những câu trả lời và trí tuệ rất rộng và chung chung.

Cá nhân tôi thấy rằng tôi dành rất ít thời gian để tìm kiếm các lỗi lạ trong các chương trình Java và C #, trong khi mã C ++ có tập hợp các lỗi lặp lại riêng biệt và Python / tương tự có các lỗi phổ biến và ngớ ngẩn của riêng nó sẽ được trình biên dịch phát hiện trong các ngôn ngữ khác.

Ngoài ra tôi thấy khó để xem xét các ngôn ngữ chức năng về vấn đề này, bởi vì tôi chưa bao giờ thấy một chương trình lớn và phức tạp được viết bằng mã chức năng hoàn toàn. Xin vui lòng nhập liệu của bạn.

Chỉnh sửa: Hoàn toàn tùy ý làm rõ lỗi khó tìm: Mất hơn 15 phút để sao chép hoặc hơn 1 giờ để tìm nguyên nhân và khắc phục.

Hãy tha thứ cho tôi nếu đây là một bản sao, nhưng tôi không tìm thấy bất cứ điều gì về chủ đề cụ thể này.

— Magnus Wolffelt
nguồn

10

Tôi muốn xem một số nghiên cứu được thực hiện trong chủ đề này! Không chỉ là "bằng chứng giai thoại của tôi cho thấy rằng ngôn ngữ duy nhất tôi biết là vua" mà là tỷ lệ lỗi từ các dự án lớn, v.v.

— Frank Shearar

@Frank .. nếu bạn có RẤT NHIỀU (và ý tôi là RẤT NHIỀU) thời gian, bạn có thể khai thác một số thống kê từ ohloh, miễn là bạn có thể xác định các bản vá sửa lỗi từ hàng ngàn kho lưu trữ mã.

— Tim Post

Một trong những chỉ nhận xét được cho phép. Không có hướng dẫn nào khác :)

— Victor Hurdugaci

4

Tôi nghĩ rằng "khó tìm" cần phải được làm rõ. Câu hỏi của bạn và hầu hết các câu trả lời dường như định nghĩa "khó tìm" là tương đương với "không bị trình biên dịch bắt". Bạn đề cập đến python là có các lỗi ngớ ngẩn sẽ được trình biên dịch phát hiện. Đủ công bằng. Nhưng những con bọ ngớ ngẩn đó thường không khó tìm. Chắc chắn, chúng không cùng loại với lỗi C ++ xuất phát từ việc giải phóng bộ nhớ quá sớm.

— Winston Ewert

@Winston Đồng ý.

— Magnus Wolffelt

58

Hệ thống loại ngôn ngữ càng mạnh, càng nhiều lỗi sẽ bị bắt tại thời điểm biên dịch.

Hình dưới đây so sánh một số ngôn ngữ lập trình nổi tiếng về sức mạnh, sự đơn giản và an toàn của các hệ thống loại của chúng. [ Nguồn ]

văn bản thay thế

* Bao thanh toán trong khả năng sử dụng các cấu trúc không an toàn.

C # bị nhồi vào hàng không an toàn do từ khóa "không an toàn" và máy móc con trỏ liên quan. Nhưng nếu bạn muốn nghĩ về những điều này như một loại cơ chế chức năng nước ngoài nội tuyến, hãy thoải mái nâng C # lên trời.

Tôi đã đánh dấu Haskell '98 là thuần túy nhưng GHC Haskell không thuần túy do họ chức năng * không an toàn. Nếu bạn vô hiệu hóa không an toàn * thì hãy nhảy GHC Haskell lên tương ứng.

— missingfaktor
nguồn

8

Thật là tuyệt vời!

7

Tôi không thể tìm thấy Lisp thông thường trong đồ họa: (let ((itbe '())) ... )...

— duros

7

Gì? Không còn chỗ trống nào ở phía bên trái cho PHP?

— pestaa

7

C # cho phép con trỏ an toàn : tất cả số học con trỏ được kiểm tra. Do đó, tôi tin rằng nó nên ở đó với Java.

— Alex ten Brink

11

@missingfaktor: Tôi nghĩ C # không được định vị tốt. C # cho phép và thúc đẩy các kiểu lập trình sau. Nó không nên được đo lường bởi điều tồi tệ nhất mà nó cho phép.

— back2dos

20

Theo tôi, Haskell giúp bạn tránh một số nguồn lỗi phổ biến:

đó hoàn toàn là chức năng: các chức năng không thể có tác dụng phụ (không chủ ý) và điều này làm cho việc lập trình đa lõi dễ dàng hơn và ít bị lỗi hơn
nó được gõ mạnh: bạn không thể vô tình trộn các giá trị bool, char, int và float
nó được gõ tĩnh: nhiều lỗi lập trình được bắt gặp tại thời điểm biên dịch
nullkhông phải là một phần của định nghĩa loại giá trị: bằng cách này, bạn tránh được sai lầm tỷ đô la
có rất nhiều hàm có thứ tự cao hơn được làm sẵn mà bạn có thể sử dụng lại thay vì viết các triển khai của riêng bạn, có thể bị lỗi
nó có trình thu gom rác: lỗi bộ nhớ gần như được loại bỏ (ngoại trừ "rò rỉ không gian" do chiến lược đánh giá lười biếng của nó)

— LennyProgrammer
nguồn

11

Tôi sẽ không đánh giá thấp điều này, nhưng tôi bị cám dỗ vì nó không phù hợp với tiêu chí. Nó được cho là cho phép "lập trình viên trung bình xuất các tính năng" với số lượng lỗi tối thiểu, nhưng lập trình viên trung bình, nói một cách thẳng thắn, không thể tạo ra đầu hoặc đuôi của Haskell ngay từ đầu.

— Mason Wheeler

5

Nhiều điểm tốt, nhưng trong khi loại bỏ một số loại lỗi (tác dụng phụ ngoài ý muốn, chuyển đổi loại không mong muốn) Haskell thêm một loại lỗi hoàn toàn mới: rò rỉ không gian. (Ngoài ra, mặc dù không có null, nhưng undefined, đó là một thành viên của mọi loại.)

— j_random_hacker

5

@Mason: Nếu bạn không viết trong đó, bạn không thể gặp lỗi int :)

— Michael K

2

Tôi đoán không có thứ gọi là bữa trưa miễn phí - bạn có thể có các lỗi dễ tìm, hoặc mã dễ viết, nhưng không phải cả hai :)

— Stewol

6

@Mason chính xác thì một lập trình viên trung bình là gì? Câu hỏi bắt đầu với ngôn ngữ lập trình ... ..., không phải là ngôn ngữ lập trình giữa C, C ++ và java ..., nhưng

— Agos

18

Theo truyền thống, các lỗi khó tìm nhất là các điều kiện chủng tộc trong các ứng dụng đa luồng vì chúng là

gần như không thể sinh sản
có thể rất tinh tế

Do đó, bạn cần các ngôn ngữ quản lý thị sai cho bạn càng nhiều và không chủ ý càng tốt. Đây chưa phải là chủ đạo. Java làm một số, nhưng để lại cho bạn phần khó khăn.

Theo hiểu biết của tôi, bạn cần một ngôn ngữ chức năng vì "không có tác dụng phụ" là điều mà ở nơi đầu tiên làm cho hai điểm đạn biến mất. Tôi đã thấy rằng công việc đang diễn ra một cách minh bạch làm cho Haskell trở thành một ngôn ngữ đa luồng hiệu quả và tôi tin rằng Fortress được thiết kế từ đầu để trở thành một ngôn ngữ song song hiệu quả.

Chỉnh sửa: Trong Java Executorsxử lý nhiều phần cứng hơn. Bạn cần làm cho các tác vụ riêng lẻ phù hợp với Callablegiao diện.

— dùng1249
nguồn

5

++ Điều kiện cuộc đua. Bạn có thể nói điều đó một lần nữa.

— Mike Dunlavey

Vâng. Hãy nhớ rằng tính toán song song nói chung là khó, ngay cả với sự trợ giúp ngôn ngữ. (Macro Common Lisp rất khó, mặc dù rất nhiều hỗ trợ ngôn ngữ, bởi vì những gì họ làm là rất mạnh mẽ Cùng chính..)

— David Thornley

Erlang thì sao?

— Malfist

@Malfist, tôi không biết đủ về Erlang để trả lời điều đó. Có lẽ bạn nên mở một câu hỏi nếu bạn thực sự muốn biết?

2

Erlang là một chương trình chức năng được thiết kế để làm cho đa luồng đơn giản và an toàn. Bạn không chia sẻ biến, bạn truyền tin nhắn. Đọc trang wikipedia của nó.

— Malfist

13

Ada được thiết kế sao cho càng nhiều càng tốt được bắt vào thời gian biên dịch thay vì thời gian chạy. Điều này có nghĩa là thường mất khoảng 10 lần để chương trình trong Ada biên dịch so với tương đương trong Java, nhưng khi biên dịch, bạn có thể tin tưởng hơn rằng toàn bộ các lớp lỗi sẽ không tự biểu hiện khi chương trình chạy.

— Đánh dấu
nguồn

7

+1 để nhận thấy, chính xác, Ada bắt những thứ trong trình biên dịch mà các ngôn ngữ khác bỏ qua. -1 cho xác nhận rằng điều này có nghĩa là phải mất gấp 10 lần để chương trình Ada được biên dịch. Ada thưởng cho các lập trình viên THIẾT KẾ !!! Mã của anh ấy, ai nghĩ !!! về những gì anh ta đang làm trước khi anh ta bắt đầu gõ điên cuồng. Kinh nghiệm cá nhân của tôi, khi lập trình sản xuất trong Ada cho công việc quốc phòng, là việc mất mã Ada để biên dịch lâu hơn đáng kể so với C / C ++ hoặc FORTRAN, nhưng mã Ada sau đó ít gặp rắc rối hơn. Pratt & Whitney nhận thấy một cái gì đó tương tự.

— John R. Strohm

1

@john r Strohm, từ những gì tôi hiểu, anh ấy không nói về thời gian để trình biên dịch biên dịch mã, thay vào đó là thời gian để làm cho mã có thể biên dịch được.

— Malfist

oh đồng ý về việc nhận được mã biên dịch. Tôi có thể nhớ khá nhiều bình luận phân biệt giới tính được thực hiện bởi các lập trình viên học ngôn ngữ về cách chọn nit của nó. Thông thường dọc theo dòng chữ Well, nếu bạn đặt tên một ngôn ngữ theo tên của một người phụ nữ ...

— Michael Shaw

@Ptolemy, nếu thuyền có thể được đặt theo tên phụ nữ (ngoại trừ rõ ràng là các nhà mạng Mỹ) thì ngôn ngữ lập trình cũng có thể. Thay vào đó, nó được đặt tên là "Ada" thay vì "USS Ronald Reagan" :)

1

Khi tôi đã vượt qua giai đoạn học tập, tôi thực sự đã khá nhanh chóng trong việc viết mã Ada - sau khi tôi đã dành rất nhiều thời gian để suy nghĩ về thiết kế. Ada chắc chắn KHÔNG phải là ngôn ngữ của hacker. Tôi làm việc ở Java ngày nay và một số thứ tôi thấy trong các dự án hiện tại của tôi thực sự khiến tôi nhớ Ada một chút (không bao giờ nghĩ rằng tôi nói điều đó).

— James Adam

7

Đầu tiên một định nghĩa: một lỗi khó tìm, theo tôi hiểu, là một lỗi có thể được sao chép nhưng nguyên nhân rất khó tìm.

Có lẽ khía cạnh quan trọng nhất là cái mà tôi sẽ gọi là hẹp , tức là lỗi có thể thoát được bao xa, phạm vi mà một lỗi có thể ảnh hưởng đến mức nào. Trong các ngôn ngữ như C, một lỗi, ví dụ như một chỉ mục mảng âm hoặc con trỏ chưa được khởi tạo, có thể ảnh hưởng đến mọi thứ trong toàn bộ chương trình, vì vậy trong trường hợp xấu nhất, bạn phải kiểm tra mọi thứ ở mọi nơi để tìm ra nguồn gốc của vấn đề.

Các ngôn ngữ tốt trong vấn đề đó hỗ trợ các công cụ sửa đổi truy cập và thực thi chúng theo cách khiến chúng khó hoặc không thể bỏ qua chúng. Các ngôn ngữ tốt khuyến khích bạn giới hạn phạm vi của các biến của mình, thay vì làm cho quá dễ để có các biến toàn cục (ví dụ: "mọi thứ không được khai báo rõ ràng là biến toàn cục với loại và giá trị mặc định").

Khía cạnh quan trọng thứ hai là đồng thời . Điều kiện chủng tộc nói chung là khó sinh sản và do đó khó tìm. Ngôn ngữ tốt cung cấp các cơ chế đồng bộ hóa dễ sử dụng và libs tiêu chuẩn của chúng là luồng an toàn khi cần thiết.

Điều này đã hoàn thành danh sách của tôi; những thứ khác như gõ mạnh giúp bắt lỗi trong thời gian biên dịch, nhưng những lỗi đó có thể sẽ không khó tìm thấy sau này.

Xem xét tất cả những điều đó, tôi muốn nói rằng Java và C # và nhiều ngôn ngữ khác trong thế giới JVM và .net, phù hợp để tránh các lỗi khó tìm.

— người dùng281377
nguồn

Khóa thủ công có thể là một "cơ chế đồng bộ hóa dễ sử dụng" nhưng thực sự chỉ "sử dụng đơn giản nhưng bạn sẽ có những lúc vui vẻ khi bạn theo đuổi bế tắc đó". Và, tốt, bạn có thể thực hiện đồng thời dựa trên diễn viên bằng khá nhiều ngôn ngữ.

— Frank Shearar

Frank: ít nhất là khóa là đủ đơn giản để mọi người có thể làm điều đó mà không mất nhiều ngày, tìm ra API nào sẽ sử dụng, v.v.

— user281377

Sau đó, có quan điểm rằng một giải pháp đồng thời "đủ đơn giản để mọi người có thể làm được" giống như đưa cưa bàn cho học sinh mầm non.

— David Thornley

@David: Tôi thấy quan điểm của bạn, nhưng trong nhiều trường hợp, một giải pháp đơn giản thực sự là tất cả những gì nó cần. Ví dụ, hãy xem xét một servlet chỉ được sử dụng bởi một số ít người dùng, phải sử dụng tài nguyên được chia sẻ (ví dụ: kết nối cơ sở dữ liệu). Không có đồng bộ hóa, điều kiện cuộc đua xảy ra mọi lúc mọi nơi; nhưng nó không chính xác là khoa học tên lửa để đặt tất cả các hoạt động truy cập cơ sở dữ liệu vào một khối (kết nối) {} được đồng bộ hóa.

— user281377

+1 Đối với định nghĩa này "phạm vi mà một lỗi có thể ảnh hưởng đến mức nào". Tôi đã gặp một số lỗi rất khó chịu với các ngôn ngữ động trong đó một đối tượng có kiểu dữ liệu sai đã đi rất xa trong mã (nhờ gõ vịt) trước khi tự biểu hiện là một lỗi.

— Giorgio

7

Vì Excel là DSL được sử dụng rộng rãi nhất, tôi sẽ sử dụng Excel. (tất nhiên không bao gồm VBA)

Nó phù hợp với hóa đơn:

Nó luôn dễ dàng để tạo lại (đây là một bảng tính - nó không hoạt động)
Khá dễ dàng để tìm ra lỗi, vì nó hoàn toàn "có chức năng" - bắt đầu với ô bị sai và tìm lại tất cả các phụ thuộc của nó.

— Scott Whitlock
nguồn

Điều này có thể đúng miễn là bạn không thêm các lỗi dễ tìm.

— mouviciel

+1 Một chút táo tợn vì Excel là dữ liệu, không phải là ngôn ngữ. Hãy cho tôi một tiếng cười

— đệ quy.ninja

2

@awashburn - oh, tôi không biết. Tôi nghĩ rằng nó đủ điều kiện như một ngôn ngữ. Mỗi ô là một "biến". Mỗi biến được khai báo là một chữ (chẳng hạn như 123hoặc ABC) hoặc hàm ( =SUM(A2:A5)). Excel sau đó đánh giá tất cả các biến, tìm ra thứ tự nào để giải quyết các phụ thuộc, v.v ... Đó chắc chắn không chỉ là dữ liệu.

— Scott Whitlock

2

Tôi rút lại tuyên bố của mình, hóa ra Excel đang hoàn tất ... Tôi đã học được điều gì đó hoàn toàn đáng lo ngại ...

— đệ quy.ninja

1

"... chủ nhân [Lisp] thực sự nhận ra rằng tất cả dữ liệu là mã." Có lẽ điều này cũng áp dụng cho Excel, thật kỳ lạ. blog.msdn.com/b/sriram/archive/2006/01/15/lisp-is-sin.aspx

— James Mishra

7

Đây là một câu hỏi khó vì hầu hết các lỗi không phải là lỗi của chính ngôn ngữ - thay vào đó chúng là lỗi của các nhà phát triển mắc lỗi trong cách họ sử dụng ngôn ngữ.

Tôi tin rằng có một số khía cạnh của các tính năng ngôn ngữ ảnh hưởng đến khả năng lỗi:

Tính tương tác - các ngôn ngữ động với REPL khuyến khích sự tương tác / thử nghiệm với các chương trình đang chạy và các chu kỳ kiểm tra / mã nhỏ hơn nhiều. Nếu bạn tin rằng lặp đi lặp lại là một cách tốt để khám phá các giải pháp đơn giản sạch sẽ và phát hiện / loại bỏ các lỗi thì điều này sẽ có xu hướng ủng hộ các ngôn ngữ tương tác.
Tính biểu cảm - nếu mã ngắn hơn và có độ phức tạp ít hơn / độ phức tạp ngẫu nhiên thì sẽ dễ dàng thấy các lỗi / lỗi logic hơn.
Loại an toàn - kiểm tra thời gian biên dịch càng nhiều, trình biên dịch sẽ càng bắt lỗi nhiều hơn vì vậy trong an toàn loại nói chung là một điều tốt. Tuy nhiên, những lỗi này thường không khó tìm thấy - ngay cả trong một ngôn ngữ hoàn toàn động, loại sai trong cấu trúc dữ liệu thường sẽ gây ra lỗi thời gian chạy rất rõ ràng và TDD hầu như luôn gặp phải các loại lỗi này.
Tính không thay đổi - rất nhiều lỗi cứng là do các tương tác phức tạp của trạng thái đột biến. Các ngôn ngữ nhấn mạnh tính bất biến (Haskell, Clojure, Erlang) có một lợi thế rất lớn bằng cách biến đổi đột phá
Lập trình hàm - các cách tiếp cận chức năng để viết mã có xu hướng "chính xác hơn" so với mã hướng đối tượng với các chuỗi hiệu ứng / tương tác phức tạp. Kinh nghiệm của tôi là FP giúp tránh các lỗi khó khăn - tôi tin rằng có một số nghiên cứu học thuật ở đâu đó mà hiện tại tôi không thể tìm thấy điều đó.
Hỗ trợ đồng thời - các vấn đề tương tranh đặc biệt khó phát hiện và gỡ lỗi, đó là lý do tại sao điều này rất quan trọng. Bất cứ điều gì mà đòi hỏi tay khóa cuối cùng là cam chịu thất bại (và điều này bao gồm khá nhiều mỗi cách tiếp cận hướng đối tượng để đồng thời). Ngôn ngữ tốt nhất mà tôi biết về vấn đề này là Clojure - nó có một cách tiếp cận duy nhất để quản lý đồng thời kết hợp bộ nhớ giao dịch phần mềm với các cấu trúc dữ liệu bất biến để có được một khung đồng thời mới, đáng tin cậy và có thể kết hợp. Xem http://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey để biết thêm thông tin chi tiết

— mikera
nguồn

Những người như tôi, những người nhiệt tình ủng hộ lập trình chức năng đánh giá cao câu trả lời này. Biểu cảm là bạn của bạn.

— Sridhar Sarnobat

1

Câu trả lời tốt nhất cho đến nay! Tôi nghĩ rằng điều này được hỗ trợ bởi hai phân tích về tần suất lỗi sau: deliberate-software.com/safe-rank-part-2 và macbeth.cs.ucdavis.edu/lang_study.pdf . Cả hai đều cho thấy rằng càng tinh khiết, càng nhiều chức năng, càng biểu cảm và ngôn ngữ càng an toàn thì càng ít lỗi. Tương tự, cả hai đều cho thấy Clojure và Ruby thoát khỏi quy tắc An toàn, có thể chỉ ra rằng Tương tác có tác động tương đương như bạn đã chỉ ra.

— Didier A.

@DidierA. Thật không may, liên kết ucdavis bị hỏng (không có kho lưu trữ wbm) - Tôi nghĩ rằng bạn đã nhận được nó từ trang của Prem Devanbu , hiện chỉ đến một liên kết được cập nhật: Một nghiên cứu quy mô lớn về ngôn ngữ lập trình và chất lượng mã trong Github

— icc97

5

Ngôn ngữ càng kém mạnh mẽ thì càng ít lựa chọn để bạn tự bắn vào chân mình.

Các ngôn ngữ cấp cao như Java và C # sẽ tạo ra ít lỗi hơn các ngôn ngữ cấp thấp như C ++.

Phải nói rằng tôi tin rằng Java an toàn hơn C #. Java bị giới hạn một cách giả tạo để một lập trình viên trung bình không có kiến thức nâng cao có thể làm chủ được nó và tạo ra các chương trình ổn định.

— dùng8685
nguồn

4

+1 cho "Ngôn ngữ càng kém mạnh mẽ thì càng ít tùy chọn để bạn tự bắn vào chân mình".

— Michael K

Biểu đồ từ missfaktor dường như nói rằng C # và C ++ đang ở "bước chân" ngang bằng với khả năng tự bắn vào đó và nâng Java lên trên mức đó. Tuy nhiên, không phải tôi đồng ý với phần đó của biểu đồ. Bạn bị buộc phải đi qua các vòng để thực hiện một số cảnh quay C #.

— Jesse C. Choper

6

An toàn và sức mạnh không tỷ lệ nghịch (đó là những gì bạn dường như nghĩ ;-) Haskell, chẳng hạn, là TUYỆT VỜI mạnh mẽ và có rất ít cách để tự bắn vào chân mình.

— missingfaktor

3

Nếu ngôn ngữ yếu, bạn chỉ cần một bàn chân lớn hơn.

7

@missingfaktor, đó là vì nó là tác dụng phụ để tự bắn vào chân mình.

3

Theo bạn, ngôn ngữ nào cho phép lập trình viên trung bình xuất ra các tính năng với ít lỗi khó tìm nhất?

Theo tôi, Delphi. Dựa trên Pascal, ngôn ngữ đủ đơn giản và trực quan để lập trình viên trung bình (hoặc thậm chí là lập trình viên thiếu kinh nghiệm) dễ dàng tiếp nhận, và công cụ phong phú và hỗ trợ thư viện của nó giúp dễ dàng tìm thấy hầu hết các lỗi.

Gõ mạnh và một trình biên dịch nghiêm ngặt bắt được nhiều lỗi phổ biến.
Cú pháp trực quan không khuyến khích các lỗi phổ biến. ("Lỗi cuối cùng của thế giới" if (alert = RED) {LaunchNukes;}, chẳng hạn, sẽ không biên dịch.)
Một mô hình đối tượng được thiết kế tốt giúp loại bỏ nhiều lỗi OOP C ++ phổ biến.
Kiểm tra giới hạn và kiểm tra phạm vi được tích hợp trong ngôn ngữ, giảm đáng kể khả năng xảy ra sự cố bảo mật.
Có lẽ là trình biên dịch nhanh nhất mà con người biết đến, giúp tăng năng suất của bạn và làm cho việc mất đi sự suy nghĩ của bạn trong khi chờ đợi vào một bản dựng.
Trình gỡ lỗi Visual Studio của trình gỡ lỗi muốn giống như khi nó lớn lên.
Theo dõi rò rỉ được tích hợp trực tiếp vào trình quản lý bộ nhớ, khiến việc tìm và sửa lỗi rò rỉ bộ nhớ trở nên tầm thường.
Một thư viện tiêu chuẩn lớn, trưởng thành cung cấp các cách dựng sẵn và thử nghiệm trước để hoàn thành các nhiệm vụ chung mà không phải xây dựng các triển khai có lỗi của riêng bạn.
Tàu với các công cụ hữu ích, chẳng hạn như một hệ thống ghi nhật ký mạnh mẽ và một hồ sơ, để làm cho việc theo dõi các vấn đề dễ dàng hơn.
Hỗ trợ cộng đồng mạnh mẽ cho các vấn đề phổ biến không có trong thư viện tiêu chuẩn, bao gồm thư viện đồng thời mạnh mẽ của bên thứ ba .

— Mason Wheeler
nguồn

Tôi là một tay đua Delphi từ đường trở về, nhưng nó đã đi xa khỏi gốc rễ Pascal khi nó cho phép tôi đánh máy bất cứ thứ gì khác, a la C / C ++:var I: Integer; Pointer(I)^ := $00;

— Jesse C. Choper

1

@Jlie: Có lẽ, nhưng tôi thấy đó là một sự nhượng bộ cần thiết cho chủ nghĩa thực dụng. Kernighan đã có rất nhiều điểm tốt khi ông viết Tại sao Pascal không phải là ngôn ngữ lập trình yêu thích của tôi. Kiểu chữ là cần thiết để có được nhiều thứ quan trọng cấp thấp được thực hiện. Nhưng một trong những điểm mạnh của Delphi là cách các thư viện của nó gói gọn các chi tiết cấp thấp và làm cho hầu hết các con trỏ không an toàn và các công cụ typecast không cần thiết.

— Mason Wheeler

Tôi không đồng ý rằng điều đó có thể là cần thiết - nhưng tuyên bố Typing mạnh có phần bị phủ nhận bởi điều này. Pascal gốc không cho phép các shenanigans như vậy và do đó được đánh máy mạnh mẽ. Nhưng tôi sẽ không đi quá xa để gọi Delphi đánh máy yếu - đó là loại 'gõ vừa phải'.

— Jesse C. Choper

1

@Jlie: Không phải phiên bản Wirth ban đầu của Pascal có cho phép các bản ghi biến thể không? IIRC cuối cùng họ đã trở nên phổ biến để sử dụng để đánh máy mạnh mẽ đến nỗi Borland và những người khác quyết định chỉ đưa các kiểu chữ vào để làm cho nó đơn giản hơn vì mọi người đều làm việc đó.

— Mason Wheeler

en.wikipedia.org/wiki/Pascal_(programming_language)#Divisions và en.wikipedia.org/wiki/Pascal_(programming_language)#Criticism cũng như pascal-central.com/ppl/chapter3.html dường như chỉ ra nó là một phần của tiêu chuẩn đầu tiên vào năm 1983. Tôi thấy một số tài liệu tham khảo của Wirth dường như có từ năm 1974, vì vậy tôi nói có. Tôi nghĩ rằng phần có vấn đề đã cho phép nó bị lật đổ như vậy (iethe các trường biến thể có cùng bộ nhớ, giống như các hiệp hội trong C). Nếu chúng chỉ đơn giản được sử dụng như một cơ chế phạm vi và bố cục bộ nhớ dành cho superset, thì nó sẽ được gõ mạnh hơn.

— Jesse C. Choper

2

Một điều cần tính đến là thời gian quay vòng.

Trong khoảng 5 năm trở lại đây, tôi chủ yếu phát triển các ứng dụng web bằng java (JSF, Seam, v.v.). Gần đây tôi có một công việc mới và chúng tôi đang sử dụng Perl (với Catalyst và Moose).

Tôi làm việc hiệu quả hơn ở Perl, hơn tôi ở Java.

Không cần phải biên dịch và triển khai (nóng), là một lý do. Tôi cũng thấy rằng các trường hợp sử dụng bằng văn bản là dễ dàng hơn, vì nó có thể được thực hiện theo cách lặp nhiều hơn. Và các khung công tác trong Java dường như phức tạp không cần thiết, ít nhất là đối với các dự án tôi đã tham gia.

Tôi đoán số lượng lỗi trong mã Perl của tôi ít nhiều giống với số lỗi trong mã Java của tôi, nó thậm chí có thể cao hơn. Nhưng, tôi thấy et dễ dàng hơn và nhanh hơn để tìm và sửa các lỗi này.

— slu
nguồn

1

Có lẽ việc khảo sát số lượng công cụ có sẵn để phân tích mã tĩnh và động cho mọi ngôn ngữ lập trình có thể đưa ra ý tưởng. Càng nhiều công cụ cho một ngôn ngữ, nhiều khả năng ngôn ngữ này rất phổ biến đối với người dùng hoặc rất phổ biến trong việc tạo ra các lỗi khó tìm. Nhưng tôi không thể khiến Google chỉ cho tôi bất kỳ nghiên cứu nào được thực hiện về chủ đề này. Cũng cần lưu ý rằng một số ngôn ngữ như C có thể được sử dụng để khắc phục các lỗi phần cứng cơ bản cũng như khắc phục sự hao mòn của phần cứng khi có tuổi.

— vpit3833
nguồn

1

"Làm việc xung quanh sự hao mòn của phần cứng khi nó già đi" ...?

— j_random_hacker

Tôi đã đọc được rằng một số hệ điều hành Unix chạy trên các máy quan trọng, kiểm tra sức khỏe của CPU, RAM và các phần cứng khác. serverfault.com/questions/56192/ trên thảo luận về vấn đề này. Nếu một số dòng trong mô-đun RAM bị lỗi theo thời gian, các mô-đun bị lỗi đó sẽ không được HĐH sử dụng và nó sẽ không báo cáo chúng trong tổng bộ nhớ vật lý có sẵn. Những điều như vậy có thể được thực hiện trên phần cứng khác là tốt.

— vpit3833

Đó là một miếng ngon thú vị, nhưng tôi không thấy nó có liên quan ở đây. Ngoài ra, không có gì trong liên kết của bạn đề cập đến các hệ điều hành Unix tự sửa chữa này - nó chỉ nói về các cách để kiểm tra căng thẳng phần cứng của PC.

— j_random_hacker

1

Tôi đã đề cập đến nó có nghĩa là các chương trình một mình có thể không phải là nguồn gây ra lỗi, nó cũng có thể là phần cứng hoặc các yếu tố bên ngoài khác.

— vpit3833

1

Thay vì nói về ngôn ngữ, nói về ngôn ngữ là gì

java buộc bạn phải suy nghĩ về các ngoại lệ (ném ...) và bạn phải publisch hoặc xử lý các ngoại lệ này. Điều đó có thực sự ngăn tôi quên các lỗi sai hay tôi đang sử dụng nhiều ngoại lệ xuất phát từ SystemException không cần xử lý này?
những gì về "thiết kế theo hợp đồng" (http://en.wikipedia.org/wiki/Design_by_contract) buộc tôi phải suy nghĩ về trước và hậu điều kiện. Tôi đã đọc rằng bây giờ có thể với c # -4.0.

— k3b
nguồn