Исходное сообщение fixin

Исходное сообщение UnCens0red: fixin да лаймер ты )
ты просто отсос полный.
и нех тут трендеть мол мы тут в неадеквате,помойму ты что то напутал :D

С такими выражениями неадекват - это вы, по моему. ;-)

LI 5.09.15

И всеж терапия доктора Димона действует, вон какой ты стал примерный, начальство небось не одну рейку обламало об твою сраку.., теперь паинька, ни одного плохого слова.., глядишь лет через 5 будешь нормальным человеком..., вот только ориентацию на гетеро ты наверно уже не сменишь, так и будешь ГОМО...,

ЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫ.....

О, кстати, Сергей! У меня к Вам предложение! Давайте Вы признаете, что Ваше заявление, что для трансляции запроса достаточно регулярных выражений, не соответствует действительности и было сделано потому, что Вы не разбираетесь в теме.

fixin,

Исходное сообщение snakeye: О, кстати, Сергей! У меня к Вам предложение! Давайте Вы признаете, что Ваше заявление, что для трансляции запроса достаточно регулярных выражений, не соответствует действительности и было сделано потому, что Вы не разбираетесь в теме.

А где вы видели такое заявление? гыгыгы. Процитируйте дословно. Особенно слово ДОСТАТОЧНО. ;-)
В колонках играет: 056 ЧОРНА РЕДЬКА {056 ЧОРНА РЕДЬКА}

LI 5.09.15

Да лааадно, неадекваное!! Да я таких имбицилов никада не встречал... у нас в инсте много всяких ходит, но чтоб такое убожество!
Респект тебе, заводишь народ!

Ну еще бы http://www.mazzy.ru/ указал.

кстати, fixin, несколько квалифицированных и сертифицированных IT-специалистов утверждают, что твой профессиональный уровень крайне невысок, но понтов при этом выше крыши. Твои невежественные высказывания, сопровождаемые гыгыканьем породили несколько прямых несложных вопросов. Потрудитесь ответить, сделайте милость...
_________________________________________
кстати, всем новым посетителям данного дневника категорически рекомендуется прочитать этот пост для получения достаточно целостного представления о fixin-е

А где вы видели такое заявление? гыгыгы. Процитируйте дословно. Особенно слово ДОСТАТОЧНО. ;-)

Ну как же...

Парсер - это хуйня. Теория компиляторов давно проработана, надеюсь ты не изобретал велосипед и юзал регулярные выражения? Гыггыы.

Это не работа с СУБД, это работа со строками.

Написание трансляторов - это хуйня, много ума не надо, из одного стандарта в другой.

Трансляция запроса - это из области компиляторов.

Согласен, что слова "достаточно" в цитатах нет, но из них можно сделать вполне однозначный вывод, что Вы считаете трансляцию объектных запросов в реляционные несложной текстовой задачей, выполнимой исключительно регулярными выражениями.
Возможно, я ошибаюсь, и эта задача действительно решается регулярными выражениями. В таком случае я был бы рад, если бы Вы указали мне на мои ошибки.

Исходное сообщение snakeye:

А где вы видели такое заявление? гыгыгы. Процитируйте дословно. Особенно слово ДОСТАТОЧНО. ;-)

Ну как же...

Парсер - это хуйня. Теория компиляторов давно проработана, надеюсь ты не изобретал велосипед и юзал регулярные выражения? Гыггыы.

Это не работа с СУБД, это работа со строками.

Написание трансляторов - это хуйня, много ума не надо, из одного стандарта в другой.

Трансляция запроса - это из области компиляторов.

Согласен, что слова "достаточно" в цитатах нет, но из них можно сделать вполне однозначный вывод, что Вы считаете трансляцию объектных запросов в реляционные несложной текстовой задачей, выполнимой исключительно регулярными выражениями.
Возможно, я ошибаюсь, и эта задача действительно решается регулярными выражениями. В таком случае я был бы рад, если бы Вы указали мне на мои ошибки.

Гыгыгы, какие то неправильные у вас выводы.
Слова достаточно нет, так что не галлюцинируйте по поводу моих мыслей.
Давайте будем о фактах, гыгыгы..
В колонках играет: 156 ОЙ, НЕ БУЛО Б ЛИХА {156 ОЙ, НЕ БУЛО Б ЛИХА}

LI 5.09.15

Гыгыгы, какие то неправильные у вас выводы.
Слова достаточно нет, так что не галлюцинируйте по поводу моих мыслей.
Давайте будем о фактах, гыгыгы..

А по существу вопроса Вы ничего не хотите сообщить?

Исходное сообщение snakeye:

Гыгыгы, какие то неправильные у вас выводы.
Слова достаточно нет, так что не галлюцинируйте по поводу моих мыслей.
Давайте будем о фактах, гыгыгы..

А по существу вопроса Вы ничего не хотите сообщить?

Что именно? То что написание конкретных приложений для СУБД я считаю более сложным и менее формализированным занятием, чем написание компиляторов, где исходные и конечные данные четко формализированы?
В колонках играет: 176 Де, де, де {176 Де, де, де}

LI 5.09.15

Что именно? То что написание конкретных приложений для СУБД я считаю более сложным и менее формализированным занятием, чем написание компиляторов, где исходные и конечные данные четко формализированы?

Начнём с малого.

Вы согласны с тем, что задача перевода запроса сложнее, чем обработка текстовых строк и регулярных выражений для её решения недостаточно?

Исходное сообщение snakeye:

Что именно? То что написание конкретных приложений для СУБД я считаю более сложным и менее формализированным занятием, чем написание компиляторов, где исходные и конечные данные четко формализированы?

Начнём с малого.
Вы согласны с тем, что задача перевода запроса сложнее, чем обработка текстовых строк и регулярных выражений для её решения недостаточно?

Ага, сложнее. А что вы подразумеваете под обработкой текстовых строк?
Регулярных выражений однозначно недостаточно.
Но сложнее не на много.
В общем написание компилятора на данном уровне теории - тривиальная задача.

LI 5.09.15

Ага, сложнее.

Отлично!

А что вы подразумеваете под обработкой текстовых строк?

Нет-нет, это как раз вопрос к Вам, следующий. Что Вы подразумеваете под "Это не работа с СУБД, это работа со строками"?

Регулярных выражений однозначно недостаточно.

Отлично!

Но сложнее не на много.
В общем написание компилятора на данном уровне теории - тривиальная задача.

Ничего-ничего, потихоньку разберёмся, насколько тривиальная и насколько сложнее.

Исходное сообщение snakeye:

Ага, сложнее.

Отлично!

А что вы подразумеваете под обработкой текстовых строк?

Нет-нет, это как раз вопрос к Вам, следующий. Что Вы подразумеваете под "Это не работа с СУБД, это работа со строками"?

Регулярных выражений однозначно недостаточно.

Отлично!

Но сложнее не на много.
В общем написание компилятора на данном уровне теории - тривиальная задача.

Ничего-ничего, потихоньку разберёмся, насколько тривиальная и насколько сложнее.

нуну. ;-)

LI 5.09.15

нуну. ;-)

Вы, наверное, невнимательно читали. Там был вопрос к Вам:

Что Вы подразумеваете под "Это не работа с СУБД, это работа со строками"? Применительно к трансляции запросов, если Вы вдруг потеряли нить беседы.

Исходное сообщение snakeye:

нуну. ;-)

Вы, наверное, невнимательно читали. Там был вопрос к Вам:
Что Вы подразумеваете под "Это не работа с СУБД, это работа со строками"? Применительно к трансляции запросов, если Вы вдруг потеряли нить беседы.

Ну вы же не храните ничего в СУБД, вы просто один текст преобразуете в другой по жестким правилам.

LI 5.09.15

Ну вы же не храните ничего в СУБД, вы просто один текст преобразуете в другой по жестким правилам.

Заблуждение. Во-первых, в СУБД хранится схема данных - разбиение классов на реляционные таблицы, кратности связей и т.п. Во-вторых, в СУБД хранятся таблицы прав доступа к отдельным объектам и даже к отдельным полям объектов. Согласны?

Далее, система работает прозрачно для пользователя на MSSQL и ORACLE. Запрос для каждой СУБД нужно строить с учётом соответствующего диалекта SQL, особенностей соответствующего сервера БД, да и семантику каждого конкретного запроса тоже нужно учитывать. Согласны?

На случай невнимательности - тут два вопроса.

Исходное сообщение snakeye:

нуну. ;-)

Вы, наверное, невнимательно читали. Там был вопрос к Вам:
Что Вы подразумеваете под "Это не работа с СУБД, это работа со строками"? Применительно к трансляции запросов, если Вы вдруг потеряли нить беседы.

т.е. компилятор - это не приложение для работы с СУБД и даже не столько для работы с файлами.

LI 5.09.15

т.е. компилятор - это не приложение для работы с СУБД и даже не столько для работы с файлами.

Очевидно, что я имею в виду случай, когда транслятор запросов является подсистемой платформы, построенной на реляционных БД. Вы готовы отказаться от своего поспешного заявления?

Исходное сообщение snakeye:

т.е. компилятор - это не приложение для работы с СУБД и даже не столько для работы с файлами.

Очевидно, что я имею в виду случай, когда транслятор запросов является подсистемой платформы, построенной на реляционных БД. Вы готовы отказаться от своего поспешного заявления?

Нет. Ваше уточнение не меняет сути. Вы можете поручить свой компилятор написать кодеру, который не умеет даже коннектиться к базе, а только обрабатывает строки. У вас нарушение логики!


LI 5.09.15

Исходное сообщение snakeye:

Ну вы же не храните ничего в СУБД, вы просто один текст преобразуете в другой по жестким правилам.

Заблуждение. Во-первых, в СУБД хранится схема данных - разбиение классов на реляционные таблицы, кратности связей и т.п. Во-вторых, в СУБД хранятся таблицы прав доступа к отдельным объектам и даже к отдельным полям объектов. Согласны?
Далее, система работает прозрачно для пользователя на MSSQL и ORACLE. Запрос для каждой СУБД нужно строить с учётом соответствующего диалекта SQL, особенностей соответствующего сервера БД, да и семантику каждого конкретного запроса тоже нужно учитывать. Согласны?
На случай невнимательности - тут два вопроса.

В Субд хранится схема данных, да, согласен.

И по второму вопросу согласен.

Но написание компилятора - это не работа с СУБД.

Это все равно что сказать, что написание компилятора языка Си означает глубокие познания в применении языка Си во всех прикладных областях.

Извините, вы заблуждаетесь.

Вы не видите очевидной разницы. В компиляторе все условия формализованы и заданы. В разработке приложения все нечетко, нужно принимать больше решений, следовательно больше труда. Надеюсь, это понятно?!

Вы еще скажите, что написание драйверов - это верх программирования. ;-)

LI 5.09.15

Исходное сообщение fixin
Но написание компилятора - это не работа с СУБД.

Это все равно что сказать, что написание компилятора языка Си означает глубокие познания в применении языка Си во всех прикладных областях.

Извините, вы заблуждаетесь.

Вы не видите очевидной разницы. В компиляторе все условия формализованы и заданы. В разработке приложения все нечетко, нужно принимать больше решений, следовательно больше труда. Надеюсь, это понятно?!

Вы еще скажите, что написание драйверов - это верх программирования. ;-)

Ну что-же, вставлю свои 5 копеек.
Во первых в бизнес-приложениях обычно тоже все условия формализуются и задаются, занимаются этим специальные люди, называемые Аналитиками и Проектировщиками

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

В третьих, возвращаясь к приведённому вами примеру языка С не забывайте, что сам язык С (синтаксис, семантику) необходимо было придумать и спроектировать. Так-же как и синтаксис/семантику исходного языка запросов с которого происходит трансляция.

Сергей?

Вы можете поручить свой компилятор написать кодеру, который не умеет даже коннектиться к базе, а только обрабатывает строки. У вас нарушение логики!

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

В Субд хранится схема данных, да, согласен.

Отлично!

И по второму вопросу согласен.

Отлично!

Но написание компилятора - это не работа с СУБД.

В данном случае это была работа со строками, работа с внутренней объектной моделью, работа с СУБД.

Это все равно что сказать, что написание компилятора языка Си означает глубокие познания в применении языка Си во всех прикладных областях.

Ну как же! Проектирование синтаксиса и семантики языка начинается с исследования предполагаемой области применения. А потом уже пишется компилятор. И это, заметьте, тоже выходит за рамки регулярных выражений. Есть возражения?

Вы не видите очевидной разницы. В компиляторе все условия формализованы и заданы. В разработке приложения все нечетко, нужно принимать больше решений, следовательно больше труда. Надеюсь, это понятно?!

Чтобы условия были формализованы и заданы, эти условия кому-то нужно формализовать и задать. Это касается как разработки приложения, так и, в равной степени, разработки синтаксиса и семантики языка.

Вы еще скажите, что написание драйверов - это верх программирования. ;-)

Я не знаю, что такое "верх программирования". Есть различные прикладные области, есть задачи разной сложности.

Но, не будем уходить от главной темы. Следующий вопрос. Следует ли понимать слова "Это не работа с СУБД" как "Необходимости разбираться в тонкостях работы с СУБД нет, всё описывается неким стандартом?"

Сделаем небольшой протокол:

Исходные заявления:

Парсер - это хуйня. Теория компиляторов давно проработана, надеюсь ты не изобретал велосипед и юзал регулярные выражения? Гыггыы.

Это не работа с СУБД, это работа со строками.

Написание трансляторов - это хуйня, много ума не надо, из одного стандарта в другой.

Трансляция запроса - это из области компиляторов.

Ок, в ходе обсуждения:

Вы согласны с тем, что задача перевода запроса сложнее, чем обработка текстовых строк и регулярных выражений для её решения недостаточно?

Ага, сложнее. Регулярных выражений однозначно недостаточно.

В Субд хранится схема данных, да, согласен.

Запрос для каждой СУБД нужно строить с учётом соответствующего диалекта SQL, особенностей соответствующего сервера БД, да и семантику каждого конкретного запроса тоже нужно учитывать. Согласны?

согласен