Hi IT

AV>>P.S. Правда, слишком рьяно идет здесь реклама Nemerle. Даже отбивает желание смотреть на это.

IT>То что мы наблюдаем, это не ръяная реклама, а просто восторг по поводу "Бритни"

Возможно это связано с личным восприятием каждого участника форума. Но у меня большинство моментой касающихся Nemerle на данном форуме ассоциируется именно с рекламой.


AV>>Но я сволочь любознательная — при возможности попробую посмотреть.

IT>Посмотри.

Посмотреть-то посмотрю как-нибудь. Но к моим текущим задачам его никак не приложить будет. Поэтому только в свободное время (которого катастрофически не хватает). К моим текущим задачам скорее приложим OCaml

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

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

VD>>По сути же... проблема в том, что классы в разных сборках должны быть совместимы.

IT>Я понимаю проблему. Вопрос, проблема ли это и нужно ли её решать.

В текущем варианте имеется просто недоделанность приводящая к тому, что анонимные типы мало на что годны и применяются в основном только для LINQ-запросов.

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

Правильным решением было бы внести измеения в рантайм. Там дело вто на день.

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

AV>Посмотреть-то посмотрю как-нибудь. Но к моим текущим задачам его никак не приложить будет. Поэтому только в свободное время (которого катастрофически не хватает). К моим текущим задачам скорее приложим OCaml

Ты бы все же сначала поглядел о чем рассуждаешь. А то забавно получается. Nemerle по сути клон O'Caml с С-подобным синтаксисом, но O'Caml тебе подходит, а Nemerle нет. Парадокс одноако.

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

VD>Это относится к системе типов Хаскеля. Точнее примитивности системы Хинли-Миллера. Она конечно позволяет довольно ээфективно выводить типы, но страдает достадными ограничениями вроде невозможности перегрузки функций по имени. Например, мы не можем определить свойство (метод, поле, функцию) "x" у типа Point и скажем у типа Point3D. Разруливание на уровне модулей не катит, так как оба типа данных могут понадобиться в одном коде. Посему фукнции начинают вбирать в себя префиксы вроде pointX и point3dX. Сто лично мне очень не наравится. И вообще, я привык к "излишествам" рожденным С++: перегрузка, неявные приведения типов, объекты...

Вы с какой Луны свалились? Сегодня говорить о системе Хиндли-Милнера в применении к Хаскеллу — все равно, что уподоблять, к примеру, Лаурин-Клемент 1904 года Макларену MP4-21.

В GHC — а это, фактически, референсный компилятор Хаскелла — давно уже есть:
1. Multiparameter typeclasses + functional dependencies
2. GADTs

Недавно GHC был переведен на system Fc, что позволило реализовать еще и type-indexed data types и устаканить все сложные взаимодействия между упомянутыми возможностями.

VD>Ну, мы уже наблюдали как Хаскель сливает Немерлу .

Немерл ... мухаха. Детский лепет.

Hi VladD2

AV>>Посмотреть-то посмотрю как-нибудь. Но к моим текущим задачам его никак не приложить будет. Поэтому только в свободное время (которого катастрофически не хватает). К моим текущим задачам скорее приложим OCaml

V>Ты бы все же сначала поглядел о чем рассуждаешь. А то забавно получается. Nemerle по сути клон O'Caml с С-подобным синтаксисом, но O'Caml тебе подходит, а Nemerle нет. Парадокс одноако.

Облом подкрался незаметно. Ты пытаешься судить о моих потребностях не зная задач, которые мне необходимо решать сейчас и в ближайшее будущее. Дам краткое описание проекта, а ты скажи мне каким боком мне сюда прикрутить Nemerle. ОК?

Краткая постановка задачи: Необходимо разработать Application Server. Все это должно работать на кучу платформ (на данный момент 5. Винда считается одной платформой). Приложения, которые крутяться на нем должны собираться из разных компонентов (то есть фактически надо реализовать на свой лад COM). Компонеты должны могут писаться на разных языках (в списке есть OCaml, но нет Nemerle). Там еще куча ограничений. Но они тебе и большинству будут не интересны, да и NDA есть.

Так какой язык стоит мне смотреть в первую очередь учитывая периодический цейтнот?

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

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

A>Вы с какой Луны свалились? Сегодня говорить о системе Хиндли-Милнера в применении к Хаскеллу — все равно, что уподоблять, к примеру, Лаурин-Клемент 1904 года Макларену MP4-21.
Только разница в том, что по твоей аналогии Макларен MP4-21 будет еле ползать и будет перегружен бесполезными для болида f1 функциями — 7 сиденьями, возможность использования в качестве кареты скорой помощи и интегрированную систему противоракетной обороны. Но при этом все равно обладать теми самыми ограничениями, о которых говорит VladD2.

A>Недавно GHC был переведен на system Fc, что позволило реализовать еще и type-indexed data types и устаканить все сложные взаимодействия между упомянутыми возможностями.
По-моему это просто небольшие, инкрементальные изменения. Причем непонятно чего и для кого. Я не так давно смотрел данные опросов — пользователям GHC это все просто не нужно. То что им нужно, разработчикам GHC улучшать не особо и интересно — они же занимаются чистой наукой.

VD>>Ну, мы уже наблюдали как Хаскель сливает Немерлу .
A>Немерл ... мухаха. Детский лепет.

“First they ignore you, then they laugh at you, then they fight you, then you win.”

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

VK> Я не так давно смотрел данные опросов — пользователям GHC это все просто не нужно. То что им нужно, разработчикам GHC улучшать не особо и интересно — они же занимаются чистой наукой.
В потверждение моих слов — вот оно. Небольшой отрывок:

Second, here's a super-quick summary of what we've learned:

— The #1 complaint was the compilation speed and memory usage of GHC.

— Next most unpopular was performance and size of the generated code.

— The most-requested feature, after performance improvements, is some kind of debugger.

— Portability and the difficulty of compiling GHC was raised a lot.

— API and feature changes breaking code between releases was also a common gripe.

— Many people mentioned the quality of error messages as something that could be improved.

— Many people want improvements to documentation, especially library docs.

— Lots of requests for an IDE and better GUI support.

— There is some concern over the complexity of GHC affecting its maintainability and portability,
and how difficult it is to contribute.

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

VD>>>По сути же... проблема в том, что классы в разных сборках должны быть совместимы.
IT>>Я понимаю проблему. Вопрос, проблема ли это и нужно ли её решать.
VD>В текущем варианте имеется просто недоделанность приводящая к тому, что анонимные типы мало на что годны и применяются в основном только для LINQ-запросов.

Мой вопрос был про нужность обсуждаемой фичи. Скажем так, такая фича — must have, очень полезная фича, nice to have, а шо это такое. Мой вопрос, если это последние два варианта, то надо ли было вообще затеивать это всё.

VD>Если поступить как предлагаешь ты, то будет уже явный косякт который уже потом будет невозможно исправить не внося ломающие изменения.

Я предлагаю не явный косяк, я предлагаю точку, от которой можно начать обсуждение. Уверен, что в MS этот вопрос обсуждался и эту точку тоже проходили, но вот чем всё законичилось было бы интересно выведать у AVK, прикрывающегося NDA.

VD>Правильным решением было бы внести измеения в рантайм. Там дело вто на день.

Опять же вопрос. Стоит ли эта фича того, что бы из-за неё менять рантайм?

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

IT>Опять же вопрос. Стоит ли эта фича того, что бы из-за неё менять рантайм?

Что такое кортежи ты знаешь. Анонимные типы в Шарпе были бы их аналогами если бы были реализованы полноценно. Ну, а стоит ли их вводить ты сам можешь сказать. Мое мнение — стоит. Правда я лично предпочел Немерловый варинат. Он может и имеет гипотетическую проблему — значения можно перепутать, так как они позиционные, но на практике я таких проблем не видел. Дополнительные же выгоды очевидны: совместимость со список параметров, легная копоциция, декомпозиция (патетрн-мтачинг) и т.п. Правда вряд ли все это будет в Шарпе. Плюс, похоже, в Шарпе их хотя сделать изменяемыми, а это убивает возможность использовать их как замену вэлью-типам. Помнишь, как ты заменил одну переменуню на кортеж и все продолженло работать далее? Вот тут может быть облом.

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

V>>Ты бы все же сначала поглядел о чем рассуждаешь. А то забавно получается. Nemerle по сути клон O'Caml с С-подобным синтаксисом, но O'Caml тебе подходит, а Nemerle нет. Парадокс одноако.

AV>Облом подкрался незаметно. Ты пытаешься судить о моих потребностях не зная задач, которые мне необходимо решать сейчас и в ближайшее будущее.

Я сужу не о твоем проекте, а алогизмах в твоих суждениях.

AV> Дам краткое описание проекта, а ты скажи мне каким боком мне сюда прикрутить Nemerle. ОК?

Не вопрос.

AV>Краткая постановка задачи: Необходимо разработать Application Server. Все это должно работать на кучу платформ (на данный момент 5. Винда считается одной платформой).

На остальных Моно работает?

AV> Приложения, которые крутяться на нем должны собираться из разных компонентов (то есть фактически надо реализовать на свой лад COM).

Ага. Если пользоваться С++, то еще не то надо реалзовывать. Немерле же бегает на базе CLI которое проектировалось как COM 2.0.

AV> Компонеты должны могут писаться на разных языках (в списке есть OCaml, но нет Nemerle).

CLI бегает море языков. В том числе и очень близкий к OCaml язык F# (клон с некоторыми расширениями под дотнет).

AV>Там еще куча ограничений. Но они тебе и большинству будут не интересны, да и NDA есть.

Значит их опускаем.

AV>Так какой язык стоит мне смотреть в первую очередь учитывая периодический цейтнот?

Зависит от ответа на вопрос "Поддерживается ли Моно на остальных четрых платформах?". Если ответ — да, то даже думать не чего. Немерле однозначно лучший выбор. Проблемы будут искючительно организационного характера (нужно учить людей программировать на нем, и учить дотенту).

Единственное что я тебе точно могу скзать — это то, что С++ это неимоврено плохой вобор для вашего проекта. И того кто принял такое решение надо банально гнать с работы.
Для таких проектов выбор может идти между дотнетом и Явой (как технологии, а не как языка, Ява тоже поддерживает массу языков).

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

Что касается O'Caml... Он практически не имеет динамических возможностей. Так что поддержка компонентношго подхода на нем выльется в сущий ад. В этом языке даже повышающее приведение типов отсуствует так как оно может привести к исключению во время исполнения, а в дизайн языка пытались заложить чтобы их не было.

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

VK>Но при этом все равно обладать теми самыми ограничениями, о которых говорит VladD2.
Какими, черт подери, ограничаниями? Написано же — typeclasses. В том виде, как они поддерживаются в GHC (multiparameter typeclasses + fundeps), они не просто обеспечивают перегрузку, а вообще позволяют программировать внутри системы типов.

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

A>Вы с какой Луны свалились? Сегодня говорить о системе Хиндли-Милнера в применении к Хаскеллу — все равно, что уподоблять, к примеру, Лаурин-Клемент 1904 года Макларену MP4-21.

Это пустой треп. Факт остается файктом. Хаскелевская система типов основана на системе типов Хиндли-Миллера и переняла у нее все ее недостатки. То что она была расширена — это уже к делу не отностися.

A>В GHC — а это, фактически, референсный компилятор Хаскелла — давно уже есть:
A>1. Multiparameter typeclasses + functional dependencies
A>2. GADTs

Какой это отношение имеет к тому о чем говорю я?
Сие замечание является банальной попыткой докопаться до слов.

A>Недавно GHC был переведен на system Fc, что позволило реализовать еще и type-indexed data types и устаканить все сложные взаимодействия между упомянутыми возможностями.

Да хоть колеса от карьерного самосвала. Такиех вещей как перегрузка фукнций, неявное привдение типов система типов Хаскеля не позволяла и никогда не будет позволят.

VD>>Ну, мы уже наблюдали как Хаскель сливает Немерлу .

A>Немерл ... мухаха. Детский лепет.

Да хоть горшком назови. Всем плевать. Хаскель красивая игрушка не пригодная для реальной жизни. А на Немрле или на его аналоге будут тонны кода в ближайшем будущем, и получать от этого огромные приемущества. Так что свои безасновательные можешь оставить при себе. Они никого не колышат.

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

VK>>Но при этом все равно обладать теми самыми ограничениями, о которых говорит VladD2.
A>Какими, черт подери, ограничаниями? Написано же — typeclasses. В том виде, как они поддерживаются в GHC (multiparameter typeclasses + fundeps), они не просто обеспечивают перегрузку, а вообще позволяют программировать внутри системы типов.

Программировать внтури системы типов позволяет и С++. Достоинством только это не является. Скоре недостатком.

Базворды же вроде "multiparameter typeclasses + fundeps" мало чего говорят окружающим.
Возможно конечно, что те описания Хаскеля которые я читал сильно устарели или попросту врут, но в них четко описывалось, что перегризить функцию по количеству параметров в Хаскеле невозможно. И приведения типов могут быть только явные. Если это не так, то продемонстрируй обратное. И по возможность без базвородов, а на практических примерах и доходчиво.

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

VD>Это пустой треп. Факт остается файктом. Хаскелевская система типов основана на системе типов Хиндли-Миллера и переняла у нее все ее недостатки. То что она была расширена — это уже к делу не отностися.

VD>Да хоть колеса от карьерного самосвала. Такиех вещей как перегрузка фукнций, неявное привдение типов система типов Хаскеля не позволяла и никогда не будет позволят.

Загляните, чтоль, сюда. Когда настанет просветление, можно будет продолжить.

Hi VladD2

V>>>Ты бы все же сначала поглядел о чем рассуждаешь. А то забавно получается. Nemerle по сути клон O'Caml с С-подобным синтаксисом, но O'Caml тебе подходит, а Nemerle нет. Парадокс одноако.

AV>>Облом подкрался незаметно. Ты пытаешься судить о моих потребностях не зная задач, которые мне необходимо решать сейчас и в ближайшее будущее.

V>Я сужу не о твоем проекте, а алогизмах в твоих суждениях.

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

AV>>Краткая постановка задачи: Необходимо разработать Application Server. Все это должно работать на кучу платформ (на данный момент 5. Винда считается одной платформой).

V>На остальных Моно работает?

Обломись. Как минимум на HP-UX не работает. Да и AIX маячит в дальней перспективе.
Далее, в списке языков есть Java. Как ее прикрутить к Mono? Да и рассчитывать на Mono в 2004 году странно было бы.
Список языков постоянно расширяется. Поэтому закладываться на .NET опять же нельзя.

Как видишь все дальнейшие твои размышления обламываются хотя бы тем, что даже Mono не работает на всех нужных платформах. Не говоря о куче других ограничений. Неужели ты думаешь, что код начали писать сразу без анализа существующих вариантов?

Поэтому получается, что мне OCaml на данный момент гораздо нужнее чем Nemerle.

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

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

A>Загляните, чтоль, сюда. Когда настанет просветление, можно будет продолжить.

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

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

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

к сожалению, не напишешь. А писать для каждого такого случая

type Properties = [(String, String)]

class OpenConnection a r | r -> a where
    openConnection :: String -> a -> r

instance OpenConnection Properties Connection where
    openConnection url props = ...

instance OpenConnection String (String -> Connection) where
    openConnection url username password = ...

несколько неестественно.

Надеюсь, что я что то пропустил.

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

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

Я предлагаю отделить ветку и перенести в rsdn.decl. Многим будет интересно, а здесь тема затеряется в бессмысленном флейме.

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

AV>Ты судишь об аллогизмах в моих суждения не зная чем эти суждения вызваны.

Причина алогизмов не имеет значения. Важен факт их наличия.

AV>Обломись. Как минимум на HP-UX не работает. Да и AIX маячит в дальней перспективе.

Забавный у вас выбор платформ.
С ним и С++-то проблематично убдет перенсти. Так что Ява становится самым разумным решением.

AV>Далее, в списке языков есть Java. Как ее прикрутить к Mono? Да и рассчитывать на Mono в 2004 году странно было бы.

А можно узнать как вы собираетесь к С++-ному коду Яву подключать?
Вообще, у вас забавнишие требования.

AV>Список языков постоянно расширяется. Поэтому закладываться на .NET опять же нельзя.

А что за странная такая задача? Зачем серверу приложений поддерживать постоянно расширяемый список языков и соврешенно эксзотические платформы?

AV>Как видишь все дальнейшие твои размышления обламываются хотя бы тем, что даже Mono не работает на всех нужных платформах. Не говоря о куче других ограничений. Неужели ты думаешь, что код начали писать сразу без анализа существующих вариантов?

Я вижу, что у вас очень странный проект.

AV>Поэтому получается, что мне OCaml на данный момент гораздо нужнее чем Nemerle.

O'Caml для системы требующей интероперабельности с Явой — это просто супер. Что-то мне подсказвает, что проект заранее провальный. Ну, да дерзайте.

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

A>Загляните, чтоль, сюда. Когда настанет просветление, можно будет продолжить.

Хм. Красивое извращение. Если я правильно понял, то ребята выходят не мытьем, так кактаньем. Они порождают для всех типов которыми нужно "перегрузить" фукнцию отдельный класс-типа и создают воплощения. В итоге получается, что мы имеем несколько типо объявленных в класс и метод оперирующий с этим классом. Так?
Вот только при этом мы имеем опять же не перегрзуку, а один метод с истенным полиморфизом.
Классы типов конечно круты, но сути дела они не меняют.

Так что чудес небывает. Если бы оговоренных мной ограничений не было, то Хаскелевские компиляторы дохли бы на средних проектах. У Nemerle та же проблема. Допустимость перегрузки и приведений типов накладывает ограничения на синтаксис (нельзя описывать паттерн-матчинг на уровне функций) и влияет на производительность. По сему вывод типов допускается только логально. Иначе кубический алгоритм повесит любой современный компьютер.

Hi VladD2

AV>>Ты судишь об аллогизмах в моих суждения не зная чем эти суждения вызваны.

V>Причина алогизмов не имеет значения. Важен факт их наличия.

Имеет значение. Еще какое. В одной ситуации что-то выглядит абсурдом, в другой ситуации может быть оправданным. В моей ситуации изучение OCaml будет полезным, а вот Nemerle — нет. Где аллогизм здесь?

AV>>Обломись. Как минимум на HP-UX не работает. Да и AIX маячит в дальней перспективе.

V>Забавный у вас выбор платформ.

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

V>С ним и С++-то проблематично убдет перенсти. Так что Ява становится самым разумным решением.

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

AV>>Далее, в списке языков есть Java. Как ее прикрутить к Mono? Да и рассчитывать на Mono в 2004 году странно было бы.

V>А можно узнать как вы собираетесь к С++-ному коду Яву подключать?

А что поднять JVM в своей программе большая проблема? А наши программеры не знали об этом.

V>Вообще, у вас забавнишие требования.

Нормальные требования. Что тебя так сильно удивляет?

AV>>Список языков постоянно расширяется. Поэтому закладываться на .NET опять же нельзя.

V>А что за странная такая задача? Зачем серверу приложений поддерживать постоянно расширяемый список языков и соврешенно эксзотические платформы?

Там не только сервер приложений, там еще и своя реализация аналога COM/DCOM. Об этом я уже писал в самом начале. Вот для этого и надо поддержка разных языков. Чтобы можно было писать компоненты на разных языках.

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

AV>>Как видишь все дальнейшие твои размышления обламываются хотя бы тем, что даже Mono не работает на всех нужных платформах. Не говоря о куче других ограничений. Неужели ты думаешь, что код начали писать сразу без анализа существующих вариантов?

V>Я вижу, что у вас очень странный проект.

Чем же он такой странный? Да, не такой как подавляющее кол-во проектов, в нем не надо дергать БД, рисовать формочки. А в остальном ничего странного. Тебе же не кажеться, например, Mono странным проектом?

AV>>Поэтому получается, что мне OCaml на данный момент гораздо нужнее чем Nemerle.

V>O'Caml для системы требующей интероперабельности с Явой — это просто супер. Что-то мне подсказвает, что проект заранее провальный. Ну, да дерзайте.

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

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