Здравствуйте, Cyberax, Вы писали:
C>LINQ — это лишь способ выдирать Expression Tree. А что ты с ним дальше делаешь — твоё личное дело. Можешь приспособить для решения диффуров и декодирования MPEG4.
Позанудствую. Преобразованием лямбд в ExpressionTree занимается непосредственно компилятор. Это всё можно делать и без Linq, так же как и Linq можно использовать без ExpressionTree.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, AndrewVK, Вы писали:
G>>Мой тезис состоял в том, что при решении задачи, в которой ты не работаешь с внешними источниками данных с реляционной моделью, выгода от LINQ как минимум неочевидна.
AVK>Ну, поскольку твой опыт в использовании линка, как я понимаю, чуть менее чем 0, то твоему экспертному мнению, не подкрепленному аргументами, я пока что не доверяю, уж извини.
Я вот совершенно уверен в том, что _мне_лично_ выгода не очевидна. И я совершенно не собираюсь тебя ни в чем убеждать — _мне_ она неочевидна, о чем я сообщаю, не пытаюсь тебе доказать, что ее нигде никогда нет. Ты высказываешь свое мнение, я свое. Мы ими обмениваемся. А не выясняем, какой эксперт экспертистее. Или я что-то не так понимаю, Андрей? Или так второе?
Я вижу, тебе по какой-то причине важно подчеркнуть, что у тебя опыт использования LINQ есть, а у меня нет. Пожалуйста. Да, опыта использования LINQ у меня в районе ноля, если не считать, что он похож на query list сomprehesions Эрланга, конечно. Но давай притворимся, что ничего общего между ними нет, и что LINQ жутко сложная штука, в которой я совсем ничерта не понимаю, я совершенно не против .
G>>Учитывая, что LINQ по большому счету заточен под прикладную задачу, и нафиг не вперся в случае, если мы не работаем с реляционной БД.
AVK>Вот этот тезис — неверен и бездоказателен.
Считаешь что неверен — возрази. Будут нормальные доводы — не только соглашусь, но и спасибо скажу.
G>>Однако, если ты хочешь возразить мне по существу тезиса — пожалуйста.
AVK>Возражать можно только на конкретные аргументы. А возражать против твоего голого имха сродни занятию пенисометрией.
Ок, не возражай. Андрей, я проблемы-то не вижу никакой, в чем дело-то? Кто-то заставляет тебя так реагировать на голое ИМХО, что это становится сродни занятию пенисометрией, я не пойму? На РСДН запретили разговорить конструктивно? Или на РСДН запретили высказывать ИМХО?
Здравствуйте, Cyberax, Вы писали:
C>LINQ — это лишь способ выдирать Expression Tree. А что ты с ним дальше делаешь — твоё личное дело. Можешь приспособить для решения диффуров и декодирования MPEG4.
Простой вопрос — а нафига мне выдирать Expression Tree и что-то с ним делать, не имея действительно строгих к тому показаний, что без этого реально сильно туго/сложно получается?
G>>Да, тогда б конечно. Я наверное поверил бы, что при работе с базой данных map-reduce без LINQ никак нельзя обойтись. Вероятно, я бы проигнорировал даже тот факт, что там совсем не реляционная модель в основе, и в этих плясках с бубнами нет необходимости. C>Так никто не говорит, что "не обойтись". Но с LINQом многое удобнее.
А настолько-ли удобнее, чтобы ради пары финтифлюшек тянуть в решение очередную концепцию, и вводить еще один indirection level? Покажи, какие именно вещи ты сделаешь удобнее, в случае SIP-сервера. Задача ведь тебе знакома, так? Или библиотеки а-ля gstreamer. Что, правда радикальный эффект получится, да?
C>Вот тут его для Coachdb можно использовать: http://james.newtonking.com/projects/json/help/
Нафига? Ты представляешь себе характер запросов при работе с CouchDB? Ты в большинстве сразу из вьюхи-мапа простым лукап-запросом вынимаешь готовые данные, которые уже правильно сгруппированы, и все. Там многие вещи, привычные по реляционным БД, делаются _по_другому_. Т.е. совсем. Так, что не приходится ничего по сусекам выскребать.
Здравствуйте, Gaperton, Вы писали:
C>>LINQ — это лишь способ выдирать Expression Tree. А что ты с ним дальше делаешь — твоё личное дело. Можешь приспособить для решения диффуров и декодирования MPEG4. G>Простой вопрос — а нафига мне выдирать Expression Tree и что-то с ним делать, не имея действительно строгих к тому показаний, что без этого реально сильно туго/сложно получается?
В более человеческом стиле писать запросы или комбинировать предикаты для map/reduce, например.
C>>Так никто не говорит, что "не обойтись". Но с LINQом многое удобнее. G>А настолько-ли удобнее, чтобы ради пары финтифлюшек тянуть в решение очередную концепцию, и вводить еще один indirection level? Покажи, какие именно вещи ты сделаешь удобнее, в случае SIP-сервера. Задача ведь тебе знакома, так? Или библиотеки а-ля gstreamer. Что, правда радикальный эффект получится, да?
Не, ну так можно сказать о функциональном программировании, объектном ориентировании и т.п.
LINQ просто часто позволяет вместо простынь кода писать что-то короткое и красивое. Например, для SIPа это может быть поиск правил, подходящих по номеру, или поиск маршрута для пакета. Оно вообще по мелочи много где полезно бывает.
C>>Вот тут его для Coachdb можно использовать: http://james.newtonking.com/projects/json/help/ G>Нафига? Ты представляешь себе характер запросов при работе с CouchDB? Ты в большинстве сразу из вьюхи-мапа простым лукап-запросом вынимаешь готовые данные, которые уже правильно сгруппированы, и все. Там многие вещи, привычные по реляционным БД, делаются _по_другому_. Т.е. совсем. Так, что не приходится ничего по сусекам выскребать.
Ну вот эту вьюху можно записать в виде LINQ. Оно для этого вообще идеально подходит. И где-то я это даже уже видел.
Здравствуйте, Cyberax, Вы писали:
C>>>LINQ — это лишь способ выдирать Expression Tree. А что ты с ним дальше делаешь — твоё личное дело. Можешь приспособить для решения диффуров и декодирования MPEG4. G>>Простой вопрос — а нафига мне выдирать Expression Tree и что-то с ним делать, не имея действительно строгих к тому показаний, что без этого реально сильно туго/сложно получается? C>В более человеческом стиле писать запросы или комбинировать предикаты для map/reduce, например.
Зачем мне комбинировать предикаты для map/reduce как-то "выдирая Expresison Tree", если я прям в теле функций map и reduce могу их "скомбинировать" стандартными средствами языка? Вот взять, в случае CouchDB, и обратиться к объектам JSON на родном для них JavaScript? map и reduce — это самые обычные, простые функции.
C>>>Так никто не говорит, что "не обойтись". Но с LINQом многое удобнее. G>>А настолько-ли удобнее, чтобы ради пары финтифлюшек тянуть в решение очередную концепцию, и вводить еще один indirection level? Покажи, какие именно вещи ты сделаешь удобнее, в случае SIP-сервера. Задача ведь тебе знакома, так? Или библиотеки а-ля gstreamer. Что, правда радикальный эффект получится, да? C>Не, ну так можно сказать о функциональном программировании, объектном ориентировании и т.п.
C>LINQ просто часто позволяет вместо простынь кода писать что-то короткое и красивое. Например, для SIPа это может быть поиск правил, подходящих по номеру, или поиск маршрута для пакета. Оно вообще по мелочи много где полезно бывает.
Поиск маршрута для пакета — это один лукап по "номерному плану". Таблица такая, с масками номеров, и дестинайшнами. Берется номер. Матчится.
Как-то маловато пользы от отсутствующего LINQ просматривается для того, чтобы такой славный Go отправлять втопку на задаче, например, SIP-сервера — решающее в ней совершенно не способность языка к LINQ, а другие качества.
Я так напоминаю — разговор вообще о Go. А не о том, как я не люблю LINQ.
C>>>Вот тут его для Coachdb можно использовать: http://james.newtonking.com/projects/json/help/ G>>Нафига? Ты представляешь себе характер запросов при работе с CouchDB? Ты в большинстве сразу из вьюхи-мапа простым лукап-запросом вынимаешь готовые данные, которые уже правильно сгруппированы, и все. Там многие вещи, привычные по реляционным БД, делаются _по_другому_. Т.е. совсем. Так, что не приходится ничего по сусекам выскребать. C>Ну вот эту вьюху можно записать в виде LINQ. Оно для этого вообще идеально подходит. И где-то я это даже уже видел.
Можно. Тока опять, решающее преимущество разве будет? Вьюхи — не нормализованная система таблиц. Это денормализованный набор map-ов, с ключом и результатом произвольного типа, возможно составного. Его надо проектировать так, чтобы join-ов и OR-маппинга не возникало, и запросы были просты. Запрос по ключу — получаешь JSON документ. Отправил в браузер. Тот его прожевал — показал. И все. Нет semantic gap, который надо устранять, он сведен к минимуму.
Ты изучаешь технологии по статьям в Википедии?
Влад, полноти.
Загрузи бесплатный C# Express и попробуй LINQ в реальной обстановке.
Если же обращаешься к Википедии, то хотя бы используй английский вариант: http://en.wikipedia.org/wiki/Language_Integrated_Query
G>Покажи мне пожалуйста, каким именно образом можно обойти вниманием реляционную модель, реляционные базы данных, и SQL, говоря о LINQ.
Ты не на того напал. Не стоит подменять мои слова и заставлять меня спорить с самим собой. Я на такие приемы давно не покупаюсь.
Давай лучше я еще раз и более развернуто объясню тебе, что имел в виду? ОК?
Так вот. LINQ — это:
1. Библиотека функций высшего в которой привычные для функциональщиков имена ФВП заменены на аналоги из SQL. При этом с самим SQL функции и даже синтаксис LINQ имеет мало общего. Эта библиотека имеет отдельное название LINQ to Object.
2. Синтаксические расширения языков. На самом деле не более чем сахар, так как и без них все ОК.
3. Языковые расширения позволяющие преобразовывать код так называемых лябда-выражений в AST (обозванное Expression [Tree]).
4. Ряд провайдеров позволяющих преобразовывать Expression Tree в запросы к внешним источникам данных.
G>Потом попробуй мне объяснить, каким именно боком LINQ, SQL, и реляционная модель тебе пригодиться, к примеру, при работе с базой данных построенной на схеме map-reduce. Если не слышал о таких — погугли.
G>Вообще есть огромный мир, лежащий за рамками того, к чему вы привыкли. Мир, в котором сервера работают не под Windows, и в котором не применяют РСУБД. В задачах телекома, к примеру, покажешь мне, в какое место засунуть ваш LINQ, и каким образом люди без него спокойно обходятся? Вне контекста баз данных, разумеется. Он же типа совсем-пресовсем никакого отношения к ним не имеет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Gaperton, Вы писали:
VD>>Прости, но когда я прочел твое сравнение этого Гоу с Питоном, то у меня возникло стйкое ощущение, что как минимум Питон ты точно знаешь очень поверхностно.
G>А меня вот уже давно возникло стойкое ощущение, что 90% языков, которые ты берешься обсуждать, ты знаешь очень поверхностно.
Я этого и не скрываю. Но не до такой степени, чтобы не понимать, что класс задач у Гоу и Питона координально различаются.
G>К разговору твоя личность конечно не имеет никакого отношения, как и моя, но почему бы тебе не узнать об этом моем ощущении, правда? Не вижу причин, почему нет.
Ну, до определенной черты в общем-то ничего страшного. Просто в запале эта черта очень легко переходится. Предлагаю стараться контролировать этот процесс.
G>Кстати, я не сравнивал этот язык с Питоном. Я говорил, что класс задач для этого языка будет примерно похожий. Имея при этом в виду серверные приложения Питона — в следующем посте есть пояснение, кстати. Но ты же у нас не всегда задумываешься над тем, что комментируешь. Так что я не в претензии.
Я не профи в Питоне, но понимаю суть языка. Посему ствои слова вызыват у меня удивление.
Основой фишкой питона является прототипный ООП, динамический контроль типов, утиная типизация и метапрограммирование которые замечательно получается на базе предыдущих фишек. В Гоу этим даже не пахнет. Напротив Гоу предлагате статическую типизацию. Упрощенный до нельзя ООП (или закос на него).
Все это наследие Оберона, а не питона. И стало быть ниши этот язык будет скорее всего делить не с Питоном, а с Обероном и Компонентным Пасклаем (ака Блэк Бокс).
VD>>В общем, нравится тебе этот язык. Замечательно. Только не надо его героизировать. А то станешь похожим на Вирта с его обероном.
G>Я его не героизирую. Я отметил, что он мне понравился, и ничего больше. Можно, разрешаешь? Секта не против? А то порядки у вас больно строгие.
Шутка повторенная дважды перестает быть шуткой. У всех у нас есть свои "секты". Мировозрение разных людей не может быть идентичным.
Я стараюсь быть беспреспрестрастным когда говорю о языках. Чего и тебе советую.
Пойми я возразил тебе исключительно из-за тог, что твои рассужения, на мовй скромный взгляд, очень далеки от реальности.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Gaperton, Вы писали:
G>Я вот совершенно уверен в том, что _мне_лично_ выгода не очевидна.
Отличная позиция. Не знаю и знать не хочу. Только остальным то какое до этого дело?
G>Я вижу, тебе по какой-то причине важно подчеркнуть, что у тебя опыт использования LINQ есть
Нет. Но если делаешь заявления — будь добр их аргументировать.
G>, а у меня нет. Пожалуйста. Да, опыта использования LINQ у меня в районе ноля, если не считать, что он похож на query list сomprehesions Эрланга, конечно.
Оно тоже исключительно под реляционные БД заточен?
AVK>>Вот этот тезис — неверен и бездоказателен.
G>Считаешь что неверен — возрази.
Еще раз — ты выдвинул, тебе и доказывать. И никак иначе.
G> Будут нормальные доводы — не только соглашусь, но и спасибо скажу.
Нормальные доводы лежат на поверхности, достаточно взглянуть на имеющиеся прямо в BCL linq2objects и linq2xml, про которые упомянуто даже в бездарной статье в русской википедии. Ссылку на linq для CoachDB тебе тоже уже приводили. Есть linq для db4o. Этого мало?
... << RSDN@Home 1.2.0 alpha 4 rev. 1276 on Windows 7 6.1.7600.0>>
Здравствуйте, VladD2, Вы писали:
VD>Основой фишкой питона является прототипный ООП, динамический контроль типов, утиная типизация и метапрограммирование которые замечательно получается на базе предыдущих фишек. В Гоу этим даже не пахнет.
Утячья типизация в нем есть.
... << RSDN@Home 1.2.0 alpha 4 rev. 1276 on Windows 7 6.1.7600.0>>
Здравствуйте, IT, Вы писали:
IT>Позанудствую. Преобразованием лямбд в ExpressionTree занимается непосредственно компилятор. Это всё можно делать и без Linq, так же как и Linq можно использовать без ExpressionTree.
Это вопрос того, что понимать под LINQ. МС под ним понимает весь набор функционала, не только query comprehension.
... << RSDN@Home 1.2.0 alpha 4 rev. 1276 on Windows 7 6.1.7600.0>>
Ты его не там ищешь. LINQ обеспечивает бесшовную интеграцию системы типов БД и системы типов используемого языка.
G> Вьюхи — не нормализованная система таблиц. Это денормализованный набор map-ов, с ключом и результатом произвольного типа, возможно составного.
В контексте LINQ это совершенно пофик.
... << RSDN@Home 1.2.0 alpha 4 rev. 1276 on Windows 7 6.1.7600.0>>
Здравствуйте, VladD2, Вы писали:
VD>Я этого и не скрываю. Но не до такой степени, чтобы не понимать, что класс задач у Гоу и Питона координально различаются.
Все не так прямолинейно. Питон, как это ни странно, довольно часто применяется для серверных задач. В том же классе аппликух, что и Эрланг.
Вот там-то его гоу и настигнет. Гоу уровнем пониже питона и попроще, это так. Зато, он быстр, и _достаточно_ выразителен, чтобы выкинуть _связку_ С/С++ — Питон. Он не заставляет выбирать между комфортом, простотой языка, и эффективностью, предоставляя достаточно неплохой балланс.
Да, и Эрлангу эта штука тоже вполне конкурент. Не потому, что язык похож чем-то, а потому, что удобен в том же классе задач.
G>>К разговору твоя личность конечно не имеет никакого отношения, как и моя, но почему бы тебе не узнать об этом моем ощущении, правда? Не вижу причин, почему нет.
VD>Ну, до определенной черты в общем-то ничего страшного. Просто в запале эта черта очень легко переходится. Предлагаю стараться контролировать этот процесс.
Думаю, ты знаешь, что контроллировать этот процесс и оставаться на грани я умею достаточно хорошо — примерно как и ты. И именно поэтому предлагаю более радикальный подход — воздержаться от перехода на личности вообще. Это в данном случае бессмысленно, и совершенно ни к чему не приведет. Мне вот, честно, даже напрягаться лень.
VD>Я не профи в Питоне, но понимаю суть языка. Посему ствои слова вызыват у меня удивление. VD>Основой фишкой питона является прототипный ООП, динамический контроль типов, утиная типизация и метапрограммирование которые замечательно получается на базе предыдущих фишек. В Гоу этим даже не пахнет. Напротив Гоу предлагате статическую типизацию. Упрощенный до нельзя ООП (или закос на него). VD>Все это наследие Оберона, а не питона. И стало быть ниши этот язык будет скорее всего делить не с Питоном, а с Обероном и Компонентным Пасклаем (ака Блэк Бокс).
Ты пытаешься определить нишу применений, сравнивая отдельные языковые фичи. Я же это делаю, рассматривая комбинации фич, и их пользу в контексте конкретных прикладных задач/проблем, с целью определить сильные стороны платформы, и из этого уже вывести класс применений, где они будут важны. Это главная и существенная разница в наших "методологических подходах".
Go, будучи статически типизированным, разработан так, чтобы сохранить ощущение "легкости" и простоты, возникающей при применении динамических языков. Андрей рядом правильно тебе указал, что там есть утиная типизация.
Rather than requiring the programmer to declare ahead of time that two types are related, in Go a type automatically satisfies any interface that specifies a subset of its methods.
Ты вообще посмотри их language design FAQ, он короткий, и снимает все вопросы. http://golang.org/doc/go_lang_faq.html
VD>Пойми я возразил тебе исключительно из-за тог, что твои рассужения, на мовй скромный взгляд, очень далеки от реальности.
Как ты понимаешь, я думаю ровно наоборот. И ты должен знать, что я вроде как не полный идиот. Стало быть, на то есть причины. Можно обсуждать эти причины. Это и есть конструктивная дискуссия.
Здравствуйте, Gaperton, Вы писали:
ВВ>>У тебя не возникает сомнения, что твое мнение о LINQ на основе статьи из википедии может быть, скажем так, не совсем полным?
G>Вот у тебя, к примеру, не возникло сомнения в том, что я знаком с LINQ только по русской википедии. Ты, также, по видимому, абсолютно уверен в том, что я просто не понимаю LINQ, а ты понимаешь, и ты хочешь мне это показать.
Влад, не обижайся, но он прав. То что ты с LINQ знаком черезвычайно поверхностно видно невооруженным взглядом из твоих слов.
Ты очень правильно сравнил (тут где-то рядом) LINQ с лист/куари-компрехеншоном. Это оно и есть, если говорить о синтаксисе. В язык просто засунут синтаксис который переписывается компилятором в вызовы функций высшего порядка.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
G>>Можно. Тока опять, решающее преимущество разве будет?
AVK>Ты его не там ищешь. LINQ обеспечивает бесшовную интеграцию системы типов БД и системы типов используемого языка.
В этой области искать преимущество LINQ мне запретили эксперты по LINQ, как ты мог заметить.
G>> Вьюхи — не нормализованная система таблиц. Это денормализованный набор map-ов, с ключом и результатом произвольного типа, возможно составного. AVK>В контексте LINQ это совершенно пофик.
Не совсем пофиг, и дело не в LINQ. Дело в проблеме, которую он эффективно решает.
В контексте работы с базой map-reduce, не возникает проблемы mapping-а типов в тех масштабах и в таком виде, как при работе с РСУБД. И, как следствие, острой необходимости с ней бороться. Функции map и reduce пишутся в терминах "родных" типов. Отдельного развитого языка запросов нет — он не нужен. Данные в таких базах обычно нетипизированы — они лишены структуры и схемы. Поэтому, нет большого количества "типов", с которыми надо интегрироваться.
К примеру, имея дело с CouchDB весь mapping сводится к сериалайзеру JSON. И все. Его же можно устроить достаточно "гражданским" образом, не применяя "магии". И будет _достаточно_ удобно.
Это все имеет значение почему. Масштабируемые веб-приложения, способные работать на больших фермах, строятся сейчас и будут в будущем строиться на базе map-reduce.
Здравствуйте, AndrewVK, Вы писали:
AVK>Это вопрос того, что понимать под LINQ. МС под ним понимает весь набор функционала, не только query comprehension.
Мне кажется, что МС вообще ничего не понимает, а его представители в разных местах под этой аббревиатурой понимают разные вещи.
В спецификации C# 3.0 эта аббревиатура не встречается во все, а 4.0 только один раз:
This is useful in many LINQ methods. Using the declarations above:
var result = strings.Union(objects); // succeeds with an IEnumerable<object>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
VD>>Основой фишкой питона является прототипный ООП, динамический контроль типов, утиная типизация и метапрограммирование которые замечательно получается на базе предыдущих фишек. В Гоу этим даже не пахнет.
AVK>Утячья типизация в нем есть.
А можно ссылку на описание?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Gaperton, Вы писали:
AVK>>Ты его не там ищешь. LINQ обеспечивает бесшовную интеграцию системы типов БД и системы типов используемого языка.
G>В этой области искать преимущество LINQ мне запретили эксперты по LINQ, как ты мог заметить.
Может и мог, но не заметил.
G>К примеру, имея дело с CouchDB весь mapping сводится к сериалайзеру JSON. И все. Его же можно устроить достаточно "гражданским" образом, не применяя "магии". И будет _достаточно_ удобно.
В итоге тебе все равно придется эти данные обрабатывать в самом приложении.
... << RSDN@Home 1.2.0 alpha 4 rev. 1276 on Windows 7 6.1.7600.0>>
Здравствуйте, Gaperton, Вы писали:
G>Все не так прямолинейно. Питон, как это ни странно, довольно часто применяется для серверных задач. В том же классе аппликух, что и Эрланг.
Все очень даже прямолинейно. Питон во много раз мощнее этого Гоу. И в ближайшие лет 5 Гоу его не догонит. В то же время, по скорости этот Гоу будет соперничать скорее с C# и Явой. Они тоже в серверных приложениях во всю применяются. Ты сейчас пользуешься сервером написанном на C#.
G>Вот там-то его гоу и настигнет. Гоу уровнем пониже питона и попроще, это так. Зато, он быстр, и _достаточно_ выразителен, чтобы выкинуть _связку_ С/С++ — Питон. Он не заставляет выбирать между комфортом, простотой языка, и эффективностью, предоставляя достаточно неплохой балланс.
Не смешите мои тапочки. Если люди вместо Явы взяли Питон, значит им нужна краткость синтаксиса и мощь метапрограммирования. Ну, или эти люди просто балованы использующие не подходящий для решаемой задачи инструмент.
G>Да, и Эрлангу эта штука тоже вполне конкурент. Не потому, что язык похож чем-то, а потому, что удобен в том же классе задач.
Не ты ли тут рассказывал, что без языковых особенностей Эрланга реализовать аналогичные фичи (легкие процессы общающеся между собой сообщениями) эффективно будет крайне тяжело? Если же говорить только о самих фишках, то конечно, наличие встроенных средств работы с многопоточностью чем-то роднит Эрланг и Гоу. Но тем самым класс задач у них не сильно пересекается. То что легко и качественно пишется на Эрланге на Гоу будет болью в жопе.
И опять же. В питоне как раз нет встроенных фишек работы с многопоточностью. Но зато в нем есть мега-фича — метапрограммирование которое позоляет реализовать в питоне любую из таких фишек. И те кого не устроят фишки Гоу опять же предпочтут питон.
G>Думаю, ты знаешь, что контроллировать этот процесс и оставаться на грани я умею достаточно хорошо — примерно как и ты. И именно поэтому предлагаю более радикальный подход — воздержаться от перехода на личности вообще. Это в данном случае бессмысленно, и совершенно ни к чему не приведет. Мне вот, честно, даже напрягаться лень.
Я именно это и предлагал. Так что давай от обсуждения мох знаний в других языках перейдем к обсуждению того, что же ты такого нового и привлекательного увидел в Гоу.
VD>>Я не профи в Питоне, но понимаю суть языка. Посему ствои слова вызыват у меня удивление. VD>>Основой фишкой питона является прототипный ООП, динамический контроль типов, утиная типизация и метапрограммирование которые замечательно получается на базе предыдущих фишек. В Гоу этим даже не пахнет. Напротив Гоу предлагате статическую типизацию. Упрощенный до нельзя ООП (или закос на него). VD>>Все это наследие Оберона, а не питона. И стало быть ниши этот язык будет скорее всего делить не с Питоном, а с Обероном и Компонентным Пасклаем (ака Блэк Бокс).
G>Ты пытаешься определить нишу применений, сравнивая отдельные языковые фичи.
Ну, почему же? Я вижу суть языка.
В последнее время танкостроение стало моим хобби. Я не утверждаю, что я мега-крут в этой области, но все же такие базовые вещи я различаю очень хорошо.
Так вот задачи для которых предназначен Гоу, на мой взгляд — это не сложные по логике, требующие более-менее приемлемой производительности, и надежности программы. Серверные, не серверные без разницы. Хотя конечно типобезопасный язык на сервере более важен в виду требований к устойчивости.
Питон же как раз сильно отличается тем, что обеспечивает решение более сложных задач за счет намного более мощьных языковых возможностей, но при этом не обеспечивающий приемлемой производительности и от того не применимый в так называемых системных задачах.
G> Я же это делаю, рассматривая комбинации фич, и их пользу в контексте конкретных прикладных задач/проблем, с целью определить сильные стороны платформы, и из этого уже вывести класс применений, где они будут важны. Это главная и существенная разница в наших "методологических подходах".
Ну, и как ты тогда умудряешься не замечать того, что языки очень сильно отличаются? Они предполагают радикально разный подход к разработке!
G>Go, будучи статически типизированным, разработан так, чтобы сохранить ощущение "легкости" и простоты, возникающей при применении динамических языков. Андрей рядом правильно тебе указал, что там есть утиная типизация.
G>http://golang.org/doc/go_lang_faq.html#inheritance G>
G>Rather than requiring the programmer to declare ahead of time that two types are related, in Go a type automatically satisfies any interface that specifies a subset of its methods.
Да, я его смотрел. Но все детали сразу не углядишь.
VD>>Пойми я возразил тебе исключительно из-за тог, что твои рассужения, на мовй скромный взгляд, очень далеки от реальности.
G>Как ты понимаешь, я думаю ровно наоборот.
Понимаю .
G> И ты должен знать, что я вроде как не полный идиот. Стало быть, на то есть причины. Можно обсуждать эти причины. Это и есть конструктивная дискуссия.
Ну, не надо быть идиотом, чтобы выдавать желаемое за действительное. Все мы этим грешны под час.
Ты не плохой пиарщик и подчас умудряешься описать вещь намного более красочно чем она выглядит на самом деле.
ЗЫ
Кстати, возникла одна идея. Можно организовать небольшую "войнушку"... Завести отдельную тему в которой попробовать сравнить языки по выразительной мощности.
Я могу выступить за C# и Nemere. Ты за Go и Erlang, FR за Python, ну, и может быть еще кто-то подтянется. За одно можно будет сравнить полученные решения на скорость. Думаю, эта "битва" была бы интересна очень многим.
Ну, как идея?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Если нам не помогут, то мы тоже никого не пощадим.
Или так второе? 
Андрей, я проблемы-то не вижу никакой, в чем дело-то? 
Ты изучаешь технологии по статьям в Википедии?
