21

Кхм,

чёрт, а я всегда думал что

for(Player p = getKnownPlayers())(){}

будет run-time error в том случае если метод вернёт массив Player[]

22

Мышкин пишет:

чёрт, а я всегда думал что

А я всегда думал, что между

for(Player p = getKnownPlayers())

и

for(Player i : getKnownPlayers())

есть некоторая разница default/big_smile
Или князь до сих пор в Java 1.4.x программирует? default/big_smile

23

Кхм, я и смотрю какой-то странный синтакс, а это Балансер оказывается новую версию жабы рекламирует.

24

Мышкин пишет:

Кхм, я и смотрю какой-то странный синтакс, а это Балансер оказывается новую версию жабы рекламирует.

Угу. Мине за ето sun по утрам халявным кофием поит default/smile

25

У меня есть знакомый Габен, мы с ним часто полемизируем насчёт БЛ и ЧЛ, что "лучше", что первично и т.п.
В результате пришёл такому выводу:
у БЛогика ЧЛ и витале, автоматически функционирует, у ЧЛогика то же с БЛ. Это можно сравнить с процедурой в проге, которая раз за разом выполняет заложенные в ней действия.
Деловики используют наработки структурников, а структурники - деловиков.

26

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

В настоящее время используют такие подходы (в скобках -- наиболее характерные языки, реализующие данный подход):
1. Процедурный. (C, Pascal, bash, и т.д.)
2. Фукциональный. (Lisp, Scheme.)
3. Объектно-ориентированный. (Smalltalk, C++, Java.)
4. Ситуационный, он же event-based. (Честно говоря, х.з. Может, Tk?)
5. Продукционный, он же rule-based (встроенные языки пакетов Maple, Mathematica).
6. Логический (Слышал только о Прологе, но и его хватает. default/smile )

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

Подходы 1 и 3 -- императивные, 2, 5, 6 -- декларативные. 4 -- комбинированный.

Подробно о каждом подходе и их различиях:

1. Имеются отдельно данные и отдельно методы. (Это тоже довольно условно, так как, в принципе, можно залезть в сегмент кода. default/smile )
Данные живут отдельной жизнью и они, как правило, несут в себе сложность задачи, то есть, когда задача усложняется, усложняются и структуры данных. Для этих языков характерно следующее:
- линейность -- команды выполняются одна за другой, преобразуя данные,
- процедурность -- существует возможность разбиения сложного алгоритма на более простые, то есть программист может расширять словарь команд.

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

Отличие от процедурного подхода трудно почувствовать, не зная функциональных языков, но оно, очевидно есть.

Например, в языке Scheme существует возможность реализовать функции, выделяющие голову и хвост списка (car и cdr) не через создание структуры данных, а через создание кода, который и отождествляется с этой структурой. То есть, пользователь этого кода (не знающий о реализации) полагает, что он передает как аргумент этих функций список, но на самом деле передается код (например, какая-то лямбда-функция). То есть тут получается что-то вроде "суперинкапсуляции", когда код и данные не просто объединены, но являются разными сторонами одной сущности.

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

На самом деле, как я уже писал, суть функционального программирования очень трудно передать (так что рекомендую почитать, например, книжку Абельсона "Структура и интерпретация программ" -- замечательная весчь! default/smile ), но уж поверьте на слово, это очень изящный подход.

Например, вот решение задачи о том, сколькоми способами можно поменять на монеты заданную сумму, если есть монеты достоинством 1, 5, 10, 25 и 50 копеек.

(define (cc amount values)
        (cond
             ((= amount 0) 1)
             ((or (< amount 0) (null? values)) 0)
             (else
                  (+ (cc amount (cdr values))
                     (cc (- amount
                            (car values))
                         values)))))

После исполнения приведенного кода в ответ на запрос

(cc 100 '(50 25 10 5 1))

(поменять рубль на монеты указанных номиналов), программа выведет 292. (А 5 копеек можно поменять только двумя способами -- на пятачок и на 5 копеечных монет. default/smile )

3. Это очень модно, так что об этом и без меня все всё знают.

Характерные особенности:
- инкапсуляция,
- наследование,
- полиморфизм.

Имхо, единственной на практике полезной вещью является полиморфизм. Остальное часто только приводит к куче лишней писанины, а это болезненный удар по моей лени (но сказанное не верно, если базовые классы написаны кем-то другим default/smile ). А разговоры об "абстракции" и "удобстве многократного использования кода" как особенностях ООП -- это пижонство. default/smile Так как это пришло в ООП из процедурного программирования как модификация технологии "сверху-вниз".

Основная идея ООП -- "все объекты, которые сами все о себе знают".

4. Вместо описания последовательности действий, описываются события и алгоритмы их обработки. Алгоритмы могут сами вызывать события.

5. Продукционный подход -- это основа современной компьютерной алгебры.

Пример продукционной программы на некотором условном языке:

f(0)=1
f(n)=n*f(n-1)

То есть заданы правила, описывающие свойства некоторой функции (в данном случае это факториал).
Теперь задав программе цель f(5), мы получим результат -- 120. Программисту описывать алгоритм нет нужды.

Характерные особенности:
- описывается не алгоритм, а свойства системы,
- описание представляет собой правила преобразования для поиска решения, не обязательно однозначно задающие алгоритм продвижения к цели: поиск такого алгоритма -- проблема транслятора. default/smile

6. Наиболее абстрактный подход.

Пример программы:

предок (Иван, Петр).
предок (Петр, Василий).

предок (A, С) :- предок(A,B) and предок(B,C).

?-предок(Иван, Василий).

Здесь можно выделить следующие элементы: набор фактов, свойство отношения "быть предком" и цель -- "является ли Иван предком Василия?"

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

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

Пролог довольно удобен для написания программ работы с базами данных. Ну и, естественно, его часто используют для написания программ, имитиующих AI.

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

27

Balancer пишет:
'!' пишет:

причём оперирует не машинными типами данных, а абстрактными.

Нет, типизация в них бывает зачастую очень жёсткая. При чём, в случае того же O'Caml она даже статическая, не динамическая. Но, как и во многих современных императивных ЯВУ, типизация может быть скрыта от пользователя.

Ну на самом деле, конечно, типы в идею ФЯП пришли только при создании трансляторов. В том же Lisp вначале даже чисел не было. default/smile

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

28

'!' пишет:

Спасибо! Кажется, понятно. Суть ФП - не в преобразовании данных, хранящихся в переменных и структурах, как в ИП, а в порождении новых данных на основе входных, путем последовательного применения функций (вопрос о хранении данных скрыт в реализации транслятора).

Ну, вроде того... default/smile

'!' пишет:

Возвращаясь к сабжу - да, ФП, похоже, чернологично по сути ...

Да большой разницы нет в ч/б-логичности между ФП и ИП нет, наверное. И тут и там сначала проектируются общие крупные куски (БЛ), а потом это все реализуется через функции самого языка (ЧЛ).

29

masai пишет:

Да большой разницы нет в ч/б-логичности между ФП и ИП нет, наверное. И тут и там сначала проектируются общие крупные куски (БЛ), а потом это все реализуется через функции самого языка (ЧЛ).

А вот у меня на форуме творческий ЧЛ уже который раз говорит, что не доверяет ФП, т.к. там скрыта внутренняя связь элементов default/big_smile

Так что, я снова повторюсь, что ФП представляет собой БЛ (берёт на себя организацию логических связей). А ИП - это больше ЧЛ языки, они ориентированы на жёсткую последовательность действий.

30

'!' пишет:

Кодирование - преим. ЧЛ, проектирование и специфицирование - БЛ.

...постановка задач - снова ЧЛ; определение смысла жизни - БЛ default/big_smile

31

Balancer пишет:
masai пишет:

Да большой разницы нет в ч/б-логичности между ФП и ИП нет, наверное. И тут и там сначала проектируются общие крупные куски (БЛ), а потом это все реализуется через функции самого языка (ЧЛ).

А вот у меня на форуме творческий ЧЛ уже который раз говорит, что не доверяет ФП, т.к. там скрыта внутренняя связь элементов default/big_smile

Так что, я снова повторюсь, что ФП представляет собой БЛ (берёт на себя организацию логических связей). А ИП - это больше ЧЛ языки, они ориентированы на жёсткую последовательность действий.

В целом согласен, но потенциально и на ФП можно сделать что-то императивное, и в ИП намудрить с функциями. default/smile

32

>В целом согласен, но потенциально и на ФП можно сделать что-то императивное, и в ИП намудрить с функциями. default/smile

Дык, разработчики языков и тех и других логик. И даже ЧЛ не откажет себе в перегрузке части БЛ-задач на язык и наоборот default/smile

Так и рождаются функциональный O'Caml, в котором можно писать совершенно императивно (хоть и смотрится ужасно), или императивный Python, в котором есть лямбда-выражения default/smile

33

Balancer пишет:

>В целом согласен, но потенциально и на ФП можно сделать что-то императивное, и в ИП намудрить с функциями. default/smile

Дык, разработчики языков и тех и других логик. И даже ЧЛ не откажет себе в перегрузке части БЛ-задач на язык и наоборот default/smile

Ну это само собой. Не бывает же чисто черных и чисто белых логиков. default/smile

34

А вот если взять программу на Форте и записать задом наперёд, то то, что получится, будет программой на каком-то языке? Я думаю, да. И скорее всего, функциональном.

У меня вопрос к Balancer'у:
Java-машина для чего нужна?
и нужна ли устройству, которое не ходит в интернет,
но имеет дело с реальным масштабом времени?

35

kaprizka пишет:

Java-машина для чего нужна?

для выполнения ява-байткода

kaprizka пишет:

и нужна ли устройству, которое не ходит в интернет,
но имеет дело с реальным масштабом времени?

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

36

xeye пишет:

для выполнения ява-байткода

Откуда возьмётся ява-байткод на штуковине, которая не подключена к интернету?

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

Вообще-то миллисекундные задержки очень вероятны. А при случае и микросекундные, например 125 мкс.

37

kaprizka пишет:
xeye пишет:

для выполнения ява-байткода

Откуда возьмётся ява-байткод на штуковине, которая не подключена к интернету?

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

38

Попытался изучить Яву. Не сумел.
Пример из самоучителя работает с грехом пополам с функцией drawText("Hello, WWW!"), но не работает с другими графическими функциями.
В классах чёрт ногу сломит, и как там среди гор мусора искать именно те классы и методы, какие мне нужны - хз.

39

kaprizka пишет:

Попытался изучить Яву. Не сумел.
Пример из самоучителя работает с грехом пополам с функцией drawText("Hello, WWW!"), но не работает с другими графическими функциями.
В классах чёрт ногу сломит, и как там среди гор мусора искать именно те классы и методы, какие мне нужны - хз.

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

40

kaprizka пишет:

Попытался изучить Яву. Не сумел.
Пример из самоучителя работает с грехом пополам с функцией drawText("Hello, WWW!"), но не работает с другими графическими функциями.
В классах чёрт ногу сломит, и как там среди гор мусора искать именно те классы и методы, какие мне нужны - хз.

Джаву надо начинать учить не с графики. %) А лучше с книги "Thinking in Java 2".

А язык хороший, нравится больше, чем С++. default/tongue