В последнее время на Stack Overflow была куча Perl-ненависти, поэтому я решил перенести вопрос « Пять вещей, которые ты ненавидишь за свой любимый язык » в Stack Overflow. Возьми свой любимый язык и скажи мне пять вещей, которые ты ненавидишь в этом. Это могут быть вещи, которые вас просто раздражают, допущенные недостатки дизайна, признанные проблемы с производительностью или любая другая категория. Вы просто должны ненавидеть это, и это должен быть ваш любимый язык.
Не сравнивайте его с другим языком и не говорите о языках, которые вы уже ненавидите. Не говорите о вещах, которые вам нравятся на вашем любимом языке. Я просто хочу услышать то, что вы ненавидите, но терпите, чтобы вы могли использовать все остальное, и я хочу услышать о том языке, который вы хотели, чтобы другие люди использовали.
Я спрашиваю об этом всякий раз, когда кто-то пытается навязать мне свой любимый язык, а иногда и в качестве вопроса для интервью. Если кто-то не может найти пять вещей, которые можно ненавидеть в своем любимом инструменте, он не знает его достаточно хорошо, чтобы либо защищать его, либо тратить большие деньги, используя его. Он не использовал это в достаточно различных ситуациях, чтобы полностью исследовать это. Он защищает это как культуру или религию, что означает, что если я не выберу его любимую технологию, я ошибаюсь.
Мне все равно, какой язык вы используете. Не хотите использовать определенный язык? Тогда не надо. Вы проходите тщательную проверку, чтобы сделать осознанный выбор, и все еще не используете его? Хорошо. Иногда правильный ответ звучит так: «У вас сильная команда программистов с хорошими практиками и большим опытом работы в Bar. Переход на Foo будет глупым».
Это хороший вопрос и для обзоров кода. Люди, которые действительно знают кодовую базу, будут иметь всевозможные предложения для этого, и те, кто не знает это так хорошо, имеют неконкретные жалобы. Я спрашиваю: «Если бы вы могли начать этот проект заново, что бы вы сделали по-другому?» В этой фэнтезийной стране пользователи и программисты могут жаловаться на все, что им не нравится. «Мне нужен лучший интерфейс», «Я хочу отделить модель от представления», «Я бы использовал этот модуль вместо этого», «Я бы переименовал этот набор методов», или что бы они ни делали не нравится о текущей ситуации. Вот как я понимаю, что конкретный разработчик знает о кодовой базе. Это также подсказка о том, сколько программиста
Ненависть - не единственное измерение того, как много людей знают, но я нахожу это довольно хорошим. То, что они ненавидят, также подсказывает мне, насколько хорошо они думают об этом предмете.
источник
Ответы:
Пять вещей, которые я ненавижу в Java:
Я знаю, я должен проверить Скала.
источник
Вау, я удивлен, что SQL еще не дошел до этого. Думаю, это означает, что никто не любит это :)
... и несколько бонусов, чтобы ненавидеть это, без дополнительной оплаты
источник
JavaScript :
Все самые крутые вещи безумно сложны, но тогда вся крутость также обернута таким небольшим количеством кода, что вы чувствуете себя глупо, пытаясь следовать ему
'+' - абсурдный выбор оператора для конкатенации в слабо типизированном языке. Они пытались отпугнуть новичков?
Это минное поле совместимости с разными браузерами (неважно, включено оно или нет)
Как правило, это ненадежно - связано с разборками, такими как блокировка кнопки «назад», всплывающие окна, которые никогда не умирают, и т. Д.
Отладка практически невозможна, потому что есть только несколько разных сообщений об ошибках и несколько разных типов (Number, String, Object и т. Д.)
Если бы не JQuery, я бы все равно ненавидел его так же, как раньше :)
источник
char
s, приводить что угодно к чему-либо с помощью указателей void * и т. Д.) Он статически типизирован вместо динамически типизированного, а также требует явной типизации вместо вывод типа, но они не связаны с сильной v / s слабой типизацией. [Случайные примеры: Python имеет неявную динамическую строгую типизацию, Haskell имеет (необязательно явную) статическую строгую типизацию, Java имеет явную (в основном статическую) строгую типизацию, C имеет явную статическую (относительно слабую) типизацию.] "Строго типизированный" и "слабо типизированный "на самом деле не четко определены.'3'+'2'='32'
,'3'-'2'=1
.PHP:
1) Заставляет меня делать ненужные переменные:
2) Реализация lambdas, настолько хромая, что примерно эквивалентна использованию
eval()
и настолько ужасно неправильна, что я никогда не использовал ее (см. Http://www.php.net/create_function ).3) Система try / catch, которая может отлавливать только около 80% возможных ошибок.
4) Поддержка Regex такая же хромая, как и лямбда-поддержка, потому что она должна быть написана внутри обычных строк, что делает один из самых сложных в освоении инструментов программирования примерно в три раза сложнее. И PHP должен быть «простым» языком?!?!?
5) Нет способа безопасно извлечь что-то из $ _POST, не написав его дважды, не создав собственную функцию или не используя оператор '@':
6) Бонусный ответ: «@». Если вы не можете быть обеспокоены написанием своего кода правильно, просто добавьте '@', и это слишком плохо для тех, кому позже придется отлаживать ваш код.
источник
C ++
источник
C # / .NET:
lock
утверждений - вместо этого у вас должны быть определенные блокирующие объекты, и должны быть такие методы,Acquire
которые возвращают одноразовые маркеры блокировки. Следствие: не должно быть монитора для каждого объекта.GetHashCode()
иEquals()
не должно бытьSystem.Object
- не все подходит для хеширования. Вместо этого, иметьIdentityComparer
который делает то же самое, и держатьIComparer<T>
,IComparable<T>
,IEqualityComparer<T>
иIEquatable<T>
интерфейсы для пользовательских сравнений.Это было с моей головы - спросите меня завтра, и я приду к другому 5 :)
источник
С
Необходимость иметь дело с строковыми буферами вручную является склонной к ошибкам болью. Поскольку большое количество вычислений действительно перемещает и модифицирует строки (компьютеры не так часто используются для обработки больших чисел, как люди думали, что они когда-то вернутся назад), очень приятно иметь возможность использовать управляемые языки или строку C ++ объекты для борьбы с этим. Когда я должен сделать это в прямом C, это похоже на плавание в зыбучих песках.
источник
Как насчет пяти вещей, которые я ненавижу в списках «Вещи, которые я ненавижу в каком-то языке»? : D
5 - Оранжевый красный не делает его яблоком.
Когда проектируется язык, дизайнеры обычно имеют в виду, для чего он нужен. Использование этого для чего-то совершенно другого может работать, но жаловаться, когда это не так, просто глупо. Возьми Питона. Я уверен, что или кто-то имеет, или кто-то когда-нибудь сделает утилиту для создания exe-файлов из кода Python. Почему на земле Бога вы хотите это сделать? Это было бы аккуратно - не поймите меня неправильно - но это бесполезно. Так что перестаньте жаловаться на это!
Хорошо разработанный проект, вероятно, будет содержать код на нескольких языках. Это не значит, что вы не можете завершить проект только с одним языком. Некоторые проекты могут быть в пределах возможностей любого языка, который вы используете.
4- Вы стоите на деревянных ногах?
Платформа может оказать большое влияние на то, что может сделать язык. В настоящее время сборщики мусора, или даже ранняя попытка «сбора мусора» в паскалях, могут помочь в исчезновении памяти (может быть, malloc больше оперативной памяти ??). Компьютеры работают быстрее и, конечно, мы ожидаем большего от наших языков. И, честно говоря, мы, вероятно, должны. Однако за удобство компилятора приходится платить огромную цену за создание хеш-таблиц или строк, а также за множество других концепций. Эти вещи не могут наследоваться той платформе, на которой они используются. Сказать, что их легко включить в язык, просто говорит мне, что у вас может не быть ноги, на которой можно стоять.
3- Кто виноват, это правда?
Ошибок. Знаешь. Я люблю жуков. Почему я люблю жуков. Потому что это значит, что я могу сохранить свою работу. Без ошибок было бы много закрытых пиццерий. Однако пользователи ненавидят ошибки. Но вот небольшой всплеск холодной воды. Каждая ошибка - ошибка программистов. Не язык. Язык с таким строгим синтаксисом, который значительно уменьшил бы количество возможных ошибок, был бы совершенно бесполезным языком. Его способности, вероятно, можно посчитать с одной стороны. Вы хотите гибкости или власти? У вас есть ошибки. Почему? Потому что ты не идеален, и ты совершаешь ошибки. Возьмите действительно идентифицируемый пример в C:
Мы все знаем, что будем делать. Однако, возможно, некоторые из нас не осознают, что ... функциональность может быть очень полезной. В зависимости от того, что вы делаете. Переполнение буфера - это стоимость этой функциональности. Этот код выше. Если бы я действительно выпустил это для публики. Это опять .. скажи это со мной .. "Моя вина". Не С за то, что позволил мне это сделать.
2- Разве мы не должны положить это в корзину?
Очень просто указать на функцию на языке, который мы не понимаем, потому что мы не используем его часто и называем его глупым. Пожаловаться, что он есть и т. Д. Гото всегда развлекает меня. Люди всегда жалуются на то, что Гото говорит на языке. Тем не менее, держу пари, что ваша последняя программа включала в себя тип goto. Если вы когда-либо использовали перерыв или продолжение, вы использовали goto. Это и есть. Конечно, это «безопасный» переход, но это то, что есть. У Гото есть свое применение. Используются ли «неявные» gotos, такие как continue или break, или явные gotos (с использованием фактического ключевого слова «goto» для любого языка). Не то, чтобы разработчики языка были безупречны, но обычно ... если функциональность существовала с незапамятных времен (для этого языка). Вероятно, этот аспект является определяющим качеством этого языка. Смысл .. это ' s используется и, вероятно, не зависает из-за обратной совместимости. Это используется сегодня. Как и 5 минут назад. И используется правильно. Ну ... возможно, кто-то использует его ненадлежащим образом, но это относится к # 3 в моем списке.
1. - Все является объектом.
Хорошо ... это действительно подмножество # 2. Но это самая раздражающая жалоба, которую я вижу в списках ненависти. Не все это объект. Существует множество концепций, которые не принадлежат или не должны быть объектами. Размещать вещи там, где они не принадлежат, просто безобразно и может снизить эффективность программы. Конечно. Может быть, не так много, в зависимости от языка. Это также относится к № 5. Это значит ... да. Глобал в порядке. Функции в отличие от статических методов в порядке. Объединение ОО-программирования с глобальными функциями - это нормально. Теперь ... это не значит, что мы все должны выйти и "освободить" наш код от его объектных моделей. При разработке раздела кода или целого проекта то, что происходит за кулисами, должноследует учитывать при составлении его вместе. Мало того, где живет эта концепция и многие другие факторы. Зачем заключать глобальные функции в классы или концепции пространства имен, если это не имеет смысла? Возьмите статические переменные-члены. Это очень забавляет меня, потому что .. хорошо .. В зависимости от языка и реализации, конечно, но в целом вы только что объявили глобальным. Да, есть несколько причин, чтобы обернуть эти не-OO-концепции в OO-оболочки. Одним из них является самодокументированный код. Это может иметь смысл. Так .. как я и говорю. Не выходите и «освободите» свой код. Но любой хороший современный язык будет иметь глобальную концепцию вне ОО-моделирования. Да, я специально хочу указать, что язык программирования ОО без глобальной концепции, скорее всего, имеет серьезный недостаток в дизайне. Опять же, хотя .. зависит от намерения и дизайна языка, поэтому я не пытаюсь выбрать какой-то конкретный язык, и здесь слишком много, чтобы проанализировать его. В любом случае, подумайте, где код должен жить и быть наиболее эффективным. Добавление вспышки к чему-то, что не добавляет функциональности или поддержки, просто изнашивает клавиатуру быстрее. Это никому не приносит пользы. Ну ... если вам не нравятся очки брауни от человека, который, вероятно, неправильно учил вас, что все является объектом.
Короче говоря, программирование - это не просто бездумное нажатие на клавиатуру. Есть много конструктивных соображений для любого проекта. Я знаю, что это клише, но вы должны смотреть на это со всех сторон. Даже с современными типобезопасными языками. Вы не просто бросаете код и ожидаете, что он будет работать хорошо. Конечно ... это может сработать, но это может быть неправильный путь. В целом, выберите язык и формат, который лучше всего подходит для конкретной работы И окружающей среды. Но ни один язык не отнимает мысли, стоящие за этим. Если вы не думаете .. вы просто печатаете.
источник
Пять вещей, которые я ненавижу в Java (который сейчас является моим любимым языком) в произвольном порядке.
источник
В Ruby есть много недостатков, связанных с его скоростью, но я их не ненавижу. У этого также есть недостатки с евангелизацией сообщества, идущей за борт, но это действительно не беспокоит меня. Вот что я ненавижу:
Способ передачи блока в функции глупый. Нет причин, по которым блоки должны передаваться за пределы списка параметров или иметь странный специальный синтаксис для доступа (yield). Я придерживаюсь мнения, что блокам должен был быть задан менее неоднозначный синтаксис (или хэши могли бы использовать разные разделители; возможно, <>, а не {}), и передача в качестве параметров в методы должна была быть такой же, как и все другие параметры.
Эти странности, такие как блок должен быть последним переданным параметром, и передача более одного блока отличается с более длинным синтаксисом, действительно раздражают меня.
источник
Perl
Смешанное использование сигил
Например, ни один из них не одинаков:
В
Perl6
нем написано :Отсутствие истинного OO
В
Perl6
нем написано :Плохо разработанные функции регулярных выражений
В
Perl6
нем написано :Отсутствие многократной отправки
В
Perl6
нем написано :Плохая перегрузка оператора
В
Perl6
нем написано :источник
Я буду делать PHP так, как мне нравится, и Python будет слишком много.
Нет пространства имен; все в каком-то очень большом пространстве имен, которое ад в больших средах
Отсутствие стандартов в отношении функций: функции массива принимают иглу в качестве первого аргумента, стог сена - в качестве второго (см. Array_search ). Строковые функции часто берут стог сена первым, а иголку вторым (см. Стр. ). Другие функции просто используют разные схемы именования: bin2hex , strtolower , cal_to_jd
Некоторые функции имеют странные возвращаемые значения, что не является нормальным: это заставляет вас иметь третью переменную, объявленную из ниоткуда, в то время как PHP может эффективно интерпретировать пустой массив как ложный с помощью жонглирования его типов. Нет рядом других функций, делающих то же самое.
Язык (до PHP6) делает все возможное , чтобы уважать почти-отсталый обратную совместимость, что делает его носить плохие методы и функции вокруг , когда не требуется (см mysql_escape_string против mysql_real_escape_string ).
Язык превратился из языка шаблонов в полноценный. Это означает, что кто угодно может выводить что угодно, когда захочет, и этим злоупотребляют. В итоге вы получаете шаблоны для языка шаблонов ...
Это отстой при импорте файлов. У вас есть 4 различных способа сделать это (включая, include_once, require, require_once), все они медленные, очень медленные. На самом деле весь язык медленный. По крайней мере, довольно медленно, чем Python (даже с фреймворком) и RoR из того, что я собираю.
Я все еще люблю PHP, хотя. Это цепная пила веб-разработки: вы хотите, чтобы сайт от маленького до среднего выполнялся очень быстро и был уверен, что кто-нибудь может его разместить (хотя конфигурации могут отличаться)? PHP прямо здесь, и он настолько вездесущ, что требуется всего 5 минут для установки полного стека LAMP или WAMP. Ну, я сейчас вернусь к работе с Python ...
источник
Вот некоторые вещи, которые мне не нравятся в Java (это не мой любимый язык):
источник
C ++
питон
источник
Objective-C
1) Нет пространств имен, только соглашения по именованию вручную - я не против этого с точки зрения разделения классов, но мне не хватает возможности импортировать все определения классов в пространстве имен в одну строку (например, import com.me.somelibrary. *).
2) В библиотеках все еще есть дыры в важных областях, таких как поддержка RegEx.
3) Синтаксис свойства немного неуклюжий, требующий три строки (в двух отдельных файлах) для объявления свойства.
4) Мне нравится модель сохранения / выпуска, но легче выпустить ссылку, а затем случайно использовать ее позже.
5) Хотя Xcode на самом деле не является языковой функцией, она настолько переплетена с использованием Objective-C, что я не могу не думать об этом аспекте ... в основном автозаполнение очень сомнительно. Это больше похоже на систему, которая вознаграждает вас за то, что вы нашли то, что вы хотите, существует, а затем представляет это как выбор. Но тогда я полагаю, что мне никогда не нравились двигатели с автозаполнением.
источник
YES/NO
для логических выражений это плохо? И что более важно, вы говорите, что именованные параметры - это плохо? Я могу понять bools, но именованные параметры, возможно, являются одной из лучших функций ObjC (с точки зрения читабельности).C ++
Строки.
Они не совместимы со строками платформы, поэтому в итоге вы используете std :: vector половину времени. Политика копирования (копирование при записи или глубокое копирование) не определена, поэтому нельзя дать гарантии производительности для простого синтаксиса. Иногда они полагаются на алгоритмы STL, которые не очень интуитивно понятны в использовании. Слишком много библиотек катят свои собственные, которые, к сожалению, намного более удобны в использовании. Если вы не должны объединить их.
Разнообразие строковых представлений
Теперь, это небольшая проблема с платформой - но я все еще надеюсь, что было бы лучше, если бы менее упрямый стандартный класс строк был бы доступен ранее. Следующие строковые представления, которые я часто использую:
Построить модель.
Я до смерти устал от того, что все время тратился на перепутывание с кем-то, что-то, предварительными декларациями, оптимизацией предварительно скомпилированных заголовков и включений, чтобы поддерживать переносимость как минимум добавочного времени сборки и т. Д. Это было здорово в восьмидесятых, но сейчас? Есть так много препятствий для упаковки кода, чтобы его можно было использовать повторно, чтобы даже маме собаке стало скучно слушать меня.
Трудно анализировать
Это делает внешние инструменты особенно сложными для написания и получения правильных результатов. И сегодня нам, ребятам из C ++, в основном не хватает цепочки инструментов. Я люблю свое отражение в C # и делегатов, но я могу жить без них. Без большого рефакторинга я не могу.
Потоки слишком сложны.
Язык даже не распознает их (на данный момент), и свободы компилятора - хотя и велики - слишком болезненны.
Статическая инициализация и инициализация по требованию. Технически, я обманываю здесь: это еще одна часть головоломки в «коде повторного использования»: это кошмар, чтобы получить что-то инициализированное только тогда, когда это необходимо. Лучшее решение всех других проблем с переадресацией - это бросить все в заголовки, эта проблема говорит: «Нет, вы не можете».
Конечно, многое из этого выходит за рамки строгой языковой компетенции, но IMO весь инструментарий необходимо оценивать и развивать.
источник
std::string
? может быть, чтение хорошей документации и / или учебникаstd::vector
(и почему вы не должны использовать егоstd::string
в местах, для которых он никогда не был предназначен) может прояснить это для вас.std::string
если я не могу использовать его половину времени? (C ++ 0x по крайней мере исправляет это, но я все еще застрял с десятками библиотек, которые используют различные строковые представления).but why do we have to bother with them (inclusion guards)
- потому что C ++ не имеет модулей.How "standard" is a std::string if I can't use it half of the time?
- Я думаю, это зависит от того, как вы используетеstd::string
. Строковый класс позволяет вам получить доступ к строковым данным какconst char*
черезstd::string::c_str
, что уже делает егоstd::string
полностью совместимым с каждым классом / функцией, которая также принимаетconst char*
аргументы.JavaScript :
Object
Прототип может быть изменен. Каждый отдельный объект в вашей программе получает новые свойства, и, возможно, что-то ломается.Все объекты являются хеш-картами, но их безопасно использовать как таковые. В частности, если один из ваших ключей окажется
__proto__
, у вас проблемы.Нет закрытия объекта во время ссылки на функцию. Фактически, закрытие объекта вообще не
this
выполняется - вместо этого устанавливается всякий раз, когда вызывается функция с нотацией объекта илиnew
оператором.this
Это приводит к большой путанице, особенно при создании обратных вызовов событий, потому что не установлено то, что ожидает программист.new
оператора приводит к тому,this
что его значение устанавливается равным глобальному объекту, что приводит к значительному повреждению.Оператор сложения перегружен для выполнения конкатенации строк, несмотря на то, что эти две операции принципиально различаются. Причиняет боль, когда значение, которое вы ожидаете получить, на самом деле является строкой.
==
и!=
операторы выполняют приведение типов. Сравнения между различными типами включают список правил, которые ни один смертный не может запомнить полностью. Это смягчается наличием===
и!==
операторов.И то,
null
и другоеundefined
существует, с немного разными, но лишними значениями. Почему?Странный синтаксис для настройки цепочек прототипов.
parseInt(s)
ожидает число в стиле C, поэтому рассматривает значения с начальными нулями как восьмеричные и т. д. Вы можете, по крайней мере,parseInt(s, 10)
но поведение по умолчанию сбивает с толку.Нет области видимости блока.
Может объявлять одну и ту же переменную более одного раза.
Может использовать переменную, не объявляя ее, в этом случае она является глобальной и, вероятно, нарушает вашу программу.
with { }
,Действительно сложно документировать с помощью инструментов, подобных JavaDoc.
источник
null
иundefined
: иногда вы действительно хотите знать, было ли переменной присвоено значение или нет. Поскольку null - это значение, undefined - единственный способ определить это. Конечно, единственный раз, когда я нашел это полезным, было создание функций получения / установки.for
в качестве имени переменной."for"
допустимо в качестве хеш-ключа.__proto__
не зарезервированное слово Специальные строковые значения, которые не работают должным образом при использовании в качестве ключей хеша, нарушают разумные ожидания о том, как ассоциативные массивы работают на любом языке. Они также нарушают спецификацию EcmaScript.newline may or may not end a statement depending on context
это один из моих 5 лучших списковPython:
__init__
)__getattr__
что не так)print
загрузки в файл (но они исправляют это в Python 3)источник
C #
Я хотел бы
switch()
на любой тип, и этоcase
может быть любое выражение.Нельзя использовать синтаксис инициализатора объекта с полями «только для
private set
чтения» / autoprops. Как правило, мне нужна языковая помощь в создании неизменяемых типов.Использование
{}
для пространства имен и класса, а также метода и блоков свойств / индексаторов, блоков с несколькими операторами и инициализаторов массива. . Трудно понять, где вы находитесь, когда они далеко друг от друга или не соответствуют друг другу.Я ненавижу писать
(from x in y ... select).Z()
. Я не хочу возвращаться к синтаксису вызова метода, потому что в синтаксисе запроса что-то отсутствует.Я хочу
do
пункт о синтаксисе запроса, который похожforeach
. Но тогда это не совсем вопрос.Я действительно достигаю здесь. Я думаю, что C # - это фантастика, и трудно найти что-то сломанное.
источник
PHP
источник
C (хорошо, это не мой любимый, но это еще не было сделано.)
РЕДАКТИРОВАТЬ: я мог бы, вероятно, придумать больше, если бы я прибегнул к большему количеству библиотечного кода (как я сделал с сокетами, но это особенно плохо), но я уже чувствовал, что я обманывал для выбора на C. Так много языков существует только для хорошие части C и заменить плохие, что это похоже на избиение мертвой лошади.
источник
Common Lisp:
источник
BrainF * ск
Ваш основной момент в том, что вы завершили сборку ? Я могу сделать больше в регулярных выражениях Perl!
Отсутствие предметов. Да ладно, люди! Это как, привет ...
Нет сетевых библиотек. Все, что я хочу, это очистить веб-страницу, GOSH.
Нет первоклассных функций. Поздравляем - вы можете поболтать с друзьями по Java.
Бесконечная лента для хранения и ничего больше. Это настолько анально претенциозно, что мы могли бы также написать Лисп.
источник
JavaScript
источник
PHP:
Тем не менее PHP является (сценарии) языком. ;-)
источник
VB6
источник
Ruby - мой любимый язык, вот что мне не нравится:
источник
Delphi:
источник
JavaScript
Каждый сценарий выполняется в едином глобальном «пространстве имен» ... то, на что вы должны обращать внимание при работе со сценариями из разных источников.
Если переменная используется, но не была определена ранее, она считается глобальной переменной
Поставщики браузеров разрабатывают стандарты по своему усмотрению, делая программирование для нас, разработчиков, использующих такой красивый язык, сложнее, чем должно быть
Чувствительность к регистру - учитывая, что не существует достойной IDE для разработки js с проверкой во время компиляции
Обходные пути (например, использование
hasOwnProperty
метода) для выполнения некоторых, в противном случае простых операций.источник
Haskell:
($)
оператора может быть изменена, чтобы сделать некоторые выражения более красивыми.Большинство из них не достигают уровня ненависти, и есть люди, пытающиеся найти или построить надежные обходные пути для каждого из них.
Изменить: Там было некоторое замешательство по поводу пункта 5. В частности, некоторые люди, кажется, думают, что я имел в виду порядок аргументов, а я нет. Вместо того, чтобы объяснять, что я имел в виду, я просто укажу людям на следующую ссылку: http://hackage.haskell.org/trac/haskell-prime/wiki/ChangeDollarAssociativity , которая хорошо это выражает.
источник