it-swarm.com.ru

Какие пять вещей ты ненавидишь в своем любимом языке?

В последнее время на Stack Overflow была куча Perl-ненависти, поэтому я подумал, что подам мой вопрос " Пять вещей, которые вы ненавидите за ваш любимый язык " в Stack Overflow. Возьми свой любимый язык и скажи мне пять вещей, которые ты ненавидишь в этом. Это могут быть вещи, которые вас раздражают, допущенные недостатки дизайна, признанные проблемы с производительностью или любая другая категория. Вы просто должны ненавидеть это, и это должен быть ваш любимый язык.

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

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

Мне все равно, какой язык вы используете. Не хотите использовать определенный язык? Тогда не надо. Вы проходите тщательную проверку, чтобы сделать осознанный выбор, и все еще не используете его? Хорошо. Иногда правильный ответ звучит так: "У вас сильная команда программистов с хорошими практиками и большим опытом работы в Bar. Переход на Foo будет глупым".


Это хороший вопрос и для обзоров кода. Люди, которые действительно знают кодовую базу, будут иметь всевозможные предложения для этого, и те, кто не знает это так хорошо, имеют неконкретные жалобы. Я спрашиваю: "Если бы вы могли начать этот проект заново, что бы вы сделали по-другому?" В этой фэнтезийной стране пользователи и программисты могут жаловаться на все, что им не нравится. "Мне нужен лучший интерфейс", "Я хочу отделить модель от представления", "Я бы использовал этот модуль вместо другого", "Я бы переименовал этот набор методов", или что бы они ни делали не нравится о текущей ситуации. Вот как я понимаю, что конкретный разработчик знает о кодовой базе. Это также ключ к пониманию того, насколько эго программиста связано с тем, что он говорит мне.

Ненависть - не единственное измерение того, как много людей знают, но я нахожу это довольно хорошим. То, что они ненавидят, также подсказывает мне, насколько хорошо они думают об этом предмете.

404
brian d foy

PHP

  • Почти каждая стандартная функция находится в глобальном масштабе
  • Непоследовательный порядок аргументов функции
  • Непоследовательная функция именования
  • Регистронезависимые функции
  • Сценарий может вести себя по-разному в зависимости от файла php.ini
  • Возможность использовать неопределенные переменные
  • В некоторых случаях приходится присваивать результат переменной, прежде чем его можно будет использовать в функции

И гораздо более субъективно:

  • Динамический набор текста
2
Yacoby

Python

  1. Django для Python 3 не существует.
  2. Статическая типизация. Да, динамическая типизация - отличная вещь, но иногда я хочу сделать ее статической.
  3. Правильная поддержка юникода (исправлено в Python 3)
  4. Наименование строителей. Я ненавижу все это подчеркивает __in__ мой код.
  5. Темы не очень эффективны
2
Davinel

Общий LISP

  • условия не являются классами (поскольку классы появились позже), хотя их интерфейс почти идентичен
  • некоторые имена просто странные, например, flet/label (единственное отличие: область действия) и defvar/defparameter (единственное отличие: поведение, если оно уже определено) или любая из функций изменения битов (dpb, ldb и т. д.)
  • пакеты ... действительно трудно понять правильно - каждый раз, когда я думаю, что понимаю их, они не делают то, что я хочу
  • встроенные структуры данных и функции не так универсальны, как могли бы быть (например, почему я не могу определить свою собственную хеш-функцию переносимо?)
  • несколько пространств имен для функций, переменных и т. д. (я в принципе не против этого, но CL сделал это слишком сложным; Норвиг сказал, что он не может отличить спецификацию, но, по-видимому, существует как минимум 7 пространств имен)
2
Ken

Я больше всего ненавижу в своем любимом языке то, что мой выбор постоянно меняется. Каждый раз, когда я думаю, что нашел The One, я нахожу пять (или больше) вещей, которые я ненавижу по этому поводу. И тогда трава выглядит зеленее там ...

2
WReach

Python:

Я все еще умеренный пользователь Python, поэтому мои жалобы могут быть просто блокировкой знаний или неправильным использованием. Комментарии приветствуются. Я люблю этот язык.

  1. Плохая поддержка ниток и GIL. Если вы хотите использовать многоядерную платформу, большинство программистов python, вероятно, порекомендуют многопроцессорную обработку или какую-то другую, не используйте многопоточность. Это не даст вам ожидаемого результата.
  2. свойство только для переменной экземпляра. _class_var = свойство (classmethod (some_method)) просто не будет работать. Как я могу получить свойство обернутой переменной класса?
  3. нет контроля доступа. Все элементы управления доступом имеют искажение синтаксиса. Например, private - это __private, protect - _protected и т.д. ... И надеюсь, что все программы python следуют соглашению об именах. Давай, мы можем сделать лучше, чем это.
  4. Я согласен с философией python о простом и понятном синтаксисе, но, по моему мнению, некоторые простые и понятные синтаксисы, которые не поддерживаются, кажутся здравым смыслом. Например, a ++, ++ a, a-- и --a, self-de/increment, что с ними не так? foo = (a> b? a: b) унарная операция, что с ними не так? (Я знаю, что в py2.6 введено нечто подобное, но, учитывая широкую поддержку почти всех других языков для этого простого синтаксиса, зачем изобретать колесо? Почему бы просто не следовать лучшей практике? Разве хорошая вещь не должна оставаться в хорошем? "форма"?)
  5. Программа для интерфейса. Python не имеет интерфейса или абстрактного понятия класса (в py3k есть нечто, называемое abc), все конкретно. Я думаю, что предоставление "интерфейсного" или "абстрактного" ключевого слова для создания скелета класса и наследования и расширения класса защиты не будет плохой идеей. Это помогает при проектировании сверху вниз. В настоящее время мне просто нужно заполнить каждый из методов NotImplementedError, довольно утомительная работа.
  6. Я должен добавить это. версия менее 3.x имеет типы str и unicode. Это настоящий кошмар. Это делает смешивание ascii и non-ascii/unicode наиболее вероятным сбоем (плохо, плохо)

Я видел, как люди жалуются на скорость. Я не понимаю этого. Это интерпретируемый язык, код не компилируется в машинный код до времени выполнения, это просто его природа. Вы не можете сравнить скорость от интерпретируемого языка до компилируемого. Насколько я вижу, среди языков интерпретации/сценариев python не медленный.

2
jimx

PHP:

  • Абсурдная функция assert () ... она запускает eval () для кода внутри
  • ?> тег удаляет все последующие строки после него?!
  • Странная обработка числовых строк (попробуйте их как ключи массива)
  • Болезненная поддержка юникода, которая выглядит больше не будет, будет решена PHP 6
  • Низкая стоимость ввода означает, что 95% дают PHP программистам ужасное имя - и пытаться найти кого-то из 5% нанимающих - это безумие.
2
user350443

Общий LISP

  • Отсутствие стандартных библиотек для более современных функций (сокеты, потоки, ...)
  • Может использовать стандартизированный пользовательский интерфейс, который отображается на родную систему управления окнами
  • Способность схемы назначать лямбда-выражение переменной и использовать переменную непосредственно, так как вызов функции выглядит лучше, чем APPLY для FUNCALL. Побочный эффект наличия нескольких пространств имен, я думаю
  • Стандартизированная система упаковки на уровне исходного кода для библиотек, чтобы их можно было легко использовать из нескольких реализаций

Интересно, на что был бы похож типизированный LISP

2
Gautham Ganapathy

Я выхожу на конечность, так как не могу использовать ее на полную ставку, но все равно попробую!

Perl 6

  1. func ("frew")! = func ("frew")
    • Это меня раздражает, но для этого есть все основания. В Perl 5 print (5 + 6) * 10 до сих пор время от времени получает меня
  2. Может быть легче разобрать, чем Perl 5 во многих местах, но иногда он все еще убивает моего редактора
  3. В нем все еще много шума линии Perl 5, который пугает многих людей. Это значит, что их сложнее разбудить и т.д.
  4. Еще нет библиотек.
    • Это не будет проблемой, если Perl 6 действительно поддержит Perl 5, но это может быть бременем, которое не стоит нести.
  5. Здесь нет REPL или того, что рубинисты называют irb.
    • Надежный интерактивный Perl 6 с дополнением табуляции, цветовым кодированием и т.д. Сделает его использование и обучение более приятным.
  6. В настоящее время документация в основном английская спецификация. Не совсем легко читать.
  7. Я знаю, что это глупое клише, но его еще нет!
    • (Мне разрешено жаловаться, потому что я помогаю :-P)

Первые три языка; остальные на самом деле не сам язык, а тот факт, что он еще не вышел.

2
Frew Schmidt

Perl

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

  • Функции write() и format().

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

Я уверен, что кто-то не согласится, но когда я посмотрел на них, надеясь, что они решат мою проблему, я обнаружил, что это "мир боли" (цитируя Большого Лебовски), и надеюсь, что Perl6 либо покончил с их или, лучше, полностью переписать их, чтобы они были несколько более полезными и полезными.

2
Chris Lutz

Python

  1. Стандартная библиотека во многих местах не подчиняется собственным правилам стиля. (РЕР-8)
  2. Супер-ключевое слово Py3k полно нежелательной магии (вы не можете присвоить его другому имени, работает без self , почему у нас есть этот явный параметр в все?)
  3. Поддержка Unicode не полная в Py2k и отстой в Py3k (стандартный ввод в Unicode, без двоичных данных! WTF? Создание нового стандарта WSGI - это хакерство).
  4. GIL. Очень ограниченная поддержка многопоточности (с CPython)
  5. PyPI (индекс пакетов Python) отстой. Завистливый взгляд на рубины
2
passy

Haskell

  1. Иногда система типов чувствует себя задом наперед. Что если я не хочу, чтобы компилятор определял типы для моих переменных? Что делать, если я хочу наоборот, где он проверяет ограничения указанных переменных? Например, вместо того, чтобы выводить тип элементов списка, он гарантирует, что все они принадлежат к определенному классу типов. Это тонкая, но огромная разница, которая мешает мне программировать пользовательские интерфейсы. Это можно сделать, но это требует больше усилий, чем в некоторых других языках. Haskell качается для частей не-пользовательского интерфейса, но пользовательский интерфейс я оставляю на нетипизированный язык.

  2. Разрешение построения бесконечных значений иногда приводит к действительно расстраивающим ошибкам.

  3. NoMonomorphismRestriction.

  4. Обработка строк иногда кусает меня в задницу, и вы не узнаете об этом, пока ваша программа не выйдет из строя, потому что вы неправильно их перепутали. Что-то здесь не так, когда мы теряем информацию о типах, которая должна была предотвратить это.

  5. Классы типов должны автоматически выводиться для тривиальных случаев, таких как типы свидетелей, но существует серьезный потенциал для злоупотреблений.

2
user350201

C

  • Он настолько гибок и силен, что действительно легко написать действительно ужасный или совершенно опасный код (или, если хотите, "с большой силой приходит большая ответственность").
  • '=' для присваивания и '==' для равенства; легко спутать в утверждениях "если".
  • Реализация ряда фундаментальных частей языка зависит от компилятора; например размер основных типов, порядок битов в битовых полях, заполнение и порядок байтов в объединениях.
  • Битовые поля не могут быть параметризованы (то есть вы можете использовать массив целых чисел, но у вас не может быть массива битов).
  • Обработка строк может быть улучшена.
2
Steve Melnikoff

c #:

1) статические методы должны быть членами класса

2) методы статического расширения могут быть добавлены только к статическим классам

3) Реализация интерфейсных функций не помечена чем-то вроде "переопределения", чтобы показать, что они принадлежат базовому классу или интерфейсу (что затрудняет гарантию того, что вы переопределяете ожидаемый метод (с правильной сигнатурой) с помощью только проверки кода) ,.

У меня только 3. Я думаю, это довольно хорошо.

2
Frank Schwieterman

C #

Я знаю, что это глупо, но я бы хотел, чтобы типы данных конвертировались в то, что я хочу, самостоятельно, без необходимости добавлять (int) или Convert.ToInt32 или что-то еще. Это просто сэкономит мне время. И меня раздражает, что если я что-то напишу для вывода int, а потом окажется, что мне нужно long, то часто мне приходится проходить и менять все, что я сделал, чтобы это работало. Просто сделай это для меня!

Извините, не могу вспомнить пять, но я новичок в этом, так что, возможно, я вернусь и добавлю больше позже: P

2
Sir Graystar

Пять вещей, которые я ненавижу в C++

  • Время ссылки. С помощью распределенных сборок я могу перестроить весь наш проект в то же время, что и для запуска нашего компоновщика.
  • Нет стандартного способа предотвращения переупорядочения операций с памятью. Использование объединенной в запись памяти обычно требует злоупотребления ключевым словом volatile. Предотвращение переупорядочения чтения (часто критически важного для оптимизации при работе с математическими конвейерами SIMD) обычно достигается путем внедрения нулевого блока ASM в середине процедуры.
  • Многошаговые макросы для решения проблем строкового преобразования:
#define STR_LINE2(x) #x#define STR_LINE(x)   STR_LINE2(x)#define LINE_NUMBER STR_LINE(__LINE__)
  • Просто больно делать манипуляции со строками.
  • Распространение нестандартизированных вариантов printf (vsnprintf_s vs _vsnprintf_s).
2
Vorlauf

Python, снова:

  1. Нет ключевого слова переключения. И нет, словарь не является заменой для него. Даже не куча Elif операторов.

  2. Непоследовательная обработка разрыва строки. Почему я могу сделать:

     test = (1,
             2,
             3)
    

    И не:

    from itertools import cycle,
                          islice,
                          izip
    

    Почему я не могу сделать:

    if stuff \
       and foo \
       or bar:
        return "Formated string with %(arg)s" % \
               {'arg': "bloody slash"}
    

    без использования косой черты?

  3. Существует не один очевидный и только один способ сделать это. Python терпит неудачу под своим девизом, точно так же, как Java не удалось выполнить "Писать один раз, где-нибудь запустить".

    # what somebody from an another language would do
    if not test.has_key('foo'):
        test['foo'] = 0
    n = test['foo'] = test['foo'] + 1
    

    против

    # what an agnostic beginer would do 
    try:
        test['foo'] += 1
    except KeyError:
        test['foo'] = 1
    n = test['foo']
    

    против

    # what you end up after looking for dictionary default value in the python doc
    test.setdefault('foo', 0)
    n = test['foo'] = test['foo'] + 1
    

    против

    # what I would do
    n = test['foo'] = test.get('foo', 0) + 1
    

    И хуже всего то, что они не делают точно то же самое. Есть тонкие различия.

  4. Выбор между пробелами и вкладками. Там не должно быть никакого выбора. Выбери, положи его в камень и прекрати драться.

  5. Почему вы можете это сделать:

    test = {}
    test['foo'] = 0
    

    но нет:

    test = []
    test[] = 0
    

P.S: " ".join(l) хорошие люди. Хватит жаловаться на это, это не очевидно, но с учетом шаблона итератора, это просто правильный способ сделать это.

2
e-satis

С #

  • Отсутствие множественной диспетчеризации в зависимости от типа времени выполнения аргументов метода. dynamic должен решить большую часть этого, но он еще не выпущен.
    • Реализация интерфейса является декларативной, а не структурной. Мне очень нравится, как язык Google Go делает типы
    • Выполнение асинхронных вызовов методов действительно громоздко (и я уверен, что все потоки являются потоками ОС, а не легкими)
    • Нет макрос системы. Я не говорю здесь о макросах в стиле C; Я говорю о макросах в стиле LISP/Scheme
    • Операторы являются статическими методами, и их подписи чрезмерно ограничены (и вы не можете создавать новые).
  • 2
    Robert Davis

    EL - язык выражений, ${...} и #{...} на страницах JSP и JSF 2.0 Facelets, который используется для извлечения данных из базового кода Java.

    • Все забавные вещи, такие как вызовы методов с параметрами и именование на основе аннотаций, присутствуют только в EL в Java EE 6, который доступен только в Glassfish v3.
    • Это королевская боль: 1) получить правильные фляги для более раннего контейнера Servlet 2.5 и 2) заставить их работать, не мешая какой-либо предыдущей реализации, доступной в контейнере.
    • Имея только более раннюю версию JSF, такую ​​как 1.2, убирает вызовы методов и оставляет вас работать с f: setPropertyActionListener - http://weblogs.Java.net/blog/2009/07/22/say-sayonara -спал - что, поверьте мне, не очень приятно.
    • У синтаксического анализатора EL нет представления о том, откуда взят фрагмент, предназначенный для синтаксического анализа и интерпретации, поэтому вы стремитесь дать всему идентификатор, чтобы вы могли, по крайней мере, определить, какой тег сделал его раздражительным.
    • Eclipse выдает предупреждение при каждом вызове метода EL, так как это JSF 1.2. только тоже.
    2
    Thorbjørn Ravn Andersen

    С #

    • Типы ссылок по умолчанию обнуляются; Нулевое ключевое слово в языке нетипизировано.
    • Отсутствие дискриминационных союзов
    • Исключения: по умолчанию , неисключительный метод обработки ошибок - альтернативы мало.
    • синтаксис и ограничения операторов архаичного переключения
    • Излишнее различие между конструкторами + статическими методами
    • Статические методы не могут быть частью интерфейса
    • Отсутствие реализации интерфейса по форме, а не явной реализации интерфейса, что приводит к многочисленным хакерским разработкам языка, таким как синтаксис запроса linq, foreach, коллекция и объектные инициализаторы - ни один из которых не может быть гибко использован повторно. Например, синтаксис инициализатора объекта может быть хорошим, но он плохо работает с неизменяемыми объектами.
    • Невозможно унаследовать "интерфейс" класса независимо от реализации, что приводит к дублированию кода и избыточному коду, который предоставляет интерфейсы, абстрактные базовые классы, несколько распространенных реализаций и отсутствие возможности выбирать биты каждого из них для использования. Также; приводит к слишком большому количеству кода, который тесно связан с конкретной реализацией, поскольку обычно явно ссылаются на тип реализации, а не на интерфейс.
    • Невозможно умножить наследование через композицию, поскольку "интерфейс" классов тесно связан с его реализацией; эффективно отсутствие миксинов.
    • Вышеуказанные ограничения интерфейсов приводят к распространению практически идентичных интерфейсов, которые не перекрываются естественным образом в какой-либо иерархии типов. IComparable против IEquatable против IComparable<T> против object.Equals против operator == и т. д. и т. д. По сути, создание пользовательского типа, удовлетворяющего всем этим вещам, требует гораздо больше работы, чем необходимо (в частности, для классов коллекции). Очевидно, что разработчики языка понимают это, отсюда и различные обходные пути для таких вещей, как linq, foreach и инициализаторы коллекций, которые работают по форме, а не по интерфейсу.
    • Избыточное использование скобок и фигурных скобок, а не макет-структура.
    • Возвращаемые значения можно игнорировать, что ограничивает эффективность вывода типа.
    • Перечисления не являются обычным типом и не могут иметь методов. Кроме того, значения перечисления не являются типобезопасными и могут быть инициализированы в 0, несмотря на отсутствие значения 0. Смешивание метафор путем объединения перечислений типа flag и non-flag.
    • Отсутствие надлежащей поддержки типов значений. Типы значений не могут быть унаследованы, имеют разную семантику конструктора и плохо работают из-за ограничений CLR. Кроме того, запутанная семантика в отношении типов значений: некоторые значения действительно являются значениями (и не могут быть изменены), а другие действительно являются псевдонимами, ненулевыми ссылками (переменными). Это становится особенно запутанным в отношении следующего вопроса:
    • Семантическое различие между полями и свойствами, особенно в связи с отсутствием модификатора изменчивости (аля C++ const)
    • Не могу специализировать дженерики
    • Невозможно предоставить параметры универсального типа по умолчанию (например, фабричные универсальные параметры)
    • отсутствие typedef делает непростыми для использования дженерики (using - это ограниченный, но полезный заменитель!)
    • Не может обобщать вещи, отличные от типов (например, функции, простые значения или имена). Это означает, что вы не можете сделать что-то вроде создания обобщенной реализации свойства зависимостей, что приводит, в конечном счете, к неприятным реализациям таких вещей, как свойства зависимостей, и в результате к чрезмерному использованию фрагментов кода и плохо читаемого кода.
    • Ограниченная возможность указать требования к общим типам, например, универсальный метод суммирования, который принимает int, double и bigint (без хитрых и часто медленных хаков).
    • Реализация метода интерфейса или переопределение виртуального метода не может возвращать более определенный тип или принимать более общий тип; т.е. ограниченная поддержка со/контравариантности даже в C # 4.
    2
    Eamon Nerbonne

    Пять вещей, в которых я негодую Nemerle:

    • Локальные функции не могут дать
    • Возможность компиляции лямбды иногда зависит от того, будет ли она встроена
    • Несоответствующая семантика значения/ссылочного типа для кортежей
    • Случайная неоднозначность между индексами массива и аргументами типа
    • Отсутствие общего усыновления
    2
    Don Reba

    С ++

    • загадочные сообщения об ошибках, когда используются шаблоны
    • отсутствие шаблонных ограничений (многие случаи можно обойти с помощью метапрограммирования шаблонов, но это приведет к нечитаемому коду (по крайней мере, для средних программистов) в большинстве случаев)
    • указатель на синтаксис функции-члена
    • комитет по стандартам c ++ должен выпускать официальные стандарты чаще (или, по крайней мере, выпускать отдельные обновления для самой стандартной библиотеки), я имею в виду, что TR1 был выпущен в 2005 году, и у нас до сих пор нет shared_ptr, bind и подобных в стандартной библиотеке.
    • -
    2
    smerlin

    С

    1. битовые поля - они плохо определены языком, и то, как они работают, зависит от компилятора и архитектуры.
    2. Часто трудно найти, где определенный символ определен в большой массе кода, особенно. если этот символ создается макросом. Что напоминает мне ...
    3. Препроцессор - довольно уродливый хакер, подверженный всевозможным злоупотреблениям.
    4. отсутствие целых чисел стандартного размера (в последнее время исправлено с помощью uint * _t, но вокруг появляется множество старого кода с пользовательскими определениями типов или #defines для DWORD, Word, BYTE и т. д.)
    5. Отсутствие чего-то похожего на cpan.org в Perl (хотелось бы ошибиться в этом)

    Правка: Думая о CPAN для C, я подумал ... что бы я назвал такой вещью, подумал о "ccan" и, погуглив, натолкнулся на это: http: //ccan.ozlabs .org /

    Похоже, что это все еще в зачаточном состоянии, хотя.

    2
    smcameron

    R (R-проект для статистики)

    1. Ужасная, ужасная поддержка строк
    2. Удивительно сложно для некоторых простых описательных задач, таких как кросс-табуляция
    3. Обработка большого набора данных осуществляется в памяти.
    2
    Gregg Lind

    VBA (потому что вы думали, что ваш язык плохой)

    1. Пробелы внутри строки строго соблюдаются.
    2. Операторы просто заканчиваются и требуют "_" для перехода к следующей строке, но не каждая строка может быть разбита.
    3. Нет ++, -, + =, - = заявления. Шутки в сторону?
    4. Массивы могут начинаться с любого индекса, а не только с 0.
    5. Некоторые типы (то есть значение с десятичной точкой с фиксированной точкой) должны быть подтипами Variant и не доступны как их собственный тип.
    6. ! = и <>.
    7. "=" используется как компаратор и присваиватель вместо разделения на "=" и "==".
    8. "Вариант Явный".
    9. Пользовательский интерфейс не обновлялся с 2000 года.
    10. Office2k7 не обновился до VB.NET
    11. Большинство объектных моделей бессмысленно и слишком многословно.
    2
    Andrew Scagnelli

    Python

    • Нет заявлений в lambdas. Grrrr
    • foo( a for b in c if d ) чувствует себя неправильно, меня удивляет каждый раз, когда мне это сходит с рук. Разве это не должно быть foo( (a for b in c if d) )?
    • Могу ли я иметь понимание dict?
    • операторы map и filter имеют особый синтаксис в списках, как насчет того, чтобы уменьшить? или сортировать?
    • Просто с помощью оператора yield функция волшебным образом превращается в генератор, и ее интерфейс полностью меняется. Кроме того, этот генератор не может выполнять какую-либо работу до первой next(). по крайней мере, не без использования функции, которая возвращает генератор.

    JavaScript

    • Нет краткого синтаксиса для создания библиотек модульного кода. Вы должны вызвать функцию, которая возвращает словарь открытых методов. И вы должны редактировать это (по крайней мере) в двух местах каждый раз, когда вы изменяете интерфейс вашего модуля.
    • Создание замыканий включает в себя возврат его из функции, которая возвращает функцию из функции ('sup dog) yo'. Беспорядок!
    • Синтаксис и поведение for each ( foo ) воспринимаются как запоздалая мысль.
    • Знание того, когда ваш код будет фактически запущен (и в каком порядке), скорее является мрачным искусством. Единственный способ сделать это правильно - поместить все (да, и это тоже) в один большой файл. и даже тогда вам все равно нужно ждать документа.
    • Я что-то пропустил? Нет ли тривиального способа получить сериализованные значения JSON, не создавая их вручную? (да, JQuery может сделать это, вроде).
    2
    SingleNegationElimination

    Clojure

    • Отсутствие встроенного синтаксиса для необязательных и ключевых параметров в определениях функций. Конечно, вы можете добавить его достаточно легко, но это означает, что авторы библиотек не используют его. Повсеместная деструкция еще не доказала, что является хорошей заменой
    • Недостаток комбинации методов (до/после/вокруг методов, найденных в Common LISP)
    • Слишком сильная зависимость от Java взаимодействия, например нет встроенного файла IO
    • Иногда я хочу статической типизации. Этот не чистая ненависть; Я обычно предпочитаю динамический, и попытки смешать эти два были в основном неудовлетворительными
    • Нет встроенного быстрого формата двоичной сериализации для встроенных структур данных, хотя я слышал, что люди работают над этим
    2
    Zak

    Что касается C #:

    1. Я ненавижу, что нет никакого ключевого слова, чтобы указать, какие исключения выбрасываются из метода, как в Java. Это гораздо лучший способ документировать исключения, чем использование XML-комментария.
    2. Я также хотел бы иметь намного лучший синтаксис для общих ограничений, таких как oring и anding ограничений.
    3. Почему метод не может возвращать более одного значения?
    4. Отсутствие поддержки аспектно-ориентированного программирования на языке.
    5. Почему нельзя аннотировать каждый метод доступа к свойству с помощью атрибута?
    6. Отсутствие встроенной поддержки регулярных выражений, как в Perl.
    2
    Ikaso

    C++ отсутствие хороших инструментов рефакторинга, отсутствие проверенных исключений

    Java отсутствие шаблонов, отсутствие ключевого слова const

    2
    quant_dev

    Java - нет поддержки композиции на уровне языка

    1
    Rostislav Matl

    C #

    1. Нет простого способа проверить, является ли тип числовым
    2. Это означает, что вы, вероятно, застряли, используя большую часть стека Microsoft, IIS и ​​MSSQL
    3. Вместо того чтобы быть конкретным инструментом для конкретной проблемы, C # пытается быть языком для каждой парадигмы.
    4. Недостаток сообщества. Конечно, начинают появляться платформы с открытым исходным кодом и библиотеки для C #. Те же, что были доступны Java разработчикам в течение многих лет.
    5. Трудно найти хорошую помощь. Интернет полон плохих примеров того, как решать проблемы с C #. Это восходит к проблеме № 3.
    1
    CountCet

    REBOL

    REBOL является среди моих любимых языков. Я не могу сказать, что у меня есть фаворит, хотя Хаскелл тоже занимает довольно высокое место.

    1. Его странный синтаксис отпугивает многих разработчиков, прежде чем они даже попробуют.

      используйте [URL правил электронной почты] [
       
      
      ; A small DSL that sends email to people about URLs.
      rules: [
          some [
              into [
                  set email email!
                  set url url!
                  (send/subject email url reform [ "Check Out" url ])
              ]
          ]
      ]
      
      ; Global context
      notify: func [ [catch] dsl [block!] ] [
          unless parse dsl rules [
              throw make error! "You screwed up somehow."
          ]
      ]
      
       
      ] 
       
       уведомить [[[email protected] http://www.google.com] [[email protected] http: // www .yahoo.com]]
    2. Рекурсивные диалекты очень легко проверить с помощью PARSE, но очень сложно оценить. (Стеки могут быть полезны здесь.)

    3. REBOL имеет очень слабую интеграцию со многими популярными технологиями, в частности с XML. Я подозреваю, что это отчасти высокомерие, потому что тип данных REBOL BLOCK! может делать почти все, что может делать XML. Однако в реальном мире есть XML.
    4. Нет Юникода.
    5. Благодаря AltMe, сообщество пользователей REBOL очень замкнуто. Я могу понять, почему они хотят использовать AltMe. Он написан на REBOL и демонстрирует свои сильные стороны. К сожалению, это также откладывает их на их собственный маленький остров.

    Будущая REBOL 3, мы надеемся, исправит многие из этих проблем, кроме последней.

    1
    Gregory Higley

    Я чувствую, что любимый язык невозможно выбрать. Динамическую типизацию и статическую типизацию нельзя сравнивать, поэтому я просто перечислю, какой из них я использую

    C++:

    • Синтаксис метапрограммирования шаблонов ужасен. Неявный ::value сделает его гораздо более кратким
    • ->. Почему компилятор не может понять, что я делаю ptr.thing и просто делаю -> для меня?
    • Я ненавижу пробелы. Таким образом, весь vector<vector<int>> должен быть vector<vector<int> >, чтобы я получил дрожь, и тогда я не могу сосредоточиться, когда вижу эту строку кода, и в итоге пытаюсь найти способ использовать int[][] или что-то еще
    • Макросы. Я лично люблю концепцию макросов. Но с C++, я, что система взломать
    • Я ненавижу ;

    Python:

    • Строки неизменяемы. Делает так, что я не могу просто сделать строку [4] = "b"
    • Списки неявно копируются по ссылке. Что просачивается в [[0] * ширина] * проблемы с высотой
    • Отсутствие хвостовой рекурсии (мне пришлось настроить IDLE, чтобы не выкидывать тысячи сообщений об ошибках всякий раз, когда я ошибочно набирал рекурсивную функцию)
    • Словари ключи не принимают списки/дикты
    • Отсутствие глубоких границ. Когда я делаю понимание списка, я не хочу, чтобы переменная в нем влияла на внешнюю область видимости.
    1
    Demur Rumed

    Python: Выбор части массива не дает того, что вы просили.

    [1] дает вам один элемент
    a [1: 2] дает вам один элемент, а не [a [1], a [2]]
    a [1: 3] дает 2 элемента

    Я ненавижу это, но возможно это только потому, что я главным образом работаю в Verilog.

    1
    Marty

    По мнению многих, Java работает медленно, но я согласен с определенной степенью использования.

    Ява драматична. У них есть много классов только для одной вещи, которую вы хотели сделать. Но вы знаете гибкость свойства XD.

    Поначалу Java сложная, но веселая как всегда.

    Когда вы пишете простой код для печати "Hello, World!" ПОЖАЛУЙСТА, НЕ ИСПОЛЬЗУЙТЕ Java! XD Я уверен, что я оправдан.

    Java - это смесь, поэтому не говорите, что это чисто OOP язык.

    Есть еще много, но я ограничен только пятью XD. Спасибо!

    1
    Richeve Bebedor

    С #

    Ненависть питомца номер один в C # должна быть:

    (1) События имеют сильные ссылки на всех слушателей, что предотвращает сбор мусора всего, что слушает событие. Если вы хотите увидеть проблемы, это вызвало просто поиск в сети всех людей, которые пытались решить проблему, создав своего рода "обработчик событий со слабой ссылкой".

    (2) Необходимость проверить, равно ли событие нулю, прежде чем вы вызовите его, похоже, что-то, что должно обрабатываться языком.

    (3) Сериализатор XML не имеет возможности читать/писать комментарии в файле XML. Неплохо в среде, где XML-файлы модифицируются как вручную, так и с помощью инструмента, написанного на C #. Можно обойти это, просто используя необработанный XmlDocument, но было бы лучше иметь возможность абстрагировать это от класса.

    (4) Процесс сборки не позволяет вам напрямую обращаться к таким вещам, как файлы xsd, вместо этого вам нужен промежуточный шаг, где вы создаете частичный класс C #. Это также вызывает проблемы с файлами XAML, когда вам иногда нужно дважды перестраивать, чтобы изменения проходили правильно.

    (5) Нет поддержки встроенных функций ЦП, таких как MMX и SSE 1,2,3,4, и поэтому эти ценные функции ЦП не используются при запуске приложений на C #.

    Другие, которые не попали в топ-5:

    (6) Не могу пометить поля как свойства, все свойства должны быть явно реализованы с самого начала:

    Например. в настоящее время имеет:

    public class MyClass {
        private int someInt;
    
        public int SomeInt {
            get {
                    return someInt;
            }
            set {
                    someInt = value;
            }
        }
    }
    

    Хотел бы

    public class MyClass {
        [IsProperty(public, get, set)]
        private int someInt;
    }
    

    (7) Нет поддержки для нескольких возвращаемых значений, например:

    public int, string, double MyFunction()
    {
        ....
        return x,y,z;
    }
    
    
    public void TestMyFunction()
    {
        int x, string y, double z = MyFunction();
    }
    

    (8) Нет поддержки ковариантных типов возврата

    У меня есть некоторые претензии по поводу реализации обобщений, но я остановлюсь там. Я думаю, что C # является отличным языком для выполнения всех операций с графическим интерфейсом, сетями и настройками, и является моим языком номер один для ускорения и ускорения работы таким образом, который может быть поддержан в долгосрочной перспективе.

    1
    John Stewien

    C++

    1. Создание простого фрагмента кода занимает так много времени.
    2. для (std :: vector :: const_iterator iter = [...]
    3. vector.remove () не удаляет.
    4. vector.Push_front () не существует.
    5. заголовочные файлы
    6. Нет лямбда
    7. Нет автоматического пустого виртуального деструктора, если есть хотя бы одна виртуальная функция.
    1
    user35978

    MEL (язык выражения майя):

    • Массивы с одиночными измерениями: Вынуждает меня вручную синхронизировать два или более списков или использовать строки с разделителями для имитации более сложных структур данных. Естественно, они тоже неизменны.
    • Однопоточный и медленный: Вызывает зависание всего приложения Maya во время выполнения задачи. Бонусные баллы за то, что вы не можете убить длинные операции, вместо этого нужно закрыть и снова открыть Maya.
    • Пути получения сценариев не являются рекурсивными: Это означает, что каждый каталог, в котором вы хотите хранить сценарии, должен быть добавлен к пути сценария.
    • Нет пространств имен: Принудительное непоследовательное использование соглашений об именах, чтобы глобальные процедуры не сталкивались.
    • Модальные команды: Каждая команда является модальной, то есть все операции Create, Modify и Query обрабатываются путем установки флагов. Это также вынудило разработчиков заставить большинство команд возвращать массивы
    • Несоответствующий стиль команды: Большинство команд массивов фактически возвращают массивы, но команда Tokenize должна принимать массив в качестве ссылки, которую он затем заполняет, а не выплевывать массив. Это среди других несоответствий.

    По этим и нескольким другим причинам AutoDesk принял Python в качестве вторичного языка сценариев, что вызывает несколько других раздражающих факторов:

    • Поддерживаются не все команды MEL: Большинство из них поддерживаются, но время от времени вам приходится использовать функцию mel () для выполнения произвольного кода. Хуже всего то, что с этим надо убегать.
    • Унаследованный стиль модальной команды: Должен использовать тот же create = True, query = True, edit = True.
    1
    Soviut

    Python:

    • скорость
    • статический анализ (отсутствие)
    • анонимные функции ограничены одним выражением
    1
    orip

    Мой 5 для Delphi:

    1. Процедуры и функции не обязательно отличаются от переменных, если они не параметризованы (например, у меня может быть выражение, такое как x: = GetPositionOnScreen; вместо x: = GetPositionOnScreen ();)
    2. Try/Наконец и Try/Except должны быть вложены (указано однажды, но это все еще один из моих).
    3. Нечувствительный к регистру.
    4. Может иметь несколько объектов (функций, глобальных переменных, локальных переменных) с одинаковыми именами, и Delphi с радостью попытается выяснить, что вы имеете в виду. имена должны быть уникальными.
    5. Странно, если условие правил. одиночная условная проверка не требует () вокруг нее, но если я делаю несколько проверок, мне нужно () вокруг каждой, а иногда несколько вложенных наборов для больших проверок.
    6. Нет унаследованных включает. Если мне нужно ссылаться на функциональность модуля Windows в базовой и унаследованной форме, я должен включить Windows в обе.
    1
    Tom A

    Quenya

    • Сообщество слишком мало. Практически невозможно запустить хорошую программу языкового погружения, когда рядом нет другого говорящего.
    • Неправильные глаголы. Да, я знаю, что английский и испанский тоже упоминали их, но Квения была изобретена. Почему там все еще должны быть неправильные глаголы?
    • Нет поддержки Unicode. У меня должно быть три разных шрифта Tengwar на моем компьютере, прежде чем я смогу прочитать большинство сообщений, и некоторые из них имеют плохой кернинг. Это не было бы большой проблемой, учитывая существование романизированной транскрипции, но Тенгвар так прекрасен, что вы не хотите его использовать.
    .

    1
    user218368

    JavaScript

    Из спецификации ECMAScript 5:

    • 7.6.1.2 Будущие зарезервированные слова:

      класс, перечисление, расширяет, супер, const, экспорт, импорт

      В строгом режиме: реализует, let, private, public, interface, package, protected, static, yield

    • 11.9.4 Оператор строгого равенства (===) и 11.9.1 TheEqualsOperator (==)
    • 11.9.6 Алгоритм сравнения строгого равенства (NaN === NaN ложно)
    • 8.5 Тип числа - никаких целых чисел, все поплавки.
    • 4.2.1 Объекты - прототип наследования

    Хорошо, мне нравится последний, но это 7 видов путаницы

    1
    thejefflarson

    C #

    1) Отсутствие практической способности писать дженерики для типов значений. Например, любой идиот (ну, в общем, большинство идиотов) может написать процедуру, которая вычисляет стандартное отклонение списка int, float, double и т.д. В C++, он прост в написании, легко читается и работает как быстрый неуниверсальный код , Я думаю, что если вы можете написать что-то на C #, что близко к ударам любого из этих 3, не смешно с остальными 2, вы действительно отличный программист.

    2) Ковариация и контрастная дисперсия, хотя это добавляется к 4.

    3) Чрезвычайно плохая документация по LINQ (хорошо, на самом деле не часть языка).

    4) Попытка использовать foreach/итераторы, когда я хочу каждый раз делать одну и ту же вещь, за исключением чего-то немного отличающегося в прошлый раз (например, объединить кучу строк с запятыми между ними и Word и между двумя последними). Если я напишу его с помощью IEnumerable, это будет трудно писать и читать, а с помощью for (int i = 0 i <...) это не намного лучше и менее эффективно.

    5) Я знаю, что буду получать жалобы по этому поводу, но отсутствие проверенных исключений. Это не должно быть реализовано так, как это делается в Java (разработчики фреймворка действительно делают очень хорошие замечания о том, почему они этого не сделали), но я был бы рад, если компилятор предупредил пользователей, которые не нравится, отмеченные исключения могут отключаться.

    1
    Brad

    Надо полагать, у нас есть язык. Мы?

    1
    Niklas Rosencrantz

    Python

    Те, которые я просто не понимаю ...

    • math.ceil() и math.floor() возвращают значения с плавающей точкой, а не целые числа (возможно, чтобы избежать переполнения целых чисел в базовой функции C - но почему бы не привести к длинному Python?)
    • len() - это функция, а не метод
    • reload() очень ограничен, не перезагружает модуль 9 раз из 10, только перезагружает импортированную метку, если он является модулем - т.е. не может выполнять from bar import foo; reload(foo), если foo сам не является модулем
    • Изменяемые аргументы по умолчанию имеют одну ссылку (почему не новый экземпляр при каждом вызове функции ?!)
    • Все эти подчеркнутые переменные - если они настолько закрытые, то почему мы так много видим в коде встроенных? Получите пространство имен!
    • Строки не изменяемы - возможно, для этого есть веская причина, но я сталкивался со многими ситуациями, когда мне хотелось бы настроить одного конкретного персонажа ...

    Те, которые имеют смысл на основе реализации, но раздражают ...

    • array.sort() не возвращает массив (я полагаю, это происходит на месте)
    • Постижения списков/генераторов не определяют новую область (это просто синтаксический сахар для цикла for, верно?)

    и пара, которые исправлены в Python 3

    • Целочисленное деление по умолчанию
    • global может ссылаться только на пространство имен верхнего уровня
    1
    Brendan

    Python:

    1. Нет стандартного инструментария GUI (сообщество обходит все вокруг, но, кажется, никогда не останавливается ни на чем).

    2. Эволюция инструментов и методов для распространения и установки Python приложений и библиотек была, в общем-то, непростой. (Хотя в последнее время это, кажется, приближается к исправлению.)

    3. CPython по-прежнему медленен в работе интерпретаторов (хотя PyPy выглядит довольно хорошо в наши дни, если он становится "стандартным" Python, эта проблема исчезнет).

    4. Вы не можете создавать подклассы встроенных классов (например, list и dict), не переопределяя множество методов, даже если все, что вы хотите сделать, - это просто подключить событие (например, подключить элемент, добавляемый или удаляемый). из списка вам нужно переопределить delitem, добавить, расширить, вставить, удалить и удалить - нет ни одного подклассового уведомления о событии "изменение", ни каких-либо "защищенных" методов, которые выделяют общий используемый код всеми вышеперечисленными методами).

    5. Вплоть до того, как был изобретен virtualenv, хранить на разных машинах отдельные среды Python для разных целей было настоящей проблемой.

    1
    user350432

    C #

    Я очень доволен C #, но эти два действительно раздражают меня:

    • Инициализация на основе конструктора для неизменяемых классов менее удобна, менее интуитивна (когда вы читаете код, вы не понимаете, что вы назначаете для чего-либо), имеет меньше IDE поддержки, чем встроенная инициализация объекта. Это заставляет вас склоняться к изменчивым классам неизбежно. Я знаю, что это упоминалось ранее, но у меня строго проблемы с синтаксисом инициализации для неизменяемых классов.

    • switch слишком многословен. Всякий раз, когда я вижу ситуацию, когда переключение будет правильным, я действительно склонен использовать if..else if.. только потому, что он более лаконичен (~ 30% меньше печатания). Я думаю, что для переключения не должно быть никаких проблем, следует подразумевать break, а case должен разрешать разделенный запятыми список значений.

    1
    Sedat Kapanoglu

    Scala:

    • странности стандартной библиотеки: она не всегда показывает лучшие практики и недооценена
    • жестко закодированные классы FunctionX, TupleX
    • отсутствие свойств: геттеры и сеттеры разделены, что нарушает DRY и делает такие вещи, как FRP, практически невозможными
    • необходимость = _ для инициализации свойств
    1
    thSoft

    Рубин:

    • Значительные пробелы. Для интерпретатора конец строки = конец оператора, если только он не выглядит так, как будто оператор должен продолжаться (или вы явно избегаете перехода на новую строку).
    • Медленный
    • Электронная документация не так хороша, как у Python (в обороне у Python отлично)
    • Я упоминал медленный?
    1
    Joshua Swink

    Джава:

    1. Очень противоречиво.
    2. Графические API иногда неудобны в использовании
    3. Исключения NullPointerException не сообщают вам, что такое NULL
    4. Программы, которые я пишу, иногда не работают на другой JVM, что вызывает огромную боль и противоречит утверждению Java "Пиши один раз, беги куда угодно".
    5. Качели не так хороши, как должно быть.
    1
    TomLisankie

    VB .NET, но только потому, что VB6 отравил целое поколение программистов

    Я работаю в магазине VB .NET, который раньше был магазином VB6, и каждый работающий здесь, который раньше был разработчиком VB6, упрямо отказывается что-либо узнавать о .NET. Они кодируют, как будто это все еще VB6, а их приложения сосут так же, как и приложения VB6. Мой босс активно противодействует любому использованию LINQ, потому что она боится, что другим будет слишком трудно это понять, и это правда, потому что никто не хочет этого понимать.

    Я думаю, что нам всем было бы лучше, если бы MS просто перешла с C #, что убивает меня, потому что я думаю, что фигурные скобки намного уступают многословным заключительным заявлениям VB.

    1
    Bremer

    Рубин.

    1. Странные правила области видимости - переменные, константы и методы ведут себя по-разному. Правила меняются также в зависимости от того, какое ключевое слово вы использовали для создания замыкания. Или о том, находитесь ли вы в классе, собственном классе, объекте, модуле или самом модуле. Затем есть instance_eval, который меняет правила на другой набор правил. И они снова меняются, когда модуль "включается" или "расширяется", что само по себе делает разные вещи в своей области. И некоторые наборы правил не могут быть эмулированы метапрограммированием, поэтому вы должны использовать eval. Если вы не находитесь в Ruby 1.9, где все по-другому.
    2. Пространство имен в основном бесполезно. Если у вас есть Foo :: File, то файл stdlib, вероятно, не работает для всех Foo.
    3. требование заявления нарушено. Если два файла требуют друг друга, поведение этих файлов может резко измениться в зависимости от того, какой файл загружен первым из другого места.
    4. библиотеки резко и внезапно меняют API-интерфейсы, поэтому вам необходимо указывать конкретные номера ревизий всех ваших зависимостей. Для каждого Ruby приложения в вашей системе.
    5. Система пакетов rubygems переопределяет "требуется", а не помещает файлы в путь поиска - потому что зачем использовать систему, если вы можете заменить ее?
    1
    jes5199

    Python 3

    • для отступов предусмотрены как табуляция, так и пробелы
      И вы думаете, что люди учатся на прошлом (Makefile). Просто выбирайте пробелы и запрещайте вкладки. YAML понял все правильно.
    • отсутствие популярных сторонних библиотек
      Стандартная библиотека великолепна, но многое из того, что делает Python 2 таким мощным, лежит в сторонней сфере. Python 2 получил это право: -).
    • IEEE плавает
      Плавающие точки в языках программирования сбивают с толку, потому что они отличаются от того, как мы их используем в математике. Вместо этого числовые операции следует рассматривать как выражения, которые при необходимости преобразуются в десятичный формат (т. Е. Вывод на экран). Клен и Математика сделали это правильно, я думаю.
    • набор символов для идентификаторов слишком ограничен
      list.empty? лучше, чем list.is_empty или даже len(list) != 0. Точно так же, process.kill! будет лучше, чем process.kill. Ruby и LISP получили это право.
    • при вызове функции вы должны всегда писать круглые скобки
      Было бы хорошо, если бы мы могли опустить их в однозначных случаях. Как это снова? dict.items или dict.items()? Руби тоже правильно поняла.
    1
    Tomas Sedovic

    Ruby

    1. Нет типа вывода
    2. Методы/функции не являются первоклассными объектами
    3. Область применения переменных не является лексической, хотя область действия переменных блоков является лексической
    4. def внутри Def
    5. разница между супер и супер ()
    1
    jmuk

    переписал это, подумав ...

    Пять вещей, которые я ненавижу в PHP, хотя мне это нравится (без определенного порядка):

    • Непоследовательное именование и порядок параметров во встроенных функциях.
    • Объектно-ориентированный подход к массивам благодаря SPL, но, к сожалению, не к строкам (пока).
    • Нет реального параллелизма в самом PHP, только через многопроцессорную обработку веб-серверов
    • Нет асинхронных вызовов, как в JavaScript
    • Кэширование кода операции только через расширения. Не очень плохо, но просто раздражает.

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

    1. Дело в том, что многие люди, которые используют PHP, ничего не знают о программировании и хороших практиках в целом и создают действительно грязный код. У JavaScript та же проблема.

    2. Огромное количество учебников/книг, которые учат действительно плохим практикам и стилю. Это может быть основной причиной № 3.

    3. Плохая репутация сложилась в основном из-за № 3 и № 4.

    1
    selfawaresoup

    C #

    • Общие параметры инвариантны В C # 4.0 введены ковариация и контравариантность для универсальных типов.
    • Переопределяемые члены класса должны быть явно помечены как виртуальные

    Java

    • Отсутствуют числовые типы данных без знака
    • Примитивные типы данных не являются объектами
    1
    Enrico Campidoglio

    C мой любимый, но это тоже ужасно.

    • У него худший препроцессор за всю историю. Почему они не использовали что-то вроде m4?
    • Весь заголовок и модель исходного файла повреждены. Паскаль понял это правильно с единицами.
    • Это требует диапазонов регистра в операторе switch.
    • Союзы и отливки из void * нарушают систему типов. Это делает сборщики мусора невозможными.
    • Нет вложенных функций. GNU C имеет это, но оно должно быть стандартным.
    • Нет проверки границ для выделенной памяти. Существуют инструменты, которые обнаруживают это, но они не обнаруживают ошибок, когда часть кода неправильно рассчитывает адрес и записывает в выделенную область, которая вообще не связана. Я ненавижу всю арифметику указателя.
    • Нет проверки границ для массивов.
    • Слишком много вопросов относительно мобильности. Даже wchar_t отличается на разных платформах.
    1
    ahmet demir

    Я могу добавить еще один для Python:

    Дан список l = [l1, l2, ..., ln], затем repr(l) = [repr(l1), repr(l2), ..., repr(ln)], но str(l) != [str(l1), str(l2), ..., str(ln)] (str(l) = repr(l)). Это было решено, потому что могли быть непонятными записями в списке, такими как l = ["foo], [bar,", "],["] и str(l) возвращали "[foo], [bar, ], []", что "могло бы сбить с толку пользователей". Однако это делает невозможным использование str для простого вывода данных, поскольку list убивает "просто выводить данные в читаемом формате". Augh!

    1
    Tetha

    Objective-C 2.0

    Придерживайтесь строго языка и среды выполнения, а не библиотек и не в каком-то конкретном порядке:

    1. Недостаток cVars.
    2. Нет модулей. Я не очень недоволен отсутствием пространств имен, но было бы неплохо иметь модули.
    3. Синтаксис свойств на основе Ivar требует объявления с использованием имени переменной в 3 местах. Это довольно отвратительно.
    4. С наследием. Все, что можно ненавидеть в языке C, кроме OO и ​​GC, присутствует.
    5. Объекты не могут жить в стеке. Не проблема в Obj-C, а в том, что он делает с практиками программирования на других языках. Например, мне странно, когда я получаю возвращаемое значение в стеке в C++. Если я на самом деле не смотрю документацию библиотеки, когда пишу код, я предполагаю, что каждая функция возвращает указатель, что часто приводит к некоторой значительной очистке позже.
    0
    icodestuff
    • Свойство длины легко спутать с функцией length (); используйте вместо этого size ()
    • Синтаксис для интерполяции переменной в строках селектора ('"+ $. Month +"') воняет
    • $ (event.currentTarget) не всегда работает для пузырьков и захвата
    • синтаксис атрибута работает ("[class = 'foot']") в местах, где синтаксис селектора (".foot") ничего не возвращает
    • Содержит селектор ([class ~ = done]), иногда не работает там, где работает JavaScript (this.className.search ("done")> 0)
    0
    user350176

    Python:

    1) Это язык сценариев, а не полностью скомпилированный (я предпочел бы иметь возможность компилировать двоичные файлы - меня не волнует байт-код). Это очень раздражает, если мне приходится использовать очень много библиотек (т.е. каждый, кто использует мою программу, должен установить все библиотеки, и это в основном означает, что ни один нормальный человек не сможет или не будет терпеливо правильно его настроить - если только Я делаю кучу работы, которая должна быть ненужной). Я знаю способы создания двоичных файлов, но они не работают всегда , и я предполагаю, что они все равно связывают интерпретатор в двоичных файлах (и я не не хочу этого). Теперь, если бы я мог получить компилятор байт-кода, который включал бы копии всех импортированных мной файлов (и только те), которые были бы помещены в папку моей программы, это могло бы стать подходящим компромиссом (тогда никому не пришлось бы загружать дополнительные библиотеки и например). Также было бы хорошо, если бы скомпилированные файлы python можно было сжать в один файл, один из которых был указан как файл для запуска программы до того, как это будет сделано.

    2) Иногда кажется, что он немного глючит; было несколько раз, когда код, который должен был работать, просто не работал (не было ошибок программиста), особенно код, относящийся к таким, как "из moduleX import *", и другие проблемы, связанные с импортом, а также некоторые проблемы, относящиеся к глобальные и локальные переменные.

    3) Максимальная глубина рекурсии может быть выше. Был, по крайней мере, один раз, когда я чувствовал, что мне нужно, чтобы он пошел выше.

    4) Нет оператора switch (не говоря уже о том, что учитывает числа, строки и диапазоны)

    5) Новые версии Python, похоже, покончили с множеством полезных строковых операций, и у них нет простой документации о том, как делать то же самое без них.

    6) Принудительная автоматическая сборка мусора (я бы хотел иметь возможность сделать это вручную, хотя не обязательно делать это принудительно).

    7) Нет готового класса Timer без использования графического интерфейса пользователя (ну, может быть, один, но после всех поисков, которые я сделал, найти его, конечно, не удобно! Я действительно что-то нашел, но это не так работать вообще, когда я пытался.) Под таймером я подразумеваю сортировку, которая будет выполнять указанную функцию каждые x секунд, с возможностью выключать ее при желании и т. д.

    8) Люди в сообществе, которые приводят примеры, редко рассказывают, какие модули они импортировали и как они их импортировали.

    9) Нет большой поддержки интеграции с Lua.

    10) Кажется, что нет способа добавить дополнительную функцию к конкретному экземпляру класса (а не ко всему классу в целом), если только вы не добавите динамическую переменную объекта в этот класс с объектом, имеющим необходимую функцию (но все же, вы должны сделать еще один класс только для этого).

    0
    Cordilow

    Python:

    • отсутствие разделителя, сигнализирующего об окончании блоков, приводит к двусмысленности, так что автоматическое отступание не будет работать с плохо отформатированным кодом.
    • нет макросов (декораторы не в счет)
    • нет автоматической выборки из библиотеки, как у клики Хаскелла или CPAN в Perl
    • не может объявлять переменные const (да, можно поменять свою роль, но ...)
    • метапрограммирование не работает
    • почти забыл Глобальный замок интерпретатора
    0
    drhodes

    Отсутствие препроцессора в C #.

    Я знаю, что они пропустили это, потому что некоторые люди могут злоупотреблять этим, но я думаю, что они выбросили ребенка с водой из ванны. Генерация кода считается хорошей вещью, и в C++ препроцессор был моим генератором кода первой линии.

    0
    Mike Dunlavey

    C #

    5. Оператор с нулевым слиянием

    ?? Оператор позволяет написать:

    x = y ?? z;
    

    вместо:

    x = (y == null) ? y : z;
    

    Мне нравится этот оператор, но я хочу еще один:

    x = y ??? y.foo() : z.foo();
    

    вместо

    x = (y == null) ? y.foo() : z.foo();
    

    Я все время использую подобные вещи, и нахожу раздражающим ввод части == null.


    4. Равные должны иметь лучшую поддержку

    Мне приходится начинать каждый метод Equals(object obj) с: MyClass other = obj as MyClass; if (other == null) возвращает false;

    Вам нужно только написать:

    public override bool Equals(MyClass other) {...}
    

    И язык должен позаботиться о предоставлении метода Equals(object obj).
    ПРИМЕЧАНИЕ: другое должно быть гарантировано не равным нулю.


    . Невозможно использовать тернарный оператор разных типов

    Это не компилируется, и я думаю, что должно!

    string foo = "hello";
    int bar = 4;
    object baz = foo == null ? foo : bar;
    

    2. Отсутствие частного пространства имен

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


    1. Нет множественного наследования

    Я действительно использую наследование реализации (класса) только для реализаций интерфейса по умолчанию, но я бы хотел сделать именно так много раз.

    0
    tster

    VB.NET

    1) Если не х, то это "foo" (вместо <> "foo")
    2) Короткое замыкание "OrElse" и "AndAlso" (вместо просто "Or" и "And", которые действуют по-разному)
    3) Ничего (вместо нуля)

    0
    Techgration

    Я только что обнаружил, что не могу использовать Enum как ограничение типа при создании универсального метода в c #.

    У Microsoft есть достаточно хорошее объяснение, почему, но все же. Я псих

    public static T MyFunc<T>(string arg) where T:Enum //wont work :(
    
    0
    Midhat

    У меня есть только один, но я считаю, что стоит поделиться.

    CSharp/.NET

    У нас есть свойство Length для получения количества элементов в массиве и свойство Count для получения количества элементов в коллекции. Это выглядит более странно, если учесть тот факт, что CLR автоматически добавляет IList, ICollection, IEnumerable к одномерным массивам, начинающимся с нуля, за сценой.

    Я полагаю, что команда CLR и команда BCL были трудные времена, обсуждая эту тему;)

    0
    Andrey Taptunov

    С

    • Обработка строк
    • Управление памятью (принятие решения о том, кто должен выделять, а кто должен освобождать)
    • Нет пространства имен (самое большое)
    • Нет списков/массивов и других базовых DS в стандартной библиотеке


    JavaScript

    • Использование переменной без var автоматически делает ее глобальной
    • Точки с запятой не обязательны
    • Операторы сравнения "==" и "===" и недоразумения по поводу их использования
    • Нет надлежащей поддержки для работы с двоичными данными
    • Опять же .. Нет пространства имен
    • Переменные не имеют блочной области видимости. (Довольно раздражает, приходя из мира C)
    0
    Manish

    Python

    • Нет пространств имен.
    • Псевдо-приватные атрибуты/искажение имени (в основном с getattr).
    • Обработка пути к файлу распространяется на несколько модулей. Объединение вызовов os.path некрасиво, трудно читать и в большинстве случаев нарушает DRY. Обычные операции с filepath по-прежнему не имеют вспомогательных функций, таких как получение списка файлов в директории. Модуль path - type, чтобы исправить это, был отклонен.

    ([f for f in os.listdir('/file/path') if os.path.isfile(os.path.join('/file/path', f))])

    • Документация Python (я очень, очень, очень благодарен, что документация вообще есть, и что она так хорошо отформатирована, но я ненавижу пробираться через 5000 строк примеров быстрого запуска, чтобы найти документацию по отдельным функциям для конкретных модулей ( Смотрю на тебя, optparse и logging)). Встроенные типы задокументированы по частям почти в 10 разных местах.
    0
    user297250

    HyperTalk:

    • Умер давным-давно
    • Нет простого назначения (вы не можете просто сказать a := 3, вы должны сказать put 3 into a
    • Нет вложенных функций
    • Нет реальных структур данных, только строки. Чтобы составить "списки", вы разделяете элементы с помощью itemDelimiter и экранируете их вручную. Вы также можете получить строки и слова, такие как get Word 2 of line 5 of txt

    Кроме того, я думаю, что одной из самых классных функций, уникальных для HyperTalk, является специальная переменная it:

    ask "How many years old are you?"
    answer "You are " & it*12 & " months old."
    
    0
    Joey Adams

    JavaFX

    • Вывод типа иногда ведет себя не так, как вы ожидаете, поэтому вам часто нужно явно объявить тип.
    • def ведет себя как const в C, а не final в Java
    • вы можете вставить значение в последовательность, открыв index> = seq.length, которое фактически должно вызвать ошибку компилятора (согласно ссылке).
    • если вы присваиваете String значение null, по умолчанию используется значение "". Если вы назначите null для Integer, выдается ошибка компилятора (в отличие от того, что говорится в ссылке).
    • обрабатывает CheckedExceptions так же, как RuntimeExceptions
    0
    helpermethod

    Луа

    • Если вы выполните foo.bar (1,2), то внутри метода bar значение self будет равно nil. Вы должны помнить вместо этого сделать foo: bar (1,2). Я бы предпочел, чтобы это переключалось ("self" должно быть определено по умолчанию, если вы не используете оператор ":" или не вызываете функцию, которая не является методом).
    • Переменные являются глобальными по умолчанию. Я предпочел бы отказаться от "локального" ключевого слова и вместо него использовать "глобальное".
    • Необъявленным переменным присваивается ноль. Я бы предпочел получить сообщение об ошибке. Вы можете обойти это, манипулируя метатабельным глобального env, но я бы предпочел, чтобы он был реализован по умолчанию и был в состоянии деактивировать его.
    • Несколько возвращаемых значений параметров не обрабатываются очень хорошо. Допустим, у вас есть функция foo (), которая возвращает 1,2,3 (три значения), а bar () возвращает 4,5 (два значения). Если вы выполните print (foo (), bar ()), вы получите "1,4,5" ... только "последний" кортеж расширяется при вызовах.
    • Оператор # (длина таблицы) работает только в таблицах, индексированных непрерывными целыми числами. Если ваша таблица не такая, и вы хотите знать, сколько у нее элементов, вам нужно либо проанализировать ее с помощью цикла, либо обновить счетчик каждый раз, когда вы вставляете/удаляете из него элемент.
    0
    kikito

    Джава:

    • Никакого процедурного кодирования, оно компилируется в процедурный код, поэтому позвольте мне использовать его!
    • Нет множественного наследования, пытаясь сделать то же самое с 15 000 интерфейсов отстой.
    • Дата урока, мне нужно сказать больше.
    • То, что я не могу использовать полиморфизм в полной мере. Java не будет переопределять другие типы параметров для запуска.
    • Я не могу вспомнить пятую причину, если я вернусь и отредактирую этот пост.
    0
    WolfmanDragon

    C #

    • Невозможно создать ссылку (var & t = struct)
    • Нет деструкторов локальной области видимости (IDispose подходит близко, но это не то же самое)
    • ToString, мне почти не нравится, что он есть у каждого объекта, но оказывается, что я не люблю все, используя его, как string.format. У меня скорее есть вещи, которые принимают определенный тип (например, целые числа, числа с плавающей запятой, текст, только символы). Поэтому вместо передачи какого-либо объекта мне нужно передать что-то с неявным типом или интерфейсом. Я закончил писать что-то вроде этого, чтобы безопасно избежать текста для HTML, который работал отлично.
    • Невозможно использовать виртуальный Typecast (бла) obj; не работает, если obj не наследует/имеет интерфейс бла. Простой обходной путь - снабдить интерфейс функцией преобразования.
    • Не имеет местного творения. Вместо написания var o = new Item (); Я хотел бы написать (что-то вроде) Item o() (с автоматическим удалением, если он есть).
    0
    user34537

    Python:

    1) Синтаксис продолжения строки: "... \" работает, а "... \" - нет, и этот завершающий пробел, как правило, невидим, без необычной eol-маркировки редактором.
    2) голый "рейз" невидим в трассировке стека, так как трассировка стека выглядит как предыдущее исключение.
    3) медленный
    4) плохая интеграция в веб-серверы (mod_python: dead, mod_wsgi: ограниченная область действия). Это усложняется на 3], требуя демонизации или некоторого рода сохранения памяти, чтобы работать хорошо.
    5) чрезмерно терпимо относится к смешанным символам табуляции и пробелам, позволяя изменениям в потоке управления иногда оставаться скрытыми. (возможно исправлено в последних версиях)

    0
    Rdbhost

    Луа:

    • встроенная система ошибок абсолютно ужасна

      Вы можете реализовать систему try-catch, изменив интерпретатор Lua; но он не совместим с ошибками, которые выдают встроенные функции.

    • тот факт, что они имеют __newindex вместо __setindex в качестве установщика

      ... и __newindex срабатывает только тогда, когда ключ еще не существует. Если это так, метаметод не вызывается вообще.

    • Нет хорошей системы сравнения типов.

      Есть функция type (), но она обрабатывает только основные типы (все таблицы являются таблицами). Это действительно должен иметь метаметод для сравнения типов. Я реализовал это раньше с помощью оператора 'is' и метаметода __type, и он работает очень хорошо.

    • Это сука для определения новых ключевых слов.

      Вы можете сделать это, но код внутри Lua недостаточно хорошо документирован, так что это своего рода метод проб и ошибок, чтобы узнать, как получить желаемый результат. Это серьезная проблема, когда вы хотите реализовать вещи, которые я упомянул выше (хотя не так много __setindex, это простая модификация).

    • Я не могу использовать его в веб-браузере.

      Да, на самом деле это не проблема с самим языком, но, черт возьми, я бы хотел использовать Lua вместо Javascript ... :)

    0
    June Rhodes

    Объект Паскаль:

    • В редактируемом файле происходит много скачков назад и вперед, так как интерфейс и реализация разделены на две части, но все еще находятся в одном и том же файле.
    • Динамическая индексация массивов, строки начинаются с 1, вы указываете начальный индекс при объявлении фиксированных массивов, а динамически распределяемые массивы всегда начинаются с 0.
    • Классы и объекты (не говоря уже об интерфейсах) закреплены поверх языка и, помимо прочего, не могут быть размещены в стеке, как записи.
    • При вызове функций без параметров () являются необязательными, что приводит к большим трудностям, когда вы работаете с указателями на функции или пытаетесь сослаться на результат функции, используя имя функции.
    • Списки параметров не могут обрабатывать фиксированные типы массивов или типы указателей на функции без определения внешних типов.

    Это всего лишь язык, извините за стандартную библиотеку и нестабильные IDE заслуживают своих собственных списков.

    0
    user350677