Сообщение Re[11]: Упоротость С++ от 27.08.2023 8:53
Изменено 27.08.2023 8:54 vdimas
Re[11]: Упоротость С++
Здравствуйте, Serginio1, Вы писали:
S>>>Тогда C# функциональный язык?
V>>Мультипарадигменный, как и С++, т.к. в есть поддержка функционального типа на уровне языка, поэтому можно писать и в функциональном стиле.
S>Там диалог про другое. Замыкания уже обыденность в императивных языках.
Обыденность в мультипарадигменных. ))
S>А вот PM это как бы вершина функциональности.
ПМ в статически строго-типизированных ФП-языках достаточно убог и служит, в основном, для ветвления по Discriminated Union.
Собсно, другого способа узнать код этого дискриминатора и не существует, бгг...
Потому что при ветвлении в статическом строго-типизированном ФП-языке необходимо попадать в строгий типизированный контекст после реинтерпретации "тела" DU.
Вторая фишка ПМ в строго-типизированном ФП-языке — это позиционная проверка туплов.
И на этом всё, приплыли! ))
Остальное — сахар над простой цепочкой if-elseif-...-else.
S>И степень функциональности определяется степенью PM.
Опять ерунду спорол... ))
В этой реальности у самого мощного FP-языка (Хаскеля) наблюдается самый убогий PM.
Как так?
Правильный ответ — из-за ограничений системы типов.
Отсюда, 99% трюков ПМ из Шарпа в Хаскеле принципиально невозможны, ес-но, бо в C# ты можешь матчить даже самый базовый Object.
Плюс паттерн матчинг в шарпе доступен уже в простом операторе is, в т.ч. рекурсино-уточняющий сколь угодной вложенности вглубь или сколько угодно уточняющий вдоль по цепочке таких is.
Хаскель тут сосёт не нагибаясь, как грится.
S>О чем так упорно говорили немерлисты. Вот в C# эволюция ПМ достигла своего апогея.
Не факт.
Начиная с C# 7 в каждой версии добавляются новые возможности в PM.
С чего ты решил, что этот процесс уже завершён?
S>Но по функциональности все равно проигрывает F#
Ты малость поднадоел сегодня нести ерунду...
PM в C# у выигрывает у F# с разгромным счётом, ес-но.
(сам же ссылки дал — не смотрел, разве?)
В F# есть только одна конструкция, неизвестная в C# — это явное ветвление по discriminated union, бо такого встроенного в язык типа данных нет в C#, опять бгг.
Вместо этого C# предлагает ветвиться вообще по любому достижимому типу, где дискриминатором является, собсно... тип!
F# в этом месте — мальчик для битья.
S>https://learn.microsoft.com/ru-ru/dotnet/fsharp/language-reference/pattern-matching
S>https://learn.microsoft.com/ru-ru/dotnet/csharp/fundamentals/functional/pattern-matching
S>https://learn.microsoft.com/ru-ru/dotnet/csharp/language-reference/operators/patterns#list-patterns
Ну вот и ознакомься тщательнее, с обязательным пониманием происходящего.
S> Кстати про head :: tail в C#
S>
Не забывай, что в ФП-языках список представлен линкованным списком CONS-ячеек, что в общем случае убого с т.з. эффективности, хотя позволяет единообразно ссылать на любой хвост в списке.
В C# для этого завезут ПМ над Span (конкретно для Span<char> уже завезли).
И опять получится мощнее, чем в ФП-языках, бо в ПМ можно будет ссылаться не только на хвост списка (как в ФП), а на произвольный подсписок в списке.
S>Вот у меня и был вопрос про ПМ в С++.
Для ветвления по константам он делается в switch/case.
(забыл разве?)
Для типов можно однократно накрутить хеплеры, типа такого:
https://habr.com/ru/articles/282630/
Более полно есть в Boost:
https://boostorg.github.io/hana/index.html#tutorial-quickstart
где константы времени компиляции надо оборачивать в типы народе integral_constant<int, 42>, или, используя using (продвинутую версию typedef), определить более короткие int_<42>, char_<'c'> и т.д.
Сахар для if-elseif-..-else в плюсах тоже накручивается достаточно просто, хотя и потребует некоего типа-тега, который послужит для привязки, допустим, оператора |.
По умолчанию в таких либах делается через простую запятую без дополнительных приседаний.
S>На что тут же вспомнили лисп (который тоже не чисто ФЯП), что в нем нет ПМ, но он функциональный. И просили дать определение ФП.
S>На что я ответил, что степень функциональности надо сравнивать с Haskel
Не-а.
Хаскель ленивый язык и это принципиально, т.к. в нём строится "один большой функционал", который протаскивается по главной монаде main. ))
"Разложив" на составляющие происходящее в императивном рантайме, там происходит нечто вроде бесконечного вызова ф-ий, где аргументами являются результаты предыдущих вызовов (плюс новые аргументы, в т.ч. константы), что-то типа args => func1 => (result, args) => func2 => (result, args) => и т.д.
Без ленивости это принципиально не работает.
Поэтому, сравнивать с Хаскель бесполезно — это отдельная вселенная даже в мире ФП-языков. ))
S>а лучше с F# где присутствуют все парадигмы ФП.
Дудки, F# — мультипарадигменный, просто его синтаксис заточен на ФП-конструкции, сугубо выразительности оных ради.
Собсно, это семейство ML, где не все языки из этого семейства являются чисто-функциональными, навроде Хаскеля.
Например, Caml-семейство (откуда F# родом) таковым не является.
===========================
В общем, утверждение "чем круче в языке ПМ, тем он более ФП-парадигменный" не выдерживает никакой критики, предлагаю тебе от этого утверждения отказаться. ))
S>>>Тогда C# функциональный язык?
V>>Мультипарадигменный, как и С++, т.к. в есть поддержка функционального типа на уровне языка, поэтому можно писать и в функциональном стиле.
S>Там диалог про другое. Замыкания уже обыденность в императивных языках.
Обыденность в мультипарадигменных. ))
S>А вот PM это как бы вершина функциональности.
ПМ в статически строго-типизированных ФП-языках достаточно убог и служит, в основном, для ветвления по Discriminated Union.
Собсно, другого способа узнать код этого дискриминатора и не существует, бгг...
Потому что при ветвлении в статическом строго-типизированном ФП-языке необходимо попадать в строгий типизированный контекст после реинтерпретации "тела" DU.
Вторая фишка ПМ в строго-типизированном ФП-языке — это позиционная проверка туплов.
И на этом всё, приплыли! ))
Остальное — сахар над простой цепочкой if-elseif-...-else.
S>И степень функциональности определяется степенью PM.
Опять ерунду спорол... ))
В этой реальности у самого мощного FP-языка (Хаскеля) наблюдается самый убогий PM.
Как так?
Правильный ответ — из-за ограничений системы типов.
Отсюда, 99% трюков ПМ из Шарпа в Хаскеле принципиально невозможны, ес-но, бо в C# ты можешь матчить даже самый базовый Object.
Плюс паттерн матчинг в шарпе доступен уже в простом операторе is, в т.ч. рекурсино-уточняющий сколь угодной вложенности вглубь или сколько угодно уточняющий вдоль по цепочке таких is.
Хаскель тут сосёт не нагибаясь, как грится.
S>О чем так упорно говорили немерлисты. Вот в C# эволюция ПМ достигла своего апогея.
Не факт.
Начиная с C# 7 в каждой версии добавляются новые возможности в PM.
С чего ты решил, что этот процесс уже завершён?
S>Но по функциональности все равно проигрывает F#
Ты малость поднадоел сегодня нести ерунду...
PM в C# у выигрывает у F# с разгромным счётом, ес-но.
(сам же ссылки дал — не смотрел, разве?)
В F# есть только одна конструкция, неизвестная в C# — это явное ветвление по discriminated union, бо такого встроенного в язык типа данных нет в C#, опять бгг.
Вместо этого C# предлагает ветвиться вообще по любому достижимому типу, где дискриминатором является, собсно... тип!
F# в этом месте — мальчик для битья.
S>https://learn.microsoft.com/ru-ru/dotnet/fsharp/language-reference/pattern-matching
S>https://learn.microsoft.com/ru-ru/dotnet/csharp/fundamentals/functional/pattern-matching
S>https://learn.microsoft.com/ru-ru/dotnet/csharp/language-reference/operators/patterns#list-patterns
Ну вот и ознакомься тщательнее, с обязательным пониманием происходящего.
S> Кстати про head :: tail в C#
S>
S> [var head, .. var tail]
S>Не забывай, что в ФП-языках список представлен линкованным списком CONS-ячеек, что в общем случае убого с т.з. эффективности, хотя позволяет единообразно ссылать на любой хвост в списке.
В C# для этого завезут ПМ над Span (конкретно для Span<char> уже завезли).
И опять получится мощнее, чем в ФП-языках, бо в ПМ можно будет ссылаться не только на хвост списка (как в ФП), а на произвольный подсписок в списке.
S>Вот у меня и был вопрос про ПМ в С++.
Для ветвления по константам он делается в switch/case.
(забыл разве?)
Для типов можно однократно накрутить хеплеры, типа такого:
https://habr.com/ru/articles/282630/
Более полно есть в Boost:
https://boostorg.github.io/hana/index.html#tutorial-quickstart
где константы времени компиляции надо оборачивать в типы народе integral_constant<int, 42>, или, используя using (продвинутую версию typedef), определить более короткие int_<42>, char_<'c'> и т.д.
Сахар для if-elseif-..-else в плюсах тоже накручивается достаточно просто, хотя и потребует некоего типа-тега, который послужит для привязки, допустим, оператора |.
По умолчанию в таких либах делается через простую запятую без дополнительных приседаний.
S>На что тут же вспомнили лисп (который тоже не чисто ФЯП), что в нем нет ПМ, но он функциональный. И просили дать определение ФП.
S>На что я ответил, что степень функциональности надо сравнивать с Haskel
Не-а.
Хаскель ленивый язык и это принципиально, т.к. в нём строится "один большой функционал", который протаскивается по главной монаде main. ))
"Разложив" на составляющие происходящее в императивном рантайме, там происходит нечто вроде бесконечного вызова ф-ий, где аргументами являются результаты предыдущих вызовов (плюс новые аргументы, в т.ч. константы), что-то типа args => func1 => (result, args) => func2 => (result, args) => и т.д.
Без ленивости это принципиально не работает.
Поэтому, сравнивать с Хаскель бесполезно — это отдельная вселенная даже в мире ФП-языков. ))
S>а лучше с F# где присутствуют все парадигмы ФП.
Дудки, F# — мультипарадигменный, просто его синтаксис заточен на ФП-конструкции, сугубо выразительности оных ради.
Собсно, это семейство ML, где не все языки из этого семейства являются чисто-функциональными, навроде Хаскеля.
Например, Caml-семейство (откуда F# родом) таковым не является.
===========================
В общем, утверждение "чем круче в языке ПМ, тем он более ФП-парадигменный" не выдерживает никакой критики, предлагаю тебе от этого утверждения отказаться. ))
Re[11]: Упоротость С++
Здравствуйте, Serginio1, Вы писали:
S>>>Тогда C# функциональный язык?
V>>Мультипарадигменный, как и С++, т.к. в есть поддержка функционального типа на уровне языка, поэтому можно писать и в функциональном стиле.
S>Там диалог про другое. Замыкания уже обыденность в императивных языках.
Обыденность в мультипарадигменных. ))
S>А вот PM это как бы вершина функциональности.
ПМ в статически строго-типизированных ФП-языках достаточно убог и служит, в основном, для ветвления по Discriminated Union.
Собсно, другого способа узнать код этого дискриминатора и не существует, бгг...
Потому что при ветвлении в статически строго-типизированном ФП-языке необходимо попадать в строгий типизированный контекст после реинтерпретации "тела" DU.
Вторая фишка ПМ в строго-типизированном ФП-языке — это позиционная проверка туплов.
И на этом всё, приплыли! ))
Остальное — сахар над простой цепочкой if-elseif-...-else.
S>И степень функциональности определяется степенью PM.
Опять ерунду спорол... ))
В этой реальности у самого мощного FP-языка (Хаскеля) наблюдается самый убогий PM.
Как так?
Правильный ответ — из-за ограничений системы типов.
Отсюда, 99% трюков ПМ из Шарпа в Хаскеле принципиально невозможны, ес-но, бо в C# ты можешь матчить даже самый базовый Object.
Плюс паттерн матчинг в шарпе доступен уже в простом операторе is, в т.ч. рекурсино-уточняющий сколь угодной вложенности вглубь или сколько угодно уточняющий вдоль по цепочке таких is.
Хаскель тут сосёт не нагибаясь, как грится.
S>О чем так упорно говорили немерлисты. Вот в C# эволюция ПМ достигла своего апогея.
Не факт.
Начиная с C# 7 в каждой версии добавляются новые возможности в PM.
С чего ты решил, что этот процесс уже завершён?
S>Но по функциональности все равно проигрывает F#
Ты малость поднадоел сегодня нести ерунду...
PM в C# у выигрывает у F# с разгромным счётом, ес-но.
(сам же ссылки дал — не смотрел, разве?)
В F# есть только одна конструкция, неизвестная в C# — это явное ветвление по discriminated union, бо такого встроенного в язык типа данных нет в C#, опять бгг.
Вместо этого C# предлагает ветвиться вообще по любому достижимому типу, где дискриминатором является, собсно... тип!
F# в этом месте — мальчик для битья.
S>https://learn.microsoft.com/ru-ru/dotnet/fsharp/language-reference/pattern-matching
S>https://learn.microsoft.com/ru-ru/dotnet/csharp/fundamentals/functional/pattern-matching
S>https://learn.microsoft.com/ru-ru/dotnet/csharp/language-reference/operators/patterns#list-patterns
Ну вот и ознакомься тщательнее, с обязательным пониманием происходящего.
S> Кстати про head :: tail в C#
S>
Не забывай, что в ФП-языках список представлен линкованным списком CONS-ячеек, что в общем случае убого с т.з. эффективности, хотя позволяет единообразно ссылать на любой хвост в списке.
В C# для этого завезут ПМ над Span (конкретно для Span<char> уже завезли).
И опять получится мощнее, чем в ФП-языках, бо в ПМ можно будет ссылаться не только на хвост списка (как в ФП), а на произвольный подсписок в списке.
S>Вот у меня и был вопрос про ПМ в С++.
Для ветвления по константам он делается в switch/case.
(забыл разве?)
Для типов можно однократно накрутить хеплеры, типа такого:
https://habr.com/ru/articles/282630/
Более полно есть в Boost:
https://boostorg.github.io/hana/index.html#tutorial-quickstart
где константы времени компиляции надо оборачивать в типы народе integral_constant<int, 42>, или, используя using (продвинутую версию typedef), определить более короткие int_<42>, char_<'c'> и т.д.
Сахар для if-elseif-..-else в плюсах тоже накручивается достаточно просто, хотя и потребует некоего типа-тега, который послужит для привязки, допустим, оператора |.
По умолчанию в таких либах делается через простую запятую без дополнительных приседаний.
S>На что тут же вспомнили лисп (который тоже не чисто ФЯП), что в нем нет ПМ, но он функциональный. И просили дать определение ФП.
S>На что я ответил, что степень функциональности надо сравнивать с Haskel
Не-а.
Хаскель ленивый язык и это принципиально, т.к. в нём строится "один большой функционал", который протаскивается по главной монаде main. ))
"Разложив" на составляющие происходящее в императивном рантайме, там происходит нечто вроде бесконечного вызова ф-ий, где аргументами являются результаты предыдущих вызовов (плюс новые аргументы, в т.ч. константы), что-то типа args => func1 => (result, args) => func2 => (result, args) => и т.д.
Без ленивости это принципиально не работает.
Поэтому, сравнивать с Хаскель бесполезно — это отдельная вселенная даже в мире ФП-языков. ))
S>а лучше с F# где присутствуют все парадигмы ФП.
Дудки, F# — мультипарадигменный, просто его синтаксис заточен на ФП-конструкции, сугубо выразительности оных ради.
Собсно, это семейство ML, где не все языки из этого семейства являются чисто-функциональными, навроде Хаскеля.
Например, Caml-семейство (откуда F# родом) таковым не является.
===========================
В общем, утверждение "чем круче в языке ПМ, тем он более ФП-парадигменный" не выдерживает никакой критики, предлагаю тебе от этого утверждения отказаться. ))
S>>>Тогда C# функциональный язык?
V>>Мультипарадигменный, как и С++, т.к. в есть поддержка функционального типа на уровне языка, поэтому можно писать и в функциональном стиле.
S>Там диалог про другое. Замыкания уже обыденность в императивных языках.
Обыденность в мультипарадигменных. ))
S>А вот PM это как бы вершина функциональности.
ПМ в статически строго-типизированных ФП-языках достаточно убог и служит, в основном, для ветвления по Discriminated Union.
Собсно, другого способа узнать код этого дискриминатора и не существует, бгг...
Потому что при ветвлении в статически строго-типизированном ФП-языке необходимо попадать в строгий типизированный контекст после реинтерпретации "тела" DU.
Вторая фишка ПМ в строго-типизированном ФП-языке — это позиционная проверка туплов.
И на этом всё, приплыли! ))
Остальное — сахар над простой цепочкой if-elseif-...-else.
S>И степень функциональности определяется степенью PM.
Опять ерунду спорол... ))
В этой реальности у самого мощного FP-языка (Хаскеля) наблюдается самый убогий PM.
Как так?
Правильный ответ — из-за ограничений системы типов.
Отсюда, 99% трюков ПМ из Шарпа в Хаскеле принципиально невозможны, ес-но, бо в C# ты можешь матчить даже самый базовый Object.
Плюс паттерн матчинг в шарпе доступен уже в простом операторе is, в т.ч. рекурсино-уточняющий сколь угодной вложенности вглубь или сколько угодно уточняющий вдоль по цепочке таких is.
Хаскель тут сосёт не нагибаясь, как грится.
S>О чем так упорно говорили немерлисты. Вот в C# эволюция ПМ достигла своего апогея.
Не факт.
Начиная с C# 7 в каждой версии добавляются новые возможности в PM.
С чего ты решил, что этот процесс уже завершён?
S>Но по функциональности все равно проигрывает F#
Ты малость поднадоел сегодня нести ерунду...
PM в C# у выигрывает у F# с разгромным счётом, ес-но.
(сам же ссылки дал — не смотрел, разве?)
В F# есть только одна конструкция, неизвестная в C# — это явное ветвление по discriminated union, бо такого встроенного в язык типа данных нет в C#, опять бгг.
Вместо этого C# предлагает ветвиться вообще по любому достижимому типу, где дискриминатором является, собсно... тип!
F# в этом месте — мальчик для битья.
S>https://learn.microsoft.com/ru-ru/dotnet/fsharp/language-reference/pattern-matching
S>https://learn.microsoft.com/ru-ru/dotnet/csharp/fundamentals/functional/pattern-matching
S>https://learn.microsoft.com/ru-ru/dotnet/csharp/language-reference/operators/patterns#list-patterns
Ну вот и ознакомься тщательнее, с обязательным пониманием происходящего.
S> Кстати про head :: tail в C#
S>
S> [var head, .. var tail]
S>Не забывай, что в ФП-языках список представлен линкованным списком CONS-ячеек, что в общем случае убого с т.з. эффективности, хотя позволяет единообразно ссылать на любой хвост в списке.
В C# для этого завезут ПМ над Span (конкретно для Span<char> уже завезли).
И опять получится мощнее, чем в ФП-языках, бо в ПМ можно будет ссылаться не только на хвост списка (как в ФП), а на произвольный подсписок в списке.
S>Вот у меня и был вопрос про ПМ в С++.
Для ветвления по константам он делается в switch/case.
(забыл разве?)
Для типов можно однократно накрутить хеплеры, типа такого:
https://habr.com/ru/articles/282630/
Более полно есть в Boost:
https://boostorg.github.io/hana/index.html#tutorial-quickstart
где константы времени компиляции надо оборачивать в типы народе integral_constant<int, 42>, или, используя using (продвинутую версию typedef), определить более короткие int_<42>, char_<'c'> и т.д.
Сахар для if-elseif-..-else в плюсах тоже накручивается достаточно просто, хотя и потребует некоего типа-тега, который послужит для привязки, допустим, оператора |.
По умолчанию в таких либах делается через простую запятую без дополнительных приседаний.
S>На что тут же вспомнили лисп (который тоже не чисто ФЯП), что в нем нет ПМ, но он функциональный. И просили дать определение ФП.
S>На что я ответил, что степень функциональности надо сравнивать с Haskel
Не-а.
Хаскель ленивый язык и это принципиально, т.к. в нём строится "один большой функционал", который протаскивается по главной монаде main. ))
"Разложив" на составляющие происходящее в императивном рантайме, там происходит нечто вроде бесконечного вызова ф-ий, где аргументами являются результаты предыдущих вызовов (плюс новые аргументы, в т.ч. константы), что-то типа args => func1 => (result, args) => func2 => (result, args) => и т.д.
Без ленивости это принципиально не работает.
Поэтому, сравнивать с Хаскель бесполезно — это отдельная вселенная даже в мире ФП-языков. ))
S>а лучше с F# где присутствуют все парадигмы ФП.
Дудки, F# — мультипарадигменный, просто его синтаксис заточен на ФП-конструкции, сугубо выразительности оных ради.
Собсно, это семейство ML, где не все языки из этого семейства являются чисто-функциональными, навроде Хаскеля.
Например, Caml-семейство (откуда F# родом) таковым не является.
===========================
В общем, утверждение "чем круче в языке ПМ, тем он более ФП-парадигменный" не выдерживает никакой критики, предлагаю тебе от этого утверждения отказаться. ))