Здравствуйте, VladD2, Вы писали:
G>>Простой, практичный, и удобный язык. Это в наши времена — большая редкость. Люди давно забыли, как делать простые и удобные вещи, и перестали из ценить. А зря.
VD>Сдается мне понятия простой и удобный весьма многогранны. Так что они ровным счетом ничего не выражают.
Для тебя — ничего. Для меня — выражают достаточно много. Спорить об этом не вижу смысла. Есть вещи, которые человек либо понимает, либо нет.
VD>Скажем я могу в C# 3.0 просто и удобно написать "запрос" к данным с помощью LINQ-а, а в более простом (в смысле примитивном) C# 2.0 не могу. Так какой же из этих вариантов проще?
Если идет речь о простоте выразительного средства, то есть языка — то разумеется тот, который без LINQ. Учитывая, что LINQ по большому счету заточен под прикладную задачу, и нафиг не вперся в случае, если мы не работаем с реляционной БД. И представляешь, в гугле при разработке веб-приложений как-то обходятся без РСУБД.
Здравствуйте, Gaperton, Вы писали:
G>Для тебя — ничего. Для меня — выражают достаточно много. Спорить об этом не вижу смысла. Есть вещи, которые человек либо понимает, либо нет.
Ну, да. Человек либо понимает, что оперировать слишком общими понятиями довольно бессмысленно, либо — нет.
G>Если идет речь о простоте выразительного средства, то есть языка — то разумеется тот, который без LINQ. Учитывая, что LINQ по большому счету заточен под прикладную задачу, и нафиг не вперся в случае, если мы не работаем с реляционной БД.
Это твой любимый эрланг заточен под прикладную задачу . А LINQ — это красиво завернутая (для казуалов) библиотека функций высшего порядка (Select -> map, Where -> Filter, OrderBy -> sort, ...). СУБД тут совершенно не причем. Просто LINQ позволяет как выполнить методы локально, так и преобразовать их в SQL для выполнения на сервере. Так что лучше потрать некоторое время на изучение вражеских лиц .
Так вот в мои понятия "удобный" и "простой" входит скорее удобство и простота решения задач на языке, а не простота реализации языка. Иначе я бы программировал на Обероне, клоном которого и является этот Go.
G>И представляешь, в гугле при разработке веб-приложений как-то обходятся без РСУБД.
Да мне по барабану. Хотя если моя почта лежит не в БД, то мне как-то страшновато за ее целостность.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
G>>Для тебя — ничего. Для меня — выражают достаточно много. Спорить об этом не вижу смысла. Есть вещи, которые человек либо понимает, либо нет.
VD>Ну, да. Человек либо понимает, что оперировать слишком общими понятиями довольно бессмысленно, либо — нет.
Ну да. Человек либо дает себе труд разобраться в том, о чем пишет, либо нет.
G>>Если идет речь о простоте выразительного средства, то есть языка — то разумеется тот, который без LINQ. Учитывая, что LINQ по большому счету заточен под прикладную задачу, и нафиг не вперся в случае, если мы не работаем с реляционной БД.
VD>Это твой любимый эрланг заточен под прикладную задачу . А LINQ — это красиво завернутая (для казуалов) библиотека функций высшего порядка (Select -> map, Where -> Filter, OrderBy -> sort, ...). СУБД тут совершенно не причем. Просто LINQ позволяет как выполнить методы локально, так и преобразовать их в SQL для выполнения на сервере. Так что лучше потрать некоторое время на изучение вражеских лиц .
"Казуалам" не нужна "библиотека функций высшего порядка" и прочая тарабарщина. Так же как и твои немерлевые макросы. Language INtegrated Queries появились потому, что казуалам надо удобно работать с СУБД.
VD>Так вот в мои понятия "удобный" и "простой" входит скорее удобство и простота решения задач на языке, а не простота реализации языка. Иначе я бы программировал на Обероне, клоном которого и является этот Go.
Ну, я же хорошо осведомлен о твоих понятиях. И я знаю, что в их рамках адекватно описывается весьма ограниченный круг задач и ситуаций. Менять твои понятия в мои планы не входит.
G>>И представляешь, в гугле при разработке веб-приложений как-то обходятся без РСУБД.
VD>Да мне по барабану. Хотя если моя почта лежит не в БД, то мне как-то страшновато за ее целостность.
И им по барабану, что ты не можешь представить себе БД без SQL. Поэтому, они обходятся как-то в своем gmail БД BigTable, и не страдают от отсутствия LINQ.
Здравствуйте, Gaperton, Вы писали:
G>Ну да. Человек либо дает себе труд разобраться в том, о чем пишет, либо нет.
+1
ЗЫ
Прости, но когда я прочел твое сравнение этого Гоу с Питоном, то у меня возникло стйкое ощущение, что как минимум Питон ты точно знаешь очень поверхностно.
В общем, нравится тебе этот язык. Замечательно. Только не надо его героизировать. А то станешь похожим на Вирта с его обероном.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Gaperton, Вы писали:
G>"Казуалам" не нужна "библиотека функций высшего порядка" и прочая тарабарщина. Так же как и твои немерлевые макросы. Language INtegrated Queries появились потому, что казуалам надо удобно работать с СУБД.
Ну, что же почитай манулы по C# 3.0. Потом обсудим еще раз. А то пока что разговор явно идет на уровен казуалов.
VD>>Так вот в мои понятия "удобный" и "простой" входит скорее удобство и простота решения задач на языке, а не простота реализации языка. Иначе я бы программировал на Обероне, клоном которого и является этот Go.
G>Ну, я же хорошо осведомлен о твоих понятиях. И я знаю, что в их рамках адекватно описывается весьма ограниченный круг задач и ситуаций. Менять твои понятия в мои планы не входит.
Не пойму, то ли ты потихонечку сливаешь спор переходя на личности, то ли стал настолько философом, что тебя стало трудно понять.
Ты что этим пассажем сказать то хотел?
G>>>И представляешь, в гугле при разработке веб-приложений как-то обходятся без РСУБД.
VD>>Да мне по барабану. Хотя если моя почта лежит не в БД, то мне как-то страшновато за ее целостность.
G>И им по барабану, что ты не можешь представить себе БД без SQL.
А причем тут SQL?
G>Поэтому, они обходятся как-то в своем gmail БД BigTable, и не страдают от отсутствия LINQ.
Да пусть не страдают. Главное что все же моя почта лежит в БД и управляется СУБД, а не кодом на доморощенном языке написанном на левой коленке.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Прости, но когда я прочел твое сравнение этого Гоу с Питоном, то у меня возникло стйкое ощущение, что как минимум Питон ты точно знаешь очень поверхностно.
А меня вот уже давно возникло стойкое ощущение, что 90% языков, которые ты берешься обсуждать, ты знаешь очень поверхностно. К разговору твоя личность конечно не имеет никакого отношения, как и моя, но почему бы тебе не узнать об этом моем ощущении, правда? Не вижу причин, почему нет.
Кстати, я не сравнивал этот язык с Питоном. Я говорил, что класс задач для этого языка будет примерно похожий. Имея при этом в виду серверные приложения Питона — в следующем посте есть пояснение, кстати. Но ты же у нас не всегда задумываешься над тем, что комментируешь. Так что я не в претензии.
VD>В общем, нравится тебе этот язык. Замечательно. Только не надо его героизировать. А то станешь похожим на Вирта с его обероном.
Я его не героизирую. Я отметил, что он мне понравился, и ничего больше. Можно, разрешаешь? Секта не против? А то порядки у вас больно строгие.
Здравствуйте, VladD2, Вы писали:
G>>"Казуалам" не нужна "библиотека функций высшего порядка" и прочая тарабарщина. Так же как и твои немерлевые макросы. Language INtegrated Queries появились потому, что казуалам надо удобно работать с СУБД.
VD>Ну, что же почитай манулы по C# 3.0. Потом обсудим еще раз. А то пока что разговор явно идет на уровен казуалов.
Извини, мне не интересно ни читать мануалы по С# 3.0, ни обсуждать с тобой LINQ. И то и другое имеет весьма далекое отношение к моей работе и интересам.
G>>Ну, я же хорошо осведомлен о твоих понятиях. И я знаю, что в их рамках адекватно описывается весьма ограниченный круг задач и ситуаций. Менять твои понятия в мои планы не входит.
VD>Не пойму, то ли ты потихонечку сливаешь спор переходя на личности, то ли стал настолько философом, что тебя стало трудно понять. VD>Ты что этим пассажем сказать то хотел?
Разъясню, мне не трудно. Я хотел сказать ровно то, что сказал, в ответ на это: VD>Так вот в мои понятия "удобный" и "простой" входит скорее удобство и простота решения задач на языке, а не простота реализации языка. Иначе я бы программировал на Обероне, клоном которого и является этот Go.
Ну входит в твои понятия что-то. Здорово, я принял это к сведению. И что? Занимался ты узкими задачами, опыт у тебя достаточно специфический, и касается тех задач и проблем, которые интереса для меня не представляют. Поэтому, я не собираюсь спорить с тобой о твоих понятиях и системе ценностей вообще, и обсуждать их, они мне не интересны.
Не смотря на это, я бы может быть пообщался с тобой и на тему "понятий", если бы это было приятно и познавательно. Однако, не секрет, что манеры общения у тебя ни к черту, а от своих "понятий" ты ни в коем случае не откажешься. Подбив все вместе — ну и нафига мне с тобой твои "понятия" обсуждать? Толку ноль.
G>>И им по барабану, что ты не можешь представить себе БД без SQL. VD>А причем тут SQL? G>>Поэтому, они обходятся как-то в своем gmail БД BigTable, и не страдают от отсутствия LINQ. VD>Да пусть не страдают. Главное что все же моя почта лежит в БД и управляется СУБД, а не кодом на доморощенном языке написанном на левой коленке.
Здравствуйте, Gaperton, Вы писали:
G>А меня вот уже давно возникло стойкое ощущение, что 90% языков, которые ты берешься обсуждать, ты знаешь очень поверхностно. К разговору твоя личность конечно не имеет никакого отношения, как и моя...
Предлагаю на этом закруглиться с обсуждением личностей. IT
Если нам не помогут, то мы тоже никого не пощадим.
G>"Казуалам" не нужна "библиотека функций высшего порядка" и прочая тарабарщина. Так же как и твои немерлевые макросы. Language INtegrated Queries появились потому, что казуалам надо удобно работать с СУБД.
Интересно в каком из слов Language, Integrated, Queries ты нашел упоминание о СУБД.
Здравствуйте, Alexey Axyonov, Вы писали:
G>>"Казуалам" не нужна "библиотека функций высшего порядка" и прочая тарабарщина. Так же как и твои немерлевые макросы. Language INtegrated Queries появились потому, что казуалам надо удобно работать с СУБД.
AA>Интересно в каком из слов Language, Integrated, Queries ты нашел упоминание о СУБД.
Вот статья о LINQ в википедии. Покажи мне пожалуйста, каким именно образом можно обойти вниманием реляционную модель, реляционные базы данных, и SQL, говоря о LINQ.
Потом попробуй мне объяснить, каким именно боком LINQ, SQL, и реляционная модель тебе пригодиться, к примеру, при работе с базой данных построенной на схеме map-reduce. Если не слышал о таких — погугли.
Вообще есть огромный мир, лежащий за рамками того, к чему вы привыкли. Мир, в котором сервера работают не под Windows, и в котором не применяют РСУБД. В задачах телекома, к примеру, покажешь мне, в какое место засунуть ваш LINQ, и каким образом люди без него спокойно обходятся? Вне контекста баз данных, разумеется. Он же типа совсем-пресовсем никакого отношения к ним не имеет.
Здравствуйте, Воронков Василий, Вы писали:
AA>>Интересно в каком из слов Language, Integrated, Queries ты нашел упоминание о СУБД.
ВВ>Ну человеку спецификация C# 3.0 "неинтересна". Чего вы от него хотите?
Да, неинтересна. И это совершенно нормально. Я вообще не люблю оффтопик.
Здравствуйте, Gaperton, Вы писали:
G>Потом попробуй мне объяснить, каким именно боком LINQ, SQL, и реляционная модель тебе пригодиться, к примеру, при работе с базой данных построенной на схеме map-reduce. Если не слышал о таких — погугли.
Да элементарно пригодится.
Здравствуйте, Cyberax, Вы писали:
G>>Потом попробуй мне объяснить, каким именно боком LINQ, SQL, и реляционная модель тебе пригодиться, к примеру, при работе с базой данных построенной на схеме map-reduce. Если не слышал о таких — погугли. C>Да элементарно пригодится.
Слабовато как-то. Не проняло. Может быть, современная наука на этом не остановилась? И есть работа, как LINQ помогает в решении диффуров? Или кто-нибудь придумал, как на LINQ парсить протокол SIP? Или может быть, изобрели способ делать на LINQ драйверы, декодировать MPEG4 в реальном времени, или иным образом удалить гланды через задний проход?
Да, тогда б конечно. Я наверное поверил бы, что при работе с базой данных map-reduce без LINQ никак нельзя обойтись. Вероятно, я бы проигнорировал даже тот факт, что там совсем не реляционная модель в основе, и в этих плясках с бубнами нет необходимости.
Здравствуйте, Gaperton, Вы писали:
G>Вот статья о LINQ в википедии. Покажи мне пожалуйста, каким именно образом можно обойти вниманием реляционную модель, реляционные базы данных, и SQL, говоря о LINQ.
Не не не. Это ты сперва покажи, каким образом их нельзя обойти, говоря о LINQ.
P.S. Статья в русской википедии по качеству просто никакая.
... << RSDN@Home 1.2.0 alpha 4 rev. 1276 on Windows 7 6.1.7600.0>>
Здравствуйте, Gaperton, Вы писали:
G>Слабовато как-то. Не проняло. Может быть, современная наука на этом не остановилась? И есть работа, как LINQ помогает в решении диффуров? Или кто-нибудь придумал, как на LINQ парсить протокол SIP? Или может быть, изобрели способ делать на LINQ драйверы, декодировать MPEG4 в реальном времени, или иным образом удалить гланды через задний проход?
LINQ — это лишь способ выдирать Expression Tree. А что ты с ним дальше делаешь — твоё личное дело. Можешь приспособить для решения диффуров и декодирования MPEG4.
G>Да, тогда б конечно. Я наверное поверил бы, что при работе с базой данных map-reduce без LINQ никак нельзя обойтись. Вероятно, я бы проигнорировал даже тот факт, что там совсем не реляционная модель в основе, и в этих плясках с бубнами нет необходимости.
Так никто не говорит, что "не обойтись". Но с LINQом многое удобнее.
Здравствуйте, AndrewVK, Вы писали:
G>>Вот статья о LINQ в википедии. Покажи мне пожалуйста, каким именно образом можно обойти вниманием реляционную модель, реляционные базы данных, и SQL, говоря о LINQ.
AVK>Не не не. Это ты сперва покажи, каким образом их нельзя обойти, говоря о LINQ.
Мой тезис состоял в том, что при решении задачи, в которой ты не работаешь с внешними источниками данных с реляционной моделью, выгода от LINQ как минимум неочевидна. И его поддержка в языке не может трактоваться как однозначный плюс, вне контекста заточки языка под класс задач. Разумеется, наличие поддержки LINQ усложняет инструмент. Плюс одна концепция, которую надо знать, и которая будет встречаться в коде.
На, смотри.
Если идет речь о простоте выразительного средства, то есть языка — то разумеется тот, который без LINQ. Учитывая, что LINQ по большому счету заточен под прикладную задачу, и нафиг не вперся в случае, если мы не работаем с реляционной БД. И представляешь, в гугле при разработке веб-приложений как-то обходятся без РСУБД.
Доказывать, что без реляционной модели нельзя обойтись при разговоре о LINQ, я, разумеется не буду.
Во-первых, потому, что невозможность чего-либо вообще сложно доказать.
Во-вторых, и это главное — потому что это навязанный мне тезис, не имеющий отношения к предмету разговора — я не собирался тратить время на бестолковые споры о LINQ в треде о Go. И не собираюсь. Не интересна мне притянутая за уши тема LINQ.
Однако, если ты хочешь возразить мне по существу тезиса — пожалуйста.
AVK>P.S. Статья в русской википедии по качеству просто никакая.
Здравствуйте, Gaperton, Вы писали:
G>Мой тезис состоял в том, что при решении задачи, в которой ты не работаешь с внешними источниками данных с реляционной моделью, выгода от LINQ как минимум неочевидна.
Ну, поскольку твой опыт в использовании линка, как я понимаю, чуть менее чем 0, то твоему экспертному мнению, не подкрепленному аргументами, я пока что не доверяю, уж извини.
G>Учитывая, что LINQ по большому счету заточен под прикладную задачу, и нафиг не вперся в случае, если мы не работаем с реляционной БД.
Вот этот тезис — неверен и бездоказателен.
G>Однако, если ты хочешь возразить мне по существу тезиса — пожалуйста.
Возражать можно только на конкретные аргументы. А возражать против твоего голого имха сродни занятию пенисометрией.
... << RSDN@Home 1.2.0 alpha 4 rev. 1276 on Windows 7 6.1.7600.0>>
Здравствуйте, Воронков Василий, Вы писали:
ВВ>У тебя не возникает сомнения, что твое мнение о LINQ на основе статьи из википедии может быть, скажем так, не совсем полным?
Вот у тебя, к примеру, не возникло сомнения в том, что я знаком с LINQ только по русской википедии. Ты, также, по видимому, абсолютно уверен в том, что я просто не понимаю LINQ, а ты понимаешь, и ты хочешь мне это показать.
А тебе не приходило в голову, что я могу, понимая, что такое LINQ, относиться к нему в большой степени спокойно, и не считаю его офигенски крутой штукой, по той причине, что не вижу от него выраженной пользы в своих задачах?
Задачу сервера IP телефонии, к примеру, ты себе достаточно хорошо представляешь, чтобы у тебя не возникало сомнения в том, что польза знакомых тебе приемов и языковых средств может быть весьма зависима от природы задачи? А сервера обработки биржевых данных? А конвейра мультимедиа-плеера для цифрового телевидения? Среды моделирования микроэлектронных устройств?
Понимаешь, бывает так, что приложение построено вовсе не вокруг набора бизнес-объектов, по которым надо собирать аналитику и выполнять бизнес-логику. Ну вот бывает так. А в биржевых задачах с таймсериями, прикинь, джойнов практически нет. И логика в стиле SQL нифига не раскладывается, если надо строить агрегаты вроде P&F. А в медиаконвейре — вообще другие проблемы. Ну нет там никаких "запросов", прикинь — там потоковая обработка, парсинг стека протоколов, и их синхронизация.
И дофига таких задач на самом деле, понимаешь? Вот мне сплошь они попадаются уже лет 9 как. И то, что у вас там "на самом деле" произвольные источники данных, и что кастомайзить там все типо можно круто, что ваще это цельный типо-скриптовый-ембеднутый фреймворк такой, и можно для всего кроме баз данных это прикрутить — ну не имеет это большого значения. Дело в том, что сам характер работы с данными может быть _другим_, так что нафиг это все не нужно, нет значимого выигрыша.
. А LINQ — это красиво завернутая (для казуалов) библиотека функций высшего порядка (Select -> map, Where -> Filter, OrderBy -> sort, ...). СУБД тут совершенно не причем. Просто LINQ позволяет как выполнить методы локально, так и преобразовать их в SQL для выполнения на сервере. Так что лучше потрать некоторое время на изучение вражеских лиц 
.
Если нам не помогут, то мы тоже никого не пощадим.
