Здравствуйте, Gaperton, Вы писали:
IT>>Мне всё равно совпадает твоё мнение с моим или нет. Я тут распинаюсь ради истины, а не ради тебя. G>А. Ну тогда сколько угодно. Кстати, если ты выделишь тред с "истиной" в отдельный топик, будет совсем хорошо.
Ставь бомбу в нужном месте.
G>>>Что ты статью-то, что я привел, не комментируешь? IT>>Там нечего комментировать G>Весьма показательно. Ответ принят.
В предыдущем ответе я тебе всё же прокомментировал. Можешь там почитать.
IT>>Мои выводы основаны на глубоком и всестороннем изучении технологии, на знании её внутренностей и деталей реализации. А ты даже прессрелизов не читал. Действительно, замнём.
G>Если тебя это успокаивает, то как тебе будет угодно. Мне же вполне достаточно, что мои выводы подтверждаются свидетельством автора данной технологии в своем блоге.
Ты сегодня необычайно жжёшь!
Если технологией ты называешь IQToolkit Мэта, то я автор точно такой же технологии, только называется она BLToolkit.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Gaperton, Вы писали:
Y>>Неправильно. Идея игнорирования (Objects, XML например) — это как раз твоя прерогатива. Чтобы доказать твою неправоту не нужно игнорировать реляционные данные, достаточно показать, что это только один из источников.
G>Неправильно. Для этого недостаточно показать, что это один из источников. Что для этого достаточно — это обозначить другую проблему, кроме OR-mapping, решаемую LINQ, и продемонстрировать, что она как минимум не менее значима, чем OR-mapping. Этого никто не сделал. Даже не попытался.
Странно, я вроде именно это и пытался сделать (впрочем, не только я). Даже болдом в цитате выделил проблему, решаемую LINQ, и она более значима, чем OR-mapping, ибо OR-mapping это лишь частный случай выделенной проблемы.
G>>>Если выкинуть работу с реляционным источником из списка, то вся обозначенная проблема становится достаточно несущественной и незначительной, чтобы не расшибаться в лепешку ради специальной поддержки специального механизма в языке.
Y>> И если цель была реляционные данные, зачем было городить огород с моделью провайдеров, включать реализацию LINQ to Objects, LINQ to XML?
G>Если основная цель и мотивация разработки — реляционные данные (т.е. сделать ORM менее геморройным), это вовсе не отменяет желания разработчиков сделать это посредством не узкозаточенной штуки, а более общего механизма, который способен заодно решать и более мелкие проблемы, и обрабатывать данные разных типов единообразно. Хорошее желание, правильное. Вот ровно как в статье, что ты привел, написано. Никакого противоречия тут нет.
Мда, если принять свою предпосылку за верную, то можно на этой основе строить рассуждения подтверждающие ее верность А насчет ровно как в статье...
Давай посмотрим. Вот исходный пример "Look at the 3 prevalent data models: Objects, XML and Relational Data. Programmers have to struggle with that daily when they write programs, mess around, querying relational data, doing some computations, then exposing the XML, and then vice versa." Обрисовал он текущее положение вещей. Теперь продолжение: " Imagine that tomorrow a completely new data model comes out, and you don't know if you can still map that to XML or Objects. The secret is to look at what mathematics has to offer you to solve this problem". Какая модель данных потерялась? Объясни, если несложно, как ты не видишь здесь противоречия с тем, что основная цель разработки — решить проблему с одной единственной моделью данных (реляционной, именно которую он для примера и заменяет какой-то абсолютно новой). Он говорит что цель — работать с любыми моделями данных, пускай даже сейчас неизвестными, а ты утверждаешь, что нет, основная цель — реляционные данные. Действительно, никакого противоречия. Он говорит про 3 преобладающие модели данных (и как результат — эти модели доступны "из коробки" на момент релиза), абсолютно без ранжирования, ты работу с одной называешь главной, а другие — более мелкими проблемами. Действительно, вот ровно как в статье.
G>К сведению, "огород с разными провайдерами" городили еще в OLE DB. Можно сделать OLE DB провайдера к любому источнику — к файловой системе или ящику электронной почты. Я надеюсь, сомнений в основном предназначении OLE DB, несмотря на это, у тебя не возникает?
Ага, в ASP.NET тоже модель провайдеров естью И сомнений предназначение не вызывает. А при чем здесь LINQ?
Y>>Зачем что-то выкидывать? Опять тебя в крайности кидает.
G>Крайность — это понимать все буквально. Для понимания роли и вклада каждого из факторов, их надо рассматривать изолировано. Для этого и "выкидывать". В уме, конечно.
G>Если ведущая проблема — не ORM, а XML+Objects, то нет никакого смысла тянуть SQL-синтаксис, и устраивать все так, как оно выглядит. Ибо можно проще. Здесь я полностью согласен с netch80.
Нет, ведущая проблема не XML+Objects, не ORM, не [подставь_свое], а независимость от модели данных, я ж даже выделил это в цитатах.По-этому рассматривать каждую модель "изолировано" и смысла нету.
Насчет SQL-синтаксиса, в цитате тоже есть ответ "then try to translate this into something that normal programmers can understand". SQL понимают большинство программистов — вот им и синтаксис привычен. При этом это не единственный синтаксис для работы с LINQ, более того, query expression keywords в С# даже не перекрываютquery standard query operators — ты не найдешь аналогов Distinct(), Min()/Max(), Any() и т.д.
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Здравствуйте, Gaperton, Вы писали:
ГВ>>А у меня вот точно такое же впечатление сложилось: что вы любой ценой добиваетесь "признания своей неправоты", даже когда собеседник прямо говорит, что его самого это совершенно не колышет. G>Тонкое наблюдение. Да, все так, и эта традиция имеет глубокие исторические корни .
G>Правило, что улик и доказательств недостаточно для того, чтобы спалить человека на костре, и для этого обязательно требуется его признание вины, практиковалось еще Священной Инквизицией — уважаемой организацией, которая еще в дремучее средневековье несла свет истины в народные массы. Очень гуманное правило. Признание, разумеется, выбивалось под пыткой — ну как же без этого, иначе он, сволочь, эта — совреть!
Угу, тоже тонкое наблюдение. Настоящий философский диспут в традициях XIV-го века. Носители истины имеются. Заблудшие — тоже. Осталось принудить заблудших к признанию.
ГВ>>Утверждения Гапертона, на мой сторонний взгляд, сводятся к одному: "от...итесь!" Извини мне мой французский. G>Спасибо за поддержку, дружище! Но зря ты таки в адвокаты записался. Ты посмотри хорошенько, кого ты защищаешь. Гапертон ведь неправ по полной программе.
Как жоский патерналистический мужик (с), я сам решаю — кого защищать, а кого — эдипопапить.
G>Какое у вас тут оказывается интересное обсуждение моей персоны идет. Разговор такой же задушевный, прям как будто друзей диссидента в первый раз в КГБ на профилактическую беседу пригласили, и ненавязчиво так прессуют. Уписаццо.
Да уж...
G>Тему про Го таки засрали. Разумеется, из самых благородных побуждений — истины ради. С чем всех и поздравляю. Комменты по самому Го отыскать уже почти невозможно.
. Присоединяйся — отпилить весь кусок с LINQ и хоть положить его рядом, что ли. А то и выкинуть подальше — годных рассуждений тут немного.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Как жоский патерналистический мужик (с), я сам решаю — кого защищать, а кого — эдипопапить.
Черт, а ведь точно, я уж забыл . (Занимательнейший флейм был об эдиповых отцах, кстати, я ржал как сумасшедший ).
ГВ>Попробую понадеяться на автомодерилку
. Присоединяйся — отпилить весь кусок с LINQ и хоть положить его рядом, что ли. А то и выкинуть подальше — годных рассуждений тут немного.
G>Хорошая мысль. Рядом, и пусть тонет. Я думаю так.
Ага. Хорошая. Только отделять нужно твой ответ в котором ты ушел от темы и начал выдвигать свои смелые научные гипотезы по поводу ЛИНК-а.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, yuriylsh, Вы писали:
Y>>>Неправильно. Идея игнорирования (Objects, XML например) — это как раз твоя прерогатива. Чтобы доказать твою неправоту не нужно игнорировать реляционные данные, достаточно показать, что это только один из источников.
G>>Неправильно. Для этого недостаточно показать, что это один из источников. Что для этого достаточно — это обозначить другую проблему, кроме OR-mapping, решаемую LINQ, и продемонстрировать, что она как минимум не менее значима, чем OR-mapping. Этого никто не сделал. Даже не попытался.
Y>Странно, я вроде именно это и пытался сделать (впрочем, не только я). Даже болдом в цитате выделил проблему, решаемую LINQ, и она более значима, чем OR-mapping, ибо OR-mapping это лишь частный случай выделенной проблемы.
Извини, не заметил. Попробуй еще раз — в чистом виде. Внимательно рассмотрим.
G>>Если основная цель и мотивация разработки — реляционные данные (т.е. сделать ORM менее геморройным), это вовсе не отменяет желания разработчиков сделать это посредством не узкозаточенной штуки, а более общего механизма, который способен заодно решать и более мелкие проблемы, и обрабатывать данные разных типов единообразно. Хорошее желание, правильное. Вот ровно как в статье, что ты привел, написано. Никакого противоречия тут нет.
Y>Мда, если принять свою предпосылку за верную, то можно на этой основе строить рассуждения подтверждающие ее верность
Если принять эту предпосылку как верную, то строить ничего не надо, ибо пока не было заявлено ничего, что ей противоречит. Кроме ваших эмоций. Они на меня, как ты заметил, никакого впечатления не производят.
Y>А насчет ровно как в статье... Y>Давай посмотрим.
А вот это похоже на конструктивный разговор. Трактуем статью. Хорошо.
Y>Вот исходный пример "Look at the 3 prevalent data models: Objects, XML and Relational Data. Programmers have to struggle with that daily when they write programs, mess around, querying relational data, doing some computations, then exposing the XML, and then vice versa." Обрисовал он текущее положение вещей.
Прежде чем продолжать, подумай о том, как он обрисовал текущее положение вещей. На русский перевести?
"...запрашивают некоторые реляционные данные, выполняют какие-то вычисления, затем выставляют наверх XML, и наоборот". Обрисовал он, как ты говоришь, текущее положение вещей.
А если это текущее положение вещей такое, что про программисты не должны каждый день начинать с того, чтобы запрашивать реляционные данные? А что, если им ни разу не вперлось превращать их после некоторой обработки в XML? Удивительно, как такое может быть? Простой пример:
Вот пусть так получается, что мои данные — это time series. И мне не надо превращать их в XML, потому, что ни нашлось ни одного идиота-архитектора, который решил, что это обязательно надо делать. Вот, к примеру, пишу я Windows Media Player — ну ни разу не вперлось ни то, ни другое. И что теперь будем делать с такой точной обрисовкой "текущего положения вещей", завязанной на разработчиков приложений, построенных вокруг РСУБД?
Получается, что он уже обрисовал текущее положение вещей далеко не для всех программистов, и не для всех задач, а только для достаточно узкого класса разработчиков, правда?
Y>Теперь продолжение: " Imagine that tomorrow a completely new data model comes out, and you don't know if you can still map that to XML or Objects. The secret is to look at what mathematics has to offer you to solve this problem". Какая модель данных потерялась? Объясни, если несложно, как ты не видишь здесь противоречия с тем, что основная цель разработки — решить проблему с одной единственной моделью данных (реляционной, именно которую он для примера и заменяет какой-то абсолютно новой).
Потерялись все модели, которые не были учтены при разработке. Потому, что невозможно все предусмотреть — все, это ничего. Пример привести не сложно, и я приведу. Пример, который я уже привел в помощь netch, — БД работающие с таймсериями. Смотри по ссылке. Для тебя этот пример может быть экзотическим, но для меня это очень хорошо известный и ходовой пример. Посмотри на него внимательно, прежде чем отвечать.
Y>Он говорит что цель — работать с любыми моделями данных, пускай даже сейчас неизвестными, а ты утверждаешь, что нет, основная цель — реляционные данные. Действительно, никакого противоречия.
Его высказывание, что он сможет работать с любыми моделями данных, даже сейчас неизвестными, понимаемое тобой буквально — я не могу воспринимать всерьез. Ибо это глупость. Этот тезис невозможно доказать. Поэтому, я не воспринимаю это как тезис. Я никогда не спорю с откровенной глупостью.
При этом, что человек имел в виду и хотел сказать — мне вполне понятно, и это не глупость. В глупость его слова превратились сейчас, когда их взялся трактовать ты.
Y> Он говорит про 3 преобладающие модели данных (и как результат — эти модели доступны "из коробки" на момент релиза), абсолютно без ранжирования, ты работу с одной называешь главной, а другие — более мелкими проблемами. Действительно, вот ровно как в статье.
Целых три, надо же. Мне "модель данных Objects" доступна и так из коробки без всякого LINQ, ибо она всегда поддерживается языком непосредственно. Было бы странно и очень глупо, если взаимодействие с объектами языка из самого языка представляло собой проблему.
Как и XML — никакого особенно значимого напряга работать с XML нет. Если в языке не составляет проблемы обойти дерево.
G>>К сведению, "огород с разными провайдерами" городили еще в OLE DB. Можно сделать OLE DB провайдера к любому источнику — к файловой системе или ящику электронной почты. Я надеюсь, сомнений в основном предназначении OLE DB, несмотря на это, у тебя не возникает?
Y>Ага, в ASP.NET тоже модель провайдеров естью И сомнений предназначение не вызывает. А при чем здесь LINQ?
Я комментирую твой тезис, об "огороде провайдеров". Если он к LINQ не относится — то причем тут он?
Y>>>Зачем что-то выкидывать? Опять тебя в крайности кидает.
Y>Нет, ведущая проблема не XML+Objects, не ORM, не [подставь_свое], а независимость от модели данных, я ж даже выделил это в цитатах.По-этому рассматривать каждую модель "изолировано" и смысла нету.
Ага. В том числе, от всех сейчас неизвестных. Отличная цель. Достигается путем магии, плясок с бубном, и абстрактной математики.
Y>Насчет SQL-синтаксиса, в цитате тоже есть ответ "then try to translate this into something that normal programmers can understand". SQL понимают большинство программистов — вот им и синтаксис привычен. При этом это не единственный синтаксис для работы с LINQ, более того, query expression keywords в С# даже не перекрываютquery standard query operators — ты не найдешь аналогов Distinct(), Min()/Max(), Any() и т.д.
Я не против, если ты останешься при своем мнении. Оно в чем-то стройное и логичное.
Здравствуйте, Gaperton, Вы писали:
Y>>Странно, я вроде именно это и пытался сделать (впрочем, не только я). Даже болдом в цитате выделил проблему, решаемую LINQ, и она более значима, чем OR-mapping, ибо OR-mapping это лишь частный случай выделенной проблемы.
G>Извини, не заметил. Попробуй еще раз — в чистом виде. Внимательно рассмотрим.
Если до сих пор не заметил — дальнешее общение с тобой по этой теме — бесполезная трата времени. Засим отклниваюсь.
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Здравствуйте, Gaperton, Вы писали:
G>>>Если идет речь о простоте выразительного средства, то есть языка — то разумеется тот, который без LINQ. Учитывая, что LINQ по большому счету заточен под прикладную задачу, и нафиг не вперся в случае, если мы не работаем с реляционной БД.
VD>>Это твой любимый эрланг заточен под прикладную задачу . А LINQ — это красиво завернутая (для казуалов) библиотека функций высшего порядка (Select -> map, Where -> Filter, OrderBy -> sort, ...). СУБД тут совершенно не причем. Просто LINQ позволяет как выполнить методы локально, так и преобразовать их в SQL для выполнения на сервере. Так что лучше потрать некоторое время на изучение вражеских лиц .
G>"Казуалам" не нужна "библиотека функций высшего порядка" и прочая тарабарщина. Так же как и твои немерлевые макросы. Language INtegrated Queries появились потому, что казуалам надо удобно работать с СУБД.
Уже давно использую Linq2objects и ни разу не пользовался Linq2db. Чяднт?
RSDN-ейшая из RSDN-ейших инквизиций требует от заблудшего признать существование минималистически глобального универсального всемогутера! Просто кристально чистый образец деления на нуль и умножения на пустое множество. Достоин внесения во всяческие анналы.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, yuriylsh, Вы писали:
Y>>>Странно, я вроде именно это и пытался сделать (впрочем, не только я). Даже болдом в цитате выделил проблему, решаемую LINQ, и она более значима, чем OR-mapping, ибо OR-mapping это лишь частный случай выделенной проблемы.
G>>Извини, не заметил. Попробуй еще раз — в чистом виде. Внимательно рассмотрим.
Y>Если до сих пор не заметил — дальнешее общение с тобой по этой теме — бесполезная трата времени. Засим отклниваюсь.
Молодец.
В догонку я тебе поясню, почему я не заметил.
Проблема "импеданса" при работе с неизвестными моделями данных данных — так же неизвестная, как эти неизвестные модели. Эта "проблема" по очевидной причине не стоит, и пока неизвестные модели не станут известными, проблемой не является, и поэтому — решена быть не может.
Никто и никогда не станет закладывать в язык фичу, имея цель решить воображаемые проблемы. Настоящие проблемы, на самом деле требующие решения, всегда звучат конкретно. Вот ORM — это проблема.
Для того, чтобы принять решение поддержать в языке общий механизм, вроде монад, как в Хаскеле, или вашего LINQ, одной общности и крутизны механизма недостаточно — необходимо наличие вполне конкретной и актуальной проблемы, решаемой новым механизмом.
В Хаскеле, к примеру, основная проблема, которую решало введение монад — это ввод-вывод. Почему? Потому, что ввод-вывод без монад там делается до редкостной степени через жопу. И Вадлер, когда предложил монады в качестве решения, не пел всем о том, какой это универсальный и общий механизм, способный делать все, что угодно, в том числе и науке неизвестные вещи. В своей вводной статье Вадлер разобрал четыре вполне конкретные проблемы (ввод-вывод, мутабельные массивы, исключения, парсеры), и показал, как они решаются посредством монад. Он сделал это так, что все почему-то заметили (самая ацкая проблема из перечисленных — это все равно ввод-вывод меж тем, остальное фигня по большому счету).
Ну и где ты у себя-то увидел описание проблем? Я не понимаю, как можно не понимать такую простую вещь, и сколько можно ее разжевывать. Дальнешее общение с тобой по этой теме — бесполезная трата времени. И я также откланиваюсь засим.
Здравствуйте, anton_t, Вы писали:
_>Уже давно использую Linq2objects и ни разу не пользовался Linq2db. Чяднт?
Ты открыл для себя силу и выразительность comprehensions. Штука прикольная, но без нее легко можно пережить.
Чтобы вставить в язык comprehensions, не обязательно выдумывать никакого LINQ, и делать это через него. И они вовсе не обязаны выглядеть тяжеловесно, как SQL запрос. Linq2objects — не причина появления LINQ, не смотря на то, что ты ее давно используешь, и что это приятная штука.
Здравствуйте, Gaperton, Вы писали:
G>Ты открыл для себя силу и выразительность comprehensions. Штука прикольная, но без нее легко можно пережить.
G>Чтобы вставить в язык comprehensions, не обязательно выдумывать никакого LINQ, и делать это через него. И они вовсе не обязаны выглядеть тяжеловесно, как SQL запрос. Linq2objects — не причина появления LINQ, не смотря на то, что ты ее давно используешь, и что это приятная штука.
Когда я думаю о LINQ, первая ассоциация — синтаксический сахар для создания монад в шарпе.
А почему он появился, тоже понятно. Эрик Мейджер решил популяризовать ФП.
Кстати, разногласия во многом вызваны тем, что слово LINQ используется носителями языка в разных значениях.
По этому поводу хотел спросить.
Диалог в начале ветки
VD>Сдается мне понятия простой и удобный весьма многогранны. Так что они ровным счетом ничего не выражают.
G>Для тебя — ничего. Для меня — выражают достаточно много. Спорить об этом не вижу смысла. Есть вещи, которые человек либо понимает, либо нет.
выглядит так как будто Gaperton знает какой-то способ понимания собеседника, отличающийся от методики, когда используемые общие понятия уточняются, чтобы понять что собеседник имел в виду.
Люди! Если кто-нибудь знает этот способ, буду очень благодарен, если меня ткнут в него носом.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, anton_t, Вы писали:
_>>Уже давно использую Linq2objects и ни разу не пользовался Linq2db. Чяднт?
G>Ты открыл для себя силу и выразительность comprehensions. Штука прикольная, но без нее легко можно пережить.
Ох не хотел я тебе больше отвечать, но твоя воистину нечеловеческая упертость задевает на столько, что я все же попробую последний раз объяснить тебе элементарный (как мне казалось) факт.
Так вот, попробуй просто запомнить (раз понять не можешь) — LINQ — это общее название для технологии, а не только для Query comprehensions.
Чаще всего под LINQ понимается набор функций высшего порядка аналогичный map, filter, fold, skip и т.п.
Так что применять линк можно без использования синтаксических расширений. Просто открываешь пространство имен System.Linq и начинаеш использовать методы-расширения (которые при этом виртуально добавляются ко всему что можно перебрать, т.е. спискам):
using System.Linq;
...
int[] array = { 1, 2, 3, 4, 5, 6 };
var odds = array.Where(elem => (elem % 2) != 0);
foreach (var odd in odds)
WriteLine(odd);
В данном примере не используются синтаксические расширения (только упрощенный синтаксис лямбд и методы-расширения которые являются универсальными усовершенствованиями языка).
Но LINQ здесь используется.
Тот же самый код с использованием query comprehensions будет выглядеть так:
using System.Linq;
...
int[] array = { 1, 2, 3, 4, 5, 6 };
var odds = from elem in array where (elem % 2) != 0 select elem;
foreach (var odd in odds)
WriteLine(odd);
Так понятно? Потому, что если нет, то это уже просто невероятно!
G>Чтобы вставить в язык comprehensions, не обязательно выдумывать никакого LINQ, и делать это через него. И они вовсе не обязаны выглядеть тяжеловесно, как SQL запрос. Linq2objects — не причина появления LINQ, не смотря на то, что ты ее давно используешь, и что это приятная штука.
Без разницы что для чего обязательно, а что для чего не обязательно. Тебе нужно было понять совершенно простые и очевидные мысли. Но ты уперся как сам знаешь что сам знаешь во что и развел флэйм на 1000 сообщений.
Разговоры про тяжеловесность линк-запросов — это очередной виток этого флэйма. Тебя так и тянет насыпать ничем не обоснованных заявлений чтобы побередить умы окружающих.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ehudi, Вы писали:
VD>>Сдается мне понятия простой и удобный весьма многогранны. Так что они ровным счетом ничего не выражают.
G>>Для тебя — ничего. Для меня — выражают достаточно много. Спорить об этом не вижу смысла. Есть вещи, которые человек либо понимает, либо нет.
E>выглядит так как будто Gaperton знает какой-то способ понимания собеседника, отличающийся от методики, когда используемые общие понятия уточняются, чтобы понять что собеседник имел в виду.
E>Люди! Если кто-нибудь знает этот способ, буду очень благодарен, если меня ткнут в него носом.
Понятия "простой" и "удобный" правда кажутся тебе настолько сложными, неоднозначными, и непонятными, что требуют уточнения, и стоят длинной дискуссии? Ты считаешь, их вообще возможно уточнить и договориться, чтобы они стали "общими"? Все-таки "философия программирования" — это зазеркалье какое-то.
Здравствуйте, Ehudi, Вы писали:
E>выглядит так как будто Gaperton знает какой-то способ понимания собеседника, отличающийся от методики, когда используемые общие понятия уточняются, чтобы понять что собеседник имел в виду.
E>Люди! Если кто-нибудь знает этот способ, буду очень благодарен, если меня ткнут в него носом.
Такого способа однозначно нет. Единственный известный мне и работающий способ — это детерменирование используемых понятий. Используется в любой научной деятельности.
Но надо четко понять, что когда человеку нужно раздуть скандал, то этот способ не приемлем. Ведь цель не понять других и объяснить другим свою позицию, а создать много шума и заняться упражнениями в софистике.
И все то только потому, что твое мнение не поддержали окружающие, а создание логичного и взвешенного обоснования своих слов — это тяжелый и не благодарный труд.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Gaperton, Вы писали:
G>Понятия "простой" и "удобный" правда кажутся тебе настолько сложными, неоднозначными, и непонятными, что требуют уточнения, и стоят длинной дискуссии? Ты считаешь, их вообще возможно уточнить и договориться, чтобы они стали "общими"? Все-таки "философия программирования" — это зазеркалье какое-то.
Договориться один раз и навсегда не получиться. Но я считаю, что каждый раз, когда возникает неоднозначность, надо уточнять о чем идет речь.
Что касается слова простой, то оно не так просто.
Ведь то что кажется простым одному, для другого не просто.
И мне кажется, что Вы это тоже должны понимать.
Здравствуйте, Gaperton, Вы писали:
G>Понятия "простой" и "удобный" правда кажутся тебе настолько сложными, неоднозначными, и непонятными, что требуют уточнения, и стоят длинной дискуссии? Ты считаешь, их вообще возможно уточнить и договориться, чтобы они стали "общими"? Все-таки "философия программирования" — это зазеркалье какое-то.
100%. Это доказал ты сам заявляя что синтаксис линка громоздкий в то время как множество людей считает его как раз понятным и лаконичным.
Еще раз повторю свою исходную мысль (на которую ты так и не дал ответа и развел флэйм).
Для кого-то простой язык — это язык с минимумом конструкций (типичные представители Оберон, и возможно Гоу).
Для кого-то это язык напичканный максимумом фич.
Для кого-то это язык обладающей одной-двумя мегафичами (вроде макросов Лиспа).
Для кого-то это безопасный язык.
...
Посему бросаться такими терминами без их уточнения не только бесполезно, но и вредно. Данный флэйм четко это подтверждает.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
IT>Без линка пришлось бы наворачивать циклы и состояния. Это я к вопросу о незначительности решения. И таких упражнений в день у меня по сто штук без всяких баз данных.
Что забавно — этот пример вообще невозможно выразить через куари-компрешеншон.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
IT>>Без линка пришлось бы наворачивать циклы и состояния. Это я к вопросу о незначительности решения. И таких упражнений в день у меня по сто штук без всяких баз данных.
VD>Что забавно — этот пример вообще невозможно выразить через куари-компрешеншон.
А как он запишется с использованием специального синтаксиса LINQ?
Если нам не помогут, то мы тоже никого не пощадим.
А насчет ровно как в статье...
