- 1
https://sun1-28.userapi.com/c854224/v854224060/1a2490/7JEShAFqoEU.jpg
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+1
https://sun1-28.userapi.com/c854224/v854224060/1a2490/7JEShAFqoEU.jpg
Сишник половину из этого увидит логичным.
А JS макаки без должного математического образования не знают даже, как правильно проверять на эквивалентность floating point numbers.
gost 13.12.2019 13:36 # +3
Я за «сильную типизацию» и против «слабой параши».
Steve_Brown 13.12.2019 17:45 # +4
Antifriz_otrabotanyi 16.12.2019 23:53 # 0
Кстати, инфиксных выражений в самом Tcl нет, их считают через функцию expr, и работают там только числа. Можно переопределить функцию expr и считать ей как угодно и что угодно. Не то что в этой вашей анскильной пайтушне.
XYPO3BO3 13.12.2019 14:15 # +1
https://github.com/aemkei/jsfuck
Бонус для языка с более сильной типизацией:
https://github.com/wanqizhu/pyfuck
bootcamp_dropout 13.12.2019 15:04 # 0
guestinxo 13.12.2019 15:14 # −1
bootcamp_dropout 13.12.2019 15:18 # 0
bormand 13.12.2019 16:00 # 0
guest8 13.12.2019 17:59 # −999
Soul_re@ver 15.12.2019 11:48 # +1
Вообще, не могу понять, зачем нужно лезть в это ISO кроме понтов "Мы — международный стандарт?"
guestinxo 15.12.2019 12:09 # 0
guest8 13.12.2019 22:48 # −999
guest8 13.12.2019 23:16 # −999
gost 13.12.2019 15:28 # +1
guestinxo 13.12.2019 15:30 # −1
gost 13.12.2019 15:33 # 0
3.14159265 13.12.2019 15:41 # +1
Признайся, это была единственная документация, что ты когда либо видел.
guestinxo 13.12.2019 15:44 # 0
Приведи реальный пример лучшей документации.
guestinxo 13.12.2019 15:45 # 0
gost 13.12.2019 15:48 # 0
3.14159265 13.12.2019 15:49 # +1
https://docs.python.org/3.8/
Единственная пользительная штука в документации к «PHP» это мини-версия so в комментах.
guestinxo 13.12.2019 15:57 # 0
https://docs.python.org/3.8/library/threading.html
Где блядь кусок кода, демонстрирующий как мне посчитать x**2 for x in range(10) параллельно? Он должен быть в начале статьи.
1024-- 16.12.2019 11:33 # +1
Мануал по языку "python" не предназначен для произвольного доступа. И это в то время, когда этот язык рекламируют для быстрого наговнячивания скриптов и SO-программирования. Мануал по языку "python" отвечает требованиям к языку чуть менее, чем никак.
- Нет списка классов в одном месте
- Нет списка функций в одном месте
- Есть только длинная портянка текста, из которой можно выкусить эти списки только юзерскриптом с document.querySelectorAll
+ Есть примеры, даже несколько
В мануале на php.net такого говноподхода нет. Разве что в списке функций есть только имена, а нет сигнатур.
+ Есть классов в одном месте
+ Есть список функций в одном месте
- В списке функций есть только имена, а нет сигнатур.
+ Есть примеры, даже несколько
С php.net может потягаться только cplusplus.com. Там иерархия модулей/классов раскрывается без перехода на новую страницу. И такая ориентируемость на произвольный доступ для нетривиального языка, где для старта требуется много последовательного чтения.
guestinxo 16.12.2019 11:37 # 0
guest8 13.12.2019 17:08 # −999
XYPO3BO3 13.12.2019 17:16 # 0
Тогда для сравнения нужно в остальных примерах тоже показать недокументированные функции. Как минимум у WinAPI недокументированные функции есть.
guest8 13.12.2019 17:51 # −999
Stallman 13.12.2019 18:11 # +2
https://www.php.net/manual/en/function.register-tick-function.php
Какой тик? Какая, блять, функция, с какой сигнатурой? Что за второй параметр с типом mixed? Догадайся сам и напиши об этом в комменты <3
XYPO3BO3 13.12.2019 19:30 # 0
Soul_re@ver 15.12.2019 12:04 # 0
Функция с любой сигнатурой (смотри про параметры выше), можно даже использовать члены класса если первым аргументом передать массив [объект, член-класса] (пример на странице документации)
Тик — это неведомая ёбаная хуйня, которая происходит когда интерпретатор немного поработает. (ссылка есть на странице документации)
Мне приходилось читать много хуёвой документации.
guestinxo 13.12.2019 19:55 # 0
Специально самую хуёвую страницу нашел, молодец
guest8 13.12.2019 19:55 # −999
guestinxo 13.12.2019 19:57 # +1
guest8 13.12.2019 19:59 # −999
guestinxo 13.12.2019 20:01 # +1
guest8 13.12.2019 20:02 # −999
guestinxo 13.12.2019 20:05 # 0
guest8 13.12.2019 20:07 # −999
guestinxo 13.12.2019 20:08 # 0
guest8 13.12.2019 20:12 # −999
guestinxo 13.12.2019 20:15 # 0
guest8 13.12.2019 20:16 # −999
Stallman 13.12.2019 21:14 # 0
guest8 13.12.2019 21:19 # −999
guestinxo 13.12.2019 21:15 # 0
1024-- 16.12.2019 11:54 # 0
+ Список методов и полей
+ Список модулей
+ Примеры
guest8 13.12.2019 22:18 # −999
guest8 13.12.2019 22:21 # −999
gost 13.12.2019 22:22 # 0
>>> В сипайтоне одновременно может работать только один поток.
Если у тебя есть четырёхъядерный проц, и в языке без «GIL» ты начнёшь считать сумму охуенного массива в четыре потока, то посчитаешь её в четыре (на самом деле меньше, но это не важно) раза быстрее, чем если бы считал одним. В «Python», запустив суммирование на четырёх потоках, никакого увеличения производительности ты не получишь.
guest8 13.12.2019 22:35 # −999
guest8 13.12.2019 23:17 # −999
guest8 13.12.2019 23:30 # −999
guestinxo 14.12.2019 00:39 # 0
guest8 14.12.2019 01:10 # −999
Stallman 14.12.2019 11:34 # 0
Konardinho 14.12.2019 14:13 # 0
gost 15.12.2019 17:16 # 0
guestinxo 13.12.2019 19:56 # +1
Desktop 14.12.2019 00:46 # 0
А ещё они любят сделать демо-проект, зипануть его и выложить с минимумом комментариев. Потому что время индусов из Купертино слишком дорого, чтобы тратить его на такую ерунду.
guest8 14.12.2019 01:10 # −999
1024-- 16.12.2019 11:50 # 0
> https://perldoc.perl.org/perlfunc.html#lock-THING
Какая-то каша из говна и мёда.
+ наборы функций объединены в списки
+ всё на одной странице, удобно искать
- недоструктурированная каша, сигнатуры не на первом месте
> https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessa
Более-менее адекватный вариант, но могло бы быть и лучше.
+ удобная иерархия слева
- сигнатура не на первом месте
> https://man.openbsd.org/pf.4
Адище, в котором ни черта не выцепишь, пока не прочитаешь от корки до корки.
- недоструктурированная каша
+ есть разделы и чётко видно, где какой ключ начинается/заканчивается
> https://developer.apple.com/documentation/uikit/uisplitviewcontroller
Недоструктурированная каша. Это класс, где тогда сука список полей и методов? Адище, в котором ни черта не выцепишь, пока не прочитаешь от корки до корки.
- длинная портянка, где поля и методы употребляются где-то между делом
+ в See Also есть какой-то логичный список (троллинг такой?)
> https://www.php.net/manual/en/function.vpopmail-add-domain.php
Более-менее адекватный вариант, но могло бы быть и лучше. Хотя, поудобней майкрософтовской.
+ сигнатура на первом месте
+ структурированная питушня
guest8 16.12.2019 14:30 # −999
Antifriz_otrabotanyi 17.12.2019 00:28 # +1
https://forth-standard.org/standard/core/DOES
Тут тебе и описание, и комментарии и примеры.
Stallman 13.12.2019 17:25 # 0
BECEHHEE_O6OCTPEHuE 13.12.2019 17:30 # −1
bootcamp_dropout 13.12.2019 15:36 # 0
gost 13.12.2019 15:43 # +1
bootcamp_dropout 13.12.2019 15:52 # 0
gost 13.12.2019 16:01 # +2
Возможно, ты путаешь слабую и динамическую типизации. Не путай.
bootcamp_dropout 13.12.2019 16:08 # 0
XYPO3BO3 13.12.2019 16:33 # 0
При динамической типизации хранится пара (тип, значение).
>> если в repl питона забить "1" + 1 будет ошибка рантайма а не компиляции
В принципе, конкретно в данном случае, когда выражение состоит из констант, могли бы реализовать и анализатор этапа компиляции. Почему не реализовали, вопрос отдельный.
В общем же случае, когда выражение из переменных, проверить сможем только в рантайме.
>> чем это лучше js в котором просто неявно реализованы методы приведения
Это позволяет ловить ошибки. Лучше явно указать, как я хочу преобразовать один тип в другой, чем гадать на кофейной гуще, что же получится.
Что мы хотим получить из "1" + 1: число, строку или что-то ещё? Плюс в данном случае означает сложение, конкатенацию или что-то ещё?
bootcamp_dropout 13.12.2019 16:49 # +1
guest8 13.12.2019 17:54 # −999
XYPO3BO3 13.12.2019 19:32 # +1
guest8 13.12.2019 19:33 # −999
XYPO3BO3 13.12.2019 19:55 # 0
guest8 13.12.2019 19:57 # −999
XYPO3BO3 13.12.2019 20:22 # 0
guest8 13.12.2019 20:24 # −999
1024-- 16.12.2019 11:59 # 0
Меня в немногословном питоне бесит, что вместо
или даже развёрнутого
надо писать
или
gost 16.12.2019 12:14 # 0
1024-- 16.12.2019 13:07 # 0
1024-- 16.12.2019 11:57 # 0
gost 13.12.2019 18:56 # +1
Пусть у нас есть какая-нибудь функция, например:
И вот какой-нибудь невнимательный программист допускает ошибку:
Он попросту забыл, что в форме хранятся ещё нераспарсенные данные в виде строк. В нормальных языках (с сильной типизацией) на этом месте программист получит ошибку сразу после запуска и пойдёт фиксить. В языках со слабой типизацией язык решит, что он умнее программиста, и выдаст какую-то поебень, которая ещё сто лет будет создавать непонятные глюки.
Собственно, то, что слабая типизация — говно, умные люди поняли уже давным-давно, и именно поэтому сделали «Typescript».
bootcamp_dropout 13.12.2019 19:09 # 0
Это важно, чтобы понимать что js отличается только механизмами приведения типов
>Он попросту забыл, что в форме хранятся ещё нераспарсенные данные в виде строк. В нормальных языках (с сильной типизацией) на этом месте программист получит ошибку сразу после запуска и пойдёт фиксить. В языках со слабой типизацией язык решит, что он умнее программиста, и выдаст какую-то поебень, которая ещё сто лет будет создавать непонятные глюки.
Этот пример абсолютно ничего не значит, потому что с таким же успехом можно придумать пример в котором это полезно. Падает или не падает программа - это абсолютно не важно с точки зрения требований к программе так как оба результата в сущности неверны
>Собственно, то, что слабая типизация — говно, умные люди поняли уже давным-давно, и именно поэтому сделали «Typescript».
Typescript - это статический анализатор, по сути. Его не остается после компиляции и проверку типов при компиляции можно нахуй отключить. Это другая парадигма относительно питона и других скриптовых языков
1024-- 16.12.2019 12:06 # −1
Иначе сильная типизация только уменьшает вероятность работы программы.
Без неё на сервер бы отправилось какое-то говно или клиету бы отобразилось какое-то говно. Пользователь увидел бы, что у него сняли 510 рублей вместо 16 и пожаловался бы в техподдержку. А так оно просто упадёт, пользователь подумает, что кнопка не реализована.
gost 16.12.2019 12:25 # 0
Однако лично я, например, предпочту, чтобы сбоящее приложение упало вместо отправки произвольной суммы куда-нибудь в Эфиопию. Потому что возврат денег — это адская ебля, как для клиента, так и для компании.
> А так оно просто упадёт, пользователь подумает, что кнопка не реализована.
Ну естественно, если писать в «JS-way», игнорируя любые ошибки. А нормальные люди™ в случае непредвиденных исключений извиняются перед Кадыровым пользователем и шлют краш-репорт.
1024-- 16.12.2019 13:11 # 0
Кстати, а как его правильно послать?
* Пользователь (а то и анонимус) может послать туда любую питушню и затроллить сервер
* Если разрешить отправлять только залогиненным, то мы никогда не получим сообщение о том, что пользователь не смог залогиниться из-за ошибки.
gost 16.12.2019 13:23 # 0
А от желающих посрать ничего не поможет, только бан.
BECEHHEE_O6OCTPEHuE 13.12.2019 17:31 # −1
Antifriz_otrabotanyi 13.12.2019 20:57 # −1
guest8 13.12.2019 17:09 # −999
bootcamp_dropout 13.12.2019 17:22 # 0
На этом слайде какой-то высер который никогда никому не помешает в работе, все "бытовые" приведения типов легко умещаются в мозгу любой веб-макаки. А уж если ты решил складывать массивы с объектами - будь добр почитать стандарт
guest8 13.12.2019 17:50 # −999
bootcamp_dropout 13.12.2019 18:00 # 0
Плюс не обязан быть везде коммутативен, если это не нарушает аксиоматики. Как понимаешь, аксиоматики арифметики массивов и объектов не существует
> Уверен, программист на PHP, Cobol или C++ точно так же скажет про любой изьян языка.
Я не согласен с тем что это изъян языка
> Кстати, что там с типом null? Уже исравили?
А что с ним?
guest8 13.12.2019 18:04 # −999
bootcamp_dropout 13.12.2019 18:15 # 0
Что значит "нормальная семантика"?
> Большинство людей привыкло к коммутативности операции сложения.
Еще раз: плюс не обязан быть коммутативен там где это не обозначено аксиоматикой. Я не понимаю к чему привыкли люди, которые вычитают строки из чисел
>С ним вот.
https://2ality.com/2013/10/typeof-null.html
guest8 13.12.2019 18:21 # −999
bootcamp_dropout 13.12.2019 18:28 # 0
Не математик, но вот векторное произведение некоммутативно. Примеров именно сложения не знаю.
>Ну вот я и попросил пример. Хочется узнать про такое множество, для элементов которого определена операция "+", и она не коммутативна.
https://en.wikipedia.org/wiki/Near-ring
Операция "+" определена и не обязана быть коммутативной
>Или теперь ты скажешь, что typeof не обязана быть обратной от instanceof ?
Я хочу сказать что typeof давно неофициально deprecated, была признана ошибкой и ее похоронили без почестей. В современном js это просто мозгоебалка для собеса
Добавлю что это значит что ты полностью прав и это говно, но это не должно быть единственной причиной для хейта js, особенно новых стандартов
guest8 13.12.2019 18:41 # −999
bootcamp_dropout 13.12.2019 18:47 # 0
Именно, у кольца коммутативен, у около-кольца - не обязательно
>чото не написано нигде такого. Откуда дровишки?
Ударение на слово неофициально. Это значит что сам создатель языка признал это говном и не рекомендует к использованию
> Но JS не консистентент
Жду еще примеров
guest8 13.12.2019 18:58 # −999
bootcamp_dropout 13.12.2019 19:17 # 0
>
>Из твиттера автора?
Нет, ты можешь продолжать писать typeof null и рассказывать всем какое js говно
>Двух недостаточно?
>что дает сложение пустых массивов, и какой пункт спеки про это говорит?
Я уже высказал свое мнение по поводу сложения и привел в пример near-rings, пожалуйста, не приводи эту хуйню в пример
Что дает [] + [] мне не очень интересно, думаю, что пустую строку
Это не является примером неконсистентности
guest8 13.12.2019 19:22 # −999
bootcamp_dropout 13.12.2019 19:33 # +1
Не пойми меня неправильно: эта хуйня работает, тебе никто не запрещает ей пользоваться. Я уже признал что это говно, это признал создатель языка и скорее всего на работе на тебя косо посмотрят или нахуй пошлют. Уверен, во многих языках есть такие же конструкции и решения, которые существуют но не очень приветствуются в кодовой базе
>В каких языках бывает ситуация, в которой опытный программист не может сказать, чему равно сложение двух встроенных типов?
Вот прикинь, js-программисты не сидят целый день и складывают массивы с массивами
>Почему, кстати?
По той же причине, что и "1" + 2 === "12" - интерпретирование плюса как конкатенации. Вангую что []-[] === 0 по той же причинеи аналогично числам и строкам. Консистентность!
guest8 14.12.2019 22:57 # −999
gost 13.12.2019 19:45 # +1
Я не джаваскриптер, но помню, что плюс сначала проверяет оба аргумента на число, потом пытается вызвать valueOf, потом — toString, и всё это переплетено и перемешано так, что хрен запомнишь. Собственно, чем дальше плюс заходит в своих эвристиках — тем неадекватнее получаются результаты, вплоть до преобразования обоих аргументов в строки и их последующей конкатенации.
UPD: Во, нашёл это говно: https://dmitripavlutin.com/javascriptss-addition-operator-demystified/. Какой пиздец )))
XYPO3BO3 13.12.2019 19:54 # 0
Details:
URL https://dmitripavlutin.com/javascriptss-addition-operator-demystified/
Domain dmitripavlutin.com
IP 142.93.108.123
Decision 2-6-27/ 2016-07-25-70-АИ made on 2016-07-25 by ФНС.
This block affects IP 142.93.108.123 and domain bkdostup.ru.
Decision 2-50 made on 2018-03-05 by суд.
This block affects IP 142.93.108.123, domain downloadfreegreen.bitballoon.com and URL http://downloadfreegreen.bitballoon.com/instrukciya-samus-725-g.html.
Decision 2-6-27/ 2016-01-31-6-АИ made on 2016-03-09 by ФНС.
This block affects IP 142.93.108.123, domain primedice.com and URL http://primedice.com.
Decision 2019-08-22-1780 made on 2019-08-28 by МВД.
This block affects IP 142.93.108.123 and domain rollsafe.org.
guest8 13.12.2019 19:55 # −999
gost 13.12.2019 19:17 # +1
Я могу привести пример неадекватной неконсистентности плюса:
Очевидно, что для консистентности в последнем примере результатом должно быть «"123456"»: сложение объектов намекает, что в «JS» операция «+» — это «преобразовать-в-строку-и-конкатенировать», в отличие от:
Кстати, без рофлов, а что вот это за хуйня?
bootcamp_dropout 13.12.2019 19:24 # +1
>Кстати, без рофлов, а что вот это за хуйня?
> {'a': 'b'} + {'c': 'd'}
Типы привелись к строке
> {'a': 'b'} + 'lol'
Выражение интерпретировалось как блок кода
> let hui = {'a': 'b'};
undefined
> hui + 'lol';
Типы привелись к строке
XYPO3BO3 13.12.2019 19:28 # +2
Унарный оператор перегружен: он может означать сложение (математическую операцию), а может означать и конкатенацию. Конкатенация строк — это не сложение, просто так совпало, что в JS для неё выбрали тот же знак, что и для сложения. Есть языки программирования, в которых конкатенацию обозначили другим знаком.
XYPO3BO3 13.12.2019 19:52 # 0
gost 13.12.2019 19:41 # +3
Лол. А это беда консоли, или в скрипте такой же багор будет?
> Еще раз: не существует никакой аксиоматики сложения хуя с жопой, с числами "+" работает нормально. То что поведение математических операций на каком-то говне отличается с вашими ожиданиями - это ваши проблемы.
«+» — это операция сложения. Складывая два объекта, любой нормальный человек (не писавший на «JS») ожидает, что два объекта сложатся. В «Python», например, если я к одному списку прибавлю второй, я получу адекватный и, главное, полезный результат. А вот в «JS» я получу хуйню, которая абсолютно бесполезна. Не существует реальных примеров кейсов, в которых такое идиотское поведение можно использовать.
Собственно, это и есть философия «JS»: в любой непонятной ситуации выдать программисту хоть какую-нибудь хуйню, пусть даже полностью бесполезную и неадекватную, вместо нормального сообщения о том, что получается хуйня. Именно поэтому я против «JS».
bootcamp_dropout 13.12.2019 19:52 # −1
Думаю, что да, в скрипте будет так же
>«+» — это операция сложения. Складывая два объекта, любой нормальный человек (не писавший на «JS») ожидает, что два объекта сложатся.
По-моему, вы там все ебанулись
>В «Python», например, если я к одному списку прибавлю второй, я получу адекватный и, главное, полезный результат
От этого само понятие "сложение списков" менее идиотским не становится
Вот, можешь использовать во всех кодовых базах
guest8 13.12.2019 19:54 # −999
bootcamp_dropout 13.12.2019 19:56 # 0
gost 13.12.2019 20:11 # +2
Ой, вот не надо формальную математику приплетать. В «JS» даже целые числа формально не соответствуют математике:
В отличие от «Python», где длинная арифметика искаропки.
guest8 13.12.2019 20:13 # −999
gost 13.12.2019 20:14 # 0
guest8 13.12.2019 20:17 # −999
1024-- 16.12.2019 12:22 # 0
Проблемы от этого только в случае с % и с пирформансом для менее продвинутых версий с интерпретацией вроде JScript (хотя, python всё равно больше тормозит), где добавляются лишние касты.
В остальном же одни плюсы вроде прозрачных опереций и отсутствия потери точности 32битных интов.
gost 16.12.2019 12:41 # 0
1024-- 16.12.2019 13:14 # 0
Ну вот возьмём, скажем, C/C++:
gost 16.12.2019 13:20 # 0
1024-- 16.12.2019 14:07 # 0
1 - это натуральное число
1 - это целое число
1 - это рациональное число
1 - это действительное число
1 - это комплексное число
1 - это гиперкомплексное число (...нион)
1 - это матрица размера 1*1
1 - это тензор размера 1*...*1
И при работе с числами выбирается наименьшее требуемое множество (примерно как работает умножение в numpy). Это удобно и убирает всякую питушню вроде явных кастов там, где прописаны математические правила.
Чуть менее, чем всегда пользователю нужно 1/2 = 0.5, и по идее нужны явные литералы челых чисел вместо говна вида 1/2 = 0.
1 = double
1.0 = double
1. = double
(int) 1 = int
1i = int
gost 16.12.2019 14:20 # 0
Потому что целочисленное деление aka div тоже нужно и полезно.
А с дефолтным даблом не соглашусь — это слишком неочевидное решение. Потому что для пользователя 1 — это в первую очередь целое число: точки-то нет.
1024-- 16.12.2019 14:38 # 0
Но в то же время 1/2 = 0.5.
Наименьшее требуемое множество
1 in N
-1 in Z
1/2 in Q
gost 16.12.2019 15:18 # 0
Целые числа удобны своей точностью и предсказуемостью: с поправкой на mod 2^N ты всегда можешь их точно складывать, вычитать, умножать и целочисленно делить, не беспокоясь, что в один прекрасный день у тебя внезапно исчезнет единица или чего покрупнее. А плавучка (в любом современном железе) — говно, использовать которое можно только от полной безысходности.
bootcamp_dropout 13.12.2019 20:23 # 0
guest8 13.12.2019 20:26 # −999
bootcamp_dropout 13.12.2019 20:36 # 0
В js нету типа "целое", и "литерала-целого" тоже нету
gost 13.12.2019 20:52 # 0
bootcamp_dropout 13.12.2019 20:59 # +1
gost 13.12.2019 21:09 # 0
bootcamp_dropout 13.12.2019 21:10 # 0
1024-- 16.12.2019 12:25 # 0
А длиннопитухи из пистона тормозят!
P.S. То ли дело Haskell. Int - как в программировании - быстр и короток, Integer - как в математике - длинен и медленен.
gost 16.12.2019 12:36 # 0
Но они есть!
XYPO3BO3 13.12.2019 19:58 # +1
bootcamp_dropout 13.12.2019 20:02 # 0
guest8 13.12.2019 20:03 # −999
bootcamp_dropout 13.12.2019 20:07 # 0
На работе только этим и занимаемся
guest8 13.12.2019 22:15 # −999
gost 13.12.2019 20:08 # +1
Ну тогда записывай в жсобагры.
> По-моему, вы там все ебанулись
А что для тебя неожиданного в том факте, что, складывая два объекта, нормальный человек ожидает получить их сумму, а не какую-то непонятную хуйню?
> От этого само понятие "сложение списков" менее идиотским не становится
С чего это оно «идиотское»? Такое поведение — полезное и удобное. Подойди к любому программисту (не писавшему на «JS», конечно) и спроси, что он ожидает получить в качестве результата выражения «[1, 2, 3] + [4, 5, 6]».
Хорошо, даже если ты считаешь, что это понятие идиотское — тогда почему «JS» возвращает абсолютно бесполезную хуйню, вместо внятного «HuinyaException('Bbl nblmaemecb cgeJlamb xyuHl0')»?
> [].__proto__.toString = () => {throw "go fuck yourself"}
Ну вот мы и начали фиксить баги жаваскрипта.
Но насколько я знаю, это всё уже есть в «Typescript».
bootcamp_dropout 13.12.2019 20:21 # −1
Это просто невалидный синтаксис. В других языках не существует невалидного синтаксиса?
>А что для тебя неожиданного в том факте, что, складывая два объекта, нормальный человек ожидает получить их сумму, а не какую-то непонятную хуйню?
Я не понимаю что такое "сумма двух объектов". Что такое сумма матриц - понимаю, что такое целое - тоже. Как сложить {"a": 1} и {"b": 2} и произвольные два объекта - не понимаю. Вы в своем питоне все подряд можете сложить что ли?
>С чего это оно «идиотское»? Такое поведение — полезное и удобное.
Это не отменяет того факта что это высосанная из пальца хуйня и не имеет каких-то принципиальных преимуществ над говноконкатенацией. Получается, единствоенное, что тебе не нравится - то что они разные?
> Хорошо, даже если ты считаешь, что это понятие идиотское — тогда почему «JS» возвращает абсолютно бесполезную хуйню, вместо внятного «HuinyaException('Bbl nblmaemecb cgeJlamb xyuHl0')»
Я не вижу разницы между ексепшеном и непонятной хуйней, для меня и то и другое - неправильное поведение
guest8 13.12.2019 20:23 # −999
bootcamp_dropout 13.12.2019 20:31 # 0
VM546:1 Uncaught SyntaxError: Unexpected token ':' как бы намекает
>Это два множества кортежей: {(a,1)} и {(b,2)}, в результате его сложения будет {(a,1), (b,2)}.
Это можно интерпретировать только как кортежи? Что если я хочу что-то другое? Что если я вообще не хочу их складывать?
>А про Fast Fail слышал?
Это одна из философий обработки ошибок. В js другая. Что в этом плохого?
gost 13.12.2019 20:51 # 0
То, что она — говно. «Философия обработки ошибок JS» ошибки не обрабатывает, а заметает под коврик — чтобы через пару лет об них кто-нибудь споткнулся и ёбнулся.
bootcamp_dropout 13.12.2019 20:58 # +1
js придумали для гостевух. На гостевухах такая политика оправдана
guest8 13.12.2019 21:00 # −999
3.14159265 16.12.2019 17:33 # 0
Ещё он дико удобен как браузерный калькулятор.
gost 13.12.2019 21:11 # 0
Ну вот и всё, с этим отступлением все противоречия разрешаются. Правда, остаются ещё сумасшедшие, которые пишут на «JS» проекты в сотни тысяч строк кода, но с ними уже должны врачи разбираться.
1024-- 16.12.2019 12:32 # 0
gost 16.12.2019 12:40 # 0
1024-- 16.12.2019 13:22 # 0
Только зачем-то полусохраняют обратную совместимость. Неясно, зачем в "JavaScript" и "C++"
* вводят новые фичи
* стараются поддерживать старое говно
* умудряются выпускать несовместимое говно со старыми версиями (например, убрали Function.prototype.caller)
* не вводят директивы явного отключения старого говна
В итоге язык с каждой новой версией начинает всё больше вонять, и на нём становится невозможно писать.
* Старый код больше не компилируется из-за мелких несовместимостей.
* Новый код использует новые фичи и хаки для обхода старых багов
Неясно, почему нельзя отключать говно директивами (вроде 'use strict') на постоянной основе
* Старый код продолжает работать без потери совместимости
* Новый код использует новый подход без старого говна
gost 16.12.2019 13:26 # 0
Видимо, боятся повторить эпический фейл питона.
> Неясно, почему нельзя отключать говно директивами (вроде 'use strict') на постоянной основе
Полагаю, что это будет слишком сложно для разработки: придётся по сути поддерживать два диалекта языка.
1024-- 16.12.2019 14:08 # 0
gost 16.12.2019 14:22 # 0
1024-- 16.12.2019 14:44 # 0
В итоге из-за выпиленного говна, которое слишком мешает одной группе экспертов языка, страдает 100500 групп с кодом, который его использует. И ещё 100500 групп, настрадавшихся от старого говна, не могут писать на нормальном языке.
Пусть лучше одна группа компиляторщиков пострадает за всех, но зато 100500 команд программистов будут спокойно работать.
gost 16.12.2019 15:12 # 0
Между поддержкой старого говна и выпиливанием старого говна нужен очень тонкий баланс. Уходим в одну сторону — получаем «WinAPI» с приветами из девяностых, уходим в другую — получаем «Python» и цирковое представление «переведи 100500 либ на третью версию».
1024-- 16.12.2019 15:42 # 0
Хотя бы 1% от них перевести в разработчики языка - и всё.
Тонкий баланс не нужен. Выпиливать старое просто нельзя, т.к. что-нибудь обязательно сломается.
gost 16.12.2019 16:13 # 0
Но в любом случае, даже если мы как-то ухитрились так сделать — всё равно в итоге получим десятки-сотни директив, что-то отключающих, включающих, меняющих, и каждое обновление языка 100500 программистов должны будут с ужасом во все свои проекты впиливать новые директивы, причём сначала им надо будет понять, какая из новых фич ломает проект.
Ещё остаются проблемы с API: к примеру, в одном из обновлений возьмут и выпилят из parseInt() второй аргумент. Получаем две версии стандартной библиотеки, между собой несовместимых. В следующем обновлении уберут тупую хуйню из forEach() — получаем три версии. Делаем оба изменения опциональными через директивы — получаем четыре версии. Обновляемся ещё пару раз — и выходим в окно, потому что поддерживать это будет попросту нереально.
1024-- 16.12.2019 17:15 # 0
Э, это не обратная совместимость.
Старый код должен работать как раньше, новый код должен использовать директивы для тех фич, которые ломают обратную совместимость.
В принципе, можно вообще ничего не менять по умолчанию, без директив не только не нарушать совместимость, но и новые фичи не включать. А дальше тупо в начале каждого файла будут писать что-то вида "use python 3.8".
Если получается кобенаторный рост, можно делать тупо директивы по версиям и генерацию адаптеров между версиями. Это максимум квадратичный рост. Но адаптеры можно писать только на одну версию назад, остальные генерировать и оптимизировать автоматически - линейный рост.
gost 16.12.2019 17:24 # 0
3.14159265 16.12.2019 17:03 # 0
Стал лучше js после всех их «улучшений»?
Сомневаюсь.
guest8 13.12.2019 20:58 # −999
bootcamp_dropout 13.12.2019 21:06 # +1
Там где надежность чуть поменьше, но важна, это все тестируют до дыр и в тестировании действительно fail fast полезен
Там где js там обычно принципиально важной логики нет и я могу себе позволить отнять строку от строки потому что так быстрее чем лишние плюсы или конструкторы number писать
Наконец, это нечестно противопоставлять fail fast подходу js аргументируя "порчей данных"
Порча данных происходит много где и зачастую от ошибок логики программы а не какой-то js хуйни
guest8 13.12.2019 21:20 # −999
bootcamp_dropout 13.12.2019 21:23 # +1
Именно поэтому я как js разработчик храню деньги наличкой под подушкой
Там js точно до них не доберется
1024-- 16.12.2019 12:35 # 0
Где-то недавно читал, что когда у банков и ЖКХ-контор херится база, помогает чемодан с квитанциями.
bormand 16.12.2019 14:30 # +1
Которые выцветают за пару месяцев.
1024-- 16.12.2019 14:47 # 0
gost 13.12.2019 20:48 # +1
Всё, нашёл доку 2, можешь убирать из багров.
> Как сложить {"a": 1} и {"b": 2} и произвольные два объекта - не понимаю.
И я тоже не понимаю. Но именно для этого и нужна консистентность: для тех объектов, для которых понятие суммы определено (математически или соображениями удобства), операция сложения должна возвращать их сумму. Для тех же, к которым такое понятие неприменимо, сама операция должна быть невалидна. В «Python» всё именно так.
> Это не отменяет того факта что это высосанная из пальца хуйня
Для тебя объединение списков — высосанная из пальца хуйня? А зачем тогда нужен «Array.prototype.concat»? Или ты считаешь, что «[1, 2, 3].concat([4, 5, 6])» выглядит проще, чем «[1, 2, 3] + [4, 5, 6]»?
> Я не вижу разницы между ексепшеном и непонятной хуйней, для меня и то и другое - неправильное поведение
Только эксепшон ты получишь сразу же, как только нажмёшь F5 (или что там жаваскриптеры жмут для деплоя). А непонятная хуйня может годами сидеть в системе, по-тихому портя данные клиентов.
bootcamp_dropout 13.12.2019 20:57 # 0
>Для тебя объединение списков — высосанная из пальца хуйня? А зачем тогда нужен «Array.prototype.concat»? Или ты считаешь, что «[1, 2, 3].concat([4, 5, 6])» выглядит проще, чем «[1, 2, 3] + [4, 5, 6]»?
Вот я например хочу чтобы «[1, 2, 3] + [4, 5, 6]» было операцией сложения векторов. Что, это менее удобно? Менее логично? Менее что? С этой точки зрения, какое мне дело, вернет ли мне конкатенацию или какое-то говно?
>Только эксепшон ты получишь сразу же, как только нажмёшь F5 (или что там жаваскриптеры жмут для деплоя). А непонятная хуйня может годами сидеть в системе, по-тихому портя данные клиентов.
Это не говно, это просто другая модель
gost 13.12.2019 21:15 # 0
Да, ожидать от операции сложения списков поведения операции сложения векторов — это нелогично. Если нужно складывать вектора — складывай вектора:
> С этой точки зрения, какое мне дело, вернет ли мне конкатенацию или какое-то говно?
> Это не говно, это просто другая модель
Мы сошлись на том, что в языке для написания гостевух такая модель действительно может быть полезна.
bootcamp_dropout 13.12.2019 21:20 # 0
Как будто что-то плохое
1024-- 16.12.2019 12:41 # 0
Ну ведь правда же не самое удобное решение. Сложение значение разных типов и чёткие правила автоматических преобразований типов - отличная фича, что бы там ни говорили сильнопитуизоиды. Но можно было бы выбрать значение для возврата и получше.
gost 16.12.2019 12:46 # +1
«undefined», например.
Кстати, мне оправдания в стиле «так написано в Книге» до боли напоминают беседы с крестовиками, которым показывают UB. Мол, сам дурак, что произвольные два инта складываешь, надо Стандарт читать!
Но, справедливости ради, если UB в си/крестах всё таки нужны для оптимизаций, то вот эти вот [1,2]+[3,4]=="1,23,4" — просто непродуманное говно.
1024-- 16.12.2019 13:26 # 0
Кстати и директивах. Почему бы не сделать safe-версию C/C++ с директивой 'use safe', где все UB заменили на какое-то логичное поведение, когда код либо как-то предсказуемо и медленно работает, либо вовсе не компилируется, если вместо UB нужно сгенерировать слишком сложный код (набор ситуаций описан в стандарте, либо включается флагами вида -Eall -Epedantic)?
На C/C++ пишут не только цари, которые каждое правило прочитали.
gost 16.12.2019 13:31 # 0
1024-- 16.12.2019 14:21 # 0
C++ - язык высокого уровня общего назначения. Тут можно выбирать высокоуроневые "медленные" виртуальные методы или использовать невиртуальное быстроговно уровнем пониже.
Зачем использовать Java/C# с друним синтаксисом, встроенной виртуальной машиной, автоматически инстанцированными шаблонами вместо C++, если дело касается какой-то мелочи - такой же язык, только с перламутровыми пуговицами?
У нас не хватает конструкторов. Так же и с техникой: либо ты выбираешь телефон с NFC и плохой прошивкой камеры, либо без NFC с хорошей прошивкой камеры, либо с плохим GPS модулем и кнопками, либо с хорошим GPS модулем и без кнопок, и нельзя взять сразу со всем хорошим потому, что каждый производитель делает свои велосипеды, продвигает отдельные фичи и не может сделать всё и сразу хорошо. В случае с языками нет такой явной прибыли при переманимании всех на свой язык, можно объединиться и внести разные фичи и модульную сборку в один язык или в одну платформу (как F#, C#, JScript.NET в .NET).
guest8 16.12.2019 14:25 # −999
gost 16.12.2019 14:53 # 0
(Страуструп)
Насчёт высокоуровневости — спорный вопрос. Собственно, чёткого определения «уровневости» языка пока ещё не придумали и, боюсь, не придумают.
> Зачем использовать Java/C# с друним синтаксисом, встроенной виртуальной машиной, автоматически инстанцированными шаблонами вместо C++, если дело касается какой-то мелочи - такой же язык, только с перламутровыми пуговицами?
Какой мелочи? C++ изначально спроектирован с оглядкой на оптимизацию посредством UB (вернее, посредством предположения того, что UB в программе не будет). Убираем из него UB — получаем тормозящее говно (причём последнее — вовсе не от убирания UB). А зачем писать на тормозящем говне, если можно выбрать тормозящее не-говно: хоть «C#», хоть «Python», хоть «JavaScript»?
И нет, я ни в коем разе не оправдываю UB: это, конечно, говно. Но это говно приходится кушать за то, что конпелятор делает хелловорлды на крестах быстрыми.
Честно говоря, не понял концепцию языков-конструкторов. Вот, например, я хочу компиляцию в мышиные коды (чтоб быстро!), Вася хочет собрать прогу в бандл once и run её everywhere, а Пете надо хуярить скрипты под Unity. И что с этим делать — пилить по бэкенду на каждый возможный случай?
1024-- 16.12.2019 15:37 # 0
Почему бы и нет? Компиляторщики напилили 10 бэкэндов -
* 100000 проектов сэкономили на специалистах в других языках,
* 100000 проектов получили возможность перекомпилировать мышиные коды в run everywhere, когда мощности компьютеров повысились, а количество клиентов с устройствами нового типа увеличилось. Вкинуть 10000000 в разработку одного инструмента - дешевле, чем вкидывать 10000000000 в зарплаты программистов в 100000 проектах.
> получаем тормозящее говно
Ну и ладно.
> тормозящее не-говно
Надо учить. А если выучил тормозящее не-говно, но хочешь написать царский код, придётся заметно переучиваться. А так - включил компилятор в один режим - и он скомпилирует логичный, но медленный код; переключил в другой - и будут ошибки компиляции, исправив которые, можно получить быстрый код.
gost 16.12.2019 15:58 # +1
> переключил в другой - и будут ошибки компиляции, исправив которые, можно получить быстрый код.
Дык в том-то и дело, что отлавливать и выдавать по ошибке на все UB попросту нереально. Вот есть у нас какое-нибудь
— в крестах с запрещённым UB оно компилироваться не будет (это, кстати, одно из самых ебанутых UB).
Или вот так:
— тоже аж четыре потенциальных UB.
Любое обращение к укококозателю — парочка UB, любая операция с интом — UB, ссылка — UB, родился — UB, живёшь — UB, умер — UB.
По сути, компилятор с UB и компилятор без UB — это два совершенно разных продукта, пересекаться у них будут только парсеры. Впиливать функциональность одного во второй — только плодить баги и тратить ресурсы на поддержку. Разрабатывать отдельно — никому не нужно (кому нужен язык без UB — просто пишут на джавах).
1024-- 16.12.2019 17:22 # 0
gost 16.12.2019 17:31 # 0
Самый главный багор — это UB в переполнении интов. Чтобы от него избавиться — придётся каждую операцию с интами аккуратно заворачивать в обёрточки. Даже конпелятор с отсутствием оптимизаций на основе UB будет не так сильно тормозить.
1024-- 16.12.2019 17:48 # 0
3.14159265 16.12.2019 17:54 # +1
Так уже есть WebAssembly и Emscripten.
Я давно говорил что js нужно не расширять всякой сахарозной питушней, но наоборот сужать.
Мне в asm.js нравится как они не никак не меняя язык фактически завезли в него явные 32-битные intы.
А вместо нечитаемого байт-кода как у CLR или JVM получился няшный js.
bootcamp_dropout 16.12.2019 15:37 # 0
Серьезно, вы топите за эту хуйню только потому что где-то еще ее увидали. Она не имеет смысла сама по себе
1024-- 16.12.2019 15:51 # 0
Типа как умножению чисел обучили в школе, но если бы не обучили, оно бы не имело смысла, и можно было бы жить без него?
Ну или компьютеры. Увидали их люди и начали использовать, а сама по себе фигня "компьютер" не нужна, без неё жили 100500 лет?
Ничего само по себе не нужно, можно жить в мировом океане на этапе одноклеточных.
Как работает естественный отбор решений? Человек видит несколько вариантов решения проблемы и выбирает наиболее удобный. Когда появляется новый вариант, процесс выбора повторяется. Если человек ранее нигде не увидал новое решение, он его и и не выберет.
Чем [1,2,3] + [4,5,6] == '1,2,3,4,5,6' удобнее [1,2,3] + [4,5,6] == [1,2,3,4,5,6], если рассматривать потребности для средней программы?
Лично мне первый вариант пригождался чуть менее, чем никогда, а вот конкатенацию я регулярно использую.
bootcamp_dropout 16.12.2019 16:00 # 0
Непонятно, какое отношение это имеет к теме разговора
>Чем [1,2,3] + [4,5,6] == '1,2,3,4,5,6' удобнее [1,2,3] + [4,5,6] == [1,2,3,4,5,6], если рассматривать потребности для средней программы?
Тем что, перефразируя Линуса Торвальдса, это мотивирует людей никогда и нигде не пользоваться этим говном.
Этот вопрос принципиален для js. Такое поведение допустимо для питона где можно переопределить оператор, затем привести новый тип и переопределить оператор для него. В случае невозможности переопределения операторов если "+" для структуры, которая задается списком, однозначно определить нельзя(я уже привел в пример что это можно считать векторной суммой), то намного лучше иметь совсем неиспользуемый результат и не поощрять чужеродные для языка практики
gost 16.12.2019 16:25 # +3
Кстати, а почему тогда «+» для строк их конкатенирует? Может, я хочу получить строку, в которой каждый символ — это сумма чаркодов соответствующих символов из исходных строк? Неоднозначность! Чужеродная практика!
А почему «*» работает не в кольце вычетов по модулю 42? Хочу кольцо вычетов! Неоднозначность! Чужеродная практика! Запретить!
А почему Array.prototype.concat() создаёт новый массив, вместо in-place конкатенирования? Хочу инплейс! Чужеродно!
В общем, такая логика крайне ущербна и глупа.
bootcamp_dropout 16.12.2019 16:32 # 0
>Кстати, а почему тогда «+» для строк их конкатенирует? Может, я хочу получить строку, в которой каждый символ — это сумма чаркодов соответствующих символов из исходных строк? Неоднозначность! Чужеродная практика!
Совершенно верно. Для строк есть String.prototype.concat. Думаю, это просто издержка дизайна или фича для "фанатов удобства"
>А почему «*» работает не в кольце вычетов по модулю 42? Хочу кольцо вычетов! Неоднозначность! Чужеродная практика! Запретить!
>А почему Array.prototype.concat() создаёт новый массив, вместо in-place конкатенирования? Хочу инплейс! Чужеродно!
Да-да, очень интересно
gost 16.12.2019 16:42 # +1
Что мешало её определить?
> Никто не думал специально "а давайте строки конкатенируем"
Да-да, и именно поэтому «+» в жаваскрипте приводит оба аргумента к строкам и конкатенирует их. Ну, просто случайно так получилось.
> В таком контексте любые разговоры о пользе или логике лишены основания
Аргументируй, раз уж хочешь дискуссии.
Если какая-то часть языка бесполезна — значит, она лишняя. Следовательно, её необходимо либо сделать полезной ([1,2,3,4,5,6]), либо явно убрать (undefined/TypeError).
bootcamp_dropout 16.12.2019 18:06 # 0
Отсутствие понятие "перегрузка оператора"
>Да-да, и именно поэтому «+» в жаваскрипте приводит оба аргумента к строкам и конкатенирует их. Ну, просто случайно так получилось.
Именно так. Операция приведения типа и конкатенация - отдельны, зоть и выполняются неявно
>Аргументируй, раз уж хочешь дискуссии.
>Если какая-то часть языка бесполезна — значит, она лишняя. Следовательно, её необходимо либо сделать полезной ([1,2,3,4,5,6]), либо явно убрать (undefined/TypeError).
Сложение массивов - это не часть языка по причине невозможности переопределить операторы
1024-- 16.12.2019 18:14 # 0
Как пользовательская перегрузка операторов связана с поведением оператора по умолчанию?
Почему тогда 1+2 == 3 в жс, если перегрузки + для интов там нет?
bootcamp_dropout 16.12.2019 18:21 # 0
Array - не встроенный тип js, а потомок Object. В js невозможно определить оператор "+" для произвольного потомка встроенного типа. Рассказывать как охуенно можно определить "+" для Object надеюсь никто не хочет
3.14159265 16.12.2019 18:24 # +1
>для произвольного потомка встроенного типа
Прототипы, не?
1024-- 16.12.2019 18:31 # 0
Почему тогда String([1,2,3]) === '1,2,3', а не '[object Object]'?
Array - не какой-то пользовательский тип, а встроенный в язык тип! Поведение для него может быть прописано отдельно без упоминания хуерархий классов. Более того, для того, чтобы он не тормозил, в обход абстракций жс ключи массива должны физически быть интами.
bootcamp_dropout 16.12.2019 18:36 # 0
Потому что toString и valueOf это методы, которые можно переопредеелить, как и конструктор string
>Array - не какой-то пользовательский тип, а встроенный в язык тип!
Это неправда
>Поведение для него может быть прописано отдельно без упоминания хуерархий классов.
Как и для любого класса - наследника. в с# тоже все объекты - наследники object, но их поведение можно спокойно переопределить
>Более того, для того, чтобы он не тормозил, в обход абстракций жс ключи массива должны физически быть интами.
Детали реализации не имеют отношения к теме разговора.
1024-- 16.12.2019 18:56 # 0
>Это неправда
22.1 Array Objects
Array objects are exotic objects that give special treatment to a certain class of property names. See 9.4.2 for a definition
of this special treatment.
> Как и для любого класса - наследника. в с# тоже все объекты - наследники object, но их поведение можно спокойно переопределить
Так мы об этом и говорили: поведение + для массивов можно было спокойно переопределить.
bootcamp_dropout 16.12.2019 19:02 # 0
of this special treatment.
Я не понимаю какое отношение это имеет к тому, что Array - это не встроенный тип, а наследник Object
>Так мы об этом и говорили: поведение + для массивов можно было спокойно переопределить.
Нет, нельзя было. В с# есть перегрузка операторов, в js - нет
gost 16.12.2019 19:04 # +1
bootcamp_dropout 16.12.2019 19:07 # 0
gost 16.12.2019 19:15 # +1
1024-- 16.12.2019 19:17 # 0
Класс Array встроен в язык.
Не важно, он там проходит как наследник Object, или объявлен ещё одним "типом".
Ещё раз спрашиваю, причём здесь пользовательская перегрузка операторов? Чтобы определить поведение оператора для любых двух типов, отдельно упомянутых в стандарте, не нужно разрешать пользователю перегружать его. Для этого нужно определить определение оператора в стандарте языка для нужных типов.
bootcamp_dropout 16.12.2019 19:24 # 0
Класс Array встроен в язык.
Не важно, он там проходит как наследник Object, или объявлен ещё одним "типом".
От этого он отдельным типом не становится.
>Чтобы определить поведение оператора для любых двух типов, не нужно разрешать пользователю перегружать его.
Конкретно для Array - нужно, так как это не тип
В общем случае - можно что угодно со стандартом сделать, непонятно правда, зачем
gost 16.12.2019 19:33 # +1
Не нужно, это даже я могу сделать. Берём параграф 12.8.3.1 и изменяем его (я его изменил, не надо этого искать в Стандарте!) вот таким образом:
Вуаля, теперь [1, 2, 3] + [4, 5, 6] == [1, 2, 3, 4, 5, 6].
bootcamp_dropout 16.12.2019 19:36 # 0
gost 16.12.2019 19:44 # +2
bootcamp_dropout 16.12.2019 19:50 # 0
gost 16.12.2019 19:55 # +2
gost 16.12.2019 18:34 # +1
Правда?
bootcamp_dropout 16.12.2019 18:38 # 0
gost 16.12.2019 18:57 # +1
bootcamp_dropout 16.12.2019 19:05 # 0
gost 16.12.2019 19:14 # +1
Создал, проверил.
bootcamp_dropout 16.12.2019 19:17 # 0
3.14159265 16.12.2019 18:18 # +1
В js есть "перегрузка операторов".
Допустим унарный плюс переопределяется на раз.
gost 16.12.2019 18:22 # +1
Что мешало его определить?
> Именно так. Операция приведения типа и конкатенация - отдельны, зоть и выполняются неявно
>> Никто не думал специально "а давайте строки конкатенируем".
Это предложение неверное. Эйх специально подумал о конкатенации строк. Операция «+» специально кастует оба аргумента в строку, а потом конкатенирует их. Это продуманная часть языка. И она — говно.
> Сложение массивов - это не часть языка по причине невозможности переопределить операторы
Мы обсуждаем дизайн языка, а именно то, что поведение плюса в JS — говно. Даже если Эйх не осилил перегрузку операторов, заставлять плюс приводить произвольные аргументы к строкам и конкатенировать их — идея откровенно идиотская, поскольку не приносит ровным счётом ничего полезного. Куда более адекватным поведением был бы возврат «undefined» для любых типов, для которых сложение не (может быть) определено.
1024-- 16.12.2019 17:44 # 0
Плохие практики прикрывают исключениями или объявляют UB.
Сделан плюс из желания помочь разработчику. Аналогично с '2'-1, чтобы программисту легче было взять число из формочки и применить к нему формулу. Просто не был продуман.
Есть в жс вещи вроде прототипов, которые сообщество оопитушков не понимает, есть двоякие '1'+1, которые иногда помогают, а иногда мешают, но питушня вроде []+[] - бесполезная с 99.999% случаях хрень, для которой в жизни есть альтернативы. Даже если бы было Object.prototype.toString = JSON.stringify;, уже плюс стал бы более полезным.
bootcamp_dropout 16.12.2019 17:58 # 0
линк на параграф стандарта?
>Сделан плюс из желания помочь разработчику. Аналогично с '2'-1, чтобы программисту легче было взять число из формочки и применить к нему формулу. Просто не был продуман.
Это неправда. Во всех этих примерах первым и ключевым являются механики приведения типа. Приведение строки к числу и непосредственное вычитание - это разные операции которые необязательно были продуманы для работы вместе
>Есть в жс вещи вроде прототипов, которые сообщество оопитушков не понимает, есть двоякие '1'+1, которые иногда помогают, а иногда мешают, но питушня вроде []+[] - бесполезная с 99.999% случаях хрень, для которой в жизни есть альтернативы. Даже если бы было Object.prototype.toString = JSON.stringify;, уже плюс стал бы более полезным.
Не лепи вместе toString и "+"
1024-- 16.12.2019 18:24 # +1
12.8.3.1 Runtime Semantics: Evaluation
и далее по ссылкам
> Во всех этих примерах первым и ключевым являются механики приведения типа. Приведение строки к числу и непосредственное вычитание - это разные операции которые необязательно были продуманы для работы вместе
Для строк и чисел были продуманы, для массивов - не очень
> Не лепи вместе toString и "+"
Шта? В языке они уже слеплены.
bootcamp_dropout 16.12.2019 18:31 # 0
>12.8.3.1 Runtime Semantics: Evaluation
>и далее по ссылкам
В параграфе не определена операция "+" для массивов
>Для строк и чисел были продуманы, для массивов - не очень
Это правда, но утверждение ни имеет никакого смысла
>Шта? В языке они уже слеплены.
Это тоже неправда. Приведение типов используется много где, "+" как бинарный оператор определен только для строк и чисел
gost 16.12.2019 18:36 # +1
В параграфе определена операция «+» для любых типов. Включая массив.
bootcamp_dropout 16.12.2019 18:39 # −1
Это неправда. Параграф определяет механику приведения типов для дальнейшего сложения. Ничего о самой механике сложения не говорится
gost 16.12.2019 18:42 # +1
> Return the string-concatenation of lstr and rstr.
> Return the result of applying the addition operation to lnum and rnum.
Это я специально выделил. Или «возвратить результат конкатенации строк lstr и rstr» — это не «механика сложения»?
bootcamp_dropout 16.12.2019 18:49 # −1
Да, все верно. Для примера, механика операции сложения определена в параграфе 12.8.5, механика конкатенации в стандарте не приведена. То что ты процитировал это все еще механика приведения типов
gost 16.12.2019 18:53 # +1
Правда штоле?
6.1.4
> То что ты процитировал это все еще механика приведения типов
Заканчивай толстить, это уже слишком жирно.
bootcamp_dropout 16.12.2019 19:00 # 0
>Заканчивай толстить, это уже слишком жирно.
Напомню, что ты пытался мне набросить instanceof конструктора, так что уж точно не тебе меня учить как трактовать стандарт моего основного рабочего языка
gost 16.12.2019 19:04 # +1
bootcamp_dropout 16.12.2019 19:06 # 0
1024-- 16.12.2019 19:12 # +1
3.14159265 16.12.2019 17:00 # 0
Правильный вопрос.
Какая-то неправильная метаматика.
3.14159265 16.12.2019 18:21 # +1
В js тоже можно переопределить оператор.
Array.prototype.toString = function(){return "123"}
bootcamp_dropout 16.12.2019 18:24 # 0
3.14159265 16.12.2019 18:30 # +1
bootcamp_dropout 16.12.2019 18:33 # 0
3.14159265 16.12.2019 18:52 # +1
>Его переопределить нельзя.
>Переопределение valueOf - это просто трюк, который к оператору не имеет никакого отношения
Н-н-нооо как же тогда изменяется результат его выполнения?
Если «не имеет никакого отношения».
Разве это не есть искомое Переопределение?
bootcamp_dropout 16.12.2019 18:55 # 0
1024-- 16.12.2019 19:02 # +1
bootcamp_dropout 16.12.2019 19:09 # 0
1024-- 16.12.2019 19:12 # 0
bootcamp_dropout 16.12.2019 19:16 # 0
gost 16.12.2019 19:18 # +1
Во-вторых, определить сложение можно для чего угодно: достаточно написать в стандарте строчку «для объектов типа huj операция + возвращает объект типа cock».
bootcamp_dropout 16.12.2019 19:27 # 0
Пункт 6.1 стандарта
>Во-вторых, определить сложение можно для чего угодно: достаточно написать в стандарте строчку «для объектов типа huj операция + возвращает объект типа cock».
Конечно можно. Только нахуя раздувать стандарт?
1024-- 16.12.2019 19:29 # 0
> Of the objects defined in this specification only Date objects (see 20.3.4.45) and Symbol objects (see 19.4.3.5) over-ride the default ToPrimitive behaviour. Date objects treat no hint as if the hint were String.
Date тоже не входит в святое множество типов из 6.1, но реализует кастомную питушню для ToPrimitive без какого-либо использования возможности задания этой кастомной питушни пользователем.
bootcamp_dropout 16.12.2019 19:30 # 0
1024-- 16.12.2019 19:36 # 0
bootcamp_dropout 16.12.2019 19:41 # 0
1024-- 16.12.2019 19:51 # 0
1. только метод, который используется внутри стандартной реализации ToPrimitive (сам ToPrimitive не меняется) и
2. результат ToPrimitive для не-объектов не может поменяться при определении, скажем, Number.prototype[Symbol.toPrimitive].
То есть пользователю ToPrimitive перегружать нельзя, а для Date смогли описать реализацию. С операторами то же самое. Пользователю явно перегружать не дают, есть возможность повлиять, авторы стандарта могут вписать кастомизацию для каких-угодно случаев.
bootcamp_dropout 16.12.2019 19:57 # 0
"However, objects may over-ride this behaviour by defining a @@toPrimitive method."
Пользователю можно перегрузить ToPrimitive
1024-- 16.12.2019 20:03 # 0
> 6.1.5.1 Well-Known Symbols
> @@toPrimitive "Symbol.toPrimitive" A method that converts an object to a corresponding primitive value. Called by the ToPrimitive abstract operation
А в той сноске вообще написано, что определение @@toPrimitive может переопределить поведение "хинт - это число":
> When ToPrimitive is called with no hint, then it generally behaves as if the hint were Number. However, objects may over-ride this behaviour by defining a @@toPrimitive method.
@@toPrimitive - метод, ToPrimitive - абстрактная операция.
ToPrimitive вызывает @@toPrimitive, алгоритм ToPrimitive не меняется.
bootcamp_dropout 16.12.2019 20:05 # 0
1024-- 16.12.2019 20:09 # 0
> When ToPrimitive is called with no hint, then it generally behaves as if the hint were Number. However, objects may over-ride this behaviour by defining a @@toPrimitive method. Of the objects defined in this specification only Date objects (see 20.3.4.45) and Symbol objects (see 19.4.3.5) over-ride the default ToPrimitive behaviour. Date objects treat no hint as if the hint were String.
В том же куске текста, который мы тут рассасываем, пишут, что они поведение самой ToPrimitive изменяют.
bootcamp_dropout 16.12.2019 20:11 # 0
1024-- 16.12.2019 20:05 # 0
1. что valueOf, что @@toPrimitive работает только для Object
2. что определение valueOf, что @@toPrimitive влияет на выполнение какой-то другой операции.
1024-- 16.12.2019 19:33 # 0
Кстати, я бы заодно туда сравнение для Date ввёл.
bootcamp_dropout 16.12.2019 19:40 # 0
>Кстати, я бы заодно туда сравнение для Date ввёл.
Оно же и так реализовано за счет приведения к unix timestamp
А вообще я за momentjs
1024-- 16.12.2019 19:53 # +1
Частично.
Если сравнивать через <, <=, >=, >, работает каст в число и unix timestamp.
Если сравнивать через ==, !=, работает поведение ==, != для Object со сравнением по ссылке, которое выдаст falsee у двух разных объектов с одинаковым unix timestamp.
gost 16.12.2019 19:43 # +1
Принимается.
> Конечно можно. Только нахуя раздувать стандарт?
А нахуя в стандарте такая неадекватная процедура сложения? Её можно переписать так, чтобы она, во-первых, была существенно короче и проще, а во-вторых — более адекватной. Как-нибудь вот так:
bootcamp_dropout 16.12.2019 19:46 # 0
Я согласен с тем что это хуйня. Но изменить что-то уже вряд ли можно из-за обратной совместимости
gost 16.12.2019 19:52 # 0
1024-- 16.12.2019 19:55 # +1
можно сделать 'use stricter'
ещё останется 'use strictest' для случая, если 'use stricter' не всё говно запретит
gost 16.12.2019 19:57 # 0
bootcamp_dropout 16.12.2019 19:58 # 0
gost 16.12.2019 19:59 # 0
Stallman 16.12.2019 20:00 # +1
gost 16.12.2019 20:01 # 0
1024-- 16.12.2019 19:19 # 0
Почему вдруг невозможно описать в стандарте поведение сложения для массива? Религия не позволяет?
bootcamp_dropout 16.12.2019 19:25 # 0
>Почему вдруг невозможно описать в стандарте поведение сложения для массива? Религия не позволяет?
Именно так. Лично я считаю что нахуй не надо
gost 16.12.2019 19:15 # 0
3.14159265 16.12.2019 18:47 # 0
Вот только надо трогать святой void грязными лапами.
Это практически единственная инвариантная вещь жса.
Которая спасает от
var undefined=42;
bootcamp_dropout 16.12.2019 18:50 # 0
gost 16.12.2019 16:14 # +1
fixed.
1024-- 16.12.2019 12:37 # 0
> А непонятная хуйня может годами сидеть в системе, по-тихому портя данные клиентов.
Сразу же, как только нажмёшь F5 и воспроизведёшь хитрожопую ситуацию, в которой возникает исключение.
1024-- 16.12.2019 12:19 # 0
Как-то раз Пи уже показывал, что JS прекрасен как конструктор языков.
Осталось только написать фреймворки высокого уровня, которые перехреначивают прототипы и делают для JS поведение
* со строгой питуизацией как в python
* со слабой типизацией и полезными результатами как в python
* с кучей математических фич как в Matlab
1024-- 16.12.2019 12:17 # 0
+1
Ну разве что для редких тестов использовать.
Her 13.12.2019 19:28 # +1
1024-- 16.12.2019 12:12 # 0
Э, "обратная операция" - это совсем другое. Корень и степень - взаимно обратные операции на R+. А typeof и instanceof - как sin и cos - две стороны одной медали.
Однако, typeof null === 'object' - старое говно, которое давно пора было бы убрать хотя бы в strict mode.
bormand 16.12.2019 14:31 # +1
guest8 16.12.2019 14:35 # −999
bormand 16.12.2019 14:35 # 0
guest8 16.12.2019 14:34 # −999
1024-- 16.12.2019 14:57 # 0
Вот Борманд более логичное написал про new.
> ты скажешь, что typeof не обязана быть обратной от instanceof
Даже если считать, что 'number' === Number. Или вовсе считать, что Number === 1 === 2 === ...,
Где хоть что-то намекающее на обратность?
gost 16.12.2019 15:19 # 0
bootcamp_dropout 16.12.2019 15:28 # +1
1024-- 16.12.2019 12:09 # 0
Неождианное поведение это всегда изьян.
3.14159265 13.12.2019 15:39 # +4
На самом деле этого точно не знает никто.
OlegUP 13.12.2019 16:26 # 0
XYPO3BO3 13.12.2019 16:34 # +3
OlegUP 13.12.2019 17:35 # 0
zhigolo 13.12.2019 17:36 # 0
gost 13.12.2019 18:46 # +2
3.14159265 13.12.2019 20:58 # 0
XYPO3BO3 13.12.2019 19:50 # +1
Допуск должен быть пропорционален абсолютному значению аргумента. Только какого: большего или меньшего или их среднему значению?
Когда аргумент близок к нулю, дальше уменьшать допуск дальше мы не можем, иначе можем получить неадекватный результат. Значит, нужно ограничить минимальное значение допуска.
На следующем шаге получим что-то типа такого:
Ничего не забыл или алгоритм нужно ещё доработать?
3.14159265 13.12.2019 21:49 # +2
Я бы этой антицарской и тормозной хуйнёй не занимался.
А просто бы вычел их как целые и наложил бы маску на нижние биты.
Фууууу. Ну питушня же анскилозная. Какое УМНОЖЕНИЕ )))
Выделенные жырным нули и есть ворецируемый эпсилон.
XYPO3BO3 13.12.2019 21:55 # 0
Если они разные, придётся мантиссу одного из чисел сдвигать.
3.14159265 13.12.2019 21:57 # +1
Если числа отличаются НА ПОРЯДОК, то эпсилон уже не нужен.
>Если они разные
То и числа разные :)
Рабоать она не будет работать с числами разного знака около нуля и NaNaми.
Но это легко поправить 2-3 доп. условиями
XYPO3BO3 13.12.2019 22:05 # 0
Такой же пример можно придумать и для двоичных порядков.
3.14159265 13.12.2019 22:10 # 0
Вычитание вынесет 1 бит разницы в порядках в младшие разряды.
А там её схавает битовая маска.
В противном случае разница между числами слишком велика.
guest8 13.12.2019 22:11 # −999
3.14159265 13.12.2019 22:12 # −1
guest8 13.12.2019 22:13 # −999
3.14159265 13.12.2019 22:14 # 0
#скрыльник, #напитуль, #хрюльни, #вроверь
guest8 13.12.2019 22:16 # −999
3.14159265 13.12.2019 22:18 # 0
guest8 13.12.2019 22:16 # −999
gostinho 09.01.2020 09:44 # 0
guestinxo 14.12.2019 00:25 # 0
XYPO3BO3 13.12.2019 22:29 # 0
3.14159265 16.12.2019 16:33 # 0
Ещё раз: вычитаются мантиссы И порядки. Как одно число.
В этом заключается царское изящество данного способа.
Причём он работает независимо от порядка чисел.
https://ideone.com/wTnBMz
Казалось бы, абсолютная разница числе составляет ЦЕЛУЮ единицу.
Однако вычитание нивелирует её в младшие разряды.
XYPO3BO3 13.12.2019 23:45 # 0
Между 4.0000000001 и 3.9999999999 разность равна 2E-10. Это довольно маленькое число.
Однако, в шестнадцатеричном представлении
4.0000000001 = 0x1.000000001b7ce000p+2
3.9999999999 = 0x1.ffffffffc9064000p+1
Поскольку IEEE754 для нормализованных чисел не хранит ведущую единицу, мантиссы будут храниться как 0x000000001b7ce и 0xffffffffc9064 соответственно (т. е. как совершенно непохожие числа), а порядки будут отличаться на единицу.
XYPO3BO3 14.12.2019 00:03 # 0
Тогда:
4.0000000001 = 0x2.0000000036f9cp+1
3.9999999999 = 0x1.ffffffffc9064000p+1
Или:
4.0000000001 = 0x1.000000001b7cep+2
3.9999999999 = 0x0.ffffffffe4832p+2
Мантиссы 2.0000000036f9 и 1.ffffffffc9064000 либо 1.000000001b7ce и 0.ffffffffe4832 уже́ можно сравнивать.
3.14159265 16.12.2019 16:22 # 0
Ну правильно
И мантиссы как раз отличаются на 1.
Но разница уходит в младшие разряды. И получается довольно несущественной.
3.14159265 16.12.2019 16:30 # 0
https://ideone.com/kdVR1u
Для даблов, с их точностью 2.00e-010 это довольно большая мантисса.
Потому я взял 1e-013.
Впрочем можно просто увеличить число нулей в 0x7FFFFFFFFFFFF000L
guestinxo 14.12.2019 00:24 # −1
3.14159265 16.12.2019 16:23 # +1
В этом весь смысл хака.
Вычитать и порядки ВМЕСТЕ с мантиссами. Как единое целое.
3.14159265 13.12.2019 20:51 # +1
Тут ещё большой вопрос что каждый понимает под «эквивалентностью».
Лично мне кажется два флоата эквивалентны, если их битовые представления эквивалентны *.
>bool operator ==
А это я бы обозначил как «приблизительное равенство».
* А NaNы сведены к одному фиксированному значению.
XYPO3BO3 13.12.2019 20:57 # 0
А ещё у плавпитуха бывают денормализованные числа. Когда порядок слишком маленький (иногда это называют underflow в противоположность overflow), включается второй формат битового представления: в мантиссе больше не подразумевается ведущая единица. Я не помню, пересекаются ли множества нормализованных и денормализованных (нужно проверять). Если вдруг они пересекаются, то нормализованное и денормализованное представление одного и того же числа будем считать разными числами?
3.14159265 13.12.2019 21:12 # −1
>+0 и -0 будем считать разными числами?
Я бы не сказал что они разные. Но они явно неэквивалентные.
Текстовое представление ведь различается.
>нормализованное и денормализованное представление одного и того же числа будем считать разными числами?
См. начало ветки:
http://govnokod.ru/26263#comment516271
«на самом деле этого точно не знает никто»
1024-- 16.12.2019 12:54 # 0
guest8 13.12.2019 16:56 # −999
BECEHHEE_O6OCTPEHuE 13.12.2019 17:32 # 0
OlegUP 13.12.2019 17:38 # 0
guest8 13.12.2019 20:21 # −999
Antifriz_otrabotanyi 13.12.2019 20:53 # 0
phpBidlokoder2 13.12.2019 20:52 # −1
Кресты для быдла
Antifriz_otrabotanyi 13.12.2019 20:52 # 0
3.14159265 13.12.2019 21:03 # +1
https://www.php.net/manual/en/reserved.constants.php
Именно поэтому я за «PHP».
XYPO3BO3 13.12.2019 21:05 # 0
3.14159265 13.12.2019 21:14 # 0
Чтобы флоат циклы по целым числам не ломались.
XYPO3BO3 13.12.2019 22:02 # 0
В более общем случае если y > 0, z > y*PHP_FLOAT_EPSILON, то y + z > y.
Всё, больше ничего оно не гарантирует.
В «PHP» нет гарантий, что 0.3 + 0.7 === 1.0.
В «PHP» нет гарантий, что 100000.0 + 500.0 === 100500.0.
MPA3uIII 13.12.2019 22:03 # −1
guest8 09.01.2020 09:46 # −999
inkanus_gray 11.01.2020 19:13 # 0
phpBidlokoder2 13.12.2019 20:53 # −1
Ещё забыли про
typeof null
0.1 + 0.2
gost 13.12.2019 20:56 # −1
MPA3uIII 13.12.2019 22:00 # 0
guest8 14.12.2019 01:21 # −999
bootcamp_dropout 14.12.2019 01:49 # 0
Все ссылки ведут на какой-то говносайт, который у меня нет открывается, так что да, на дваче
guest8 14.12.2019 02:01 # −999
AnalBoy 12.01.2020 00:04 # 0
guest8 13.12.2019 22:11 # −999
ASD_77 14.12.2019 00:41 # 0
Antifriz_otrabotanyi 14.12.2019 20:26 # 0
gost 14.12.2019 20:34 # 0
guest8 14.12.2019 04:33 # −999
nemywok_Ha_naJlO4KE 14.12.2019 21:41 # 0
ASD_77 14.12.2019 23:24 # 0
inkanus_gray 15.12.2019 00:48 # 0
Sers 15.12.2019 01:07 # 0
персона Альц-геймер
j123123 15.12.2019 00:42 # 0
1024-- 16.12.2019 13:05 # +2
В остальном это лишь говно программирования, в котором привыкли купаться сраные сишники.
Вот увидите, когда выйдут ЯПы нового поколения, старые жсники будут топить за typeof null === 'object', [1]+[1] = '1,2' и прочее логичное говно как сейчас сишники объясняют, что 0.1 + 0.2 != 0.3 - логично только потому, что прошло достаточно много времени с того момента, как эта "фича" была добавлена в плавающего питуха.
Сейчас только время возникновения разделяет 0.1 + 0.2 != 0.3 и [1]+[1] = '1,2'. К 0.1 + 0.2 != 0.3 все давно привыкли, а [1]+[1] = '1,2' - всё ещё новое. Но фактически всё это - говно.
И если числа реализовали через задницу, то 0.1 + 0.2 != 0.3 для адекватного человека никогда не станет логичным.
3.14159265 16.12.2019 15:41 # +3
Ну да, не додумались завезти рациональные числа из коробки в жопулярные промышленные языки.
Теперь все ловят багры плавающих питухов.
Причём на момент создания жаб,пнп,жсов (1995) дроби могли оказаться шустрее, чем эмулируемые флоаты или тормознутые инструкции x87-копроцессора.
ЕМНИП FPU стал обязательным только в Пентиумах. А в 486 он мало того что был опциональным, так ещё и тупил безбожно.
Но даже Пентиумы не были панацеей, вспомним FDIV-bug, связанный опять-таки с плавающим питухом.
Сама реальность должна была подсказать разрабам, что флоаты говно.
XYPO3BO3 16.12.2019 16:57 # +1
UBASIC version 8 has the high-precision real and complex arithmetic (up to 2600 digits) of prior versions, and adds exact rational arithmetic and arithmetic of single-variable polynomials with complex, rational, or modulo p coefficients, as well as string handling and limited list handling abilities.
https://en.wikipedia.org/wiki/UBASIC
ftp://ftp.bu.edu/mirrors/simtelnet/msdos/ubasic/
guest8 17.12.2019 12:26 # −999
3.14159265 17.12.2019 15:34 # +1
Многие платформы на тот момент если и поддерживали плавающего питуха, то только благодаря необязательному копроцессору.
К примеру Моторолла и в 1995 году выпускала недорогие модели процессоров без FPU.
Таков был общий тренд. Интел здесь не исключение. Наоборот, штеуд был одним из пионеров, кто интегрировал FPU и CPU в одном чипе.
3.14159265 16.12.2019 18:38 # +3
Нужно просто всё складывать с плюсами.
Малость WTF. Много NaN.
>[1]+[1] = '1,2' - всё ещё новое.
3.14159265 16.12.2019 18:13 # +4
All external data is stored and referenced from a single object, called the heap. Essentially this heap is a massive array (intended to be a typed array, which is highly optimized for performance).
All data is stored within this array – effectively replacing global variables, data structures, closures, and any other forms of data storage.
Posted: April 3rd, 2013
https://johnresig.com/blog/asmjs-javascript-compile-target/
Царь мудро учил неразумных анскилябр, что массив — единственно полезная структура.
Все остальные формы данных — есть частный случай массива.
Глупые анскилябры только кукарекали и насмехались над Царём.
А теперь уже более 90% популярных сайтов используют данную технологию.
guest8 17.12.2019 00:44 # −999
XYPO3BO3 17.12.2019 01:35 # 0
bormand 17.12.2019 04:18 # 0
Ну кстати был микроконтроллер однобитный.
XYPO3BO3 17.12.2019 04:29 # 0
Antifriz_otrabotanyi 21.12.2019 08:49 # 0
XYPO3BO3 17.12.2019 05:37 # +1