Нашли или выдавили из себя код, который нельзя назвать нормальным,
на который без улыбки не взглянешь?
Не торопитесь его удалять или рефакторить, — запостите его на
говнокод.ру, посмеёмся вместе!
> https://habr.com/ru/post/518308/
> Мне надоело, что индустрия зависит от прихоти создателей языков программирования. Сообществу нужно больше власти
> В языках вечно не хватает чего-то простого — лямбда-функций,
> именованных объединений, кастомных примитивных типов. Я лезу
> в обсуждения на Stack Overflow, в Github и вижу, как разрабы жалуются
> — им не хватает того же, чего и мне. Но обсуждения почти всегда
> заканчиваются одинаково: нужная фича не появится, потому что
> главный дизайнер языка и члены его команды нужной ее не считают.
Именно поэтому я за Си. Хорошо что есть крестопарашная помойка, в которую дизайнеры языка добавляют всякую хуйню по желанию каждого встречного и поперечного. Если б такого не было, всю эту поебень пытались бы пропихнуть в Си. Так что от крестопараши определенно есть какая-то польза.
> Истинные причины отсутствия дженериков всегда лежали в техническом поле. Если вы заглянете в код компилятора Go, то у вас не останется сомнений — всему виной низкое качество кодовой базы компилятора. Добавить их просто невозможно не переписав компилятор, и, как я понимаю, для Go 2.0 они собираются сделать именно это.
> Я давно убедился: разработчики языков ничуть не лучше обычных программистов. У них нет никакого уникального знания или экспертизы, которая делала бы их лучше, чем вы. Зачастую они игнорируют базовые практики разработки программного обеспечения, которые известны даже новичкам. Если код компилятора нужно переписать — это вина создателей компилятора, это они не следили за архитектурой и все запустили.
Бляя... ну что за хуйня... С каких хуев он приравнял разработчиков стандарта языка к разработчикам компилятора/рантайма конкретного языка? Не, ну я понимаю что в каком-то там Go-вне это может быть действительно так, но ведь есть и языки, у которых более одного компилятора
> Проблема не в том, что мне не хватает синтаксического сахарка, чтобы сделать "красивенько". Все эти штуки — енамы, рекорды, юнионы — важные промышленные фичи, которые позволяют автоматизировать. Они появились не потому, что кто-то захотел выпендриться, они появились в ответ на конкретные задачи, которые не получалось хорошо решать со старыми инструментами.
> Без лямбд, которые позволяют передать фильтер в коллекцию одной строкой, кодовая база наших репозиториев разрослась бы кратно. Когда у тебя кодовая база вдвое больше, чем могла бы быть — ты в полном дерьме. Это работает, как снежный ком. Чем больше на проекте необязательного кода, тем сложнее его будет поддерживать — а чем сложнее его поддерживать — тем быстрее качество его кодовой базы будет ухудшаться. В плохом проекте любое изменение делает его ещё хуже.
Так всё просто. Надо просто сделать язык с ГОМОИКОНАМИ, и пусть каждый как ему вздумается нахуеверчивает там лямбды-хуямбды, рекорды-хуекорды и прочую поебень через метушню.
> Обычные языки сейчас дают хуёвый, но базис. С гомоиконами у всех всё будет по-своему.
Ну так пусть будут какие-нибудь либы из официального пакетного менеджена такого языка, которые через гомоиконы добавляют разного рода хуйню, и пусть этими либами пользуется 99% тех, кому такая-то хуйня нужна в языке. И если какая-то библиотека пользуется гомоиконами из такой-то библиотеки, то пусть требует ее в зависимостях. Не вижу проблемы
Ну вот нету у тебя в стандартной либе лямбд. И ты не хочешь их туда добавлять, пусть сообщество сначала что-нибудь запилит и определится, а там посмотрим.
Но сообщество пильнуло три разных реализации, на то оно и сообщество. Теперь читая чужой код ты должен понимать все три варианта. И городить адаптеры между либами, которые завязались на разные.
Посмотри на те же кресты, сколько там разных реализаций строк нахуевертили...
> Но сообщество пильнуло три разных реализации, на то оно и сообщество.
Ну и хуй с ним, под крестоговно никто ж не запрещает пилить всякую хуйню типа boost. Можно сделать официально одобренные создателями языка гомоиконы, которые там какую-то питушню добавляют, а если кто использует какую-то непонятные сторонние васянские гомоиконы, не одобренные официальными создателями языка - ну как бы это их проблемы.
В том же питоне ж как-то умудряются соблюдать PEP 8 в 99% случаев? Ну вот пусть так же соблюдают правила, что использовать можно только официально одобренные гомоиконы из особого раздела в пакетном менеджере
Стандартизация в говнокрестах - вот это диктатура, например если я в кресты захочу новую разновидность метушни добавить, ну чтоб помимо препроцессора, шаблонов с концептами и констэкспров чтоб еще какая-то хрень была, что надо делать? Ну допустим я могу всех послать нахуй и запилить свой ни с чем не совместимый компилятор (или запатчить существующий), в котором та хуйня будет, только вот им нихуя никто пользоваться не будет. А если будет возможность делать компилтайм-библиотеки через гомоиконы для добавления хуйни - это уже намного проще, к тому же такая компилтайм-библиотека может быть совместимой с кучей компиляторов, а не запиливаться отдельно под clang, отдельно под gcc, отдельно MSVC и так далее, как сейчас по факту происходит, когда крестокомитет очередную версию своего говностандарта выпускает
Тогда это будет ассемблер на гомоиконах, написанный сам на себе. Потом этот ассемблер через гомоиконы можно будет расширить до полноценного компилятора
Ну не закидывай рантайм на таргет, сри туда только асмом, юзай форт как макропроцессор/конпелятор. Ты же это и хотел на s-expr'ах наваять? А на хосте то у тебя хоть как какой-то рантайм будет, и не маленький.
Ну как бы если FORTH рассматривать как язык, на котором будет запилен некий ассемблер с компилтайм-метапрограммированием через FORTH, то чем LISP хуже? По-моему примерно однохуйственно. Мне просто скобочки больше нравятся, чем обратная польская нотация
> JSON не имеет ни схем
Очевидно, ты не прав. Я всегда могу построить отображение XML -> JSON. Обратно не всегда, т.к. можно нахуевертить невалидную схему, но я могу и просто невалидный XML сделать.
> кроме скриптоблядей
Да даже на плюсах с JSON работать приятнее.
1) Я могу любой XML представить в виде JSON.
2) Я могу проверить любой JSON, что он соответствует формату, который я придумал на шаге 1.
3) В итоге могу использовать JSON вместо XML.
1) Я могу любой XML представить в виде массива с массивами на ПХП.
2) Я могу проверить любой массив с массивами на ПХП, что он соответствует формату, который я придумал на шаге 1.
3) Могу использовать массив с массивами на ПХП так же, как и XML.
>На каком пункте ты не согласен?
Зачем мне JSON вообще?
xpath имеет официальную спеку на w3c
а что такое JSONSelect?
ну я ввел в гугл, вижу https://github.com/lloyd/JSONSelect
>JSONSelect is EXPERIMENTAL, ALPHA, etc.
>9 years
Пример того, как jsonpath работает даже на постгресе (а так на жс, жабу, пхп и тд все есть).
Реально же это хуй знает что надо парсить, чтобы по-царски принимать мегабайты текста (хмл или жсон, не критично), но искать в них где-то глубоко в дереве избранные штуки. Какой-то сценарий "прими, загляни, не вздумай десериализовывать, передай дальше".
> Статическая валидация структуры вредна?
ты и так провалидируешь эту структуру, когда соберешься её десериализовать в объект и напорешься на отсутствие поля, которое not null, зачем делать это два раза?
> SOAP позволяет
и при этом не очень отличает идемпотентность и неидемпотентность, по крайней мере когда HTTP является транспортом (ну и я навскидку не могу сказать, где там какие могут быть пометки, чтобы отметить, что данный результат RPC можно покешировать)
в следствии чего требуется руками размечать на нжинксе пути, по которым должны быть прокешированы данные и на сколько, и всё равно будет поебень
Во первых не обязательно держать, это охуенно для того, чтобы относительно динамические объекты на уровне функций уметь (далее ты задашь вопрос нахуя вообще логика в бд - ну так бывает, лишь бы она была инфраструктурной, невидимой для снаружи, а не бизнес).
Во вторых тебе не всегда нужна 7 нормальная форма, и даже наоборот, после того как база нормализована предельно, ты для ускорения делаешь денормализацию. Чем хуже хранить жсон в постгресе вместо монгодибил? Хранить такое можно в text (CLOB), а можно и в jsonb.
Ну и наконец всякие составные типы (для записи эн локализованных переводов хранить там же) очень заебись в jsonb (раньше был ещё hstore, сейчас jsonb уже достаточно заебись, чтобы не добавлять экстеншеном негативные типы).
> Зачем мне JSON вообще?
Его удобно парсить, он удобно ложится на объекты в скриптушне.
Он проще: в нём есть только объекты, массивы, числа, строки и null.
В общем 99% макак c тобой не согласны, и выберут JSON, а XML вызывает рвотный рефлекс.
XML предоставляет:
* xpath
* dom
* sax/stax
JSON ничего такого не предоставляет. Его не удобно "парсить".
>, он удобно ложится на объекты в скриптушне.
Не на любой скриптушне, а на JSе. Там из него получаются объекты. В питухоне из него получаются дикты, например.
И было сказано "кроме скриптоблядей".
Разуеется, JavaScript программисту JSON удобнее.
> в нём есть только объекты, массивы, числа, строки и null
В XML есть всё тоже самое, плюс составные структуры (см схему).
>В общем 99% макак c тобой не согласны
Вполне может быть. А в 2007-м они думали по другому.
Макаки ретранслируют то, что им в интернете написали.
> а XML вызывает рвотный рефлекс.
А HTML не вызывает.
Когда надо написать
Напоминает хрюканье леваков, которые сейчас по америкосии бегают:
"Мне надоело, что гугл зарабатывает так много денег, а я так мало. Сообществу бедных негров нужно больше власти над гуглом".
* Любое сообщество на 80% состоит из идиотов
* Сообщество популярных языков состоит из идиотов на 98%
* Если пустить сообщество, то завтра в стандартной библиотеке в глобальном неймспейсе будет mysql_real_escape_string и twitter_tweet.
* Почти все языки развиваются ровно так, как хочет их создатель (иначе будет еще более неконсистентное говно, см design by committee).
* Сообщество может форкнуть язык, и сделать его пад сибя. Или пойти нахуй
Ага, и получится замечательная история с крестами от борланда, крестами от майкрософта и крестами от гну. Или с джаваскриптом в разных браузерах. Проходили всё это уже...
Поэтому я против "opensource"-сообществ. Я просто однажды установил определённую версию "PHP", и меня дальше не ебёт, что за хуйню придумывает "сообщество".
> Я давно убедился: разработчики языков ничуть не лучше обычных программистов. У них нет никакого уникального знания или экспертизы, которая делала бы их лучше, чем вы. Зачастую они игнорируют базовые практики разработки программного обеспечения, которые известны даже новичкам. Если код компилятора нужно переписать — это вина создателей компилятора, это они не следили за архитектурой и все запустили.
Бляя... ну что за хуйня... С каких хуев он приравнял разработчиков стандарта языка к разработчикам компилятора/рантайма конкретного языка? Не, ну я понимаю что в каком-то там Go-вне это может быть действительно так, но ведь есть и языки, у которых более одного компилятора
> Без лямбд, которые позволяют передать фильтер в коллекцию одной строкой, кодовая база наших репозиториев разрослась бы кратно. Когда у тебя кодовая база вдвое больше, чем могла бы быть — ты в полном дерьме. Это работает, как снежный ком. Чем больше на проекте необязательного кода, тем сложнее его будет поддерживать — а чем сложнее его поддерживать — тем быстрее качество его кодовой базы будет ухудшаться. В плохом проекте любое изменение делает его ещё хуже.
Так всё просто. Надо просто сделать язык с ГОМОИКОНАМИ, и пусть каждый как ему вздумается нахуеверчивает там лямбды-хуямбды, рекорды-хуекорды и прочую поебень через метушню.
Обычные языки сейчас дают хуёвый, но базис. С гомоиконами у всех всё будет по-своему.
В лишпах там как раз всё единообразно и есть базис в виде s-exp. Хотя тот же Рэкет позволяет строить в целом произвольные парсеры
А какие ещё есть семейства языков с иконностью?
Реальные примеры: https://ru.wikipedia.org/wiki/Гомоиконичность#Примеры
Хотел про них написать, но как-то не был уверен до конца
XLST, tcl, .. 🙂
Ну так пусть будут какие-нибудь либы из официального пакетного менеджена такого языка, которые через гомоиконы добавляют разного рода хуйню, и пусть этими либами пользуется 99% тех, кому такая-то хуйня нужна в языке. И если какая-то библиотека пользуется гомоиконами из такой-то библиотеки, то пусть требует ее в зависимостях. Не вижу проблемы
Но сообщество пильнуло три разных реализации, на то оно и сообщество. Теперь читая чужой код ты должен понимать все три варианта. И городить адаптеры между либами, которые завязались на разные.
Посмотри на те же кресты, сколько там разных реализаций строк нахуевертили...
давай теперь их все в стандарт добавим!
Ну и хуй с ним, под крестоговно никто ж не запрещает пилить всякую хуйню типа boost. Можно сделать официально одобренные создателями языка гомоиконы, которые там какую-то питушню добавляют, а если кто использует какую-то непонятные сторонние васянские гомоиконы, не одобренные официальными создателями языка - ну как бы это их проблемы.
В том же питоне ж как-то умудряются соблюдать PEP 8 в 99% случаев? Ну вот пусть так же соблюдают правила, что использовать можно только официально одобренные гомоиконы из особого раздела в пакетном менеджере
Какая диктатура )))
Собственно от этого и пытались уйти, не?
А есть циркониевые зависимости, которые по тв рекламирует Джигарханян
Стандартизация в говнокрестах - вот это диктатура, например если я в кресты захочу новую разновидность метушни добавить, ну чтоб помимо препроцессора, шаблонов с концептами и констэкспров чтоб еще какая-то хрень была, что надо делать? Ну допустим я могу всех послать нахуй и запилить свой ни с чем не совместимый компилятор (или запатчить существующий), в котором та хуйня будет, только вот им нихуя никто пользоваться не будет. А если будет возможность делать компилтайм-библиотеки через гомоиконы для добавления хуйни - это уже намного проще, к тому же такая компилтайм-библиотека может быть совместимой с кучей компиляторов, а не запиливаться отдельно под clang, отдельно под gcc, отдельно MSVC и так далее, как сейчас по факту происходит, когда крестокомитет очередную версию своего говностандарта выпускает
Форт?
Я о том, что можно ассемблер с s-expr сделать, типа там
Ну и "режим" ассемблера часто есть, примерно как твои s-expr'ы только кверху жопой.
Очевидно, ты не прав. Я всегда могу построить отображение XML -> JSON. Обратно не всегда, т.к. можно нахуевертить невалидную схему, но я могу и просто невалидный XML сделать.
> кроме скриптоблядей
Да даже на плюсах с JSON работать приятнее.
Это странная логика. Ты так же можешь преобразовать XML в бинарный формат. Означает ли это, что схемы есть у чего угодно?
>Обратно не всегда,
Почему? Любое дерево без петель можно представить как в JSON, так и в XML, так и в чем угодно.
>можно нахуевертить невалидную схему
Схема не является обязательной для XML.
>но я могу и просто невалидный XML сделать.
Равно как и невалидный JSON.
>Да даже на плюсах с JSON работать приятнее.
Чем это приятнее?
Отсутствием XPath и стандартных схем для генерации?
2) Я могу проверить любой JSON, что он соответствует формату, который я придумал на шаге 1.
3) В итоге могу использовать JSON вместо XML.
На каком пункте ты не согласен?
2) Я могу проверить любой массив с массивами на ПХП, что он соответствует формату, который я придумал на шаге 1.
3) Могу использовать массив с массивами на ПХП так же, как и XML.
>На каком пункте ты не согласен?
Зачем мне JSON вообще?
Почему сразу не взять формат со схемой и xpath и пр?
а что такое JSONSelect?
ну я ввел в гугл, вижу
https://github.com/lloyd/JSONSelect
>JSONSelect is EXPERIMENTAL, ALPHA, etc.
>9 years
сайт тоже керуто https://jsonselect.org/
заебись как всё стабильно, прямо хочется в продакшен сразу
Скармливаем движку БД json и потом можем по нему делать выборки?
Реально же это хуй знает что надо парсить, чтобы по-царски принимать мегабайты текста (хмл или жсон, не критично), но искать в них где-то глубоко в дереве избранные штуки. Какой-то сценарий "прими, загляни, не вздумай десериализовывать, передай дальше".
В жсон есть и свой жсон-патх, а ну для особых ценителей есть и жсон-схема.
Работать с жсоном даже в постгресе куда приятнее, и уже охуенно эффективно.
Как поможет твоя схема, если клиенту требуется только тот набор полей, который ему понятен, а сервер уже помолодел и присылает что-то дополнительно?
Статическая валидация структуры вредна?
> SOAP для динозавров.
SOAP позволяет сгенерировать прокси класс на java или C# по WSDL, и не писать его вручную.
>Работать с жсоном даже в постгресе куда приятнее
Чем приятнее?
>а сервер уже помолодел и присылает что-то дополнительно?
Для этого обычно используют версии эндпоинтов
ты и так провалидируешь эту структуру, когда соберешься её десериализовать в объект и напорешься на отсутствие поля, которое not null, зачем делать это два раза?
> SOAP позволяет
и при этом не очень отличает идемпотентность и неидемпотентность, по крайней мере когда HTTP является транспортом (ну и я навскидку не могу сказать, где там какие могут быть пометки, чтобы отметить, что данный результат RPC можно покешировать)
в следствии чего требуется руками размечать на нжинксе пути, по которым должны быть прокешированы данные и на сколько, и всё равно будет поебень
> Чем приятнее?
jsonb
- ого. А кстати когда выгодно использовать такой подход?
всегда?
json вместо jsonb надо выбирать только в одном случае - ты собираешься сохранить оригинальное авторское форматирование
А про то, когда это вообще надо в реляционной базе держать.
Во вторых тебе не всегда нужна 7 нормальная форма, и даже наоборот, после того как база нормализована предельно, ты для ускорения делаешь денормализацию. Чем хуже хранить жсон в постгресе вместо монгодибил? Хранить такое можно в text (CLOB), а можно и в jsonb.
Ну и наконец всякие составные типы (для записи эн локализованных переводов хранить там же) очень заебись в jsonb (раньше был ещё hstore, сейчас jsonb уже достаточно заебись, чтобы не добавлять экстеншеном негативные типы).
Его удобно парсить, он удобно ложится на объекты в скриптушне.
Он проще: в нём есть только объекты, массивы, числа, строки и null.
В общем 99% макак c тобой не согласны, и выберут JSON, а XML вызывает рвотный рефлекс.
define "парсить".
XML предоставляет:
* xpath
* dom
* sax/stax
JSON ничего такого не предоставляет. Его не удобно "парсить".
>, он удобно ложится на объекты в скриптушне.
Не на любой скриптушне, а на JSе. Там из него получаются объекты. В питухоне из него получаются дикты, например.
И было сказано "кроме скриптоблядей".
Разуеется, JavaScript программисту JSON удобнее.
> в нём есть только объекты, массивы, числа, строки и null
В XML есть всё тоже самое, плюс составные структуры (см схему).
>В общем 99% макак c тобой не согласны
Вполне может быть. А в 2007-м они думали по другому.
Макаки ретранслируют то, что им в интернете написали.
> а XML вызывает рвотный рефлекс.
А HTML не вызывает.
Когда надо написать
макак всё устраивает.
А если я предложу им написать
то сразу проблюются.
JS - JSON.parse
PHP - json_decode
Python - json.loads
Во всех этих языках я получаю то, что ожидаю.
<petuh name="petya"/>
и
<kuritsa name="kvochka"/>
?
Мне удобнее работать с
а не с домом
> массива с массивами
> на ПХП
Идеальное сочетание.
Как выше сказали, это деталь имплементации. Были стековые процессоры, которые его вообще нативно поддерживали.
"Мне надоело, что гугл зарабатывает так много денег, а я так мало. Сообществу бедных негров нужно больше власти над гуглом".
* Любое сообщество на 80% состоит из идиотов
* Сообщество популярных языков состоит из идиотов на 98%
* Если пустить сообщество, то завтра в стандартной библиотеке в глобальном неймспейсе будет mysql_real_escape_string и twitter_tweet.
* Почти все языки развиваются ровно так, как хочет их создатель (иначе будет еще более неконсистентное говно, см design by committee).
* Сообщество может форкнуть язык, и сделать его пад сибя. Или пойти нахуй
Ага, и получится замечательная история с крестами от борланда, крестами от майкрософта и крестами от гну. Или с джаваскриптом в разных браузерах. Проходили всё это уже...
А просто авторам выпустить третий питон и надцать лет ждать, пока закопают второй
Но третий пункт был зря.