Re[2]: Жизнь без IDE
От: vshabanov http://vshabanov-ru.blogspot.com
Дата: 28.09.09 17:44
Оценка: 67 (6)
Здравствуйте, VladD2, Вы писали:

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


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


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


Информация о типах/ф-ях получается из документации и/или из просмотра сорцов. Плюс команда :t в ghci (или C-c C-t в emacs).

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

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

Кода пишется обычно немного, у меня получается в среднем килострока (с комментариями и пустами строками) хаскеля/окемла в месяц. Т.е. 50 строк в день. Это отлаженного кода в конечном продукте. Реально пишется/меняется строк 150. В общем, чтобы поправить 150 строк никакого IDE по-моему не нужно.

Т.е. IDE в целом -- экономия на спичках. Кода редактируется мало, доки читать все равно надо. Зачем мне автокомплит ф-ии, если я не знаю, что она делает? А если ф-ия уже используется, то есть emacs-овый автокомплит по используемым в тексте словам.

И о недостатках IDE.

IDE -- интегрированная среда, где отдельные элементы обычно выбираются разработчиком, а не пользователем. По-этому IDE в принципе никогда не будут устраивать всех пользователей. Например, еще когда я пользовался IDE (VC++, C++Builder), я пользовался ими только для рисования формочек и отладки, редакторы у них были отстойными.

(Кстати, emacs&linux получились удачными именно благодаря тому, что интеграция отдана на откуп пользователю. Да и вообще, большинство удобных "IDE" люди собирают себе сами: у кого FAR с плагинами, у кого vim, у кого emacs, а кто и в блокноте всех сделает).

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

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

IDE разные -- я пишу и на Haskell, и на Java, и на C++, также экспериментирую со всякими Coq, Agda, иногда редактирую sh, Makefile, python. Работаю под линуксом, виндой, в удаленном терминале. Нахрена мне столько IDE? Одно только переключение между ними сожрет больше времени, чем любой даваемый ими прирост. Я, кстати, даже по тырнету хожу conkeror-ом -- emacs-оподобным браузером, чтобы не учить отдельные keystrokes (да и мышкой не пользоваться тоже).

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

IDE часто имеют свой менеджер проектов. Хоть как-то его настроить под свои нужды уже подвиг. Запустить сборку проекта с консоли тоже тяжко. Т.е. использование IDE мало того, что менее удобно, так еще оно и привязывает к этой IDE (что очень неудобно для людей, этой IDE не пользующихся). Из-за этого привязывания (типичный one microsoft way подход к софту) получается сковывание мозгов -- люди не могут даже понять, как же вообще можно жить без IDE.

У меня, кстати, даже рабочего стола с иконками нет -- тайлящийся оконный менедер сильно удобнее, и midnight commander-ом я пользуюсь редко -- cd с автокомплитом работает быстрее, чем долбить вверх/вниз/энтер как обезьянка.

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

Кстати настроенный emacs + linux + нормальный оконный менеджер -- это более чем IDE. Нет только отладки, class browser-а и автокомплита по коду (просто по словам есть). Отладка не нужна, вместо class browser-а просто ходим по файлам (и переключаемся между буферами инкрементальным поиском), для автокомплита по ф-иям достаточно открыть модуль с этими ф-иями, а для библиотек все равно надо в доку лезть.

Но, опять же, я не думаю, что если бы я писал в виндовом блокноте, то моя производительность уменьшилась бы в разы. Так процентов на 10-20 максимум (и то, из-за автокомплита в основном, т.к. я медленно печатаю). Для сравнения, на хаскеле я решаю задачи в среднем раза в 2 быстрее, чем на С++, а если правильно выбирать способ решения задачи, то можно вообще получить огромную разницу. Т.е. есть более мощные способы увеличить производительность, чем спички-IDE.

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

VD>Мне периодически приходится писать писать код без поддержки IDE. Не скажу, что это очень трудно. Но определенный дискомфорт испытываю. Помогает отладчик. Когда в отладчике видишь структуру данных, то конечно проще написать несколько строк кода, но потом без многократных итераций "компиляция <-> правка" не обходится. Если же код пишется в IDE, то компиляция в большинстве случаев проходит с первого раза, да и отладка требуется реже.

VD>Недавно переписывал части кода в интеграции немерла и был момент когда в IDE не было части функций. Например, не работали хинты к методам. При этом можно было бы смотреть типы выражений (в том числе и типов... то что тут назвали "мегафичей"), но вот списка перегрузок (описания параметров для каждой из перегрузок) получить было нельзя. Так вот даже это уже замедлило работу в несколько раз, так как пришлось лазить и выяснять описания типов для каждого метода. Эта проблема не так актуальна в языках основанных на алгоритме хиндли-миллера, так так полноценной перегрузки в них нет (не считая расширений вроде классов типов), но все же и в них приходится лазить по модулям и выяснять описания функций. А это время и нервы которые лучше потратить на разработку и отладку алгоритмов.
VD>Когда я слышу про отладку... что мол она не нужна, то тоже как-то смешно становится. Мне не понятно как можно разбираться с чужим, объемистым, кодом в условиях когда нет ни отладчика, ни даже полной информации о типах. Ну, а в таких языках как Haskell и F# где есть или намеки на перегрузку (классы типов) или почти полноценная перегрузка (как F#) отладка, на мой взгляд вообще необходима.

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

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

А про перегрузку я вообще не понял, чем она мешает?
Re[10]: Жизнь без IDE
От: maxkar  
Дата: 03.10.09 14:35
Оценка: 56 (5)
Здравствуйте, dr.Chaos, Вы писали:

DC>Ну тут, видимо, опять вопрос в терминологии. Рефакторинг делается перед внесением фичи чтобы облегчить этот процесс. И основной стимул, тут не отсутствие средств (хотя что бы вы знали про vim, sed и awk ), а то что просто переписывание кода — это переливание из пустого в порожнее, т.к. код в итоге будет иметь «идеальную» архитектуру, а заказчик 0 новых функции и столько же багов. Мало того, потом окажется, что архитектура то не идеально и т.п. Основная цель рефаторингов изменить код так, чтоб его было проще менять под текущие и ближайшие цели, т.е. где-то добавить гибкости, где то убавить овердизайна. Ну и что касается твоего поинта: «большие рефакторинги состоят из кучи маленьких», — да, состоят, но по моему опыту занимают они не много времени ( может я их просто не замечаю благодаря «убогим» vim, sed, awk ).


А можно ваше определение рефакторинга? Это то, что "делается перед внесением фичи, чтобы облегчить этот процесс"?. Просто если использовать, например, определение из wiki (которое более широкое, чем ваше), у меня получается, что как раз таки большая часть рефакторингов делается не перед внесением фичи а во время или сразу после внесения фичи, после изменения кода. Я в дальнейшем буду использовать термин "рефакторинг" для обозначения "изменения программы без изменения ее фунциональности (или внешнего поведения) с целью улучшения ее качества" (вольный перевод wiki). Если вас не устраивает — готов использовать другое название, только предложите Именно для того определения, которое я привел. Потому что такая активность существует и хочется как-то ее называть.

Все нижеследующее из моего опыта. Основное время пишу на Java, но какие-то вещи (в основном — утилиты разные) пишу на Ocaml. И на том и на другом могу писать как в vim'е, так и в IDE (eclipse JDT и OcaIDE). И всякие мелочи на одну-две сотни строк (эксперименты, примеры и т.п.) пишу именно в vim'e. Могу даже и в notepad'е, но просто неудобно по сравнению с vim'ом. Недавно еще баловался с FlashDevelop. Все это к чему — большая часть привычек выработана в eclipse IDE и я хорошо замечаю, когда мне некоторых функций (рефакторингов!) не хватает в других случаях.

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

1. "Extract variable". Основное применение — когда части какого-либо сложного выражения хочется дать "человекочитаемое" имя. Для ocaml'а это было бы что-то вроде изменения кода f (f1 + f2 * f3) на let meaningfullName = f2 * f3 in f (f1 + meaningfullName). Вторая польза от такого рефакторинга встречается реже, но все же есть. Она проявляется, если в коде есть две похожие формулы. В этом случае после вынесения двух "переменных" для каждой из формул при чтении будет понятно, какая из двух имелась в виду. Необходимость заводить переменную для части формулы "сразу" не очевидна. Возможно, я формулу беру из ТЗ, составленного экспертами (т.е. на предварительных этапах мне достаточно знать, что формула реализуема в требуемом контексте). Либо изначально была простая формула, после чего к ней дописали одну "фичу", затем вторую и третью. После третьей фичи при взгляде на код стало понятно, что "что-то здесь не так", с одного беглого взгляда получившееся выражение не читается и неплохо было бы его разбить на читаемые части. Причем, как ни странно, делать это нужно сейчас — пока я еще помню, какой смысл несет какая часть формулы. Когда следующий раз придется менять это место, я могу и не вспомнить, что же там было. Придется разбирать формулу, пытаться понять ее значение. Возможно — смотреть ТЗ, справочники и т.п. По месту же — несколько раз "expand selection" + комбинация клавиш. По времени — копейки, дальнейшая экономия может быть вполне заметной. Да и по времени все это сравнимо будет с теми копейками, которые я потрачу на ручное вынесение переменной Так вот, в OcaIDE уже была ситуация, где при наличии автоматических инструментов я бы сделал такой рефакторинг (там два или три раза одно и то же выражение встретилось), только вот нету его. И, что интересно, года за 2, которые я применяю этот рефакторинг, его семантика всегда была "назвать выражение". На java это была final-переменная (галочка ставилась при первом применении рефакторинга и больше никогда не снималась). Т.е. именно "название" для чего-либо, а не "ячейка для хранения данных". В общем, типичная "переменная" из функциональных языков и иммено в такой семантике я и хотел рефакторинг для ocaml'а. Да, еще вспомнил применение — отладочная печать значения подвыражения. Очень естественно делается выделением переменной и добавлением инструкции печати.

2. "Introduce constant". Примерно то же, что первое. Только не для выражения, а для "магического числа". Также отличается тем, где заводится эта константа (для ocaml'а я бы ожидал константу на уровне модуля). Руками делается элементарно, но это нужно сначала сходить в ту область модуля, где лежат все консатны, написать там что-то, затем вернуться обратно. А так — в процессе кодирования пишется "магическое число", из которого затем заводится константа. Называть будем уже сразу по месту. Я, правда, еще хожу в объявление писать документацию (ага, ко всему), но если без этого — некоторый выигрыш. Сам по себе рефакторинг вроде бы несложный и выигрыш незаметный, но запомнился мне потому, что оказался удобен (при работе с протоколами байтовыми) и в то же время был повешен на hotkey. Еще раз повторю — основное применение — "назвать константу".

3. "Extract method". Ну, в общем, опять разновидность первого Только имя хочется дать уже не выражению, а формуле с параметрами. Учитывая вопросы с тем, чем должны быть использованные переменные — частью замыкания или параметрами, сразу скажу, что по умолчанию достаточно было бы их все делать параметрами с возможностью изменить на замыкание в диалоге. Опять же, функция для извлечения может появляться либо при написании из ТЗ, либо в результате эволюции. Для ocaml'а такой рефакторинг бы применялся, например, в случаях let a = if somecond1 then if somecond2 then value1 else value2 else if somecond3 then if somecond4 then value3 else value4 как части более сложной конструкции (другой функции, например). Достаточно большая часть вынесения методов на java у меня приходится именно на такой случай — заводим переменную и в зависимости от разных условий ее инициализируем. Да, выглядит по-другому, суть примерно та же. Есть еще часть случаев, когда идет императивщина (но в ocaml'е я тоже ее могу сделать), но и без нее достаточно случаев применимости. В ocaml'е сам видел ситуацию, когда такой рефакторинг помог бы. Причем родилось такое место в результате исправления ошибок. Сначала было два места, в которых делались похожие "элементарные" вещи. Что-то вроде "a + b", которые выносить в метод вроде бы было неоправданно. После пробных запусков я понял, что у меня логическая ошибка и нужно бы подправить код. Оказалось, что похожая ошибка была и во втором месте. На этом дело не закончилось, нашлась еще одна логическая ошибка. Итого — в двух местах "на ровном месте" у меня вырос патч двух логических ошибок. Сам по себе он было нормален, но появлялось дублирование да и исходные функции становились уже великоваты. Был бы удобный инструмент для рефакторинга — было бы совсем хорошо. А так — не было, но и код мне нужен был на один раз, поэтому все так и осталось жить. Итого — на самом деле у нас рефакторинг "назвать функцию или кусок кода человеческим именем", чтобы не приходилось "компилировать" этот код в его семантику.

4. "Rename something". Имя говорит само за себя. Используется, когда становится ясно, что имя неточно отражает значение, например. Опять же, образоваться имя может разными способами. Например, в результате дописывания фич, когда каждое изменение меняет семантику совсем чуть-чуть, но в результате значение переменной уже сильно отличается от ее названия. Еще один случай — когда оказывается, что методы в одинаковых ситуациях называются немного по-разному. Прекрасно ловится на этапе кодирования и там же прекрасно все переименовывается (пока еще не затронуло кучу пользователей). Применяется ко всему — и к локальным переменным, и к методам, и к классам. В ocaml'е вполне могло бы применяться к именам функций или модулей.

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

Про рефакторинги поговорили, теперь перейдем к месту IDE в этом процессе. Я полностью согласен, что все эти рефакторинги в рассматриваемых ситуациях делаются легко вручную (rename something может быть сложнее, но ничего экстраординарного там нет). Первые три можно даже попробовать в текстовом редакторе реализовать. Первые два даже и не слишком сложно будет сделать (для vim), и это покроет большинство случаев применения. Только вот не в сложности или скорости здесь дело. Если посмотреть то, что я написал выше, получается, что я использую операции "назвать результат формулы", "назвать константу", "назвать функцию", "исправить имя aka rename". Эти операции фактически являются (реализованы с помощью) соответствующими рефакторингами. Ну а рефакторинги в качестве механизма уже перемещают блоки текста или чего там еще использует IDE. Все четыре операции имеют соответствующие комбинации горячих клавиш. В результате на 4-х комбинациях я имею 4 операции. Высокоуровневых операции, описываемых в терминах конструкций языка. Т.е. я не просто куда-то переношу куски текста, я выполняю некоторую вполне осмысленную и "высокоуровневую" трансформацию программы. Да, я могу сам выполнить и все низкоуровневые операции с кусками текста, но зачем? Ведь в языках же, наоборот, стремятся к большей выразительности при меньшем количестве кода. Ну да, мы получаем большую выразительность и "высокоуровневые" термины для написания программ. Но в IDE я также получаю "высокоуровневые" операции для манипуляции над программами. Т.е. не просто скопировать блок кода, а именно "перенести метод", например. Или 4 указанных операции. Детали реализации этих операций меня не сильно интересуют. А манипуляции существующим кодом в ряде отраслей важны. На самом деле это практически вся автоматизация бизнеса с ее изменениями требований и прочим, когда важно не только то, что написано сейчас, но и как из того, что было вчера сделать то, что нужно сегодня. Из-за непредсказуемости требований это тоже имеет свой fun. И для решения этих задач используются соответствующие инструменты (те же IDE). Причем, что интересно, вполне может быть, что требования к возможности изменения кода как раз гораздо выше, чем требования к его выразительности. Т.е. требования меняются часто и нам важна вся инфраструктура, возможности найти места для изменений в огромной кодовой базе и т.п. Поэтому в данном случае вопрос о наличии и возможностях IDE будет очень и очень актуален.

Немного напишу про упомянутцй "expand selection", который используется для 1-го и 3-го рефакторингов. Это расширение существующего выделения на логические блоки кода, уже содержащего выделение. Возможный пример для ocaml'а: исходная конструкция let a = if b > 0 then c + d else let e = c-d in e * e, исходное выделение — первая e в выражении e * e. Выделения при очередных расширениях:

  1. e * (для выделения метода или переменной, например)
  2. e * e
  3. let e = ...
  4. if b > ...
  5. let a = ...
Опять же, мелочи, но для подготовки к рефакторингам очень удобно. Не нужно глазками искать начало блока, конец, тянуть выделение. Всего лишь контролируется, что "по дереву языка" мы пришли в то место, которое нам нужно и над которым выполняется операция. Опять же, я команды отдаю не в терминах "текстового редактора", а в терминах языка, его грамматики. Примерно того же рода копирование "фрагмента кода" в другой код. Мелочь, но import'ы для java тянутся и автоматически появляются в новом месте. А вот будет ли в OcaIDE что-нибудь сделано, когда я скопирую кусок из одного файла в другой (не помню, где собранная лежит дома, а для мелочей хватает и vim'а)? А и исходном файле у меня могли быть #open вначале, поэтому не все можно оставить как есть, нужно либо имя модуля дописать првы вызовах, либо директивы #open в целевом файле. Мне с "кодом" работать все же приятнее, чем с "текстовым представлением этого кода".

Ну и напоследок про «перераспределить обязанности между классами и один из них, возможно, выкинь». В таком виде рефакторинга нет. Он будет выполняться с помощью нескольких более простых. А вот в каких терминах мы будем работать при этих мелких рефакторингах — это большой вопрос. Можно таскать "куски текста" (понимая под этим перемещение метода, например). Только вот при этом нужно контролировать, что все зависимости утянуты и т.п. Возможно, метод менять (если часть методов осталось в одном классе, а часть уехала). А можно сказать, что "вот этот метод должен уехать в тот класс". При этом IDE может проверить зависимости (например, скажет, что ссылки остались на приватный метод и видимость ему нужно поменять), сама поменяет все ссылки на функции в исходном коде. При перемещении метода вверх в иерархии классов можно одним кликом сказать "добавить зависимости", проверить их и продолжить операцию. Ну да, наверное, все равно какие-то мелочи придется сделать "в тексте руками". Но если не все плохо, это будет малая часть. А большая часть будет в реорганизации структуры, фрагментов программы.
Re[6]: Жизнь без IDE
От: Mirrorer  
Дата: 28.09.09 07:09
Оценка: 51 (2) :))
Здравствуйте, BulatZiganshin, Вы писали:

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


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


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

Я вообще к чему. Микросхемки можно паять и на коленках, чего уж там. Но в промышеллном производстве пользуются немного другими технологиями.
Re[8]: Жизнь без IDE
От: MigMit Россия http://migmit.vox.com
Дата: 28.09.09 19:54
Оценка: :)))
Здравствуйте, VladD2, Вы писали:

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


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


Отношение количества хаскеллистов к количеству пишущих на других языках примерно равно отношению количества умных к количеству идиотов. Это в качестве альтернативной гипотезы.
Re[8]: Жизнь без IDE
От: Klapaucius  
Дата: 01.10.09 15:19
Оценка: +3
Здравствуйте, thesz, Вы писали:

T>Это вопрос личного выбора.

T>Лично я считаю, что мне нужен сперва язык, а потом среда, другие считают иначе.

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

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

T>Или так: мне важнее потенциальные возможности, кому-то — уже реализованные.


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

T>Я добавлю к этой позиции ещё и "но автоматизация не должна накладывать требования получения дополнительных навыков".\


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

T>Иными словами, если я автоматизирую создание класса в Java и мне надо выучить последовательность действий, и у меня есть возможность создать ФВП в Хаскеле без изучения этой последовательности, то я предпочту ФВП.


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

T>Как только эта самая автоматизация требует формирования рефлексов, тут она начинает быть вредна.


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

T>А вот эти два предложения я не понял совсем.


В этих предложениях всего лишь написано, что я не понял, как предложение "Именно поэтому следует писать программы так, чтобы каждое их изменение было сопряжено с интеллектуальной деятельностью, а не рутиной."
может быть аргументом против автоматизации. Выглядит как аргумент за.
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[14]: Жизнь без IDE
От: IT Россия linq2db.com
Дата: 02.10.09 19:21
Оценка: +3
Здравствуйте, VladD2, Вы писали:

VD>В случае форм — это оправдано.


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

VD>Так вот, я не рассматриваю IDE именно как средство работы с кодом. Но дизайнеры тоже не считаю лишней фигней. Другое дело кода дизайнеры закрывают дыры в языке. Это действительно прискорбно.


VD>Но к чему все это?


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

IT>>Ты путаешь рефакторинг кода и рефакторинг дизайна.


VD>Я ничего не путаю. Но чтобы менять дизайн, нужно тупо менять код.


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

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


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

IT>>Повторяю — тупой. Раньше на это уходило от нескольких минут до нескольких часов, сейчас ровно полсекунды.


VD>Все зависит от запущенности случая. У меня уходили дни! А могли бы уходить минуты.


Дни? На переименование методов?

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


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


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

VD>Нет. Уверен, что при наличии такой IDE я бы сделал код таким как хочу. Меня сейчас останавливает от этого только объем работ и их трудоемкость.


Объём каких работ? Влад, вот давай эксперимент, в следующий раз, когда ты потратишь день на какую-нибудь мелочь, ты расскажешь нам как-бы ты это делал с помощью автоматических средств рефакторинга. OK?
Если нам не помогут, то мы тоже никого не пощадим.
Re[18]: Жизнь без IDE
От: deniok Россия  
Дата: 26.10.09 14:14
Оценка: :)))
Здравствуйте, LaPerouse, Вы писали:

LP>

Если оно крякает как утка, плавает как утка и выглядит как утка, то это, вероятно, утка и есть.


— воскликнул селезень, бросаясь к чучелу, поставленному охотником.
Re[4]: Жизнь без IDE
От: Klapaucius  
Дата: 01.10.09 07:46
Оценка: 47 (1) +1
Здравствуйте, thesz, Вы писали:

T>Иными словами, думай, а не пользуйся усилителями интеллекта.

T>Здоровее будешь.

Ну, по такой логике и компилятор — усилитель интеллекта. И чтобы не захворать, видимо, следует все писать в машкодах? Это мало того, что, мягко говоря, не согласуется с вашей обычной позицией, так еще и просто бессмысленно. Количество нерешенных задач все равно бесконечно и нет никакого смысла создавать для себя трудности. Тем более, что решение одной и той же задачи раз за разом не только не представляет никакого интереса, так еще и для ума никакой пользы не несет, по той простой причине, что интеллектуальной деятельностью вовсе не является.
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[15]: Жизнь без IDE
От: z00n  
Дата: 07.10.09 23:06
Оценка: 8 (2)
Здравствуйте, VladD2, Вы писали:

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

Даже если у человека на было денег на workstation, это скорее был бы Brief или KEDIT.
Но в то время уже давно (с середины 70-x) были, лисп-машины с настоящими IDE — на них, например, разрабатывали Smalltalk (Xerox Dorado и Dolphin).
Using KEE (Knowledge Engineering Environment) on a Symbolics Lisp Machine(Еще ссылки тут).


VD>Тогда у людей еще емаксов не было. Емакс вышел из стен МИТ-а где-то в 80-ых. ГНУтый емакс — это 1984. К тому же это штуковина на любителя.


Нортон коммандера тем более еще не было — первая версия вышла в 86-ом)

Весь UNIX был написан в редакторе ed- это не было большой проблемой так как вместо мониторов были телетайпы
Из ed'а вышли sam(~80 год) and vi(76 год). Пользуясь sam, например, Страуструп написал С++. Торвальдс до сих пор пишет в MicroEMACS(85 год). Разумеется все они пользовались grep sed и awk.
Re[9]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.09.09 20:32
Оценка: 1 (1) +1
Здравствуйте, MigMit, Вы писали:

MM>Отношение количества хаскеллистов к количеству пишущих на других языках примерно равно отношению количества умных к количеству идиотов. Это в качестве альтернативной гипотезы.


А каково отношение хороших программ написанных на хаскеле и хороших программ написанных не на нем?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Жизнь без IDE
От: IT Россия linq2db.com
Дата: 02.10.09 15:26
Оценка: 1 (1) +1
Здравствуйте, VladD2, Вы писали:

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


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


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


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

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

В общем, либо быстрый старт в начале и плохопахнущая куча кода в конце, либо недовольство начальства из-за срывов развития проекта на начальной стадии и травля анекдотов в курилке или в кафешке (вместо того, чтобы заниматься ловлей глюков как все нормальные люди) на завершающей.
Если нам не помогут, то мы тоже никого не пощадим.
Жизнь без IDE
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 27.09.09 12:58
Оценка: +2
Здравствуйте, vshabanov, Вы писали:

V>* killer feature -- показывает типы отдельных частей выражения (надо компилить с опцией -dtypes), очень удобно при поиске ошибок (можно посмотреть код вокруг ошибки и понять где типы раходятся) и при разбирании в коде.


В OcaIDE это тоже есть.

V>Замечу, что никакой class browser, autocomplete с анализом кода (типа выдать методы после точки) не нужны и не используются.


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

V>Знаю нескольких человек, пишущих на Хаскеле в FAR-е, и по своей производительности они сделают любого программиста, сидящего в навороченной IDE.


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


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

27.09.09 18:33: Ветка выделена из темы IDE для ФЯ
Автор: VladD2
Дата: 26.09.09
— VladD2
Re[2]: Жизнь без IDE
От: FR  
Дата: 27.09.09 15:53
Оценка: +2
Здравствуйте, VladD2, Вы писали:

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


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

VD>Мне периодически приходится писать писать код без поддержки IDE. Не скажу, что это очень трудно. Но определенный дискомфорт испытываю. Помогает отладчик. Когда в отладчике видишь структуру данных, то конечно проще написать несколько строк кода, но потом без многократных итераций "компиляция <-> правка" не обходится. Если же код пишется в IDE, то компиляция в большинстве случаев проходит с первого раза, да и отладка требуется реже.


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

Вот разбираться в чужом коде, и в процессе изучения нового языка, да IDE здорово помогает.
Re[7]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.09.09 17:55
Оценка: +2
Здравствуйте, 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


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

ЗЫ

В общем, из услышанного у меня сложилось впечатление, что ты описываешь работу с проектом относительно небольшого размера, который пишиется одним-двумя человеками и который можно полностью заложить в мозг одного человека. Но что делать с проектами где есть миллионы строк кода и который разработывают десятки человек? Никакой Хаскель на сделает, так чтобы любая задача могла легко уместиться в голове. А без этого метды "копируем функцию" просто не будут работать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Жизнь без IDE
От: Klapaucius  
Дата: 01.10.09 10:08
Оценка: +2
Здравствуйте, thesz, Вы писали:

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

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

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

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


Это тоже пустое утверждение — что-то вроде "если хочешь быть счастливым — будь им". Я так понимаю, что мы говорим о том, полезна автоматизация или нет. Моя позиция простая: все что может быть автоматизировано — должно быть автоматизировано. Ручное выполнение автоматизируемого пищи ни уму ни сердцу не дает. Ваша позиция для меня непонятна. Кажется, вы считаете, что автоматизация где-то полезна, а где-то вредна. Но как отличить те области, где она вредна от тех, где полезна мне пока не понятно.
И в особенности непонятно, как отказ от автоматизации может привести к тому, чтобы каждое изменение программ "было сопряжено с интеллектуальной деятельностью, а не рутиной". По моему скромному разумению так можно только обеспечить статистическое преобладание рутины над интеллектуальной деятельностью.
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[7]: Жизнь без IDE
От: VoidEx  
Дата: 01.10.09 12:34
Оценка: +2
Здравствуйте, Klapaucius, Вы писали:

K>Это тоже пустое утверждение — что-то вроде "если хочешь быть счастливым — будь им". Я так понимаю, что мы говорим о том, полезна автоматизация или нет. Моя позиция простая: все что может быть автоматизировано — должно быть автоматизировано. Ручное выполнение автоматизируемого пищи ни уму ни сердцу не дает.


Напомнило отрывок из "Записки невесты программиста", где вместо написания 10 открыток, жених целый день автоматизировал, да баги правил. Разумное место для автоматизации, 10 свадебных открыток, которые не будут написаны больше никогда.
Это я к тому, что крайности, они как бы часто чем-то пренебрегают, я привёл пример неразумной автоматизации. Кроме того, ваша т.н. автоматизация требует ещё и изучения, а толком ничего не даёт. Зачем мне учить команду "удалить две строки", когда я могу запомнить только клавишу delete и что с шифтом и стрелками можно код выделять.
Повторюсь, я не против автоматизации, но ваша позиция слишком максималистичная.

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


Именно так, где-то она не нужна, так как не стоит того. От того, что вам не понятно, как отличить, когда нужна, а когда нет, по-моему, стоит сделать вывод, что над этим надо основательно подумать, а не выбирать одно из двух крайностей.
Re[7]: Жизнь без IDE
От: FR  
Дата: 02.10.09 03:52
Оценка: +1 -1
Здравствуйте, VladD2, Вы писали:

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


Для OCaml'а есть вполне качественное IDE, для Лиспов тоже их полно, но я не вижу повального ими увлечения. Не знаю может специфика Hемерле, в котором слишком привычная императивная и ООП часть и в котором легко обойтись совсем без функциональщины на тебя так воздействует, может то что ты больше работаешь с окружением чем с самим языком, может то что у тебя нет привычки работать с REPL. В общем я наоборот вижу у тебя IDE зависимость которая не лечится даже такими сильными средствами как ФЯ
Re[10]: Жизнь без IDE
От: Klapaucius  
Дата: 02.10.09 12:35
Оценка: +2
Здравствуйте, thesz, Вы писали:

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


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

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

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

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

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


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

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


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

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

T>К чему приводит твой призыв "автоматизировать надо всё!"?

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

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

T>Ура!

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

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


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

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


Это напоминает аргумент приверженцев некоего языка, которые утверждают, что если написание программ будет болью и ужасом — люди будут лучше продумывать программу зарание. Ну допустим, иде провоцируют перекраивать программу по живому потому, что это легко. Но любой мощный язык делает написание легкоизменяемых с минимальными усилиями программ достаточно легким и как бы само собой получающимся. В этом, в общем-то, их можность и проявляется.
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[9]: Жизнь без IDE
От: dr.Chaos Россия Украшения HandMade
Дата: 02.10.09 14:53
Оценка: +2
Здравствуйте, VladD2, Вы писали:

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


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


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


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

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


Есть такая присказка: "Если бы люди умели пользоваться vim, grep, sed, awk, то миллионы программных продуктов так никогда и не были бы созданы.". Это более универсальные инструменты, но с ними можно работать не менее эффективно чем с IDE.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[9]: Жизнь без IDE
От: thesz Россия http://thesz.livejournal.com
Дата: 02.10.09 15:22
Оценка: :))
Здравствуйте, Mirrorer, Вы писали:

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


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


Зависит.

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

Однако, когда я программировал, выпимши пива — да, такое было, хотя и давно, — я использовал только Хаскель, поскольку и тикль, и Си были одинаково опасными. Некоторые части программ даже использовались потом без существенных переделок.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[19]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.10.09 14:14
Оценка: +1 :)
Здравствуйте, MigMit, Вы писали:

MM>При том самом. Если внутреняя структура типа видна вне модуля, в котором он определён — пиши пропало, потом нужно будет лазить по исходникам с лупой.


А. Пнял. Но это уже проблема Хаскеля и других языков где есть только алгебраические типы, так как их природа плохо совместима с инкапсуляцией.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Жизнь без IDE
От: LaPerouse  
Дата: 25.10.09 18:34
Оценка: -2
Здравствуйте, thesz, Вы писали:

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


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


T>Было бы интересно увидеть пример не рекурсивного алгоритма. Желательно, не тривиального.

T>То, что я изучал, они все, как один "вот базис индукции, вот шаг индукции, вперёд!"

Пример не рекурсивного алгоритма? Алгоритм реализующий итеративный процесс. Может записываться в виде хвостовой рекурсии, однако рекурсивным он от этого не станет.
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[19]: Жизнь без IDE
От: deniok Россия  
Дата: 26.10.09 14:25
Оценка: +2
Здравствуйте, LaPerouse, Вы писали:

LP>Я не понял. Состояние оно либо есть либо нет. С монадой State чистота функции нарушается? Нарушается. Все, ФП кончился. Началась суровая жизнь


А, так ты даже этого не знаешь! Ты просто Хаскелл мало изучал. Открою тебе страшную тайну — с монадой State чистота функции не нарушается. Монада State — чисто синтаксическая конструкция, безо всякого тайного хакерства, чистая как слеза ребенка:
newtype State s a = State { runState :: s -> (a, s) }

instance Monad (State s) where
    return a = State $ \s -> (a, s)
    m >>= k  = State $ \s -> let
        (a, s') = runState m s
        in runState (k a) s'

class (Monad m) => MonadState s m | m -> s where
    get :: m s
    put :: s -> m ()

instance MonadState s (State s) where
    get   = State $ \s -> (s, s)
    put s = State $ \_ -> ((), s)
Re[15]: Жизнь без IDE
От: LaPerouse  
Дата: 27.10.09 15:20
Оценка: -2
Здравствуйте, Mr.Cat, Вы писали:

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

L>>Сначала у меня даже средства для рефакторинга стояли (см. HaRe)
L>>GHC внутре (shim)
MC>Ага, спасибо.

L>>и ещё по мелочи, но потом я от них отказался.

MC>Можно хотя бы названия?

Для языков без поддержки IDE я рекомендую использовать прекрасный редактор с открытыми кодами Notepad++. Им реально можно пользоваться (в отличие от emacs/vim/etc).
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[18]: Жизнь без IDE
От: thesz Россия http://thesz.livejournal.com
Дата: 27.10.09 22:27
Оценка: +1 :)
LP>Вим, чтобы избежать подобной судьбы, ввел два режима

Широта твоей неосведомлённости просто поражает.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[18]: Жизнь без IDE
От: LaPerouse  
Дата: 28.10.09 08:14
Оценка: :))
Здравствуйте, thesz, Вы писали:

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


T>>>Сборка — это часть разработки.

T>>>Кстати, влияющая на многие стороны разрабатываемого проекта.
LP>>Сборка — это сборка. И к эклипсу это не имеет никакого отношения. Все. Точка. Признай наконец-то что сказал чушь.

T>Вообще-то имеет.


T>Ещё раз. Сложности сборки проектов с кодогенерацией под текущими средами разработки практически полностью блокируют её использование.


Это бред. Еще раз. Eclipse не имеет никакого отношения к сборке проекта. И он не осложняет сборку проекта. Вообще никак.


LP>>Нет, спасибо. Генерят код для жабы те, кто не умеет на ней писать.

T>Да-да. А компиляторами из Си в ассемблер пользуются те, кто не умеет писать на ассемблере.

передергивать-то не надо. java не ассемблер а высокоуровневый язык, сравнимый с Agda, на котором ты собрался генерировать java-код.
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[19]: Жизнь без IDE
От: VoidEx  
Дата: 28.10.09 11:15
Оценка: :))
Здравствуйте, LaPerouse, Вы писали:

LP>передергивать-то не надо. java не ассемблер а высокоуровневый язык, сравнимый с Agda, на котором ты собрался генерировать java-код.

Правда что ли?
Re[8]: Жизнь без IDE
От: BulatZiganshin  
Дата: 27.09.09 20:21
Оценка: 45 (1)
Здравствуйте, 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 занудной, нетворческой работы. потому люди и уходят туда, где больше творчества, а меньше разборок с третьим слоем пятого компонента
Люди, я люблю вас! Будьте бдительны!!!
Re[8]: Жизнь без IDE
От: vshabanov http://vshabanov-ru.blogspot.com
Дата: 28.09.09 19:40
Оценка: 45 (1)
Здравствуйте, VladD2, Вы писали:

VD>Как я понимаю, для того чтобы все эти :i и :t работали, предварительно в интерпретатору нужно скормить содержимое всего проекта. Так?

VD>Сколько это занимает времени?

Загрузка проекта файлов из 50 занимает несколько секунд. Если делалось что-то хардкорное с типами, то может и полминуты грузить десяток файлов. Делается это один раз, дальше делается :r -- перегрузка текущего модуля -- перегружаются только измененные модули, это уже шустро.

Если что-то уж совсем большое, то можно вынести в package (грузится почти мгновенно). Еще можно скомпилить некоторые файлы, если они не меняются (по сути типа локальный пакет получается, но тут есть опасности, что .o не соответствует .hs).
Re[6]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.10.09 20:20
Оценка: 18 (1)
Здравствуйте, thesz, Вы писали:

K>>И чтобы не захворать, видимо, следует все писать в машкодах? Это мало того, что, мягко говоря, не согласуется с вашей обычной позицией, так еще и просто бессмысленно.


T>Тем не менее, это моя позиция.

T>Попробуй убедить меня в обратном.

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

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

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

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

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

Таким образом вывод мой такв. Качественных IDE у большинство нет по бедности (или каким-то другим причинам, например дороговизне и сложности их создания). Заявления о их не нужности являются следствиями того, что а) средства работы с ортодоксальными ФЯ сильно отличаются от того, что можно увидеть в привычных IDE, б) "честь мундира" жалко, ведь казалось бы ФЯ так круты, что на них можно было бы легко написать эти IDE, но их все же нет.

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

Ну, и вопрос... Как я понимаю на русском таких текстов нет. Есть ли такие тексты на английском? И если есть, то не хочет ли кто-либо перевести их на русский и выложить для общественности к нам?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Жизнь без IDE
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 27.10.09 12:22
Оценка: 10 (1)
Здравствуйте, Mr.Cat, Вы писали:

MC>Кстати, вопрос ко всем виммерам и любителям емакса. Чем (набор плагинов/режимов/...) вы пользуетесь для работы с кодом на хаскеле?

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

Сначала у меня даже средства для рефакторинга стояли (см. HaRe), GHC внутре (shim) и ещё по мелочи, но потом я от них отказался. Оказалось вполне достаточно иметь haskell-mode.

Что такое переменная внутри функции в Haskell я не очень понимаю — то, что в let вяжется? Или where тоже пойдёт? Или аргумент лямбды? Сомневаюсь, что этот тип будет показан (надо глянуть на GHC API, это вообще возможно?). Но тип самой функции он выводит замечательно. Мне этого бывает достоточно, т.к. я стараюсь писать маленькие функции.

-- разбор camel case идентификатора
parse = groupBy (\_ -> not . isUpper)


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

Если отбросить редкие использования, то очень часто пользуюсь — подсветкой, :make с показом ошибок, автодополнением, навигацией (обычно по тегам). Всё. Остальное снаружи — google, hoogle, cabal, ghci, lambdabot.
Re[15]: Жизнь без IDE
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 27.10.09 14:06
Оценка: 10 (1)
Здравствуйте, Mr.Cat, Вы писали:

L>>и ещё по мелочи, но потом я от них отказался.

MC>Можно хотя бы названия?

Вспомню — напишу. Что-то для кабала было, не помню, к сожалению.

L>>Оказалось вполне достаточно иметь haskell-mode.

MC>Речь сейчас про emacs? Или имеется в виду родная поддержка вима?

Про vim. Хотя изначально я сидел на emacs. Там поддержка Haskell сильнее, если нет разницы какой редактор использовать, то иди на emacs лучше.

L>>Что такое переменная внутри функции в Haskell я не очень понимаю — то, что в let вяжется? Или where тоже пойдёт? Или аргумент лямбды?

MC>Угу. Я иногда читаю чужой код и там бывает что-то такое:
MC>
MC>какаяТоФункция :: чтоТо -> НеведомаяМонада ЧтоТоЕще
MC>какаяТоФункция = do
MC>  переменная <- известнаяФункция . неведомаяФункция $ чтоТоТретье
MC>  ...
MC>

MC>Соответственно, хочется по минимуму бегать по гуглам и другим частям чужого исходника.

А ну можно _si, он покажет тип неведомойФункции и НеведомойМонады. Т.е. для топ-левел всё работает. Вот для "переменная" он ничего не покажет.

L>>автодополнением

MC>Для этого нужно что-то ставить?

Нет, haskellmode только, он не всё может, но хватает.
Смотри здесь — http://projects.haskell.org/haskellmode-vim/screencasts.html

L>>навигацией (обычно по тегам)

MC>Ctags или как их там? Или что-то особое для хаскеля есть?

Да, их умеет генерить ghci (:etags/:ctags), а также есть отдельная утилитка.
Re[18]: Жизнь без IDE
От: z00n  
Дата: 27.10.09 21:48
Оценка: 6 (1)
Здравствуйте, LaPerouse, Вы писали:

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


LP>Положительные стороны:

LP>1. Есть все привычные функции редактирования, и самое главное, они изначально сидят на привычных клавишах. Это и смещение выделенных кусков по Tab и Shift+Tab, и блочное выделение и многое другое

К сожалению нет многих "непривычных функций", например delete-indentation или align-regexp — а очень привыкаешь. Очень бедные возможности работать с клавиатуры — тут третьего не дано — либо аккорды — либо командный режим как в vim. Нет нормального undo!

LP>2. Легко добавляется новая подсветка, буквально за пять минут можно сделать новую

Такая как в N++ и в емакс добавляется за 5 минут. Вот целиком подсветка JavaFX:
(require 'generic-x)

(define-generic-mode
  'javafx-mode
  '("//" ("/*" . "*/"))
  '("abstract" "attribute" "bind" "break" ... 
  '(("%{\\([A-Z_]+\\)}" 1 font-lock-variable-name-face)
    ("\\b[0-9][0-9][0-9]\\b" . font-lock-constant-face))
  '(".fx\\'")
  nil
  "Major mode for JavaFX Script.")

(provide 'javafx-mode)

LP>3. Есть встроенная консоль. Компилятор добавляется очень просто.
bash
Process started >>>
ls
bash: line 1: $'ls\r': command not found
pwd
bash: line 2: $'pwd\r': command not found

Как по ошибкам из нее скакать?

LP>4. Есть вкладки и очень удобное переключение между ними

Ну-ну, в емаксе есть, наверное 20 способов переключаться между буферами.
LP>5. Есть очень удобная фича — выделение текущего слова под курсором определенным цветом по всему документу.
C-s C-w
LP>6. Есть поддержка UTF8
стандартно с 23 версии
LP>7. Очень шустрав работе
Емакс не медленнее — он дольше стартует, поэтому его можно запустить как сервер — и он будет быстрее N++.
win: emacsclientw
nix: emacs --daemon

Вообще у емакса всего один существенный недостаток — первые 2 недели непривычно

LP>Из минусов — нет нормального скриптового интерфейса (как лисп в емаксе).


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

Во основном, он медленно стартует, но как и емакс, его можно запустить сервером — зато у него практически работает консоль

LP>В Emacs нужно иметь шесть пальцев на руке для нормальной работы. В Ecb по умолчанию для переключения между панелями нужно жать одновременно на 6 кнопок(!!!). Вим, чтобы избежать подобной судьбы, ввел два режима, но от этого стало только хуже. Получается, если я хочу выделить последнее набранное слово я должен переключать режим — это же ужас.


У меня нет ни одной комбинации из 6 кнопок. И вообще в студии или идее комбинации ничем не лучше и их не меньше.
Re[2]: Жизнь без IDE
От: thesz Россия http://thesz.livejournal.com
Дата: 28.09.09 09:35
Оценка: 4 (1)
Здравствуйте, VladD2, Вы писали:

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


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

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

Makefile + REPL

ghci InterestingModule.hs
InterestingModule*>:t interestingFunction
interestingFunction :: InterestingType -> InterestingResult
InterestingModule*>:i InterestingType
data InterestingType =
    InterestingData Int
InterestingModule*>:t interestingFunction (InterestingData 10)
interestingFunction InterestingData :: InterestingResult
InterestingModule*>interestingFunction (InterestingData 10)
*** Exception: 10 is not supported.


VD>Мне периодически приходится писать писать код без поддержки IDE. Не скажу, что это очень трудно. Но определенный дискомфорт испытываю. Помогает отладчик. Когда в отладчике видишь структуру данных, то конечно проще написать несколько строк кода, но потом без многократных итераций "компиляция <-> правка" не обходится. Если же код пишется в IDE, то компиляция в большинстве случаев проходит с первого раза, да и отладка требуется реже.


Это ж ты, небось, пользуешься подходом "разбиение программы с помощью ООП, написание методов с помощью ФП".

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

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


*Main> :i Num
class (Eq a, Show a) => Num a where
  (+) :: a -> a -> a
  (*) :: a -> a -> a
  (-) :: a -> a -> a
  negate :: a -> a
  abs :: a -> a
  signum :: a -> a
  fromInteger :: Integer -> a
        -- Defined in GHC.Num
instance Num PortNumber -- Defined in Network.Socket
instance Num Int -- Defined in GHC.Num
instance Num Integer -- Defined in GHC.Num
instance Num Double -- Defined in GHC.Float
instance Num Float -- Defined in GHC.Float


Оно?

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


Скажи волшебные :t и :i, и тебе не придётся лазить по модулям.

VD>Когда я слышу про отладку... что мол она не нужна, то тоже как-то смешно становится. Мне не понятно как можно разбираться с чужим, объемистым, кодом в условиях когда нет ни отладчика, ни даже полной информации о типах. Ну, а в таких языках как Haskell и F# где есть или намеки на перегрузку (классы типов) или почти полноценная перегрузка (как F#) отладка, на мой взгляд вообще необходима.


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

Поэтому дополнительного этапа для понимания поведения компилятора (как в случае F# или C++) в каждом конкретном случае не требуется.

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

Это Data.Dwarf и Data.Elf, если интересно. Посмотри, сколько там классов.

За две недели он полностью подключил их к системе, нашёл две ошибки в Data.Dwarf и протестировал на всякого рода интересных примерах, наподобие volatilve * const * * * volatile const * const volatile arr[10].

Коллега — vshabanov.

VD>Посему послушать моснстров которым "все эти баловства" (с) не нужны, было бы очень интересно.

VD>Так что если кто-то может поделиться, то не стесняйтесь. Это очень интересно!

Это не интересно. Это обычная работа обычных людей.

Рутина!
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[10]: Жизнь без IDE
От: vshabanov http://vshabanov-ru.blogspot.com
Дата: 28.09.09 22:02
Оценка: 4 (1)
Здравствуйте, VladD2, Вы писали:

V>>Загрузка проекта файлов из 50 занимает несколько секунд. Если делалось что-то хардкорное с типами, то может и полминуты грузить десяток файлов. Делается это один раз, дальше делается :r -- перегрузка текущего модуля -- перегружаются только измененные модули, это уже шустро.


V>>Если что-то уж совсем большое, то можно вынести в package (грузится почти мгновенно). Еще можно скомпилить некоторые файлы, если они не меняются (по сути типа локальный пакет получается, но тут есть опасности, что .o не соответствует .hs).


VD>А тебе не хотелось бы, чтобы все это делалось автоматом? Ну, чтобы в бэкграунде давно не изменяемые модули компилировались или помещались в пакет. А измененные чтобы сами перезагружались или перекомпилировались (опять же в бэкграунде)? Ну, чтобы ты тупо выполнил команду :xyz с путем к каталогу проекта и все остальное чтобы сделал REPL?


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

Команду с каталогом проекта я, кстати, не использую. Это emacs сам делает. Типичная последовательность действий:
1. открываем файл
2. жмем C-c C-l, происходит запуск ghci (если еще не запущен), cd до папки с описанием проекта (.cabal-файлом) и загрузка текущего открытого файла
3. в окошке ghci дергаем нужные нам ф-ии
4. правим сорцы
5. жмем C-c C-r, происходит перегрузка ранее загруженного модуля
6. если есть ошибки компиляции, то жмем C-x ` (такая же комбинация клавиш, как и при make) и попадаем на место в исходнике с ошибкой (следующий C-x ` следующая ошибка), повторяем C-c C-r, если ошибок нет, то пункт 3.

Т.е. работа строго однозадачная и по кругу: пишем, компилим, тестим. Показ ошибок во время этапа "пишем" отвлекает.
Re[12]: Жизнь без IDE
От: maxkar  
Дата: 07.10.09 09:50
Оценка: 4 (1)
Здравствуйте, dr.Chaos, Вы писали:

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


DC>Ну, во-первых, спасибо за содержательный ответ .


M>>А можно ваше определение рефакторинга? Это то, что "делается перед внесением фичи, чтобы облегчить этот процесс"?. Просто если использовать, например, определение из wiki (которое более широкое, чем ваше), у меня получается, что как раз таки большая часть рефакторингов делается не перед внесением фичи а во время или сразу после внесения фичи, после изменения кода. Я в дальнейшем буду использовать термин "рефакторинг" для обозначения "изменения программы без изменения ее фунциональности (или внешнего поведения) с целью улучшения ее качества" (вольный перевод wiki). Если вас не устраивает — готов использовать другое название, только предложите Именно для того определения, которое я привел. Потому что такая активность существует и хочется как-то ее называть.


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

С прагматичными целями согласен. Одна из моих целей — сэкономить время при последующем чтении. Чтобы код читался "линейно", без остановок, возвратов назад и т.п. Желательно — на "повышенной скорости, по-диагонали". Это в целом даже более актуально, чем подготовка всего кода к дальнейшему изменению. Потому, что чтобы сделать изменение, сначала нужно найти то место, в котором это изменение должно быть. При практически нулевых затратах на улучшение сейчас это может принести ощутимую выгоду в дальнейшем. Серьезные (и длительные) преобразования, действительно, делаются по согласованию с менеджерами, в том числе с учетом возможных путей дальнейшей эволюции, вероятности внесения багов, сложности поддержки и т.п. Но не пойду же я к менеджеру с вопросом "а вот у меня здесь сложная формула, я хочу из нее выделить подвыражение и назвать его. Можно я потрачу на это 1,5-3 секунды?".
Как уже писал, читаемость — достаточно субъективный вопрос. Но пока что мой опыт показывает, что те рефакторинги, которые я применяю, полезны не только мне. Из опыта. Я провожу ревью кода других разработчиков. После прохождения "первой ступени" (правильное использование библиотек, нормальный дизайн, проверка граничных случаев там, где надо и т.п.) я начинаю обращать внимание на читаемость (до прохождения того этапа занматься читаемостью особого смысла не вижу). По стилю кода и читаемость замечания даются даже на в "рекомендательной" форме ("лучше делать так потому, что") а в форме альтернативы ("я бы сделал так то, потому что мне кажется, что.../мне удобнее..."). Получалось так, что те программисты тоже в дальнейшем начинали использовать указанный стиль (и по ревью заметно, и в беседе сами говорили, что так действительно удобнее). Ну и еще видел программистов, которые сразу же в том стиле пишут (и формулируют "критерии" точно так же, как и я).
Вопрос про определение был задан не с целью придраться и т.п. Мне просто стало интересно, мы расходимся в определениях или вы просто не используете ряд практик, которые использую я (эти практики и описал далее).


M>>1. "Extract variable"...

M>>2. "Introduce constant"...
M>>3. "Extract method"...
M>>4. "Rename something"...

DC>Ээээ.... И это все возможности что предоставляет IDE?

Нет. Совсем далеко не все. Это "рефакторинги, которые часто используются при написании (сразу после написания) кода".
1. Здесь не приведены "quick fix", которые используются при написании кода (в eclipse они не попали в рефакторинги). Применяются, опять же, с целью улучшения читаемости. Это "invert if/conditional", "replace if with conditional", "change method signature" (вызов метода с отличающейся сигнатурой, позволяет добавить параметр/параметры прямо из точки вызова), "create method" (не уверен, что именно так называется. Заводит несуществующий метод по его вызову в коде). Последнее хочется отметить особо — оно и "extract method" у меня являются единственными источниками private-методов. Ну т.е. private ... ... (...) я пишу только в vim и т.п. В IDE же либо сначала пишется вызов, либо метод образуется из уже существующего кода. Исключений не помню (хотя, возможно, и были).
2. Здесь не приведены рефакторинги, которые используются "перед" написанием кода (т.е. подготовка к исправлениям/внесению функциональности).
3. Здесь нет рефакторингов, которые "не используются". Мною, естественно. Возможно, кто-то другой использует те рефакторинги.
4. Не приведены рефакторинги, которые используются при написании кода, но редко. Вообще не помню, что из этой категории бывает. Хотя, например, "change method signature", наверное. "Move methods up/down" с некоторой натяжкой тоже.
5. Не приведены возможности анализа. Это деревья вызовов, поиски вхождений (не текста, а именно поля/функции). Outline. Переходы к реализации из кода, переходы к родительским определениям из кода. Открытие ресурса или класса по имени (не нужно ходить по файловой системе). Документация в outline (как документация к текущему вызову так и набираемый javadoc). Документация при code completion (ага, очень удобно смотреть, как обрабатываются граничные условия не ходя далеко). Отметки "на полях" для проблем, специальных комментариев (TODO и т.п., настраиваются), элемента под курсором (поля/метода).
За исключением п. 3 всеми этими возможностями я пользуюсь. Вероятно, есть еще какая-то часть, которую я забыл, и есть части, которыми я не пользуюсь (ну например, отладчиком пользуюсь очень редко).

DC>Т.е. ты хочешь сказать что эти 4 приёма являются полным и непротиворечивым базисом для совершения любого рефакторинга?

Да ни в коем случае. Это "контрпример" к утверждению "рефакторинги выполняются пред правкой бага/внесением изменения". Не более того. А вдруг у вас все то же используется, но только называете вы его по-другому? Да, и заодно это был "контрпример" к утверждению "IDE являются костылями к недостаточной выразительности языка программирования" (не ваше утверждение, но пример и на него отвечает).

M>>Немного напишу про упомянутцй "expand selection", который используется для 1-го и 3-го рефакторингов. Это расширение существующего выделения на логические блоки кода, уже содержащего выделение. Возможный пример для ocaml'а: исходная конструкция let a = if b > 0 then c + d else let e = c-d in e * e, исходное выделение — первая e в выражении e * e. Выделения при очередных расширениях:


M>>Ну и напоследок про «перераспределить обязанности между классами и один из них, возможно, выкинь». В таком виде рефакторинга нет. Он будет выполняться с помощью нескольких более простых. А вот в каких терминах мы будем работать при этих мелких рефакторингах — это большой вопрос. Можно таскать "куски текста" (понимая под этим перемещение метода, например). Только вот при этом нужно контролировать, что все зависимости утянуты и т.п. Возможно, метод менять (если часть методов осталось в одном классе, а часть уехала). А можно сказать, что "вот этот метод должен уехать в тот класс". При этом IDE может проверить зависимости (например, скажет, что ссылки остались на приватный метод и видимость ему нужно поменять), сама поменяет все ссылки на функции в исходном коде. При перемещении метода вверх в иерархии классов можно одним кликом сказать "добавить зависимости", проверить их и продолжить операцию. Ну да, наверное, все равно какие-то мелочи придется сделать "в тексте руками". Но если не все плохо, это будет малая часть. А большая часть будет в реорганизации структуры, фрагментов программы.


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

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

DC>Когда ты говоришь что IDE тебе даёт "высокоуровневые операции для манипуляции над программой" ты не прав, все высокоуровневые манипуляции над программой тебе даёт твой мозг, а IDE тебе облегчает только маленькую часть из них, и самое плохое что набор операций маленький и нерасширяемый, т.е. ты, в итоге, начинаешь думать над переделкой дизайна в терминах того что предоставляет IDE. А если ты забиваешь на эти рамки, то получается что у тебя просто набор манипуляций над текстом программы, а в этом плане vim даст 100 очков форы.


Ну так мне это и нужно! Пускай операции мне дает мозг. Но ведь IDE понимает меня именно в моих терминах! Она понимает команду "перемести метод туда". Ей не надо это разжевывать в качестве последовательности низкоуровныевых команды (выдели, перемести, добавь иморт туда). Да, многого она не понимает, но базовые частые команды она значет хорошо. У меня есть уровни "библиотека или программа"/"пакет"/"класс"/"поле или метод"/"алогоритм реализации метода"/"текст, которым записан алгоритм". И я общаюсь с IDE на том уровне, на котором хочу (да, приходиться работать на разных уровнях). Чистые "текстовые преобразования" я при необходимости тоже делаю. Обычно в vim'е . Помню, как в нем последовательностью замен по регулярным выражениям из одного куска кода делал другой. Можно было бы и в IDE это сделать, но vim'овский сиснтаксис выражений я помню, а IDE-шный еще читать нужно было (оно там есть, все то же я мог бы сделать сразу из eclipse).
И не даст vim 100 очков форы как только дело коснется операций над "логическими единицами программы". Банальный пример. Пусть у нас есть семейство каких-либо форматов, которые мы разбираем. Есть format1.Parser.parse(...), format2.Parser.parse(...), ..., format15.Parser.parse(...). Все функции parse — статические. Где-то в коде могли использоваться через Parser.parse (с импортами), где-то — через статические импорты. В одном коде могли использоваться несколько парсеров. И вот мы решили переименовать format8.Parser.parse() в format8.Parser.parseOldFormat(...) и завести format8.Parser.parseNewFormat(...) (Ну, с целью улучшения читаемости). Как это "безболезненно" сделать в vim'е? Ну так, чтобы переименовалось ровно то, что нужно? Напомню, есть статические импорты и разные обращения (а еще где-то тоже может определяться свой метод parse, который скрывает импортированный статически метод). Ну да, данный пример немного надуман. Но в реальных проектах подобная ситуация вполне возможна — всякие filter/find(condition)/adapt и прочие утилитарные методы, которые плодятся по "похожим сервисам". А в IDE вся операция переименования — безболезненная и достаточно безопасная (баги в переименовывалке я не встречал). Причем если будет место для потенциальных конфликтов в результате переименования (изменится семантика "текста"), IDE меня предупредит, покажет список всех изменений (preview) и заставит его подтвердить.
С "нерасширяемым" набором тоже не соглашусь. В текстовом редакторе он тоже "ограниченный". Ну ладно, notepad рассматривать не будем (там эта проблема совсем не лечится). В vim'е можно написать скрипт, забиндить клавиши, это уже "расширение" IDE. Ну так подобным способом можно и eclipse расширять. Вот недавно обнаружил в eclipse функцию "create refactoring script", которая по проведенным ранее рефакторингом может какой-то скрипт делать. Подробнее не изучал, не за чем было. Но это все мелочи. При желании можно написать плагин (ага, на java, на которой я и так пишу) и там реализовать все те "высокоуровневые" операции, которые мне нужны. И что замечательно — при реализации плагина я получу все бонусы от работы с "высокоуровневой" моделью кода, мне не придется вручную разбирать, кто же откуда импортирован и вообще как парсится кусок текста (на случай экзотических записей и т.п.). Вот, например, модель java, с которой я могу работать при написании плагина (рефакторинги и т.п.). При желании я могу работать и с текстом, не используя эту модель (используя модель текстового редактора).

В общем, высокоуровневость при возможности перейти на нижний уровень — это совсем даже не плохо. Да, ее можно использовать для решения не тех задач, для которых она предназначена. Но не использовать ее только по этой причине — неправильно. А иначе придется отказаться почти от всего и писать на ассемблере. А что? OСaml, например, не дает мне сделать то, что дает делать низкоуровневый C (segfault, например). Ну так давайте от caml'а откажемся. А потом и от C откажемся, так как в нем нет, например, команд mmx. А в assembler'е — есть! Так что для каждой задачи — свой инструмент.

P.S. Написал, и понял, что пример с переименованием метода parse в vim'е можно сделать "достаточно безопасно". Потому что существует интеграция eclipse в vim (наоборот тоже существует, но не интересна). Т.е. vim выступает в качестве front-end'а к запущенному в качестве back-end'а eclipse. И есть у меня подозрения, что переименование в данном случае прошло бы относительно безболезненно. Но вот только в этом случае мы бы получили уже не текстовый редактор, а "полноценную" IDE.
Re[23]: Жизнь без IDE
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 26.10.09 16:26
Оценка: 4 (1)
Здравствуйте, LaPerouse, Вы писали:

LP>Что-то рсдн периодически валится.




LP>То есть получается, что это таки ИП, но ИП сильно контролируемый. Так сказать, попытка укрощения состояния номер два. Первым был ООП.

LP>Нет?

Ещё раньше появились локальные переменные Да, это ИП, в том смысле, что состояние подразумевает очерёдность шагов. Без очерёдности шагов состояния просто нет.

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


Это неправда. Или ты не так понял.

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

LP>Ну значит монады какие-то не те. Автор ведь не уточняет, какие монады имеет ввиду.

LP>И кстати он их там не использует, то есть описываемые в секции 4.7 проблемы касаются чистого безмонадического фп. Может быть монады, решая проблему кривого интерфейса в секции 4.7, привносят какую-то новую проблему. Например ту, о которой он говорит в приведенном мной куске вступления:

LP>

Monads are used to encode state by threading it throughout the program. This makes programs more intricate but does not achieve the modularity properties of true explicit state


Именно к этой цитате и был у меня вопрос. Что такого intricate делает state монада, если она наоборот убирает запутанность, локализую изменения? Мне непонятно. Почему не достигается модульность, если все свойства модульности соблюдаются? Опять неясно. Отсюда мой вопрос.

LP>(только вот секция 4.7 тут не при чем, возможно он хотел написать об этой проблеме когда писал вступление, но забыл)


Может быть.

LP>Ничего не понял. Вижу изменяемый объект. Что, фишка в том, что на этот объект нельзя ссылаться кроме как из тела данной функции?


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

Смысл в чём. У тебя есть код с состоянием. P1, P2, P3 из книги. Для того, чтобы использовать его при явном состоянии, тебе достаточно просто вызвать его в любом месте — и всё. Вызвал не там — поломал. В случае, когда этот код завёрнут в монаду, для вызова тебе нужно "запустить" состояние. То же самое, что ты делаешь и с функциями с аккумулятором — передаёшь начальное значение аккумулятора. Чистота сохраняется, модульность не нарушается.

Т.е. в двух словах (оперируя примерами из книги). Ты получаешь декларативный код с аккумуляторами, который выглядит как код с явным состоянием. Из-за того, что сигнатура у него как у явного состояния — модульность не нарушается — снаружи ничего менять не надо. Из-за того, что реально внутри он использует аккумуляторы, код остаётся чистым.

Т.е. в чём то автор прав. Если сигнатура у нас чистая (в смысле не монадическая) — мы не можем сделать изменение в состоянии, не нарушив условия модульности. Но в случае сигнатуры a -> M b в интерфейсе модуля, мы можем как угодно менять состояние в функциях и снаружи ничего перекомпилировать не надо. Как-то так.

Может быть тебе стоит посмотреть внимательнее на монаду State? Она по сути очень несложная — это функция s -> (a,s), т.е. на входе исходное состояние, на выходе результат и конечно состояние. Объединяя эти функции мы получаем последовательность, т.к. каждое следующее состояние зависит от предыдущего. То же самое и тот же способ, что и в случае с аккумуляторами. Заворачивая её в монаду мы можем писать, не передавая состояние явно, т.е. получаем код, близкий к императивному.
Re[9]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.09.09 22:26
Оценка: 1 (1)
Здравствуйте, BulatZiganshin, Вы писали: (много)

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

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

По любому, спасибо за то, что не ответил в стиле "а мне не надо"!
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Жизнь без IDE
От: thesz Россия http://thesz.livejournal.com
Дата: 28.09.09 09:37
Оценка: 1 (1)
Здравствуйте, Cyberax, Вы писали:

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


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

C>Это лишь означает, что ты не умеешь пользоваться IDE.

А ты — стилем программирования, при котором IDE не нужна.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[6]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.10.09 07:44
Оценка: 1 (1)
Здравствуйте, BulatZiganshin, Вы писали:

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


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


То что ты не видел говнокода (или не видишь его в своих проектах) говорит только об одном — ты работаешь один над относительно мелкими проектами.

Говнокод — это обязательный атрибут любого большого, долгоживущего проекта. И появляется он отнюдь не потому, что кто-то там идиот и не умеет писать или проектировать. Точнее не только по этому. Появляется он в виду массы причин. Тут тебе и люди разной квалификации работающие над проектом. Код который одному кажется идеальным другому кажется говнокодом. Тут тебе и банальный рост твоей квалификации. Кода который казался приемлемым год назад, на сегодня, становится неприемлемым. Тут тебе и изменения требований не увязывающиеся с принятой годы назад идеологией. Тут и ошибки допущенные при проектировании. Если с этим не бороться, то рано или поздно весь проект станет одной большой помойкой. И тут без рефакторинга не обойтись. А рефактринг — это как раз та самая рутина которую (по уму) нужно автоматизировать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.10.09 16:57
Оценка: 1 (1)
Здравствуйте, dr.Chaos, Вы писали:

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


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

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

Во-вторых, внесение фич — это огромная ошибка. Сам грешен иногда поддаюсь искушению совместить эти процессы, но понимаю, что делаю плохо. Стимулом к тому как раз является то, что нет хороших средств рефакторинга. А когда делаешь что-то руками то творчество бьет в мозг. Автоматизированный же рефакторинг позволяет рефакторить код большими "транзакциями". Тут уже точно не получится поддаться на искушение.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Жизнь без IDE
От: dr.Chaos Россия Украшения HandMade
Дата: 03.10.09 04:44
Оценка: 1 (1)
Здравствуйте, VladD2, Вы писали:

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


Угу, только вот найди мне рефакторинг: «перераспределить обязанности между классами и один из них, возможно, выкинь»

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


Ну тут, видимо, опять вопрос в терминологии. Рефакторинг делается перед внесением фичи чтобы облегчить этот процесс. И основной стимул, тут не отсутствие средств (хотя что бы вы знали про vim, sed и awk ), а то что просто переписывание кода — это переливание из пустого в порожнее, т.к. код в итоге будет иметь «идеальную» архитектуру, а заказчик 0 новых функции и столько же багов. Мало того, потом окажется, что архитектура то не идеально и т.п. Основная цель рефаторингов изменить код так, чтоб его было проще менять под текущие и ближайшие цели, т.е. где-то добавить гибкости, где то убавить овердизайна. Ну и что касается твоего поинта: «большие рефакторинги состоят из кучи маленьких», — да, состоят, но по моему опыту занимают они не много времени ( может я их просто не замечаю благодаря «убогим» vim, sed, awk ).

ЗЫ Просьба комментарии в скобочках считать шуткой, с долей правды.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[20]: Жизнь без IDE
От: MigMit Россия http://migmit.vox.com
Дата: 03.10.09 10:08
Оценка: 1 (1)
Здравствуйте, thesz, Вы писали:

MM>>При том самом. Если внутреняя структура типа видна вне модуля, в котором он определён — пиши пропало, потом нужно будет лазить по исходникам с лупой.


T>Конструктор — та же функция, и я не вижу причин, по которым я могу экспортировать функцию и не могу конструктор.


Ну, блин...

Вот у тебя в одном модуле написано
module A where
data Level = Level Int
raiseLevel :: Level -> Int -> Int
raiseLevel (Level x) y = x+y


А в другом
module B where
import A
defaultLevel = Level 0


Внезапно ты обнаружил, что тип нужно сделать более общим:

module A where
data Level = Level (Int -> Int)
raiseLevel :: Level -> Int -> Int
raiseLevel (Level f) = f


Ищи его теперь в модуле B.

Если же у тебя был экспортирован не конструктор, а смартконструктор
module A (Level, level, raiseLevel) where
data Level = Level Int
level :: Int -> Level
level = Level


то потом всё будет проще:
module A (Level, level, generalLevel, raiseLevel) where
data Level = Level (Int -> Int)
level :: Int -> Level
level n = Level (n +)
generalLevel :: (Int -> Int) -> Level
generalLevel = Level


И в B ничего менять не надо.

T>Только жизнь себе усложню.


Как обычно — немного усложнишь поначалу, зато облегчишь потом.
Re[12]: Жизнь без IDE
От: Cyberax Марс  
Дата: 05.10.09 20:38
Оценка: 1 (1)
Здравствуйте, metaprogrammer, Вы писали:

VD>>Ну, почему только про VisualAge. Смолток был в 80-ом и до IBM-а.

M> И много на том смолтолке писали?
Много.

M> IDE были не нужны, и вдруг разом стали нужны, так что ли?

Не совсем. До где-то середины 90-х сложные IDE были невозможны на x86 технически. Но даже простые IDE типа Turbo Pascal'а/Borland C++ уже в ту пору рулили.

Они просто подняли производительность труда и снизили планку входа.

VD>> А задачи, действительно реашалось более примитивные.

M> Это не так. Преимущественно куда как более сложные, чем сейчас.
Какие?

VD>> То что тогда казалось подвигом, сейчас обычное дело.

M> Примерчик можно?
Отладка кода в режиме ядра, к примеру. Сейчас я спокойно это делаю символьным отладчиком из IDE.
Sapienti sat!
Re[23]: Жизнь без IDE
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 28.10.09 14:22
Оценка: 1 (1)
Здравствуйте, LaPerouse, Вы писали:

L>>Во-первых, ООП создавался не для борьбы с копипастным кодом.

LP>Здесь вообще мало говорится о том, почему он появился.

The idea occurred to them of grouping the different types of ships into different classes of objects; each class of objects being responsible for defining its own data and behavior


L>>Во-вторых, у ООП есть ряд серьёзных недостатков, хорошо об этом написано у thesz здесь.

LP>Здесь практически ничего не написано.

С наследованием, классами и ООП целиком обязательно ассоциируется, во-первых, неявная диспетчеризация по первому аргументу функции, во-вторых, группировка методов вокруг классов и, в-третьих, но не в последних по значению, открытые типы данных


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

L>>А у Явы этих недостатков ещё больше. Отсутствие функций высшего порядка приносит просто огромную кучу бойлерплейта. Декоратор для группы строк:

LP>Пиши так:


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

1. Кода меньше не стало
2. От бойдерплейта мы не избавились (заменили цикл на объявление локал класса)
3. У тебя ошибка в коде связанная с копи-пастом
4. На языках, поддерживающих ФВП первые три пункта отсутствовали бы как класс:

endsWith = any . endsWith
startsWith = any . startsWith


Ой! Тут тоже бойлерплейт! Да, но в этом языке его можно удалить:

any1 = (any .)
endsWith = any1 endsWith
startsWith = any1 startsWith


LP>Predicate<T> определяется один раз и его хватает очень намного


Да не хватает их ни фига. Я пример ещё тривиальный привёл. Для стандартных классов можно нагенерить Function2<T,A,R> и использовать. Но тут мы просто разделяем сложность. Клиенту то попроще будет, а вот библиотеку такую писать — сложнее.

Кстати, вот это, думаю, тебе будет интересно:
http://www.rsdn.ru/article/java/JavaFP.xml
Автор(ы): Евгений Кирпичев aka jkff
Дата: 28.12.2008
Официально язык Java поддерживает только объектно-ориентированную парадигму, которая не всегда позволяет сделать код компактным, легко читаемым и удобным в поддержке. Однако Java-гуру умудряются использовать имеющиеся в Java возможности для применения в Java-коде функционального стиля программирования, который в некоторых случаях позволяет радикально улучшить читаемость кода (делая его более декларативным), а также упростить его поддержку и развитие. Надеемся, что данная статья будет полезна многим Java-программистам разного уровня.
Большая часть данной статьи не имеет отношения к собственно функциональному программированию (далее – ФП). В основном будут рассмотрены способы повышения читаемости некоторых часто встречающихся паттернов, особенно при использовании функционального стиля, и без которых об ФП не может быть и речи. О приемах собственно ФП будет сказано совсем немного, ближе к концу статьи.


L>>И ещё куча таких методов, отличающихся только выделенным. Понасоздавать на каждую функцию по классу?

LP>Да нет, использовать то, что есть. И просить у Sun сделать ФВП в 7-ой яве

+1. А потом просить карринг, а потом ленивость..

L>>Так не бывает. Что именно ты не понял? Dependently Typed Programming in Agda читал?

LP>Да я ничего не понял, честное слово. Не читал.

Ну почитай, тогда вернёмся.

LP>Ладно, спасибо за ссылки, просто с этим надо очень серъезно разбираться. С ходу понять не получается (по крайней мере у меня).


Я думаю, с первого раза даже у thesz не получалось
Re[2]: Жизнь без IDE
От: samius Япония http://sams-tricks.blogspot.com
Дата: 27.09.09 15:02
Оценка: +1
Здравствуйте, VladD2, Вы писали:

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

Хиндли — Милнера
Re[3]: Жизнь без IDE
От: Cyberax Марс  
Дата: 27.09.09 15:07
Оценка: +1
Здравствуйте, Don Reba, Вы писали:

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

Это лишь означает, что ты не умеешь пользоваться IDE.
Sapienti sat!
Re[5]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.09.09 15:19
Оценка: +1
Здравствуйте, Don Reba, Вы писали:

C>>Это лишь означает, что ты не умеешь пользоваться IDE.


DR>Обоснуй.


Мне кажется, обосновывать нужно как раз заявление о бесполезности IDE.
Их преимущества очевидны. Это возможность постоянно видеть инфрмацию о типах которая без этого была бы доступна только после компиляции (которая может занимать минуты и даже часы). Если в динамических языках информацию о типах можно получать и динамически и менять код (тоже динамически). Это возможность быстро переключаться между частями проекта. Когда проект большой — это дорогого стоит. Это возможность моментально выявлять ошибки и практически не допускать их. Это возможность быстро, без ошибочно и просто менять проект (делать сложный рефакторинг). Это возможность не лазить в хэлп по каждому поводу. К тому же в статически-ипизированном языке не всегда ясно в какой хэлп лезть. Ведь тип варжения может быть не очевиден если нет IDE. Ни конечно же отладка... Разбираться в чудом (и тем более, плохо написанном) проекте не просто без отладчика. Да и в своем иной раз разобраться не просто.

В общем, преимущества как раз очевидны.

Лучше расскажи как же люди умудряются жить без IDE и при этом иметь достойную производительность труда?
И часть про волшебные свойства ФП можно пропустить, так как не ФЯ тут даже не рассматриваются.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Жизнь без IDE
От: FR  
Дата: 27.09.09 15:45
Оценка: +1
Здравствуйте, vshabanov, Вы писали:

V>Я как-то пробовал окемл с автокомплитом (только вроде это был не OcaIDE, а какой-то режим для eclipse). В принципе в меру удобно, но кроме этого автокомплита там была еще система проектов, вместо Makefile, ну и еще всякие привычные вещи из emacs отсутсвовали. В общем я посчитал, что не стоит оно того, чтобы изучать другую IDE.


OcaIDE это и есть плагин для эсклипса
Он нормально подерживает Makefile.
Правда вроде есть еще один камловский плагин для eclipse, он вроде чуть уступает OcaIDE.

V>Про ненужность IDE. Действительно у окемла IDE уровня VS нет. Да и отладчик там под виндой как-то непросто заставить работать. В начале я тоже как-то думал "а где бы мне IDE нормальную надыбать". Но в итоге я теперь и для C++/Java кода никакой IDE и отладчиком не пользуюсь. Стиль разработки сменился.


OcaIDE в общем-то вполне на уровне VS.
Под win если использовать mingw вариант OCaml все настраивается и графический отладчик и сборка через make.
Re[3]: Жизнь без IDE
От: BulatZiganshin  
Дата: 27.09.09 17:06
Оценка: +1
Здравствуйте, VladD2, Вы писали:

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

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

ага. дико интересно было бы услышать аналогичный рассказ от тебя. что ты такое регулярно делаешь, что требует часов без ide?
Люди, я люблю вас! Будьте бдительны!!!
Re[7]: Жизнь без IDE
От: dmz Россия  
Дата: 28.09.09 07:47
Оценка: +1
M>Бангалорскими. И во всем этом придется кому-то разбираться. К примеру юноше со взором горящим. Который еще молод и ему не дадут написать свою версию M>бангалорской библиотеки с гейшами и го. А гуры будут все говорить что ИДЕ оно ненужно. А молодежь будет охреневать. И невдомек ей будет что задачи M>стоящие перед ними и перед гурами разные. Кому-то писать прототип сложноалгоритмичной мегафичи. А кому-то поддерживать код в который превратилась M>мегфича после реализации доблестными бангалорцами.

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

А что касается Хаскелла, то программировать на нем в бессознательном состоянии невозможно. Это, наверное, его плюс, но
это и причина, по которой он никогда не станет мейнстримом.
Re[10]: Жизнь без IDE
От: dmz Россия  
Дата: 28.09.09 09:15
Оценка: +1
VD>Извини, но это опять декларации. Меня не интересует то что кто-то не использует полноценной IDE. Меня интересует то как при этом происходит процесс работы с проектом. И то какая при этом получается производительность труда (сравнительно с аналогичным проектом поддерживаемым в IDE). А в твоем рассказе одни декларации.

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

Про процесс работы я вообще не понял. Процесс точно такой же — смотрим, редактируем, компилируем. Можешь привести конкретные кейсы, которые интересуют?
Re[3]: Жизнь без IDE
От: thesz Россия http://thesz.livejournal.com
Дата: 28.09.09 09:54
Оценка: :)
Здравствуйте, VladD2, Вы писали:

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


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

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

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

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

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

Этот листочек бумаги заменит тебе второй монитор.

Заодно ты выучишь словарь проблемы.

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

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

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

Иными словами, думай, а не пользуйся усилителями интеллекта.

Здоровее будешь.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[5]: Жизнь без IDE
От: Mirrorer  
Дата: 28.09.09 18:15
Оценка: +1
Здравствуйте, thesz, Вы писали:

T>Законы монад никто не отменял. Это раз.

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

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

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

T>Поэтому надо минимизировать IO, что выгодно само по себе. Это три.

А как бы никто и не спорит Но монады ж они не только для ЙО пользуются. Ну и вопрос был необязательно про бинд, а про любую функцию с которой "не, ну все понятно, но что конкретно ?" (с)

T>Defined at видишь? Поскольку "иногда хочется", то этого должно быть достаточно всегда. Было бы часто, был бы другой коленкор, но тогда надо выбирать другой язык.

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

T>Ещё Haddock умеет вставлять ссылки на исходники (ссылка source справа от названия функции).

Прикольная фича. Но для этого как минимум надо иметь haddock совместимые комментарии.
Re[11]: Жизнь без IDE
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 29.09.09 04:25
Оценка: +1
Я вспомнил еще одну фичу IDE, которая мне реально помогает.
Вот есть функции
List.fold_left : ('a -> 'b -> 'a) -> 'a -> 'b list -> 'a
Enum.fold : ('a -> 'b -> 'b) -> 'b -> 'a t -> 'b
Array.fold_left : ('a -> 'b -> 'a) -> 'a -> 'b array -> 'a
Map.fold : (key -> 'a -> 'b -> 'b) -> 'a t -> 'b -> 'b
Hashtbl.fold : ('a -> 'b -> 'c -> 'c) -> ('a, 'b) t -> 'c -> 'c
или например
String.nsplit : string -> string -> string list
nsplit s sep splits the string s into a list of strings which are separated by sep.

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



и пока пишу аргументы вижу подсказку по типам:



Вот это мне лично здорово экономит время, и я пока плохо представляю как с этим борются люди без IDE.
Re[8]: Жизнь без IDE
От: Klapaucius  
Дата: 01.10.09 14:59
Оценка: :)
Здравствуйте, VoidEx, Вы писали:

VE>Напомнило отрывок из "Записки невесты программиста", где вместо написания 10 открыток, жених целый день автоматизировал, да баги правил. Разумное место для автоматизации, 10 свадебных открыток, которые не будут написаны больше никогда.


Э, нет! Это не спортивно. Я все-таки говорил о принятии решения применять ли средство автоматизации или не применять — а не разрабатывать ли его или не разрабатывать.

VE>Это я к тому, что крайности, они как бы часто чем-то пренебрегают, я привёл пример неразумной автоматизации.


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

VE>Кроме того, ваша т.н. автоматизация требует ещё и изучения, а толком ничего не даёт.


Идея возражения, в общем, ясна. Постулируется, что автоматизация требует во-первых, изучения, а во-вторых — ничего не дает. С такой вводной, конечно, я справиться не могу и полностью разбит, но все это звучит немного странно. Да, я неявно предположил, что автоматизация избавляет от ручного труда — т.е. решает задачи, которые перед автоматизацией ставятся. И это неявное предположение я считаю простительным. Дело в том, что с ваших позиций можно атаковать вообще все что угодно с совершенно опустошающим результатом.
Пример: допустим, мы обсуждаем преимущества путешествия из пункта A в пункт B на самолете. Тут дается вводная: 1) самолет летит через Марианские острова 2) самолет взрывается в воздухе 3) самолет вообще никуда не летит, потому, что он не настоящий. Дальше обсуждать, понятное дело, уже нечего.

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


Давайте все-таки предположим, что автоматизация таки дает некий эффект, т.е. задачу свою выполняет.
Остается, понятное дело, вполне резонное возражение: новый инструмент требует освоения. Это возражение выдвигают чуть менее чем все, кто пишут на rsdn. Обычно оно звучит так: "Я отлично знаю язык Java++ и решу на нем задачу быстрее, чем на языке Пейтон-Джонс потому, что для решения ее на языке ПДж мне нужно сначала изучить этот язык (а дальше он мне может и не пригодится)" — тут человек полностью последователен. Он честно заявляет: все, чего я не знаю — мне не нужно, все чем я не умею пользоваться мне никогда не пригодится. Для меня представляет интерес то, каким образом эту точку зрения удается совмещать с противоположной. Я, как человек ленивый, желаю в этом вопросе вскарабкаться на плечи титанов и сразу обращаюсь с вопросами к людям, которые явно над этим основательно подумали и выработали некий критерий отсечения ненужных навыков. Он, кроме шуток, очень полезен, потому, что необъятное объять, к сожалению, нельзя.
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[11]: Жизнь без IDE
От: thesz Россия http://thesz.livejournal.com
Дата: 02.10.09 09:34
Оценка: +1
Здравствуйте, VladD2, Вы писали:

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


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

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

Вот моё мнение о библиотеках: они нужны.

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

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

Это, кстати, гарантирует быстрое подключение чужих библиотек.

VD>>>Кто считает иначе? Покажи, плиз, кто выбирает среду и под нее язык?

T>><lj user=lex_kravetski>, например. Во всём остальном он не дурак, однако тут — вот такой, какой есть.
VD>Не очень известная личность, по словам гугля.

http://blogs.yandex.ru/top?username=lex_kravetski#lex_kravetski

82-е место по рейтингу Яндекс-блогов.

У меня, например, >7000.

T>>Да и здесь хватает. "Хаскель? А среда под него есть? Ну, я без среды не могу."

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

Это чёткое доказательство того, что люди предпочитают средство автоматизации языку.

Это как если бы в школе ученик заявил, что без доступа к Mathematica он не будет изучать производные.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[12]: Жизнь без IDE
От: Аноним  
Дата: 02.10.09 10:09
Оценка: +1
Здравствуйте, FR, Вы писали:

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


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


Хотелось бы конкретных примеров. Пока больше похоже на утверждение, что некоторое масло более масленное, чем какое-то другое.
Re[11]: Жизнь без IDE
От: thesz Россия http://thesz.livejournal.com
Дата: 02.10.09 10:36
Оценка: :)
Здравствуйте, VladD2, Вы писали:

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


M>> А кому это надо? Зачем голову чушью забивать?

VD>Дык если этих "монстров" не развести на разговор, то создается впечатление, что они вбивают код прямо в командйной строке (включив перенаправление в файл).

Да...

Но откуда ты узнал? Мой домашний макинтош даже не подключен к интернету.

------------
$cat — >A.hs
-- |A
-- An A module.

module A where

import qualified Data.Map as Map

mlookup = Map.lookup
^D
$xce A.hs
------------

xce — вызов XCode дял редактирования.

Типичная сессия в начале чего-нибудь.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[13]: Жизнь без IDE
От: FR  
Дата: 02.10.09 12:16
Оценка: -1
Здравствуйте, VladD2, Вы писали:


FR>>Влад ты же все знаешь, и про монады читал, и ML модули я тебе пару лет назад разъяснял, но почему-то не хочешь понять


VD>Модули вещь исключительно структурная, к ФЯ ни каким боком не имеющая.


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

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


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

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


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


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


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

FR>>Хорошая структурная это практически ОО,


VD>Бред полнейший.


Нет лучший структурный сишный код который я видел во многом эмуляция ООП.

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


VD>А. Ясно. Ты в терминологии плаваешь. Структурная декомпозиция не имеет никакого отношения к структурам.

VD>Учи мат.часть http://en.wikipedia.org/wiki/Decomposition_(computer_science)

Нет я не плаваю, это ты не читаешь что тебе пишут.

VD>Если ты под "функциональной декомпозицией" понимаешь процесс дробления функций, то я тебя расстрою — это метод структурной декомпозиции. Короче ссылку я тебе уже дал.


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

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


Угу только ты в упор не видишь аргументов.

FR>>Зато лучше в том что могут давать информацию в более удобном для восприятия виде.


VD>Это чем же вид то лучше? Ты давно полноценными IDE пользояался?


Тем что дают и общий вид системы и возможность детализации.

VD>Ага. Твое мнение — это объективно, а мое — субъективно.


У обоих субъективно.

VD>Кому в голову взбредет лезть в репл для поиски имени функции если есть комплит и навигация?


Многие REPL'ы имеют комплит, а некторые и навигацию
Re[11]: Жизнь без IDE
От: vshabanov http://vshabanov-ru.blogspot.com
Дата: 02.10.09 12:22
Оценка: +1
Здравствуйте, VladD2, Вы писали:

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


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


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


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


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


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

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

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

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

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

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

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

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


Тем, что эту ф-ию не запустишь отдельно от всего остального и не потестишь.
Re[7]: Жизнь без IDE
От: dr.Chaos Россия Украшения HandMade
Дата: 02.10.09 13:37
Оценка: -1
Здравствуйте, VladD2, Вы писали:

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


Простые рефакторинги, т.е. те что можно автоматизировать, они и так делаются очень быстро, а сложные и объёмные автоматизации не поддаются. Мало того ИМХО рефаторинг это довольно творческое занятие, потому что рефакторинг делают вкупе либо с внесением новых фич, либо с правкой багов, а сам по себе он не нужен.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[16]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.10.09 19:53
Оценка: +1
Здравствуйте, vshabanov, Вы писали:

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


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

Сижу переписываю код генерации fake-исходников для эмуляции GOTO когда реальных исходников нет или неизвесно где они лежат.

Какие задачи передо мной стоят?

1. Найти место которое нужно изменить.
2. Подумать как это лучше сделать.
3. Изменить.
4. Протестировать.
5. Если нужно перейти к пункту 2.

Код писал не я. Я только знаю одну входную точку. Что я делаю?
1. Ставлю точку прерывания в это место.
2. Запускаю IDE под отладчиком и выполняю GOTO на тип из системной сборки.
3. Срабатывает прерывание.
4. Брожу по коду и ищу нужное место... О! Нашел.
5. Анализирую это место. Ага! Вижу что не так!
6. Думаю как изменить. Вот тут может потребоваться пойти попить чай, а то и вообще свалить домой и подумать. Но на этот раз все очевидно.
7. Меняю код. При этом у меня работает автодополнение при вооде и в отладчике я вижу реальные типы переменных (язык, таки, поддерживает динамический полиморфизм).
8. Срубаю отладку и жму F5.
9. Пробую переход. О! Работает как надо.

Итак. Я не занимался отладкой как таковой. Мои изменения заработали с первого раза. Но я использовал отладчик и IDE для облегчения свой задачи.

И это не единичный случай. Для меня это тоже самое, что для вас РПЕЛ. Только, пожалуй, мощнее.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Жизнь без IDE
От: IT Россия linq2db.com
Дата: 03.10.09 04:53
Оценка: :)
Здравствуйте, thesz, Вы писали:

T>Это всё теории.

T>Моя практика показывает обратное.

По всей видимости вы вместе со твоей практикой вещи просто уникальные. Вымирающий вид. Любой краеведческий музей через десять лет выделит для вас не то что полку, целый стеллаж!
Если нам не помогут, то мы тоже никого не пощадим.
Re[7]: Жизнь без IDE
От: BulatZiganshin  
Дата: 03.10.09 12:31
Оценка: :)
Здравствуйте, VladD2, Вы писали:

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


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


VD>То что ты не видел говнокода (или не видишь его в своих проектах) говорит только об одном — ты работаешь один над относительно мелкими проектами.


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


которых почти нет на ФП. а ты прям как личное оскорбление это воспринял
Люди, я люблю вас! Будьте бдительны!!!
Re[15]: Жизнь без IDE
От: thesz Россия http://thesz.livejournal.com
Дата: 03.10.09 21:22
Оценка: +1
Здравствуйте, IT, Вы писали:

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


IT>>>По всей видимости вы вместе со твоей практикой вещи просто уникальные. Вымирающий вид. Любой краеведческий музей через десять лет выделит для вас не то что полку, целый стеллаж!


T>>Наоборот.

T>>Мы племя младое, незнакомое!

IT>Это племя известно науке со времён возникновения самой науки. Имя этому племени "Первый парень на деревне". Характерные особенности: красный диплом (или как минимум красные глаза от учёбы) в институте (опционально), длительная работа в замкнутом окружении в качестве главной/самой важной персоны, в результате завышенная самооценка и непоколебимая уверенность в собственной гениальности, неумение и нежелание работать в команде равных, переходящие в паническую боязнь.


Да, мне известны такие товарищи.

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

Особенно мне было приятно, когда мои коллеги высоко отозвались о моём умении работать в команде. Лично я думал, что я хреновый командный игрок, ан нет!
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[22]: Жизнь без IDE
От: MigMit Россия http://migmit.vox.com
Дата: 04.10.09 15:42
Оценка: +1
Здравствуйте, thesz, Вы писали:

MM>>Ищи его теперь в модуле B.


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


При компиляции чего? Модуля A — не скажут. Модуля B — скажут. Через несколько дней. Когда у тебя до него руки дойдут.

MM>>И в B ничего менять не надо.


T>Это если они сводимы друг к другу.


Естественно.

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

MM>>Как обычно — немного усложнишь поначалу, зато облегчишь потом.


T>Если у меня структура данных меняется (а она меняется на протяжении всего проекта, практически), то это "немного усложнишь поначалу" означает постоянное повышение сложности на всём времени проекта.


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


Поясни. Я думал, что это преобразование как раз означает СМЕНУ структуры данных.
Re[13]: Жизнь без IDE
От: metaprogrammer  
Дата: 05.10.09 20:56
Оценка: -1
Здравствуйте, Cyberax, Вы писали:

VD>>>Ну, почему только про VisualAge. Смолток был в 80-ом и до IBM-а.

M>> И много на том смолтолке писали?
C>Много.

Не Smalltalk определят лицо индустрии. И сложные задачи решались в основном не на нём. Да, блин, сложные задачи решались (и сейчас решаются) даже на Фортране!

M>> IDE были не нужны, и вдруг разом стали нужны, так что ли?

C>Не совсем. До где-то середины 90-х сложные IDE были невозможны на x86 технически. Но даже простые IDE типа Turbo Pascal'а/Borland C++ уже в ту пору рулили.

Да ну, какие это на фиг IDE? Редактор с запускалкой компилятора и хелпа и подсветкой ошибок. Ничего из того, о чём тут говорит Влад, там и близко не было. Никакого автоматизированного рефакторинга, никакого автокомплита и прочих сомнительных прелестей.

C>Они просто подняли производительность труда и снизили планку входа.


А всякие там emacs на пару с sed и awk на ещё большие высоты поднимали производительность труда. И что?

M>> Это не так. Преимущественно куда как более сложные, чем сейчас.

C>Какие?

Библиотек мало было, все постоянно велосипеды сложные изобретали. Кодирования из готовых кубиков не существовало как класса, а сейчас 90% программирования — сборка из готовых кубиков.

VD>>> То что тогда казалось подвигом, сейчас обычное дело.

M>> Примерчик можно?
C>Отладка кода в режиме ядра, к примеру. Сейчас я спокойно это делаю символьным отладчиком из IDE.

Это частности.
Re[16]: Жизнь без IDE
От: geniepro http://geniepro.livejournal.com/
Дата: 06.10.09 05:36
Оценка: +1
Здравствуйте, metaprogrammer, Вы писали:

M> В ML модули параметризованные.


В Аде тоже (родовые пакеты).
Re[11]: Жизнь без IDE
От: demao  
Дата: 25.10.09 13:02
Оценка: -1
Здравствуйте, VladD2, Вы писали:
VD>Если ты сайтики лепишь с посещаемостиью в 10 человек в день, то конечно все ОК. А если сложное приложение (GUI, сложная логика или высоконагруженное), то ты приплыл.

Ээ.. "Высоконагруженное" и "отладчик" — это взаимоисключающие вещи... Как простой пример: timeout транзакции в j2ee равен 30 секунд. И что можно успеть сделать в отладчике за такое время?.. тут только логи помогут.. Ну или repl — запустить выполнение в нем можно быстро, если предварительно выделить весь тест в процедуру.
Re[15]: Жизнь без IDE
От: Cyberax Марс  
Дата: 26.10.09 16:08
Оценка: +1
Здравствуйте, LaPerouse, Вы писали:

LP>>>А я считаю что заблуждаются те, кто считают IDEA едва ли не вершиной совершенства. Да,редактор кода может получше будет, однако совокупная мощь платформы Eclipse задавит кого хочешь.

C>>Нет, это Eclipse — помойка несовместимых плугинов. До интегрированности IDEA ей как до Луны.
LP>Ну если в идеа имеется два с половиной плугина, что там интегрировать-то?
Реализация Scala сделана в виде плугина. Как и большая часть внутренностей самой IDEA.

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

Ага, так как нету интеграции-то.

В IDEA есть общая система представления кода в виде AST, которую используют все плагины. Это позволяет делать:
1) Injected languages (скажем, подсветку и отладку regex'ов внутри литералов)
2) ПОЛНЫЙ рефакторинг. Т.е. мой плугин просто подписывается на оповещения узлов AST, и обрабатывает их соответствующим образом. Так что я могу вызвать переименование класса, редактируя конфиг Spring'а или mapping-файл в Hibernate.

LP>>>К тому же открыли только небольшую часть проекта.

C>>Достаточну для разработки на Scala.
LP>И что, плагином для скалы можно пользоваться?
Да. Причём вполне удобно.
Sapienti sat!
Re[8]: Жизнь без IDE
От: LaPerouse  
Дата: 26.10.09 16:19
Оценка: :)
Здравствуйте, thesz, Вы писали:

T>~100 КБ на Eclipse.

T>Резюме?
T>Байда.

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

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

T>И привет!

Чего-чего? Эклипс автоматически создает такой класс:

/**
 * 
 */
package eNet.calc_module_integration;

/**
 * @author lprs
 *
 */
public class CalcMode
{
}


И пустой метод заглушку при создании метода Или ты думал что эклипс сам еще код пишет

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


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


Эти рутинные задачи были, есть и будут всегда. Программирование — на 50 процентов рутинная работа. Состоит из создания новых модулей, файлов, вбивания кода. Еще процентов 20 — анализ написанного тобой или кем-то другим. И среда разработки призвана как раз облегчить эту техническую работу, занимающую в виме 70 процентов времени, а в эклипсе — процентов 35.
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[9]: Жизнь без IDE
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 26.10.09 16:31
Оценка: :)
Здравствуйте, VladD2, Вы писали:

L>>А мне вот после vim-а в Эклипсе неудобно. И да, я много пишу на Java.

VD>В vim-е?

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

Есть и плюсы, кстати — чаще генерирую код
Re[9]: Жизнь без IDE
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 26.10.09 16:38
Оценка: :)
Здравствуйте, LaPerouse, Вы писали:

LP>Чего-чего? Эклипс автоматически создает такой класс:


LP>
LP>/**
LP> * 
LP> */
LP>package eNet.calc_module_integration;

LP>/**
LP> * @author lprs
LP> *
LP> */
LP>public class CalcMode
LP>{
LP>}
LP>


Кстати! Может интересно будет. У меня в vim-е вот такие сниппеты тоже были. А потом я почему то перестал их использовать (ну разве что для getter/setter-ов — это же просто ужас какой то). Написать, конечно, медленнее, но на мою производительность совершенно не влияет, кажется.

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

LP>И пустой метод заглушку при создании метода Или ты думал что эклипс сам еще код пишет


http://lomeo.livejournal.com/24990.html
Практически всё можно автоматизировать — варианты единственны. Это часто в Haskell.

LP>Эти рутинные задачи были, есть и будут всегда. Программирование — на 50 процентов рутинная работа. Состоит из создания новых модулей, файлов, вбивания кода. Еще процентов 20 — анализ написанного тобой или кем-то другим. И среда разработки призвана как раз облегчить эту техническую работу, занимающую в виме 70 процентов времени, а в эклипсе — процентов 35.


На 90% программирование — написание постов в рсдн.
Re[24]: Жизнь без IDE
От: deniok Россия  
Дата: 26.10.09 16:50
Оценка: :)
Здравствуйте, lomeo, Вы писали:

L> Ну как мы программы на Яве пишем?


Ну ты, похоже, их автоматически генерируешь из Хаскелла
Re[16]: Жизнь без IDE
От: LaPerouse  
Дата: 27.10.09 15:17
Оценка: :)
Здравствуйте, lomeo, Вы писали:

L>Здравствуйте, Mr.Cat, Вы писали:

L>Про vim. Хотя изначально я сидел на emacs. Там поддержка Haskell сильнее, если нет разницы какой редактор использовать, то иди на emacs лучше.

Правильнее будет сказать — иди в emacs. Хотя твой образ мысли мне тоже нравится
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[16]: Жизнь без IDE
От: z00n  
Дата: 27.10.09 18:21
Оценка: +1
Здравствуйте, LaPerouse, Вы писали:

LP>Для языков без поддержки IDE я рекомендую использовать прекрасный редактор с открытыми кодами Notepad++. Им реально можно пользоваться (в отличие от emacs/vim/etc).


Я под win регулярно использую Notepad++ для просмотра кода по правой кнопке — но редактировать в нем код? Вместо emacs?! У N++ даже поиск работает через зад; и aspell прикручивается через зад и шрифты скачут по ширине.
Если уж не emacs-vim — можно использовать Jedit(http://www.jedit.org) — он еще туда-сюда.
Re[17]: Жизнь без IDE
От: thesz Россия http://thesz.livejournal.com
Дата: 28.10.09 07:21
Оценка: +1
Здравствуйте, LaPerouse, Вы писали:

T>>Сборка — это часть разработки.

T>>Кстати, влияющая на многие стороны разрабатываемого проекта.
LP>Сборка — это сборка. И к эклипсу это не имеет никакого отношения. Все. Точка. Признай наконец-то что сказал чушь.

Вообще-то имеет.

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

T>>Вот скажи, ты .bat файлами пользуешься?

T>>Если пользуешься, они компилируются в Java байт-код?
T>>Так и здесь — на Agda2 ты можешь делать ответственные вещи. Из которых получаются Java классы. Которые ты используешь в других местах твоего проекта.
LP>Нет, спасибо. Генерят код для жабы те, кто не умеет на ней писать.

Да-да. А компиляторами из Си в ассемблер пользуются те, кто не умеет писать на ассемблере.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[20]: Жизнь без IDE
От: dr.Chaos Россия Украшения HandMade
Дата: 28.10.09 08:10
Оценка: +1
Здравствуйте, LaPerouse, Вы писали:

LP>А какова твоя версия появления двух режимов?


Ну начнём с того что их далеко не 2.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[24]: Жизнь без IDE
От: thesz Россия http://thesz.livejournal.com
Дата: 28.10.09 17:04
Оценка: :)
Здравствуйте, lomeo, Вы писали:

L>Я думаю, с первого раза даже у thesz не получалось


Ха!

Полтора года ломал голову.

Да и сейчас ещё не очень силён.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.09.09 14:16
Оценка:
Здравствуйте, D. Mon, Вы писали:

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


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

Мне периодически приходится писать писать код без поддержки IDE. Не скажу, что это очень трудно. Но определенный дискомфорт испытываю. Помогает отладчик. Когда в отладчике видишь структуру данных, то конечно проще написать несколько строк кода, но потом без многократных итераций "компиляция <-> правка" не обходится. Если же код пишется в IDE, то компиляция в большинстве случаев проходит с первого раза, да и отладка требуется реже.
Недавно переписывал части кода в интеграции немерла и был момент когда в IDE не было части функций. Например, не работали хинты к методам. При этом можно было бы смотреть типы выражений (в том числе и типов... то что тут назвали "мегафичей"), но вот списка перегрузок (описания параметров для каждой из перегрузок) получить было нельзя. Так вот даже это уже замедлило работу в несколько раз, так как пришлось лазить и выяснять описания типов для каждого метода. Эта проблема не так актуальна в языках основанных на алгоритме хиндли-миллера, так так полноценной перегрузки в них нет (не считая расширений вроде классов типов), но все же и в них приходится лазить по модулям и выяснять описания функций. А это время и нервы которые лучше потратить на разработку и отладку алгоритмов.
Когда я слышу про отладку... что мол она не нужна, то тоже как-то смешно становится. Мне не понятно как можно разбираться с чужим, объемистым, кодом в условиях когда нет ни отладчика, ни даже полной информации о типах. Ну, а в таких языках как Haskell и F# где есть или намеки на перегрузку (классы типов) или почти полноценная перегрузка (как F#) отладка, на мой взгляд вообще необходима.

Посему послушать моснстров которым "все эти баловства" (с) не нужны, было бы очень интересно.
Так что если кто-то может поделиться, то не стесняйтесь. Это очень интересно!
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Жизнь без IDE
От: vshabanov http://vshabanov-ru.blogspot.com
Дата: 27.09.09 14:51
Оценка:
Здравствуйте, D. Mon, Вы писали:

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


V>>* killer feature -- показывает типы отдельных частей выражения (надо компилить с опцией -dtypes), очень удобно при поиске ошибок (можно посмотреть код вокруг ошибки и понять где типы раходятся) и при разбирании в коде.


DM>В OcaIDE это тоже есть.


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

V>>Замечу, что никакой class browser, autocomplete с анализом кода (типа выдать методы после точки) не нужны и не используются.


DM>Удивительно! Для меня такой автокомплит стал наоборот очень большой подмогой, скорость и удобство разработки возросла очень сильно по сравнению с обычным редактором с подсветкой.


Я как-то пробовал окемл с автокомплитом (только вроде это был не OcaIDE, а какой-то режим для eclipse). В принципе в меру удобно, но кроме этого автокомплита там была еще система проектов, вместо Makefile, ну и еще всякие привычные вещи из emacs отсутсвовали. В общем я посчитал, что не стоит оно того, чтобы изучать другую IDE.

V>>Знаю нескольких человек, пишущих на Хаскеле в FAR-е, и по своей производительности они сделают любого программиста, сидящего в навороченной IDE.


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


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


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

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

Про ненужность IDE. Действительно у окемла IDE уровня VS нет. Да и отладчик там под виндой как-то непросто заставить работать. В начале я тоже как-то думал "а где бы мне IDE нормальную надыбать". Но в итоге я теперь и для C++/Java кода никакой IDE и отладчиком не пользуюсь. Стиль разработки сменился.
Re[2]: Жизнь без IDE
От: Don Reba Канада https://stackoverflow.com/users/49329/don-reba
Дата: 27.09.09 15:03
Оценка:
Я пишу в на Яве в Эклипсе, Шарпе в Студии и Немерле в Виме. В целом, эффективность ввода текста в Виме полностью компенсирует необходимость чаще переключаться на окно со справкой. С автодополнением было бы лучше, но всё как-то лень его прикрутить.
Ce n'est que pour vous dire ce que je vous dis.
Re[4]: Жизнь без IDE
От: Don Reba Канада https://stackoverflow.com/users/49329/don-reba
Дата: 27.09.09 15:08
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Это лишь означает, что ты не умеешь пользоваться IDE.


Обоснуй.
Ce n'est que pour vous dire ce que je vous dis.
Re[3]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.09.09 15:09
Оценка:
Здравствуйте, samius, Вы писали:

S>Хиндли — Милнера


Это не важно. Да и звучит прикольнее .
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.09.09 15:11
Оценка:
Здравствуйте, Cyberax, Вы писали:

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

C>Это лишь означает, что ты не умеешь пользоваться IDE.

Я тоже так считаю, но ОЧЕНЬ хотел бы услышать развернутую аргументацию от тех кто так не считает. Жаль, что все заканчивается на пустых декларациях.

Народ! Поделитесь, плиз!
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Жизнь без IDE
От: Cyberax Марс  
Дата: 27.09.09 15:15
Оценка:
Здравствуйте, Don Reba, Вы писали:

C>>Это лишь означает, что ты не умеешь пользоваться IDE.

DR>Обоснуй.
В ViM'е нет: онлайновой подсветки ошибок и вывод результатов инспекций, рефакторинг, отладка, банальный переход по типу.

А сказки про "скорость ввода" не надо мне рассказывать. Я уже не помню чего в ViMе было бы, чего нет в той же IDEA. Там есть и прямоугольные выделения, и кольцо буфферов обмена, закладки, возможность повторять N последних действий.
Sapienti sat!
Re[5]: Жизнь без IDE
От: Don Reba Канада https://stackoverflow.com/users/49329/don-reba
Дата: 27.09.09 15:22
Оценка:
Здравствуйте, VladD2, Вы писали:


VD>Я тоже так считаю, но ОЧЕНЬ хотел бы услышать развернутую аргументацию от тех кто так не считает. Жаль, что все заканчивается на пустых декларациях.


Заглядывать в справку требуется только изредко. Как это действие не ускоряй, его влияние на производительность ограничено. Мой опыт говорит, что оно и не велико.
Ce n'est que pour vous dire ce que je vous dis.
Re[2]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.09.09 15:25
Оценка:
Здравствуйте, vshabanov, Вы писали:

V>Про ненужность IDE. Действительно у окемла IDE уровня VS нет. Да и отладчик там под виндой как-то непросто заставить работать. В начале я тоже как-то думал "а где бы мне IDE нормальную надыбать". Но в итоге я теперь и для C++/Java кода никакой IDE и отладчиком не пользуюсь. Стиль разработки сменился.


Ну, так и расскажи нам про этот стиль.
Я вот иногда вынужден писать оноситльно большие куски кода без IDE (в расширенном смысле этого слова) и испытываю дикий дискомфорт. То что я мог бы сделать за 5 минут в IDE требует десятков минут, а то и часов когда делаешь это "вручную".
Дико интересно как народ умудряется без этого всего обходиться. Причем не заявления, а именно рассказ...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Жизнь без IDE
От: Don Reba Канада https://stackoverflow.com/users/49329/don-reba
Дата: 27.09.09 15:41
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>В ViM'е нет: онлайновой подсветки ошибок и вывод результатов инспекций, рефакторинг, отладка, банальный переход по типу.


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

C>А сказки про "скорость ввода" не надо мне рассказывать. Я уже не помню чего в ViMе было бы, чего нет в той же IDEA. Там есть и прямоугольные выделения, и кольцо буфферов обмена, закладки, возможность повторять N последних действий.


В IDEA появилась поддержка Немерле? При чём он тут?
Вим это не пара фич которые достаточно иметь, чтобы быстро печатать. То, что ты его плохо помнишь не повод заявлять, что я не умею пользоваться IDE.
Ce n'est que pour vous dire ce que je vous dis.
Re[7]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.09.09 16:04
Оценка:
Здравствуйте, Don Reba, Вы писали:

DR>Онлайновой подвсетки ошибок и рефакторинга для Немерле вообще нигде нет. Для отладки пользуюсь Студией. Переход по типу есть когда он в том же файле, но вообще, это такая мелочь.


Это как? А чем же я тогда пользуюсь?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Жизнь без IDE
От: Cyberax Марс  
Дата: 27.09.09 16:32
Оценка:
Здравствуйте, Don Reba, Вы писали:

C>>А сказки про "скорость ввода" не надо мне рассказывать. Я уже не помню чего в ViMе было бы, чего нет в той же IDEA. Там есть и прямоугольные выделения, и кольцо буфферов обмена, закладки, возможность повторять N последних действий.

DR>В IDEA появилась поддержка Немерле? При чём он тут?
Я говорил про IDE вообще. Всё перечисленное есть для Scala.

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

Ну я как бы пользовался ViM'ом. Не помню я чего там такого есть замечательного.
Sapienti sat!
Re[2]: Жизнь без IDE
От: VoidEx  
Дата: 27.09.09 16:37
Оценка:
Здравствуйте, VladD2, Вы писали:

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

Я так не считаю, но напишу.

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

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

VD>Помогает отладчик. Когда в отладчике видишь структуру данных, то конечно проще написать несколько строк кода, но потом без многократных итераций "компиляция <-> правка" не обходится. Если же код пишется в IDE, то компиляция в большинстве случаев проходит с первого раза, да и отладка требуется реже.

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

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

Лазить не приходится, модули обычно небольшие, в одно окно браузера умещаются. Хинты были бы полезны, если бы не одно но, нужно уже знать, что где-то какая-то функция нужная есть, а где именно — ты не помнишь, вот тогда да. Было бы полезно иметь хинты с возможностью поиска и встроенной доки (hayoo + hoogle, например), а ещё чтобы можно было модуль скачать; с этим прекрасно справляется обычный браузер, резкого улучшения производительности, скорее всего, не будет; но leskah я, может, и поставил бы, когда его допилят, но именно из-за hayoo + hoogle.

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

А ты не смейся, и правда не нужна. Т.е. как без нее жить в C++/C#/... я и сам не представляю, а в Хаскеле мне не была нужна ни разу.
VD>Мне не понятно как можно разбираться с чужим, объемистым, кодом в условиях когда нет ни отладчика, ни даже полной информации о типах.
Ну почему ж нет, документации достаточно, а благодаря чистоте, функции и модули часто изолированны настолько, что можно исправлять, не боясь задеть что-то ещё.

VD>Ну, а в таких языках как Haskell и F# где есть или намеки на перегрузку (классы типов) или почти полноценная перегрузка (как F#) отладка, на мой взгляд вообще необходима.

Зачем отладка? Как наличие перегрузки (классов типов) влияет на необходимость отладки?

VD>Посему послушать моснстров которым "все эти баловства" (с) не нужны, было бы очень интересно.

Я не монстр, и сам с трудом представляю написание кода в C++ без IDE. Да и без ассиста геморройно, но вот как-то так получается, что в Хаскеле с этим проблем нет.
Re[8]: Жизнь без IDE
От: Don Reba Канада https://stackoverflow.com/users/49329/don-reba
Дата: 27.09.09 16:37
Оценка:
Здравствуйте, VladD2, Вы писали:

DR>>Онлайновой подвсетки ошибок и рефакторинга для Немерле вообще нигде нет.


VD>Это как? А чем же я тогда пользуюсь?


Уже есть? Это большой плюс. Интересно, какие возможности рефакторинга реализованы?
Ce n'est que pour vous dire ce que je vous dis.
Re[3]: Жизнь без IDE
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 27.09.09 16:55
Оценка:
Здравствуйте, VoidEx, Вы писали:

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


В F# REPL имеется, и в студии неплохо поддержан.
Re[6]: Жизнь без IDE
От: BulatZiganshin  
Дата: 27.09.09 17:04
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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

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

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

как я работаю в фаре: отладка, как уже говорил, printf'ами. вместо автокомплита копирую имена переменных/функций или набираю их сам (имена из станд. библиотек и моих собственные мелких хелперов невелики по размеру, это тебе не system.console.writeln ). если мне нужно найти определение какой-то функции, то использую поиск по файлам. для хелпа по сишным функциям использую google
Люди, я люблю вас! Будьте бдительны!!!
Re[9]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.09.09 17:18
Оценка:
Здравствуйте, Don Reba, Вы писали:

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


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

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


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

Подсветка ошибок в реальном времени есть уже очень давно. Сейчас она работает лучше, так как я этот участок серьезно переписал (с учетом полученных знаний о компиляторе).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Жизнь без IDE
От: BulatZiganshin  
Дата: 27.09.09 17:34
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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


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

в хаскеле я такого думаю не делал ни разу. объявление одинаковых идентификаторов в разных модулях прикладной программы здесь очень редкая практика
Люди, я люблю вас! Будьте бдительны!!!
Re[4]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.09.09 18:07
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

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


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

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

Все тоже самое в интеграции занимает существенно меньше времени. Все эти итерации не нужны. Сразу видишь, что за типы вывелись даже если ты точно не помнил сигнатуры функций. Навигация по коду позволяет молниеносно переходить к реализациям и смотреть, что там не так или менять их. Подсветка ошибок позволяет не лепить горбатого и не ждать минутами перкомпиляции. Автодополнение позволяет видеть какие методы есть у данной переменной (тип которой не нужно держать в голове). Список перегрузок позволяет правильно заполнять список параметров не тратя время на лазанье по хелпу.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.09.09 18:12
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

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


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

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


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

Ну, и в хаскеле есть что автоматизировать. Скажем, никогда не поверю, что в хаскеле не возникает необходимость сделать из локальной функции глобальную (преобразовав неявные замыкания в явные параметры и т.п.).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Жизнь без IDE
От: MigMit Россия http://migmit.vox.com
Дата: 27.09.09 18:24
Оценка:
Основная среда разработки: Emacs.

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

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

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

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

Каждый модуль, как правило, перезагружается в REPL постоянно, по нескольку раз на каждую функцию (причём все недописанные места заменяются на undefined). Поэтому идёт постоянный контроль правильности типов. Если где-то типы не сошлись — это исправляется за несколько секунд.
Re[8]: Жизнь без IDE
От: VoidEx  
Дата: 27.09.09 20:04
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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


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

VD>Ну, хотя бы по этому поводу спору нет.

VD>А у хаскеля хороший отладчик? Где можно на него глянуть?
Тут

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

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

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

А у меня сложилось впечатление, что большую часть времени некоторым приходится набивать код. Не там узкое место, ой не там.
Re[5]: Жизнь без IDE
От: BulatZiganshin  
Дата: 27.09.09 20:30
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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


да, насчёт говнокода я попал в самую тютельку
Люди, я люблю вас! Будьте бдительны!!!
Re[8]: Жизнь без IDE
От: dmz Россия  
Дата: 28.09.09 05:36
Оценка:
VD>В общем, из услышанного у меня сложилось впечатление, что ты описываешь работу с проектом относительно небольшого размера, который пишиется одним-двумя человеками и который можно полностью заложить в мозг одного человека. Но что делать с проектами где есть миллионы строк кода и который разработывают десятки человек?

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

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

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


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

У нас в команде используется Erlang, OCaml, Javascript, C, Beep --- и как-то все обходятся без IDE, жалоб не поступает. Опять же, непонятно как быть с IDE, если используешь несколько языков. Мало какие IDE достойно поддерживают несколько языков, и как быть? Для каждого языка --- привыкать к своей IDE? Мозг жалко, в т.ч. спинной. А как быть, если используются разные системы сборки? scons, cmake или какая-нибудь вообще своя? Прогибать весь проект под IDE, используя только те средства, которые они поддерживают?
Re[2]: Жизнь без IDE
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 28.09.09 06:51
Оценка:
Здравствуйте, VladD2, Вы писали:

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


Если идёт обработка больших массивов данных (видео, например), то отладчик только мешает. Логи, логи, логи. Да и структуры данных в таком случае низкоуровневые и интуитивно понятные. Подсветки синтаксиса достаточно.
Re[3]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.09.09 07:18
Оценка:
Здравствуйте, Nuzhny, Вы писали:

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


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


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

В той же обработке видео может быть некий сложный алгоритм фильтрации или еще что-то. Иначе — это просто примитивная задача которая не требует высокоуровенвых средств разработки. Тогда уж было бы разумно выбрать в качестве языка разработки С с поддержкой современного ассемблера.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.09.09 08:03
Оценка:
Здравствуйте, dmz, Вы писали:

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


Извини, но это опять декларации. Меня не интересует то что кто-то не использует полноценной IDE. Меня интересует то как при этом происходит процесс работы с проектом. И то какая при этом получается производительность труда (сравнительно с аналогичным проектом поддерживаемым в IDE). А в твоем рассказе одни декларации.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Жизнь без IDE
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 28.09.09 08:26
Оценка:
Здравствуйте, VladD2, Вы писали:

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

VD>Это — не аргумент.

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

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


Нет, лучше выбрать современный компилятор С++ (от Интела подойдёт), ручной ассемблер он, как правило, обгоняет. Сейчас, вот, CUDA рассматриваю. Но и в этом случае ассемблер не применяется.
Для сложных же фильтров просто выходит больше логов: сохраняются промежуточные результаты (то есть изображения) на каждом этапе обработки. Чем тут поможет отладчик? В шестнадцатеричном виде кусок памяти не так информативен.
Re[5]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.09.09 08:36
Оценка:
Здравствуйте, Nuzhny, Вы писали:

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

VD>>Это — не аргумент.

N>Почему же не аргумент?


Потому, что задачи разные бывают.

N>Нет, лучше выбрать современный компилятор С++ (от Интела подойдёт),


Это все равно С. Только компилятор более оптимизирующий.

N>ручной ассемблер он, как правило, обгоняет.


Ага. Если уровень знания этого ассемблера сильно ниже уровня знаний разработчика компилятора.
А если пишет человек со знаниями, то в тонких местах он сможет выжать очень не мало. Оптимизатор омпилятора принципиально ограничен, так как не умет думать и учиться на ошибках.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Жизнь без IDE
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 28.09.09 08:52
Оценка:
Здравствуйте, VladD2, Вы писали:

N>>Почему же не аргумент?

VD>Потому, что задачи разные бывают.

Разумеется. Я же и писал для каких задач.

N>>Нет, лучше выбрать современный компилятор С++ (от Интела подойдёт),

VD>Это все равно С. Только компилятор более оптимизирующий.

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


N>>ручной ассемблер он, как правило, обгоняет.

VD>Ага. Если уровень знания этого ассемблера сильно ниже уровня знаний разработчика компилятора.

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

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


Зато это умеют делать его создатели. В чём ты хочешь меня убедить? Что надо писать реализации на ассемблере нетривиальных алгоритмов? Причём писать эти реализации для каждой новой архитектуры процессора? Причём при наличии самого лучшего компилятора в мире, который меня устраивает?
Не утруждай себя.
Да и вообще, это оффтоп. Я рассказал какие логи применяю и почему мне это выгодней, чем пользоваться отладчиком из IDE. Как раз, по теме.
Re[10]: Жизнь без IDE
От: FR  
Дата: 28.09.09 09:02
Оценка:
Здравствуйте, VladD2, Вы писали:

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


Ну могу свой пример привести, нужно было в достаточно большой чужой проект (3D игра на C++) внести некоторые изменения, и исправить пару багов, при этом с движком на котором она написана мы были незнакомы. Использовать IDE не было возможности, так как игра компилировалась под windows и некоторые не PC устройства, компилятор допотопный даже тогда клон GCC, нормальных IDE под него тогда просто не было (тот же плугин для эсклипса был только в зародыше). Использовали обычные текстовые редакторы и сгенерировали doxygen'ом "документацию" с полным включением всех исходников и включенной опцией навигации по исходникам (помню чуть ли не десять часов генерировалось ) Этого вполне хватило для нормальной работы. С отладкой да пришлось пока не привыкли помучатся с логами.
Производительность труда в самом начале работы да была очень низкой. К концу работы мало отличалась от производительности при работе с нормальным IDE.
Re[7]: Жизнь без IDE
От: BulatZiganshin  
Дата: 28.09.09 09:12
Оценка:
Здравствуйте, Mirrorer, Вы писали:

M>Представь себе что Хаскел двинул в массы


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

речь идёт о том что
1) чем выше уровень языка, тем больше он даёт возможностей для написания хороших программ. С больше асма, С# больше C и т.д.
2) если посмотреть на то, где больше всего даёт выигрыш ide, то это как раз или плохой код, в котором ни фига не разобраться, или плохой язык приводящий к необходимости отладки, или работа в большом коллективе / с большим числом бибилиотек. ничего этого у нас в общем-то нет, так что без ide можно обойтись
3) более того, ни в чём из вышеприведённого я и не хотел бы участвовать
Люди, я люблю вас! Будьте бдительны!!!
Re[8]: Жизнь без IDE
От: Mirrorer  
Дата: 28.09.09 09:17
Оценка:
Здравствуйте, dmz, Вы писали:

dmz>Спорно, что IDE тут вообще фактор.

IDE это действительно не фактор сама по себе. Фактор это поддержка. И научить студиоса ловить простые баги в мягком розовом цвете вижуалстудийного отладчика гораздо проще чем принтфами. А еще есть штуки как go to Declaration, find ingeritances и прочая, имя им легион.

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

Пожалуй даже соглашусь. Мое мнение заключается в том, что чем больше тупой работы выполняет железяка тем удобнее. Для некоторых проектов объем этой тупой работы выполняемой простым редактором и ИДЕ практически равнозначен. Но для других — иде позволяет автоматизировать тупые операции. Что есть плюс.
Есть хороший пример. Hiew — редактор. IDA — IDE. Задачу анализа чужого кода можно выполнить и там и там. Но есть нюанс (С).

dmz>Примеры поддержки больших проектов без него есть.

Можно конкретные примеры ?
emacs, если что, за пример не катит. Для лиспа он вполне себе ИДЕ.

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

dmz>это и причина, по которой он никогда не станет мейнстримом.
Как знать как знать. Напишут дсл с крутой монадой VisualBasic. И моск включать не придется. Я, канеш, утрирую, но в каждой шутке есть доля шутки.
Re[2]: Жизнь без IDE
От: dmz Россия  
Дата: 28.09.09 09:21
Оценка:
VD>Кстати, я бы с огромным удовольствием послушал бы тех кто считает, что IDE с разными автодополнениями не нужны как класс. Интересно как у них построен процесс разработки? Как они получают информацию о внешних типах и функциях которые нужно вызвать?

Ну вот единственный кейс. Посмотреть тип какой-нибудь сущности. Несколько путей: нажать на кнопку, и vim перейдет к месту, где эта сущность объявляется, т.к. подцеплены ctags.

Второй — сделан alias, который грепает по заголовкам дерева проекта и показывает декларацию.
Re[8]: Жизнь без IDE
От: Mirrorer  
Дата: 28.09.09 09:45
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

BZ>1) чем выше уровень языка, тем больше он даёт возможностей для написания хороших программ. С больше асма, С# больше C и т.д.

категорически не могу не согласиться Но к иде этот пункт имеет слабое отношение.

BZ>2) если посмотреть на то, где больше всего даёт выигрыш ide, то это как раз или плохой код, в котором ни фига не разобраться, или плохой язык приводящий к необходимости отладки, или работа в большом коллективе / с большим числом бибилиотек.

BZ>ничего этого у нас в общем-то нет, так что без ide можно обойтись
Я бы заметили что ничего этого у нас пока нет. При достаточно большой пользовательской базе и количестве библиотек эти вопросы так или иначе выплывут на поверхность. Кустарное написание Хаскел шедевров мастерами заменится промышленными кодогенараторами или программными или индийскими. Такие дела. Это конечно если Хаскелл получит большое распространение. Но рекламная акция поставь [: :] вокруг списка и получи автоматическое распараллеливание квиксорта, поддерживаемая книгами типа RWH может возыметь действие.
Re[5]: Жизнь без IDE
От: thesz Россия http://thesz.livejournal.com
Дата: 28.09.09 09:45
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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

C>>Это лишь означает, что ты не умеешь пользоваться IDE.

VD>Я тоже так считаю, но ОЧЕНЬ хотел бы услышать развернутую аргументацию от тех кто так не считает. Жаль, что все заканчивается на пустых декларациях.


Что ты считаешь непустыми декларациями, определись.

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

Лично мне было бы интересней услышать, как автодополнение и дерево классов позволяют лучше структурировать тот код, что ты сейчас пишешь, и в котором потом будешь разбираться. Или кто-то будет разбираться. Или кто-то пишет сейчас, а ты будешь разбираться потом.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[9]: Жизнь без IDE
От: BulatZiganshin  
Дата: 28.09.09 09:49
Оценка:
Здравствуйте, Mirrorer, Вы писали:

BZ>>1) чем выше уровень языка, тем больше он даёт возможностей для написания хороших программ. С больше асма, С# больше C и т.д.

M>категорически не могу не согласиться Но к иде этот пункт имеет слабое отношение.

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

кстати, если вспомнить про c++, то он тоже прошёл путь от языка для учёных, изучающих новейшие аспекты ооп, к языку для всех, к языку для высококвалифицированных, но всё же промышленных программистов
Люди, я люблю вас! Будьте бдительны!!!
Re[12]: Жизнь без IDE
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 28.09.09 12:03
Оценка:
Здравствуйте, VladD2, Вы писали:

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


Не понял о чём речь.
Можно пример, что за куча ненужной информации? Что значит вспоминать кодированные имена?
С точкой тоже непонятно. Имеется в виду, что в Haskell нет методов или что?

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


Возникает, конечно! Например, чтобы протестировать отдельно эту функцию, или если она достаточно абстрактна для вынесения наружу. Явное связывание аргументов называется lambda lifting, а сам этот рефакторинг Lift to top level.

Я поставил себе HaRe к vim давным-давно, это система автоматического рефакторинга. Только, если честно, пользуюсь им не часто. lambda lifting — это простое добавление аргументов, а lift to top level — это сдвиг блока влево
Re[10]: Жизнь без IDE
От: Mirrorer  
Дата: 28.09.09 13:19
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

BZ>по мере того, как фп будет продвигаться в массы, всё это разумеется будет теряться

О. Вот и я о том жеж. Консенсус достигнут.

ЗЫ
Представляю себе проекты типа скрестить Хаскелл и 1С... мммммм..
Re[6]: Жизнь без IDE
От: DemAS http://demas.me
Дата: 28.09.09 13:41
Оценка:
"Cyberax" <37054@users.rsdn.ru> writes:

> Я уже не помню чего в ViMе было бы, чего нет в той же IDEA.


Быстродействия. На моем домашнем компе это некритично, но на рабочем
ноуте все преимущества Eclipse/IDEA компенсируются задержками из за их
прожорливости.

А на нетбуке альтернативы emacs/vim я пообще не вижу.
Posted via RSDN NNTP Server 2.1 beta
Re[7]: Жизнь без IDE
От: Cyberax Марс  
Дата: 28.09.09 13:56
Оценка:
Здравствуйте, DemAS, Вы писали:

>> Я уже не помню чего в ViMе было бы, чего нет в той же IDEA.

DAS> Быстродействия. На моем домашнем компе это некритично, но на рабочем
DAS>ноуте все преимущества Eclipse/IDEA компенсируются задержками из за их
DAS>прожорливости.
Ну не знаю, IDEA нынче быстро работать стала на хороших машинах.

DAS> А на нетбуке альтернативы emacs/vim я пообще не вижу.

На нетбуке писать — это уже извращение.
Sapienti sat!
Re[7]: Жизнь без IDE
От: Mr.Cat  
Дата: 28.09.09 14:21
Оценка:
Здравствуйте, DemAS, Вы писали:
DAS> А на нетбуке альтернативы emacs/vim я пообще не вижу.
Кстати, емакс местами тоже прожорлив стал. Сейчас вроде получше, а когда 23-й еще не зарелизен был — у него были-таки проблемы с производительностью.
Re[3]: Жизнь без IDE
От: Mirrorer  
Дата: 28.09.09 15:26
Оценка:
Здравствуйте, thesz, Вы писали:

T>Скажи волшебные :t и :i, и тебе не придётся лазить по модулям.


С типами понятно. А как прыгнуть к реализации эффективно ?

Ну захотелось мне к примеру прыгнуть на реализацию >>= в монаде WierdCompositionMonad.
Предположим что документации у нас нету, а исходники есть.
В студии можно сделать go to declaration. И если из контекста можно однозначно сказать какой именно перегружаемый вариант используется, то прыгнет именно туда.

Да, хорошие имена функций и знание типа функции могут здорово помочь. Но не всегда. Иногда хочется именно что посмотреть на реализацию.

Как такое делается для Хаскеля ?
Re[4]: Жизнь без IDE
От: thesz Россия http://thesz.livejournal.com
Дата: 28.09.09 15:45
Оценка:
Здравствуйте, Mirrorer, Вы писали:

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


T>>Скажи волшебные :t и :i, и тебе не придётся лазить по модулям.


M>С типами понятно. А как прыгнуть к реализации эффективно ?


M>Ну захотелось мне к примеру прыгнуть на реализацию >>= в монаде WierdCompositionMonad.

M>Предположим что документации у нас нету, а исходники есть.
M>В студии можно сделать go to declaration. И если из контекста можно однозначно сказать какой именно перегружаемый вариант используется, то прыгнет именно туда.

Законы монад никто не отменял. Это раз.

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

Поэтому надо минимизировать IO, что выгодно само по себе. Это три.

M>Да, хорошие имена функций и знание типа функции могут здорово помочь. Но не всегда. Иногда хочется именно что посмотреть на реализацию.


M>Как такое делается для Хаскеля ?


*Main> :i Set
data Set a
  = Data.Set.Tip | Data.Set.Bin !Data.Set.Size a !(Set a) !(Set a)
        -- Defined in Data.Set
instance (Ord a, Ord b) => Monad' Set a b
  -- Defined at b.hs:16:9-40
instance (Eq a) => Eq (Set a) -- Defined in Data.Set
instance (Ord a) => Ord (Set a) -- Defined in Data.Set
instance (Read a, Ord a) => Read (Set a) -- Defined in Data.Set
instance (Show a) => Show (Set a) -- Defined in Data.Set


Defined at видишь? Поскольку "иногда хочется", то этого должно быть достаточно всегда. Было бы часто, был бы другой коленкор, но тогда надо выбирать другой язык.

Ещё Haddock умеет вставлять ссылки на исходники (ссылка source справа от названия функции).
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[5]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.09.09 17:18
Оценка:
Здравствуйте, thesz, Вы писали:

T>Defined at видишь? Поскольку "иногда хочется", то этого должно быть достаточно всегда. Было бы часто, был бы другой коленкор, но тогда надо выбирать другой язык.


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

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

Если серьезно, то ты нехотя ответил на многие вопросы. Если выбросить из твоих ответов много букв и бравады, то в них остается одно, но весьма рациональное зерно. Ты вместо возможностей IDE пользуешься похожими возможностями предоставляемыми REPL-ом. Так?

Тогда у меня остается только один вопрос. Если нужные возможности практически есть, то почему бы их не прикрутить к редактору, чтобы не нужно было долбить что-то в командной строке и потом искать что-то в модуле? Ведь, как я понимаю — это вполне возможно и не так уж сложно было бы сделать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Жизнь без IDE
От: Mirrorer  
Дата: 28.09.09 17:46
Оценка:
Здравствуйте, VladD2, Вы писали:

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


Если я правильно помню, то хаскельная мода к емаксу так и делает. она пишет в окошко интерпретатора :i или :t и результат выводит там же. вешается на любой хоткей.
Re[6]: Жизнь без IDE
От: MigMit Россия http://migmit.vox.com
Дата: 28.09.09 17:51
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Другими словами, вместо того чтобы встроить в редактор все необходимое для ускорения и упрощения работы с проектом мы посылаем всех выбирать другой язык?


Естественно. Если язык настолько неудобен, что для работы с ним нужно столько всего навешивать — мы идём выбирать другой язык. Совершенно нормальное поведение, вообще-то.
Re[6]: Жизнь без IDE
От: MigMit Россия http://migmit.vox.com
Дата: 28.09.09 18:21
Оценка:
Здравствуйте, Mirrorer, Вы писали:

T>>Defined at видишь? Поскольку "иногда хочется", то этого должно быть достаточно всегда. Было бы часто, был бы другой коленкор, но тогда надо выбирать другой язык.

M>Зачем другой язык ? Мне кажется емаксовую моду вполне можно этому научить. Он умеет показывать типы функций в подсказках, значит умеет их находить как-то.

Обычный вывод типов. Emacs просто обращается к GHCi.
Re[7]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.09.09 18:49
Оценка:
Здравствуйте, MigMit, Вы писали:

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


Так может в этом и кроется загадка хаскеля? В том смысле, что при весьма лестных отзывах о языке пишут на нем единицы. Возможно как раз дело в том, что это как раз те единицы которые предпочитают спартанский образ жизни?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.09.09 18:50
Оценка:
Здравствуйте, Mirrorer, Вы писали:

M>Если я правильно помню, то хаскельная мода к емаксу так и делает. она пишет в окошко интерпретатора :i или :t и результат выводит там же. вешается на любой хоткей.


Как я понимаю, для того чтобы все эти :i и :t работали, предварительно в интерпретатору нужно скормить содержимое всего проекта. Так?
Сколько это занимает времени?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.09.09 18:52
Оценка:
Здравствуйте, vshabanov, Вы писали:

Поясню оценку.

Она не означает, что я согласен с автором сообщения. Более того по большей части я с ним как раз не согласен.
Оценка за попытку описать технику своей работы. Это многое объясняет... ну, по крайней мере для меня.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Жизнь без IDE
От: thesz Россия http://thesz.livejournal.com
Дата: 28.09.09 19:38
Оценка:
Здравствуйте, VladD2, Вы писали:

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


T>>Defined at видишь? Поскольку "иногда хочется", то этого должно быть достаточно всегда. Было бы часто, был бы другой коленкор, но тогда надо выбирать другой язык.

VD>Другими словами, вместо того чтобы встроить в редактор все необходимое для ускорения и упрощения работы с проектом мы посылаем всех выбирать другой язык?

Объясню.

Часто требуется с другими языками, не с Хаскелем.

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


Потому, что они думают, как ты.

VD>Если серьезно, то ты нехотя ответил на многие вопросы. Если выбросить из твоих ответов много букв и бравады, то в них остается одно, но весьма рациональное зерно. Ты вместо возможностей IDE пользуешься похожими возможностями предоставляемыми REPL-ом. Так?


Даже если и так, то процент моего использования возможностей REPL вне "загрузил-исправил-загрузил-проверил" ниже в разы, чем на других языках.

Собственно, что мною и ценится.

И другими тоже.

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


Именно потому, что ценность в том, что это не нужно.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[8]: Жизнь без IDE
От: Mirrorer  
Дата: 28.09.09 19:40
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Как я понимаю, для того чтобы все эти :i и :t работали, предварительно в интерпретатору нужно скормить содержимое всего проекта. Так?

VD>Сколько это занимает времени?

Я с большими проектами не работал поэтому сказать не могу. Надо будет ради прикола попытаться проделать этот трюк с исходниками самого хаскела. Но для небольших проектов это время неощутимо практически.
Re[8]: Жизнь без IDE
От: vshabanov http://vshabanov-ru.blogspot.com
Дата: 28.09.09 19:51
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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


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


Хм, для меня спартанский образ жизни это FAR и винда (да и то ghci, инет, консоль и make там есть, хотя и не так удобно интегрированы).

Emacs+linux+нормальный wm покруче многих IDE будет. Я может даже и не сильно против всяких браузеров кода и автокомплитов, но моя "IDE" настолько лучше всяких VS и Eclipse-ов, что мне проще обходиться без них (к тому же это делает код лучше .
Re[8]: Жизнь без IDE
От: MigMit Россия http://migmit.vox.com
Дата: 28.09.09 19:56
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Как я понимаю, для того чтобы все эти :i и :t работали, предварительно в интерпретатору нужно скормить содержимое всего проекта. Так?

VD>Сколько это занимает времени?

В разы меньше, чем время загрузки солюшена в студию.
Re[9]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.09.09 20:30
Оценка:
Здравствуйте, vshabanov, Вы писали:

V>Загрузка проекта файлов из 50 занимает несколько секунд. Если делалось что-то хардкорное с типами, то может и полминуты грузить десяток файлов. Делается это один раз, дальше делается :r -- перегрузка текущего модуля -- перегружаются только измененные модули, это уже шустро.


V>Если что-то уж совсем большое, то можно вынести в package (грузится почти мгновенно). Еще можно скомпилить некоторые файлы, если они не меняются (по сути типа локальный пакет получается, но тут есть опасности, что .o не соответствует .hs).


А тебе не хотелось бы, чтобы все это делалось автоматом? Ну, чтобы в бэкграунде давно не изменяемые модули компилировались или помещались в пакет. А измененные чтобы сами перезагружались или перекомпилировались (опять же в бэкграунде)? Ну, чтобы ты тупо выполнил команду :xyz с путем к каталогу проекта и все остальное чтобы сделал REPL?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Жизнь без IDE
От: BulatZiganshin  
Дата: 29.09.09 06:08
Оценка:
Здравствуйте, D. Mon, Вы писали:

DM>И запомнить правильный порядок аргументов (и порядок аргументов у функций-аргументов) у меня никак не получается


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

правда, есть и противоположная тенденция — ставить наиболее значащие аргументы в начало, поскольку split str ';' выглядит как-то более эстетично
Люди, я люблю вас! Будьте бдительны!!!
Re[12]: Жизнь без IDE
От: vshabanov http://vshabanov-ru.blogspot.com
Дата: 29.09.09 09:41
Оценка:
Здравствуйте, D. Mon, Вы писали:

DM>Я вспомнил еще одну фичу IDE, которая мне реально помогает.

DM>Вот есть функции
DM>List.fold_left : ('a -> 'b -> 'a) -> 'a -> 'b list -> 'a
DM>Enum.fold : ('a -> 'b -> 'b) -> 'b -> 'a t -> 'b
DM>Array.fold_left : ('a -> 'b -> 'a) -> 'a -> 'b array -> 'a
DM>Map.fold : (key -> 'a -> 'b -> 'b) -> 'a t -> 'b -> 'b
DM>Hashtbl.fold : ('a -> 'b -> 'c -> 'c) -> ('a, 'b) t -> 'c -> 'c
DM>или например
DM>String.nsplit : string -> string -> string list
DM> nsplit s sep splits the string s into a list of strings which are separated by sep.

В emacs-е для хаскеля показываются типы для ф-ий из prelude. В кемле есть интерпретатор, где можно посмотреть или ocamlbrowser. Попробуй посмотри, сколько времени ты тратишь на поиск типа ф-ии, и сколько времени для забивания её параметров. IDE тут конечно помогает, но это копейки.
Re[8]: Жизнь без IDE
От: dr.Chaos Россия Украшения HandMade
Дата: 29.09.09 09:48
Оценка:
Здравствуйте, VladD2, Вы писали:

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


Я тут влезу немного. Я работаю с проектом которому уже более 15 лет(С/С++), и работали над ним сотни программистов. Конечно та часть которой я посвящал больше всего внимания, написана за последние 4 года, но в ней есть куски старого кода перенесённого из других проектов. Так вот мне в нём ещё не попадались такие куски когда все типы в голове не умещались, а автокомплит просто поиском по имени функции в хедерах помогает в 90% случаев. Кроме того, я отладчиком пользуюсь где-то раз в год, когда по коре и трейсам совсем непонятно из-за чего упало, эта привычка у меня появилась после того как господа из IBM-а своим патчиком вырубили все отладчики на 4 месяца . Так что разбираюсь я в чужом коде простым чтением: вот недавно разбирался в работе одного древнего приложения, там и парсер lex/yacc и обработка всего этого дела на смеси С/С++, нормально пошло.

Основной инструмент — это Vim, так же помогает find, grep, bash, sed и awk последние 2 реже для особых случаев рефакторинга. В принципе для навигации в 80% случаев хватает тегов, для остального моей памяти и grep-а.

Ну тут стоит заметить, что сторонних библиотек мы используем мало, поэтому в документацию стороннюю лазить приходится редко, а своей документации кот наплакал .
В общем, нормально живётся, моей продуктивностью довольны. Не замечал что люди которые используют эклипс и/или студию более продуктивны (Vim-ом пользуются ещё несколько человек).
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[6]: Жизнь без IDE
От: BulatZiganshin  
Дата: 29.09.09 10:44
Оценка:
Здравствуйте, VladD2, Вы писали:

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


прикрути пользователй хаскела на порядки меньше чем сишников, а интеграций такое впечателние что чуть ли не больше: vs (да-да!), eclipse, vim, emacs и ещё несколько редакторов на самом хаскеле. да ещё и не по одной версии интеграции иногда. ес-но, все они оказываются недоделанными. бакгроунд компиляция например была под eclipse, но мало кто это знает и уже тем более пользуется. или например winhugs показывает иерархию классов, функции в них и даже открывает редактор на нужном определении. кто об этом в курсе?
Люди, я люблю вас! Будьте бдительны!!!
Re[8]: Жизнь без IDE
От: BulatZiganshin  
Дата: 29.09.09 10:50
Оценка:
Здравствуйте, VladD2, Вы писали:

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


ну разумеется. то же самое верно для всех других непопулярных языков. недостаток community, books, libraries, tools и т.д. мешают их использовать в коммерческих проектах и рекурсивно приводят к тому что эти community и пр. так и не растут. и виндами пользуются не потому что они лучше и дешевле юниха

ты-то ведь интеграцию для немерле писал именно потому, что понимал какое сдерживающее влияние оказывает её отсутствие на число пользователtй этого неплохого языка? и если сейчас тебя спросить, почему немерле менее популярен, чем c#, ты ведь не скажешь, что это потому что язык хуже? так что ж ты здесь с такой претензией изобретаешь велосипеды?
Люди, я люблю вас! Будьте бдительны!!!
Re[4]: Жизнь без IDE
От: BulatZiganshin  
Дата: 29.09.09 11:59
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Она не означает, что я согласен с автором сообщения. Более того по большей части я с ним как раз не согласен.

VD>Оценка за попытку описать технику своей работы. Это многое объясняет... ну, по крайней мере для меня.

что интересно, ты при этом проигнорировал описание техники работы других, более продвинутых товарищей

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

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

ps: кстати, вот без чего мне действительно было бы неудобно — без синтаксичсекой подсветки. привык за 15 лет, без нёе уже мозг думать отказывается
Люди, я люблю вас! Будьте бдительны!!!
Re[9]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 29.09.09 12:24
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

BZ>ты-то ведь интеграцию для немерле писал именно потому, что понимал какое сдерживающее влияние оказывает её отсутствие на число пользователtй этого неплохого языка?


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

BZ>и если сейчас тебя спросить, почему немерле менее популярен, чем c#, ты ведь не скажешь, что это потому что язык хуже? так что ж ты здесь с такой претензией изобретаешь велосипеды?


Какие велосипеды?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Жизнь без IDE
От: BulatZiganshin  
Дата: 29.09.09 12:28
Оценка:
Здравствуйте, VladD2, Вы писали:

BZ>>и если сейчас тебя спросить, почему немерле менее популярен, чем c#, ты ведь не скажешь, что это потому что язык хуже? так что ж ты здесь с такой претензией изобретаешь велосипеды?


VD>Какие велосипеды?


надо было сказать открываешь америки удивляешься тому, что на хаскеле и порчих не пишут из-за отсутствия развитых IDE
Люди, я люблю вас! Будьте бдительны!!!
Re[5]: Жизнь без IDE
От: thesz Россия http://thesz.livejournal.com
Дата: 01.10.09 09:33
Оценка:
Здравствуйте, Klapaucius, Вы писали:

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


T>>Иными словами, думай, а не пользуйся усилителями интеллекта.

T>>Здоровее будешь.

K>Ну, по такой логике и компилятор — усилитель интеллекта.


Это следует только из твоего расширительного толкования.

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

K>И чтобы не захворать, видимо, следует все писать в машкодах? Это мало того, что, мягко говоря, не согласуется с вашей обычной позицией, так еще и просто бессмысленно.


Тем не менее, это моя позиция.

Попробуй убедить меня в обратном.

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


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

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


Именно поэтому следует писать программы так, чтобы каждое их изменение было сопряжено с интеллектуальной деятельностью, а не рутиной.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[7]: Жизнь без IDE
От: thesz Россия http://thesz.livejournal.com
Дата: 01.10.09 12:07
Оценка:
Здравствуйте, Klapaucius, Вы писали:

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


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

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

Ну, не знаю. К тому же не я начал кидаться "бесконечно" и "нет никакого смысла".

Это вопрос личного выбора.

Лично я считаю, что мне нужен сперва язык, а потом среда, другие считают иначе.

Или так: мне важнее потенциальные возможности, кому-то — уже реализованные.

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

K>Это тоже пустое утверждение — что-то вроде "если хочешь быть счастливым — будь им". Я так понимаю, что мы говорим о том, полезна автоматизация или нет. Моя позиция простая: все что может быть автоматизировано — должно быть автоматизировано.

Я добавлю к этой позиции ещё и "но автоматизация не должна накладывать требования получения дополнительных навыков".\

Иными словами, если я автоматизирую создание класса в Java и мне надо выучить последовательность действий, и у меня есть возможность создать ФВП в Хаскеле без изучения этой последовательности, то я предпочту ФВП.

K>Ручное выполнение автоматизируемого пищи ни уму ни сердцу не дает. Ваша позиция для меня непонятна. Кажется, вы считаете, что автоматизация где-то полезна, а где-то вредна. Но как отличить те области, где она вредна от тех, где полезна мне пока не понятно.


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

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

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

А вот эти два предложения я не понял совсем.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[9]: Жизнь без IDE
От: thesz Россия http://thesz.livejournal.com
Дата: 01.10.09 16:39
Оценка:
Здравствуйте, Klapaucius, Вы писали:

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


T>>Это вопрос личного выбора.

T>>Лично я считаю, что мне нужен сперва язык, а потом среда, другие считают иначе.

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


Ух ты!

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

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


О том и речь.

Есть такой тезис, развиваемый PSP/TSP, что время между внесением ошибки и её обнаружением пропорциональна стоимости её исправления (временной и, далее, денежной).

Чем больше ловит язык, тем лучше.

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


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

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

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

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

T>>Или так: мне важнее потенциальные возможности, кому-то — уже реализованные.

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

А по-моему, существует.

Реализация возможностей приводит к фиксации чего-то. I can tell you, even when you're a Java enthusiast, there's nothing more depressing than looking at java.util.Date and thinking, "That should have been immutable, but it's going to be mutable for the rest of eternity. We will never fix that."

T>>Я добавлю к этой позиции ещё и "но автоматизация не должна накладывать требования получения дополнительных навыков".\

K>Ну, это возможно разве что только в идеале. Да даже в идеале невозможно. В идеале — это обеспечить такую кривую обучения, чтобы возможности раскрывались и осваивались ненавязчиво.

Мой призыв "язык(и) без IDE!" на самом деле сводится к тому, сколько надо учить инструментов. Другая положительная сторона: сколько можно использовать инструментов одновременно.

Я минимизирую число изучаемых инструментов, выбрав наиболее мощный ЯП. Я максимизирую число используемых инструментов, используя произвольную сборку с Makefile (как пример).

К чему приводит твой призыв "автоматизировать надо всё!"?

T>>Иными словами, если я автоматизирую создание класса в Java и мне надо выучить последовательность действий, и у меня есть возможность создать ФВП в Хаскеле без изучения этой последовательности, то я предпочту ФВП.

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

Ура!

T>>Как только эта самая автоматизация требует формирования рефлексов, тут она начинает быть вредна.

K>Ну, это, конечно, неправильная автоматизация. Автоматизация должна избавлять от необходимости формировать рефлексы.

От необходимости напрягать мозги вообще. Рефлексы второстепенны.

T>>А вот эти два предложения я не понял совсем.


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

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

Я не должен думать, какую автоматизацию применить в данный момент.

Я должен думать, как писать программу, чтобы её изменения были минимальными.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[9]: Жизнь без IDE
От: VoidEx  
Дата: 01.10.09 17:54
Оценка:
Здравствуйте, Klapaucius, Вы писали:

K>Я строю свой диспут с thesz именно на максимализме и даже экстремизме (не в политическом смысле, конечно) именно потому, что он, как мне кажется, последовательно (до этого самого момента) проводил здесь идеи о том, что максимализм — это то же самое, что прагматизм, а компромисс между A и B хуже и A и B. Тут же эта передовая идея вдруг дала сбой и я, конечно же, решил провентилировать этот вопрос.


Ну, я с ним в этом не согласен, если в такой формулировке.

K> Обычно оно звучит так: "Я отлично знаю язык Java++ и решу на нем задачу быстрее, чем на языке Пейтон-Джонс потому, что для решения ее на языке ПДж мне нужно сначала изучить этот язык (а дальше он мне может и не пригодится)" — тут человек полностью последователен. Он честно заявляет: все, чего я не знаю — мне не нужно, все чем я не умею пользоваться мне никогда не пригодится.


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

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


Склоняюсь к тому, что этот критерий вообще разный для разных людей.
Re[8]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.10.09 20:24
Оценка:
Здравствуйте, thesz, Вы писали:

T>Лично я считаю, что мне нужен сперва язык, а потом среда, другие считают иначе.


Верно ли я понял, что среда все же нужна?

Кто считает иначе? Покажи, плиз, кто выбирает среду и под нее язык?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.10.09 20:30
Оценка:
Здравствуйте, Klapaucius, Вы писали:

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


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

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

И я вот не пойму кто прав они или мы (я ведь тоже грешен, язык ставлю выше)?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.10.09 07:35
Оценка:
Здравствуйте, FR, Вы писали:

FR>Для OCaml'а есть вполне качественное IDE, для Лиспов тоже их полно, но я не вижу повального ими увлечения.


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

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


На мой взгляд рассказы о том, что функциональщина чем-то там отличается — это чушь. Код есть код и с ним надо работать.

Что до "окружения", то я вообще не понимаю как можно работать с языком. Я пишу код (создаю проекты) которые решают те или иные задачи. Язык всего лишь инструмент (без него нельзя). И рано или поздо кода становится много. Когда его становится много, то и написание нового кода, и модификация старого, и даже, изучение имеющегося кода (который может быть написан другими или так давно, что подробности уже стерлись) требуют все больше и больше усилий. IDE или те средства которые описывались здесь (допотопные, на мой взгляд, но все же действенные) позволяют двигаться дальше с приемлемой скоростью.

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

Рассказ про то, что IDE вынуждает что-то там изучить меня тоже порадовал. Изучение этих отдельных средств задча куда более объемная нежели изучение возможнсотей IDE или ее настройка под себя.

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

Вера в REPL тоже забавит. Есть у Nemerle REPL. Но попросу не удобен для работы с проектом в котром несколько сотен файлов и столько же типов. Про тысячи я вообще молчу. Так что тот же REPL может быть и не плох, особенно для чистого ФЯ (коим ОКамл не является), но опять же ему не плохо было бы быть встроеным в IDE.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Жизнь без IDE
От: FR  
Дата: 02.10.09 08:35
Оценка:
Здравствуйте, VladD2, Вы писали:


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


Это не важно, важно то скажем условно что 90% явистов не представляют себе жизни без IDE, а среди тех же камлистов таких скажем всего 10%

VD>На мой взгляд рассказы о том, что функциональщина чем-то там отличается — это чушь. Код есть код и с ним надо работать.


Не чушь, просто вы немерлисты используете ООП на верхнем уровне, поэтому отличий для вас нет. Это и IT и ты постоянно демонстрируете.

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


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

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


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

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


Я думаю усилий нужно примерно одинаково.

VD>То что IDE привязывает — это факт. Но привязывают и другие средства. А уж язык привязывает куда сильнее. Это один из главных фаторов почему новые языки принимюатся в штыки, на мой взгляд.


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

VD>Вера в REPL тоже забавит. Есть у Nemerle REPL. Но попросу не удобен для работы с проектом в котром несколько сотен файлов и столько же типов. Про тысячи я вообще молчу. Так что тот же REPL может быть и не плох, особенно для чистого ФЯ (коим ОКамл не является), но опять же ему не плохо было бы быть встроеным в IDE.


Это не вера, просто ты серъезно не работал с REPL, навыков нет, объяснять бесполезно.
У чистого Хаскеля REPL во многом похуже чем у грязного OCaml'а
Re[9]: Жизнь без IDE
От: thesz Россия http://thesz.livejournal.com
Дата: 02.10.09 08:52
Оценка:
Здравствуйте, VladD2, Вы писали:

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


T>>Лично я считаю, что мне нужен сперва язык, а потом среда, другие считают иначе.


VD>Верно ли я понял, что среда все же нужна?


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

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

VD>Кто считает иначе? Покажи, плиз, кто выбирает среду и под нее язык?


<lj user=lex_kravetski>, например. Во всём остальном он не дурак, однако тут — вот такой, какой есть.

Да и здесь хватает. "Хаскель? А среда под него есть? Ну, я без среды не могу."
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[9]: Жизнь без IDE
От: Denom Украина  
Дата: 02.10.09 08:54
Оценка:
Здравствуйте, VladD2, Вы писали:

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


Я не знаю как насчет больших проектов, но вот судя по роликам по F# интерактивный режим разработки там норма.
Большим плюсом является то что F# Interactive являестся встороенным в студию. Не нужно никуда переглючаться.
Есть разные типы файлов скрипт (fsx )и файл программы (fs) — соответственоо для fsx открывается F# Interactive.
Вообще иногда возникает рефлекс бысто проверить написанную функцию (особенно когда у тебя проект на миллион сток на паскале .
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[7]: Жизнь без IDE
От: thesz Россия http://thesz.livejournal.com
Дата: 02.10.09 09:05
Оценка:
Здравствуйте, VladD2, Вы писали:

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


K>>>И чтобы не захворать, видимо, следует все писать в машкодах? Это мало того, что, мягко говоря, не согласуется с вашей обычной позицией, так еще и просто бессмысленно.

T>>Тем не менее, это моя позиция.
T>>Попробуй убедить меня в обратном.
VD>А я почти уверен, что это не твоя позиция, а твоя защитная рекция. Я попробовал IDE ссылка на которую приведена ветке рядом и понял, что продукт не рабочий даже на сегодняшний день. Он тупо повис и чуть не убил всю ОС когда я всего лишь скопировал в него пример из интернета.
VD>Не трудно догадаться, что во времена когда ты начал пользоваться хаскелем IDE или не было вовсе, или они были в еще более непотребном виде. Вот ты привык... С одной стороны к работе с тем, что есть, а с другой к тому что нормальной IDE нет и в ближайшее время не появится.

Я не пользуюсь средой при программировании на практически всех ЯП с 1991 года. Norton Commander, а затем Volcov Commander, знаешь ли.

Отладчиком я прекратил пользоваться вскорости после практически полного перехода на Си, это 1995-96 год.

Хаскелем я пользуюсь с 1998 года.

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

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


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

Исключение составляет связка Agda2 + Emacs, пожалуй.

VD>Из всего сказанного в этой теме мне осталось не ясно только несколко моментов. Главный из них — почему, если у гуру есть сои методики и технологии работы с проектами, они не делятся ими с новичками? Почему никто не дает ссылок на статьи типа "как создать и развить большой проект на Хасеель?", а вместо этого с удовольствием ведутся беседы на абстрактные темы рвущие в клочья мозг большинства новичков?


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

Хаскель играет вспомогательную и интегрирующую роль.

И играет её с помощью того, что ты называешь "абстрактные темы рвущие в клочья мозг большинства новичков".
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[10]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.10.09 09:09
Оценка:
Здравствуйте, FR, Вы писали:

FR>Это не важно, важно то скажем условно что 90% явистов не представляют себе жизни без IDE, а среди тех же камлистов таких скажем всего 10%


А ты не задумывался, что это потому, что для Явы есть ряд очень качественных IDE. Как ты считаешь IDE для ОКамла могут сравниться с поддержкой Java в IDEA или Эклипсе?

VD>>На мой взгляд рассказы о том, что функциональщина чем-то там отличается — это чушь. Код есть код и с ним надо работать.


FR>Не чушь, просто вы немерлисты используете ООП на верхнем уровне, поэтому отличий для вас нет. Это и IT и ты постоянно демонстрируете.


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

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


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

В общем, твои слова бездоказательны и не убедительны.

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


Хуже хотя бы тем, что работают не в реальном времени. Плюс не полноценны.

FR>Я думаю усилий нужно примерно одинаково.


Неверно думаешь.

FR>Это не вера, просто ты серъезно не работал с REPL, навыков нет, объяснять бесполезно.


Что такое "серьезно работать"? Я им пользовался. По сравнению с IDE — это резкое понижение возможностей.
По сути я всгда использую РЕПЛ, только он вылгдяит по-другому. Я пишу код в редкторе который предоставляет мне информацию о типах, подсказки, автодополнение при вводе, навигацию. Этого достаточно чтобы быстро разобраться в конкретном участке кода и сделать необходимые изменения. Далее я жму F5 и смотрю как код работает. Тут могут быть варианты. Это может быть или юнт-тесты, иди реальное приложение, или специальный мелкий тест описывающий решаемую проблему.

FR>У чистого Хаскеля REPL во многом похуже чем у грязного OCaml'а


Да ни один репл не позволит работать реальных боевых условиях. К тому же REPL может быть встроен в IDE и никак не исключает нормальных средств работы.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Жизнь без IDE
От: metaprogrammer  
Дата: 02.10.09 09:10
Оценка:
Здравствуйте, VladD2, Вы писали:

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


Ровно так же, как он был построен, когда никаких IDE ещё не было. Просто многие люди консервативны и не любят менять привычки (и я из их числа).

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


Если заменить отладчик на REPL, то никакого дискомфорта не наблюдается. REPL — лучшая IDE.

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


Отладка нужна, но не такая, какую предоставляют интерактивные дебаггеры в стиле "step-watch-step-watch".
Re[10]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.10.09 09:13
Оценка:
Здравствуйте, thesz, Вы писали:

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


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


Кстати, а по поводу библиотек у тебя мнение такое же?

VD>>Кто считает иначе? Покажи, плиз, кто выбирает среду и под нее язык?


T><lj user=lex_kravetski>, например. Во всём остальном он не дурак, однако тут — вот такой, какой есть.


Не очень известная личность, по словам гугля.

T>Да и здесь хватает. "Хаскель? А среда под него есть? Ну, я без среды не могу."


Это четкое доказательство того, что людям трудно осваивать новое без средств автоматизации.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Жизнь без IDE
От: metaprogrammer  
Дата: 02.10.09 09:18
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>А ты не задумывался, что это потому, что для Явы есть ряд очень качественных IDE. Как ты считаешь IDE для ОКамла могут сравниться с поддержкой Java в IDEA или Эклипсе?


IDE для F# — может. Но почему-то многие F#-щики предпочитают REPL без IDE.

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


VD>Нет никакой ФП декомпозиции.


Есть, ещё как есть.

VD> Есть структурная, известная с С.


Ничего общего.


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


Это только самый маленький, самый первый шаг в ФП.

FR>>Это не вера, просто ты серъезно не работал с REPL, навыков нет, объяснять бесполезно.


VD>Что такое "серьезно работать"? Я им пользовался. По сравнению с IDE — это резкое понижение возможностей.


Так возможностями надо уметь пользоваться, да?

FR>>У чистого Хаскеля REPL во многом похуже чем у грязного OCaml'а


VD> Да ни один репл не позволит работать реальных боевых условиях.


Что, правда не позволит? А мужики то и не знают, вот беда.

Советую почитать у Пола Грэма, как в реальных боевых условиях через удалённый REPL он продакшн код правил, одновременно втирая по телефону клиенту, что мол "какие такие ошибки, всё работает — вот посмотрите прям щас".

VD> К тому же REPL может быть встроен в IDE и никак не исключает нормальных средств работы.


Может, да. Только при этом IDE как-то особо не используется. Отмирает за ненадобностью, остаётся только в роли пускали хелпа.
Re[9]: Жизнь без IDE
От: metaprogrammer  
Дата: 02.10.09 09:27
Оценка:
Здравствуйте, VladD2, Вы писали:

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


А кому это надо? Зачем голову чушью забивать?

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


Я правильно понял, что до где-то года 96-го все поголовно решали слишком примитивные задачи, поскольку приличных IDE просто не было (ой, мне сейчас опять про VisualAge начнут напоминать...)?

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


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

VD> Есть у Nemerle REPL. Но попросу не удобен для работы с проектом в котром несколько сотен файлов и столько же типов.


А вот не фиг раздельную компиляцию разводить. REPL очень удобен для быстрой интроспекции поведения непонятных кусков сколь угодно большого проекта. Я вообще человек мерзостный и глупый, и в силу этого в любом крупном проекте на время разработки и отладки содержу backdoor — висящий на каком либо порту доступный через telnet REPL какого либо скриптового языка с возможностью легко дёргать за reflection и смотреть, что там как внутри работает. Это на порядки удобнее и мощнее чем любой отладчик. Я могу модифицировать код работающего проекта, могу писать и тут же применять сложные тесты, не останавливая работы приложения. Да, это глупо, несекурно, мерзко — но это работает.

VD> Про тысячи я вообще молчу. Так что тот же REPL может быть и не плох, особенно для чистого ФЯ (коим ОКамл не является), но опять же ему не плохо было бы быть встроеным в IDE.


REPL распрекрасно рулит и заруливает и для ни разу не функциональных языков.
Re[9]: Жизнь без IDE
От: thesz Россия http://thesz.livejournal.com
Дата: 02.10.09 09:45
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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


А для Хаскеля можно написать такое: AspectAG.

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

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


Или умело разбил проект на примитивные задачи.

Но такое тебе в голову придти не может, поскольку в этом случает окажется, что "монстры программирования" всё-таки существуют.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[11]: Жизнь без IDE
От: FR  
Дата: 02.10.09 09:51
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>А ты не задумывался, что это потому, что для Явы есть ряд очень качественных IDE. Как ты считаешь IDE для ОКамла могут сравниться с поддержкой Java в IDEA или Эклипсе?


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


VD>Я не раз с успехом использовать IDE кода писал код в котором не было ни грамма ООП. Так что твои предположения высасывание из пальца.


Угу а я писал без IDE чистый ООП код.


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


Влад ты же все знаешь, и про монады читал, и ML модули я тебе пару лет назад разъяснял, но почему-то не хочешь понять

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

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

VD>В общем, твои слова бездоказательны и не убедительны.


Нет просто у тебя установка, непробиваемая.

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


VD>Хуже хотя бы тем, что работают не в реальном времени. Плюс не полноценны.


Зато лучше в том что могут давать информацию в более удобном для восприятия виде.



VD>Что такое "серьезно работать"? Я им пользовался. По сравнению с IDE — это резкое понижение возможностей.


Это субъективно.
И потом не вместо IDE, а скорее рядом, просто это рядом перекрывает многие возможности IDE.


VD>Да ни один репл не позволит работать реальных боевых условиях.


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

VD>К тому же REPL может быть встроен в IDE и никак не исключает нормальных средств работы.


Это да, только мнение о том что является нормальными средствами у всех разные
Re[12]: Жизнь без IDE
От: metaprogrammer  
Дата: 02.10.09 09:55
Оценка:
Здравствуйте, FR, Вы писали:

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


Кстати, есть смысл говорить о семантической декомпозиции, и функциональная декомпозиция — это её частный случай, как правило более чем достаточный на практике.
Re[13]: Жизнь без IDE
От: metaprogrammer  
Дата: 02.10.09 10:10
Оценка:
Здравствуйте, Аноним, Вы писали:

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


А>Хотелось бы конкретных примеров. Пока больше похоже на утверждение, что некоторое масло более масленное, чем какое-то другое.


Отличный пример функциональной декомпозиции был в журнале "Практика функционального программирования", про игру в шашки. Подробненько так, шаг за шагом.
Re[10]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.10.09 10:11
Оценка:
Здравствуйте, Denom, Вы писали:

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

D>Большим плюсом является то что F# Interactive являестся встороенным в студию. Не нужно никуда переглючаться.

Сдается мне, что это хорошо только для демонстраций. Ну, не верю, я что кто-то может загонять 10 проектов по 1000 файлов в РЕПЛ чтобы протестировать его функциональность.

D>Есть разные типы файлов скрипт (fsx )и файл программы (fs) — соответственоо для fsx открывается F# Interactive.

D>Вообще иногда возникает рефлекс бысто проверить написанную функцию (особенно когда у тебя проект на миллион сток на паскале .

Это, да. По одной функции тестировать удобно. Но не всегда можно одну функцию протестировать.

Опять же я не против РЕПЛ-а. Я против противопоставления РЕПЛ-а наличию IDE.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Жизнь без IDE
От: metaprogrammer  
Дата: 02.10.09 10:14
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Сдается мне, что это хорошо только для демонстраций. Ну, не верю, я что кто-то может загонять 10 проектов по 1000 файлов в РЕПЛ чтобы протестировать его функциональность.


Я видел вживую, как работает Don Syme. Именно так — в REPL. Да и что значит "загонять 10 проектов по 1000 файлов"? Это на практике означает загрузить одну dll (которая все прочие за собой потянет).

При моём варианте (repl по telnet) вообще любая debug-сборка приложения будет в себя включать REPL.

VD>Опять же я не против РЕПЛ-а. Я против противопоставления РЕПЛ-а наличию IDE.


На практике, опять же, так и получается, что когда есть умный REPL, то от IDE уже, собственно, ничего и не надо.
Re[12]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.10.09 10:19
Оценка:
Здравствуйте, metaprogrammer, Вы писали:

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

VD>>Нет никакой ФП декомпозиции.


M> Есть, ещё как есть.


VD>> Есть структурная, известная с С.


M> Ничего общего.




Есть отличия? Ну, расскажи в чем они заключаются.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.10.09 10:31
Оценка:
Здравствуйте, metaprogrammer, Вы писали:

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


M> А кому это надо? Зачем голову чушью забивать?


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

M> Я правильно понял, что до где-то года 96-го все поголовно решали слишком примитивные задачи, поскольку приличных IDE просто не было (ой, мне сейчас опять про VisualAge начнут напоминать...)?


Ну, почему только про VisualAge. Смолток был в 80-ом и до IBM-а.
А задачи, действительно реашалось более примитивные. То что тогда казалось подвигом, сейчас обычное дело.
Конечно не только IDE иземенили положение дел, но и они в том числе.

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


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


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

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


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

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

M>Я вообще человек мерзостный и глупый, и в силу этого в любом крупном проекте на время разработки и отладки содержу backdoor — висящий на каком либо порту доступный через telnet REPL какого либо скриптового языка с возможностью легко дёргать за reflection и смотреть, что там как внутри работает. Это на порядки удобнее и мощнее чем любой отладчик. Я могу модифицировать код работающего проекта, могу писать и тут же применять сложные тесты, не останавливая работы приложения. Да, это глупо, несекурно, мерзко — но это работает.


Это чушь. Отладчика это не заменит. Да и само наличие "скрипта" уже говорит, что что-то не так. В прочем, я понял что в данном случае речь идет скорее всего о неком диалекте лиспа.

M> REPL распрекрасно рулит и заруливает и для ни разу не функциональных языков.


Лисп?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.10.09 10:37
Оценка:
Здравствуйте, thesz, Вы писали:

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


Они так браво говорят банальности, что смахивают на трепачей
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Жизнь без IDE
От: thesz Россия http://thesz.livejournal.com
Дата: 02.10.09 10:47
Оценка:
Здравствуйте, VladD2, Вы писали:

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


M>> Я правильно понял, что до где-то года 96-го все поголовно решали слишком примитивные задачи, поскольку приличных IDE просто не было (ой, мне сейчас опять про VisualAge начнут напоминать...)?

VD>Ну, почему только про VisualAge. Смолток был в 80-ом и до IBM-а.

О, да.

И широко применялся в проектах по написанию OS/360, например.

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

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

Потому, что Хаскель более-менее популярен всего года два-три, как. Это раз. Потому, что необходимость в IDE меньше, это двас.

Потому и не могут написать IDE вот уже 22 года, аж с 1987.

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


VD>Агащазблин. Проект может только загружаться в этот РЕПЛ по несколько минут.


А перегружать изменённый файл в секунды.

Что на деле и наблюдается.

VD>А если РЕПЛ интерпретирующий, то загруженый проект может просто перестать предоставлять приемлемый отклик.


А ты не проверяй весь проект, проверяй только часть.

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


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


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

А это далеко не везде возможно.

В REPL ты проверяешь одну функцию на наборе аргументов. Поправил, проверил, поправил, проверил. Отката не требуется.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[11]: Жизнь без IDE
От: thesz Россия http://thesz.livejournal.com
Дата: 02.10.09 10:48
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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

VD>Они так браво говорят банальности, что смахивают на трепачей

Или просто умнее тебя и лучше программируют.

Такое в голову не приходило?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[12]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.10.09 10:53
Оценка:
Здравствуйте, FR, Вы писали:

FR>Влад ты же все знаешь, и про монады читал, и ML модули я тебе пару лет назад разъяснял, но почему-то не хочешь понять


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

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


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

FR>Хорошая структурная это практически ОО,


Бред полнейший.

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


А. Ясно. Ты в терминологии плаваешь. Структурная декомпозиция не имеет никакого отношения к структурам.
Учи мат.часть http://en.wikipedia.org/wiki/Decomposition_(computer_science)

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


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

VD>>В общем, твои слова бездоказательны и не убедительны.


FR>Нет просто у тебя установка, непробиваемая.


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

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


VD>>Хуже хотя бы тем, что работают не в реальном времени. Плюс не полноценны.


FR>Зато лучше в том что могут давать информацию в более удобном для восприятия виде.


Это чем же вид то лучше? Ты давно полноценными IDE пользояался?

VD>>Что такое "серьезно работать"? Я им пользовался. По сравнению с IDE — это резкое понижение возможностей.


FR>Это субъективно.


Ага. Твое мнение — это объективно, а мое — субъективно.

FR>И потом не вместо IDE, а скорее рядом, просто это рядом перекрывает многие возможности IDE.


Кому в голову взбредет лезть в репл для поиски имени функции если есть комплит и навигация?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Жизнь без IDE
От: FR  
Дата: 02.10.09 10:55
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Хотелось бы конкретных примеров. Пока больше похоже на утверждение, что некоторое масло более масленное, чем какое-то другое.


Сложно, все-равно что на конкретных примерах объяснить что такое ООП.
Re[14]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.10.09 10:58
Оценка:
Здравствуйте, metaprogrammer, Вы писали:

M> Отличный пример функциональной декомпозиции был в журнале "Практика функционального программирования", про игру в шашки. Подробненько так, шаг за шагом.


Можно ссылку?

ЗЫ

Рабяты. Вы точно терминологией владеете?
http://en.wikipedia.org/wiki/Decomposition_(computer_science)
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.10.09 10:58
Оценка:
Здравствуйте, FR, Вы писали:

FR>Сложно, все-равно что на конкретных примерах объяснить что такое ООП.


ООП отлично объясняется на конкретных примерах. На базе, например, окошек.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Жизнь без IDE
От: FR  
Дата: 02.10.09 11:00
Оценка:
Здравствуйте, VladD2, Вы писали:


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


Применяется обратная схема, REPL встроен в приложение. Как упрощенный пример консоль управления встроенная во многие игры.

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


Крайности смыкаются, в SmallTalk в отладчике вполне доступен REPL
Встроенный REPL как раз и позволяет перезагружать модули и править код на ходу.
Re[12]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.10.09 11:00
Оценка:
Здравствуйте, thesz, Вы писали:

VD>>Они так браво говорят банальности, что смахивают на трепачей


T>Или просто умнее тебя и лучше программируют.

T>Такое в голову не приходило?

Ну, как же. Они же только на это и намекают. От чего и смахивают на трепачей только сильнее.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Жизнь без IDE
От: FR  
Дата: 02.10.09 11:03
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>ООП отлично объясняется на конкретных примерах. На базе, например, окошек.


Можно хотя бы ссылку на такое объяснение?
Re[12]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.10.09 11:07
Оценка:
Здравствуйте, FR, Вы писали:

FR>Применяется обратная схема, REPL встроен в приложение. Как упрощенный пример консоль управления встроенная во многие игры.


Это очередная выдумка. REPL не встраивается в приложения F#. Если я имею запущенное приложение F#, то РЕПЛ к нему уже не подключить. А вот отладчик — можно.

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

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


FR>Крайности смыкаются, в SmallTalk в отладчике вполне доступен REPL


В Смолток РЕПЛ? Вау? На фиг он там упал? Там среда "живая".

FR>Встроенный REPL как раз и позволяет перезагружать модули и править код на ходу.


Это опять твои фантазии. Перезагружать там ничего не надо. Модулей там тоже нет. Там есть байткод методов которые общаются исключительно сообщениями. Это позволяет менять код методов (в "экземпляре", т.е. в работающем приложении) прямо на ходу.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Жизнь без IDE
От: Denom Украина  
Дата: 02.10.09 11:07
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Опять же я не против РЕПЛ-а. Я против противопоставления РЕПЛ-а наличию IDE.


Согласен. Мне понравился REPL именно как часть IDE
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[16]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.10.09 11:11
Оценка:
Здравствуйте, FR, Вы писали:

VD>>ООП отлично объясняется на конкретных примерах. На базе, например, окошек.


FR>Можно хотя бы ссылку на такое объяснение?


У меня под рукой нет. А гугль тебе не помог?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Жизнь без IDE
От: thesz Россия http://thesz.livejournal.com
Дата: 02.10.09 11:26
Оценка:
Здравствуйте, VladD2, Вы писали:

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


VD>>>Они так браво говорят банальности, что смахивают на трепачей


T>>Или просто умнее тебя и лучше программируют.

T>>Такое в голову не приходило?
VD>Ну, как же. Они же только на это и намекают. От чего и смахивают на трепачей только сильнее.

Или, всё же, умнее тебя и лучше программируют. А ты просто завидуешь и пытаешься развести их "на слабо".
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[13]: Жизнь без IDE
От: FR  
Дата: 02.10.09 11:31
Оценка:
Здравствуйте, VladD2, Вы писали:


VD>Это очередная выдумка. REPL не встраивается в приложения F#. Если я имею запущенное приложение F#, то РЕПЛ к нему уже не подключить. А вот отладчик — можно.


Влад я писал приложения со встроенным реплом на питоне. Для питона есть как стандартные библиотеки для этого, так и модули например из wx http://wiki.wxpython.org/PyWrap который включает REPL и интегрированный диспетчер.
Это нормальная практика. Как в F# с этим я не знаю, но OCaml вполне позволяет это.

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


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


FR>>Крайности смыкаются, в SmallTalk в отладчике вполне доступен REPL


VD>В Смолток РЕПЛ? Вау? На фиг он там упал? Там среда "живая".


Ты хоть раз Смаллтолк запускал?
Я хоть только и баловался, но сразу же залез в том же Dolphin в Tools/Workspace который представляет собой repl в чистом виде. В других смаллталках он тоже обязательно присутствует.

FR>>Встроенный REPL как раз и позволяет перезагружать модули и править код на ходу.


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


В смаллтолке нет конечно, там есть образ который без проблем меняется на ходу. Зато в питоне есть модули и REPL позволяет их перезагружать, в итоге получаем тоже самое.
Re[17]: Жизнь без IDE
От: FR  
Дата: 02.10.09 11:32
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>>>ООП отлично объясняется на конкретных примерах. На базе, например, окошек.


FR>>Можно хотя бы ссылку на такое объяснение?


VD>У меня под рукой нет. А гугль тебе не помог?


Нет, мне проще читать что таких объяснений нет
Re[10]: Жизнь без IDE
От: Klapaucius  
Дата: 02.10.09 11:53
Оценка:
Здравствуйте, VoidEx, Вы писали:

VE>Он не последователен, он тоже вдаётся в крайность, но противоположную. Одному всё нужно, а другому всё не нужно. Это к последостельности имеет крайне отдалённое отношение.


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

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


Ну, допустим. Но, например, какой?
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[12]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.10.09 12:30
Оценка:
Здравствуйте, vshabanov, Вы писали:

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


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

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


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

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


А, ну, ясно. Это позиция из серии "хрен оспоришь".
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
л
Re[14]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.10.09 12:40
Оценка:
Здравствуйте, FR, Вы писали:

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


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

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


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


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

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


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


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

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


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

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


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


Чунь не говори. О структурной декомпозиции и о ОО-декомпозиции можно прочесть даже в учебниках для школ.
А вот выдуманная тобой новая модель только в твоем воображении и существует.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Жизнь без IDE
От: vshabanov http://vshabanov-ru.blogspot.com
Дата: 02.10.09 12:43
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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


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

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


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


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


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


Я тебе предложил вариант поработать без отладчика. Поработаешь и оспаривать не понадобится.
Re[12]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.10.09 12:51
Оценка:
Здравствуйте, vshabanov, Вы писали:

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


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

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

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


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


У тебя уже запущено приложение. Правь исходники и тестируй дальше.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.10.09 13:06
Оценка:
Здравствуйте, vshabanov, Вы писали:

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


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

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

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

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


Работал я без отладчика или там где нет отладочной информации, а от отладки асма толку — 0. Потому и говорю, что — это идиотизм. Отладчик — это великолепный инструмент которым нужно уметь пользоваться. А ваша бравада говорит только о ваших условиях работы. В реально сложных условиях вы или взяли бы в руки отладчик и научились бы им пользоваться, или просто тих ретировались бы.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Жизнь без IDE
От: vshabanov http://vshabanov-ru.blogspot.com
Дата: 02.10.09 13:12
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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


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


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

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


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

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


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


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


Тестируй приложение целиком. Я предпочитаю оттестировать отдельные ф-ии/модули/библиотеки и как следует подумать над их интеграцией, после чего приложение уже не столько тестируется, сколько смотрится на предмет общей удобности работы.
Re[11]: Жизнь без IDE
От: thesz Россия http://thesz.livejournal.com
Дата: 02.10.09 13:22
Оценка:
Здравствуйте, 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. После определения возможностей возможно более-менее полноценно поддержать ту возможность, что мы получили до появления новой.

Получается замкнутый круг. Мы только чот поддержали что-то, а новая версия сводит часть нашей работы на нет.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[15]: Жизнь без IDE
От: vshabanov http://vshabanov-ru.blogspot.com
Дата: 02.10.09 13:24
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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


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

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

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

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

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


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

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


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

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


VD>Работал я без отладчика или там где нет отладочной информации, а от отладки асма толку — 0. Потому и говорю, что — это идиотизм. Отладчик — это великолепный инструмент которым нужно уметь пользоваться. А ваша бравада говорит только о ваших условиях работы. В реально сложных условиях вы или взяли бы в руки отладчик и научились бы им пользоваться, или просто тих ретировались бы.
Re[7]: Жизнь без IDE
От: dr.Chaos Россия Украшения HandMade
Дата: 02.10.09 13:37
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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

Короче, почему ты считаешь что собранное вручную окружение будет хуже чем IDE типа эклипса или студии?
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[15]: Жизнь без IDE
От: FR  
Дата: 02.10.09 13:48
Оценка:
Здравствуйте, 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>А вот выдуманная тобой новая модель только в твоем воображении и существует.

Угу только почему-то ФЯ программы реально абсолютно ничего общего со структурными не имеют.
Re[8]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.10.09 14:09
Оценка:
Здравствуйте, dr.Chaos, Вы писали:

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


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

Кроме того есть еще три аспекта — интеграция, качество, доступность. Все они хромают при таком подходе. Особенно последнее. Ведь всю эту байду не получишь в одном флаконе. Да и шорткатам учиться придется долго. Лично я так и не смог освоить Emacs хотя пару раз пробовал. Думаю, я не единственный кто не смог его освоить.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.10.09 16:32
Оценка:
Здравствуйте, IT, Вы писали:

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


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

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

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

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

Потом на поздних этапах цели проекта могут измениться. Хороший пример тот же немерловый компилятор. Его писали как компилятор командной строки. Причем с целью как можно быстрее получить что-то работающее. Когда компилятор был почти в бэте вдруг выяснилось, что для создания IDE компилятор нужно было писать совсем иначе. Многое нужно делать более детально, а много вообще по другому. Лично ты надорвал пуп когда попытался этот проект отрефакторить. Списав все на кривые руки предшественников ты предложил его переписать с нуля. А я вот мучился изучая проект и рефакторя все это дело вручную. Была бы IDE способная поднять этот проект и автоматизировать рефакториг, я бы давно закончил.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.10.09 17:00
Оценка:
Здравствуйте, thesz, Вы писали:

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


Ну, я бы мог сделать смелые предположения и намекнуть тебе на них, но лучше буду операться на факты. А факты у нас очень печальные. Те кто считает себя умнее других не пишет кода который можно было бы с чем-то сравнить.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.10.09 17:07
Оценка:
Здравствуйте, FR, Вы писали:

FR>Давай ты не будешь мне рассказывать про игры.

FR>По твоему отладка, трассировка и тестирование не часть разработки?
FR>В играх кстати это очень существенная часть.

Ты намеренно подменяешь понятия. Мы говорили о разработке софта с помощью РЕЛП-а. Консоли в играх не РЕПЛ. То что и там, и там есть консоль не значит, что они тождественны и одно можено приводить в качестве доказательства другого.

Ты говорил что? Что в игры встраиваются РЕПЛ-ы. Это беспардонное вранье. И ты это знаешь. И у тебя хватает наглости заниматься софистикой оправдывая свои слова. В общем, извини, но мне игры в аратора не интересны. Ты сюда поупражняться ходишь. А я лучше займусь чем-нибудь полезным.

FR>Ты хоть раз Смаллтолк запускал?


Да и не раз.

FR>Я хоть только и баловался, но сразу же залез в том же Dolphin в Tools/Workspace который представляет собой repl в чистом виде. В других смаллталках он тоже обязательно присутствует.


Это не репл. Это как раз IDE в функции которой входит в том числе и замена кода на лету.

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


Ну, дык Питон и тормозит как черт знает что. Какова архитектура, таков и результат.
Чем более динамиченый язык, тем проще в нем менять что-то на лету, но тем он тормознее и ненадежнее. Две стороны одной медали.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Жизнь без IDE
От: FR  
Дата: 02.10.09 17:23
Оценка:
Здравствуйте, VladD2, Вы писали:


VD>Ты намеренно подменяешь понятия. Мы говорили о разработке софта с помощью РЕЛП-а. Консоли в играх не РЕПЛ. То что и там, и там есть консоль не значит, что они тождественны и одно можено приводить в качестве доказательства другого.


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

VD>Ты говорил что? Что в игры встраиваются РЕПЛ-ы. Это беспардонное вранье. И ты это знаешь. И у тебя хватает наглости заниматься софистикой оправдывая свои слова. В общем, извини, но мне игры в аратора не интересны. Ты сюда поупражняться ходишь. А я лучше займусь чем-нибудь полезным.


Угу а то что я сам встраивал тот же PyCrust в игру это мне приснилось. Нет Влад телепат из тебя очень паршивый. Насчет заняться чем то полезным ты прав, у нас почему-то почти всегда ругань получается

FR>>Ты хоть раз Смаллтолк запускал?


VD>Да и не раз.


Не похоже.


VD>Это не репл. Это как раз IDE в функции которой входит в том числе и замена кода на лету.


Это репл органично встроенный в IDE

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


VD>Ну, дык Питон и тормозит как черт знает что. Какова архитектура, таков и результат.


Больше нечего сказать?
Re[12]: Жизнь без IDE
От: IT Россия linq2db.com
Дата: 02.10.09 17:48
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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


Сложнее.

VD>А разбираться в коде?


Тоже сложно.

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


Чем дальше в лес, тем жирнее партизаны (c)

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


Это потому, что ты смотришь на возможности IDE через призму возможностей, которые нужны лично тебе. А крутые среды на этом не останавливаются. Давно ли ты, например, генерировал типизированные датасеты? Или мапил в редакторе модель данных на объектную модель приложения? Или рисовал в редакторе интерфейс, а среда писала за тебя код? Это всё признаки "крутой" среды и многие ими пользуются чуть ли не чаще, чем пишут код.

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


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

Ты же здесь говоришь о рефакторинге дизайна, а без переписывания всего компилятора это невозможно в принципе. Да ты и сам это уже понял. И была бы у тебя IDE с возможностями даже решарпера, от переписывания всего тебя бы это не спасло никак.
Если нам не помогут, то мы тоже никого не пощадим.
Re[13]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.10.09 18:25
Оценка:
Здравствуйте, IT, Вы писали:

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


IT>Это потому, что ты смотришь на возможности IDE через призму возможностей, которые нужны лично тебе.


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

IT>А крутые среды на этом не останавливаются. Давно ли ты, например, генерировал типизированные датасеты?


Давно. И это было несомненно удобнее нежели работать с ХМЛ-ем и БД средствами которые предоставлялись в C# 2.0.
Для 3-его и Немерла такие костыли не нужны. Я с этим и не спорил. Я говорил об IDE, как о средстве работы с проектом.

IT>Или мапил в редакторе модель данных на объектную модель приложения?


Никогда этим не занимался. Но это не важно.

IT>Или рисовал в редакторе интерфейс, а среда писала за тебя код?


И сейчас постараюсь так сделать. Более того для рисования форм выберу C#, а не Немерл просто потому, что там это сделано качественно.

IT> Это всё признаки "крутой" среды и многие ими пользуются чуть ли не чаще, чем пишут код.


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

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

Но к чему все это?

IT>Ты путаешь рефакторинг кода и рефакторинг дизайна.


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

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


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

IT>Повторяю — тупой. Раньше на это уходило от нескольких минут до нескольких часов, сейчас ровно полсекунды.


Все зависит от запущенности случая. У меня уходили дни! А могли бы уходить минуты.

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


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

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


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

IT>Да ты и сам это уже понял. И была бы у тебя IDE с возможностями даже решарпера, от переписывания всего тебя бы это не спасло никак.


Нет. Уверен, что при наличии такой IDE я бы сделал код таким как хочу. Меня сейчас останавливает от этого только объем работ и их трудоемкость.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Жизнь без IDE
От: thesz Россия http://thesz.livejournal.com
Дата: 02.10.09 19:51
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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


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


http://thesz.mskhug.ru/svn
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[12]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.10.09 19:58
Оценка:
Здравствуйте, thesz, Вы писали:

T>У меня просьба личного характера. RSDN работает очень медленно,


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

T>поэтому искать сообщение тяжело. Поэтому оставляй побольше контекста.


Гугль рулит. Пиши "site:tsdn.ru/имя-форума искомая-строка" и будет тебе счастье.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Жизнь без IDE
От: thesz Россия http://thesz.livejournal.com
Дата: 02.10.09 20:01
Оценка:
Здравствуйте, IT, Вы писали:

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


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

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

"Не рекомендую. Съедят." (C) Понедельник начинается в субботу

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


Это всё теории.

Моя практика показывает обратное.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[15]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.10.09 21:38
Оценка:
Здравствуйте, IT, Вы писали:

IT>К тому, что мы начали с того, что важнее IDE или язык и ты сам только что сказал, что IDE (как минимум дизайнеры) часто закрывают дыры в языке.


Не как "минимум", а "только".

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


Я не путаю. Чтобы перенести статики мне один фиг понадобятся более простые рефакторинги.

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


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

IT>Дни? На переименование методов?


Поля. Проблема в том, что место где оно встречается море (десятки тысяч мест) и имя перегруженное. Плюс сюда накладывается проблема бутсрипа когда просто переименование не прокатывает и 3 минуты на компиляцию.

IT>Для переименования поля не нужно тратить день.


Это реальный факт.

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


Нет. Для тупого переименования поля. Никакой логики не менялось. Я уже даже думал писать в компиляторе заплатку которая будет принуждать его генерировать список вхождений переменной. Еще раз повторюсь, что проблема осложнялась бутстрипингом. Два чася я тупо правил переменные по подсказкам компилятора, а потом оказывалось, что просто переименовать ее нельзя, так как она используется в макросе и квази-цитировании. Далее делалась другая попытка на которую тоже уходило два часа тупой работы. Через 8-10 часов я таки победим эту проблему введя fake-поле с тем же именем и поменяв код генерации квази-цитирования. Если бы мне нашли все вхождения (и не явные) этой переменной, то я бы справился бы за час, а то и за 15 минут.

IT>Объём каких работ? Влад, вот давай эксперимент, в следующий раз, когда ты потратишь день на какую-нибудь мелочь, ты расскажешь нам как-бы ты это делал с помощью автоматических средств рефакторинга. OK?


Могу описать тебе задачу и посмеяться над тем как ты будешь ее решать. В прочем я уже дал подсказку которая может сэкономит пол дня.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.10.09 21:50
Оценка:
Здравствуйте, thesz, Вы писали:

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


T>http://thesz.mskhug.ru/svn


50 файлов общим объемом 266 килобайт хаскелевского кода.
Объем проекта ниже среднего.

Что он хоть делает?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: Жизнь без IDE
От: thesz Россия http://thesz.livejournal.com
Дата: 02.10.09 22:00
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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


T>>http://thesz.mskhug.ru/svn


VD>50 файлов общим объемом 266 килобайт хаскелевского кода.

VD>Объем проекта ниже среднего.

VD>Что он хоть делает?


Модель процессора на основе потока данных.

Три типа разборщиков на монадах.

Разбор Фортрана. Fourier-Motzkin elimination.

Встроенный в Хаскель HDL.

Что-то ещё.

Твой репозиторий где?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[16]: Жизнь без IDE
От: MigMit Россия http://migmit.vox.com
Дата: 02.10.09 22:10
Оценка:
Здравствуйте, VladD2, Вы писали:

IT>>Дни? На переименование методов?


VD>Поля. Проблема в том, что место где оно встречается море (десятки тысяч мест) и имя перегруженное.


Вот именно поэтому я и утверждаю, что экспортировать конструкторы — не след. (Это к нашей с thesz вялой дискуссии).
Re[17]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.10.09 23:51
Оценка:
Здравствуйте, MigMit, Вы писали:

VD>>Поля. Проблема в том, что место где оно встречается море (десятки тысяч мест) и имя перегруженное.


MM>Вот именно поэтому я и утверждаю, что экспортировать конструкторы — не след. (Это к нашей с thesz вялой дискуссии).


Причем здесь конструкторы?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: Жизнь без IDE
От: MigMit Россия http://migmit.vox.com
Дата: 03.10.09 07:20
Оценка:
Здравствуйте, VladD2, Вы писали:

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


VD>>>Поля. Проблема в том, что место где оно встречается море (десятки тысяч мест) и имя перегруженное.


MM>>Вот именно поэтому я и утверждаю, что экспортировать конструкторы — не след. (Это к нашей с thesz вялой дискуссии).


VD>Причем здесь конструкторы?


При том самом. Если внутреняя структура типа видна вне модуля, в котором он определён — пиши пропало, потом нужно будет лазить по исходникам с лупой.
Re[13]: Жизнь без IDE
От: thesz Россия http://thesz.livejournal.com
Дата: 03.10.09 09:44
Оценка:
Здравствуйте, IT, Вы писали:

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


T>>Это всё теории.

T>>Моя практика показывает обратное.

IT>По всей видимости вы вместе со твоей практикой вещи просто уникальные. Вымирающий вид. Любой краеведческий музей через десять лет выделит для вас не то что полку, целый стеллаж!


Наоборот.

Мы племя младое, незнакомое!
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[19]: Жизнь без IDE
От: thesz Россия http://thesz.livejournal.com
Дата: 03.10.09 09:48
Оценка:
Здравствуйте, MigMit, Вы писали:

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


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


VD>>>>Поля. Проблема в том, что место где оно встречается море (десятки тысяч мест) и имя перегруженное.


MM>>>Вот именно поэтому я и утверждаю, что экспортировать конструкторы — не след. (Это к нашей с thesz вялой дискуссии).


VD>>Причем здесь конструкторы?


MM>При том самом. Если внутреняя структура типа видна вне модуля, в котором он определён — пиши пропало, потом нужно будет лазить по исходникам с лупой.


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

Конструктор — та же функция, и я не вижу причин, по которым я могу экспортировать функцию и не могу конструктор.

То, что конструктор участвует в сравнении с образцом, ничего не меняет. Всё равно мне как-то придётся делать выбор. Хоть pattern guards, хоть view, хоть предикатами.

Только жизнь себе усложню.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[16]: Жизнь без IDE
От: vshabanov http://vshabanov-ru.blogspot.com
Дата: 03.10.09 13:32
Оценка:
Здравствуйте, VladD2, Вы писали:

IT>>Дни? На переименование методов?


VD>Поля. Проблема в том, что место где оно встречается море (десятки тысяч мест) и имя перегруженное. Плюс сюда накладывается проблема бутсрипа когда просто переименование не прокатывает и 3 минуты на компиляцию.


IT>>Для переименования поля не нужно тратить день.


VD>Это реальный факт.


Теперь кажется становится ясно, почему ты не можешь без отладчика. Похоже, имеется некий трудно собираемый код, в котором на каждый чих надо ждать по 3 минуты компиляции. Понятно, что тебе проще поправить этот чих прямо в отладчике и продолжить выполнение. Т.е. фактически ты пользуешься не отладчиком как таковым, а edit&continue -- REPL для бедных.

Если код достаточно модульный и нет никакого bootstrapping-а, то пересборка -- это перекомпиляция одного-нескольких модулей. Не надо ждать тонну времени. Соответственно, edit&continue становится менее нужным.
Re[10]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.10.09 14:23
Оценка:
Здравствуйте, dr.Chaos, Вы писали:

DC>Угу, только вот найди мне рефакторинг: «перераспределить обязанности между классами и один из них, возможно, выкинь»


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

DC>Ну тут, видимо, опять вопрос в терминологии. Рефакторинг делается перед внесением фичи чтобы облегчить этот процесс.


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

DC>И основной стимул, тут не отсутствие средств (хотя что бы вы знали про vim, sed и awk ), а то что просто переписывание кода — это переливание из пустого в порожнее, т.к. код в итоге будет иметь «идеальную» архитектуру, а заказчик 0 новых функции и столько же багов.


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

DC>Мало того, потом окажется, что архитектура то не идеально и т.п.


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

DC>Основная цель рефаторингов изменить код так, чтоб его было проще менять под текущие и ближайшие цели, т.е. где-то добавить гибкости, где то убавить овердизайна. Ну и что касается твоего поинта: «большие рефакторинги состоят из кучи маленьких», — да, состоят, но по моему опыту занимают они не много времени ( может я их просто не замечаю благодаря «убогим» vim, sed, awk ).


Все зависит от объема проекта, наличия и изменений в целях и запущенности кода.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Жизнь без IDE
От: IT Россия linq2db.com
Дата: 03.10.09 18:50
Оценка:
Здравствуйте, thesz, Вы писали:

IT>>По всей видимости вы вместе со твоей практикой вещи просто уникальные. Вымирающий вид. Любой краеведческий музей через десять лет выделит для вас не то что полку, целый стеллаж!


T>Наоборот.

T>Мы племя младое, незнакомое!

Это племя известно науке со времён возникновения самой науки. Имя этому племени "Первый парень на деревне". Характерные особенности: красный диплом (или как минимум красные глаза от учёбы) в институте (опционально), длительная работа в замкнутом окружении в качестве главной/самой важной персоны, в результате завышенная самооценка и непоколебимая уверенность в собственной гениальности, неумение и нежелание работать в команде равных, переходящие в паническую боязнь.
Если нам не помогут, то мы тоже никого не пощадим.
Re[21]: Жизнь без IDE
От: thesz Россия http://thesz.livejournal.com
Дата: 03.10.09 21:18
Оценка:
Здравствуйте, MigMit, Вы писали:

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


MM>>>При том самом. Если внутреняя структура типа видна вне модуля, в котором он определён — пиши пропало, потом нужно будет лазить по исходникам с лупой.


T>>Конструктор — та же функция, и я не вижу причин, по которым я могу экспортировать функцию и не могу конструктор.


MM>Ну, блин...


MM>Вот у тебя в одном модуле написано

MM>А в другом
MM>Внезапно ты обнаружил, что тип нужно сделать более общим:
MM>Ищи его теперь в модуле B.

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

Неужто ты баг в ghc нашёл?

MM>И в B ничего менять не надо.


Это если они сводимы друг к другу.

T>>Только жизнь себе усложню.

MM>Как обычно — немного усложнишь поначалу, зато облегчишь потом.

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

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

А пока мне надо втыкать глубже, бросать дальше. В чём мне Хаскель весьма помогает, за что и ценИм.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[16]: Жизнь без IDE
От: IT Россия linq2db.com
Дата: 04.10.09 00:25
Оценка:
Здравствуйте, VladD2, Вы писали:

IT>>Дни? На переименование методов?

VD>Поля. Проблема в том, что место где оно встречается море (десятки тысяч мест) и имя перегруженное. Плюс сюда накладывается проблема бутсрипа когда просто переименование не прокатывает и 3 минуты на компиляцию.

Вот "плюс сюда накладывается" и есть самая большая проблема. А само по себе переименование не такая уж и большая.

IT>>Для переименования поля не нужно тратить день.

VD>Это реальный факт.

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

IT>>Объём каких работ? Влад, вот давай эксперимент, в следующий раз, когда ты потратишь день на какую-нибудь мелочь, ты расскажешь нам как-бы ты это делал с помощью автоматических средств рефакторинга. OK?

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

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

Впрочем, всё это не важно. Я отвечал на твой вопрос, что важнее язык или IDE. И смысл сказанного заключался в том, что IDE здорово помогает получать быстрые типовые решения. Особенно это было доведено до совершенства в Дельфи. Но после определённого момента IDE перестаёт играть столько важную роль и на первый план выходят возможности и выразительность языка.
Если нам не помогут, то мы тоже никого не пощадим.
Re[23]: Жизнь без IDE
От: thesz Россия http://thesz.livejournal.com
Дата: 04.10.09 19:44
Оценка:
Здравствуйте, MigMit, Вы писали:

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


MM>>>Ищи его теперь в модуле B.

T>>Неужто мне при компиляции про ошибки не скажут?
MM>При компиляции чего? Модуля A — не скажут. Модуля B — скажут. Через несколько дней. Когда у тебя до него руки дойдут.

У меня несколько циклов: микроцикл с исправлением ошибок компилятора, малый цикл с REPL, базовый цикл с тестированием программы на каких-то моих функциональных тестах и далее идёт использование.

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

Есть у нас различие в подходах к разработке?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[24]: Жизнь без IDE
От: MigMit Россия http://migmit.vox.com
Дата: 04.10.09 20:04
Оценка:
Здравствуйте, thesz, Вы писали:

T>Есть у нас различие в подходах к разработке?


Ты никогда не делаешь библиотек, которыми будут пользоваться другие?
Re[13]: Жизнь без IDE
От: Denom Украина  
Дата: 05.10.09 06:31
Оценка:
Здравствуйте, VladD2, Вы писали:

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


на чем (какой язык)?
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[25]: Жизнь без IDE
От: thesz Россия http://thesz.livejournal.com
Дата: 05.10.09 08:54
Оценка:
Здравствуйте, MigMit, Вы писали:

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


T>>Есть у нас различие в подходах к разработке?


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


Вот тогда я иногда делаю так, как ты сказал.

Но если у меня AST на 20+ типов, я его лучше так таскать буду.

Как это делают другие: http://haskell.org/ghc/docs/latest/html/libraries/haskell-src/Language-Haskell-Syntax.html которые поумней меня будут.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[25]: Жизнь без IDE
От: thesz Россия http://thesz.livejournal.com
Дата: 05.10.09 09:01
Оценка:
Здравствуйте, MigMit, Вы писали:

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


T>>Есть у нас различие в подходах к разработке?


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


Будем бить авторитетом: The disadvantage is that pattern matching, which is so useful, cannot be used on abstract data types (страница 8).
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[26]: Жизнь без IDE
От: MigMit Россия http://migmit.vox.com
Дата: 05.10.09 09:11
Оценка:
Здравствуйте, thesz, Вы писали:

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


T>Будем бить авторитетом: The disadvantage is that pattern matching, which is so useful, cannot be used on abstract data types (страница 8).


Чем хорошо фундаментальное математическое образование — приучает плевать на любые авторитеты с высокой колокольни.
Re[27]: Жизнь без IDE
От: thesz Россия http://thesz.livejournal.com
Дата: 05.10.09 10:35
Оценка:
Здравствуйте, MigMit, Вы писали:

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


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


T>>Будем бить авторитетом: The disadvantage is that pattern matching, which is so useful, cannot be used on abstract data types (страница 8).


MM>Чем хорошо фундаментальное математическое образование — приучает плевать на любые авторитеты с высокой колокольни.


То есть, ты не согласен.

Каковы твои аргументы?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[14]: Жизнь без IDE
От: Аноним  
Дата: 05.10.09 12:42
Оценка:
Здравствуйте, metaprogrammer, Вы писали:

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


А>>Хотелось бы конкретных примеров. Пока больше похоже на утверждение, что некоторое масло более масленное, чем какое-то другое.


M> Отличный пример функциональной декомпозиции был в журнале "Практика функционального программирования", про игру в шашки. Подробненько так, шаг за шагом.


Ничего уникального не увидел -- обычный структурный подход "сверху вниз". Для тех, кто начинал программировать на языках типа Фортран/Бейсик или Паскаль/Модула, там ничего нового. Разве что Haskell позволяет типы сразу не писать.

Так что ждем-с примеров функциональной декомпозиции.
Re[27]: Жизнь без IDE
От: thesz Россия http://thesz.livejournal.com
Дата: 05.10.09 12:57
Оценка:
Здравствуйте, MigMit, Вы писали:

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


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


T>>Будем бить авторитетом: The disadvantage is that pattern matching, which is so useful, cannot be used on abstract data types (страница 8).


MM>Чем хорошо фундаментальное математическое образование — приучает плевать на любые авторитеты с высокой колокольни.


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

Поскольку твой предыдущий ответ был получен менее, чем через 10 минут после моего комментария, я думаю, что четыре часа достаточно время для формулировки всего, чего надо.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[11]: Жизнь без IDE
От: dr.Chaos Россия Украшения HandMade
Дата: 05.10.09 13:30
Оценка:
Здравствуйте, VladD2, Вы писали:

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


Это если ты мыслишь в рамках этих операций.

VD>Не, рефакторинг делается тогда когда программист понимает, что текущее устройство кода отличается от его текущих воззрений.


Воззрений на что? На решаемую задачу? Или на ориентацию идентификаторов по Фен Шую?


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


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

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

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

Я об этом и говорю, ты упростил себе жизнь (сделал вообще возможным) добавление фичи/исправление бага.

DC>>Основная цель рефаторингов изменить код так, чтоб его было проще менять под текущие и ближайшие цели, т.е. где-то добавить гибкости, где то убавить овердизайна. Ну и что касается твоего поинта: «большие рефакторинги состоят из кучи маленьких», — да, состоят, но по моему опыту занимают они не много времени ( может я их просто не замечаю благодаря «убогим» vim, sed, awk ).


VD>Все зависит от объема проекта, наличия и изменений в целях и запущенности кода.


Влад, мне привести объём проекта в котором я работаю в мегабайтах?
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[11]: Жизнь без IDE
От: dr.Chaos Россия Украшения HandMade
Дата: 05.10.09 13:58
Оценка:
Здравствуйте, maxkar, Вы писали:

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

M>А можно ваше определение рефакторинга? Это то, что "делается перед внесением фичи, чтобы облегчить этот процесс"?. Просто если использовать, например, определение из wiki (которое более широкое, чем ваше), у меня получается, что как раз таки большая часть рефакторингов делается не перед внесением фичи а во время или сразу после внесения фичи, после изменения кода. Я в дальнейшем буду использовать термин "рефакторинг" для обозначения "изменения программы без изменения ее фунциональности (или внешнего поведения) с целью улучшения ее качества" (вольный перевод wiki). Если вас не устраивает — готов использовать другое название, только предложите Именно для того определения, которое я привел. Потому что такая активность существует и хочется как-то ее называть.


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


M>1. "Extract variable"...

M>2. "Introduce constant"...
M>3. "Extract method"...
M>4. "Rename something"...

Ээээ.... И это все возможности что предоставляет IDE?

M>Про рефакторинги поговорили, теперь перейдем к месту IDE в этом процессе. Я полностью согласен, что все эти рефакторинги в рассматриваемых ситуациях делаются легко вручную (rename something может быть сложнее, но ничего экстраординарного там нет). Первые три можно даже попробовать в текстовом редакторе реализовать. Первые два даже и не слишком сложно будет сделать (для vim), и это покроет большинство случаев применения. Только вот не в сложности или скорости здесь дело. Если посмотреть то, что я написал выше, получается, что я использую операции "назвать результат формулы", "назвать константу", "назвать функцию", "исправить имя aka rename". Эти операции фактически являются (реализованы с помощью) соответствующими рефакторингами. Ну а рефакторинги в качестве механизма уже перемещают блоки текста или чего там еще использует IDE. Все четыре операции имеют соответствующие комбинации горячих клавиш. В результате на 4-х комбинациях я имею 4 операции. Высокоуровневых операции, описываемых в терминах конструкций языка. Т.е. я не просто куда-то переношу куски текста, я выполняю некоторую вполне осмысленную и "высокоуровневую" трансформацию программы. Да, я могу сам выполнить и все низкоуровневые операции с кусками текста, но зачем? Ведь в языках же, наоборот, стремятся к большей выразительности при меньшем количестве кода. Ну да, мы получаем большую выразительность и "высокоуровневые" термины для написания программ. Но в IDE я также получаю "высокоуровневые" операции для манипуляции над программами. Т.е. не просто скопировать блок кода, а именно "перенести метод", например. Или 4 указанных операции. Детали реализации этих операций меня не сильно интересуют. А манипуляции существующим кодом в ряде отраслей важны. На самом деле это практически вся автоматизация бизнеса с ее изменениями требований и прочим, когда важно не только то, что написано сейчас, но и как из того, что было вчера сделать то, что нужно сегодня. Из-за непредсказуемости требований это тоже имеет свой fun. И для решения этих задач используются соответствующие инструменты (те же IDE). Причем, что интересно, вполне может быть, что требования к возможности изменения кода как раз гораздо выше, чем требования к его выразительности. Т.е. требования меняются часто и нам важна вся инфраструктура, возможности найти места для изменений в огромной кодовой базе и т.п. Поэтому в данном случае вопрос о наличии и возможностях IDE будет очень и очень актуален.


Т.е. ты хочешь сказать что эти 4 приёма являются полным и непротиворечивым базисом для совершения любого рефакторинга?

M>Немного напишу про упомянутцй "expand selection", который используется для 1-го и 3-го рефакторингов. Это расширение существующего выделения на логические блоки кода, уже содержащего выделение. Возможный пример для ocaml'а: исходная конструкция let a = if b > 0 then c + d else let e = c-d in e * e, исходное выделение — первая e в выражении e * e. Выделения при очередных расширениях:


M>

    M>
  1. e * (для выделения метода или переменной, например)
    M>
  2. e * e
    M>
  3. let e = ...
    M>
  4. if b > ...
    M>
  5. let a = ...
    M>
M>Опять же, мелочи, но для подготовки к рефакторингам очень удобно. Не нужно глазками искать начало блока, конец, тянуть выделение. Всего лишь контролируется, что "по дереву языка" мы пришли в то место, которое нам нужно и над которым выполняется операция. Опять же, я команды отдаю не в терминах "текстового редактора", а в терминах языка, его грамматики. Примерно того же рода копирование "фрагмента кода" в другой код. Мелочь, но import'ы для java тянутся и автоматически появляются в новом месте. А вот будет ли в OcaIDE что-нибудь сделано, когда я скопирую кусок из одного файла в другой (не помню, где собранная лежит дома, а для мелочей хватает и vim'а)? А и исходном файле у меня могли быть #open вначале, поэтому не все можно оставить как есть, нужно либо имя модуля дописать првы вызовах, либо директивы #open в целевом файле. Мне с "кодом" работать все же приятнее, чем с "текстовым представлением этого кода".

M>Ну и напоследок про «перераспределить обязанности между классами и один из них, возможно, выкинь». В таком виде рефакторинга нет. Он будет выполняться с помощью нескольких более простых. А вот в каких терминах мы будем работать при этих мелких рефакторингах — это большой вопрос. Можно таскать "куски текста" (понимая под этим перемещение метода, например). Только вот при этом нужно контролировать, что все зависимости утянуты и т.п. Возможно, метод менять (если часть методов осталось в одном классе, а часть уехала). А можно сказать, что "вот этот метод должен уехать в тот класс". При этом IDE может проверить зависимости (например, скажет, что ссылки остались на приватный метод и видимость ему нужно поменять), сама поменяет все ссылки на функции в исходном коде. При перемещении метода вверх в иерархии классов можно одним кликом сказать "добавить зависимости", проверить их и продолжить операцию. Ну да, наверное, все равно какие-то мелочи придется сделать "в тексте руками". Но если не все плохо, это будет малая часть. А большая часть будет в реорганизации структуры, фрагментов программы.


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

Когда ты говоришь что IDE тебе даёт "высокоуровневые операции для манипуляции над программой" ты не прав, все высокоуровневые манипуляции над программой тебе даёт твой мозг, а IDE тебе облегчает только маленькую часть из них, и самое плохое что набор операций маленький и нерасширяемый, т.е. ты, в итоге, начинаешь думать над переделкой дизайна в терминах того что предоставляет IDE. А если ты забиваешь на эти рамки, то получается что у тебя просто набор манипуляций над текстом программы, а в этом плане vim даст 100 очков форы.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[26]: Жизнь без IDE
От: z00n  
Дата: 05.10.09 14:40
Оценка:
Здравствуйте, thesz, Вы писали:

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


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


T>>>Есть у нас различие в подходах к разработке?


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


T>Будем бить авторитетом: The disadvantage is that pattern matching, which is so useful, cannot be used on abstract data types (страница 8).


А следующее предложение "Solutions to this problem are on the horizon" То, чего не было в Миранде circa 1987, есть в Scala и F#.
Re[27]: Жизнь без IDE
От: thesz Россия http://thesz.livejournal.com
Дата: 05.10.09 15:04
Оценка:
Здравствуйте, z00n, Вы писали:

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


T>>Будем бить авторитетом: The disadvantage is that pattern matching, which is so useful, cannot be used on abstract data types (страница 8).


Z>А следующее предложение "Solutions to this problem are on the horizon" То, чего не было в Миранде circa 1987, есть в Scala и F#.


Зачем мне использовать view, если я могу использовать исходные типы, получив при этом проверку полноты разбора по образцу?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[28]: Жизнь без IDE
От: z00n  
Дата: 05.10.09 15:47
Оценка:
Здравствуйте, thesz, Вы писали:

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


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


T>>>Будем бить авторитетом: The disadvantage is that pattern matching, which is so useful, cannot be used on abstract data types (страница 8).


Z>>А следующее предложение "Solutions to this problem are on the horizon" То, чего не было в Миранде circa 1987, есть в Scala и F#.


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

Чтобы не нарушать инкапсуляцию. В скале полнота проверяется, если иерархия "заперта".
Re[14]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.10.09 19:08
Оценка:
Здравствуйте, Denom, Вы писали:

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


D>на чем (какой язык)?


40 минут было только в С/С++. А проекты по 10К файлов были на разных языках, от Дельфи и C#-а до С++.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[26]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.10.09 19:10
Оценка:
Здравствуйте, thesz, Вы писали:

T>Но если у меня AST на 20+ типов, я его лучше так таскать буду.


А этот АСТ действительно нужен из вне?

Скажем если вы планируете расширения которые должны анализировать АСТ, то это одно. А если это отдельный проект, то его можно было бы оставить в рамках модуля.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[29]: Жизнь без IDE
От: thesz Россия http://thesz.livejournal.com
Дата: 05.10.09 20:15
Оценка:
Здравствуйте, z00n, Вы писали:

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


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

Z>Чтобы не нарушать инкапсуляцию. В скале полнота проверяется, если иерархия "заперта".

А мы говорим угадай про что?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[27]: Жизнь без IDE
От: thesz Россия http://thesz.livejournal.com
Дата: 05.10.09 20:17
Оценка:
Здравствуйте, VladD2, Вы писали:

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


T>>Но если у меня AST на 20+ типов, я его лучше так таскать буду.


VD>А этот АСТ действительно нужен из вне?


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


И внести все возможные анализы внутрь этого модуля.

Нет уж.

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

Доступ извне может быть и закрыт. Это уже дело вкуса.

Иерархические модули Хаскеля отлично подходят для этой цели.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[11]: Жизнь без IDE
От: metaprogrammer  
Дата: 05.10.09 20:31
Оценка:
Здравствуйте, VladD2, Вы писали:

M>> Я правильно понял, что до где-то года 96-го все поголовно решали слишком примитивные задачи, поскольку приличных IDE просто не было (ой, мне сейчас опять про VisualAge начнут напоминать...)?


VD>Ну, почему только про VisualAge. Смолток был в 80-ом и до IBM-а.


И много на том смолтолке писали? IDE были не нужны, и вдруг разом стали нужны, так что ли?

VD> А задачи, действительно реашалось более примитивные.


Это не так. Преимущественно куда как более сложные, чем сейчас.

VD> То что тогда казалось подвигом, сейчас обычное дело.


Примерчик можно?

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


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


Не "не могут", а не пытаются. Потому что те, кто мог бы написать IDE, уже давно все эти цацки и побрякушки переросли. А кому нужны IDE, те не осилят написать.

VD>Агащазблин. Проект может только загружаться в этот РЕПЛ по несколько минут.


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

VD> А если РЕПЛ интерпретирующий, то загруженый проект может просто перестать предоставлять приемлемый отклик.


Какие занятные представления о REPLах. Интересно, откуда? Python, наверное?

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


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

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


Тем, что это частный случай возможностей REPL. Весьма ограниченный.

VD>Это чушь.


Ну ну. Не тебе судить.

VD> Отладчика это не заменит.


Но ведь заменяет, вот в чём пафос.

VD> Да и само наличие "скрипта" уже говорит, что что-то не так.


Опять же, извини, но не тебе судить.

VD> В прочем, я понял что в данном случае речь идет скорее всего о неком диалекте лиспа.


Совершенно не обязательно. В разных случаях это были:

— IronPython
— Jython
— F#
— Lua
— даже Forth

M>> REPL распрекрасно рулит и заруливает и для ни разу не функциональных языков.


VD>Лисп?


См. выше, из них только один с большой натяжкой функциональный.
Re[15]: Жизнь без IDE
От: metaprogrammer  
Дата: 05.10.09 20:34
Оценка:
Здравствуйте, VladD2, Вы писали:

M>> Отличный пример функциональной декомпозиции был в журнале "Практика функционального программирования", про игру в шашки. Подробненько так, шаг за шагом.


VD>Можно ссылку?


http://fprog.ru/2009/issue1/dmitry-astapov-checkers/

VD>ЗЫ


VD>Рабяты. Вы точно терминологией владеете?


Точно, точно.
Re[13]: Жизнь без IDE
От: metaprogrammer  
Дата: 05.10.09 20:37
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Это очередная выдумка.


Не стоит. Это глупо.

VD> REPL не встраивается в приложения F#.


Встраивается. Тривиально. И, что ещё интереснее, REPL от F# встраивается вообще в любое .NET-приложение. Его можно повесить ждать на какой либо порт, и подключаться по мере надобности.

VD> Если я имею запущенное приложение F#, то РЕПЛ к нему уже не подключить.


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

VD> А вот отладчик — можно.


Толку то до этого отладчика.

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


Консоль в Oblivion видел?
Re[13]: Жизнь без IDE
От: metaprogrammer  
Дата: 05.10.09 20:42
Оценка:
Здравствуйте, VladD2, Вы писали:

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


Ну, это ещё мелочёвка.

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


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


Видал я тех, кто "умеет готовить". Лучше бы я их не видел. Наихудший способ решения проблем из всех возможных.
Re[15]: Жизнь без IDE
От: metaprogrammer  
Дата: 05.10.09 20:45
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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


В ML модули параметризованные.

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


А вот где бы мне почитать не в учебнике для У/О, а на нормальном уровне изложенную строгую формальную модель объектного анализа?

Нет такой.

VD>А вот выдуманная тобой новая модель только в твоем воображении и существует.


А вот семантическая модель — таки есть, формальная.
Re[15]: Жизнь без IDE
От: metaprogrammer  
Дата: 05.10.09 20:48
Оценка:
Здравствуйте, VladD2, Вы писали:

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


Занятно. А я логику интерфейсов MSVS изучал как раз из консоли F#. Без всяких отладчиков.

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


Для работы паталогоанатома отладчик конечно же незаменим. Только не стоит и переоценивать важность такой работы.
Re[14]: Жизнь без IDE
От: Cyberax Марс  
Дата: 05.10.09 21:11
Оценка:
Здравствуйте, metaprogrammer, Вы писали:

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


VD>>>>Ну, почему только про VisualAge. Смолток был в 80-ом и до IBM-а.

M>>> И много на том смолтолке писали?
C>>Много.

M> Не Smalltalk определят лицо индустрии. И сложные задачи решались в основном не на нём. Да, блин, сложные задачи решались (и сейчас решаются) даже на Фортране!


C>>Не совсем. До где-то середины 90-х сложные IDE были невозможны на x86 технически. Но даже простые IDE типа Turbo Pascal'а/Borland C++ уже в ту пору рулили.

M> Да ну, какие это на фиг IDE?
Такие.

M> Редактор с запускалкой компилятора и хелпа и подсветкой ошибок. Ничего из того, о чём тут говорит Влад, там и близко не было. Никакого автоматизированного рефакторинга, никакого автокомплита и прочих сомнительных прелестей.

Отладчики ещё были.

Однако, даже тогда мало кто любил без тех средств работать.

C>>Они просто подняли производительность труда и снизили планку входа.

M> А всякие там emacs на пару с sed и awk на ещё большие высоты поднимали производительность труда. И что?
Не поднимали. Emacs лучше Borland C++, но уже хуже MSVS версии так седьмой.

M>>> Это не так. Преимущественно куда как более сложные, чем сейчас.

C>>Какие?
M> Библиотек мало было, все постоянно велосипеды сложные изобретали. Кодирования из готовых кубиков не существовало как класса, а сейчас 90% программирования — сборка из готовых кубиков.
И что? Это только те сложности, которые сами себе создавали, чтобы героически преодолевать.

M>>> Примерчик можно?

C>>Отладка кода в режиме ядра, к примеру. Сейчас я спокойно это делаю символьным отладчиком из IDE.
M> Это частности.
И их много.
Sapienti sat!
Re[15]: Жизнь без IDE
От: metaprogrammer  
Дата: 05.10.09 21:25
Оценка:
Здравствуйте, Cyberax, Вы писали:

M>> Редактор с запускалкой компилятора и хелпа и подсветкой ошибок. Ничего из того, о чём тут говорит Влад, там и близко не было. Никакого автоматизированного рефакторинга, никакого автокомплита и прочих сомнительных прелестей.

C>Отладчики ещё были.

И? Где там все эти рефакторинги с интеллисенсами? Не было их, и не надо было. Жили как-то.

C>Однако, даже тогда мало кто любил без тех средств работать.


В 80х? Да нет, много кто без всего этого прекрасно обходился.

C>Не поднимали. Emacs лучше Borland C++, но уже хуже MSVS версии так седьмой.


Да? Правда, что ли? Ничего себе новости.

C>И что? Это только те сложности, которые сами себе создавали, чтобы героически преодолевать.


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

M>> Это частности.

C>И их много.

И все они никакого отношения к IDE не имеют, что характерно.
Re[15]: Жизнь без IDE
От: Курилка Россия http://kirya.narod.ru/
Дата: 05.10.09 21:30
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


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


C>>>Не совсем. До где-то середины 90-х сложные IDE были невозможны на x86 технически. Но даже простые IDE типа Turbo Pascal'а/Borland C++ уже в ту пору рулили.


C>Однако, даже тогда мало кто любил без тех средств работать.


C>>>Они просто подняли производительность труда и снизили планку входа.

M>> А всякие там emacs на пару с sed и awk на ещё большие высоты поднимали производительность труда. И что?
C>Не поднимали. Emacs лучше Borland C++, но уже хуже MSVS версии так седьмой.

Чтот у меня не сходится: вроде речь про середину 90-х, а седьмая студия — это уже .Net (ещё без цифры) и 2002-й год. Кто-то что-то тут не то
Да даже 6.0 ито лишь в середине 98-го появилась.
А с емаксом, подозреваю, что вопросы были в том, насколько он был под винду юзабелен в то время (сам не в курсе).
Re[16]: Жизнь без IDE
От: Cyberax Марс  
Дата: 06.10.09 02:54
Оценка:
Здравствуйте, metaprogrammer, Вы писали:

M>>> Редактор с запускалкой компилятора и хелпа и подсветкой ошибок. Ничего из того, о чём тут говорит Влад, там и близко не было. Никакого автоматизированного рефакторинга, никакого автокомплита и прочих сомнительных прелестей.

C>>Отладчики ещё были.
M> И? Где там все эти рефакторинги с интеллисенсами?
Были в некоторых IDE (для ST).

M> Не было их, и не надо было. Жили как-то.

Насчёт "не надо было" — не надо

В Дельфи навигация появилась где-то в 95-м году, это ОЧЕНЬ тогда помогало. Source navigator для С++ появился тогда же. А в VC6 уже был и неплохой индексатор.

C>>Однако, даже тогда мало кто любил без тех средств работать.

M> В 80х? Да нет, много кто без всего этого прекрасно обходился.
Ну да. Вариантов-то не было.

C>>Не поднимали. Emacs лучше Borland C++, но уже хуже MSVS версии так седьмой.

M> Да? Правда, что ли? Ничего себе новости.
Факт, однако. Популярность Emacs'а как раз после конца 90-х резко пошла вниз.

C>>И что? Это только те сложности, которые сами себе создавали, чтобы героически преодолевать.

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

M>>> Это частности.

C>>И их много.
M> И все они никакого отношения к IDE не имеют, что характерно.
Что характерно, имеют.
Sapienti sat!
Re[16]: Жизнь без IDE
От: Cyberax Марс  
Дата: 06.10.09 02:59
Оценка:
Здравствуйте, Курилка, Вы писали:

C>>Не поднимали. Emacs лучше Borland C++, но уже хуже MSVS версии так седьмой.

К>Чтот у меня не сходится: вроде речь про середину 90-х, а седьмая студия — это уже .Net (ещё без цифры) и 2002-й год. Кто-то что-то тут не то
К>Да даже 6.0 ито лишь в середине 98-го появилась.
Да, это я говорю уже про конец 90-х.

К>А с емаксом, подозреваю, что вопросы были в том, насколько он был под винду юзабелен в то время (сам не в курсе).

Вполне юзабелен был.
Sapienti sat!
Re[16]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.10.09 18:40
Оценка:
Здравствуйте, metaprogrammer, Вы писали:

M> Занятно. А я логику интерфейсов MSVS изучал как раз из консоли F#. Без всяких отладчиков.


И как? Можно глянуть на результат?

M> Для работы паталогоанатома отладчик конечно же незаменим. Только не стоит и переоценивать важность такой работы.


Я ее не переоцениваю.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.10.09 18:48
Оценка:
Здравствуйте, metaprogrammer, Вы писали:

M>>> IDE были не нужны, и вдруг разом стали нужны, так что ли?

C>>Не совсем. До где-то середины 90-х сложные IDE были невозможны на x86 технически. Но даже простые IDE типа Turbo Pascal'а/Borland C++ уже в ту пору рулили.

M> Да ну, какие это на фиг IDE? Редактор с запускалкой компилятора и хелпа и подсветкой ошибок. Ничего из того, о чём тут говорит Влад, там и близко не было. Никакого автоматизированного рефакторинга, никакого автокомплита и прочих сомнительных прелестей.


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

C>>Они просто подняли производительность труда и снизили планку входа.


M> А всякие там emacs на пару с sed и awk на ещё большие высоты поднимали производительность труда. И что?


Тогда у людей еще емаксов не было. Емакс вышел из стен МИТ-а где-то в 80-ых. ГНУтый емакс — это 1984. К тому же это штуковина на любителя.

VD>>>> То что тогда казалось подвигом, сейчас обычное дело.

M>>> Примерчик можно?
C>>Отладка кода в режиме ядра, к примеру. Сейчас я спокойно это делаю символьным отладчиком из IDE.

M> Это частности.


Это реалии жизни. Код тогда было писать сложнее. Задачи были примитивнее. Теперь код казалось бы писать проще, но сложность задач выросла многократно компенсировавав упрощение жизни.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Жизнь без IDE
От: BulatZiganshin  
Дата: 08.10.09 08:18
Оценка:
Здравствуйте, VladD2, Вы писали:

C>>>Не совсем. До где-то середины 90-х сложные IDE были невозможны на x86 технически. Но даже простые IDE типа Turbo Pascal'а/Borland C++ уже в ту пору рулили.


M>> Да ну, какие это на фиг IDE? Редактор с запускалкой компилятора и хелпа и подсветкой ошибок. Ничего из того, о чём тут говорит Влад, там и близко не было. Никакого автоматизированного рефакторинга, никакого автокомплита и прочих сомнительных прелестей.


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


в середине 90-х? и медведи заглядывали в окна, как же без этого

простые ide (turbo pascal) появились в начале 80-х, года с 87-го в них стали появляться отладчики. в конце 80-х были turbo pascal, rurbo c++, quick msc, ms power bench, так что обычные программисты (те что сейчас пользуются msvs) были уже об-ide-чены. рефакторингов/автокомплитов действительно до середины 90-х я не видел
Люди, я люблю вас! Будьте бдительны!!!
Re[16]: Жизнь без IDE
От: BulatZiganshin  
Дата: 08.10.09 09:23
Оценка:
Здравствуйте, z00n, Вы писали:

Z>Но в то время уже давно (с середины 70-x) были, лисп-машины с настоящими IDE — на них, например, разрабатывали Smalltalk (Xerox Dorado и Dolphin).


smalltalk появился в начале 70-х, только речь наверно шла о массовых программистах. для них первой ide был наверно turbo-pascal. и это кстати одна из причин его бешеной поппулярности — цпрщение цикла edit-compile-lonk до "нажал кнопку и тебе показали место ошибки"
Люди, я люблю вас! Будьте бдительны!!!
Re[16]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.10.09 14:28
Оценка:
Здравствуйте, z00n, Вы писали:

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


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

Z>Даже если у человека на было денег на workstation, это скорее был бы Brief или KEDIT.

Ага KEDIT. А далее выходишь в команд промт и давай батники вызвать. Сам так какое-то время работал.
И это был не очень удобно, как в прочем и тогдашний KEDIT.

Z>Но в то время уже давно (с середины 70-x) были, лисп-машины с настоящими IDE — на них, например, разрабатывали Smalltalk (Xerox Dorado и Dolphin).


А вот это уже чушь. Где они были то? У очень ограниченного круга людей имеющих доступ к очень дорогой аппаратуре. А простые смертные довольствовались фортраном или С с васиком в лучшем случае.

Z>Нортон коммандера тем более еще не было — первая версия вышла в 86-ом)


Дык все и работали в командной строке вплоть до 90-ых. Первые IDE как раз из нортона и вызвались.

Z>Весь UNIX был написан в редакторе ed- это не было большой проблемой так как вместо мониторов были телетайпы :)


Вот имнно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.10.09 14:39
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

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


BZ>в середине 90-х? :))) и медведи заглядывали в окна, как же без этого :)


BZ>простые ide (turbo pascal) появились в начале 80-х, года с 87-го в них стали появляться отладчики. в конце 80-х были turbo pascal, rurbo c++, quick msc, ms power bench, так что обычные программисты (те что сейчас пользуются msvs) были уже об-ide-чены. рефакторингов/автокомплитов действительно до середины 90-х я не видел


А что собственно изменилось с 1983 (когда появилась первая IDE) до 1995-го когда появился первый интеллисенс (в распространненых IDE)? Подскажу — скорость процессоров. Ее стало достаточно для анализа кода в "реалтайме".
В середине 90-ых появились "Пни" т.е. первые пентиумы с 60-90 Мгц. Их даже не распаковку видео не хватало тогда. В конце же 90-ых машины уже легко справлялись с интелессенсом для простых языков.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: Жизнь без IDE
От: BulatZiganshin  
Дата: 08.10.09 14:50
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>А что собственно изменилось с 1983 (когда появилась первая IDE) до 1995-го когда появился первый интеллисенс (в распространненых IDE)? Подскажу — скорость процессоров. Ее стало достаточно для анализа кода в "реалтайме".

VD>В середине 90-ых появились "Пни" т.е. первые пентиумы с 60-90 Мгц. Их даже не распаковку видео не хватало тогда. В конце же 90-ых машины уже легко справлялись с интелессенсом для простых языков.

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

просто идёт постепенное развитие. ты предыдущую эпоху не застал, и тебе кажется, что is — это нечто принципиально новое и крутое. а в моей жизни это например была встроенная отладка
Люди, я люблю вас! Будьте бдительны!!!
Re[17]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.10.09 14:52
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

BZ>smalltalk появился в начале 70-х, только речь наверно шла о массовых программистах.


В конце, скорее. А то что было доступно ограниченному кругу лиц, а не было внутренней разработкой, вообще в начале 80-ых.

Лично я смог увидеть Смолток только в 90-ых.

BZ> для них первой ide был наверно turbo-pascal. и это кстати одна из причин его бешеной поппулярности — цпрщение цикла edit-compile-lonk до "нажал кнопку и тебе показали место ошибки"


Так и есть. К тому же Смолток не обладал IDE. Там была другая идеология — идеология имиджа. Свойства конечно схожи, но далеко не идентичны. IDE же имеет смысл только когда мы говорим о языках с традиционной файловой организацией.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: Жизнь без IDE
От: BulatZiganshin  
Дата: 08.10.09 14:54
Оценка:
Здравствуйте, VladD2, Вы писали:

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


BZ>>smalltalk появился в начале 70-х, только речь наверно шла о массовых программистах.


VD>В конце, скорее.


насколько я помню, был смоллтолк-70, так что начало ращзарьотки — это конец 60-х. не знаю, была ли там среда с самого начала

BZ>> для них первой ide был наверно turbo-pascal. и это кстати одна из причин его бешеной поппулярности — цпрщение цикла edit-compile-lonk до "нажал кнопку и тебе показали место ошибки"


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


ну зачем искуственно разграничивать. главное чтобы было удобно
Люди, я люблю вас! Будьте бдительны!!!
Re[18]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.10.09 15:06
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

BZ>я так не думаю. во-первых, у большинства программистов стояли машины слабее.


Дык, темболее!

BZ> во-вторых, что по твоему — пни на 100% этим анализом загружались?


Первый интеллисенс был очень ограниченным и был реализован для языков которые очень легко парсить и типизировать.
Самый первый случай интеллисенса который я мог наблюдать — это была Gupta SQLWindows (ныне Team Developer). Она была доступна (если не ошибаюсь) где-то в середине. Но там не было контекстного интеллисенса. SQLWindows был полупроцедурным языком у которого по началу не было текстового представления. Код переставлялся неким деревом. Так вот у него был боковой рулбар в котором был список имеющихся функций, которые, к слову, имели удобную структурированную систему префиксов. Но даже это здорово ускоряло разработку, особенно для новичка не знавшего местный АПИ. Потом был VB 4 (опять же если не ошибаюсь). Как известно Васик очень легко парсится и типизируется. В нем ведь даже не было наследования. Классы были очень примитивными. А вот первый интеллисенс для С++ был просто чудовшино медленным и много врал. В прочем, он и сейчас не сильно лучше. Хотя и техника другая, и времени на разработку было предостаточно. Но главное, что на технике вроде той что была в моем распоряжении в 1993-ем создать идее с интеллисенсом было практически невозможно. Даже список функцй не поместился бы в память (640 К весьма не много).

BZ>просто идёт постепенное развитие.


Несомненно. Но развиваться на машинах с 2 гигами памяти как-то значительно проще чем на машине с 2 килами :).

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


Я ее застал. Конец скорее, но застал. И мне не кажется, я точно понимаю, что скажем стложность тогдашней IDE и современной не может идти ни в какое сравнение. То же самое можно сказать и любых других областях. И все это, как ты точно заметил, в следствии того, что идет постепенное развитие. Развитие оно идет везеде. Даже те же Лиспы развиваются. Например, по прошестрвии 50 лет возможно скоро появится первый не глючный компилятор лиспа для виндовс. :)) (злорадствую, не обращайте внимания)
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.10.09 15:13
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:


VD>>В конце, скорее.


BZ>насколько я помню, был смоллтолк-70, так что начало ращзарьотки — это конец 60-х. не знаю, была ли там среда с самого начала


Самый первый был 72, но его мало кто видел.

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


BZ>ну зачем искуственно разграничивать. главное чтобы было удобно


Затем, что другая идеология, другие средства. Вы же не называете REPL словом IDE?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Жизнь без IDE
От: kitsunekko  
Дата: 09.10.09 12:20
Оценка:
VD>Так что тот же REPL может быть и не плох, особенно для чистого ФЯ (коим ОКамл не является), но опять же ему не плохо было бы быть встроеным в IDE.
Так встрой — хотя бы Nemerle Console
Автор: alvas
Дата: 13.02.09

После F# без интерпретатора ломка начинается.
Как минимум нужны команды "загрузить файл" и "приликовать сборку".
Cкрипты для интерпретатора типа .fsi тоже хотелось бы.
Re[10]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.10.09 13:02
Оценка:
Здравствуйте, kitsunekko, Вы писали:

VD>>Так что тот же REPL может быть и не плох, особенно для чистого ФЯ (коим ОКамл не является), но опять же ему не плохо было бы быть встроеным в IDE.

K>Так встрой — хотя бы Nemerle Console
Автор: alvas
Дата: 13.02.09


Кто-то уже это делал. Где-то был плагин.

K>После F# без интерпретатора ломка начинается.


Это пока что первый случай.

K>Как минимум нужны команды "загрузить файл" и "приликовать сборку".

K>Cкрипты для интерпретатора типа .fsi тоже хотелось бы.

Откровенно говоря я считаю, что реализация вещей которые тебе не нужны и мало интересны не приведут к хорошему результату. Тут хорошо бы найти человека которому этот РЕПЛ был бы нужен самому.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Жизнь без IDE
От: LaPerouse  
Дата: 24.10.09 19:47
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

BZ>изюм тут вот в чём — интересная работа — это когда ты описываешь сложные алгоритмы. и хаскель позволяет писать их почти на естсевенном языке.


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

Языки с унификацией (пролог-семейство) делают маленький шаг по направлению к естественным языкам. И именно в силу этого свойства неприменимы на практике.
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[19]: Жизнь без IDE
От: Трурль  
Дата: 24.10.09 20:33
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:


BZ>насколько я помню, был смоллтолк-70, так что начало ращзарьотки — это конец 60-х. не знаю, была ли там среда с самого начала


Это ты с прямым углом перепутал.
Re[10]: Жизнь без IDE
От: deniok Россия  
Дата: 24.10.09 21:21
Оценка:
Здравствуйте, LaPerouse, Вы писали:

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


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

LP>Языки с унификацией (пролог-семейство) делают маленький шаг по направлению к естественным языкам. И именно в силу этого свойства неприменимы на практике.


Пх, прологовская унификация с бэктрэкингом — всего лишь один из великого множества алгоритмов. Чем он так важен, никто пока не объяснил.
Re[10]: Жизнь без IDE
От: VoidEx  
Дата: 24.10.09 21:25
Оценка:
Здравствуйте, LaPerouse, Вы писали:

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


BZ>>изюм тут вот в чём — интересная работа — это когда ты описываешь сложные алгоритмы. и хаскель позволяет писать их почти на естсевенном языке.


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

Я тут функцию написал с использованием нескольких бесконечных списков, где список формируется локальной функцией, принимающей на вход то, что она сгенерировала до этого (но не список, применяются некоторые трансформации), а ещё на вход подаётся окончательный результат (с помощью fix), который получается из куска бесконечного списка.
В общем, я к чему клоню, если нарисовать картинку, выглядит всё просто (только выходы подаются на входы и т.п.), переносится с картинки в код и обратно — легко (т.е. код понятен), однако я боюсь даже представить это на елдах каких-нибудь, тут на всю задействована ленивость. Если будет время, интереса ради перепишу, да сравню, хотя вряд ли, писькой трясти и нести добро в массы лень, а для себя я выводы уже сделал.
А, ну и да, у меня был изначально тупой относительно императивный алгоритм (именно он приходит в голову первым, так как его проще "придумать"), однако он выглядел ужасно. На большинстве языков выбора не будет, либо этот ужасный алгоритм, либо ленивость через елды, и не менее ужасный код.
Re[20]: Жизнь без IDE
От: thesz Россия http://thesz.livejournal.com
Дата: 24.10.09 23:07
Оценка:
Здравствуйте, Трурль, Вы писали:

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



BZ>>насколько я помню, был смоллтолк-70, так что начало ращзарьотки — это конец 60-х. не знаю, была ли там среда с самого начала


Т>Это ты с прямым углом перепутал.


Не совсем: The first version, known as Smalltalk-71, was created in a few mornings on a bet that a programming language based on the idea of message passing inspired by Simula could be implemented in "a page of code."[1]

http://en.wikipedia.org/wiki/Smalltalk
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[12]: Жизнь без IDE
От: thesz Россия http://thesz.livejournal.com
Дата: 24.10.09 23:34
Оценка:
Здравствуйте, LaPerouse, Вы писали:

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


Было бы интересно увидеть пример не рекурсивного алгоритма. Желательно, не тривиального.

То, что я изучал, они все, как один "вот базис индукции, вот шаг индукции, вперёд!"
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[12]: Жизнь без IDE
От: thesz Россия http://thesz.livejournal.com
Дата: 24.10.09 23:36
Оценка:
Здравствуйте, LaPerouse, Вы писали:

LP>Бэктрэкинг — всего лишь один из способов реализации унификации.

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

Унификация без отката не Тьюринг-полна. По-моему, такой вариант называется унификацией Милнера. Поэтому унификация с лямбдой — понятия разных категорий.

Впрочем, это я просто так, потыкать палочкой.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[11]: Жизнь без IDE
От: LaPerouse  
Дата: 24.10.09 23:52
Оценка:
Здравствуйте, deniok, Вы писали:

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


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


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


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

LP>>Языки с унификацией (пролог-семейство) делают маленький шаг по направлению к естественным языкам. И именно в силу этого свойства неприменимы на практике.


D>Пх, прологовская унификация с бэктрэкингом — всего лишь один из великого множества алгоритмов. Чем он так важен, никто пока не объяснил.


Бэктрэкинг — всего лишь один из способов реализации унификации. Само унификация универсальна, в этом смысле они с лямбдой — понятия одной категории (впрочем во всем этом я разбираюсь мало).
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[11]: Жизнь без IDE
От: LaPerouse  
Дата: 24.10.09 23:57
Оценка:
Здравствуйте, VoidEx, Вы писали:

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


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


BZ>>>изюм тут вот в чём — интересная работа — это когда ты описываешь сложные алгоритмы. и хаскель позволяет писать их почти на естсевенном языке.


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

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

Ничего удивительного, просто это был изначально рекурсивный алгоритм, понятное дело что на хаскеле он будет выглядеть как родной.
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[11]: Жизнь без IDE
От: LaPerouse  
Дата: 24.10.09 23:59
Оценка:
test
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[10]: Жизнь без IDE
От: vshabanov http://vshabanov-ru.blogspot.com
Дата: 25.10.09 10:19
Оценка:
Здравствуйте, LaPerouse, Вы писали:

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


BZ>>изюм тут вот в чём — интересная работа — это когда ты описываешь сложные алгоритмы. и хаскель позволяет писать их почти на естсевенном языке.


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


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

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

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

LP>Языки с унификацией (пролог-семейство) делают маленький шаг по направлению к естественным языкам. И именно в силу этого свойства неприменимы на практике.


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

PS. Имеется стойкое ощущение, что ни с хаскеллом, ни с прологом ты не знаком.
Re[12]: Жизнь без IDE
От: vshabanov http://vshabanov-ru.blogspot.com
Дата: 25.10.09 10:23
Оценка:
Здравствуйте, LaPerouse, Вы писали:

LP>Вон в хаскеле загнали ИП в резервации-монады и устроили функциональный рай. Дискриминация, однако. А между тем, это обычная парадигма программирования, такая же, как фп. Чем она такое заслужила?


Тем, что ИП выражается через ФП, а наоборот нет. ИП -- более узко, более сложно и опасно, его надо держать в резервации, чтобы не приносило проблем.
Re[11]: Жизнь без IDE
От: LaPerouse  
Дата: 25.10.09 18:23
Оценка:
Здравствуйте, vshabanov, Вы писали:

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


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


BZ>>>изюм тут вот в чём — интересная работа — это когда ты описываешь сложные алгоритмы. и хаскель позволяет писать их почти на естсевенном языке.


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


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


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

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

V>Хаскел действительно тупой, язык уровня ассемблера. Только не ассемблера для машин фон-неймана/регистровых машин, а ассемблера для типизированной лямбды.


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

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


Java и C++ очень старые языки для подобного сравнения. Берем Scala и видим, что у haskell остается очень мало преимуществ в сравнении с ней.

LP>>Языки с унификацией (пролог-семейство) делают маленький шаг по направлению к естественным языкам. И именно в силу этого свойства неприменимы на практике.


V>Пролог очень узкий, медленный и не типизированный. Его проще встроить в другой язык, чем использовать только его.


Все правильно. Только к чему ты это написал?

V>PS. Имеется стойкое ощущение, что ни с хаскеллом, ни с прологом ты не знаком.


Я знаком с тем и другим в достаточной мере, чтобы приблизительно судить о достоинствах/недостатках.
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[13]: Жизнь без IDE
От: LaPerouse  
Дата: 26.10.09 11:48
Оценка:
Здравствуйте, vshabanov, Вы писали:

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


LP>>Вон в хаскеле загнали ИП в резервации-монады и устроили функциональный рай. Дискриминация, однако. А между тем, это обычная парадигма программирования, такая же, как фп. Чем она такое заслужила?


V>Тем, что ИП выражается через ФП, а наоборот нет.


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

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


Повторяю, это просто другая парадигма программирования. Со своими плюсами и минусами. Можно подумать, что у ФП нет плохих сторон. По мнению авторитетов у ФП вообще есть фатальный недостаток — страдает модульность, что недопустимо при проектировании крупных систем. Вот что к примеру пишет Питер Ван Рой в своем CTM:

Functional languages encourage the overuse of higher-order programming.
Typical examples are monads and currying. Monads are used to encode
state by threading it throughout the program. This makes programs more
intricate but does not achieve the modularity properties of true explicit
state (see Section 4.7).
Currying lets you apply a function partially by
giving only some of its arguments. This returns a new function that expects
the remaining arguments. The function body will not execute until all
arguments are there. The flipside is that it is not clear by inspection whether
the function has all its arguments or is still curried (“waiting” for the rest).


Подробнее об этом читать разделе 4.7, где указанные недостатки демонстрируется на конкретных примерах.
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[6]: Жизнь без IDE
От: LaPerouse  
Дата: 26.10.09 12:35
Оценка:
Здравствуйте, thesz, Вы писали:

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


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

По-моему отрицающие пользу IDE личности либо ни разу в глаза их не видели, либо принимают за IDE те убогие поделия, которые существуют для C++. Посмотрите на современные продукты типа Eclipse или IDEA, попробуйте вбить в них хотя бы 10 кб кода, тогда мнение ваше резко изменится

Сейчас я расскажу вкратце о своем среднестатистическом сеансе работы в Eclipse. Пишу тест. Эклипс компилирует файлы по мере ввода, подчеркивая ошибки. Поскольку функциональность, задействованная в тесте, как правило не реализована он подчеркивает красным практически все. После того, как тест написан, пробегаемся по коду, нажимая на Ctrl+1 на подчеркнутых токенах и выбираем автоматически предлагаемое действие — создаем пакет-класс-метод или изменяем сигнатуру существующего метода. Красные подчеркивания изсчезают. Потом нажимаю на F12 (по умолчанию F3) для перехода на сгенерированный эклипсом кусок кода, набираю код, пользуясь такими фичами, как assign statement to new local variable/field или extract to method, потом нажимаю на Ctrl+Tab для возврата к тесту и так далее для каждого новосозданного куска кода. После реализации запускаю тест прямо из среды разработки и тут же вижу детальные результаты выполнения. Далее при необходимости вхожу в отладку используя великолепный встроенный отладчик. Остановившись в точке останова, могу использовать окно Display для набора произвольных выражений (эта штука являясь сама по себе разновидностью REPL по мощи намного превосходит его, так как позволяет работать в контексте текущего брейкпоинта).
Отлаженный код сигнализирует зеленой полоской плагина junit-a. После этого остается только положить код в SVN пользуясь встроенной интеграцией с системой контроля версий. Если приложение нуждается в профилировке, тут же можно запустить интегрированный профилировщик.

По сравнению с вышеперечисленным хардкорная работа в обычном текстовом редакторе выглядит прошлым веком. Вимы и емаксы кажутся настолько архаичными, примитивными и неудобными, что заставить себя набрать в них хотя бы двадцать строчек кода уже не могу (раньше мог).
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[8]: Жизнь без IDE
От: LaPerouse  
Дата: 26.10.09 12:52
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


C>>>А сказки про "скорость ввода" не надо мне рассказывать. Я уже не помню чего в ViMе было бы, чего нет в той же IDEA. Там есть и прямоугольные выделения, и кольцо буфферов обмена, закладки, возможность повторять N последних действий.

DR>>В IDEA появилась поддержка Немерле? При чём он тут?
C>Я говорил про IDE вообще. Всё перечисленное есть для Scala.

Скорее нет чем есть. Плагин для Eclipse пока сырой и кривой.

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

C>Ну я как бы пользовался ViM'ом. Не помню я чего там такого есть замечательного.

А в нем и нет ничего замечательного, обычный консольный редактор.
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[9]: Жизнь без IDE
От: Cyberax Марс  
Дата: 26.10.09 12:54
Оценка:
Здравствуйте, LaPerouse, Вы писали:

DR>>>В IDEA появилась поддержка Немерле? При чём он тут?

C>>Я говорил про IDE вообще. Всё перечисленное есть для Scala.
LP>Скорее нет чем есть. Плагин для Eclipse пока сырой и кривой.
IDEA стала OpenSource. Кому теперь нужен Eclipse?
Sapienti sat!
Re[14]: Жизнь без IDE
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 26.10.09 12:57
Оценка:
Здравствуйте, LaPerouse, Вы писали:

LP>Повторяю, это просто другая парадигма программирования. Со своими плюсами и минусами. Можно подумать, что у ФП нет плохих сторон. По мнению авторитетов у ФП вообще есть фатальный недостаток — страдает модульность, что недопустимо при проектировании крупных систем. Вот что к примеру пишет Питер Ван Рой в своем CTM:


LP>

LP>Functional languages encourage the overuse of higher-order programming.
LP>Typical examples are monads and currying. Monads are used to encode
LP>state by threading it throughout the program. This makes programs more
LP>intricate but does not achieve the modularity properties of true explicit
LP>state (see Section 4.7).


LP>Подробнее об этом читать разделе 4.7, где указанные недостатки демонстрируется на конкретных примерах.


Я внимательно просмотрел 4.7 — там нет ни слова о монадах.

И я до сих пор не понимаю, как возможность выделить состояние в тип, позволив ограничивать работу с ним, позволив быть ему composable быть запутанным и менее модульным, чем состояние в ИП, размазанное по всей программе?
Re[14]: Жизнь без IDE
От: deniok Россия  
Дата: 26.10.09 13:02
Оценка:
Здравствуйте, LaPerouse, Вы писали:


LP>Если подходить формально, это две разные парадигмы, ИП — основанное на модификации состояния, ФП -на чистых функциях. Как только ты начнешь "выражать ИП через ФП", ФП перестанет быть таковым. Обратное также справедливо.

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

Это какие-то рассуждения, безуспешно пытающиеся выглядеть правдоподобными. Возможность доступа к внешнему для функции состоянию ликвидирует саму возможность говорить о доказуемых гарантиях ее чистоты. А состояние с контролируемой локальностью вводится в чистом ФП запросто:
-- описывам вычисление над состоянием
-- (в do-нотации выглядело бы еще более императивно)
tick :: State Int Int
tick = get >>= \n -> put (n+1) >> return n
-- делаем вычисление (императивщина локальна внутри монады State)
plusOne :: Int -> Int
plusOne n = execState tick n
-- делаем вычисление несколько раз
plus :: Int -> Int -> Int
plus n x = execState (sequence $ replicate n tick) x
-- кстати, sequence $ replicate n tick :: State Int [Int]
-- то есть мы еще в монаде State

Проверяем
> plusOne 41
42
> plus 2 3
5
Re[7]: Жизнь без IDE
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 26.10.09 13:04
Оценка:
Здравствуйте, LaPerouse, Вы писали:

LP>По-моему отрицающие пользу IDE личности либо ни разу в глаза их не видели, либо принимают за IDE те убогие поделия, которые существуют для C++. Посмотрите на современные продукты типа Eclipse или IDEA, попробуйте вбить в них хотя бы 10 кб кода, тогда мнение ваше резко изменится


Я работал в IDEA с версии 2.5, если не ошибаюсь. В Эклипсе тоже несколько лет.

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


А мне вот после vim-а в Эклипсе неудобно. И да, я много пишу на Java.
Re[15]: Жизнь без IDE
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 26.10.09 13:12
Оценка:
Здравствуйте, lomeo, Вы писали:

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


Извиняюсь, что написал не по-русски, но, думаю, вопрос понятен?
Re[15]: Жизнь без IDE
От: LaPerouse  
Дата: 26.10.09 13:24
Оценка:
Здравствуйте, deniok, Вы писали:

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


"доказуемые гарантии чистоты" пусть идут в баню вместе с теоретиками. а нам простым индусам нужно быстро писать код.

D>А состояние с контролируемой локальностью вводится в чистом ФП запросто:

D>
D>-- описывам вычисление над состоянием
D>-- (в do-нотации выглядело бы еще более императивно)
D>tick :: State Int Int
D>tick = get >>= \n -> put (n+1) >> return n
D>-- делаем вычисление (императивщина локальна внутри монады State)
D>plusOne :: Int -> Int
D>plusOne n = execState tick n
D>-- делаем вычисление несколько раз
D>plus :: Int -> Int -> Int
D>plus n x = execState (sequence $ replicate n tick) x
D>-- кстати, sequence $ replicate n tick :: State Int [Int]
D>-- то есть мы еще в монаде State
D>


Что я вижу? Обычный объект, инкапсулирующий состояние. Какое же это ФП? Тогда и java по-твоему функциональный язык?
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[10]: Жизнь без IDE
От: LaPerouse  
Дата: 26.10.09 13:37
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


DR>>>>В IDEA появилась поддержка Немерле? При чём он тут?

C>>>Я говорил про IDE вообще. Всё перечисленное есть для Scala.
LP>>Скорее нет чем есть. Плагин для Eclipse пока сырой и кривой.
C>IDEA стала OpenSource. Кому теперь нужен Eclipse?

Очевидно тем, кто считает Eclipse более удобной и мощной средой чем IDEA.
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[16]: Жизнь без IDE
От: deniok Россия  
Дата: 26.10.09 13:41
Оценка:
Здравствуйте, LaPerouse, Вы писали:


LP>Что я вижу? Обычный объект, инкапсулирующий состояние.


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

LP>Какое же это ФП? Тогда и java по-твоему функциональный язык?


Нет, java не функциональный язык, она не сводится к лямбда-исчислению.
Re[11]: Жизнь без IDE
От: Cyberax Марс  
Дата: 26.10.09 13:42
Оценка:
Здравствуйте, LaPerouse, Вы писали:

DR>>>>>В IDEA появилась поддержка Немерле? При чём он тут?

C>>>>Я говорил про IDE вообще. Всё перечисленное есть для Scala.
LP>>>Скорее нет чем есть. Плагин для Eclipse пока сырой и кривой.
C>>IDEA стала OpenSource. Кому теперь нужен Eclipse?
LP>Очевидно тем, кто считает Eclipse более удобной и мощной средой чем IDEA.
А, ну они заблуждаются.
Sapienti sat!
Re[16]: Жизнь без IDE
От: LaPerouse  
Дата: 26.10.09 13:45
Оценка:
Здравствуйте, lomeo, Вы писали:

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


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


L>Извиняюсь, что написал не по-русски, но, думаю, вопрос понятен?


Вопрос понятен. Непонятно, чем ты руководствовался, задавая его Ведь ИП — он сильно разный бывает. Если для укрощения дикого состояния, которое похоже любителям хаскеля кажется средоточием вселенского зла, использовать ООП, то получим ровно то, о чем ты написал. Можно конечно сделать тоже самое с монадой State, но при чем тут спрашивается ФП?
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[12]: Жизнь без IDE
От: LaPerouse  
Дата: 26.10.09 13:47
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


DR>>>>>>В IDEA появилась поддержка Немерле? При чём он тут?

C>>>>>Я говорил про IDE вообще. Всё перечисленное есть для Scala.
LP>>>>Скорее нет чем есть. Плагин для Eclipse пока сырой и кривой.
C>>>IDEA стала OpenSource. Кому теперь нужен Eclipse?
LP>>Очевидно тем, кто считает Eclipse более удобной и мощной средой чем IDEA.
C>А, ну они заблуждаются.

А я считаю что заблуждаются те, кто считают IDEA едва ли не вершиной совершенства. Да,редактор кода может получше будет, однако совокупная мощь платформы Eclipse задавит кого хочешь. Даже NetBeans. К тому же открыли только небольшую часть проекта.
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[17]: Жизнь без IDE
От: LaPerouse  
Дата: 26.10.09 13:54
Оценка:
Здравствуйте, deniok, Вы писали:

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



LP>>Что я вижу? Обычный объект, инкапсулирующий состояние.


D>Нет, это только видимость. Обычный объект — плохо определенное понятие, неявно апеллирующее к свойствам рантайма. Монада же State (как и большинство других) вводится чисто синтаксически.


Если оно крякает как утка, плавает как утка и выглядит как утка, то это, вероятно, утка и есть.

Социализм — это власть трудящихся и централизованная плановая экономика.
Re[17]: Жизнь без IDE
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 26.10.09 14:01
Оценка:
Здравствуйте, LaPerouse, Вы писали:

LP>Вопрос понятен. Непонятно, чем ты руководствовался, задавая его Ведь ИП — он сильно разный бывает. Если для укрощения дикого состояния, которое похоже любителям хаскеля кажется средоточием вселенского зла, использовать ООП, то получим ровно то, о чем ты написал. Можно конечно сделать тоже самое с монадой State, но при чем тут спрашивается ФП?


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

1) запутанными
2) менее модульными, чем явное состояние

Оба эти пункта я взял из твоей цитаты, как раз то, что ты сам выделил. Затем я показал, что вижу гораздо бОльшую ясность и модульность в том, что мы можем не только делать ровно то же самое, но ещё и ограничивать использование и обращаться с состоянием как с first-class value. Именно об этой разнице в моём понимании и цитате я и спросил.

Сейчас же оказывается, что это одно и то же (выделенное). Т.е. монады состояния как минимум не хуже явного состояния. Следовательно, проблем с модульностью у ФП нет. Тогда к чему ты привёл эту цитату? Или монады — не ФП?
Re[18]: Жизнь без IDE
От: LaPerouse  
Дата: 26.10.09 14:05
Оценка:
Здравствуйте, lomeo, Вы писали:

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


LP>>Вопрос понятен. Непонятно, чем ты руководствовался, задавая его Ведь ИП — он сильно разный бывает. Если для укрощения дикого состояния, которое похоже любителям хаскеля кажется средоточием вселенского зла, использовать ООП, то получим ровно то, о чем ты написал. Можно конечно сделать тоже самое с монадой State, но при чем тут спрашивается ФП?


L>Я так понял, что монады, инкапсулирующие состояние, отличаются от императивного решения тем, что являются


L>1) запутанными

L>2) менее модульными, чем явное состояние

L>Оба эти пункта я взял из твоей цитаты, как раз то, что ты сам выделил. Затем я показал, что вижу гораздо бОльшую ясность и модульность в том, что мы можем не только делать ровно то же самое, но ещё и ограничивать использование и обращаться с состоянием как с first-class value. Именно об этой разнице в моём понимании и цитате я и спросил.


Я не понял. Состояние оно либо есть либо нет. С монадой State чистота функции нарушается? Нарушается. Все, ФП кончился. Началась суровая жизнь

L>Сейчас же оказывается, что это одно и то же (выделенное). Т.е. монады состояния как минимум не хуже явного состояния. Следовательно, проблем с модульностью у ФП нет. Тогда к чему ты привёл эту цитату? Или монады — не ФП?


Да, см. выделенное. Это не фп. Ну, и более запутанные тоже.
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[13]: Жизнь без IDE
От: Cyberax Марс  
Дата: 26.10.09 14:09
Оценка:
Здравствуйте, LaPerouse, Вы писали:

C>>А, ну они заблуждаются.

LP>А я считаю что заблуждаются те, кто считают IDEA едва ли не вершиной совершенства. Да,редактор кода может получше будет, однако совокупная мощь платформы Eclipse задавит кого хочешь.
Нет, это Eclipse — помойка несовместимых плугинов. До интегрированности IDEA ей как до Луны.

LP>Даже NetBeans.

LOL! Кому вообще нафиг NetBeans нужен, чтоб с ним сравнивать?

LP>К тому же открыли только небольшую часть проекта.

Достаточну для разработки на Scala.
Sapienti sat!
Re[19]: Жизнь без IDE
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 26.10.09 14:15
Оценка:
Здравствуйте, LaPerouse, Вы писали:

LP>Я не понял. Состояние оно либо есть либо нет. С монадой State чистота функции нарушается? Нарушается. Все, ФП кончился. Началась суровая жизнь


В чём проблема состояния по твоему? Решает ли эту проблему монада State?
Re[20]: Жизнь без IDE
От: LaPerouse  
Дата: 26.10.09 14:40
Оценка:
Здравствуйте, lomeo, Вы писали:

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


LP>>Я не понял. Состояние оно либо есть либо нет. С монадой State чистота функции нарушается? Нарушается. Все, ФП кончился. Началась суровая жизнь


L>В чём проблема состояния по твоему?


Знал я когда то, но уже забыл
В SICP написано на эту тему много. Да и в том же CTM должно быть (хотя я не читал эту книгу).
Основная проблема состояния — это его изменяемость и как следствие отсутствие прочной опоры под ногами. То есть сущность которая находится в одном состоянии в определенный момент времени может изменить состояние, при этом оставшись семантически той же самой сущностью. Поэтому возможны ошибки, когда другие сущности, зависящие от нее, перестают быть совместимыми с этим новым состоянием. В ФП вместо изменения какой то сущности предлагается пересоздать ее, одновременно пересоздав (если требуется) все другие сущности, которые от нее зависят. Тем самым решается проблема несовместимости, но привносятся новые проблемы. Одна из них — нарушение модульности. Смотри секцию 4.7 в CTM, там хорошо написано.
То есть нет серебряной пули. То, что прекрасно решает одни проблемы, порождает другие. Поэтому хорошо использовать мультипарадигменные языки, которые позволят использовать наиболее приемлемое для данной задачи решение.

L>Решает ли эту проблему монада State?


Да не знаю я. Я вижу, что на примерах оно ничем не отличается от объекта, функции перестают быть чистыми, то есть фп здесь и не пахнет. Это я твердо знаю. Как она устроена и как связана с основами мироздания — не ко мне вопрос.
Кстати, поясни пожалуйста, чем таки эта монада отличается от объекта (если отличается)
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[20]: Жизнь без IDE
От: LaPerouse  
Дата: 26.10.09 14:57
Оценка:
Здравствуйте, deniok, Вы писали:

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


LP>>Я не понял. Состояние оно либо есть либо нет. С монадой State чистота функции нарушается? Нарушается. Все, ФП кончился. Началась суровая жизнь


D>А, так ты даже этого не знаешь! Ты просто Хаскелл мало изучал. Открою тебе страшную тайну — с монадой State чистота функции не нарушается. Монада State — чисто синтаксическая конструкция, безо всякого тайного хакерства, чистая как слеза ребенка:


как же не нарушается, если я вижу, что нарушается?
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[21]: Жизнь без IDE
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 26.10.09 15:00
Оценка:
Здравствуйте, LaPerouse, Вы писали:

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


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

LP>В ФП вместо изменения какой то сущности предлагается пересоздать ее, одновременно пересоздав (если требуется) все другие сущности, которые от нее зависят. Тем самым решается проблема несовместимости, но привносятся новые проблемы. Одна из них — нарушение модульности. Смотри секцию 4.7 в CTM, там хорошо написано.


Я прочитал эту секцию. Нарушения модульности при использовании монады — нет. Был один интерфейс у функций (a -> M b), такой же и остался.

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


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

L>>Решает ли эту проблему монада State?


LP>Да не знаю я. Я вижу, что на примерах оно ничем не отличается от объекта, функции перестают быть чистыми, то есть фп здесь и не пахнет. Это я твердо знаю. Как она устроена и как связана с основами мироздания — не ко мне вопрос.

LP>Кстати, поясни пожалуйста, чем таки эта монада отличается от объекта (если отличается)

Это всего лишь функция s -> (a,s). Кстати, чистая.

s у нас состояние, a — результат. Просто, будучи зашитой в монаду мы не видим s, а работаем с a напрямую:

counter <- get
let newCounter = counter + 1
put newCounter


Могу и подробнее, если интересно.
Re[21]: Жизнь без IDE
От: deniok Россия  
Дата: 26.10.09 15:10
Оценка:
Здравствуйте, LaPerouse, Вы писали:

LP>как же не нарушается, если я вижу, что нарушается?


Ткни пальцем, где?
Re[8]: Жизнь без IDE
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.10.09 15:40
Оценка:
Здравствуйте, lomeo, Вы писали:

L>А мне вот после vim-а в Эклипсе неудобно. И да, я много пишу на Java.


В vim-е?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[21]: Жизнь без IDE
От: Mr.Cat  
Дата: 26.10.09 15:42
Оценка:
Здравствуйте, LaPerouse, Вы писали:
LP>То есть сущность которая находится в одном состоянии в определенный момент времени может изменить состояние, при этом оставшись семантически той же самой сущностью.
Очень похоже на один из сценариев использования stm. В мире фп как минимум в clojure и хаскеле все необходимые для этого средства уже есть. Один из этих языков даже чистый.
Re[22]: Жизнь без IDE
От: LaPerouse  
Дата: 26.10.09 15:53
Оценка:
Что-то рсдн периодически валится.

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

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


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


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


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

LP>>В ФП вместо изменения какой то сущности предлагается пересоздать ее, одновременно пересоздав (если требуется) все другие сущности, которые от нее зависят. Тем самым решается проблема несовместимости, но привносятся новые проблемы. Одна из них — нарушение модульности. Смотри секцию 4.7 в CTM, там хорошо написано.


L>Я прочитал эту секцию. Нарушения модульности при использовании монады — нет. Был один интерфейс у функций (a -> M b), такой же и остался.


Ну значит монады какие-то не те. Автор ведь не уточняет, какие монады имеет ввиду.
И кстати он их там не использует, то есть описываемые в секции 4.7 проблемы касаются чистого безмонадического фп. Может быть монады, решая проблему кривого интерфейса в секции 4.7, привносят какую-то новую проблему. Например ту, о которой он говорит в приведенном мной куске вступления:

Monads are used to encode state by threading it throughout the program. This makes programs more intricate but does not achieve the modularity properties of true explicit state


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

L>Это всего лишь функция s -> (a,s). Кстати, чистая.

L>s у нас состояние, a — результат. Просто, будучи зашитой в монаду мы не видим s, а работаем с a напрямую:
L>
L>counter <- get
L>let newCounter = counter + 1
L>put newCounter
L>


L>Могу и подробнее, если интересно.


Ничего не понял. Вижу изменяемый объект. Что, фишка в том, что на этот объект нельзя ссылаться кроме как из тела данной функции?
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[14]: Жизнь без IDE
От: thesz Россия http://thesz.livejournal.com
Дата: 26.10.09 15:54
Оценка:
Здравствуйте, LaPerouse, Вы писали:

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

T>>Было бы интересно увидеть пример не рекурсивного алгоритма. Желательно, не тривиального.
T>>То, что я изучал, они все, как один "вот базис индукции, вот шаг индукции, вперёд!"

LP>Пример не рекурсивного алгоритма? Алгоритм реализующий итеративный процесс. Может записываться в виде хвостовой рекурсии, однако рекурсивным он от этого не станет.


Иными словами, здесь снова базис и шаг индукции.

Что интересно, при записи такого алгоритма делают чёткое различие между предыдущим и вычисляемым состоянием. То есть, работают функционально.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[22]: Жизнь без IDE
От: Курилка Россия http://kirya.narod.ru/
Дата: 26.10.09 15:54
Оценка:
Здравствуйте, lomeo, Вы писали:

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


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


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


А можешь как-то более развёрнуто его аргументировать это мнение?
Re[7]: Жизнь без IDE
От: thesz Россия http://thesz.livejournal.com
Дата: 26.10.09 15:57
Оценка:
Здравствуйте, LaPerouse, Вы писали:

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


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


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


LP>По-моему отрицающие пользу IDE личности либо ни разу в глаза их не видели, либо принимают за IDE те убогие поделия, которые существуют для C++. Посмотрите на современные продукты типа Eclipse или IDEA, попробуйте вбить в них хотя бы 10 кб кода, тогда мнение ваше резко изменится


~100 КБ на Eclipse.

Резюме?

Байда.

LP>Сейчас я расскажу вкратце о своем среднестатистическом сеансе работы в Eclipse. Пишу тест. Эклипс компилирует файлы по мере ввода, подчеркивая ошибки. Поскольку функциональность, задействованная в тесте, как правило не реализована он подчеркивает красным практически все. После того, как тест написан, пробегаемся по коду, нажимая на Ctrl+1 на подчеркнутых токенах и выбираем автоматически предлагаемое действие — создаем пакет-класс-метод или изменяем сигнатуру существующего метода. Красные подчеркивания изсчезают. Потом нажимаю на F12 (по умолчанию F3) для перехода на сгенерированный эклипсом кусок кода, набираю код, пользуясь такими фичами, как assign statement to new local variable/field или extract to method, потом нажимаю на Ctrl+Tab для возврата к тесту и так далее для каждого новосозданного куска кода. После реализации запускаю тест прямо из среды разработки и тут же вижу детальные результаты выполнения. Далее при необходимости вхожу в отладку используя великолепный встроенный отладчик. Остановившись в точке останова, могу использовать окно Display для набора произвольных выражений (эта штука являясь сама по себе разновидностью REPL по мощи намного превосходит его, так как позволяет работать в контексте текущего брейкпоинта).

LP>Отлаженный код сигнализирует зеленой полоской плагина junit-a. После этого остается только положить код в SVN пользуясь встроенной интеграцией с системой контроля версий. Если приложение нуждается в профилировке, тут же можно запустить интегрированный профилировщик.

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

И привет!

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


Тебе решают рутинные задачи, которых в принципе могло бы и не быть.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[14]: Жизнь без IDE
От: LaPerouse  
Дата: 26.10.09 16:01
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


C>>>А, ну они заблуждаются.

LP>>А я считаю что заблуждаются те, кто считают IDEA едва ли не вершиной совершенства. Да,редактор кода может получше будет, однако совокупная мощь платформы Eclipse задавит кого хочешь.
C>Нет, это Eclipse — помойка несовместимых плугинов. До интегрированности IDEA ей как до Луны.

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

LP>>Даже NetBeans.

C>LOL! Кому вообще нафиг NetBeans нужен, чтоб с ним сравнивать?

Да я само об той среде низкого мнения, так как в ней практически отсутствует редактор кода, но поддержка J2EE в ней хорошая, инструментария много.

LP>>К тому же открыли только небольшую часть проекта.

C>Достаточну для разработки на Scala.

И что, плагином для скалы можно пользоваться?
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[23]: Жизнь без IDE
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 26.10.09 16:27
Оценка:
Здравствуйте, Курилка, Вы писали:

К>А можешь как-то более развёрнуто его аргументировать это мнение?


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

Плюс — простой базис обладает рядом преимуществ. Для меня важен простой reasoning. В случае сложного базиса рассуждать уже сложнее. Ну как мы программы на Яве пишем?
Re[12]: Жизнь без IDE
От: vshabanov http://vshabanov-ru.blogspot.com
Дата: 26.10.09 17:47
Оценка:
Здравствуйте, LaPerouse, Вы писали:

V>>Хаскел действительно тупой, язык уровня ассемблера. Только не ассемблера для машин фон-неймана/регистровых машин, а ассемблера для типизированной лямбды.


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


Ну естественный человеческий язык для записи алгоритмов -- это equational reasoning + индукция. Хаскелл -- это оно и есть.

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


LP>Java и C++ очень старые языки для подобного сравнения. Берем Scala и видим, что у haskell остается очень мало преимуществ в сравнении с ней.


У Хаскелла есть фундаментальное преимущество -- он чистый. Чистота опупительно повышает модульность. Van Roy, конечно, приводит вымученный пример с добавлением логов, который проще сделать с мутабельностью/глобальными переменными. Но это настолько малая часть по сравнению с остальными задачами в программировании, что не стоит обращать на это внимание. А кроме модульности чистотв упрощает reasoning (особливо в сочетании с индукцией по алгебраическим типам, хотя в скале оно вроде есть).

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

Третье преимущество -- ленивость. Ленивые вычисления дают большую выразительную силу.

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

LP>>>Языки с унификацией (пролог-семейство) делают маленький шаг по направлению к естественным языкам. И именно в силу этого свойства неприменимы на практике.


V>>Пролог очень узкий, медленный и не типизированный. Его проще встроить в другой язык, чем использовать только его.


LP>Все правильно. Только к чему ты это написал?


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

V>>PS. Имеется стойкое ощущение, что ни с хаскеллом, ни с прологом ты не знаком.


LP>Я знаком с тем и другим в достаточной мере, чтобы приблизительно судить о достоинствах/недостатках.


Видимо все-таки в недостаточной мере, т.к. твои суждения часто расходятся с суждениями более знакомых товарищей.
Re[24]: Жизнь без IDE
От: LaPerouse  
Дата: 26.10.09 18:03
Оценка:
Здравствуйте, lomeo, Вы писали:

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


L>Это неправда. Или ты не так понял.


Как еще можно понять вот это?

Так что же, в конце концов, Haskell просто открыл заново императивное колесо?

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


"Мягкое введение в хаскель"
http://www.rsdn.ru/article/haskell/haskell_part1.xml#EDGBG
Автор(ы): Пол Хьюдак, Джон Петерсон, Джозеф Фасел
Дата: 03.03.2007
Задача данного материала – обеспечить «мягкое» введение в программирование на Haskell для имеющих опыт программирования, по крайней мере, на одном языке, желательно функциональном (даже если это «почти функциональный» язык, такой как ML или Scheme).


У Душкина тоже было кое-что на эту тему, но я книгу уже отдал.

L>Во-первых, монады — это не императивщина. Императивщина реализуется через монады. Но через монады можно реализовать (и реализуют) не только императивщину. С другой стороны, состояние (или нечто на него похожее) можно реализовать не только через монады. Это уже известные функции с аккумуляторами, это потоки, FRP.


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

L>Именно к этой цитате и был у меня вопрос. Что такого intricate делает state монада, если она наоборот убирает запутанность, локализую изменения? Мне непонятно. Почему не достигается модульность, если все свойства модульности соблюдаются? Опять неясно. Отсюда мой вопрос.

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

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

LP>>Ничего не понял. Вижу изменяемый объект. Что, фишка в том, что на этот объект нельзя ссылаться кроме как из тела данной функции?


L>Можно, но тогда мы должны это явно указывать в типе функции, в которой используем именно это состояние.


L>Смысл в чём. У тебя есть код с состоянием. P1, P2, P3 из книги. Для того, чтобы использовать его при явном состоянии, тебе достаточно просто вызвать его в любом месте — и всё. Вызвал не там — поломал. В случае, когда этот код завёрнут в монаду, для вызова тебе нужно "запустить" состояние. То же самое, что ты делаешь и с функциями с аккумулятором — передаёшь начальное значение аккумулятора. Чистота сохраняется, модульность не нарушается.


L>Т.е. в двух словах (оперируя примерами из книги). Ты получаешь декларативный код с аккумуляторами, который выглядит как код с явным состоянием. Из-за того, что сигнатура у него как у явного состояния — модульность не нарушается — снаружи ничего менять не надо. Из-за того, что реально внутри он использует аккумуляторы, код остаётся чистым.


L>Т.е. в чём то автор прав. Если сигнатура у нас чистая (в смысле не монадическая) — мы не можем сделать изменение в состоянии, не нарушив условия модульности. Но в случае сигнатуры a -> M b в интерфейсе модуля, мы можем как угодно менять состояние в функциях и снаружи ничего перекомпилировать не надо. Как-то так.


L>Может быть тебе стоит посмотреть внимательнее на монаду State? Она по сути очень несложная — это функция s -> (a,s), т.е. на входе исходное состояние, на выходе результат и конечно состояние. Объединяя эти функции мы получаем последовательность, т.к. каждое следующее состояние зависит от предыдущего. То же самое и тот же способ, что и в случае с аккумуляторами. Заворачивая её в монаду мы можем писать, не передавая состояние явно, т.е. получаем код, близкий к императивному.


Спасибо за объяснение, теперь понял. Но все же и ты не будешь отрицать, что решить проблему модульности помогло решение, пришедшее из императивного мира, пусть и лишенное многих его недостатков (но надо думать не всех, и надо думать лишенное кое-каких преимуществ, например глобальности — ведь глобальность в некоторых случаях нужна).
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[22]: Жизнь без IDE
От: LaPerouse  
Дата: 26.10.09 18:08
Оценка:
Здравствуйте, deniok, Вы писали:

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


LP>>как же не нарушается, если я вижу, что нарушается?


D>Ткни пальцем, где?


Я бы конечно ткнул, но вы же опять скажете, что "это локальные изменения", а я не понимаю толком эту лапшу, чтобы достойно возразить.
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[25]: Жизнь без IDE
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 26.10.09 18:20
Оценка:
Здравствуйте, LaPerouse, Вы писали:

LP>Ну ладно, я же говорил не про все монады, а только про State. Остальные в контексте нашей беседы неинтересны (за исключением IO).


Значит я тебя не понял. Все монады состояний (и IO в том числе) — эмулируют императивное вычисление.

LP>Кстати, это можно у него самого спросить, он весьма доступен для общения в мейл-листе языка Моцарт.


Ты оказался ближе

LP>Спасибо за объяснение, теперь понял. Но все же и ты не будешь отрицать, что решить проблему модульности помогло решение, пришедшее из императивного мира, пусть и лишенное многих его недостатков (но надо думать не всех, и надо думать лишенное кое-каких преимуществ, например глобальности — ведь глобальность в некоторых случаях нужна).


Глобальность возможна только через unsafe хаки, да. Ещё недостаток у этого решения — надо чуть больше писать.
Re[23]: Жизнь без IDE
От: deniok Россия  
Дата: 26.10.09 18:37
Оценка:
Здравствуйте, LaPerouse, Вы писали:

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


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


LP>>>как же не нарушается, если я вижу, что нарушается?


D>>Ткни пальцем, где?


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


Ну, вроде lomeo уже разъяснил про State. IO — это другое дело, она специально создана для взаимодействия с глобальным окружением. А State — это как раз пример того, что изменяемое состояние может успешно моделироваться чистыми средствами. При этом обладая всеми необходимыми для изменяемого состояния свойствами.

В отличие от этого чистота никогда не гарантируется императивными языками; никто и ни в каком императивном языке не запретит мне вызвать внутри функции что-то типа getCurrentTime() и организовать зависимость возвращаемого значения от результата такого вызова.
Re[19]: Жизнь без IDE
От: VoidEx  
Дата: 26.10.09 20:56
Оценка:
Здравствуйте, LaPerouse, Вы писали:

LP>Я не понял. Состояние оно либо есть либо нет. С монадой State чистота функции нарушается?

Нет

А вот в ИП чистоту в ФВП вообще не получить, так как нет такого типа "чистая функция" и в любой твой "чистый" алгоритм можно передать print, что мы и наблюдаем при обсуждении моего предложения генерировать фолды в Немерле автоматически: "а в какую сторону, по вашему обходить". В ИП это имеет значение и никак от этой "грязи" не избавишься.
Re[9]: Жизнь без IDE
От: thesz Россия http://thesz.livejournal.com
Дата: 26.10.09 22:31
Оценка:
Здравствуйте, LaPerouse, Вы писали:

T>>~100 КБ на Eclipse.

T>>Резюме?
T>>Байда.
LP>А язык? Нужно именно на java попробовать, поскольку только jdt находится во вменяемом состоянии. cdt по определению обречен, а остальные языки не получают должного внимания со стороны разработчиков.

Ну!

Я про то и говорю. Про Эклипс вкупе с языком.

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

T>>И привет!
LP>Чего-чего? Эклипс автоматически создает такой класс:
LP>
LP>public class CalcMode
LP>

LP>И пустой метод заглушку при создании метода Или ты думал что эклипс сам еще код пишет

Вообще-то, я собирался автоматически код писать.

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

И всё!

В Эклипсе мы приехали. Слезаем.

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

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

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

На одну строку кода приходится, наверное, 0.5% файлов и 1-2% классов.

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

LP>Еще процентов 20 — анализ написанного тобой или кем-то другим. И среда разработки призвана как раз облегчить эту техническую работу, занимающую в виме 70 процентов времени, а в эклипсе — процентов 35.


Насчёт чтения — согласен.

Но это уж язык такой, что описанием типа метода не отделаешься, надо обязательно взглянуть внутрь, чтобы понять, что же он делает.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[10]: Жизнь без IDE
От: LaPerouse  
Дата: 27.10.09 08:20
Оценка:
Здравствуйте, lomeo, Вы писали:

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


LP>>Чего-чего? Эклипс автоматически создает такой класс:


LP>>
LP>>/**
LP>> * 
LP>> */
LP>>package eNet.calc_module_integration;

LP>>/**
LP>> * @author lprs
LP>> *
LP>> */
LP>>public class CalcMode
LP>>{
LP>>}
LP>>


L>Кстати! Может интересно будет. У меня в vim-е вот такие сниппеты тоже были. А потом я почему то перестал их использовать (ну разве что для getter/setter-ов — это же просто ужас какой то). Написать, конечно, медленнее, но на мою производительность совершенно не влияет, кажется.


В том то и дело, что в эклипсе это не просто сниппет, а сниппет, генерящийся из контекста. Например нет необходимости задавать имя класса — оно уже возьмется из контекста.
Вбиваешь в эклипсе такой код
SomeObject obj = new SomeObject("test");
obj.foo();


SomeObject не существует, поэтому подчеркивается красным при компиляции в фоне (это происходит сразу после набора). Потом становишься курсором на него, вызываешь меню QuickFix (Ctrl+1) и выбираешь "create class SomeObject"- создается класс с таким именем. Потом переходишь курсором на конструктор и точно также создаешь конструктор, и далее метод foo(). Никакому виму такое и не снится Само собой, что снипеты о которых ты говоришь, использовать долго невозможно, банально вбить быстрее получится. Тут же совершенно другой случай.

LP>>И пустой метод заглушку при создании метода Или ты думал что эклипс сам еще код пишет


L>http://lomeo.livejournal.com/24990.html

L>Практически всё можно автоматизировать — варианты единственны. Это часто в Haskell.

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

LP>>Эти рутинные задачи были, есть и будут всегда. Программирование — на 50 процентов рутинная работа. Состоит из создания новых модулей, файлов, вбивания кода. Еще процентов 20 — анализ написанного тобой или кем-то другим. И среда разработки призвана как раз облегчить эту техническую работу, занимающую в виме 70 процентов времени, а в эклипсе — процентов 35.


L>На 90% программирование — написание постов в рсдн.


Ну это уже не программирование, я имел ввиду чистое время. А если считать все... у меня непосредственно на работу уходит в среднем от силы часа два в день Из которых вбивание кода занимает минут тридцать-сорок.
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[10]: Жизнь без IDE
От: LaPerouse  
Дата: 27.10.09 08:30
Оценка:
Здравствуйте, thesz, Вы писали:

T>Ну!

T>Я про то и говорю. Про Эклипс вкупе с языком.

Значит ты им неправильно пользовался.

LP>>И пустой метод заглушку при создании метода Или ты думал что эклипс сам еще код пишет

T>Вообще-то, я собирался автоматически код писать.
T>Есть у меня пара описаний, я хочу из них создать пару десятков классов.
T>И всё!
T>В Эклипсе мы приехали. Слезаем.

И при чем здесь эклипс? Он тебе чем-то мешает?

LP>>Эти рутинные задачи были, есть и будут всегда. Программирование — на 50 процентов рутинная работа. Состоит из создания новых модулей, файлов, вбивания кода.


T>Как я понимаю, ты пишешь не задумываясь о том, что же ты пишешь.


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

T>На одну строку кода приходится, наверное, 0.5% файлов и 1-2% классов.


А сигнатуры методов? Их эклипс также помогает эффективно создавать с параметрами, взятыми из контекста.

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


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

LP>>Еще процентов 20 — анализ написанного тобой или кем-то другим. И среда разработки призвана как раз облегчить эту техническую работу, занимающую в виме 70 процентов времени, а в эклипсе — процентов 35.


T>Насчёт чтения — согласен.

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

Не нужно, если модуль-класс нормально спроектированы. И тем более не нужно, если есть документация — ее эклипс покажет по F2 или при наведении курсора мыши.
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[11]: Жизнь без IDE
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 27.10.09 09:18
Оценка:
Здравствуйте, LaPerouse, Вы писали:

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


Я работал с IDEA и Eclipse. Да и в vim у меня eclim, там есть команда :JavaCorrect.
Да и потом — это же vim, там можно очень многое. Уж создать то класс по имени можно точно

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

И вот тут IDE мне очень сильно мешает. А что? Ведь написать тонну кода там очень просто.

На самом деле для меня ценность IDE не в редакторе, который понимает контекст. Гораздо важнее навигация по коду. Но вот в vim-е с навигацией тоже всё в порядке, так что зачем мне IDE?

LP>Как ты это автоматизируешь? Для этого нужен умный анализатор, который видит код на уровне синтаксического дерева.


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

Djinn> data Reader r a = Reader (r -> a)
Djinn> returnR ? a -> Reader r a
returnR :: a -> Reader r a
returnR a = Reader (\ _ -> a)
Djinn> bindR ? Reader r a -> (a -> Reader r b) -> Reader r b
bindR :: Reader r a -> (a -> Reader r b) -> Reader r b
bindR a b =
        case a of
        Reader c -> Reader (\ d ->
                            case b (c d) of
                            Reader e -> e d)
Re[11]: Жизнь без IDE
От: thesz Россия http://thesz.livejournal.com
Дата: 27.10.09 09:40
Оценка:
Здравствуйте, LaPerouse, Вы писали:

T>>Ну!

T>>Я про то и говорю. Про Эклипс вкупе с языком.
LP>Значит ты им неправильно пользовался.

Если бы я не был умным, я бы тебе поверил.

LP>>>И пустой метод заглушку при создании метода Или ты думал что эклипс сам еще код пишет

T>>Вообще-то, я собирался автоматически код писать.
T>>Есть у меня пара описаний, я хочу из них создать пару десятков классов.
T>>И всё!
T>>В Эклипсе мы приехали. Слезаем.
LP>И при чем здесь эклипс? Он тебе чем-то мешает?

Да.

Мне надо уметь во время компиляции Java кода создавать некоторые классы и подтыкать их в проекты Эклипса.

Скажешь, как это делать проще, чем в GNU make, буду признателен — признаю свою неправоту.

LP>>>Эти рутинные задачи были, есть и будут всегда. Программирование — на 50 процентов рутинная работа. Состоит из создания новых модулей, файлов, вбивания кода.


T>>Как я понимаю, ты пишешь не задумываясь о том, что же ты пишешь.

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

Если ты не понял, то это относилось к тому, что ты написал в комментарии, на который отвечал я.

Хотя я не знаю, может, есть RSDN plugin для Eclipse?

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


Вот взял ты язык по мощнее.

Ту же Agda2.

Как тебе поможет Eclipse?

T>>На одну строку кода приходится, наверное, 0.5% файлов и 1-2% классов.

LP>А сигнатуры методов? Их эклипс также помогает эффективно создавать с параметрами, взятыми из контекста.

Мне проще наперёд продумать, чем запоминать ещё одну редко используемую (если наперёд всё продумал) последовательность нажатий кнопок.

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

LP>Модули, файлы, пакеты и сигнатуры функций — весьма значимые единицы набора кода.

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

T>>Насчёт чтения — согласен.

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

Видишь — два "если".

Значит — нужно.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[12]: Жизнь без IDE
От: Mr.Cat  
Дата: 27.10.09 11:44
Оценка:
Здравствуйте, lomeo, Вы писали:
L>Да и потом — это же vim, там можно очень многое.
Кстати, вопрос ко всем виммерам и любителям емакса. Чем (набор плагинов/режимов/...) вы пользуетесь для работы с кодом на хаскеле?
Я бы, например, не отказался от плагина, показывающего выведенные типы переменных внутри функции. Еще было бы неплохо уметь видеть какую-нибудь доку (хотя бы тип) по произвольной функции.
Re[14]: Жизнь без IDE
От: Mr.Cat  
Дата: 27.10.09 13:07
Оценка:
Здравствуйте, lomeo, Вы писали:
L>Сначала у меня даже средства для рефакторинга стояли (см. HaRe)
L>GHC внутре (shim)
Ага, спасибо.

L>и ещё по мелочи, но потом я от них отказался.

Можно хотя бы названия?

L>Оказалось вполне достаточно иметь haskell-mode.

Речь сейчас про emacs? Или имеется в виду родная поддержка вима?

L>Что такое переменная внутри функции в Haskell я не очень понимаю — то, что в let вяжется? Или where тоже пойдёт? Или аргумент лямбды?

Угу. Я иногда читаю чужой код и там бывает что-то такое:
какаяТоФункция :: чтоТо -> НеведомаяМонада ЧтоТоЕще
какаяТоФункция = do
  переменная <- известнаяФункция . неведомаяФункция $ чтоТоТретье
  ...

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

L>автодополнением

Для этого нужно что-то ставить?

L>навигацией (обычно по тегам)

Ctags или как их там? Или что-то особое для хаскеля есть?
Re[12]: Жизнь без IDE
От: LaPerouse  
Дата: 27.10.09 15:05
Оценка:
Здравствуйте, thesz, Вы писали:

LP>>И при чем здесь эклипс? Он тебе чем-то мешает?

T>Да.
T>Мне надо уметь во время компиляции Java кода создавать некоторые классы и подтыкать их в проекты Эклипса.
T>Скажешь, как это делать проще, чем в GNU make, буду признателен — признаю свою неправоту.

Так возрадуйся — ANT и MAVEN тебя спасут. Я даже тебе могу сказать по шагам что надо сделать — оформить через External Tools свой скрипт, включить в опциях тула refresh и rebuild и все.

T>Ту же Agda2.

T>Как тебе поможет Eclipse?

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

T>Вот типы функций и аргументов — это да. Остальное можно смело выкидывать.


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

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

LP>>Не нужно, если модуль-класс нормально спроектированы. И тем более не нужно, если есть документация — ее эклипс покажет по F2 или при наведении курсора мыши.
T>Видишь — два "если".
T>Значит — нужно.

Ну-ну. На практике о том, что делает метод зачастую можно догадаться уже из названия.
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[13]: Жизнь без IDE
От: LaPerouse  
Дата: 27.10.09 15:08
Оценка:
Здравствуйте, LaPerouse, Вы писали:

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


LP>>>И при чем здесь эклипс? Он тебе чем-то мешает?

T>>Да.
T>>Мне надо уметь во время компиляции Java кода создавать некоторые классы и подтыкать их в проекты Эклипса.
T>>Скажешь, как это делать проще, чем в GNU make, буду признателен — признаю свою неправоту.

LP>Так возрадуйся — ANT и MAVEN тебя спасут. Я даже тебе могу сказать по шагам что надо сделать — оформить через External Tools свой скрипт, включить в опциях тула refresh и rebuild и все.


Само собой, можно использовать и GNU make. Через тот же externral tools
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[13]: Жизнь без IDE
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 27.10.09 15:44
Оценка:
Здравствуйте, LaPerouse, Вы писали:

T>>Скажешь, как это делать проще, чем в GNU make, буду признателен — признаю свою неправоту.

LP>Так возрадуйся — ANT и MAVEN тебя спасут.

А при чём тут тогда Eclipse?

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


http://www.rsdn.ru/forum/decl/3451868.flat.aspx#3451868
Автор: dotneter
Дата: 01.07.09


Читал уже?
Re[14]: Жизнь без IDE
От: LaPerouse  
Дата: 27.10.09 15:55
Оценка:
Здравствуйте, lomeo, Вы писали:

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


T>>>Скажешь, как это делать проще, чем в GNU make, буду признателен — признаю свою неправоту.

LP>>Так возрадуйся — ANT и MAVEN тебя спасут.

L>А при чём тут тогда Eclipse?


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

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


L>http://www.rsdn.ru/forum/decl/3451868.flat.aspx#3451868
Автор: dotneter
Дата: 01.07.09


L>Читал уже?


Нет, спасибо, почитаю.
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[13]: Жизнь без IDE
От: thesz Россия http://thesz.livejournal.com
Дата: 27.10.09 16:29
Оценка:
Здравствуйте, LaPerouse, Вы писали:

LP>>>И при чем здесь эклипс? Он тебе чем-то мешает?

T>>Да.
T>>Мне надо уметь во время компиляции Java кода создавать некоторые классы и подтыкать их в проекты Эклипса.
T>>Скажешь, как это делать проще, чем в GNU make, буду признателен — признаю свою неправоту.
LP>Так возрадуйся — ANT и MAVEN тебя спасут. Я даже тебе могу сказать по шагам что надо сделать — оформить через External Tools свой скрипт, включить в опциях тула refresh и rebuild и все.

И это проще, чем добавление "каталог:\n\tchdir каталог\nmake all"?

В случае make у меня всё единообразно — есть список целей, есть способы их достижения. В случае Eclipse?..

T>>Ту же Agda2.

T>>Как тебе поможет Eclipse?
LP>Нафиг мне сдался язык, про который слышали полтора человека, включая тебя?

Когда-то так было со всеми языками, это раз.

Он тебе может понадобиться, это два.

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


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

T>>Вот типы функций и аргументов — это да. Остальное можно смело выкидывать.

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

Перевожу: ты делаешь много непродуктивной деятельности.

LP>Во-вторых, описание сигнатур методов занимают процентов 10 от объема исходников.


У меня под рукой оказались исходники из статьи первого выпуска http://fprog.ru

Они содержат процедуру сбалансированной вставки элемента в дерево.

Судя по ним, твои оценки справедливы только для Functional Java. Но, поскольку ты не пользуешься FJ (я в этом уверен, помня нашу дискуссию про оптимизации схем), я считаю, что ты преувеличиваешь в целях достижения победы в дискуссии.

LP>Учытывая, что эклипс может генерить их из самых различных ситуций (по quick fix, с помощью средств рефакторинга и т.д.), это очень полезная фича.


Ты уж извини меня, но "сигнатуры функций" не являются полезными строками кода.

Да, они занимают заметный объём кода, но они бесполезны. Их тебе проверит компилятор.

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

LP>>>Не нужно, если модуль-класс нормально спроектированы. И тем более не нужно, если есть документация — ее эклипс покажет по F2 или при наведении курсора мыши.
T>>Видишь — два "если".
T>>Значит — нужно.
LP>Ну-ну. На практике о том, что делает метод зачастую можно догадаться уже из названия.

"Зачастую" тоже означает, что нужно.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[17]: Жизнь без IDE
От: VoidEx  
Дата: 27.10.09 18:48
Оценка:
Здравствуйте, z00n, Вы писали:

Z>Я под win регулярно использую Notepad++ для просмотра кода по правой кнопке — но редактировать в нем код? Вместо emacs?! У N++ даже поиск работает через зад; и aspell прикручивается через зад и шрифты скачут по ширине.

Z>Если уж не emacs-vim — можно использовать Jedit(http://www.jedit.org) — он еще туда-сюда.

Я лично пишу в HippoEDIT, сравнить не могу, давно другое не использовал. Забиндил alt + B (cabal install в папке проекта), + H (HLint текущему файлу), + R (run в WinGHCi текущего файла), + C (HsColour текущему и в буфер обмена). Подсветка есть, больше мне ничего и не нужно
Re[14]: Жизнь без IDE
От: LaPerouse  
Дата: 27.10.09 19:05
Оценка:
Здравствуйте, thesz, Вы писали:

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


LP>>>>И при чем здесь эклипс? Он тебе чем-то мешает?

T>>>Да.
T>>>Мне надо уметь во время компиляции Java кода создавать некоторые классы и подтыкать их в проекты Эклипса.
T>>>Скажешь, как это делать проще, чем в GNU make, буду признателен — признаю свою неправоту.
LP>>Так возрадуйся — ANT и MAVEN тебя спасут. Я даже тебе могу сказать по шагам что надо сделать — оформить через External Tools свой скрипт, включить в опциях тула refresh и rebuild и все.

T>И это проще, чем добавление "каталог:\n\tchdir каталог\nmake all"?


T>В случае make у меня всё единообразно — есть список целей, есть способы их достижения. В случае Eclipse?..


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

T>>>Ту же Agda2.

T>>>Как тебе поможет Eclipse?
LP>>Нафиг мне сдался язык, про который слышали полтора человека, включая тебя?
T>Когда-то так было со всеми языками, это раз.
T>Он тебе может понадобиться, это два.

У меня конечно хватило бы отмороженности задействовать его в проекте, если бы:
1. Я знал точно, что оно поможет
2. У нее была бы хорошая интеграция с java. Не просто интероп, но компилировалось бы в ява-байткод.
3. Хоть какая-то поддержка и комунити

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


T>Тут рядом было, в верхних топиках.


Да, да уже смотрю.
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[17]: Жизнь без IDE
От: LaPerouse  
Дата: 27.10.09 19:49
Оценка:
Здравствуйте, z00n, Вы писали:

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


LP>>Для языков без поддержки IDE я рекомендую использовать прекрасный редактор с открытыми кодами Notepad++. Им реально можно пользоваться (в отличие от emacs/vim/etc).


Z>Я под win регулярно использую Notepad++ для просмотра кода по правой кнопке — но редактировать в нем код? Вместо emacs?! У N++ даже поиск работает через зад; и aspell прикручивается через зад и шрифты скачут по ширине.

Z>Если уж не emacs-vim — можно использовать Jedit(http://www.jedit.org) — он еще туда-сюда.

Да, поиск работает через зад. В смысле сначала спереди назад, потом с зада наперед И что?
А с aspell просто интеграция хреновая. Не может подсвечивать ошибки, это плохо, да.
Шрифты по ширине — комментарии имеешь ввиду? Сделано для того, чтобы вместить больше букв в строчку. Имхо, так удобнее.

Положительные стороны:
1. Есть все привычные функции редактирования, и самое главное, они изначально сидят на привычных клавишах. Это и смещение выделенных кусков по Tab и Shift+Tab, и блочное выделение и многое другое
2. Легко добавляется новая подсветка, буквально за пять минут можно сделать новую
3. Есть встроенная консоль. Компилятор добавляется очень просто.
4. Есть вкладки и очень удобное переключение между ними
5. Есть очень удобная фича — выделение текущего слова под курсором определенным цветом по всему документу.
6. Есть поддержка UTF8
7. Очень шустрав работе

Из минусов — нет нормального скриптового интерфейса (как лисп в емаксе).

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

В Emacs нужно иметь шесть пальцев на руке для нормальной работы. В Ecb по умолчанию для переключения между панелями нужно жать одновременно на 6 кнопок(!!!). Вим, чтобы избежать подобной судьбы, ввел два режима, но от этого стало только хуже. Получается, если я хочу выделить последнее набранное слово я должен переключать режим — это же ужас.
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[15]: Жизнь без IDE
От: thesz Россия http://thesz.livejournal.com
Дата: 27.10.09 22:18
Оценка:
Здравствуйте, LaPerouse, Вы писали:

T>>И это проще, чем добавление "каталог:\n\tchdir каталог\nmake all"?

T>>В случае make у меня всё единообразно — есть список целей, есть способы их достижения. В случае Eclipse?..
LP>Вот не понимаю я, при чем тут эклипс. nmake — утилита сборки, эклипс — среда разработки. Совершенно разные вещи. Я думал, что тебе тяжело сынтегрировать эклипс с nmake. А теперь я и не знаю, что думать

Сборка — это часть разработки.

Кстати, влияющая на многие стороны разрабатываемого проекта.

И не nmake, а GNU make.

T>>>>Ту же Agda2.

T>>>>Как тебе поможет Eclipse?
LP>>>Нафиг мне сдался язык, про который слышали полтора человека, включая тебя?
T>>Когда-то так было со всеми языками, это раз.
T>>Он тебе может понадобиться, это два.
LP>У меня конечно хватило бы отмороженности задействовать его в проекте, если бы:
LP>1. Я знал точно, что оно поможет
LP>2. У нее была бы хорошая интеграция с java. Не просто интероп, но компилировалось бы в ява-байткод.
LP>3. Хоть какая-то поддержка и комунити

Вот скажи, ты .bat файлами пользуешься?

Если пользуешься, они компилируются в Java байт-код?

Так и здесь — на Agda2 ты можешь делать ответственные вещи. Из которых получаются Java классы. Которые ты используешь в других местах твоего проекта.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[19]: Жизнь без IDE
От: LaPerouse  
Дата: 27.10.09 22:40
Оценка:
Здравствуйте, thesz, Вы писали:

LP>>Вим, чтобы избежать подобной судьбы, ввел два режима


T>Широта твоей неосведомлённости просто поражает.


А какова твоя версия появления двух режимов?
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[16]: Жизнь без IDE
От: LaPerouse  
Дата: 27.10.09 22:43
Оценка:
Здравствуйте, thesz, Вы писали:

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


T>>>И это проще, чем добавление "каталог:\n\tchdir каталог\nmake all"?

T>>>В случае make у меня всё единообразно — есть список целей, есть способы их достижения. В случае Eclipse?..
LP>>Вот не понимаю я, при чем тут эклипс. nmake — утилита сборки, эклипс — среда разработки. Совершенно разные вещи. Я думал, что тебе тяжело сынтегрировать эклипс с nmake. А теперь я и не знаю, что думать

T>Сборка — это часть разработки.

T>Кстати, влияющая на многие стороны разрабатываемого проекта.

Сборка — это сборка. И к эклипсу это не имеет никакого отношения. Все. Точка. Признай наконец-то что сказал чушь.

T>Вот скажи, ты .bat файлами пользуешься?

T>Если пользуешься, они компилируются в Java байт-код?
T>Так и здесь — на Agda2 ты можешь делать ответственные вещи. Из которых получаются Java классы. Которые ты используешь в других местах твоего проекта.

Нет, спасибо. Генерят код для жабы те, кто не умеет на ней писать.
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[20]: Жизнь без IDE
От: thesz Россия http://thesz.livejournal.com
Дата: 28.10.09 07:18
Оценка:
Здравствуйте, LaPerouse, Вы писали:

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


LP>>>Вим, чтобы избежать подобной судьбы, ввел два режима

T>>Широта твоей неосведомлённости просто поражает.
LP>А какова твоя версия появления двух режимов?

Это не моя, это общепринятая. От автора, так сказать. vi — последователь командных редакторов Unix, см. его историю.

Joy explained that the terse, single character commands and the ability to type ahead of the display were a result of the slow 300 baud modem he used when developing the software and that he wanted to be productive when the screen was painting slower than he could think.[6]


И, кстати, vi старше Emacs.

Так что тут ты неправ вообще нигде.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[19]: Жизнь без IDE
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 28.10.09 09:03
Оценка:
Здравствуйте, LaPerouse, Вы писали:

LP>>>Нет, спасибо. Генерят код для жабы те, кто не умеет на ней писать.


Ты это серьёзно? Неужели ты не видишь, что в java полно boilerplate кода, от которого не избавишься из-за недостатков самого языка?

T>>Да-да. А компиляторами из Си в ассемблер пользуются те, кто не умеет писать на ассемблере.

LP>передергивать-то не надо. java не ассемблер а высокоуровневый язык, сравнимый с Agda, на котором ты собрался генерировать java-код.

Посмотри на Agda. Java по сравнению с этим языком не дотягивает даже до ассемблера по сравнению с С.
Re[20]: Жизнь без IDE
От: LaPerouse  
Дата: 28.10.09 11:47
Оценка:
Здравствуйте, lomeo, Вы писали:

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


LP>>>>Нет, спасибо. Генерят код для жабы те, кто не умеет на ней писать.


L>Ты это серьёзно? Неужели ты не видишь, что в java полно boilerplate кода, от которого не избавишься из-за недостатков самого языка?


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

T>>>Да-да. А компиляторами из Си в ассемблер пользуются те, кто не умеет писать на ассемблере.

LP>>передергивать-то не надо. java не ассемблер а высокоуровневый язык, сравнимый с Agda, на котором ты собрался генерировать java-код.
L>Посмотри на Agda. Java по сравнению с этим языком не дотягивает даже до ассемблера по сравнению с С.

Ну-ну. Расскажите вкратце, что оно из себя представляет. Я почитал вики и ничего не понял. Почему agda, а не epigram? И кстати, там написано, что Агда — "theorem prover". Я слабо разбираюсь во всем этом, но всегда думал, что автоматическое доказательство теорем — удел логических языков типа пролога. Ведь для формулировки теорем нужна возможность формулировать утверждения и задавать цели, которые среда будет стремиться автоматически достичь. А Agda — функциональный язык. Как так?
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[21]: Жизнь без IDE
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 28.10.09 12:58
Оценка:
Здравствуйте, LaPerouse, Вы писали:

LP>Видишь ли, java — объектно-ориентированный язык, а копипастный код — одно из зол, для борьбы с которой ООП и создавался. Так что зачастую такой код появляется не благодаря, а вопреки идеям, лежащим в основе языка.


Во-первых, ООП создавался не для борьбы с копипастным кодом. Во-вторых, у ООП есть ряд серьёзных недостатков, хорошо об этом написано у thesz здесь.

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


А у Явы этих недостатков ещё больше. Отсутствие функций высшего порядка приносит просто огромную кучу бойлерплейта. Декоратор для группы строк:

    public boolean startsWith(String s)
    {
        for (String str: strings) {
            if (str.startsWith(s)) {
                return true;
            }
        }

        return false;
    }

    public boolean endsWith(String s)
    {
        for (String str: strings) {
            if (str.endsWith(s)) {
                return true;
            }
        }

        return false;
    }


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

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


Я не пользуюсь Agda в разработке. Но многие приёмы из неё успешно использую в Haskell.
На "Не породив новые" отвечу так — не попробовав не узнаешь.

LP>Ну-ну. Расскажите вкратце, что оно из себя представляет. Я почитал вики и ничего не понял.


Так не бывает. Что именно ты не понял? Dependently Typed Programming in Agda читал?

LP>Почему agda, а не epigram?


Субъективно. Мне ближе его синтаксис.

LP>И кстати, там написано, что Агда — "theorem prover". Я слабо разбираюсь во всем этом, но всегда думал, что автоматическое доказательство теорем — удел логических языков типа пролога.


Есть такая изумительная штука, называется Curry-Howard изоморфизм. Это утверждение о том, что типы данных, есть аксиомы, типы функций — есть теоремы, а программмы (тело функций) — есть доказательство этих теорем. Изоморфизм там явный, его сразу видно. Так вот, в этом смысле между доказательством теоремы и написанием программы нет никакой разницы.

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

LP>Ведь для формулировки теорем нужна возможность формулировать утверждения и задавать цели, которые среда будет стремиться автоматически достичь. А Agda — функциональный язык. Как так?


Curry-Howard изоморфизм. Меня в своё время очень сильно зацепило. Почитай, там и примеры есть отображения.
Re[19]: Жизнь без IDE
От: thesz Россия http://thesz.livejournal.com
Дата: 28.10.09 13:23
Оценка:
Здравствуйте, LaPerouse, Вы писали:

T>>Вообще-то имеет.

T>>Ещё раз. Сложности сборки проектов с кодогенерацией под текущими средами разработки практически полностью блокируют её использование.
LP>Это бред. Еще раз. Eclipse не имеет никакого отношения к сборке проекта. И он не осложняет сборку проекта. Вообще никак.

Осложняет. Осложняет, уверяю тебя.

Нельзя взять Eclipse и сделать в нём какой угодно проект. Надо ещё всякого другого знать и использовать.

LP>>>Нет, спасибо. Генерят код для жабы те, кто не умеет на ней писать.

T>>Да-да. А компиляторами из Си в ассемблер пользуются те, кто не умеет писать на ассемблере.
LP>передергивать-то не надо. java не ассемблер а высокоуровневый язык, сравнимый с Agda, на котором ты собрался генерировать java-код.

Любой язык программирования является сравнимым с другим. Например, автокод сравним с Прологом, PL/1 — с Java, C# с Direct3D Shading Language. Нам же интересны результаты сравнения, а не просто факт сравнимости.

Поэтому.

Mixfix синтаксис в Java есть?

Параметрический полиморфизм в Java есть?

Функции высших порядков в Java есть?

Зависимые типы данных в Java есть?

Строгое формальное доказательство соответствия программ спецификации есть?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[22]: Жизнь без IDE
От: LaPerouse  
Дата: 28.10.09 13:56
Оценка:
Здравствуйте, lomeo, Вы писали:

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


LP>>Видишь ли, java — объектно-ориентированный язык, а копипастный код — одно из зол, для борьбы с которой ООП и создавался. Так что зачастую такой код появляется не благодаря, а вопреки идеям, лежащим в основе языка.


L>Во-первых, ООП создавался не для борьбы с копипастным кодом.


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

L>Во-вторых, у ООП есть ряд серьёзных недостатков, хорошо об этом написано у thesz здесь.


Здесь практически ничего не написано.

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

L>А у Явы этих недостатков ещё больше. Отсутствие функций высшего порядка приносит просто огромную кучу бойлерплейта. Декоратор для группы строк:

Пиши так:

    public boolean startsWith(final String s)
    {
    return atLeastOne(new Predicate<String>() {
            public boolean predicate(String str)
            {
                return str.startsWith(s);
            }
        });
    }

    public boolean endsWith(final String s)
    {
        return atLeastOne(new Predicate<String>() {
            public boolean predicate(String str)
            {
                    return str.startsWith(s);
            }
        });
    }
    
    private boolean atLeastOne(Predicate<String> predicate)
    {
        for (String str: strings) {
            if (predicate.predicate(str)) 
            {
                return true;
            }
        }

        return false;
    }


Predicate<T> определяется один раз и его хватает очень намного
public interface Predicate <T>
{
    boolean predicate(T object);
}


L>И ещё куча таких методов, отличающихся только выделенным. Понасоздавать на каждую функцию по классу?


Да нет, использовать то, что есть. И просить у Sun сделать ФВП в 7-ой яве

L>Так не бывает. Что именно ты не понял? Dependently Typed Programming in Agda читал?


Да я ничего не понял, честное слово. Не читал.

LP>>И кстати, там написано, что Агда — "theorem prover". Я слабо разбираюсь во всем этом, но всегда думал, что автоматическое доказательство теорем — удел логических языков типа пролога.


L>Есть такая изумительная штука, называется Curry-Howard изоморфизм. Это утверждение о том, что типы данных, есть аксиомы, типы функций — есть теоремы, а программмы (тело функций) — есть доказательство этих теорем. Изоморфизм там явный, его сразу видно. Так вот, в этом смысле между доказательством теоремы и написанием программы нет никакой разницы.


Ладно, спасибо за ссылки, просто с этим надо очень серъезно разбираться. С ходу понять не получается (по крайней мере у меня).
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[7]: Жизнь без IDE
От: artem_korneev США https://www.linkedin.com/in/artemkorneev/
Дата: 29.10.09 14:45
Оценка:
Здравствуйте, LaPerouse, Вы писали:

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


У тебя какое-то странное представление о работе в vim/emacs.
Что будем называть IDE? Если IDE это Integrated Development Environment, то в этом смысле, настроенные vim/emacs — тоже вполне себе IDE.
Автокомплит кода там есть. Правда, он не такой продвинутый, как, например, в Visual Studio, но в принципе — хватает. Особенно, если использовать CEDET (для emacs) — тогда это уже дополнение не просто по словам, а контекстно-зависимое, "умное дополнение". Хотя там ещё есть что усовершенствовать.
Некоторая интеграция с отладчиком и переход на строчки с ошибками компиляции — есть.
Переход к месту объявления функции/переменной, перечисление мест, где функция или переменная используется — всё это есть.
Некоторые ошибки — подсвечиваются во время редактирования(непарные скобки, например). Некоторые — нет. Кстати, в том же emacs есть некоторые любопытные функции, которых я пока не видел в "больших IDE" — например, принудительное форматирование блока кода. Иногда это помогает заметить логические ошибки в чужом коде. Хотя сейчас большинство IDE форматируют код при наборе, так что для новых проектов это становится неактуально.

Посему, не стоит думать что vim/emacs так уж кардинально отстают от других IDE по функциональности. В тоже время, "готовые" IDE зачастую сильно завязаны на конкретный компилятор, систему сборки и т.д. Например, в том проекте, над которым я сейчас работаю, этим летом сборку перевели на мейкфайлы. Соответственно, Visual Studio их не понимает и некорректно подсвечивает активные/неактивные участки кода.
С уважением, Artem Korneev.
Re[20]: Жизнь без IDE
От: Аноним  
Дата: 01.11.09 09:58
Оценка:
Здравствуйте, thesz, Вы писали:

T>Строгое формальное доказательство соответствия программ спецификации есть?


http://krakatoa.lri.fr/
Re[21]: Жизнь без IDE
От: deniok Россия  
Дата: 01.11.09 10:21
Оценка:
Здравствуйте, Аноним, Вы писали:

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


T>>Строгое формальное доказательство соответствия программ спецификации есть?


А>http://krakatoa.lri.fr/


А для описания спецификаций учить дополнительный язык, Java Modeling Language? Который разбирается Krakatoa, который передает результат в Why, который вызывает прувер, например, COQ, чтобы проверить все спецификации?

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

Тем более, что наличие в этом JML аннотаций типа pure, подсказывает мне, что стандартный императивный джавовский дизайн всё равно менять придется.
Re[22]: Жизнь без IDE
От: Аноним  
Дата: 01.11.09 11:01
Оценка:
Здравствуйте, deniok, Вы писали:

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


А если, извините, требуется код на Java? Вот требуется, и всё тут? Тогда уж лучше так, чем совсем без аннотаций.

D>Тем более, что наличие в этом JML аннотаций типа pure, подсказывает мне, что стандартный императивный джавовский дизайн всё равно менять придется.


И это прекрасно.
Re[23]: Жизнь без IDE
От: deniok Россия  
Дата: 01.11.09 11:13
Оценка:
Здравствуйте, Аноним, Вы писали:

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


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


А> А если, извините, требуется код на Java? Вот требуется, и всё тут? Тогда уж лучше так, чем совсем без аннотаций.


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

java не ассемблер а высокоуровневый язык, сравнимый с Agda, на котором ты собрался генерировать java-код

Re[24]: Жизнь без IDE
От: Аноним  
Дата: 01.11.09 11:29
Оценка:
Здравствуйте, deniok, Вы писали:

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

D>

D> java не ассемблер а высокоуровневый язык, сравнимый с Agda, на котором ты собрался генерировать java-код



Речь выше шла о тезисе, что средств формальной верификации для Java нет. Я же говорю, что таки есть.
Re[25]: Жизнь без IDE
От: deniok Россия  
Дата: 01.11.09 11:40
Оценка:
Здравствуйте, Аноним, Вы писали:

А> Речь выше шла о тезисе, что средств формальной верификации для Java нет. Я же говорю, что таки есть.


Это средства формальной верификации аннотаций на JML к коду на Java. Сама Java недостаточно выразительна для верификации.
Re[15]: Жизнь без IDE
От: Аноним  
Дата: 01.11.09 11:56
Оценка:
Здравствуйте, Mr.Cat, Вы писали:

MC>Угу. Я иногда читаю чужой код и там бывает что-то такое:

MC>
MC>какаяТоФункция :: чтоТо -> НеведомаяМонада ЧтоТоЕще
MC>  ...
MC>

MC>Соответственно, хочется по минимуму бегать по гуглам и другим частям чужого исходника.

Leksah по Ctrl+double_click показывает тип функции + документацию из исходника + положение в дереве исходников. Оттуда по "go to definition" можно и на собственно исходники посмотреть (если GHC и библиотеки были поставлены с исходниками). Ну и автокомплит и подсветка и даже встроенный дебагер (GHCi) имеется.
Re[21]: Жизнь без IDE
От: thesz Россия http://thesz.livejournal.com
Дата: 01.11.09 15:55
Оценка:
Здравствуйте, Аноним, Вы писали:

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


T>>Строгое формальное доказательство соответствия программ спецификации есть?


А>http://krakatoa.lri.fr/


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

Чтобы вы поняли, на что надо отвечать: есть ли в языке Java формальное доказательство соответствия программ спецификации?

Так, чтобы ничего скачивать не пришлось.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[22]: Жизнь без IDE
От: FR  
Дата: 06.11.09 13:07
Оценка:
Здравствуйте, thesz, Вы писали:

T>Чтобы вы поняли, на что надо отвечать: есть ли в языке Java формальное доказательство соответствия программ спецификации?


T>Так, чтобы ничего скачивать не пришлось.


Как я понял там только написанный на OCaml анализатор Java кода
Re[13]: Жизнь без IDE
От: xonixx  
Дата: 06.11.09 13:30
Оценка:
Здравствуйте, vshabanov, Вы писали:

V>У Хаскелла есть фундаментальное преимущество -- он чистый. Чистота опупительно повышает модульность.


А в лекции 5а SICP http://groups.csail.mit.edu/mac/classes/6.001/abelson-sussman-lectures/ почему-то утверждается строго противоположное!
sicp
Re[14]: Жизнь без IDE
От: vshabanov http://vshabanov-ru.blogspot.com
Дата: 06.11.09 14:52
Оценка:
Здравствуйте, xonixx, Вы писали:

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


V>>У Хаскелла есть фундаментальное преимущество -- он чистый. Чистота опупительно повышает модульность.


X>А в лекции 5а SICP http://groups.csail.mit.edu/mac/classes/6.001/abelson-sussman-lectures/ почему-то утверждается строго противоположное!


Там утверждается, что чем больше глобальных переменных, тем лучше? Да, если в какой-то вложенный модуль надо передать какой-нить флажок logEnable, то может и стоит сделать его глобальным. Но это лучше вообще сделать через переменную окружения или -DDEBUG=1. Во всех остальных случаях, если алгоритм мутабельный и имеет внешние зависимости, то нельзя их прятать и создавать головную боль при поддержке. А когда язык тебе не позволяет прятать косяки под плющом, то сразу как-то по другому начинаешь проектировать, срубая ненужные зависимости, от чего имеешь феерический выигрыш на поддержке и очень малую цену изменения кода. Т.е. чистота в хаскеле мешает писать мутабельный/неявно связанный говонокод.
Re[15]: Жизнь без IDE
От: xonixx  
Дата: 06.11.09 15:10
Оценка:
Здравствуйте, vshabanov, Вы писали:

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


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


V>>>У Хаскелла есть фундаментальное преимущество -- он чистый. Чистота опупительно повышает модульность.


X>>А в лекции 5а SICP http://groups.csail.mit.edu/mac/classes/6.001/abelson-sussman-lectures/ почему-то утверждается строго противоположное!


V>Там утверждается, что чем больше глобальных переменных, тем лучше?


Нет, если точнее там говорилось ровно следующее

http://mitpress.mit.edu/sicp/full-text/sicp/book/node53.html

(Ctrl-F -> "While the program is still simple, it betrays some painful breaches of modularity")
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.