- 1
- 2
-- All scripts should begin at line
null, Null, NULL = nil
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
−340
-- All scripts should begin at line
null, Null, NULL = nil
Lua
nUll, nUlL, nULl, nULL,
Null, NulL, NuLl, NuLL,
NUll, NUlL, NULl, NULL = nil
NlI,Иll,NII,ИII
nIl,nlI,nil,nIL,
NiLL, ИiLL,итд...
null, nulL, nuLL, nuLl,
nULl, nULL, nUlL, nUll,
NUll, NULl, NuLl, NuLL,
NulL, NUlL, NULL
хотя херня какаято получается :(
плохо у меня с ним
NaIN!
Only WCT forever
А ещё там есть загрузчик на кое-чём ещё:
https://github.com/freebsd/freebsd/blob/master/stand/forth/loader.4th
мощно
https://github.com/freebsd/freebsd/blob/master/stand/lua/loader.lua
print(null) - - nil
(или наоборот)
Теперь угадай чья фуфайка торт и золотой хуй.
Лунная клизма, дай мне силу!
я забыл что неинициализированна переменна будет нил
этот код не имеет смысла
зависит от точки _G
Просо —– это хорошо!
https://www.ecma-international.org/ecma-262/9.0/index.html#sec-terms-and-definitions-null-type
Хотя, typeof null === 'object'
https://www.ecma-international.org/ecma-262/9.0/index.html#sec-typeof-operator-runtime-semantics-evaluation
В отличие от объектов, литералы null равны самим себе и не содержат свойств:
> undefined крайне скверный тип, он никогда ничему не равен, кроме себя
null ведёт себя так же с ===
хотя, null == undefined
В общем, времени на раздумья не было, а в голове автора наверно ещё вертелись низкоуровневые и типизированные сущности.
в C# попытка была сделать и то и то.. и как всегда получилось все сильно громоздко
Придумать трудно, нужны ПРОТОТИПЫ.
Ничего лучше не придумывается. Берётся прототип языка, обкатывается на реальных проектах. Выясняются слабые места и недоработки, создаётся новый язык с новыми фичами и без старых багов, а старый язык выкидывается нафиг. И так несколько раз, пока в ходе эволюции не получится нормальный язык.
Для старого скриптоговна предлагаются варианты:
* Выбросить нахрен
* Автоматический транслятор из произвольной в последнюю версию
* Встраивать интерпретаторы всех прошлых версий
И главное - не жалеть старое говно. Совместимость должна обеспечиваться комплияторами/трансляторами, а не языком.
По идее, в JS надо
* выкинуть undefined и void
* заменить === на ==, а == на ~ (вроде не должно мешать унарной тильде)
* добавить перегрузку операторов с возможностью задания произвольных как в хаскеле
* добавить прослойку между ООП и ФП: сделать адекватную замену (x => x.field); добавить двоеточие как в lua, чтобы в зависимости от выбора привязывать/не привязывать this к методу объекта; аналогично - с call/apply
* разделить в объектах данные и метаданные или полностью перейти на Symbol. Я не против, если operator('+-+') будет возвращать символ, а дальше его можно было бы использовать как ключ для перегрузки оператора +-+.
* сделать обязательной точку с запятой
* выбрать что-то из var/let и оставить только одно
* упростить синтаксис функций. (x,y) => z оставить, а варианты function(){} и () => {} облегчить и свести до одного, скажем, (in,put){ return output; }, this передавать либо явно, либо в функциях отдельного сорта. Например, [x,y] => z и [in,put]{ return output; } принимают свой this (как function(){}), а круглые скобки - нет (как x=>y).
Касательно кода языка. Зачем выкидывать полностью? Главное, что должно получиться на выходе - язык, который выпускается как новый, в котором не оставлено говно для обратной совместимости. Выкидываются только куски кода, соответствующие плохим фичам; куски кода, соответствующие хорошим фичам - адаптируются под новый язык.
Касательно пользователей. Ну, либо транслятор, либо несколько движков для разных версий, либо всё вместе.
Если речь о вебе, то даже хорошо бы было, если старые движки ещё и CSS/HTML той же версии был. Тогда б настало всеобщее счастье. Программист проверяет, чтоб всё работает под текущий стандарт, а потом его код гарантированно запускается под этим же движком многие годы.
Лучше, чем сейчас, когда всё обновляется, но то поддерживает обратную совместимость и копит говно, то не поддерживает и всё ломает, то ещё что-то от изменений ломается.
Сколько там лет уже лет прошло? А второй до сих пор жив.
Если в очередной раз дату не передвинут.
Это же здорово.
Сделали новый нормальный язык без багов старого, а обратная совместимость осталась через то, что
> второй до сих пор жив
Зато теперь нет ёбли с пиндосскими либами и скриптами где они вечно забывали воткнуть encode и decode (для инглиша и так сойдёт). По-моему вполне адекватный ход.
> возвращает int
А должно возвращать хуету, от которой мне потом всё равно придётся брать ord?
Ну заебись.
Что должно лежать в массиве байтов, если не числа от 0 до 255?
Всем похуй на двойку, раз уж явно решили ломать с ней обратную совместимость...
В двойке у тебя была байтстринга. И ты по индексу получал... байтстрингу длины 1. Сомнительная хуйня, но для строки ещё сойдёт.
В тройке у тебя нет байтстринги. Есть массив байтов. И возвращать по индексу массив из одного байта - это уже треш какой-то.
> array
Array из интов жрёт дохуя. Массив байтов нужен для любых блобов (пакеты из сети, двоичные данные с диска, вот это всё). По сути это и есть Array, просто плотный.
В принципе, в эрланге со списками из интов живут как-то. Наверное и тут можно было бы забить на пирфоманс.
А, ты про import array? Да, этот плотный и не жрёт. Я затупил.
Ну тогда смело можно было вообще только юникод оставлять.
Им ctypes и struct завезли, а они хотят байтоёбить форматом... В конец уже упоролись со своим питоном. Правильно Гвидо сделал, что прикрыл эту вакханалию.
Гвидо похуй было же. Если бы ему не было похуй - он бы никогда на это не решился.
> попробуй понять почему не работает
Потому что 'r' вместо 'rb'. Вот только этот код у тебя и на двойке случайно работал. Просто удачные файлы попадались.
Питонисты такие наивные... У них отобрали инструмент для отстрела ног, а они жалуются...
Лень. Что там будет то? Там кривая либа, которая хочет именно текстовую строку (хотя протокол явно двоичный)?
> по дефолту в однобайтовой локали
Я про конвертер '\r\n' в '\n' на венде. А в торрентах полно замечательных полей с хешами, где такая хуйня может встретится. Всего 2 байта должны удачно лечь. Поэтому даже в двойке нельзя было открывать двоичные файлы без 'b'.
Ну дождись, пока автор портанёт либу на тройку. Или сам портани. Зачем совать либу от одного языка в другой и надеяться, что это прокатит?
Даже с 'rb' и актуальной версией либы (под тройку)?
> Ну это пушка.
Крестобляди никогда не понять тонкую душу питониста...
Мне лень. Ничего интересного я там не найду.
Если оно с 'rb' не работает, но обещает совместимость с тройкой - это косяк либы. Если автор либы и не обещал совместимость - ну ССЗБ, о чём вообще разговор?
Какую конкретно либу надо ставить чтобы попробовать? А то их там куча похожих в репозитории. Штук 100 наверное.
За каким хуем её дают скачать для тройки - х.з. Ну да ладно, давайте её пофиксим. Не брать же портированный под тройку форк.
1) Из-за изменившихся правил поиска модулей либа не может найти свои же кишки. Фиксим импорт на bencode.BTL
2) Не может найти некий StringType. Убираем импорты, заменяем типы на свежие. Выбрасываем ветку для long нахуй.
3) Теперь наконец-то получаем ошибку декодирования. Въёбываем ord'ов в ключи мапы которую там читали.
4) index хочет байты, въёбываем b перед строками, заодно обмазываем ord'ами сравнения. bdecode() заработало.
5) У dict.items() нет sort, обмазываем в list.
6) Запинываем ошибки конкатенации байтов и строк (b-литералы и encode после str). Убираем ветку для строки и добавляем ветку для bytes.
7) Профит, торрент читается и сохраняется.
Гвидо, блядь. Раз недооценил масштабы использования своего языка.
Но какого хрена эта либа вообще делает в репе для тройки? Зачем пип ставит заведомо мёртвые либы? Вот в чём вопрос.
> юникод
Эта функция должна бить ассёртом по ебалу передавшим туда юникод. Ибо протокол двоичный. Но в питоне так не принято, да?
> рабочую либу для тройки
"bencode3", "bencode.py". Авторы пишут, что для тройки подходит. Разве это всё не работает?
> Ассерт же в дебаг моде только
Ну ок, согласен, полноценным исключением по ебалу.
Что конкретно в них тебя не устраивает? У меня они несколько торрентов разобрали без проблем. Вижу все поля и хеши.
> кто же будет либы переписывать на тройку
Да мне похуй, кто будет их переписывать, если честно. Гвидо спрашивай. Не я устроил эту маленькую победоносную войну с переходом напитон3.
> Нет
Да. А ты дальше сиди на своей двойке и собирай грабли с автокастом строк в байты и обратно.
Да, я не настоящий сварщик. Я всего лишь допиливал хрень на базе твистеда на прошлой работе и писал тестики, утилитки и адаптер для бинарных протоколов через ctypes на текущей. Всякий just for fun с usb коннектом до циклоняшки и stm'ки, само собой, считать за работу напитоне нельзя. Подработку с сервером на фласке - аналогично.
Очевидно, что раз питон не является моим основным языком, я не имею права высказывать своё мнение о питонах, в особенности о работе с байтами.
Удваиваю вопрос, кстати. Буквально вчера поставил python-geoip на свой самый новый Питон 3.7.2 через штатный пип, пробую — нихера не работает, вываливается с невразумительной ошибкой. Смотрю исходники — а там куча принтов без скобок. Охуеть.
А тут я имел в виду байтстрингу.
В других языках это прекрасно понимали и тащили обратную совместимость. Один гвидо, видимо, недооценил масштабы своего поделия.
Ну а раз уж за каким-то хуем попёрлись ломать - надо все косяки фиксить, а не только скобочки к принту. Второго шанса то уже точно не будет.
Всё остальное - мелкая косметика, на которую можно было вообще хуй забить и которую затащили заодно с переработкой строк и деления.
> Это ОЧЕНЬ страшно, сложно и дорого.
Да, это действительно очень страшно. Огромная кодовая база, которая реально используется, но при этом держится на соплях и изоленте.
Вот только этот страх есть при любом рефакторинге питоньего кода, переход с двойки на тройку просто вытащил эту проблему на поверхность.
Я согласен, и в крестах можно поломать логику если нет тестов. Но там я хотя бы не боюсь переименовывать поля...
Потому что я хочу показать преимущество языков со статической типизацией.
Питон няшный. Мне очень нравится на нём писать небольшие скрипты, экспериментировать с железками через его REPL. Но я тупо боюсь трогать тот же парсер тредов на NGK. Хотя надо бы.
Да надо бы.
Либо мы сравниваем языки честно и беспристрастно, либо организуем "сорта" языков и внутри них сравниваем только выбранные. Статические-динамические языки - это слишком неточно. Можно ещё сравнивать языки, использующиеся в веб-клиентах, серверах, в микроконтроллерах. Потом окажется, что это тоже неточно, и личность автора может улучшить/испортить хороший язык. Соответственно, сравнивать языки в категориях "языки Кернигана и Ритчи", "языки Вирта", "языки Ван Россума", "языки Эйха" и т.д., где каждый язык будет победителем в своей нише.
Да ну это говно. Когда-то у него были крутые регулярки и онлайн-репа с крутыми либами. Но сейчас это уже везде есть.
Прыщебляди соснули.
В итоге вся эта замечательная идея вырождается в сишко-колл-конвеншн или какой-нибудь COM. Где на языки как таковые вообще всем насрать. Лишь бы ABI стабильное было.
С виртуальной машиной придётся либо сделать слишком низко, что она не нужна, либо слишком высоко, что принципиальных изменений в языке не провернёшь, не потеряв совместисомть.
В общем, надо как-то попадать в середину, где оптимально.
В мире языков так не считают. Под много популярных языков библиотеки несовместимы, кроме случаев, когда переиспользуется сишкостандартная библиотека или работает компиляция в жс.
Я бы скриптушню транслировал в новую версию. А кто писал говнокрипты, которые надеются на размер своего файла и прочую питушню - выкинуть.