Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, FR, Вы писали:

FR>>Объясни пожалуйста, чем более мощны функции в это тройке (Окамл Хаскель и Немерле) чем например в питоне (или руби).

VD>Наличием карринга/частичного применения.

Это важно для Хаскеля и Окамла с их бесскобочным способом вызова и комбинаторикой, и мало что дает для обычных скобочных в Немерле и Питоне.

FR>>Мне кажется что наоборот Окамл и Немерле немного уступают тут динамике (за счет того что в динамике функции более обобщенные).

VD>Обобщенность не влияет на работу с функциями. К тому же у Немерле и темболее у Хаскеля с ОКамлом особых проблем с обобщением нет. В Немерле дела чуть хуже из-за особенностей системы типов .NET.

Ну у Окамла тоже есть проблемы. Тот же map нельзя реализовать с помощью обычной функции. А обобщеность дает не меньше пользы чем карринг.


FR>>В питоне да есть свои заморочки, (но с другой стороны его ООП мощнее за счет метаклассов чем), но в чем Руби-то слабее?, по моему там ООП мощнее Скалы и Немерле (тоже за счет метаклассов).

VD>Отсуствием защиты. В прочем я и отмечал Питон в этом смысле. В Руби дела отсбоят несколько лучше.

Насчет питона согласен, это во многом результат вжика создателя.
Но насчет руби может дела все-таки не отсбоят несколько лучше а дела обстоят ничем ни хуже чем в Скале и Немерле?

FR>>Выделенное интенсивно делают, в рамках PyPy.

VD>Вот только результат пока что слабенький.

Для альфы очень неплохо.

FR>>Ну руби позволяет и частично синтаксис "менять", питон нет, но метапрограммирование у обоих вполне на уровне. К тому же питон предоставляет библиотеки для полного доступа к AST и комиляции, и при желании там очень много можно наворотить.

VD>Руби тоже не позволяет менять сам синтаксис. Он позволяет некоторым конструкциям прикидываться другими. Но это менее мещьный механизм. И более опасный (нет синтаксического контроля).

угу

VD>>>11. Встроенная поддержка параллелизма. Тут в списке остается только Эрлэнг. Но Немерле, ОКамл и Лисп позволяют добавить подобнрые фрэймворки в виде библиотеки. Так что пункт не столь очевиден.

FR>>Питон тоже позволяет в виде библиотеки, есть даже несколько в стиле эрланга.

VD>Собственно о том и речь. Но тут скорее говориться о введении в язык неких боле высокоуровневых контсрукций. В прочем возможно метастредств Питона и Руби хватит на это. Готов согласиться, что этот пункт можно решать библиотечными методами при некоторых условиях.

Не "можно решить", а в случае питона уже давно решены, притом несколькими способами, от радикального вмешательства в интерпретатор (Stackless Python) до библиотек легких потоков в разных стилях (например Candygram http://candygram.sourceforge.net/)

VD>Весь код дотнета компилирюется в нэтив-код. Так что не надо. Да и мощьности языку это не предает. Так что фактически это опят разговор из серии "мне не нравится дотнет".

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

VD>>>Конечно можно сказать, что кому-то некоторые пункты могут оказаться не важными, но факт отсается фактом.

FR>>Не факт, а твое субъективное мнение.

VD>Мнение вполне себе объективное. По сути ты не поспорил не с дним пунктом. Даже с твоими уточнениями ничего коренным образом не меняется.

Для тебя конечно нет

VD>Немерле объективно более мощьный язык. Просто, как я уже говорил, многомерность самого понятия мощьности делает осознание этого факта слжной задачей. Ведь если тебе не важны некоторые измерения, то ты вполне можешь говорить что Немерле имеет приблизительно одинаковую мощьность с другим языком (например, Руби или Питон). А учитывая эффект Блаб-программиста из которого вытекает, что некоторые измерения попросту отсутсвуют для тех людей которые с ними не знакомы, то любой Блаб-программист считает все остальные языки стольк же мощьными как и его любимый Блаб. И проистекает это потму, что он думает на этом самом Блабе.

Влад извини, но в отношении динамики ты сам выступаешь прямой иллюстрацией именно такого Блаб программиста, притом по моему практически все здесь кто всеръез работают с динамикой хорошо это видят.

PI>>спеку пишет архитектор

M>Архитектор напишет, что в таком-то месте, необходимо использовать алгоритм XXX. Задача программиста реализовать алгоритм(предположим, что подходящей готовой реализации не нашлось). После того, как программист реализует его, как тестер должен понять какие исключительные ситуации могут быть при использовании алгоритма ?

архитектор подразбивает систему на подсистемы и описывает интерфейсы, которые должны реализовать блоки, а также ограничения (например, по производительности), которые на эти блоки налагаются
естественно, могут быть "whole system-wide policies"
задача определения какие исключительные ситуации могут быть получены в результате вызова тех или иных функций, мягко говоря — частный случай в этом свете (она тривиальна)

M>>>А кто будет эту спеку писать ?

PI>>спеку пишет архитектор

К>И чем дольше цепочка, тем проще она рвётся

еще раз повторяю, вы тут не со мной спорите, а с Бруксом — Брукс говорит исключительно о сложных, больших, стабильных промышленных системах (OS/360 тому пример)
из этих характеристик с необходимостью следует, что составные части системы должны быть тщательно протестированы
с необходимостью следует, что эти системы не может разрабатывать кучка гениальных универсальных программеров
команды из нескольких сотен специалистов — это то количество, на котором ваши насмешки должны смениться как минимум уважением к людям, которые смогли "заставить это работать", потому что agile-методологии очень вряд ли с этим смогли бы справиться
проявить интерес к результатам методологических наработок этих людей, и возможно, перенять что-либо из "тяжёлых", бюрократизированных методологий, — это достойно

а обсуждать "операционные бригады" Брукса, не понимая (забыв), в чем их суть — недостойно

M>>>>А кто будет эту спеку писать ?

PI>>>спеку пишет архитектор

К>>И чем дольше цепочка, тем проще она рвётся

PI>а обсуждать "операционные бригады" Брукса, не понимая (забыв), в чем их суть — недостойно

и тем более недостойно вести себя в стиле "не согласный я! с обоими!"
по крайней мере, о какой цепочке речь идёт я не понял, если структура большой команды — иерархическая, с архитекторами во главе

FR wrote:
> Ну у Окамла тоже есть проблемы. Тот же map нельзя реализовать с помощью обычной функции. А обобщеность дает не меньше пользы чем карринг.
У Окамла масса проблем. Но что за проблема с map — не пойму .
А у замыканий Питона по сравнению с Окамловскими есть недостаток —
невозможность модификации переменной из объемлющей области видимости.
Но это я так, придираюсь, на самом деле влез, чтобы полюбопытствовать
насчет проблем map.

Здравствуйте, Gajdalager, Вы писали:

G>Т.е. очевидно, что пропущена(скорей всего, по недосмотру), Скала, которая не только позволяет, но и уже добавила подобный фреймворк

Питон тоже позволяет и даже добавлен и даже до того как на свет появились Скала и Немерле

PI>> а можешь выписать что есть в Скале, чего нет в Немерле?

VD>Можно. Но туташняя публика во сновном не поймет того о чем идет речь.

VD>В скале есть две вещи которые мощьнее Немерла.
VD>1. Более общая реализация алгеброических типов.
что значет более общая? и за счет чего (во что они преобразовываются)?

VD>2. Не явные замыкания.
а в немерле разве явные? (в явных я так понимаю, нужно указывать, что захватывается? или как?)

E>Но позиция понятна -- ты считаешь, что каждый пользователь имеет право расширять язык так, как ему нужно.

а кто так не считает?

Здравствуйте, PhantomIvan, Вы писали:

E>>Но позиция понятна -- ты считаешь, что каждый пользователь имеет право расширять язык так, как ему нужно.

PI>а кто так не считает?

Я, например.
Со временем даже свободный синтаксис Ruby и Scala. Отсутствие обязательных скобок, к примеру, или запись вызова метода без . начинает напрягать при чтении кода. Скажем видишь в коде

x <

и гадаешь "шо це таке?"

Здравствуйте, Programmierer AG, Вы писали:

PA>FR wrote:
>> Ну у Окамла тоже есть проблемы. Тот же map нельзя реализовать с помощью обычной функции. А обобщеность дает не меньше пользы чем карринг.
PA>У Окамла масса проблем. Но что за проблема с map — не пойму .

Ну тут я похоже ошибся, ввело в заблуждение что нет встроенной функции map, а есть только List.map

PA>А у замыканий Питона по сравнению с Окамловскими есть недостаток -
PA>невозможность модификации переменной из объемлющей области видимости.

Не совсем понял, можно пример.

E>Так вот, наиболее горластые пропагандисты Nemerle явно относятся к слепо верующим.

давай уж поименно, а то я всех активных пользователей немерле могу пересчитать по пальцам
и кто здесь горлопанит, мне не понятно о ком ты, да еще во множественном числе...
кто во что верит, тоже вопрос большой, учитывая, что у каждого (я думаю) здесь опыт разработки ПО > 5 лет
если есть альтернатива немерле как универсальному средству написания ПО под дотнет — пожалуйста, рад бы услышать и перепрыгнуть
если не под дотнет — что дает такой скачок в никуда (или скажите куда), если дает те же возможности плюс нечто еще более аппетитное, то я бы перепрыгнул (почему бы нет, скажем, если скала была круче в 5 раз, может и на жава перешел бы)

E> И это вызывает раздражение. Ведь тот же Влад сам заявлял, что слиняет с Nemerle на что-нибудь более крутое, как только оно появится.

ну да, Влад не относится к "слепо верующим" — тогда кого ты имел в виду?

E> Между тем, многим, выбравшим Nemerle в качестве инструмента придется сидеть на нем достаточно долго.

для тех, кто сделал свой выбор осознанно — вряд ли, будет что-то лучшее — те, которые с немерле сейчас — перейдут (это, я так понимаю, люди умные и активные, сидеть сиднем просто так не будут)

E> Вспоминая COBOL можно предположить, что долго может растянуться на годы.

и наконец, дело немерле может банально "не выгореть" благодаря типичной инерции мышления, которую многие проявляют (оправдывая это опенсорсностью и чем угодно еще, но только не своей узколобостью)
сам язык (и интеграция к студии), уже можно использовать, но полную инструментальную поддержку (типа тулзы профайлинга, и прочего веб-аспнета, интеграции с разными фиговинами типа хибернейта) десять человек не осилят, а в будущем будут другие (нелибовые) фигни типа wpf, к которым немерле уже не получит интеграции, и получится кобол, только с той разницей, что никто так и не накодил на немерле, и не оценил его мощь — #####, сейчас комьюнити немерле как такового, не существует

так что кобола не получится, т.к. нечего поддерживать будет — никто не юзает language — значит language не существует
(подставьте вместо language любой инструмент)

E>>>Но позиция понятна -- ты считаешь, что каждый пользователь имеет право расширять язык так, как ему нужно.

PI>>а кто так не считает?

E>Я, например.
E>Со временем даже свободный синтаксис Ruby и Scala. Отсутствие обязательных скобок, к примеру, или запись вызова метода без . начинает напрягать при чтении кода. Скажем видишь в коде
E>

E>x <
E>

E>и гадаешь "шо це таке?"

тут дело такое — не хочешь — не ешь
а может ты просто не умеешь готовить?
в немерле ответ на "шо це таке" обычно получаешь при наведении на икс и получении хинта
если ты как п.м. не хочешь использования макросов в проекте, просто запрещаешь это политикой, вот и все
и для тебя как бы и не существует этой возможности

FR>>>Где эти остальные?
FR>>>Много людей здесь используют немерле как основной инструмент для работы?

AF>>Для работы его не используют по другим причинам. Поддержка IDE пока не очень стабильна, нет инструментов для рефакторинга и прочих приятных вещей. Но личность Влада уж точно не является одной из таких причин А вот в нерабочих условиях я думаю уже довольно многие пробовали с ним работать.

а я уже подсчитал, и думаю, не больше 30-50
"по-нормальному" — 10

FR>Тогда зачем ты предлагаешь мне его использовать для работы?
FR>А для нерабочих условий (есть и у меня такое хобби) уже образовалась очередь из языков которые было бы интересно посмотреть — поковырять, но времени не хватает а для вас похоже свет клином сошелся на одном языке.

"мы" вообще-то как минимум, 2-3 языка использовали профессионально, и ещё пяток "пробовали"
а некоторые из "нас" пяток профессионально и еще десяток — "так"

так что вряд-ли для "нас" свет клином где-то случайно сошелся

Здравствуйте, PhantomIvan, Вы писали:

E>>Так вот, наиболее горластые пропагандисты Nemerle явно относятся к слепо верующим.

PI>давай уж поименно, а то я всех активных пользователей немерле могу пересчитать по пальцам
PI>и кто здесь горлопанит, мне не понятно о ком ты, да еще во множественном числе...

Я в самом начале уже говорил и даже имена перечислял.

PI>если не под дотнет — что дает такой скачок в никуда (или скажите куда), если дает те же возможности плюс нечто еще более аппетитное, то я бы перепрыгнул (почему бы нет, скажем, если скала была круче в 5 раз, может и на жава перешел бы)

Советовать ничего не буду. У каждого свои задачи, свои условия, свои пристрастия.
О том, чем я пользовался, о том и рассказываю -- C++ и Ruby. Что хотел бы попробовать и пробую -- так же говорил -- D и Scala. Переход на D или Scala рассматривается не столько потому, что они круче чем C++, а по ряду других причин. О своем опыте рассказать могу, в принципе-то. А вот что-то советовать и абстракто что-то с чем-то сравнивать измеряя рост удавов в попугаях не буду.

И я считаю, что прирост производительности берется не из языка программирования, хотя здесь в это мало кто верит.

E>> И это вызывает раздражение. Ведь тот же Влад сам заявлял, что слиняет с Nemerle на что-нибудь более крутое, как только оно появится.

PI>ну да, Влад не относится к "слепо верующим" — тогда кого ты имел в виду?

Как раз Влад типичный "слепо верующий" об нем и речь.

E>> Между тем, многим, выбравшим Nemerle в качестве инструмента придется сидеть на нем достаточно долго.

PI>для тех, кто сделал свой выбор осознанно — вряд ли, будет что-то лучшее — те, которые с немерле сейчас — перейдут (это, я так понимаю, люди умные и активные, сидеть сиднем просто так не будут)

Угу-угу. Я, к примеру, занимаюсь сопровождением продуктов, которые стартовали еще в 2001-м/2002-м годах. А на местах моей предыдущей работы еще продолжают развивать начатые еще в 99-м и 2000-м году проекты. Практически на тех же технологиях. Так что самые умные берут новую технологию и линяют в другое место. А кто-то их наработки потом сопровождает. А политика "после нас хоть потоп", уж так получилось, не по мне.

Здравствуйте, PhantomIvan, Вы писали:

PI>тут дело такое — не хочешь — не ешь

Это как понимать?
Если мне достается на сопровождение так написанный код, я что должен делать?

PI>а может ты просто не умеешь готовить?

Конечно, здесь с тобой одни только ламеры общаются.

PI>в немерле ответ на "шо це таке" обычно получаешь при наведении на икс и получении хинта

Угу, в распечатке.
А попробуй ты с ходу сказать какой тип будет у переменной result:

#pragma indent
 
using System
using System.Console
using System.Math
 
def makeDistrib(trxCount : int, quantums : int)
    mutable r : list[int] = []
    mutable remainingTrx = trxCount
    mutable remainingQuantums = quantums
    foreach (_i in [1..quantums])
        r ::= Round((remainingTrx :> double) / remainingQuantums,
                MidpointRounding.AwayFromZero) :> int
        remainingTrx -= r.Head
        --remainingQuantums
    r.Rev
 
def result = makeDistrib(2, 6)
WriteLine($"$result")

не прибегая к помощи IDE.

FR wrote:
> Ну тут я похоже ошибся, ввело в заблуждение что нет встроенной функции map, а есть только List.map
List.map работает только для списков, она полиморфна относительно типа
элементов. Если ты имел в виду map для любых структур данных, то да,
такое в Окамле возможно только при помощи функторов, о чем я недавно
причитал

Автор: Programmierer AG
Дата: 20.11.06

.
Нет в мире совершенства. Питоновский map в этом отношении не идеален —
ему даешь множество или генератор, а он возвращает список, непорядок .
>
> PA>А у замыканий Питона по сравнению с Окамловскими есть недостаток -
> PA>невозможность модификации переменной из объемлющей области видимости.
> Не совсем понял, можно пример.

>>> x = 1
>>> def inner() : x += 1
...
>>> inner ()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<stdin>", line 1, in inner
UnboundLocalError: local variable 'x' referenced before assignment

Мне понравился ответ тов. Jacek Generowicz (начинается с "A long, long
time ago, in a Python far away, there were three namesapaces: local (to
a function), global and builtin."):
http://www.velocityreviews.com/forums/t333095-closures-pythonschemeruby.html
Вот что бывает, когда язык проектируют любители.

А вообще Питона я не знаю, может и наврал чего .

Здравствуйте, PhantomIvan, Вы писали:

FR>>Тогда зачем ты предлагаешь мне его использовать для работы?
FR>>А для нерабочих условий (есть и у меня такое хобби) уже образовалась очередь из языков которые было бы интересно посмотреть — поковырять, но времени не хватает а для вас похоже свет клином сошелся на одном языке.

PI>"мы" вообще-то как минимум, 2-3 языка использовали профессионально, и ещё пяток "пробовали"
PI>а некоторые из "нас" пяток профессионально и еще десяток — "так"

PI>так что вряд-ли для "нас" свет клином где-то случайно сошелся

Значит вы в это вас не входите

Здравствуйте, Programmierer AG, Вы писали:

PA>FR wrote:
>> Ну тут я похоже ошибся, ввело в заблуждение что нет встроенной функции map, а есть только List.map
PA>List.map работает только для списков, она полиморфна относительно типа
PA>элементов. Если ты имел в виду map для любых структур данных, то да,
PA>такое в Окамле возможно только при помощи функторов, о чем я недавно
PA>причитал

Автор: Programmierer AG
Дата: 20.11.06

.

Так интересно это значит не моя тупость мне помешала написать подобное когда я пару лет назад ковырял окамл

PA>Нет в мире совершенства. Питоновский map в этом отношении не идеален -
PA>ему даешь множество или генератор, а он возвращает список, непорядок .

Это да, но при желании можно и такую реализацию сделать, хотя подозреваю если постаратся и в окамле можно что-нибудь наколдовать

>>
>> PA>А у замыканий Питона по сравнению с Окамловскими есть недостаток -
>> PA>невозможность модификации переменной из объемлющей области видимости.
>> Не совсем понял, можно пример.

....

PA>Вот что бывает, когда язык проектируют любители.

Это скоропалительный вывод

PA>А вообще Питона я не знаю, может и наврал чего .

угу:

In [7]: x = 1

In [8]: def inner():
   ...:     global x
   ...:     x += 1
   ...:
   ...:

In [9]: inner()

In [10]: x
Out[10]: 2

PI>>тут дело такое — не хочешь — не ешь

E>Это как понимать?

это такой анекдот старый, про вождя, которого готовил индеец, а ковбой сначала похавал, а потом только узнал

E>Если мне достается на сопровождение так написанный код, я что должен делать?

тут ты загнался, признай — потому что на сопровождение приходит сколь угодно запутанный код на любом языке (хоть с++, хоть васик)

PI>>а может ты просто не умеешь готовить?

это еще один анекдот (вам не нравятся дети (подставить другое)? может быть вы их не умеете готовить?)

E>Конечно, здесь с тобой одни только ламеры общаются.

спакуха, моя твоя уважай
но моя не понимать всей той экспрессии, с которой ты изъясняешься

PI>>в немерле ответ на "шо це таке" обычно получаешь при наведении на икс и получении хинта

E>Угу, в распечатке.
никогда не печатал проги... хотя попробую, может это прикольно...

E>А попробуй ты с ходу сказать какой тип будет у переменной result:
E>

E>#pragma indent
 
E>using System
E>using System.Console
E>using System.Math
 
E>def makeDistrib(trxCount : int, quantums : int)
E>    mutable r : list[int] = []
E>    mutable remainingTrx = trxCount
E>    mutable remainingQuantums = quantums
E>    foreach (_i in [1..quantums])
E>        r ::= Round((remainingTrx :> double) / remainingQuantums,
E>                MidpointRounding.AwayFromZero) :> int
E>        remainingTrx -= r.Head
E>        --remainingQuantums
E>    r.Rev
 
E>def result = makeDistrib(2, 6)
E>WriteLine($"$result")
E>

E>не прибегая к помощи IDE.

честно говоря, засек время — 10 секунд, взгляд прыгает по следующим строчкам:

E>def result = makeDistrib(2, 6)

E>def makeDistrib(trxCount : int, quantums : int)

E>    r.Rev

E>    mutable r : list[int] = []

и сразу готов был ответ —

list[int]

но потом еще минут размышлений "а где прикол", и стало ясно, что ты забыл здесь скобки:

E>    r.Rev

еще 5 минут жестоких размышлений:
-extension-методы кажется определять свойства не позволяют (только методы)
-#pragma indent позволяет опускать пустые скобки: (), но тогда ответ тот же (особо не юзаю этот режим, не знаю точно)
-макросом ты хакнул лексер, и теперь Rev у тебя означает все-что угодно, но только не Rev
-...

сдаюсь в общем, что там в результате?

Здравствуйте, eao197, Вы писали:

E>Угу, в распечатке.
E>А попробуй ты с ходу сказать какой тип будет у переменной result:
E>

E>#pragma indent
 
E>using System
E>using System.Console
E>using System.Math
 
E>def makeDistrib(trxCount : int, quantums : int)
E>    mutable r : list[int] = []
E>    mutable remainingTrx = trxCount
E>    mutable remainingQuantums = quantums
E>    foreach (_i in [1..quantums])
E>        r ::= Round((remainingTrx :> double) / remainingQuantums,
E>                MidpointRounding.AwayFromZero) :> int
E>        remainingTrx -= r.Head
E>        --remainingQuantums
E>    r.Rev
 
E>def result = makeDistrib(2, 6)
E>WriteLine($"$result")
E>

E>не прибегая к помощи IDE.

Без помощи IDE только по этому коду могу предоположить, что list[int], правильно?


ЗЫ: немерле вообще незнаю, даже с синтаксисом незнаком