Năm điều bạn ghét về ngôn ngữ yêu thích của bạn là gì? [đóng cửa]

Gần đây đã có một nhóm Perl-ghét trên Stack Overflow, vì vậy tôi nghĩ rằng tôi sẽ mang câu hỏi " Năm điều bạn ghét về ngôn ngữ yêu thích của bạn " cho Stack Overflow. Lấy ngôn ngữ yêu thích của bạn và cho tôi biết năm điều bạn ghét về nó. Đó có thể là những điều khiến bạn khó chịu, thừa nhận lỗi thiết kế, các vấn đề về hiệu suất được công nhận hoặc bất kỳ danh mục nào khác. Bạn chỉ cần ghét nó, và nó phải là ngôn ngữ yêu thích của bạn.

Đừng so sánh nó với ngôn ngữ khác và đừng nói về những ngôn ngữ mà bạn đã ghét. Đừng nói về những điều bạn thích bằng ngôn ngữ yêu thích của bạn. Tôi chỉ muốn nghe những điều mà bạn ghét nhưng chịu đựng để bạn có thể sử dụng tất cả những thứ khác, và tôi muốn nghe về ngôn ngữ mà bạn muốn người khác sẽ sử dụng.

Tôi hỏi điều này bất cứ khi nào ai đó cố gắng đẩy ngôn ngữ yêu thích của họ lên tôi, và đôi khi là một câu hỏi phỏng vấn. Nếu ai đó không thể tìm thấy năm điều đáng ghét về công cụ yêu thích của mình, anh ta sẽ không biết rõ về nó để ủng hộ nó hoặc kiếm được số tiền lớn khi sử dụng nó. Anh ta đã không sử dụng nó trong các tình huống đủ khác nhau để khám phá nó hoàn toàn. Anh ấy ủng hộ nó như một nền văn hóa hoặc tôn giáo, điều đó có nghĩa là nếu tôi không chọn công nghệ yêu thích của anh ấy, tôi đã sai.

Tôi không quan tâm đến việc bạn sử dụng ngôn ngữ nào. Không muốn sử dụng một ngôn ngữ cụ thể? Vậy thì đừng. Bạn có cần mẫn để đưa ra lựa chọn sáng suốt mà vẫn không sử dụng nó? Khỏe. Đôi khi câu trả lời đúng là "Bạn có một đội ngũ lập trình mạnh với các thực tiễn tốt và nhiều kinh nghiệm trong Bar. Thay đổi thành Foo sẽ là ngu ngốc."

Đây là một câu hỏi tốt cho đánh giá mã quá. Những người thực sự biết một cơ sở mã sẽ có tất cả các loại đề xuất cho nó và những người không biết rõ về nó có những khiếu nại không cụ thể. Tôi hỏi những câu như "Nếu bạn có thể bắt đầu lại dự án này, bạn sẽ làm gì khác?" Ở vùng đất giả tưởng này, người dùng và lập trình viên có thể phàn nàn về bất cứ điều gì và mọi thứ họ không thích. "Tôi muốn có giao diện tốt hơn", "Tôi muốn tách mô hình khỏi chế độ xem", "Tôi sẽ sử dụng mô-đun này thay vì mô-đun khác", "Tôi đổi tên bộ phương thức này" hoặc bất cứ điều gì họ thực sự không Tôi không thích tình hình hiện tại. Đó là cách tôi nắm được số lượng nhà phát triển cụ thể biết về cơ sở mã. Nó cũng là một đầu mối về bao nhiêu lập trình viên '

Ghét không phải là chiều kích duy nhất để tìm hiểu xem mọi người biết bao nhiêu, nhưng tôi đã thấy nó là một thứ khá tốt. Những điều họ ghét cũng cho tôi manh mối họ nghĩ về chủ đề này tốt như thế nào.

Năm điều tôi ghét về Java:

• Không có chức năng hạng nhất.
• Không suy luận kiểu.
• Thiếu mặc định lành mạnh trong ví dụ đồ họa.
• NullPulumException không chứa thêm thông tin về những gì là null.
• Sự phổ biến của các khung / giao diện nhà cung cấp dịch vụ / các lớp nhà máy / hệ thống tiêm phụ thuộc vô nghĩa. Khả năng cấu hình gần như không bao giờ được sử dụng, DRY bị vi phạm nghiêm trọng, và mã tăng gấp bốn lần kích thước và một nửa về mức độ dễ đọc.

Tôi biết, tôi nên kiểm tra Scala.

Ồ, tôi ngạc nhiên khi SQL chưa xuất hiện ở đây. Đoán có nghĩa là không ai yêu nó :)

• Cú pháp không nhất quán trong quá trình thực hiện
• Sự khác biệt mã tinh tế có thể có sự phân nhánh hiệu suất lớn vì những lý do dường như tối nghĩa
• Hỗ trợ kém cho thao tác văn bản
• Chi phí đầu vào dễ dàng nhưng đường cong học tập dốc để làm chủ ngôn ngữ
• Tiêu chuẩn hóa tối thiểu trên toàn cộng đồng cho các thực tiễn tốt nhất, điều này bao gồm kiểu cú pháp.

... Và một vài lý do thưởng để ghét nó, không tính thêm phí

• mệnh đề WHERE đi sau cùng, giúp dễ dàng thực hiện sớm CẬP NHẬT hoặc XÓA, phá hủy toàn bộ bảng. Thay vào đó, WHERE nên đi đâu đó lên phía trước.
• Thật khó để thực hiện phân chia quan hệ.
• Tôi có thể đặt giá trị thành NULL, nhưng tôi không thể kiểm tra giá trị đó bằng với NULL. Tôi có thể kiểm tra IS NULL, nhưng theo tôi thì điều đó chỉ làm phức tạp mã - không cần thiết như vậy.
• Tại sao chúng ta cần phải hoàn toàn xác nhận lại công thức cho một cột NHÓM, thay vì đặt bí danh trên cột và sau đó NHÓM theo bí danh (hoặc chỉ mục cột như với SORT)?

JavaScript :

1. Tất cả những điều tuyệt vời nhất đều cực kỳ phức tạp, nhưng sau đó, tất cả sự mát mẻ cũng được gói gọn trong một số lượng mã nhỏ đến mức bạn cảm thấy ngu ngốc khi phải vật lộn để theo dõi nó

2. '+' là một lựa chọn vô lý của nhà điều hành để ghép nối trong một ngôn ngữ được gõ yếu. Có phải họ đang cố gắng để sợ các noobs?

3. Đó là một mỏ khai thác tương thích trình duyệt chéo (đừng bận tâm liệu nó có bật hay không)

4. Nói chung là không đáng tin cậy - liên quan đến các trò gian lận như chặn nút quay lại, cửa sổ bật lên không bao giờ chết, v.v.

5. Gần như không thể gỡ lỗi vì chỉ có một vài thông báo lỗi khác nhau và một vài loại khác nhau (Số, Chuỗi, Đối tượng, v.v.)

Nếu nó không dành cho jQuery, có lẽ tôi vẫn ghét nó nhiều như trước đây :)

PHP:

1) Buộc tôi thực hiện các biến không cần thiết:

$parts = explode('|', $string);
$first = $parts[0];

2) Việc triển khai lambdas rất khập khiễng tương đương với việc sử dụng eval()và rất sai lầm tôi chưa bao giờ sử dụng nó (xem http://www.php.net/create_feft ).

3) Một hệ thống thử / bắt chỉ có thể bắt được khoảng 80% lỗi có thể xảy ra.

4) Hỗ trợ Regex cũng khập khiễng như hỗ trợ lambda vì nó phải được viết bên trong các chuỗi thông thường, làm cho một trong những công cụ lập trình khó học nhất khó gấp ba lần. Và PHP được cho là một ngôn ngữ "dễ dàng"?!?!?

5) Không có cách nào có thể rút nội dung ra khỏi $ _POST một cách an toàn mà không cần viết hai lần hoặc xây dựng chức năng của riêng bạn hoặc sử dụng toán tử '@':

$x = isset($_POST['foo']['bar']) ? $_POST['foo']['bar'] : null;

6) Trả lời tiền thưởng: '@'. Nếu bạn không thể bận tâm viết mã chính xác, chỉ cần thêm '@' và quá tệ cho bất kỳ ai phải gỡ lỗi mã của bạn sau này.

C ++

• Quá dễ dàng để bộ nhớ bị hỏng ngẫu nhiên và tạo ra các lỗi gần như không thể tìm thấy (mặc dù, Valgrind đã đi một chặng đường dài để sửa lỗi này).
• Thông báo lỗi mẫu.
• Khi sử dụng các mẫu, thật dễ dàng để kết thúc mọi thứ trong một tệp và sau đó nhận được các lần biên dịch ngu ngốc.
• Thư viện chuẩn là một trò đùa trong thời hiện đại (mặc định vẫn không có chủ đề hoặc mạng?)
• Rất nhiều bit nhỏ khó chịu của C chọc qua (đặc biệt là tất cả các chuyển đổi giữa short / int / unsign / etc ..)

CNET:

• Các lớp nên được niêm phong theo mặc định
• Không nên có locktuyên bố - thay vào đó, bạn nên có các đối tượng khóa cụ thể và nên có các phương thức như Acquiretrả lại mã thông báo khóa dùng một lần. Hệ quả: không nên có màn hình cho mọi đối tượng.
• GetHashCode()và Equals()không nên ở trong System.Object- không phải mọi thứ đều phù hợp để băm. Thay vào đó, có một IdentityComparermà làm điều tương tự, và giữ cho IComparer<T>, IComparable<T>, IEqualityComparer<T>và IEquatable<T>giao diện để so sánh tùy chỉnh.
• Hỗ trợ kém cho sự bất biến
• Cách kém để khám phá các phương thức mở rộng - đó sẽ là một quyết định sáng suốt hơn nhiều so với thực tế là tôi đang sử dụng một không gian tên.

Những thứ đó nằm ngoài đỉnh đầu của tôi - hãy hỏi tôi vào ngày mai và tôi sẽ đưa ra một 5 khác nhau :)

C

• thao tác chuỗi.

Phải xử lý thủ công với bộ đệm chuỗi là một nỗi đau dễ bị lỗi. Vì rất nhiều máy tính thực sự di chuyển và sửa đổi các chuỗi (máy tính không được sử dụng nhiều cho các công cụ khủng hoảng số lượng lớn như mọi người nghĩ rằng chúng sẽ quay trở lại khi nào), thật tuyệt khi có thể sử dụng ngôn ngữ được quản lý hoặc chuỗi của C ++ đối tượng để đối phó với những điều này. Khi tôi phải làm điều đó trong C thẳng, cảm giác như bơi trong cát lún.

Làm thế nào về năm điều tôi ghét về danh sách "Những điều tôi ghét về một số ngôn ngữ"? : D

5- Vẽ một màu đỏ cam không làm cho nó trở thành một quả táo.

Khi một ngôn ngữ được thiết kế, các nhà thiết kế thường nghĩ rằng nó hữu ích cho việc gì. Sử dụng nó cho một cái gì đó hoàn toàn khác nhau có thể làm việc, nhưng phàn nàn khi nó không chỉ là ngu ngốc. Lấy Python. Tôi chắc chắn ai đó sẽ có ai đó hoặc một ngày nào đó sẽ tạo ra một tiện ích để tạo exe từ mã Python. Tại sao trên trái đất của Thiên Chúa bạn muốn làm điều đó? Nó sẽ gọn gàng không khiến tôi hiểu nhầm nhưng nó không có tác dụng. Vì vậy, hãy ngừng phàn nàn về nó!

Một dự án được thiết kế tốt có thể sẽ chứa mã từ nhiều ngôn ngữ. Điều đó không có nghĩa là bạn không thể hoàn thành một dự án chỉ với một ngôn ngữ. Một số dự án có thể nằm trong khả năng của bất kỳ ngôn ngữ nào bạn đang sử dụng.

4- Bạn đang đứng trên chân gỗ?

Nền tảng có thể là một ảnh hưởng lớn của những gì ngôn ngữ có thể làm. Với những người thu gom rác hiện nay, hoặc thậm chí là những kẻ phát xít cố gắng sớm "thu gom rác", có thể hỗ trợ làm mờ bộ nhớ (có thể là malloc nhiều ram hơn ??). Máy tính nhanh hơn và tất nhiên, chúng tôi mong đợi nhiều ngôn ngữ hơn. Và khá thẳng thắn, có lẽ chúng ta nên. Tuy nhiên, có một cái giá rất lớn để trả cho sự tiện lợi của trình biên dịch để tạo các bảng hoặc chuỗi băm hoặc một loạt các khái niệm khác. Những thứ này có thể không được kế thừa cho nền tảng mà chúng được sử dụng. Để nói rằng chúng dễ dàng bao gồm một ngôn ngữ chỉ cho tôi biết bạn có thể không có chân để đứng.

3- Lỗi thực sự là của ai?

Lỗi. Bạn biết. Tôi yêu bọ. Tại sao tôi yêu bọ. Bởi vì nó có nghĩa là tôi có thể giữ công việc của mình. Nếu không có lỗi, sẽ có nhiều cửa hàng pizza đóng cửa. Tuy nhiên, người dùng ghét lỗi. Nhưng đây là một chút nước lạnh. Mỗi lỗi là lỗi lập trình viên. Không phải ngôn ngữ. Một ngôn ngữ có cú pháp chặt chẽ như vậy sẽ làm giảm đáng kể số lượng lỗi có thể tạo ra sẽ là một ngôn ngữ hoàn toàn vô dụng. Khả năng của nó có thể được tính bằng một tay. Bạn muốn linh hoạt hay sức mạnh? Bạn đã có lỗi. Tại sao? Bởi vì bạn không hoàn hảo, và bạn mắc lỗi. Lấy một ví dụ thực sự có thể xác định được trong C:

int a[10];
for (int idx = 0; idx < 15; idx++) a[idx] = 10;

Chúng ta đều biết những gì sẽ làm. Tuy nhiên, điều mà có lẽ một số người trong chúng ta không nhận ra là .. chức năng đó có thể rất có lợi. Tùy thuộc vào những gì bạn đang làm. Bộ đệm tràn là chi phí của chức năng đó. Mã đó ở trên. Nếu tôi thực sự phát hành nó cho công chúng. Đó là một lần nữa .. nói với tôi .. "Lỗi của tôi". Không phải C là cho phép tôi làm điều đó.

2- Chúng ta không nên bỏ nó vào thùng rác?

Rất dễ để chỉ ra một tính năng trong ngôn ngữ mà chúng tôi không hiểu vì chúng tôi không sử dụng nó thường xuyên và gọi nó là ngu ngốc. Khiếu nại rằng nó ở đó, vv Goto luôn luôn giải trí cho tôi. Mọi người luôn phàn nàn về việc goto đang ở trong một ngôn ngữ. Tuy nhiên, tôi đặt cược chương trình cuối cùng của bạn bao gồm một loại goto. Nếu bạn đã từng sử dụng giờ nghỉ hoặc tiếp tục, bạn đã sử dụng goto. Đó là những gì nó được. Cấp, đó là một goto "an toàn", nhưng đó là những gì nó được. Goto có công dụng của chúng. Cho dù gotos "ngầm" như tiếp tục hay phá vỡ được sử dụng hoặc gotos rõ ràng (sử dụng từ khóa "goto" thực tế cho bất kỳ ngôn ngữ nào). Không phải các nhà phát triển ngôn ngữ là hoàn hảo, nhưng thông thường ... nếu chức năng đã tồn tại từ thời bình minh (đối với ngôn ngữ đó). Có khả năng khía cạnh đó là một chất lượng xác định của ngôn ngữ đó. Có nghĩa là .. nó ' s đang được sử dụng và có khả năng không treo xung quanh vì khả năng tương thích ngược. Nó đang được sử dụng ngày hôm nay. Như trong 5 phút trước. Và sử dụng đúng cách. Chà .. có thể nói ai đó đang sử dụng nó không đúng cách, nhưng điều đó liên quan đến # 3 trong danh sách của tôi.

1. - Mọi thứ đều là một đối tượng.

Ok .. cái này thực sự là một tập hợp con của # 2. Nhưng đây là lời phàn nàn khó chịu nhất mà tôi thấy trong danh sách ghét. Không phải tất cả mọi thứ là một đối tượng. Có rất nhiều khái niệm không thuộc hoặc không cần phải là đối tượng. Đặt những thứ mà chúng không thuộc về chỉ là xấu xí và có thể làm giảm hiệu quả của một chương trình. Chắc chắn rồi. Có lẽ không nhiều tùy thuộc vào ngôn ngữ. Điều này cũng liên quan đến # 5. Điều này có nghĩa là ... có. Toàn cầu đều ổn. Các chức năng như được áp dụng cho các phương thức tĩnh là ok. Kết hợp lập trình OO với các chức năng toàn cầu là ok. Bây giờ .. điều đó không có nghĩa là tất cả chúng ta nên ra ngoài và "giải phóng" mã của chúng tôi khỏi các mô hình đối tượng. Khi thiết kế một phần mã hoặc toàn bộ dự án, những gì xảy ra đằng sau hậu trường nênđược xem xét khi đặt nó cùng nhau. Không chỉ nơi khái niệm đó sống và nhiều yếu tố khác. Tại sao bọc các hàm toàn cục trong các lớp hoặc đặt tên cho các khái niệm không gian nếu nó không phục vụ mục đích? Lấy biến thành viên tĩnh. Điều đó rất thú vị với tôi bởi vì .. tốt .. Phụ thuộc vào ngôn ngữ và việc thực hiện tất nhiên, nhưng nói chung, bạn vừa tuyên bố một toàn cầu. Có, có một số lý do để bọc các khái niệm không phải OO này trong các trình bao bọc OO. Một khóa học là tự viết mã. Điều đó có thể có ý nghĩa. Vì vậy, như tôi nói. Đừng ra ngoài và "giải phóng" mã của bạn. Nhưng bất kỳ ngôn ngữ hiện đại tốt nào cũng sẽ có một khái niệm toàn cầu bên ngoài mô hình OO. Có, tôi đặc biệt có ý chỉ ra rằng một ngôn ngữ lập trình OO không có khái niệm toàn cầu rất có thể có một lỗi thiết kế nghiêm trọng. Một lần nữa mặc dù .. phụ thuộc vào ý định và thiết kế của ngôn ngữ, vì vậy tôi không cố gắng chọn bất kỳ ngôn ngữ cụ thể nào và có quá nhiều thứ để phân tích ngay tại đây. Dù sao đi nữa, hãy xem xét nơi mã nên sống và là hiệu quả nhất. Thêm một loạt flare vào thứ gì đó không thêm chức năng hoặc hỗ trợ chỉ làm mòn bàn phím nhanh hơn. Nó không làm ai tốt cả. Chà .. trừ khi bạn thích điểm brownie từ người có lẽ đã dạy bạn không chính xác rằng mọi thứ đều là một đối tượng.

Nói tóm lại, lập trình không chỉ đơn giản là gõ nhẹ vào bàn phím. Có rất nhiều cân nhắc thiết kế cho bất kỳ dự án. Tôi biết đó là sáo rỗng, nhưng bạn phải nhìn nó từ mọi góc độ. Ngay cả với các ngôn ngữ hiện nay loại an toàn. Bạn không chỉ cần tặc mã ra và mong nó hoạt động tốt. Chắc chắn .. nó có thể hoạt động, nhưng nó có thể không phải là cách đúng đắn để đi về nó. Nhìn chung, chọn ngôn ngữ và định dạng phù hợp nhất cho công việc cụ thể VÀ môi trường. Nhưng không có ngôn ngữ nào lấy đi ý nghĩ đằng sau nó. Nếu bạn không suy nghĩ .. bạn chỉ cần gõ.

Năm điều tôi ghét về Java (hiện tại là ngôn ngữ yêu thích của tôi) không theo thứ tự cụ thể.

1. Nhiều như tôi là một fan hâm mộ của Java Generics, có rất nhiều điều kỳ lạ phát sinh từ cách nó được thiết kế. Như vậy, có vô số hạn chế gây khó chịu với thuốc generic (một số trong đó là kết quả của việc xóa kiểu).
2. Cách Object.clone () và các giao diện Clonizable hoạt động hoàn toàn bị phá vỡ.
3. Thay vì đi đường cao tốc và biến mọi thứ thành một đối tượng (a.la. SmallTalk), Sun đã loại bỏ hai loại dữ liệu khác nhau: Đối tượng và nguyên thủy. Kết quả là bây giờ có hai đại diện cho các loại dữ liệu cơ bản và sự tò mò lớn hơn như quyền anh / unboxing và không thể đưa nguyên thủy vào Bộ sưu tập.
4. Xoay quá phức tạp. Đừng hiểu sai ý tôi: có rất nhiều thứ hay ho có thể làm với Swing nhưng đó là một ví dụ tuyệt vời về kỹ thuật quá mức.
5. Khiếu nại cuối cùng này cũng là lỗi của Sun và những người đã viết thư viện XML cho Java. Các thư viện Java XML quá phức tạp. Để chỉ cần đọc trong tệp XML, tôi thường phải lo lắng về việc tôi đang sử dụng trình phân tích cú pháp nào: DOM hoặc SAX? Các API cho mỗi loại đều khó hiểu như nhau. Hỗ trợ riêng trong ngôn ngữ để dễ dàng phân tích cú pháp / viết XML sẽ rất hay.
6. java.util.Date hút. Không chỉ phức tạp không cần thiết mà tất cả các phương pháp hữu ích đã bị phản đối (và được thay thế bằng các phương pháp khác làm tăng độ phức tạp).

Ruby có nhiều sai sót liên quan đến tốc độ của nó, nhưng tôi không ghét chúng. Nó cũng có những sai sót với việc truyền giáo cộng đồng quá mức, nhưng điều đó không thực sự làm tôi bận tâm. Đây là những gì tôi ghét:

• Các bao (khối) có 4 cú pháp tạo khác nhau và không có cú pháp nào là tối ưu. Cú pháp tao nhã không đầy đủ và mơ hồ với các giá trị băm, và cú pháp đầy đủ là xấu.
• Cộng đồng có xu hướng chống lại tài liệu thực tế, ủng hộ 'đọc mã'. Tôi thấy điều này trẻ con và lười biếng.
• Lạm dụng siêu lập trình, đặc biệt là trong các thư viện, khiến các lỗi trở thành một cơn ác mộng để theo dõi.
• Trên một lưu ý liên quan, siêu lập trình phổ biến làm cho một IDE toàn diện trở nên khó khăn, nếu không muốn nói là không thể thực hiện được.

• Cách khối truyền đến các chức năng được thực hiện là ngớ ngẩn. Không có khối lý do nào được chuyển ra ngoài danh sách tham số hoặc có cú pháp đặc biệt kỳ lạ để truy cập (sản lượng). Tôi cho rằng các khối nên được cung cấp một cú pháp ít mơ hồ hơn (hoặc băm có thể đã sử dụng các dấu phân cách khác nhau; có lẽ <> thay vì {}) và chuyển làm tham số cho các phương thức nên giống như tất cả các tham số khác.

  object.method(1, {|a| a.bar}, "blah")
  

  Những điều kỳ lạ này, như khối phải là tham số cuối cùng được truyền và vượt qua nhiều khối khác nhau với cú pháp dài hơn, thực sự làm tôi khó chịu.

Perl

• Sử dụng hỗn hợp sigils

  my @array = ( 1, 2, 3 );
  my $array = [ 4, 5, 6 ];
  
  my $one  = $array[0]; # not @array[0], you would get the length instead
  my $four = $array->[0]; # definitely not $array[0]
  
  my( $two,  $three ) = @array[1,2];
  my( $five, $six   ) = @$array[1,2]; # coerce to array first
  
  my $length_a = @array;
  my $length_s = @$array;
  
  my $ref_a = \@array;
  my $ref_s = $array;
  

  • Ví dụ, không ai trong số này giống nhau:

    $array[0]   # First element of @array
    @array[0]   # Slice of only the First element of @array
    %array[0]   # Syntax error
    $array->[0] # First element of an array referenced by $array
    @array->[0] # Deprecated first element of @array
    %array->[0] # Invalid reference
    $array{0}   # Element of %array referenced by string '0'
    @array{0}   # Slice of only one element of %array referenced by string '0'
    %array{0}   # Syntax error
    $array->{0} # Element of a hash referenced by $array
    @array->{0} # Invalid reference
    %array->{0} # Deprecated Element of %array referenced by string '0'
    

  Trong Perl6đó có viết :

  my @array = ( 1, 2, 3 );
  my $array = [ 4, 5, 6 ];
  
  my $one  = @array[0];
  my $four = $array[0]; # $array.[0]
  
  my( $two,  $three ) = @array[1,2];
  my( $five, $six   ) = $array[1,2];
  
  my $length_a = @array.length;
  my $length_s = $array.length;
  
  my $ref_a = @array;
  my $ref_s = $array;
  

• Thiếu OO thực sự

  package my_object;
  # fake constructor
  sub new{ bless {}, $_[0] }
  # fake properties/attributes
  sub var_a{
    my $self = shift @_;
    $self->{'var_a'} = $_[0] if @_;
    $self->{'var_a'}
  }
  

  Trong Perl6đó có viết :

  class Dog is Mammal {
      has $.name = "fido";
      has $.tail is rw;
      has @.legs;
      has $!brain;
      method doit ($a, $b, $c) { ... }
      ...
  }
  

• Các tính năng regex được thiết kế kém

  /(?=regexp)/;           # look ahead
  /(?<=fixed-regexp)/;    # look behind
  /(?!regexp)/;           # negative look ahead
  /(?<!fixed-regexp)/;    # negative look behind
  /(?>regexp)/;           # independent sub expression
  /(capture)/;            # simple capture
  /(?:don't capture)/;    # non-capturing group
  /(?<name>regexp)/;      # named capture
  /[A-Z]/;                # character class
  /[^A-Z]/;               # inverted character class
  # '-' would have to be the first or last element in
  # the character class to include it in the match
  # without escaping it
  /(?(condition)yes-regexp)/;
  /(?(condition)yes-regexp|no-regexp)/;
  /\b\s*\b/;              # almost matches Perl6's <ws>
  /(?{ print "hi\n" })/;  # run perl code
  

  Trong Perl6đó có viết :

  / <?before pattern>  /;   # lookahead
  / <?after pattern>   /;   # lookbehind
  / regexp :: pattern  /;   # backtracking control
  / ( capture )        /;   # simple capture
  / $<name>=[ regexp ] /;   # named capture
  / [ don't capture ]  /;   # non-capturing group
  / <[A..Z]>           /;   # character class
  / <-[A..Z]>          /;   # inverted character class
  # you don't generally use '.' in a character class anyway
  / <ws>               /;   # Smart whitespace match
  / { say 'hi' }       /;   # run perl code
  

• Thiếu nhiều công văn

  sub f(   int $i ){ ... }  # err
  sub f( float $i ){ ... }  # err
  sub f($){ ... } # occasionally useful
  

  Trong Perl6đó có viết :

  multi sub f( int $i ){ ... }
  multi sub f( num $i ){ ... }
  multi sub f( $i where $i == 0 ){ ... }
  multi sub f(     $i ){ ... } # everything else
  

• Quá tải vận hành kém

  package my_object;
  use overload
    '+' => \&add,
    ...
  ;
  

  Trong Perl6đó có viết :

  multi sub infix:<+> (Us $us, Them $them) |
                      (Them $them, Us $us) { ... }
  

Đôi khi tôi sẽ làm PHP vì tôi thích nó và Python sẽ được thực hiện quá nhiều.

• Không có không gian tên; mọi thứ đều ở trong một không gian tên rất lớn, là địa ngục trong môi trường lớn hơn

• Thiếu các tiêu chuẩn khi nói đến các hàm: các hàm mảng lấy kim làm đối số thứ nhất, haystack là thứ hai (xem mảng_search ). Các hàm chuỗi thường lấy haystack trước, kim thứ hai (xem strpose ). Các hàm khác chỉ sử dụng các sơ đồ đặt tên khác nhau: bin2hex , strtolower , cal_to_jd

  Một số hàm có các giá trị trả về kỳ lạ, không bình thường: Điều này buộc bạn phải có một biến thứ ba được khai báo từ hư không trong khi PHP có thể diễn giải một mảng trống là sai với kiểu tung hứng của nó. Gần như không có chức năng khác làm tương tự.

  $var = preg_match_all('/regexp/', $str, $ret);
  echo $var; //outputs the number of matches 
  print_r($ret); //outputs the matches as an array
  

• Ngôn ngữ (cho đến PHP6) làm hết sức để tôn trọng khả năng tương thích ngược gần như chậm phát triển, khiến nó mang theo các thực tiễn và chức năng xấu khi không cần thiết (xem mysql_escape_opes so với mysql_real_escape_opes ).

• Ngôn ngữ phát triển từ ngôn ngữ tạo khuôn mẫu sang ngôn ngữ phụ trợ đầy đủ. Điều này có nghĩa là bất cứ ai cũng có thể xuất bất cứ thứ gì khi họ muốn, và nó bị lạm dụng. Bạn kết thúc với các công cụ mẫu cho một ngôn ngữ tạo khuôn mẫu ...

• Nó hút lúc nhập tập tin. Bạn có 4 cách khác nhau để làm điều đó (bao gồm, bao gồm_once, request, request_once), tất cả đều chậm, rất chậm. Trong thực tế, toàn bộ ngôn ngữ là chậm. Ít nhất, khá chậm hơn python (ngay cả với một khung) và RoR từ những gì tôi thu thập được.

Tôi vẫn thích PHP, mặc dù. Đó là sự phát triển của web: bạn muốn một trang web vừa và nhỏ được thực hiện nhanh chóng và chắc chắn rằng bất kỳ ai cũng có thể lưu trữ nó (mặc dù cấu hình có thể khác nhau)? PHP ở ngay đó và nó rất phổ biến, chỉ mất 5 phút để cài đặt một ngăn xếp LAMP hoặc WAMP đầy đủ. Chà, giờ tôi sẽ quay lại làm việc với Python ...

Đây là một số điều tôi không thích về Java (không phải là ngôn ngữ yêu thích của tôi):

• Generics loại erasure (tức là không có tướng tổng hợp)
• Không có khả năng bắt nhiều ngoại lệ (thuộc các loại khác nhau) trong một khối bắt đơn
• Thiếu các hàm hủy (hoàn thiện () là một thay thế rất kém)
• Không hỗ trợ cho việc đóng hoặc xử lý các chức năng như dữ liệu (các lớp bên trong ẩn danh là một thay thế rất dài dòng)
• Các trường hợp ngoại lệ được kiểm tra nói chung, hoặc cụ thể hơn, làm cho các ngoại lệ không thể phục hồi được kiểm tra (ví dụ: SQLException)
• Không hỗ trợ cấp độ ngôn ngữ cho các bộ sưu tập theo nghĩa đen
• Không có suy luận kiểu khi các hàm tạo của các lớp chung được gọi, tức là (các) tham số loại phải được lặp lại ở cả hai phía của '='

C ++

1. Cú pháp mẫu
2. Vấn đề thừa kế kim cương
3. Rất nhiều / thiếu các thư viện tiêu chuẩn mà các ngôn ngữ hiện đại có (mặc dù tăng đến gần).
4. Truyền hình
5. Cú pháp được sử dụng xung quanh IOStreams

Con trăn

1. Không gian có ý nghĩa (đôi khi)
2. từ khóa thiếu
3. Hỗ trợ luồng hạn chế (ít nhất là hiện tại)
4. "tự" thay vì "này"
5. Không gian có ý nghĩa (đôi khi)

Mục tiêu-C

1) Không có không gian tên, chỉ có các quy ước đặt tên thủ công - Tôi không bận tâm rằng về mặt phân tách lớp, nhưng tôi không thể nhập tất cả các định nghĩa lớp trong một không gian tên trong một dòng duy nhất (như nhập com.me.somel Library. *).

2) Thư viện vẫn còn một số lỗ hổng trong các lĩnh vực quan trọng như hỗ trợ RegEx.

3) Cú pháp thuộc tính là một chút vụng về, yêu cầu ba dòng (trong hai tệp riêng biệt) để khai báo một thuộc tính.

4) Tôi thích mô hình giữ lại / phát hành, nhưng nó dễ dàng hơn là phát hành một tài liệu tham khảo và sau đó vô tình sử dụng nó sau này.

5) Mặc dù không thực sự là một tính năng ngôn ngữ, Xcode rất đan xen với việc sử dụng Objective-C Tôi không thể không nghĩ về khía cạnh đó ... về cơ bản là tự động hoàn thành, rất iffy. Nó giống như một hệ thống thưởng cho bạn vì đã tìm thấy thứ bạn muốn tồn tại, và sau đó trình bày nó như một sự lựa chọn sau đó. Nhưng sau đó tôi cho rằng tôi chưa bao giờ thích động cơ tự động hoàn thành.

C ++

• Dây.
  Chúng không thể tương tác với các chuỗi nền tảng, vì vậy cuối cùng bạn sử dụng std :: vector một nửa thời gian. Chính sách sao chép (sao chép trên ghi hoặc sao chép sâu) không được xác định, do đó không thể đưa ra đảm bảo hiệu suất cho cú pháp đơn giản. Đôi khi, họ dựa vào các thuật toán STL không trực quan để sử dụng. Quá nhiều thư viện tự cuộn mà không may sử dụng thoải mái hơn nhiều. Trừ khi bạn phải kết hợp chúng.

• Sự đa dạng của các biểu diễn chuỗi
  Bây giờ, đây là một chút vấn đề về nền tảng - nhưng tôi vẫn hy vọng nó sẽ tốt hơn khi một lớp chuỗi tiêu chuẩn ít cố chấp hơn đã có sẵn trước đó. Các đại diện chuỗi sau đây tôi sử dụng thường xuyên:

  • LPCTSTR chung,
  • LPC (W) STR được phân bổ bởi CoTaskMem ALLoc,
  • BSTR, _bstr _t
  • (w) chuỗi,
  • Chuỗi C,
  • std :: vector
  • một lớp roll-my-own ( thở dài ) thêm kiểm tra phạm vi và các hoạt động cơ bản vào bộ đệm (w) char * có độ dài đã biết

• Xây dựng mô hình.
  Tôi phát ốm với tất cả thời gian dành cho việc nhầm lẫn với những người bao gồm những gì, tuyên bố chuyển tiếp, tối ưu hóa các tiêu đề được biên dịch trước và bao gồm để giữ cho thời gian xây dựng tăng ít nhất có thể chịu được, v.v. Có rất nhiều trở ngại để đóng gói một đoạn mã để nó có thể được sử dụng lại đến nỗi ngay cả chó mẹ cũng cảm thấy chán khi nghe tôi nói.

• Khó phân tích
  Điều này làm cho các công cụ bên ngoài đặc biệt khó viết và đúng. Và ngày nay, những người C ++ của chúng ta đang thiếu chủ yếu trong chuỗi công cụ. Tôi yêu sự phản ánh C # của tôi và các đại biểu nhưng tôi có thể sống mà không có họ. Nếu không tái cấu trúc tuyệt vời, tôi không thể.

• Việc phân luồng quá khó
  Ngôn ngữ thậm chí không nhận ra nó (bây giờ) và các quyền tự do của trình biên dịch - trong khi tuyệt vời - là đau đớn.

• Khởi tạo tĩnh và theo yêu cầu Về mặt kỹ thuật, tôi gian lận ở đây: đây là một mảnh ghép khác trong "mã bọc để tái sử dụng": Thật là một cơn ác mộng khi chỉ cần khởi tạo một cái gì đó khi cần thiết. Giải pháp tốt nhất cho tất cả các vấn đề phân phối lại khác là ném mọi thứ vào tiêu đề, vấn đề này nói "neeener - bạn không thể".

Cấp, rất nhiều trong số đó vượt quá phạm vi ngôn ngữ nghiêm ngặt, nhưng IMO toàn bộ chuỗi công cụ cần phải được đánh giá và cần phát triển.

JavaScript :

• Các Objectnguyên mẫu có thể được sửa đổi. Mỗi đối tượng trong chương trình của bạn đều có các thuộc tính mới và một cái gì đó có thể bị phá vỡ.

• Tất cả các đối tượng là bản đồ băm, nhưng thật khó để sử dụng chúng một cách an toàn như vậy. Đặc biệt, nếu một trong những chìa khóa của bạn xảy ra __proto__, bạn sẽ gặp rắc rối.

• Không có đối tượng đóng cửa tại thời điểm tham chiếu chức năng. Trong thực tế, không có sự đóng cửa đối tượng nào cả - thay vào đó, thisđược đặt bất cứ khi nào một hàm được gọi với ký hiệu đối tượng hoặc newtoán tử. Kết quả là có nhiều nhầm lẫn, đặc biệt là khi tạo các cuộc gọi lại sự kiện, vì thiskhông được đặt thành những gì lập trình viên mong đợi.

  • Hệ quả: gọi một hàm không có ký hiệu đối tượng hoặc newtoán tử dẫn đến thisviệc được đặt bằng với đối tượng toàn cục, dẫn đến phá vỡ nhiều.

• Toán tử bổ sung bị quá tải để thực hiện nối chuỗi, mặc dù hai thao tác khác nhau về cơ bản. Kết quả là đau đớn khi một giá trị bạn mong đợi là một số trên thực tế là một chuỗi.

• ==và các !=nhà khai thác thực hiện cưỡng chế loại. So sánh giữa các loại khác nhau liên quan đến một danh sách các quy tắc mà không người phàm nào có thể nhớ đầy đủ. Điều này được giảm nhẹ bởi sự tồn tại của ===và các !==nhà khai thác.

• Cả hai nullvà undefinedtồn tại, với ý nghĩa tinh tế khác nhau, nhưng dư thừa. Tại sao?

• Cú pháp lạ để thiết lập chuỗi nguyên mẫu.

• parseInt(s)mong đợi một số kiểu C, do đó, coi các giá trị với các số 0 đứng đầu là bát phân, v.v. Ít nhất bạn có thể parseInt(s, 10)nhưng hành vi mặc định là khó hiểu.

• Không có phạm vi khối.

• Có thể khai báo cùng một biến nhiều lần.

• Có thể sử dụng một biến mà không cần khai báo nó, trong trường hợp đó là toàn cầu và có thể phá vỡ chương trình của bạn.

• with { }.

• Thực sự rất khó để làm tài liệu với JavaDoc như các công cụ.

Con trăn

• Thiếu gõ tĩnh
• Xử lý đối số mặc định (cụ thể là bạn có thể thay đổi đối số mặc định cho những người gọi trong tương lai!)
• Quá nhiều dấu gạch dưới yêu cầu (hàm tạo phải được gọi __init__)
• Thiếu các thành viên và chức năng riêng tư thích hợp (quy ước chỉ nói rằng hầu hết mọi thứ bắt đầu bằng dấu gạch dưới là riêng tư, ngoại trừ tất cả những thứ như __getattr__ không phải là)
• Cú pháp vui printđể lấy tệp (nhưng họ đang sửa nó trong Python 3)

C #

• Tôi ước tôi có thể switch()trên bất kỳ loại nào, và đó casecó thể là bất kỳ biểu hiện nào.

• Không thể sử dụng cú pháp trình khởi tạo đối tượng với các trường / tự động đọc 'chỉ đọc' private set. Nói chung, tôi muốn trợ giúp ngôn ngữ với việc tạo ra các loại bất biến.

• Sử dụng {}cho không gian tên và lớp và phương thức và khối thuộc tính / bộ chỉ mục và khối đa câu lệnh và khởi tạo mảng . Làm cho nó khó khăn để tìm ra bạn đang ở đâu khi chúng cách xa nhau hoặc không khớp.

• Tôi ghét viết lách (from x in y ... select).Z(). Tôi không muốn phải quay lại cú pháp cuộc gọi phương thức vì cú pháp truy vấn bị thiếu một cái gì đó.

• Tôi muốn một domệnh đề về cú pháp truy vấn, nó giống như foreach. Nhưng nó không thực sự là một truy vấn sau đó.

Tôi thực sự đạt đến đây. Tôi nghĩ C # thật tuyệt vời và thật khó để tìm thấy nhiều thứ bị hỏng.

PHP

1. Không có tính năng sửa lỗi nếu bạn không điều khiển máy chủ và thậm chí sau đó chúng còn bị hút
2. Số lượng cực lớn của mã PHP xấu nổi xung quanh cung cấp cho tất cả các lập trình viên PHP một tên xấu
3. Đặt tên hàm không nhất quán
4. Không thể có biến gõ tĩnh nếu tôi muốn (Tôi là một fan hâm mộ lớn của việc gõ động 90% thời gian)
5. REGISTER_GLOBALS là ma quỷ

C (OK, nó không phải là sở thích của tôi, nhưng nó chưa được thực hiện.)

• Cú pháp thư viện socket.
• Không có chức năng quá tải.
• Dây kiểu C.
• Bộ đệm tràn ngập.
• Cú pháp mật mã. Tôi không biết bao nhiêu lần tôi đã nhìn lên những thứ như atoi, vỗ vào trán tôi và hét lên "Tất nhiên rồi!"

EDIT: Tôi có thể có thể tìm ra nhiều hơn nếu tôi sử dụng nhiều mã thư viện hơn (như tôi đã làm với các socket, nhưng chúng đặc biệt tệ), nhưng tôi đã cảm thấy như mình gian lận khi chọn C. Vì vậy, nhiều ngôn ngữ chỉ tồn tại những phần tốt của C và thay thế phần xấu giống như đánh một con ngựa chết.

Lisp thường gặp:

1. Từ khóa thường quá dài dòng.
2. Thư viện hỗ trợ thật đáng thương.
3. Không hoạt động tốt trong các hệ điều hành muốn xử lý bộ nhớ nghiêm ngặt hơn.
4. Không có phương tiện tốt để tương tác với HĐH.
5. Tiện ích "vòng lặp" không được xác định rõ và chắc chắn không nhìn Lispy.

BrainF * ck

• Điểm nổi bật của bạn là bạn đã hoàn thành Turing ?! Tôi có thể làm nhiều hơn trong biểu thức chính quy Perl!

• Thiếu đồ vật. Mọi người ơi! Giống như, xin chào ...

• Không có thư viện mạng. Tất cả những gì tôi muốn là cạo một trang web, GOSH.

• Không có chức năng hạng nhất. Xin chúc mừng - bạn có thể giao lưu với bạn bè Java của mình.

• Một băng vô hạn để lưu trữ và không có gì khác. Điều này rất tự phụ đến nỗi chúng tôi cũng có thể viết Lisp.

JavaScript

1. các số dưới dạng chuỗi - Toán học có thể gây khó chịu khi các số được hiểu là các chuỗi. 5 + 2 = 52? Ơ ...
2. quyền - tất cả những thứ tốt nhất cần có sự cho phép của người dùng!
3. cập nhật màn hình - Trình duyệt phải ở trạng thái ổn định để cập nhật màn hình. Dường như không có cách nào để buộc màn hình cập nhật ở giữa tập lệnh.
4. Chậm - mặc dù Chrome của Chrome rất hay ...
5. Sự khác biệt của trình duyệt làm cho việc sử dụng ngôn ngữ [bị kiểm duyệt].

PHP:

• Không bao giờ có thể chắc chắn rằng một số tiện ích mở rộng gần như phổ biến có sẵn trên tất cả các máy chủ web.
• cố gắng trở thành tất cả mọi thứ trong tương lai (goto, đóng cửa, ...)
• nhiều rủi ro bảo mật cho người dùng chưa có kinh nghiệm
• quá tải toán tử sẽ tốt hơn
• tất cả các lập trình viên nghèo không học cách làm cho nó hoạt động đúng và đặt tên xấu

Tuy nhiên PHP là các (kịch bản) ngôn ngữ. ;-)

VB6

1. Chỉ có Windows.
2. Không còn được hỗ trợ.
3. Mảng có thể bắt đầu ở bất kỳ số nào, thay vào đó tất cả được chuẩn hóa thành 0.
4. các ứng dụng được biên dịch phụ thuộc vào nhiều dll để chạy đúng.
5. Nhiều điều khiển phức tạp như điều khiển trình duyệt hoặc các đoạn mã phức tạp có xu hướng phá vỡ IDE khi bạn chạy mã không được biên dịch, nhưng chỉ hoạt động tốt khi được biên dịch.

Ruby là ngôn ngữ yêu thích của tôi, đây là những gì tôi không thích:

• Chủ đề xanh + chặn thư viện C = thất bại khổng lồ
• VẬY
• Thư viện tiêu chuẩn tự nó không phù hợp với việc sử dụng tiếng nổ! phương pháp
• Mô-đun bao gồm + mở rộng là lộn xộn.
• "Các lớp mở" không thể nằm trong phạm vi - Tôi muốn thêm Chuỗi # do do, nhưng tôi không muốn điều đó bị rò rỉ vào tất cả các thư viện của bên thứ ba
• Không có giải pháp đóng gói triển khai nhị phân.

Delphi:

• IDE hơi không ổn định.
• Cái nhìn sâu sắc mã đôi khi bị nhầm lẫn.
• Gỡ lỗi đôi khi là lỗi.
• Cập nhật một số tập tin dự án có thể là cồng kềnh.
• Nếu bắt đầu khi một hoặc nhiều gói không có sẵn, thông báo lỗi sẽ xuất hiện nhiều lần.

JavaScript

• Mỗi tập lệnh được thực thi trong một "không gian tên" toàn cầu duy nhất ... một cái gì đó mà bạn phải chú ý khi làm việc với các tập lệnh từ các nguồn khác nhau

• Nếu một biến được sử dụng nhưng chưa được xác định trước, nó được coi là biến toàn cục

• Các nhà cung cấp trình duyệt tạo ra các tiêu chuẩn theo ý họ, làm cho mã hóa cho các nhà phát triển của chúng tôi sử dụng một ngôn ngữ đẹp như vậy khó hơn nó nên

• Phân biệt chữ hoa chữ thường - xem xét rằng không có IDE phù hợp để phát triển js với kiểm tra thời gian biên dịch

• Giải pháp thay thế (chẳng hạn như sử dụng hasOwnPropertyphương pháp) để thực hiện một số thao tác đơn giản.

Haskell:

1. Không gian rò rỉ từ đánh giá lười biếng.
2. Phân cấp số không được xây dựng liên quan đến trừu tượng toán học.
3. IO đơn điệu nghiêm ngặt có thể làm cho việc gỡ lỗi khó khăn hơn.
4. Các triển khai lớn xử lý I / O theo những cách có vẻ không tương thích với tiêu chuẩn. (Cụ thể, xuất ra các ký tự chỉ xuất ra 8 bit thấp - và sau đó mã được xây dựng sử dụng giả định này để thực hiện I / O nhị phân. Ick.)
5. Sự kết hợp của ($)toán tử có thể được thay đổi để làm cho một số biểu thức đẹp hơn.

Hầu hết trong số này không tăng đến mức độ ghét và có những người đang cố gắng khắc phục hoặc xây dựng các cách giải quyết vững chắc cho từng điều này.

Chỉnh sửa: Có một số nhầm lẫn về điểm 5. Đặc biệt một số người dường như nghĩ rằng tôi có nghĩa là thứ tự của các đối số, mà tôi không. Thay vì giải thích những gì tôi muốn nói, tôi sẽ chỉ cho mọi người vào liên kết sau, http://hackage.haskell.org/trac/haskell-prime/wiki/ChangeDollarAssociativity , thể hiện điều đó tốt.