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

AV>Клиент хочет, платит за это. У него обльшой зоопарк платформ. И менять их слишком дорого пока. Дешевле оказалось писать под кучу платформ.

...

AV>Да нету никаких проблем с С++. Надо только знать что можно, а что нельзя использовать. Это не занимает много времени (по факту подобные проблемы были только первые 3-5 недель). Джава не подошла по нескольким причинам.


Ваш клиент неимоверно богат, раз ему не жаль денег на разработку сервера приложений на С++ и жаль денег чтобы поставить на машинах Линукс или Виндовс.

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

L>Да ладно, это же трюк. Приходится заводить на каждое имя фунции по классу, и на каждую сигнатуру по инстансу.
L>В "чистом" виде перегрузки на самом деле нет

L>

L>openConnection :: String -> String -> String -> Connection
L>openConnection url username password = ...

L>openConnection :: String -> [(String, String)] -> Connection
L>openConnection url properties = ...
L>

L>к сожалению, не напишешь.

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

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

Вместо этого мы имеем красивый и очень мощный механизм typeclasses. Можно написать, например, буквально в 5 строчках функцию, принимающую любое количество параметров любого типа.

Hi VladD2

AV>>Клиент хочет, платит за это. У него обльшой зоопарк платформ. И менять их слишком дорого пока. Дешевле оказалось писать под кучу платформ.

V>...

AV>>Да нету никаких проблем с С++. Надо только знать что можно, а что нельзя использовать. Это не занимает много времени (по факту подобные проблемы были только первые 3-5 недель). Джава не подошла по нескольким причинам.


V>Ваш клиент неимоверно богат, раз ему не жаль денег на разработку сервера приложений на С++ и жаль денег чтобы поставить на машинах Линукс или Виндовс.

Бедный, богатый, какая разница в данном случае. Тут считать надо. Насчет стоимости ОС можно согласиться. А вот как насчет переучивания работников на какой-то язык? И с учетом того, что работники время от времени меняются? Может лучше предоставить возможность им использовать то, что знают?

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

Давай опустим домыслы. На анализ существующих вариантов заказчиком было потрачено очень много времени и денег. И раз они пришли к такому мнению, значит оно им дешевле.

Кстати, ты так и не ответил, почему в моей ситуации изучение Nemerle предпочтительнее изучения OCaml?

--
С Уважением

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

A>В контексте глобального вывода типов перегрузка "в чистом виде" невозможна в принципе.

Это не соотвествует действительности. Сложность алгоритма получается высокой. Но на практике все будет работать. Собствнно это как раз описано в дисере Москаля на www.nemerle.org

A>Вместо этого мы имеем красивый и очень мощный механизм typeclasses. Можно написать, например, буквально в 5 строчках функцию, принимающую любое количество параметров любого типа.

Назвать красивым внеполовое извращение ссылку на которое ты привел я бы не отчаялся.

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

Ну, и надо понимать, что в этом мире большинство API в С++-подобных ЯП где перегрузка и привденеие типов исходно заложены в дизайн. А стало быть Хаскель в этом мире будет всегда чувтствовать себя неуютно. Его действительно неординарная систама классов типов не вписывается в систему типов ООП-языков доминирующих на сегодня.

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

AV>Бедный, богатый, какая разница в данном случае. Тут считать надо. Насчет стоимости ОС можно согласиться. А вот как насчет переучивания работников на какой-то язык? И с учетом того, что работники время от времени меняются? Может лучше предоставить возможность им использовать то, что знают?

Да это аргумент. Но тогда надо на Яве писать. Ява програмистов много и они относительно дешевы. Плюс полная переносимость и надежность. Но С++ для сервера приложений — это точно перебор. Это себе только топ-компании вроде IBM/MS безболезненно могут позволить.

AV>Давай опустим домыслы. На анализ существующих вариантов заказчиком было потрачено очень много времени и денег. И раз они пришли к такому мнению, значит оно им дешевле.

Решать конечно им. Но я бы назвал такое выбор очень рискованным.

AV>Кстати, ты так и не ответил, почему в моей ситуации изучение Nemerle предпочтительнее изучения OCaml?

В твоей ситуации тебе надо Яву учить. С точки же зрения просто развития как программиста Nemerle — это OCaml++. Потому вообще довольно бессмысленно учить OCaml если можно выучить Nemerle. Это и проще и позновательнее. Причем после Nemerle выучить OCaml уже довольно просто, так как остается только въехать в его кудрявые конструкции. Семантика же очень близка.

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

A>>В контексте глобального вывода типов перегрузка "в чистом виде" невозможна в принципе.

VD>Это не соотвествует действительности. Сложность алгоритма получается высокой. Но на практике все будет работать. Собствнно это как раз описано в дисере Москаля на www.nemerle.org

Вот единственная диссертация Москаля, которую мне удалось обнаружить на указанном сайте. Это не имеет ничего общего с глобальным выводом типов.

Простейший пример:

foo :: String -> String
foo _ = "foo"

foo :: String -> Int
foo _ = 666

bar :: String -> String
bar _ = "bar"

bar :: Int -> String
bar _ = "666"

foobar = bar . foo

Как прикажете посчитать, например, foobar "Fucking overloading!" ???

Иногда лучше жевать.

Бам! Извините, ступил.

Перегрузка по типу возврата не работает вообще никогда. И это не зависит даже от типа вывода.

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

A>В контексте глобального вывода типов перегрузка "в чистом виде" невозможна в принципе.

Ну, так а я о чём!

Насчёт остального — от вывода типов отказываться не собираюсь В общем то, спорить не о чем, я всего лишь хотел сказать, что (удобной) перегрузки в Хаскеле нет. А с чем это связано я представляю.

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

A>Перегрузка по типу возврата не работает вообще никогда. И это не зависит даже от типа вывода.
Как это не работает? Type classes вроде это позволяют?

Навскидку несколько примеров: mzero, fromInteger, fromIntegral, readIO, readLn (read, в конце концов) — все перегружены по типу возврата. Или что-то другое имелось в виду?

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

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

A>>Перегрузка по типу возврата не работает вообще никогда. И это не зависит даже от типа вывода.
PM>Как это не работает? Type classes вроде это позволяют?

type classes конечно позволяют, я имел в виду "наивную перегрузку" в том смысле как писал lomeo

Я тут привел не совсем корректный пример — перегрузки по типу возврата, который без typclasses не работает никогда.

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

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

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

A>>В контексте глобального вывода типов перегрузка "в чистом виде" невозможна в принципе.

L>Ну, так а я о чём!

L>Насчёт остального — от вывода типов отказываться не собираюсь В общем то, спорить не о чем, я всего лишь хотел сказать, что (удобной) перегрузки в Хаскеле нет. А с чем это связано я представляю.

Я выше уже написал. Перегрузка несовместима с глобальным выводом по определению, т.е. тривиально.

Hi VladD2

AV>>Бедный, богатый, какая разница в данном случае. Тут считать надо. Насчет стоимости ОС можно согласиться. А вот как насчет переучивания работников на какой-то язык? И с учетом того, что работники время от времени меняются? Может лучше предоставить возможность им использовать то, что знают?

V>Да это аргумент. Но тогда надо на Яве писать. Ява програмистов много и они относительно дешевы.

Нда. А мужики-то о java и не знали. Не так уж много у них спецов по java есть в штате. Что делать с остальными? Переучивать? Увольнять и набирать других?

V>Плюс полная переносимость и надежность.

Это далеко не самые определяющие факторы были. Да и насчет полной переносимости и надежности тоже преувеличение. Да, по сравнению с C/C++ там сложнее что-то перемудрить, но хватает мест где можно наворотить.

AV>>Давай опустим домыслы. На анализ существующих вариантов заказчиком было потрачено очень много времени и денег. И раз они пришли к такому мнению, значит оно им дешевле.

V>Решать конечно им. Но я бы назвал такое выбор очень рискованным.

Риск оправдался. Комплекс уже работает. Тем более, что если отсечь откровенно опасные моменты, то и на C++ можно относительно безопасно писать.

AV>>Кстати, ты так и не ответил, почему в моей ситуации изучение Nemerle предпочтительнее изучения OCaml?

V>В твоей ситуации тебе надо Яву учить.

Вот уж что-что, а Java учить не надо. Работал я с ней. Ну не лежит душа у меня к ней.

V>С точки же зрения просто развития как программиста Nemerle — это OCaml++. Потому вообще довольно бессмысленно учить OCaml если можно выучить Nemerle. Это и проще и позновательнее. Причем после Nemerle выучить OCaml уже довольно просто, так как остается только въехать в его кудрявые конструкции. Семантика же очень близка.

Ну выучу я Nemerle. И где мне его применить сейчас? Ну нету у меня пока задач под него. И не предвидиться.
Далее, выучил я немерле. А мне надо OCaml сейчас для работы. Дальше сел учить OCaml. Тебе не кажеться, что это удаление гланд паяльной лампой через одно отверстие?
Кстати, времени свободного не так уж и много есть. И я предпочитаю его тратить на жену, дочь и друзей. В крайнем случае, если на меня нашла блажь и мне охота что-то изучить, то я предпочитаю изучать то, что я так или иначе могу применить. Даже если не сейчас, то в обозримом будущем. А не через N лет.

Как видишь, Nemerle ничего не даст мне в данный момент. В отличии от OCaml.

--
С Уважением

A>Я выше уже написал. Перегрузка несовместима с глобальным выводом по определению, т.е. тривиально.

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

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

A>Как прикажете посчитать, например, foobar "Fucking overloading!" ???
Да легко. В Немерловском выводителе поддержка перегрузки по результату есть, правда включена она только для операторов преобразования типов и generic методов. Но я ради интереса включал поддержку для любых методов. Вывод типов просто откладывается до того момента, когда точно известен необходимый нам тип.

Когда мы считаем foobar("a***n — дурилка картонная!"), то мы же не просто выбрасываем это значение, так? А например делаем вот что: (foobar("a***n — дурилка картонная")-3). Из этого компилятор делает вывод, что тип foobar должен быть string->int.

A>Иногда лучше жевать.
Иногда лучше не жевать.

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

VK>Когда мы считаем foobar("a***n — дурилка картонная!"), то мы же не просто выбрасываем это значение, так? А например делаем вот что: (foobar("a***n — дурилка картонная")-3). Из этого компилятор делает вывод, что тип foobar должен быть string->int.

А если мы делаем print(foobar("Громозека — грубиян и невоспитанный тип"))?

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

A>Иногда лучше жевать.

Согласен. Особенно когда тупишь. А вообще, почитай внимательнее. Там все описано. Единственная проблема — это сложность алгоритма.

Ответ на вопрос см. тут.

Автор: Vermicious Knid
Дата: 02.03.07

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

AV>Нда. А мужики-то о java и не знали. Не так уж много у них спецов по java есть в штате. Что делать с остальными? Переучивать? Увольнять и набирать других?

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

AV>Риск оправдался.

Это будет видно когда проект закончится успехом.

Что до отсуствия у тебя задач... У тебя не задачи отсуствуют. У тебя решения заранее предопределены. Тебе их даже обдумывать не надо. Так что ОКамл тебе тоже будет бесполезен. Хотя... возможно это будет началом перестройки мышления.

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

A>Я выше уже написал. Перегрузка несовместима с глобальным выводом по определению, т.е. тривиально.

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

Самое смешное, что лично я хотел бы чтобы ты был прав, так как не вижу смысла в выводе типов выше тел методов, но вижу приемущества от такого ограничения.

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

VK>Когда мы считаем foobar("a***n — дурилка картонная!"), то мы же не просто выбрасываем это значение, так? А например делаем вот что: (foobar("a***n — дурилка картонная")-3). Из этого компилятор делает вывод, что тип foobar должен быть string->int.

Какая-то ахинея. Вы уж, если пытаетесь меня критиковать, хоть почитайте. Я же сам потом написал, что там ничего не помогает!

Например, явное указание foobar :: String -> String.

А Вы пытаетесь из строки вычесть целое, потом говорите, что компилятор отсюда выведет string->int, что это вообще за бред?

A>>Иногда лучше жевать.
VK>Иногда лучше не жевать.

Уж лучше пожуйте.