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

VD>>>Вера в REPL тоже забавит.

M>> Это не вера, это практический опыт.

VD>Практический опыт бывает разный. То что для того же Хаскеля не могут 10 лет написать IDE — это тоже практический опыт.

M>> А вот не фиг раздельную компиляцию разводить. REPL очень удобен для быстрой интроспекции поведения непонятных кусков сколь угодно большого проекта.

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

Ты так часто говоришь об огромных проектах. Собственно, вопрос: какой был самый большой проект, над которым ты работал?

И еще раз повторюсь -- отладчик нужен, когда программа вообще делает что-то не то (т.е. произошел засер памяти или какие-нить таблицы виртуальных методов не совпали). И то, в основном он нужен, чтобы посмотреть backtrace от падения (или где что повисло). Засеры памяти вообще лучше отдельно находить (к тому же они свойственны в основном C/C++). Остаются редкие разовые запуски ().

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

Более того, наличие отладчика также плохо действует на мозг, как и IDE: "Зачем мне делать нормальные сообщения об ошибках, у мяж отладчик есть"; "Нафиг мне думать о логах и диагностике, нафиг мне использовать неубиваемые подходы, нахачу говнокода, а там отлажу. Ведь отладка -- 50% времени разработки, значит у меня все правильно"; "Нафиг мне разбираться с прогой, я ща ее отладчиком потыркаю, прилеплю костыль, а там будь что будет", и т.д.

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

Повторюсь. Я использовал отладчик очень длительное время. Потом перешел на кемл и как-то не смог сходу запустить его отладчик. Забил -- надо будет позже под линухом отлажу. Однако позже не наступило. Проект, практически без тестирования, был выпущен и за последующие несколько лет было обнаружено ДВЕ ошибки (одна в С++ части, вторая некритичная).

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

VD>Оптимально конечно иметь возможность править код прямо во время отлкадки и производить замену кода на уровне типов и функций. Чем это хуже РЕПЛа?

Тем, что эту ф-ию не запустишь отдельно от всего остального и не потестишь.

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

V>Ты так часто говоришь об огромных проектах. Собственно, вопрос: какой был самый большой проект, над которым ты работал?

Да, как-то мелкие довольно редко попадаются. 200 файлов — норма. Были проекты в которых было файлов по 10000 файлов. Полная перекомпиляция — 40 минут.

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

Вы просто не умеете его готовить (с)

V>Более того, наличие отладчика также плохо действует на мозг, как и IDE

А, ну, ясно. Это позиция из серии "хрен оспоришь".

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

T>Менее, чем на замеры производительности программистов ты не согласен?

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

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

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

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

Поэтому такой вот радикальный подход мне и не понятен.

T>Реализация возможностей приводит к фиксации чего-то.

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

T>Я минимизирую число изучаемых инструментов, выбрав наиболее мощный ЯП. Я максимизирую число используемых инструментов, используя произвольную сборку с Makefile (как пример).
T>К чему приводит твой призыв "автоматизировать надо всё!"?

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

K>>Это требует изучения ФВП. Но понятно, что изучение ФВП раскрывает гораздо (несоизмеримо) больше возможностей, чем изучение какого-нибудь генератора кода для Явы. Кроме того, это намного интереснее.
T>Ура!

Ура-то ура, но я веду к том, что, разумеется, нужно учитывать соотношение стоимость(обучения)/эффективность(использования). Это соотношение рассматривается в каждом конкретном случае и никакие обобщения вроде IDE — всегда зло в этой оценке помочь не могут.

T>От необходимости напрягать мозги вообще.

От необходимости напрягать мозги вообще автоматизация избавить не может.

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

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

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

FR>Модули из структурных языков и модули ML это разные вещи.

О, как? Обоснуй!

VD>>Монады никаким боком к декомпозиции не имеют.

FR>Понятно, значит все-таки не читал :(

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

VD>>Так что я не хочу понять, я не могу понять... о каких таких новых вещах идет речь.

FR>Ну нету в структурном программировании ни сигнатур, структур и функторов из модулей ML.

Это точно. В нем даже понятий таких нет. У тебя огромные проблемы с терминалогией.

FR>Нет алгебраических типов данных.

Естественно. Иди почитай определение словосочетания о котором ты пытаешься говорить.

VD>>Да, ну. Где можно про это почитать?

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

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

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

V>>Ты так часто говоришь об огромных проектах. Собственно, вопрос: какой был самый большой проект, над которым ты работал?

VD>Да, как-то мелкие довольно редко попадаются. 200 файлов — норма. Были проекты в которых было файлов по 10000 файлов. Полная перекомпиляция — 40 минут.

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

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

VD>Вы просто не умеете его готовить (с)

V>>Более того, наличие отладчика также плохо действует на мозг, как и IDE

VD>А, ну, ясно. Это позиция из серии "хрен оспоришь".

Я тебе предложил вариант поработать без отладчика. Поработаешь и оспаривать не понадобится.

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

V>Повторюсь. Я использовал отладчик очень длительное время. Потом перешел на кемл и как-то не смог сходу запустить его отладчик. Забил -- надо будет позже под линухом отлажу. Однако позже не наступило. Проект, практически без тестирования, был выпущен и за последующие несколько лет было обнаружено ДВЕ ошибки (одна в С++ части, вторая некритичная).

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

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

VD>>Оптимально конечно иметь возможность править код прямо во время отлкадки и производить замену кода на уровне типов и функций. Чем это хуже РЕПЛа?

V>Тем, что эту ф-ию не запустишь отдельно от всего остального и не потестишь.

У тебя уже запущено приложение. Правь исходники и тестируй дальше.

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

V>Вот и замечательно. А теперь расскажи, как тебе помог отладчик? Может я действительно не умею готовить. Мне твой рассказ может пригодиться, т.к. по долгу службы я сейчас как раз встраиваю в нашу IDE отладчик )))

По разному помогал. От изучения работы чужого кода, до понимания в чем не верны собственные предпосылки.
Скажем в той же интеграции есть два потока. Один GUI, другой тот где идет обработки исходников (компилятор писали люди с ФЯ-школой, что привело к тому что он получился однопоточный). Общение между ними идет сообщениями (через очередь заданий). Иногда один поток должен ждать другой. Точнее рабочий поток всегда ждет заданий, а второй иногда должен дожидаться окончания их обработки. Так как логика получается весма пушистая, то иногда происходили (надеюсь) "зависания". Воспроизвести это логами невозможно, так как в логе просто ничего нет. Остановка отладчиком дает четкий ответ — проблема в заимоблокировке, так как в одном потоке ожидание ввода, а в другом результата. Ошибка плевая — очередь приоритетная и более приоритетные задачи удаляют менее приоритетные, а те ожидали завершения. Но без отладчика невозможно понять что происходит.

Другой пример с той же интеграцией. Интеграция использует код MS. Там натуральная инудусятина. Но нужно разбираться как он работает и как обходить проблемы которые он создает. Переписывать все с нуля не реально — это много человеколет. В итоге наличие отладочной информации позволило залезть отладчиком в их код и понять его логику. То же с кодом компилятора.

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

V>Я тебе предложил вариант поработать без отладчика. Поработаешь и оспаривать не понадобится.

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

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

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

V>>Повторюсь. Я использовал отладчик очень длительное время. Потом перешел на кемл и как-то не смог сходу запустить его отладчик. Забил -- надо будет позже под линухом отлажу. Однако позже не наступило. Проект, практически без тестирования, был выпущен и за последующие несколько лет было обнаружено ДВЕ ошибки (одна в С++ части, вторая некритичная).

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

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

VD>Так же могу порадоваться за тот объем времени, что есть у тебя на отладку. Так как лепление логов отнимает не мало времени. Я тоже не против логов. Некоторые вещи только ими и можно выловить. Но у меня нет времени ждать минунами пересборки проекта только для того чтобы понять, что вот эту-то переменную я как раз и забыл влепить в лог.

Вот видишь. Проблема, опять таки, в языке (С++?). Haskell и ocaml компилятся шустро, минутами ждать пересборки не надо.

VD>>>Оптимально конечно иметь возможность править код прямо во время отлкадки и производить замену кода на уровне типов и функций. Чем это хуже РЕПЛа?

V>>Тем, что эту ф-ию не запустишь отдельно от всего остального и не потестишь.

VD>У тебя уже запущено приложение. Правь исходники и тестируй дальше.

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

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

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

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

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

Вот, что я нашёл:

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

Смотрим Пола Грехема:

Most people have learned to do a similar sort of filtering on new things they hear about. They don't even start paying attention until they've heard about something ten times. They're perfectly justified: the majority of hot new whatevers do turn out to be a waste of time, and eventually go away. By delaying learning VRML, I avoided having to learn it at all.

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

Как нет смысла изучать vim/emacs, поскольку они не везде есть (хотя и чаще, чем VS/Eclipse).

T>>Наличие среды означает, что есть некоторые вещи, которые язык плохо "автоматизирует".
T>>Иными словами, изучения языка недостаточно, чтобы быть максимально производительным.
T>>Иными словами, язык со средой может быть и лучше, но он хуже, чем язык, в котором я производителен без среды.
K>Вообще-то язык без среды — это такая книжка с описанием. Компилятор, интерпретатор — это уже среда.

Не соглашусь. Ты используешь расширительное толкование.

Это "среда выполнения", а не "среда разработки".

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

Да. И их использование должно быть минимальным или средства должны быть универсальными (make).

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

Среда нужна для её использования. Как раз именно для злоупотребления.

Самое простое: можно насоздавать кучу функций с типами A -> Bool, B -> Bool и тп, и передавать соответствующую, а можно сделать класс и использовать метод.

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

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

T>>Как только мне станет нужна среда программирования для Хаскеля, я начну искать другой язык программирования.
K>Поэтому такой вот радикальный подход мне и не понятен.

Так ты и не делаешь попыток понять.

Ты поспорить вышел, а не понять.

T>>Реализация возможностей приводит к фиксации чего-то.
K>Ну да, допустим, что реализация возможности закрывает путь для других возможностей. Но пример с мутабельной датой не особенно показателен. Фактически — они там сами кузнецы своего несчаться. Понятно, что от мутабельного класса для даты эм не отделаться и вечно придется таскать за собой для совместимости — но вполне можно было бы сделать новую версию стандартной библиотеки, в которой часть старых проблем была бы исправлена. В том же .NET есть два набора взаимозаменяемых, в общем-то, коллекций — старый и новый.
K>Ну так вот, предположение о том, что реализованные возможности перекрывают реализацию возможностей потенциальных я согласен считать верным. Но при этом, я утверждаю, что нет способа создания потенциальных возможностей, кроме реализации возможностей. Другого способа расширить пространство потенциальных возможностей нет. Да, неверный выбор может и сузить это пространство, но что тут поделать?

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

Например, не выбирать IDE. Выбирать то, что есть всюду.

T>>Я минимизирую число изучаемых инструментов, выбрав наиболее мощный ЯП. Я максимизирую число используемых инструментов, используя произвольную сборку с Makefile (как пример).
T>>К чему приводит твой призыв "автоматизировать надо всё!"?
K>Именно к этому. К минимизации числа изучаемых инструментов и максимизации числа инструментов, которые можно использовать. Впрочем, минимизация числа изучаемых инструментов — ни о чем не говорящий показатель. Минимизировать надо интегральную сложность освоения набора инструментов.

тогда наша позиция совпадает.

Наверное, можно завершить спор?

K>>>Это требует изучения ФВП. Но понятно, что изучение ФВП раскрывает гораздо (несоизмеримо) больше возможностей, чем изучение какого-нибудь генератора кода для Явы. Кроме того, это намного интереснее.
T>>Ура!
K>Ура-то ура, но я веду к том, что, разумеется, нужно учитывать соотношение стоимость(обучения)/эффективность(использования). Это соотношение рассматривается в каждом конкретном случае и никакие обобщения вроде IDE — всегда зло в этой оценке помочь не могут.

Это почему это не могут помочь?

Оценка может быть скалярной — длина, — и иерархической — длина и ширина. "По длине оба подходят, надо брать тот, что уже."

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

Более мощный язык всегда будет выигрывать у менее мощного в длительной перспективе.

Собственно, за этим языки и изобретаются: дать преимущества.

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

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

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

Полностью все возможности этой новой возможности будут определены к появлению ещё одной новой возможности в качестве technology preview. После определения возможностей возможно более-менее полноценно поддержать ту возможность, что мы получили до появления новой.

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

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

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

V>>Вот и замечательно. А теперь расскажи, как тебе помог отладчик? Может я действительно не умею готовить. Мне твой рассказ может пригодиться, т.к. по долгу службы я сейчас как раз встраиваю в нашу IDE отладчик )))

VD>По разному помогал. От изучения работы чужого кода, до понимания в чем не верны собственные предпосылки.
VD>Скажем в той же интеграции есть два потока. Один GUI, другой тот где идет обработки исходников (компилятор писали люди с ФЯ-школой, что привело к тому что он получился однопоточный). Общение между ними идет сообщениями (через очередь заданий). Иногда один поток должен ждать другой. Точнее рабочий поток всегда ждет заданий, а второй иногда должен дожидаться окончания их обработки. Так как логика получается весма пушистая, то иногда происходили (надеюсь) "зависания". Воспроизвести это логами невозможно, так как в логе просто ничего нет. Остановка отладчиком дает четкий ответ — проблема в заимоблокировке, так как в одном потоке ожидание ввода, а в другом результата. Ошибка плевая — очередь приоритетная и более приоритетные задачи удаляют менее приоритетные, а те ожидали завершения. Но без отладчика невозможно понять что происходит.

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

Буквально недавно интегрировал систему симуляции в нашу IDE. Тоже идет в отдельном процессе фоном. При этом там не просто очередь заданий, а достаточно тесной взаимодействие (т.к. есть пошаговая отладка). И что, подумал, написал. Заняло 500 строк на хаскеле с документацией, тестами и обработкой всевозможных ошибок. В нескольких местах были логи. Заработало почти сразу. А был бы отладчик налепил бы говнокода и шагал, думал, где-же не пашет.

VD>Другой пример с той же интеграцией. Интеграция использует код MS. Там натуральная инудусятина. Но нужно разбираться как он работает и как обходить проблемы которые он создает. Переписывать все с нуля не реально — это много человеколет. В итоге наличие отладочной информации позволило залезть отладчиком в их код и понять его логику. То же с кодом компилятора.

А это говнокод, о котором уже писали.

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

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

V>>Я тебе предложил вариант поработать без отладчика. Поработаешь и оспаривать не понадобится.

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

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

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

А почему ты думаешь, что от этого страдают? Ты, в целом, прав — мы действительно создаём себе удобное окружение, но, чёрт побери почему, ты считаешь что оно для нас менее удобно? К виму, я действительно пришёл не от хорошей жизни: необходимо собирать код на удалённом компе и соединиться с ним можно по telnet и ssh. Вот только вчера видел как человек работал с этим кодом с помощью Эклипса, и для себя я понял что с навигацией по tag-ам я бы быстрее нашёл нужное место, чем этот человек со всплывающими типами и автокомплитом.

Короче, почему ты считаешь что собранное вручную окружение будет хуже чем IDE типа эклипса или студии?

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

VD> И тут без рефакторинга не обойтись. А рефактринг — это как раз та самая рутина которую (по уму) нужно автоматизировать.

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

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

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

FR>>Модули из структурных языков и модули ML это разные вещи.

VD>О, как? Обоснуй!

В структурном программировании модуль средство инкапсуляции плюс средство разделения кода на независимые части.
Модуль ML кроме этого добавляет:

Модули ML могут быть вложенными. В единице трансляции могут содержатся несколько модулей.

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

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

Еще большую обобщенность добавляют функторы, то есть функции над структурами позволяющие связывать и параметризовать структуры другими структурами, например тут http://caml.inria.fr/pub/docs/manual-ocaml/manual004.html#htoc15 показан пример где задается сигнатура для упорядоченного типа, и этой сигнатурой параметризируются тип Set. Результат вполне аналогичен например обобщенному программированию с помощью шаблонов в C++.

FR>>Ну нету в структурном программировании ни сигнатур, структур и функторов из модулей ML.

VD>Это точно. В нем даже понятий таких нет. У тебя огромные проблемы с терминалогией.

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

FR>>Нет алгебраических типов данных.

VD>Естественно. Иди почитай определение словосочетания о котором ты пытаешься говорить.

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

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

Угу только почему-то ФЯ программы реально абсолютно ничего общего со структурными не имеют.

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

DC>Короче, почему ты считаешь что собранное вручную окружение будет хуже чем IDE типа эклипса или студии?

Я так не считаю, но вижу это в некоторых из рассказов. Как только начинается рассказ про то что "это все баловство" так сразу вижу, что это от-того, что этого нет.

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

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

VD>Здравствуйте, dr.Chaos, Вы писали:

DC>>Короче, почему ты считаешь что собранное вручную окружение будет хуже чем IDE типа эклипса или студии?

VD>Я так не считаю, но вижу это в некоторых из рассказов. Как только начинается рассказ про то что "это все баловство" так сразу вижу, что это от-того, что этого нет.

Да вроде, тебе привели аналоги тех возможностей что ты называл.

VD>Кроме того есть еще три аспекта — интеграция, качество, доступность. Все они хромают при таком подходе. Особенно последнее. Ведь всю эту байду не получишь в одном флаконе. Да и шорткатам учиться придется долго. Лично я так и не смог освоить Emacs хотя пару раз пробовал. Думаю, я не единственный кто не смог его освоить.

Есть такая присказка: "Если бы люди умели пользоваться vim, grep, sed, awk, то миллионы программных продуктов так никогда и не были бы созданы.". Это более универсальные инструменты, но с ними можно работать не менее эффективно чем с IDE.

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

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

dmz>>А что касается Хаскелла, то программировать на нем в бессознательном состоянии невозможно.

Зависит.

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

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

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

VD>Кстати интереснейший вопрос для обсуждения. Но философски, так что ему место в другом форуме.

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

VD>И я вот не пойму кто прав они или мы (я ведь тоже грешен, язык ставлю выше)?

Правы все... или не правы все ... кому как угодно.

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

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

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

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

А что рефактроить без среды проще что ли?
А разбираться в коде?

Чем круче джип, тем дольше бежать за трактором (с)

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

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

Потом на поздних этапах цели проекта могут измениться. Хороший пример тот же немерловый компилятор. Его писали как компилятор командной строки. Причем с целью как можно быстрее получить что-то работающее. Когда компилятор был почти в бэте вдруг выяснилось, что для создания IDE компилятор нужно было писать совсем иначе. Многое нужно делать более детально, а много вообще по другому. Лично ты надорвал пуп когда попытался этот проект отрефакторить. Списав все на кривые руки предшественников ты предложил его переписать с нуля. А я вот мучился изучая проект и рефакторя все это дело вручную. Была бы IDE способная поднять этот проект и автоматизировать рефакториг, я бы давно закончил.

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

DC>Простые рефакторинги, т.е. те что можно автоматизировать, они и так делаются очень быстро, а сложные и объёмные автоматизации не поддаются. Мало того ИМХО рефаторинг это довольно творческое занятие, потому что рефакторинг делают вкупе либо с внесением новых фич, либо с правкой багов, а сам по себе он не нужен.

Это заблуждение.

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

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

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

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

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