Здравствуйте, anonymous, Вы писали:
A>Это странный аргумент из разряда «настоящие программисты не читают мануалы».
Языки строятся на некотором ожидаемом поведении, если можно интерпретировать запись функции, но для понимания её поведения нужно лезть в мануал — то это не ожидаемое поведение и потенциальный источник ошибок.
Конкретно в этом случае ожидается применение функции parseInt к элементам коллекции. Вместо этого функция применяется не только к элементам коллекции, но и к нескольким дополнительным скрытым параметрам (мы нигде в записи не видим существование индекса) — в результате на выходе появляются не ожидаемые данные.
A>Не вижу, как в языке без сигнатур функций реализовать требование точного количества аргументов. В JS вообще любая функция, в которую ты передаёшь функцию, может вызвать её с любым количеством параметров — к этому надо быть готовым.
Я в курсе. Поэтому (в частности) и считаю что JS — говно.
A>Это как динамическая типизация — нужно следить самому за тем, что ты делаешь, хотя можно встать в позу и заявить, что «ради экономии пары символов» не ввели статическую.
А можно встать в позу и орать "Это не баг, это фича!!!".
A>Правильный путь для приведённого выше примера не отличается от того, что предложил ты: A>
A>array.map(function (e) { return parseInt(e) });
A>
Это то же самое что и у меня, просто записанное по другому. Но речь слегка не об этом — я рассматривал именно существование неправильного способа использования и определение своей анонимной функции не отменяет наличие кривого map'а.
Здравствуйте, anonymous, Вы писали:
A>>>Я спросил: какой из способов «простой, очевидный и общепринятый» — проверять количество переданных аргументов в функцию или нет? F>>простой — не проверять F>>очевидный — проверять F>>общепринятый — проверять A>Закроем пока глаза на спорность этих утверждений. И как это совместить?
поднапрячься и сделать ограничения. да, это требует усилий.
A>>>То есть программисты, использующие ЯП с динамической типизацией — ненормальные. С нестрогой типизацией — ненормальные. С объявлением переменных не в начале блока инструкций — ненормальные. С возможностью выхода за пределы выделенной памяти — ненормальные. И так далее. F>>ты сейчас всех ненормальными назвал. ты, не я. A>Ты же сказал, что нормальные программисты на таком не пишут: A>
и таки язык должен [ограничивать]. если не может, я его выкидываю. и так делают все нормальные программисты испокон веков.
A>Только не говори, что «ограничивать» имеет какое-то другое значение.
со всем списком — да, не пишут. с нестрогой типизацией стараются не трогать.
в остальных случаях с ограничениями всё нормально.
A>>>На чём ты пишешь, кстати? F>>на всём, что под руки попадётся. A>Ну, озвучь уж, чем нормальные программисты пользуются.
Здравствуйте, Somescout, Вы писали:
S>Здравствуйте, anonymous, Вы писали:
A>>Это странный аргумент из разряда «настоящие программисты не читают мануалы». S>Языки строятся на некотором ожидаемом поведении, если можно интерпретировать запись функции, но для понимания её поведения нужно лезть в мануал — то это не ожидаемое поведение и потенциальный источник ошибок.
В разных семействах языков ожидания совершенно различные и это ежу понятно.
S>Конкретно в этом случае ожидается применение функции parseInt к элементам коллекции. Вместо этого функция применяется не только к элементам коллекции, но и к нескольким дополнительным скрытым параметрам (мы нигде в записи не видим существование индекса) — в результате на выходе появляются не ожидаемые данные.
В динамических языках вообще говоря стараются избегать сокращенных форм записи, поскольку очень легко ошибиться. Потому сокращенная запись это уже неожиданная вещь и как правило потенциально содержит ошибку. В данном случае именно так и есть.
A>>Не вижу, как в языке без сигнатур функций реализовать требование точного количества аргументов. В JS вообще любая функция, в которую ты передаёшь функцию, может вызвать её с любым количеством параметров — к этому надо быть готовым. S>Я в курсе. Поэтому (в частности) и считаю что JS — говно.
Тебе не нравится динамическая типизация а не JS.
A>>Правильный путь для приведённого выше примера не отличается от того, что предложил ты: A>>
S>Это то же самое что и у меня, просто записанное по другому. Но речь слегка не об этом — я рассматривал именно существование неправильного способа использования и определение своей анонимной функции не отменяет наличие кривого map'а.
В каждом языке существуют и кривые способы использования фич, и неявные эффекты. К одним ты просто привык. К тем что не привык — те вызывают боль. Такая жизнь.
Здравствуйте, Somescout, Вы писали:
A>>Это странный аргумент из разряда «настоящие программисты не читают мануалы». S>Языки строятся на некотором ожидаемом поведении, если можно интерпретировать запись функции, но для понимания её поведения нужно лезть в мануал — то это не ожидаемое поведение и потенциальный источник ошибок.
Но это же не так в общем случае, даже скорее совсем не так. Уж даже знаки операций в языках отличаются, а ты требуешь полного соответствия имён функций и их поведения.
A>>Не вижу, как в языке без сигнатур функций реализовать требование точного количества аргументов. В JS вообще любая функция, в которую ты передаёшь функцию, может вызвать её с любым количеством параметров — к этому надо быть готовым. S>Я в курсе. Поэтому (в частности) и считаю что JS — говно.
Вкусовщина. Нет смысла обсуждать.
A>>Это как динамическая типизация — нужно следить самому за тем, что ты делаешь, хотя можно встать в позу и заявить, что «ради экономии пары символов» не ввели статическую. S>А можно встать в позу и орать "Это не баг, это фича!!!".
Но тем не менее это фича. И люди, пропагандирующие единственно верный способ типизации или описания функций выглядят странно.
A>>Правильный путь для приведённого выше примера не отличается от того, что предложил ты: A>>
S>Это то же самое что и у меня, просто записанное по другому. Но речь слегка не об этом — я рассматривал именно существование неправильного способа использования и определение своей анонимной функции не отменяет наличие кривого map'а.
Что угодно можно использовать неправильно — тут вообще нечего обсуждать. В обсуждаемом же примере ошибка ещё в том, что parseInt нельзя использовать без второго параметра, поскольку поведение в этом случае не определено и зависит от реализации. Итого мы имеем: разработчик не разобрался в инструменте, совершил две ошибки и получил не то, что хотел. Хороший пример, когда танцевать помешали яйца.
Здравствуйте, neFormal, Вы писали:
A>>>>Тогда не понятно, что эти примеры должны были продемонстрировать. SA>>>Я, конечно, не уверен, но могу предположить, что коллега демонстрировал свое восхищение потря I>>А при чем здесь архитектура JS? динамическая типизация + особенности конкретной библиотеки
F>а при чём здесь типизация? проблема же в отсутствии проверки количества переданных аргументов. здесь типов нет.
Подсчет количества аргументов это требование времени выполнения — аргумент функции есть колбек определенного вида. То есть, самая что ни есть типизация.
Здравствуйте, neFormal, Вы писали:
A>>>>Я спросил: какой из способов «простой, очевидный и общепринятый» — проверять количество переданных аргументов в функцию или нет? F>>>простой — не проверять F>>>очевидный — проверять F>>>общепринятый — проверять A>>Закроем пока глаза на спорность этих утверждений. И как это совместить? F>поднапрячься и сделать ограничения. да, это требует усилий.
Ну так, кто поднапрягся? Где параметры одновременно проверяются и не проверяются?
A>>>>То есть программисты, использующие ЯП с динамической типизацией — ненормальные. С нестрогой типизацией — ненормальные. С объявлением переменных не в начале блока инструкций — ненормальные. С возможностью выхода за пределы выделенной памяти — ненормальные. И так далее. A>>Ты же сказал, что нормальные программисты на таком не пишут: F>со всем списком — да, не пишут. с нестрогой типизацией стараются не трогать. в остальных случаях с ограничениями всё нормально.
То есть таки какое-то своё определение слова «ограничивать». Ну, поделись.
A>>Ну, озвучь уж, чем нормальные программисты пользуются. F>не js
Здравствуйте, anonymous, Вы писали:
F>>поднапрячься и сделать ограничения. да, это требует усилий. A>Ну так, кто поднапрягся? Где параметры одновременно проверяются и не проверяются?
Здравствуйте, StandAlone, Вы писали:
SA>Здравствуйте, Ikemefula, Вы писали:
I>>А при чем здесь архитектура JS? динамическая типизация + особенности конкретной библиотеки SA> Чего-чего особенности????
Промисы — библиотечная фича, а не языковая. До вхождения в стандарт их годами использовали отдельной библиотекой и были ровно те же проблемы.
Здравствуйте, StandAlone, Вы писали:
SA>Нет, это у вас какой-то свой междусобойчик организовался. SA>А тема вообще-то о том, какой JS простой, стильный, клевый и позволяющий делать крутые штуки. Я тут уже реализацию then приводил, но ее что-то никто не заметил SA>Попробую еще раз. SA>Вот вам, например! Красота-то какая, ляпота! Где-нибудь еще такое видели? И в отладке, и в поддержке
Здравствуйте, Ikemefula, Вы писали:
F>>а при чём здесь типизация? проблема же в отсутствии проверки количества переданных аргументов. здесь типов нет. I>Подсчет количества аргументов это требование времени выполнения — аргумент функции есть колбек определенного вида. То есть, самая что ни есть типизация.
Здравствуйте, Ikemefula, Вы писали:
S>>Языки строятся на некотором ожидаемом поведении, если можно интерпретировать запись функции, но для понимания её поведения нужно лезть в мануал — то это не ожидаемое поведение и потенциальный источник ошибок. I>В разных семействах языков ожидания совершенно различные и это ежу понятно.
но если берут фичу из другого языка, то зачем её портить?
I>В динамических языках вообще говоря стараются избегать сокращенных форм записи, поскольку очень легко ошибиться.
вообще говоря, это неправда.
в питоне, руби, эрланге, лиспах... да везде пишут сокращённо, если позволяет синтаксис. в js просто сделано ректально.
I>Тебе не нравится динамическая типизация а не JS.
Здравствуйте, anonymous, Вы писали:
A>В обсуждаемом же примере ошибка ещё в том, что parseInt нельзя использовать без второго параметра,
а интерпретатор позволяет.
A>поскольку поведение в этом случае не определено и зависит от реализации.
JS — очень простой язык
A>Итого мы имеем: разработчик не разобрался в инструменте, совершил две ошибки и получил не то, что хотел. Хороший пример, когда танцевать помешали яйца.
ересь, записанная в документации, не перестаёт быть ересью.
в данном примере как раз разработчику и надо помнить, что map можно сделать только вприсядку и подпрыгивая.
Здравствуйте, Ikemefula, Вы писали:
I>Промисы — библиотечная фича, а не языковая. До вхождения в стандарт их годами использовали отдельной библиотекой и были ровно те же проблемы.
Золотые слова! И после вхождения в стандарт они несут с собой те же самые проблемы, обусловленные тем же самым языком.
Порождая M в степени N новых проблем, при попытке написать на этом самом языке что-то с M фич и N строк кода.
Здравствуйте, Ikemefula, Вы писали:
I>Что сказать хотел ?
То, что это ублюдочное, сраное говно, дико похожее на "мракобесный индусский C", которое еще до ES6 повсюду тащили с собой разные ангуляры, стало возможным к реализации только благодаря и посредством ублюдочному JS.
Отсюда чад кутежа, угара и жопотраха при попытке использовать JS для чего-то кроме Hello world.
Здравствуйте, neFormal, Вы писали:
A>>В обсуждаемом же примере ошибка ещё в том, что parseInt нельзя использовать без второго параметра, F>а интерпретатор позволяет.
Как и во многих других языках.
A>>поскольку поведение в этом случае не определено и зависит от реализации. F>JS — очень простой язык
Я этого не утверждал. Более того, на мой взгляд, JS довольно сложный язык из-за прототипов.
A>>Итого мы имеем: разработчик не разобрался в инструменте, совершил две ошибки и получил не то, что хотел. Хороший пример, когда танцевать помешали яйца. F>ересь, записанная в документации, не перестаёт быть ересью. в данном примере как раз разработчику и надо помнить, что map можно сделать только вприсядку и подпрыгивая.
Ты так и не объяснил, в чём подпрыгивание. И почему оно на твой взгляд допустимо везде, кроме JS.
Здравствуйте, neFormal, Вы писали:
F>>>поднапрячься и сделать ограничения. да, это требует усилий. A>>Ну так, кто поднапрягся? Где параметры одновременно проверяются и не проверяются? F>какая-то наркомания уже пошла.
Я тебе давно на это намекал, наконец-то ты это осознал.
Здравствуйте, anonymous, Вы писали:
A>Но это же не так в общем случае, даже скорее совсем не так. Уж даже знаки операций в языках отличаются, а ты требуешь полного соответствия имён функций и их поведения.
Извините, тут небольшая описка — не интерпретировать запись функции, а интерпретировать выражение (statement).
Соответственно и речи не идёт об "одинаковых именах функций и операторах": я знаю что делает map, я в курсе существования массивов в js и знаю как они записываются. Я ожидаю что array.map(f) применит функцию f к каждому элементу массива. Но, внезапно, в функции вылазит какой-то index, который не упомянут в коде вообще, и передаётся как один из параметров. Неожиданное, и абсолютно неочевидное поведение.
S>>Я в курсе. Поэтому (в частности) и считаю что JS — говно. A>Вкусовщина. Нет смысла обсуждать.
Ну да, поэтому я и написал: я считаю. А ниже вы свою вкусовщину лепите:
A>Но тем не менее это фича. И люди, пропагандирующие единственно верный способ типизации или описания функций выглядят странно. A>Вкусовщина. Нет смысла обсуждать.
A>Что угодно можно использовать неправильно — тут вообще нечего обсуждать. В обсуждаемом же примере ошибка ещё в том, что parseInt нельзя использовать без второго параметра, поскольку поведение в этом случае не определено и зависит от реализации. Итого мы имеем: разработчик не разобрался в инструменте, совершил две ошибки и получил не то, что хотел. Хороший пример, когда танцевать помешали яйца.
А язык, который молча позволил совершить эти две ошибки совершенно ни при чём. Собственно смотрите выше мою вкусовщину.
Здравствуйте, Somescout, Вы писали:
A>>Но это же не так в общем случае, даже скорее совсем не так. Уж даже знаки операций в языках отличаются, а ты требуешь полного соответствия имён функций и их поведения. S>Соответственно и речи не идёт об "одинаковых именах функций и операторах": я знаю что делает map, я в курсе существования массивов в js и знаю как они записываются. Я ожидаю что array.map(f) применит функцию f к каждому элементу массива. Но, внезапно, в функции вылазит какой-то index, который не упомянут в коде вообще, и передаётся как один из параметров. Неожиданное, и абсолютно неочевидное поведение.
Именно об этом и идёт. Ты знаешь, что делает map в языке X, и требуешь, чтобы ровно то же самое он делал в языке Y. Твоё желание совершенно понятно. Но не ясно, почему разработчики библиотеки должны следовать ему.
S>>>Я в курсе. Поэтому (в частности) и считаю что JS — говно. A>>Вкусовщина. Нет смысла обсуждать. S>Ну да, поэтому я и написал: я считаю. А ниже вы свою вкусовщину лепите:
Где?
A>>Что угодно можно использовать неправильно — тут вообще нечего обсуждать. В обсуждаемом же примере ошибка ещё в том, что parseInt нельзя использовать без второго параметра, поскольку поведение в этом случае не определено и зависит от реализации. Итого мы имеем: разработчик не разобрался в инструменте, совершил две ошибки и получил не то, что хотел. Хороший пример, когда танцевать помешали яйца. S>А язык, который молча позволил совершить эти две ошибки совершенно ни при чём. Собственно смотрите выше мою вкусовщину.
Нет, не при чём, это ж просто инструмент. Когда ты режешь себе палец, это нож виноват или ты чего-то не учёл?
Чего-чего особенности????
