>>744159 (OP)
>дальше это говно продолжаться не может
Согласен, давай нам свою крутую замену.

>>744163
тред не про это

>>744165
А про что?

>>744171
а про то, что все ужасно

>>744174
Ну мы в курсе, что все ужасно.
Выкладывай свое решение проблем.

>>744177
а может лучше вместе сядем и подресссируем, как все ужасно и подождем пока придет кто-то, кто может решить хотя бы парочку?
потому что я не могу

>>744181
Тебе с этим в /b надо.

>>744184
чего? доска-то о программировании!

>>744192
Но у тебя же про нытье, а не о программировании - с этим в /b.

>>744195
Тебе 15? Мой тред не о нытье, он о нытье на тему программирования. Я считаю, что это соответствует тематике треда, а если ты не разделяешь мое мнение, то можешь отправить жалобу или скрыть тред.

>>744206
Хорошо, успехов тебе.

>- Почему если я хочу мало-мальски выразительно работать с AST собственной программы, то я обязательно должен подписываться на (ебалу cо (скобками [и больными людьми]))?
Может потому что ты жавадебил может и чуть более продвинутый не осиливший Common Lisp?

>>744159 (OP)
1. Homoiconicity не бывает бесплатным. Либо ты получаешь её и пишешь на лиспе, либо не получаешь вовсе.
3. Ниасилил.
5. Предложи. Алсо объекты.
6. Потому что никто не посчитал нужным ебаться с aspect-oriented programming. А все потому, что не так уж и много существует ошибок, которые действительно НУЖНО обрабатывать.
7. Потому что никто не предложил единой семантики версионирования. Каждый дрочит, как он хочет.
8. Такие языки есть, только их никто не использует.
9. Пошел нахуй. Ему таки предложили, а он нос воротит. map наше всё.
10. Быстродействие, универсальность CRUD.
11. Предложили. The Prevayler, Hazelcast, Redis, MongoDB - куча-мала всевозможных подходов.

> Почему если я хочу мало-мальски выразительно работать с AST собственной программы, то я обязательно должен подписываться на (ебалу cо (скобками [и больными людьми]))?
Не обязательно.
> Почему в 2016 году для отладки нет абсолютно ничего лучше брэйкпоинтов и отладочного вывода, а любые инструменты профилирования это обязательно невыносимая ебля?
Perf + flamegraph даже макака осилит.
> Почему в 2016 году мы все еще пишем код приемущественно на функциях, когда можно было бы использовать более интуитивные высокоуровневые примитивы?
Например, какие?
> Почему обработка ошибок всегда размещается в основной логике кода, не отделяется от него в отдельный слой, а в лучшем случае нам предлагают либо разворачивать эксепшонами стэк, либо if err != nil а-ля Cи?
Потому, что ты не осилил монады и эффекты.
> Почему off-by-one is a thing и для работы со списками нам не предложили ничего лучше жалких[:слайсов] или нечитаемого синтаксического мусора "для своих" а-ля Haskell?
Потому, что ты ни осилил ни хаскель, ни APL.
>

>>744159 (OP)
Сколько лет опыта у тебя программировании? Какой lvl вообще?

Ну, трансформация списков мапами - это, конечно, неплохо, но не когда нужно работать с одним элементом. Я думаю, ОП это имел в виду под оффбайоне.
Да и даже не смотря на то, что "90% операций над коллекциями - это мап и фильтер" (на самом деле, ещё и итер), это оставшиеся 10% не отменяет.
Что я хочу этим сказать? Да хуй его знает.

>>744301
Ну есть же итераторы, как в сепепе, с проверкой границ.

Я делаю свой язык, попробую предложить парочку решений:

>- Почему если я хочу мало-мальски выразительно работать с AST собственной программы, то я обязательно должен подписываться на (ебалу cо (скобками [и больными людьми]))?
Это, на самом деле, скорее хорошо, чем плохо. Подумай только, появись полная рефлексия типа как в лиспе, где-нибуть в С++ — это же был бы полный пиздец. Мало того, что и так читать нереально, так еще и это. Проще говоря — это проблема читабельности. Метапрограммирование это классно, когда ты можешь сделать какой-то уютный макрос и съэкономить 20 строчек кода в пяти местах = 100 строчек (возможно больше, на росте базы), но это очень плохо, когда вас (программистов) чуть больше трех.
>- Почему если я хочу нормальную конкуррентность, то в лучшем случае мне парят допотопный CSP (почти сорок лет прошло, блядь!), а вместе с ним и низкоуровневою ебалу с каналами?
Потому что большинство конкуррентных задач — это в лучшем случае parallel map или pub/sub, а для них ничего большего обычно не надо.
>- Почему в 2016 году для отладки нет абсолютно ничего лучше брэйкпоинтов и отладочного вывода, а любые инструменты профилирования это обязательно невыносимая ебля?
Потому что отладка — это сложно, особенно в средах без интерпретатора. А что ты вообще хочешь?
>- Почему ни один язык не предлагает версионирование кода из коробки, а вместо этого нам предлагают ебаться с разношерстными пакетными менеджерами или вендорингом?
Потому что версионирование это не проблема кода, а его распространения (packaging, distribution) и код этим заниматься не должен. Ты же не спрашиваешь хуле Perl не деплоит твой код в облако? Для этого есть докер.
>- Почему ни один язык не позволяет легко писать GUI, а в лучшем случае нам приходится писать JS-подобный QML и связывать его с портянками на С++?
Потому что там где нужен GUI есть свои специфические и очень качественные решения для проектирования, а если очень хочешь кросс-платформенности, то твой выбор это Qt, что поделать.
>- Почему off-by-one is a thing и для работы со списками нам не предложили ничего лучше жалких[:слайсов] или нечитаемого синтаксического мусора "для своих" а-ля Haskell?
Потому что off-by-one это не синтаксическая, а психологическая проблема. Пытаться ее решать синтаксически — глупо и очень неэффективно в рантайме.

>>744295
27 лвл; 8 лет в индустрии, работал как в больших компаниях (dropbox), так и в стартапах (grammarly, например).

>>744159 (OP)
>Почему в 2016 году, на уровне кода, нас еще должно ебать какая "там" база данных, а для коммуникации нам не предложили ничего получше допотопного SQL
Потому как ты самоуверенный быдлокодер-дебилойд, неспособный даже осознать суть проблем и сформулировать их. Тебя, видимл, как местных школьников что-то "бесит", но что и почему ты понять не уже можешь (ума-то не хватает).

>>744335
Суть проблемы очевидна. ORM это так или иначе костыль вокруг невозможности прозрачно маппить схему {или ее отсутствие} на какие-то языковые модели. Но с ORM все отлично только в хеллоуворлдах. А вот когда ты переходишь с одной базы на другую, оказывается, что твои foreign keys стали как-то слишком медленными или где-то что-то проебалось или банально нет необходимой фичи (ахахах лох).

Вот ты можешь сейчас взять и безболезненно перевести свое приложение с MySQL на Postgres или с MongoDB на OrientDB, например? Не сможешь. А почему меня, как разработчика приложения, это должно ебать? Пускай базами данных и их поддержкой занимаются database engineers.

>>744343
>почему меня, как разработчика приложения, это должно ебать
понятно...

>>744345
Я считаю, что приложение должно быть МАКСИМАЛЬНО абстрагировано от низлежащей архитектуры (в том числе, от баз данных). Да, я адепт PaaS-driven разработки и да, я горжусь этим.

>>744316
>Потому что отладка — это сложно, особенно в средах без интерпретатора. А что ты вообще хочешь?
Добавлю ещё: в любом многопоточном/асинхронном коде почти любой отладчик становится бесполезным. Энджой йоу принтлн.
>Потому что там где нужен GUI есть свои специфические и очень качественные решения для проектирования, а если очень хочешь кросс-платформенности, то твой выбор это Qt, что поделать.
А есть что-то качественнее кути? Есть ещё кросплатформенный гтк с ногами и сишным интерфейсом в 2016 из линуксов. Ещё есть винапи (ыыыы). Нормальный гуй из коробки предоставляет только эпл.

>>744343
Что до твоих рассуждений, что тебя мол что-то там волновать в базе не должно, так они выдают в тебе малограмотного безответственного человека. Целостность данных это не забота каких-то там других людей, а целиком и полностью твоя. Как и целостность данных в оперативной памяти рантайма твоего кода - то же самое.

Дело не только в реляционной модели. Элементарно, начинать нужно уже с того, что у твоего "языка приложения" всегда иной набор базовых типов чем у БД. У БД набор базовых типов (а часто и операций над ними) как правило шире. (но макаки конечно об этом не знают всех их познания заканчиваются на varchar, int, double, decimal - внезапно, это то, что orm умеет приводить к).

Что до воплей на SQL. Без SQL ты не сможешь решать те задачи которые нужно. SQL не просто формулирует простой вопрос к хранилищу, а позволяет делать крайне нетривиальные манипуляции и выводы на основе данных, и в императивном стиле ты это не напишешь. Если ты используешь БД через orm-обертку, то о возможностях СУБД у тебя представление мягко говоря частичное. ORM-это вообще мусор, он ограничивает тебя 1% возможностей СУБД и создает сотни часов дополнительной работы. Что до SQL как языка, то любой язык запросов решающий те же задачи получится таким же, может чуть моднее, где-то чуть приятнее, но суть то же.

Часть ненависти к SQL у тупарей (независимо от их опыта и возраста) связана с тем что основном языке он чужероден и представлен строкой. Можно ли сделать язык запросов частью синтаксиса основного языка - да (полу-попытки были - тот же linq). Можно ли гонять не строку а AST - да. Можно ли пойти дальше и строить часть query plan'a на вызывающей стороне (которые зачастую масштабировать проще) разгрузив этим образом машины с БД - да. Но никто не хочет вкладываться. Да и макаки опять не поймут, если это не гугл конечно предложит.

Более того, нужно будет завезти БД-шную онтологию в язык. И начинать придется не с мути абстрактных рассуждений про импеданс мисмач (или как там) а с вещей типа int signedness.

Были разработки систем представляющих собой язык/платформу программирования общего (почти общего) назначения и нормальную реляционную базу данных в одном целом. (Никаких противоречий, как привыкли думать хомяки, между этими двумя мирами нет). Названия к сожалению не помню. Оно не взлетело. Но судьба подходов и технологий определяется не их качеством/правильность/удобством, а любыми другими причинами.

бамп

>>744159 (OP)
Хуиты какой-то понаписал. Я так тоже могу.
Где, хотя бы, примеры того как "должно быть" с твоей точки зрения? Как эти "проблемы" должны решаться? Как-нибудь? Да иди ты нахуй!

>>744159 (OP)
Почему все дрочат на гомоиконность?
В чем ее профит?

>>744394
Ни в чем. Прикольно, синдром школьника, изучающего программирование.

>>744395
Но лисперы это же бородатые дяди, а не школьники.

>>744316
>это же был бы полный пиздец
А все потому что любое метапрограммирование должно быть только на уровне отдельного модуля, и никак не влиять на все внешнее окружение.

Грубо говоря, хочу я чтобы литерал [] инициализировался не каким-то дефолтным массивом, а специальной коллекцией -> подключаю какой-то модуль реализующий перегрузку -> при этом эта перегрузка будет работать только в том модуле, где была инициализированна, или вообще только в той области видимости.

Короче говоря, любые макро\мета извращения должны затрагивать только определенную часть кода, и никак не влиять на остальную.

>>744369
Ты много написал. Я буду краток.
>Целостность данных это не забота каких-то там других людей, а целиком и полностью твоя
Нет, пускай этим занимается провайдер PaaS или мой database engineer.
>целостность данных в оперативной памяти рантайма твоего кода
Полностью моя.
>Дело не только в реляционной модели...
Зачем ты мне это рассказываешь? Я изучал РМД в университете, ты вряд ли что-то новое мне расскажешь.
>SQL не просто формулирует простой вопрос к хранилищу, а позволяет делать крайне нетривиальные манипуляции и выводы на основе данных, и в императивном стиле ты это не напишешь
Ой, а ну наведи мне хотя бы три примера таких "нетривиальных анти-императивных задач". Максимум ты встретишь подобное на собеседованиях, за 8 лет опыта работы я не встречал ничего "нерешаемого" императивно ни разу.
>сделать язык запросов частью синтаксиса основного языка
>Можно ли гонять не строку а AST
Так нормальные ORM и работают. Только ORM должен быть частью языка (максимум — стандартной библиотеки), а не как sqlalchemy, например.

>>744394
В том, что ты можешь нести конструкции из других языков в свой.

>>744422
>любое метапрограммирование должно быть только на уровне отдельного модуля
все закончится на том, что твои извращения буду вынасить в отдельный модуль а-ля meta_tools и использовать его везде по кодбазе, чтобы не нарушать однородность кода.

>>744450
Явное лучше неявного.

>>744450
s/буду вынасить/будут выносить

>>744451
А что ты подразумеваешь под явным и неявным? Определения в лиспах (почти везде) тоже достаточно явные и подчиняются области видимости.

>>744453
Я не знаком с лиспом, если так, то славно.

Я вот примерно о чем.
Допустим я работаю в каком то модуле по большей части с массивом символов. У меня их много и они везде, что мне удобнее было бы иметь под них литерал. А еще лучше, чтобы литерал строки '' инициализировался по факту не в строку, а в массив символов.

Я явно подключаю какой-нибудь мета-модуль, котрый перегружает мне литерал, и дале все мои 'ololo' это не строка, а массив символов.
Но только в пределах области видимости этого модуля.

Ну или например я хочу, чтобы разные URI инициализировались в объекты в соотвествии со схемой. Я явно объявляю какой нибдь специальный литерал, и далее мои <file:/etc/some/file.ext> инициализируется в объект класса File с нужным path
а <http:google.com> <socket:/ololo> соотвественно HTTP и Socket.

>>744446
>Только ORM должен быть частью языка
ORM не должен быть частью языка. ORM не должен быть вообще. Нужно сделать так, чтобы мапить не пришлось. Там нет противоречий никаких, это миф. Так не делают не потому, что это неправильно, а потому, что развивалось всё независимо, и сейчас не хотят вкладываться в создание франкенштейна.

>Ой, а ну наведи мне хотя бы три примера таких "нетривиальных анти-императивных задач".
Ясно, человек не видевший SQL-запроса больше двух экранов. Самоуверенный даун из "веба".
Справедливости ради императивно, конечно, всё возможно можно сделать. На FoxPro, на монге...
>Так нормальные ORM и работают.
Что? Отправляют в соединение не SQL, а сериализованное дерево что ли? Прости, не слышал о таком. Хорошо, если уже сделали.

>>744457
1.То, что ты предлагаешь, скорее всего сломает семантику языка и это будет нереально подсвечивать нетьюринг-полным скриптам подсветки синтаксиса, например. А таких 95%.

2. Особого выиграша между new File("/etc/some/file.ext") и <file:/etc/some/file.ext> нет, только вот второе читается хуже и непонятно тому, кто не в курсах твоих мета-извращений.

>>744458
>человек не видевший SQL-запроса больше двух экранов
Восемь лет делаю веб-сервисы и сетевые приложениях, ни разу не встречал SQL запросы длиной больше 300 символов условно.
>Самоуверенный даун из "веба"
А ты занимаешься охуенно редкими и специфичными задачами? Тогда отлично, но мы сейчас не про охуенно редкие задачи, а про 99% решений в индустрии — CRUD, SaaS, объектные интерфейсы.
>Отправляют в соединение не SQL, а сериализованное дерево что ли?
Да нет, ORM берет твое дерево запроса и генерирует по нему (за константное время, кстати) SQL, получает ответ и по этому же дереву запроса строит ответ в заданной модели.

>>744446
>Целостность данных это не забота каких-то там других людей, а целиком и полностью твоя
>Нет, пускай этим занимается провайдер PaaS или мой database engineer.
Два чаю господину. Вся эта форейн-кий параша с констрейнтами и прочим консистенси бредом из 80х - задача других людей и разработчика вообще заботить не должно. Она нужна до какой-то степени, но это уже сфера ответственности специально обученных этой дрисне специалистов.

>>744463
>Да нет, ORM берет твое дерево запроса и генерирует по нему (за константное время, кстати) SQL
Маня, я знаю, как это работает. Не считай других за дебилов, особенно когда ты сам настолько туп, что даже не понял, что я имел ввиду.

>>744159 (OP)
Чёт я ни один из пунктов не понял совсем. Не зря говорят что правильно сформулированный вопрос содержит половину его решения. А здесь только "хочу больше и круче непонятно где и непонятно как".

>>744466
Да ты просто какие-то глупости для девятиклассников с серьезным говоришь, как мне тебя восприниматься всерьез?

>>744472
Вот у меня мышление где-то на уровне 9 класса и застряло, да. Я не виноват в твоем тугоумии и узости мышления.

>>744478
>У меня
>У тебя
фикс

>>744469
зачем ты этот высер от застрявших в прошлом веке SQL пенсионеров принес? неспособных освоить NoSQL и застрявших на устаревших технологиях ничего не спасет

>>744478
>>744482
LOL

>>744485
Да я тож посмеялся, но это не отменяет того факта, что ты макака без мышления.

>>744486
Если ты не понял, я не собираюсь поддерживать этот диалог.

>>744463
>человек не видевший SQL-запроса больше двух экранов
>Восемь лет делаю веб-сервисы и сетевые приложениях, ни разу не встречал SQL запросы длиной больше 300 символов условно.
А их и не бывает.

>>744487
>Если ты не понял, я не собираюсь поддерживать этот диалог.
Так та и не можешь его продолжить, ведь о предмете разговора у тебя, как выяснилось, никакого представления-то вообще нет. Да и позиции тоже никакой нет.
Тред можно закрывать.

Я так и не понял, какие-такие примитивы предлагает ОП вместо функций?

>>744521
Процедуры.

>>744534
И чем это будет отличаться от функций?
Процедура точно так же имеет имя и может принимать аргументы.

>>744521
Стрелки наверное

>>744159 (OP)
> - Почему если я хочу мало-мальски выразительно работать с AST собственной программы, то я обязательно должен подписываться на (ебалу cо (скобками [и больными людьми]))?
те в рантайме надо? ну дык в мейнстрим платформах (дотнет, явка) рефлексия более мене норм
или на этапе трансляции? так тоже в мейнстриме - clang+llvm для сишки с крестами, roslyn для дотнет..
ну а если нужен доступ как в лиспсемействе, то без ебанутой семантики и синтаксиса, извини, не обойтись

>>744563
Какие стрелки? Лямбды? Это те же функции.

>>744564
>ну а если нужен доступ как в лиспсемействе, то без ебанутой семантики и синтаксиса, извини, не обойтись
вот в этом и беда

>>744499
Неосилятор mongo? Как там за бортом жизни?

>>744598
нет, не в этом
а в том что лисп-макросы рушат доступ к ast

>>744614
ты адепт чего?

>>744159 (OP)
>- Почему если я хочу мало-мальски выразительно работать с AST собственной программы, то я обязательно должен подписываться на (ебалу cо (скобками [и больными людьми]))?
Tcl>>744159 (OP)
>- Почему в 2016 году мы все еще пишем код приемущественно на функциях, когда можно было бы использовать более интуитивные высокоуровневые примитивы?
Каждой предметной области по edsl'ю! Алан Кей с команой в этой области копает. Гугли STEPS, OMeta.
>>744159 (OP)
>- Почему ни один язык не позволяет легко писать GUI, а в лучшем случае нам приходится писать JS-подобный QML и связывать его с портянками на С++?
Tcl/Tk

ОП, попробуй smalltalk-среды, они отчасти решают некоторые из поднятых тобой вопросов (например, нормальное версионирование каждой единицы кода из коробки).

А в остальном понимаю твое нытье и присоединяюсь.

>>744698
ml-семейство

>>744369
>Оно не взлетело
Очень даже взлетело, и было дико популярно в 90-е, но потом было задушено майкрософтом.
https://ru.wikipedia.org/wiki/Visual_FoxPro

>>744761
Так не гуглится ничего. Скинь каких новостей по STEPS.

Бамп.

>>744343
> Вот ты можешь сейчас взять и безболезненно перевести свое приложение с MySQL на Postgres или с MongoDB на OrientDB, например? Не сможешь.
Эмм.. вообще-то могу

>>744159 (OP)
Всё правильно написал.
Есть две проблемы
- общественный характер производства и частнокапиталистическая форма присвоения продуктов труда. Т.е. грубо говоря каждый тащит одеяло на себя и вся индустрийка высрать ничего не может. До того момента конечно когда зайдёт действительно крупный монополист, потому что развивать тулзы не прибыльно. Но минус этого решения в том что всю армию кодерков сложно будет трудоустроить.
- образование. Частично исходит из первой проблемы. Пока дауны бросаются жопой на любую игрушку и не имеют собственного мнения конторка может форсануть своё говно и стричь купоны. Нужно прививать нормальные подходы.

В итоге имеем миллионную армию говноделов которые дальше своего болота не вылезают и каждый наступает на одни и те же грабли. Масштабы такие ахуительные что в пределах одного стойла не могут документировать для своих же или хотябы погуглить как пользоваться тулзой чтобы неделю не писать велосипед. Если это конечно не меры по job security, что исходит из первого пункта

>>744608
как там крестишься перед тем как делаешь дата миграцию ?
транзакции уже навелосипедил ?
как там джоины в аппликации ? есть гигабитный канал ?

>>744343
Да чего же ёбнутый дебил это писал. Блядь это даже не тролинг или дилетанство это блядь просто рак. Блядь ведь с такими приходится работать это же пиздец какой то. Мне даже лень разбираться этот ли пост или вся цепочка такая но это пиздец.

Выход видимо просто окуклиться и просто писать конкретные решения пока есть адекваты рядом. Пускай из 20 человек на всю планетку но этого достаточно

>>746437
Да пошел ты нахуй!

>>744159 (OP)
>Почему если я хочу мало-мальски выразительно работать с AST собственной программы, то я обязательно должен подписываться на (ебалу cо (скобками [и больными людьми]))?
Потому что хуита со скобочками это и есть AST. Вот так вот оно выглядит, это ваше AST. Сделаешь AST для программы не на лиспе - будет выглядеть точно так же. А если сделаешь что-то типа DOM, то всё равно не избежишь мыслей о лиспе, потому что твой AST будет превращаться в код на лиспе одним обходом дерева. То есть получится что ты написал транслатор из своего языка в лисп, только по религиозным причинам не дописал один метод на 20 строчек и поэтому лишил своё AST удобного текстового представления. AST без скобочек на получится, потому что, AST это дерево, и его запись должна отражать структуру этого дерева. Лисп гомоиконичен, это значит что структура его кода подобна структуре его AST. А знаешь как выглядит структура AST других языков? Точно так же! Хочешь работать с AST - привыкай к скобочкам.
Вот, вроде доходчиво объяснил.
>Почему если я хочу нормальную конкуррентность, то в лучшем случае мне парят допотопный CSP (почти сорок лет прошло, блядь!), а вместе с ним и низкоуровневою ебалу с каналами?
По-видимому ты включаешь в понятие "нормальную конкуррентность" и "в лучшем случае" столько, что отсекаешь все более современные высокоуровневые решения. Пока ты не объяснишь что ты имел в виду ответить на твой вопрос невозможно.
>Почему в 2016 году для отладки нет абсолютно ничего лучше брэйкпоинтов и отладочного вывода, а любые инструменты профилирования это обязательно невыносимая ебля?
ВМ типа JVM или CLR позволяют остановившись на брекпоинте добраться до каждого байтика пользовательских данных, просто клацая мышкой по полям классов. Потому что все "отладочные символы" присутствуют в программе в виде метаданных классов. Мало?
>Почему ни один язык не решает проблемы интеграции кода
Потому что это задача не уровня языка.
>я все еще пишу интеграционные тесты
Потому что ты не пишешь верифицированного кода или хотя бы контрактов.
>почему вокруг тестов надо творить такую синтаксическую ебалу?
В смысле?
>Почему в 2016 году мы все еще пишем код приемущественно на функциях, когда можно было бы использовать более интуитивные высокоуровневые примитивы?
Например?
>Почему обработка ошибок всегда размещается в основной логике кода, не отделяется от него в отдельный слой
Потому что тогда возникнет задача синхронизации слоёв, усложнится редактирование кода и поток управления нельзя будет проследить просто окинув взглядом исходник.
>Почему ни один язык не предлагает версионирование кода из коробки, а вместо этого нам предлагают ебаться с разношерстными пакетными менеджерами или вендорингом?
Потому что язык и версионирование это ортогональные вещи, не? Не совсем понятно что ты хочешь.
>Почему ни один язык не позволяет легко писать GUI, а в лучшем случае нам приходится писать JS-подобный QML и связывать его с портянками на С++?
Если ты жалуешься на explicit complexity, то приведи примеры того как язык усложняет то, что можно было бы сделать проще. Если у тебя проблема с implicit complexity то научись с этим жить.
>Почему off-by-one is a thing и для работы со списками нам не предложили ничего лучше жалких[:слайсов] или нечитаемого синтаксического мусора "для своих" а-ля Haskell?
От байтоёбли и императивности. 99% кейсов работы со списками сводятся к map, filter и reduce. Использовать их было бы проще, надёжнее, яснее и оптимизируемее. Но для этого надо иметь в языке лаконичный синтаксис для анонимных функций, а от этого у байтоёбов рвётся шаблон и болит голова. Ну да всё равно прогресс движется. Вон даже в джаву лямбды завезли потому что почуяли необходимость автораспараллеливания.
>Почему CRUD обязывает меня писать либо лапшу, либо замысловатые муторные обертки, а ничего лучше protobuf кодогенераторов не придумали?
Ты видимо представляешь CRUD как какую-то конкретную задачу. Я нет.
>Почему в 2016 году, на уровне кода, нас еще должно ебать какая "там" база данных, а для коммуникации нам не предложили ничего получше допотопного SQL хипстерского JSON, который не слышал о такой вещи, как integrity; почему я еще делаю миграции вручную?
Потому что ты не осилил ORM?

>>746560
>Потому что хуита со скобочками это и есть AS
Хуйню несёшь. Ни в одном аст нет тех скобочек, о которых ты говоришь.
>почуяли необходимость автораспараллеливания
Забавно, как функци-анальщики везде носятся со своим автораспараллеливанием, когда в реальности есть окамл, который синглотредовый со своим аналогом ГИЛа, а автоматически распараллеливать в это время пытаются лишь крестокомпиляторы.
инб4 фешарп.
Он не автоматически. Это либа. Она доступна и из других дотнетовских языков.
>Лисп гомоиконичен
Это значит, что пишут на нём гомосеки, которые молятся на него как на икону и зазывают морально не созревших людей в свою секту. Что мы по твоему, например, посту и видим.

>>746560
>Потому что хуита со скобочками это и есть AST.
А почему не json? Или еще какое представление деревьев текстом?
Но вообще AST типизирована, а лиспохуита - нет, это основное отличие.

>>744159 (OP)
1 - Наследие до опенсорсной эпохи. Исторически сложилось, что компилятор и средства работы с исходниками - закрытая для разработчиков вещь. Соответственно, кроме лиспа их нигде и не было.

>>746579
>Ни в одном аст нет тех скобочек, о которых ты говоришь.
Что насчёт этого AST: (+ 1 (* 2 3)) ?
>>746584
>Но вообще AST типизирована, а лиспохуита - нет, это основное отличие.
Эксперта за версту видать. Ну давай, неси пруфы, что untyped AST это не AST.

>>746613
>Что насчёт этого AST
Это не AST, это строка текста.

"- Почему в 2016 году для отладки нет абсолютно ничего лучше брэйкпоинтов и отладочного вывода, а любые инструменты профилирования это обязательно невыносимая ебля?"
привет от Xrebel даун

>>746584
>А почему не json? Или еще какое представление деревьев текстом?
потому что код в лиспе - это скобочки
но и ast имеет ту же форму - скобочки
поэтому с ast собственной программы работают с теми же средствами что и с самой программой

>>746619
Давай, ты сначала перестанешь путать данные и их представление, а потом мы снова об этом поговорим?
>>746751
Потому что код - набор байтов.
Но и картинка имеет ту же форму - набор байтов.
Поэтому кодить надо в графических редакторах.

>>746762
Мальчика-дауна мама первый раз привезла на море.
- Смотри, сынок, море.
- Где, мама?
- Да вот же оно, сынок!
- Где, мама?
- Да вот же, вот оно!!!
- Где, мама?
Мама берет его за руку, подводит к морю, и окунает его голову в море.
- Ой, что это, мама?
- Это море, сынок.
- Где, мама?

>>746762
>Потому что хуита со скобочками это и есть AST. Вот так вот оно выглядит, это ваше AST. Сделаешь AST для программы не на лиспе - будет выглядеть точно так же. А если сделаешь что-то типа DOM, то всё равно не избежишь мыслей о лиспе, потому что твой AST будет превращаться в код на лиспе одним обходом дерева. То есть получится что ты написал транслатор из своего языка в лисп, только по религиозным причинам не дописал один метод на 20 строчек и поэтому лишил своё AST удобного текстового представления. AST без скобочек на получится, потому что, AST это дерево, и его запись должна отражать структуру этого дерева. Лисп гомоиконичен, это значит что структура его кода подобна структуре его AST. А знаешь как выглядит структура AST других языков? Точно так же! Хочешь работать с AST - привыкай к скобочкам.

>>746773
>>746584

>>746828
Ага, эпичный обосрамс, я видел.

>>744159 (OP)
>Почему если я хочу мало-мальски выразительно работать с AST собственной программы, то я обязательно должен подписываться на (ебалу cо (скобками [и больными людьми]))?
Потому что так твой твой код лучше воспринимается как каноничный AST, его воспринимать проще, он более однозначен. С чистым AST работать сложно, потому на место Лиспа пришел Кобол, который ближе к человеческой речи, и который приводится к AST. На первом курсе учат
>- Почему в 2016 году для отладки нет абсолютно ничего лучше брэйкпоинтов и отладочного вывода, а любые инструменты профилирования это обязательно невыносимая ебля?
Ну а как хотелось бы? "По щучьему веленью, по моему хотенью, ошибка в логике - проявись!" А профайлеры работают близко к ОС, это инструменты профессионалов, потому и выглядят так, как будто их писал Столлман в средине девяностых. Удобство работы с профайлерами - не самая главная проблема в профессиональной разработке.
>- Почему в 2016 году мы все еще пишем код приемущественно на функциях, когда можно было бы использовать более интуитивные высокоуровневые примитивы?
Какие такие? Почему функции неинтуитивны?
>- Почему обработка ошибок всегда размещается в основной логике кода, не отделяется от него в отдельный слой, а в лучшем случае нам предлагают либо разворачивать эксепшонами стэк, либо if err != nil а-ля Cи?
Дают маленькому ребенку тетрадку с примерами и говорят: "Решай". Как лучше его контролировать: каждую секунду лезть под руку и спрашивать не накосячил ли он, сравнивать результат после каждой задачи или разрешить звать маму, если что-то не получается или идет не так?
>>err != nil
Это на уровне goto, да, но работает даже на тех платформах, где нету поддержки ООП.
>Почему ни один язык не предлагает версионирование кода из коробки, а вместо этого нам предлагают ебаться с разношерстными пакетными менеджерами или вендорингом?
Это пошло с мира Юникс, где каждая утилита делает по чуть-чуть, но только свое.
Вам запаковать джаву вместе с гитом и обозвать гит Джава Версионинг Фреймворк?
>- Почему ни один язык не позволяет легко писать GUI, а в лучшем случае нам приходится писать JS-подобный QML и связывать его с портянками на С++?
Вот это есть такое, да. Реализация десктопного интерфейса предполагает пердолинга. Qt ещё не так и плох. gtk может быть лучше, но там тоже всё сложно. wxWidgets наел щечки!
>- Почему в 2016 году, на уровне кода, нас еще должно ебать какая "там" база данных, а для коммуникации нам не предложили ничего получше допотопного SQL хипстерского JSON, который не слышал о такой вещи, как integrity; почему я еще делаю миграции вручную?
Есть PDO и ODBC, которые должны быть универсальны, но то, как они реализованы - это другой вопрос.

>>744358
>tfw println не является thread-safe
>tfw операции ввода-вывода запускают отдельный поток, который ну совсем не зависит от того, где операция была заявлена
>tfw операции вывода буферизируются и выдают результат тогда, когда посчитают нужными.

>>745138
Другую хуиту имел в виду, но не могу вспомнить. Там приличный обыкновенный ооп язык, и в этом же синтаксисте (и в этом же рантайме) работа с полноценной СУБД.
Что-то вроде рантайма хранимок но в очеловеченном виде.

>>744343
> Вот ты можешь сейчас взять и безболезненно перевести свое приложение с MySQL на Postgres или с MongoDB на OrientDB, например? Не сможешь.
Такая кретинская постановка вопроса. Ты о реляционных бд вообще представление имеешь? Нет? Совсем никакого? Понятно тогда.

>>746360
> Эмм.. вообще-то могу
Еще один дилетант. Как вы работаете вообще...

>>744463
> Восемь лет делаю веб-сервисы и сетевые приложениях, ни разу не встречал SQL запросы длиной больше 300 символов условно.
Ахахахахахаха вот это пушка

>>746893
> быдло не знает про orm

>>747066
Нет, маня, про orm я более чем прекрасно знаю, и неоднократно в прошлом переносил проекты с orm между разными rdbms. Так быдло - это ты.

>>747066
Кукаретик уровня laba1, претендент на джуниора? И хуле orm?
1) Нативный SQL которого дофига (т.к. на ссаных hql/dql эти запросы не напишешь) придется весь переписывать
2) типы доступных констрейнтов другие, поведение другие, возможности разные
3) типы доступных индексов другие, возможности разные, т.е. может потребоваться схему существенно изменить и попять дохуя переписывать
4) хранимки все переписать, плюс возможности совершенно разные
5) триггеры все переопределить, опять же возможности совершенно разные
6) доступные типы данных другие или аналоги работаю иначе, т.е. переписывать возможно с с существенным изменением схемы
7) механизмы тех же стандартных вещей типа полнотекстового поиска другие, синтакс другой, принципы другие
8) возможности у баз данных совершенно разные - т.е. пол проекта может потребоваться переписать если не больше
9) свои самодельные расширения orm тоже придется переписать (маппинги те же)
10) и еще овердохуя других моментов
И чо бля orm твой?
Проигрываю с вас, такие все выёбистые, а на деле просто болтуны, нули полные.

>>747121
>логика внутри БД
ясно, понятно

>>747121
Абсолютно все твои проблемы высосаны из пальца. + ты юзал хуевую орм + ты зачем-то пишешь sql, когда используешь орм

>>747108
> про orm я более чем прекрасно знаю, и неоднократно в прошлом переносил проекты с orm между разными rdbms
И к чему ты это сказал?

>>746762
https://en.wikipedia.org/wiki/Homoiconicity
на, жри, неуч

>>744159 (OP)
Потому что НИНУЖНО. Было бы нужно, ты бы первый побежал всё это запиливать. Некоторое из того, что ты упомянул, есть, но ты об этом не слышал – настолько оно не нужно.

Более того, был уже такой чел. Говорил, хочу йобу, она всех порвёт. Ему запилили эту йобу. Угадай, что он ответил.

>>747177
>Абсолютно все твои проблемы высосаны из пальца. + ты юзал хуевую орм + ты зачем-то пишешь sql, когда используешь орм
Просто угораю над вами дилетантами.

>>747121
>2016 год
>аутсайдеры неспособные вкурить наконец носкл и не желающие осваивать новое

>>747278
NoSQL исторически появился раньше SQL-а, собственно весь ынтырпрайз до 70-х им в жопу и долбился. Потом британский ученый изобрёл теорию РБД, появление которой привело к немедленному выметанию всего этого ёбаного хаоса с рынка, стандартизации и тотальному овладиванию SQL-а в рекордно короткие сроки. Побочным эффектом стало то, что всякое быдло начало пихать SQL туда, где он не очень-то и нужен, и очень, блядь, страдать, от того, что их гостевухи стали долго загружаться. Потом кто-то сделал фундаментальное открытие - оказывается хранить профили пользователей гостевухи в хешь-таблице в памяти и доставать их оттуда по имени гораздо быстрее, чем реализовывать EAV поверх РБД. После этого переворота в мозгах гостевушников они приняли радостно сверкать новым базвордом по своим блогам и хабро-хабрикам, радуясь, что им в очередной раз удалось повернуть стрелку прогресса вспять и укусить себя за жопу.

>>747121
ОП спросил:
> Почему в 2016 году, на уровне кода, нас еще должно ебать какая "там" база данных
Ну вот потому и должно, что они все разные. Если закладываться на наименьший общий делитель (SELECT huy FROM pizda) тогда с ORM'ами (и разумным количеством тестов) всё прекрасно портируется. А если закладываться на фичи конкретного продукта, то и сиди жри этот продукт тогда.

>>747320
ты ошибаешься.
1) анси недостаточен (я не буду ждать когда - через 20 лет - там появятся нужные типы, деревья и операции над ними, геометрические данные и операции, географические типы и операции и еще много-много-много включая расширения процедурного языка и синтаксические и прочие мелочи коих миллион и без них нельзя)
2) даже то, что стандарт - бывает реализовано по-разному
3) твой ебучий ловест камон деноминатор сильно< чем стандарт. мне оценить трудно, но если учесть, что помимо нормальных бд существуют mysql, sqlite и всякие файрберды, то...
4) сама идея того, что возможность перехода с одной бд на другую обязана быть - ебанашкин бред. код написанный под интерпретатор php не работает на интерпретаторе python и вроде все довольны (можно сделать надъязык и транслировать, такая же глупость как orm будет) схуя, завидев ansi стандарт требуют того же от субд? потому что он есть что ли? ну это глупость.

т.е. и стандарт и даже сабсет столь малы, что для реальных задач недостаточен, но они всё равно больше чем эти ссаные мапперы могут переварить (позволить нормально работать)

>>747320
В том-то и дело, что в наиболее благоприятном для ORM случае, куда лучше всё что угодно, но не точно не СУБД c SQL: xml/json-файлы, db4o, NoSQL.

>>746835
Похоже, ты специально путаешь, чтобы вилять проще было. Ок, пойдём с начала и подробно.
>Потому что хуита со скобочками это и есть AST
Вот это конкретное утверждение есть наглый неприкрытый пиздёж лиспосектанта. Это утверждение ложно. Вместо "скобочки - одно из представлений аст", вместо "скобочки - удобное представление аст" (что тоже ложно, но чуть менее бредово, ибо кому-то и правда может быть удобно) ты заявил, что "скобочки = аст". Прежде чем снова вилять, покажи мне хоть одну скобочку в следующем "аст":
"+"
- 1
- "*"
-- 2
-- 3
И, да, пожалуйста не комментируй моё "удобное представление" выдёргивнием слов из контекста, как ты уже сделал вот здесь >>746773. Где на пять "релевантных" слов(осочетаний) только два имеют тот смысл, который ты в них вкладываешь, и одно из этих двух в другом контексте и, опять же, ложно.

>>747431
>Потому что хуита со скобочками это и есть AST
>Это утверждение ложно.
>Потому что хуита со скобочками это и есть AST. Вот так вот оно выглядит, это ваше AST.
Дальше я пояснил, что имел в виду. И рассмотрел, кстати, случай с
>что-то типа DOM
Так что это ты у нас страдаешь
>выдёргивнием слов из контекста

>Прежде чем снова вилять
>Но вообще AST типизирована, а лиспохуита - нет, это основное отличие.
Ну ты-то у нас не виляешь, ты тупо набрасываешь новый текст, надеясь что твои старые сливы забудут.

>Где на пять "релевантных" слов(осочетаний) только два имеют тот смысл, который ты в них вкладываешь
Конкретизируй предъяву.

>ты заявил, что "скобочки = аст"
Я писал свой ответ в контексте ответа на твой вопрос
>Почему если я хочу мало-мальски выразительно работать с AST собственной программы, то я обязательно должен подписываться на (ебалу cо (скобками [и больными людьми]))?
соответственно я не рассматривал непрактичные формы представления AST, а лишь те, которые удовлетворяют условию "я хочу мало-мальски выразительно работать с AST собственной программы".
Кроме того я предположил что говоря про "(ебалу cо (скобками" ты имел в виду лиспы вообще, а не конкретно те, в которых есть круглые скобки.
Предположил я это потому что думал что ты имеешь хотя бы общее представление о том, о чём говоришь. Похоже ты его не имеешь. Это делает ответ на твой вопрос тривиальным
Q:Почему если я хочу мало-мальски выразительно работать с AST собственной программы, то я обязательно должен подписываться на (ебалу cо (скобками [и больными людьми]))?
A:Возьми лисп с синтаксисом без скобочек, типа http://srfi.schemers.org/srfi-49/srfi-49.html и радуйся жизни.

>>744458
>ORM не должен быть частью языка. ORM не должен быть вообще. Нужно сделать так, чтобы мапить не пришлось. Там нет противоречий никаких, это миф. Так не делают не потому, что это неправильно, а потому, что развивалось всё независимо, и сейчас не хотят вкладываться в создание франкенштейна.
Двачую. Нас спасут объектно ориентированные СУБД.

>>745691
>>745691
http://www.vpri.org/html/writings.php
Ищи тут

>>749547
есть примеры таких систем юзабельных?

>>749547
Хуйню сказал. Очень маленький процент данных имеют объектную природу. Обычно это реляционная параша или графы.

>>749913
Нет, потому что это глупость. inb4: графовые бд

>>752465
Объекты это частный случай графов.

>>752471
Ничего подобного. Граф — это структура данных, а объект — способ организации данных.

>>749547
Объекты - хуйня из под коня, ебучее шаманство с is vs has, SOLID и прочим обливанием мочой и заряжанием баночек, вместо обоснованной и формализованной реляционной БД с нормализацией.

>>744159 (OP)
> Почему в 2016 году мы все еще пишем код приемущественно на функциях, когда можно было бы использовать более интуитивные высокоуровневые примитивы?
Это например? Чем тебе методы объектов с нормальными названиями не угодили?

> Почему в 2016 году, на уровне кода, нас еще должно ебать какая "там" база данных, а для коммуникации нам не предложили ничего получше допотопного SQL хипстерского JSON, который не слышал о такой вещи, как integrity;

Предложили - ORM.

> почему я еще делаю миграции вручную?
Ну EF шарповский, например, вполне себе умеет автоматом генерить код для миграций. Получается, в основном, достаточно хорошо.

> Почему ни один язык не позволяет легко писать GUI

Пока не могу придумать вариантов описания UI в каком-то *ML, + wysiwyg редактора формачек к нему.

> Почему обработка ошибок всегда размещается в основной логике кода, не отделяется от него в отдельный слой, а в лучшем случае нам предлагают либо разворачивать эксепшонами стэк, либо if err != nil а-ля Cи?

Этот слой ты, вообще говоря, можешь сделать сам.

> Почему ни один язык не предлагает версионирование кода из коробки, а вместо этого нам предлагают ебаться с разношерстными пакетными менеджерами или вендорингом?

Потому что это входит в функциональность системы контроля версий, а не языка.

>>744159 (OP)
> - Почему CRUD обязывает меня писать либо лапшу, либо замысловатые муторные обертки, а ничего лучше protobuf кодогенераторов не придумали?
> - Почему в 2016 году, на уровне кода, нас еще должно ебать какая "там" база данных, а для коммуникации нам не предложили ничего получше допотопного SQL хипстерского JSON, который не слышал о такой вещи, как integrity; почему я еще делаю миграции вручную?

Spring Data с высоты абстракции ссыт тебе в лицо мочой прозрения.

Король веб-девелопмента в треде. Задавайте свои вопросы.

>>756566
Какие самые типовые проекты у тебя лично? Что самое рутинное, а что самое интересное в процессе разработки?

> Пока не могу придумать вариантов описания UI в каком-то *ML, + wysiwyg редактора формачек к нему.
Xaml + студийный дизайнер к нему. Как язык разметки - топ.

>>744159 (OP)
Почему ты еще не осилил Haskell?

>>756616
Ты какой-то дебил. Половина требований к переносимому ассемблеру как к вычокоуровенному языку, ахуеть теперь.

>>756616
UPD
7. Нельзя определить тип перечислений.(ахтунг)
8. Регулярочки из коробки.
9. Вернуть через стек боллее одной переменной.сомнительно, но дайте мне это сделать!

>>756617
Обоснуй по пунктам, где проблема?
Это инструмент и он должен быть удобным.
Если бы хипстеры меньше задрачивали новомодные высокоуровневые элитарные новомодные парадигмы а просто писали стандартную либу - мир был бы лучше.

>>756616
Объектно-ориентированный Си дальше по коридору.

>>756626
Возьми и сам напиши епта.

>>756656
Где там хоть намек на ООП?

>>756626
>Обоснуй по пунктам, где проблема?
Давай, обосновываю:
когда C создавался, требования были другие, и всё.
>Это инструмент и он должен быть удобным.
Он и без того самый удобный инструмент для написания низкоуровенного кода.
>мир был бы лучше
Мир лучше именно от того что они создают новое - нахуя копаться в старом дерьме?

Посмотри что происходит в мире стандартизации C++. Там даже модули уже несколько лет не могут принять, и судя по всему ближайшие 5 лет не примут - не могут развернуться в куче своего же легасиговна.

>>756624
>7. Нельзя определить тип перечислений.(ахтунг)
С++, Rust.
>8. Регулярочки из коробки.
С++, Rust.
>9. Вернуть через стек боллее одной переменной.
Rust, С++ с помощью STL.
>>756616
>за пределами модуля
Вот тут кек, но всё же Rust.
>2. Почему в С нет ебаных ассоциативных массивов из коробки?
Потому что это переносимый между компиляторами и платформами, сука, ассемблер. Только в стандартных библиотеках плюсов с растом, из коробки только в более высокоуровенном говне вроде свифта о да, 12 часов компиляции.
>3. Почему каждый комиплятор реализует инлайн ассемблер через жопень?
Чому это кто-то должен стандартизовать? Под каждую платформу каждый реализует кто как видит.
>с подсветкой синтаксиса
В нормальном текстовом редакторе. Хотя это говно уровня пхп+хтмл, ну лан.
>полныйконтрль регистр<->переменная
Он и без того есть (асм и __асм в студии к примеру).
>Где УДОБНЫЙ механизм обработки ошибок
С++, Rust.
>Где сука, богатый функционал стандартной библиотеки?
В яве.

>>756569
>>756506
> Пока не могу придумать лучше вариантов
Я там слово потерял, и не знаметил. А так да, вот например wpf

>>756663
>когда C создавался, требования были другие
Когда лисп создавался, требования были другими. И ему не помешало, почему-то.
>Он и без того самый удобный инструмент для написания низкоуровенного кода
Сказал человек, ассемблера не видавший.

>>757312
>И ему не помешало, почему-то.
Так он и поныне самый убогий из фп языков. Хотя, если пораскинуть мозгами – лисп времён си уже давно умер, все современные форки младше даже плюсов.
>Сказал человек, ассемблера не видавший.
Ассемблер-то видал, задач где удобнее написать на нём чем на си – нет. Разве что всякие переключения контекста и SIMD хуита, где без него никак.

>>756616
> 2. Почему в С нет ебаных ассоциативных массивов из коробки?
Вот здесь двачую, за полвека почти байтоебы так и не написали ничего подобного крестовой STL.

>>757318
>задач где удобнее написать на нём чем на си – нет
Абсолютно любая низкоуровневая задача. Хотя бы потому, что ты всегда знаешь, сколько байт у тебя инт, какое где выравнивание, и нигде не проебёшься с sizeof.
Возможно, ты имел в виду кроссплатформенный низкоуровневый код, тогда да - там только сишка. Но это как с пустыней - ты будешь пить мочу не потому, что она охуенна, полезна и вкусна, а просто другой воды нет.

>>757364
>Хотя бы потому, что ты всегда знаешь, сколько байт у тебя инт, какое где выравнивание, и нигде не проебёшься с sizeof.
Если ты пишешь кроссплатформенный код на си, то ассемблеру засчитывается техническое поражение за неявку на поединок.
Если ты пишешь код на си под конкретную архитектуру, то ты должен знать её специфику.
В пределах одной архитектуры сишный код намного проще чем ассемблерный портируется с одной ОС на другую. Чем не удобство?

>>744159 (OP)
>работать с AST собственной программы
Scala же

>>744369
Ты имеешь в виду денотационную семантику SQL? SQL-ный синтаксис - это параша параш, я любой проект, который связан с РСУБД, начинаю с написания генератора запросов SQL.

>>758276
У вас хэловорлд компилируется пол часа, господин.

>>760121
Как что-то плохое.
Запустил компиляцию, и пошел на перекур. Лампота.

>>760123
Ходить на перекур во время каждой перекомпиляции из-за пропущенной скобочки/пропущенного символа в шестизначном операторе из скалыз/шапелеса/др. хуитка – от рака лёгких сдохнешь через недельку.

>>760129
IDE должна подчеркнуть их красным ещё до компиляции.

>>760148
1) IDE – не манна небесная, подчеркнёт только конкретно грубые синтаксические ошибки. А от самых "тонких" тут легендарный пример со складыванием листов тебя не спасёт даже компилятор.
2) На больших проектах анализ кода приходится банально отключать – или нужен сервер чтобы их редактировать.

>>760129
>>760178
Скорость компиляции конечно не самая сильная сторона скалы хотя есть проблемы и посерьёзнее, но вы, дебики, вообще не представляете о чем говорите.

>>760025
Вот да. Почему почему все NoSql пытаются избавиться от реляционной модели, а не от sql?

>>760288
>>747283

>>760256
Мне кажется, это твоя мамаша не представляла что делает.

бамп