Здравствуйте, Константин Л., Вы писали:
КЛ>Здравствуйте, FR, Вы писали:
КЛ>[]
FR>>Так нужно и это осмысленные операции, только от бестолковых временных структур это не избавляет. FR>>Те же std::pair, boost::tuple тоже нафиг не нужны?
КЛ>не знаю...ты сам себе противоречишь. Так нужно — но бестолковые структуры...
Нужен результат: например вернуть из функции N (разнотиповых) переменных, есть несколько альтернатив как это сделать, в языке подерживающем туплы, это элементарно просто вернуть тупл. В языке не подерживающем туплы или завести структуру из этих N переменных (единственное предназначение которой только возврат этих переменных) или что еще хуже завести у функции out параметры. Тупл здесь средство упростить и очистить от мусора код и ничего больше.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>видишь ли, в чём прикол — мы все используем наши языки не совсем по назначению, вносим в них те концепции (паттерны программирования), которые изначально в языке отсутствуют. используем продцедурное программирование с ассемблером, ООП — с Си, функциональное — с С++. и для того, чтобы знать, как можно улучшить свои паттерны программирования, и полезно знать другие языки. кроме того, некоторые сами выбирают, на чём им писать
В целом я согласен. Но под "знать язык" я подразумеваю не "прочитал книжку, глянул пару семплов и написал HelloWorld". Такие знания гроша ломаного не стоят и счастливый обладатель таких знаний сам через полгода забудет большую часть. А реальное изучение отнимет много времени. А если оно еще и не под конкретную задачу, а просто "чтоб было"... В плане ознакомления с новыми концептами другие языки просматривать стоит. Знакомиться с их парадигмами и идеями. Но полноценно изучать я бы их не рекомендовал.
L>В целом я согласен. Но под "знать язык" я подразумеваю не "прочитал книжку, глянул пару семплов и написал HelloWorld". Такие знания гроша ломаного не стоят и счастливый обладатель таких знаний сам через полгода забудет большую часть. А реальное изучение отнимет много времени. А если оно еще и не под конкретную задачу, а просто "чтоб было"... В плане ознакомления с новыми концептами другие языки просматривать стоит. Знакомиться с их парадигмами и идеями. Но полноценно изучать я бы их не рекомендовал.
сиё от тебя зависит. я например C++ с 90-го знаю, а ты? яву/C# я в своё время тоже прочёл, но остался ранодушен. зато в другие языки влез по самые уши. но это у меня хобби такое, ты может предпочитаешь рыбу ловить или в футбол играть
Здравствуйте, Константин Л., Вы писали:
КЛ>>>повеселил А может еще расскажешь, что такое атомарность функций?
VD>>Слушай, ты бы не позорился бы, а?
КЛ>ну дай попозориться, пожалуйста
КЛ>так ссылочку может даешь или еще что...А то вот говоришь умные слова, хочется узнать откуда дровишки.
ОК. Я думал ты прикалываешся, а ты похоже иправда не понял о чем я говорю.
В математике все фукнкции чистые. Это значит, что они не имеют побочных эффектов. Взывая чистую фунцию ты можешь быть уверен, что ничего не изменится. Таким образом каждый вызов можно рассматривать как атомарную операцию. Ты гарантированно застрахован от того, что во время ее вызвова что-то изменится.
Такую фукнцию ты можешь выполнять параллельно или даже автоматически распараллеливать. В отличии от нее фукнция в императивных языках всегда может что-то изменить или на что-то повлиять. Такие фукнции нельзя рассматривать как атомарные операции и в многопоточном окружении их нужно синхронизировать применяя примитивы синхронизации.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Константин Л., Вы писали:
КЛ>поинт в том, что если ты возвращаешь "бестолковые временные структуры", то значит у тебя метод делает "все сразу и еще кучу вещей", что часто говорит о его избыточности или неправильности. Если же так нужно и это осмысленная операция, то эти "бестолковые временные структуры" должны стать нормальными логическими сущностями и уж тут кортежи нафиг не нужны. Кароче моё мнение, что кортежи — это затычки для костылей, которые мы сами и сажаем.
Как грится, с очевидцами не спорят!
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Константин Л., Вы писали:
КЛ>кортежи настолько простая вещь, что не надо быть академиком, чтобы рассуждать о ней.
Ага. От того твои заявления выглядят еще более нелепо.
Хочешь я тебя удивлю? Ты используешь кортежи постоянно! Не веришь?
А чем по-твоему иявляются параметры функций?
Это ни что иноге как список фиксированной длинны разнонипных значений передающихся как единая сущность.
С/C++/Java/C# позволяют использовать их только для передачи значений. А Хаскель/ОКамл/Немерле и для возврата.
Согласись, что раз мы ввели ограничение на возврат несколькоих значений с аргументацией "Зачем возрващать несколько значений когда можно вернуть именованную структуру?", то эту же логику можно распространить и на параметры — "Зачем передавать несколько значнений когда можно передать именованную структуру?". Блее того такие языки есть! Хаскель и ОКамл так и поступают! В них фукнция может иметь только один параметр и только одно возвращаемое значение. Функции с множеством параметров у них считаются соедененными (каррированными в терминалогии этих языков). Причем единственным параметром может служить кортеж. Тоже и с возвращаемым значением.
Немерле блее традиционен, но он позволяет передавать кортеж вмесо списка отдельных параметров. Таким образом мы можем результат одной фукнции передать другой не залпом, а не по одному параметру:
def f1() : int * string
{
(1, "!!!")
}
def f2(x : int, y : string) : void
{
WriteLine($"x = $x; y = $y")
}
f2(f1());
// вместо
def (x, y) = f1();
f2(x, y);
Не находишь это красивым?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, BulatZiganshin, Вы писали:
VD>>>Языки типа Явы и C# ВООБЩЕ не рассчитаны на работу в многопоточном окружении.
C>>synchronized? lock? Это не расчет на многопоточность???
BZ>это как раз костыли вокруг mutable values, чтобы затащить их в brave new world эрланг, созданный для программирования АТСок, таких затычек не имеет, а ведь там тысячи процессов — это не подвиг, а норма
Согласен, но я бы уточнил, что это все же костыли не для изменяемых значений, а в следствии отсуствия толковой идеологии распараллеливания вычислений. Конечно тсуствие изменяемых значений позволяет автоматически распараллеливать (в основном теоритически) программы. Но есть и другие подходы. Эрланг, например, исползует идею изолированных программных процессов и пердачу между ними сообщений. Точно такой же подход используется в Сингулярити — эксперементальной ОС МС. Так еж есть идеология Активных объектов. Практически тоже что и в Эрланге, но вместо сообщений испоьзуются вызовы методов объетов привязанных к потоку.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Константин Л., Вы писали:
VD>>Но у них есть одна проблема — они неудобны. Или скажем, так в большинстве случаев вместо них удобнее использовать озврат множетсва значений (котреж, напимер). Такой подход решает и проблему многопточности (при условии что весь многопоточный код написан в фукнциональном стиле) решает, и просто удобен.
КЛ>поправь меня, но в Nemerle можно обращаться к элементам кортежа только по индексам, которые должны быть известы в compile-time и нельзя по элементам пробежаться. Так что это лучше "бестолковых безымянных структур" только их отсутствием (структур).
Поправляю. В Немерле есть возможность:
1. Передавать кортежи вместо параметров фукнций.
3. Использовать их образцах при паттерн-матчинге.
4. Ну, и действительно индексировать.
Перебирать из довольно бессмысленно так как они могут иметь разные типы данных. Хотя в макросах их можно и переберать и даже генерировать. К примеру, параметры методов тоже генерируеются как кортежи.
КЛ> А об их отсутствии (точнее о том, что это плохо и они заменяются кортежами.) я уже писал.
(задумчиво) Да, ты много пишешь...
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, cl-user, Вы писали:
CU>"Я тут сказал мысль, а вы не сметь критиковать!"
Я не вижу тут критики. Я вижу желаете у многих впихнуть свою любимую игрушку.
CU>Ну и ты нас пойми, нас очень интересует не сам список, а _почему_ он именно такой!
Этого вопроса пока не звучало. Если это интересует, то могу ответить. Толко чур не обижаться когда первый же спорщик будет послан далеко и на долго. ОК? Вы же мое объяснение хотите услышать или поспорить итаки впихнуть в список то что желаете?
CU>Или так сильно влом вежливо и без наездов объяснить, почему именно этот язык не включён в список?
Не то что бы влом, а я знаю чем это кончится. Это совершенно флэймовая тема. Каждый будет птытаться впихнуть свою игрушку переходя все пороги разумности и не разумности.
CU>Или с тебя шапка упадёт/нимб свалится, если ты признаешся, что не знаешь какой-то язык?
Знаешь, я болшинство перечисленных мной языков знаю очень поверхносно. В основном по описаниям. Это не мешает мне анализировать их и выявлять концептуально значимые вещи.
Да и на понт меня взать нельзя. Можнно тлько попросить.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>для того, чтобы изучить все эти подходы, нужно изучать поддерживающие их языки, и разумеется брать наилучших их представителей. теперь смотрим. процедурный и АТД подход стали частью ООП, так что их можно отдельно не изучать. лучшие ООП языки — эйфель (компилируемый) и руби (интерпретируемый). функциональные — схема (динамический, императивный), окамл (компилируемый, императивный, с прикрученным сбоку ООП), хаскел (чистый, компилируемый); логические — пролог (динамический, условно-императивный). немерл — противоположность окалму, это ООП язык с прикрученным императивным FP
Примерно так. Но проблема в том, что у каждого языка есть поклонники и кто-то обязательно захочет, чтобы его любимый язык попал в списко. Но в списке не нужны два, пусть даже приблизительно одинаково хороших ООЯ. И не нужно два статических ФЯ. Список нужно деражать минимальным чтбоы он остался полезным тем кто зохочет въехать во все современные парадигмы. А то что я вижу в данном случае — это попытка впихнуть в этот список все известные языки. Ну, или их популярную часть. Причем кто-то будет считать, что ради его любимого языка нужно исключить другой. Например, включить Смолток и исключить C#. Или вклчить ОКамл и исплючить Хаскель. При некотором обобщении языки ведь действительно похожие.
Объяснять и доказывать каждому почему это так или иначе задача не благодарная. Вот я попытался обяснить свою позицию по поводу C# и Смолток, но фанатикам и слуашать не охота. У них уже установка докапаться до чего получится и завязать флэйм в надеждне на победу каким-то образом. А мне это не нужно. Я не против других списков. Вот толко никто свой так и не представил. Куда как интересно поковыряться в чужом.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Но в списке не нужны два, пусть даже приблизительно одинаково хороших ООЯ. И не нужно два статических ФЯ.
дело в том, что всякая классификация — лишь наш способ упорядочить мир, придать ему в нащитх глазах большую структуру. скажем, хаскел — ленивый, а окамл — нет. считать ли это разными концепциями? всё зависит от ого, насколько глубоко ты в эту тему хочешь погрузиться
Здравствуйте, VladD2, Вы писали:
VD>Хочешь я тебя удивлю? Ты используешь кортежи постоянно! Не веришь?
VD>А чем по-твоему иявляются параметры функций?
VD>Это ни что иноге как список фиксированной длинны разнонипных значений передающихся как единая сущность.
VD>С/C++/Java/C# позволяют использовать их только для передачи значений.
Ага, фрейм стека в C/C++ в перемешку со значениями регистров уже стал кортежем.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
VD>>А чем по-твоему иявляются параметры функций?
E>Ага, фрейм стека в C/C++ в перемешку со значениями регистров уже стал кортежем.
а причём тут процессор? речь идёт о языке. и тут Влад прав — с теоретичсекой точки зрения это кортёж и есть, пока ты не используешь переменнное число аргументов
VD>В математике все фукнкции чистые. Это значит, что они не имеют побочных эффектов. Взывая чистую фунцию ты можешь быть уверен, что ничего не изменится. Таким образом каждый вызов можно рассматривать как атомарную операцию. Ты гарантированно застрахован от того, что во время ее вызвова что-то изменится.
VD>Такую фукнцию ты можешь выполнять параллельно или даже автоматически распараллеливать. В отличии от нее фукнция в императивных языках всегда может что-то изменить или на что-то повлиять. Такие фукнции нельзя рассматривать как атомарные операции и в многопоточном окружении их нужно синхронизировать применяя примитивы синхронизации.
функции с побочными эффектами удобно называть прцедурами — как раз чтобы не входить в разрез с математикой
далее, "чистоту" ещё называют ссылочной прозрачностью (referential transparency), и это означает, что результат функции зависит только от её аргументов и никак не зависит от состояния внешнего мира. для того, чтобы гарантировать это, *достаточно* запретить ей обращаться к глобальным переменным, вызывать процедуры, сохранять своё состояние в static vars
вот в этом как раз и состоит проблема вызова процедурного кода из функционального, которую ты объявил несуществующей
запретив такие вызовы, мы можем *гарантировать* referential transparency, т.е. теперь это проверяет компилятор. если разрешим — придётся проверять программисту. более того, на самом деле такие вызовы возможны с помощью unsafePerformIO — это и есть тот механизм, который позволяет программисту взять ответственность на себя *явно*
ну а тезнически запрет таких вызовов, заодно с явным описанием плорядка вызова процедур, решается "эстафетной палочкой" — фиктивным значением типа RealWorld, передаваемым от порцедуры к процедуре, и недоступным функциям. т.е. функция не может вызвать процедуру потому, что она такую эстафетную палочку не получает сверху, и не может создать её сама
кроме того, благодаря наличию этой "эстафетной палочки" среди параметров процедуры она тоже становится чистой. просто один из её параметров — это значение realworld, которое прошло через все предыдущие вызовы процедур, так что несмотря на эту чистоту, компилятор не может "соптимизировать" вызов прцедуры — она гарантированно никогда раньше с такой эстафетной палочкой (возвразённой предыдущей вызванной порцедурой) не вызывалась!
VD>Объяснять и доказывать каждому почему это так или иначе задача не благодарная. Вот я попытался обяснить свою позицию по поводу C# и Смолток,
все возможности *яызка* Смоллток в руби есть. правда, изменилась терминоллогия, и главное — нет той замечательной среды. ведь это же была первая IDE в мире! и до сих пор, как я понимаю, нет ни одной среды, где было бы так легко работать со структурой классов и проверять, что возвратят те или иные методы
C# же, как и Delphi — язык чисто практический, я лично в нём ничего концептуального не вижу. и вообще, на мой взгляд, изучать ФП надо с наиболее теоретичсеких, удобных в программировании, но неэффективных (пролог, хаскел), и далее спускать к более практичным, но сложным в использовании языкам. и заканчивать на C#, яве или чём-то ещё, что будет реально использоваться. языки более низкого уровня, типа C++, изучать необязательно — разве что чтобы понять, как функционирует процессор, да и это начинающему ни к чему
такой подход научит человека мыслить на наиболее высоком возможном уровне — ведь здесь важно, с чего ты начнёшь. если первым яхзыком будет бейсик, то он для человека станет "родным", и дальше все новые концепции будут перекладываться на его "архитектуру" если же начать с наиболее высокоуровневых языков, то человек будет думать об *алгоритме* решения задачи и потом уже, тяжко вздохнув, сооьрадать, как его реализовать на этом ограниченном языке
кроме того, высокоуровневые языки медленней стареют, чем низкоуровневые, поскольку это не языки реального прогнраммирвоания с их сотнями мелких полезных деталей, а концепции в чистом виде (т.е. сами-то языки стареют, но нас в них интересует только ввечно молодая общекоцептуальная часть)
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Константин Л., Вы писали:
КЛ>>>>повеселил А может еще расскажешь, что такое атомарность функций?
VD>>>Слушай, ты бы не позорился бы, а?
КЛ>>ну дай попозориться, пожалуйста
КЛ>>так ссылочку может даешь или еще что...А то вот говоришь умные слова, хочется узнать откуда дровишки.
VD>ОК. Я думал ты прикалываешся, а ты похоже иправда не понял о чем я говорю.
прикалывался.
VD>В математике все фукнкции чистые. Это значит, что они не имеют побочных эффектов. Взывая чистую фунцию ты можешь быть уверен, что ничего не изменится. Таким образом каждый вызов можно рассматривать как атомарную операцию. Ты гарантированно застрахован от того, что во время ее вызвова что-то изменится.
VD>Такую фукнцию ты можешь выполнять параллельно или даже автоматически распараллеливать. В отличии от нее фукнция в императивных языках всегда может что-то изменить или на что-то повлиять. Такие фукнции нельзя рассматривать как атомарные операции и в многопоточном окружении их нужно синхронизировать применяя примитивы синхронизации.
Ок, спасибо. Но все равно к практике имеет опосредованное отношение. Никто referential transparency (взято из поста выше) никто не отменял и заявлять, что язык не предназначен для нап. многопоточных программ из-за отсутствия атомарных функциий, по-моему, неправильно. Тем более что эту атомарность может обеспечить сам разработчик.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Константин Л., Вы писали:
КЛ>>кортежи настолько простая вещь, что не надо быть академиком, чтобы рассуждать о ней.
VD>Ага. От того твои заявления выглядят еще более нелепо.
VD>Хочешь я тебя удивлю? Ты используешь кортежи постоянно! Не веришь?
[]
применительно к с++ это все абстракция. И не надо со мной разговаривать как с детем, надоело уже.
[]
VD>Не находишь это красивым?
как тебе сказать...Неплохо, удобно. Но есть один недостаток — отсутствие имен элементов кортежа в функции, его возвращающей. С параметрами методов этого нет. Читабельность страдает, имхо.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Константин Л., Вы писали:
КЛ>>Здравствуйте, FR, Вы писали:
КЛ>>[]
FR>>>Так нужно и это осмысленные операции, только от бестолковых временных структур это не избавляет. FR>>>Те же std::pair, boost::tuple тоже нафиг не нужны?
КЛ>>не знаю...ты сам себе противоречишь. Так нужно — но бестолковые структуры...
FR>[b]Нужен результат: например вернуть из функции N (разнотиповых) переменных[b], есть несколько альтернатив как это сделать, в языке подерживающем туплы, это элементарно просто вернуть тупл. В языке не подерживающем туплы или завести структуру из этих N переменных (единственное предназначение которой только возврат этих переменных) или что еще хуже завести у функции out параметры. Тупл здесь средство упростить и очистить от мусора код и ничего больше.
вот в чем ошибка, которую мы сами совершаем и сами же фиксим с пом. туплов.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Константин Л., Вы писали:
КЛ>>поинт в том, что если ты возвращаешь "бестолковые временные структуры", то значит у тебя метод делает "все сразу и еще кучу вещей", что часто говорит о его избыточности или неправильности. Если же так нужно и это осмысленная операция, то эти "бестолковые временные структуры" должны стать нормальными логическими сущностями и уж тут кортежи нафиг не нужны. Кароче моё мнение, что кортежи — это затычки для костылей, которые мы сами и сажаем.
VD>Как грится, с очевидцами не спорят!
А может еще расскажешь, что такое атомарность функций?
