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

AVC>Кроме того, Limbo — императивный язык...

ну во первых, про императивность ты до этого ничего не говорил. А во вторых, Лисп все равно позволяет писать в императивном стиле

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

PA>А теперь помечтаем, и удалим все лишнее, не теряя типобезопасности:
<... красивый (без иронии) код поскипан ...>
PA>Красота!!

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

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

PA>Т.е. грубо говоря, передали сантиметры вместо килограммов, когда и сантиметры, и килограммы были представлены значениями типа float. Если ты знаешь язык, который выявляет такие ошибки, дай знать . К выводу типов это отношения не имеет — ты эту ошибку получил без вывода типов.

Если мне не отшибает память, в Modula-2 и Ada, а так же D, можно было назначать псевдонимы именам типов (вводить подтипы). При этом подтипы дальше существовали как отдельные типы, их нельзя было просто так смешивать с другими типами. Что-то вроде:

typedef string ClientName;
typedef string ServiceName;
typedef int TrxCount;

hash< ClientName, hash< ServiceName, TrxCount > > build_report( ReportParams params );

Все. Просто и надежно.

На эту тему я был в свое время свидетелем многочасового поиска бага в Java-коде, где метод получал несколько строковых аргументов:

public DBConnection getConnection( string dbName, string userName, string password ) { ... };

так вот оказалось, что везде, где метод getConnection вызывался, параметры dbName и userName были перепутаны. И компилятор ничего не мог сделать.

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

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

E>Если мне не отшибает память, в Modula-2 и Ada, а так же D, можно было назначать псевдонимы именам типов (вводить подтипы). При этом подтипы дальше существовали как отдельные типы, их нельзя было просто так смешивать с другими типами. Что-то вроде:
В C++ это тоже можно обойти, завернув данные в структуру, просто писанины больше. В ML есть 2 варианта: использовать вариантный тип или инкапсулировать тип в модуль.
E>Все. Просто и надежно.
В большинстве случаев не так просто и надежно. Часто с данными производят какие-то вычисления (из пароля с именем юзера вполне можно посчитать какой-то хэш, ширину умножить на высоту и получить площадь и т.д.) — если типы намеренно делаются несовместимыми, работать с ними становится неудобно, в какой-то момент из обертки все равно нужно получить значения родных типов, и в этот момент их можно опять перепутать. Думаю, потому в большинстве библиотек, которые я видел, точки конструируются из пар чисел, а не из несовместимых типов XCoord, YCoord, а имя юзера и пароль передаются как строки.

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

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

E>>Если мне не отшибает память, в Modula-2 и Ada, а так же D, можно было назначать псевдонимы именам типов (вводить подтипы). При этом подтипы дальше существовали как отдельные типы, их нельзя было просто так смешивать с другими типами. Что-то вроде:
PA>В C++ это тоже можно обойти, завернув данные в структуру, просто писанины больше.

Т.е., фактически, не применимо на практике.

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

Так в том-то и дело, что все моменты смешения подтипов требуют явного приведения типов. А это сразу бросается в глаза (по аналогии с рекомендацией использовать static_cast вместо приведения в стиле C в C++). И таких моментов, имхо, набирается не много.

PA> Думаю, потому в большинстве библиотек, которые я видел, точки конструируются из пар чисел, а не из несовместимых типов XCoord, YCoord, а имя юзера и пароль передаются как строки.

А тебе часто приходилось работать с Modula-2 или Ada библиотеками?

PA>И чтобы беседа окончательно не ушла в сторону, настойчиво резюмирую — вывод типов здесь не при чем.

Да я совершенно не против вывода типов. И уверен, что они всегда выводятся как нужно. (Это как всегда в программировании: программа всегда в точности делает то, что ей сказали. Другое дело, что программист не всегда понимает, что именно он говорит )
Я просто высказываю свое впечатление об одной из сторон программирования без явной декларации типов: только глядя на код не всегда понятно, с чем имеешь дело. В случае с OCaml на помощь привлекаются mil-файлы. В случае Ruby -- исходники того, что ты применяешь. Но, если показать человеку, который не совсем в теме, код:

make_ipc_controller_pair(
    ipc,
    io_alerter,
    out pair )
    {
        ipc_owner = make_ipc_sap_owner( ipc );
        controller = make_controller();

        result = make_event_handler_controller(
                ipc_owner,
                io_alerter,
                controller );
        if( result==0 )
            {
                pair = make_ipc_controller_pair( ipc, controller );
            }
        return result;
    }

и попросить понять, что здесь происходит, то это будет не так просто, как кажется.
(кстати, этот код очень сильно напоминает Ruby).

Здравствуйте, Сергей Туленцев, Вы писали:

СТ>Дык, я не про то. Вот есть у тебя макрос while. Ну или поядреней — using.
СТ>Ты видишь using, а после прохода компилятором по этому месту там совершенно другой код.
СТ>А IDE, чтобы правильно и по месту показывать ошибки должна как-то с этим разбираться.

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

Друное дело с комплитом. Макросы могут добавлять, удалять или менять AST. Хорошо бы чтобы при этом IDE отображала реальную картину в реальном времени. Ну, например, добавил я атрибут [XmlSerialize] который приводит к добавлению в класс двух методов — SaveXml() и LoadXml(). Вот хотелось бы, чтобы IDE позволяло эти методы закомплитить.

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

E>Языками нормальными нужно пользоваться:
E>

E>typedef Dictionary< ZoomedFont::ZoomedFontKey, ZoomedFont > Dict;
E>static Dict _fontMap = new Dict( new ZoomedFontKey::ZoomedFontKeyComparer() );
E>

E>

В "нормальном" до таких тонких моментов просто не доходит.

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

C>Вам бы помогли typedef'ы

Мне бы помог вывод типов. А typedef перед единственным использованием особо ничем помочь не сможет. Хотя в общем, действительно нечто вроде локального и совсем глобального (на проект) using-а было бы удобно иметь.

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

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

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



G>>Ну да. Я — ничего не перепутал. Еще что-нибудь сказать есть, кроме междометий?

Ш>Есть -- вообще-то в С++ при вызове шаблона функции поисходит вывод типа. Лет уже 15 как.

Под выводом типа во всей ветке имеется в виду вывод типа в функции вне конектса вызова. Этого в С++ нет. Лет 15 как. И еще лет 15 не будет. О том, что проверка типов выполняется при инстанциации (то что там происходит, выводом типов назвать язык не поворачивается), я написал. Хватит цепляться к словам.

G>>Это не идея. Это я на яблоках, прибегая к аналогиям, объясняюю, на что похож вывод типов в языках с системой Хиндли-Милнера. С расчетом на то, что до знающего С++ человека дойдет, зачем это надо. А ты все перепутал. В любом случае — если так не понятно, значит уже не вдолбить никак. По крайней мере, у меня идей больше нет, как объяснить.

Ш>Хамить не надо. Не умеешь объяснять доходчиво свои мысли -- лучше не пиши ничего.

Если ты не считаешь объяснения "доходчивым" — это не трагедия, и вовсе не повод объяснений не давать. Извини, я объясняю свои мысли так, как умею. И спрашивать у тебя разрешения на объяснения не собираюсь, как и спорить с тобой. Кто хочет понять — поймет, или задаст конкретный уточняющий вопрос. Ему я объясню.

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

G>Под выводом типа во всей ветке имеется в виду вывод типа в функции вне конектса вызова. Этого в С++ нет. Лет 15 как. И еще лет 15 не будет. О том, что проверка типов выполняется при инстанциации (то что там происходит, выводом типов назвать язык не поворачивается), я написал. Хватит цепляться к словам.
Конечно, вывода типов в духе ML или, пуще того, Haskell, в C++ нет и не будет.
Но справедливости ради следует признать, что при инстанциации шаблонов выполняется не только проверка типов, а нечто большее — подходящая функция или перегруженный оператор при компиляции повыражения выбирается на основании правил перегрузки, на основании ее типа определяется тип подвыражения с вызовом, и процесс повторяется рекурсивно — тип результирующего выражения может получиться довольно сложным, и семантика выражения зависит именно от выведенных таким образом типов — наиболее ярко это проявляется в expression templates. Конечно, сравнивать C++ с ФЯ, где вся программа является выражением, смысла нет.

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

PA>Конечно, вывода типов в духе ML или, пуще того, Haskell, в C++ нет и не будет.
PA>Но справедливости ради следует признать, что при инстанциации шаблонов выполняется не только проверка типов, а нечто большее — подходящая функция или перегруженный оператор при компиляции повыражения выбирается на основании правил перегрузки, на основании ее типа определяется тип подвыражения с вызовом, и процесс повторяется рекурсивно — тип результирующего выражения может получиться довольно сложным, и семантика выражения зависит именно от выведенных таким образом типов — наиболее ярко это проявляется в expression templates. Конечно, сравнивать C++ с ФЯ, где вся программа является выражением, смысла нет.

Признавать или не признавать тут нечего. Я неплохо знаю С++, 6 лет на нем пишу, знаю, что это так и есть , и не имею ни малейшего желания обсуждать С++. Потому что в этой ветке под "автоматическим выводом типов" понимается совсем другое. А именно — то, как это делается в Nemerle и ML (вывод параметрического типа функции/выражения вне контекста вызова, без явных аннотаций типа).

То, что в С++ "тоже есть, с таким же названием, но только совсем не то" — второстепенный и не относящийся к делу момент.

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

Кончай гнать.

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

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

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

VD>Кстати, больше всего меня смущало в ФЯ, то что их принципы входят в противоречие с принципами ООП. А ООП я и сейчас считаю одним из самых мощных инструментов для решения сложных задач.

Оно так и есть. Как электронщик я провожу четкую аналогию ООП с цифровой электроникой, а ФЯ — с аналоговой. Причем, сходство методов проектирования, шаблонов проектирования, способов декомпозиции и т.д. в обоих случаях просто потрясающее м/у программной индустрией и аппаратной. Складывается впечатление, что ПО-отрасль "в лоб" переняла наработки железячников по принципам (общему видению), подходам к разработке и способами манипулирования абстракциями. (И кстати, цифровые системы обработки сигналов по архитектуре с "высоты птичьего полета" более близки, все-таки, к аналоговым системам)

VD>"объекты имеют свое состояние модифицируемое посредством методов"? Слова вроде "так при модификации могут порождаться новые объекты" выглядят совсем не убедительно. Однако я же не фанатик ФЯ? Так почему я должен принимать идею о том, что модификация состояния — это зло? Темболее, что декларативность достигаемая в ФЯ отнюдь не заключена в немодифицируемости. Она скорее в другом. Она в том, что функции являются первоклассными сущностями, и в том, что с их помощью можно делать гибкую функциональную декомпозицию. В общем, функциональный взгляд на мир дает еще одно измерение.

Нет, все проще. Есть структурная (топологическая) декомпозиция (основа ООП), и есть функциональная (активно используемая при имплементации ООП). И они прекрасно уживаются и дополняют друг друга. (А с высоты причьего полета — являются одним и тем же. ИМХО — функциональность идет на первом месте, но мы ее реализуем с помощью "устройств"/объектов). Изменение состояний в "объектах" происходят в результате воздествия внешних сигналов. Однако, сами эти сигналы неплохо обрабатываются функциональными методами. Мне кажется вовсе непротиворечивой система, состоящая из "объектов", которые обмениваются сигналами (вызывают методы друг-друга, или реагируют на события друг/друга, последнее ближе к идеалу), причем на пути этих сигналов стоят всевозможные преобразователи функционального типа. Да и сами "кишки" объектов запросто могут быть выполнены как ячейки для хранения состояний, запись и извлечение информации в которые (из которых), или обновление значения в которых происходит после обработки внешних/внутренних сигналов функциональным образом.

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

Более того, функциоанльные объекты (всякие фильтры, регуляторы, нелинейные преобразователи и т.д.) — это тоже объекты. Они могут иметь св-ва (параметры) и менять свое поведение в зависимости от этих параметров. (Близко к аналогии curring-functions в ФЯ).

--------
Идеальная программная система (похожая на электронные схемы ) — это набор объектов со св-вами и событиями БЕЗ публичных методов и набор функциональных объектов. Да, именно. У объектов — только св-ва и события. Объекты объединяются топологически путем подключения к событиями друг/друга. (Сами собятия могут обрабатываться/трансформироваться функциональным образом, причем как с помощью внешних, то бишь потенциально заменяемых функциональных объектов, так и с помощью внутренних, являющихся частью имплементации объекта... но это я уже повторяюсь).

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

VD>Чудесь не бывает. Это я понял еще в жизни.



Неплохо ты, однако, сейчас устроился...

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

V>Идеальная программная система (похожая на электронные схемы ) — это набор объектов со св-вами и событиями БЕЗ публичных методов и набор функциональных объектов. Да, именно. У объектов — только св-ва и события. Объекты объединяются топологически путем подключения к событиями друг/друга. (Сами собятия могут обрабатываться/трансформироваться функциональным образом, причем как с помощью внешних, то бишь потенциально заменяемых функциональных объектов, так и с помощью внутренних, являющихся частью имплементации объекта... но это я уже повторяюсь).
А вот с этого места по подробней пожалуйста. Как это может выглядеть? Жилательно с псевдокодом.

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

ПК>>.NET используется только для Web. В продукт входит N приложений, в т.ч. и Web, вот штамп и стоит...

IT>Ну так с веба обычно всё плохое и начинается Сначала веб, потом серверок на .NET перепишите, а там и юайщики подтянутся

Знаешь, пока ЮАЙщикам на дотнет рановато, ей-богу. Блин, мне все-таки пришлось начать писать свою мини-либу для иерархий windowless-конролов, не дождавшись следующего поколения GUI на дотнете...

Ну а веб и сервачок — вполне...

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

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

VD>Пример из кода который пишу прямо сейчас:
VD>

VD>        static Dictionary<ZoomedFont.ZoomedFontKey, ZoomedFont> _fontMap = 
VD>            new Dictionary<ZoomedFont.ZoomedFontKey, ZoomedFont>(
VD>            new ZoomedFontKey.ZoomedFontKeyComparer());
VD>

А почему не так?:

        static Dictionary<ZoomedFontKey, ZoomedFont> _fontMap = 
            new Dictionary<ZoomedFontKey, ZoomedFont>(
            ZoomedFontKey.Comparer);

Если охота оставить ZoomedFont::ZoomedFontKey приватным классом, то _fontMap просится внутрь класса ZoomedFont, т.е. сам ZoomedFont надо снабдить статическими методами регистрации и использования экземплярами ZoomedFont. Если же охота сделать _fontMap внешним объектом, то можно было бы сделать ZoomedFontKey internal. Т.е. есть куча способов сократить запись.

А наиболее правильным представляется вообще так:

public class ZoomedFont {
...

    private class Dictionary : Dictionary<ZoomedFontKey, ZoomedFont> {
        public Dictionary() : base(ZoomedFontKey.Comparer) {}
    }

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

VD>Мне бы помог вывод типов. А typedef перед единственным использованием особо ничем помочь не сможет. Хотя в общем, действительно нечто вроде локального и совсем глобального (на проект) using-а было бы удобно иметь.

Я выкручиваюсь с помощью наследования от стандартных коллекций. Кстати, это неплохо помогает дополнительной декомпозиции (иногда требуется нечто более осмысленное, чем просто добавить/извлечь/найти) и к тому же позволяет насильно подавать нужные компареры и пр. параметры в конструкторы базового класса.

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

V>Я выкручиваюсь с помощью наследования от стандартных коллекций. Кстати, это неплохо помогает дополнительной декомпозиции (иногда требуется нечто более осмысленное, чем просто добавить/извлечь/найти) и к тому же позволяет насильно подавать нужные компареры и пр. параметры в конструкторы базового класса.

Я тоже... иногда... Но не всегда это приемлемо. От int не шибко понаследушся.

Кстати, в C# мне как раз больше всего не нравится, то что принцип "все является объектом" несколько не доведен до конца. Пергрузка операторов кривовата. Невозможность расширять функциональность value- и seale-тпов тоже не радует.

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

interface IAdd<T>
{
    T Add(T other);
}

// Применяется везде гда int используется в качестве параметра типа.
// Так как int выэлью-тип, то все вызовы инлайнятся и никаких 
// непроизводительных расходов не возникает.
traits IntAdd<int> : IAdd<int>
{
    int _value;
    piblic IntAdd(int value) { _value = value; }
    piblic int Add(int other) { return _value + other; }
}
...

class A
{
    static T Sum<T>(IList<T> list, Func<T, T> adder)
        where T: IAdd
    {
        T sum = defaulte(T);
        
        foreach (T value in list)
            sum = sum.Add(value);
            
        return sum;
    }
    
    static void Main()
    {
        Console.WriteLine(Sum(int[] { 1, 3, 9 }));
        Console.WriteLine(Sum(double[] { 3.2, 1.3, 2.0 }));
    }
}