Кхм,
чёрт, а я всегда думал что
for(Player p = getKnownPlayers())(){}
будет run-time error в том случае если метод вернёт массив Player[]
Вы не вошли. Пожалуйста, войдите или зарегистрируйтесь.
СОЦИОН. » Юный техник » Концепции программирования для разных логик.
Кхм,
чёрт, а я всегда думал что
for(Player p = getKnownPlayers())(){}
будет run-time error в том случае если метод вернёт массив Player[]
чёрт, а я всегда думал что
А я всегда думал, что между
for(Player p = getKnownPlayers())
и
for(Player i : getKnownPlayers())
есть некоторая разница
Или князь до сих пор в Java 1.4.x программирует?
Кхм, я и смотрю какой-то странный синтакс, а это Балансер оказывается новую версию жабы рекламирует.
Кхм, я и смотрю какой-то странный синтакс, а это Балансер оказывается новую версию жабы рекламирует.
Угу. Мине за ето sun по утрам халявным кофием поит
У меня есть знакомый Габен, мы с ним часто полемизируем насчёт БЛ и ЧЛ, что "лучше", что первично и т.п.
В результате пришёл такому выводу:
у БЛогика ЧЛ и витале, автоматически функционирует, у ЧЛогика то же с БЛ. Это можно сравнить с процедурой в проге, которая раз за разом выполняет заложенные в ней действия.
Деловики используют наработки структурников, а структурники - деловиков.
Вот краткий обзор современных подходов к программированию (на точность не претендую, так как писал все сам и не для того, чтобы было точно, а для того, чтобы было понятно. ).
В настоящее время используют такие подходы (в скобках -- наиболее характерные языки, реализующие данный подход):
1. Процедурный. (C, Pascal, bash, и т.д.)
2. Фукциональный. (Lisp, Scheme.)
3. Объектно-ориентированный. (Smalltalk, C++, Java.)
4. Ситуационный, он же event-based. (Честно говоря, х.з. Может, Tk?)
5. Продукционный, он же rule-based (встроенные языки пакетов Maple, Mathematica).
6. Логический (Слышал только о Прологе, но и его хватает. )
Вообще говоря, объектно-ориентированный подход -- это разновидность процедурного, а ситуационный выделен лишь условно.
Подходы 1 и 3 -- императивные, 2, 5, 6 -- декларативные. 4 -- комбинированный.
Подробно о каждом подходе и их различиях:
1. Имеются отдельно данные и отдельно методы. (Это тоже довольно условно, так как, в принципе, можно залезть в сегмент кода. )
Данные живут отдельной жизнью и они, как правило, несут в себе сложность задачи, то есть, когда задача усложняется, усложняются и структуры данных. Для этих языков характерно следующее:
- линейность -- команды выполняются одна за другой, преобразуя данные,
- процедурность -- существует возможность разбиения сложного алгоритма на более простые, то есть программист может расширять словарь команд.
2. В отличие от предыдущего подхода, здесь цель достигается не за счет преобразования данных, а за счет последовательного применения к ним функций, приближающих к цели. Сама программа -- это композиция этих функций.
Отличие от процедурного подхода трудно почувствовать, не зная функциональных языков, но оно, очевидно есть.
Например, в языке Scheme существует возможность реализовать функции, выделяющие голову и хвост списка (car и cdr) не через создание структуры данных, а через создание кода, который и отождествляется с этой структурой. То есть, пользователь этого кода (не знающий о реализации) полагает, что он передает как аргумент этих функций список, но на самом деле передается код (например, какая-то лямбда-функция). То есть тут получается что-то вроде "суперинкапсуляции", когда код и данные не просто объединены, но являются разными сторонами одной сущности.
Характерные особенности:
- используется полуалгоритмический подход -- вроде бы программист и задает алгоритм, но не так явно, как это делается в процедурныхя языках, он скорее задает структуру алгоритма (в отличие от Пролога, в котором задается структура системы),
- повсеместное использование лямбда-функций (они же чистые функции),
- частое использование рекурсии, очень частое использование хвостовой рекурсии (во всех итеративных алгоритмах).
На самом деле, как я уже писал, суть функционального программирования очень трудно передать (так что рекомендую почитать, например, книжку Абельсона "Структура и интерпретация программ" -- замечательная весчь! ), но уж поверьте на слово, это очень изящный подход.
Например, вот решение задачи о том, сколькоми способами можно поменять на монеты заданную сумму, если есть монеты достоинством 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 копеечных монет. )
3. Это очень модно, так что об этом и без меня все всё знают.
Характерные особенности:
- инкапсуляция,
- наследование,
- полиморфизм.
Имхо, единственной на практике полезной вещью является полиморфизм. Остальное часто только приводит к куче лишней писанины, а это болезненный удар по моей лени (но сказанное не верно, если базовые классы написаны кем-то другим ). А разговоры об "абстракции" и "удобстве многократного использования кода" как особенностях ООП -- это пижонство. Так как это пришло в ООП из процедурного программирования как модификация технологии "сверху-вниз".
Основная идея ООП -- "все объекты, которые сами все о себе знают".
4. Вместо описания последовательности действий, описываются события и алгоритмы их обработки. Алгоритмы могут сами вызывать события.
5. Продукционный подход -- это основа современной компьютерной алгебры.
Пример продукционной программы на некотором условном языке:
f(0)=1
f(n)=n*f(n-1)
То есть заданы правила, описывающие свойства некоторой функции (в данном случае это факториал).
Теперь задав программе цель f(5), мы получим результат -- 120. Программисту описывать алгоритм нет нужды.
Характерные особенности:
- описывается не алгоритм, а свойства системы,
- описание представляет собой правила преобразования для поиска решения, не обязательно однозначно задающие алгоритм продвижения к цели: поиск такого алгоритма -- проблема транслятора.
6. Наиболее абстрактный подход.
Пример программы:
предок (Иван, Петр).
предок (Петр, Василий).
предок (A, С) :- предок(A,B) and предок(B,C).
?-предок(Иван, Василий).
Здесь можно выделить следующие элементы: набор фактов, свойство отношения "быть предком" и цель -- "является ли Иван предком Василия?"
Результатом работы программы будет значение true. Но это не значит, что программа пролог только и может, что решать логические задачки. Существуют, например, встроенные предикаты, работающие с файлами, открывающие диалоговые окна и т.д.
Характерные особенности:
- описывается не алгоритм, а свойства системы, но, в отличие от предыдущих случаев, алгоритм (в идеале) не описывается даже неявно (но это не означает, что программисту не нужно заботиться о том, как решить данную задачу),
- задаются факты, некоторые предикаты и цель, истинность которой нужно определить,
- все внешние действия программа выполняет в процессе поиска решения и они определяются логикой самой задачи -- то есть программист может (почти) не заботиться о придумывании алгоритма.
Пролог довольно удобен для написания программ работы с базами данных. Ну и, естественно, его часто используют для написания программ, имитиующих AI.
Следует отметить, что логический язык программирования -- это не математическя логика, так как в программе на таком языке все же присутствует некая схема управления.
'!' пишет:причём оперирует не машинными типами данных, а абстрактными.
Нет, типизация в них бывает зачастую очень жёсткая. При чём, в случае того же O'Caml она даже статическая, не динамическая. Но, как и во многих современных императивных ЯВУ, типизация может быть скрыта от пользователя.
Ну на самом деле, конечно, типы в идею ФЯП пришли только при создании трансляторов. В том же Lisp вначале даже чисел не было.
Да и сейчас типы никто типами не называет -- просто знают, что они появятся при трансляции, так как все равно все это будет выполняться на реальной машине. Но это уже проблема транслятора.
Спасибо! Кажется, понятно. Суть ФП - не в преобразовании данных, хранящихся в переменных и структурах, как в ИП, а в порождении новых данных на основе входных, путем последовательного применения функций (вопрос о хранении данных скрыт в реализации транслятора).
Ну, вроде того...
Возвращаясь к сабжу - да, ФП, похоже, чернологично по сути ...
Да большой разницы нет в ч/б-логичности между ФП и ИП нет, наверное. И тут и там сначала проектируются общие крупные куски (БЛ), а потом это все реализуется через функции самого языка (ЧЛ).
Да большой разницы нет в ч/б-логичности между ФП и ИП нет, наверное. И тут и там сначала проектируются общие крупные куски (БЛ), а потом это все реализуется через функции самого языка (ЧЛ).
А вот у меня на форуме творческий ЧЛ уже который раз говорит, что не доверяет ФП, т.к. там скрыта внутренняя связь элементов
Так что, я снова повторюсь, что ФП представляет собой БЛ (берёт на себя организацию логических связей). А ИП - это больше ЧЛ языки, они ориентированы на жёсткую последовательность действий.
Кодирование - преим. ЧЛ, проектирование и специфицирование - БЛ.
...постановка задач - снова ЧЛ; определение смысла жизни - БЛ
masai пишет:Да большой разницы нет в ч/б-логичности между ФП и ИП нет, наверное. И тут и там сначала проектируются общие крупные куски (БЛ), а потом это все реализуется через функции самого языка (ЧЛ).
А вот у меня на форуме творческий ЧЛ уже который раз говорит, что не доверяет ФП, т.к. там скрыта внутренняя связь элементов
Так что, я снова повторюсь, что ФП представляет собой БЛ (берёт на себя организацию логических связей). А ИП - это больше ЧЛ языки, они ориентированы на жёсткую последовательность действий.
В целом согласен, но потенциально и на ФП можно сделать что-то императивное, и в ИП намудрить с функциями.
>В целом согласен, но потенциально и на ФП можно сделать что-то императивное, и в ИП намудрить с функциями.
Дык, разработчики языков и тех и других логик. И даже ЧЛ не откажет себе в перегрузке части БЛ-задач на язык и наоборот
Так и рождаются функциональный O'Caml, в котором можно писать совершенно императивно (хоть и смотрится ужасно), или императивный Python, в котором есть лямбда-выражения
>В целом согласен, но потенциально и на ФП можно сделать что-то императивное, и в ИП намудрить с функциями.
Дык, разработчики языков и тех и других логик. И даже ЧЛ не откажет себе в перегрузке части БЛ-задач на язык и наоборот
Ну это само собой. Не бывает же чисто черных и чисто белых логиков.
А вот если взять программу на Форте и записать задом наперёд, то то, что получится, будет программой на каком-то языке? Я думаю, да. И скорее всего, функциональном.
У меня вопрос к Balancer'у:
Java-машина для чего нужна?
и нужна ли устройству, которое не ходит в интернет,
но имеет дело с реальным масштабом времени?
Java-машина для чего нужна?
для выполнения ява-байткода
и нужна ли устройству, которое не ходит в интернет,
но имеет дело с реальным масштабом времени?
если ты буквально про систему реального временеи , когда критична реакция в течение миллисекунд, то яве там, конечно, делать нечего.
для выполнения ява-байткода
Откуда возьмётся ява-байткод на штуковине, которая не подключена к интернету?
если ты буквально про систему реального временеи , когда критична реакция в течение миллисекунд, то яве там, конечно, делать нечего.
Вообще-то миллисекундные задержки очень вероятны. А при случае и микросекундные, например 125 мкс.
xeye пишет:для выполнения ява-байткода
Откуда возьмётся ява-байткод на штуковине, которая не подключена к интернету?
Ну, я думаю, в результате компилирования программы для платформы ява (а это собственно ява и питон, может еще какие языки есть).
Попытался изучить Яву. Не сумел.
Пример из самоучителя работает с грехом пополам с функцией drawText("Hello, WWW!"), но не работает с другими графическими функциями.
В классах чёрт ногу сломит, и как там среди гор мусора искать именно те классы и методы, какие мне нужны - хз.
Попытался изучить Яву. Не сумел.
Пример из самоучителя работает с грехом пополам с функцией drawText("Hello, WWW!"), но не работает с другими графическими функциями.
В классах чёрт ногу сломит, и как там среди гор мусора искать именно те классы и методы, какие мне нужны - хз.
а расскажи, зачем пытался? и почему с графики начал? и работал ли ты раньше с графикой под С/WinAPI?
и что за самоучитель?
Попытался изучить Яву. Не сумел.
Пример из самоучителя работает с грехом пополам с функцией drawText("Hello, WWW!"), но не работает с другими графическими функциями.
В классах чёрт ногу сломит, и как там среди гор мусора искать именно те классы и методы, какие мне нужны - хз.
Джаву надо начинать учить не с графики. %) А лучше с книги "Thinking in Java 2".
А язык хороший, нравится больше, чем С++.
СОЦИОН. » Юный техник » Концепции программирования для разных логик.
На основе PunBB, при поддержке Informer Technologies, Inc.
Currently used extensions: favorite_topic, pun_repository. Copyright © 2008 PunBB
Сгенерировано за 0.010 секунд(ы), выполнено 73 запросов