Императивная парадигма
От: AlexCab LinkedIn
Дата: 19.07.11 10:52
Оценка:
Много рас здесь встречал высказывания типа "императивный код — фее..."
Но ведь мы используем этот подход повсеместно в жизни(когда планируем что то или делаем), чем по вашему мнению он плох применительно к программированию?
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re: Императивная парадигма
От: Undying Россия  
Дата: 19.07.11 11:18
Оценка: 1 (1) +3 -1 :))) :))
Здравствуйте, AlexCab, Вы писали:

AC>Много рас здесь встречал высказывания типа "императивный код — фее..."

AC>Но ведь мы используем этот подход повсеместно в жизни(когда планируем что то или делаем), чем по вашему мнению он плох применительно к программированию?

Ничем не плох, просто по маркетинговым причинам временно вышел из моды.
Re: Императивная парадигма
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 19.07.11 11:52
Оценка: 1 (1) +2 :)
Здравствуйте, AlexCab, Вы писали:

AC>Много рас здесь встречал высказывания типа "императивный код — фее..."

AC>Но ведь мы используем этот подход повсеместно в жизни(когда планируем что то или делаем), чем по вашему мнению он плох применительно к программированию?

1)Императивный код часто неявно оперирует состоянием, бывает сложно отследить что на самом деле происходит
2)Императивный код сильно зависит от порядка вычислений, что ограничивает возможности декомпозиции и композиции программ
3)Императивный код при повышения уровня абстракции быстро теряет гибкость, появляется необходимость переходить к более декларативным конструкциям
Re[2]: Императивная парадигма
От: Sinix  
Дата: 19.07.11 12:28
Оценка: 3 (1) +6 :))
Здравствуйте, gandjustas, Вы писали:

G>1)...


На самом деле ничего не мешает писать императивный код, не страдающий этими недостатками. Другое дело, что мало кто этим заморачивается. И, напротив, не так уж сложно получить на чистом ФП монстра с тонной побочных эффектов протаскиваемым состоянием.
Re[3]: Императивная парадигма
От: Jack128  
Дата: 19.07.11 12:49
Оценка: +2
Здравствуйте, Sinix, Вы писали:

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


G>>1)...


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


дело не в том, что можно, дело в том, что (по крайней мере в haskell'е) — это протаскиваемое состояние будет явно выражено в типах функций.
Re: Императивная парадигма
От: 0x7be СССР  
Дата: 19.07.11 12:56
Оценка:
Здравствуйте, AlexCab, Вы писали:

AC>Много рас здесь встречал высказывания типа "императивный код — фее..."

AC>Но ведь мы используем этот подход повсеместно в жизни(когда планируем что то или делаем), чем по вашему мнению он плох применительно к программированию?
Любая парадигма или идеология в программировании — это всего лишь инструмент, который надо грамотно применять или не применять.
Re: Императивная парадигма
От: MasterZiv СССР  
Дата: 19.07.11 13:03
Оценка:
On 19.07.2011 14:52, AlexCab wrote:

> Но ведь мы используем этот подход повсеместно в жизни(когда планируем что то или

> делаем), чем по вашему мнению он плох применительно к программированию?

На самом деле ничем он не плох, в конце концов на нём основана думаю большая
часть современного кода всего ПО. Но императивный код менее понятен
в силу объективных причин, а именно, каждый код содержит две составляющих:
-- что делать
-- как делать

В императивном коде вторая составляющая существенна, в декларативном она
либо вообще отсутствует, либо сведена к минимуму. Когда человек читает
код, ему естественно нужно держать в голове две эти составляющие, и
вторая -- это в общем-то мусор, лишняя информация. Она мешает читать код.
А особенно если какой-то старый код типа Fortran-а с арифметическими IF-ами,
то это всё превращается вообще в криптографию какую-то.
Posted via RSDN NNTP Server 2.1 beta
Re[2]: Императивная парадигма
От: Sharov Россия  
Дата: 19.07.11 13:43
Оценка:
Здравствуйте, gandjustas, Вы писали:


G>3)Императивный код при повышения уровня абстракции быстро теряет гибкость, появляется необходимость переходить к более декларативным конструкциям

Разъясните, пожалуйста, по поводу данного пункта, т.к. мне казалось, что абстракции в контексте ООП как раз таки придают гибкость.
Кодом людям нужно помогать!
Re[3]: Императивная парадигма
От: samius Япония http://sams-tricks.blogspot.com
Дата: 19.07.11 14:12
Оценка: +2 -1 :))
Здравствуйте, Sinix, Вы писали:

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


G>>1)...


S>На самом деле ничего не мешает писать императивный код, не страдающий этими недостатками.

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

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

Ради побочных эффектов и пишут программы. Программа, которая не "портит" консоль, рабочий стол, БД либо весь остальной мир — большая редкость.
Re[3]: Императивная парадигма
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 19.07.11 19:28
Оценка: +2 :)
Здравствуйте, Sinix, Вы писали:

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


G>>1)...


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


Угу, только он пишется сложнее, чем код этими недостатками обладающий.
Re[3]: Императивная парадигма
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 19.07.11 19:34
Оценка:
Здравствуйте, Sharov, Вы писали:

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



G>>3)Императивный код при повышения уровня абстракции быстро теряет гибкость, появляется необходимость переходить к более декларативным конструкциям

S>Разъясните, пожалуйста, по поводу данного пункта, т.к. мне казалось, что абстракции в контексте ООП как раз таки придают гибкость.

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

Например можно взглянуть на Linq vs циклы. Циклы — более императивный код, чем linq. Linq задает не порядок выполнения, а форму результата, поэтому linq можно применять и к событиям, и к базам данных и к несуществующим данными (linq to z3).
Re: Императивная парадигма
От: Tilir Россия http://tilir.livejournal.com
Дата: 19.07.11 22:29
Оценка:
Здравствуйте, AlexCab, Вы писали:

AC>Много рас здесь встречал высказывания типа "императивный код — фее..."

AC>Но ведь мы используем этот подход повсеместно в жизни(когда планируем что то или делаем), чем по вашему мнению он плох применительно к программированию?

С сугубо философской точки зрения, парадигма зависит от сложности системы и её способностей вас понимать.
Если вы пишете программу... ну скажем для станка с ЧПУ Мне как-то приходилось. Там же в общем-то довольно естественное и простое программирование. У вас есть деталь и вы должны её обработать. Поэтому программа выглядит там примерно так: "вот эту фигню на пять сантиметров вправо. так. теперь вот этой фигне на пятьсот оборотов в секунду больше. так. теперь поверни это на пять градусов вокруг оси Y..."
Теперь представьте что вы -- любящий папа. С утра уходите на работу и оставляете сыну записку "сходи за молоком, деньги в бидоне". Это декларативный алгоритм. Считается, что всё остальное ваш сын уже знает и умеет.
Увы, компьютер это ребёнок-даун. Аутист. Дифуры решать умеет, а вот за молоком ему нужно пояснять "возьми бидон с деньгами, дойди до двери, поверни ручку..." при этом "дверь", "ручка" и "бидон" это переиспользуемые библиотечные абстракции. Это ООП (и та же императивщина, конечно).
Почему Хаскелл (скажем) так прекрасен и почему он так грубо обламывается о реальный мир?
Потому что это язык программирования компов будущего. Которым достаточно будет сказать "деньги в бидоне".
До тех пор советую учить C.
Re[4]: Императивная парадигма
От: Sharov Россия  
Дата: 20.07.11 06:39
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Да, но эти самые абстракции больше описывают сам результат, а не последовательность шагов по его получению.


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

G>Например можно взглянуть на Linq vs циклы. Циклы — более императивный код, чем linq. Linq задает не порядок выполнения, а форму результата, поэтому linq можно применять и к событиям, и к базам данных и к несуществующим данными (linq to z3).


Linq, на мой взгляд, является примером очень удачной абстракции.

Это я к тому, что благодаря абстракциям гибкость в императивном коде и достигается.
Кодом людям нужно помогать!
Re[5]: Императивная парадигма
От: Jack128  
Дата: 20.07.11 06:44
Оценка:
Здравствуйте, Sharov, Вы писали:

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


с помощью абстракции достигается гибкость в ЛЮБОЙ парадигме программирования. Императив тут не причем.
Re[2]: Императивная парадигма
От: AlexCab LinkedIn
Дата: 20.07.11 06:49
Оценка: +1 -1
Здравствуйте, gandjustas, Вы писали:
G>1)Императивный код часто неявно оперирует состоянием, бывает сложно отследить что на самом деле происходит
Инкапсуляция и ограничения.
G>2)Императивный код сильно зависит от порядка вычислений, что ограничивает возможности декомпозиции и композиции программ
Структурирование.
G>3)Императивный код при повышения уровня абстракции быстро теряет гибкость, появляется необходимость переходить к более декларативным конструкциям
С повышением абстрации не престаёт быть императивным(то есть это всё таже последоватльнось действий).

Думаю это проблемы реализации(конкретного ЯП), а не самого подхода.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[6]: Императивная парадигма
От: Sharov Россия  
Дата: 20.07.11 06:52
Оценка:
Здравствуйте, Jack128, Вы писали:

J>с помощью абстракции достигается гибкость в ЛЮБОЙ парадигме программирования. Императив тут не причем.


Совершенно верно, но и злоупотреблять ими особо тоже не нужно.
Кстати по теме абстракции неплохо говорит Дейкстра в своей лекции на приемию Тьюринга.
Кодом людям нужно помогать!
Re[2]: Императивная парадигма
От: AlexCab LinkedIn
Дата: 20.07.11 06:52
Оценка: +1
Здравствуйте, MasterZiv, Вы писали:
MZ>-- что делать
MZ>-- как делать

Упаковываем "как делать" в например процедуры и у нас остаётся только "что делать".
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[2]: Императивная парадигма
От: AlexCab LinkedIn
Дата: 20.07.11 06:57
Оценка:
Здравствуйте, Tilir, Вы писали:
T>Теперь представьте что вы -- любящий папа. С утра уходите на работу и оставляете сыну записку "сходи за молоком, деньги в бидоне". Это декларативный алгоритм. Считается, что всё остальное ваш сын уже знает и умеет.
сходи за молоком(деньги в бидоне)
T>Потому что это язык программирования компов будущего. Которым достаточно будет сказать "деньги в бидоне".
ИМХО лет через 20-120 создадут ИИ и необходимость ЯП отпадёт принципе(даже для простых вещей вроде ЧПУ программ, зачем программировать в ручную если можно поручить машине), а до тех пор "декларативный язык программирования общего назначения" останется мечтой.

Даже когда вы пишете в функциональном стиле(хотя я считаю неправильно называть его декларативным, так как программы написанные в этом стиле всё таки описывает некоторую последовательность вычисление а не "что должно получится"(как HTML например)) наверняка думаете что то вроде "...эта функция возвращает значение, которое затем получает вот та функция..."(или как?).
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[3]: Императивная парадигма
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 20.07.11 09:29
Оценка:
Здравствуйте, AlexCab, Вы писали:

G>>3)Императивный код при повышения уровня абстракции быстро теряет гибкость, появляется необходимость переходить к более декларативным конструкциям

AC> С повышением абстрации не престаёт быть императивным(то есть это всё таже последоватльнось действий).

Именно перестает.
Список классов разных уровней абстракции: Socket, TcpClient, HttpWebRequest, WebClient. Первый в этой цепочке исключительно императивен: послать байты\прочитать байты, последний декларативен, загрузить url в виде строки. О том как оно загружается мы не знаем и слабо можем влиять на последовательность действий. Внутри класса webclient происходит обработка редиректов, кодировок, кеширования итп.

Если пытаться управлять императивной частью запроса, то нужно выставить миллион параметров. Например HttpWebRequest этим страдает.

AC>Думаю это проблемы реализации(конкретного ЯП), а не самого подхода.

Это как раз от ЯП мало зависит, больше зависит от того как писать. Даже на haskell можно все завернуть в IO монаду.
Re[3]: Императивная парадигма
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 20.07.11 09:30
Оценка: +1
Здравствуйте, AlexCab, Вы писали:

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

MZ>>-- что делать
MZ>>-- как делать

AC>Упаковываем "как делать" в например процедуры и у нас остаётся только "что делать".


Не всегда. Процедуры могут неявно менять состояние и будет только иллюзия декларативности.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.