Здравствуйте, VladD2, Вы писали:
VD>Кстати, возникла одна идея. Можно организовать небольшую "войнушку"... Завести отдельную тему в которой попробовать сравнить языки по выразительной мощности. VD>Я могу выступить за C# и Nemere. Ты за Go и Erlang, FR за Python, ну, и может быть еще кто-то подтянется. За одно можно будет сравнить полученные решения на скорость. Думаю, эта "битва" была бы интересна очень многим.
Здравствуйте, FR, Вы писали:
FR>И победит в результате Хаскель
Вряд ли. Как только речь зайдет о проектировании сложных систем, он сольет по полной.
Потом не так уж он выразителен как расписывают его фанаты.
VD>>Ну, как идея?
FR>Нормально, давно пузомерок не было.
Дык возможно она позволит сблизит понимание между сектами. Ведь все мы хорошо знаем только 2-3 языка, а остальные только очень посредственно. Потому и не можем быть объективными зачастую.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
AVK>>Спецификация языка, интерфейсы.
VD>То есть утиная типизация доступна только для интерфейсов?
Там интерфейсы — это как раз средство определения утиной типизации (типа "ходит и крякает") и используются в месте вызова, а не интерфейсы в стиле классических ООП-языков, в которых они используются в определении типа. Некоторая путаница в терминологии.
Примерно то, что хотели сделать концепциями в С++.
Здравствуйте, jazzer, Вы писали:
J>Там интерфейсы — это как раз средство определения утиной типизации (типа "ходит и крякает") и используются в месте вызова, а не интерфейсы в стиле классических ООП-языков, в которых они используются в определении типа. Некоторая путаница в терминологии. J>Примерно то, что хотели сделать концепциями в С++.
Да, я уже это понял. Пожалуй — это самая яркая и правильная концепция выбранная в Гоу. Опять же не в нем придуманная, но все же.
Отдельный вопрос как ее эффективно реализовать. Ведь мне не составит труда реализовать ее и для любого ООЯ, но при передаче ссылки придется неявно создавать еще один объект обертку или vtbl-map. Для немерле подобное можно даже на макросе залудить.
Так что вопрос в том как это реализовано? Даже не так... Как этом может быть эффективно реализовано?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD> Кстати, возникла одна идея. Можно организовать небольшую "войнушку"... Завести отдельную тему в которой попробовать сравнить языки по выразительной мощности. VD> Я могу выступить за C# и Nemere. Ты за Go и Erlang, FR за Python, ну, и может быть еще кто-то подтянется. За одно можно будет сравнить полученные решения на скорость. Думаю, эта "битва" была бы интересна очень многим.
VD> Ну, как идея?
VD> M>Тут вот рядом тема «языки в боевых условиях» VD> Вот эта тема да еще мне не интересна. Причем не по задумке, не по месту проведения. VD> Тут нужен интерактив.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, jazzer, Вы писали:
J>>Там интерфейсы — это как раз средство определения утиной типизации (типа "ходит и крякает") и используются в месте вызова, а не интерфейсы в стиле классических ООП-языков, в которых они используются в определении типа. Некоторая путаница в терминологии. J>>Примерно то, что хотели сделать концепциями в С++.
VD>Да, я уже это понял. Пожалуй — это самая яркая и правильная концепция выбранная в Гоу. Опять же не в нем придуманная, но все же.
Кстати, в каком языке она впервые реализована как конструкция языка? (понятно, что навернуть ее легко в динамических языках с первоклассными функциями, типа того же Перла)
VD>Отдельный вопрос как ее эффективно реализовать. Ведь мне не составит труда реализовать ее и для любого ООЯ, но при передаче ссылки придется неявно создавать еще один объект обертку или vtbl-map. Для немерле подобное можно даже на макросе залудить.
Да на любых языках с рефлексией это не составит проблем, взять тот же Питон — там еще проще, ибо у функций нету типизированных сигнатур, так что можно просто по имени метода матчить, а учитывая, что методы можно прямо в рантайме добавлять...
VD>Так что вопрос в том как это реализовано? Даже не так... Как этом может быть эффективно реализовано?
Ну язык же динамически типизированный в этой части.
Можно просто иметь табличку, какие типы каким интерфейсам удовлетворяют, заполнять ее в динамике и кэшировать результат.
Т.е. в первый раз проверить все честно, а потом просто смотреть: "ага, пришел типа А, должен сматчиться к интерфейсу Б, идем в табличку — ага, матчится, едем дальше".
G>Извини, мне не интересно ни читать мануалы по С# 3.0, ни обсуждать с тобой LINQ. И то и другое имеет весьма далекое отношение к моей работе и интересам.
LINQ это монады в чистом виде. Базы тут постолько поскольку
И выстрелили они именно благодаря
а) удобству записи лямбд
б) выводу типов
Неужели плохо иметь возможность использования удобных паттернов?
Здравствуйте, AndrewVK, Вы писали:
G>>Я вот совершенно уверен в том, что _мне_лично_ выгода не очевидна.
AVK>Отличная позиция. Не знаю и знать не хочу. Только остальным то какое до этого дело?
Позиция не такая. "Из того, что об этом знаю — мне кажется, что выгода не очевидна" Вот такая позиция.
И я тоже искренне не понимаю, какое остальным-то до этого дело? Что вы лезете спорить-то все, какая вам разница, очевидна мне выгода или нет? Не хочу я спорить.
Хочешь показать выгоду — объясни.
G>>Я вижу, тебе по какой-то причине важно подчеркнуть, что у тебя опыт использования LINQ есть
AVK>Нет. Но если делаешь заявления — будь добр их аргументировать.
Когда я спорю с тобой, и утверждаю, что ты не прав — ты можешь требовать от меня аргументации, и это правильно.
Но не тогда, когда я не спорю, а выражаю мнение. Я могу отказаться спорить на те темы, которые мне не интересны, и остаться при своем мнении. Никакой катастрофы в этом я не вижу.
Тема LINQ притянута за уши, и отношения к языку Go не имеет. В этом треде, сейчас, я не хотел на нее отвлекаться, и тем более тратить энергию на спор. Ты не согласен с моим мнением? Хочешь на него повлиять? Объясни, что именно я по твоему не учитываю или не понимаю. Я приму к сведению, возможно — отвечу. Попытаешься вместо этого спорить — не получится, я откажусь.
У меня получилось объяснить тебе мою позицию, Андрей?
G>>, а у меня нет. Пожалуйста. Да, опыта использования LINQ у меня в районе ноля, если не считать, что он похож на query list сomprehesions Эрланга, конечно.
AVK>Оно тоже исключительно под реляционные БД заточен?
Нет, конечно. Она by design с произвольными источниками работает.
Но потребность в ней выражена (и польза от нее заметна) именно тогда, когда система работает с реляционным источником, и данные имеют реляционный характер. Это я и имел в виду в первом посте.
AVK>>>Вот этот тезис — неверен и бездоказателен.
G>>Считаешь что неверен — возрази.
AVK>Еще раз — ты выдвинул, тебе и доказывать. И никак иначе.
Еще раз. Я не "выдвинул". А выразил мнение. Сообщил, что я думаю, без цели кого-либо в этом убеждать.
Мнение не тезис — оно идет as is. Не согласен — не соглашайся. Требовать доказательств не можешь — с тобой собственно, никто не спорит, и мы не в суде. Не имею желание тратить время — не доказываю. В треде о Go — не имею желания спорить о LINQ.
G>> Будут нормальные доводы — не только соглашусь, но и спасибо скажу.
AVK> достаточно взглянуть на имеющиеся прямо в BCL linq2objects и linq2xml, про которые упомянуто даже в бездарной статье в русской википедии. Ссылку на linq для CoachDB тебе тоже уже приводили. Есть linq для db4o. Этого мало?
Я, видишь-ли, ссылок у тебя не просил. Я вообще ничего не просил, что давало бы тебе повод спрашивать "этого мало?".
Я же тебе сказал — сейчас тема мне не интересна. Поэтому, ничего активно искать, рыть, и читать сейчас я не буду. Но если тебе хочется объяснить мне где я неправ — внимательно выслушаю. Если ты потратишь время, и дашь краткую выжимку, поделившись тем, что знаешь, съкономив время мне — я искренне буду тебе благодарен, потому что ценю не только свое время, но и твое — то которое ты потратил. Это — нормальное, человеческое поведение.
Если тебе не хочется — ну не объясняй, пусть я при своем мнении останусь, какое тебе дело в конце концов.
А вот спорить, и выслушивать серию разного рода понтов, и тратить кучу времени бездарно на глупости вроде выяснения кто тут по настоящему самый крутой в LINQ — ну не хочу, понимаешь? Потому, что не интересны мне сейчас ни LINQ, и тем более плевать, кто там как в нем разбирается. Неужели это сложно понять, Андрей?
AVK>Нормальные доводы лежат на поверхности...
Тем более не вижу причин гнуть понты и не показать их кратко, дав выжимку. Имей в виду, что я тебя об этом не прошу. Только, если тебе самому хочется. Я не сильно заинтересован в этом разговоре.
Здравствуйте, VladD2, Вы писали:
VD> Ты изучаешь технологии по статьям в Википедии?
Нет конечно, но я довольно часто привожу википедию в качестве иллюстрации. Удобно.
VD>Давай лучше я еще раз и более развернуто объясню тебе, что имел в виду? ОК?
VD>Так вот. LINQ — это: VD>1. Библиотека функций высшего в которой привычные для функциональщиков имена ФВП заменены на аналоги из SQL. При этом с самим SQL функции и даже синтаксис LINQ имеет мало общего. Эта библиотека имеет отдельное название LINQ to Object. VD>2. Синтаксические расширения языков. На самом деле не более чем сахар, так как и без них все ОК. VD>3. Языковые расширения позволяющие преобразовывать код так называемых лябда-выражений в AST (обозванное Expression [Tree]). VD>4. Ряд провайдеров позволяющих преобразовывать Expression Tree в запросы к внешним источникам данных.
Отлично. Теперь давай я тебе в свою очередь объясню, что я имел в виду. Для этого мне надо, чтобы ты ответил на два вопроса.
Какие проблемы решает LINQ, и что является для него killer application?
Здравствуйте, Gaperton, Вы писали:
G>Отлично. Теперь давай я тебе в свою очередь объясню, что я имел в виду. Для этого мне надо, чтобы ты ответил на два вопроса. G>Какие проблемы решает LINQ, и что является для него killer application?
Доступ к данным.
Здравствуйте, VladD2, Вы писали:
G>>Вот у тебя, к примеру, не возникло сомнения в том, что я знаком с LINQ только по русской википедии. Ты, также, по видимому, абсолютно уверен в том, что я просто не понимаю LINQ, а ты понимаешь, и ты хочешь мне это показать.
VD>Влад, не обижайся, но он прав. То что ты с LINQ знаком черезвычайно поверхностно видно невооруженным взглядом из твоих слов.
Я не обижаюсь.
VD>Ты очень правильно сравнил (тут где-то рядом) LINQ с лист/куари-компрехеншоном. Это оно и есть, если говорить о синтаксисе. В язык просто засунут синтаксис который переписывается компилятором в вызовы функций высшего порядка.
Эрланговский QLC (query list conprehesion), с которым я сравнил LINQ, он не просто выглядит так же. Оно в Эрланге и работает примерно так же, дорогой тезка.
Это не list comprehensions. Это синтаксис list conprehensions, который переписывается компилятором при помощи parse transform в вызовы функций высшего порядка. Ну, не высшего, ок, в обычные функции, насколько я помню. Но точно так же — ты можешь определять произвольные источники данных, и эффекты во многом похожи.
Вопрос не в том, как оно работает и устроено, вопрос в том, нафига и с какой целью ее в язык добавили. Для решения какой проблемы. И вот когда ты это рассмотришь, то сдается мне первое что всплывет, это будет именно работа с реляционными источниками данных, самый распространенный из которых — РСУБД.
Здесь бы мне сказать "и что вы тут мне мозг компостируете столько времени", но ты со мной вежливо общаешься и мозг не компостируешь, поэтому я просто спрошу, понятна ли тебе теперь та мысль, которую я хотел до тебя донести в своем ответе в том посте, где впервые помянул LINQ. Я ее не слишком точно сформулировал, признаю.
Понятна ли мысль — это первый вопрос. Что ты об этом думаешь и согласен или не согласен — это тоже вопрос, но второй.
Здравствуйте, AndrewVK, Вы писали:
G>>К примеру, имея дело с CouchDB весь mapping сводится к сериалайзеру JSON. И все. Его же можно устроить достаточно "гражданским" образом, не применяя "магии". И будет _достаточно_ удобно.
AVK>В итоге тебе все равно придется эти данные обрабатывать в самом приложении.
Придется. А в случае использования LINQ — неужели не придется? Объясни, не понимаю.
Здравствуйте, jazzer, Вы писали:
J>Ну язык же динамически типизированный в этой части.
Меня интересуют в основном статически типизированные языки. Для Питона или Руби нтерфейсы не нужны, а утиная типизация у них работает везде просто потому, что они динамически типизированные.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Gaperton, Вы писали:
G>Какие проблемы решает LINQ, и что
Многие. В том числе казуальной обертки для ФП.
G>является для него killer application?
Как показало одно из обуждений данный термин понимается по разному.
Если говорить о главных особенностях, то их опять же много. Среди них и унификация обработки данных из разных источников (от списков объектов, до доступа к ООБД), и возможность обработки списков объектов в стиле ФП.
LINQ — это вообще торговая марка. В спецификации C# умудрились даже не дать его определения.
Ты же перескочил на обсуждение второстепенной темы и не понял того, что я тебе пытался сказать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Mirrorer, Вы писали:
G>>Извини, мне не интересно ни читать мануалы по С# 3.0, ни обсуждать с тобой LINQ. И то и другое имеет весьма далекое отношение к моей работе и интересам.
M>LINQ это монады в чистом виде.
Это мне известно.
M>Базы тут постолько поскольку M>И выстрелили они именно благодаря M>а) удобству записи лямбд M>б) выводу типов
Базы тут далеко не постольку поскольку.
Если бы не ацкие проблемы ввода-вывода в чистом Хаскеле, то и не было бы в нем все насквозь построено на монадах.
Монады при этом никак не завязаны на ввод-вывод, конечно. Однако, если бы не проблемы ввода-вывода, которые решаются монадами, то и do-синтаксис в Хаскель никто бы тащить не стал. В строгих языках ничего подобного нет, и не потому, что это не круто, бесполезно, или недостаточно общо, а просто потому, что нет ни острой проблемы ни необходимости.
Возвращаясь к базам — если бы не мэйнстримовые проблемы взаимодействия с реляционными базами, вынуждающие городить маппинг, скорее всего не было бы никакой поддержки LINQ в мэйнстримовом языке.
M>Неужели плохо иметь возможность использования удобных паттернов?
Неплохо. Но если убрать необходимость работы с реляционной базой, то не настолько необходимо, чтобы отсутствие являлось значимым недостатком.
Ты изучаешь технологии по статьям в Википедии?
