Які п’ять речей ви ненавидите улюбленою мовою? [зачинено]

Останнім часом спостерігається скупчення Perl-ненависті на Stack Overflow, тому я подумав, що я поставлю питання " П’ять речей, які ви ненавидите про свою улюблену мову " до Stack Overflow. Візьміть свою улюблену мову і скажіть мені п’ять речей, яких ви ненавидите. Це можуть бути речі, які вас просто дратують, допущені вади дизайну, визнані проблеми в роботі або будь-яка інша категорія. Ви просто повинні ненавидіти це, і це має бути вашою улюбленою мовою.

Не порівнюйте його з іншою мовою і не говоріть про мови, які ви вже ненавидите. Не говоріть про те, що вам подобається улюбленою мовою. Я просто хочу почути речі, які ви ненавидите, але терпите, щоб ви могли використовувати всі інші речі, і я хочу почути це про мову, яку ви хотіли, щоб користувалися інші люди.

Я запитую це кожного разу, коли хтось намагається натиснути на мене свою улюблену мову, а іноді і як питання інтерв'ю. Якщо хтось не може знайти п’ять речей, щоб ненавидіти його улюблений інструмент, він не знає його досить добре, щоб або відстоювати його, або залучати великі долари, використовуючи його. Він не використовував його в досить різних ситуаціях, щоб повністю вивчити його. Він виступає за це як культуру чи релігію, а це означає, що якщо я не виберу його улюблену технологію, я помиляюся.

Мені не дуже важливо, якою мовою ви користуєтесь. Не хочете використовувати певну мову? Тоді не варто. Ви проходите належну ретельність, щоб зробити обгрунтований вибір, і все одно не використовуєте його? Чудово. Іноді правильна відповідь - "У вас є сильна команда програмування, яка має добру практику та великий досвід роботи в Bar. Перехід на Foo було б дурним".

Це хороше питання і для оглядів коду. Люди, які дійсно знають кодову базу, матимуть всілякі пропозиції щодо неї, а ті, хто її не знає так добре, мають неспецифічні скарги. Я запитую такі речі, як "Якби ти міг почати все над цим проектом, що б ти зробив інакше?" У цій фантазійній країні користувачі та програмісти отримують скарги на що-небудь і все, що їм не подобається. "Я хочу кращий інтерфейс", "я хочу відокремити модель від подання", "я б використовував цей модуль замість цього іншого", "я перейменував би цей набір методів", або що б вони насправді не мали Мені не подобається в ситуації, що склалася. Ось так я розумію, наскільки конкретний розробник знає про кодову базу. Це також підказки про те, скільки програми

Ненависть - не єдиний вимір з'ясувати, скільки людей знає, але я вважаю, що це дуже добре. Те, що вони ненавидять, також дає мені зрозуміти, наскільки добре вони думають про цю тему.

П’ять речей, які я ненавиджу щодо Java:

• Ніяких першокласних функцій.
• Немає висновку про тип.
• Відсутність розумних стандартних параметрів, наприклад, у графіці.
• NullPointerException не містить більше інформації про те, що є null.
• Поширення безглуздо «настроюваних» фреймворків / інтерфейсів постачальника послуг / заводські класи / системи впорскування залежностей. Конфігурація майже ніколи не використовується, DRY порушується грубо, а коди вчетверо в розмірах і половини в розбірливості.

Я знаю, я повинен перевірити Скалу.

Нічого собі, я здивований, що SQL ще цього не зробив. Здогадайтесь, це означає, що його ніхто не любить :)

• Невідповідний синтаксис у різних реалізаціях
• Тонкі відмінності в коді можуть мати значні наслідки для продуктивності з, здавалося б, незрозумілих причин
• Погана підтримка маніпуляції текстом
• Проста вартість вступу, але крута крива навчання до оволодіння мовою
• Мінімальна стандартизація у спільноті для найкращих практик, сюди входить стиль синтаксису.

... І кілька причин бонусу ненавидіти це без додаткових витрат

• пункт WHERE діє останньою, що спрощує передчасне виконання UPDATE або DELETE, знищуючи всю таблицю. Натомість, ГДЕ повинно йти кудись попереду.
• Важко здійснити реляційний поділ.
• Я можу встановити значення NULL, але я не можу перевірити його на рівність з NULL. Я можу перевірити, чи НУЛЬНИЙ, але це просто ускладнює код - без потреби, на мій погляд.
• Чому нам потрібно повністю дотримуватися формули для стовпця GROUPED, а не встановлювати псевдонім на стовпчик, а потім GROUP BY псевдонім (або індекс стовпця, як у SORT)?

JavaScript :

1. Усі найкрутіші речі є шалено складними, але тоді вся прохолода також загорнута в таку невелику кількість коду, що ви відчуваєте себе дурним, бореться за це.

2. '+' - це абсурдний вибір оператора конкатенації слабко набраною мовою. Чи намагалися вони відлякати нобу?

3. Це мінне поле сумісності між браузерами (неважливо, він навіть увімкнено чи ні)

4. Це, як правило, ненадійність - пов’язана з негідниками, такими як блокування кнопки "назад", спливаючі вікна, які ніколи не вмирають тощо.

5. Налагодити це майже неможливо, оскільки є лише кілька різних повідомлень про помилки та кілька різних типів (число, рядок, об’єкт тощо)

Якби не jQuery, я, мабуть, все одно ненавиджу його так, як раніше :)

PHP:

1) Змушує мене робити зайві змінні:

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

2) Реалізація лямбдасів настільки кульгава, що приблизно еквівалентна використанню eval()і настільки жахливо неправильна, що я ніколи її не використовував (див. Http://www.php.net/create_function ).

3) Система спробу / лову, яка може зафіксувати лише близько 80% помилок, які можуть виникнути.

4) Підтримка Regex настільки ж кульгава, як і лямбда-підтримка, тому що її потрібно писати всередині звичайних рядків, що робить один з найбільш важких для засвоєння інструментів програмування приблизно втричі складніше. І PHP повинен бути "легкою" мовою?!?!?

5) Ні в якому разі не можна безпечно витягувати речі з $ _POST, не записуючи їх двічі, не будуючи власну функцію або використовуючи оператор "@":

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

6) Бонусна відповідь: "@". Якщо ви не можете заперечувати правильно писати свій код, просто додайте "@" і занадто погано для тих, кому доведеться налагоджувати ваш код пізніше.

C ++

• Надто просто, щоб випадковим чином пошкодити пам'ять і створити майже неможливо знайти помилки (хоча, Вальгринд проходить довгий шлях до виправлення цього).
• Повідомлення про помилки шаблону.
• Під час використання шаблонів легко в кінцевому підсумку потрібно включити все в один файл, а потім отримати дурні рази компіляції.
• Стандартна бібліотека - це жарт у сучасну епоху (досі немає потоків чи мережі за замовчуванням?)
• Багато неприємних маленьких шматочків C пробиваються (зокрема, всі перетворення між короткими / int / неподписаними / тощо)

C # / .NET:

• Класи за замовчуванням повинні бути запечатані
• Не повинно бути lockзаяв - натомість у вас повинні бути конкретні блокуючі об'єкти, і повинні бути такі методи, як Acquireповернення одноразових жетонів блокування. Висновок: не повинно бути монітора для кожного об’єкта.
• GetHashCode()і Equals()не повинно бути System.Object- не все підходить для хешування. Замість цього, мати IdentityComparerякий робить те ж саме, і тримати IComparer<T>, IComparable<T>, IEqualityComparer<T>і IEquatable<T>інтерфейси для призначених для користувача порівнянь.
• Погана підтримка непорушності
• Поганий спосіб виявлення методів розширення - це має бути набагато більш свідомим рішенням, ніж просто те, що я використовую простір імен.

Ці були з моєї голови - запитайте мене завтра, і я придумаю різні 5 :)

С

• струнні маніпуляції.

Доводиться працювати вручну з буферними рядками, це схильність до помилок. Оскільки стільки обчислень дійсно рухаються та змінюють рядки (комп’ютери використовуються не так багато для великого скорочення чисел, як люди думали, що повернуться назад), дуже приємно користуватися керованими мовами або рядком C ++ об'єкти для вирішення цих питань. Коли мені доводиться це робити на прямій С, це відчувається, як плавати в пісні.

Як щодо п’яти речей, які я ненавиджу, у списках "Що я ненавиджу про якусь мову"? : D

5- Фарбування помаранчевим червоним не робить це яблуком.

Коли мова розроблена, дизайнери зазвичай мають на увазі, для чого вона корисна. Використовувати його для чогось зовсім іншого може спрацювати, але скаржитися, коли це не просто глупо. Візьміть Python. Я впевнений, що або хтось має, або хтось колись зробить утиліту для створення exe з Python-коду. Чому на землі Божій ти хотів би це зробити? Було б акуратно - не зрозумійте мене неправильно - але це не має ніякої користі. Тож перестаньте скаржитися на це!

Добре розроблений проект, ймовірно, міститиме код з декількох мов. Це не означає, що ви не можете завершити проект лише однією мовою. Деякі проекти можуть бути в межах можливостей будь-якої мови, якою ви користуєтесь.

4- Ти стоїш на дерев'яних ніжках?

Платформа може бути великим впливом того, що може зробити мова. На сьогоднішній день сміттєзбірники, а то й паскалі ранні спроби "вивезення сміття", можуть допомогти згасанню пам'яті (можливо, мальком більше барана ??). Комп'ютери швидше, і, звичайно, ми очікуємо, що більше наших мов. І, чесно кажучи, ми, мабуть, повинні. Однак для зручності компілятора можна створити величезну ціну для створення хеш-таблиць або рядків або різноманітних інших понять. Ці речі можуть не бути успадкованими платформою, для якої вони використовуються. Якщо сказати, що їх легко включити до мови, це просто скаже мені, що ти можеш не мати ноги, на якій можна стояти.

3- Хто в цьому винен?

Клопи. Ти знаєш. Я люблю клопів. Чому я люблю клопів. Тому що це означає, що я можу зберегти свою роботу. Без помилок було б багато закритих піцерій. Однак користувачі ненавидять помилок. Але ось трохи сплеску холодної води. Кожна помилка - це помилка програмістів. Не мова. Мова з таким суворим синтаксисом, який би значно зменшив кількість помилок, які можна було б створити, був би абсолютно марною мовою. Це, можливо, можна було б перерахувати з одного боку. Ви хочете гнучкості чи потужності? У вас є помилки. Чому? Тому що ти не ідеальний, і ти робиш помилки. Візьмемо дійсно ідентифічний приклад на мові C:

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

Ми всі знаємо, що це робити. Однак те, що, можливо, хтось із нас не усвідомлює, це те, що функціональність може бути дуже корисною. Залежно від того, що ти робиш. Перевищення буфера - це вартість цієї функціональності. Цей код вище. Якщо я насправді випустив це на публіку. Це знову .. скажи це зі мною .. "Моя вина". Це не те, що я дозволив мені це зробити.

2 - Чи не слід ставити це в кошик?

Дуже легко вказати на особливості на мові, яку ми не розуміємо, оскільки ми не використовуємо її часто і називаємо її дурною. Поскаржись, що це там і т.д. Гото завжди мене розважає. Люди завжди скаржаться на те, що гото є мовою. Але я думаю, що ваша остання програма включала тип goto. Якщо ви коли-небудь використовували перерву чи продовження, ви використовували goto. Ось що це. Зрозуміло, це "безпечне" гото, але воно є. Гото мають їх використання. Незалежно від того, чи використовуються "неявні" gotos, як продовжувати або перервати, або явні gotos (використовуючи власне ключове слово "goto" для будь-якої мови). Не те, щоб розробники мови були бездоганними, але, як правило, ... якщо функціональність існувала ще з світанку (для цієї мови). Ймовірно, цей аспект є визначальною якістю цієї мови. Значення .. це ' s використовується і, швидше за все, не висить через зворотну сумісність. Він використовується сьогодні. Як і 5 хвилин тому. І правильно використовується. Ну .. певно, хтось також його неправильно використовує, але це стосується №3 мого списку.

1. - Все є предметом.

Ок .. ця справді є підмножиною №2. Але це, безумовно, найприємніша скарга, яку я бачу у списках ненависті. Не все є об’єктом. Існує велика кількість понять, які не належать або не повинні бути об'єктами. Розміщення речей там, де вони не належать, - це просто некрасиво і може знизити ефективність програми. Звичайно. Можливо, не сильно залежно від мови. Це також стосується №5. Це означає ... так. Глобальні в порядку. Функції, призначені для статичних методів, добре. Поєднувати програмування OO з глобальними функціями - це нормально. Тепер .. це не означає, що ми всі повинні вийти і "звільнити" наш код від об'єктних моделей. При проектуванні ділянки коду або всього проекту, що відбувається за лаштунками повиннівраховуйте при складанні. Мало того, де живе ця концепція та багато інших факторів. Навіщо обертати глобальні функції в межах класів або понять простору імен, якщо це не відповідає меті? Візьміть статичні змінні члена. Це дуже мене забавляє, тому що ... ну..Залежно від мови та впровадження курсу, але загалом кажучи, ви просто оголосили глобальним. Так, є деякі причини, щоб зафіксувати ці поняття, що не належать до ОО, в OO обгортки. Одним із них є самодокументування коду. Це може мати сенс. Так .. як я кажу. Не виходьте і не звільняйте свій код. Але будь-яка добра сучасна мова матиме глобальну концепцію поза її моделювання ОО. Так, я конкретно маю на увазі, що мова програмування OO без глобальної концепції, швидше за все, має серйозні вади дизайну. Хоча знову ж таки .. залежить від наміру та дизайну мови, тому я не намагаюся вибрати якусь конкретну мову, і тут дуже багато для аналізу. Будь-хто, Поміркуйте, де код повинен жити і бути найбільш ефективним. Додавання купового спалаху до чогось, що не додає функціональності чи підтримки, просто швидше зношує клавіатуру. Це нікому не приносить користі. Ну .. якщо вам не подобаються окуляри брауні від людини, яка, ймовірно, неправильно навчила вас, що все є предметом.

Коротше кажучи, програмування - це не просто безглуздо натискання клавіатури. У будь-якому проекті є чимало міркувань щодо дизайну. Я знаю, що це кліше, але ви повинні дивитися на нього з усіх кутів. Навіть із сучасними мовами, що захищають тип. Ви не просто викручуєте код і очікуєте, що він буде добре працювати. Звичайно .. це може спрацювати, але це може бути не правильним шляхом. Загалом виберіть мову та формат, які найкраще підходять для конкретної роботи ТА оточення. Але жодна мова не забирає думки за нею. Якщо ти не думаєш .. ти просто набираєш текст.

П’ять речей, які я ненавиджу щодо Java (яка, на сьогодні, є моєю улюбленою мовою), не в особливому порядку.

1. Наскільки я шанувальник Java Generics, є багато диваків, які виникають із того, як вона була розроблена. Таким чином, існує безліч набридливих обмежень із загальними характеристиками (деякі з яких є результатом стирання типу).
2. Спосіб роботи інтерфейсів Object.clone () та Cloneable повністю порушений.
3. Замість того, щоб взяти дорогу і зробити все об'єктом (a.la. SmallTalk), Sun wimped out створив дві різні категорії типів даних: Об'єкти та примітиви. Як результат, зараз є два уявлення про основні типи даних та цікаві цікавості, такі як бокс / розпакування та неможливість розміщення примітивів у колекції.
4. Гойдалка занадто складна. Не зрозумійте мене неправильно: є багато цікавих речей, які можна зробити з Swing, але це чудовий приклад надмірної інженерії.
5. Ця остання скарга однаково є виною Sun і тих, хто написав XML-бібліотеки для Java. Бібліотеки Java XML занадто складні. Для того, щоб просто читати у XML-файлі, мені часто доводиться турбуватися про те, який парсер я використовую: DOM чи SAX? API для кожного однаково заплутано. Рідна підтримка мовою для легкого розбору / запису XML була б дуже приємною.
6. java.util.Дата смокче. Це не лише зайве ускладнення, але й усі корисні методи застаріли (і замінені іншими, що підвищують складність).

У Рубі є багато недоліків, пов'язаних з її швидкістю, але я їх не ненавиджу. Він також має вади, коли євангелізація громади переходить за борт, але це насправді не турбує мене. Це те, що я ненавиджу:

• Замикання (блоки) мають 4 різних синтаксису створення, і жоден з них не є оптимальним. Елегантний синтаксис неповний і неоднозначний з хешами, а повний синтаксис - некрасивим.
• Громада, як правило, проти реальної документації, віддаючи перевагу "прочитати код". Я вважаю це по-дитячому і ледачим.
• Зловживання метапрограмуванням, особливо в бібліотеках, робить помилок кошмаром для пошуку.
• У відповідній примітці повсюдне метапрограмування ускладнює комплексне IDE, якщо не неможливо.

• Шлях, який передається блоку функціям, нерозумний. Немає причин, що блоки повинні бути передані поза списком параметрів або мати непарний спеціальний синтаксис для доступу (вихід). Я вважаю, що блокам слід було б надати менш неоднозначний синтаксис (або хеші могли використовувати різні роздільники; можливо, <>, а не {}), і передавання параметрів методам мало бути таким же, як і всі інші параметри.

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

  Ці дивацтва, як і блок, повинні бути останнім пройденим параметром, і передача більше одного блоку відрізняється довшим синтаксисом, мене справді дратують.

Perl

• Змішане використання сигіл

  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;
  

  • Наприклад, жодне з них не те саме:

    $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'
    

  У Perl6ній написано :

  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;
  

• Відсутність справжнього ОО

  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'}
  }
  

  У Perl6ній написано :

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

• Погано розроблені функції регулярного виведення

  /(?=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
  

  У Perl6ній написано :

  / <?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
  

• Відсутність багаторазової відправки

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

  У Perl6ній написано :

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

• Погана перевантаження оператора

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

  У Perl6ній написано :

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

Я буду робити PHP, як мені подобається часом, і Python буде зроблено занадто багато.

• Немає простору імен; все знаходиться у своєму роді дуже великого простору імен, яке в певних умовах пекло

• Відсутність стандартів, коли мова йде про функції: функції масиву беруть голку за перший аргумент, копицю сіна як другу (див. Array_search ). Струнні функції найчастіше займають стог сіна першим, голкою другим (див. Strpos ). Інші функції просто використовують різні схеми іменування: bin2hex , strtolower , cal_to_jd

  Деякі функції мають дивні значення повернення, що не є нормальним. Це змушує вас оголосити третю змінну з нізвідки, тоді як PHP може ефективно інтерпретувати порожній масив як помилковий з його жонглюванням типу. Немає інших функцій, які б виконували те саме.

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

• Мова (до PHP6) робить все можливе, щоб поважати майже відсталу відсталу сумісність, змушуючи її виконувати погані практики та функції, коли це не потрібно (див. Mysql_escape_string vs. mysql_real_escape_string ).

• Мова еволюціонувала від мови-шаблона до мови, що повністю перебуває у вкладі. Це означає, що будь-хто може вивести все, що завгодно, і цим зловживають. Ви закінчуєте шаблонні двигуни для мови шаблонів ...

• Це смокче при імпорті файлів. У вас є 4 різних способи зробити це (включати, включати_конце, вимагати, вимагати_конце), всі вони повільні, дуже повільні. Насправді вся мова повільна. Принаймні, набагато повільніше, ніж python (навіть із рамкою) та RoR від того, що я збираю.

Я все ще люблю PHP. Це бензопила веб-розробки: ви хочете, щоб невеликий і середній сайт був зроблений дуже швидко і будьте впевнені, що хтось може розмістити його (хоча конфігурації можуть відрізнятися)? PHP є саме там, і це настільки повсюдно, що потрібно встановити повний стек LAMP або WAMP лише 5 хвилин. Ну, я зараз повернусь до роботи з Python ...

Ось деякі речі, які мені не подобаються щодо Java (яка не є моєю улюбленою мовою):

• Стирання типів дженериків (тобто відсутні рефіковані дженерики)
• Неможливість зловити кілька винятків (різних типів) в одному блоці вилову
• Відсутність деструкторів (finalize () є дуже поганою заміною)
• Немає підтримки для закриття чи трактування функцій як даних (анонімні внутрішні класи - це дуже багатослівна заміна)
• Перевіряли винятки взагалі або, більш конкретно, робили перевірені виправлення виключень (наприклад, SQLException)
• Немає мовної підтримки для буквальних колекцій
• Немає виводу типу, коли викликаються конструктори загальних класів, тобто параметри типу не повинні повторюватися з обох сторін '='

C ++

1. Синтаксис шаблонів
2. Проблеми щодо спадкування алмазів
3. Безліч / відсутність стандартних бібліотек, якими володіють сучасні мови (хоча прискорення наближається).
4. IOStreams
5. Синтаксис, який використовується навколо IOStreams

Пітон

1. Пробіли значущі (іноді)
2. підкреслені ключові слова
3. Обмежена підтримка потоку (принаймні, зараз)
4. "Я" замість "цього"
5. Пробіли значущі (іноді)

Ціль-С

1) Немає просторів імен, а лише конвенції про ручне іменування - я не заперечую, що з точки зору розділення класів, але я сумую за тим, щоб змогти імпортувати всі визначення класів у простору імен в одному рядку (наприклад, import com.me.somelibrary. *).

2) У важливих областях, таких як підтримка RegEx, у бібліотеках є деякі дірки.

3) Синтаксис властивості трохи незграбний, для декларування властивості потрібно три рядки (у двох окремих файлах).

4) Мені подобається модель збереження / випуску, але це простіше, ніж слід, щоб випустити посилання, а потім випадково скористатися ним пізніше.

5) Хоча насправді не є мовною особливістю, Xcode настільки переплетений із використанням Objective-C, що я не можу не думати про цей аспект ... в основному автозавершення, дуже непросте. Це більше схожа на систему, яка нагороджує вас тим, що ви знайдете те, що хочете, існує, а потім представляє це як вибір. Але тоді я припускаю, що мені ніколи не подобалися двигуни автозаповнення.

C ++

• Струни.
  Вони не взаємодіють із рядками платформи, тому ви в кінцевому підсумку використовуєте std :: vector половину часу. Політика копіювання (копія під час запису чи глибока копія) не визначена, тому гарантії виконання не можуть бути надані для прямого синтаксису. Іноді вони покладаються на алгоритми STL, які не дуже інтуїтивно зрозумілі. Занадто багато бібліотек створюють власні, які, на жаль, набагато зручніші для використання. Якщо не доведеться їх поєднувати.

• Різноманітність представлення рядків
  Тепер це трохи проблема платформи - але я все ще сподіваюся, що було б краще, коли раніше був би доступний менш жорсткий стандартний клас рядків. Наступні рядкові представлення, які я часто використовую:

  • загальний LPCTSTR,
  • LPC (W) STR, виділений CoTaskMemAlloc,
  • BSTR, _bstr _t
  • (w) рядок,
  • CString,
  • std :: вектор
  • власний клас ( зітхання ), який додає перевірку діапазону та основні операції до (w) char * буфера відомої довжини

• Побудувати модель.
  Мені страждає смерть за весь час, витрачений на балаканину з тим, хто-що включає, передає декларації, оптимізуючи заздалегідь складені заголовки і включає в себе, щоб не менше примножувати час складання, переносими і т. Д. Це було чудово у вісімдесятих, але тепер? Існує так багато перешкод, щоб спакувати шматочок коду, тому його можна повторно використовувати, що навіть мам собаці нудно слухати мене.

• Важко розібрати
  Це робить зовнішні інструменти особливо важкими для написання та отримання правильного. І сьогодні нам, хлопцям C ++, бракує в основному ланцюга інструментів. Я люблю свої C # роздуми та делегатів, але можу жити без них. Без великого рефакторингу я не можу.

• Тематика занадто важка,
  мова навіть не розпізнає її (досі), і свободи компілятора - хоч і великі - болючі.

• Статична і ініціалізація на вимогу Технічно я тут обманюю: це ще один фрагмент головоломки у "загортанні коду для повторного використання": кошмар, щоб щось ініціалізувати лише тоді, коли це потрібно. Найкращим рішенням для всіх інших проблем із переглядом є кидання всього в заголовки, ця проблема говорить про "більше" - ти не можеш ".

Зрозуміло, багато цього виходить за межі суворої мовної сфери, але ІМО весь ланцюжок інструментів потрібно оцінювати та потребує розвитку.

JavaScript :

• ObjectПрототип може бути змінений. Кожен окремий об’єкт у вашій програмі отримує нові властивості, і щось, ймовірно, ламається.

• Усі об’єкти є хеш-картами, але їх важко безпечно використовувати як такі. Зокрема, якщо один із ваших ключів трапився __proto__, ви переживаєте проблеми.

• Немає закриття об'єкта в опорний час функції. Насправді, жодне закриття об'єкта - замість цього, thisвстановлюється кожного разу, коли викликається функція із позначенням об'єкта чи newоператором. Приводить до великої плутанини, особливо при створенні зворотних викликів подій, оскільки thisне встановлено те, що програміст очікує.

  • Висновок: виклик функції без позначення об'єкта або newоператора приводить до thisтого, що він буде рівний глобальному об'єкту, що призводить до великого злому.

• Оператор додавання перевантажений, щоб також здійснювати конкатенацію рядків, незважаючи на те, що дві операції принципово відрізняються. Результат болю, коли значення, яке ви очікуєте на число, насправді є рядком.

• ==і !=оператори виконують тип примусу. Порівняння різних типів включає перелік правил, які жоден смертний не може запам'ятати повністю. Це пом'якшується існуванням ===і !==операторів.

• І те, nullі undefinedінше існує з тонко різними, але надмірними значеннями. Чому?

• Дивний синтаксис для налаштування прототипів ланцюгів.

• parseInt(s)очікує номер у стилі С, тому трактує значення з провідними нулями як восьмеричні тощо. Ви можете принаймні, parseInt(s, 10)але поведінка за замовчуванням є заплутаною.

• Без області блоку.

• Може оголошувати одну і ту ж змінну не один раз.

• Можна використовувати змінну, не оголошуючи її, і в цьому випадку вона є глобальною і, ймовірно, порушує вашу програму.

• with { }.

• Дуже складно документувати з інструментами, подібними JavaDoc.

Пітон:

• Відсутність статичного набору тексту
• Обробка аргументів за замовчуванням (зокрема, те, що ви можете змінити аргумент за замовчуванням для майбутніх абонентів!)
• Занадто багато необхідних підкреслень (потрібно викликати конструктори __init__)
• Відсутність належних приватних членів і функцій (конвенція просто говорить про те, що більшість речей, які починаються з підкреслення, є приватними, за винятком усіх подібних речей __getattr__)
• Смішний синтаксис для printфайлу (але вони виправляють це в Python 3)

C #

• Я б хотів, щоб я міг switch()будь-який тип, і це caseмогло бути будь-яке вираження.

• Неможливо використовувати синтаксис об'єкта ініціалізатора з полями "readonly" / private setautoprops. Як правило, я хочу допомогти мові в створенні непорушних типів.

• Використання в {}протягом імен та класу і методи і майна / індексатор блоків і блоків з кількома операторів і ініціалізаторів масиву . Складно зрозуміти, де ти знаходишся, коли вони далеко один від одного або невідповідні.

• Я ненавиджу писати (from x in y ... select).Z(). Мені не хочеться повертатися до синтаксису виклику методу, оскільки в синтаксисі запиту щось не вистачає.

• Я хочу doзастереження про синтаксис запитів, яке подібне foreach. Але це насправді не запит.

Я дійсно досягаю тут. Я думаю, що C # є фантастичним, і важко знайти багато того, що зламано.

PHP

1. Немає функцій налагодження, якщо ви не керуєте сервером, і навіть тоді вони неначе смоктані
2. Надзвичайно велика кількість поганого PHP-коду, що плаває, дає всім програмістам PHP погану назву
3. Невідповідність іменування функцій
4. Неможливість мати статичну змінну, якщо я хочу її (я великий фанат динамічного набору тексту 90% часу)
5. REGISTER_GLOBALS - чорт

C (Гаразд, це не моє улюблене, але це ще не було зроблено.)

• Синтаксис бібліотеки сокетів
• Немає функцій перевантаження.
• Струни в стилі C
• Буфер перевищує.
• Криптичний синтаксис. Я не знаю, скільки разів я шукав такі речі, як атої, ляпав по лобі і кричав "Звичайно!"

EDIT: Можливо, я міг би придумати більше, якби вдався до більшої кількості бібліотечного коду (як це робилося з сокетами, але вони особливо погані), але я вже відчував, що мене обманюють, щоб вибрати C. Це так багато мов, що існують лише для того, щоб взяти хороші частини С і замінюють погане, що це ніби биття мертвого коня.

Звичайний Лисп:

1. Ключові слова часто занадто багатослівні.
2. Підтримка бібліотеки жалісна.
3. Не працює в ОС, які хочуть більш жорстко обробляти пам'ять.
4. Не має хороших можливостей для взаємодії з ОС.
5. Заклад "петлі" недостатньо визначений, і, звичайно, не виглядає Ліспі.

BrainF * ck

• Ваша родзинка полягає в тому, що ви Turing завершений ?! Я можу зробити більше в регулярних виразах Perl!

• Відсутність предметів. Давай, люди! Це як привіт ...

• Немає мережевих бібліотек. Все, що я хочу, - це обрізати веб-сторінку, GOSH.

• Ніяких першокласних функцій. Вітаємо - ви знайомитеся зі своїми друзями на Java.

• Нескінченна стрічка для зберігання і нічого іншого. Це настільки анально претензійно, що ми можемо так само писати Лісп.

JavaScript

1. числа як рядки - Математика може бути неприємною, коли числа інтерпретуються як рядки. 5 + 2 = 52? Grrr ...
2. дозволи - всі найкращі речі вимагають дозволу користувача!
3. оновлення екрана - для оновлення екрана браузер повинен перебувати в стабільному стані. Здається, не існує способу змусити оновлення екрана в середині сценарію.
4. Повільно - хоча Google Chrome хороший ...
5. Відмінності браузера роблять використання мови [цензурою].

PHP:

• Ніколи не можна бути впевненим, що певні майже поширені розширення доступні на всіх веб-серверах.
• намагається бути всім у майбутньому (goto, закриття, ...)
• багато ризиків для безпеки для недосвідчених користувачів
• більше перевантаження оператора було б добре
• всі бідні програмісти, які не навчаються, як змусити його працювати належним чином, і дають йому неправильне ім’я

Тим не менш, PHP - це (сценарій) мови. ;-)

VB6

1. Тільки для Windows.
2. Більше не підтримується.
3. Масиви можуть починатися з будь-якої кількості, а не нормалізуються до 0.
4. компільовані програми залежать від того, наскільки багато dll будуть правильно працювати.
5. Багато складних елементів керування, як-от контроль браузера або складні фрагменти коду, як правило, порушують IDE, коли ви запускаєте код некомпільований, але працює добре, коли компілюється.

Рубі - моя улюблена мова, ось що мені не подобається:

• Зелені нитки + блокування бібліотек С = гігантський збій
• Так болісно повільно
• Сама стандартна бібліотека не відповідає її використанню чуб! методи
• Модуль включати + розширення безладний.
• "Відкрити класи" неможливо визначити - я хочу додати String # dostuff, але я не хочу, щоб він просочився до всіх сторонніх бібліотек
• Немає рішення щодо упаковки двійкового розгортання.

Delphi:

• IDE трохи нестабільний.
• Прозорливість коду іноді плутається.
• Налагодження часом буває помилковим.
• Оновлення декількох файлів проекту може бути громіздким.
• Якщо запускається, коли один або більше пакетів недоступні, повідомлення про помилку вискакує кілька разів.

JavaScript

• Кожен скрипт виконується в єдиному глобальному просторі імен ... те, на що потрібно бути уважним під час роботи зі сценаріями з різних джерел

• Якщо змінна використовується, але вона не була визначена раніше, вона вважається глобальною змінною

• Постачальники браузерів складають стандарти за своїм бажанням, роблячи кодування для нас розробників, які використовують таку прекрасну мову, важче, ніж це повинно бути

• Чутливість до випадку - враховуючи, що не існує гідного IDE для розробки js з перевіркою часу компіляції

• Обхідні шляхи (наприклад, використання hasOwnPropertyметоду) для виконання деяких, інакше простих операцій.

Haskell:

1. Космічні витоки від ледачих оцінок.
2. Числова ієрархія не побудована щодо математичних абстракцій.
3. Суворий монадичний IO може ускладнити налагодження.
4. Великі реалізації обробляють введення-виведення способами, які не здаються повністю сумісними зі стандартом. (Зокрема, символи, що виводяться, виводять лише низькі 8 біт - і тоді вбудовується код, який використовує це припущення для виконання бінарних вводу / виводу. Ick.)
5. Асоціативність ($)оператора може бути змінена, щоб зробити деякі вирази красивішими.

Більшість із них не піднімаються до рівня ненависті, і є люди, які намагаються виправити або побудувати міцні шляхи вирішення для кожного з них.

Редагувати: Була певна плутанина щодо пункту 5. Зокрема, деякі люди, здається, вважають, що я мав на увазі порядок аргументів, чого я не знаю. Замість того, щоб пояснити, що я мав на увазі, я просто вкажу людей на наступне посилання, http://hackage.haskell.org/trac/haskell-prime/wiki/ChangeDollarAssociactivity , що добре виражає це.