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

Усі мови програмування мають свої недоліки в дизайні просто тому, що жодна мова не може бути ідеальною, як і більшість (усіх?) Інших речей. Що убік, яка помилка дизайну в мові програмування вас найбільше дратувала через вашу історію як програміста?

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

Одне з моїх великих неприємностей - це те, як switchвипадки у мовах, що походять зі С, за замовчуванням переходять до наступного випадку, якщо ви забудете використовувати break. Я розумію, що це корисно в коді дуже низького рівня (наприклад , пристрій Даффа ), але він зазвичай не підходить для коду рівня програми та є загальним джерелом помилок кодування.

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

Мені ніколи не сподобалось використання =для призначення та ==для тестування рівності на мовах, що походять з С. Потенціал плутанини та помилок занадто високий. І навіть не запускайте мене ===в Javascript.

Краще було б :=для призначення та =для перевірки рівності. Семантика могла бути точно такою, якою є сьогодні, коли присвоєння - це вираз, який також дає значення.

Страшна помилка вибору +в Javascript як для додавання, так і для з'єднання рядків . Оскільки значення не типізовані, це призводить до візантійських правил, які визначають +, додаватимуть чи об'єднуватимуться залежно від точного вмісту кожного операнда.

На початку було б легко запровадити абсолютно новий оператор, такий як $конкатенація рядків.

Я вважаю Javascript за замовчуванням глобальним для основної проблеми, і часто є джерелом помилок, якщо ви не використовуєте JSLint тощо

Препроцесор в C і C ++ - це масова хитрість, створює абстракції, які просочуються, як сита, заохочує код спагетті через гніздо #ifdefвисловлень щурів і вимагає жахливо нечитаних ALL_CAPSімен, щоб вирішити його обмеження. Корінь цих проблем полягає в тому, що вона діє на текстовому рівні, а не на синтаксичному чи семантичному рівні. Її слід було замінити справжньою мовою для різних її випадків використання. Ось кілька прикладів, хоча, правда, деякі з них вирішені в C ++, C99 або неофіційних, але фактично стандартних розширеннях:

• #include повинні були бути замінені реальною модульною системою.

• Вбудовані функції та шаблони / дженерики можуть замінити більшість випадків використання функціональних викликів.

• Якась функція константи часу маніфеста / компіляції може бути використана для оголошення таких констант. D-розширення enum тут чудово працюють.

• Реальні макроси синтаксичного дерева можуть вирішити безліч різних випадків використання.

• Струнні міксини можуть бути використані для випадку використання коду.

• static ifабо versionтвердження можуть використовуватися для умовної компіляції.

Можна було б перерахувати сотні помилок на сотнях мови, але ІМО - це не корисна вправа з точки зору дизайну мови.

Чому?

Тому що щось, що було б помилкою в одній мові, не було б помилкою в іншій мові. Наприклад:

• Перетворення C на керовану (тобто зібрану сміття) мову або приборкання примітивних типів обмежило б її корисність як напівпереносну мову низького рівня.
• Додавання Java-пам’яті управління стилем C (наприклад, для вирішення проблем щодо продуктивності) може порушити це.

Там є уроки , які можна витягнути, але уроки рідко зрозумілі, і щоб зрозуміти їх , ви повинні розуміти технічні компроміси ... і історичний контекст. (Наприклад, громіздка реалізація дженериків на Java - це наслідок важливої ​​вимоги бізнесу щодо підтримки зворотної сумісності.)

ІМО, якщо ви серйозно ставитесь до проектування нової мови, вам потрібно фактично використовувати широкий спектр існуючих мов (і вивчати історичні мови) ... і скласти власну думку про те, які помилки. І потрібно мати на увазі, що кожна з цих мов була розроблена в певному історичному контексті, щоб заповнити певну потребу.

Якщо є загальні уроки, які слід засвоїти, вони знаходяться на "мета" рівні:

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

C і C ++ : усі цілі типи, які нічого не означають .

Особливо char. Це текст чи це крихітне ціле число? Якщо це текст, це символ "ANSI" або блок коду UTF-8? Якщо це ціле число, чи воно підписане чи без підпису?

int повинен був бути "нативним" цілим числом, але для 64-бітних систем це не так.

longможе бути або не бути більшим за int. Він може бути або не бути розміром вказівника. Це майже довільне рішення з боку авторів-компіляторів, будь то 32-бітне чи 64-бітове.

Безумовно, мова 1970-х. Перед Unicode. До 64-бітних комп'ютерів.

null.

Його винахідник Тоні Хоар називає це "помилкою в мільярд доларів" .

Він був введений в ALGOL в 60-х роках і існує в більшості часто використовуваних мов програмування сьогодні.

Краща альтернатива, що використовується в таких мовах, як OCaml та Haskell, - можливо . Загальна думка полягає в тому, що посилання на об'єкти не можуть бути нульовими / порожніми / неіснуючими, якщо тільки немає явних вказівок, що вони можуть бути такими.

(Хоча Тоні дивовижний у своїй скромності, я думаю, що майже хто-небудь допустив би таку ж помилку, і він просто трапився першим.)

У мене виникає відчуття, що люди, які розробили PHP, не використовували звичайну клавіатуру, вони навіть не використовують клавіатуру colemak, тому що вони повинні зрозуміти, що вони роблять.

Я розробник PHP. PHP не цікаво вводити.

Who::in::their::right::mind::would::do::this()? ::Оператор вимагає зсуву утримання , а потім два натискання клавіш. Яка трата енергії.

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

$last = $we.$have.$the.$dumb.'$'.$character. Знак долара використовується надзвичайно багато разів і вимагає розтягування нагород до самої вершини клавіатури плюс натискання клавіші shift.

Чому вони не могли розробити PHP для використання клавіш, які набагато швидше набирати? Чому не вдалося we.do.this()або почати функцію vars з ключа, який вимагає лише одного натискання клавіші - або зовсім не (JavaScript) і просто заздалегідь визначити всі вари (як це я маю робити для E_STRICT у будь-якому випадку)!

Я не повільний машиніст - але це лише кульгавий вибір дизайну.

Використання робочого столу надихнуло форму всередині asp.net .

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

Для мене це абсолютна відсутність PHP умов імен і упорядкування аргументів у його стандартній бібліотеці.

Хоча необхідність JASS нівелювати посилання після звільнення / видалення посилального об'єкта (або посилання буде просочуватися і кілька байтів пам'яті втрачено) є більш серйозною, але оскільки JASS є єдиною мовою, це не так важливо.

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

Розпад масиву в C і, отже, C ++.

Примітивні типи на Java.

Вони порушують принцип, що все є нащадком java.lang.Object, що з теоретичної точки зору призводить до додаткової складності мовної специфікації, і з практичної точки зору вони роблять використання колекцій надзвичайно стомлюючим.

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

Я найкраще знаю Перла, тому я підберу його.

Перл спробував багато ідей. Деякі були добрі. Деякі були погані. Деякі з них були оригінальними і не були широко скопійовані з поважних причин.

Одне - це ідея контексту - кожен виклик функції відбувається в списку або скалярному контексті, і може робити абсолютно різні речі в кожному контексті. Як я вказував на http://use.perl.org/~btilly/journal/36756, це ускладнює кожен API і часто призводить до тонких проблем із дизайном у коді Perl.

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

Ще одна поширена помилка, допущена багатьма мовами, полягає в тому, щоб почати, пропонуючи динамічні рамки, а не лексичні. Пізніше повернути це дизайнерське рішення важко, і це призводить до довготривалих бородавок. Класичний опис цих бородавок в Perl - http://perl.plover.com/FAQs/Namespaces.html . Зауважте, що це було написано до того, як Perl додав ourзмінні та staticзмінні.

Люди законно не погоджуються щодо статичного та динамічного набору тексту. Мені особисто подобається динамічний набір тексту. Однак важливо мати достатню структуру для того, щоб помилки друкувати. Perl 5 добре справляється з цим суворо. Але Перл 1-4 помилився. Декілька інших мов мають шашки, які виконують те саме, що і суворі. Поки ви добре домагаєтесь перевірки ворсинок, це прийнятно.

Якщо ви шукаєте більше поганих ідей (їх багато), вивчіть PHP та вивчіть його історію. Моя улюблена помилка минулого (давно виправлена ​​через те, що вона призводила до такої кількості дірок у безпеці) була дефолтом, що дозволяла кожному встановлювати будь-яку змінну, передаючи параметри форми. Але це далеко не єдина помилка.

Неоднозначність JavaScripts для блоків коду та літералів об'єктів.

  {a:b}

може бути кодовим блоком, де aє мітка і bє виразом; або він міг би визначити об'єкт, атрибут aякого має значенняb

Я повернусь до FORTRAN і нечутливості до білого простору.

Це пронизало специфікацію. ENDКарта повинна була бути визначена у вигляді плати з «E», з «N», і «D» в зазначеному порядку в колонках 7-72, і без будь - яких інших nonblanks, а не карти з «END» у належний стовпчики і більше нічого.

Це призвело до легкої синтаксичної плутанини. DO 100 I = 1, 10був оператором керування циклом, тоді як DO 100 I = 1. 10був оператором, який присвоював значення 1.1 змінної, що називається DO10I. (Факт, що змінні можна було створити без декларації, їх тип залежно від їх першої літери, сприяв цьому.) На відміну від інших мов, не було можливості використовувати пробіли для розділення лексем, щоб дозволити розбіжність.

Це також дозволило іншим писати дійсно заплутаний код. Є причини, чому ця функція FORTRAN ніколи не повторювалася.

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

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

Я вірю в DSL-файли (мови, що визначаються для домену), і одна річ, яку я ціную в мові, це якщо вона дозволяє мені визначати DSL поверх неї.

У Ліспі є макроси - більшість людей вважають це хорошою справою, як і я.

У C і C ++ є макроси - люди скаржаться на них, але я зміг їх використовувати для визначення DSL.

На Яві вони залишилися осторонь (а отже, і в C #), і відсутність їх була оголошена чеснотою. Звичайно, це дозволяє мати інтелігенцію, але для мене це лише твір . Щоб зробити свій DSL, я повинен розгорнутись від руки. Це біль, і це змушує мене виглядати як поганий програміст, навіть якщо це дозволяє мені робити ще куди більше з тонни коду.

Заяви , будь-якою мовою, яка їх має. Вони нічого не роблять, що ви не можете зробити з виразами і не заважають вам робити багато речей. Існування ?:потрійного оператора - лише один приклад того, що потрібно намагатися їх обійти. У JavaScript вони особливо дратують:

// 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')

Для мене проблема дизайну, яка переслідує всі мови, похідні від C; а саме - " звисаюче інше ". Ця граматична проблема повинна була бути вирішена в C ++, але вона переносилася на Java та C #.

Я думаю, що всі відповіді на даний момент вказують на єдиний недолік багатьох основних мов:

Немає можливості змінити основну мову, не впливаючи на зворотну сумісність.

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

EDIT.

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

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

Ярке ціле арифметичне переповнення Java

І Java, і C # мають набридливі проблеми з їх типами через бажання зберегти зворотну сумісність при додаванні загальних даних. Java не любить змішувати генеричні файли та масиви; C # не дозволить використовувати деякі корисні підписи, оскільки ти не можеш використовувати типи значень як межі.

Як приклад останнього, розглянемо це

публічний статичний T Аналіз <T> (тип <T> типу, рядок рядка), де T: Enum

Аналіз публічного статичного об'єкта (Тип типу, рядок рядка)

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

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

tl; dr: подумайте про параметричний поліморфізм, коли ви почнете розробляти систему типу, а не після публікації версії 1.

Я відчуваю, що я відкриваю себе, щоб отримати полум’я, але я дуже ненавиджу здатність передавати звичайні старі типи даних за посиланням на C ++. Я лише ненавиджу можливість передати складні типи за посиланням. Якщо я дивлюсь на функцію:

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

З точки виклику, не можна сказати, що bar, що може бути визначено у зовсім іншому файлі, є:

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

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

bar(&a);

значно читабельніший.

АЛЬТЕР

Коли я дізнався COBOL, твердження ALTER все ще було частиною стандарту. Коротше кажучи, ця заява дозволить вам змінювати виклики процедури під час виконання.

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

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

Найгірший гріх мови програмування - це не чітке визначення. Я пам'ятаю випадок C ++, який за своїми джерелами:

1. Був настільки жорстоко визначений, що вам не вдалося отримати програму для складання та запуску за наступними книгами чи прикладами.
2. Після того, як ви налаштували програму на компіляцію та запуск під одним компілятором та ОС, вам доведеться почати все, якщо ви переключили компілятори чи платформи.

Як я пам’ятаю, потрібно було десятиліття, щоб C ++ визначився достатньо добре, щоб зробити його таким же професійним, як C. Це щось, що ніколи не повинно повторитися.

Щось інше, я вважаю гріхом (чи варто піти на іншу відповідь?) - це більше, ніж один "найкращий" спосіб зробити якесь спільне завдання. Це справа (знову ж таки) C ++, Perl та Ruby.

Класи на C ++ - це якась вимушена модель дизайну в мові.

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

Мені до цього прийдеться, але все одно, компілятори C ++ так важко писати, що ця мова відчуває себе монстром.

Незважаючи на те, що в кожній мові є свої помилки, жодна неприємність, коли ви знаєте про них. За винятком цієї пари:

Складний синтаксис у поєднанні з багатомовним API

Особливо це стосується такої мови, як Objective-C. Не тільки синтаксис є надзвичайно складним, але API використовує назви функцій, такі як:

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

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

1. підписані символи на С - мерзота, придумана для того, щоб математики мали великі колекції дрібних предметів
2. Використання корпусу для перенесення смислового контенту - знову ж таки для математиків, яким не потрібно говорити і ніколи не вистачає місця для їх формул
3. Дозволити / Звичайне присвоєння та Поставити призначення в Основних діалектах - тут я не думаю, що тут займаються математики