Зауюзать ф-цию не прочитав доку. Потом удивлять почему она работает не так, как я себе придумал.
Согласен. Хотя бывает и обратное:
Описание: Функция сортирует A-Z.
А по факту сортирует только 3 символа: A, -, Z.
Описание: Функция сортирует A-Z.
А по факту сортирует только 3 символа: A, -, Z.
А пример и жизни можно? Часто бывает что доки просто нету, но я давно имею привычку перечитывать исходники подключаемых либ (если это возможно).
Описанное crkll больше на регексп похоже
хз эту мамбуду - \w и A-z это походу перебор для яваскрипта ?
думаю что речь шла о порядке сортировки, а не про регулярки
да, но как бы порядок сортировки в ней можно указать
А однажды попалась и более всратая фигня:
Коммент: "эта хрень сортирует числа".
По факту сортировка для всяких статей и документов (не помню зачем). В "числа" включены и римские, типо: XVIII, IX и т. п.
Долго не мог понять, пока не поднял исходник.
Коммент: "эта хрень сортирует числа".
По факту сортировка для всяких статей и документов (не помню зачем). В "числа" включены и римские, типо: XVIII, IX и т. п.
Долго не мог понять, пока не поднял исходник.
читать исходники - полезно, интересно и даже необходимо, если речь о npm пакетах (там и фото автора могут быть, и левые текстовые файлы, инструкции по прокачке пресухи и тд)
Представляю, как охренел человек, которому задали устроить сортировку римских чисел.
просто конвертируешь в арабские и сравниваешь. конвертор с кучей ифов. но не сложный.
Если в языке или библиотеке, функции, особенно тривиальные, требуют вдумчивого чтения документации, потому что ведут себя не так, как эти же функции в других языках, и не так, как было бы логично, то это яркий пример абсолютно уебанского дизайна.
В идеале, просто при взгляде на список функций какого-либо фасада чего-либо, должно быть однозначно понятно, что и как это что-то работает, и что оно умеет. И функции не должны вести себя не так, как может показаться из названия.
В идеале, просто при взгляде на список функций какого-либо фасада чего-либо, должно быть однозначно понятно, что и как это что-то работает, и что оно умеет. И функции не должны вести себя не так, как может показаться из названия.
Так внутрь просто надо передать сравнивающую функию аля .sort((a,b) => +a - +b), после того как один раз наебнешься запомнишь на всегда. Задолбали эти мемы про джс когда на самом деле просто програмисты криворукие.
про принцип наименьшего удивления в мире js не слыхали?
в сотнях языков есть функция или метод sort. везде делает то, что ожидается. кроме сраного js.
вот нахуя?
в сотнях языков есть функция или метод sort. везде делает то, что ожидается. кроме сраного js.
вот нахуя?
причина в динамической типизации. Т.к. массив может содержать значения разных типов, то (по умолчанию) перед сравнением у сравниваемых членов вызывается toString, и сравниваются результирующие строки. Что бы изменить поведение по умолчанию, нужно передать ф-цию, которая будет сравнивать так, как тебе нужно.
нет, причина в долбоебизме.
что мешало назвать функцию sort_lexicographically?
что мешало назвать функцию sort_lexicographically?
ну потому что это стандартная ф-ция для сортировки. "lexicographically" - это частный случай. По сути sort - это ф-ция высшего порядка, которая как раз и принимает определенную пользователем ф-цию для сортировки.
то есть слепили в кучу 2 разные функции и разной семантикой, при этом по дефолту сделали редкий частный случай - это типа нормально?
по умолчанию сделан не редкий случай, а единственно возможный. В js у всех объектов гарантировано реализован метод toString.
динамическая типизация = криворукие программисты
динамическая типизация == криворукие программисты
динамическая типизация === криворукие программисты
Это не динамическая типизация, а слабая типизпция
Тогда уж типизация тут вообще не при чем - toString и в java есть, а там сильная статическая. Дело не в типизации, а в том, что дизайн языка - говно.
Проблема в том, что в js отсутствует напрочь такое понятие, как тип массива, или тип коллекции. И это выбешивает.
Там нет понятия "массив интов", или "массив строк", всегда "массив хуй знает чего".
Там нет понятия "массив интов", или "массив строк", всегда "массив хуй знает чего".
Это был просто пример с другой типизацией. Я могу и другой привести: в python тоже любой тип приводится в str, у списков нет типа, но list.sort() все равно забросает тебя исключениями, если типы не согласуются. Так что "массив хуй знает чего" вообще не оправдание для такого поведения. :)
там все хуй знает чего
Тогда должны быть функции
sortNum()
sortStr()
sortObj([A,B=>Int] comparator)
А не одна, по умолчанию делающая неинтуитивное приведение типов.
sortNum()
sortStr()
sortObj([A,B=>Int] comparator)
А не одна, по умолчанию делающая неинтуитивное приведение типов.
Нет, необходимо создать универсальную функцию, которая будет сортировать согласно принимаемым параметрам... OH SHIT!
Тогда у неё не должно быть неочевидного поведения по умолчанию. Потому что оно нарушает принцип наименьшего удивления.
Проблема именно с этим сортом в том, что иногда он сработает для чисел правильно, а иногда - нет. То есть, легко проебаться при тестировании, но оно тихо, без ошибок, наебнет тебе логику в проде.
Проблема именно с этим сортом в том, что иногда он сработает для чисел правильно, а иногда - нет. То есть, легко проебаться при тестировании, но оно тихо, без ошибок, наебнет тебе логику в проде.
В питоне тоже динамическая типизация, но такого блядства нет.
Это не программисты криворукие, это архитекторы кривоногие.
Вот, к примеру, кем надо быть, чтобы в java.util.Date нумеровать месяцы с нуля, а дни - с единицы?
Хорошо хоть с некоторых пор на опасных методах @Deprecated повесили...
Вот, к примеру, кем надо быть, чтобы в java.util.Date нумеровать месяцы с нуля, а дни - с единицы?
Хорошо хоть с некоторых пор на опасных методах @Deprecated повесили...
java.util.Date полностью задепрекейчен уже лет десять
а до этого все нормальные люди юзали йоду лет десять
а до этого все нормальные люди юзали йоду лет десять
Беда в том, что я с ней работал двадцать лет назад :-)))
Прям как обсуждать проезд по 50 копеек.
Чтобы написать коммент, необходимо залогиниться