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

VE>Мне помогает REPL, и отсутствие оного в C++/C#/F# очень напрягает.

В F# REPL имеется, и в студии неплохо поддержан.

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

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

а какая инфа о типах, отсутствующая в исходниках, тебе постоянно бывает нужна?

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

ну, иерархия каталогов в ос и подчастей в проекте ничем не отличаются

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

и на какую кнопку у тебя это повешено?

VD>Это возможность быстро, без ошибочно и просто менять проект (делать сложный рефакторинг).

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

VD>Это возможность не лазить в хэлп по каждому поводу.

ещё один весьма конкретный аргумент

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

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

VD>Ни конечно же отладка...

с этим согласен. использовать printf скучно. правда и то, что использование хаскела даёт на порядок меньше поводов для отладки, чем низкоуровневое С-программирование.

VD>Лучше расскажи как же люди умудряются жить без IDE и при этом иметь достойную производительность труда?
VD>И часть про волшебные свойства ФП можно пропустить, так как не ФЯ тут даже не рассматриваются.

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

как я работаю в фаре: отладка, как уже говорил, printf'ами. вместо автокомплита копирую имена переменных/функций или набираю их сам (имена из станд. библиотек и моих собственные мелких хелперов невелики по размеру, это тебе не system.console.writeln ). если мне нужно найти определение какой-то функции, то использую поиск по файлам. для хелпа по сишным функциям использую google

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

VD>Я вот иногда вынужден писать оноситльно большие куски кода без IDE (в расширенном смысле этого слова) и испытываю дикий дискомфорт. То что я мог бы сделать за 5 минут в IDE требует десятков минут, а то и часов когда делаешь это "вручную".
VD>Дико интересно как народ умудряется без этого всего обходиться. Причем не заявления, а именно рассказ...

ага. дико интересно было бы услышать аналогичный рассказ от тебя. что ты такое регулярно делаешь, что требует часов без ide?

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

DR>Уже есть? Это большой плюс.

Я бы сказал уже (пока) нет.
Они были уже пол года. Сейчас я произвожу глубокий рефактринг проекта и временно они не доступны. Но в CTP они есть.

DR>Интересно, какие возможности рефакторинга реализованы?

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

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

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

DR>>Интересно, какие возможности рефакторинга реализованы?

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

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

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

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

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

BZ>а какая инфа о типах, отсутствующая в исходниках, тебе постоянно бывает нужна?

Это в языках с выводом типа?
У меня ощущение, что я с кем-то другим разговариваю.

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

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

BZ>ну, иерархия каталогов в ос и подчастей в проекте ничем не отличаются

О... Решение, супер! Для тех кто никогда не видел больших проектов. Ести твой проект большой, то чтобы найти в нем нужный каталог и файл, нужно потратить десятки минут.
Предположим, что ты не подходил к проекту в течении полугода. Или это не твой проект. Что будешь делать?

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

BZ>и на какую кнопку у тебя это повешено?

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

VD>>Это возможность быстро, без ошибочно и просто менять проект (делать сложный рефакторинг).

BZ>можно примеры рефакторинга, которые сложно делать вручную?

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

VD>>Это возможность не лазить в хэлп по каждому поводу.

BZ>ещё один весьма конкретный аргумент

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

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

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

То есть ты не сталкивался в С++ с перегрузкой, виртуальными методами, include-ами, метапрограммированием на шблокнах?
Или у тебя список типов ограничен двумя десятками?

VD>>Ни конечно же отладка...

BZ>с этим согласен. использовать printf скучно. правда и то, что использование хаскела даёт на порядок меньше поводов для отладки, чем низкоуровневое С-программирование.

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

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

VD>>Лучше расскажи как же люди умудряются жить без IDE и при этом иметь достойную производительность труда?
VD>>И часть про волшебные свойства ФП можно пропустить, так как не ФЯ тут даже не рассматриваются.

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

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

BZ>как я работаю в фаре: отладка, как уже говорил, printf'ами. вместо автокомплита копирую имена переменных/функций или набираю их сам (имена из станд. библиотек и моих собственные мелких хелперов невелики по размеру, это тебе не system.console.writeln ).

Ты помнишь наизусть все имена из всех библиотек которые используешь?
Если нет, то поиск и копирование должны занимать не малое время. Неуже ли не было бы удобнее просто набрать пару букв и нажать ctrl+space?

BZ>если мне нужно найти определение какой-то функции, то использую поиск по файлам. для хелпа по сишным функциям использую google

Опять же, а сколько времени нужно чтобв найти фукнкцию имя которйо точно не известно?

ЗЫ

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

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

BZ>ага. дико интересно было бы услышать аналогичный рассказ от тебя. что ты такое регулярно делаешь, что требует часов без ide?

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

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

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

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

BZ>а ты попробуй прикинуть — часто ли тебе приходится делать нетривиальные переименования (те, которые нельзя сделать текстовой заменой)?

Мне часто. И я очень страдаю, что рефакторинг не доступен для кода компилятора.

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

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

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

Основная среда разработки: Emacs.

Автодополнение: мне хватает стандартного M-/ (дополняет по словам в открытых файлах). Есть и более навороченные, но как-то не надо.

Отладка: в ghci есть встроенный отладчик, только я его не видел ни разу, ибо нафиг не нужен. Поскольку практически каждая функция может быть вызвана отдельно (в REPL-е) и занимает несколько строчек — даже как-то стрёмно что-то отлаживать. Иногда пользую Debug.Trace.

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

Рефакторинг: в хаскеле крайне редко нужно что-то переписать. Как правило, оказывается удобнее дописать.

Каждый модуль, как правило, перезагружается в REPL постоянно, по нескольку раз на каждую функцию (причём все недописанные места заменяются на undefined). Поэтому идёт постоянный контроль правильности типов. Если где-то типы не сошлись — это исправляется за несколько секунд.

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

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

VD>То есть ты не сталкивался в С++ с перегрузкой, виртуальными методами, include-ами, метапрограммированием на шблокнах?

Странный вывод.

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

VD>Не вижу. У меня складывается другое впечатление, ... что когда чего-то нет, многим очень хочется делать вид, что оно и нужно вовсе.
Спешу разочаровать — неверное впечатление. Отладчик у GHC есть, но я как об этом случайно узнал год назад, так на него ни разу и не взглянул. Слово "случайно" здесь то же неспроста, т.е. я не искал этой возможности, хотя, само собой, про отладчики был в курсе.
И это не редкость.

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

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

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

я просто не понял тебя. мне показалось, что речь идёт об известном тебе типе, о котором после компиляции появляются некие ценные сведения (типа sizeof ). значит, на самом деле речь идёт о том, что тебе нужны типы самих автовыведенных переменных. согласен, несовпадение типов — это собственно основной тип ошибок, обнаруживаемых компилятором. т.е. типичный цикл нетривиального изменения у меня выглядит так: кодируешь-кодируешь, затем пытаешься откомпилять. и начинается — вставка импортов, редактирование идентификаторов, где-то ты используешь string как char и тому подобное ремесленничество. но я повторю вопрос Шабанова: что у тебя занимает больше времени — описание алгоритма, или исправление ошибок на невнимательность? если второе (что следует из того, что ide в несколько раз ускоряет твою работу), то значит ты занимаешься какой-то monkey work.

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

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


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

BZ>>ну, иерархия каталогов в ос и подчастей в проекте ничем не отличаются

VD>О... Решение, супер! Для тех кто никогда не видел больших проектов. Ести твой проект большой, то чтобы найти в нем нужный каталог и файл, нужно потратить десятки минут.
VD>Предположим, что ты не подходил к проекту в течении полугода. Или это не твой проект. Что будешь делать?

честно говоря, не понимаю, в чём разница между проектом в ide и проектом как иерархией каталогов. что тебе проще найти в ide, чем в файлах?

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

BZ>>и на какую кнопку у тебя это повешено?

VD>Ощущение, что общаешься с неандертальцем.
VD>Ошибки подчеркиваются сразу при вводе. Не все конечно, но это позволяет не тратить часов компилируя проекты и исправляя ошибки налепленные за 5 минут слепой печати.

так и есть. я не пользовался ide с подчёркиванием ошибок зато была одна, вообще не выпускавшая с ошибочной строки только эээ, во-первых ты сразу пишешь безошибочный код? это опять-таки признак monkey work — т.е. код так прост, что его можно писать напрямую. сложный код, как я уже говорил, проходит несколько этапов последовательных приближений от размытой идеи к точному определению. второе — неясно какие типы ошибок обнаруживаются без компиляции, тем более в применении к хаскелу. третье — если у вас часами идёт *инкрементальная* компиляция проекта (а не full rebuild), то подавайте заявку в книгу Гиннеса

VD>>>Это возможность быстро, без ошибочно и просто менять проект (делать сложный рефакторинг).

BZ>>можно примеры рефакторинга, которые сложно делать вручную?

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

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

VD>>>Это возможность не лазить в хэлп по каждому поводу.

BZ>>ещё один весьма конкретный аргумент

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

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

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

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

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

VD>То есть ты не сталкивался в С++ с перегрузкой, виртуальными методами, include-ами, метапрограммированием на шблокнах?
VD>Или у тебя список типов ограничен двумя десятками?

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

VD>>>Ни конечно же отладка...

BZ>>с этим согласен. использовать printf скучно. правда и то, что использование хаскела даёт на порядок меньше поводов для отладки, чем низкоуровневое С-программирование.

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

— ну а вы как снимаете напряжение?
— ВОДКА

printf'ом и пользуюсь, для С тоже

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

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

VD>>>Лучше расскажи как же люди умудряются жить без IDE и при этом иметь достойную производительность труда?
VD>>>И часть про волшебные свойства ФП можно пропустить, так как не ФЯ тут даже не рассматриваются.

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

VD>Не вижу. У меня складывается другое впечатление, ... что когда чего-то нет, многим очень хочется делать вид, что оно и нужно вовсе.

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

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

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


BZ>>как я работаю в фаре: отладка, как уже говорил, printf'ами. вместо автокомплита копирую имена переменных/функций или набираю их сам (имена из станд. библиотек и моих собственные мелких хелперов невелики по размеру, это тебе не system.console.writeln ).

VD>Ты помнишь наизусть все имена из всех библиотек которые используешь?

ну наверно в 98% случаев короткие имена я помню. а для длинных переключаюсь туда где они есть и копирую

VD>Если нет, то поиск и копирование должны занимать не малое время. Неуже ли не было бы удобнее просто набрать пару букв и нажать ctrl+space?

да проще конечно. никто не говорит, что отсутствие ide во всём упрощает работу. но я думаю, что оно не настолько усложняет работу. за исключением отладчика это имхо всего лишь несколько процентов лишнего времени, причём самое основное — это переход к месту ошибки: перейти в нужный модуль (alt-f11 и несколько букв из его имени) и нужную строку (alt-f8 и номер строки). т.е. тоже не особо сложно, но это делается чаще всего. ну и всё остальное так же. поиск нужной мне функции и копирование её имени в прогу — это пара десятков keystrokes

BZ>>если мне нужно найти определение какой-то функции, то использую поиск по файлам. для хелпа по сишным функциям использую google

VD>Опять же, а сколько времени нужно чтобв найти фукнкцию имя которйо точно не известно?

а что о ней известно? имя модуля — смотришь какие функции в нём определены (это для хаскела, благо что у меня под рукой исходники его stdlib)


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

во-первых, таких задач на хаскеле никто наверно и не писал. самый большой проект, который я знаю — ghc — это несколько сот kloc и 20 лет работы одного человека плюс 10 другого, причём они вряд ли особо разбираются в коде друг дурга (один делает front-end, другой back-end)

вт-вторых, для того чтобы не лезть в чужой код, есть методология. хаскел может помочь её соблюдать, предоставляя каналы, неизменяемые переменные, те же монады, между прочим, пользы от которых ты никак не можешь понять. ну а в-третьих я с тобой согласен — чем больший у вас codebase и объём использования библиотек, тем больше времени ты не своё пишешь, а разбираешься с чужим. но разве это интересно?

c#, vs, enterprise — это всё такие mark of devils занудной, нетворческой работы. потому люди и уходят туда, где больше творчества, а меньше разборок с третьим слоем пятого компонента

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

BZ>>ага. дико интересно было бы услышать аналогичный рассказ от тебя. что ты такое регулярно делаешь, что требует часов без ide?

VD>Представь себе. Куча кода написанного в разное время разными людьми и имеющего совершенно разное качество.

да, насчёт говнокода я попал в самую тютельку

Здравствуйте, BulatZiganshin, Вы писали: (много)

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

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

По любому, спасибо за то, что не ответил в стиле "а мне не надо"!

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

У меня был опыт работы в таком проекте. На C++ образца 1994 года. Около 1Gb исходников, ноль документации, получен от третьей конторы. Поддерживался
и разрабатывался командой в 10 человек. Вопрос IDE каждый решал для себя сам, с переменных успехом. Я после нескольких итераций остановился на vim, и ни в чем обделен не был. Всякие типа вещи классброузеров, тэгов и прочая для C++ к виму можно прикрутить, я поначалу пользовался, потом забил.

Для массовых операций с исходниками использовал перл.

VD>Никакой Хаскель на сделает, так чтобы любая задача могла легко уместиться в голове. А без этого метды "копируем функцию" просто не будут работать.

Задача, которая является большой на C++, на хаскелле может быть совсем небольшой.

У нас в команде используется Erlang, OCaml, Javascript, C, Beep --- и как-то все обходятся без IDE, жалоб не поступает. Опять же, непонятно как быть с IDE, если используешь несколько языков. Мало какие IDE достойно поддерживают несколько языков, и как быть? Для каждого языка --- привыкать к своей IDE? Мозг жалко, в т.ч. спинной. А как быть, если используются разные системы сборки? scons, cmake или какая-нибудь вообще своя? Прогибать весь проект под IDE, используя только те средства, которые они поддерживают?

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

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

Если идёт обработка больших массивов данных (видео, например), то отладчик только мешает. Логи, логи, логи. Да и структуры данных в таком случае низкоуровневые и интуитивно понятные. Подсветки синтаксиса достаточно.

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

VD>>Представь себе. Куча кода написанного в разное время разными людьми и имеющего совершенно разное качество.

BZ>да, насчёт говнокода я попал в самую тютельку

Ой вей, я вас прОсю.
Представь себе что Хаскел двинул в массы. Ну лет через 15 к примеру. Народ к тому времени будет учить его по книгам Хаскел за 24 часа для чайников.
А где мозгов и книги для чайников не хватит будут юзать performUnsafeIO или как его там. И будут либы написанные такими программистами. Бангалорскими. И во всем этом придется кому-то разбираться. К примеру юноше со взором горящим. Который еще молод и ему не дадут написать свою версию бангалорской библиотеки с гейшами и го. А гуры будут все говорить что ИДЕ оно ненужно. А молодежь будет охреневать. И невдомек ей будет что задачи стоящие перед ними и перед гурами разные. Кому-то писать прототип сложноалгоритмичной мегафичи. А кому-то поддерживать код в который превратилась мегфича после реализации доблестными бангалорцами. И молодешь будет плакать и жрать кактус, а гуры вести просранные разговоры о теплом ламповом звуке(С) аскетичных редакторов. И то что современные ИДЕ высокие частоты не тянут. Иващеблин.

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

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

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

N>Если идёт обработка больших массивов данных (видео, например), то отладчик только мешает. Логи, логи, логи. Да и структуры данных в таком случае низкоуровневые и интуитивно понятные. Подсветки синтаксиса достаточно.

Ага. А если мы пишем "Дарова, мир!", то нам вообще ничего не нужно.
Это — не аргумент.

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

M>Бангалорскими. И во всем этом придется кому-то разбираться. К примеру юноше со взором горящим. Который еще молод и ему не дадут написать свою версию M>бангалорской библиотеки с гейшами и го. А гуры будут все говорить что ИДЕ оно ненужно. А молодежь будет охреневать. И невдомек ей будет что задачи M>стоящие перед ними и перед гурами разные. Кому-то писать прототип сложноалгоритмичной мегафичи. А кому-то поддерживать код в который превратилась M>мегфича после реализации доблестными бангалорцами.

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

А что касается Хаскелла, то программировать на нем в бессознательном состоянии невозможно. Это, наверное, его плюс, но
это и причина, по которой он никогда не станет мейнстримом.

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

dmz>У меня был опыт работы в таком проекте. На C++ образца 1994 года. Около 1Gb исходников, ноль документации, получен от третьей конторы. ... после нескольких итераций остановился на vim...

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

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

VD>Ага. А если мы пишем "Дарова, мир!", то нам вообще ничего не нужно.
VD>Это — не аргумент.

Почему же не аргумент? При включённых и отключённых оптимизациях (и прочих дебаг-опциях) скорость обработки одного кадра может различаться в сотни, а то и тысячи раз. Посчитай, во сколько замедляется процесс отладки.
Логи — это не только текст. Это также изображения, куски видео, 2D и 3D графики, диаграммы. Не всё так просто в этом мире.

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

Нет, лучше выбрать современный компилятор С++ (от Интела подойдёт), ручной ассемблер он, как правило, обгоняет. Сейчас, вот, CUDA рассматриваю. Но и в этом случае ассемблер не применяется.
Для сложных же фильтров просто выходит больше логов: сохраняются промежуточные результаты (то есть изображения) на каждом этапе обработки. Чем тут поможет отладчик? В шестнадцатеричном виде кусок памяти не так информативен.