Здравствуйте, Lloyd, Вы писали:
L>Take возвращает первые n элементов коллекции.
Но если ты не понял иронии в моем примере, то ладно. Раз ты такой серьезный, то, вероятно, мне надо по честному показать, что же надо сделать, чтобы ровно тот же самый кусок кода ровно так же сработал в Go. Так вот, примерно это:
func ( arr []string )Sum( f func (string) int ) sum int {
for _, val := range arr {
sum += f( val )
}
return
}
После чего, я задам полный Split, и вместо Take просто возьму от него слайс. Как-то так:
pos := strings.Split( text, "\n", 0 )[0:line-1].Sum( func( s string ) int { return len( s ) + 1 } ) + column;
Этот пример иллюстрирует одно из интереснейших свойств Go — "ортогональность" методов и типов. Без generic-ов такие штуки в полный рост изображать тяжело, конечно. Но их скоро добавят.
Только нафига так делать, если можно писать по-простому? Забыли уж поди, как оно по-простому-то делается?
Здравствуйте, Lloyd, Вы писали:
L>>>Take возвращает первые n элементов коллекции.
G>>А strings.Split с третьим параметром, отличающимся от ноля, бьет строку ровно на заданное количество сегментов. Причем, последний сегмент, который я и забираю указывая [line], остается не разбитым. Да, вероятно я немного ошибся, и надо указать [line-1]
L>Думаю будет проще объяснить, что делает код: он вычисляет порядковый номер символа в тексте через его строку (line) и колонку (column).
Здравствуйте, Gaperton, Вы писали:
L>>Думаю будет проще объяснить, что делает код: он вычисляет порядковый номер символа в тексте через его строку (line) и колонку (column).
G>Да ну? Правда что-ли?
Здравствуйте, Lloyd, Вы писали:
G>>Только нафига так делать, если можно писать по-простому? Забыли уж поди, как оно по-простому-то делается?
L>По-простому — это то мясо, что ты написал? Это опять ирония что-ли?
Здравствуйте, IT, Вы писали:
IT>Я это всё к тому, что метды Take и Sum принадлежат классу Enumerable пространства имён (внимание!) System.Linq. А ты к чему?
К выделенному.
IT>>>Без линка пришлось бы наворачивать циклы и состояния. Это я к вопросу о незначительности решения. И таких упражнений в день у меня по сто штук без всяких баз данных.
Здравствуйте, Gaperton, Вы писали:
G>>>Только нафига так делать, если можно писать по-простому? Забыли уж поди, как оно по-простому-то делается?
L>>По-простому — это то мясо, что ты написал? Это опять ирония что-ли?
G>По-простому, это без ФВП и линков.
Не очень-то удачная попытка. С линком значительно проще.
Здравствуйте, Lloyd, Вы писали:
L>>>Думаю будет проще объяснить, что делает код: он вычисляет порядковый номер символа в тексте через его строку (line) и колонку (column).
G>>Да ну? Правда что-ли?
L>Yup.
Здравствуйте, VladD2, Вы писали:
VD>Любая задача, в том числе "задача построения коммуникаций" в конечном итоге состоит из обработки данных. Так что LINQ в ней будет применим по любому.
В какой-то степени — да. Вопрос только в значимости тех упрощений, которые даст LINQ для задач построения коммуникаций.
VD>Это примерно так же как в любой задаче можно применять циклы.
Ага, осталось довести до абсурда и вспомнить, что все Тьюринг-полные языки равны по своим возможностям.
VD>Все что Гапертон говорил про линк — это набор заблуждений. Их развенчали сразу несколько человек. Но вы с Гапертоном даже не удосужились задуматься над их словами. А ты нагло врешь говоря "опровержений тезису Гапертона так и не появилось".
Их и не могло появиться, причина — ниже.
ГВ>>По отношению к любой вещи, понимаешь ли, можно задать два независимых вопроса: "зачем?" и "чем является?" [...] Понятна коллизия? VD>[...] На что ему было убедительно доказано и много раз подтверждено практикой целой кучи людей, что ЛИНК не заточен ни под одну прикладную задачу и с базами данных работает по стольку по скольку умеет работать и с ними. Целая куча работы сказал ему и тебе, что использует линк исключительно для обработки списков объектов.
VD>Поясни в чем тут коллизия.
Коллизия между вопросами "зачем оно" и "что оно из себя представляет". Ответ на первый вопрос требует анализа причинно-следственных связей, которые привели к появлению предмета. Ответ на второй вопрос требует разбора внутренней структуры предмета. Выводы, полученные из ответа на второй вопрос ненадёжны, если мы ищем ответ на первый. Скажем, из того, что под влиянием LINQ (возможно) многие плотнее изучили ФП ещё не следует, что в первоначальные замыслы разработчиков LINQ входило несение света ФП в массы (зачем тогда маскировать ФП-конструкции под SQL-подобными?) А вот из того, что в 90-х — начале 2000-х ORM был едва ли не самым горячим топиком IT-сообществ очень даже напрашивается вывод, что как раз проблемами ORM и был вызван к жизни LINQ.
Кстати, любопытное подтверждение рассуждениям о возможном влиянии РСУБД мы находим в документации на SQL Server 2005:
You can use .NET Framework languages in addition to the Transact-SQL programming language to create database objects and retrieve and update data for Microsoft SQL Server 2005 databases. In Visual Basic, Visual C#, or Visual C++ projects, you can create stored procedures, triggers, aggregates, user-defined functions, and user-defined types.
Спору нет, LINQ — очень неплохое дополнение для языка, работающего в плотной связи с SQL Server. Обрати внимание, фактически здесь сказано об использовании языков .Net во вполне определённой среде, а здесь это не просто использование, это очень неплохой маркетинговый ответ Oracle. Как по мне, так эта причина стоит гораздо больше, чем возможность сканировать массивы объектов. И снова, смотрим на среду: оба-на — РСУБД!
Что до неточностей формулировок в высказываниях на форуме, так их я списываю на ту или иную степень эмоциональной компоненты в реакциях собеседников. Все ж живые люди, в конце концов.
VD>В прочем что ты тут можешь пояснить? Это гон чистой воды. И разбивается он примитивными примерами использования линка для обработки массивов, списков и других коллекций.
А давай не будем путать причины появления X и возможности X? Это две большие разницы. Я не собираюсь спорить с тем, что помимо работы с РСУБД LINQ подходит ещё для кучи других задач, это вполне естественно. Но причины появления из существующих возможностей однозначно вывести можно далеко не всегда.
VD>Только полное не понимание предмета разговора и еще большее не желание призначать собственную не правоту привело к этому бредовешему флэйму.
Опять двадцать пять.
VD>Мне кажется, что получив по 7 и более минусов за первые свои два сообщения он мог бы остановиться и задуматься.
Спроси у Гапертона об этом. На меня, например, минусы действуют ровно в той же степени, что и плюсы — как признак наличия обратной связи.
ГВ>>[... мобильный телефон ... изоморфны демагогическим приёмам ... вычислить моё целеполагание ...] VD>Вот эту демагогию ты оставь для других. Мы обсуждаем тут ЛИНК. Вот о нем и говори.
Поаккуратней с повелительным наклонением. Если ты не понимаешь иллюстрации, то лучше переспроси, я объясню.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Lloyd, Вы писали:
L>>>По-простому — это то мясо, что ты написал? Это опять ирония что-ли?
G>>По-простому, это без ФВП и линков.
L>Не очень-то удачная попытка. С линком значительно проще.
Понятие "простоты" у всех разное. Мой первый пример задействует базовые выразительные средства, в нем меньше телодвижений и суеты, и он должен быстрее работать.
А чтобы получить запись в точности как у вас в примере с линком, мне надо один раз написать несколько строк кода — как во втором примере. Не вижу никакой проблемы. Ты хоть понял, как и почему он работать-то будет? Или надо объяснять?
Не очень удачный пример — тот, который выбрал IT для демонстрации силы линка. Я бы на его месте другое что-нибудь привел.
If n > 0, split Splits s into at most n substrings; the last substring will be the unsplit remainder.
Я указываю, на сколько максимум подстрок надо быть строку. И последняя подстрока будет неразбита, и содержать остаток текста. Моя программа использует этот факт. И все.
Здравствуйте, VladD2, Вы писали:
ГВ>>По-видимому, тебе показалось, что обсуждение носит слишком общий характер, поскольку задачи, решаемые пропонентами Go не похожи на те, которые решаешь ты и ещё несколько активных защитников LINQ.
VD>Опять врешь.
Как я могу врать в предположениях — тайна сия велика есть.
VD>Вот сообщение гапертона в котором он сам отлично описал все смыслы которые могут вкладываться в эти общие понятия: VD>http://rsdn.ru/forum/philosophy/3608581.aspx
Обрати внимание, когда это произошло.
VD>ЛИНК ты вообще приплел из обще-демагогических соображений. Он был не боле чем примером.
О! Уже, оказывается, я приплёл LINQ. Офигительно.
ГВ>> В этом нет ничего страшного и нет никакой попытки кого-то задеть, просто акценты на фичах языка люди с разной спецификой работы расставляют по-разному. VD>Не было никаких акцентов. Было два слишком общих понятия смысл которых попросили уточнить.
Дык. В том-то и фокус, что эти самые смыслы влёт считываются людьми, работающими над схожими проблемами.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Gaperton, Вы писали:
G>>>По-простому, это без ФВП и линков.
L>>Не очень-то удачная попытка. С линком значительно проще.
G>Понятие "простоты" у всех разное. Мой первый пример задействует базовые выразительные средства, в нем меньше телодвижений и суеты, и он должен быстрее работать.
По поводу "меньше телодвижений" это ты сильно преувеличиваешь. А почему он может быстрее работать?
G>А чтобы получить запись в точности как у вас в примере с линком, мне надо один раз написать несколько строк кода — как во втором примере. Не вижу никакой проблемы.
Зачем что-то писать, когда можно воспользоваться готовыми средствами?
G>Ты хоть понял, как и почему он работать-то будет? Или надо объяснять?
Здравствуйте, Gaperton, Вы писали:
G>Я указываю, на сколько максимум подстрок надо быть строку. И последняя подстрока будет неразбита, и содержать остаток текста. Моя программа использует этот факт. И все.
Здравствуйте, Gaperton, Вы писали:
G>Не очень удачный пример — тот, который выбрал IT для демонстрации силы линка. Я бы на его месте другое что-нибудь привел.
Я тебе демонстрировал не силу линка, а его использование без БД. Или ты теперь с БД решил переключиться на силу? Думаю, в твоём исполнении это уже никому не будет интересно.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>В какой-то степени — да. Вопрос только в значимости тех упрощений, которые даст LINQ для задач построения коммуникаций.
Значимость можно оценить только попробовав самостоятельно. Тебе похоже это не гразит, так как ты исходно пологаешь, что тебе это все на фиг не нужно.
Для остальных же скажу, что применение ЛИНК-а по сравнению с традиционными для C# и Явы средствами позволяет сократить код в несколько раз. В некоторых случаях в 10-20 раз.
VD>>Это примерно так же как в любой задаче можно применять циклы.
ГВ>Ага, осталось довести до абсурда и вспомнить, что все Тьюринг-полные языки равны по своим возможностям.
А никакого абсурда. Это тольк ты понять не можешь. ЛИНК по сути и есть замена циклов.
Я думаю, что STL ты знаешь. Так? Ну, вот LINQ 2 Objects — это STL на стеройдах.
Так что если для решения некоторой задачи ты в силах применить STL вместо циклов, то работая на C# 3.0 сможешь там же применить ЛИНК. Причем объем кода будет существенно меньше чем на С++ с использованием STL и несравнимо меньше по сравнению с реализацией того же самого на циклах.
ГВ>Коллизия между вопросами "зачем оно" и "что оно из себя представляет". Ответ на первый вопрос требует анализа причинно-следственных связей, которые привели к появлению предмета.
Кончай повторять одну и ту же глупость по сто раз. То что, скажем, бензиновый двигатель придумали для автомашин никак не влияет на то, что его можно с успехом использовать для самолетов, танков или даже генераторов электичества. Точно так же даже технология придуманная где-то для доступа к БД не обязана применяться для этого. К тому же ты просто не знаешь все реальных предпосылок от того судишь о предмете крайне не проффесионально. Вот толко повтояться я уже устал. Ну, не способен ты понять очевидные вещи, ну и фиг с тобой.
ГВ>Ответ на второй вопрос требует разбора внутренней структуры предмета. Выводы, полученные из ответа на второй вопрос ненадёжны, если мы ищем ответ на первый. Скажем, из того, что под влиянием LINQ (возможно) многие плотнее изучили ФП ещё не следует, что в первоначальные замыслы разработчиков LINQ входило несение света ФП в массы
А зачем этму следовать? Есть факты. Они неоспоримы. ЛИНК — это и есть ФП. Конечно ЛИНК это больше чем просто ФП, но часть того что понимается под аббревиатурой ЛИНК — это несомненно ФП. И авторы линка — это отчетливо понимали.
ГВ>(зачем тогда маскировать ФП-конструкции под SQL-подобными?)
Это отдельный вопрос. Ответ на него лично для меня очевиден.
ФП в том виде в котором он был реализован в классических ФЯ (языках) не был принят массами хотя первому ФЯ уже стукнуло 50 лет, да и менее экстравагантным и более высокоуровневым языкам вроде ML-я и Хаскеля тоже уже по несколько десятков лет.
А вот синтаксис SQL-я людям знаком. При этом SQL — это пожалуй самая близка технология к ФП. По этому было найдено гениальное решение — функции ФП библиотек были переименованы в похожие функции SQL-я. Более того стандартный список ФП-шных функций был расширен. Тем же которые не имели аналогов в SQL оставили старые названия (например, Take, TakeWhile, Skip). Между прочем такой функции как TOP в ЛИНКе нет. Вместо нее как раз применяется Take. Так что совершенно ясно, что ноги линка растут именно от ФП, а не от SQL-я.
К сожалению у этого есть обратная сторона. Многие для кого доступ к данным очень важне, а ФП пока не знаком сочли линк плохим интерфейсом, так как он не позволяет формировать таких запросов к СУБД как им нужно. О таких вещах как оптимизация запросов вообще говорить не приходится.
Но что я тебе об этом рассказываю? Ты же ведь заранее имешь мнение которое хрен оспоришь. Разбираться ты тоже ни в чем не будешь.
ГВ>А вот из того, что в 90-х — начале 2000-х ORM был едва ли не самым горячим топиком IT-сообществ очень даже напрашивается вывод, что как раз проблемами ORM и был вызван к жизни LINQ.
Не что из того что было темами горячих дискуссий? Скажем темой горячих дискуссий последних лет является параллелизм. В 4-ом фрэймворке (очень скоро) выйдет PLINQ — это реализация LINQ 2 Object позволяющая автоматически распараллелить вычисления на имеющиеся в системе процессоры. Давай сделаем и из этого далеко идущие выводы. И тогда получится, что ЛИНК был вызван к жизни стремлением к распараллеливанию. А все эти провайдеры к СБУД — это так баловство.
Ну, как? Ну, ты конечно понимаешь что это глупость. Так вот твои идеи по поводу линк-а — это еще большея глупость.
Выстаиваемый SQL был известен за долго до появления C#. МС мог встроить SQL в C# еще при создании самого C#. Вот только в МС не захотели встаивать в универсальный язык общего назначения средства которые полезны только в одном (хотя и весьма широком) сегменте рынка разработки ПО.
А вот когда им предложили универсальную технологию которая покрывает все сферы разработки ПО и в том числе (а не в основном) доступ к релляционным данным, то они с радостью включили в язык эту технолгию. Ну, а то, что на поверку это оказалось
ГВ>Кстати, любопытное подтверждение рассуждениям о возможном влиянии РСУБД мы находим в документации на SQL Server 2005:
ГВ>
You can use .NET Framework languages in addition to the Transact-SQL programming language to create database objects and retrieve and update data for Microsoft SQL Server 2005 databases. In Visual Basic, Visual C#, or Visual C++ projects, you can create stored procedures, triggers, aggregates, user-defined functions, and user-defined types.
Ахринеть. И что же этот абзац подтверждает?
В Oracle 11G можно использовать Яву. И как это влияет на наличие в Яве средств вроде ЛИНК?
Короче, у тебя дичайшие проблемы с логикой. Как ты программистом то работаешь? Ты же ведь умудряешся делать выводы из вообще не связанных вещей? Ты хоть обрати на дату этой документации! Она же вышла раньше чем ЛИНК был задуман!
ГВ>Спору нет, LINQ — очень неплохое дополнение для языка, работающего в плотной связи с SQL Server.
Не. Это полнейшая клиника.
Чушь за гранью фола.
ГВ>Обрати внимание, фактически здесь сказано об использовании языков .Net во вполне определённой среде, а здесь это не просто использование, это очень неплохой маркетинговый ответ Oracle. Как по мне, так эта причина стоит гораздо больше, чем возможность сканировать массивы объектов. И снова, смотрим на среду: оба-на — РСУБД!
Блин, да фича такая есть в SQL Server 2005 — триггеры на управляемых языках. К ЛИНКу оно вообще отношения не имеет! Более того когда предполагается, что триггер должен обрабатывать большие массивы данных или вообще преимущественно занимаются запросами, то спецы по SQL Server советуют использовать транзакт, так как дотнетные триггеры оказываются медленнее и неудобнее.
ГВ>Что до неточностей формулировок в высказываниях на форуме, так их я списываю на ту или иную степень эмоциональной компоненты в реакциях собеседников. Все ж живые люди, в конце концов.
Ген. Если у тебя еще в состоянии, то ответь плиз на очень простой вопрос.
Если у нас есть фича с помощью которой мы можем одинаково удобно работать с СУБД (любой а не реалионной), ХМЛ-ем, объектами в памяти компьютера и даже распараллеливание вычисления, то эта фича универсальная или все же предназначена только для доступа к РСУБД?
VD>>В прочем что ты тут можешь пояснить? Это гон чистой воды. И разбивается он примитивными примерами использования линка для обработки массивов, списков и других коллекций.
ГВ>А давай не будем путать причины появления X и возможности X?
Да какая разница, в конце концов, какие были причины? Фича универсальная? 100%. Так какого хрена ты защищаешь высказывание "LINQ по большому счету заточен под прикладную задачу, и нафиг не вперся в случае, если мы не работаем с реляционной БД"?
Оно верно?
ГВ>Спроси у Гапертона об этом. На меня, например, минусы действуют ровно в той же степени, что и плюсы — как признак наличия обратной связи.
Ну, да, ну, да... "...Их здесь тысячи..."
ГВ>>>[... мобильный телефон ... изоморфны демагогическим приёмам ... вычислить моё целеполагание ...] VD>>Вот эту демагогию ты оставь для других. Мы обсуждаем тут ЛИНК. Вот о нем и говори.
ГВ>Поаккуратней с повелительным наклонением. Если ты не понимаешь иллюстрации, то лучше переспроси, я объясню.
Иллюстрации хороши когда ты что-то кому-то объясняешь. А когда ты что-то пытаешься обосновать или доказать иллюстрации — это часть обмана и демагогии. Так что про телефоны я с тобой разговаривать не буду. Они не имееют никакого отношения к вопросу. Они вообще ничего общего не имеют с ни с линком ни с ИТ.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>> В этом нет ничего страшного и нет никакой попытки кого-то задеть, просто акценты на фичах языка люди с разной спецификой работы расставляют по-разному. VD>>Не было никаких акцентов. Было два слишком общих понятия смысл которых попросили уточнить.
ГВ>Дык. В том-то и фокус, что эти самые смыслы влёт считываются людьми, работающими над схожими проблемами.
Ну, давай, моговед, поведай нам, что же Гапертон имел в виду под словами "простой" и "удобный" если слово "простой" он сам же охарактеризовал как имеющее 4 значения (пруфлинк
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Коллизия между вопросами "зачем оно" и "что оно из себя представляет"...
Так. Давай как с чистого листа начнем. ОК?
Итак. Вот цитата Гапертона относительно ЛИНК:
LINQ по большому счету заточен под прикладную задачу, и нафиг не вперся в случае, если мы не работаем с реляционной БД.
Теперь я задам несколько вопросов, а ты постараешься на них дать честный вопрос и не уйти в сторону. ОК?
Принимаются ответы: "нет", "да" и "не знаю".
1. Можно ли с помощью линк обрабатывать коллекции в памяти.
2. Можно ли с помощью линка обрабатывать ХМЛ.
3. Есть ли в ЛИНК-е что-то что может быть применимо толко для РСУБД и не применимо для других источников данных?
4. Упрощает ли ЛИНК обрабтку списков объектов по сравнению с другими средствами их обработки доступными в шарпе и васике?
4. Можно ли называть технологию более удобную для обработки объектов в памяти нежели для работы с СУБД "большому счету заточен под прикладную задачу, и нафиг не вперся в случае, если мы не работаем с реляционной БД"?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Забыли уж поди, как оно по-простому-то делается? 
Если нам не помогут, то мы тоже никого не пощадим.
