Здравствуйте, FR, Вы писали:
ВВ>>А где ты оперируешь такой сущностью как функция? В других функциях? FR>Угу. По сути в функциональщине больше ничего и нету.
Ну таким образом "функциональщина" — это что, по твоему мнению? Просто когда часть кода написана в ф-ном стиле, а часть как угодно?
Ты вот ратуешь за "чистоту" функций — т.е. внутри что угодно, а внешне все должно быть stateless, immutable и проч. — но для чего нужна эта "чистота"? Для того, чтобы код в других фукнциях выглядел функционально? При это часть кода у тебя проекте по-прежнему будет в императивном стиле.
Мне казалось, что ФП предполагает нечто иное. При твоем подходе ты всю логику можешь описать в императивном стиле с лесом if-ов, свитчей и проч. — собственно, с чем и боремся, кстати говоря — при этом какая-то внешняя часть проекта будет оформлена "красиво".
Действительно "функциональщина" какая-то получается.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Ну таким образом "функциональщина" — это что, по твоему мнению? Просто когда часть кода написана в ф-ном стиле, а часть как угодно?
Так в любых даже самых что ни на есть функциональных строгих языках часть кода всегда императивна
ВВ>Ты вот ратуешь за "чистоту" функций — т.е. внутри что угодно, а внешне все должно быть stateless, immutable и проч. — но для чего нужна эта "чистота"? Для того, чтобы код в других фукнциях выглядел функционально? При это часть кода у тебя проекте по-прежнему будет в императивном стиле.
Во первых я за это не ратую, я как раз за то чтобы и внутри было все функционально. Я просто демонстрирую что для написания в функциональном стиле шашечки не необходимы.
ВВ>Мне казалось, что ФП предполагает нечто иное. При твоем подходе ты всю логику можешь описать в императивном стиле с лесом if-ов, свитчей и проч. — собственно, с чем и боремся, кстати говоря — при этом какая-то внешняя часть проекта будет оформлена "красиво".
Императивный стиль ни имеет никакого отношения к лесу ифов, их без проблем можно нагородить и в чисто функциональных языках. Вообще у меня уже возникает впечатление что немерлисты уже тут так промыли всем мозги что люди уже принимают за ФП только сахар из немерле.
ВВ>Действительно "функциональщина" какая-то получается.
Угу и она уже дает кучу преимуществ из функциональных языков, а именно модульность и инкапсуляцию кода, упрощение отладки, легкое распаралеливание.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, FR, Вы писали:
ВВ>>>А где ты оперируешь такой сущностью как функция? В других функциях? FR>>Угу. По сути в функциональщине больше ничего и нету.
ВВ>Ну таким образом "функциональщина" — это что, по твоему мнению? Просто когда часть кода написана в ф-ном стиле, а часть как угодно?
Писать ВСЕ в функциональном стиле а)неэффективно б)не всегда возможно. Практически в любом проекте на функ. языке будет немного императивного кода.
ВВ>Ты вот ратуешь за "чистоту" функций — т.е. внутри что угодно, а внешне все должно быть stateless, immutable и проч. — но для чего нужна эта "чистота"? Для того, чтобы код в других фукнциях выглядел функционально? При это часть кода у тебя проекте по-прежнему будет в императивном стиле.
Чем больше чистых функций, тем проще создавать из них другие чистые функции, тем проще распараллеливать и оптимизировать код.
ВВ>Мне казалось, что ФП предполагает нечто иное.
Что именно?
Здравствуйте, gandjustas, Вы писали:
ВВ>>Ну таким образом "функциональщина" — это что, по твоему мнению? Просто когда часть кода написана в ф-ном стиле, а часть как угодно? G>Писать ВСЕ в функциональном стиле а)неэффективно б)не всегда возможно. Практически в любом проекте на функ. языке будет немного императивного кода.
А в данном случае речь о том, что "функциональность" соблюдается только снаружи. "Распарелливать" и "оптимизировать" можно и без нее. Пишите "красиво" на ООП.
ВВ>>Ты вот ратуешь за "чистоту" функций — т.е. внутри что угодно, а внешне все должно быть stateless, immutable и проч. — но для чего нужна эта "чистота"? Для того, чтобы код в других фукнциях выглядел функционально? При это часть кода у тебя проекте по-прежнему будет в императивном стиле. G>Чем больше чистых функций, тем проще создавать из них другие чистые функции, тем проще распараллеливать и оптимизировать код. ВВ>>Мне казалось, что ФП предполагает нечто иное. G>Что именно?
Изменение стереотипов. Можно, конечно, рассуждать, что императивность не искоренима в принципе и везде есть чуточку "императива" — пожалуй и так, но суть-то не в этом.
Если новая концепция программирования не заставляет тебя думать и писать по-другому, а лишь помогает что-то там "распараллелить", то в recycle bin эту концепцию.
У вас же получается, что мы думаем по-старому, пишем по-старому ("по-старому" кстати далеко не эквивалетно "плохо"), и при этом используем какие-то "фишки" функционального стиля, при этом считая, что "функциональщина" больше ничего не дает.
А вы пробовали взять?
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Ютьюб? Вроде бы его Гугл же купил недавно за кругленькую сумму. Смысл тогда тратиться на убыточный сервис? Может, я, конечно, что-то не понимаю
Вот от гугловцев это и слышал.
У них денег много (было как минимум до последнего времени), так, что могут себе позволить держать некоторые убыточные сервисы так, на перспективу. ВВ>Ну или та же рапида — не может же она быть убыточной. Ибо смысл тогда какой, последний оплот пиратства? Мне кажется, что вполне она живет за счет этих своих премиум аккаунтов.
Про рапиду не в курсе, но думаю они в плюсе.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>А в данном случае речь о том, что "функциональность" соблюдается только снаружи. "Распарелливать" и "оптимизировать" можно и без нее. Пишите "красиво" на ООП.
ООП также как чистые функции распаралелвать как раз не дает. Почитай pdf на который я выше дал ссылку.
ВВ>Изменение стереотипов. Можно, конечно, рассуждать, что императивность не искоренима в принципе и везде есть чуточку "императива" — пожалуй и так, но суть-то не в этом. ВВ>Если новая концепция программирования не заставляет тебя думать и писать по-другому, а лишь помогает что-то там "распараллелить", то в recycle bin эту концепцию.
Изменение стереотипов и "заставление думать" нужно когда ты осваиваешь функциональщину, и поэтому учится ей да очень желательно на функциональном или даже чисто функциональном языке. А вот дальше зачем себя ограничивать в использовании концепции? Почему нельзя применять ее и в языках для нее не приспособленных?
ВВ>У вас же получается, что мы думаем по-старому, пишем по-старому ("по-старому" кстати далеко не эквивалетно "плохо"), и при этом используем какие-то "фишки" функционального стиля, при этом считая, что "функциональщина" больше ничего не дает. ВВ>А вы пробовали взять?
Конечно пробовали, и пишем и думаем не по старому, хотя и приходится писать на старых язках.
Вообще, извините за аналогию, но то, что вы говорите похоже, скажем, на рассуждения об ООП в C# в стиле — вот я нафигачу кучу статических классов, причем всю логику напишу в них, потом "сверху" создам несколько инстансных, и это все будет ООП. И ничего, кроме этого, я в ООП не вижу. Причем если использовать ООП везде, то это будет а)неэффективно б)не всегда возможно (что, кстати, абсолютная правда).
Здравствуйте, FR, Вы писали:
ВВ>>А в данном случае речь о том, что "функциональность" соблюдается только снаружи. "Распарелливать" и "оптимизировать" можно и без нее. Пишите "красиво" на ООП. FR>ООП также как чистые функции распаралелвать как раз не дает. Почитай pdf на который я выше дал ссылку.
ПДФ-ом не проникся, извини Потом смысл оперировать понятиями ФП вроде "чистых ф-ций", если ты сам в них вкладываешь несколько иной смысл чем в ФП?
ВВ>>Изменение стереотипов. Можно, конечно, рассуждать, что императивность не искоренима в принципе и везде есть чуточку "императива" — пожалуй и так, но суть-то не в этом. ВВ>>Если новая концепция программирования не заставляет тебя думать и писать по-другому, а лишь помогает что-то там "распараллелить", то в recycle bin эту концепцию. FR>Изменение стереотипов и "заставление думать" нужно когда ты осваиваешь функциональщину, и поэтому учится ей да очень желательно на функциональном или даже чисто функциональном языке. А вот дальше зачем себя ограничивать в использовании концепции? Почему нельзя применять ее и в языках для нее не приспособленных?
Обычно "изменение стереотипов" приводит к тому, что по-старому уже думать не хочется. Да, всем нам приходится писать на старых языках, но мы же при этом не делаем вид, что в них доступны все прелести ФП. Да и применять ФП-техники можно. Точно также я в свое время применял некоторые ОО-техники в ВБ6, когда приходилось писать на нем. Но ведь он от этого не становился объектно-ориентированным?
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, gandjustas, Вы писали:
ВВ>Вообще, извините за аналогию, но то, что вы говорите похоже, скажем, на рассуждения об ООП в C# в стиле — вот я нафигачу кучу статических классов, причем всю логику напишу в них, потом "сверху" создам несколько инстансных, и это все будет ООП. И ничего, кроме этого, я в ООП не вижу. Причем если использовать ООП везде, то это будет а)неэффективно б)не всегда возможно (что, кстати, абсолютная правда).
ВВ>Ну все-таки что-то не то, нет?
Совершенно кривая аналогия, если бы ты привел пример использования только сути ООП и ничего больше был бы коррекный пример. Но для ООП в стиле шарпа или С++ такое трудно сделать, в стиле же смалтака можно соорудить даже и на том же си.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>ПДФ-ом не проникся, извини Потом смысл оперировать понятиями ФП вроде "чистых ф-ций", если ты сам в них вкладываешь несколько иной смысл чем в ФП?
Я как раз совершенно не отклоняюсь от смысла ФП. Вот IT даже уже вкладывает свой смысл основанный на особенностях реализации немерле и ML образных языков.
FR>>Изменение стереотипов и "заставление думать" нужно когда ты осваиваешь функциональщину, и поэтому учится ей да очень желательно на функциональном или даже чисто функциональном языке. А вот дальше зачем себя ограничивать в использовании концепции? Почему нельзя применять ее и в языках для нее не приспособленных?
ВВ>Обычно "изменение стереотипов" приводит к тому, что по-старому уже думать не хочется. Да, всем нам приходится писать на старых языках, но мы же при этом не делаем вид, что в них доступны все прелести ФП. Да и применять ФП-техники можно. Точно также я в свое время применял некоторые ОО-техники в ВБ6, когда приходилось писать на нем. Но ведь он от этого не становился объектно-ориентированным?
Так я нигде не утверждал что в них доступны все прелести ФП. Я просто сказал что при необходимости на них вполне можно писать и в ФП стиле. Да это будет в большинстве случаев коряво и неуклюже, но вполне возможно и иногда даже выгодно.
Здравствуйте, FR, Вы писали:
FR>Совершенно кривая аналогия, если бы ты привел пример использования только сути ООП и ничего больше был бы коррекный пример. Но для ООП в стиле шарпа или С++ такое трудно сделать, в стиле же смалтака можно соорудить даже и на том же си.
А в чем кривизна аналогии? ООП должно быть "всеобъемлющим" (что кстати нереализуемо вообще), а ФП — нет?
Со смолтолком не знаком, не знаю, что там было. А в рамках шарпа ОО предполагает что у тебя логика строится на полиморфизме классов — причем целиком и полностью это не делает никто, даже убежденный ООП-ист, ибо есть некоторый баг в концепции
Кстати, абсолютно идеальная ОО-программа будет содержать минимум императива. Только такой нет.
Только смысл-то ООП не в том, что мы начинаем кое-где лепить классы с виртуальными ф-циями, а в том, что саму структуру программы начинаешь описывать, воспринимать, "думать" по-другому. В категориях сущностей — не действий — обладающих поведением, состоянием и пр. Именно в этом соль ООП на самом деле, а не в том, что местами использовать "ее суть", а местами — забить.
А ФП в каком-то плане ломает мозги покруче так, чем ООП. Серьезно покруче. Почему ж у вас он получает роль обвертки какой-то? Писать на ФП — это значит думать, что mutable это такая же исключительная ситуация как и static в шарпе (а скорее всего даже куда более исключительная ситуация).
Здравствуйте, FR, Вы писали:
FR>Так я нигде не утверждал что в них доступны все прелести ФП. Я просто сказал что при необходимости на них вполне можно писать и в ФП стиле. Да это будет в большинстве случаев коряво и неуклюже, но вполне возможно и иногда даже выгодно.
Но при этом сам же говоришь, что "по сути в функциональщине больше ничего и нету", кроме описанного тобой подхода
Там есть другой образ мысли, при котором нам не придет в голову строчить такие ПДФ-ы как тот, на который ты мне ссылку дал.
Здравствуйте, IT, Вы писали:
IT>Ты о чём? Ни в C#, ни в C/C++ ни if, ни switch ничего не возвращают и никогда не будут возвращать. Так что про immutable стиль в этих языках забудь.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, gandjustas, Вы писали:
ВВ>>>Ну таким образом "функциональщина" — это что, по твоему мнению? Просто когда часть кода написана в ф-ном стиле, а часть как угодно? G>>Писать ВСЕ в функциональном стиле а)неэффективно б)не всегда возможно. Практически в любом проекте на функ. языке будет немного императивного кода.
ВВ>А в данном случае речь о том, что "функциональность" соблюдается только снаружи. "Распарелливать" и "оптимизировать" можно и без нее. Пишите "красиво" на ООП.
Вообще любую программу можно написать на ассемблере, выше уже обсуждали. Только трудозатраты слишком велики. Так и распараллеливанием. Композиция чистых функций распараллеливается декларативно (может даже автоматически, но это не нужно), для императивного кода так сделать не получается.
Что касается оптимизации, то для чистых функций результат работы можно заменить на константу, если функция в программе или подпрограмме вызывается на небольшом конечном множестве аргуметнов. Для императивного кода такое выполнить в большенстве случаев невозможно.
ВВ>>>Ты вот ратуешь за "чистоту" функций — т.е. внутри что угодно, а внешне все должно быть stateless, immutable и проч. — но для чего нужна эта "чистота"? Для того, чтобы код в других фукнциях выглядел функционально? При это часть кода у тебя проекте по-прежнему будет в императивном стиле. G>>Чем больше чистых функций, тем проще создавать из них другие чистые функции, тем проще распараллеливать и оптимизировать код. ВВ>>>Мне казалось, что ФП предполагает нечто иное. G>>Что именно?
ВВ>Изменение стереотипов. Можно, конечно, рассуждать, что императивность не искоренима в принципе и везде есть чуточку "императива" — пожалуй и так, но суть-то не в этом. ВВ>Если новая концепция программирования не заставляет тебя думать и писать по-другому, а лишь помогает что-то там "распараллелить", то в recycle bin эту концепцию.
ФП заставляет думать и писать по-другому. Простота распараллеливания и оптимизации чистого функционального кода — это следствие.
ВВ>У вас же получается, что мы думаем по-старому, пишем по-старому ("по-старому" кстати далеко не эквивалетно "плохо"), и при этом используем какие-то "фишки" функционального стиля, при этом считая, что "функциональщина" больше ничего не дает.
Такой подход тоде может использоваться. Иногда очень оправданно.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>А в чем кривизна аналогии? ООП должно быть "всеобъемлющим" (что кстати нереализуемо вообще), а ФП — нет?
Кривизна в том что я взял имено суть ФП, а ты суть ООП оставил полностью за скобками.
В стиле смалталка ООП как раз и всеобъемлющий.
ВВ>Со смолтолком не знаком, не знаю, что там было. А в рамках шарпа ОО предполагает что у тебя логика строится на полиморфизме классов — причем целиком и полностью это не делает никто, даже убежденный ООП-ист, ибо есть некоторый баг в концепции
В ОО в стиле смалталка такого бага нет. Там вся логика строится только на объектах и посылках сообщений этим объектам.
ВВ>Кстати, абсолютно идеальная ОО-программа будет содержать минимум императива. Только такой нет.
Главный признак императива изменяемое состояние будет.
ВВ>Только смысл-то ООП не в том, что мы начинаем кое-где лепить классы с виртуальными ф-циями, а в том, что саму структуру программы начинаешь описывать, воспринимать, "думать" по-другому. В категориях сущностей — не действий — обладающих поведением, состоянием и пр. Именно в этом соль ООП на самом деле, а не в том, что местами использовать "ее суть", а местами — забить.
Не местами, главное чистота, если она соблюдена ФП уже есть.
ВВ>А ФП в каком-то плане ломает мозги покруче так, чем ООП. Серьезно покруче. Почему ж у вас он получает роль обвертки какой-то? Писать на ФП — это значит думать, что mutable это такая же исключительная ситуация как и static в шарпе (а скорее всего даже куда более исключительная ситуация).
ФП ломает мозги покруче только потому что сначала ты изучал ООП.
Еще раз повторю, все это важно только при обучении.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Но при этом сам же говоришь, что "по сути в функциональщине больше ничего и нету", кроме описанного тобой подхода
Если совсем по сути то там еще меньше, но на Unlambda писать также приятно как и на Brainfuck
ВВ>Там есть другой образ мысли, при котором нам не придет в голову строчить такие ПДФ-ы как тот, на который ты мне ссылку дал.
Если есть цель внедрить безболезнено функциональщину (и в особености бонусы для распаралелвания которые она дает) в досточно нискоуровневый язык очень похожий на C++ то очень даже придет
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, FR, Вы писали:
FR>>Совершенно кривая аналогия, если бы ты привел пример использования только сути ООП и ничего больше был бы коррекный пример. Но для ООП в стиле шарпа или С++ такое трудно сделать, в стиле же смалтака можно соорудить даже и на том же си.
ВВ>А в чем кривизна аналогии? ООП должно быть "всеобъемлющим" (что кстати нереализуемо вообще), а ФП — нет?
Нет.
ВВ>Со смолтолком не знаком, не знаю, что там было. А в рамках шарпа ОО предполагает что у тебя логика строится на полиморфизме классов — причем целиком и полностью это не делает никто, даже убежденный ООП-ист, ибо есть некоторый баг в концепции ВВ>Кстати, абсолютно идеальная ОО-программа будет содержать минимум императива. Только такой нет.
Это как?
ВВ>Только смысл-то ООП не в том, что мы начинаем кое-где лепить классы с виртуальными ф-циями, а в том, что саму структуру программы начинаешь описывать, воспринимать, "думать" по-другому. В категориях сущностей — не действий — обладающих поведением, состоянием и пр. Именно в этом соль ООП на самом деле, а не в том, что местами использовать "ее суть", а местами — забить.
Практика показывает что на низком уровне абстраций удобнее отделять данные от алгоритмов их обработки. тогда классы вырождаются в наборы методов и классы данных. Вот тут и приходит на помощь ФП.
ВВ>А ФП в каком-то плане ломает мозги покруче так, чем ООП. Серьезно покруче. Почему ж у вас он получает роль обвертки какой-то? Писать на ФП — это значит думать, что mutable это такая же исключительная ситуация как и static в шарпе (а скорее всего даже куда более исключительная ситуация).
Во всем должен быть прагматичный подход. Если mutable заметно упрощает\убыстряет реализацию, то стоит использовать его, но так чтобы сама функция при этом оставалась "чистой".Никто не говорит что все внетренности надо писать императивно.
Здравствуйте, minorlogic, Вы писали:
IT>>Ты о чём? Ни в C#, ни в C/C++ ни if, ни switch ничего не возвращают и никогда не будут возвращать. Так что про immutable стиль в этих языках забудь.
M>i ==5 ? 5 : 7
И много ты immutable кода такими конструкциями написал? Только честно.
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Воронков Василий, Вы писали:
ВВ> HTML в данном случае можно понимать как некий язык разметки, к которому тот же XAML довольно близок идеологически.
Ничего общего, кроме угловых скобочек. XAML это просто формат сериализации, удобный для написания человеком. А идеология у WPF вполне себе классическая десктопная.
ВВ>Только вот в итоге все равно непонятно, что в вин-формс не нравится. Уровень абстракции недостаточно высок?
Убогий дизайн.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
ВВ>> HTML в данном случае можно понимать как некий язык разметки, к которому тот же XAML довольно близок идеологически. AVK>Ничего общего, кроме угловых скобочек. XAML это просто формат сериализации, удобный для написания человеком. А идеология у WPF вполне себе классическая десктопная.
Может объяснишь в чем принципиальное отличие?
ВВ>>Только вот в итоге все равно непонятно, что в вин-формс не нравится. Уровень абстракции недостаточно высок? AVK>Убогий дизайн.
Мне кажется, что вполне она живет за счет этих своих премиум аккаунтов.
Если нам не помогут, то мы тоже никого не пощадим.
