Re[2]: Философический вопрос про автоматический вывод типов. - Философия программирования

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

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

По-моему, до появления generic'ов в дотнете и яве это был один из очень сильных аргументов в пользу STL против соответствующих библиотек дотнета и явы.
В C++ вообще очень любят как можно больше делать на этапе компиляции, и это правильно — вспомним CT-assert'ы, concept check libraries и т.д. Ты сам это прекрасно знаешь, не лукавь

.
E>Но на момент написания кода подсказок-то нет (разве что IDE будет очень умная).
Для качественных подсказок IDE должна выполнять львиную долю работы компилятора или быть с компилятором интегрирована, и в данном случае ничего не меняется. Когда я использую злые шаблоны с частичными специализациями, вложенные типы и пространства имен, я тоже часто остаюсь без подсказки.

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

Это особенность Windows-developer'ов, которые (включая меня) давно сидят на игле ИДЕ. Т.к. Немерле позиционируется как замена Шарпу, целевая аудитория у него такая — привыкшая к Студии, это не хорошо и не плохо, это факт. Вон Vermicious Knid, с другой стороны, пишет и не жалуется, получается как-будто здорово. Так что как аргумент против Немерла и вывода типов это не проходит.

PA>>Намекнуть, чем пользуются программисты на Лиспе, ML, Erlang, ...?
E>Думаю, что emacs-ом, но неужели VisualStudio?
Угадал

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

Posted via RSDN NNTP Server 2.0

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

E>>Но, насколько я понял, в Nemerle в nested functions можно не указывать типы параметрам и возвращаемому значению. В таких случаях запись в Nemerle визуально не сильно отличается от записи в Ruby или Python.
PA>Ключевое — визуально. Разница существенная.

Когда я пишу код, мне важно именно "визуальная" составляющая -- то, что мне видно в исходниках/документации.

E>>Разница только в том, в какой момент времени тебя предупредят об ошибке, если ты ошибся -- во время компиляции или исполнения.
PA>Этого недостаточно?

Достаточно для чего?

Чтобы совершить ошибку в коде и написать не правильное формирование тела отчета? Код уже написан. Вот что главное. И если мне компилятор скажет, что код не правильный, мне его придется переписывать точно так же, как если об ошибке сообщит unit-test.

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

.
E>Приведение типов как раз возможно в языках со сборкой мусора, например, множественное наследование интерфейсов.
При множественном наследовании интерфейсов ситуация (утечка памяти из-за неправильного объявления типа), которую ты описал в примере, невозможна. Во-вторых, языки со сборкой мусора!=Java. В-третьих, мы говорили о возможных опасностях вывода типов. Жду другого примера

.

PA>>Если серьезно, вернемся к классическим определениям. АТД определяется множеством операций, которые над ним можно выполнять. flush_all и есть такая операция. Поэтому менять тип make_io_controller как угодно не удастся.
E>А тебе не кажется, что это уже duck typing начинается?
Я предпочитаю теримн generic programming (как мне кажется, об утиной типизации только ruby-сообщество говорит).
E>Т.е., если я сменю тип возвращаемого значения на другой, в котором есть метод flush_all (возможно случайно), то все нормально?

Если это ненормально, добавляем тип вручную. Если нормально, оставляем обобщенную реализацию и позволяем компилятору сделать грязную работу. Все просто

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

Мы там тебе письма посылали. Ответь, плиз.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

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

Сдается мне, что из кода и так все очевидно. Мне не нужно никаких других подсказок кроме знания о том, что int.Parse преобразует строку в число. Остальное мой мозг выведет все автоматически лучше любого компилятора. Ну, а в местах где это не так очевидно имеет смысл явно указать тип рпи объявлении переменной.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

E>>>Но, насколько я понял, в Nemerle в nested functions можно не указывать типы параметрам и возвращаемому значению. В таких случаях запись в Nemerle визуально не сильно отличается от записи в Ruby или Python.
PA>>Ключевое — визуально. Разница существенная.
E>Когда я пишу код, мне важно именно "визуальная" составляющая -- то, что мне видно в исходниках/документации.
В исходниках и документации содержится ровно то, что мы туда вносим. Если мы хотим там что-от видеть — мы беремся за клавиатуру и принимаемся стучать(еще раз рекомендую посмотреть на описания интерфейсов модулей в реальной программе на O'Caml). Но мы, труженики клавы и монитора, лучше других должны понимать, что наши любимые компьютеры служат для автоматизации рутинных действий и для повышения производительности нашего труда за счет освобождения мозгов для творческой работы. Если я пишу простую функцию вроде

let rec member list x =
    match list with
    []         -> false
    head::tail -> if head=x then true 
                                else member tail x;;

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

PA>>Этого недостаточно?

E>Достаточно для чего?

E>Чтобы совершить ошибку в коде и написать не правильное формирование тела отчета?
Я не знаю, о каких ошибках ты говоришь, и как они связаны именно с выводом типов. Не хочу флеймить по этому поводу, это похоже именно на боязнь паровозов, о которой писал Гапертон.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

PA>При множественном наследовании интерфейсов ситуация (утечка памяти из-за неправильного объявления типа), которую ты описал в примере, невозможна.

Смотри ширше (ширее). При множественном наследовании интерфейсов смена типа может сделать доступными методы из другого интерфейса, который не должен был бы быть доступен в данном месте.

PA> Во-вторых, языки со сборкой мусора!=Java.

А разве в C# нет множественного наследования интерфейсов?

PA> В-третьих, мы говорили о возможных опасностях вывода типов. Жду другого примера

.

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

E>>А тебе не кажется, что это уже duck typing начинается?
PA>Я предпочитаю теримн generic programming (как мне кажется, об утиной типизации только ruby-сообщество говорит).

Не только, такой же duck typing и в Python-е доступен.

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

PA>Если это ненормально, добавляем тип вручную.

Вот смысл в том, что ненормальность определится не в момент компиляции, а во время unit-тестов.

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

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

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

Хотел было описать Dictionary<ZoomedFont.ZoomedFontKey, ZoomedFont> в юсинге, да не тут то было. ZoomedFontKey — это вложенный приватный класс и за пределами ZoomedFont его не видно. Если бы вывод типов позволил бы мне хотя бы не писать "Dictionary<ZoomedFont.ZoomedFontKey, ZoomedFont>" два раза, я уже был бы рад.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

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

Дык жто же этот самый компилятор не сможет с макросами разобраться?

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

PA>(еще раз рекомендую посмотреть на описания интерфейсов модулей в реальной программе на O'Caml).

Посмотрел, похоже на h-файлы. Если это автоматом генерируется, то классно.

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

В таком примере — да. Да только не часто лично мне приходится абстрактными списками оперировать. А вот чем-то подобным:

template< class IPC_SAP >
so_4::ret_code_t
make_ipc_controller_pair(
    ipc_sap_owner_templ_t< IPC_SAP > ipc,
    so_4::rt::comm::io_alerter_auto_ptr_t io_alerter,
    ipc_controller_pair_t< IPC_SAP > & pair )
    {
        IPC_SAP * ipc_raw_ptr = ipc.get();

        ipc_sap_owner_auto_ptr_t ipc_owner(
                make_ipc_sap_owner_auto_ptr( ipc ) );
        event_handler_controller_auto_ptr_t controller;

        so_4::ret_code_t result = make_event_handler_controller(
                ipc_owner,
                io_alerter,
                controller );
        if( 0 == result )
            {
                ipc_controller_pair_t< IPC_SAP > p( ipc_raw_ptr, controller );
                pair = p;
            }

        return result;
    }

чуть ли не каждый день.

PA>Я не знаю, о каких ошибках ты говоришь, и как они связаны именно с выводом типов. Не хочу флеймить по этому поводу, это похоже именно на боязнь паровозов, о которой писал Гапертон.

Ошибка была простая -- возвращался Hash, где ключем было имя клиента, а значением -- другой Hash, в котором ключем было имя услуги, а значением -- количество транзакций. Поскольку ключи везде String-и, то я, перепутав, написал вывод отчета, который считал, что в первом хэше ключем является имя услуги, а во вложенных хешах -- имя клиента. Соответственно, не так считалось общее количество транзакций по клиенту. А все из-за того, что лень было тип сделать -- Report и методы getter-ы для него.

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

VD>

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

VD>Хотел было описать Dictionary<ZoomedFont.ZoomedFontKey, ZoomedFont> в юсинге, да не тут то было. ZoomedFontKey — это вложенный приватный класс и за пределами ZoomedFont его не видно. Если бы вывод типов позволил бы мне хотя бы не писать "Dictionary<ZoomedFont.ZoomedFontKey, ZoomedFont>" два раза, я уже был бы рад.

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

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

VladD2 wrote:
> Хотел было описать Dictionary<ZoomedFont.ZoomedFontKey, ZoomedFont> в
> юсинге, да не тут то было. ZoomedFontKey — это вложенный приватный класс
> и за пределами ZoomedFont его не видно. Если бы вывод типов позволил бы
> мне хотя бы не писать "Dictionary<ZoomedFont.ZoomedFontKey, ZoomedFont>"
> два раза, я уже был бы рад.
Вам бы помогли typedef'ы

Posted via RSDN NNTP Server 2.0

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

Оверквотинг удален.

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

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

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

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

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

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

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

VD>Сдается мне, что из кода и так все очевидно. Мне не нужно никаких других подсказок кроме знания о том, что int.Parse преобразует строку в число. Остальное мой мозг выведет все автоматически лучше любого компилятора. Ну, а в местах где это не так очевидно имеет смысл явно указать тип рпи объявлении переменной.

Блин, мысли роятся, а облечь в слова не могу.

Кстати, новость не по топику: с недавних пор стала возможной конструкция
.

using(def x = SomeClass())
{
}

Раньше же приходилось писать так:

def x = SomeClass();
using(x)
{
}

Интересно, это оператор присваивания теперь возвращает значение? Или просто сделали исключение для юзинга. Пойду в исходниках посмотрю.

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

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

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

VD>Дык жто же этот самый компилятор не сможет с макросами разобраться?

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

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

СТ>Интересно, это оператор присваивания теперь возвращает значение? Или просто сделали исключение для юзинга. Пойду в исходниках посмотрю.

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

) языки неявно приводят к bool все что под руку попадется.

... << RSDN@Home 1.1.4 stable rev. 510>>

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

>> А Microsoft.VSDesigner namespace — это, по-твоему, недоразумение?

TK>Еще скажи, что в System.Data.dll это компилятор C# создал namespace <CppImplementationDetails> и namespace <CrtImplementationDetails>

Какая разница? До тех пор пока это на .NET это может быть хоть C#, хоть C++/CLI, хоть его предок-уродец MC++. У нас тут как всегда началось всё с одного, съехало на другое, а аргументы про третье.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

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

PA>>(еще раз рекомендую посмотреть на описания интерфейсов модулей в реальной программе на O'Caml).
E>Посмотрел, похоже на h-файлы. Если это автоматом генерируется, то классно.
Акцент был на то, что если хочется иметь код, документирующий интерфейс модуля, его можно создать, но это не является обязательным. Получить автоматически интерфейс из реализации — раз плюнуть, только после этого его обычно редактируют, чтобы убрать лишние детали реализации (служебные функции, определения типов, которые мы хотим спрятать, и т.д.) и добавить комментарии. Если бы он совсем автоматом генерировался, смысла бы в нем не было.

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

E>А вот чем-то подобным:
А теперь помечтаем, и удалим все лишнее, не теряя типобезопасности:

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;
    }

Красота!!

Неужели не согласен, что твоя функция пугает не потому, что она такая "системная", а потому, что все типы (с длинными "системными" именами) введены вручную?

E>Ошибка была простая -- возвращался Hash, где ключем было имя клиента, а значением -- другой Hash, в котором ключем было имя услуги, а значением -- количество транзакций. Поскольку ключи везде String-и, то я, перепутав, написал вывод отчета, который считал, что в первом хэше ключем является имя услуги, а во вложенных хешах -- имя клиента. Соответственно, не так считалось общее количество транзакций по клиенту. А все из-за того, что лень было тип сделать -- Report и методы getter-ы для него.
Т.е. грубо говоря, передали сантиметры вместо килограммов, когда и сантиметры, и килограммы были представлены значениями типа float. Если ты знаешь язык, который выявляет такие ошибки, дай знать

. К выводу типов это отношения не имеет — ты эту ошибку получил без вывода типов.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

СТ>>Интересно, это оператор присваивания теперь возвращает значение? Или просто сделали исключение для юзинга. Пойду в исходниках посмотрю.

Д>Нет ничего криминального в том, что этот оператор возвращает значение. Источником проблем является тот факт, что некоторые (не будем показывать пальцем

) языки неявно приводят к bool все что под руку попадется.

Я так удивился потому, что раньше прочитал в документации, что оператор присвоения возвращает void, равно как и инкремент/декремент.
Стало быть, нельзя писать конструкций вида:

a = b = c;
d = ++e;

Зачем оно так было сделано — не знаю (особенно, если неявного приведения к bool нет), но верю, что были причины.

	От:	Programmierer AG
	Дата:	09.02.06 11:49
	Оценка:	+2

	От:	Cyberax
	Дата:	09.02.06 11:58
	Оценка:

От:	eao197	http://eao197.blogspot.com
Дата:	09.02.06 11:58
Оценка:

	От:	Programmierer AG
	Дата:	09.02.06 11:59
	Оценка:	+2

От:	VladD2	www.nemerle.org
Дата:	09.02.06 12:09
Оценка:

От:	Сергей Туленцев	http://software.tulentsev.com
Дата:	09.02.06 12:43
Оценка:

От:	IT	linq2db.com
Дата:	09.02.06 12:54
Оценка:	+1