ranges, unzip (без C++)
От: alexeiz  
Дата: 19.09.11 05:01
Оценка:
Здравствуйте, c-smile, Вы писали:

CS>В принципе лучше (короче) но как бы не менее cryptic, нет?


Отвлечемся от С++. Как ты хочешь, чтобы это выглядело?

24.09.11 01:54: Ветка выделена из темы ranges, unzip
Автор: c-smile
Дата: 19.09.11
— VladD2
24.09.11 01:55: Перенесено модератором из 'C/C++' — VladD2
Re: ranges, unzip (без C++)
От: enji  
Дата: 19.09.11 10:07
Оценка: +1
Здравствуйте, alexeiz, Вы писали:

A>Отвлечемся от С++. Как ты хочешь, чтобы это выглядело?


А можно мне влезть?

Как-то вот так:

int vmax_total = sequence.unzip(x -> x.vmax).accumulate(0);

или даже

int vmax_total = sequence.unzip(_.vmax).accumulate(0);

Re: ranges, unzip (без C++)
От: enji  
Дата: 19.09.11 10:15
Оценка:
Здравствуйте, alexeiz, Вы писали:

A>Здравствуйте, c-smile, Вы писали:


CS>>В принципе лучше (короче) но как бы не менее cryptic, нет?


A>Отвлечемся от С++. Как ты хочешь, чтобы это выглядело?


а если серьезно — то почему не дали возможность иметь "шаблонные" лямбды + немного сахара, чтобы template<class T> можно было бы опускать, а также чтобы по дефолту параметры передавались как const&:

int vmax_total = sequence.unzip([](el){return el.vmax}).accumulate(0);

что эквивалентно

int vmax_total = sequence.unzip([] template<class T>(const T& el){return el.vmax}).accumulate(0);

Руками же можно сделать шаблонный функтор, вполне бы и компилер справился. Вроде как ничего мегасложного по сравнению с нешаблонным нету...
Re: ranges, unzip (без C++)
От: k.o. Россия  
Дата: 19.09.11 10:16
Оценка: 4 (1)
Здравствуйте, alexeiz, Вы писали:

A>Здравствуйте, c-smile, Вы писали:


CS>>В принципе лучше (короче) но как бы не менее cryptic, нет?


A>Отвлечемся от С++. Как ты хочешь, чтобы это выглядело?


Если отвлечься от C++, то это могло бы выглядеть так:
vmax_total = sum . map vmax
Re[2]: ranges, unzip (без C++)
От: WolfHound  
Дата: 20.09.11 09:16
Оценка: :)
Здравствуйте, k.o., Вы писали:

KO>Если отвлечься от C++, то это могло бы выглядеть так:

KO>
KO>vmax_total = sum . map vmax
KO>

Это ты функцию создал. Ее еще к последовательности применить надо.
Плюс у ML'ных языков свои тараканы. Типа отсутствия перегрузки, неявных приведений типов, захламление области видимости (vmax это функция, применяемая к структуре и как следствие она импортируется в текущую область видимости),...

Но есть вполне реальный язык без этих тараканов. Ну вы все его знаете.
def vmax_total = sequence.Map(_.vmax).Sum();

_.vmax сахар для лямбды x => x.vmax
Map и Sum методы расширения. Те они фактически свободные функции просто синтаксический сахар передает "this" первым параметром.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[3]: ranges, unzip (без C++)
От: Alexander Poluektov Германия http://www.google.com/profiles/alexander.poluektov#buzz
Дата: 20.09.11 09:42
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Плюс у ML'ных языков свои тараканы. Типа отсутствия перегрузки, неявных приведений типов, захламление области видимости (vmax это функция, применяемая к структуре и как следствие она импортируется в текущую область видимости),...


"ML-ные языки" это примерно как ".Net-языки": и тех, и других много, и они обладают разным набором фич (и косяков, соответственно).

Про перегрузку лучше даже не вспоминать (в Haskell она решается typeclass'ами).
К вопросу о захламлении, vmax с тем же успехом может быть определена локально внутри vmax_total.

KO>>
KO>>vmax_total = sum . map vmax
KO>>


WH>
WH>def vmax_total = sequence.Map(_.vmax).Sum();
WH>


И в каком фрагменте кода меньше мусора? (подсказка: в коде на Haskell)
Re[4]: ranges, unzip (без C++)
От: WolfHound  
Дата: 20.09.11 11:17
Оценка: :))
Здравствуйте, Alexander Poluektov, Вы писали:

AP>Про перегрузку лучше даже не вспоминать (в Haskell она решается typeclass'ами).

Ну покажи мне перегрузку функций с разным колличеством параметров.

AP>К вопросу о захламлении, vmax с тем же успехом может быть определена локально внутри vmax_total.

Ценой дополнительного кода которого в нормальных языках не будет.

WH>>
WH>>def vmax_total = sequence.Map(_.vmax).Sum();
WH>>

AP>И в каком фрагменте кода меньше мусора? (подсказка: в коде на Haskell)
Полный код такой
let vmax_total = (sum . map vmax) sequence

Посчитай мусор еще раз
Не забудь обратить внимание на нечеловеческий порядок функций в примере на хаскеле.
Да и не забудь про импорт функции vmax
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[5]: ranges, unzip (без C++)
От: Alexander Poluektov Германия http://www.google.com/profiles/alexander.poluektov#buzz
Дата: 20.09.11 11:27
Оценка: :)
Здравствуйте, WolfHound, Вы писали:

AP>>Про перегрузку лучше даже не вспоминать (в Haskell она решается typeclass'ами).

WH>Ну покажи мне перегрузку функций с разным колличеством параметров.

Она не нужна.

AP>>К вопросу о захламлении, vmax с тем же успехом может быть определена локально внутри vmax_total.

WH>Ценой дополнительного кода ...

Это какого? Ключевого слова `where`?

WH>... которого в нормальных языках не будет.


Предлагаю оставить эти полунамеки, и начать называть вещи своими именами: "в нормальном языке Nemerle"

WH>>>
WH>>>def vmax_total = sequence.Map(_.vmax).Sum();
WH>>>

AP>>И в каком фрагменте кода меньше мусора? (подсказка: в коде на Haskell)
WH>Полный код такой
WH>
WH>let vmax_total = (sum . map vmax) sequence
WH>


Нет, такой:

vmax_total = sum $ map vmax sequence


WH>Посчитай мусор еще раз


Ну посчитал
Re[6]: ranges, unzip (без C++)
От: WolfHound  
Дата: 20.09.11 11:38
Оценка:
Здравствуйте, Alexander Poluektov, Вы писали:

WH>>Ну покажи мне перегрузку функций с разным колличеством параметров.

AP>Она не нужна.
Все чего нет в хаскеле не нужно. Позиция понятна.

WH>>Ценой дополнительного кода ...

AP>Это какого? Ключевого слова `where`?
Плюс то что после where.

WH>>... которого в нормальных языках не будет.

AP>Предлагаю оставить эти полунамеки, и начать называть вещи своими именами: "в нормальном языке Nemerle"
Есть еще как минимум Scala.

AP>Ну посчитал

И что? Насчитал пару скобок?
А про бесчеловечный порядок ты опять забыл?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[7]: ranges, unzip (без C++)
От: Alexander Poluektov Германия http://www.google.com/profiles/alexander.poluektov#buzz
Дата: 20.09.11 11:52
Оценка: :)
Здравствуйте, WolfHound, Вы писали:

WH>>>Ну покажи мне перегрузку функций с разным колличеством параметров.

AP>>Она не нужна.
WH>Все чего нет в хаскеле не нужно. Позиция понятна.

Я не хаскеллист, если что.
Но давай я тебя тоже буду просить изобразить на Nemerle то, чего в нем нет by-design, а потом буду надувать щеки, и говорить про понятную позицию.

WH>>>Ценой дополнительного кода ...

AP>>Это какого? Ключевого слова `where`?
WH>Плюс то что после where.

Тот же код будет внутри класса foo, так что мимо.

WH>>>... которого в нормальных языках не будет.

AP>>Предлагаю оставить эти полунамеки, и начать называть вещи своими именами: "в нормальном языке Nemerle"
WH>Есть еще как минимум Scala.

Огласите весь список, пожалуйста (с).

AP>>Ну посчитал

WH>И что? Насчитал пару скобок?

Стыдно врать, скобок там четыре. А также куча мусорных точек, def, underscore и точка с запятой.

WH>А про бесчеловечный порядок ты опять забыл?


Конвейер смотрелся бы уместнее, не спорю. И, кстати, намного уместнее, чем вызов через точку.

Если ты считаешь, что код на Nemerle "человечнее" выглядит -- у нас с тобой разный генный набор, и рассуждать об эстетике нам больше не стоит.
Re[8]: ranges, unzip (без C++)
От: WolfHound  
Дата: 20.09.11 12:31
Оценка:
Здравствуйте, Alexander Poluektov, Вы писали:

AP>Но давай я тебя тоже буду просить изобразить на Nemerle то, чего в нем нет by-design, а потом буду надувать щеки, и говорить про понятную позицию.

Вот только демагогию не разводи.
Ты вместо того чтобы признать что хаскель это не умеет сказал "не нужно".

AP>Тот же код будет внутри класса foo, так что мимо.

С чего бы?
В классе foo будет объявление поля. И все.

AP>Стыдно врать, скобок там четыре. А также куча мусорных точек, def, underscore и точка с запятой.

А ты "забыл" кучу кода в where.

AP>Конвейер смотрелся бы уместнее, не спорю. И, кстати, намного уместнее, чем вызов через точку.

А вызов через точку это и есть конвейер.

AP>Если ты считаешь, что код на Nemerle "человечнее" выглядит -- у нас с тобой разный генный набор, и рассуждать об эстетике нам больше не стоит.

Строчкой выше ты сказал что что конвейер уместнее.
Так что ты умудряешься противоречить сам себе в двух идущих подряд строках.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[9]: ranges, unzip (без C++)
От: Alexander Poluektov Германия http://www.google.com/profiles/alexander.poluektov#buzz
Дата: 20.09.11 12:52
Оценка:
Здравствуйте, WolfHound, Вы писали:

AP>>Но давай я тебя тоже буду просить изобразить на Nemerle то, чего в нем нет by-design, а потом буду надувать щеки, и говорить про понятную позицию.


WH>Ты вместо того чтобы признать что хаскель это не умеет сказал "не нужно".


Хаскель этого не умеет
А кстати, каким образом при обсуждении приведенной c-smile задачи вдруг всплыла перегрузка и неявное преобразование типов?

WH>Вот только демагогию не разводи.


Да что ты, что ты! Где мне с тобой тягаться.

AP>>Тот же код будет внутри класса foo, так что мимо.

WH>С чего бы?
WH>В классе foo будет объявление поля. И все.

Ок, признаю, имя vmax появится в области видимости модуля.
(Правда не вижу в этом проблемы).

AP>>Конвейер смотрелся бы уместнее, не спорю. И, кстати, намного уместнее, чем вызов через точку.

WH>А вызов через точку это и есть конвейер.

Этой мысли я не понял.
Я могу output функции f1 скормить в input функции f2 (при условии соотвествия типов) через точку?
Если так, то посыпаю голову пеплом.
Re[10]: ranges, unzip (без C++)
От: WolfHound  
Дата: 20.09.11 17:14
Оценка:
Здравствуйте, Alexander Poluektov, Вы писали:

AP>Хаскель этого не умеет

Так лучше.

AP>А кстати, каким образом при обсуждении приведенной c-smile задачи вдруг всплыла перегрузка и неявное преобразование типов?

Разговор был переведен на возможности других языков. И заметь не мной.

AP>Да что ты, что ты! Где мне с тобой тягаться.

Вот и не надо. Лучше оперировать фактами. Если они есть.

AP>Ок, признаю, имя vmax появится в области видимости модуля.

AP>(Правда не вижу в этом проблемы).
А если имя vmax будет в двух классах?
Более чем реальная ситуация.
Тут, как ни крутись, а иерархические области видимости заруливают плоские.

AP>Этой мысли я не понял.

AP>Я могу output функции f1 скормить в input функции f2 (при условии соотвествия типов) через точку?
AP>Если так, то посыпаю голову пеплом.
Это называется extension method. Синтаксический сахар к статическим методам.
И об этом я, кстати, уже в этой теме говорил.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[11]: ranges, unzip (без C++)
От: Alexander Poluektov Германия http://www.google.com/profiles/alexander.poluektov#buzz
Дата: 21.09.11 06:57
Оценка:
Здравствуйте, WolfHound, Вы писали:

AP>>А кстати, каким образом при обсуждении приведенной c-smile задачи вдруг всплыла перегрузка и неявное преобразование типов?

WH>Разговор был переведен на возможности других языков. И заметь не мной.

Именно тобой.
Вопрос, который столь фатально увел подветку в оффтопик, звучал как "Отвлечемся от С++. Как ты хочешь, чтобы это выглядело?"
Автор: alexeiz
Дата: 19.09.11


AP>>Да что ты, что ты! Где мне с тобой тягаться.

WH>Вот и не надо. Лучше оперировать фактами. Если они есть.

Как тебе такой факт: большая полуось орбиты Луны равняется 384399 км.
Имеет в данном топике примерно столько же релевантности, как и наличие "нормальной" перегрузки и неявного преобразования типов в Nemerle.

AP>>Ок, признаю, имя vmax появится в области видимости модуля.

AP>>(Правда не вижу в этом проблемы).
WH>А если имя vmax будет в двух классах?

В пределах одного модуля?
А работать при этом надо только с конкретным классом foo? Тогда локальное определение.
Или нужно работать со всеми единообразно? Тогда typeclass.
В разных модулях? Тогда вообще не проблема.

AP>>Этой мысли я не понял.

AP>>Я могу output функции f1 скормить в input функции f2 (при условии соотвествия типов) через точку?
AP>>Если так, то посыпаю голову пеплом.
WH>Это называется extension method. Синтаксический сахар к статическим методам.
WH>И об этом я, кстати, уже в этой теме говорил.

Окей, вот конвейерный вариант для Haskell:

vmax_total = map vmax sequence >> sum


где

(>>) = flip ($)


Порядок следования функций достаточно "человечный"?
Теперь, пожалуйста, продемонстрируй, как таким же "росчерком пера" избавиться от синтаксического шума в примере на Nemerle.

Кстати, интересует также, как записать композицию функций, т.е. чтобы пример на Nemerle был эквивалентен изначально приведенному коду на Haskell:

vmax_total = sum . map vmax


P.S Ты ведь модератор. Ты же видишь, что ветка давно оффтопик в форуме по C++, и соответствующие бомбы имеются. Снеси плз в КСВ.
Re[12]: ranges, unzip (без C++)
От: _nn_ www.nemerleweb.com
Дата: 21.09.11 08:12
Оценка: 4 (1)
AP>Кстати, интересует также, как записать композицию функций, т.е. чтобы пример на Nemerle был эквивалентен изначально приведенному коду на Haskell:

AP>
AP>vmax_total = sum . map vmax
AP>


Возможные варианты на Nemerle/F#, выбирайте что по душе
def vmax_total = Enumerable.Sum(sequence.Map(_.vmax));

def vmax_total = Enumerable.Sum <| sequence.Map(_.vmax);

def vmax_total = Enumerable.Sum << sequence.Map <| _.vmax;

def vmax_total = Enumerable.Sum <| (_.vmax |> sequence.Map);

def vmax_total = sequence.Map(_.vmax) |> Enumerable.Sum;

def vmax_total = sequence.Map >> Enumerable.Sum <| _.vmax;


Haskell крут, хватит спорить

В выражении: vmax_total = sum . map vmax
Как Haskell сам умеет подставлять ("this.") при обращении к vmax ?


AP>P.S Ты ведь модератор. Ты же видишь, что ветка давно оффтопик в форуме по C++, и соответствующие бомбы имеются. Снеси плз в КСВ.

+1
http://rsdn.nemerleweb.com
http://nemerleweb.com
Re[13]: ranges, unzip (без C++)
От: Alexander Poluektov Германия http://www.google.com/profiles/alexander.poluektov#buzz
Дата: 21.09.11 08:32
Оценка: +2
Здравствуйте, _nn_, Вы писали:

AP>>Кстати, интересует также, как записать композицию функций, т.е. чтобы пример на Nemerle был эквивалентен изначально приведенному коду на Haskell:


AP>>
AP>>vmax_total = sum . map vmax
AP>>


__>Возможные варианты на Nemerle/F#, выбирайте что по душе

__>
__>def vmax_total = Enumerable.Sum(sequence.Map(_.vmax));

__>def vmax_total = Enumerable.Sum <| sequence.Map(_.vmax);

__>def vmax_total = Enumerable.Sum << sequence.Map <| _.vmax;

__>def vmax_total = Enumerable.Sum <| (_.vmax |> sequence.Map);

__>def vmax_total = sequence.Map(_.vmax) |> Enumerable.Sum;

__>def vmax_total = sequence.Map >> Enumerable.Sum <| _.vmax;
__>


Мне по душе, когда без лишних слов
По-моему в данном случае очевидно, чья запись чище.

__>Haskell крут, хватит спорить


(хныкая и показывая пальцем на Wolfhound) А он первый начал!

Для меня вся ситуация выглядит так: k.o. привел фрагмент кода "абстрагируясь" от C++, но его ошибкой было написать этот фрагмент не на Нормальном Языке, что было воспринято как приглашение начать прозелитизм Нормального Языка.

Я на самом деле ничего против Nemerle не имею: вполне допускаю, что это лучший на сегодняшний день язык для разроботки под .Net; и естественно, у него есть свои преимущества перед Haskell.
Что меня напрягает, так это попытка установить полный порядок на множестве языков, и объявить Nemerle его максимальным элементом.

__>В выражении: vmax_total = sum . map vmax

__>Как Haskell сам умеет подставлять ("this.") при обращении к vmax ?

Выражение (map vmax) имеет тип [a] -> [a], так что остается только дать ему требуемый [a], т.е. sequence.
Re[14]: ranges, unzip (без C++)
От: _nn_ www.nemerleweb.com
Дата: 21.09.11 09:03
Оценка:
Здравствуйте, Alexander Poluektov, Вы писали:

AP>Мне по душе, когда без лишних слов

AP>По-моему в данном случае очевидно, чья запись чище.

Но ведь sum и map живут в каком-нибудь пространстве имен.
В Nemerle можно их вытащить также наружу:
using System.Linq.Enumerable;

def vmax_total = sequence.Map >> Sum <| _.vmax;


Дальше уже некуда:
.Map — Синтаксис для вызов метода.
_.vmax — Доступ к полю/свойству объекта.
Другого синтаксиса не предусмотрено. Да и куда тут упрощать ?

В выражении в любом случае должны присутствовать: sequence, Map, Sum и vmax.
Разве что при создании функции в Nemerle нужно описать аргумент явно: (Как мне кажется по другому не получится)
def vmax_total = p => p.Map >> Sum <| _.vmax;

А в Haskell это можно протащить неявно.


__>>Haskell крут, хватит спорить


AP>(хныкая и показывая пальцем на Wolfhound) А он первый начал!

Мир и пиво
http://rsdn.nemerleweb.com
http://nemerleweb.com
Re[15]: ranges, unzip (без C++)
От: Alexander Poluektov Германия http://www.google.com/profiles/alexander.poluektov#buzz
Дата: 21.09.11 09:12
Оценка:
Здравствуйте, _nn_, Вы писали:

__>
__>using System.Linq.Enumerable;

__>def vmax_total = sequence.Map >> Sum <| _.vmax;
__>


Это уже симпатичнее. Еще немного -- и станет совсем хорошо

__>В выражении в любом случае должны присутствовать: sequence, Map, Sum и vmax.


sequence -- не должен

__>Разве что при создании функции в Nemerle нужно описать аргумент явно: (Как мне кажется по другому не получится)

__>
__>def vmax_total = p => p.Map >> Sum <| _.vmax;
__>

__>А в Haskell это можно протащить неявно.

Именно.

__>>>Haskell крут, хватит спорить


AP>>(хныкая и показывая пальцем на Wolfhound) А он первый начал!

__>Мир и пиво

Завтра отпуск -- как раз начну
Re[12]: ranges, unzip (без C++)
От: WolfHound  
Дата: 21.09.11 11:20
Оценка:
Здравствуйте, Alexander Poluektov, Вы писали:

WH>>Разговор был переведен на возможности других языков. И заметь не мной.

AP>Именно тобой.
AP>Вопрос, который столь фатально увел подветку в оффтопик, звучал как "Отвлечемся от С++. Как ты хочешь, чтобы это выглядело?"
Автор: alexeiz
Дата: 19.09.11

Осталось выяснить кто автор этого вопроса.

AP>Имеет в данном топике примерно столько же релевантности, как и наличие "нормальной" перегрузки и неявного преобразования типов в Nemerle.

Ты не прав.
k.o. показал решение на языке в котором нет кучи возможностей.
Я указал на это.
После чего кое-кто начал защищать "обиженный" хаскель.

AP>В пределах одного модуля?

AP>А работать при этом надо только с конкретным классом foo? Тогда локальное определение.
Дополнительный код.
А если нужно с двумя, то нужно алиасы придумывать. И опять куча лишнего кода.

AP>Или нужно работать со всеми единообразно? Тогда typeclass.

Опять лишний код.

AP>В разных модулях? Тогда вообще не проблема.

И вместо _.vmax будешь писать SuperPuperModule.vmax

В языках, где области видимости иерархические таких проблем вообще нет.

AP>Порядок следования функций достаточно "человечный"?

AP>Теперь, пожалуйста, продемонстрируй, как таким же "росчерком пера" избавиться от синтаксического шума в примере на Nemerle.
Сделаем порядок еще более человечным.
Добавим разрешение неоднозначностей...
let vmax_total = sequence >> map SuperPuperModule.vmax >> sum

def vmax_total = sequence.Map(_.vmax).Sum();

Ну и где шума больше
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[13]: ranges, unzip (без C++)
От: Alexander Poluektov Германия http://www.google.com/profiles/alexander.poluektov#buzz
Дата: 21.09.11 11:53
Оценка:
Здравствуйте, WolfHound, Вы писали:

AP>>Вопрос, который столь фатально увел подветку в оффтопик, звучал как "Отвлечемся от С++. Как ты хочешь, чтобы это выглядело?"
Автор: alexeiz
Дата: 19.09.11

WH>Осталось выяснить кто автор этого вопроса.

Осталось выяснить, как этот вопрос связан с перегрузками и неявными преобразованиями типов.

AP>>Имеет в данном топике примерно столько же релевантности, как и наличие "нормальной" перегрузки и неявного преобразования типов в Nemerle.

WH>Ты не прав.

Я прав.

WH>k.o. показал решение на языке в котором нет кучи возможностей.

WH>Я указал на это.

Да, именно это и является полнейшим оффтопиком в этой ветке.

AP>>В пределах одного модуля?

AP>>А работать при этом надо только с конкретным классом foo? Тогда локальное определение.
WH>Дополнительный код.
WH>А если нужно с двумя, то нужно алиасы придумывать. И опять куча лишнего кода.

Какие алиасы?

AP>>Или нужно работать со всеми единообразно? Тогда typeclass.

WH>Опять лишний код.

Boring, boring, boring.
Очевидно же, что "ML'ный язык" не спроста запрещает неограниченную перегрузку. В отличие от закорючек в приведенной ниже записи Nemerle.

AP>>В разных модулях? Тогда вообще не проблема.

WH>И вместо _.vmax будешь писать SuperPuperModule.vmax

Нет, не буду. Импортирую SuperPuperModule as S, и все дела.

WH>Сделаем порядок еще более человечным.


Окей, на этом месте я всерьез укрепляюсь во мнении о разном генном наборе.

И не надо пихать всюду это пошлое let: мы не внутри IO, кажется.

WH>Добавим разрешение неоднозначностей...


... и получаем на выходе

vmax_total = map S.vmax sequence >> sum


против

def vmax_total = sequence.Map(_.vmax).Sum();


WH>Ну и где шума больше


Дай-ка подумаю... снова в Nemerle?

WH>После чего кое-кто начал защищать "обиженный" хаскель.


Мы вообще в этой ветке не спорим о возможностях языков... уточню: я не спорю.
Вопрос был, как бы это могло выглядить, если абстрагироваться от C++.
Теперь ты, пытаясь называть белое "черным" и наоборот, безуспешно пытаешься продемонстрировать, что запись на Nemerle меньше "шумит"
Мне остается пожелать тебе дальнейших успехов, и самоустраниться.

На последок я еще раз рискну попросить перенести ветку из форума по C++.
Re[14]: ranges, unzip (без C++)
От: WolfHound  
Дата: 21.09.11 12:31
Оценка:
Здравствуйте, Alexander Poluektov, Вы писали:

AP>Boring, boring, boring.

Факт! Факт! Факт!

AP>Очевидно же, что "ML'ный язык" не спроста запрещает неограниченную перегрузку. В отличие от закорючек в приведенной ниже записи Nemerle.

По тому что они просто не осилили вывод типов.
Вот так просто и банально.
И это тоже факт.

AP>Нет, не буду. Импортирую SuperPuperModule as S, и все дела.

Придумываешь алиасы. Однобуквенные.

AP>Дай-ка подумаю... снова в Nemerle?

Ты забыл про SuperPuperModule as S

Я тут просто указываю на неточности и подтасовки.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[3]: ranges, unzip (без C++)
От: enji  
Дата: 21.09.11 12:43
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Но есть вполне реальный язык без этих тараканов. Ну вы все его знаете.

WH>
WH>def vmax_total = sequence.Map(_.vmax).Sum();
WH>



Это ж скала, один в один
Re[15]: ranges, unzip (без C++)
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.09.11 21:59
Оценка: +1
Здравствуйте, _nn_, Вы писали:

__>Но ведь sum и map живут в каком-нибудь пространстве имен.

__>В Nemerle можно их вытащить также наружу:
__>
__>using System.Linq.Enumerable;

__>def vmax_total = sequence.Map >> Sum <| _.vmax;
__>


Какой ужас! В борьбе за краткость победу одержала глупость .

Лучше чуть длинее, но понятнее:
def vmax_total = sequence.Map(_.vmax).Sum();
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: ranges, unzip (без C++)
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.09.11 22:06
Оценка: +1
Здравствуйте, Alexander Poluektov, Вы писали:

AP>
AP>vmax_total = map S.vmax sequence >> sum
AP>


AP>против


AP>
AP>def vmax_total = sequence.Map(_.vmax).Sum();
AP>


Если вы не меряетесь у кого короче, а говорите о понятности и читаемости, то только полный ML головгого мозга, на мой взгляд, может быть объяснением тому факту, что первая запись кажется понятнее.

Лично для меня более важна естественная последовательность описания вычислений. Во втором случае я ее вижу. В первом — нет.

В прочем, флэйм ML-ная нотация vs. сишная меня не заводит. Так что фиг бы с ним.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: ranges, unzip (без C++)
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.09.11 22:08
Оценка: +1
Здравствуйте, WolfHound, Вы писали:

WH>Я тут просто указываю на неточности и подтасовки.


Ты тем самым создаешь негативное отношение к немерлу. Зачем его противопоставлять хаскелю? В конце концов и Немерл, и Хаскель поддерживают ФП в сто раз лучше С++. Лучше было бы сказать что-то вроде "или вот так, на немерле..." или просто промолчать. Ну, привели пример на том что знают и фиг бы с ними.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.