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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

Ну могу свой пример привести, нужно было в достаточно большой чужой проект (3D игра на C++) внести некоторые изменения, и исправить пару багов, при этом с движком на котором она написана мы были незнакомы. Использовать IDE не было возможности, так как игра компилировалась под windows и некоторые не PC устройства, компилятор допотопный даже тогда клон GCC, нормальных IDE под него тогда просто не было (тот же плугин для эсклипса был только в зародыше). Использовали обычные текстовые редакторы и сгенерировали doxygen'ом "документацию" с полным включением всех исходников и включенной опцией навигации по исходникам (помню чуть ли не десять часов генерировалось ) Этого вполне хватило для нормальной работы. С отладкой да пришлось пока не привыкли помучатся с логами.
Производительность труда в самом начале работы да была очень низкой. К концу работы мало отличалась от производительности при работе с нормальным IDE.

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

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

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

речь идёт о том что
1) чем выше уровень языка, тем больше он даёт возможностей для написания хороших программ. С больше асма, С# больше C и т.д.
2) если посмотреть на то, где больше всего даёт выигрыш ide, то это как раз или плохой код, в котором ни фига не разобраться, или плохой язык приводящий к необходимости отладки, или работа в большом коллективе / с большим числом бибилиотек. ничего этого у нас в общем-то нет, так что без ide можно обойтись
3) более того, ни в чём из вышеприведённого я и не хотел бы участвовать

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

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

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

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

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

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

dmz>Примеры поддержки больших проектов без него есть.
Можно конкретные примеры ?
emacs, если что, за пример не катит. Для лиспа он вполне себе ИДЕ.

dmz>А что касается Хаскелла, то программировать на нем в бессознательном состоянии невозможно. Это, наверное, его плюс, но
dmz>это и причина, по которой он никогда не станет мейнстримом.
Как знать как знать. Напишут дсл с крутой монадой VisualBasic. И моск включать не придется. Я, канеш, утрирую, но в каждой шутке есть доля шутки.

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

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

Второй — сделан alias, который грепает по заголовкам дерева проекта и показывает декларацию.

Здравствуйте, 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>Так что если кто-то может поделиться, то не стесняйтесь. Это очень интересно!

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

Рутина!

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

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

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

А ты — стилем программирования, при котором IDE не нужна.

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

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

BZ>2) если посмотреть на то, где больше всего даёт выигрыш ide, то это как раз или плохой код, в котором ни фига не разобраться, или плохой язык приводящий к необходимости отладки, или работа в большом коллективе / с большим числом бибилиотек.
BZ>ничего этого у нас в общем-то нет, так что без ide можно обойтись
Я бы заметили что ничего этого у нас пока нет. При достаточно большой пользовательской базе и количестве библиотек эти вопросы так или иначе выплывут на поверхность. Кустарное написание Хаскел шедевров мастерами заменится промышленными кодогенараторами или программными или индийскими. Такие дела. Это конечно если Хаскелл получит большое распространение. Но рекламная акция поставь [: :] вокруг списка и получи автоматическое распараллеливание квиксорта, поддерживаемая книгами типа RWH может возыметь действие.

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

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

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

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

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

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

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

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

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

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

кстати, если вспомнить про c++, то он тоже прошёл путь от языка для учёных, изучающих новейшие аспекты ооп, к языку для всех, к языку для высококвалифицированных, но всё же промышленных программистов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я поставил себе HaRe к vim давным-давно, это система автоматического рефакторинга. Только, если честно, пользуюсь им не часто. lambda lifting — это простое добавление аргументов, а lift to top level — это сдвиг блока влево

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

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

ЗЫ
Представляю себе проекты типа скрестить Хаскелл и 1С... мммммм..

"Cyberax" <37054@users.rsdn.ru> writes:

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

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

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

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

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

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

Здравствуйте, DemAS, Вы писали:
DAS> А на нетбуке альтернативы emacs/vim я пообще не вижу.
Кстати, емакс местами тоже прожорлив стал. Сейчас вроде получше, а когда 23-й еще не зарелизен был — у него были-таки проблемы с производительностью.

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

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

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

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

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

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

Здравствуйте, 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 справа от названия функции).