Мне интересен период, когда они писали самую первую версию kdb.

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

T>Мне интересен период, когда они писали самую первую версию kdb.

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

T>>Мне интересен период, когда они писали самую первую версию kdb.
KP>Логи? В принципе, для отладки любого приложения этого достаточно, при умении ими пользоваться, конечно.

А ещё у них отладчика нет до сих пор. То есть, его нет и не было никогда.

Как они с поддержкой программ для Wall Street справляются?..

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

T>>>Мне интересен период, когда они писали самую первую версию kdb.
KP>>Логи? В принципе, для отладки любого приложения этого достаточно, при умении ими пользоваться, конечно.

T>А ещё у них отладчика нет до сих пор. То есть, его нет и не было никогда.

T>Как они с поддержкой программ для Wall Street справляются?..

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

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

T>Как они с поддержкой программ для Wall Street справляются?..

Вот она причина мирового экономического кризиса.

T>>Как они с поддержкой программ для Wall Street справляются?..
KP>А он вообще нужен? Лично для меня, необходимость в отладчике очч спорный момент. Если он есть, это безусловно хорошо, но если его нет, то логов всегда достаточно. А если еще и библиотека логирования хорошая, то отладчик скорее будет лишним

Сколько людей, столько и мнений

Автор: eao197
Дата: 06.03.09

.

Моё, кстати, примерно такое же, как у тебя.

T>>Как они с поддержкой программ для Wall Street справляются?..
FR>Вот она причина мирового экономического кризиса.

Я её отношу на счёт наличия побочных эффектов в K. Это затруднило анализ финансовых потоков. Был бы использован Хаскель, проблем бы не было.

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

T>>>Как они с поддержкой программ для Wall Street справляются?..
KP>>А он вообще нужен? Лично для меня, необходимость в отладчике очч спорный момент. Если он есть, это безусловно хорошо, но если его нет, то логов всегда достаточно. А если еще и библиотека логирования хорошая, то отладчик скорее будет лишним

T>Сколько людей, столько и мнений

Автор: eao197
Дата: 06.03.09

.

T>Моё, кстати, примерно такое же, как у тебя.

На мой взгляд тут довольно просто все. Если человек писал под большое количество платформ, то он наверняка хорошо умеет работать с логами, в особенности если приходилось писать поп встроенные/мобильные платформы. Если же основной опыт это Java, .NET и только под Винду.. Ну что ждать от такого конеченого человека

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

KP>На мой взгляд тут довольно просто все. Если человек писал под большое количество платформ, то он наверняка хорошо умеет работать с логами, в особенности если приходилось писать поп встроенные/мобильные платформы. Если же основной опыт это Java, .NET и только под Винду.. Ну что ждать от такого конеченого человека

Да, действительно, все просто. Достаточно пописать под большое количество платформ чтобы понять, что нет никакой доблести в отрицании отладчика. Иногда отладчик очень серьезно экономит время и силы. Можно это использовать в своей работе. А можно не использовать и тешить себя сознанием собственной крутизны, которая позволяет работать вообще без отладчика

KP>>На мой взгляд тут довольно просто все. Если человек писал под большое количество платформ, то он наверняка хорошо умеет работать с логами, в особенности если приходилось писать поп встроенные/мобильные платформы. Если же основной опыт это Java, .NET и только под Винду.. Ну что ждать от такого конеченого человека
E>Да, действительно, все просто. Достаточно пописать под большое количество платформ чтобы понять, что нет никакой доблести в отрицании отладчика. Иногда отладчик очень серьезно экономит время и силы. Можно это использовать в своей работе. А можно не использовать и тешить себя сознанием собственной крутизны, которая позволяет работать вообще без отладчика

Дедлайн ты не читал.

Молодец. Тешь себя сознанием собственной крутости и дальше.

DSL в своей работе ты не используешь.

Молодец. Тешь себя сознанием собственной крутости и дальше.

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

3.14здеть изволите сударь...

T>Дедлайн ты не читал.

разобрал на заметки

T>DSL в своей работе ты не используешь.

DSL-и разные бывают, и такие, и такие, и такие.

E>3.14здеть изволите сударь...

Ничего подобного. Я просто могу чего-то не знать.

Теперь я знаю, и даже больше, чем ты хотел сказать.

T>>Дедлайн ты не читал.

E>разобрал на заметки

T>>DSL в своей работе ты не используешь.

E>DSL-и разные бывают, и такие, и такие, и такие.

Тогда чего ты насчёт необходимости отладчика упираешься?

Про "меньше времени на отладку" знаешь, про отладчик нет ни в одном из твоих отчётов про DSL. Я думаю, что ты осознаешь, во что бы тебе обошёлся отладчик для каждого из языков.

У меня в голове не укладывается, как после всего этого ещё можно заикаться об обязательности отладчика. О том, что это преимущество.

Преимущество в мощности самого языка. Если на нём можно быть производительным без отладчика, то вот оно, преимущество. Отладчик добавит не сильно.

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

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

T>Тогда чего ты насчёт необходимости отладчика упираешься?

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

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

T>Тогда чего ты насчёт необходимости отладчика упираешься?

Потому что люди разные. Я, например, могу писать программы в vim-е и без отладчика. А есть люди, которые не хотят это делать без IDE и отладчика. У них даже стиль такой -- чуть что, сразу точку останова в коде и затем пошаговая трассировка... И, что важно, такие люди очень хорошо пишут программы, от которых я всегда старался открещиваться (например, интеграция с разными банковскими автоматизированными системами).

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

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

T>Преимущество в мощности самого языка. Если на нём можно быть производительным без отладчика, то вот оно, преимущество. Отладчик добавит не сильно.

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

T>>Тогда чего ты насчёт необходимости отладчика упираешься?
FR>Не надо крайностей.
FR>По моему опыту очень полезно отказатся от отладчика при написании нового кода, это реально
FR>ускоряет его написание и повышает качество. Но отказ от использования отладчика при подержке
FR>и модернизации даже своего (не говоря уже о чужом) коде вреден и замедляет работу.

Зависит от языка.

ОЧЕНЬ СИЛЬНО.

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

E>Да, действительно, все просто. Достаточно пописать под большое количество платформ чтобы понять, что нет никакой доблести в отрицании отладчика. Иногда отладчик очень серьезно экономит время и силы. Можно это использовать в своей работе. А можно не использовать и тешить себя сознанием собственной крутизны, которая позволяет работать вообще без отладчика

Что-то меняется в этом мире. Давно я не соглашался с тобой так все цело и полностью.

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

T>DSL в своей работе ты не используешь.

T>Молодец. Тешь себя сознанием собственной крутости и дальше.

Я балдею от твоего самомнения.

Ты бы сначала узнал по подробнее что и зачем используют твои оппоненты, а потом бы домыслы свои высказывал (а лучше держал бы их при себе).

eao197 с ДСЛ-ями знаком точно не по наслышке. Он разработал систему кросплатформной сборки проектов на Руби. Причем эта система реализована в виде встроенного в Руби ДСЛ-я.

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

Так что бравада тем, что тебе не нужен отладчик является просто констатацией факта — ты не умеешь ускорить отладку программ.

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

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

E>>3.14здеть изволите сударь...

T>Ничего подобного. Я просто могу чего-то не знать.

Дык когда человек говорит о том, что не знает это и называется тем самым словом за которое тут могут забанить .

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

T>Тогда чего ты насчёт необходимости отладчика упираешься?

T>Про "меньше времени на отладку" знаешь, про отладчик нет ни в одном из твоих отчётов про DSL. Я думаю, что ты осознаешь, во что бы тебе обошёлся отладчик для каждого из языков.

Прикинь, есть люди с разными мнениями. А твое мнение не всегда бывает правильным.
Вот такие дела.

Любой кто пытался отладить парсер созданный с помощью Яка поймет, что отладчик очень не помешал бы. А вед казалось бы классический пример ДСЛ-я. И логами отлаживать можно...

T>У меня в голове не укладывается, как после всего этого ещё можно заикаться об обязательности отладчика. О том, что это преимущество.

А ты не заметил, что он не говорил об обязательности?
Он говорил, о том, что с отладчиком удобнее.

T>Преимущество в мощности самого языка. Если на нём можно быть производительным без отладчика, то вот оно, преимущество. Отладчик добавит не сильно.

Ну, то есть все же добавит? Значит ты тут все же споришь только о том насколько много добавит?

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

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

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

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

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

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

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

Ошибки конечно бывает, но по моему тесты (еще очень большой плюс REPL) ловят их быстрее и надежнее отладчика.

T>>DSL в своей работе ты не используешь.
T>>Молодец. Тешь себя сознанием собственной крутости и дальше.
VD>Я балдею от твоего самомнения.
VD>Ты бы сначала узнал по подробнее что и зачем используют твои оппоненты, а потом бы домыслы свои высказывал (а лучше держал бы их при себе).
VD>eao197 с ДСЛ-ями знаком точно не по наслышке. Он разработал систему кросплатформной сборки проектов на Руби. Причем эта система реализована в виде встроенного в Руби ДСЛ-я.

Ух ты! Да ты что! Вот это да! Вот это настоящий программистский подвиг!

"Был неправ, вспылил. Раскаиваюсь, прошу разрешения загладить, искупить."

Это он, по-моим расчётам, положил на это чудо не менее двух или трёх недель.

У меня на .BAT файлах (ну, CMD — под OS/2) это столько и заняло — две недели. На тикле вдвое быстрее.

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

Причём здесь отладка логами?

VD>Так что бравада тем, что тебе не нужен отладчик является просто констатацией факта — ты не умеешь ускорить отладку программ.

Зачем мне ускорять отладку программ на Си, если я могу взять OCaml без отладчика и всё равно оказаться быстрей?

Неужто непонятно такое простое соображение?

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

Закон больших чисел.

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

Ориентироваться же надо на лучших. Например, на разработчиков kdb.

T>>Тогда чего ты насчёт необходимости отладчика упираешься?
T>>Про "меньше времени на отладку" знаешь, про отладчик нет ни в одном из твоих отчётов про DSL. Я думаю, что ты осознаешь, во что бы тебе обошёлся отладчик для каждого из языков.
VD>Прикинь, есть люди с разными мнениями. А твое мнение не всегда бывает правильным.
VD>Вот такие дела.

(самомнение на 11)

Ну, ты понял насчёт правильности мнения, да?

(самомнение на 5)

VD>Любой кто пытался отладить парсер созданный с помощью Яка поймет, что отладчик очень не помешал бы. А вед казалось бы классический пример ДСЛ-я. И логами отлаживать можно...

Поэтому не надо использовать Java и не надо использовать генераторы разборщиков. Обе эти вещи относятся к 90-м года двадцатого века.

T>>У меня в голове не укладывается, как после всего этого ещё можно заикаться об обязательности отладчика. О том, что это преимущество.
VD>А ты не заметил, что он не говорил об обязательности?
VD>Он говорил, о том, что с отладчиком удобнее.

А я говорил, что отладчик — гиря на ногах обоих разработчиков, и пользователей и компиляторщиков.

T>>Преимущество в мощности самого языка. Если на нём можно быть производительным без отладчика, то вот оно, преимущество. Отладчик добавит не сильно.
VD>Ну, то есть все же добавит? Значит ты тут все же споришь только о том насколько много добавит?

Новая языковая фича — 10% производительности. Отладчик — 5%.

Я выберу фичу.

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

Eclipse — хорошая среда?

VD>В прочем, не нужны — не пользуйся. Что других то за советскую власть агетировать?

А почему бы не поагитировать?

Тем более, что не за советскую власть.

Про дедлайн напомнили, ещё чего интересного разобрали. Даже пошутили удачно по пути.

По-моему, хорошо получилось.

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

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

Можно подумать, что кто-то пишет код так чтобы без отладчика его и запустить то было нельзя.

FR>Ошибки конечно бывает, но по моему тесты (еще очень большой плюс REPL) ловят их быстрее и надежнее отладчика.

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

От тебя про реплы слушать вообще смешно (в контексте твоей современной работы на С++).

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

T>Ух ты! Да ты что! Вот это да! Вот это настоящий программистский подвиг!

Подвиг, не подвиг, а ты пальцем в небо попал. И все остальные твои слова после этого выглядят совершенно не серьезно.

T>Это он, по-моим расчётам, положил на это чудо не менее двух или трёх недель.

Ну, а что ты о других то судишь? Ты что всю свою работу за первую неделю работы сделал что ли?

T>У меня на .BAT файлах (ну, CMD — под OS/2) это столько и заняло — две недели. На тикле вдвое быстрее.

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

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

T>Причём здесь отладка логами?

А ты у нас настолько крут, что твои программы отладки не требуют?

VD>>Так что бравада тем, что тебе не нужен отладчик является просто констатацией факта — ты не умеешь ускорить отладку программ.

T>Зачем мне ускорять отладку программ на Си, если я могу взять OCaml без отладчика и всё равно оказаться быстрей?

Ну, да. На ОКамле ведь программы ошибок содержать не могут. Так?

T>Неужто непонятно такое простое соображение?

Понятно. Понты кидаешь. Или и просто ни одной большой программы ни разу в жизни не написал.
Ты вообще хоть раз вносил изменения в программу которую писало 10 человек (или более)?

T>Программистов много, среди них обязательно окажется много кого угодно. И вот таких вот удивительных людей тоже.

T>Ориентироваться же надо на лучших. Например, на разработчиков kdb.

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

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

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

(смотря какие ошибки)

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

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

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

Кстати по отладке (в т.ч. и без отладчика) на DTF был хороший цикл статей:
Способы отладки приложений , Отладка по крэш-дампам, Протоколирование , Визуальный анализ кода.

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

D>В ВУЗах на первых курсах широко распространена практика написания кода алгоритма без компьютера — на бумажке, его трассировка и т.д. чтобы развивались исключительно аналитические способности студента.

Ага. А в третьем классе учат складывать и умножать четырехзначные числа в столбик. Означает ли это, что калькулятор — это зло?

D>В музыкальных школах (по классу фортепьяно, например) заставляют учить то или иное музыкальное произведение не нажимая клавиш на инструменте (чтобы работала исключительно двигательная память).

Ага. Еще можно учить ПДД без практики возждения, а потом купить права. Ну, и что?

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

Отладчик это инструмент. Если кто-то идиот или неумеха, то он ему конечно не поможет.

D>Но это в бОльшой степени касается алгоритмов. Дейкстра тоже проповедовал программирование без отладчика, если ссылаться на авторитеты.

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

Вообще, программировать с отладчиком — это само по себе нонсенс. Отлачик средство поиска ошибок, а не средство разработки. Если ошибки — милости просим в отладчик. Нет, так и нужды в нем нет.

В зависимости от разных факторов (квалификации, языка, качества кода, объема кода, сложности задачи) ошибок может быть меньше или больше. Но так чтобы совсем без них, так не бывает. Разве что в программах класса "Здарова, мир".

D>Кстати по отладке (в т.ч. и без отладчика) на DTF был хороший цикл статей:
D>Способы отладки приложений , Отладка по крэш-дампам, Протоколирование , Визуальный анализ кода.

Не открывается. Возможно снова РСДН-ДоС.

T>Поэтому не надо использовать Java и не надо использовать генераторы разборщиков. Обе эти вещи относятся к 90-м года двадцатого века.

Все таки надо сказать что-нибудь хорошее про генераторы разборщиков. В ocamlyacc большая часть ошибок вылавливается на этапе компиляции, и, например, для бипа — yacc не создал ни одной проблемы вообще. Даже отладочная печать AST недоделана, поскольку не понадобидась. Уж не знаю, зачем бы там был отладчик.

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

T>"Был неправ, вспылил. Раскаиваюсь, прошу разрешения загладить, искупить."

T>Это он, по-моим расчётам, положил на это чудо не менее двух или трёх недель.

T>У меня на .BAT файлах (ну, CMD — под OS/2) это столько и заняло — две недели. На тикле вдвое быстрее.

Угу любая программа пишется хорошим программистом за два дня, в худшем случае за пару недель.
Правда авторы аналогов того что написал eao197 об этом не знают и годами пишут свои scons'ы

T>Зачем мне ускорять отладку программ на Си, если я могу взять OCaml без отладчика и всё равно оказаться быстрей?

Кстати у Ocaml'а очень хороший отладчик, подерживает шагание в обе стороны, правда полноценно работает только в linux. Я линукс на ноут поставил чтобы на него посмотреть, еще установил OcaIDE и до сих пор тащусь

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


VD>Можно подумать, что кто-то пишет код так чтобы без отладчика его и запустить то было нельзя.

Неоднократно наблюдал

FR>>Ошибки конечно бывает, но по моему тесты (еще очень большой плюс REPL) ловят их быстрее и надежнее отладчика.

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

Это не зависит от размеров и чужих библиотек.
У меня отладчик дополнение к тестам.

VD>От тебя про реплы слушать вообще смешно (в контексте твоей современной работы на С++).

Ну у меня сейчас вообще весело, просто мечта для ненавистников отладчика, boot-time и NT Native API,
отладка по логам, вместо REPL'а VirtualBox

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

VD>Вообще, программировать с отладчиком — это само по себе нонсенс. Отлачик средство поиска ошибок, а не средство разработки. Если ошибки — милости просим в отладчик. Нет, так и нужды в нем нет.

Вообще идеально отладчик интегрирован в Smalltalk, вот в нем вполне реально писать в отладчике

FR>Кстати у Ocaml'а очень хороший отладчик, подерживает шагание в обе стороны, правда полноценно работает только в linux. Я линукс на ноут поставил чтобы на него посмотреть, еще установил OcaIDE и до сих пор тащусь

Неправославно. Осудительно.

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

FR>Ну у меня сейчас вообще весело, просто мечта для ненавистников отладчика, boot-time и NT Native API,
Сорри, что вмешиваюсь в ваш спор.
Если не секрет, для каких задач применяете Native API?
Под boot-time подразумеваете boot-execute apps или драйвера?
Спасибо.

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

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

D>>Но это в бОльшой степени касается алгоритмов. Дейкстра тоже проповедовал программирование без отладчика, если ссылаться на авторитеты.
VD>Ссылаясь надо не забывать цитаты приводить. А то вы так бедных авторитетов переврете, что они после смерти в гробу ворочаться будут .

Если отладка – процесс удаления ошибок,
то программирование должно быть процессом их внесения.
Э. Дейкстра.

Ни и дальше уже цитата не Дейкстры, но о его трудах:

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

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

LD>Если не секрет, для каких задач применяете Native API?
LD>Под boot-time подразумеваете boot-execute apps или драйвера?
LD>Спасибо.

boot-execute apps, дефрагментатор и оптимизатор реестра.

T>>Ух ты! Да ты что! Вот это да! Вот это настоящий программистский подвиг!
VD>Подвиг, не подвиг, а ты пальцем в небо попал. И все остальные твои слова после этого выглядят совершенно не серьезно.

Это всё в глазах наблюдателя.

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

Меня поправили, это отлично.

Но вопрос с повестки дня не снят.

Делает ли человек для каждого своего языка отладчики?

Если да, то сколько это у него занимает. Если нет, то чего он требует от других языков того, что сам не делает?

T>>Это он, по-моим расчётам, положил на это чудо не менее двух или трёх недель.
VD>Ну, а что ты о других то судишь? Ты что всю свою работу за первую неделю работы сделал что ли?
T>>У меня на .BAT файлах (ну, CMD — под OS/2) это столько и заняло — две недели. На тикле вдвое быстрее.
VD>Ну, ты крут и вообще молодец. Вот только какое это к делу отношение имеет? Ты в очередной раз начал учить отца детопроизводством заниматься. А сейчас отмазки ищешь. Вот только глупо от этого ты выглядеть не перестанешь. Так что в следующий раз когда кода кого-то начнешь учить чему-то, то подумай 100 раз и узнай не зря ли время потратишь.

Мне совершенно не важно, как я выгляжу в твоих глазах.

Мне важно, чтобы моё соображение было рассмотрено.

VD>>>Что до вопроса об отладчиках и отладкой логированием, то лично я считаю отладчик эдаким логом на стройдах. С его помощь можно все тоже самое что и с помощью логов, только не над на каждый чих перекомпилировать и перезапускать отлаживаемую программу, а стало быть можно выполнять свою работу во много раз быстрее.
T>>Причём здесь отладка логами?
VD>А ты у нас настолько крут, что твои программы отладки не требуют?

Я REPL пользуюсь. В запущенных случаях пользуюсь trace. Но это не отладка в чистом виде, это промежуточное тестирование.

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

VD>>>Так что бравада тем, что тебе не нужен отладчик является просто констатацией факта — ты не умеешь ускорить отладку программ.
T>>Зачем мне ускорять отладку программ на Си, если я могу взять OCaml без отладчика и всё равно оказаться быстрей?
VD>Ну, да. На ОКамле ведь программы ошибок содержать не могут. Так?

Будут. Но меньше на строку кода и строк кода будет меньше.

T>>Неужто непонятно такое простое соображение?
VD>Понятно. Понты кидаешь. Или и просто ни одной большой программы ни разу в жизни не написал.
VD>Ты вообще хоть раз вносил изменения в программу которую писало 10 человек (или более)?

Да, когда я работал в геймдеве. Справился на отлично. Ускорил многое в полтора раза, а немногое — в пять и более раз.

Поскольку это был C++, делать движок модульным начальство отказывалось, то пришлось пользоваться отладчиком.

Так что я знаю, какая это боль.

T>>Ориентироваться же надо на лучших. Например, на разработчиков kdb.
VD>Лучшими их ты назначил?

Не только я. Но ты волен выбрать других, я же только как пример их привёл.

T>>Поэтому не надо использовать Java и не надо использовать генераторы разборщиков. Обе эти вещи относятся к 90-м года двадцатого века.
dmz>Все таки надо сказать что-нибудь хорошее про генераторы разборщиков. В ocamlyacc большая часть ошибок вылавливается на этапе компиляции, и, например, для бипа — yacc не создал ни одной проблемы вообще. Даже отладочная печать AST недоделана, поскольку не понадобидась. Уж не знаю, зачем бы там был отладчик.

Я при описании грамматик обязательно допускаю ошибки.

Чаще всего это выглядит как-то так:
topexpr ::= ... expr
shifts ::= ... topexpr
plusminus ::= ... shifts
muldiv ::= ... plusminus -- вставил недавно, до этого они не встречались.
expr ::= plusminus

Сейчас провёл эксперимент, ghc -fwarn-unused-binds о таком сообщает, просто надо контролировать экспорты.

Ха, буду знать, спасибо!

T>>"Был неправ, вспылил. Раскаиваюсь, прошу разрешения загладить, искупить."
T>>Это он, по-моим расчётам, положил на это чудо не менее двух или трёх недель.
T>>У меня на .BAT файлах (ну, CMD — под OS/2) это столько и заняло — две недели. На тикле вдвое быстрее.
FR>Угу любая программа пишется хорошим программистом за два дня, в худшем случае за пару недель.
FR>Правда авторы аналогов того что написал eao197 об этом не знают и годами пишут свои scons'ы

Они их пишут годами потому, что 1) тяжело тестировать, 2) надо поддерживать всех на свете, 3) ЯП дурацкий и ещё много причин.

Могу сказать с уверенностью, что больше 5% своего рабочего времени никто на такую ерунду не тратит. За исключением запущенных случаев, но это в очень больших софтверных компаниях.

Я, собственно, справился быстро потому, что упёрся рогом. Потом мы катались на первом сборщике два года. Как раз те самые ~2% рабочего времени.

T>>Зачем мне ускорять отладку программ на Си, если я могу взять OCaml без отладчика и всё равно оказаться быстрей?
FR>Кстати у Ocaml'а очень хороший отладчик, подерживает шагание в обе стороны, правда полноценно работает только в linux. Я линукс на ноут поставил чтобы на него посмотреть, еще установил OcaIDE и до сих пор тащусь

Бедный я, бедный.

Худой я, и бледный.

Сижу мод Макосью на первом iMac 17" PPC без интернета и мучаюсь. У vim там даже подсветки синтаксиса нет. Хотя я пользуюсь XCode. Хотя и там подсветки нет.

Всё, перехожу на ноут (придётся купить), ставлю Линукс (придётся ставить), ocaml (придётяс отказаться от современного синтаксиса) и OcaIDE (придётся отказаться от произвольной структуры проекта).

Буду тащиться.

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

T>Это всё в глазах наблюдателя.

Отрадно, что ты это понимаешь. Остается надежда, что этот же аргумент ты когда-нибудь научишься применять к себе.

T>Делает ли человек для каждого своего языка отладчики?

T>Если да, то сколько это у него занимает. Если нет, то чего он требует от других языков того, что сам не делает?

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

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

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

T>>>"Был неправ, вспылил. Раскаиваюсь, прошу разрешения загладить, искупить."
T>>>Это он, по-моим расчётам, положил на это чудо не менее двух или трёх недель.
T>>>У меня на .BAT файлах (ну, CMD — под OS/2) это столько и заняло — две недели. На тикле вдвое быстрее.
FR>>Угу любая программа пишется хорошим программистом за два дня, в худшем случае за пару недель.
FR>>Правда авторы аналогов того что написал eao197 об этом не знают и годами пишут свои scons'ы

T>Они их пишут годами потому, что 1) тяжело тестировать, 2) надо поддерживать всех на свете, 3) ЯП дурацкий и ещё много причин.



Жалко, что такая причина как "этими продуктами пользуются" вошла в категорию "еще много причин". Видимо, из-за своей мелочности.

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

T>Они их пишут годами потому, что 1) тяжело тестировать, 2) надо поддерживать всех на свете, 3) ЯП дурацкий и ещё много причин.

Реальна только вторая причина.

T>Могу сказать с уверенностью, что больше 5% своего рабочего времени никто на такую ерунду не тратит. За исключением запущенных случаев, но это в очень больших софтверных компаниях.

T>Я, собственно, справился быстро потому, что упёрся рогом. Потом мы катались на первом сборщике два года. Как раз те самые ~2% рабочего времени.

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

T>Всё, перехожу на ноут (придётся купить), ставлю Линукс (придётся ставить), ocaml (придётяс отказаться от современного синтаксиса) и OcaIDE (придётся отказаться от произвольной структуры проекта).

T>Буду тащиться.

Не стоит, я думаю ты без проблем все что нужно и отладчик и IDE за пару недель напишешь.

Здравствуйте, kaa.python, Вы писали:
...
KP>Логи? В принципе, для отладки любого приложения этого достаточно, при умении ими пользоваться, конечно.

Конечно, достаточно. И для любого приложения, кто бы спорил. Но с отладчиком бывает в разы быстрее. Все очень сильно зависит от приложения.

Мне приходилось кодить без отладчика (мэйнфреймы, разработка плагинов, скрипты). Случалось, например, делать так: часть кода писалась и отлаживалпсь на писюке в VS, потом, уже готовая, перетаскивалась куда надо. Эффективность существенно повышалась, в значительной степени благодаря отладчику. It сильно depends...

И в конце концов, отладчик ведь никому не мешает. Пусть будет .

T>>Они их пишут годами потому, что 1) тяжело тестировать, 2) надо поддерживать всех на свете, 3) ЯП дурацкий и ещё много причин.
FR>Реальна только вторая причина.

Весомы все три, в перечисленном мной порядке.

Сборка происходит медленно, ошибки в ней ловить тяжело.

У всех разные запросы, их надо свести воедино.

Всё это осложняется идиосинкразиями ЯП.

T>>Могу сказать с уверенностью, что больше 5% своего рабочего времени никто на такую ерунду не тратит. За исключением запущенных случаев, но это в очень больших софтверных компаниях.
T>>Я, собственно, справился быстро потому, что упёрся рогом. Потом мы катались на первом сборщике два года. Как раз те самые ~2% рабочего времени.
FR>Все-таки похоже ты не понимаешь как и многие хаскелисты разницы между продуктом и тулзой для внутреннего использования. От этого похоже и явное преувеличение важности языка.

Объясняй.

T>>Всё, перехожу на ноут (придётся купить), ставлю Линукс (придётся ставить), ocaml (придётяс отказаться от современного синтаксиса) и OcaIDE (придётся отказаться от произвольной структуры проекта).
T>>Буду тащиться.

FR>Не стоит, я думаю ты без проблем все что нужно и отладчик и IDE за пару недель напишешь.

Нет, не напишу, поскольку буду занят использованием ЯП в моих гнусных целях. Поэтому придётся копить деньги на ноутбук и далее по списку.

T>>>>Это он, по-моим расчётам, положил на это чудо не менее двух или трёх недель.
T>>>>У меня на .BAT файлах (ну, CMD — под OS/2) это столько и заняло — две недели. На тикле вдвое быстрее.
FR>>>Угу любая программа пишется хорошим программистом за два дня, в худшем случае за пару недель.
FR>>>Правда авторы аналогов того что написал eao197 об этом не знают и годами пишут свои scons'ы

T>>Они их пишут годами потому, что 1) тяжело тестировать, 2) надо поддерживать всех на свете, 3) ЯП дурацкий и ещё много причин.

E>

E>Жалко, что такая причина как "этими продуктами пользуются" вошла в категорию "еще много причин". Видимо, из-за своей мелочности.

Она во второй находится, нет?

T>>Это всё в глазах наблюдателя.
E>Отрадно, что ты это понимаешь. Остается надежда, что этот же аргумент ты когда-нибудь научишься применять к себе.

Так я уже!

Я почти идеальный наблюдатель — достаточно сферический, а на расстоянии в 1-3 нм от поверхности моего тела царит, практически, вакуум. Достаточно сферический и практически в вакууме. Чего ещё желать?

E>В одном из проектов используется специализированный язык для алгоритмической обработки потоков данных (в языке реализованны конструкции if и switch). Пользователи просят средства отладки даже не смотря на то, что программы на этом языке имеют очень небольшой объем и сложность. Пока средства отладки -- это специально добавленная в язык конструкция trace и автономный интерпритатор языка для имитации потоков данных. Со временем, похоже, придется делать пошаговый отладчик.

Понятно.

Поменять язык как-либо в сторону большей декларативности невозможно почему именно? (если что, то мне действительно интересно)

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

T>Она во второй находится, нет?

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

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


T>>>Могу сказать с уверенностью, что больше 5% своего рабочего времени никто на такую ерунду не тратит. За исключением запущенных случаев, но это в очень больших софтверных компаниях.
T>>>Я, собственно, справился быстро потому, что упёрся рогом. Потом мы катались на первом сборщике два года. Как раз те самые ~2% рабочего времени.
FR>>Все-таки похоже ты не понимаешь как и многие хаскелисты разницы между продуктом и тулзой для внутреннего использования. От этого похоже и явное преувеличение важности языка.

T>Объясняй.

По моему бесполезно

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

Это можно толковать двояко: либо я (и другие приверженцы ФП) тупы, либо ты не умеешь объяснять.

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

Исключительно же ради того же торжества истины я отмечу, что ФП ассоциируется с большими вложениями умственного труда.

PS
Ещё есть третий вариант: ты боишься сменить точку зрения в процессе объяснения, а твоя текущая точка зрения как-то связана с получаемыми тобой на работе плюсами. Самое простое: ты боишься в процессе объяснения разобраться в своём понимании настолько, что твоя работа покажется тебе унылым и скучным забиванием гвоздей меховым тапочком.

Но я побоялся его предложить, Он довольно обиден. Поэтому и не предлагаю.

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

T>Поменять язык как-либо в сторону большей декларативности невозможно почему именно? (если что, то мне действительно интересно)

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

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

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

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

FR>>По моему бесполезно

T>Это можно толковать двояко: либо я (и другие приверженцы ФП) тупы, либо ты не умеешь объяснять.

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

T>Исключительно ради торжества истины. А то пришедший со стороны человек может не понять, что можно понимать по-разному.

T>Исключительно же ради того же торжества истины я отмечу, что ФП ассоциируется с большими вложениями умственного труда.

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

T>PS
T>Ещё есть третий вариант: ты боишься сменить точку зрения в процессе объяснения, а твоя текущая точка зрения как-то связана с получаемыми тобой на работе плюсами. Самое простое: ты боишься в процессе объяснения разобраться в своём понимании настолько, что твоя работа покажется тебе унылым и скучным забиванием гвоздей меховым тапочком.

T>Но я побоялся его предложить, Он довольно обиден. Поэтому и не предлагаю.

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

FR>>>По моему бесполезно
T>>Это можно толковать двояко: либо я (и другие приверженцы ФП) тупы, либо ты не умеешь объяснять.
FR>Нет, совсем другое, извини за грубость, но ты сейчас токуешь, и не видишь вокруг ничего, объяснять
FR>что-то хоть чуть-чуть не совпадающее с его мнением человеку в таком состоянии абсолютно бесполезно

Возьми на себя труд, объясни.

Мне это может и не помочь, а вот кому другому, читающему наше общение, поможет.

Не думай обо мне, короче. Think about children.

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

Зависимо.

Если бы было "независимо" то мы бы до сих продукты писали на ассемблере, а то и в автокоде.

Зачем тогда такое количество технологий-то?

И ещё раз: чем же прототип отличается от продукта?

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

T>Возьми на себя труд, объясни.

T>Мне это может и не помочь, а вот кому другому, читающему наше общение, поможет.

T>Не думай обо мне, короче. Think about children.

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

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

T>Зависимо.

T>Если бы было "независимо" то мы бы до сих продукты писали на ассемблере, а то и в автокоде.

Как раз малозависимо. Да на каких то языках проще делать прототипы. Но необязательно на них же
будет проще писать и уконечную систему.

T>Зачем тогда такое количество технологий-то?

T>И ещё раз: чем же прототип отличается от продукта?

Тем что в нем нет тех мелочей на которые реально приходится 90% работы.

T>>Возьми на себя труд, объясни.
T>>Мне это может и не помочь, а вот кому другому, читающему наше общение, поможет.
T>>Не думай обо мне, короче. Think about children.
FR>Я раньше довольно много делал сборок с помощью scons от простеньких утилиток до вполне приличных
FR>библиотек, поэтому волей не волей разбирался как оно работает и лазил в потрохах и хотя бы представляю
FR>себе сложность задачи, хотя сам системы сборки (кроме bat файлов как и ты) не писал. Поэтому твои
FR>заявления о двух неделях ничего кроме ухмылки у меня вызвать не могут.

Это нормально. Я преувеличивал для достижения нужного эффекта.

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

FR>>>того что если скажем прототип пишется за неделю, то продукт на его основе несколько месяцев, независимо от используемых технологий.
T>>Зависимо.
T>>Если бы было "независимо" то мы бы до сих продукты писали на ассемблере, а то и в автокоде.
FR>Как раз малозависимо. Да на каких то языках проще делать прототипы. Но необязательно на них же
FR>будет проще писать и уконечную систему.

"Малозависимо" звучит гораздо лучше. Это не категоричное "незавосимо".

Дальше я педалировать не буду, и так неплохо.

T>>И ещё раз: чем же прототип отличается от продукта?
FR>Тем что в нем нет тех мелочей на которые реально приходится 90% работы.

Сейчас, сейчас... Сейчас... Сейчас...

Ссылки не нашёл, привожу по памяти: "90% объёма программного проекта требует на своё создание 90% времени. Оставшиеся 10% требуют на своё создание оставшиеся 90% времени."

Итак, на доводку прототипа (оставшиеся 10%) нам требуется 90% времени. Значит, на создание прототипа мы уже потратили первые 90% времени! Это означает, что написав прототип за пяток недель, за оставшиеся пять недель мы получим готовый продукт!

Ура, товарищи!

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

T>Это нормально. Я преувеличивал для достижения нужного эффекта.

Несолидно. После этого и заявления о преимуществах ФП также будут казатся преувеличенными.

T>А то меня все построить пытаются, вот я и сопротивляюсь. Они мне с козырей "система сборки", а у меня перевод готов "я тоже за пару недель справился".

Что-то мне кажется что ты сам тут всех больше строить пытаешся

T>"Малозависимо" звучит гораздо лучше. Это не категоричное "незавосимо".

Ну категоричность она присуща функциональщикам, у них левое полушарие обычно гипертрофированно

T>>>И ещё раз: чем же прототип отличается от продукта?
FR>>Тем что в нем нет тех мелочей на которые реально приходится 90% работы.

T>Сейчас, сейчас... Сейчас... Сейчас...

T>Ссылки не нашёл, привожу по памяти: "90% объёма программного проекта требует на своё создание 90% времени. Оставшиеся 10% требуют на своё создание оставшиеся 90% времени."

T>Итак, на доводку прототипа (оставшиеся 10%) нам требуется 90% времени. Значит, на создание прототипа мы уже потратили первые 90% времени! Это означает, что написав прототип за пяток недель, за оставшиеся пять недель мы получим готовый продукт!

Не я конечно уважаю и иронию и юмор с сатирой, но переигрываешь

T>>Это нормально. Я преувеличивал для достижения нужного эффекта.
FR>Несолидно. После этого и заявления о преимуществах ФП также будут казатся преувеличенными.

То есть, противникам сторонников ФЯ можно заявлять о преувеличенных подвигах на почве DSEL?

Ещё раз.

Я боролся с образом "подвига". Ни один из DS(E)L eao я не считаю достаточно героическим. Основное его преимущество в наличии PDF про это дело при наличии отсутствия PDF у меня. Сама же техническая сторона ни рыба, ни мясо. Повторение не раз пройденного.

T>>А то меня все построить пытаются, вот я и сопротивляюсь. Они мне с козырей "система сборки", а у меня перевод готов "я тоже за пару недель справился".
FR>Что-то мне кажется что ты сам тут всех больше строить пытаешся

Да ты что!

Я при всём желании не смогу. Вас всех очень много.

T>>"Малозависимо" звучит гораздо лучше. Это не категоричное "незавосимо".
FR>Ну категоричность она присуща функциональщикам, у них левое полушарие обычно гипертрофированно

По тестам я весьма сбалансирован. Почему я и не могу работать с музыкой.

T>>Итак, на доводку прототипа (оставшиеся 10%) нам требуется 90% времени. Значит, на создание прототипа мы уже потратили первые 90% времени! Это означает, что написав прототип за пяток недель, за оставшиеся пять недель мы получим готовый продукт!

FR>Не я конечно уважаю и иронию и юмор с сатирой, но переигрываешь

Исключительно ради повеселить.

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

T>Я боролся с образом "подвига". Ни один из DS(E)L eao я не считаю достаточно героическим. Основное его преимущество в наличии PDF про это дело при наличии отсутствия PDF у меня. Сама же техническая сторона ни рыба, ни мясо. Повторение не раз пройденного.

Странное у тебя восприятие, я никакого "образа подвига" не увидел.
Ты же вроде тоже бывший фортер, так что DSL должно быть для тебя обыденной, рутиной вещью.

FR>>Что-то мне кажется что ты сам тут всех больше строить пытаешся

T>Да ты что!

T>Я при всём желании не смогу. Вас всех очень много.

Не это ты расшалился, даже полуфункциональщики вроде меня начали накидыватся

FR>>Ну категоричность она присуща функциональщикам, у них левое полушарие обычно гипертрофированно

T>По тестам я весьма сбалансирован. Почему я и не могу работать с музыкой.

Вот тут не понял, раскрой.

T>>Я боролся с образом "подвига". Ни один из DS(E)L eao я не считаю достаточно героическим. Основное его преимущество в наличии PDF про это дело при наличии отсутствия PDF у меня. Сама же техническая сторона ни рыба, ни мясо. Повторение не раз пройденного.
FR>Странное у тебя восприятие, я никакого "образа подвига" не увидел.
FR>Ты же вроде тоже бывший фортер, так что DSL должно быть для тебя обыденной, рутиной вещью.

Именно.

FR>>>Что-то мне кажется что ты сам тут всех больше строить пытаешся
T>>Да ты что!
T>>Я при всём желании не смогу. Вас всех очень много.
FR>Не это ты расшалился, даже полуфункциональщики вроде меня начали накидыватся

Где?

FR>>>Ну категоричность она присуща функциональщикам, у них левое полушарие обычно гипертрофированно
T>>По тестам я весьма сбалансирован. Почему я и не могу работать с музыкой.
FR>Вот тут не понял, раскрой.

Музыка задействует правое полушарие, отключая интуицию и чувства. Забирает их на себя. А для меня это всё очень важно.

Это в Peopleware описано. Вот тут я кусочек цитировал: http://thesz.livejournal.com/446422.html

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

FR>>Не это ты расшалился, даже полуфункциональщики вроде меня начали накидыватся

T>Где?

http://gzip.rsdn.ru/forum/message/3313869.flat.1.aspx

Автор: thesz
Дата: 04.03.09

T>Музыка задействует правое полушарие, отключая интуицию и чувства. Забирает их на себя. А для меня это всё очень важно.

Музыка она разная бывает, ритмичная запросто и левое может забить

T>Это в Peopleware описано. Вот тут я кусочек цитировал: http://thesz.livejournal.com/446422.html

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

T>>Где?
FR>http://gzip.rsdn.ru/forum/message/3313869.flat.1.aspx

Автор: thesz
Дата: 04.03.09

Слишком широко. Толком не видно.

T>>Музыка задействует правое полушарие, отключая интуицию и чувства. Забирает их на себя. А для меня это всё очень важно.
FR>Музыка она разная бывает, ритмичная запросто и левое может забить

Правое забивает любая.

T>>Это в Peopleware описано. Вот тут я кусочек цитировал: http://thesz.livejournal.com/446422.html
FR>На меня кстати похоже действует, в тишине я лучше работаю, но если в работу реально уходишь то уже просто ничего вокруг не видно и не слышно

Это когда кодирование.

Ровно противоположное "избежать кодирования".

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

KP>А он вообще нужен? Лично для меня, необходимость в отладчике очч спорный момент. Если он есть, это безусловно хорошо, но если его нет, то логов всегда достаточно. А если еще и библиотека логирования хорошая, то отладчик скорее будет лишним

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

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

T>Слишком широко. Толком не видно.

Нормально видно

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

T>Это когда кодирование.

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

T>Ровно противоположное "избежать кодирования".

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

T>>Слишком широко. Толком не видно.
FR>Нормально видно

Мне видно, что никто на тебя не нападал.

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

Великолепно.

Сперва надо сказать нет, а потом повторить своими словами высказанное оппонентом.

Великолепно, повторюсь.

T>>Ровно противоположное "избежать кодирования".
FR>Угу, это интересное развлечение, но очень часто "хорошо подумать, написать короткий красивый код" по времени и результату одинаково с "думать некогда, кодировать кодировать и кодировать"

После чего приходят изменения и выигрыш становится виден.

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

T>Мне видно, что никто на тебя не нападал.

А я тут при чем?
Я вроде тихо мирно веду беседу никого ни трогая

T>Великолепно.

T>Сперва надо сказать нет, а потом повторить своими словами высказанное оппонентом.

T>Великолепно, повторюсь.

Тьфу запутал ты меня окончательно


T>>>Ровно противоположное "избежать кодирования".
FR>>Угу, это интересное развлечение, но очень часто "хорошо подумать, написать короткий красивый код" по времени и результату одинаково с "думать некогда, кодировать кодировать и кодировать"

T>После чего приходят изменения и выигрыш становится виден.

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

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

T>Зачем мне ускорять отладку программ на Си, если я могу взять OCaml без отладчика и всё равно оказаться быстрей?

T>Неужто непонятно такое простое соображение?

Что-то мне логика здесь не понятна. А что именно мы собираемся отлаживать? Если ошибки интерпретации памяти искать — это одно, а если надо сам алгоритм отлаживать, то пофиг на каком языке было написано, в случае той самой алгоритмической ошибки. Даже абсолютно правильно реализованный алгоритм, скажем, обработки сигналов, может выкидывать фортели на некоторых данных из-за банального переполнения. А вот в уже приведённом примере использования третьесторонних библиотек, да еще если дока не полна или, как бывает, расхождения док-ции и реального поведения, то тут без отладки в любом виде никак.

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


FR>Ты же вроде тоже бывший фортер, так что DSL должно быть для тебя обыденной, рутиной вещью.

Кстати, никто не пробовал делать компилятор форта для управляемых платформ на основе родного стека? Там заморока в том, что верификатор не пропускает, если состояние стека на начало и конец ф-ии не идентично, однако же можно подавить саму верификацию.

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

T>>Зачем мне ускорять отладку программ на Си, если я могу взять OCaml без отладчика и всё равно оказаться быстрей?
T>>Неужто непонятно такое простое соображение?
V>Что-то мне логика здесь не понятна. А что именно мы собираемся отлаживать? Если ошибки интерпретации памяти искать — это одно, а если надо сам алгоритм отлаживать, то пофиг на каком языке было написано, в случае той самой алгоритмической ошибки. Даже абсолютно правильно реализованный алгоритм, скажем, обработки сигналов, может выкидывать фортели на некоторых данных из-за банального переполнения. А вот в уже приведённом примере использования третьесторонних библиотек, да еще если дока не полна или, как бывает, расхождения док-ции и реального поведения, то тут без отладки в любом виде никак.

Эх, молодёжь!

На 640K банкомата, что ought to be enough for everyone, даже td386 не запускался, если не говорить о количестве трудов, которых стоило его туда занести.

Программа могла внести — и вносила, — любые ошибки в работу "третьесторонних библиотек" вендора.

Так что я предпочту другой язык, пусть даже с подкачкой ручками, чем Си с отладчиком.

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


V>Я тут как-то высказывал мысли о возможности сделать типобезопасный форт с явной аннотацией состояний стека, а алгоритм верификации этих состояний в процессе компиляции вполне прост. Так что, если есть интерес, можно пообсуждать.

Вроде такие форты уже есть например http://factorcode.org/

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

T>Эх, молодёжь!

Самокритика?

T>На 640K банкомата, что ought to be enough for everyone, даже td386 не запускался, если не говорить о количестве трудов, которых стоило его туда занести.

На 16 Кб у нас форт с трасировщиком вполне помещался.
А на 48 и с отладчиком и монитором.

T>>Эх, молодёжь!
FR>Самокритика?

Типа того.

T>>На 640K банкомата, что ought to be enough for everyone, даже td386 не запускался, если не говорить о количестве трудов, которых стоило его туда занести.

FR>На 16 Кб у нас форт с трасировщиком вполне помещался.
FR>А на 48 и с отладчиком и монитором.

Сколько разработчиков было? Ты, да я, да мы с тобой, итого четверо?

V>Я тут как-то высказывал мысли о возможности сделать типобезопасный форт с явной аннотацией состояний стека, а алгоритм верификации этих состояний в процессе компиляции вполне прост. Так что, если есть интерес, можно пообсуждать.

Наш пострел везде поспел: http://thesz.livejournal.com/923822.html

Действительно, ничего сложного большую часть времени.

Но иногда!

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

FR>>На 16 Кб у нас форт с трасировщиком вполне помещался.
FR>>А на 48 и с отладчиком и монитором.

T>Сколько разработчиков было? Ты, да я, да мы с тобой, итого четверо?

Фортеры они любят гордое одиночество
Потом правда двое стало.

T>>Сколько разработчиков было? Ты, да я, да мы с тобой, итого четверо?
FR>Фортеры они любят гордое одиночество
FR>Потом правда двое стало.

В общем, у нас проект был посложней.

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

E>Да, действительно, все просто. Достаточно пописать под большое количество платформ чтобы понять, что нет никакой доблести в отрицании отладчика.

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

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

T>Эх, молодёжь!
T>На 640K банкомата, что ought to be enough for everyone, даже td386 не запускался, если не говорить о количестве трудов, которых стоило его туда занести.

Т.е., кто с банкомётами не работал, тот автоматом молодёжь? Занятно, но постолько-поскольку...

T>Программа могла внести — и вносила, — любые ошибки в работу "третьесторонних библиотек" вендора.
T>Так что я предпочту другой язык, пусть даже с подкачкой ручками, чем Си с отладчиком.

Я здесь не могу разглядеть ответа насчёт использования третьесторонних либ. Ты предлагаешь ими не пользоваться вообще?

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

FR>На 16 Кб у нас форт с трасировщиком вполне помещался.
FR>А на 48 и с отладчиком и монитором.

"а вот у нас"
У нас в 4к на x51 вполне влазили программа, причем, программа переносила сама себя из готовой форт-программы под ДОС-ом в целевую архитектуру (указывали стартовое слово, далее все зависимые высокоуровневые паковались для этой архитектуры в прошиваемый образ). Ввиду отсутствия всяких мощных сред разработки, это была единственная альтернатива ассемблеру.

T>>Эх, молодёжь!
T>>На 640K банкомата, что ought to be enough for everyone, даже td386 не запускался, если не говорить о количестве трудов, которых стоило его туда занести.
V>Т.е., кто с банкомётами не работал, тот автоматом молодёжь? Занятно, но постолько-поскольку...

"Молодёжь" это к тому, что отлаживать рвёшься.

Алгоритмические ошибки без отладчика ловятся на раз. Усилю утверждение, сказав, что ловля алгоритмических ошибок отладчиком — потеря времени.

T>>Программа могла внести — и вносила, — любые ошибки в работу "третьесторонних библиотек" вендора.
T>>Так что я предпочту другой язык, пусть даже с подкачкой ручками, чем Си с отладчиком.
V>Я здесь не могу разглядеть ответа насчёт использования третьесторонних либ. Ты предлагаешь ими не пользоваться вообще?

Только написанных на чистом ФЯ.

Всё остальное себе дороже.

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

T>Алгоритмические ошибки без отладчика ловятся на раз. Усилю утверждение, сказав, что ловля алгоритмических ошибок отладчиком — потеря времени.

Не боишься подставиться столь громкими заявлениями? Попробуешь доказать свои слова? Учитывая, что цель любой отладки в первую очередь в локализации ошибок, мне даже интересно, что же ты себе там надумал, что выдал столь суровое утверждение.

Еще сдаёся мне, что у тебя поверхностное представление о том, как твои коллеги организуют отладку и для каких целей. А учитывая размеры современных проектов, к тому же откровенной глупостью и шапкозакидательством отдаёт. (на всякий случай: тему "тесты vs отладка" — поднимать не надо)


T>Только написанных на чистом ФЯ.
T>Всё остальное себе дороже.

Угу, как это знакомо. Наивная вера в Деда Мороза и прочие серебрянные пули. В ООП подобная истерия была одно время вокруг паттернов проектирования. Не в корень зришь. Кач-во библиотек не столько от технологии зависит, сколько от мастерства разработчиков (от архитектора до программистов). Кривой дизайн библиотеки или несоответствие документации никакое ФП не спасёт. Подходы, обеспечивающие приемлимое кач-во программного продукта, универсальны и одинаково работают как для ООП, так и для ФП, так и для всевозможных еще не изобретённых ххП.


P.S. К тому же, все в курсе, что гнутый компилятор Хаскеля до сих пор содержит прорву багов, отчего народ и не собирается пока что им пользоваться в серьёзных продуктах (так же как и Немерле). Так он и ходит на уровне языка для экспериментов и написания тулзин локального использования. Писать на этом "мегаязыке" со встроенными утечками памяти программы для банкоматов — увольте.

T>>Алгоритмические ошибки без отладчика ловятся на раз. Усилю утверждение, сказав, что ловля алгоритмических ошибок отладчиком — потеря времени.
V>Не боишься подставиться столь громкими заявлениями? Попробуешь доказать свои слова? Учитывая, что цель любой отладки в первую очередь в локализации ошибок, мне даже интересно, что же ты себе там надумал, что выдал столь суровое утверждение.

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

V>Еще сдаёся мне, что у тебя поверхностное представление о том, как твои коллеги организуют отладку и для каких целей. А учитывая размеры современных проектов, к тому же откровенной глупостью и шапкозакидательством отдаёт. (на всякий случай: тему "тесты vs отладка" — поднимать не надо)

"Размеры современных проектов"

Скажи лучше, плохая структуризация современных проектов. Ничего отрезать невозможно.

T>>Только написанных на чистом ФЯ.
T>>Всё остальное себе дороже.
V>Угу, как это знакомо. Наивная вера в Деда Мороза и прочие серебрянные пули. В ООП подобная истерия была одно время вокруг паттернов проектирования. Не в корень зришь. Кач-во библиотек не столько от технологии зависит, сколько от мастерства разработчиков (от архитектора до программистов). Кривой дизайн библиотеки или несоответствие документации никакое ФП не спасёт. Подходы, обеспечивающие приемлимое кач-во программного продукта, универсальны и одинаково работают как для ООП, так и для ФП, так и для всевозможных еще не изобретённых ххП.

Дорогой друг, какое конкретно количество строк написал ты или любой твой коллега на любом ФЯ?

Если это количество больше 100, я продолжу спор, но уже доказательно. Если меньше, то поверь мне на слово — ты не прав. Ты просто не в курсе, как нельзя накосячить на ФЯ.

V>P.S. К тому же, все в курсе, что гнутый компилятор Хаскеля до сих пор содержит прорву багов, отчего народ и не собирается пока что им пользоваться в серьёзных продуктах (так же как и Немерле). Так он и ходит на уровне языка для экспериментов и написания тулзин локального использования. Писать на этом "мегаязыке" со встроенными утечками памяти программы для банкоматов — увольте.

G не означает GNU.

После этого параграфа, пожалуй, я буду настаивать, чтобы ты поверил мне на слово.

За более, чем 10 лет использования Хаскеля, я столкнулся всего с двумя ошибками: проблемы рантайма под windows в ghc 6.6 (ограничение сверху на хип) и, недавно, совершенно не критичная ошибка с отсутствие поддержки семейств типов в template haskell.

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

VD>Ссылаясь надо не забывать цитаты приводить. А то вы так бедных авторитетов переврете, что они после смерти в гробу ворочаться будут .

Ну вообще-то стыдно об этом не знать, это же классика

VD>Вообще, программировать с отладчиком — это само по себе нонсенс. Отлачик средство поиска ошибок, а не средство разработки. Если ошибки — милости просим в отладчик. Нет, так и нужды в нем нет.

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

T>>Зачем мне ускорять отладку программ на Си, если я могу взять OCaml без отладчика и всё равно оказаться быстрей?

T>>Неужто непонятно такое простое соображение?

V>Что-то мне логика здесь не понятна. А что именно мы собираемся отлаживать?
V>третьесторонних библиотек, да еще если дока не полна или, как бывает, расхождения док-ции и реального поведения, то тут без отладки в любом виде никак.

У меня такое ошушение, что алгоритм, который в принципе можно пройти отладчиком — можно отлаживать просто методом пристального взглядывания.

Когда я, будучи школьником, писал демки — которые там что-то вычисляли в цикле из десятка параметров — то, если бы я пытался отлавливать глюки путем пошагового исполнения, так бы до сих пор и отлаживался, я думаю. Гораздо продуктивнее оказалось добавить логи и построить графики значений одних переменных в зависимости от других — разрывы и причина были найдены с первого взгляда на них. С тех пор и повелось.

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

dmz> Гораздо продуктивнее оказалось добавить логи

Тут часто говорят про логи вместо отладчика. А вот как происходит добавление логов в программы на Хаскеле? Там же должно быть до фига чистых функций, которые для добавления одной строчки вывода в лог придется оборачивать в хламидомонады, т.е. менять их тип, т.е. переписывать почти всю программу. Или есть простое решение?

DM>Тут часто говорят про логи вместо отладчика. А вот как происходит добавление логов в программы на Хаскеле? Там же должно быть до фига чистых функций, которые для добавления одной строчки вывода в лог придется оборачивать в хламидомонады, т.е. менять их тип, т.е. переписывать почти всю программу. Или есть простое решение?

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

dmz>Гы. Знал бы хаскелл — сказал. Из того, что я о нем знаю — это действительно может быть проблемой Кастую Summon thesz. Если получится — то он явится и разъяснит.

Но наверное, он скажет, что логи тоже не нужны. А программы на хаскеле правильные в силу типизации и чистоты.

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

DM>Тут часто говорят про логи вместо отладчика. А вот как происходит добавление логов в программы на Хаскеле? Там же должно быть до фига чистых функций, которые для добавления одной строчки вывода в лог придется оборачивать в хламидомонады, т.е. менять их тип, т.е. переписывать почти всю программу. Или есть простое решение?

import Debug.Trace

-- trace :: String -> a -> a

foo = trace "foo" (sum [1..10])

dmz>> Гораздо продуктивнее оказалось добавить логи
DM>Тут часто говорят про логи вместо отладчика. А вот как происходит добавление логов в программы на Хаскеле? Там же должно быть до фига чистых функций, которые для добавления одной строчки вывода в лог придется оборачивать в хламидомонады, т.е. менять их тип, т.е. переписывать почти всю программу. Или есть простое решение?

Программы на Хаскеле чистые и в них ошибок быть не может.

Обязательная часть выполнена, переходим к произвольной.

Если разрабатываем и лень гонять много REPL, то Debug.Trace. Некоторые продвинутые делают что-то на основе unsafePerformIO, это когда логов много.

Я предпочитаю протягивать логи через типы. Была функция a -> b, стала a -> (b,String).

Видно, что к чему.

T>Я предпочитаю протягивать логи через типы. Была функция a -> b, стала a -> (b,String).

Я правильно понимаю, что сообщение лога возвращается вместо исходного значения?
Это же может повлечь затычки в других частях, которые ожидают что a -> b, а не a -> (b,String)

Посмотреть бы реальный пример какой-нибудь.

T>>Я предпочитаю протягивать логи через типы. Была функция a -> b, стала a -> (b,String).
dmz>Я правильно понимаю, что сообщение лога возвращается вместо исходного значения?

Вместе с исходным.

dmz>Это же может повлечь затычки в других частях, которые ожидают что a -> b, а не a -> (b,String)

Да! Именно!

Мы вынуждены сказать, что здесь у нас логи, и добавить свою порцию, если надо.

dmz>Посмотреть бы реальный пример какой-нибудь.

Затруднюсь прямо сейчас.

dmz>Посмотреть бы реальный пример какой-нибудь.

#ifdef __LOGGING__
log :: a -> Log -> (a,Log)
log = (,)

addLog :: (a,Log) -> Log -> (a,Log)
addLog (a,l) l' = (a,l++l')

#define FROMLOG(v) v##logged(v,v##log)

#else
log :: a -> Log -> a
log = const

addLog :: a -> b -> a
addLog = const

#define FROMLOG(v) v##logged@v

#endif

...
f a b c = log r ["a" $$ a,"b" $$ b]
    where
        r = ...

g x y z = addLog blogged ["x" $$ x]
    where
        FROMLOG(b) = f a b c

Хак (плюс-минус, может не работать прям сразу, но идея, думаю, ясна).

Но работает.

Быстро работает, когда надо.

Практически, кусок практически настоящей системы.

dmz>>Посмотреть бы реальный пример какой-нибудь.

T>

T>#ifdef __LOGGING__
T>

Это сишный препроцессор, натравливаемый на исходники перед компиляцией настоящим компилятором?

dmz>>>Посмотреть бы реальный пример какой-нибудь.
T>>

T>>#ifdef __LOGGING__
T>>

dmz>Это сишный препроцессор, натравливаемый на исходники перед компиляцией настоящим компилятором?

Ага.

ghc -cpp -D__LOGGING__ -Iinclude -osuf log.o -hisuf log.hi ...
ghc -cpp -Iinclude ...

Такое требуется уже потом, когда нужна скорость. Я описал на случай, если потребуется.

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

DM>>Тут часто говорят про логи вместо отладчика. А вот как происходит добавление логов в программы на Хаскеле? Там же должно быть до фига чистых функций, которые для добавления одной строчки вывода в лог придется оборачивать в хламидомонады, т.е. менять их тип, т.е. переписывать почти всю программу. Или есть простое решение?

T>Программы на Хаскеле чистые и в них ошибок быть не может.

Да ладно, приоритеты операций можно перепутать где угодно и записать x*a+c вместо x*(a+c) на любом языке программирования. На функциональных, может быть, даже проще, т.к. функциональщики скобок не любят

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

T>Некоторые продвинутые делают что-то на основе unsafePerformIO, это когда логов много.

Или когда они нестандартные. У нас на icfpc2008 был gtrace :: String -> DrawObject -> a -> a, который выводил графические примитивы на карту. Причём анимацию, карта не мусорилась. Тоже для чистых функций, разумеется.

T>>Программы на Хаскеле чистые и в них ошибок быть не может.
E>Да ладно, приоритеты операций можно перепутать где угодно и записать x*a+c вместо x*(a+c) на любом языке программирования. На функциональных, может быть, даже проще, т.к. функциональщики скобок не любят

Приоритеты операций на Хаскеле отлично разделены и упорядочены и с ними ошибок быть не может.

(прошу прощения, удержаться не мог)

T>>Некоторые продвинутые делают что-то на основе unsafePerformIO, это когда логов много.
L>Или когда они нестандартные. У нас на icfpc2008 был gtrace :: String -> DrawObject -> a -> a, который выводил графические примитивы на карту. Причём анимацию, карта не мусорилась. Тоже для чистых функций, разумеется.

*сидит, немо отупевши*

Хотя это могло иметь смысл.

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

E>Иногда отладчик очень серьезно экономит время и силы.

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

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

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

Cтранно, вроде отвечал на это сообщение сразу же, "видимо что-то случилось" (C)

------------

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

Согласен, здесь "что-то не так" (используя печатные выражения).

T>Ну, задача у тебя такая — разработать алгоритм. Это означает, что его изначально нет или он описывается кругами разводимых рук.

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

T>"Размеры современных проектов"
T>Скажи лучше, плохая структуризация современных проектов. Ничего отрезать невозможно.

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

Сам этот заметный рост сложности проектов стал возможен только благодаря высокоуровневой поддержке ср-в разработки.

T>Дорогой друг, какое конкретно количество строк написал ты или любой твой коллега на любом ФЯ?

На Схеме несколько тысяч в своё время, включая сам мини-интерпретатор Схемы.

T>Если это количество больше 100, я продолжу спор, но уже доказательно. Если меньше, то поверь мне на слово — ты не прав. Ты просто не в курсе, как нельзя накосячить на ФЯ.

Знаю, но ты не то называешь косяком. Т.н. "косяки", связанные с низкоуровневыми ошибками, типа проходу по памяти, — это самый низкий процент ошибок в современных проектах, к тому же, эти места легко вычисляемые. Большинство ошибок (по моему опыту) — это именно ошибки алгоритмического плана. Вообще, надо признать, что вообще само по себе кол-во ошибок стало смехотворным на единицу строк кода в последние годы, ИМХО это от всё меньшей доли самописных велосипедов в проектах, даже на С++. (Еще лет 10 назад каждый проект состоял примерно на 80% из самописанины библиотечно-фреймворкового уровня). Рождая по 300-500 строк кода в день, никакой разработчик не в состоянии помнить подробности даже собственных творений уже спустя пару месяцев. "Тупой" код-ревью на таких объёмах банально не прокатывает для задачи локализации ошибок, юнит-тесты на все случаи не напишешь (да и не надо), поэтому нужны эффективные ср-ва для целей этой самой локализации. У нас в проекте VoIP, где всё происходит в динамике и точу останова не везде поставишь таким ср-вом является многоуровневое логгирование (т.е. регулируется вербальность логов по мере уточнения локации косяка).

T>За более, чем 10 лет использования Хаскеля, я столкнулся всего с двумя ошибками: проблемы рантайма под windows в ghc 6.6 (ограничение сверху на хип) и, недавно, совершенно не критичная ошибка с отсутствие поддержки семейств типов в template haskell.

Поражает даже не кол-во багов на треккере GHC, а их характер. Можешь объяснить наличие большого кол-ва низкоуровневых багов в треккере, учитывая, что сам компилятор написан на Хаскеле?

Т.е. ситуация такова, что сам этот момент у меня пока в голове не укладывается... Сам язык получился неплох, но от задумки до реализации, как известно...

А помогать им с отладкой... было бы ради чего — там помимо низкоуровневых, куча ошибок и логического плана и даже вывода типов. Вообще, кол-во багов поражает. Я как-то нашёл баг для библиотеки ADO.Net под MS SQL CE, запостил, мне сказали спасибо, дык баг был единственный (!!!) на всю либу. Просто сценарий у нас был, прямо скажем, далеко не рядовой (выжималка процессорных тиков для около-ИИ-темы). И вот я со своими далеко не рядовыми сценариями (где надо выжимать максимум из железки) полезу в Хаскель, начну его "выжимать" и он однозначно начнёт сыпаться. В общём, серьёзнее быть надо. Увлечение-увлечением, а дело надо делать сегодня на сегодняшних инструментах... Я даже любимый когда-то С/С++ не очень в критических местах юзал, ибо еще в 92-м нарвался подряд на 3 встроенных в Борландовский С++ бага в первом же более-менее крупном проекте, дособирали на ваткоме, но без IDE это было не то... После чего забросил C++ до 97-го года примерно, до выхода IDE от MS. Дальше рассказывать? На чём приличное кол-во внутренних тулзов у нас было сделано? На Форте и на VB for DOS. Про последний надо подробно, ибо к VB приклеился определённый образ у рунета. Так вот, вначале его использования я любил просматривать ассемблерный лог компиляции VB-программы (есть такая опция у компилятора), и должен сказать, что компилятор генерил прекрасный код. Мне, как ассемблерщику со стажем, по крайней мере очень нравилось. Везде, где раньше бы применялся Фортран (много было расчётных задач), мы юзали VB for DOS, благо и формы с кнопками быстро накидать можно было. В общем, рабочая лошадка, в которой нечему ломаться (и ни разу так ничего и не сломалось за 3 года плотного использования). Так что, к выбору инструментария у меня подход весьма прямолинейный — необходимо чтобы сам инструментарий не веселил своими причудами, ибо не до него.

T>>"Размеры современных проектов"
T>>Скажи лучше, плохая структуризация современных проектов. Ничего отрезать невозможно.
V>Т.е. наболело?
V>В своей команде вполне аргументировано ты можешь проталкивать необходимые улучшения модульной структуры, а здесь это суть гадание на кофейной куче и к процессу отладки относится мало. Большие размеры современных проектов — это объективная реальность, и эти размеры растут в последние годы очень быстро. Собс-но, для этого мы, программисты, и нужны, чтобы автоматизировать как можно больше аспектов человеческой деятельности.

Все они сравнимы по сложности с Emacs.

V>Сам этот заметный рост сложности проектов стал возможен только благодаря высокоуровневой поддержке ср-в разработки.

Да, разработка Emacs стала возможной благодаря Emacs.

T>>Дорогой друг, какое конкретно количество строк написал ты или любой твой коллега на любом ФЯ?
V>На Схеме несколько тысяч в своё время, включая сам мини-интерпретатор Схемы.
T>>Если это количество больше 100, я продолжу спор, но уже доказательно. Если меньше, то поверь мне на слово — ты не прав. Ты просто не в курсе, как нельзя накосячить на ФЯ.
V>Знаю, но ты не то называешь косяком. Т.н. "косяки", связанные с низкоуровневыми ошибками, типа проходу по памяти, — это самый низкий процент ошибок в современных проектах, к тому же, эти места легко вычисляемые.

Нет. Это ошибки типа "в этом if надо было проверить ещё и это условие".

Вот так в современном ФЯ (OCaml, Haskell, Clean) накосячить очень тяжело.

Схема не современный ФЯ.

T>>За более, чем 10 лет использования Хаскеля, я столкнулся всего с двумя ошибками: проблемы рантайма под windows в ghc 6.6 (ограничение сверху на хип) и, недавно, совершенно не критичная ошибка с отсутствие поддержки семейств типов в template haskell.
V>Поражает даже не кол-во багов на треккере GHC, а их характер. Можешь объяснить наличие большого кол-ва низкоуровневых багов в треккере, учитывая, что сам компилятор написан на Хаскеле?

Нет.

V>Т.е. ситуация такова, что сам этот момент у меня пока в голове не укладывается... Сам язык получился неплох, но от задумки до реализации, как известно...

Я пользуюсь, и ничего.

V>А помогать им с отладкой... было бы ради чего — там помимо низкоуровневых, куча ошибок и логического плана и даже вывода типов. Вообще, кол-во багов поражает. Я как-то нашёл баг для библиотеки ADO.Net под MS SQL CE, запостил, мне сказали спасибо, дык баг был единственный (!!!) на всю либу. Просто сценарий у нас был, прямо скажем, далеко не рядовой (выжималка процессорных тиков для около-ИИ-темы). И вот я со своими далеко не рядовыми сценариями (где надо выжимать максимум из железки) полезу в Хаскель, начну его "выжимать" и он однозначно начнёт сыпаться.

Алгоритмы надо выжимать, не железку.

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

Мы от разного хохочем.

Ты от количества багов, я от невозможности "вот это описать вот так кратко".

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

T>Да, разработка Emacs стала возможной благодаря Emacs.

Да ради бога, хоть Emacs, хоть Eclipse, хоть VS. (Не принципиально, хотя, нормального context-sensitive intellicense я в Emacs ни разу не видел, или что-то изменилось за последние лет 8?)


T>Нет. Это ошибки типа "в этом if надо было проверить ещё и это условие".
T>Вот так в современном ФЯ (OCaml, Haskell, Clean) накосячить очень тяжело.

Опять намёк на алгебраические типы?
Понимаешь, там где в ФЯ используют алгебраические типы и паттерн-матчинг, в ООП юзают гомоморфные иерархии (в случае compile-time для C++ уже показывал). Так что, если придеживаться принципу Лисков, никаких "забытых" if быть не может в принципе, ибо нету в проекте этих if, относящихся к логике системы типов. Есть только те if, которые относятся к значениям данных, но тут нам ФП ничем не поможет.

V>>Поражает даже не кол-во багов на треккере GHC, а их характер. Можешь объяснить наличие большого кол-ва низкоуровневых багов в треккере, учитывая, что сам компилятор написан на Хаскеле?

T>Нет.

Зря, вопрос про низкоуровневость багов — ключевой. И я знаю на него ответ, но он тебе не понравится.

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


V>>Сам язык получился неплох, но от задумки до реализации, как известно...
T>Я пользуюсь, и ничего.

Я не уверен, что ты используешь 100% возможностей языка, если, как ты сам говорил, ты его используешь в основном для утилит/экспериментов и т.д.

T>Алгоритмы надо выжимать, не железку.

А уже открыт другой способ выжимания?

Замечу лишь, что алгоритмы неотделимы от структуры данных. Иногда банальное уменьшение коссвенности вдвое даёт прирост вчетверо. Упомянутое особенно стало заметно последние несколько лет, всвязи с резким увеличением собственной выч. мощности процов относительно скорости внешней памяти. Как насчёт fixed-size arrays в Хаскель? Никак? А ты портируй, скажем, encoder speex на Хаскель (там сплошная математика, к тому же, тебе это небось пару вечеров) и замерь, что получилось. Обязательно сравни хотя бы на 4-х сотнях одновременно работающих этих кодеков, ибо вопрос использования памяти так же интересен (необязательно в разных тредах, просто по очереди чанки данных подавай для одновременно созданных объектов).

Мне даже его С-версию оптимизировать пришлось, ибо жрут кодировщики процессорные тики, это их фундаментальная природа.
Заодно мне интересно, сколько строк кода в итоге ты сэкономишь. А то сдаётся, что мы10%-20% при наилучшем раскладе, за счёт понижения производительности в разы. ИМХО, неприемлима пока эта цена в промышленных разработках.

ФП будет развиваться, это неплохая парадигма, которая (как и все прочие) хороша лишь на своём месте, а не в каждой дыре. Удачным станет тот подход, который в рамках проекта позволит гладко совмещать технологии (проекта с т.з. IT, а не компилятора). Предложенный сегодня способ безопасного совмещения — это интероперабельность на основе платформ Java и .Net. Хаскелю надо ветвиться в эту сторону, чтобы обрести возможность общение с внешним миром и стать полезным.

T>>Да, разработка Emacs стала возможной благодаря Emacs.
V>Да ради бога, хоть Emacs, хоть Eclipse, хоть VS. (Не принципиально, хотя, нормального context-sensitive intellicense я в Emacs ни разу не видел, или что-то изменилось за последние лет 8?)

Я тоже. Но я не видел его ни в какой другой среде.

T>>Нет. Это ошибки типа "в этом if надо было проверить ещё и это условие".
T>>Вот так в современном ФЯ (OCaml, Haskell, Clean) накосячить очень тяжело.
V>Опять намёк на алгебраические типы?
V>Понимаешь, там где в ФЯ используют алгебраические типы и паттерн-матчинг, в ООП юзают гомоморфные иерархии (в случае compile-time для C++ уже показывал). Так что, если придеживаться принципу Лисков, никаких "забытых" if быть не может в принципе, ибо нету в проекте этих if, относящихся к логике системы типов. Есть только те if, которые относятся к значениям данных, но тут нам ФП ничем не поможет.

Да брось ты!

При написании кода с глубоким заглядыванием наподобие нижеприведённого:

esimp (EMul a b) = case (esimp a, esimp b) of
    (EConst a,EMul (EConst b) c) -> esimp $ EMul (EConst $ a*b) c
    (EConst a,EMul b (EConst c)) -> esimp $ EMul (EConst $ a*c) b
    (a,b)
        | iszero a -> ezero
        | iszero b -> ezero
        | isone a -> b
        | isone b -> a
        | otherwise -> EMul a b

Ты замучаешься описывать это дело на системе типов C++. Либо жизнь на это положишь, либо будешь делать это в рантайме. И будешь ловить ошибки.

Или вот другой пример:

-------------------------------------------------------------------------------
-- Balin's pipelined sum acc.

balinF :: Maybe i -> Maybe i -> Maybe i -> (Maybe i,Maybe (i,i))
balinF oldAcc input loopback = (newAcc,output)
    where
        (newAcc,output) = case (oldAcc,input,loopback) of
            (acc,Just inp,Just lb) -> (acc,Just (inp,lb))
            (Just acc,Nothing,Just lb) -> (Nothing,Just (acc,lb))
            (Just acc,Just inp,Nothing) -> (Nothing,Just (acc,inp))
            (acc,Nothing,Nothing) -> (acc,Nothing)
            (_,inp,Nothing) -> (inp,Nothing)
            (_,_,lb) -> (lb,Nothing)

Сумматор имени Влада Балина aka Gaperton, функция автомата Мили. Что, сможешь сделать такую же таблицу решений? А в такое же количество строк?

V>>>Поражает даже не кол-во багов на треккере GHC, а их характер. Можешь объяснить наличие большого кол-ва низкоуровневых багов в треккере, учитывая, что сам компилятор написан на Хаскеле?
T>>Нет.
V>Зря, вопрос про низкоуровневость багов — ключевой. И я знаю на него ответ, но он тебе не понравится.
V>Есть такая наука о кач-ве ПО, так вот, ей глубоко плевать на ФП и на прочие технологии. Что характерно для аппологетов хаскеля на этом форуме, так это шапкозакидательсво и пренедрежительное отношение к коллегам. Некоторых даже банили за откровенное хамство. В реальной жизни поручить что-нибудь действительно важное разработчику, склонному к шапкозакидательству, это 100 раз подумать стоит. Если разработчик не понимает, что этапы анализа задачи и подходы, обеспечивающие кач-во ПО вообще не оперируют никакими технологиями, то такой разработчик, мягко говоря, под стол пешком еще ходит. Твоя реплика про "круги разводимых рук" была просто в точку, дальше можно было ничего не обсуждать.

Я не понял твоего абзаца практически совсем.

Он не несёт никакой информации. Что за наука? Что за шапкозакидательство? Бред какой-то.

Переведи его на нормальный язык.

V>>>Сам язык получился неплох, но от задумки до реализации, как известно...
T>>Я пользуюсь, и ничего.
V>Я не уверен, что ты используешь 100% возможностей языка, если, как ты сам говорил, ты его используешь в основном для утилит/экспериментов и т.д.

Да,я использую примерно 10-15% от всех возможностей Хаскеля. Языковых возможностей, конечно.

Сдались мне эти 100%. Мне ещё на что время потратить хочется.

T>>Алгоритмы надо выжимать, не железку.
V>А уже открыт другой способ выжимания?

Я не понял вопроса.

Если ты выжимаешь алгоритмы, то что ты про железки-то говоришь? Если ты выжимаешь железку, то мне как-то дальше неинтересно.

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

V>Замечу лишь, что алгоритмы неотделимы от структуры данных. Иногда банальное уменьшение коссвенности вдвое даёт прирост вчетверо. Упомянутое особенно стало заметно последние несколько лет, всвязи с резким увеличением собственной выч. мощности процов относительно скорости внешней памяти. Как насчёт fixed-size arrays в Хаскель? Никак? А ты портируй, скажем, encoder speex на Хаскель (там сплошная математика, к тому же, тебе это небось пару вечеров) и замерь, что получилось.

Нет, там не сплошная математика. Там математики всего ничего, в районе lsp.c. В том файле есть места практически квадратичные относительно lpcrdr (порядка lpcrdr*lpcrdr/2), да ещё и рекурсивно определённые, как я понимаю. Оный lpcrdr = 10 (lpcSize).

Для плавающей запятой это получается порядка 500 операций. Или ~3000 тактов. Параллелить смысла не имеет. Без распараллеливания Хаскель отстанет.

Я справился быстрее, чем за пару выходных. Но медленней, чем мне бы хотелось. И узнал о реализации speex больше, чем это нужно здоровому человеку. Ну, и ладно.

Вообще, speex написан плохо. Например, for (i=0;i<6;i++) без комментариев, объясняющих, что такое это 6. Функции длиной в 500-700 строк это не хорошо.

V>ФП будет развиваться, это неплохая парадигма, которая (как и все прочие) хороша лишь на своём месте, а не в каждой дыре. Удачным станет тот подход, который в рамках проекта позволит гладко совмещать технологии (проекта с т.з. IT, а не компилятора). Предложенный сегодня способ безопасного совмещения — это интероперабельность на основе платформ Java и .Net. Хаскелю надо ветвиться в эту сторону, чтобы обрести возможность общение с внешним миром и стать полезным.

Aye aye, sir!

Хаскель взял под козырёк и пошёл выполнять.

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

T>>>Да, разработка Emacs стала возможной благодаря Emacs.
V>>Да ради бога, хоть Emacs, хоть Eclipse, хоть VS. (Не принципиально, хотя, нормального context-sensitive intellicense я в Emacs ни разу не видел, или что-то изменилось за последние лет 8?)

T>Я тоже. Но я не видел его ни в какой другой среде.

А IntelliJ Idea ты видел?

http://www.jetbrains.com/idea/features/code_assistance.html

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

T>Да брось ты!
T>При написании кода с глубоким заглядыванием наподобие нижеприведённого:
...
T>Ты замучаешься описывать это дело на системе типов C++. Либо жизнь на это положишь, либо будешь делать это в рантайме. И будешь ловить ошибки.

1. А где (EMul b (EConst c), EConst a) -> ?
Вот тебе баг и язык тебе никак не помог — ибо прекрасно компилится без этой ветки, в которой выход на вторую половину ситуаций.

2. Еще косяки:
const1 * var1 * var2 * var3 * const2 — оптимизация возможна, но не будет произведена.
const1 * (var1 * const2) — оптимизация невозможна, но будет произведена.

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

3. Почему izzero и иже с ним проверяется после EConst? (просто любопытно)

4. На системе типов С++ прекрасно делается на частичной специализации.
Букв будет гораздо больше, в основном всвязи с тем, что в С++ шаблонность типов и ф-ий явно аннотировать надо, а в Хаскеле всё шаблонное по-умолчанию.


T>Или вот другой пример:
T>

T>-------------------------------------------------------------------------------
T>-- Balin's pipelined sum acc.

T>balinF :: Maybe i -> Maybe i -> Maybe i -> (Maybe i,Maybe (i,i))
T>balinF oldAcc input loopback = (newAcc,output)
T>    where
T>        (newAcc,output) = case (oldAcc,input,loopback) of
T>            (acc,Just inp,Just lb) -> (acc,Just (inp,lb))
T>            (Just acc,Nothing,Just lb) -> (Nothing,Just (acc,lb))
T>            (Just acc,Just inp,Nothing) -> (Nothing,Just (acc,inp))
T>            (acc,Nothing,Nothing) -> (acc,Nothing)
T>            (_,inp,Nothing) -> (inp,Nothing)
T>            (_,_,lb) -> (lb,Nothing)
T>

T>Сумматор имени Влада Балина aka Gaperton, функция автомата Мили. Что, сможешь сделать такую же таблицу решений? А в такое же количество строк?

Можно саму постановку задачи или пример использования этого кода?
В любом случае, уже сейчас видно, что основную логику в сравнимое кол-во строк впихнуть можно.
В хаскеле не спец, так что еще вопросы:
— что за Just?
— откуда в этой задаче ожидается Maybe/Nothing?


T>Я не понял твоего абзаца практически совсем.
T>Он не несёт никакой информации. Что за наука? Что за шапкозакидательство? Бред какой-то.

Ты хочешь сказать, что не слышал о существовании науки о качестве и дисциплины "управление качеством"? Фига се "бред"... В общем, спорить пока не имеет смысла, повторюсь лишь, что заявления, типа "ЯП такой-то сам по себе обеспечивает качество ПО" — это в раздел юмора сносить можно. Любой ЯП не в состоянии обеспечить более 1-2-х _нефункциональных_ требований. Гораздо больше нефункциональных требований способны обеспечить готовые библиотеки и фреймворки, а это уже как-то с языком постольку-поскольку связано. А уж про функциональные требования и ЯП в одном предложении упоминать — оксюморон, кроме случаев разработки повторно используемых библиотек под этот самый ЯП.


T>Да,я использую примерно 10-15% от всех возможностей Хаскеля. Языковых возможностей, конечно.
T>Сдались мне эти 100%.

Вот и я про то, что "я пользуюсь 10 лет, и ничего" меня не сильно убеждают на фоне простыни в трекере. Если использовать как основной язык в крупных проектах, то рано или поздно код крылом заденет практически 100% конструкций языка. Взять тот же Решарпер — трудно с ходу придумать ситуацию, в которой он слажает, но в более-менее крупных проектах находится сразу куча таких мест "сами по себе".



T>>>Алгоритмы надо выжимать, не железку.
V>>А уже открыт другой способ выжимания?

T>Я не понял вопроса.
T>Если ты выжимаешь алгоритмы, то что ты про железки-то говоришь? Если ты выжимаешь железку, то мне как-то дальше неинтересно.

Та блин, а как еще можно "выжимать железку", не вскрывая проца, кроме как через алгоритмы и структуры данных?


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

Во-первых, немного еще оптимизируется в основном за счёт выкидывания лишнего из длинных списков аргументов ф-ий. Сами вычисления оптимизировать там практически не куда (кроме явного указания float вместо умолчательного double в нескольких десятках мест). Если же ты уверен, что знаешь, как оптимизировать сам принцип кодирования сигнала — то немедленно сообщи на сайт... ибо speex на сегодня — один из наилучших по показателям кач-во/процессорные_тики. Там эхоподавитель еще сыроват (отдельный необязательный модуль), но кодировщик весьма неплох.


T>Для плавающей запятой это получается порядка 500 операций. Или ~3000 тактов. Параллелить смысла не имеет. Без распараллеливания Хаскель отстанет.

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


T>Я справился быстрее, чем за пару выходных. Но медленней, чем мне бы хотелось. И узнал о реализации speex больше, чем это нужно здоровому человеку. Ну, и ладно.

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

T>Функции длиной в 500-700 строк это не хорошо.

Это из-за ориентации на embedded и С, а он, в отличие от С++, инлайнинг и linked-time generation не умеет. В любом случае, эти строки — весьма просты, т.к. содержат практически одни вычисления.


T>Хаскель взял под козырёк и пошёл выполнять.

Не Хаскель, так другой, не принципиально. Случится смешная и грустная одновременно ситуация, когда ФП языки, худшие чем Хаскель, станут более популярны "по техническим причинам".

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

T>

T>esimp (EMul a b) = case (esimp a, esimp b) of
T>    (EConst a,EMul (EConst b) c) -> esimp $ EMul (EConst $ a*b) c
T>    (EConst a,EMul b (EConst c)) -> esimp $ EMul (EConst $ a*c) b
T>    (a,b)
T>        | iszero a -> ezero
T>        | iszero b -> ezero
T>        | isone a -> b
T>        | isone b -> a
T>        | otherwise -> EMul a b
T>

Кстати отличный образчик ущербности плоского пространства имен.
Префикс E/e везде лишний.

V>>>Да ради бога, хоть Emacs, хоть Eclipse, хоть VS. (Не принципиально, хотя, нормального context-sensitive intellicense я в Emacs ни разу не видел, или что-то изменилось за последние лет 8?)
T>>Я тоже. Но я не видел его ни в какой другой среде.
G>А IntelliJ Idea ты видел?

Нет, конечно.

G>http://www.jetbrains.com/idea/features/code_assistance.html

Это те же олухи, что и MPS?

T>>

T>>esimp (EMul a b) = case (esimp a, esimp b) of
T>>    (EConst a,EMul (EConst b) c) -> esimp $ EMul (EConst $ a*b) c
T>>    (EConst a,EMul b (EConst c)) -> esimp $ EMul (EConst $ a*c) b
T>>    (a,b)
T>>        | iszero a -> ezero
T>>        | iszero b -> ezero
T>>        | isone a -> b
T>>        | isone b -> a
T>>        | otherwise -> EMul a b
T>>

WH>Кстати отличный образчик ущербности плоского пространства имен.
WH>Префикс E/e везде лишний.

Давай то же самое в неплоском пространстве.

Даже удивительно, что ты не сделал это сразу.

T>>Да брось ты!
T>>При написании кода с глубоким заглядыванием наподобие нижеприведённого:
V>...
T>>Ты замучаешься описывать это дело на системе типов C++. Либо жизнь на это положишь, либо будешь делать это в рантайме. И будешь ловить ошибки.

V>1. А где (EMul b (EConst c), EConst a) -> ?
V>Вот тебе баг и язык тебе никак не помог — ибо прекрасно компилится без этой ветки, в которой выход на вторую половину ситуаций.

Это не баг.

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

AFAIR, esimp применялся после дифференцирования и я пришёл к выводу, что оно и так работает неплохо — всё, что надо упрощалось и группировалось.

V>2. Еще косяки:
V>const1 * var1 * var2 * var3 * const2 — оптимизация возможна, но не будет произведена.

У меня этого случая не встречалось. Я думал о решении, пришёл к выводу, что надо упорядочивать пары.

V>const1 * (var1 * const2) — оптимизация невозможна, но будет произведена.

Почему это она невозможна?

V>В общем, подобной задачкой я занимался в своей жизни неоднократно, приведённый код никуда не годится, ибо, при обработке арифметических и логических выражений не следует использовать бинарные AST, тут нужен банальный список одноуровневых аргументов.

Я и такой вариант рассматривал. Зависит. Да тот же gcc в пример привести. Там ушли с n-арных сложений-умножений на бинарные. Для упрощения.

Просто я планировал сделать генератор оптимизаторов, для двоичного дерева он удобней.

V>3. Почему izzero и иже с ним проверяется после EConst? (просто любопытно)

Так показалось удобней.

V>4. На системе типов С++ прекрасно делается на частичной специализации.
V>Букв будет гораздо больше, в основном всвязи с тем, что в С++ шаблонность типов и ф-ий явно аннотировать надо, а в Хаскеле всё шаблонное по-умолчанию.

ЧТД.

T>>Или вот другой пример:
T>>

T>>-------------------------------------------------------------------------------
T>>-- Balin's pipelined sum acc.

T>>balinF :: Maybe i -> Maybe i -> Maybe i -> (Maybe i,Maybe (i,i))
T>>balinF oldAcc input loopback = (newAcc,output)
T>>    where
T>>        (newAcc,output) = case (oldAcc,input,loopback) of
T>>            (acc,Just inp,Just lb) -> (acc,Just (inp,lb))
T>>            (Just acc,Nothing,Just lb) -> (Nothing,Just (acc,lb))
T>>            (Just acc,Just inp,Nothing) -> (Nothing,Just (acc,inp))
T>>            (acc,Nothing,Nothing) -> (acc,Nothing)
T>>            (_,inp,Nothing) -> (inp,Nothing)
T>>            (_,_,lb) -> (lb,Nothing)
T>>

T>>Сумматор имени Влада Балина aka Gaperton, функция автомата Мили. Что, сможешь сделать такую же таблицу решений? А в такое же количество строк?

V>Можно саму постановку задачи или пример использования этого кода?

Эта штука ставится перед конвейеризованным сумматором и выполняет роль накапливания суммы. На вход её может (Maybe i) придти число — очередной элемент суммируемого ряда. На вход "loopback" тоже может (Maybe i) придти число — очередная сумма. На выход она должна поставлять пары чисел на сложение, если таковая пара может быть образована.

Соответственно, она изредка (Maybe i) держит что-то в своём аккумуляторе oldAcc — если не удалось образовать пары на сложение.

Да. balinF отрабатывает потактово. newAcc этого такта придёт в oldAcc следующего.

V>В любом случае, уже сейчас видно, что основную логику в сравнимое кол-во строк впихнуть можно.

Даже бесконечно большее число строк будет сравнимо.

Здесь тебя спасают nullable types.

Если ты попробуешь без них, только на значениях, то будет гораздо интересней.

V>В хаскеле не спец, так что еще вопросы:
V>- что за Just?
V>- откуда в этой задаче ожидается Maybe/Nothing?

data Maybe a = Nothing | Just a

Maybe позникает из-за возможного отсутствия любого элемента.

T>>Я не понял твоего абзаца практически совсем.
T>>Он не несёт никакой информации. Что за наука? Что за шапкозакидательство? Бред какой-то.

V>Ты хочешь сказать, что не слышал о существовании науки о качестве и дисциплины "управление качеством"?

Как называется эта "наука о качестве"?

V>Фига се "бред"... В общем, спорить пока не имеет смысла, повторюсь лишь, что заявления, типа "ЯП такой-то сам по себе обеспечивает качество ПО" — это в раздел юмора сносить можно. Любой ЯП не в состоянии обеспечить более 1-2-х _нефункциональных_ требований.

Про теорию типов ты не слышал, так?

T>>Да,я использую примерно 10-15% от всех возможностей Хаскеля. Языковых возможностей, конечно.
T>>Сдались мне эти 100%.
V>Вот и я про то, что "я пользуюсь 10 лет, и ничего" меня не сильно убеждают на фоне простыни в трекере. Если использовать как основной язык в крупных проектах, то рано или поздно код крылом заденет практически 100% конструкций языка. Взять тот же Решарпер — трудно с ходу придумать ситуацию, в которой он слажает, но в более-менее крупных проектах находится сразу куча таких мест "сами по себе".

Стиль кодирования? Нет?

T>>То, что тебе пришлось работать с уже готовым алгоритмом, что не соптимизируешь, так это беда, а не повод для гордости.
V>Во-первых, немного еще оптимизируется в основном за счёт выкидывания лишнего из длинных списков аргументов ф-ий. Сами вычисления оптимизировать там практически не куда (кроме явного указания float вместо умолчательного double в нескольких десятках мест). Если же ты уверен, что знаешь, как оптимизировать сам принцип кодирования сигнала — то немедленно сообщи на сайт... ибо speex на сегодня — один из наилучших по показателям кач-во/процессорные_тики. Там эхоподавитель еще сыроват (отдельный необязательный модуль), но кодировщик весьма неплох.

Я знаю, как соптимизировать параллельный запуск многих speex одновременно.

T>>Для плавающей запятой это получается порядка 500 операций. Или ~3000 тактов. Параллелить смысла не имеет. Без распараллеливания Хаскель отстанет.
V>Ты не понял, параллелить единичный кодек смысла не имеет, разумеется. Мне было интересно сравнить одновременный запуск сотен кодеков. Учитывая, что входные данные подаются фиксированными порциями, эту "одновременность" можно сделать и в одном треде в цикле, в любом случае не имеет смысла делать больше тредов, чем ядер железки.

Заставите-таки. Займусь-таки.

Посмотрим, короче.

T>>Я справился быстрее, чем за пару выходных. Но медленней, чем мне бы хотелось. И узнал о реализации speex больше, чем это нужно здоровому человеку. Ну, и ладно.
V>Быстрее чем за пару выходных портировал и заставил работать все 3 режима кодека?

Быстрее, чем пару выходных я поняд, что оптимизировать на Хаскеле там нечего.

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

Это не код. Это соображения.

T>>Функции длиной в 500-700 строк это не хорошо.
T>>Хаскель взял под козырёк и пошёл выполнять.
V>Не Хаскель, так другой, не принципиально. Случится смешная и грустная одновременно ситуация, когда ФП языки, худшие чем Хаскель, станут более популярны "по техническим причинам".

"Avoid success at all costs" anyone?

T>>Да брось ты!
T>>При написании кода с глубоким заглядыванием наподобие нижеприведённого:
V>...
T>>Ты замучаешься описывать это дело на системе типов C++. Либо жизнь на это положишь, либо будешь делать это в рантайме. И будешь ловить ошибки.
V>1. А где (EMul b (EConst c), EConst a) -> ?
V>Вот тебе баг и язык тебе никак не помог — ибо прекрасно компилится без этой ветки, в которой выход на вторую половину ситуаций.

Вдогонку.

Смотри, сколько ты всего обнаружил!

Смог ли бы ты обнаружить столько же всего в коде на плюсах, размазанному по нескольким файлам?

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

V>>>>Да ради бога, хоть Emacs, хоть Eclipse, хоть VS. (Не принципиально, хотя, нормального context-sensitive intellicense я в Emacs ни разу не видел, или что-то изменилось за последние лет 8?)
T>>>Я тоже. Но я не видел его ни в какой другой среде.
G>>А IntelliJ Idea ты видел?

T>Нет, конечно.

G>>http://www.jetbrains.com/idea/features/code_assistance.html

T>Это те же олухи, что и MPS?

Да, они самые Те же олухи, что и ReSharper и TeamCity
Однако я придрался к утверждению, что "нормального context-sensitive intellicense я не видел его ни в какой другой среде". Ну не видел — значит не видел.. Но в Идее он как раз есть, один из самых умных, AFAIK.

T>>Это те же олухи, что и MPS?
G>Да, они самые Те же олухи, что и ReSharper и TeamCity
G>Однако я придрался к утверждению, что "нормального context-sensitive intellicense я не видел его ни в какой другой среде". Ну не видел — значит не видел.. Но в Идее он как раз есть, один из самых умных, AFAIK.

Она не бесплатная и для Java, поэтому ничего сказать не могу.

G>>>http://www.jetbrains.com/idea/features/code_assistance.html
T>>Это те же олухи, что и MPS?
G>Да, они самые Те же олухи, что и ReSharper и TeamCity
G>Однако я придрался к утверждению, что "нормального context-sensitive intellicense я не видел его ни в какой другой среде".
G>Ну не видел — значит не видел.. Но в Идее он как раз есть, один из самых умных, AFAIK.

Сходил к коллегам, осведомился про IDEA. Специально спросил насчёт intellisense. Получил ответ в смысле "интеллисенс у них нормальный, как у всех."

Подозрительно.

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

T>Давай то же самое в неплоском пространстве.

      | Not(Not(rule))         => optimize(Rule.And(rule));
      | And(Not(rule))         => optimize(Rule.Not(rule));
      | Not(And(rule))         => optimize(Rule.Not(rule));
      | And(And(rule))         => optimize(Rule.And(rule));
      | Not(rule)              => Rule.Not(optimize(rule));
      | And(rule)              => Rule.And(optimize(rule));

"Rule." в правой части тоже можно убрать.
Просто пока у меня не дошли руки переделать немерловый вывод типов.

T>>Давай то же самое в неплоском пространстве.
WH>

WH>      | Not(Not(rule))         => optimize(Rule.And(rule));
WH>      | And(Not(rule))         => optimize(Rule.Not(rule));
WH>      | Not(And(rule))         => optimize(Rule.Not(rule));
WH>      | And(And(rule))         => optimize(Rule.And(rule));
WH>      | Not(rule)              => Rule.Not(optimize(rule));
WH>      | And(rule)              => Rule.And(optimize(rule));
WH>

WH>"Rule." в правой части тоже можно убрать.
WH>Просто пока у меня не дошли руки переделать немерловый вывод типов.

Да, так значительно лучше. Это шаг вперёд вне всякого сомнения.

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

T>Смотри, сколько ты всего обнаружил!
T>Смог ли бы ты обнаружить столько же всего в коде на плюсах, размазанному по нескольким файлам?

Ты што мы говорим? По 3-5 тыс code-review строк в день не хочешь?
Разве лишние угловые и фигурные скобки заслонят логику? Если стоит задача реализовать (или проверить) инварианты, то абсолютно пофиг на каком языке, их кол-во и характер от этого не изменится. Человек же не строками кода мыслит, а "понятиями", соотв. пропускная способность и ограничивается не строками, а скоростью переваривания понятий.

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

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

T>Это не баг.
T>Она не обрабатывается в оптимизирующем смысле этого слова, но она обрабатывается вообще, как одна из ситуаций.

Тю блин, ты же мне класс задач показал, не так ли? Пофиг, что в конкретно этом месте забытый матч не фатален, просто ошибки логики ЯП пока не научились ловить.


V>>2. Еще косяки:
V>>const1 * var1 * var2 * var3 * const2 — оптимизация возможна, но не будет произведена.

T>У меня этого случая не встречалось. Я думал о решении, пришёл к выводу, что надо упорядочивать пары.

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

V>>const1 * (var1 * const2) — оптимизация невозможна, но будет произведена.
T>Почему это она невозможна?

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

V>>В общем, подобной задачкой я занимался в своей жизни неоднократно, приведённый код никуда не годится, ибо, при обработке арифметических и логических выражений не следует использовать бинарные AST, тут нужен банальный список одноуровневых аргументов.

T>Я и такой вариант рассматривал. Зависит. Да тот же gcc в пример привести. Там ушли с n-арных сложений-умножений на бинарные. Для упрощения.

Ес-но, там же линкер теперь linked-time codogeneration делает, и граф операций у него на узлах без ограничения арности, да еще в linked-time гораздо больше известно о возможной константности значений.

T>Просто я планировал сделать генератор оптимизаторов, для двоичного дерева он удобней.

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

T>Даже бесконечно большее число строк будет сравнимо.

Еще раз, что есть Just в том коде? (Я действительно хочу привести на паре языков реализацию аналога).




V>>В хаскеле не спец, так что еще вопросы:
V>>- что за Just?
V>>- откуда в этой задаче ожидается Maybe/Nothing?

T>

T>data Maybe a = Nothing | Just a
T>

T>Maybe позникает из-за возможного отсутствия любого элемента.

Maybe понятен, непонятен Just. Почему не так:

data Maybe a = Nothing | a

И что есть Just(a, b)?

T>Как называется эта "наука о качестве"?

Тебя смущает слово "наука"?

T>Про теорию типов ты не слышал, так?

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


T>Стиль кодирования? Нет?

Нет.

T>"Avoid success at all costs" anyone?

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

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

Про теорию типов ты, конечно, слышал мало.

Про классический пример, когда вывод типов ML показывает на зацикливание, ты тоже не видел.

Система типов ЯП — это логика. Правильная система типов исправляет ошибки логики.

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

Прикольно?

V>>>2. Еще косяки:
V>>>const1 * var1 * var2 * var3 * const2 — оптимизация возможна, но не будет произведена.
T>>У меня этого случая не встречалось. Я думал о решении, пришёл к выводу, что надо упорядочивать пары.
V>Не надо, надо в один список класть одноранговые операции, т.е. и EDiv тоже.
V>Если в твой код добавить EDiv и все на прямом паттерн матчинге сделать — это вообще макраме будет. В противовес этому код перебора списка с выхватыванием всех констант значительно покороче выйдет.

Вот именно поэтому и не надо EDiv. Надо EInv (1/x) и ENeg (-x). Это из алгебры, там на этом собаку съели.

V>>>const1 * (var1 * const2) — оптимизация невозможна, но будет произведена.
T>>Почему это она невозможна?
V>Потому что числовые типы могут быть различными для аргументов, и от порядка вычислений может зависеть результат (мы же пока конечным кол-вом бит в типах располагаем). В общем, скобки явно определяют последовательность операций и их игнорировать нельзя.

Это ты уже о чём-то своём.

V>>>В общем, подобной задачкой я занимался в своей жизни неоднократно, приведённый код никуда не годится, ибо, при обработке арифметических и логических выражений не следует использовать бинарные AST, тут нужен банальный список одноуровневых аргументов.
T>>Я и такой вариант рассматривал. Зависит. Да тот же gcc в пример привести. Там ушли с n-арных сложений-умножений на бинарные. Для упрощения.
V>Ес-но, там же линкер теперь linked-time codogeneration делает, и граф операций у него на узлах без ограничения арности, да еще в linked-time гораздо больше известно о возможной константности значений.

Это ты тоже о чём-то своём. Кодогенерация, как самый простой этап, остался на RTL. Все оптимизации работают на TreeSSA, который бинарный для сложения и умножения.

linked-time кодогенерация это из будущего. Оно только в SVN.

Как-то странно говорить о багах в ghc и упоминать незаконченные возможности gcc.

T>>Просто я планировал сделать генератор оптимизаторов, для двоичного дерева он удобней.
V>Для двоичного дерева потребуется многократный вызов подобного оптимизатора, пока все возможные узлы не "схлопнутся" (и то, далеко стоящие не схлопнутся), и для определения конца этого процесса придётся тащить дополнительный флаг. При использовании же N-арного дерева с явным расположением узлов одного логического уровня на одном уровне дерева потребуется лишь однократный вызов для полной оптимизации всех возможных ситуаций. Более того, для указанного выше ньюанса со скобками тебе бы пришлось вводить доп. тип узла AST в бинарном дереве.

Опыт оптимизации говорит о том, что ты неправильно мыслишь.

Но это твои личные проблемы.

T>>Даже бесконечно большее число строк будет сравнимо.
V>Еще раз, что есть Just в том коде? (Я действительно хочу привести на паре языков реализацию аналога).

Я привёл определение Maybe. Могу привести ещё раз:

data Maybe a = Nothing | Just a

Справа от знака равенства Just a означает создание значения типа Maybe a, слева от знака равенства — сравнение значения типа Maybe a с образцом Just a. Если пришло значение Just x на образец Just a, то a в выражении справа от знака равенства будет равен x.

let f (Just a) = a+10
f (Just 11)
21
f Nothing
*ошибка сравнения с образцом*

(задумался над очевидным фактом незнания тобой алгебраических типов.)

V>>>В хаскеле не спец, так что еще вопросы:
V>>>- что за Just?
V>>>- откуда в этой задаче ожидается Maybe/Nothing?

T>>

T>>data Maybe a = Nothing | Just a
T>>

T>>Maybe позникает из-за возможного отсутствия любого элемента.

V>Maybe понятен, непонятен Just. Почему не так:
V>

V>data Maybe a = Nothing | a
V>

Потому, что нельзя. Как мы отличим a, который Maybe a, от a, который, допустим, List a?

V>И что есть Just(a, b)?

:t Just 10
Just 10 :: Maybe Int
:t Just "Hello"
Just "Hello" :: Maybe String
:t Just (10,"Hello")
Just (10,"Hello") :: Maybe (Int,String)

(,) — пара, тупл или тапл (tuple).

:t (,)
(,) :: (a,b)

Пара независимо полиморфна по обеим аргументам.

T>>Как называется эта "наука о качестве"?
V>Тебя смущает слово "наука"?

Да. У науки, обычно, бывает название.

T>>Про теорию типов ты не слышал, так?
V>В посление годы слышал слишком много, но ты, похоже, не понял разницы в ыункциональных и неыункциональных требованиях.

Признаюсь честно, всеё разницы я вижу только в приставке "не".

Я даже слов таких не знаю.

T>>Стиль кодирования? Нет?
V>Нет.

Почему?

T>>"Avoid success at all costs" anyone?
V>Наоборот, разделение труда, т.к. уже есть большие готовые прикладные платформы.

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