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

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

WF>Если под "боксингом" ты имеешь ввиду полиморфизм (т.е когда в массиве хранится некий Object или т.н "Top"), то ситуация такая. (далее идут мои, возможно ошибочные, размышления). Вообще говоря, можно ввести тип Top, однако в силу статичности O`Caml его смысл несколько теряется (т.к ты все равно с этим типом потом ничего осмысленного не сделаешь).

В Немерле таких проблем нет. Вся динамическая поддержка дотнета в твоем распоряжении.

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

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

VD>Думаю твой пример на этом:
AVC>>Вот еще один пример "из жизни" (я его, конечно, схематизировал), связанный с этой стороной Си++.
VD>можно было бы и закончить.

VD>К тому же ты сам усугубил свою проблему создав неявное приведение к bool.

Я имел в виду:
Вот еще один пример "из жизни" (я его, конечно, схематизировал), связанный с этой стороной Си++.
Приведенный пример связан с моделированием FPU другого процессора.
Код не мой, но ведь часто так и пишут на Си++.
Меня удивило только "равнодушие" компилятора.
Раз такая тема поднята применительно к Nemerle, IMHO, есть опасность, что в той или иной степени могут быть повторены ошибки Си++.

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

E>1. У тебя вообще образование связано с программированием? Или же ты в большей степени самоучка?

По образованию я юнист и бухгалтер. Неужели не похоже?

E>2. Ты так с легкостью переходил с одной технологии на другую... А как быть с проектами, которые развивались в рамках какой-нибудь технологии в течении нескольких лет?

Я не сказал бы, что это было с легкостью. Это был постепенный процесс. Часть его прошла когда особых проектов и не было. Вернее был, но он с лихвой окупился еще в середине 90-ых. А потом основной доход я получал от продажи журналов (в основном бухгалтерских), так что разработка не была основыным дохождом. Скорее она была основным расходом.

А вообще, все очень просто. Продукт который не выпущен на ранок за 2-3 года рискует оказаться провальным. Револющии и темболее эволюции даже в нашей бурно развивающейся индустрии происходят куда реже. Так что можно без проблем сдавать продукт и начинать новый на новом витке.

Так что я не вижу тут проблем. Те кто засиделся скорее огребут от конкурентов чем что-то до добются. Это я говорю как экономист. Конечно речь не идет о монстрах вроде МС и Сана. Они то могут себе повзолить и деять параллельных продуктов на совершенно разных принципах. Могут позволить себе писать ОС 15 лет подряд на С. У них есть на это деньги.

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

E>Ты так уверен? Сколько кода ты написал на Nemerle чтобы об этом судить?

Зато я таскал мешки с цементом! Это тоже в зачет идет!

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

E>Классная фраза. Эдак про што угодно сказать можно.

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

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

Легко. Просто вызов вывода в косоль выводится во время компиляции. А вызов заключенный в <[ ]> попадает в генерируемый код. Собственно примеры есть на их сайте.

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

AVC>Раз такая тема поднята применительно к Nemerle, IMHO, есть опасность, что в той или иной степени могут быть повторены ошибки Си++.

По-моему, С++ стал таким примером, что даже Денис Ричи завязал с разработкой новых языков программирования.

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

E>>1. У тебя вообще образование связано с программированием? Или же ты в большей степени самоучка?

VD>По образованию я юнист и бухгалтер. Неужели не похоже?

Похоже, но лучше знать наверняка
Поросто те вещи, про которые ты написал, даже в нашем провинциальном ВУЗе, даже в далекие 1990-1995 годы, рассказывалось на лекциях преподавателями или на переменках друзьями-коллегами, которые где-то подрабатывали. Была соответствующая атмосфера, в которой информация о старых и новых направлениях буквально витала в воздухе и только ленивый ее не анализировал и не усваивал.

Поэтому то, что для тебя бывало для открытием, для многих было всего лишь информационным фоном. Я не хочу сказать, что для меня никаких откровений не было, отнюдь. Но то, что я спокойнее воспринимал новые открытия, это очень вероятно. Может потому, что изначально этих открытий было больше. Я, например, радовался, когда появился Windows и был стороником Windows, даже агитировал за Windows когда был выбор между Windows и OS/2. Только вот OLE и COM-у я совершенно не обрадовался и всегда старался держаться подальше, так же как и от CORBA. Зато довольно быстро понял, что Java станет серьезным противником C++ и, поэтому, при каждом удобном случае старался провозгласить "Java must die!"

VD>А вообще, все очень просто. Продукт который не выпущен на ранок за 2-3 года рискует оказаться провальным.

Есть системы, рынок которых достаточно узок и малоизвестен. В качестве примеров можно взять системы для банковского процессинга, АСУТП, телекоммуникации. В таких нишах оперативное реагирование на технологии даже каждые пять лет уже не просто. А пять лет -- это не так уж мало. Например, Java появилась в 1995-1996 годах, но тогда она не была конкурентом C++. Через пять лет (в 2000-2001) уже можно было бы инициировать смену платформы с Java на C++, вполне. Но проходит еще пять лет и в качестве весьма серьезной альтернативы Jave выступает C#. А еще через пять лет альтернативой C# вполне может стать Nemerle.
Да вот, если время выпуска версии занимает 2-3 года, то смена мейнстрима раз в пять лет -- это слишком расточительно, имхо.

VladD2,

> А вообще, все очень просто. Продукт который не выпущен на ранок за 2-3 года рискует оказаться провальным. Револющии и темболее эволюции даже в нашей бурно развивающейся индустрии происходят куда реже. Так что можно без проблем сдавать продукт и начинать новый на новом витке.
>
> Так что я не вижу тут проблем. Те кто засиделся скорее огребут от конкурентов чем что-то до добются. <...>

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

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

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

[ИМХО]
Влад, ну ведь эрудированный человек, писал на C/С++ и вот все строишь из себя С++ ненавистника.
Зачем ?

С++ это, как минимум, Веха в истории развтития языков программирования, такая как Java ( не C# ибо .Net есть попытка повторения успеха платформенно-независимой машины ).

Ну вот зачемв все так экранизировать ? ( В отношении себя и C++ естественно )
[/ИМХО]

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

Положа руку на сердце — согласен — это все очень хорошо и понятно.

Но как всегда — есть одно НО, а именно — автор кода — легко поймет что скрывается за "визуально не типизированным" выражением, а вот программист, которыёё будет этот код поддерживать ?

Дело в том, что как излишняя типизация есть зло, так и отсутсвие ьтаковой, ИМХО, есть тоже зло, ибо расслабляет программиста и как результат — код в котором тожде трудно понять чот и как с первого взгляда.

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

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

CS>>Еще раз мне представляется проблема несколько надуманной.
CS>>На Java я пишу немного в последнее время. А в C++ автоматический вывод типов
CS>>я из своей практики исключил. И лучше бы его там не было вообще.

WF>Интересно, как можно говорить о некоторой возможности если ты даже с ней не работал (впечатление такое сложилось)?

Я не понял, с чем я не работал? С Nemerle — не работал. С O'Caml — тоже.
C C++ работаю.

WF>..и даже не хочешь узнать, что это за фича и как она работает.

Как она работает я знаю или, скажем так, понимаю как сделать.
Я не понимаю зачем.

WF>В O`Caml disjoint union-ов нет. Но ничто не мешает использовать в данном случае joint union.

А самый завлящщий discriminated union ?
Иногда надо.


CS>>"не ошибаешься в указании типа". Если я ошибусь мне компайлер скажет.
CS>>А в твоем случае скажет unittest. Который еще писать надо.

WF>Нет. Тип выведется. И в худщем варианте, выведется более общий тип, чем ты указал бы.

Я как-то об этом узнаю?

WF>Да, позволяет. Работать с очень сложными типами. Пример — монады (а еще лучше Arrows Хаскелля ). Посмотрел бы я на того маньяка, кто захочет везде явно типы указывать Ты указываешь типы для граничных случаев (там где ввод/вывод, например), а все остальные внутренние сложные типы выводятся автоматически.

"Работать с очень сложными типами" как это связано с длиной
идентификатора типа? Что такое вообще "очень сложный тип" в твоем понимании?

Кроме того что не нужно писать типы явно что-нибудь еще
есть в автоматическом выводе типов?

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

WF>>Интересно, как можно говорить о некоторой возможности если ты даже с ней не работал (впечатление такое сложилось)?

CS>Я не понял, с чем я не работал? С Nemerle — не работал. С O'Caml — тоже.
CS>C C++ работаю.

С выводом типом по типу как в ML-языках.

WF>>..и даже не хочешь узнать, что это за фича и как она работает.

CS>Как она работает я знаю или, скажем так, понимаю как сделать.
CS>Я не понимаю зачем.

Я отвечал зачем. Ниже написал еще раз. Плюс важное замечание

WF>>В O`Caml disjoint union-ов нет. Но ничто не мешает использовать в данном случае joint union.

CS>А самый завлящщий discriminated union ?
CS>Иногда надо.

Ну это join union и есть, насколько я понимаю.

WF>>Нет. Тип выведется. И в худщем варианте, выведется более общий тип, чем ты указал бы.

CS>Я как-то об этом узнаю?

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

CS>"Работать с очень сложными типами" как это связано с длиной
CS>идентификатора типа? Что такое вообще "очень сложный тип" в твоем понимании?

Скажем, композиция пары Haskell-евских функционалов высшего порядка и получится сложный тип. По-моему (маленькому) опыту такие типы начинают активно появляться там, где есть монады. Ну и вообще замечал, что при описании Haskell-овских eDSL-ей обычно на границе eDSL-я простые типы (фигура, время, цвет), а в самой реализации чего-нибудь сложного типы просто зубодробительные.

В моем понимании "очень сложный тип" — это когда много стрелочек Если в типе употребляется где-то больше 5 других типов, для меня это уже сложно.

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

Подумал и вспомнил еще один момент. Причем наиболее важный

Еще один момент — это параметрический полиморфизм. Допустим, где-то в коде у тебя есть выражение map(func, lst), где map и func — функции, lst — некоторые параметры. Как ты можешь узнать, что это выражение корректно? Что тип элемента списка, сигнатура func и map — консистентны? При том, что map — полиморфная функция, она может работать со множеством разных параметров разных типов. Ты же не будешь к каждому подвыражению приписывать конкретный тип? Например, в случае выражения "map (\x -> x*2) [1, 2, 3]", тип map будет выведен как (int->int)->[int]->[int]. А в случае "map (\x -> x*2) ["1", "2", "3"]" будет ошибка унификации — тип не может быть выведен, т.е выражение неконсистентно.

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

CS>Кроме того что не нужно писать типы явно что-нибудь еще
CS>есть в автоматическом выводе типов?

Написал выше.

Здравствуйте, Павел Кузнецов, Вы писали:

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

А именно?

IT,

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

> А именно?

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

Здравствуйте, Павел Кузнецов, Вы писали:

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

>> А именно?

ПК>

ПК>Револющии и темболее эволюции даже в нашей бурно развивающейся индустрии происходят куда реже. Так что можно без проблем сдавать продукт и начинать новый на новом витке. Так что я не вижу тут проблем. Те кто засиделся скорее огребут от конкурентов чем что-то до добются.

Мне классиков цитировать не надо Мне интересно знать о каком именно продукте идёт речь?

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

S>Влад, ну ведь эрудированный человек, писал на C/С++ и вот все строишь из себя С++ ненавистника.
S>Зачем ?

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



Я не ненавистник. Я считаю С++ этапом. Этапом в истории, этапом в собственном развитии. И считаю, что этап это пройден. Согласен, что не для всех. Но для меня одноначно пройден.

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

S>Но как всегда — есть одно НО, а именно — автор кода — легко поймет что скрывается за "визуально не типизированным" выражением, а вот программист, которыёё будет этот код поддерживать ?

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

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

S>Дело в том, что как излишняя типизация есть зло, так и отсутсвие ьтаковой,

Это не отсуствие! В этом вся и разница.

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

Развитие идет по пути упрощения решения сложных задач. Это не оболваниевание, это расширение возможностей. Ведь можно что-то оболванить и тем самым сделать доступным массам. А можно сделать отличную автоматику которая скроет сложность.

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

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Эти рассуждения обычно неприменимы к продукту с долгим временем жизни. Очень много относительно небольших фирм построено вокруг нескольких продуктов, новые версии которых должны выходить регулярно. Позволить себе переписать все с нуля только ради перехода на очередную модную технологию они не могут, и, главное, никакого конкурентного преимущества от этого не получат, т.к. за время переписывания уже существующей функциональности их конкуренты напишут новую. Только когда продукт достигает пределов заложенной изначально архитектуры, и требует переписывания, можно задуматься о переходе на другую технологию. Но и в этом случае часто решение будет не в пользу такого варианта, т.к. будет существовать множество компонент, одно повторное использование которых может позволить реализовать новую архитектуру значительно быстрее, чем перевод всего этого на новую технологию. Плюс накопленный опыт уже работающих специалистов по сравнению с их переучиванием или наймом новых. Плюс известные
ПК>риски против неизвестных.

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

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

Д>Ни один продукт не является неразделимым монолитом. А если все-таки является, то его архитектору надо бить по рукам железной палкой.



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

Например, механизмы коммуникаций между старыми подсистемами.

Д>или переписывать с их помощью особо проблематичные старые подсистемы.

А что, старые подсистемы по-определению проблематичные и нуждаются в переписывании?
Мне представляется, что долгоиграющий продукт с проблематичными подсистемами просто не выжил бы.

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

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

IT>А именно?

А можно мне за Павла ответить? Ну, например, Base24-card.

Да и чего специализированные системы вспоминать. Можно, имхо, на MS Word посмотреть, Visual Studio, IE, Mozilla, Opera. Вряд ли их можно назвать продуктами с коротким временем жизни.