Previous Entry Share Next Entry
2016-01

Когда нужны и не нужны IDE.

(это мой коммент к прошлому посту)

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

Трудный код - его мало, он нетипичный и, как правило, плохо поддается разбиению на модули. "Рожается" медленно и типично для этого нужны супер-гуру, 1-2 шт.
Сложный код - его много, но он плюс-минус однообразный, и не поддается уплотнению. "Рожается" быстро, но с кучей мелочей, типично параллелизуется на Х программистов, X>5.

Например, "написать движок построения планов к БД" - трудный код.

Написать экспортеры в Х форматов - сложный код.

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

А делятся программисты на два лагеря вот так: http://osteele.com/posts/2004/11/ides (за ссылку спасибо lionet)

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

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

Если я пишу сам - я могу херачить DSL'и транслирующиеся по нескольку метауровней в итоговый код, если пишет 3 человека - уже появляются какие-то conventions, если пишет 30+ - то фичи языков начинают активно запрещаться, иначе человек, ушедший в отпуск, тратит еще месяц на последующее "вьезжание в тему".

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

Рутины типично много везде. Поэтому LISP не побеждает, а остается нишевым языком. А тот же самый дотнет рантайм прототипировался на лиспе. И это нормально. Для каждой задачи свой инструмент.

This entry was originally posted at http://wizzard.dreamwidth.org/271706.html. It has comment count unavailable comments. Please comment there using OpenID.

  • 1
dr_hyder March 22nd, 2013
Гуру всё же тоже надо некоторых разумных конвенций придерживаться, иначе может получиться классический write-only код который кроме автора никто поддерживать не сможет(впрочем это и так получается). Но в целом согласен, например.

vinslivins March 22nd, 2013
:(

vinslivins March 22nd, 2013
ну в плане - пишут же большие проекты на руби как-то? а он весьма плотный
(я правда не знаю, как пишут)

wizzard0 March 22nd, 2013
Мне всегда казалось, что в больших проектах руби превращается в Джаву путем ограничения фич в местах, где стыкуется код многих людей. Но я в этом смысле не настоящий сварщик, надо рубистов поспрашивать.

vinslivins March 22nd, 2013
да всё так и есть. наверное (
(не видел больших проектов на руби)

wizzard0 March 22nd, 2013
А, кроме того, я не видел никогда примеров уплотнения кода на Руби до той степени, до которой можно уплотнить любой язык с макросами путем бесконтрольного их применения :)

wizzard0 March 22nd, 2013
Отличная статья! Вынесу в тело поста.

nponeccop March 22nd, 2013
У меня прямо противоположное мнение: рутину писать на чем угодно в ноутпаде/емаксе, а ключевой код - на развитых языках с инструментальной поддержкой.

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

wizzard0 March 22nd, 2013
А что такое "ключевой код"?

> потому, что не приспособлен для простых задач и дешевых исполнителей. В своей области применения (трудные задачи и дорогие исполнители) он вполне успешен.
Здрасте, а я что говорю?

Короче, не понял, в каком месте мнение противоположное.

dz March 22nd, 2013
Да.

ady_1981 March 22nd, 2013
А я не могу понять, почему REPL не побеждает. Причем именно REPL стыкованный с IDE.

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

justy_tylor March 22nd, 2013
Если задача уже решается "неестественным интеллектом", то люди в ней не требуются. Если нет, то просто нет.

Задача IDE не "умность", а наглядность. Лёгкая визуализация подходящих identities для модели, а также процессов, происходящих при её прогоне. Больше в психологию и UX. А программисты любят и хотят в алгоритмы. Получается как всегда.

zyxman March 23rd, 2013
С точки зрения менеджера можно сказать так: в маленьком проекте обычно есть возможность набрать лучших людей, а на большом проекте нужно работать с любыми, а для хомо сапиенс программирование не есть эволюционно-выгодным на достаточно долгом для естественного отбора периоде, поэтому средний человек плох как программист.
С другой стороны, всегда давят ограничения бюджета и времени, поэтому и сложность софта внутри одного проекта, тоже разделяется, причем бОльшая часть будет попроще, а мЕньшая часть будет посложнее - так, по моему личному опыту рутина порядка 90% и более.
Иногда удается рутину экспортировать на сторону - аутсорсить или (в идеале) роботизировать, но ввиду ограничений времени это скорее исключения чем правило.

zyxman March 23rd, 2013
"жесткие ключевые части" в наше время частенько пишут рутинным инструментарием, а при приближении к дедлайну, переписывают на чем угодно, абы вписаться в мегабайтово-мегагерцовые ограничения.

(Anonymous) March 29th, 2013
> Хорошие инструменты рефакторинга, тестирования, профилирования (!) и "умные" редакторы так же повышают производительность программиста

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

Вот что проблемно – инструменты рефакторинга в основном привязаны к конкретной IDE, без такой привязки было бы намного веселее.

> если пишет 30+ - то фичи языков начинают активно запрещаться, иначе человек, ушедший в отпуск, тратит еще месяц на последующее "вьезжание в тему".

Фичи обычо запрещаются лишь в over-engineered языках вроде С++ :)
А так то при использовании DSL в большой команде можно просто хорошо его задокументировать. В том же Rails например дофига всяких DSL, но ниче, люди юзают спокойно.

> Рутины типично много везде. Поэтому LISP не побеждает, а остается нишевым языком.

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

  • 1
?

Log in

No account? Create an account