- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
> https://habr.com/ru/post/518308/
> Мне надоело, что индустрия зависит от прихоти создателей языков программирования. Сообществу нужно больше власти
> В языках вечно не хватает чего-то простого — лямбда-функций,
> именованных объединений, кастомных примитивных типов. Я лезу
> в обсуждения на Stack Overflow, в Github и вижу, как разрабы жалуются
> — им не хватает того же, чего и мне. Но обсуждения почти всегда
> заканчиваются одинаково: нужная фича не появится, потому что
> главный дизайнер языка и члены его команды нужной ее не считают.
Именно поэтому я за Си. Хорошо что есть крестопарашная помойка, в которую дизайнеры языка добавляют всякую хуйню по желанию каждого встречного и поперечного. Если б такого не было, всю эту поебень пытались бы пропихнуть в Си. Так что от крестопараши определенно есть какая-то польза.
> Я давно убедился: разработчики языков ничуть не лучше обычных программистов. У них нет никакого уникального знания или экспертизы, которая делала бы их лучше, чем вы. Зачастую они игнорируют базовые практики разработки программного обеспечения, которые известны даже новичкам. Если код компилятора нужно переписать — это вина создателей компилятора, это они не следили за архитектурой и все запустили.
Бляя... ну что за хуйня... С каких хуев он приравнял разработчиков стандарта языка к разработчикам компилятора/рантайма конкретного языка? Не, ну я понимаю что в каком-то там Go-вне это может быть действительно так, но ведь есть и языки, у которых более одного компилятора
> Без лямбд, которые позволяют передать фильтер в коллекцию одной строкой, кодовая база наших репозиториев разрослась бы кратно. Когда у тебя кодовая база вдвое больше, чем могла бы быть — ты в полном дерьме. Это работает, как снежный ком. Чем больше на проекте необязательного кода, тем сложнее его будет поддерживать — а чем сложнее его поддерживать — тем быстрее качество его кодовой базы будет ухудшаться. В плохом проекте любое изменение делает его ещё хуже.
Так всё просто. Надо просто сделать язык с ГОМОИКОНАМИ, и пусть каждый как ему вздумается нахуеверчивает там лямбды-хуямбды, рекорды-хуекорды и прочую поебень через метушню.
Обычные языки сейчас дают хуёвый, но базис. С гомоиконами у всех всё будет по-своему.
В лишпах там как раз всё единообразно и есть базис в виде s-exp. Хотя тот же Рэкет позволяет строить в целом произвольные парсеры
А какие ещё есть семейства языков с иконностью?
Реальные примеры: https://ru.wikipedia.org/wiki/Гомоиконичность#Примеры
Хотел про них написать, но как-то не был уверен до конца
Ну так пусть будут какие-нибудь либы из официального пакетного менеджена такого языка, которые через гомоиконы добавляют разного рода хуйню, и пусть этими либами пользуется 99% тех, кому такая-то хуйня нужна в языке. И если какая-то библиотека пользуется гомоиконами из такой-то библиотеки, то пусть требует ее в зависимостях. Не вижу проблемы
Но сообщество пильнуло три разных реализации, на то оно и сообщество. Теперь читая чужой код ты должен понимать все три варианта. И городить адаптеры между либами, которые завязались на разные.
Посмотри на те же кресты, сколько там разных реализаций строк нахуевертили...
давай теперь их все в стандарт добавим!
Ну и хуй с ним, под крестоговно никто ж не запрещает пилить всякую хуйню типа boost. Можно сделать официально одобренные создателями языка гомоиконы, которые там какую-то питушню добавляют, а если кто использует какую-то непонятные сторонние васянские гомоиконы, не одобренные официальными создателями языка - ну как бы это их проблемы.
В том же питоне ж как-то умудряются соблюдать PEP 8 в 99% случаев? Ну вот пусть так же соблюдают правила, что использовать можно только официально одобренные гомоиконы из особого раздела в пакетном менеджере
Какая диктатура )))
Собственно от этого и пытались уйти, не?
А есть циркониевые зависимости, которые по тв рекламирует Джигарханян
Стандартизация в говнокрестах - вот это диктатура, например если я в кресты захочу новую разновидность метушни добавить, ну чтоб помимо препроцессора, шаблонов с концептами и констэкспров чтоб еще какая-то хрень была, что надо делать? Ну допустим я могу всех послать нахуй и запилить свой ни с чем не совместимый компилятор (или запатчить существующий), в котором та хуйня будет, только вот им нихуя никто пользоваться не будет. А если будет возможность делать компилтайм-библиотеки через гомоиконы для добавления хуйни - это уже намного проще, к тому же такая компилтайм-библиотека может быть совместимой с кучей компиляторов, а не запиливаться отдельно под clang, отдельно под gcc, отдельно MSVC и так далее, как сейчас по факту происходит, когда крестокомитет очередную версию своего говностандарта выпускает
Форт?
Я о том, что можно ассемблер с s-expr сделать, типа там
Ну и "режим" ассемблера часто есть, примерно как твои s-expr'ы только кверху жопой.
Очевидно, ты не прав. Я всегда могу построить отображение XML -> JSON. Обратно не всегда, т.к. можно нахуевертить невалидную схему, но я могу и просто невалидный XML сделать.
> кроме скриптоблядей
Да даже на плюсах с JSON работать приятнее.
2) Я могу проверить любой JSON, что он соответствует формату, который я придумал на шаге 1.
3) В итоге могу использовать JSON вместо XML.
На каком пункте ты не согласен?
Скармливаем движку БД json и потом можем по нему делать выборки?
Реально же это хуй знает что надо парсить, чтобы по-царски принимать мегабайты текста (хмл или жсон, не критично), но искать в них где-то глубоко в дереве избранные штуки. Какой-то сценарий "прими, загляни, не вздумай десериализовывать, передай дальше".
В жсон есть и свой жсон-патх, а ну для особых ценителей есть и жсон-схема.
Работать с жсоном даже в постгресе куда приятнее, и уже охуенно эффективно.
Как поможет твоя схема, если клиенту требуется только тот набор полей, который ему понятен, а сервер уже помолодел и присылает что-то дополнительно?
ты и так провалидируешь эту структуру, когда соберешься её десериализовать в объект и напорешься на отсутствие поля, которое not null, зачем делать это два раза?
> SOAP позволяет
и при этом не очень отличает идемпотентность и неидемпотентность, по крайней мере когда HTTP является транспортом (ну и я навскидку не могу сказать, где там какие могут быть пометки, чтобы отметить, что данный результат RPC можно покешировать)
в следствии чего требуется руками размечать на нжинксе пути, по которым должны быть прокешированы данные и на сколько, и всё равно будет поебень
> Чем приятнее?
jsonb
- ого. А кстати когда выгодно использовать такой подход?
всегда?
json вместо jsonb надо выбирать только в одном случае - ты собираешься сохранить оригинальное авторское форматирование
А про то, когда это вообще надо в реляционной базе держать.
Во вторых тебе не всегда нужна 7 нормальная форма, и даже наоборот, после того как база нормализована предельно, ты для ускорения делаешь денормализацию. Чем хуже хранить жсон в постгресе вместо монгодибил? Хранить такое можно в text (CLOB), а можно и в jsonb.
Ну и наконец всякие составные типы (для записи эн локализованных переводов хранить там же) очень заебись в jsonb (раньше был ещё hstore, сейчас jsonb уже достаточно заебись, чтобы не добавлять экстеншеном негативные типы).
Его удобно парсить, он удобно ложится на объекты в скриптушне.
Он проще: в нём есть только объекты, массивы, числа, строки и null.
В общем 99% макак c тобой не согласны, и выберут JSON, а XML вызывает рвотный рефлекс.
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).
* Сообщество может форкнуть язык, и сделать его пад сибя. Или пойти нахуй
Ага, и получится замечательная история с крестами от борланда, крестами от майкрософта и крестами от гну. Или с джаваскриптом в разных браузерах. Проходили всё это уже...
А просто авторам выпустить третий питон и надцать лет ждать, пока закопают второй
Но третий пункт был зря.