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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

Типа того.

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

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

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

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

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

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

Но иногда!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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