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

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

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

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

G>Затем же, зачем в С++ есть шаблоны. Делается это для того, чтобы компилятор вывел общий тип.

G>Возьми шаблонную функцию С++. Типы ее аргументов не выводятся, они проверяются при инстанцировании в каждом конкретном случае.

Да ну? Ты ничего не перепутал?

G>Теперь предствь, что компилятор может вывести параметризованный тип из контекста употребления для любой функции, и тебе не надо писать template. Так что любая функция у тебя обладает параметрическим полиморфизмом без лишних теложвижений с твоей стороны.

Всё -- шаблон -- это плохая идея. Например потому, что при выводе типов шаблонов функций не работают неявные конверсии типов.

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

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

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

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

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

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

G>>Затем же, зачем в С++ есть шаблоны. Делается это для того, чтобы компилятор вывел общий тип.

G>>Возьми шаблонную функцию С++. Типы ее аргументов не выводятся, они проверяются при инстанцировании в каждом конкретном случае.

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

G>>Теперь предствь, что компилятор может вывести параметризованный тип из контекста употребления для любой функции, и тебе не надо писать template. Так что любая функция у тебя обладает параметрическим полиморфизмом без лишних теложвижений с твоей стороны.

Ш>Всё -- шаблон -- это плохая идея. Например потому, что при выводе типов шаблонов функций не работают неявные конверсии типов.

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

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

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

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

AFAIK, в 90-х Ритчи создал язык Limbo (для системы Inferno ).
Использовать Си++ он "почему-то" не стал.
Этот язык сильно отличается от Си++ (и Си ) : type-safe, сборка мусора, модульность, может использоваться на машинах без memory-protection...
Ну прямо как Обе...
Впрочем, ой, что это я! На RSDN же полагается верить, что именно Вирт завидует успехам Ритчи и Страуструпа...

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

AVC>AFAIK, в 90-х Ритчи создал язык Limbo (для системы Inferno ).
AVC>Использовать Си++ он "почему-то" не стал.
AVC>Этот язык сильно отличается от Си++ (и Си ) : type-safe, сборка мусора, модульность, может использоваться на машинах без memory-protection...
AVC>Ну прямо как Обе...

как странно, в слове "Лисп" совсем нет таких букв

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

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

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

VD>Я тебе уже не раз говорил, что Руби хотя вещь и красивая, но далекая от совершенства. Не нужно по ней судить о других языках.

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

VD>Хм. Нэмерл выводит типы. Это всеравно что вписывать их явно. Так что ошибок быть не может. Язык статически типизированный!

Думается мне, что eao197 говорил про то, как ты полезешь как-нибудь в исходники, которые ты писал год-полтора назад, и увидишь такую вот безличную картину.
Как, без поддержки IDE, ты вспомнишь, кто что возвращает?

AVC wrote:
> Использовать Си++ он "почему-то" не стал.
Тогда С++ еще был "в детстве", так что неудивительно.

> Этот язык сильно отличается от Си++ (и Си ) : type-safe, сборка мусора,
> модульность, может использоваться на машинах без memory-protection...
Там не сборка мусора, а подсчет ссылок. С++ тоже замечательно
используется без защиты памяти.

Из от С++ отличных фич Limbo и системы Inferno: поддержка параллелизма и
распределенности на уровне языка (в виде каналов), более сильная
типизация, другой синтаксис, динамическая подгрузка кода. В начале 90-х
это было вполне приличным набором.

Однако, современный С++ большую часть фич Limbo реализует в виде библиотек.

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

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

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

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

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

std::map< std::string, std::map< std::string, int > > build_report( const report_params_t & params );

Вроде и типы все знаешь, а что это такое и почему -- вопрос.

Но я действительно упустил из виду, что в Nemerle все, что идет из метода наружу, должно декларироваться.

СТ>Как, без поддержки IDE, ты вспомнишь, кто что возвращает?

Применительно к Nemerle меня больше всего забавляет другое -- вроде бы и язык интересный, и многое обещает, и многим нравится. Но препятствием служит отсутствие IDE!
По мне, так если язык действительно хороший (теплый взгляд в сторону C++ и Ruby), так на нем даже в Notepade (не говоря уже про vim и emacs) программировать можно.

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

PA>Обычно типы можно посмотреть безо всяких IDE, достаточно интерпретатора.

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

Если же речь идет о статически типизированных языках, т.к. C++ (Java, C#), то для просмотра типа тебе достаточно иметь заголовочные файлы.

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


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

E>std::map< std::string, std::map< std::string, int > > build_report( const report_params_t & params );
E>

E>Вроде и типы все знаешь, а что это такое и почему -- вопрос.
ПО-моему, функция построения отчета по каким-то параметрам (кстати, это целая проблема — придумывать названия параметрам типа args, settings, options, params,...).

E>Применительно к Nemerle меня больше всего забавляет другое -- вроде бы и язык интересный, и многое обещает, и многим нравится. Но препятствием служит отсутствие IDE!
На IDE внимание акцентирует только Влад, не надо обобщать.
E>По мне, так если язык действительно хороший (теплый взгляд в сторону C++ и Ruby), так на нем даже в Notepade (не говоря уже про vim и emacs) программировать можно.
Намекнуть, чем пользуются программисты на Лиспе, ML, Erlang, ...?

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

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

Я и не путаю
Но, насколько я понял, в Nemerle в nested functions можно не указывать типы параметрам и возвращаемому значению. В таких случаях запись в Nemerle визуально не сильно отличается от записи в Ruby или Python. Разница только в том, в какой момент времени тебя предупредят об ошибке, если ты ошибся -- во время компиляции или исполнения. Но на момент написания кода подсказок-то нет (разве что IDE будет очень умная).

PA>ПО-моему, функция построения отчета по каким-то параметрам (кстати, это целая проблема — придумывать названия параметрам типа args, settings, options, params,...).

Ага, вопрос в том, что является ключем в первом map (имя клиента или имя сервиса), а что во вложенном (имя сервиса или имя клиента).

PA>На IDE внимание акцентирует только Влад, не надо обобщать.

Не только

Автор: Максим Зелинский
Дата: 08.02.06

PA>Намекнуть, чем пользуются программисты на Лиспе, ML, Erlang, ...?

Думаю, что emacs-ом, но неужели VisualStudio?

Отвечу в обратном порядке.

E>Если же речь идет о статически типизированных языках, т.к. C++ (Java, C#), то для просмотра типа тебе достаточно иметь заголовочные файлы.
Статически типизируемые языки — это те, в которых типы известны на этапе компиляции, соответственно компилятор дает по рукам при ошибках типизации. Независимо от того, выводятся типы автоматически или вбиваются вручную.

E>Чтобы посмотреть типы в run-time, необходимо, как минимум, работающее окружение. Т.е. некий тестовый стенд, на котором ты можешь запустить тестовый прогон и поставить точку прерывания в нужном месте.

Да нету никаких рантаймов, тестовых прогонов и точек прерывания.
На примере ОКамла.
Разработка ведется в стиле REPL. В процессе разработки нового модуля периодически скармливаем текст интерпретатору. И тут же видим типы всех значений (в т.ч. функций), определенных в модуле. Во время активной разработки достаточно ml-файла (некий аналог .cpp-файла) — т.к. есть вывод типов, то и интерфейс модуля выводится автоматически. Затем, после того, как модуль устаканится, можно добавить mli-файл, в котором явно указываются все экспортируемые значения и их типы.

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

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

AVC>>Этот язык сильно отличается от Си++ (и Си ) : type-safe, сборка мусора, модульность, может использоваться на машинах без memory-protection...
AVC>>Ну прямо как Обе...

Д>как странно, в слове "Лисп" совсем нет таких букв

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

"Человек — двуногое существо без перьев и с плоскими ногтями." (c) Платон

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

PA>На примере ОКамла.
Вот, тебе, как разработчику build-системы, может быть интересна работа конкурентов:
http://svn.metaprl.org/viewcvs/mojave/omake/src/
Думаю, в .mli-файлах все понятно, без интерпретатора, что опровергает тезис о невозможности понять что-либо в программах на языках с выводом типов без IDE . С другой стороны, если ты сопровождаешь систему, то компилятор и интерпретатор таки должны быть под рукой.

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

E>>Если же речь идет о статически типизированных языках, т.к. C++ (Java, C#), то для просмотра типа тебе достаточно иметь заголовочные файлы.
PA>Статически типизируемые языки — это те, в которых типы известны на этапе компиляции, соответственно компилятор дает по рукам при ошибках типизации. Независимо от того, выводятся типы автоматически или вбиваются вручную.

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

E>>Чтобы посмотреть типы в run-time, необходимо, как минимум, работающее окружение. Т.е. некий тестовый стенд, на котором ты можешь запустить тестовый прогон и поставить точку прерывания в нужном месте.

PA>Да нету никаких рантаймов, тестовых прогонов и точек прерывания.

Ок. Методику работы понял.

PA>Еше раз — отсутствие фич (в данном случае вывода типов) нельзя выдавать за преимущество. Если пугает опасность забыть типы функций в модуле — всегда есть возможность добавить аннотации типов. Но языки, которые требуют вводить типы на каждом шагу, как справку из ЖЭКа, морально устарели.

Может быть (хотя я пока так не думаю).
Но вот если взглянуть с другой стороны:

std::auto_ptr< io_controller_t > c = make_io_controller( params );
c->flush_all();

Ведь здесь есть факт двойного соглашения -- с одной стороны, make_io_controller обязуется отдать мне объект, который может быть приведен к std::auto_ptr<io_controller_t>. С другой стороны, я явно объявляю, что в этом месте мне нужен именно std::auto_ptr<io_controller_t>, а не что-нибудь другое. Поэтому компилятор бьет меня по рукам при нарушении соглашения с любой из сторон.
Если бы у меня была конструкция:

auto c = make_io_controller( params );
c->flush_all();

то при смене типа возвращаемого значения у make_io_controller я об этом даже не узнаю -- компилятор просто сделает c нужного типа и все.
Например, такой сценарий: make_io_controller стал возвращать не auto_ptr, а io_controller_t*. Если мой код об этом не узнает, то я не буду удалять объекты io_controller_t.

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

E>Но вот если взглянуть с другой стороны:
E>

E>std::auto_ptr< io_controller_t > c = make_io_controller( params );
c->>flush_all();
E>

E>Ведь здесь есть факт двойного соглашения -- с одной стороны, make_io_controller обязуется отдать мне объект, который может быть приведен к std::auto_ptr<io_controller_t>. С другой стороны, я явно объявляю, что в этом месте мне нужен именно std::auto_ptr<io_controller_t>, а не что-нибудь другое. Поэтому компилятор бьет меня по рукам при нарушении соглашения с любой из сторон.
E>Если бы у меня была конструкция:
E>

E>auto c = make_io_controller( params );
c->>flush_all();
E>

E>то при смене типа возвращаемого значения у make_io_controller я об этом даже не узнаю -- компилятор просто сделает c нужного типа и все.
E>Например, такой сценарий: make_io_controller стал возвращать не auto_ptr, а io_controller_t*. Если мой код об этом не узнает, то я не буду удалять объекты io_controller_t.
Это особенности C++. Попробуй придумать пример, не связанный с ручным управлением памятью и приведением типов .

Если серьезно, вернемся к классическим определениям. АТД определяется множеством операций, которые над ним можно выполнять. flush_all и есть такая операция. Поэтому менять тип make_io_controller как угодно не удастся.

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

PA>Это особенности C++. Попробуй придумать пример, не связанный с ручным управлением памятью и приведением типов .

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

PA>Если серьезно, вернемся к классическим определениям. АТД определяется множеством операций, которые над ним можно выполнять. flush_all и есть такая операция. Поэтому менять тип make_io_controller как угодно не удастся.

А тебе не кажется, что это уже duck typing начинается?
Т.е., если я сменю тип возвращаемого значения на другой, в котором есть метод flush_all (возможно случайно), то все нормально?

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

E>Но, насколько я понял, в Nemerle в nested functions можно не указывать типы параметрам и возвращаемому значению. В таких случаях запись в Nemerle визуально не сильно отличается от записи в Ruby или Python. Разница только в том, в какой момент времени тебя предупредят об ошибке, если ты ошибся -- во время компиляции или исполнения. Но на момент написания кода подсказок-то нет (разве что IDE будет очень умная).

Как мне думается, особых мозгов от IDE это не потребует, так как все равно придется пользовать компилятор как библиотеку.
Но ведь есть еще и макросы, меняющие синтаксис. Вот тут надо будет много думать.