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

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

Обратите внимание: если язык «плохой» только потому, что он не предназначен для конкретной вещи, это не дизайнерский недостаток, а дизайн, поэтому не указывайте такие неприятности языков. Если язык не подходит для того, для чего он предназначен, это, конечно, недостаток в дизайне. Реализация конкретных вещей и под капотом тоже не учитывается.

29 голосов | спросил Anto 1 Jam1000000amThu, 01 Jan 1970 03:00:00 +030070 1970, 03:00:00

4 ответа


42

Одно из моих больших раздражений - это случай, когда в случаях, когда C-производные языки делятся на следующий случай, если вы забыли для использования switch. Я понимаю, что это полезно в коде очень низкого уровня (например, Устройство Даффа ), но он обычно не подходит для кода уровня приложения и является общим источником ошибок кодирования.

Я помню примерно в 1995 году, когда впервые читал о деталях Java, когда я узнал о break Я был очень разочарован тем, что они сохранили дефолтное поведение по умолчанию. Это просто делает switch в прославленный switch с другим именем.

ответил Mic 5 Maypm11 2011, 23:42:45
41

Мне никогда не нравилось использование = для назначения и == для тестирования равенства на языках C. Потенциал путаницы и ошибок слишком высок. И даже не заставляйте меня начинать с === в Javascript.

Лучше было бы := для назначения и = для тестирования равенства. Семантика могла быть точно такой же, как и сегодня, где присваивание - это выражение, которое также дает значение.

ответил Mic 5 Maypm11 2011, 23:42:45
29

Выбор + в Javascript для добавления и конкатенации строк была ужасная ошибка. Поскольку значения являются нетипизированными, это приводит к византийским правилам, которые определяют, будет ли + добавлять или объединять, в зависимости от точного содержимого каждого операнда.

Вначале было бы легко ввести совершенно новый оператор, такой как $ для конкатенации строк.

ответил Mic 5 Maypm11 2011, 23:42:45
22

Препроцессор в C и C ++ представляет собой массивный kludge, создает абстракции, которые просачиваются подобно ситам, поощряет код спагетти через гнезда крысы #ifdef операторам и требует ужасающе нечитабельных имен ALL_CAPS, чтобы обойти его ограничения. Корень этих проблем состоит в том, что он работает на текстовом уровне, а не на синтаксическом или семантическом уровне. Он должен был быть заменен реальными языковыми особенностями для его различных вариантов использования. Вот несколько примеров, хотя, по общему признанию, некоторые из них решены в C ++, C99 или неофициальных, но de facto стандартных расширениях:

  • #include должен быть заменен реальной системой модулей.

  • Встроенные функции и шаблоны /генераторы могут заменить большинство случаев использования функций.

  • Для объявления таких констант может быть использована некоторая функция постоянной времени манифеста /компиляции. расширения Dum enum отлично работают здесь.

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

  • String mixins можно использовать для использования кода для инъекций кода .

  • static if или version могут использоваться для условной компиляции.

ответил Mic 5 Maypm11 2011, 23:42:45

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132