Lỗ hổng thiết kế lớn nhất bạn gặp phải trong bất kỳ ngôn ngữ lập trình nào? [đóng cửa]

Tất cả các ngôn ngữ lập trình đều có lỗi thiết kế đơn giản vì không một ngôn ngữ nào có thể hoàn hảo, giống như với hầu hết (tất cả?) Những thứ khác. Điều đó sang một bên, lỗi thiết kế nào trong ngôn ngữ lập trình đã làm bạn khó chịu nhất trong suốt lịch sử làm lập trình viên?

Lưu ý rằng nếu một ngôn ngữ "xấu" chỉ vì nó không được thiết kế cho một thứ cụ thể thì đó không phải là lỗi thiết kế, mà là một tính năng của thiết kế, vì vậy đừng liệt kê những phiền toái như vậy của ngôn ngữ. Nếu một ngôn ngữ được sử dụng cho những gì nó được thiết kế cho, đó tất nhiên là một lỗ hổng trong thiết kế. Thực hiện những điều cụ thể và dưới mui xe những điều không được tính.

Một trong những phiền toái lớn của tôi là cách switchcác trường hợp trong các ngôn ngữ có nguồn gốc C mặc định rơi vào trường hợp tiếp theo nếu bạn quên sử dụng break. Tôi hiểu rằng điều này hữu ích trong mã cấp độ rất thấp (ví dụ: Thiết bị của Duff ), nhưng nó thường không phù hợp với mã cấp ứng dụng và là nguồn phổ biến của lỗi mã hóa.

Tôi nhớ vào khoảng năm 1995 khi tôi đọc về các chi tiết của Java lần đầu tiên, khi tôi đến phần về switchtuyên bố tôi đã rất thất vọng vì họ đã giữ lại hành vi rơi vào mặc định. Điều này chỉ làm cho switchmột vinh quang gotovới một tên khác.

Tôi chưa bao giờ thực sự thích sử dụng =để chuyển nhượng và ==kiểm tra công bằng trong các ngôn ngữ có nguồn gốc C. Khả năng nhầm lẫn và sai sót là quá cao. Và thậm chí đừng để tôi bắt đầu ===trong Javascript.

Tốt hơn nên có sự :=phân công và =kiểm tra bình đẳng. Các ngữ nghĩa có thể giống hệt như ngày nay, trong đó phép gán là một biểu thức cũng tạo ra một giá trị.

Sự lựa chọn +trong Javascript cho cả bổ sung và nối chuỗi là một sai lầm khủng khiếp. Vì các giá trị được gỡ bỏ, điều này dẫn đến các quy tắc byzantine xác định xem +sẽ thêm hoặc ghép, tùy thuộc vào nội dung chính xác của mỗi toán hạng.

Ban đầu, thật dễ dàng để giới thiệu một toán tử hoàn toàn mới, chẳng hạn như $nối chuỗi.

Tôi thấy Javascript mặc định là toàn cầu đối với một vấn đề lớn và thường là nguồn lỗi nếu bạn không sử dụng JSLint hoặc tương tự

Bộ tiền xử lý trong C và C ++ là một khối lượng lớn, tạo ra các bản tóm tắt rò rỉ như sàng, khuyến khích mã spaghetti thông qua các #ifdefcâu lệnh của chuột và yêu cầu các ALL_CAPStên không thể đọc được khủng khiếp để khắc phục các hạn chế của nó. Căn nguyên của những vấn đề này là nó hoạt động ở cấp độ văn bản chứ không phải ở cấp độ cú pháp hay ngữ nghĩa. Nó nên được thay thế bằng các tính năng ngôn ngữ thực cho các trường hợp sử dụng khác nhau của nó. Dưới đây là một số ví dụ, mặc dù phải thừa nhận một số trong số này được giải quyết trong C ++, C99 hoặc các phần mở rộng tiêu chuẩn không chính thức nhưng thực tế :

• #include nên được thay thế bằng một hệ thống mô-đun thực sự.

• Các hàm nội tuyến và các mẫu / tổng quát có thể thay thế hầu hết các trường hợp sử dụng lệnh gọi hàm.

• Một số loại tính năng hằng số thời gian biểu hiện / biên dịch có thể được sử dụng để khai báo các hằng số đó. Phần mở rộng của enum làm việc tuyệt vời ở đây.

• Các macro cấp độ cú pháp thực có thể giải quyết rất nhiều trường hợp sử dụng linh tinh.

• Mixins chuỗi có thể được sử dụng cho trường hợp sử dụng mã tiêm.

• static ifhoặc versionbáo cáo có thể được sử dụng để biên dịch có điều kiện.

Người ta có thể liệt kê hàng trăm lỗi trong hàng trăm ngôn ngữ, nhưng IMO nó không phải là một bài tập hữu ích từ quan điểm thiết kế ngôn ngữ.

Tại sao?

Bởi vì một cái gì đó sẽ là một lỗi trong một ngôn ngữ sẽ không phải là một sai lầm trong ngôn ngữ khác. Ví dụ:

• Biến C thành ngôn ngữ được quản lý (tức là rác được thu thập) hoặc loại bỏ các kiểu nguyên thủy sẽ hạn chế tính hữu dụng của nó như là ngôn ngữ cấp thấp bán di động.
• Thêm quản lý bộ nhớ kiểu C vào Java (ví dụ: để giải quyết các mối quan tâm về hiệu năng) sẽ phá vỡ nó.

Có những bài học để học, nhưng những bài học hiếm khi được cắt rõ ràng, và để hiểu chúng, bạn phải hiểu sự đánh đổi kỹ thuật ... và bối cảnh lịch sử. (Ví dụ, việc triển khai Java chung chung cồng kềnh là kết quả của yêu cầu kinh doanh vượt trội để duy trì khả năng tương thích ngược.)

IMO, nếu bạn nghiêm túc trong việc thiết kế một ngôn ngữ mới, bạn thực sự cần phải sử dụng một loạt các ngôn ngữ hiện có (và nghiên cứu ngôn ngữ lịch sử) ... và tự khắc phục lỗi của mình là gì. Và bạn cần nhớ rằng mỗi ngôn ngữ này được thiết kế trong một bối cảnh lịch sử cụ thể, để đáp ứng một nhu cầu cụ thể.

Nếu có những bài học chung để học, chúng ở cấp độ "meta":

• Bạn không thể thiết kế một ngôn ngữ lập trình lý tưởng cho mọi mục đích.
• Bạn không thể tránh phạm sai lầm ... đặc biệt là khi nhìn từ tầm nhìn xa.
• Nhiều sai lầm là đau đớn để sửa chữa ... cho người dùng ngôn ngữ của bạn.
• Bạn phải tính đến nền tảng và kỹ năng của đối tượng mục tiêu của bạn; tức là lập trình viên hiện có.
• Bạn không thể làm hài lòng mọi người.

C và C ++ : Tất cả những loại số nguyên đó không có nghĩa gì cả.

Đặc biệt char. Nó là văn bản hay nó là một số nguyên nhỏ? Nếu là văn bản, nó là ký tự "ANSI" hay đơn vị mã UTF-8? Nếu đó là một số nguyên, nó được ký hoặc không dấu?

int được dự định là số nguyên có kích thước "gốc", nhưng trên các hệ thống 64 bit, thì không.

longcó thể hoặc không thể lớn hơn int. Nó có thể hoặc không thể là kích thước của một con trỏ. Đó là một quyết định tùy ý về phía người viết trình biên dịch cho dù đó là 32 bit hay 64 bit.

Chắc chắn là một ngôn ngữ của những năm 1970. Trước Unicode. Trước máy tính 64 bit.

null.

Nhà phát minh của nó, Tony Hoare, gọi đó là "sai lầm tỷ đô" .

Nó được giới thiệu trong ALGOL vào những năm 60 và tồn tại trong hầu hết các ngôn ngữ lập trình được sử dụng phổ biến hiện nay.

Sự thay thế tốt hơn, được sử dụng trong các ngôn ngữ như OCaml và Haskell, là có thể . Ý tưởng chung là các tham chiếu đối tượng không thể rỗng / trống / không tồn tại trừ khi có một dấu hiệu rõ ràng rằng chúng có thể là như vậy.

(Mặc dù sự khiêm tốn của Tony rất tuyệt vời, tôi nghĩ rằng hầu hết mọi người đều mắc phải sai lầm tương tự, và anh ta chỉ là người đầu tiên.)

Tôi có cảm giác rằng những người thiết kế PHP không sử dụng bàn phím bình thường, họ thậm chí không sử dụng bàn phím colemak, vì họ nên nhận ra họ đang làm gì.

Tôi là một nhà phát triển PHP. PHP không thú vị để gõ.

Who::in::their::right::mind::would::do::this()? Các ::nhà điều hành đòi hỏi sự thay đổi tổ chức và sau đó hai phím bấm. Thật là một sự lãng phí năng lượng.

Mặc dù-> này-> là-> không-> nhiều-> tốt hơn. Điều đó cũng đòi hỏi ba lần nhấn phím với sự thay đổi ở giữa hai biểu tượng.

$last = $we.$have.$the.$dumb.'$'.$character. Ký hiệu đô la được sử dụng rất nhiều lần và yêu cầu giải thưởng kéo dài đến tận cùng của bàn phím cộng với nhấn phím shift.

Tại sao họ không thể thiết kế PHP để sử dụng các khóa nhanh hơn để gõ? Tại sao không thể we.do.this()hoặc có các vars bắt đầu bằng một khóa chỉ yêu cầu một lần nhấn phím - hoặc hoàn toàn không (JavaScript) và chỉ xác định trước tất cả các vars (như tôi phải làm cho E_STRICT bằng mọi cách)!

Tôi không phải là người đánh máy chậm - nhưng đây chỉ là một sự lựa chọn thiết kế khập khiễng.

Việc sử dụng các hình thức lấy cảm hứng từ máy tính để bàn trong asp.net .

Nó luôn cảm thấy khó chịu và cản trở hoặc cách thức hoạt động của web. Rất may, asp.net-mvc không bị như vậy, mặc dù có tín dụng với Ruby, v.v. cho cảm hứng đó.

Đối với tôi, đó là sự thiếu hoàn toàn các quy ước đặt tên và lập luận của PHP trong thư viện chuẩn của nó.

Mặc dù sự cần thiết của JASS để vô hiệu hóa các tham chiếu sau khi đối tượng được tham chiếu được giải phóng / xóa (hoặc tham chiếu sẽ bị rò rỉ và một vài byte bộ nhớ sẽ bị mất) nghiêm trọng hơn, nhưng vì JASS là ngôn ngữ có mục đích duy nhất, nhưng điều đó không quan trọng.

Lỗ hổng thiết kế lớn nhất mà tôi gặp phải là python không được thiết kế như python 3.x để bắt đầu.

Mảng phân rã trong C và do đó C ++.

Các kiểu nguyên thủy trong Java.

Họ phá vỡ nguyên tắc rằng mọi thứ đều là hậu duệ java.lang.Object, từ quan điểm lý thuyết dẫn đến sự phức tạp thêm của đặc tả ngôn ngữ, và từ góc độ thực tế, họ sử dụng các bộ sưu tập vô cùng tẻ nhạt.

Autoboxing đã giúp giảm bớt những hạn chế thực tế nhưng với chi phí làm cho đặc tả trở nên phức tạp hơn và giới thiệu một vỏ chuối to béo: bây giờ bạn có thể có một ngoại lệ con trỏ null từ hoạt động số học đơn giản.

Tôi biết Perl tốt nhất, vì vậy tôi sẽ chọn nó.

Perl đã thử nhiều ý tưởng. Một số đã tốt. Một số là xấu. Một số là bản gốc và không được sao chép rộng rãi vì lý do tốt.

Một là ý tưởng về bối cảnh - mọi cuộc gọi chức năng diễn ra trong danh sách hoặc bối cảnh vô hướng và có thể thực hiện những điều hoàn toàn khác nhau trong mỗi bối cảnh. Như tôi đã chỉ ra tại http://use.perl.org/~btilly/journal/36756 điều này làm phức tạp mọi API và thường dẫn đến các vấn đề thiết kế tinh tế trong mã Perl.

Tiếp theo là ý tưởng buộc kiểu cú pháp và kiểu dữ liệu hoàn toàn. Điều này dẫn đến việc phát minh ra cà vạt để cho phép các đối tượng giả trang thành các loại dữ liệu khác. (Bạn cũng có thể đạt được hiệu ứng tương tự bằng cách sử dụng quá tải, nhưng buộc là cách tiếp cận phổ biến hơn trong Perl.)

Một lỗi phổ biến khác, được thực hiện bởi nhiều ngôn ngữ, là bắt đầu bằng cách cung cấp phạm vi động thay vì từ vựng. Thật khó để hoàn nguyên quyết định thiết kế này sau đó, và dẫn đến mụn cóc kéo dài. Mô tả kinh điển về những mụn cóc trong Perl là http://perl.plover.com/FAQs/Namespaces.html . Lưu ý rằng điều này đã được viết trước khi Perl thêm ourcác biến và staticbiến.

Mọi người hợp pháp không đồng ý về gõ tĩnh so với động. Cá nhân tôi thích gõ động. Tuy nhiên, điều quan trọng là phải có đủ cấu trúc để bắt lỗi chính tả. Perl 5 làm tốt công việc này với sự nghiêm ngặt. Nhưng Perl 1-4 đã sai điều này. Một số ngôn ngữ khác có trình kiểm tra lint làm điều tương tự như nghiêm ngặt. Miễn là bạn giỏi về việc thực thi kiểm tra xơ vải, điều đó có thể chấp nhận được.

Nếu bạn đang tìm kiếm nhiều ý tưởng tồi hơn (rất nhiều trong số đó), hãy tìm hiểu PHP và nghiên cứu lịch sử của nó. Lỗi quá khứ yêu thích của tôi (đã được sửa từ lâu vì nó dẫn đến rất nhiều lỗ hổng bảo mật) đã được mặc định cho phép bất kỳ ai đặt bất kỳ biến nào bằng cách chuyển các tham số của biểu mẫu. Nhưng đó là xa sai lầm duy nhất.

JavaScripts mơ hồ cho các khối mã và các đối tượng bằng chữ.

  {a:b}

có thể là một khối mã, trong đó alà một nhãn và blà một biểu thức; hoặc nó có thể định nghĩa một đối tượng, với một thuộc tính acó giá trịb

Tôi sẽ quay trở lại FORTRAN và sự vô cảm của khoảng trắng.

Nó tràn ngập các đặc điểm kỹ thuật. Các ENDthẻ đã được định nghĩa như là một thẻ với một 'E', chữ 'N', và 'D' theo thứ tự trên cột 7-72, và không có nonblanks khác, chứ không phải là một thẻ với "END" trong hợp cột và không có gì khác.

Nó dẫn đến sự nhầm lẫn cú pháp dễ dàng. DO 100 I = 1, 10là một câu lệnh điều khiển vòng lặp, trong khi đó DO 100 I = 1. 10là một câu lệnh gán giá trị 1.1 cho một biến được gọi DO10I. (Thực tế là các biến có thể được tạo mà không cần khai báo, loại của chúng tùy thuộc vào chữ cái đầu tiên của chúng, đã góp phần vào điều này.) Không giống như các ngôn ngữ khác, không có cách nào sử dụng khoảng trắng để tách mã thông báo để cho phép định hướng.

Nó cũng cho phép người khác viết mã thực sự khó hiểu. Có nhiều lý do tại sao tính năng này của FORTRAN không bao giờ bị trùng lặp nữa.

Một trong những vấn đề lớn nhất với BASIC là thiếu phương pháp được xác định rõ ràng để mở rộng ngôn ngữ ngoài môi trường ban đầu của nó, dẫn đến một loạt các triển khai hoàn toàn không tương thích (và một nỗ lực hậu thực tế gần như không liên quan ở bất kỳ tiêu chuẩn hóa nào).

Hầu như bất kỳ ngôn ngữ nào sẽ bị bẻ cong vào mục đích sử dụng chung của một số lập trình viên điên rồ. Tốt hơn là lên kế hoạch cho việc sử dụng cho mục đích chung đó ngay từ đầu trong trường hợp ý tưởng điên rồ đó được thực hiện.

Tôi tin vào DSL (ngôn ngữ dành riêng cho tên miền) và một điều tôi đánh giá cao trong ngôn ngữ là nếu nó cho phép tôi xác định DSL trên đầu trang.

Trong Lisp có macro - hầu hết mọi người coi đây là một điều tốt, cũng như tôi.

Trong C và C ++ có các macro - mọi người phàn nàn về chúng, nhưng tôi đã có thể sử dụng chúng để xác định DSL.

Trong Java, họ bị bỏ rơi (và do đó trong C #) và việc thiếu chúng được tuyên bố là một đức tính tốt. Chắc chắn rằng nó cho phép bạn có intellisense, nhưng với tôi đó chỉ là một oeuvre . Để thực hiện DSL của tôi, tôi phải mở rộng bằng tay. Đó là một nỗi đau, và nó khiến tôi trông giống như một lập trình viên tồi, mặc dù điều đó cho phép tôi làm được rất nhiều việc với rất ít mã.

Tuyên bố , trong mọi ngôn ngữ có chúng. Họ không làm gì mà bạn không thể làm với biểu thức và ngăn bạn làm nhiều việc. Sự tồn tại của một ?:nhà điều hành ternary chỉ là một ví dụ về việc phải cố gắng để có được xung quanh họ. Trong JavaScript, chúng đặc biệt khó chịu:

// With statements:
node.listen(function(arg) {
  var result;
  if (arg) {
    result = 'yes';
  } else {
    result = 'no';
  }
  return result;
})

// Without:
node.listen(function(arg) if (arg) 'yes' else 'no')

Đối với tôi, đó là vấn đề thiết kế gây khó chịu cho tất cả các ngôn ngữ có nguồn gốc từ C; cụ thể là " lủng lẳng khác ." Vấn đề ngữ pháp này đã được giải quyết trong C ++, nhưng nó đã được chuyển sang Java và C #.

Tôi nghĩ rằng tất cả các câu trả lời đều chỉ ra một thất bại của nhiều ngôn ngữ chính:

Không có cách nào để thay đổi ngôn ngữ cốt lõi mà không ảnh hưởng đến khả năng tương thích ngược.

Nếu điều này được giải quyết thì khá nhiều tất cả những sự kìm kẹp khác có thể được giải quyết.

CHỈNH SỬA.

điều này có thể được giải quyết trong các thư viện bằng cách có các không gian tên khác nhau và bạn có thể hình dung làm một cái gì đó tương tự cho hầu hết cốt lõi của ngôn ngữ, mặc dù điều này có thể có nghĩa là bạn cần hỗ trợ nhiều trình biên dịch / trình thông dịch.

Cuối cùng, tôi không nghĩ rằng tôi biết cách giải quyết nó theo cách hoàn toàn thỏa đáng, nhưng điều đó không có nghĩa là một giải pháp không tồn tại, hoặc không thể làm được nhiều hơn thế

Tràn số học số nguyên im lặng của Java

Cả Java và C # đều có vấn đề gây khó chịu với các hệ thống loại của chúng do mong muốn duy trì khả năng tương thích ngược trong khi thêm tổng quát. Java không thích trộn chung và mảng; C # sẽ không cho phép một số chữ ký hữu ích vì bạn không thể sử dụng các loại giá trị làm giới hạn.

Như một ví dụ về cái sau, hãy xem xét rằng

công khai tĩnh T Parse <T> (Loại <T> loại, chuỗi str) trong đó T: Enum

đối tượng tĩnh công khai Parse (Kiểu kiểu, chuỗi str)

MyEnum e = Enum.Pude (typeof (MyEnum), str);

MyEnum e = (MyEnum) Enum.Pude (typeof (MyEnum), str);

tl; dr: nghĩ về đa hình tham số khi bạn bắt đầu thiết kế hệ thống loại của mình, không phải sau khi bạn xuất bản phiên bản 1.

Tôi cảm thấy như mình đang mở ra để nổi bần bật, nhưng tôi thực sự ghét khả năng truyền các kiểu dữ liệu cũ đơn giản bằng cách tham chiếu trong C ++. Tôi chỉ hơi ghét việc có thể vượt qua các loại phức tạp bằng cách tham khảo. Nếu tôi đang xem một chức năng:

void foo()
{
    int a = 8;
    bar(a);
}

Từ điểm gọi, không có cách nào để nói rằng bar, có thể được xác định trong một tệp hoàn toàn khác, là:

void bar(int& a)
{
    a++;
}

Một số người có thể lập luận rằng làm một cái gì đó như thế này có thể chỉ là một thiết kế phần mềm tồi và không đổ lỗi cho ngôn ngữ, nhưng tôi không thích ngôn ngữ đó cho phép bạn làm điều này ngay từ đầu. Sử dụng một con trỏ và gọi

bar(&a);

dễ đọc hơn nhiều

THAY ĐỔI

Khi tôi học COBOL, câu lệnh ALTER vẫn là một phần của tiêu chuẩn. Tóm lại, tuyên bố này sẽ cho phép bạn sửa đổi các cuộc gọi thủ tục trong thời gian chạy.

Điều nguy hiểm là bạn có thể đặt câu lệnh này trong một số đoạn mã tối nghĩa hiếm khi được truy cập và nó có khả năng thay đổi hoàn toàn dòng chảy của phần còn lại của chương trình. Với nhiều câu lệnh ALTER, bạn có thể làm cho gần như không thể biết chương trình của bạn đang làm gì vào bất kỳ thời điểm nào.

Người hướng dẫn đại học của tôi, rất nhấn mạnh, tuyên bố rằng nếu anh ta thấy câu nói đó trong bất kỳ chương trình nào của chúng tôi, anh ta sẽ tự động bỏ rơi chúng tôi.

Tội lỗi tồi tệ nhất của ngôn ngữ lập trình là không được xác định rõ. Một trường hợp tôi nhớ là C ++, trong nguồn gốc của nó:

1. Đã bị định nghĩa quá tệ đến nỗi bạn không thể có được một chương trình để biên dịch và chạy bằng cách làm theo các cuốn sách hoặc ví dụ.
2. Khi bạn đã điều chỉnh chương trình để biên dịch và chạy trong một trình biên dịch và HĐH, bạn sẽ phải bắt đầu lại nếu bạn chuyển đổi trình biên dịch hoặc nền tảng.

Theo tôi nhớ, phải mất khoảng một thập kỷ để C ++ được định nghĩa đủ tốt để khiến nó trở nên đáng tin cậy về chuyên môn như C. Đó là điều không bao giờ nên xảy ra nữa.

Một cái gì khác tôi coi là một tội lỗi (nó có nên đi theo một câu trả lời khác không?) Đang có nhiều hơn một cách "tốt nhất" để thực hiện một số nhiệm vụ chung. Đó là trường hợp của (một lần nữa) C ++, Perl và Ruby.

Các lớp trong C ++ là một số kiểu mẫu thiết kế bắt buộc trong ngôn ngữ.

Thực tế không có sự khác biệt nào trong thời gian chạy giữa một cấu trúc và một lớp, và thật khó hiểu khi hiểu lợi thế lập trình thực sự của "ẩn thông tin" là gì mà tôi muốn đặt nó ở đó.

Tôi sẽ bị hạ thấp vì điều đó, nhưng dù sao, trình biên dịch C ++ rất khó để viết ngôn ngữ này cảm thấy như một con quái vật.

Mặc dù mọi ngôn ngữ đều có lỗi, nhưng không có gì phiền toái khi bạn biết về chúng. Ngoại trừ cặp này:

Cú pháp phức tạp kết hợp với API dài dòng

Điều này đặc biệt đúng với một ngôn ngữ như Objective-C. Cú pháp không chỉ phức tạp quá mức mà API còn sử dụng các tên hàm như:

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath

Tôi là tất cả vì rõ ràng và không mơ hồ, nhưng điều này là vô lý. Mỗi lần tôi ngồi xuống với xcode, tôi cảm thấy như một n00b, và điều đó thực sự gây nản lòng.

1. ký tự ký tự trong C - một sự ghê tởm được phát minh để cho các nhà toán học có bộ sưu tập lớn các vật phẩm nhỏ
2. Sử dụng trường hợp để mang nội dung ngữ nghĩa - một lần nữa cho các nhà toán học, những người không cần nói chuyện và không bao giờ có đủ không gian cho các công thức của họ
3. Tôi cho phép gán / đơn giản so với Đặt gán trong phương ngữ cơ bản - tôi nghĩ không có nhà toán học nào tham gia ở đây