Re[6]: Каким отладчиком пользовались разработчики Kx Systems
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 06.03.09 14:45
Оценка: 4 (2) +11 :)
Здравствуйте, kaa.python, Вы писали:

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


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[5]: Каким отладчиком пользовались разработчики Kx Systems
От: Sinclair Россия https://github.com/evilguest/
Дата: 23.03.09 11:03
Оценка: :))) :))) :)))
Здравствуйте, yumi, Вы писали:
Y>Для себя я определил область применения отладчика. Это когда нужно разбираться в чужом коде. В своем коде, я почти не пользуюсь отладчиком.
Угадываю: в твоём коде отладчиком пользуются другие?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[8]: Каким отладчиком пользовались разработчики Kx Systems
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 06.03.09 16:01
Оценка: 33 (6) :))
Здравствуйте, thesz, Вы писали:

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

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


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

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


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[35]: Каким отладчиком пользовались разработчики Kx System
От: dmz Россия  
Дата: 22.03.09 05:26
Оценка: 30 (5) +2 :)
C>>>Зато в Java у меня есть умный автокомплит и средства генерации кода, которые сглаживают разницу в объёме.
dmz>>Черт его знает. Автокомпилит за тебя код писать не будет.
C>Он сейчас такой умный, что даже иногда и пишет

Есть мнение, что он пишет только такое (и так) что лучше было бы это не писать вообще.

C>Ну вот видишь, ты автокомплитом в IDEA не пользовался.


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

Да в общем, немного пользовался. Давно. Я помню, оно там по фрагменту зуба (кусок названия типа переменной что ле) генерило все животное целиком:

MyCool<хоткей> - втыкаем в меню - еще пара нажатий на клавиши ->

MyCoolType myCoolType = new MyCoolType(...)


В этой строке лишнего чуть меньше, чем всё.

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

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

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

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

^, X, ->, <-


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

Если эти рассуждения верны (а вроде они достаточно очевидны), то очевидные недостатки тут таковы:

Язык (типичный брейнфак получился) — невербальный (это фактически язык жестов) и не само-объясняемый.

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

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

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

А подход с хоткеями — это такой DSL, выход которого потом надо ковырять и поддерживать. Т.е. вся эта мегадопечатка повышает уровень языка только в смысле одноразового написания кода, но сам-то код потом надо тестировать, поддерживать и т.п. При этом, если мы написали мало кода (функцию высшего порядка) — то она всегда работает тем образом, которым она определена и поддерживать нам надо только ее. А вот код, который нагенерился нашими хоткеями, требует индивидуального подхода — т.е. если у нас сгенерился кусок кода A, про который мы знаем, что он работает правильно, то про сгенеренный похожим (но не идентичным! идентичным он быть не может) образом кусок кода B — мы ничего сказать не можем. Короче говоря, это все раздувает код. Больше кода — больше ошибок. Ну ее нахрен, такую "высокоуровневость".
Re[3]: Каким отладчиком пользовались разработчики Kx Systems
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 06.03.09 12:29
Оценка: +6 -1 :)
Здравствуйте, thesz, Вы писали:

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

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

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


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


А он вообще нужен? Лично для меня, необходимость в отладчике очч спорный момент. Если он есть, это безусловно хорошо, но если его нет, то логов всегда достаточно. А если еще и библиотека логирования хорошая, то отладчик скорее будет лишним
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[4]: Каким отладчиком пользовались разработчики Kx Systems
От: thesz Россия http://thesz.livejournal.com
Дата: 06.03.09 12:56
Оценка: :))) :)))
T>>Как они с поддержкой программ для Wall Street справляются?..
FR>Вот она причина мирового экономического кризиса.

Я её отношу на счёт наличия побочных эффектов в K. Это затруднило анализ финансовых потоков. Был бы использован Хаскель, проблем бы не было.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[24]: Каким отладчиком пользовались разработчики Kx System
От: vdimas Россия  
Дата: 21.03.09 04:24
Оценка: 11 (3) -1 :)
Здравствуйте, thesz, Вы писали:

T>>>Это не баг.

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

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


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


Во-первых, с чего ты взял? Во-вторых, еще раз русским по белому: как это относится к реализации функциональных требований?

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

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

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

T>Прикольно?


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

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

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

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

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


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


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

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


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


Хочешь сказать, что Хаскель оперирует целыми числами бесконечной разрядности? Результат деления двух целых какой тип имеет?

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


Угу, поползновения увильнуть от прямого вопроса. Я привёл простой пример, который не оптимизирует твой подход, в то время как как компиляторы Java, C#, C++ прекрасно его оптимизируют. Может, ты чего-то не знаешь и пытаешься делать умное лицо?

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


Я так и понял, проехали. Если ФП не в состоянии "автоматом" исправлять ошибки логики, то это проблемы программиста, а не ЯП... ЧТД.

T>(задумался над очевидным фактом незнания тобой алгебраических типов.)


Мде, офигенные у кое-кого манеры... Не пора ли кое-кому в сад? Говоря твоим же языком, еще много постов назад задумался над очевидным фактом незнания тобой теории групп и понятия размеченных объеденений, когда ты упирался насчёт алгебраических св-в семейств явным образом инстанциированных шаблонных типов в С++ или игнорировал замечание относительно реализаций dispatched unions.

Т.к. ты, очевидно, не понимаешь места, которое занимает реализация алгебраических типов Хаскеля в теории групп, то я тебе могу подсказать: алгебраические типы в реализации Хаскеля — суть размеченные объединения, селектор которых доступен в run-time, и модель селектора при этом выполнена в виде типа. Сделано это, очевидно, из-за принятой в Хаскеле "шаблонности" кода, что позволяет в минимальном синтаксисе выступать селектору в виде конструктора типа в процессе его параметризации.

В общем, я же написал, что Хаскель не знаю, соотв. могу не знать подробности синтаксиса алгебраических типов в нём. Спросил конкретно про "Just", трудно было сказать, что это имя конструктора (по совместительству селектора) типа Maybe? Неужели не слышал про языки, в которых для алгебраических типов указывают конечные типы их вариантов? Или где селекторы выполнены в виде интегральных типов?


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

V>>
V>>data Maybe a = Nothing | a
V>>


T>Потому, что нельзя. Как мы отличим a, который Maybe a, от a, который, допустим, List a?


Не поэтому, а потому что в Хаскеле алгебраическую группу составляют взаимно уникальные типы. Собственно, т.к. он ничего кроме матчинга не умеет, то неудивительно, эта уникальность необходима для корректной работы. По-сути, значения алгебраических типов "заворачиваются в обёртку" дважды, сначала в тип селектора, а потом как все алгебраические типы. Вот это оборачивание в уникальный селектор и гарантирует необходимую логике паттерн-матчинга уникальность. Теперь тебе понятно, почему так нельзя?

Мне пришлось потратить вечер на изучение Хаскеля, чтобы объяснять тебе то, что ты должен был знать еще лет 10 назад.

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

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

Тем не менее, обещанное решение.
1. Раскроем "_" в первоначальном примере и Just/Nothing во всех местах:
(newAcc,output) = case (oldAcc,input,loopback) of
            (Just acc, Just inp, Just lb) -> (Just acc, Just (inp, lb))
            (Just acc, Just inp, Nothing) -> (Nothing, Just (acc, inp))
            (Just acc, Nothing, Just lb) -> (Nothing, Just (acc, lb))
            (Just acc, Nothing, Nothing) -> (Just acc, Nothing)
            (Nothing acc, Just inp, Just lb) -> (Nothing, Just (inp, lb))
            (Nothing acc, Just inp, Nothing) -> (Just inp, Nothing)
            (Nothing acc, Nothing inp, Just lb) -> (Just lb, Nothing)
            (Nothing acc, Nothing inp, Nothing lb) -> (Nothing, Nothing)


Получился обычный двоичный дешифратор. И сдаётся мне, что линейный, да еще избыточный в первоначальном варианте матчинг не очень хорош, в случае двоичного дешифратора.
Для нашей задачи (3 бита дешифрации) достаточно сделать 2 сравнения для любой ветки алгоритма (C#):
    using Pair = KeyValuePair<int, int>;

    struct  Ballin {
        public int? acc; 
        public Pair? pair;

        Ballin(int? a, Pair? p) { acc = a; pair = p; }

        public static Ballin Produce(int? acc, int? inp, int? lb) {
            if (!inp.HasValue) return TryPair(acc, lb);
            if (!lb.HasValue) return TryPair(acc, inp);
            return new Ballin(acc, new Pair(inp.Value, lb.Value));
        }

        private static Ballin TryPair(int? arg1, int? arg2) {
            if (!arg1.HasValue) return new Ballin(arg2, null);
            if (!arg2.HasValue) return new Ballin(arg1, null);
            return new Ballin(null, new Pair(arg1.Value, arg2.Value));
        }
    }


А сколько сравнений сделает Хаскель для последнего варианта в первоначальном коде? 12? Так может, это не столько Хаскель тормозит, сколько программисты на нём? Мой вариант вполне переводим на Хаскель с сохранением 2-х сравнений для каждой ветки, и код сожмется практически до первоначального кол-ва строк, ввиду особенностей синтаксиса Хаскеля. И не надо опять начинать про "преждевременную оптимизацию", ибо мой алгоритм не просто быстрее, он несколько нагляднее, т.к. объясняет суть алгоритма: паруем первое попавшееся, остаток в аккумулятор.


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

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

T>Да. У науки, обычно, бывает название.


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


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


T>Признаюсь честно, всеё разницы я вижу только в приставке "не".


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

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

V>>Нет.

T>Почему?


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

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


Если ничего не изменится, он не станет успешным никогда. 10 с лишним лет Хаскель топчется на месте и перемен не предвидится — слишком уж консервативна среда вокруг него. Пока читал про систему типов Хиндли-Милнера наткнулся на куда более интересные вещи, например на Fortress, Boo. Эта система может запросто лечь на "не чисто" функциональные языки, и даже на презираемое некоторыми ООП. ИМХО, реализовать систему Хиндли-Милнера только над алгебраическими типами оказалось проще-всего (ибо всего одна разновидность полиморфизма, т.е. упрощается вывод типов), но сама эта система не требует никакой алгебраичности, она ортогональна ей. Не пошатнулись там еще твои "устои"?

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

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

------------
За сим позвольте откланиться в этой ветке, т.к. игра в пинг-понг недоговоренностями и односложными предложениями требует "реал-тайм" участия в форуме для сохранения конструктива, а такой вид участия я не в состоянии себе позволить.
Re[7]: Каким отладчиком пользовались разработчики Kx Systems
От: thesz Россия http://thesz.livejournal.com
Дата: 06.03.09 15:29
Оценка: -4 :)
KP>>На мой взгляд тут довольно просто все. Если человек писал под большое количество платформ, то он наверняка хорошо умеет работать с логами, в особенности если приходилось писать поп встроенные/мобильные платформы. Если же основной опыт это Java, .NET и только под Винду.. Ну что ждать от такого конеченого человека
E>Да, действительно, все просто. Достаточно пописать под большое количество платформ чтобы понять, что нет никакой доблести в отрицании отладчика. Иногда отладчик очень серьезно экономит время и силы. Можно это использовать в своей работе. А можно не использовать и тешить себя сознанием собственной крутизны, которая позволяет работать вообще без отладчика

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

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

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

Молодец. Тешь себя сознанием собственной крутости и дальше.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[12]: Каким отладчиком пользовались разработчики Kx System
От: Didro Россия home~pages
Дата: 07.03.09 22:46
Оценка: +5
Здравствуйте, VladD2, Вы писали:

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


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

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

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

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

Кстати по отладке (в т.ч. и без отладчика) на DTF был хороший цикл статей:
Способы отладки приложений , Отладка по крэш-дампам, Протоколирование , Визуальный анализ кода.
Re[14]: Каким отладчиком пользовались разработчики Kx System
От: dmz Россия  
Дата: 12.03.09 06:29
Оценка: :))) :))
dmz>Гы. Знал бы хаскелл — сказал. Из того, что я о нем знаю — это действительно может быть проблемой Кастую Summon thesz. Если получится — то он явится и разъяснит.

Но наверное, он скажет, что логи тоже не нужны. А программы на хаскеле правильные в силу типизации и чистоты.
Re[7]: Каким отладчиком пользовались разработчики Kx Systems
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.03.09 11:53
Оценка: :))) :)
Здравствуйте, eao197, Вы писали:

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


Что-то меняется в этом мире. Давно я не соглашался с тобой так все цело и полностью.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[37]: Каким отладчиком пользовались разработчики Kx System
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 22.03.09 21:15
Оценка: +1 :)))
Здравствуйте, Cyberax, Вы писали:

L>>Упс, а я их генерировал. Даже специальные запросы, но они у меня не очень часто встречаются.

C>Упс, а у меня их человек на fulltime'е пишет. Так как они не генерируются нифига.

У меня генерилка не фултайм работает, а так когда понадобится, но зато и платить не надо :-)
Re[10]: Каким отладчиком пользовались разработчики Kx System
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 07.03.09 06:21
Оценка: 3 (1) +2
Здравствуйте, thesz, Вы писали:

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


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

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

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

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


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[12]: Каким отладчиком пользовались разработчики Kx System
От: FR  
Дата: 08.03.09 14:30
Оценка: 1 (1) +1 :)
Здравствуйте, thesz, Вы писали:

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


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

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


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


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

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


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


Не стоит, я думаю ты без проблем все что нужно и отладчик и IDE за пару недель напишешь.
Re[16]: Каким отладчиком пользовались разработчики Kx System
От: vdimas Россия  
Дата: 17.03.09 18:01
Оценка: 20 (1) +1
Здравствуйте, 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 года плотного использования). Так что, к выбору инструментария у меня подход весьма прямолинейный — необходимо чтобы сам инструментарий не веселил своими причудами, ибо не до него.
Re[14]: Каким отладчиком пользовались разработчики Kx System
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 08.03.09 18:26
Оценка: 11 (2)
Здравствуйте, thesz, Вы писали:

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


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

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

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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[35]: Каким отладчиком пользовались разработчики Kx System
От: Lazy Cjow Rhrr Россия lj://_lcr_
Дата: 24.03.09 10:56
Оценка: 6 (1) +1
vdimas,

L>>Я постепенно прихожу к выводу, что Scala возникла тоже из-за низкого уровня Java А это не та причина, по которой надо создавать новый язык, IMHO. А то получится Scala — монстр типа С++. Язык с набором несвязанных фич вместо языка с фичами, уложенными в некую систему. Хотя, вполне допускаю, что я пока просто эту систему не вижу.


V>Да, как-то пока сложно разглядеть идею Scala и причину его разработки как таковую, кроме причины отсутствия языковых альтернатив для Java — платформы.


Очень легко.

1-я причина — это максимально приближенное к идеалу (а идеал здесь — виртуальные классы, которые не могут быть поддержаны из-за JVM) решение Expression Problem:

"Can your application be structured in such a way that both the data model and the set of virtual operations over it can be extended without the need to modify existing code, without the need for code repetition and without runtime type errors.". We stress "without runtime type errors" as an important statement because the expression problem really becomes interesting (read challenging) when exposed to a type system that ensures safe execution of the code.

Отсюда следуют куски типа selftype-ы, traits, mixin composition-ы и абстрактные типы (не путать с абстрактными классами). А также чтобы реализовать расширяемые компоненты, необходимы функции-как-первоклассные-значения и вообще, всесторонняя поддержка ФП.
(подробности в "Scalable Component Abstractions" и "Independently Extensible Solutions to the Expression Problem")

2-я причина — это расширение паттерн-матчинга с алгебраических типов на объекты. Отсюда следуют куски про паттерн-матчинг в Скале, case classes и apply/unapply.
(подробности в "Translation Correctness for First-Order Object-Oriented Pattern Matching" и "Matching Objects With Patterns").

3-я причина — расширить систему типов так, чтобы джава со своими дженериками стала частным случаем. Отсюда поддержка экзистенциальных типов в Скале.

и 4-я причина — это разработка нетривиальных DSEL, как примеры библиотека актёров и SQL.
(соответствующая статья "Event-Based Programming without Inversion of Control")

Вроде бы всё, то есть я не знаю конструкции, которая бы не была обусловлена одним из вышеназванных 4-х пунктов.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[15]: Каким отладчиком пользовались разработчики Kx System
От: thesz Россия http://thesz.livejournal.com
Дата: 12.03.09 12:07
Оценка: 4 (1) :)
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


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

Но работает.

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

Практически, кусок практически настоящей системы.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[25]: Каким отладчиком пользовались разработчики Kx System
От: thesz Россия http://thesz.livejournal.com
Дата: 20.03.09 13:54
Оценка: 1 (1) +1
T>>Сходил к коллегам, осведомился про IDEA. Специально спросил насчёт intellisense. Получил ответ в смысле "интеллисенс у них нормальный, как у всех."
T>>Подозрительно.
V>Эти же ребята сделали Решарпер, так что могу осмысленно говорить лишь про него. Польза отнего не только и не столько в intellisense, сколько в тех хинтах, где он предлагает выполнить некое действие. Как пример — просто объявляю некое приватное поле, а потом alt+enter дважды, чтобы мне инициализацию этого поля встявили в конструктор, и потом сделали геттер на него. И таких действий у него, скажем прямо, немало. Так что, некая "говорливость" кода неплохо компенсируют подбные тулзы.

Читать-то его обратно всё равно приходится.

IDE pervasiveness мешает людям переходить на языки получше. Эта дурацкая привычка полагаться на IDE в выполнении "мелких задач, с которыми может справиться и компьютер", мешает понять, что этих задач может не быть в принципе.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[3]: Каким отладчиком пользовались разработчики Kx Systems
От: FR  
Дата: 06.03.09 12:42
Оценка: :))
Здравствуйте, thesz, Вы писали:

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


Вот она причина мирового экономического кризиса.
Re[4]: Каким отладчиком пользовались разработчики Kx Systems
От: yumi  
Дата: 10.03.09 02:06
Оценка: +1 :)
Здравствуйте, kaa.python, Вы писали:

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


Для себя я определил область применения отладчика. Это когда нужно разбираться в чужом коде. В своем коде, я почти не пользуюсь отладчиком.
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org
Re[23]: Каким отладчиком пользовались разработчики Kx System
От: thesz Россия http://thesz.livejournal.com
Дата: 19.03.09 14:19
Оценка: :))
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>Просто пока у меня не дошли руки переделать немерловый вывод типов.

Да, так значительно лучше. Это шаг вперёд вне всякого сомнения.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[43]: Каким отладчиком пользовались разработчики Kx System
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 22.03.09 08:35
Оценка: +2
Здравствуйте, Cyberax, Вы писали:

dmz>>>>А генерация кода — приводит к "много подобного кода в разных местах"

C>>>Ну приводит. Что дальше? Я не говорил, что макросы — совсем не нужны.
dmz>>Ну так в джаве их нет, макросов. А наличие мега-допечатки провоцирует писать тонны кода, потому что это просто и быстро, вместо того, что бы попытаться его обобщить.
C>А я утверждаю, что Java — это идеал?
C>Я просто говорю, что DSELи — это может быть далеко не единственный способ реализации DSLей. И возможно даже, что не самый удачный.

Макросы — это лакмусовая бумажка, которая показывает места, где язык невыразителен. В Яве нет даже этой бумажки :) Поэтому там так часто приходится пользоваться генераторами. Или IDEA — кому как. В питоне — лямбды и функции высшего порядка поднимают уровень языка в разы, а декораторы добивают там, где не справляются ФВП.

Насчёт Явы и IDEA. Я сидел на IDEA с версии 2.5. Восхищался (и до сих пор восхищен) её редактором. Однако, я заметил, что Java и без того болтливый язык, а IDEA провоцирует меня на

1) написание большого количества boilerplate
2) лёгкое и частое использование рефакторингов, что снизило мою дисциплинированность
3) доверие инспекциям, на которые я стал обращать внимание и элементарно отвлекаться

Я понимаю, что проблема во мне, и что я просто не умею пользоваться IDEA. Но, вот такой я человек — считаю, что IDEA — замечательная среда, может лучшая для Java, и одновременно, что она мне больше мешает, чем помогает.

Поэтому я слез с IDEA и начал больше

1) заниматься кодогенерацией, МП, DSL
2) думать, прежде чем писать :)
3) обращать внимание на важные вещи, а не на финтифлюшки
Re[27]: Каким отладчиком пользовались разработчики Kx System
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 22.03.09 09:22
Оценка: +1 :)
Здравствуйте, vdimas, Вы писали:

V>В общем, ты очень много пишешь, но мало приводишь примеров. Из тех, что приводил — не для демонстрации основного твоего посыла "невозможно накосячить", из-за чего собственно и разгорелось у нас. Хотим хлеба и зрелищ. Покажи нам подтверждение своих слов.


Я уже не помню, о чём вы говорили :-) Но, наверное, имеется в виду описание инвариантов поведения в типах.

V>Где ты увидел вопрос про "плоское пространство имён"? Похоже, ты не отличаешь "область видимости" от "уровня доступа/видимости".


Что такое уровень видимости в Haskell? Там же блоков нет.

Если ты про do-нотацию, то там немножко другое.

Хотя вот этот пример работает, как и ожидается.

main = do
    v <- return 1
    print v
    do v <- return 2
       print v


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


Почему автомат проще на ООП?

V>Кстати, интересная мысль в голову пришла. Вот у нас есть некий направленный граф. Есть 2 распространённых способа моделирования направленного графа:

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

Haskell — язык ленивый.

vertex1 = Vertex [Edge vertex2]
vertex2 = Vertex [Edge vertex1]


Но вообще-то каждому подходу свои структуры данных. На Haskell чистые структуры пишутся легко, мутабельные — сложнее (см. doubly linked list, например).

V>Ладно, много раз порывался забросить этот театр абсурда, ибо кое-кто нить рассуждения постоянно теряет... Но мне пока кое-что надо увидеть (надеюсь этот бонус всё-таки будет). В общем, конкретно здесь речь шла о том (просто напоминаю), что я предположил, что на некоторых задачах ты всё-равно будешь использовать больше, чем упомянутые 10% возможностей. Я понимаю, что эти модули по приведённым тобой ссылкам сделал не ты лично, но зато ты имеешь возможность взглянуть в их исходники, сравнить кол-во использованных возможностей языка со своим "стилем кодирования" и, теперь восстановив нить обсуждения, сказать — удачный ли был мой пример в плане демонстрации того, что не только стиль кодирования определяет набор используемых языковых ср-в для решения задач, но иногда выход за эти 10% обуславливается характером самих задач.


С Хаскелем проще — там 90% конструкций сахар. Что касается этих библиотек, то там кода вообще кот наплакал, потому что основные операции зашиты в натив. В MVar так вообще 1% языковых средств используется. Самое сильное — do-нотация :))

T>>Почему State monad уродство? Твоё личное предпочтение?

V>Обычное lvalue.

Потому что на императивном языке это примитивная операция?

V>Это было бы так, если бы не странные ограничения name conventions (сдаётся мне, что это еще один из минусов для целей популяризации). C# и то отличает тип от ф-ии, не обладая такой системой вывода типов.


О, это сделано для удобства. Не надо писать map :: forall a b. (a -> b) -> [a] -> [b], достаточно просто (a -> b) -> [a] -> [b] и то, что a,b — параметры типа, а не конкретные типы определится по регистру. Что касается конструкторов против функций — то верхний регистр — это что-то вроде new в С#: x = Foo 42 против x = foo 42.

P.S. И эта... Кончайте лаяться :-) Вы же оба умные, что аж смотреть страшно. Даёшь больше конструктива!
Re[38]: Каким отладчиком пользовались разработчики Kx System
От: Cyberax Марс  
Дата: 21.03.09 23:12
Оценка: 6 (1)
Здравствуйте, lomeo, Вы писали:

C>>Причём нужно создать почти идеально совместимый по синтаксису DSL, так как в браузеры у нас пока Haskell не встроен. В общем, задача очень быстро станет наааааамного сложнее написания модуля для IDEA.

L>Почему? Не понял, если честно.
Не, ну тебе нужно будет повторить весь HTML, CSS и JS в виде DSL.

L>Писать injected language сложнее, чем DSeL, а т.к. кол-во первых должно быть равно кол-во второго, то непонятно откуда растёт сложность?

...кстати, а сложнее ли?...

Смысл в том, что для Injected-языка я могу использовать ЛЮБОЙ парсер, в том числе и интеллектуальный, пропускающий плохие куски, могу использовать ЛЮБОЕ промежуточное представление и т.д.

Ну и вопросы с рефакторингом остаются.

L>Во-вторых, я не призываю писать тебя dsl для css. Речь вообще не об этом. Началось с чего? Ты сказал, что то, что может injected language — не может eDSL.

Ну вот я и объясняю.

L>Я не понял почему (ведь для хоста-языка у нас уже всё есть) и переспросил.

Не верно. Для хост-языка может быть есть парсеры, но это O-малое для качественного DSL.
Sapienti sat!
Re[3]: Каким отладчиком пользовались разработчики Kx Systems
От: pierre  
Дата: 11.06.09 16:57
Оценка: 4 (1)
Здравствуйте, thesz, Вы писали:

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


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


Хм, всегда у них был 'отладчик' и сейчас есть. Пример (K3):

  {(x+y)*2}["a";"b"]
type error
{(x+y)*2}
   ^
>  x
"a"
>  y
"b"
>  :123 / вернуть 123 из текущего выражения
:123
246 / результат
  /


Каждый '>' называется suspension и они могут быть вложены.

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

  {\(x*100)+1}'(1 2 3 4 5)
101 / '\' выводит то что стоит перед ним
201
301
401
501
101 201 301 401 501 / результат 
  \b stop / переключаем в режим брякпоинтов
  {\(x*100)+1}'(1 2 3 4 5)
stop
{\(x*100)+1}
 ^
>  x
1
>  : / продолжение исполнения
:
stop
{\(x*100)+1}
 ^
>  x
2
>  /


Намного удобнее чем всякие маразматические ide.
Re[27]: Каким отладчиком пользовались разработчики Kx System
От: z00n  
Дата: 21.03.09 16:16
Оценка: 3 (1)
Здравствуйте, vdimas, Вы писали:

V> А сколько сравнений сделает Хаскель для последнего варианта в первоначальном коде? 12? Так может, это не столько Хаскель тормозит, сколько программисты на нём?

V> Сорри, если кого-то задел в "пылу боя", но ты бы сам взглянул на генерируемый бинарный код приведённого примера, для начала.
Мне не нужно, спасибо. И я не програмист на Хаскеле(хотя не зарекаюсь), и не был задет. Я просто взглянул на эти "12" и понял что вы даже не слышали о том, что паттерн матчинг компилируют. А если вы не слышали об этом, то наверное считали, что програмисты на Haskell (SML, OCAML, Nemerle, Scala) такие тупые(и ленивые!), что вместо того, чтобы взять бумажку (как вы), и откомпилировать на ней (как вы) — они лепят везде этот страшно неэффективный код с M*N сравнений.

У меня тут в кустах, случайно стоит рояль — правда с динамической типизацией — придется руками дооптимизировать:

С точки зрения компиляции ПМ, 'balin' аналогичен:
-- типа Lua
local Just, Nothing, TypeError = 'Just', 'Nothing', 'TypeError'

local fun mock_balin
  | (Just|Nothing),Just,Just       -> 111
  | Just,Nothing,Just              -> 222
  | Just,Just,Nothing              -> 333
  | (Just|Nothing),Nothing,Nothing -> 444
  | (Just|Nothing),(Just|Nothing),Nothing        -> 555
  | (Just|Nothing),(Just|Nothing),(Just|Nothing) -> 666
  | _,_,_ -> TypeError
end


Компилятор (не знающий о статической типизации и алгебраических типах) выдаст нам:
local function mock_balin(_u0,_u1,_u2)
  if _u0 == Just then
    if _u1 == Just then
      if _u2 == Just then return 111
      else
        if _u2 == Nothing then return 333 else return TypeError end;
      end;
    else
      if _u1 == Nothing then
        if _u2 == Just then return 222
        else
          if _u2 == Nothing then return 444 else return TypeError end;
        end;
      else return TypeError
      end;
    end;
  else
    if _u0 == Nothing then
      if _u1 == Just then
        if _u2 == Just then return 111
        else
          if _u2 == Nothing then return 555 else return TypeError end;
        end;
      else
        if _u1 == Nothing then
          if _u2 == Nothing then return 444
          else if _u2 == Just then return 666 else return TypeError end;
          end;
        else return TypeError
        end;
      end;
    else return TypeError
    end;
  end;
end;


Теперь нам нужно выкинуть все ветки с 'TypeError'(статическая типизация) и обратить внимание на то, что тег либо Just либо Nothing и второй тест не нужен (type span optimization):
local function mock_balin2(tag1,tag2,tag3)
  if tag1 == Just then
    if tag2 == Just then 
      if tag3 == Just then return 111 else return 333 end
    else --// tag2 == Nothing
      if tag3 == Just then return 222 else return 444 end
    end
  else --// tag1 == Nothing
    if tag2 == Just then
      if tag3 == Just then return 111 else return 555 end
    else --// tag2 == Nothing
      if tag3 == Nothing then return 444 else return 666 end
    end
  end
end

Вот и все, обращаем внимание на то, что все правые части сохранились — значит исходный код не был избыточным. Хороший компилятор перепишет это как case и сделает hash-consing для экономии места.
Re[10]: Каким отладчиком пользовались разработчики Kx System
От: vdimas Россия  
Дата: 10.03.09 15:39
Оценка: 1 (1)
Здравствуйте, thesz, Вы писали:

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


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


Что-то мне логика здесь не понятна. А что именно мы собираемся отлаживать? Если ошибки интерпретации памяти искать — это одно, а если надо сам алгоритм отлаживать, то пофиг на каком языке было написано, в случае той самой алгоритмической ошибки. Даже абсолютно правильно реализованный алгоритм, скажем, обработки сигналов, может выкидывать фортели на некоторых данных из-за банального переполнения. А вот в уже приведённом примере использования третьесторонних библиотек, да еще если дока не полна или, как бывает, расхождения док-ции и реального поведения, то тут без отладки в любом виде никак.
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[18]: Каким отладчиком пользовались разработчики Kx System
От: vdimas Россия  
Дата: 18.03.09 12:31
Оценка: 1 (1)
Здравствуйте, 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. Хаскелю надо ветвиться в эту сторону, чтобы обрести возможность общение с внешним миром и стать полезным.
Re[26]: Каким отладчиком пользовались разработчики Kx System
От: Cyberax Марс  
Дата: 20.03.09 16:19
Оценка: 1 (1)
Здравствуйте, thesz, Вы писали:

C>>Видимо, вопроса не поняли. Или IDEA пользоваться не умеют.

T>Когда я написал вот этот параграф выше, мне было некоторое время интересно, что же коллективный разум RSDN придумает.
T>Коллективный разум RSDN не подкачал. Он не пропустил это мимо своего внимания, это раз. И он показал свой обычный высокий уровень аргументации, это два.
Если хочешь, могу более подробно объяснить. Я считаю, что функциональность IDEA во многом делает Java языком более высокого уровня.
Sapienti sat!
Re: Каким отладчиком пользовались разработчики Kx Systems?
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 06.03.09 11:54
Оценка: +1
Здравствуйте, thesz, Вы писали:

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


Логи? В принципе, для отладки любого приложения этого достаточно, при умении ими пользоваться, конечно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[9]: Каким отладчиком пользовались разработчики Kx Systems
От: thesz Россия http://thesz.livejournal.com
Дата: 06.03.09 20:33
Оценка: :)
E>3.14здеть изволите сударь...

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

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

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


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


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


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


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

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

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

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

Надобно будет свести желание отладчика и преждевременную оптимизацию. Есть у меня намётки, что они растут из одного корня.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[9]: Каким отладчиком пользовались разработчики Kx Systems
От: thesz Россия http://thesz.livejournal.com
Дата: 07.03.09 18:08
Оценка: -1
T>>DSL в своей работе ты не используешь.
T>>Молодец. Тешь себя сознанием собственной крутости и дальше.
VD>Я балдею от твоего самомнения.
VD>Ты бы сначала узнал по подробнее что и зачем используют твои оппоненты, а потом бы домыслы свои высказывал (а лучше держал бы их при себе).
VD>eao197 с ДСЛ-ями знаком точно не по наслышке. Он разработал систему кросплатформной сборки проектов на Руби. Причем эта система реализована в виде встроенного в Руби ДСЛ-я.

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

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

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

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

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


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

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


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

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

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


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

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

Ориентироваться же надо на лучших. Например, на разработчиков kdb.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[11]: Каким отладчиком пользовались разработчики Kx System
От: thesz Россия http://thesz.livejournal.com
Дата: 07.03.09 18:39
Оценка: :)
T>>Тогда чего ты насчёт необходимости отладчика упираешься?
T>>Про "меньше времени на отладку" знаешь, про отладчик нет ни в одном из твоих отчётов про DSL. Я думаю, что ты осознаешь, во что бы тебе обошёлся отладчик для каждого из языков.
VD>Прикинь, есть люди с разными мнениями. А твое мнение не всегда бывает правильным.
VD>Вот такие дела.

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

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

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

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


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

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

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

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

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

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

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

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

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


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

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


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

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

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

По-моему, хорошо получилось.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[11]: Каким отладчиком пользовались разработчики Kx System
От: dmz Россия  
Дата: 08.03.09 09:11
Оценка: :)
FR>Кстати у Ocaml'а очень хороший отладчик, подерживает шагание в обе стороны, правда полноценно работает только в linux. Я линукс на ноут поставил чтобы на него посмотреть, еще установил OcaIDE и до сих пор тащусь

Неправославно. Осудительно.
Re[2]: Каким отладчиком пользовались разработчики Kx Systems
От: goto Россия  
Дата: 08.03.09 15:34
Оценка: +1
Здравствуйте, kaa.python, Вы писали:
...
KP>Логи? В принципе, для отладки любого приложения этого достаточно, при умении ими пользоваться, конечно.

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

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

И в конце концов, отладчик ведь никому не мешает. Пусть будет .
Re[15]: Каким отладчиком пользовались разработчики Kx System
От: thesz Россия http://thesz.livejournal.com
Дата: 08.03.09 18:07
Оценка: :)
FR>>>Все-таки похоже ты не понимаешь как и многие хаскелисты разницы между продуктом и тулзой для внутреннего использования. От этого похоже и явное преувеличение важности языка.
T>>Объясняй.
FR>По моему бесполезно

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

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

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

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

Но я побоялся его предложить, Он довольно обиден. Поэтому и не предлагаю.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[13]: Каким отладчиком пользовались разработчики Kx System
От: vdimas Россия  
Дата: 10.03.09 18:40
Оценка: :)
Здравствуйте, FR, Вы писали:

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

FR>А на 48 и с отладчиком и монитором.

"а вот у нас"
У нас в 4к на x51 вполне влазили программа, причем, программа переносила сама себя из готовой форт-программы под ДОС-ом в целевую архитектуру (указывали стартовое слово, далее все зависимые высокоуровневые паковались для этой архитектуры в прошиваемый образ). Ввиду отсутствия всяких мощных сред разработки, это была единственная альтернатива ассемблеру.
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[14]: Каким отладчиком пользовались разработчики Kx System
От: vdimas Россия  
Дата: 11.03.09 03:18
Оценка: +1
Здравствуйте, thesz, Вы писали:

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


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

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


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

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

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


P.S. К тому же, все в курсе, что гнутый компилятор Хаскеля до сих пор содержит прорву багов, отчего народ и не собирается пока что им пользоваться в серьёзных продуктах (так же как и Немерле). Так он и ходит на уровне языка для экспериментов и написания тулзин локального использования. Писать на этом "мегаязыке" со встроенными утечками памяти программы для банкоматов — увольте.
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[19]: Каким отладчиком пользовались разработчики Kx System
От: thesz Россия http://thesz.livejournal.com
Дата: 18.03.09 14:07
Оценка: -1
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!

Хаскель взял под козырёк и пошёл выполнять.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[20]: Каким отладчиком пользовались разработчики Kx System
От: Belsen  
Дата: 19.03.09 23:22
Оценка: +1
Здравствуйте, thesz, Вы писали:

T>-------------------------------------------------------------------------------
T>-- Balin's pipelined sum acc.
T> 
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>Сумматор имени Влада Балина aka Gaperton, функция автомата Мили.
T>Что, сможешь сделать такую же таблицу решений? А в такое же количество строк?

Безотносительно к теме пользования отладчиками, не стало бы понятнее, что делает эта фунция, если ее переписать вот так?
balinF' :: Maybe i -> Maybe i -> Maybe i -> (Maybe i, Maybe (i, i))
balinF' oldAcc input loopback = case (oldAcc, input, loopback) of
            (Just a, Just n, Just l) -> (Just a, Just (n, l))
            (Just a, Just n, Nothing) -> (Nothing, Just (a, n))
            (Just a, Nothing, Just l) -> (Nothing, Just (a, l))
            (Nothing, Just n, Just l) -> (Nothing, Just (n, l))
            (Just a, Nothing, Nothing) -> (Just a, Nothing)
            (Nothing, Just n, Nothing) -> (Just n, Nothing)
            (Nothing, Nothing, Just l) -> (Just l, Nothing)
            (Nothing, Nothing, Nothing) -> (Nothing, Nothing)


Или так?
balinF'' :: Maybe i -> Maybe i -> Maybe i -> (Maybe i, Maybe (i, i))
balinF'' a b c = case (mapMaybe id [a,b,c]) of
    [x,y,z] -> (Just x, Just (y, z))
    [x,y] -> (Nothing, Just (x, y))
    [x] -> (Just x, Nothing)
    [] -> (Nothing, Nothing)
I might be wrong...
Re[24]: Каким отладчиком пользовались разработчики Kx System
От: Cyberax Марс  
Дата: 20.03.09 13:21
Оценка: +1
Здравствуйте, thesz, Вы писали:

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

Видимо, вопроса не поняли. Или IDEA пользоваться не умеют.
Sapienti sat!
Re[33]: Каким отладчиком пользовались разработчики Kx System
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 21.03.09 09:01
Оценка: +1
Здравствуйте, Cyberax, Вы писали:
Здравствуйте, thesz, Вы писали:

Мужики, вы о разном говорите. Да, Haskell тоже не помешают некоторые инструменты. Да, некоторые из финтифлюшек IDEA — костыли, следствие низкого уровня Java.

C>Зато позволяет inect'ить в код практически ЛЮБОЙ язык. Например, в модуле поддержки GWT это используется для разбора JavaScript-кода внутри комментариев в Java-коде — http://www.jetbrains.com/idea/features/gwt.html Причём в этом JS-коде полностью работает автокомплит, поддержка JQuery с подвязками автокомплита к CSS, рефакторинг и т.д.

C>Я не думаю, что это было бы возможно в каком-либо DSLе. Даже в Haskell'е.

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

C>Сейчас следующим языком, который я буду использовать после Питона и Java станет, скорее всего, Scala. Слишком избалован я нормальными IDE.


Я постепенно прихожу к выводу, что Scala возникла тоже из-за низкого уровня Java А это не та причина, по которой надо создавать новый язык, IMHO. А то получится Scala — монстр типа С++. Язык с набором несвязанных фич вместо языка с фичами, уложенными в некую систему. Хотя, вполне допускаю, что я пока просто эту систему не вижу.
Re[28]: Каким отладчиком пользовались разработчики Kx System
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 21.03.09 19:56
Оценка: +1
Здравствуйте, thesz, Вы писали:

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


T>Ну, как тебе сказать.


T>Вот в игростроении, например. Делал всё, как все остальные: DirectX прямо в коде, без всякой обвязки. Так у меня на две тысячи строк кода взрывов было всего порядка пяти или шести вызовов D3D — DrawIndexPrimitive и установка параметров шейдеров. Да, я использовал уже написанный collision detection и выборку по миру. Так это был нами написанный код.


Собственно, об этом и речь, что предметная область довольно специфическая. Как в свое время АСУТП была -- народ писал сам все, начиная от драйверов устройств и заканчивая рисованием исторических трендов. Затем, постепенно, развились SCADA системы и некоторые классы информационно-измерительных систем стали решаться на раз, с помощью только визуального программирования.

В той же игровой индустрии для ПК инструменты типа OpenGL, DirectX или SDL так же не сразу появились, но постепенно подобные библиотеки берут на себя изрядную часть забот разработчика.

E>>Вот в моем проекте, которым я занимаюсь последние несколько лет, порядка 100K строк прикладного кода. Самые большие из задействованных в нем библиотек -- ACE (330K строк), SObjectizer (50K), ObjESSty (60K). Не считая того кода, который спрятан в ODBC, реляционных БД, http-серверах.


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


С++ используем.

T>Библиотеки — это те же самые языки программирования. Их возможности используются процентов на 10, хорошо если так много. Просто разным людям нужны разные возможности, вот и пестрота с объёмом наперевес.


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

T>И в заключении: деньги платят за решение проблем, которые никто ещё не решал. Не решённые проблемы не существуют в виде библиотек. Уже существующими библиотеками можно только облегчить свою судьбу, но не уйти от неё совсем.


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[31]: Каким отладчиком пользовались разработчики Kx System
От: dmz Россия  
Дата: 22.03.09 01:57
Оценка: +1
C>Просто недавно заметил — если писать на Питоне, то кода где-то раза в два меньше, чем на Java получается. Но только пишется он где-то раза в два медленнее.

Это странно. При всех своих недостатках, питон все же выше уровнем чем жаб... джава раза эдак в четыре.
Re[33]: Каким отладчиком пользовались разработчики Kx System
От: dmz Россия  
Дата: 22.03.09 03:42
Оценка: +1
dmz>>Это странно. При всех своих недостатках, питон все же выше уровнем чем жаб... джава раза эдак в четыре.
C>Чем выше? Ну есть у него list comprehensions и прочие вкусности. Из-за этого и получается код меньше.

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

Ну вот теже list comprehensions. lambda. Декораторы. Перегружаемые операторы. Доступ к собственному AST. Богатая стандартная библиотека. Вроде все мелочи, но вот так и набегает.

C>Зато в Java у меня есть умный автокомплит и средства генерации кода, которые сглаживают разницу в объёме.


Черт его знает. Автокомпилит за тебя код писать не будет. "Средства генерации кода" вроде должны, но если их есть и они такие удобные, зачем тогда умный автокомплит — написал немного кода, и он сгенерил тебе МНОГО кода. А когда кода мало, так что можно глазом охватить — то вроде как и умный автокомплит не нужен. В частности, зачем он тебе нужен для SQL, если этот SQL генерится из представления твоих данных и идеологии работы с ними
и ты в глаза его не видишь, этот SQL?

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

Опять же, о скорости набора. Нажал, подождал, выбрал из из списка. Который еще придется листать и смотреть. Это что, быстрее, чем просто написать ?
Re[46]: Каким отладчиком пользовались разработчики Kx System
От: palm mute  
Дата: 23.03.09 13:21
Оценка: :)
Здравствуйте, lomeo, Вы писали:

C>>Ну HTML — ладно. А вот CSS — точно будет редактировать напрямую. Ибо нафиг ему Haskell не сдался.

L>Отвечу обоим. В общем, да согласен. Я CSS не генерил ещё, кажется Но и названия классов чтобы менялись — не вспомню.
L>Но я предупреждал, что пример не очень удачный
Генератор CSS на Haskell
Каким отладчиком пользовались разработчики Kx Systems?
От: thesz Россия http://thesz.livejournal.com
Дата: 06.03.09 11:37
Оценка:
Мне интересен период, когда они писали самую первую версию kdb.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[2]: Каким отладчиком пользовались разработчики Kx Systems
От: thesz Россия http://thesz.livejournal.com
Дата: 06.03.09 12:03
Оценка:
T>>Мне интересен период, когда они писали самую первую версию kdb.
KP>Логи? В принципе, для отладки любого приложения этого достаточно, при умении ими пользоваться, конечно.

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

Как они с поддержкой программ для Wall Street справляются?..
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[4]: Каким отладчиком пользовались разработчики Kx Systems
От: thesz Россия http://thesz.livejournal.com
Дата: 06.03.09 12:42
Оценка:
T>>Как они с поддержкой программ для Wall Street справляются?..
KP>А он вообще нужен? Лично для меня, необходимость в отладчике очч спорный момент. Если он есть, это безусловно хорошо, но если его нет, то логов всегда достаточно. А если еще и библиотека логирования хорошая, то отладчик скорее будет лишним

Сколько людей, столько и мнений
Автор: eao197
Дата: 06.03.09
.

Моё, кстати, примерно такое же, как у тебя.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[5]: Каким отладчиком пользовались разработчики Kx Systems
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 06.03.09 13:10
Оценка:
Здравствуйте, thesz, Вы писали:

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

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

T>Сколько людей, столько и мнений
Автор: eao197
Дата: 06.03.09
.


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


На мой взгляд тут довольно просто все. Если человек писал под большое количество платформ, то он наверняка хорошо умеет работать с логами, в особенности если приходилось писать поп встроенные/мобильные платформы. Если же основной опыт это Java, .NET и только под Винду.. Ну что ждать от такого конеченого человека
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[10]: Каким отладчиком пользовались разработчики Kx System
От: FR  
Дата: 07.03.09 04:36
Оценка:
Здравствуйте, thesz, Вы писали:

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


Не надо крайностей.
По моему опыту очень полезно отказатся от отладчика при написании нового кода, это реально
ускоряет его написание и повышает качество. Но отказ от использования отладчика при подержке
и модернизации даже своего (не говоря уже о чужом) коде вреден и замедляет работу.
Re[11]: Каким отладчиком пользовались разработчики Kx System
От: thesz Россия http://thesz.livejournal.com
Дата: 07.03.09 10:32
Оценка:
T>>Тогда чего ты насчёт необходимости отладчика упираешься?
FR>Не надо крайностей.
FR>По моему опыту очень полезно отказатся от отладчика при написании нового кода, это реально
FR>ускоряет его написание и повышает качество. Но отказ от использования отладчика при подержке
FR>и модернизации даже своего (не говоря уже о чужом) коде вреден и замедляет работу.

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

ОЧЕНЬ СИЛЬНО.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[8]: Каким отладчиком пользовались разработчики Kx Systems
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.03.09 12:02
Оценка:
Здравствуйте, thesz, Вы писали:

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


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


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

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

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

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

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

Есть много людей знающих толк в отладке логированием, но предпочитающих отладчики для многих задач. Конечно иногда логирование является единственным подходящим способом (нет отладчика, отладчик влияет на работу приложения и т.п.). Но это именно что исключения.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Каким отладчиком пользовались разработчики Kx System
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.03.09 12:14
Оценка:
Здравствуйте, thesz, Вы писали:

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


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


Дык когда человек говорит о том, что не знает это и называется тем самым словом за которое тут могут забанить .
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Каким отладчиком пользовались разработчики Kx System
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.03.09 12:22
Оценка:
Здравствуйте, thesz, Вы писали:

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


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


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

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

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


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

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


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

Сдается мне, что в средствах разрабоки которые ты используешь хреновые отладчики, вот ты и докажываешь всем окружающим, что они тебе не нужны.
В прочем, не нужны — не пользуйся. Что других то за советскую власть агетировать?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Каким отладчиком пользовались разработчики Kx System
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.03.09 12:26
Оценка:
Здравствуйте, FR, Вы писали:

FR>Не надо крайностей.

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

А какой смысл отказываться от отладчика при отладке ошибок в новом коде? Не, я конечно понимаю, что если ошибок нет, то нет нужны и в отладчике. Но если они есть, то что?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Каким отладчиком пользовались разработчики Kx System
От: FR  
Дата: 07.03.09 13:06
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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

Ошибки конечно бывает, но по моему тесты (еще очень большой плюс REPL) ловят их быстрее и надежнее отладчика.
Re[13]: Каким отладчиком пользовались разработчики Kx System
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.03.09 21:46
Оценка:
Здравствуйте, FR, Вы писали:

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


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

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


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

От тебя про реплы слушать вообще смешно (в контексте твоей современной работы на С++).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Каким отладчиком пользовались разработчики Kx System
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.03.09 22:03
Оценка:
Здравствуйте, thesz, Вы писали:

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


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

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


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

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


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

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


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


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

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


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


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

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


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

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


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


Лучшими их ты назначил?
Да и прежде чем на кого-то ориентироваться неплохо было бы с ними хотя бы познакомиться.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Каким отладчиком пользовались разработчики Kx System
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.03.09 00:00
Оценка:
Здравствуйте, Didro, Вы писали:

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


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

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


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

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


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

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


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

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

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

D>Кстати по отладке (в т.ч. и без отладчика) на DTF был хороший цикл статей:

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

Не открывается. Возможно снова РСДН-ДоС.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Каким отладчиком пользовались разработчики Kx System
От: dmz Россия  
Дата: 08.03.09 04:52
Оценка:
T>Поэтому не надо использовать Java и не надо использовать генераторы разборщиков. Обе эти вещи относятся к 90-м года двадцатого века.

Все таки надо сказать что-нибудь хорошее про генераторы разборщиков. В ocamlyacc большая часть ошибок вылавливается на этапе компиляции, и, например, для бипа — yacc не создал ни одной проблемы вообще. Даже отладочная печать AST недоделана, поскольку не понадобидась. Уж не знаю, зачем бы там был отладчик.
Re[10]: Каким отладчиком пользовались разработчики Kx System
От: FR  
Дата: 08.03.09 05:46
Оценка:
Здравствуйте, thesz, Вы писали:

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


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


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


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

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


Кстати у Ocaml'а очень хороший отладчик, подерживает шагание в обе стороны, правда полноценно работает только в linux. Я линукс на ноут поставил чтобы на него посмотреть, еще установил OcaIDE и до сих пор тащусь
Re[14]: Каким отладчиком пользовались разработчики Kx System
От: FR  
Дата: 08.03.09 05:52
Оценка:
Здравствуйте, VladD2, Вы писали:


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


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

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


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


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

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


Ну у меня сейчас вообще весело, просто мечта для ненавистников отладчика, boot-time и NT Native API,
отладка по логам, вместо REPL'а VirtualBox
Re[14]: Каким отладчиком пользовались разработчики Kx System
От: FR  
Дата: 08.03.09 05:55
Оценка:
Здравствуйте, VladD2, Вы писали:

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


Вообще идеально отладчик интегрирован в Smalltalk, вот в нем вполне реально писать в отладчике
Re[15]: Каким отладчиком пользовались разработчики Kx System
От: Lonely Dog Россия  
Дата: 08.03.09 09:31
Оценка:
Здравствуйте, FR, Вы писали:

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

Сорри, что вмешиваюсь в ваш спор.
Если не секрет, для каких задач применяете Native API?
Под boot-time подразумеваете boot-execute apps или драйвера?
Спасибо.
Re[14]: Каким отладчиком пользовались разработчики Kx System
От: Didro Россия home~pages
Дата: 08.03.09 09:46
Оценка:
Здравствуйте, VladD2, Вы писали:

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

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

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

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


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

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

Re[16]: Каким отладчиком пользовались разработчики Kx System
От: FR  
Дата: 08.03.09 11:38
Оценка:
Здравствуйте, Lonely Dog, Вы писали:

LD>Если не секрет, для каких задач применяете Native API?

LD>Под boot-time подразумеваете boot-execute apps или драйвера?
LD>Спасибо.

boot-execute apps, дефрагментатор и оптимизатор реестра.
Re[11]: Каким отладчиком пользовались разработчики Kx System
От: thesz Россия http://thesz.livejournal.com
Дата: 08.03.09 13:59
Оценка:
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>Лучшими их ты назначил?

Не только я. Но ты волен выбрать других, я же только как пример их привёл.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[13]: Каким отладчиком пользовались разработчики Kx System
От: thesz Россия http://thesz.livejournal.com
Дата: 08.03.09 14:10
Оценка:
T>>Поэтому не надо использовать Java и не надо использовать генераторы разборщиков. Обе эти вещи относятся к 90-м года двадцатого века.
dmz>Все таки надо сказать что-нибудь хорошее про генераторы разборщиков. В ocamlyacc большая часть ошибок вылавливается на этапе компиляции, и, например, для бипа — yacc не создал ни одной проблемы вообще. Даже отладочная печать AST недоделана, поскольку не понадобидась. Уж не знаю, зачем бы там был отладчик.

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

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

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

Ха, буду знать, спасибо!
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[11]: Каким отладчиком пользовались разработчики Kx System
От: thesz Россия http://thesz.livejournal.com
Дата: 08.03.09 14:18
Оценка:
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 (придётся отказаться от произвольной структуры проекта).

Буду тащиться.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[12]: Каким отладчиком пользовались разработчики Kx System
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 08.03.09 14:24
Оценка:
Здравствуйте, thesz, Вы писали:

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


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

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


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


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

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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[12]: Каким отладчиком пользовались разработчики Kx System
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 08.03.09 14:28
Оценка:
Здравствуйте, thesz, Вы писали:

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

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

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




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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[13]: Каким отладчиком пользовались разработчики Kx System
От: thesz Россия http://thesz.livejournal.com
Дата: 08.03.09 16:09
Оценка:
T>>Они их пишут годами потому, что 1) тяжело тестировать, 2) надо поддерживать всех на свете, 3) ЯП дурацкий и ещё много причин.
FR>Реальна только вторая причина.

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

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

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

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

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

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

Объясняй.

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

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

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


Нет, не напишу, поскольку буду занят использованием ЯП в моих гнусных целях. Поэтому придётся копить деньги на ноутбук и далее по списку.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[13]: Каким отладчиком пользовались разработчики Kx System
От: thesz Россия http://thesz.livejournal.com
Дата: 08.03.09 16:09
Оценка:
T>>>>Это он, по-моим расчётам, положил на это чудо не менее двух или трёх недель.
T>>>>У меня на .BAT файлах (ну, CMD — под OS/2) это столько и заняло — две недели. На тикле вдвое быстрее.
FR>>>Угу любая программа пишется хорошим программистом за два дня, в худшем случае за пару недель.
FR>>>Правда авторы аналогов того что написал eao197 об этом не знают и годами пишут свои scons'ы

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


E>


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


Она во второй находится, нет?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[13]: Каким отладчиком пользовались разработчики Kx System
От: thesz Россия http://thesz.livejournal.com
Дата: 08.03.09 16:17
Оценка:
T>>Это всё в глазах наблюдателя.
E>Отрадно, что ты это понимаешь. Остается надежда, что этот же аргумент ты когда-нибудь научишься применять к себе.

Так я уже!

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

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


Понятно.

Поменять язык как-либо в сторону большей декларативности невозможно почему именно? (если что, то мне действительно интересно)
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[14]: Каким отладчиком пользовались разработчики Kx System
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 08.03.09 16:27
Оценка:
Здравствуйте, thesz, Вы писали:

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


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[14]: Каким отладчиком пользовались разработчики Kx System
От: FR  
Дата: 08.03.09 17:41
Оценка:
Здравствуйте, thesz, Вы писали:


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

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

T>Объясняй.


По моему бесполезно
Re[16]: Каким отладчиком пользовались разработчики Kx System
От: FR  
Дата: 08.03.09 18:27
Оценка:
Здравствуйте, thesz, Вы писали:

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


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


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

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


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


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

T>PS

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

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


Ну тут совсем мимо, в данный момент у меня вполне интересная работа. Боротся с недокументированными потрохами виндов не менее интересно чем изучать новые языки
Re[17]: Каким отладчиком пользовались разработчики Kx System
От: thesz Россия http://thesz.livejournal.com
Дата: 08.03.09 18:59
Оценка:
FR>>>По моему бесполезно
T>>Это можно толковать двояко: либо я (и другие приверженцы ФП) тупы, либо ты не умеешь объяснять.
FR>Нет, совсем другое, извини за грубость, но ты сейчас токуешь, и не видишь вокруг ничего, объяснять
FR>что-то хоть чуть-чуть не совпадающее с его мнением человеку в таком состоянии абсолютно бесполезно

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

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

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

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

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

Зависимо.

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

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

И ещё раз: чем же прототип отличается от продукта?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[18]: Каким отладчиком пользовались разработчики Kx System
От: FR  
Дата: 08.03.09 19:09
Оценка:
Здравствуйте, thesz, Вы писали:

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


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


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


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

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

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

T>Зависимо.


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


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

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


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


Тем что в нем нет тех мелочей на которые реально приходится 90% работы.
Re[19]: Каким отладчиком пользовались разработчики Kx System
От: thesz Россия http://thesz.livejournal.com
Дата: 08.03.09 20:00
Оценка:
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% времени! Это означает, что написав прототип за пяток недель, за оставшиеся пять недель мы получим готовый продукт!

Ура, товарищи!
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[20]: Каким отладчиком пользовались разработчики Kx System
От: FR  
Дата: 08.03.09 20:17
Оценка:
Здравствуйте, thesz, Вы писали:

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


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

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


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

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


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

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

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

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


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


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


Не я конечно уважаю и иронию и юмор с сатирой, но переигрываешь
Re[21]: Каким отладчиком пользовались разработчики Kx System
От: thesz Россия http://thesz.livejournal.com
Дата: 09.03.09 14:38
Оценка:
T>>Это нормально. Я преувеличивал для достижения нужного эффекта.
FR>Несолидно. После этого и заявления о преимуществах ФП также будут казатся преувеличенными.

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

Ещё раз.

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

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

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

Да ты что!

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

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

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

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

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


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


Исключительно ради повеселить.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[22]: Каким отладчиком пользовались разработчики Kx System
От: FR  
Дата: 09.03.09 15:59
Оценка:
Здравствуйте, thesz, Вы писали:

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


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

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


T>Да ты что!


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


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

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


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


Вот тут не понял, раскрой.
Re[23]: Каким отладчиком пользовались разработчики Kx System
От: thesz Россия http://thesz.livejournal.com
Дата: 09.03.09 17:10
Оценка:
T>>Я боролся с образом "подвига". Ни один из DS(E)L eao я не считаю достаточно героическим. Основное его преимущество в наличии PDF про это дело при наличии отсутствия PDF у меня. Сама же техническая сторона ни рыба, ни мясо. Повторение не раз пройденного.
FR>Странное у тебя восприятие, я никакого "образа подвига" не увидел.
FR>Ты же вроде тоже бывший фортер, так что DSL должно быть для тебя обыденной, рутиной вещью.

Именно.

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

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

Где?

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

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

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

Это в Peopleware описано. Вот тут я кусочек цитировал: http://thesz.livejournal.com/446422.html
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[24]: Каким отладчиком пользовались разработчики Kx System
От: FR  
Дата: 09.03.09 17:30
Оценка:
Здравствуйте, 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


На меня кстати похоже действует, в тишине я лучше работаю, но если в работу реально уходишь то уже просто ничего вокруг не видно и не слышно
Re[25]: Каким отладчиком пользовались разработчики Kx System
От: thesz Россия http://thesz.livejournal.com
Дата: 10.03.09 00:27
Оценка:
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>На меня кстати похоже действует, в тишине я лучше работаю, но если в работу реально уходишь то уже просто ничего вокруг не видно и не слышно

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

Ровно противоположное "избежать кодирования".
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[26]: Каким отладчиком пользовались разработчики Kx System
От: FR  
Дата: 10.03.09 04:02
Оценка:
Здравствуйте, thesz, Вы писали:

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


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

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


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


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

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


Угу, это интересное развлечение, но очень часто "хорошо подумать, написать короткий красивый код" по времени и результату одинаково с "думать некогда, кодировать кодировать и кодировать"
Re[27]: Каким отладчиком пользовались разработчики Kx System
От: thesz Россия http://thesz.livejournal.com
Дата: 10.03.09 10:05
Оценка:
T>>Слишком широко. Толком не видно.
FR>Нормально видно

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

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

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

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

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

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

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

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

После чего приходят изменения и выигрыш становится виден.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[28]: Каким отладчиком пользовались разработчики Kx System
От: FR  
Дата: 10.03.09 10:59
Оценка:
Здравствуйте, thesz, Вы писали:

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


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

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


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


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


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


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

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

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


Не обязательно, изменения они такая подлая вещь, что и умный красивый код тоже приходится переписывать.
Re[23]: Каким отладчиком пользовались разработчики Kx System
От: vdimas Россия  
Дата: 10.03.09 15:39
Оценка:
Здравствуйте, FR, Вы писали:


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


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

Я тут как-то высказывал мысли о возможности сделать типобезопасный форт с явной аннотацией состояний стека, а алгоритм верификации этих состояний в процессе компиляции вполне прост. Так что, если есть интерес, можно пообсуждать.
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[11]: Каким отладчиком пользовались разработчики Kx System
От: thesz Россия http://thesz.livejournal.com
Дата: 10.03.09 15:56
Оценка:
T>>Зачем мне ускорять отладку программ на Си, если я могу взять OCaml без отладчика и всё равно оказаться быстрей?
T>>Неужто непонятно такое простое соображение?
V>Что-то мне логика здесь не понятна. А что именно мы собираемся отлаживать? Если ошибки интерпретации памяти искать — это одно, а если надо сам алгоритм отлаживать, то пофиг на каком языке было написано, в случае той самой алгоритмической ошибки. Даже абсолютно правильно реализованный алгоритм, скажем, обработки сигналов, может выкидывать фортели на некоторых данных из-за банального переполнения. А вот в уже приведённом примере использования третьесторонних библиотек, да еще если дока не полна или, как бывает, расхождения док-ции и реального поведения, то тут без отладки в любом виде никак.

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

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

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

Так что я предпочту другой язык, пусть даже с подкачкой ручками, чем Си с отладчиком.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[24]: Каким отладчиком пользовались разработчики Kx System
От: FR  
Дата: 10.03.09 16:00
Оценка:
Здравствуйте, vdimas, Вы писали:


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


Вроде такие форты уже есть например http://factorcode.org/
Re[12]: Каким отладчиком пользовались разработчики Kx System
От: FR  
Дата: 10.03.09 16:06
Оценка:
Здравствуйте, thesz, Вы писали:

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


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

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


На 16 Кб у нас форт с трасировщиком вполне помещался.
А на 48 и с отладчиком и монитором.
Re[13]: Каким отладчиком пользовались разработчики Kx System
От: thesz Россия http://thesz.livejournal.com
Дата: 10.03.09 16:26
Оценка:
T>>Эх, молодёжь!
FR>Самокритика?

Типа того.

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


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

FR>А на 48 и с отладчиком и монитором.

Сколько разработчиков было? Ты, да я, да мы с тобой, итого четверо?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[24]: Каким отладчиком пользовались разработчики Kx System
От: thesz Россия http://thesz.livejournal.com
Дата: 10.03.09 16:32
Оценка:
V>Я тут как-то высказывал мысли о возможности сделать типобезопасный форт с явной аннотацией состояний стека, а алгоритм верификации этих состояний в процессе компиляции вполне прост. Так что, если есть интерес, можно пообсуждать.

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

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

Но иногда!
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[14]: Каким отладчиком пользовались разработчики Kx System
От: FR  
Дата: 10.03.09 16:35
Оценка:
Здравствуйте, thesz, Вы писали:

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

FR>>А на 48 и с отладчиком и монитором.

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


Фортеры они любят гордое одиночество
Потом правда двое стало.
Re[15]: Каким отладчиком пользовались разработчики Kx System
От: thesz Россия http://thesz.livejournal.com
Дата: 10.03.09 16:41
Оценка:
T>>Сколько разработчиков было? Ты, да я, да мы с тобой, итого четверо?
FR>Фортеры они любят гордое одиночество
FR>Потом правда двое стало.

В общем, у нас проект был посложней.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[7]: Каким отладчиком пользовались разработчики Kx Systems
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 10.03.09 18:10
Оценка:
Здравствуйте, eao197, Вы писали:

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


Думаю что доблесть скорее во внимательном чтении поста перед ответом. Ну да ладно, флуд у вас куда лучше, нежели у меня выходит.
Re[12]: Каким отладчиком пользовались разработчики Kx System
От: vdimas Россия  
Дата: 10.03.09 18:40
Оценка:
Здравствуйте, thesz, Вы писали:

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

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

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

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

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

Я здесь не могу разглядеть ответа насчёт использования третьесторонних либ. Ты предлагаешь ими не пользоваться вообще?
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[13]: Каким отладчиком пользовались разработчики Kx System
От: thesz Россия http://thesz.livejournal.com
Дата: 10.03.09 19:45
Оценка:
T>>Эх, молодёжь!
T>>На 640K банкомата, что ought to be enough for everyone, даже td386 не запускался, если не говорить о количестве трудов, которых стоило его туда занести.
V>Т.е., кто с банкомётами не работал, тот автоматом молодёжь? Занятно, но постолько-поскольку...

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

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

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

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

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

Всё остальное себе дороже.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[15]: Каким отладчиком пользовались разработчики Kx System
От: thesz Россия http://thesz.livejournal.com
Дата: 11.03.09 04:45
Оценка:
T>>Алгоритмические ошибки без отладчика ловятся на раз. Усилю утверждение, сказав, что ловля алгоритмических ошибок отладчиком — потеря времени.
V>Не боишься подставиться столь громкими заявлениями? Попробуешь доказать свои слова? Учитывая, что цель любой отладки в первую очередь в локализации ошибок, мне даже интересно, что же ты себе там надумал, что выдал столь суровое утверждение.

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

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


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

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

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

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

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

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

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


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

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

За более, чем 10 лет использования Хаскеля, я столкнулся всего с двумя ошибками: проблемы рантайма под windows в ghc 6.6 (ограничение сверху на хип) и, недавно, совершенно не критичная ошибка с отсутствие поддержки семейств типов в template haskell.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[14]: Каким отладчиком пользовались разработчики Kx System
От: yumi  
Дата: 12.03.09 00:59
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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

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


На самом деле для большинства (низкоквалифицированных), это средство лечения симптоматики, а не самой проблемы в корне. Конечно, в умелых руках, отладчик отличный инструмент.
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org
Re[11]: Каким отладчиком пользовались разработчики Kx System
От: dmz Россия  
Дата: 12.03.09 03:06
Оценка:
T>>Зачем мне ускорять отладку программ на Си, если я могу взять OCaml без отладчика и всё равно оказаться быстрей?

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


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

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

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

Когда я, будучи школьником, писал демки — которые там что-то вычисляли в цикле из десятка параметров — то, если бы я пытался отлавливать глюки путем пошагового исполнения, так бы до сих пор и отлаживался, я думаю. Гораздо продуктивнее оказалось добавить логи и построить графики значений одних переменных в зависимости от других — разрывы и причина были найдены с первого взгляда на них. С тех пор и повелось.
Re[12]: Каким отладчиком пользовались разработчики Kx System
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 12.03.09 04:21
Оценка:
Здравствуйте, dmz, Вы писали:

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


Тут часто говорят про логи вместо отладчика. А вот как происходит добавление логов в программы на Хаскеле? Там же должно быть до фига чистых функций, которые для добавления одной строчки вывода в лог придется оборачивать в хламидомонады, т.е. менять их тип, т.е. переписывать почти всю программу. Или есть простое решение?
Re[13]: Каким отладчиком пользовались разработчики Kx System
От: dmz Россия  
Дата: 12.03.09 06:28
Оценка:
DM>Тут часто говорят про логи вместо отладчика. А вот как происходит добавление логов в программы на Хаскеле? Там же должно быть до фига чистых функций, которые для добавления одной строчки вывода в лог придется оборачивать в хламидомонады, т.е. менять их тип, т.е. переписывать почти всю программу. Или есть простое решение?

Гы. Знал бы хаскелл — сказал. Из того, что я о нем знаю — это действительно может быть проблемой Кастую Summon thesz. Если получится — то он явится и разъяснит.
Re[13]: Каким отладчиком пользовались разработчики Kx System
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 12.03.09 07:39
Оценка:
Здравствуйте, D. Mon, Вы писали:

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


import Debug.Trace

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

foo = trace "foo" (sum [1..10])
Re[13]: Каким отладчиком пользовались разработчики Kx System
От: thesz Россия http://thesz.livejournal.com
Дата: 12.03.09 09:21
Оценка:
dmz>> Гораздо продуктивнее оказалось добавить логи
DM>Тут часто говорят про логи вместо отладчика. А вот как происходит добавление логов в программы на Хаскеле? Там же должно быть до фига чистых функций, которые для добавления одной строчки вывода в лог придется оборачивать в хламидомонады, т.е. менять их тип, т.е. переписывать почти всю программу. Или есть простое решение?

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

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

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

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

Видно, что к чему.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[14]: Каким отладчиком пользовались разработчики Kx System
От: dmz Россия  
Дата: 12.03.09 10:06
Оценка:
T>Я предпочитаю протягивать логи через типы. Была функция a -> b, стала a -> (b,String).

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

Посмотреть бы реальный пример какой-нибудь.
Re[15]: Каким отладчиком пользовались разработчики Kx System
От: thesz Россия http://thesz.livejournal.com
Дата: 12.03.09 11:45
Оценка:
T>>Я предпочитаю протягивать логи через типы. Была функция a -> b, стала a -> (b,String).
dmz>Я правильно понимаю, что сообщение лога возвращается вместо исходного значения?

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

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


Да! Именно!

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

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


Затруднюсь прямо сейчас.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[16]: Каким отладчиком пользовались разработчики Kx System
От: dmz Россия  
Дата: 12.03.09 12:15
Оценка:
dmz>>Посмотреть бы реальный пример какой-нибудь.

T>
T>#ifdef __LOGGING__
T>


Это сишный препроцессор, натравливаемый на исходники перед компиляцией настоящим компилятором?
Re[17]: Каким отладчиком пользовались разработчики Kx System
От: thesz Россия http://thesz.livejournal.com
Дата: 12.03.09 13:04
Оценка:
dmz>>>Посмотреть бы реальный пример какой-нибудь.
T>>
T>>#ifdef __LOGGING__
T>>


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


Ага.

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

Такое требуется уже потом, когда нужна скорость. Я описал на случай, если потребуется.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[14]: Каким отладчиком пользовались разработчики Kx System
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 12.03.09 16:22
Оценка:
Здравствуйте, thesz, Вы писали:

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


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


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[14]: Каким отладчиком пользовались разработчики Kx System
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 12.03.09 17:12
Оценка:
Здравствуйте, thesz, Вы писали:

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


Или когда они нестандартные. У нас на icfpc2008 был gtrace :: String -> DrawObject -> a -> a, который выводил графические примитивы на карту. Причём анимацию, карта не мусорилась. Тоже для чистых функций, разумеется.
Re[15]: Каким отладчиком пользовались разработчики Kx System
От: thesz Россия http://thesz.livejournal.com
Дата: 12.03.09 17:37
Оценка:
T>>Программы на Хаскеле чистые и в них ошибок быть не может.
E>Да ладно, приоритеты операций можно перепутать где угодно и записать x*a+c вместо x*(a+c) на любом языке программирования. На функциональных, может быть, даже проще, т.к. функциональщики скобок не любят

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

(прошу прощения, удержаться не мог)
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[15]: Каким отладчиком пользовались разработчики Kx System
От: thesz Россия http://thesz.livejournal.com
Дата: 12.03.09 21:43
Оценка:
T>>Некоторые продвинутые делают что-то на основе unsafePerformIO, это когда логов много.
L>Или когда они нестандартные. У нас на icfpc2008 был gtrace :: String -> DrawObject -> a -> a, который выводил графические примитивы на карту. Причём анимацию, карта не мусорилась. Тоже для чистых функций, разумеется.

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

Хотя это могло иметь смысл.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[7]: Каким отладчиком пользовались разработчики Kx Systems
От: gear nuke  
Дата: 17.03.09 08:35
Оценка:
Здравствуйте, eao197, Вы писали:

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


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

Фразу "отладчик не нужен" я бы заменил на "им нужно уметь пользоваться настолько хорошо, что бы вообще не запускать".
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re[17]: Каким отладчиком пользовались разработчики Kx System
От: thesz Россия http://thesz.livejournal.com
Дата: 17.03.09 21:13
Оценка:
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>Так что, к выбору инструментария у меня подход весьма прямолинейный — необходимо чтобы сам инструментарий не веселил своими причудами, ибо не до него.


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

Ты от количества багов, я от невозможности "вот это описать вот так кратко".
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[20]: Каким отладчиком пользовались разработчики Kx System
От: Gajdalager Украина  
Дата: 18.03.09 15:31
Оценка:
Здравствуйте, 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
<< RSDN@Home 1.2.0 alpha 4 rev. 1128>>
Сейчас играет Ayreon — Amazing Flight
Re[20]: Каким отладчиком пользовались разработчики Kx System
От: vdimas Россия  
Дата: 19.03.09 04:32
Оценка:
Здравствуйте, 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>Хаскель взял под козырёк и пошёл выполнять.


Не Хаскель, так другой, не принципиально. Случится смешная и грустная одновременно ситуация, когда ФП языки, худшие чем Хаскель, станут более популярны "по техническим причинам".
Re[20]: Каким отладчиком пользовались разработчики Kx System
От: WolfHound  
Дата: 19.03.09 08:59
Оценка:
Здравствуйте, 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 везде лишний.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[21]: Каким отладчиком пользовались разработчики Kx System
От: thesz Россия http://thesz.livejournal.com
Дата: 19.03.09 10:03
Оценка:
V>>>Да ради бога, хоть Emacs, хоть Eclipse, хоть VS. (Не принципиально, хотя, нормального context-sensitive intellicense я в Emacs ни разу не видел, или что-то изменилось за последние лет 8?)
T>>Я тоже. Но я не видел его ни в какой другой среде.
G>А IntelliJ Idea ты видел?

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

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


Это те же олухи, что и MPS?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[21]: Каким отладчиком пользовались разработчики Kx System
От: thesz Россия http://thesz.livejournal.com
Дата: 19.03.09 10:04
Оценка:
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 везде лишний.

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

Даже удивительно, что ты не сделал это сразу.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[21]: Каким отладчиком пользовались разработчики Kx System
От: thesz Россия http://thesz.livejournal.com
Дата: 19.03.09 10:29
Оценка:
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?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[21]: Каким отладчиком пользовались разработчики Kx System
От: thesz Россия http://thesz.livejournal.com
Дата: 19.03.09 10:34
Оценка:
T>>Да брось ты!
T>>При написании кода с глубоким заглядыванием наподобие нижеприведённого:
V>...
T>>Ты замучаешься описывать это дело на системе типов C++. Либо жизнь на это положишь, либо будешь делать это в рантайме. И будешь ловить ошибки.
V>1. А где (EMul b (EConst c), EConst a) -> ?
V>Вот тебе баг и язык тебе никак не помог — ибо прекрасно компилится без этой ветки, в которой выход на вторую половину ситуаций.

Вдогонку.

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

Смог ли бы ты обнаружить столько же всего в коде на плюсах, размазанному по нескольким файлам?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[22]: Каким отладчиком пользовались разработчики Kx System
От: Gajdalager Украина  
Дата: 19.03.09 10:40
Оценка:
Здравствуйте, 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.
<< RSDN@Home 1.2.0 alpha 4 rev. 1128>>
Сейчас играет Ayreon — Out Of The White Hole
Re[23]: Каким отладчиком пользовались разработчики Kx System
От: thesz Россия http://thesz.livejournal.com
Дата: 19.03.09 11:09
Оценка:
T>>Это те же олухи, что и MPS?
G>Да, они самые Те же олухи, что и ReSharper и TeamCity
G>Однако я придрался к утверждению, что "нормального context-sensitive intellicense я не видел его ни в какой другой среде". Ну не видел — значит не видел.. Но в Идее он как раз есть, один из самых умных, AFAIK.

Она не бесплатная и для Java, поэтому ничего сказать не могу.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[23]: Каким отладчиком пользовались разработчики Kx System
От: thesz Россия http://thesz.livejournal.com
Дата: 19.03.09 11:20
Оценка:
G>>>http://www.jetbrains.com/idea/features/code_assistance.html
T>>Это те же олухи, что и MPS?
G>Да, они самые Те же олухи, что и ReSharper и TeamCity
G>Однако я придрался к утверждению, что "нормального context-sensitive intellicense я не видел его ни в какой другой среде".
G>Ну не видел — значит не видел.. Но в Идее он как раз есть, один из самых умных, AFAIK.

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

Подозрительно.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[22]: Каким отладчиком пользовались разработчики Kx System
От: WolfHound  
Дата: 19.03.09 13:05
Оценка:
Здравствуйте, 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." в правой части тоже можно убрать.
Просто пока у меня не дошли руки переделать немерловый вывод типов.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[22]: Каким отладчиком пользовались разработчики Kx System
От: vdimas Россия  
Дата: 19.03.09 20:22
Оценка:
Здравствуйте, thesz, Вы писали:

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

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

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

Конкретно в твоём оформление первые 10 сек мешало отсутствие пробела после запятой, что не позволяло автоматически визуально структурировать текст, приходилось вчитываться, т.е. пользоваться не только мозжечком (отделённые пробелами конструкции составляли одно целое, а через запятую без пробелов — делимое).
Re[22]: Каким отладчиком пользовались разработчики Kx System
От: vdimas Россия  
Дата: 19.03.09 21:06
Оценка:
Здравствуйте, 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?


Наоборот, разделение труда, т.к. уже есть большие готовые прикладные платформы.
Re[23]: Каким отладчиком пользовались разработчики Kx System
От: thesz Россия http://thesz.livejournal.com
Дата: 19.03.09 21:36
Оценка:
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>Наоборот, разделение труда, т.к. уже есть большие готовые прикладные платформы.

Ты уж извини, но когда Хаскель станет успешным, им станешь пользоваться ты. Меня это беспокоит. Ты очень странный.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[23]: Каким отладчиком пользовались разработчики Kx System
От: thesz Россия http://thesz.livejournal.com
Дата: 19.03.09 21:41
Оценка:
T>>Смотри, сколько ты всего обнаружил!
T>>Смог ли бы ты обнаружить столько же всего в коде на плюсах, размазанному по нескольким файлам?
V>Ты што мы говорим? По 3-5 тыс code-review строк в день не хочешь?
V>Разве лишние угловые и фигурные скобки заслонят логику? Если стоит задача реализовать (или проверить) инварианты, то абсолютно пофиг на каком языке, их кол-во и характер от этого не изменится. Человек же не строками кода мыслит, а "понятиями", соотв. пропускная способность и ограничивается не строками, а скоростью переваривания понятий.

Информации. Не понятий, а информации.

Это основное отличие.

См. метрику Хальстеда.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[21]: Каким отладчиком пользовались разработчики Kx System
От: thesz Россия http://thesz.livejournal.com
Дата: 20.03.09 09:43
Оценка:
B>Безотносительно к теме пользования отладчиками, не стало бы понятнее, что делает эта фунция, если ее переписать вот так?
B>
B>balinF' :: Maybe i -> Maybe i -> Maybe i -> (Maybe i, Maybe (i, i))
B>balinF' oldAcc input loopback = case (oldAcc, input, loopback) of
B>            (Just a, Just n, Just l) -> (Just a, Just (n, l))
B>            (Just a, Just n, Nothing) -> (Nothing, Just (a, n))
B>            (Just a, Nothing, Just l) -> (Nothing, Just (a, l))
B>            (Nothing, Just n, Just l) -> (Nothing, Just (n, l))
B>            (Just a, Nothing, Nothing) -> (Just a, Nothing)
B>            (Nothing, Just n, Nothing) -> (Just n, Nothing)
B>            (Nothing, Nothing, Just l) -> (Just l, Nothing)
B>            (Nothing, Nothing, Nothing) -> (Nothing, Nothing)
B>


Длинней. Понятней, но длинней.

B>Или так?

B>
B>balinF'' :: Maybe i -> Maybe i -> Maybe i -> (Maybe i, Maybe (i, i))
B>balinF'' a b c = case (mapMaybe id [a,b,c]) of
B>    [x,y,z] -> (Just x, Just (y, z))
B>    [x,y] -> (Nothing, Just (x, y))
B>    [x] -> (Just x, Nothing)
B>    [] -> (Nothing, Nothing)
B>


Это происходит "в железе", там списков нет. Но на совсем верхнем уровне можно.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[24]: Каким отладчиком пользовались разработчики Kx System
От: vdimas Россия  
Дата: 20.03.09 13:13
Оценка:
Здравствуйте, thesz, Вы писали:

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

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

Эти же ребята сделали Решарпер, так что могу осмысленно говорить лишь про него. Польза отнего не только и не столько в intellisense, сколько в тех хинтах, где он предлагает выполнить некое действие. Как пример — просто объявляю некое приватное поле, а потом alt+enter дважды, чтобы мне инициализацию этого поля встявили в конструктор, и потом сделали геттер на него. И таких действий у него, скажем прямо, немало. Так что, некая "говорливость" кода неплохо компенсируют подбные тулзы.
Re[25]: Каким отладчиком пользовались разработчики Kx System
От: thesz Россия http://thesz.livejournal.com
Дата: 20.03.09 13:51
Оценка:
T>>Сходил к коллегам, осведомился про IDEA. Специально спросил насчёт intellisense. Получил ответ в смысле "интеллисенс у них нормальный, как у всех."
C>Видимо, вопроса не поняли. Или IDEA пользоваться не умеют.

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

Коллективный разум RSDN не подкачал. Он не пропустил это мимо своего внимания, это раз. И он показал свой обычный высокий уровень аргументации, это два.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[27]: Каким отладчиком пользовались разработчики Kx System
От: thesz Россия http://thesz.livejournal.com
Дата: 20.03.09 16:57
Оценка:
C>>>Видимо, вопроса не поняли. Или IDEA пользоваться не умеют.
T>>Когда я написал вот этот параграф выше, мне было некоторое время интересно, что же коллективный разум RSDN придумает.
T>>Коллективный разум RSDN не подкачал. Он не пропустил это мимо своего внимания, это раз. И он показал свой обычный высокий уровень аргументации, это два.
C>Если хочешь, могу более подробно объяснить. Я считаю, что функциональность IDEA во многом делает Java языком более высокого уровня.

Ну, валяй.

Выбери инвариант поинтересней и попробуй поддержать его по участку программы с помощью Java+IDEA. Или попробуй реализовать DSEL и опиши, что надо запомнить конечному пользователю, чтобы быть успешным пользователем этого DSEL.

Хотя меня больше беспокоит что ты огульно назвал моих коллег "не умеющими пользоваться IDEA". Мои коллеги умные, это я тебе точно говорю.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[28]: Каким отладчиком пользовались разработчики Kx System
От: Cyberax Марс  
Дата: 20.03.09 17:36
Оценка:
Здравствуйте, thesz, Вы писали:

T>Выбери инвариант поинтересней и попробуй поддержать его по участку программы с помощью Java+IDEA. Или попробуй реализовать DSEL и опиши, что надо запомнить конечному пользователю, чтобы быть успешным пользователем этого DSEL.

Я могу написать кастомную инспекцию, если прямо так захочется. Например, я уже тут приводил пример с тем, как Hibernate анализирует HQL-запросы в коде:


Ещё можно вспомнить разные удобные рефакторинги — выделение метода, выделение method object'а, упрощение выражений, анализ мёртвого кода и т.п.

T>Хотя меня больше беспокоит что ты огульно назвал моих коллег "не умеющими пользоваться IDEA". Мои коллеги умные, это я тебе точно говорю.

Так это никак не влияет на умение пользоваться IDEA....
Sapienti sat!
Re[29]: Каким отладчиком пользовались разработчики Kx System
От: thesz Россия http://thesz.livejournal.com
Дата: 20.03.09 20:39
Оценка:
T>>Выбери инвариант поинтересней и попробуй поддержать его по участку программы с помощью Java+IDEA. Или попробуй реализовать DSEL и опиши, что надо запомнить конечному пользователю, чтобы быть успешным пользователем этого DSEL.
C>Я могу написать кастомную инспекцию, если прямо так захочется. Например, я уже тут приводил пример с тем, как Hibernate анализирует HQL-запросы в коде:
C>[img]
C>http://files.rsdn.ru/37054/HQLBug.png
C>[/img]

Отличный пример. Он, как бы, говорит сам за себя. Совершенно не требует никаких объяснений.

По нему сразу видно, как можно быстро и удобно сделать DSEL, отдать пользователю и он всё поймёт с полуслова.

C>Ещё можно вспомнить разные удобные рефакторинги — выделение метода, выделение method object'а, упрощение выражений, анализ мёртвого кода и т.п.


Мне это всё совершенно непонятно.

T>>Хотя меня больше беспокоит что ты огульно назвал моих коллег "не умеющими пользоваться IDEA". Мои коллеги умные, это я тебе точно говорю.

C>Так это никак не влияет на умение пользоваться IDEA....

Это ещё хуже, если вдуматься.

Я не про коллег, если что.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[30]: Каким отладчиком пользовались разработчики Kx System
От: Cyberax Марс  
Дата: 20.03.09 20:51
Оценка:
Здравствуйте, thesz, Вы писали:

T>Отличный пример. Он, как бы, говорит сам за себя. Совершенно не требует никаких объяснений.

T>По нему сразу видно, как можно быстро и удобно сделать DSEL, отдать пользователю и он всё поймёт с полуслова.

Вот тут вот есть модуль для работы с RegExp'ами для IDEA: http://svn.jetbrains.org/idea/Trunk/bundled/RegExpSupport/

C>>Ещё можно вспомнить разные удобные рефакторинги — выделение метода, выделение method object'а, упрощение выражений, анализ мёртвого кода и т.п.

T>Мне это всё совершенно непонятно.
Ну непонятно, так непонятно.

C>>Так это никак не влияет на умение пользоваться IDEA....

T>Это ещё хуже, если вдуматься.
T>Я не про коллег, если что.
Да я не спорю.

Просто недавно заметил — если писать на Питоне, то кода где-то раза в два меньше, чем на Java получается. Но только пишется он где-то раза в два медленнее.
Sapienti sat!
Re[31]: Каким отладчиком пользовались разработчики Kx System
От: thesz Россия http://thesz.livejournal.com
Дата: 20.03.09 21:41
Оценка:
T>>Отличный пример. Он, как бы, говорит сам за себя. Совершенно не требует никаких объяснений.
T>>По нему сразу видно, как можно быстро и удобно сделать DSEL, отдать пользователю и он всё поймёт с полуслова.
C>
C>Вот тут вот есть модуль для работы с RegExp'ами для IDEA: http://svn.jetbrains.org/idea/Trunk/bundled/RegExpSupport/

Ты обмолвился, что можешь подробно объяснить
Автор: Cyberax
Дата: 20.03.09
.

Пока я наблюдаю либо картинки, либо ссылки. Объяснений ровно ноль целых, ноль десятых.

C>>>Так это никак не влияет на умение пользоваться IDEA....

T>>Это ещё хуже, если вдуматься.
T>>Я не про коллег, если что.
C>Да я не спорю.
C>Просто недавно заметил — если писать на Питоне, то кода где-то раза в два меньше, чем на Java получается. Но только пишется он где-то раза в два медленнее.

О, да.

Питон — наше всё. Вершина языков программирования! Он недавно сместил оттуда Лисп, как ты уже, наверняка, знаешь.

Как я понимаю, ни Камлом, ни Хаскелем ты не пользуешься?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[30]: Каким отладчиком пользовались разработчики Kx System
От: . Великобритания  
Дата: 20.03.09 22:11
Оценка:
thesz wrote:

> Отличный пример. Он, как бы, говорит сам за себя. Совершенно не требует

> никаких объяснений.
>
> По нему сразу видно, как можно быстро и удобно сделать DSEL, отдать
> пользователю и он всё поймёт с полуслова.
А какой инструмент будет для этого DSL забирать из СУБД структуру данных, использовать описание маппинга (hbm, ещё один DSL), чтобы на лету проверить правильность имён и подсказать имена/свойств, кусочки комментов из javadoc?

Как этот DSL поможет при рефакторинге? Банально переименовать название поля и в бинах, и в маппингах и т.п.?

В общем-то IDEA этот DSL и позволяет прикрутить в любое место кода, только это у неё называется не DSL, а injected language.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[32]: Каким отладчиком пользовались разработчики Kx System
От: Cyberax Марс  
Дата: 21.03.09 00:37
Оценка:
Здравствуйте, thesz, Вы писали:

C>>Вот тут вот есть модуль для работы с RegExp'ами для IDEA: http://svn.jetbrains.org/idea/Trunk/bundled/RegExpSupport/

T>Ты обмолвился, что можешь подробно объяснить
Автор: Cyberax
Дата: 20.03.09
.

T>Пока я наблюдаю либо картинки, либо ссылки. Объяснений ровно ноль целых, ноль десятых.
Если кратко рассказывать — то IDEA предоставляет инфраструктуру для работы с синтаксическим деревом и его интеграцию со средствами IDE. Скажем, удобную поддержку автокомплита и рефакторинга. Это не совсем просто для использования в простых случаях (где макросы типа Немерля рулили бы).

Зато позволяет inect'ить в код практически ЛЮБОЙ язык. Например, в модуле поддержки GWT это используется для разбора JavaScript-кода внутри комментариев в Java-коде — http://www.jetbrains.com/idea/features/gwt.html Причём в этом JS-коде полностью работает автокомплит, поддержка JQuery с подвязками автокомплита к CSS, рефакторинг и т.д.

Я не думаю, что это было бы возможно в каком-либо DSLе. Даже в Haskell'е.

C>>Да я не спорю.

C>>Просто недавно заметил — если писать на Питоне, то кода где-то раза в два меньше, чем на Java получается. Но только пишется он где-то раза в два медленнее.
T>О, да.
T>Питон — наше всё. Вершина языков программирования! Он недавно сместил оттуда Лисп, как ты уже, наверняка, знаешь.
Я не считаю Питон вершиной языков. Но код таки на нём короче получается.

T>Как я понимаю, ни Камлом, ни Хаскелем ты не пользуешься?

Я писал на OCaml'е, Erlang'е и Scala. OCaml не прижился, так как у меня задач под него не было. Erlang я в production'е использовал, но потом отказался из-за тормознутости. Haskell я изучал, понял как работают монады , потом забросил.

Сейчас следующим языком, который я буду использовать после Питона и Java станет, скорее всего, Scala. Слишком избалован я нормальными IDE.
Sapienti sat!
Re[21]: Каким отладчиком пользовались разработчики Kx System
От: vdimas Россия  
Дата: 21.03.09 04:29
Оценка:
Здравствуйте, Belsen, Вы писали:

B>Или так?

B>
B>balinF'' :: Maybe i -> Maybe i -> Maybe i -> (Maybe i, Maybe (i, i))
B>balinF'' a b c = case (mapMaybe id [a,b,c]) of
B>    [x,y,z] -> (Just x, Just (y, z))
B>    [x,y] -> (Nothing, Just (x, y))
B>    [x] -> (Just x, Nothing)
B>    [] -> (Nothing, Nothing)
B>


Коллега, ты абсолютно прав, сначала я хотел представить именно эту версию алгоритма (на C#), но т.к. речь шла об эмуляторе железки, то остановился на дешифраторе.
Re[26]: Каким отладчиком пользовались разработчики Kx System
От: vdimas Россия  
Дата: 21.03.09 04:54
Оценка:
Здравствуйте, thesz, Вы писали:


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


Как это не может быть в принципе? Подобный "Решарпер" для Хаскеля помогал бы интиллисенсом для длинных идентификаторов, подсвечивал бы ошибки компиляции прямо в процессе редактирования кода, вставлял пропущенные варианты для паттерн-матчинга, отмечал бы неиспользуемые переменные в замыканиях, подсказывал бы, когда монада не имела побочного результата и можно было бы преобразовать просто в ф-ию (бывают иногда атавизмы в процессе работы над кодом), и т.д. и т.п.
Re[31]: Каким отладчиком пользовались разработчики Kx System
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 21.03.09 08:51
Оценка:
Здравствуйте, ., Вы писали:

.>А какой инструмент будет для этого DSL забирать из СУБД структуру данных, использовать описание маппинга (hbm, ещё один DSL), чтобы на лету проверить правильность имён и подсказать имена/свойств, кусочки комментов из javadoc?


Есть мнение, что это разные задачи и для них нужны разные инструменты.

Некоторые пользуют thunderbird, а некоторые fetchmail + procmail + mutt + pgp + mailcap + msmtp.

.>Как этот DSL поможет при рефакторинге? Банально переименовать название поля и в бинах, и в маппингах и т.п.?


Для этого нужен редактор с поддержкой рефакторинга. vim + HaRe, например.

Что касается "и в бинах, и в маппингах". Есть мнение, что надо одно из другого генерировать, а не синхронизировать.

.>В общем-то IDEA этот DSL и позволяет прикрутить в любое место кода, только это у неё называется не DSL, а injected language.


Мне кажется, что injected language написать сложнее, чем eDSL.
Re[27]: Каким отладчиком пользовались разработчики Kx System
От: thesz Россия http://thesz.livejournal.com
Дата: 21.03.09 11:51
Оценка:
T>>IDE pervasiveness мешает людям переходить на языки получше. Эта дурацкая привычка полагаться на IDE в выполнении "мелких задач, с которыми может справиться и компьютер", мешает понять, что этих задач может не быть в принципе.
V>Как это не может быть в принципе? Подобный "Решарпер" для Хаскеля помогал бы
V>интиллисенсом для длинных идентификаторов,

Плохая практика. Теорему Шеннона о длине кода никто не отменял.

V>подсвечивал бы ошибки компиляции прямо в процессе редактирования кода,


Отвлекая от написания кода.

V>вставлял пропущенные варианты для паттерн-матчинга,


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

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


Несмотря на то, что это разрешённая и часто используемая практика.

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


Из всех монад только ST и IO имеют побочные эффекты. Прикинь! Только 2 из всего их множества!

Ты бы пописал на Хаскеле, вместо фантазирования на эту тему.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[25]: Каким отладчиком пользовались разработчики Kx System
От: z00n  
Дата: 21.03.09 12:16
Оценка:
Здравствуйте, vdimas, Вы писали:

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

V>Для нашей задачи (3 бита дешифрации) достаточно сделать 2 сравнения для любой ветки алгоритма (C#):

V>А сколько сравнений сделает Хаскель для последнего варианта в первоначальном коде? 12? Так может, это не столько Хаскель тормозит, сколько программисты на нём?


Спасибо! Давно так не смеялся: тормозные програмисты на Haskell — херово оптимизируют матчинг.
Re[26]: Каким отладчиком пользовались разработчики Kx System
От: vdimas Россия  
Дата: 21.03.09 12:45
Оценка:
Здравствуйте, z00n, Вы писали:

Z>Спасибо! Давно так не смеялся: тормозные програмисты на Haskell — херово оптимизируют матчинг.


Сорри, если кого-то задел в "пылу боя", но ты бы сам взглянул на генерируемый бинарный код приведённого примера, для начала. Просто уже давно есть устойчивая неприязнь к продавцам серебрянных пуль, ибо мы всегда чем-то за что-то расплачиваемся.
Re[34]: Каким отладчиком пользовались разработчики Kx System
От: vdimas Россия  
Дата: 21.03.09 13:02
Оценка:
Здравствуйте, lomeo, Вы писали:


L>Я постепенно прихожу к выводу, что Scala возникла тоже из-за низкого уровня Java А это не та причина, по которой надо создавать новый язык, IMHO. А то получится Scala — монстр типа С++. Язык с набором несвязанных фич вместо языка с фичами, уложенными в некую систему. Хотя, вполне допускаю, что я пока просто эту систему не вижу.


Да, как-то пока сложно разглядеть идею Scala и причину его разработки как таковую, кроме причины отсутствия языковых альтернатив для Java — платформы.
Re[25]: Каким отладчиком пользовались разработчики Kx System
От: thesz Россия http://thesz.livejournal.com
Дата: 21.03.09 13:35
Оценка:
T>>>>Это не баг.
T>>>>Она не обрабатывается в оптимизирующем смысле этого слова, но она обрабатывается вообще, как одна из ситуаций.
V>>>Тю блин, ты же мне класс задач показал, не так ли? Пофиг, что в конкретно этом месте забытый матч не фатален, просто ошибки логики ЯП пока не научились ловить.
T>>Про теорию типов ты, конечно, слышал мало.
T>>Про классический пример, когда вывод типов ML показывает на зацикливание, ты тоже не видел.
V>Во-первых, с чего ты взял?

С чего я взял что? Что не видел?

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

V>Во-вторых, еще раз русским по белому: как это относится к реализации функциональных требований?


Ты великолепен!

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

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

Круто!

Совсем-совсем не применимо? Даже пытаться не стоит?

T>>Прикольно?

V>Что именно прикольно? Из твоих слов может показаться, что система типов даётся сверху, в то время как её разрабатывают те же люди, и точно так же допускают в ней косяки, навроде твоего esim.

Type theory should eat itself. Она может быть метациркулярна в более сильном, чем стандартные ЯП, смысле.

Все косяки в esimp, что ты увидел, существовали только в твоих глазах, дорогой товарищ.

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


Это очень важный момент. Точнее, это очень важное непонимание — то, что ты продемонстрировал параграфом выше.

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

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

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

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

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

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


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

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

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


О! "Плоское пространство имён".

import qualified Data.Map
import qualified Data.Map as Map
-- или import qualified Data.IntMap as Map

Ты, уж, ознакомься с критикуемым-то. Вся информация в интернете есть.

А то мне скоро наскучит мириться с твоим тиражированием идиотизма.

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


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

Например, Java и .Net до сих пор не имеют библиотеки моделирования систем на дискретных событиях.

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

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


Приведи пример.

Есть у меня подозрение, что функциональности там кот наплакал.

V>В принципе, это известные банальности, но ты их умудрился пропустить каким-то образом. Иначе трудно объяснить твоё полное непонимание относительно того, что спецификация языка и его реализация+инфраструктура — это две очень большие разницы. Вот обскачет по популярности твой долгосуществующий и неплохой Хаскель толькочторождённая поделка вроде Scala, может лучше понимать станешь. И ведь обскачет как стоячего, ибо "большие" программы на Scala будут куда как надёжнее и функциональнее, чем аналогичные на Хаскеле только лишь из-за работы языка поверх довольно мощной платформы.


Мне будет совершенно не жалко.

Потому, что в случае популярности Хаскеля им начнёшь пользоваться ты. А меня это беспокоит.

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

V>Блин, моя очередь спрашивать кому здесь сколько лет.
V>Если бы не торопился с ответом, а хотя бы в течении 10 сек пытался попроектировать предложенное дерево арифм. выражений на N-арных узлах, ты бы увидел, что операция "цепляется" к одному аргументу, а не к паре, и не предлагал бы очевидное.

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

Поэтому я вернулся к предложенному выше.

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

T>>Это ты уже о чём-то своём.
V>Хочешь сказать, что Хаскель оперирует целыми числами бесконечной разрядности? Результат деления двух целых какой тип имеет?

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

Например, только что ты предположил, что 10*A*12 нельзя упростить в 120*A. Это верно в случае, когда 10 и 12 с A могут иметь разные типы, например 10 :: Double, а 12, A :: Float.

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

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

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

V>Угу, поползновения увильнуть от прямого вопроса. Я привёл простой пример, который не оптимизирует твой подход, в то время как как компиляторы Java, C#, C++ прекрасно его оптимизируют. Может, ты чего-то не знаешь и пытаешься делать умное лицо?

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

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

V>Я так и понял, проехали. Если ФП не в состоянии "автоматом" исправлять ошибки логики, то это проблемы программиста, а не ЯП... ЧТД.

Оно может указывать на ошибки логики.

T>>(задумался над очевидным фактом незнания тобой алгебраических типов.)

V>Мде, офигенные у кое-кого манеры... Не пора ли кое-кому в сад? Говоря твоим же языком, еще много постов назад задумался над очевидным фактом незнания тобой теории групп и понятия размеченных объеденений, когда ты упирался насчёт алгебраических св-в семейств явным образом инстанциированных шаблонных типов в С++ или игнорировал замечание относительно реализаций dispatched unions.

Ты давай код приводи, да высказывайся по чётче, экскурсовод по саду ты наш.

V>Т.к. ты, очевидно, не понимаешь места, которое занимает реализация алгебраических типов Хаскеля в теории групп, то я тебе могу подсказать: алгебраические типы в реализации Хаскеля — суть размеченные объединения, селектор которых доступен в run-time, и модель селектора при этом выполнена в виде типа. Сделано это, очевидно, из-за принятой в Хаскеле "шаблонности" кода, что позволяет в минимальном синтаксисе выступать селектору в виде конструктора типа в процессе его параметризации.


Спасибо. Буду знать. А то не знал, что не знаю, теперь буду знать. Не думаю, что буду знать, что знаю, правда, но буду знать о своём незнании.

Самому-то не видно, что не знаешь.

Хоть читай Monin, Formal methods, хоть не читай. Всё равно, пока на RSDN участник коллективного разума не покажет, что ты этого не знаешь, так и не узнаешь о том, что ты этого не знаешь.

V>В общем, я же написал, что Хаскель не знаю, соотв. могу не знать подробности синтаксиса алгебраических типов в нём. Спросил конкретно про "Just", трудно было сказать, что это имя конструктора (по совместительству селектора) типа Maybe? Неужели не слышал про языки, в которых для алгебраических типов указывают конечные типы их вариантов? Или где селекторы выполнены в виде интегральных типов?


Ответ на предпоследний вопрос: да, знаю. Хаскель называется.
data Maybe a where
    Nothing :: Maybe a
    Just :: a -> Maybe a


Maybe в GADT стиле.

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

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

V>>>
V>>>data Maybe a = Nothing | a
V>>>


T>>Потому, что нельзя. Как мы отличим a, который Maybe a, от a, который, допустим, List a?

V>Не поэтому, а потому что в Хаскеле алгебраическую группу составляют взаимно уникальные типы. Собственно, т.к. он ничего кроме матчинга не умеет, то неудивительно, эта уникальность необходима для корректной работы. По-сути, значения алгебраических типов "заворачиваются в обёртку" дважды, сначала в тип селектора, а потом как все алгебраические типы. Вот это оборачивание в уникальный селектор и гарантирует необходимую логике паттерн-матчинга уникальность. Теперь тебе понятно, почему так нельзя?

Да, большое спасибо. Еще про одно своё незнание узнал.

"О, сколько нам открытий чудных!.."

V>Мне пришлось потратить вечер на изучение Хаскеля, чтобы объяснять тебе то, что ты должен был знать еще лет 10 назад.


Спасибо. Спасибо тебе, дорогой товарищ!

V>Кстати, посмотри на реализацию алгебраических типов в Немерле, там селектор представлен в виде типа-наследника от некоей базы, которая и образует группу, а совместимость типов группы достигается за счёт принятого в ООП-ориентированной платформе .Net неявного приведения наследника к базе (как и положено для ООП).


Спасибо!

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


Спасибо ещё раз.

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

V>Тем не менее, обещанное решение.

V>1. Раскроем "_" в первоначальном примере и Just/Nothing во всех местах:
V>
V>(newAcc,output) = case (oldAcc,input,loopback) of
V>            (Just acc, Just inp, Just lb) -> (Just acc, Just (inp, lb))
V>            (Just acc, Just inp, Nothing) -> (Nothing, Just (acc, inp))
V>            (Just acc, Nothing, Just lb) -> (Nothing, Just (acc, lb))
V>            (Just acc, Nothing, Nothing) -> (Just acc, Nothing)
V>            (Nothing acc, Just inp, Just lb) -> (Nothing, Just (inp, lb))
V>            (Nothing acc, Just inp, Nothing) -> (Just inp, Nothing)
V>            (Nothing acc, Nothing inp, Just lb) -> (Just lb, Nothing)
V>            (Nothing acc, Nothing inp, Nothing lb) -> (Nothing, Nothing)
V>


Слушай, вот эта картинка выдаёт уровень твоего внимания как нельзя лучше.

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

V>Для нашей задачи (3 бита дешифрации) достаточно сделать 2 сравнения для любой ветки алгоритма (C#):
V>
V>    using Pair = KeyValuePair<int, int>;

V>    struct  Ballin {
V>        public int? acc; 
V>        public Pair? pair;

V>        Ballin(int? a, Pair? p) { acc = a; pair = p; }

V>        public static Ballin Produce(int? acc, int? inp, int? lb) {
V>            if (!inp.HasValue) return TryPair(acc, lb);
V>            if (!lb.HasValue) return TryPair(acc, inp);
V>            return new Ballin(acc, new Pair(inp.Value, lb.Value));
V>        }

V>        private static Ballin TryPair(int? arg1, int? arg2) {
V>            if (!arg1.HasValue) return new Ballin(arg2, null);
V>            if (!arg2.HasValue) return new Ballin(arg1, null);
V>            return new Ballin(null, new Pair(arg1.Value, arg2.Value));
V>        }
V>    }
V>


V>А сколько сравнений сделает Хаскель для последнего варианта в первоначальном коде? 12?


Почему ты всегда предполагаешь самый плохой вариант и думаешь, что твой ответ будет верным? Это не самое выгодное поведение.

Сравнений будет три для любого варианта. Табличное сравнение с образцом разворачивается в дерево сравнений.

V>Так может, это не столько Хаскель тормозит, сколько программисты на нём? Мой вариант вполне переводим на Хаскель с сохранением 2-х сравнений для каждой ветки, и код сожмется практически до первоначального кол-ва строк, ввиду особенностей синтаксиса Хаскеля. И не надо опять начинать про "преждевременную оптимизацию", ибо мой алгоритм не просто быстрее, он несколько нагляднее, т.к. объясняет суть алгоритма: паруем первое попавшееся, остаток в аккумулятор.


Да её и не надо, этой оптимизации. Она компилятором выполняется.

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

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

Про неё, наверняка, есть статья в Википедии или где-то ещё?

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

V>>>Нет.
T>>Почему?
V>Потому что задачи разные бывают. Вот простая задача: кеш неких связанных данных, обслуживающий сетевые запросы, приходящие из разных потоков, требующий транзакционности выборок связанных данных. Уверен, что на Хаскеле это будут танцы с бубнами и куча лишних строк кода, по сравнению с mainstream-языками.

MVar

хгкд=http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent-Chan.html]Chan[/url]

Software Transactional Memory.

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

Ещё раз: предполагать самый плохо вариант ответа — не самая лучшая стратегия. Да и тактика тоже так себе.

V>Более того, на этой задаче ты начёнешь задевать крылом те конструкции, которые не задевал раньше, независимо от стиля кодирования.


Это всё слова. Это надо доказывать. Во-первых, тебе надо показать, как эта задача обязательно выведет за стиль кодирования решения на обычных языках. Во-вторых, тебе надо показать, как эта задача выведет за стиль кодирования решение на Хаскеле.

Потому, что разницы в применении стиля кодирования на любом ЯП нет.

Давай, потрать ещё вечер.

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

V>Если ничего не изменится, он не станет успешным никогда.

Ура! Спасибо тебе, дорогой товарищ!

V>10 с лишним лет Хаскель топчется на месте и перемен не предвидится — слишком уж консервативна среда вокруг него. Пока читал про систему типов Хиндли-Милнера наткнулся на куда более интересные вещи, например на Fortress, Boo. Эта система может запросто лечь на "не чисто" функциональные языки, и даже на презираемое некоторыми ООП. ИМХО, реализовать систему Хиндли-Милнера только над алгебраическими типами оказалось проще-всего (ибо всего одна разновидность полиморфизма, т.е. упрощается вывод типов), но сама эта система не требует никакой алгебраичности, она ортогональна ей. Не пошатнулись там еще твои "устои"?


Я не понял, о чём ты говоришь.

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


Почему State monad уродство? Твоё личное предпочтение?

Типобезопасность в ленивых ФЯ достигается проще всех остальных. Все остальные системы сложнее. BitC, например — авторы сами признают, что задача у них очень мощная и почти неподъёмная.

Всё, что может Фортресс, выражается в зависимых типах.

Собственно, почему я на них так и сфокусирован: разобравшись с ЗТД, я получаю забесплатно и Фортресс, и Boo и практически всё, что смогу захотеть.

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


Увы, практика доказывает обратное.

Алгоритм W (Хиндли-Милнера) сперва доказали для чистого подмножества ML, а потом отдельно доказывали для ML со ссылками.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[26]: Каким отладчиком пользовались разработчики Kx System
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 21.03.09 15:11
Оценка:
Здравствуйте, thesz, Вы писали:

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


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


T>Например, Java и .Net до сих пор не имеют библиотеки моделирования систем на дискретных событиях.


T>Мой опыт говорит, что количество написанного кода всегда в разы превышает количество кода с использованием библиотек. Да только на открытие файла требуется действий больше, чем просто fopen.


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

Вот в моем проекте, которым я занимаюсь последние несколько лет, порядка 100K строк прикладного кода. Самые большие из задействованных в нем библиотек -- ACE (330K строк), SObjectizer (50K), ObjESSty (60K). Не считая того кода, который спрятан в ODBC, реляционных БД, http-серверах.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[34]: Каким отладчиком пользовались разработчики Kx System
От: Cyberax Марс  
Дата: 21.03.09 18:27
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Мужики, вы о разном говорите. Да, Haskell тоже не помешают некоторые инструменты. Да, некоторые из финтифлюшек IDEA — костыли, следствие низкого уровня Java.

Да я не спорю. Java по уровню не сильно лучше какого-нибудь VisualBasic'а версии 6. Разве что синтаксис поприятнее.

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

C>>Я не думаю, что это было бы возможно в каком-либо DSLе. Даже в Haskell'е.

L>Ну как. Если хост-язык у нас один, то у нас уже есть его поддержка и не надо на каждый чих (dsel) писать новую.
Не получится.

Скажем, во многих случаях требуется работа с внешними ресурсами. Например, IDEA мне подсветит, если у меня в запросе есть неизвестная табличка (в схеме БД её нет), или если в JS в JQuery используется неизвестный CSS-класс.

C>>Сейчас следующим языком, который я буду использовать после Питона и Java станет, скорее всего, Scala. Слишком избалован я нормальными IDE.

L>Я постепенно прихожу к выводу, что Scala возникла тоже из-за низкого уровня Java
Да.

L>А это не та причина, по которой надо создавать новый язык, IMHO. А то получится Scala — монстр типа С++. Язык с набором несвязанных фич вместо языка с фичами, уложенными в некую систему. Хотя, вполне допускаю, что я пока просто эту систему не вижу.

Почему? JVM — это вполне нормальная среда для языков. Разве что систему типов нормально без erasure не сделать
Sapienti sat!
Re[27]: Каким отладчиком пользовались разработчики Kx System
От: thesz Россия http://thesz.livejournal.com
Дата: 21.03.09 19:16
Оценка:
T>>Мой опыт говорит, что количество написанного кода всегда в разы превышает количество кода с использованием библиотек. Да только на открытие файла требуется действий больше, чем просто fopen.

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


Ну, как тебе сказать.

Вот в игростроении, например. Делал всё, как все остальные: DirectX прямо в коде, без всякой обвязки. Так у меня на две тысячи строк кода взрывов было всего порядка пяти или шести вызовов D3D — DrawIndexPrimitive и установка параметров шейдеров. Да, я использовал уже написанный collision detection и выборку по миру. Так это был нами написанный код.

E>Вот в моем проекте, которым я занимаюсь последние несколько лет, порядка 100K строк прикладного кода. Самые большие из задействованных в нем библиотек -- ACE (330K строк), SObjectizer (50K), ObjESSty (60K). Не считая того кода, который спрятан в ODBC, реляционных БД, http-серверах.


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

Библиотеки — это те же самые языки программирования. Их возможности используются процентов на 10, хорошо если так много. Просто разным людям нужны разные возможности, вот и пестрота с объёмом наперевес.

Стиль кодирования защищает от слишком накладных возможностей языка. Обвязка вокруг библиотеки защищает от её полного знания и понимания. Да ещё даёт возможность более быстрого переноса.

И в заключении: деньги платят за решение проблем, которые никто ещё не решал. Не решённые проблемы не существуют в виде библиотек. Уже существующими библиотеками можно только облегчить свою судьбу, но не уйти от неё совсем.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[35]: Каким отладчиком пользовались разработчики Kx System
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 21.03.09 21:49
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Скажем, во многих случаях требуется работа с внешними ресурсами. Например, IDEA мне подсветит, если у меня в запросе есть неизвестная табличка (в схеме БД её нет), или если в JS в JQuery используется неизвестный CSS-класс.


Ну раз хост язык у нас один, то эти таблички и css (вернее их описания) у нас в языке же. Нет таблички или класса — программа не скомпилируется.
Re[36]: Каким отладчиком пользовались разработчики Kx System
От: Cyberax Марс  
Дата: 21.03.09 21:59
Оценка:
Здравствуйте, lomeo, Вы писали:

C>>Скажем, во многих случаях требуется работа с внешними ресурсами. Например, IDEA мне подсветит, если у меня в запросе есть неизвестная табличка (в схеме БД её нет), или если в JS в JQuery используется неизвестный CSS-класс.

L>Ну раз хост язык у нас один, то эти таблички и css (вернее их описания) у нас в языке же. Нет таблички или класса — программа не скомпилируется.
Т.е. мне нужно будет создать DSL для:
1) HTML
2) CSS
3) SQL (в разных диалектах)
4) JavaScript
5) Регэкспы (в том числе перловые)
6) .....

Причём нужно создать почти идеально совместимый по синтаксису DSL, так как в браузеры у нас пока Haskell не встроен. В общем, задача очень быстро станет наааааамного сложнее написания модуля для IDEA.
Sapienti sat!
Re[37]: Каким отладчиком пользовались разработчики Kx System
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 21.03.09 22:27
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Причём нужно создать почти идеально совместимый по синтаксису DSL, так как в браузеры у нас пока Haskell не встроен. В общем, задача очень быстро станет наааааамного сложнее написания модуля для IDEA.


Почему? Не понял, если честно. Писать injected language сложнее, чем DSeL, а т.к. кол-во первых должно быть равно кол-во второго, то непонятно откуда растёт сложность?

Во-вторых, я не призываю писать тебя dsl для css. Речь вообще не об этом. Началось с чего? Ты сказал, что то, что может injected language — не может eDSL. Я не понял почему (ведь для хоста-языка у нас уже всё есть) и переспросил.
Re[32]: Каким отладчиком пользовались разработчики Kx System
От: Cyberax Марс  
Дата: 22.03.09 02:18
Оценка:
Здравствуйте, dmz, Вы писали:

C>>Просто недавно заметил — если писать на Питоне, то кода где-то раза в два меньше, чем на Java получается. Но только пишется он где-то раза в два медленнее.

dmz>Это странно. При всех своих недостатках, питон все же выше уровнем чем жаб... джава раза эдак в четыре.
Чем выше? Ну есть у него list comprehensions и прочие вкусности. Из-за этого и получается код меньше.

Зато в Java у меня есть умный автокомплит и средства генерации кода, которые сглаживают разницу в объёме.
Sapienti sat!
Re[34]: Каким отладчиком пользовались разработчики Kx System
От: Cyberax Марс  
Дата: 22.03.09 03:59
Оценка:
Здравствуйте, dmz, Вы писали:

dmz>Я как-то не могу сходу сформулировать, но Java — это вообще низкоуровневый язык, примерно как C++, более того, если мне не изменяет память, местами C++ даже имеет какие-то полезные штуки, которых в Java не было. Так что быть уровнем выше Java — вообще не штука.

Ага.

dmz>Ну вот теже list comprehensions. lambda. Декораторы. Перегружаемые операторы. Доступ к собственному AST. Богатая стандартная библиотека. Вроде все мелочи, но вот так и набегает.

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

C>>Зато в Java у меня есть умный автокомплит и средства генерации кода, которые сглаживают разницу в объёме.

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

dmz>"Средства генерации кода" вроде должны, но если их есть и они такие удобные, зачем тогда умный автокомплит — написал немного кода, и он сгенерил тебе МНОГО кода. А когда кода мало, так что можно глазом охватить — то вроде как и умный автокомплит не нужен. В частности, зачем он тебе нужен для SQL, если этот SQL генерится из представления твоих данных и идеологии работы с ними

Там немного другое. В Java нельзя общим образом организовать hashCode/equals методы. Но в IDE я могу сделать их парой нажатий клавиш.

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

А ещё средства рефакторинга. Например, я люблю переменные переименовывать. В Питоне — это полный упс.

dmz>Опять же, о скорости набора. Нажал, подождал, выбрал из из списка. Который еще придется листать и смотреть. Это что, быстрее, чем просто написать ?

Ну вот видишь, ты автокомплитом в IDEA не пользовался.
Sapienti sat!
Re[26]: Каким отладчиком пользовались разработчики Kx System
От: vdimas Россия  
Дата: 22.03.09 05:26
Оценка:
Здравствуйте, thesz, Вы писали:


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


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

V>>Очень редкое нефункциональное требование, из области забавного. (да, ты приводил уже ссылку)

V>>Абсолютно не применимо, когда логика алгоритма зависит от входных данных — а это большинство сценариев в современных бизнес-приложениях.

T>Круто!

T>Совсем-совсем не применимо? Даже пытаться не стоит?

Придумай куда применить. У нас и констант-то не много в коде обычно, параметры алгоритмов зачастую через конфиги настраиваются в run-time. И не от хорошей жизни.


T>Все косяки в esimp, что ты увидел, существовали только в твоих глазах, дорогой товарищ.


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


T>Это очень важный момент. Точнее, это очень важное непонимание — то, что ты продемонстрировал параграфом выше.

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

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


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


Да-да, компилятор за нас всё напишет... Это я уже слышал, но ни разу еще не видел (хотя вплотную занялся исходниками Хаскеля — и там не вижу тоже).

А если это область обработки сигналов или ИИ, суть числомолотилка, умножение векторов и т.д? Оно что в ООП, что в твоём ФП даже записывается примерно одинаково. На обоих ЯП в алгоритмах можно наделать косяков, о которых компилятор и знать не будет — будет честно компилить подсунутые расчёты, которые туфтой и являются.

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

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


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


T>О! "Плоское пространство имён".


T>import qualified Data.Map

T>import qualified Data.Map as Map
T>-- или import qualified Data.IntMap as Map

Где ты увидел вопрос про "плоское пространство имён"? Похоже, ты не отличаешь "область видимости" от "уровня доступа/видимости".

T>Ты, уж, ознакомься с критикуемым-то. Вся информация в интернете есть.

T>А то мне скоро наскучит мириться с твоим тиражированием идиотизма.

Хамишь, парниша... Это помимо того, что опять бросаешься отвечать, не понимая сути вопроса. Даю еще одну попытку.


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


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


T>Например, Java и .Net до сих пор не имеют библиотеки моделирования систем на дискретных событиях.


Разных математических тонна, какой именно класс систем на дискретных событиях интересует?

И зря ты этот пример привёл, ой как зря. Помнишь спор о графическом представлении программной модели? Вот для как раз этой предметной области графическое представление — самое то. Если интересуешься системами на дискретных событиях, марковскими процессами и прочим, то сразу гоу ту симулинк и не занимайся онанизмом на текстовом ЯП.

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

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

Как на Хаскеле зациклить этот граф во втором случае?


T>Мой опыт говорит, что количество написанного кода всегда в разы превышает количество кода с использованием библиотек. Да только на открытие файла требуется действий больше, чем просто fopen.


Это смотря где больше:
using(Stream s = File.OpenStream(path))
  return EDIParser.Parse(s);


В любом случае, пример неудачный. Огромная часть бизнес задач сегодня — это распределённые системы, веб-морды, данные в СУБД (метаданные тоже), насраиваемое логгирование и т.д. и т.п., под небольшой прикладной логикой плавают целые айсберги тяжеловесного middleware.

T>Приведи пример.

T>Есть у меня подозрение, что функциональности там кот наплакал.

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

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



T>Потому, что в случае популярности Хаскеля им начнёшь пользоваться ты. А меня это беспокоит.


Что именно беспокоит? И почему тебя беспокоит, чем занимаются люди в тысячах километров от тебя?


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

T>Поэтому я вернулся к предложенному выше.

Странно, не помню "специальных" случаев для задачи оптимизации. Может, поделишься трудностями — подскажем как решить.

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


Очередной выпад типичного ФП-проповедника. Смысл как обычно: "все дураки".
Дык, у меня есть чудесный ответ: "сам дурак". Мы конкретный твой исходник обсуждаем, а не предполагаемые вербальные ограничения его использования. И ведь насколько мне позволяют судить мои познания в Хаскеле, в твой исходник можно подавать любые типы, для пары которых определена операция умножения "*". И уж тем более не понятно, почему ты явно не указал в контракте, что тип аргументов будет одинаков, раз того требует твой сценарий использования этого оптимизатора. А ведь этот косяк посильнее первого будет, не находишь? В общем, хреновый из тебя продавец ФП, будь ты в моей команде — был бы наруган за подобное разгильдяйство в контрактах. Так что, список мест, где тебе стоило бы взять свои слова обратно, неуклонно растёт.


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


Ну и какую?

T>Да в той задаче мне это просто не нужно было. И в той задаче отлично справился подход с алгебраическим представлением, вот и всё моё умное лицо.


Так это я неправильно мыслю об оптимизации вообще, или оно тебе в этом конкретном месте не очень надо было? У тебя с логикой вообще как?


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

V>>Я так и понял, проехали. Если ФП не в состоянии "автоматом" исправлять ошибки логики, то это проблемы программиста, а не ЯП... ЧТД.

T>Оно может указывать на ошибки логики.


Я знаю, на какие ошибки логики оно может указывать. И вывод типов не только в Хаскеле есть, если помнишь. И логика не только на if или паттерн матчингах строится, сами вычисления — это тоже часть логики. Ты же всё время пытаешься меня убедить, что мы тут в основном совершаем ошибки того плана, который обязательно найдёт компилятор. Это заблуждение. Подавляющее большинство ошибок по моему опыту — это или высокоуровневые, т.е. ошибки той логики, которая компилятору недоступна, и связана с некорректным пониманием требований или (что гораздо чаще) с неполной их реализацией. Или же те описки, которые пропускает система типов компилятора.
Вот суть одного моего косяка из недавнего:
public bool SomeProp {
  set {
    if(value
      DoSomething();

    _value = false; // должно быть _value = value;
  }
}


Причём, то-ли глаз замылился, то ли что... Но даже при просмотре кода я эту описку упускал дважды, не мог понять, что за фигня (было подозрение на ошибку синхронизации и перезапись из другого потока). Типизация в порядке — компилятор себе компилит. Чистое ФП не предлагать, я бы и на Хаскеле тут State сделал бы, это один из атрибутов состояния активного соединения.

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


T>Спасибо. Буду знать. А то не знал, что не знаю, теперь буду знать. Не думаю, что буду знать, что знаю, правда, но буду знать о своём незнании.

T>Самому-то не видно, что не знаешь.

Наплюй, просто в твоей манере решил абзац написать. Как оно смотрится со стороны, когда банальности за откровения выдаются, теперь представляешь.

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

V>>>>
V>>>>data Maybe a = Nothing | a
V>>>>


...
T>Да, большое спасибо. Еще про одно своё незнание узнал.

Дык, на вопрос лучше не отвечать вообще, чем отвечать так, как ты там ответил.
Раз не смог объяснить, значит сам не знаешь. Как тебе такая логика?

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


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


T>Слушай, вот эта картинка выдаёт уровень твоего внимания как нельзя лучше.


Да, надо заканчивать в 6 утра постить. Сделал правильно, кол-во сравнений у себя посчитал неправильно.


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

V>>>>Нет.
T>>>Почему?
V>>Потому что задачи разные бывают. Вот простая задача: кеш неких связанных данных, обслуживающий сетевые запросы, приходящие из разных потоков, требующий транзакционности выборок связанных данных. Уверен, что на Хаскеле это будут танцы с бубнами и куча лишних строк кода, по сравнению с mainstream-языками.

T>MVar

T>хгкд=http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent-Chan.html]Chan[/url]
T>Software Transactional Memory.

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

T>Ещё раз: предполагать самый плохо вариант ответа — не самая лучшая стратегия. Да и тактика тоже так себе.

Ладно, много раз порывался забросить этот театр абсурда, ибо кое-кто нить рассуждения постоянно теряет... Но мне пока кое-что надо увидеть (надеюсь этот бонус всё-таки будет). В общем, конкретно здесь речь шла о том (просто напоминаю), что я предположил, что на некоторых задачах ты всё-равно будешь использовать больше, чем упомянутые 10% возможностей. Я понимаю, что эти модули по приведённым тобой ссылкам сделал не ты лично, но зато ты имеешь возможность взглянуть в их исходники, сравнить кол-во использованных возможностей языка со своим "стилем кодирования" и, теперь восстановив нить обсуждения, сказать — удачный ли был мой пример в плане демонстрации того, что не только стиль кодирования определяет набор используемых языковых ср-в для решения задач, но иногда выход за эти 10% обуславливается характером самих задач.


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


T>Почему State monad уродство? Твоё личное предпочтение?


Обычное lvalue.

T>Типобезопасность в ленивых ФЯ достигается проще всех остальных. Все остальные системы сложнее. BitC, например — авторы сами признают, что задача у них очень мощная и почти неподъёмная.


Наверно ты хотел сказать — вывод типов в ленивых ФЯ достигается проще всех остальных. Однако, ты же можешь и явно типы специфицировать, начиная от примитивных, типа int (или как они там в Хаскель называются). И тогда ленивость/нелинивость будут до фени.

T>Всё, что может Фортресс, выражается в зависимых типах.


Хороший аргумент.
Это из разряда "всё, что могут делегаты C# выражается в библиотечном виде на С++".

T>Собственно, почему я на них так и сфокусирован: разобравшись с ЗТД, я получаю забесплатно и Фортресс, и Boo и практически всё, что смогу захотеть.


Это было бы так, если бы не странные ограничения name conventions (сдаётся мне, что это еще один из минусов для целей популяризации). C# и то отличает тип от ф-ии, не обладая такой системой вывода типов.

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


T>Увы, практика доказывает обратное.

T>Алгоритм W (Хиндли-Милнера) сперва доказали для чистого подмножества ML, а потом отдельно доказывали для ML со ссылками.

Насколько я понял, еще в конце 80-х все эти вещи произошли.
Re[36]: Каким отладчиком пользовались разработчики Kx System
От: dmz Россия  
Дата: 22.03.09 05:32
Оценка:
dmz>А подход с хоткеями — это такой DSL, выход которого потом надо ковырять и поддерживать. Т.е. вся эта мегадопечатка повышает уровень языка только в смысле одноразового написания кода, но сам-то код потом надо тестировать, поддерживать и т.п. При этом, если мы написали мало кода (функцию высшего порядка) — то она всегда работает тем образом, которым она определена и поддерживать нам надо только ее. А вот код, который нагенерился нашими хоткеями, требует индивидуального подхода — т.е. если у нас сгенерился кусок кода A, про который мы знаем, что он работает правильно, то про сгенеренный похожим (но не идентичным! идентичным он быть не может) образом кусок кода B — мы ничего сказать не можем. Короче говоря, это все раздувает код. Больше кода — больше ошибок. Ну ее нахрен, такую "высокоуровневость".


И еще — если мы написали функцию высшего порядка, или код на DSL — то когда нам надо что-то поменять в поведении — мы можем поменять только в одном месте — в определении функции или в кодогенераторе DSL.

Если же код нагенерился из языка жестов, и нам надо поменять поведение нагенеренного кода — то мы делаем что?
Re[36]: Каким отладчиком пользовались разработчики Kx System
От: Cyberax Марс  
Дата: 22.03.09 05:36
Оценка:
Здравствуйте, dmz, Вы писали:

C>>Ну вот видишь, ты автокомплитом в IDEA не пользовался.

dmz>Вы все такие загадочные... Хоть расскажите словами (и примерами), про зияющие высоты, которых мы не замечаем. Может придется забить на все и перелезть на Java.
Например, пишу:
for(Unit un : units.<shift_space>
//Tyт оно мне СРАЗУ мгновенно напишет, если нет ambiguity
for(Unit un : units.getUnits())


dmz>Да в общем, немного пользовался. Давно. Я помню, оно там по фрагменту зуба (кусок названия типа переменной что ле) генерило все животное целиком:

dmz>
dmz>MyCool<хоткей> - втыкаем в меню - еще пара нажатий на клавиши ->
dmz>MyCoolType myCoolType = new MyCoolType(...)
dmz>

Да, так тоже умеем.

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

Она ОЧЕНЬ легковесная. Многие действия я просто уже "вслепую" делаю.

НО!

Не ВСЕ действия можно выполнить вслепую, иногда надо делать выбор. Скажем, если я пишу:
Map<AA,BB> something=new <shift_space>

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

Для С++ такое нормально не сделать, кстати. Так как даже XRefactory не может разибирать некоторые программы.
Sapienti sat!
Re[37]: Каким отладчиком пользовались разработчики Kx System
От: dmz Россия  
Дата: 22.03.09 05:47
Оценка:
C>for(Unit un : units.<shift_space>
C>//Tyт оно мне СРАЗУ мгновенно напишет, если нет ambiguity
C>for(Unit un : units.getUnits())
C>[/java]

По моему — мизер. По моему, если ты помнишь, что у тебя есть Unit и units — то о существовании getUnits не забудешь точно.
А уж если есть та самая ambigity... А уж явное декларирование Unit un...

А уж если мы нагенерили пиццот таких блоков, а потом выяснили, что надо делать, то, что мы в них делаем, немного по-другому...
Re[38]: Каким отладчиком пользовались разработчики Kx System
От: Cyberax Марс  
Дата: 22.03.09 06:03
Оценка:
Здравствуйте, dmz, Вы писали:

dmz>По моему — мизер. По моему, если ты помнишь, что у тебя есть Unit и units — то о существовании getUnits не забудешь точно.

dmz>А уж если есть та самая ambigity... А уж явное декларирование Unit un...
Ты не понимаешь, мне эти самые getUnits() писать не надо. Оно мгновенно само подставляется.

Таких мелочей в IDEA просто очень много.

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

И чем поможет DSL, когда выяснится, что мы его неправильно изначально спроектировали?
Sapienti sat!
Re[39]: Каким отладчиком пользовались разработчики Kx System
От: dmz Россия  
Дата: 22.03.09 06:12
Оценка:
dmz>>По моему — мизер. По моему, если ты помнишь, что у тебя есть Unit и units — то о существовании getUnits не забудешь точно.
dmz>>А уж если есть та самая ambigity... А уж явное декларирование Unit un...

C>Ты не понимаешь, мне эти самые getUnits() писать не надо. Оно мгновенно само подставляется.


Что бы оно "мгновенно само подставилось", ты уже написал Units un. А если у тебя больше одной функции,
которая возвращает что-то типа Units, то пропадает "само" и "мгновенно".

Да и мне как-то почти по барабану, нажать shift-space, или написать getUnits.

C>Таких мелочей в IDEA просто очень много.


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

C>И чем поможет DSL, когда выяснится, что мы его неправильно изначально спроектировали?

Когда мало кода и он в одном месте — это лучше чем много кода и он в разных местах? Или не лучше? Или одинаково?
Так вот обобщить часто используемый паттерн в ФВП или DSL — приводит к "мало кода в одном месте".

А генерация кода — приводит к "много подобного кода в разных местах"
Re[40]: Каким отладчиком пользовались разработчики Kx System
От: Cyberax Марс  
Дата: 22.03.09 06:26
Оценка:
Здравствуйте, dmz, Вы писали:

C>>Ты не понимаешь, мне эти самые getUnits() писать не надо. Оно мгновенно само подставляется.

dmz>Что бы оно "мгновенно само подставилось", ты уже написал Units un. А если у тебя больше одной функции,
dmz>которая возвращает что-то типа Units, то пропадает "само" и "мгновенно".
Ну тогда надо просто тыкнуть на нужный элемент в списке. Два-три нажатия клавиш.

dmz>Да и мне как-то почти по барабану, нажать shift-space, или написать getUnits.

Нет. Если там есть getSomeSpecialUnits() — то можно и имя забыть, и писать дольше будет.

C>>И чем поможет DSL, когда выяснится, что мы его неправильно изначально спроектировали?

dmz>Когда мало кода и он в одном месте — это лучше чем много кода и он в разных местах? Или не лучше? Или одинаково?
dmz>Так вот обобщить часто используемый паттерн в ФВП или DSL — приводит к "мало кода в одном месте".
dmz>А генерация кода — приводит к "много подобного кода в разных местах"
Ну приводит. Что дальше? Я не говорил, что макросы — совсем не нужны.
Sapienti sat!
Re[41]: Каким отладчиком пользовались разработчики Kx System
От: dmz Россия  
Дата: 22.03.09 06:31
Оценка:
dmz>>Да и мне как-то почти по барабану, нажать shift-space, или написать getUnits.
C>Нет. Если там есть getSomeSpecialUnits() — то можно и имя забыть, и писать дольше будет.

На случай подобной забывчивости всегда есть тупая допечатка

dmz>>А генерация кода — приводит к "много подобного кода в разных местах"

C>Ну приводит. Что дальше? Я не говорил, что макросы — совсем не нужны.

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

Я это к тому, что как ни крути, джава — низкоуровневый язык. И при помощи IDE это никак не исправить.
Re[42]: Каким отладчиком пользовались разработчики Kx System
От: Cyberax Марс  
Дата: 22.03.09 06:46
Оценка:
Здравствуйте, dmz, Вы писали:

dmz>>>Да и мне как-то почти по барабану, нажать shift-space, или написать getUnits.

C>>Нет. Если там есть getSomeSpecialUnits() — то можно и имя забыть, и писать дольше будет.
dmz>На случай подобной забывчивости всегда есть тупая допечатка
То есть? В том же Питоне IDE не справляются даже с банальнейшими случаями. Так как вывода типов-то нет.

dmz>>>А генерация кода — приводит к "много подобного кода в разных местах"

C>>Ну приводит. Что дальше? Я не говорил, что макросы — совсем не нужны.
dmz>Ну так в джаве их нет, макросов. А наличие мега-допечатки провоцирует писать тонны кода, потому что это просто и быстро, вместо того, что бы попытаться его обобщить.
А я утверждаю, что Java — это идеал?

Я просто говорю, что DSELи — это может быть далеко не единственный способ реализации DSLей. И возможно даже, что не самый удачный.
Sapienti sat!
Re[39]: Каким отладчиком пользовались разработчики Kx System
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 22.03.09 08:06
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>>>Причём нужно создать почти идеально совместимый по синтаксису DSL, так как в браузеры у нас пока Haskell не встроен. В общем, задача очень быстро станет наааааамного сложнее написания модуля для IDEA.

L>>Почему? Не понял, если честно.
C>Не, ну тебе нужно будет повторить весь HTML, CSS и JS в виде DSL.

HTML, CSS и, тем более JS не очень хороший пример, ну да бог с ним.

В общем весь повторять не надо — только то, что нужно. Мы можем определить явный комбинатор html, который будет принимать применения комбинаторов head и body, а можем определить генератор комбинаторов и писать tag "ul", например.

C>Смысл в том, что для Injected-языка я могу использовать ЛЮБОЙ парсер, в том числе и интеллектуальный, пропускающий плохие куски, могу использовать ЛЮБОЕ промежуточное представление и т.д.


А для eDSL вообще парсеры не нужны.

C>Ну и вопросы с рефакторингом остаются.


Или рефаторинги хост языка. Или дописываем _отдельно_.

L>>Я не понял почему (ведь для хоста-языка у нас уже всё есть) и переспросил.

C>Не верно. Для хост-языка может быть есть парсеры, но это O-малое для качественного DSL.

Не, я не про парсеры, а про среду. Ведь мы когда создаём модуль для injected language, наверное, не только язык описываем, но и к среде его привязываем? В случае с eDSL у нас уже есть готовая среда. Правда, в случае с injected language сообщения будут более осмысленными, а рефакторинги более специфическими, но и писать, наверное, больше. С другой стороны, писать можно на родном языке, а не на хост. Тут тоже есть и плюсы и минусы.

В общем, мне кажется, у меня в голове уже всё сложилось Injected languages -- это опять такой подход "всё в одном", у него есть свои плюсы, конечно. Но тут дело в предпочтениях, наверное. Мне, например, комбайны мало нравятся.

Спасибо.
Re[29]: Каким отладчиком пользовались разработчики Kx System
От: thesz Россия http://thesz.livejournal.com
Дата: 22.03.09 09:15
Оценка:
T>>Вот в игростроении, например. Делал всё, как все остальные: DirectX прямо в коде, без всякой обвязки. Так у меня на две тысячи строк кода взрывов было всего порядка пяти или шести вызовов D3D — DrawIndexPrimitive и установка параметров шейдеров. Да, я использовал уже написанный collision detection и выборку по миру. Так это был нами написанный код.
E>Собственно, об этом и речь, что предметная область довольно специфическая. Как в свое время АСУТП была -- народ писал сам все, начиная от драйверов устройств и заканчивая рисованием исторических трендов. Затем, постепенно, развились SCADA системы и некоторые классы информационно-измерительных систем стали решаться на раз, с помощью только визуального программирования.
E>В той же игровой индустрии для ПК инструменты типа OpenGL, DirectX или SDL так же не сразу появились, но постепенно подобные библиотеки берут на себя изрядную часть забот разработчика.

Хаха три раза, ага.

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

E>С++ используем.

Ещё хуже, поскольку язык обширней.

T>>Библиотеки — это те же самые языки программирования. Их возможности используются процентов на 10, хорошо если так много. Просто разным людям нужны разные возможности, вот и пестрота с объёмом наперевес.

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

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

T>>И в заключении: деньги платят за решение проблем, которые никто ещё не решал. Не решённые проблемы не существуют в виде библиотек. Уже существующими библиотеками можно только облегчить свою судьбу, но не уйти от неё совсем.

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

Выделенное жирным — заблуждение. Заблуждение, что я об этом говорил.

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

Вот и тонны кода.

E>Зато потом начинается соревнование производителей за более выгодную для пользователей реализацию идеи. Достаточно вспомнить, что MS DOS не был чем-то новым, MS Windows не был чем-то новым. Все это уже решалось и достаточно хорошо. Зато эти продукты стали хорошими адаптациями уже известных идей для конкретных условий.


Хорошо пристроенными и хорошо раскрученными адаптациями, а не просто хорошими адаптациями.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[30]: Каким отладчиком пользовались разработчики Kx System
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 22.03.09 11:15
Оценка:
Здравствуйте, thesz, Вы писали:

E>>В той же игровой индустрии для ПК инструменты типа OpenGL, DirectX или SDL так же не сразу появились, но постепенно подобные библиотеки берут на себя изрядную часть забот разработчика.


T>Хаха три раза, ага.


Ну похоже, я жуву в параллельной вселенной. В которой когда-то были игры под MS DOS, для которых параметры звука пользователям нужно было выставлять вручную. И в которой некоторые игры не могли работать, если звуковая карта была не совместима с Sound Blaster. Наверное, тогда разработчикам игр не приходилось самим писать код для работы со звуковухой. И что появление вещей, типа DirectSound и SDL ну нисколько не облегчило жизнь разработчикам игр, ну совсем

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


Это всего лишь значит, что для многих библиотек это очень тяжело сделать физически. Т.к. не все разработчики библиотек заботятся о модульной огранизации, чтобы можно было выделить только то, что необходимо, а все остальное выкинуть. Так что применительно к ACE я просто не могу сказать, какой процент кода в нем занимают такие вещи, как ACE_Thread_Mutex, ACE_SOCK_Acceptor, ACE_SOCK_Connector, ACE_Reactor, ACE_Select_Reactor, ACE_TP_Reactor, ACE_Timer_Thread_Adapter и пр. Но, подозреваю, что эти вещи очень тесно связаны с еще большим куском кода из ACE, обеспечивающим кросс-платформенность.

Пример на эту же тему. Я попробовал вытянуть из Boost-а библиотеку для работы с hash-map-ами. Так она со всеми своими зависимостями потянула на 7Mb исходников (~4Kloc сам boost::unordered и ~193Kloc дополнительных зависимостей).

T>>>И в заключении: деньги платят за решение проблем, которые никто ещё не решал. Не решённые проблемы не существуют в виде библиотек. Уже существующими библиотеками можно только облегчить свою судьбу, но не уйти от неё совсем.

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

T>Выделенное жирным — заблуждение. Заблуждение, что я об этом говорил.


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[27]: Каким отладчиком пользовались разработчики Kx System
От: thesz Россия http://thesz.livejournal.com
Дата: 22.03.09 11:32
Оценка:
T>>Ну, возможно, видел. Но ведешь себя так, как будто не видел. В голове у тебя не отложилось, как это можно использовать.
V>И сколько раз за 10 лет твоего использования Хаскеля он помог тебе избежать зацикливания? Я вообще таких ошибок за всю свою жизнь помню меньше, чем пальцев на одной руке, среди огромного множества остальных.

Да, это редкая ошибка. Но она ловится.

T>>Круто!

T>>Совсем-совсем не применимо? Даже пытаться не стоит?
V>Придумай куда применить. У нас и констант-то не много в коде обычно, параметры алгоритмов зачастую через конфиги настраиваются в run-time. И не от хорошей жизни.

То есть, мы не можем выразить сложность алгоритма через эти самые параметры?

T>>Все косяки в esimp, что ты увидел, существовали только в твоих глазах, дорогой товарищ.

V>Сколько сахар не говори... Ты там неплохо про "тиражирование идиотизма сказал". Если есть входные данные, на которых алгоритм не работает, то это обычный косяк, и не надо заниматься мантрой "не критично, не критично".

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

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

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

T>>Разница между ЯП в этом случае будет составлять в скорости надёжного распространения новых знаний по системе.

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

О, да. Все вокруг либо дети, лиоб уже взрослые, все вокруг либо пишут полную туфту, либо сразу пишут всё, как надо.

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

V>Да-да, компилятор за нас всё напишет... Это я уже слышал, но ни разу еще не видел (хотя вплотную занялся исходниками Хаскеля — и там не вижу тоже).

Вот тут
Автор: thesz
Дата: 10.03.09


Цитирую самого себя:

Пример.

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

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

Достаточно стандартным приёмом является и конструирование языка для своих внутренних нужд. Даже если это просто некое внутреннее представление.

Внутреннее представление есть у всех. Степень типизации, правда, разная.

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

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

Это вынуждает этим пользоваться.

Это сокращает количество ошибок.

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


Прошу прощения за отсутствие новизны. Но вас, несторонников ЯП много, а нас, знающих про ЯП, пока мало.

V>А если это область обработки сигналов или ИИ, суть числомолотилка, умножение векторов и т.д? Оно что в ООП, что в твоём ФП даже записывается примерно одинаково. На обоих ЯП в алгоритмах можно наделать косяков, о которых компилятор и знать не будет — будет честно компилить подсунутые расчёты, которые туфтой и являются.


В ghc 6.10.1 появились data families и type families. data families позволяют безопасно преобразовывать данные. Мы можем гарантировать, что входные и выходные данные будут в boxed формате для обычного кода, а все промежуточные — в unboxed для скорости.

Это используется в реализации OpenCL и Data Parallel Haskell, как я понял из описаний Manuel Chakravarty.

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

Система типов Хаскеля представляет собой логику, называется она как-то в районе Fomega, или Fc, не помню.

Такую же логику пытался сделать для ООП Luca Cardelli. Это заняло у него больше 25 лет, насколько я помню.

За другие 25 лет система типов Хаскеля прошла путь от обычного алгоритма W Милнера до открытых функций над типами. Сейчас Хаскель способен типобезопасно выражать операции над векторами в стиле GPGPU, что ставит его на одну доску с C++, как минимум. А легкость, которой это достигается, позволяет передвинуть его вперёд C++.

А я по мелочи — размеры битовых векторов проверяю.

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


"Куда, как более гладко", как мы неоднократно выясняли на RSDN, означает "куда, как привычней мне лично".

Серьёзно. Ну вот откуда ты знаешь, что на ЯП получится хуже, чем на ООЯП? Ты делал сравнительные реализации?

А я могу похвастаться тем, что мы делали. ООЯП C++ с мощной библиотекой SystemC проиграл по практически по всем пунктам Хаскелю с одним файликом в двадцать строк кода. В пункты входили быстродействие программы, объём кода, сроки разработки и душевное здоровье членов коллектива.

V>В общем, ты очень много пишешь, но мало приводишь примеров. Из тех, что приводил — не для демонстрации основного твоего посыла "невозможно накосячить", из-за чего собственно и разгорелось у нас. Хотим хлеба и зрелищ. Покажи нам подтверждение своих слов.


Ты спрашивай, а не отвечай сам на свои вопросы самым худшим вариантом, что ты смог придумать.

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


T>>О! "Плоское пространство имён".


T>>import qualified Data.Map

T>>import qualified Data.Map as Map
T>>-- или import qualified Data.IntMap as Map

V>Где ты увидел вопрос про "плоское пространство имён"? Похоже, ты не отличаешь "область видимости" от "уровня доступа/видимости".


Так объясни.

T>>Ты, уж, ознакомься с критикуемым-то. Вся информация в интернете есть.

T>>А то мне скоро наскучит мириться с твоим тиражированием идиотизма.
V>Хамишь, парниша... Это помимо того, что опять бросаешься отвечать, не понимая сути вопроса. Даю еще одну попытку.

Давай-давай, объясняй.

А я посмотрю. по твоему объяснению, был ли я прав про "плоское пространство имён" и был ли прав ты про "не в состоянии обеспечить нормальной инакпсуляции".

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

T>>Например, Java и .Net до сих пор не имеют библиотеки моделирования систем на дискретных событиях.
V>Разных математических тонна, какой именно класс систем на дискретных событиях интересует?

Меня интересует моделирование VHDL. В Java 6 SE API этого нет, даже близко. То, что выпадает по поиску, не годится по причинам низкой производительности.

V>И зря ты этот пример привёл, ой как зря. Помнишь спор о графическом представлении программной модели? Вот для как раз этой предметной области графическое представление — самое то. Если интересуешься системами на дискретных событиях, марковскими процессами и прочим, то сразу гоу ту симулинк и не занимайся онанизмом на текстовом ЯП.


И ежегодно выкладывай мою годовую зарплату за это удовольствие.

Я уж лучше потрачу месяц и помучаюсь с ЯП.

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


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

V>Кстати, интересная мысль в голову пришла. Вот у нас есть некий направленный граф. Есть 2 распространённых способа моделирования направленного графа:

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

import Data.List

infixr 3 #

data G n = G [(n,[n])]

emptyG :: G n
emptyG = G []
extendG :: n -> [n] -> G n -> G n
extendG node nodes (G graph) = G $ (node,nodes):graph

(node,nodes) # graph = extendG node nodes graph

prettyG :: Show n => G n -> String
prettyG (G graph) = unlines $
    map (\(n,ns) -> show n++" -> "++show ns) graph

cyclic = (1,[2]) # (2,[1]) # emptyG


Вывод:
*Main> putStr $ prettyG cyclic
1 -> [2]
2 -> [1]

T>>Мой опыт говорит, что количество написанного кода всегда в разы превышает количество кода с использованием библиотек. Да только на открытие файла требуется действий больше, чем просто fopen.

V>Это смотря где больше:
V>
V>using(Stream s = File.OpenStream(path))
V>  return EDIParser.Parse(s);
V>


Ты path как-то собрал? Ты исключение как-то проверил?

V>В любом случае, пример неудачный. Огромная часть бизнес задач сегодня — это распределённые системы, веб-морды, данные в СУБД (метаданные тоже), насраиваемое логгирование и т.д. и т.п., под небольшой прикладной логикой плавают целые айсберги тяжеловесного middleware.


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

T>>Приведи пример.

T>>Есть у меня подозрение, что функциональности там кот наплакал.
V>У меня есть подозрения, что даже одну вшивую, но интерактивную страничку, работающую с различными платёжными системами, и использующую со стороны сервера сразу несколько защищённых протоколов передачи и протоколов аутентификации, на Хаскеле долго и нудно ручками долбить надо будет, в отличие от .Net или Java, где это всё 2 пальца об асфальт.

В крайнем случае, я сделаю интерфейс.

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


Ты это о чём?

T>>Потому, что в случае популярности Хаскеля им начнёшь пользоваться ты. А меня это беспокоит.

V>Что именно беспокоит? И почему тебя беспокоит, чем занимаются люди в тысячах километров от тебя?

Люди в тысяче километров от меня делали атомную бомбу. Мир очень маленький.

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

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

Самое простое: обратная группировка. ab+ac => a(b+c). Чтобы уменьшить количество умножений и делений. Да ещё надо учесть, что a, b и c не просто переменные, а сложные функции от бесконечных степенных рядов, могут быть и sin/cos, и экспонентой.

Мне на данном этапе хватило упорядоченного упрощения. Что-то типа:
esimp (Mul a b) = case orderPair (esimp a,esimp b) of
    (Const a,Mul (Const b) c) -> ...
    -- (Mul a b,Const c) быть не может, как не может быть (Const a, Mul b (Const c)).


Это был следующий вариант.

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

Я не перфекционист и перфекционистов сторонюсь. перфекционизм и перфекционисты мешают наслаждаться жизнью.

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

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

V>Очередной выпад типичного ФП-проповедника. Смысл как обычно: "все дураки".
V>Дык, у меня есть чудесный ответ: "сам дурак". Мы конкретный твой исходник обсуждаем, а не предполагаемые вербальные ограничения его использования. И ведь насколько мне позволяют судить мои познания в Хаскеле, в твой исходник можно подавать любые типы, для пары которых определена операция умножения "*". И уж тем более не понятно, почему ты явно не указал в контракте, что тип аргументов будет одинаков, раз того требует твой сценарий использования этого оптимизатора. А ведь этот косяк посильнее первого будет, не находишь? В общем, хреновый из тебя продавец ФП, будь ты в моей команде — был бы наруган за подобное разгильдяйство в контрактах. Так что, список мест, где тебе стоило бы взять свои слова обратно, неуклонно растёт.

Я не беру свои слова обратно. Не тру комментарии в ЖЖ, ни свои, ни чужие. Мне настолько же важен мой и чужой ум, насколько важна моя и чужая глупость.

Теперь к теме задачи. Операция умножения под кодовым названием Asterisk, она же *, она же Звёздочка, принимает на входе два аргумента одного типа и выдаёт результат того же типа. Это, прошу прощения, элементарная алгебра. Именно по алгебре и сделано определение Звёздочки в Хаскеле: (*) :: Num a => a -> a -> a

Тебя почти полностью оправдывает, что ты привык к разгильдяйству современных ЯП наподобие C++, где тип умножения может иметь никак не связанные параметры и результат, да ещё и производить побочные действия.

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

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

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

V>Ну и какую?

Новую.

У тебя, видимо, ещё не было опыта, когда ты неправильно что-то предполагал. Ты, видимо, никогда не ошибался в своих предположениях.

Ну, так поздравляю: ты не так давно что-то предположил и ошибся! Это новый, очень ценный опыт.

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

Да и вообще, думать наперёд лучше, чем думать опосля.

T>>Да в той задаче мне это просто не нужно было. И в той задаче отлично справился подход с алгебраическим представлением, вот и всё моё умное лицо.

V>Так это я неправильно мыслю об оптимизации вообще, или оно тебе в этом конкретном месте не очень надо было? У тебя с логикой вообще как?

Опыт gcc показывает, что ты неправильно мыслишь об оптимизации вообще. Это понятно?

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

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

V>>>Я так и понял, проехали. Если ФП не в состоянии "автоматом" исправлять ошибки логики, то это проблемы программиста, а не ЯП... ЧТД.
T>>Оно может указывать на ошибки логики.
V>Я знаю, на какие ошибки логики оно может указывать. И вывод типов не только в Хаскеле есть, если помнишь. И логика не только на if или паттерн матчингах строится, сами вычисления — это тоже часть логики. Ты же всё время пытаешься меня убедить, что мы тут в основном совершаем ошибки того плана, который обязательно найдёт компилятор. Это заблуждение. Подавляющее большинство ошибок по моему опыту — это или высокоуровневые, т.е. ошибки той логики, которая компилятору недоступна, и связана с некорректным пониманием требований или (что гораздо чаще) с неполной их реализацией. Или же те описки, которые пропускает система типов компилятора.
V>Вот суть одного моего косяка из недавнего:
V>
V>public bool SomeProp {
V>  set {
V>    if(value
V>      DoSomething();

V>    _value = false; // должно быть _value = value;
V>  }
V>}
V>


Оная someProp на Хаскеле содержала бы _value в качестве составной части результата. Ты бы смог её протестировать отдельно, на всех интересных входных данных.

Даже если бы это была монада State:
MyModule>let inputState = emptyInputState { value = True, _value = True }
MyModule>runState (someProp arg2 arg3) inputState
MyState { _value = False } -- а должно быть True!

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

Вот эта самая функциональная чистота, она же тоже ограничение. Как невозможность вкладывать строку и число. Это такая же часть системы типов, она заставляет тебя писать в определённом стиле, как и выполнение atol перед сложением.

И помогает ловить ошибки.

V>Причём, то-ли глаз замылился, то ли что... Но даже при просмотре кода я эту описку упускал дважды, не мог понять, что за фигня (было подозрение на ошибку синхронизации и перезапись из другого потока). Типизация в порядке — компилятор себе компилит. Чистое ФП не предлагать, я бы и на Хаскеле тут State сделал бы, это один из атрибутов состояния активного соединения.


"Настоящий программист способен написать фортрановскую программу на любом языке программирования."

State это та же чистая функция, вид в профиль.

V>Или взять твой пример BallinF, там ведь в правой части каждой строки матчинга можно допустить описку/ошибку логики, которая прекрасно скомпилится. И где тут будет помощь компилятора?


В Хаскеле — мало. Хотя я тут навострился применять семейства типов, кое-что полезное ловится.

В теории типов ты можешь задать (почти) произвольный инвариант в типе. Например, если должно быть сложение на (EBin Plus a b), то нельзя делать вычитания.

T>>Спасибо. Буду знать. А то не знал, что не знаю, теперь буду знать. Не думаю, что буду знать, что знаю, правда, но буду знать о своём незнании.

T>>Самому-то не видно, что не знаешь.
V>Наплюй, просто в твоей манере решил абзац написать. Как оно смотрится со стороны, когда банальности за откровения выдаются, теперь представляешь.

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

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

V>>>>>
V>>>>>data Maybe a = Nothing | a
V>>>>>


V>...

T>>Да, большое спасибо. Еще про одно своё незнание узнал.

V>Дык, на вопрос лучше не отвечать вообще, чем отвечать так, как ты там ответил.

V>Раз не смог объяснить, значит сам не знаешь. Как тебе такая логика?

Раз я не смог объяснить, значит, что я не смог объяснить. Всякие "сам не знаешь" это для выведения оппонента из себя. Вина может быть моей, вина может быть твоей.

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

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

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

Да. Теперь буду поступать именно так. Задали вопрос — отвечу. Задали непонятный вопрос — отвечу, что вопрос непонятен, и что если ты хотел спросить то-то и то-то, то ответы такие-то. Последнее по ситуации.

То есть, как я всегда и поступал.

T>>Слушай, вот эта картинка выдаёт уровень твоего внимания как нельзя лучше.

V>Да, надо заканчивать в 6 утра постить. Сделал правильно, кол-во сравнений у себя посчитал неправильно.

А вот на Хаскеле можно программировать с температурой или даже выпив литр пива. Всё равно работать будет.

Очень удобно.

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

V>>>>>Нет.
T>>>>Почему?
V>>>Потому что задачи разные бывают. Вот простая задача: кеш неких связанных данных, обслуживающий сетевые запросы, приходящие из разных потоков, требующий транзакционности выборок связанных данных. Уверен, что на Хаскеле это будут танцы с бубнами и куча лишних строк кода, по сравнению с mainstream-языками.

T>>MVar

T>>хгкд=http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent-Chan.html]Chan[/url]
T>>Software Transactional Memory.

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

T>>Ещё раз: предполагать самый плохо вариант ответа — не самая лучшая стратегия. Да и тактика тоже так себе.

V>Ладно, много раз порывался забросить этот театр абсурда, ибо кое-кто нить рассуждения постоянно теряет... Но мне пока кое-что надо увидеть (надеюсь этот бонус всё-таки будет). В общем, конкретно здесь речь шла о том (просто напоминаю), что я предположил, что на некоторых задачах ты всё-равно будешь использовать больше, чем упомянутые 10% возможностей. Я понимаю, что эти модули по приведённым тобой ссылкам сделал не ты лично, но зато ты имеешь возможность взглянуть в их исходники, сравнить кол-во использованных возможностей языка со своим "стилем кодирования" и, теперь восстановив нить обсуждения, сказать — удачный ли был мой пример в плане демонстрации того, что не только стиль кодирования определяет набор используемых языковых ср-в для решения задач, но иногда выход за эти 10% обуславливается характером самих задач.


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

STM пристально не интересовался. Потом посмотрю.

T>>Почему State monad уродство? Твоё личное предпочтение?

V>Обычное lvalue.

За исключением прозрачности по ссылкам. И скрытости. Так что это не обычное lvalue.

T>>Типобезопасность в ленивых ФЯ достигается проще всех остальных. Все остальные системы сложнее. BitC, например — авторы сами признают, что задача у них очень мощная и почти неподъёмная.

V>Наверно ты хотел сказать — вывод типов в ленивых ФЯ достигается проще всех остальных. Однако, ты же можешь и явно типы специфицировать, начиная от примитивных, типа int (или как они там в Хаскель называются). И тогда ленивость/нелинивость будут до фени.

Я сказал ровно то, что я хотел сказать. Это не то, что ты считаешь, что я, наверное, сказал.

T>>Всё, что может Фортресс, выражается в зависимых типах.

V>Хороший аргумент.
V>Это из разряда "всё, что могут делегаты C# выражается в библиотечном виде на С++".

Да. Только в C++ библиотеки плохо собираются вместе, а в теории типов будут собираться хорошо. Плюс, когда мне понадобится что-то очень похожее на Фортресс, но с запахом жасмина, то я смогу сделать это сам.

Как самостоятельно собирал циклы с многими точками входа на Хаскеле, вместо использования PL/1.

T>>Собственно, почему я на них так и сфокусирован: разобравшись с ЗТД, я получаю забесплатно и Фортресс, и Boo и практически всё, что смогу захотеть.

V>Это было бы так, если бы не странные ограничения name conventions (сдаётся мне, что это еще один из минусов для целей популяризации). C# и то отличает тип от ф-ии, не обладая такой системой вывода типов.

Похоже, ты вообще не утруждаешь себя размышлениями. Что будет означать (just nothing list) в сравнении с образцом? nothing — это конструктор, или переменная? Над Хаскелем изначально работали люди, которых приглашают специально поработать над C# или Java, чтобы решить очередные проблемы. Приглашают потому, что они overqualified для работы на полную ставку.

T>>Увы, практика доказывает обратное.

T>>Алгоритм W (Хиндли-Милнера) сперва доказали для чистого подмножества ML, а потом отдельно доказывали для ML со ссылками.
V>Насколько я понял, еще в конце 80-х все эти вещи произошли.

Алгоритм W — 1978. А со ссылками позже на несколько лет.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[31]: Каким отладчиком пользовались разработчики Kx System
От: thesz Россия http://thesz.livejournal.com
Дата: 22.03.09 11:42
Оценка:
E>>>В той же игровой индустрии для ПК инструменты типа OpenGL, DirectX или SDL так же не сразу появились, но постепенно подобные библиотеки берут на себя изрядную часть забот разработчика.
T>>Хаха три раза, ага.
E>Ну похоже, я жуву в параллельной вселенной. В которой когда-то были игры под MS DOS, для которых параметры звука пользователям нужно было выставлять вручную. И в которой некоторые игры не могли работать, если звуковая карта была не совместима с Sound Blaster. Наверное, тогда разработчикам игр не приходилось самим писать код для работы со звуковухой. И что появление вещей, типа DirectSound и SDL ну нисколько не облегчило жизнь разработчикам игр, ну совсем

А, вот ты о чём.

Сейчас объём кода самих игр не изменился. Логика чуть повыше, но и объёмы побольше. Процент вызова DX такой же, какой был процент IN/OUT под MS-DOS.

Это справедливо для всех известных мне игр и движков.

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

E>Это всего лишь значит, что для многих библиотек это очень тяжело сделать физически. Т.к. не все разработчики библиотек заботятся о модульной огранизации, чтобы можно было выделить только то, что необходимо, а все остальное выкинуть. Так что применительно к ACE я просто не могу сказать, какой процент кода в нем занимают такие вещи, как ACE_Thread_Mutex, ACE_SOCK_Acceptor, ACE_SOCK_Connector, ACE_Reactor, ACE_Select_Reactor, ACE_TP_Reactor, ACE_Timer_Thread_Adapter и пр. Но, подозреваю, что эти вещи очень тесно связаны с еще большим куском кода из ACE, обеспечивающим кросс-платформенность.
E>Пример на эту же тему. Я попробовал вытянуть из Boost-а библиотеку для работы с hash-map-ами. Так она со всеми своими зависимостями потянула на 7Mb исходников (~4Kloc сам boost::unordered и ~193Kloc дополнительных зависимостей).

boost::unordered — hash map, так?

То есть, ядро составляет 193KLOC, что, примерно, 5% от самого boost::unordered. Ядро ACE должно быть таким же, наверное.

Небольшим.

T>>>>И в заключении: деньги платят за решение проблем, которые никто ещё не решал. Не решённые проблемы не существуют в виде библиотек. Уже существующими библиотеками можно только облегчить свою судьбу, но не уйти от неё совсем.

E>>>Выделенное жирным -- заблуждение. Деньги очень хорошо платят и за решение конкретных задач конкретного заказчика. Поскольку при всем богатстве выбора обязательно находятся клиенты, которые хотят "точно такой же, но с перламутровыми пуговицами".
E>>>Реальные прорывы (вроде изобретения парового двигателя, дизеля, телефона, компьютерной мыши или графического оконного интерфейса) встречаются очень редко.
T>>Выделенное жирным — заблуждение. Заблуждение, что я об этом говорил.
E>Твоя фраза, имхо, воспринимается весьма однозначно: деньги платят за решения еще нерешенных никем проблем. Это очень сильное преувеличение, о чем я тебе и сказал. Если же ты пытался сказать о чем-то другом, то лично я этого не понял.

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

Значит, получается не решённая никем задача.

Это не означает, что будет прорыв в технологиях. Достаточно прорыва канализации, уже сложно получится.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[32]: Каким отладчиком пользовались разработчики Kx System
От: . Великобритания  
Дата: 22.03.09 14:02
Оценка:
lomeo wrote:

> .>А какой инструмент будет для этого DSL забирать из СУБД структуру

> данных, использовать описание маппинга (hbm, ещё один DSL), чтобы на
> лету проверить правильность имён и подсказать имена/свойств, кусочки
> комментов из javadoc?
> Есть мнение, что это разные задачи и для них нужны разные инструменты.
Так вот ИДЕЯ и является таким инструментом, для организации всего этого дела. Какие есть альтернативы? Ведь DSL к этому никакого отношения не имеет.

> .>Как этот DSL поможет при рефакторинге? Банально переименовать название

> поля и в бинах, и в маппингах и т.п.?
> Для этого нужен редактор с поддержкой рефакторинга. vim
А откуда этот редактор узнает, что в hbm.xml-файле такой-то тег, такой-то атрибут означает имя поля и там его тоже поменять?
Вот ИДЕЮ этому можно "обучать".

> Что касается "и в бинах, и в маппингах". Есть мнение, что надо одно из

> другого генерировать, а не синхронизировать.
Это невозможно. Маппинг содержит другую информацию, кроме названий/типов полей объекта. А значит он должен быть помещён отдельно от бина, ради декларативности и SRP.

> .>В общем-то IDEA этот DSL и позволяет прикрутить в любое место кода,

> только это у неё называется не DSL, а injected language.
> Мне кажется, что injected language написать сложнее, чем eDSL.
Injected lanugage это DSL, встроенный в IDE.
Скажем, у тебя есть
[html]
<img src="../images/img.gif" style="border:1px dotted #fea0e0" class="foo bar" onclick="clicked(1,2,3)">test</img>
[/html]
тут в одном языке, html, в одной из его синтаксических элементов (значении атрибута style) вставлен другой язык — css. При наведении мышой IDEA покажет квадратик закрашенный цветом #fea0e0, чтобы сразу понять как оно выглядит.
src содержит путь до файла, который должен существовать (при наведении мышой IDEA покажет в тултипе размер картинки и её thumbnail).
В атрибуте class встречается названия классов css, которое должно быть определено в неком другом файле .css.
А в onclick ещё один язык — js.

Соответственно, IDE тебе сможет найти где находится определение функции clicked, выведет определения css-классов foo и bar, покажет все места, где используются эти имена. Не забудет их переименовать везде где нужно, при переименовании. Будет правильно раскрашивать, подчёркивать синтаксические ошибки и покажет помощь (документацию) по функции clicked.

Или ты предлагаешь переписать все DSL в eDSL? Я сомневаюсь, что есть такой язык, куда одинаково просто и удобно можно будет заембеддить языки для regex, sql, css и html.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[31]: Каким отладчиком пользовались разработчики Kx System
От: FR  
Дата: 22.03.09 17:14
Оценка:
Здравствуйте, eao197, Вы писали:

E>Ну похоже, я жуву в параллельной вселенной. В которой когда-то были игры под MS DOS, для которых параметры звука пользователям нужно было выставлять вручную. И в которой некоторые игры не могли работать, если звуковая карта была не совместима с Sound Blaster. Наверное, тогда разработчикам игр не приходилось самим писать код для работы со звуковухой. И что появление вещей, типа DirectSound и SDL ну нисколько не облегчило жизнь разработчикам игр, ну совсем


Тут я подержу thesz'а в игроделе больше всего распрастранены два крайних варианта берется готовый движок и игра по сути скриптование под него, или наооборот чистейшее велосипедостроение. При велосипедном варианте для последних версий DX на самом деле можно сделать вполне вменяемый рендерер очень небольшого объема, то есть процент кода работющий непосредстаенно с DX очень мал.
Re[33]: Каким отладчиком пользовались разработчики Kx System
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 22.03.09 20:25
Оценка:
Здравствуйте, ., Вы писали:

>> Есть мнение, что это разные задачи и для них нужны разные инструменты.

.>Так вот ИДЕЯ и является таким инструментом, для организации всего этого дела. Какие есть альтернативы? Ведь DSL к этому никакого отношения не имеет.

IDEA — это комбайн :-)

.>А откуда этот редактор узнает, что в hbm.xml-файле такой-то тег, такой-то атрибут означает имя поля и там его тоже поменять?

.>Вот ИДЕЮ этому можно "обучать".

Если что-то по сути есть одна сущность и встречается в двух и более местах, то я стараюсь все "вторые места" генерировать.

>> Что касается "и в бинах, и в маппингах". Есть мнение, что надо одно из

>> другого генерировать, а не синхронизировать.
.>Это невозможно. Маппинг содержит другую информацию, кроме названий/типов полей объекта. А значит он должен быть помещён отдельно от бина, ради декларативности и SRP.

Можно пример, а то вот даже для бин/маппинг есть Hibernate Annotations.

.>Injected lanugage это DSL, встроенный в IDE.

.>Соответственно, IDE тебе сможет найти где находится определение функции clicked, выведет определения css-классов foo и bar, покажет все места, где используются эти имена. Не забудет их переименовать везде где нужно, при переименовании. Будет правильно раскрашивать, подчёркивать синтаксические ошибки и покажет помощь (документацию) по функции clicked.

Да, я понимаю это. И про IDEA регулярно читаю. Хочу прояснить свою позицию. Я не говорю — DSL — труъ, IDEA must die. Но лично мне IDEA скорее вредит, т.к. поощряет держать несколько зависимых источников, вместо генерации их. Подчёркиваю — это очень субъективное, допускаю, что программисту с более сильной внутренней организацией и дисциплиной IDEA может сильно помочь.

.>Или ты предлагаешь переписать все DSL в eDSL? Я сомневаюсь, что есть такой язык, куда одинаково просто и удобно можно будет заембеддить языки для regex, sql, css и html.


perl? :))

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

Подытожу:

1. IDEA поощряет написание boilerplate кода.
2. Мы должны полагаться на то, что будем пользоваться IDEA при разработке данного проекта, и что она всегда корректно синхронизирует наш код.
Re[34]: Каким отладчиком пользовались разработчики Kx System
От: Cyberax Марс  
Дата: 22.03.09 20:36
Оценка:
Здравствуйте, lomeo, Вы писали:

.>>Это невозможно. Маппинг содержит другую информацию, кроме названий/типов полей объекта. А значит он должен быть помещён отдельно от бина, ради декларативности и SRP.

L>Можно пример, а то вот даже для бин/маппинг есть Hibernate Annotations.
Например, скрипты создания индексов (зависят от БД), названия таблиц и специальные запросы. Нечего им в коде делать.

Чего ты тут будешь генерировать?
Sapienti sat!
Re[35]: Каким отладчиком пользовались разработчики Kx System
От: VladD2 Российская Империя www.nemerle.org
Дата: 22.03.09 20:53
Оценка:
Здравствуйте, Cyberax, Вы писали:

L>>Можно пример, а то вот даже для бин/маппинг есть Hibernate Annotations.

C>Например, скрипты создания индексов (зависят от БД), названия таблиц и специальные запросы. Нечего им в коде делать.

C>Чего ты тут будешь генерировать?


SQL?

Лично мне нравится идея когда БД описывается специальным ДСЛ-ем, а уже ее структура генерируется и изменяется с помощью универсального кода который читает это описание, сравнивает его с метаинформацией взятой из БД и модифицирует БД так чтобы она соответствовала исходному описанию.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[34]: Каким отладчиком пользовались разработчики Kx System
От: . Великобритания  
Дата: 22.03.09 20:56
Оценка:
lomeo wrote:

> .>А откуда этот редактор узнает, что в hbm.xml-файле такой-то тег,

> такой-то атрибут означает имя поля и там его тоже поменять?
> .>Вот ИДЕЮ этому можно "обучать".
> Если что-то по сути есть одна сущность и встречается в двух и более
> местах, то я стараюсь все "вторые места" генерировать.
Так объясняю же, нечего генерировать-то. Просто это разная информация, но связанная. Одна информация описывает структуру объекта (поля и их типы), а другая — как этот объект взаимодействует с субд.

> Можно пример, а то вот даже для бин/маппинг есть Hibernate Annotations.

Их полезность несколько спорная...

> Да, я понимаю это. И про IDEA регулярно читаю. Хочу прояснить свою

> позицию. Я не говорю — DSL — труъ, IDEA must die. Но лично мне IDEA
> скорее вредит, т.к. поощряет держать несколько зависимых источников,
> вместо генерации их. Подчёркиваю — это очень субъективное, допускаю, что
> программисту с более сильной внутренней организацией и дисциплиной IDEA
> может сильно помочь.
Генерации чего? Я просто не понимаю, что ты хочешь сказать. Нечего генерировать-то!

> perl?



> 1. IDEA поощряет написание boilerplate кода.

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

> 2. Мы должны полагаться на то, что будем пользоваться IDEA при

> разработке данного проекта, и что она всегда корректно синхронизирует
> наш код.
Ничего подобного. Если идеи нет или она что-то не умеет — меняешь файлы как нравится. Она ничего "своего" не создаёт, обыкновенные исходники. Файлы проектов идеи даже не обязательно класть в систему контроля версий.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[36]: Каким отладчиком пользовались разработчики Kx System
От: Cyberax Марс  
Дата: 22.03.09 21:05
Оценка:
Здравствуйте, VladD2, Вы писали:

C>>Чего ты тут будешь генерировать?

VD>SQL?
Это далеко не всегда возможно.

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

Это противоречит использованию легковесных mapper'ов, за которые тут не так давно были битвы Вариант, на самом деле, интересный. Я примерно сейчас его и использую — DSLем являются файлы mapping'а Hibernate.

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

Или мы, может быть, хотим одну модель данных использовать для нескольких mapping'ов. Тоже некрасиво получается.
Sapienti sat!
Re[35]: Каким отладчиком пользовались разработчики Kx System
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 22.03.09 21:06
Оценка:
Здравствуйте, Cyberax, Вы писали:

.>>>Это невозможно. Маппинг содержит другую информацию, кроме названий/типов полей объекта. А значит он должен быть помещён отдельно от бина, ради декларативности и SRP.

L>>Можно пример, а то вот даже для бин/маппинг есть Hibernate Annotations.
C>Например, скрипты создания индексов (зависят от БД), названия таблиц и специальные запросы. Нечего им в коде делать.
C>Чего ты тут будешь генерировать?

Упс, а я их генерировал. Даже специальные запросы, но они у меня не очень часто встречаются.
Re[36]: Каким отладчиком пользовались разработчики Kx System
От: Cyberax Марс  
Дата: 22.03.09 21:11
Оценка:
Здравствуйте, lomeo, Вы писали:

L>>>Можно пример, а то вот даже для бин/маппинг есть Hibernate Annotations.

C>>Например, скрипты создания индексов (зависят от БД), названия таблиц и специальные запросы. Нечего им в коде делать.
C>>Чего ты тут будешь генерировать?
L>Упс, а я их генерировал. Даже специальные запросы, но они у меня не очень часто встречаются.
Упс, а у меня их человек на fulltime'е пишет. Так как они не генерируются нифига.
Sapienti sat!
Re[35]: Каким отладчиком пользовались разработчики Kx System
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 22.03.09 21:12
Оценка:
Здравствуйте, ., Вы писали:

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


Ну, я генерировал. Плюс ещё и морду. Из одного места всё.

>> Можно пример, а то вот даже для бин/маппинг есть Hibernate Annotations.

.>Их полезность несколько спорная...

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

.>Генерации чего? Я просто не понимаю, что ты хочешь сказать. Нечего генерировать-то!


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

>> 1. IDEA поощряет написание boilerplate кода.

.>Не так уж он и страшен этот код. Писать такой код, конечно, может не столь красиво, но облегчение рефакторинга даёт серьёзное преимущество.

Да. Но для меня это минус. Вместо написания двадцати строк кода я пишу пицот.
Даже если эти пицот пишутся быстрее благодаря IDEA — для меня это недостаток.

>> 2. Мы должны полагаться на то, что будем пользоваться IDEA при

>> разработке данного проекта, и что она всегда корректно синхронизирует
>> наш код.
.>Ничего подобного. Если идеи нет или она что-то не умеет — меняешь файлы как нравится. Она ничего "своего" не создаёт, обыкновенные исходники. Файлы проектов идеи даже не обязательно класть в систему контроля версий.

Тогда мы теряем в синхронизации! Поменяешь ты без IDEA где нибудь название класса стиля и привет! В хтмл он не отобразится.
Re[36]: Каким отладчиком пользовались разработчики Kx System
От: Cyberax Марс  
Дата: 22.03.09 21:15
Оценка:
Здравствуйте, lomeo, Вы писали:

.>>Ничего подобного. Если идеи нет или она что-то не умеет — меняешь файлы как нравится. Она ничего "своего" не создаёт, обыкновенные исходники. Файлы проектов идеи даже не обязательно класть в систему контроля версий.

L>Тогда мы теряем в синхронизации! Поменяешь ты без IDEA где нибудь название класса стиля и привет! В хтмл он не отобразится.
Это можно поймать инспекциями в IDEA или на build-сервере.
Sapienti sat!
Re[37]: Каким отладчиком пользовались разработчики Kx System
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 22.03.09 21:21
Оценка:
Здравствуйте, Cyberax, Вы писали:

.>>>Ничего подобного. Если идеи нет или она что-то не умеет — меняешь файлы как нравится. Она ничего "своего" не создаёт, обыкновенные исходники. Файлы проектов идеи даже не обязательно класть в систему контроля версий.

L>>Тогда мы теряем в синхронизации! Поменяешь ты без IDEA где нибудь название класса стиля и привет! В хтмл он не отобразится.
C>Это можно поймать инспекциями в IDEA или на build-сервере.

Я там выделил, о чём мы говорим.
Re[38]: Каким отладчиком пользовались разработчики Kx System
От: Cyberax Марс  
Дата: 22.03.09 21:23
Оценка:
Здравствуйте, lomeo, Вы писали:

.>>>>Ничего подобного. Если идеи нет или она что-то не умеет — меняешь файлы как нравится. Она ничего "своего" не создаёт, обыкновенные исходники. Файлы проектов идеи даже не обязательно класть в систему контроля версий.

L>>>Тогда мы теряем в синхронизации! Поменяешь ты без IDEA где нибудь название класса стиля и привет! В хтмл он не отобразится.
C>>Это можно поймать инспекциями в IDEA или на build-сервере.
L>Я там выделил, о чём мы говорим.
Ну и? Если IDEA нет, то говорить об IDEA как-то особо смысла не имеет.

Я говорю про то, что IDEA прекрасно работает с внешними изменениями.
Sapienti sat!
Re[36]: Каким отладчиком пользовались разработчики Kx System
От: . Великобритания  
Дата: 22.03.09 21:29
Оценка:
lomeo wrote:

> .>Так объясняю же, нечего генерировать-то. Просто это разная информация,

> но связанная. Одна информация описывает структуру объекта (поля и их
> типы), а другая — как этот объект взаимодействует с субд.
> Ну, я генерировал. Плюс ещё и морду. Из одного места всё.
Может тебе повезло с задачей, что всё, от структуры БД до ГУИ можно сгенерировать по одному описанию.

> Это пример. В качестве инструмента для избавления от дублирования очень

> даже ничего.
Что плохо в аннотациях — в одном месте куча разных вещей.

> Может задачи разные? У меня постоянно находятся места, которые требует

> или копи-пасты с небольшой правкой, или выделения абстракции, или если
> окружение это не позволяет — генерации.
Да, наверно.

> Тогда мы теряем в синхронизации! Поменяешь ты без IDEA где нибудь

> название класса стиля и привет! В хтмл он не отобразится.
Не понял. Синхронизации чего с чем? Если ты что-то поменял вручную и перестало работать, то значит руки кривые. Спрашивается накой вручную было менять?

Кстати, можно будет запустить инспекции в ИДЕЕ и проверить, что всё "синхронизовано".
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[39]: Каким отладчиком пользовались разработчики Kx System
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 22.03.09 21:29
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Ну и? Если IDEA нет, то говорить об IDEA как-то особо смысла не имеет.


Ты отвечаешь на пункт о привязке к IDEA.

C>Я говорю про то, что IDEA прекрасно работает с внешними изменениями.


Согласен.
Re[37]: Каким отладчиком пользовались разработчики Kx System
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 22.03.09 21:36
Оценка:
Здравствуйте, ., Вы писали:

.>Может тебе повезло с задачей, что всё, от структуры БД до ГУИ можно сгенерировать по одному описанию.


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

.>Что плохо в аннотациях — в одном месте куча разных вещей.


Не спорю. Я говорил о том, что в них хорошего.

.>Не понял. Синхронизации чего с чем? Если ты что-то поменял вручную и перестало работать, то значит руки кривые. Спрашивается накой вручную было менять?


Значит, привязка к IDEA есть.

Я о чём вообще толкую — мне кажется, что если есть зависимости, то их можно отразить в коде, а можно в IDEA. Я предпочитаю код. Вот и всё. Спорить вроде как не о чем?
Re[37]: Каким отладчиком пользовались разработчики Kx System
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 22.03.09 21:37
Оценка:
Здравствуйте, ., Вы писали:

А вообще прикольно как мы от темы оторвались!
Re[38]: Каким отладчиком пользовались разработчики Kx System
От: . Великобритания  
Дата: 22.03.09 21:55
Оценка:
lomeo wrote:

> Значит, привязка к IDEA есть.

Что ты под привязкой понимаешь?

> Я о чём вообще толкую — мне кажется, что если есть зависимости, то их

> можно отразить в коде, а можно в IDEA. Я предпочитаю код. Вот и всё.
> Спорить вроде как не о чем?
Что значит отобразить зависимость в IDEA? IDEA это не яп, и уж тем более не dsl, это такой продвинутый текстовый редактор, который понимает семантику редактируемых файлов (и не только файлов) и распознаёт взаимосвязи между ними.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[38]: Каким отладчиком пользовались разработчики Kx System
От: . Великобритания  
Дата: 22.03.09 22:03
Оценка:
lomeo wrote:

> А вообще прикольно как мы от темы оторвались!

философия...
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[37]: Каким отладчиком пользовались разработчики Kx System
От: VladD2 Российская Империя www.nemerle.org
Дата: 22.03.09 22:06
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>>>Чего ты тут будешь генерировать?

VD>>SQL?
C>Это далеко не всегда возможно.

В каких? Использование DBF?

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

C>Это противоречит использованию легковесных mapper'ов, за которые тут не так давно были битвы

С чего бы это?
И вообще, откуда эти догмы?

C>Вариант, на самом деле, интересный. Я примерно сейчас его и использую — DSLем являются файлы mapping'а Hibernate.


Выражаю тебе свои соболезнования. Хуже ДСЛ чем недоязык основанный на ХМЛ-е придумать трудно.
Я бы предпочел более высокоуровеное описание.

C>Но дальше начинаются интересные вопросы — если мы используем код с аннотациями


Это не обязательно должно быть кодом на универсальном языке. Это может быть встроенным или внешним ДСЛ-ем являющимся высокоуровневым описанием требуемых сущностей.

C>в качестве единственного источника информации, то у нас в скомпилированном коде будет информация о таблицах и запросах хранится. А если мы хотим эту сборку отдать внешним клиентам? Тогда надо будет как-то вытащить информацию из неё.


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

C>Или мы, может быть, хотим одну модель данных использовать для нескольких mapping'ов. Тоже некрасиво получается.


А зафиг мне какие-то маперы? У нас есть метаописание, набор поддерживаемых СУБД и встроенный в сборку код который позволяет работать с поддерживаемыми СУБД. Вот последний — это есть высокоинтеллектуальное решени которое требует мощьных средств разработки. Но в их число я бы включил хороший язык с поддержкой метапрограммирования, а не внешний мапер и уж тем более не гибернэйт.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[38]: Каким отладчиком пользовались разработчики Kx System
От: Cyberax Марс  
Дата: 22.03.09 22:31
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>>>SQL?

C>>Это далеко не всегда возможно.
VD>В каких? Использование DBF?
В том числе. Или необходимость разных шаманств со схемой (типа назначения tablespace'ов и прочего тюнинга).

C>>Это противоречит использованию легковесных mapper'ов, за которые тут не так давно были битвы

VD>С чего бы это?
VD>И вообще, откуда эти догмы?
Так как нам надо будет

C>>Вариант, на самом деле, интересный. Я примерно сейчас его и использую — DSLем являются файлы mapping'а Hibernate.

VD>Выражаю тебе свои соболезнования. Хуже ДСЛ чем недоязык основанный на ХМЛ-е придумать трудно.
VD>Я бы предпочел более высокоуровеное описание.
XML — это просто (ну не самый удачный, да) способ записи дерева, которое может использоваться для чего угодно. К уровню описания он не имеет особого отношения.

C>>Но дальше начинаются интересные вопросы — если мы используем код с аннотациями

VD>Это не обязательно должно быть кодом на универсальном языке. Это может быть встроенным или внешним ДСЛ-ем являющимся высокоуровневым описанием требуемых сущностей.
Это всё понятно.

C>>в качестве единственного источника информации, то у нас в скомпилированном коде будет информация о таблицах и запросах хранится. А если мы хотим эту сборку отдать внешним клиентам? Тогда надо будет как-то вытащить информацию из неё.

VD>Задача сформулирована как-то мутно. Попробую ответить, но не уверен, что угадаю все недостказанное.
VD>Сборка умеет работать с конкретной структурой БД. В ней ведь код который рассчитан на обработку конкретных данных. Сборка сама модицицирует не подходящую БД или создаст новую... если что. Так что отдавай. Проблем не будет.
Нет, у меня другая проблема. Я описываю структуру базы в виде entity-классов:
class User
{
    public Set<Role> roles;
//...
}
class Role
{
    public Set<Role> users;
//...
}

Эти entity-классы идут в клиентскую библиотеку, которая распространяется заказчикам.

А на сервере используется mapping в отдельных файлах для её отображения на БД и XML:
<class name="User" table="system_user">
        <set name="roles" cascade="save-update">
            <cache usage="read-write"/>
            <key column="parent_user"/>
            <many-to-many class="Role" column="parent_role"/>
        </set>
</class>
<class name="Role" table="system_role">
        <set name="users" cascade="save-update">
            <cache usage="read-write"/>
            <key column="parent_role"/>
            <many-to-many class="User" column="parent_user"/>
        </set>
</class>

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

А ещё может быть отдельный mapping на XML или настройки для объектной БД. А ещё для отдельных БД может потребоваться дополнительные шаманства в mapping'е.

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

C>>Или мы, может быть, хотим одну модель данных использовать для нескольких mapping'ов. Тоже некрасиво получается.

VD>А зафиг мне какие-то маперы? У нас есть метаописание, набор поддерживаемых СУБД и встроенный в сборку код который позволяет работать с поддерживаемыми СУБД. Вот последний — это есть высокоинтеллектуальное решени которое требует мощьных средств разработки. Но в их число я бы включил хороший язык с поддержкой метапрограммирования, а не внешний мапер и уж тем более не гибернэйт.
Тем не менее, Hibernate + IDEA уже решают эту проблему более чем удовлетворительно.
Sapienti sat!
Re[28]: Каким отладчиком пользовались разработчики Kx System
От: vdimas Россия  
Дата: 22.03.09 22:35
Оценка:
Здравствуйте, lomeo, Вы писали:


L>Самое сильное — do-нотация


В ФП-языке самое сильное — это императивные блоки?

T>>>Почему State monad уродство? Твоё личное предпочтение?

V>>Обычное lvalue.

L>Потому что на императивном языке это примитивная операция?


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

L>О, это сделано для удобства. Не надо писать map :: forall a b. (a -> b) -> [a] -> [b], достаточно просто (a -> b) -> [a] -> [b] и то, что a,b — параметры типа, а не конкретные типы определится по регистру. Что касается конструкторов против функций — то верхний регистр — это что-то вроде new в С#: x = Foo 42 против x = foo 42.


Полноценно обсуждать эту тему не готов, но согласно ИМХО — экономия на спичках.
Re[39]: Каким отладчиком пользовались разработчики Kx System
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 22.03.09 23:09
Оценка:
Здравствуйте, ., Вы писали:

>> Значит, привязка к IDEA есть.

.>Что ты под привязкой понимаешь?

То, что теперь тебе придётся пользоваться IDEA.

>> Я о чём вообще толкую — мне кажется, что если есть зависимости, то их

>> можно отразить в коде, а можно в IDEA. Я предпочитаю код. Вот и всё.
>> Спорить вроде как не о чем?
.>Что значит отобразить зависимость в IDEA? IDEA это не яп, и уж тем более не dsl, это такой продвинутый текстовый редактор, который понимает семантику редактируемых файлов (и не только файлов) и распознаёт взаимосвязи между ними.

Отразить, а не отобразить. То, что имя класса css в атрибуте class и в css файле связаны.
Re[40]: Каким отладчиком пользовались разработчики Kx System
От: Cyberax Марс  
Дата: 22.03.09 23:23
Оценка:
Здравствуйте, lomeo, Вы писали:

.>>Что ты под привязкой понимаешь?

L>То, что теперь тебе придётся пользоваться IDEA.
Необязательно. Можешь пользоваться любой другой IDE, но тогда не будет IDEAвских фич.

.>>Что значит отобразить зависимость в IDEA? IDEA это не яп, и уж тем более не dsl, это такой продвинутый текстовый редактор, который понимает семантику редактируемых файлов (и не только файлов) и распознаёт взаимосвязи между ними.

L>Отразить, а не отобразить. То, что имя класса css в атрибуте class и в css файле связаны.
Как ты отразишь зависимости, если язык этого не позволяет?
Sapienti sat!
Re[6]: Каким отладчиком пользовались разработчики Kx Systems
От: cencio Украина http://ua-coder.blogspot.com
Дата: 22.03.09 23:30
Оценка:
Здравствуйте, kaa.python, Вы писали:

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


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

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

T>>Сколько людей, столько и мнений
Автор: eao197
Дата: 06.03.09
.


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


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


а к чему эти наезды на джавистов? у них есть log4j и распарсывать результат им приходится
Re[29]: Каким отладчиком пользовались разработчики Kx System
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 22.03.09 23:36
Оценка:
Здравствуйте, vdimas, Вы писали:

L>>Самое сильное — do-нотация :))

V>В ФП-языке самое сильное — это императивные блоки?

Это шутка?

L>>О, это сделано для удобства. Не надо писать map :: forall a b. (a -> b) -> [a] -> [b], достаточно просто (a -> b) -> [a] -> [b] и то, что a,b — параметры типа, а не конкретные типы определится по регистру. Что касается конструкторов против функций — то верхний регистр — это что-то вроде new в С#: x = Foo 42 против x = foo 42.


V>Полноценно обсуждать эту тему не готов, но согласно ИМХО — экономия на спичках.


Ну как же спички. Foo — такая же функция, только создаёт некое значение. Если мы будем писать new Foo, то это уже далеко не ФВП. Бритва Оккама и всё такое.
Re[41]: Каким отладчиком пользовались разработчики Kx System
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 22.03.09 23:37
Оценка:
Здравствуйте, Cyberax, Вы писали:

.>>>Что значит отобразить зависимость в IDEA? IDEA это не яп, и уж тем более не dsl, это такой продвинутый текстовый редактор, который понимает семантику редактируемых файлов (и не только файлов) и распознаёт взаимосвязи между ними.

L>>Отразить, а не отобразить. То, что имя класса css в атрибуте class и в css файле связаны.
C>Как ты отразишь зависимости, если язык этого не позволяет?

Генерацией с языка, который это позволяет.
Re[42]: Каким отладчиком пользовались разработчики Kx System
От: Cyberax Марс  
Дата: 22.03.09 23:54
Оценка:
Здравствуйте, lomeo, Вы писали:

L>>>Отразить, а не отобразить. То, что имя класса css в атрибуте class и в css файле связаны.

C>>Как ты отразишь зависимости, если язык этого не позволяет?
L>Генерацией с языка, который это позволяет.
Ага, и когда дизайнер поправит результирующий HTML или CSS, то что будешь делать?
Sapienti sat!
Re[43]: Каким отладчиком пользовались разработчики Kx System
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 23.03.09 00:14
Оценка:
Здравствуйте, Cyberax, Вы писали:

L>>Генерацией с языка, который это позволяет.

C>Ага, и когда дизайнер поправит результирующий HTML или CSS, то что будешь делать?

Зачем дизайнеру трогать результирующий HTML или CSS??
Re[44]: Каким отладчиком пользовались разработчики Kx System
От: . Великобритания  
Дата: 23.03.09 00:22
Оценка:
lomeo wrote:

> Зачем дизайнеру трогать *результирующий* HTML или CSS??

А что будет трогать дизайнер?
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[44]: Каким отладчиком пользовались разработчики Kx System
От: Cyberax Марс  
Дата: 23.03.09 01:00
Оценка:
Здравствуйте, lomeo, Вы писали:

L>>>Генерацией с языка, который это позволяет.

C>>Ага, и когда дизайнер поправит результирующий HTML или CSS, то что будешь делать?
L>Зачем дизайнеру трогать результирующий HTML или CSS??
Ну HTML — ладно. А вот CSS — точно будет редактировать напрямую. Ибо нафиг ему Haskell не сдался.
Sapienti sat!
Re[45]: Каким отладчиком пользовались разработчики Kx System
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 23.03.09 07:06
Оценка:
Здравствуйте, Cyberax, Вы писали:

L>>>>Генерацией с языка, который это позволяет.

C>>>Ага, и когда дизайнер поправит результирующий HTML или CSS, то что будешь делать?
L>>Зачем дизайнеру трогать результирующий HTML или CSS??
C>Ну HTML — ладно. А вот CSS — точно будет редактировать напрямую. Ибо нафиг ему Haskell не сдался.

Отвечу обоим. В общем, да согласен. Я CSS не генерил ещё, кажется :-) Но и названия классов чтобы менялись — не вспомню.
Но я предупреждал, что пример не очень удачный ;-)

На этом, пожалуй, закругляюсь, спасибо!
Re[32]: Каким отладчиком пользовались разработчики Kx System
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 24.03.09 13:43
Оценка:
Здравствуйте, thesz, Вы писали:

E>>Твоя фраза, имхо, воспринимается весьма однозначно: деньги платят за решения еще нерешенных никем проблем. Это очень сильное преувеличение, о чем я тебе и сказал. Если же ты пытался сказать о чем-то другом, то лично я этого не понял.


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


T>Значит, получается не решённая никем задача.


Вот хорошая заметка на эту тему: The Book Of JOSH (тебе она может быть еще интересна и враждебным отношением к Java ). Так во в ней описывается, как люди повторяют уже имеющуюся функциональность, но на другой "элементной базе".

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

Аналогично этому многие производители программ повторяют то, что уже делали когда-то другие, но чуть по своему. Посмотри, например, на реляционные СУБД, компиляторы C++, текстовые процессоры, http-сервера, видео/аудио-проигрыватели и пр. Это все ну никак не попадает под "не решенные никем задачи". И еще хорошо, если в конкретных продуктах есть действительно какие-то серьезные нововедения.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[16]: Каким отладчиком пользовались разработчики Kx System
От: vdimas Россия  
Дата: 26.03.09 11:20
Оценка:
Здравствуйте, thesz, Вы писали:

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


Нет, совершенно не представляю (идиотская ситуация, согласен), но не суть — громкое заявление ты сделал не на этот счёт. Ладно бы ты еще упёрся именно насчёт пошаговой отладки, я бы и не встрял, ибо само существование спора "пошаговая отладка vs отладочная печать" с моей т.з. — пример наличия идиотизма в нашей профессии. Мне этот спор не интересен. Но отказаться от отладки как таковой в любом её проявлении — это для меня открытие.


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


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


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

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

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


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

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

Спасибо, за лестное звание друга. Очень не люблю количественные вопросы, но на схеме писал прилично, собственно, как и самописный мини-интерпретатор схемы тоже имеется. Бока в другом: тщательно изучил в своё время более 20-ти (!!!) исходников популярных лиспов и схем на предмет реализации замыканий, потому как оно где byvalue, а где-то byref (byname). Самое интересное, что все эти виды замыканий имеют право на существование, но они имеют разную семантику (разную модель), и отсюда несовместимость и косяки отлаженного исходника при смене платформы.

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

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


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


Да, после того как отослал, увидел на сайте, откуда первая буква.


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




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


Знаешь, меня даже не кол-во багов смущает в багтрекере ghc, а их характер. Ведь компилятор написан на Хаскеле! Ладно бы на С, как же так? (10 раз "ай-ай-ай"). Ты ведь не первый здесь Хаскель хвалишь, за последние годы было много рекламы такого плана. И что характерно — по большей части в хамоватом тоне.

То, что ты с чем-то там не столкнулся — это еще ничего не значит. Я, например, несколько лет использовал ADO для Compact SQL от MS, а потом, в одном из сценариев, обнаружил грубейший баг, о чём запостил, получил в ответ "спасибо", но баг был единственный на всю эту либу, а там море interop-a и прочей явной реинтерепретации памяти. Так что, не только в технологиях серебрянная пуля зарыта, она в первую очередь зарыта в организации работ, в ресурсах, в контроле кач-ва и т.д.

Мой поинт такой: за Хаскель было сказано уже слишком много на этом сайте. Кому надо, тот давно понял. Если бы у меня были подходящие задачи, я бы им, наверно, пользовался поактивней. А так у меня то возня с WinAPI, то VoIP. То по размеру программ ограничения идут, то сверхжёсткие по быстродействию... и на фоне этого меня улыбает твоя постоянная мантра о "несвоевременной оптимизации". Знал бы ты, сколько тяп-ляп кода лежит у нас в местах, которые не критичны в плане ресурсов. Как говорится, знаю, как сделать эти места лучше, не знаю — зачем.
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[28]: Каким отладчиком пользовались разработчики Kx System
От: vdimas Россия  
Дата: 26.03.09 14:10
Оценка:
Здравствуйте, thesz, Вы писали:

V>>Как это не может быть в принципе? Подобный "Решарпер" для Хаскеля помогал бы

V>>интиллисенсом для длинных идентификаторов,

T>Плохая практика. Теорему Шеннона о длине кода никто не отменял.


С точки зрения кода, один идентификатор — один символ. Незначащие идентификаторы требуют дополнительных комментариев, которые составляют неотъемлимую часть кода, и, соответственно, значащей информации.

V>>подсвечивал бы ошибки компиляции прямо в процессе редактирования кода,


T>Отвлекая от написания кода.


Не отвлекает, зато время экономит — я далеко не каждый день свой код компилирую, хотя сотни строк кода в день накидываются. В общем, этот пункт можно бсуждать только после приличной практики. Я в своё время был полным противником Java и .Net, ибо после возможностей С++ как-то убого всё было... Генерики и аналог замыканий в C# 2.0 немного спас положение, а заодно приобрёл практику пользования тулзами поддержки набора кода. В общем, время экономит нехило.

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


V>>вставлял пропущенные варианты для паттерн-матчинга,


T>С большой вероятностью наиболее идиотским способом.


Ну вставит он тебе нечто вроде: (_, Some x, _) -> ?
и ты сразу будешь видеть, где у тебя получился неполный матч, удали да напиши себе что хочешь. Это был просто пример, вставлять он может много чего. Самым "идиотским" способом Решарпер вставляет NotImplementedExcetion в тело методов, которые я забыл нагенерить согласно реализованным контрактам, но это так удобно, что все именно с этого и начинают реализацию методов контрактов.

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


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


T>Несмотря на то, что это разрешённая и часто используемая практика.


Для чего используемая? Для соотвествия типу ф-ии?


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


T>Из всех монад только ST и IO имеют побочные эффекты. Прикинь! Только 2 из всего их множества!


T>Ты бы пописал на Хаскеле, вместо фантазирования на эту тему.


Монады можно и самим делать, вроде, я еще не программировал но видел уже десятки их.
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[47]: Каким отладчиком пользовались разработчики Kx System
От: . Великобритания  
Дата: 28.03.09 02:25
Оценка:
Здравствуйте, palm mute, Вы писали:

C>>>Ну HTML — ладно. А вот CSS — точно будет редактировать напрямую. Ибо нафиг ему Haskell не сдался.

L>>Отвечу обоим. В общем, да согласен. Я CSS не генерил ещё, кажется Но и названия классов чтобы менялись — не вспомню.
L>>Но я предупреждал, что пример не очень удачный
PM>Генератор CSS на Haskell
Это, как я понимаю, не то. Это просто ещё один язык, "улучшенный css", который преобразуется в обычный css с помощью утилитки на хаскелле. Вот если бы это был eDSL, чтобы css-разметку можно было прозрачно пересекать с haskell-кодом, чтобы всё что можно проверялось на этапе компиляции — вот это другое дело.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[29]: Каким отладчиком пользовались разработчики Kx System
От: thesz Россия http://thesz.livejournal.com
Дата: 10.04.09 14:20
Оценка:
V>>>Как это не может быть в принципе? Подобный "Решарпер" для Хаскеля помогал бы
V>>>интиллисенсом для длинных идентификаторов,
T>>Плохая практика. Теорему Шеннона о длине кода никто не отменял.
V>С точки зрения кода, один идентификатор — один символ. Незначащие идентификаторы требуют дополнительных комментариев, которые составляют неотъемлимую часть кода, и, соответственно, значащей информации.

Ай.

(настолько моему мозгу больно)

V>>>подсвечивал бы ошибки компиляции прямо в процессе редактирования кода,

T>>Отвлекая от написания кода.
V>Не отвлекает, зато время экономит — я далеко не каждый день свой код компилирую, хотя сотни строк кода в день накидываются. В общем, этот пункт можно бсуждать только после приличной практики. Я в своё время был полным противником Java и .Net, ибо после возможностей С++ как-то убого всё было... Генерики и аналог замыканий в C# 2.0 немного спас положение, а заодно приобрёл практику пользования тулзами поддержки набора кода. В общем, время экономит нехило.

Вот REPL поверх ФЯ попробуй, тогда говори, как часто ты компилируешь код.

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


Лучший ЯП даст лучший дизайн (верхнего уровня).

V>>>вставлял пропущенные варианты для паттерн-матчинга,

T>>С большой вероятностью наиболее идиотским способом.
V>Ну вставит он тебе нечто вроде: (_, Some x, _) -> ?
V>и ты сразу будешь видеть, где у тебя получился неполный матч, удали да напиши себе что хочешь. Это был просто пример, вставлять он может много чего. Самым "идиотским" способом Решарпер вставляет NotImplementedExcetion в тело методов, которые я забыл нагенерить согласно реализованным контрактам, но это так удобно, что все именно с этого и начинают реализацию методов контрактов.

module Events where data Event = Key Char | Mouse Coord2

module MyEventProc where

onEvent (Key c) = ...
onEvent (Mouse c) = ...
onEvent x = ... -- this is default action. may cause "overlapping patterns warning"
                -- for a while. just ignore it.


Или:
unJust (Just x) = x


Смысла в Nothing нет.

V>В хаскеле же тоже есть классы типов (контракты, т.е.), и точно так же под них можно генерить заготовки имплементаций.


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

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

T>>Несмотря на то, что это разрешённая и часто используемая практика.
V>Для чего используемая? Для соотвествия типу ф-ии?

Именно.

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

T>>Из всех монад только ST и IO имеют побочные эффекты. Прикинь! Только 2 из всего их множества!
T>>Ты бы пописал на Хаскеле, вместо фантазирования на эту тему.
V>Монады можно и самим делать, вроде, я еще не программировал но видел уже десятки их.

Ай.

(мозгу снова больно)
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[17]: Каким отладчиком пользовались разработчики Kx System
От: thesz Россия http://thesz.livejournal.com
Дата: 10.04.09 14:58
Оценка:
T>>Я практически четыре года подряд пишу программы, алгоритмы которых не знаю. Представляешь, каково это — ловить алгоритмические ошибки в программе, алгоритм которой ты толком не представляешь?
V>Нет, совершенно не представляю (идиотская ситуация, согласен), но не суть — громкое заявление ты сделал не на этот счёт. Ладно бы ты еще упёрся именно насчёт пошаговой отладки, я бы и не встрял, ибо само существование спора "пошаговая отладка vs отладочная печать" с моей т.з. — пример наличия идиотизма в нашей профессии. Мне этот спор не интересен. Но отказаться от отладки как таковой в любом её проявлении — это для меня открытие.

Этот спор тебе интересен. Ты его продолжаешь.

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

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

Посмотрим.

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

T>>Если это количество больше 100, я продолжу спор, но уже доказательно. Если меньше, то поверь мне на слово — ты не прав. Ты просто не в курсе, как нельзя накосячить на ФЯ.
V>Спасибо, за лестное звание друга. Очень не люблю количественные вопросы, но на схеме писал прилично, собственно, как и самописный мини-интерпретатор схемы тоже имеется. Бока в другом: тщательно изучил в своё время более 20-ти (!!!) исходников популярных лиспов и схем на предмет реализации замыканий, потому как оно где byvalue, а где-то byref (byname). Самое интересное, что все эти виды замыканий имеют право на существование, но они имеют разную семантику (разную модель), и отсюда несовместимость и косяки отлаженного исходника при смене платформы.

Что ты мне в качестве примера приводишь всё самое плохое, что есть в мире ФЯ?

Приводи всё самое хорошее.

Хотя бы ML возьми, если Хаскел не хочешь.

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


Современные ФЯ дают гораздо больше. Я, например, написал DSEL для описания ядер (аппаратуры), там в систему типов Хаскеля вынесены проверки размерности получаемых результатов. Да, это доступно на плюсах, но более громоздко и менее прямо.

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

V>Знаешь, меня даже не кол-во багов смущает в багтрекере ghc, а их характер. Ведь компилятор написан на Хаскеле! Ладно бы на С, как же так? (10 раз "ай-ай-ай"). Ты ведь не первый здесь Хаскель хвалишь, за последние годы было много рекламы такого плана.

1) Библиотека времени выполнения написана на Си.
2) ghc очень большой. Его поддерживает всего ничего человек, около 10. И при этом я встретил всего две ошибки несмотря на его выбор в качестве основного ЯП.

Для сравнения. Над icc трудится что-то около тысячи человек по всему миру.

Поэтому проводи повторный анализ.

V>И что характерно — по большей части в хамоватом тоне.


Если тебе не нравится мой тон, не общайся. Если тебе не нравится мой тон, не делай Gлупых ошибок.

V>То, что ты с чем-то там не столкнулся — это еще ничего не значит. Я, например, несколько лет использовал ADO для Compact SQL от MS, а потом, в одном из сценариев, обнаружил грубейший баг, о чём запостил, получил в ответ "спасибо", но баг был единственный на всю эту либу, а там море interop-a и прочей явной реинтерепретации памяти. Так что, не только в технологиях серебрянная пуля зарыта, она в первую очередь зарыта в организации работ, в ресурсах, в контроле кач-ва и т.д.


И не допускай non sequitur и смешения понятий.

Серебренная пуля относится только к ЯП. Всё остальное к выбору ЯП ортогонально.

V>Мой поинт такой: за Хаскель было сказано уже слишком много на этом сайте. Кому надо, тот давно понял. Если бы у меня были подходящие задачи, я бы им, наверно, пользовался поактивней. А так у меня то возня с WinAPI, то VoIP. То по размеру программ ограничения идут, то сверхжёсткие по быстродействию... и на фоне этого меня улыбает твоя постоянная мантра о "несвоевременной оптимизации".


Да ты ж оптимизируешь без огонька и без особых рассуждений.

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

Придумать что-то за рамками этого ты не в силах.

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

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


Чтобы кода было меньше.

Недавно читал статью про мнезию, там было сказано, что код для поддержки, срабатывающий чрезвычайно редко, плохо поддаётся тестированию и содержит в себе подавляющее большинство ошибок. Одним из критериев разработки мнезии и было сокращение этого кода.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[30]: Каким отладчиком пользовались разработчики Kx System
От: vdimas Россия  
Дата: 10.04.09 21:18
Оценка:
Здравствуйте, thesz, Вы писали:

T>>>Плохая практика. Теорему Шеннона о длине кода никто не отменял.

V>>С точки зрения кода, один идентификатор — один символ. Незначащие идентификаторы требуют дополнительных комментариев, которые составляют неотъемлимую часть кода, и, соответственно, значащей информации.

T>Ай.

T>(настолько моему мозгу больно)

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

А теперь еще раз про код и комментарии, а так же про определение понятий "символ/алфавит".


T>Вот REPL поверх ФЯ попробуй, тогда говори, как часто ты компилируешь код.


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


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


T>Лучший ЯП даст лучший дизайн (верхнего уровня).


А как же middleware?
Использование максимального кол-ва имеющихся _надёжных_ решений — это тоже важный критерий в большой доле случаев, который оправдывает компромиссы относительно инструментария. Мне, может, глубоко в душе и неприятно соотносить себя с тем саммым миллионом леммингов, которые могут ошибаться (в могут и нет), но тот аргумент, когда всё что нужно есть под рукой и в очень надёжном исполнении, заставил меня примерно лет 5 назад пользоваться языками, которые недолюбливаю до сих пор. Се ля ви.

Я кстати, так и не понял, что насчёт модулей в Хаскеле, я имею ввиду бинарные коммерческие модули библиотечного плана (тот же потенциальный middlware), который не поддавался бы тривиальной декомпиляции. Потому как "предкомпилённые" модули что я пока видел, имеют текстовый формат и довольно легко читаются даже без предварительного форматирования. Да и как иначе, если 99% кода имеет "шаблонный" (в терминах С++) характер?


V>>В хаскеле же тоже есть классы типов (контракты, т.е.), и точно так же под них можно генерить заготовки имплементаций.


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


И что? Тоже самое происходит при отсутствии реализаций контрактов в том же C#. Одно дело по документации вытаскивать все методы контрактов (или по логам компилятора), другое дело сразу поиметь заготовки для их имплементации (одновременно с этим редоктор кода подсвечивает на эту ошибку, т.е. мы знаем о ней до компиляции). Мне тут даже настаивать неохота, ибо это надо просто попробовать в "промышленных масштабах" — все отмечают крайнее удобство подобного рода поддержки. Можно без этого жить? Конечно. Но с этим +1 к эффективности. А "+1" величина относительная.

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

T>>>Несмотря на то, что это разрешённая и часто используемая практика.
V>>Для чего используемая? Для соотвествия типу ф-ии?

T>Именно.


Именно что "именно". Это известный косяк в дизайне, когда для существуют сценарии, для которых в сигнатуре наблюдается избыточность. На более высоком уровне "что-то не так", т.е. здесь есть, что подсвечивать.
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[31]: Каким отладчиком пользовались разработчики Kx System
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 13.04.09 14:35
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Именно что "именно". Это известный косяк в дизайне, когда для существуют сценарии, для которых в сигнатуре наблюдается избыточность. На более высоком уровне "что-то не так", т.е. здесь есть, что подсвечивать.


Кстати, nponeccop тоже как то высказывал сомнения в практической полезности комбинатора K.

Теоретическая его (или его аналогов — игнорирование связанной переменной) полезность — завершение базиса комбинаторов сомненений не вызывает. Отсюда вопрос — должен ли практический язык общего назначения быть Тьюринг полным?
Re[32]: Каким отладчиком пользовались разработчики Kx System
От: vdimas Россия  
Дата: 13.04.09 15:57
Оценка:
Здравствуйте, lomeo, Вы писали:


L>Теоретическая его (или его аналогов — игнорирование связанной переменной) полезность — завершение базиса комбинаторов сомненений не вызывает. Отсюда вопрос — должен ли практический язык общего назначения быть Тьюринг полным?


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

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

В общем, мне нравится идея использования смеси DSL для выражения различных частей программы. Некоторые из них запросто могут быть далеки от Тьюринг-полноты. Жаль, что на сегодня такой подход не оправдывает свои трудозатраты в общем случае, но ведущие разработчики ср-в поддержки разработки идут к "точке практичности" на всех парах.
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[33]: Каким отладчиком пользовались разработчики Kx System
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 13.04.09 19:45
Оценка:
Здравствуйте, vdimas, Вы писали:

L>>Теоретическая его (или его аналогов — игнорирование связанной переменной) полезность — завершение базиса комбинаторов сомненений не вызывает. Отсюда вопрос — должен ли практический язык общего назначения быть Тьюринг полным?


Речь же шла о косяке в дизайне? Так тут связь вроде как прямая — наличие K-комбинатора — косяк в дизайне. Я может и ошибаюсь, но не вижу где.

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


Если речь о IDE, то тут разница в том, что для императивного языка неиспользуемые переменные действительно можно поподчёркивать (изменили алгоритм, переменная не используются, но инициализируется, т.к. мы про неё забыли/не учли). В функциональном же языке неиспользуемая переменная нужна только чтобы закрывать дырку в типе. И везде, где она якобы не используется — верный там дизайн или кривой — надо смотреть далеко наверх в определения комбинаторов, а не при их использовании. Это по-моему очень важное отличие — IDE тут нечего помогать.

V>Чем больше степеней свободы предоставляет язык, тем больше потенциальных возможностей накосячить, та же самая бритва Оккама. ;)

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

+1. Как насчёт DSL на основе ленивого языка с HOF? (Да, я про Хаскель :))
Статическая типизация будет нам ограничивать, а ленивость + HOF позволят создавать хорошие комбинаторы.

Пример. Ты писал о языке context free art — не помню названия, но там ты очень красивые цветы рисовал буквально несколькими строчками.
Вот этот язык почти в таком же виде можно нарисовать на Haskell.

Это оффтопик, конечно, но тема, наверное интересная. Я тоже считаю макросы крайней мерой.

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


Вот тут момент, о котором постоянно говорит thesz. Средства разработки как поддержка DSL против языковой поддержки. Вот ещё хороший язык для рисования DSL без макросов — Scala.
Re[34]: Каким отладчиком пользовались разработчики Kx System
От: vdimas Россия  
Дата: 13.04.09 21:57
Оценка:
Здравствуйте, lomeo, Вы писали:

L>>>Теоретическая его (или его аналогов — игнорирование связанной переменной) полезность — завершение базиса комбинаторов сомненений не вызывает. Отсюда вопрос — должен ли практический язык общего назначения быть Тьюринг полным?


L>Речь же шла о косяке в дизайне? Так тут связь вроде как прямая — наличие K-комбинатора — косяк в дизайне. Я может и ошибаюсь, но не вижу где.


Сам себе отвечал?

Наверно в том ошибка, что не надо мешать базисы и дизайн.
Например, goto является самой базовой операцией для императивных языков, в которых для Тьюринг полноты достаточно всего пары: if + goto, однако его непосредственное использование в современных императивных языках — неоспоримый косяк.

ИМХО, необходимость использования низкоуровневого костыля в коде прикладного характера и есть косяк дизайна. Для непосредственной логики отсечения должно быть что-то вроде явного if, причём этот if должен так же существовать в моделируемой предметной области, а не "закрывать дырку" в коде.


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

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

L>+1. Как насчёт DSL на основе ленивого языка с HOF? (Да, я про Хаскель

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

L>Пример. Ты писал о языке context free art — не помню названия, но там ты очень красивые цветы рисовал буквально несколькими строчками.

L>Вот этот язык почти в таком же виде можно нарисовать на Haskell.

Да, видел неоднократные подобного рода утверждения относительно Хаскеля... Тогда вопрос: есть ли при этом возможность ограничить набор языковых конструкций? Чтобы потенциальный разработчик, вместо формирования требований к DSL (возникни таковая надобность), не "сорвался" на прямое подключение и использование произвольных библиотечных модулей?

L>Это оффтопик, конечно, но тема, наверное интересная. Я тоже считаю макросы крайней мерой.


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

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


L>Вот тут момент, о котором постоянно говорит thesz. Средства разработки как поддержка DSL против языковой поддержки.


Оно к этому и идёт, дай им по-акуммулировать ресурсы и опыт.
Тут ведь идёт естественное движение от применения наработок по поддержке конкретного языка в сторону поддержки произвольного языка, через некий способ описания того произвольного языка, достаточного не только для компиляции, но и для "разумного" поведения инструментов, уровня Решарпера. Знаешь ли ты или thesz обо всех ньюансах такой поддержки? Я вот уже лет 10 на jIdea смотрю, и на решарпер лет 5 скоро, количество "тонких моментов" просто поражает (и это для "фискированных" и весьма однозначных языков, а не для произвольных ДСЛ), и постоянно растёт. Ребята роют область, которая ранее толком не была пахана.
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[18]: Каким отладчиком пользовались разработчики Kx System
От: vdimas Россия  
Дата: 13.04.09 22:28
Оценка:
Здравствуйте, thesz, Вы писали:

T>Этот спор тебе интересен. Ты его продолжаешь.


Похоже, это глюкнул "rsdn@home", или я не то что-то нажал в нём.

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

Re[16]: Каким отладчиком пользовались разработчики Kx System
Автор: vdimas
Дата: 17.03.09
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re: Каким отладчиком пользовались разработчики Kx Systems?
От: RegisteredUser  
Дата: 18.04.09 11:23
Оценка:
Здравствуйте, thesz, Вы писали:

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


В недавнем интервью Arthur Whitney признался, что необходимости в отладчике он никогда и не видел:

BC In terms of debugging your code, obviously the power
of a terse language such as K or Q is that, presumably,
it’s easier to find bugs by inspection. How do you debug
them?
AW In C I never learned to use the debugger so I used
to never make mistakes, but now I make mistakes and I
just put in a print statement. K is interpreted, so it’s a lot
easier. If I’m surprised at the value of some local at some
point, I can put in a print, and that’s really all I do.
...
AW It has been 20 years now that I’ve had Wall Street
customers—they’re doing 2 billion transactions a day and
they have trillion-row databases—and in those 20 years,
there was one time where we couldn’t reproduce the bug.
That was nasty. I knew the kinds of operations that they
were doing and I finally found it by just reading my code.
BC Was this a bug in K or Q, or was it in the C base
implementation?
AW It was a bug in C, in my implementation.

Re[4]: Каким отладчиком пользовались разработчики Kx Systems
От: pierre  
Дата: 11.06.09 17:02
Оценка:
Здравствуйте, pierre, Вы писали:

P>Хм, всегда у них был 'отладчик' и сейчас есть. Пример (K3):


Правда, это не касается того кода который пишет Arthur Whitney (если это имелось в виду).
Re[28]: Каким отладчиком пользовались разработчики Kx System
От: vdimas Россия  
Дата: 24.06.09 00:02
Оценка:
Здравствуйте, thesz, Вы писали:

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


T>То есть, мы не можем выразить сложность алгоритма через эти самые параметры?


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


T>Один из "косяков" (отсутствие оптимизации случая) не встречался в реальной жизни,


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

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


А меня не радует, что мы съехали с основной темы — локализации ошибок. И когда я задаю вопрос, почему в этом случае обещанной помощи компилятора не было (и там есть куда предметно углубиться, поверь), твой ответ "не критично" — это больше чем слив. Это заведомая профанация всего обсуждения. Уже пытался тебя привести в чувство, напомнив, что на конкретных примерах мы обсуждаем _классы_ задач, но всё, к сожалению, мимо. Тем не менее, раз ты настаиваешь, я попытаюсь ниже объяснить, почему в подобных классах задач компилятор не помогает.


T>О, да. Все вокруг либо дети, лиоб уже взрослые, все вокруг либо пишут полную туфту, либо сразу пишут всё, как надо.


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

В принципе, тратить время на "философию" я перестал примерно 4-5 лет назад, но периодически непроизвольно рефлексирую на некоторые громкие заявления. Не на все, конечно, а на те, где внутренний наивный оптимизм опять тебе шепчет "а вдруг в этот раз что-то действительно стоящее...". Чаще всего — ан нет, показалось.

T>Итак, строго типизированные представления помогают.


Это известно давно, при чём тут "чистое" ФП? Бывает строго, сильно, слабо типизированные и нетипизированные языки, статически и динамически типизированные, причём, среди функциональных и нефункциональных есть и те и другие. Если же ты имел ввиду статическую типизацию, то опять же, и среди функциональных есть как со статической, так и с динамической типизацией. Скажу больше, алгебраические типы в реализации Хаскеля — это разновидность динамической типизации (не торопись пытаться опровергнуть, это тоже вопрос фундаментального плана).

Разберем, почему в твоем примере не помог коммпилятор (да, в той ситуации это было для тебя не критично... но для меня не критично, что это для тебя не критично , пример-то зрит в корень). Итак. Что суть представляет собой алгебраическая группа? Это некое множество, над которыми определены операции, относящиеся исключительно к членам этого множества. Искать в Хаскеле серебрянную пулю пока бесполезно хотя бы потому, что он позволяет задавать алгебраические множества лишь одного типа — размеченные объединения. Все остальные способы разделения типов на "сорты" выходят за возможности системы типов компилятора (напр. определения группы через предикаты), т.е. не контроллируется в compile-time, а значит, при такой искусственной, с т.з. компилятора декомпозиции, он не помогает с логикой контроля этих "виртуальных" типов. Вот этот твой пример, где не было выхода на другую половину ситуаций (и вообще любой матчинг, где используется аналогичная "глубина просмотра") — всего лишь наглядная демонстрация оперирования группой, св-ва которой невозможно "объяснить" компилятору, потому он и не подсказывает тебе забытый матч, ибо группа нод, содержащих более 2-х близкостоящих констант, существует исключительно в голове разработчика. И ведь, с т.з. теории групп, мы вполне можем задать операции над этой "виртуальной группы", так же как и предикат для определения принадлежности к группе, да вот только статически представить эту группу сложновато, от того оперирование над ней происходит исключительно в рантайм, со всеми вытекающими прелестями. И когда я уже десять раз, наверно, повторял о невозможности компилятора проверять "высокоуровневую логику", ты просто не понимаешь, очевидно, о чём тут идёт речь. А речь тут о том, что пока не придумали того самого "идеального языка", позволяющего задавать произвольные контракты. Была бы возможность задать контракт на такую структуру из нод с константами — и не пропустил бы компилятор твой недописанный матч.


T>Достаточно стандартным приёмом является и конструирование языка для своих внутренних нужд. Даже если это просто некое внутреннее представление.

T>Внутреннее представление есть у всех. Степень типизации, правда, разная.

Во-первых, большинство mainstream языков строго типизированные. Во вторых, конструирование DSL как раз и связано с обсуждаемой проблемой, в саму грамматику DSL и в "компилятор" закладываются ограничения — набор допустимых конструкций, что суть тоже контракт определённого вида. Если рассматривать DSL не для описания данных, а для целей программирования, то большинство из них — это "обрезанные" разновидности существующих ЯП, и в этой "обрезанности" и состоит смысл порождения языка (тебе, как стороннику DSEL персонально), дабы ограничить возможности базового языка до определённого набора безопасных в контексте задачи конструкций. До определённой степени это можно делать на системе типов, но лишь на определённом множестве требований.



T>Вот здесь показано, как пользоваться GADT, чтобы компилятор проверил правильность преобразований.


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

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

Пример из твоей личной практики можно?


T>В ghc 6.10.1 появились data families и type families. data families позволяют безопасно преобразовывать данные. Мы можем гарантировать, что входные и выходные данные будут в boxed формате для обычного кода, а все промежуточные — в unboxed для скорости.


"Номер раз", где ты соглашаешься с потенциальной выгодой от гетерогенности.


T>Это используется в реализации OpenCL и Data Parallel Haskell, как я понял из описаний Manuel Chakravarty.

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

Здесь не очень понял. В рантайм можно, или все же в compile-time?



T>А я по мелочи — размеры битовых векторов проверяю.


И больше нигде как в ФП это невозможно...


T>Серьёзно. Ну вот откуда ты знаешь, что на ЯП получится хуже, чем на ООЯП? Ты делал сравнительные реализации?


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

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


T>А я могу похвастаться тем, что мы делали. ООЯП C++ с мощной библиотекой SystemC проиграл по практически по всем пунктам Хаскелю с одним файликом в двадцать строк кода. В пункты входили быстродействие программы, объём кода, сроки разработки и душевное здоровье членов коллектива.


Суть понятна, без GC некоторые вещи выглядят страшно. Но прикол в том, что на том же C# практически 1-в-1 сделать можно было.
И еще лишь очередное подтверждение банальности, что частный случай проще общего в решении. Т.е., вы сравнивали монстра с 1% процентом его возможностей, а это неспортивно. Я таких сравнений перед каждым новым проектом делаю дофига, если не больше, но далекоидущих выводов не делаю из того факта, что в свободном доступе нет решения, идеально мне подходящего. Где надо — допиливаем, где проще написать самим, чем допилить монтра — пишем своё. (напр, с 0-ля построил серверную библиотеку протокола IAX2 — а этот монстрик далеко не на один файлик, даже не на один десяток). Но ты там на блогах целое шоу из этой будничной ситуации устроил. В общем, много эмоций.

V>>В общем, ты очень много пишешь, но мало приводишь примеров. Из тех, что приводил — не для демонстрации основного твоего посыла "невозможно накосячить", из-за чего собственно и разгорелось у нас. Хотим хлеба и зрелищ. Покажи нам подтверждение своих слов.


T>Ты спрашивай, а не отвечай сам на свои вопросы самым худшим вариантом, что ты смог придумать.


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


...

V>>Где ты увидел вопрос про "плоское пространство имён"? Похоже, ты не отличаешь "область видимости" от "уровня доступа/видимости".


T>Так объясни.


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


V>>И зря ты этот пример привёл, ой как зря. Помнишь спор о графическом представлении программной модели? Вот для как раз этой предметной области графическое представление — самое то. Если интересуешься системами на дискретных событиях, марковскими процессами и прочим, то сразу гоу ту симулинк и не занимайся онанизмом на текстовом ЯП.


T>И ежегодно выкладывай мою годовую зарплату за это удовольствие.


T>Я уж лучше потрачу месяц и помучаюсь с ЯП.


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


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


T>Автоматы на алгебраических типах делаются естественней и безопасней, чем на ООП.


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

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


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

T>Я не перфекционист и перфекционистов сторонюсь. перфекционизм и перфекционисты мешают наслаждаться жизнью.


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

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


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


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



T>У тебя, видимо, ещё не было опыта, когда ты неправильно что-то предполагал. Ты, видимо, никогда не ошибался в своих предположениях.


T>Ну, так поздравляю: ты не так давно что-то предположил и ошибся! Это новый, очень ценный опыт.


Да, именно, через десяток постов узнать, что операция * не перегружаема в Хаскеле — это крайне ценно. Остальным, к сожалению, можно подтереться.


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


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


T>Да и вообще, думать наперёд лучше, чем думать опосля.


А толкать банальности, ИМХО, разновидность троллинга. Ты за собеседника не волнуйся, он обязательно думает, просто у него приоритеты могут не как у тебя стоять, и думает он только над тем, что его интересует. Это надо быть, мягко говоря, не совсем практичной личностью, чтобы заботиться о своем форумном "внешнем виде". Большинство [вменяемых] собеседников обычно обсуждают то, что им интересно, но твой характер ведения диалога полностью исключает такую возможность. Тебе своего времени вот на всё, что было выше, не жаль?


T>>>Да в той задаче мне это просто не нужно было. И в той задаче отлично справился подход с алгебраическим представлением, вот и всё моё умное лицо.

V>>Так это я неправильно мыслю об оптимизации вообще, или оно тебе в этом конкретном месте не очень надо было? У тебя с логикой вообще как?

T>Опыт gcc показывает, что ты неправильно мыслишь об оптимизации вообще. Это понятно?

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

gcc сливает MS VC++ в плане оптимизации, это понятно? Бестолковые отсылки на "чужой опыт" без малейшего упоминания каких-либо предметных вещей — это бестолковая манера сама по-себе, это понятно?

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


T>Оная someProp на Хаскеле содержала бы _value в качестве составной части результата. Ты бы смог её протестировать отдельно, на всех интересных входных данных.


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


V>>Или взять твой пример BallinF, там ведь в правой части каждой строки матчинга можно допустить описку/ошибку логики, которая прекрасно скомпилится. И где тут будет помощь компилятора?


T>В Хаскеле — мало. Хотя я тут навострился применять семейства типов, кое-что полезное ловится.


T>В теории типов ты можешь задать (почти) произвольный инвариант в типе. Например, если должно быть сложение на (EBin Plus a b), то нельзя делать вычитания.



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


Я ВСЕГДА крайне внимательно читаю оппонента, собсно за этим и встреваю. Но не всегда способен за оппонента додумывать. А насчет предположения наихудшего варианта — ты уже не первый раз на это жалуешься, но это малость смешно. Я, как находящийся в оппозиции по обсуждаемому вопросу, именно и должен искать слабые места, и лично мне так же интересны в первую очередь наихудшие случаи. Просто ситуация такова, что Хаскель в одних аспектах хорош, в других явно так себе, а лет мне уже достаточно, но времени — ровно наоборот...


T>За исключением прозрачности по ссылкам. И скрытости. Так что это не обычное lvalue.


Практически обычное... Присвоение в сторону lvalue — это _операция_, которая уже реализована для всех примитивных типов, но может быть перегружена для пользовательских. Может быть написана в виде вызова ф-ии.


T>>>Типобезопасность в ленивых ФЯ достигается проще всех остальных. Все остальные системы сложнее. BitC, например — авторы сами признают, что задача у них очень мощная и почти неподъёмная.

V>>Наверно ты хотел сказать — вывод типов в ленивых ФЯ достигается проще всех остальных. Однако, ты же можешь и явно типы специфицировать, начиная от примитивных, типа int (или как они там в Хаскель называются). И тогда ленивость/нелинивость будут до фени.

T>Я сказал ровно то, что я хотел сказать. Это не то, что ты считаешь, что я, наверное, сказал.


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


T>Похоже, ты вообще не утруждаешь себя размышлениями. Что будет означать (just nothing list) в сравнении с образцом? nothing — это конструктор, или переменная? Над Хаскелем изначально работали люди, которых приглашают специально поработать над C# или Java, чтобы решить очередные проблемы. Приглашают потому, что они overqualified для работы на полную ставку.


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

T>>>Увы, практика доказывает обратное.

T>>>Алгоритм W (Хиндли-Милнера) сперва доказали для чистого подмножества ML, а потом отдельно доказывали для ML со ссылками.
V>>Насколько я понял, еще в конце 80-х все эти вещи произошли.

T>Алгоритм W — 1978. А со ссылками позже на несколько лет.


Ну и? Т.е. этап давно пройденный, за чем дело встало? Почему adga2 только сейчас?
Re[29]: Каким отладчиком пользовались разработчики Kx System
От: thesz Россия http://thesz.livejournal.com
Дата: 24.06.09 11:12
Оценка:
Здравствуйте, vdimas, Вы писали:

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


Стоило с тобой согласиться, так ты с темой хрен знает какой давности вылез. Удивительно.

Чего ты до меня докапываешься?

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

T>>То есть, мы не можем выразить сложность алгоритма через эти самые параметры?
V>Можем, если захотим. И на С++ подобная фича тоже запросто делается, т.к. параметрами шаблонов могут быть интегральные типы.

Вот насчёт "запросто" поподробней. Сделай рациональные типы со сложением, умножением и делением на шаблонах C++. Сделай рациональные типы с теми же операциями на Хаскеле. Сравни объём кода и сложность (количество всяких вещей).

Пойдём дальше.

Перегрузи в C++ оператор ';', чтобы она протягивала контекст, как в параметризованных монадах.

С перегруженной ';' мы можем считать сложность алгоритма без изменения исходного кода.

V>Просто мне твоя логика не понятна: то ты обвиняешь в "преждевременной оптимизации", то рекламируешь возможность ограничения сложности алгоритмов в контракте.


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

V>По мне — это противоположные полюсы одного и того же процесса.


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

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

V>К тому же, run-time ограничения сложности мне как-то привычнее, ибо они способны оперировать большим числом параметров, например: временем выполнения (что критично для сетевых таймаутов), или текущей мнгновенной загрузкой процессора (была и такая задачка у меня), а подобные параметры не доступны компилятору, естественно.


Их можно ввести и добиться формального учёта.

V>Я потому и попросил тебя привести пример, ибо мой личный опыт мне не подсказал пока killer-example для этой фичи.


Для какой фичи? Определения времени выполнения? Так рилтайм приложения из района встраиваемых систем. Там, где можно использовать Atom.

T>>Один из "косяков" (отсутствие оптимизации случая) не встречался в реальной жизни,

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

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

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

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

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

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

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

Смотри на приблизительный сценарий нашей беседы:
T: Вот такая задача, вот так в ней мне помог компилятор...
V: А вот с этим он не помог.
T: С чем не помог?
V: А вот с этим — когда я делал похожее, у меня было вот эдак, и в твоём случае компилятор с этим не помог.
T: Но в моей задаче не было этого!
V: А почему тебе компилятор не помог с этим справиться?
T: Да потому, что в моей задаче это не было критично и я такого не делал!
V: То, что ты говоришь "не критично", означает слив.

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

V>Это заведомая профанация всего обсуждения. Уже пытался тебя привести в чувство, напомнив, что на конкретных примерах мы обсуждаем _классы_ задач, но всё, к сожалению, мимо. Тем не менее, раз ты настаиваешь, я попытаюсь ниже объяснить, почему в подобных классах задач компилятор не помогает.


Трепещу в нетерпении.

T>>О, да. Все вокруг либо дети, лиоб уже взрослые, все вокруг либо пишут полную туфту, либо сразу пишут всё, как надо.


V>Либо делают громкие заявления, которые затрудняются потом объяснить.

V>"О, да" и иже с ним больше не пиши, это как-то не к лицу разработчикам с таким стажем.

На всякий случай: "О, да." это цитата из Града Обречённого.

V>В принципе, тратить время на "философию" я перестал примерно 4-5 лет назад, но периодически непроизвольно рефлексирую на некоторые громкие заявления. Не на все, конечно, а на те, где внутренний наивный оптимизм опять тебе шепчет "а вдруг в этот раз что-то действительно стоящее...". Чаще всего — ан нет, показалось.


Ты не даёшь себе труда разобраться.

Я уже встречался с этим шаблоном на примере ЖЖ пользователя lex_kravetski. Он тоже про Хаскель спрашивал. Практически всё, что ему рассказывали, он сводил к "это мы обёрткой сделаем" и "это мы можем в динамике проверить". Практически каждый третий его комментарий заканчивался "и чем это лучше Java?"

Однажды попав в смоляную яму Тьюринга (Turing tar-pit), он не видит разницы между Тьюринг полными языками.

Так и здесь.

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

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

Просто (pardon the pun, it's intented) многие вещи при переходе на алгебраические типы станут выполняться проще настолько, что станут возможными.

T>>Итак, строго типизированные представления помогают.

V>Это известно давно, при чём тут "чистое" ФП? Бывает строго, сильно, слабо типизированные и нетипизированные языки, статически и динамически типизированные, причём, среди функциональных и нефункциональных есть и те и другие. Если же ты имел ввиду статическую типизацию, то опять же, и среди функциональных есть как со статической, так и с динамической типизацией. Скажу больше, алгебраические типы в реализации Хаскеля — это разновидность динамической типизации (не торопись пытаться опровергнуть, это тоже вопрос фундаментального плана).

V>Разберем, почему в твоем примере не помог коммпилятор (да, в той ситуации это было для тебя не критично... но для меня не критично, что это для тебя не критично , пример-то зрит в корень). Итак. Что суть представляет собой алгебраическая группа? Это некое множество, над которыми определены операции, относящиеся исключительно к членам этого множества. Искать в Хаскеле серебрянную пулю пока бесполезно хотя бы потому, что он позволяет задавать алгебраические множества лишь одного типа — размеченные объединения.

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

Классы типов?

V>т.е. не контроллируется в compile-time, а значит, при такой искусственной, с т.з. компилятора декомпозиции, он не помогает с логикой контроля этих "виртуальных" типов. Вот этот твой пример, где не было выхода на другую половину ситуаций (и вообще любой матчинг, где используется аналогичная "глубина просмотра") — всего лишь наглядная демонстрация оперирования группой, св-ва которой невозможно "объяснить" компилятору, потому он и не подсказывает тебе забытый матч, ибо группа нод, содержащих более 2-х близкостоящих констант, существует исключительно в голове разработчика. И ведь, с т.з. теории групп, мы вполне можем задать операции над этой "виртуальной группы", так же как и предикат для определения принадлежности к группе, да вот только статически представить эту группу сложновато, от того оперирование над ней происходит исключительно в рантайм, со всеми вытекающими прелестями.

V>И когда я уже десять раз, наверно, повторял о невозможности компилятора проверять "высокоуровневую логику", ты просто не понимаешь, очевидно, о чём тут идёт речь. А речь тут о том, что пока не придумали того самого "идеального языка", позволяющего задавать произвольные контракты. Была бы возможность задать контракт на такую структуру из нод с константами — и не пропустил бы компилятор твой недописанный матч.

Coq и иже с ними?

T>>Достаточно стандартным приёмом является и конструирование языка для своих внутренних нужд. Даже если это просто некое внутреннее представление.

T>>Внутреннее представление есть у всех. Степень типизации, правда, разная.
V>Во-первых, большинство mainstream языков строго типизированные.

Не с достаточной степенью строгости.

V>Во вторых, конструирование DSL как раз и связано с обсуждаемой проблемой, в саму грамматику DSL и в "компилятор" закладываются ограничения — набор допустимых конструкций, что суть тоже контракт определённого вида. Если рассматривать DSL не для описания данных, а для целей программирования, то большинство из них — это "обрезанные" разновидности существующих ЯП, и в этой "обрезанности" и состоит смысл порождения языка (тебе, как стороннику DSEL персонально), дабы ограничить возможности базового языка до определённого набора безопасных в контексте задачи конструкций. До определённой степени это можно делать на системе типов, но лишь на определённом множестве требований.


Со временем всё более и более широком.

T>>Вот здесь показано, как пользоваться GADT, чтобы компилятор проверил правильность преобразований.

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

Описание команд модели процессора с учётом размеров регистров.

data Expr size v f where
        ...
    EBinary    :: BinOp leftsize rightsize resultsize
           -> Expr leftsize v f -> Expr rightsize v f
           -> Expr resultsize v f
       ...
data BinOp leftsize rightsize resultsize where
    Plus    :: BinOp size size size
    Minus    :: BinOp size size size
    Mul    :: BinOp size size size
    Mul2    :: BinOp size size (NPlus size size)
        ...


T>>В ghc 6.10.1 появились data families и type families. data families позволяют безопасно преобразовывать данные. Мы можем гарантировать, что входные и выходные данные будут в boxed формате для обычного кода, а все промежуточные — в unboxed для скорости.

V>"Номер раз", где ты соглашаешься с потенциальной выгодой от гетерогенности.

Чего?

T>>Это используется в реализации OpenCL и Data Parallel Haskell, как я понял из описаний Manuel Chakravarty.

T>>В принципе, эти штуки использует факт, что типы данных в Хаскеле по структуре совпадают с выражениями лямбда-исчисления. Над ними можно производить вычисления, как над лямбда-термами.
V>Здесь не очень понял. В рантайм можно, или все же в compile-time?

Compile time.

Смотри (применение NPlus смотри выше в BinOp):
data Z = Z
data S n = S n

type family   NPlus a b
type instance NPlus Z a = a
type instance NPlus (S a) b = S (NPlus a b)


T>>А я по мелочи — размеры битовых векторов проверяю.

V>И больше нигде как в ФП это невозможно...

Настолько просто — нет.

T>>Серьёзно. Ну вот откуда ты знаешь, что на ЯП получится хуже, чем на ООЯП? Ты делал сравнительные реализации?

V>Как я сделаю тебе сравнительную реализацию, если рано или поздно нам приходится упираться в понятие "некопируемого экземпляра"?

Что такое "некопируемый экземпляр"?

V>А если это возможно в ФП через пару приседаний (те же монады), то зачем нам такое ФП?

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

Увы, и ах, но нет.

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

В этом случае "мутабельная переменная" здесь не совсем подходит.

V>Ведь это же очевидно, что некоторые монады — суть моделирование мутабельности.


Буквально одна, конкретно State. А есть ещё Cont, List, Error... А есть ещё их комбинации...

V>Ну и для чего тогда весь первоначальный цирк с "чистым" ФП, если на всех этих моделях мутабельных регистров можно так же точно смоделировать все грабли с побочными эффектами, как в императивных языках?


Всё равно у меня на выходе функция, а её проще проверять.

Монада состояния это функция state -> (a,state). На любую часть монадического кода я могу подать какое угодно state и проверить, что же за a и что же за state он мне вернёт.

Вырезал, и проверил.

Очень просто.

V>Признаюсь, грамотный ответ именно на этот вопрос интересует больше, чем все другие вместе взятые по теме ФП (ввиду практичности этого момента, в отличии от прочей задвигаемой здесь белеберды о "самоконтроллируемости всего").


Они связаны друг с другом.

При введении изменяемости в непротиворечивую систему типов надо снова доказывать её непротиворечивость.

T>>А я могу похвастаться тем, что мы делали. ООЯП C++ с мощной библиотекой SystemC проиграл по практически по всем пунктам Хаскелю с одним файликом в двадцать строк кода. В пункты входили быстродействие программы, объём кода, сроки разработки и душевное здоровье членов коллектива.


V>Суть понятна, без GC некоторые вещи выглядят страшно. Но прикол в том, что на том же C# практически 1-в-1 сделать можно было.


Не поверю, пока не увижу. Даже странно, что ты не написал те самые 20 строк кода, если всё настолько один-в-один.

V>И еще лишь очередное подтверждение банальности, что частный случай проще общего в решении. Т.е., вы сравнивали монстра с 1% процентом его возможностей, а это неспортивно.


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

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

Товарищи, использовавшие SystemC, не смогли провести такой анализ.

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

V>Я таких сравнений перед каждым новым проектом делаю дофига, если не больше, но далекоидущих выводов не делаю из того факта, что в свободном доступе нет решения, идеально мне подходящего. Где надо — допиливаем, где проще написать самим, чем допилить монтра — пишем своё. (напр, с 0-ля построил серверную библиотеку протокола IAX2 — а этот монстрик далеко не на один файлик, даже не на один десяток). Но ты там на блогах целое шоу из этой будничной ситуации устроил. В общем, много эмоций.


Это не я устроил. Это устроил руководитель товарищей, что писали на SystemC. Который не смог произвести анализ.

V>>>Где ты увидел вопрос про "плоское пространство имён"? Похоже, ты не отличаешь "область видимости" от "уровня доступа/видимости".

T>>Так объясни.
V>Я имел ввиду разграничение видимости типа private/public на всех уровнях, а не только на уровне модулей. Я не верю в реальные программы без побочных эффектов (в файл же писать как-то надо), т.е. вопрос инкапсуляции "опасных" данных и кода по-прежнему открыт.

IO Int не совместимо с Int. Отрисовка в DrawingArea gtk2hs выполняется в RenderM, где надо делать специальные действия по вызову IO действий.

Там, где ты требуешь public/private, работает система типов.

T>>Автоматы на алгебраических типах делаются естественней и безопасней, чем на ООП.

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

Главное, что сама логическая часть работает правильно. И если мне понадобится хранить состояние автомата и ходить по нему вперёд-назад, то я могу это сделать лёгким движением руки.

Вдогонку: автомат для RS232 ~30 строк. Обернуть его в IO монаду для общения с Control.Parallel.Chan — три-пять строк. Ошибки будут явно не обёртке, поэтому беспокоиться на этот счёт не надо.

T>>Я не перфекционист и перфекционистов сторонюсь. перфекционизм и перфекционисты мешают наслаждаться жизнью.

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

Тогда я не понимаю, чего ты его возобновил.

T>>У тебя, видимо, ещё не было опыта, когда ты неправильно что-то предполагал. Ты, видимо, никогда не ошибался в своих предположениях.

T>>Ну, так поздравляю: ты не так давно что-то предположил и ошибся! Это новый, очень ценный опыт.
V>Да, именно, через десяток постов узнать, что операция * не перегружаема в Хаскеле — это крайне ценно. Остальным, к сожалению, можно подтереться.

И это твоё новое знание тоже неверно: операция * перегружается.

T>>>>Да в той задаче мне это просто не нужно было. И в той задаче отлично справился подход с алгебраическим представлением, вот и всё моё умное лицо.

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

V>gcc сливает MS VC++ в плане оптимизации, это понятно?


Я работал с товарищами из Optimitech.com, пользовался их библиотекой оптимизаций. Их сложение тоже было двухместным.

V>Бестолковые отсылки на "чужой опыт" без малейшего упоминания каких-либо предметных вещей — это бестолковая манера сама по-себе, это понятно?


Так прекрати со мной общаться.

V>Что мне понятно, так это то, что от реализации оптимизации в gcc ты крайне далек, и в лучшем случае слышал краем уха, как можно судить по твоим наивным "заглядываниям вглубь еще на 1 уровень" на основе матчинга.


Смотрим на gcc 4.4.4, что случайно оказался у меня под рукой. Файл tree-ssa-copy.c:
bool
may_propagate_copy (tree dest, tree orig)
  /* For memory partitions, copies are OK as long as the memory symbol
     belongs to the partition.  */
  if (TREE_CODE (dest) == SSA_NAME
      && TREE_CODE (SSA_NAME_VAR (dest)) == MEMORY_PARTITION_TAG)
    return (TREE_CODE (orig) == SSA_NAME
            && !is_gimple_reg (orig)
        && (SSA_NAME_VAR (dest) == SSA_NAME_VAR (orig)
            || bitmap_bit_p (MPT_SYMBOLS (SSA_NAME_VAR (dest)),
                             DECL_UID (SSA_NAME_VAR (orig)))));


Что можно переписать на "заглядывании внутрь на основе матчинга" вот так:
may_propagate_copy dest@(SSA_NAME destNameVar) orig@(SSA_NAME (MEMORY_PARTITION origUID))
    = not (isGimpleReg orig)
      && (destNameVar == origNameVar
          || bitmap_bit_p (mptSymbols destNameVar) origUID)


Плюс-минус, тем не менее.

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


Лично я бы предпочёл вопрос в более прямой форме, например: "а вот если нам надо рассматривать ещё и вот такой вариант, что надо сделать?"

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

V>А твое рефлексирование и постоянное проявление недовольства фактом замеченной недоделанности (с переходом на личности) по-сути убило все обсуждение, это понятно?


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

Да, это убило дискуссию.

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

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


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

T>>>>Типобезопасность в ленивых ФЯ достигается проще всех остальных. Все остальные системы сложнее. BitC, например — авторы сами признают, что задача у них очень мощная и почти неподъёмная.

V>>>Наверно ты хотел сказать — вывод типов в ленивых ФЯ достигается проще всех остальных. Однако, ты же можешь и явно типы специфицировать, начиная от примитивных, типа int (или как они там в Хаскель называются). И тогда ленивость/нелинивость будут до фени.
T>>Я сказал ровно то, что я хотел сказать. Это не то, что ты считаешь, что я, наверное, сказал.
V>Я предположил, что ты неверно выразил верную мысль. Ибо твоя исходная формулировка некорректна (курить "строгую типизацию").

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

Поэтому не только вывод, но и проверка типов для ленивых ФЯ получается проще, чем у других ЯП.

T>>Похоже, ты вообще не утруждаешь себя размышлениями. Что будет означать (just nothing list) в сравнении с образцом? nothing — это конструктор, или переменная? Над Хаскелем изначально работали люди, которых приглашают специально поработать над C# или Java, чтобы решить очередные проблемы. Приглашают потому, что они overqualified для работы на полную ставку.

V>Угу, только сам автор Хаскеля выдвинул несколько иную версию произошедшего.

Какую же?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[30]: Каким отладчиком пользовались разработчики Kx System
От: vdimas Россия  
Дата: 03.07.09 08:22
Оценка:
Здравствуйте, thesz, Вы писали:

T>Стоило с тобой согласиться, так ты с темой хрен знает какой давности вылез. Удивительно.


Да у меня rsdn@home на разных локациях валяется, и из одной из них неосторожно синхронизировался, забыв про давний неотправленный пост. Так что сорри, и спасибо за ответ.


T>Перегрузи в C++ оператор ';', чтобы она протягивала контекст, как в параметризованных монадах.

T>С перегруженной ';' мы можем считать сложность алгоритма без изменения исходного кода.

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

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


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

V>>Я потому и попросил тебя привести пример, ибо мой личный опыт мне не подсказал пока killer-example для этой фичи.

T>Для какой фичи? Определения времени выполнения? Так рилтайм приложения из района встраиваемых систем. Там, где можно использовать Atom.

Понятно, т.е. когда мы можем гарантировать, что процессорное время целиком отведено под нашу задачу. Для многозадачных операционок общего пользования это малость мимо. Возвращаясь к ';' и прочему, мне все-равно плохо понятно, как ты собрался считать время выполнения. Ты можешь подсчитать кол-во выражений, но как ты подсчитаешь их сложность, и тем паче время работы в тиках целевого проца?

T>Смотри на приблизительный сценарий нашей беседы:

T>T: Вот такая задача, вот так в ней мне помог компилятор...
T>V: А вот с этим он не помог.
T>T: С чем не помог?
T>V: А вот с этим — когда я делал похожее, у меня было вот эдак, и в твоём случае компилятор с этим не помог.
T>T: Но в моей задаче не было этого!
T>V: А почему тебе компилятор не помог с этим справиться?
T>T: Да потому, что в моей задаче это не было критично и я такого не делал!
T>V: То, что ты говоришь "не критично", означает слив.

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

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


Серьёзно?
Если я определяюсь — использовать этот ЯП или нет, но не так уж глупо. Насчет того человека с Явой и меня — в чем-то ты прав. Решение-то не простое: на одной чаше весов легкость написания своих велосипедов, на другой — мощь фреймворков и тонн библиотек (по крайней мере в интересующей меня области). А так же легкость в интероперабельности с различными COMпонентами и т.д. А то задачи-то разные: там веб-морду нарисовать, там пару окон ГУИ, здесь с кассовым аппаратом связаться и т.д., и каждая задача на .Net (иногда плюс С++) делается за считанные часы (если не минуты), а на Хаскеле подобные задачи требуют лишних приседаний. Я много просмотрел и твоих блогов и блогов твоих регулярных товарищей в ЖЖ, и те случаи, что пока видел, помогают лишь в самых примитивных случаях, а остальное делается гораздо сложнее даже, чем в С++, напр. типы, обобщаемые по интегральному параметру (зависимые).

Было бы всё так просто, не было бы этого и подобных разговоров.

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

T>Классы типов?

Не совсем, ты же не можешь использовать это при одном уровне ветвления матчинга, надо делать еще один уровень, и это вырождается в похожие уровни вложенностей if/else.

V>>И когда я уже десять раз, наверно, повторял о невозможности компилятора проверять "высокоуровневую логику", ты просто не понимаешь, очевидно, о чём тут идёт речь. А речь тут о том, что пока не придумали того самого "идеального языка", позволяющего задавать произвольные контракты. Была бы возможность задать контракт на такую структуру из нод с константами — и не пропустил бы компилятор твой недописанный матч.


T>Coq и иже с ними?


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

V>>Во-первых, большинство mainstream языков строго типизированные.

T>Не с достаточной степенью строгости.

Для С++ я уже говорил: избавь его от приведения в стиле С и от всяких xxx_cast<>, и это будет другой язык с другой репутацией. Во всем остальном он достаточно строг, а xxx_cast<> вылавливаются в проекте простым поиском. Мне известна система на миллионны строк без единого xxx_cast<>.

V>>Во вторых, конструирование DSL как раз и связано с обсуждаемой проблемой, в саму грамматику DSL и в "компилятор" закладываются ограничения — набор допустимых конструкций, что суть тоже контракт определённого вида. Если рассматривать DSL не для описания данных, а для целей программирования, то большинство из них — это "обрезанные" разновидности существующих ЯП, и в этой "обрезанности" и состоит смысл порождения языка (тебе, как стороннику DSEL персонально), дабы ограничить возможности базового языка до определённого набора безопасных в контексте задачи конструкций. До определённой степени это можно делать на системе типов, но лишь на определённом множестве требований.


T>Со временем всё более и более широком.


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


T>Описание команд модели процессора с учётом размеров регистров.

T>
T>        ...
T>


Или я ничего не понял, или здесь просто строгая типизация на обобщенных типах.


T>Смотри (применение NPlus смотри выше в BinOp):

T>
...
T>


T>>>А я по мелочи — размеры битовых векторов проверяю.

V>>И больше нигде как в ФП это невозможно...

T>Настолько просто — нет.


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

T>Что такое "некопируемый экземпляр"?


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

V>>А если это возможно в ФП через пару приседаний (те же монады), то зачем нам такое ФП?

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

T>Увы, и ах, но нет.


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

T>В этом случае "мутабельная переменная" здесь не совсем подходит.

V>>Ведь это же очевидно, что некоторые монады — суть моделирование мутабельности.


T>Буквально одна, конкретно State. А есть ещё Cont, List, Error... А есть ещё их комбинации...


V>>Ну и для чего тогда весь первоначальный цирк с "чистым" ФП, если на всех этих моделях мутабельных регистров можно так же точно смоделировать все грабли с побочными эффектами, как в императивных языках?


T>Всё равно у меня на выходе функция, а её проще проверять.


T>Монада состояния это функция state -> (a,state). На любую часть монадического кода я могу подать какое угодно state и проверить, что же за a и что же за state он мне вернёт.

T>Вырезал, и проверил.
T>Очень просто.

А юнит-тестирование объектов в ООП разве не оно же?


V>>Признаюсь, грамотный ответ именно на этот вопрос интересует больше, чем все другие вместе взятые по теме ФП (ввиду практичности этого момента, в отличии от прочей задвигаемой здесь белеберды о "самоконтроллируемости всего").


T>Они связаны друг с другом.

T>При введении изменяемости в непротиворечивую систему типов надо снова доказывать её непротиворечивость.

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

V>>Суть понятна, без GC некоторые вещи выглядят страшно. Но прикол в том, что на том же C# практически 1-в-1 сделать можно было.

T>Не поверю, пока не увижу. Даже странно, что ты не написал те самые 20 строк кода, если всё настолько один-в-один.

1-в-1 по логике, не по размеру кода, ессно (описание типов малость говорливо в том же C#, согласен)... просто там миниатюрная логика у тебя, но сама подобная логика (создали экземпляр типа, отдали и забыли) достижима только в системах с GC.

V>>И еще лишь очередное подтверждение банальности, что частный случай проще общего в решении. Т.е., вы сравнивали монстра с 1% процентом его возможностей, а это неспортивно.


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

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

T>Товарищи, использовавшие SystemC, не смогли провести такой анализ.


Даже если смогли бы/хотели бы провести анализ, не упростили по фундаментальным причинам. Да, в С/С++ структура программы и способ решения задач почти всегда пляшет от доступной модели управления памятью, отсюда столько ручных "мета-описаний" в любых задачах обобщения алгоритмов на заведомо неизвестные структуры.

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


T>IO Int не совместимо с Int. Отрисовка в DrawingArea gtk2hs выполняется в RenderM, где надо делать специальные действия по вызову IO действий.


T>Там, где ты требуешь public/private, работает система типов.


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

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

V>>gcc сливает MS VC++ в плане оптимизации, это понятно?


T>Я работал с товарищами из Optimitech.com, пользовался их библиотекой оптимизаций. Их сложение тоже было двухместным.


V>>Бестолковые отсылки на "чужой опыт" без малейшего упоминания каких-либо предметных вещей — это бестолковая манера сама по-себе, это понятно?


T>Так прекрати со мной общаться.
Re[15]: Каким отладчиком пользовались разработчики Kx System
От: blackhearted Украина  
Дата: 03.07.09 09:29
Оценка:
Здравствуйте, Didro, Вы писали:

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

D>

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


А чем может быть доказана корректность программ? Крутостью разработчика?
Re[31]: Каким отладчиком пользовались разработчики Kx System
От: thesz Россия http://thesz.livejournal.com
Дата: 03.07.09 09:51
Оценка:
T>>Перегрузи в C++ оператор ';', чтобы она протягивала контекст, как в параметризованных монадах.
T>>С перегруженной ';' мы можем считать сложность алгоритма без изменения исходного кода.
V>Насколько я понял, в Хаскеле не очень любят явное употребление ';', или позиционная запись тоже будет работать для этого случая?

';' использована мной вместо >>=. >>= исполняет роль точки с запятой в монадах

V>В С++ можно перегрузить оператор ','.


Ура!

V>>>Я потому и попросил тебя привести пример, ибо мой личный опыт мне не подсказал пока killer-example для этой фичи.

T>>Для какой фичи? Определения времени выполнения? Так рилтайм приложения из района встраиваемых систем. Там, где можно использовать Atom.
V>Понятно, т.е. когда мы можем гарантировать, что процессорное время целиком отведено под нашу задачу. Для многозадачных операционок общего пользования это малость мимо. Возвращаясь к ';' и прочему, мне все-равно плохо понятно, как ты собрался считать время выполнения. Ты можешь подсчитать кол-во выражений, но как ты подсчитаешь их сложность, и тем паче время работы в тиках целевого проца?

К любым операциям я могу пристегнуть типы со временем выполнения.

Вместо обычного Integer в + у меня будет MyInt cpu cycles, операция сложения для которого будет вычислять количество тиков для обеих подвыражений с учётом CPU.

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

Мне придётся подумать, но это возможно. Люди это делают.

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

V>Серьёзно?
V>Если я определяюсь — использовать этот ЯП или нет, но не так уж глупо. Насчет того человека с Явой и меня — в чем-то ты прав. Решение-то не простое: на одной чаше весов легкость написания своих велосипедов, на другой — мощь фреймворков и тонн библиотек (по крайней мере в интересующей меня области). А так же легкость в интероперабельности с различными COMпонентами и т.д. А то задачи-то разные: там веб-морду нарисовать, там пару окон ГУИ, здесь с кассовым аппаратом связаться и т.д., и каждая задача на .Net (иногда плюс С++) делается за считанные часы (если не минуты), а на Хаскеле подобные задачи требуют лишних приседаний. Я много просмотрел и твоих блогов и блогов твоих регулярных товарищей в ЖЖ, и те случаи, что пока видел, помогают лишь в самых примитивных случаях, а остальное делается гораздо сложнее даже, чем в С++, напр. типы, обобщаемые по интегральному параметру (зависимые).

Зато часть с GUI будет работать с учётом части с Web лицом и с учётом части, работающей с COM-портом. И все будут работать с базой и если в базе что-то поменялось, то придётся протащить изменения везде, где надо.

V>Было бы всё так просто, не было бы этого и подобных разговоров.


Это проще, чем ты думаешь.

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

T>>Классы типов?
V>Не совсем, ты же не можешь использовать это при одном уровне ветвления матчинга, надо делать еще один уровень, и это вырождается в похожие уровни вложенностей if/else.

Покажи, я не понимаю.

V>>>И когда я уже десять раз, наверно, повторял о невозможности компилятора проверять "высокоуровневую логику", ты просто не понимаешь, очевидно, о чём тут идёт речь. А речь тут о том, что пока не придумали того самого "идеального языка", позволяющего задавать произвольные контракты. Была бы возможность задать контракт на такую структуру из нод с константами — и не пропустил бы компилятор твой недописанный матч.

T>>Coq и иже с ними?
V>Близко, но язык на сегодня непрактичен из-за узкой специализации и связанной с этим отсутствием нужной мне инфраструктуры для моих повседневных задач.

Лично моё мнение таково: прикладные части задачи решаются очень быстро, вне зависимости от ЯП. Главное — это ядро логики. Основной риск всегда там.

Именно поэтому Хаскель и именно поэтому движение в сторону зависимых типов.

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

Coq умеет генерировать код на Камле или Хаскеле. Значит, его легко переделать под генерацию F#. Если тебе нужна инфраструктура, то это твой путь.

V>>>Во-первых, большинство mainstream языков строго типизированные.

T>>Не с достаточной степенью строгости.
V>Для С++ я уже говорил: избавь его от приведения в стиле С и от всяких xxx_cast<>, и это будет другой язык с другой репутацией. Во всем остальном он достаточно строг, а xxx_cast<> вылавливаются в проекте простым поиском. Мне известна система на миллионны строк без единого xxx_cast<>.

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

T>>Со временем всё более и более широком.

V>Если говорить конкретно по Хаскель, то я дважды здесь задавал вопрос: что мешает человеку, использующему DSEL, вместо формирования требований к DSL (буде такая потребность) "сорваться" на прямое использование потенционально небезопасной всей мощи языка. По-сути, вопрос стоит в плоскости целей разработки DSL как таковых.

Типы.

T>>Описание команд модели процессора с учётом размеров регистров.

T>>
T>>        ...
T>>

V>Или я ничего не понял, или здесь просто строгая типизация на обобщенных типах.

Это строгая типизация с учётом смысла операций. Ты зря урезал NPlus, который стоит в операции Concat. На Java/C# это сделать нельзя вообще, на C++ очень сложно.

T>>>>А я по мелочи — размеры битовых векторов проверяю.

V>>>И больше нигде как в ФП это невозможно...
T>>Настолько просто — нет.
V>Явная специализация обобщенных типов конечно руль (это выход на метапрограммирование), но она опять же, не только в Хаскеле. Неужели простота только в кол-ве букв?

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

T>>Что такое "некопируемый экземпляр"?

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

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

Что такое "некопируемый экземпляр"?


Это всё требует более развёрнутого пояснения.

V>>>А если это возможно в ФП через пару приседаний (те же монады), то зачем нам такое ФП?

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

T>>Увы, и ах, но нет.


V>>>Ведь это же очевидно, что некоторые монады — суть моделирование мутабельности.

T>>Буквально одна, конкретно State. А есть ещё Cont, List, Error... А есть ещё их комбинации...
V>>>Ну и для чего тогда весь первоначальный цирк с "чистым" ФП, если на всех этих моделях мутабельных регистров можно так же точно смоделировать все грабли с побочными эффектами, как в императивных языках?
T>>Всё равно у меня на выходе функция, а её проще проверять.
T>>Монада состояния это функция state -> (a,state). На любую часть монадического кода я могу подать какое угодно state и проверить, что же за a и что же за state он мне вернёт.
T>>Вырезал, и проверил.
T>>Очень просто.

V>А юнит-тестирование объектов в ООП разве не оно же?


Отличается количество движений программиста.

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

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

V>>>Признаюсь, грамотный ответ именно на этот вопрос интересует больше, чем все другие вместе взятые по теме ФП (ввиду практичности этого момента, в отличии от прочей задвигаемой здесь белеберды о "самоконтроллируемости всего").

T>>Они связаны друг с другом.
T>>При введении изменяемости в непротиворечивую систему типов надо снова доказывать её непротиворечивость.
V>Для С++ этим занимается целый коммитет, и эта вещь одноразова, вообще-то на весь язык, т.е., каждый разработчик компилятора уже не должен заниматься никакими док-вами.

Но для создания встроенных языков и/или библиотек тебе придётся доказывать это снова и снова. Для каждой библиотеки и для каждого сочетания библиотек.

V>>>Суть понятна, без GC некоторые вещи выглядят страшно. Но прикол в том, что на том же C# практически 1-в-1 сделать можно было.

T>>Не поверю, пока не увижу. Даже странно, что ты не написал те самые 20 строк кода, если всё настолько один-в-один.
V>1-в-1 по логике, не по размеру кода, ессно (описание типов малость говорливо в том же C#, согласен)... просто там миниатюрная логика у тебя, но сама подобная логика (создали экземпляр типа, отдали и забыли) достижима только в системах с GC.

Количество движений, помнишь? Количество движений. Логика никого не интересует.

T>>Товарищи, использовавшие SystemC, не смогли провести такой анализ.

V>Даже если смогли бы/хотели бы провести анализ, не упростили по фундаментальным причинам.

Да брось ты.

V>Да, в С/С++ структура программы и способ решения задач почти всегда пляшет от доступной модели управления памятью, отсюда столько ручных "мета-описаний" в любых задачах обобщения алгоритмов на заведомо неизвестные структуры.


Ты пытаешься их оправдать, исходя из своего опыта.

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

T>>Там, где ты требуешь public/private, работает система типов.

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

Что сделает твой безответственный, либо начинающий программист в случае наличия public/private?

Да ровно то же самое.

V>Лично мне кажется, что public/private ортогональны системе типов, это лишь ср-во повышения безопасности кода при разделении труда, а от разделения труда в больших проектах никуда не деться.


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

С типами, однако интересней: Parser не даёт возможность читать файлы. Если не сделать ему интерфейс MonadIO. А последнее будет видно.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[15]: Каким отладчиком пользовались разработчики Kx System
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.07.09 12:12
Оценка:
Здравствуйте, Didro, Вы писали:

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

D>

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


Дейкстра говорит большую банальность, я формулирую такое по другому — писать код надо головой а не дебуггером(руками, ногами).
Re[17]: Каким отладчиком пользовались разработчики Kx System
От: heavyweapondude  
Дата: 20.07.09 10:30
Оценка:
Здравствуйте, FR, Вы писали:

...

Почти наверняка WinDbg + VMWare решат вопрос отладки
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.