30 игровых скриптов, которые можно написать на языке PHP

Рассказ. По мотивам спора выше.

Сидят за столом 7 мальчиков.

Приходит еще один, и кладет перед каждым мальчиком - по кристаллу.

В центре стола, за которым сидят мальчики - 7 мест для вставки кристаллов.

Если кристаллы вставить, то заработает источник света в комнате.

Мальчик, принесший всем по кристаллу - это я.

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

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

Спорить с тобой, почему твой кристалл сам по себе не светится - мне не интересно.

> А я это выяснил? Вот так прямо взял и выяснил? Не намекнул, об этом, в пику того как Вы пытались намекать о противоположном?

Ну а что вы тогда хотели этим сказать?

> Мозг где-то вверху стопорится, там в одном неймспейсе - 10.000 функций, придуманных другими.

В Haskell, например, есть совершенно обычные пространства имён.

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

Дженериками пользуетесь?

> У меня нет 3-4 часов, чтобы в деталях изложить для Вас все и еще часов 10, нужных на то, чтобы Вы не съзжали с вопросов и не уезжали на своем мягком месте в ближайший ельник, с крольчихами и блэкджеком на питоне.

То есть ответа по существу не будет?

> А почему не ждете от меня описания межконтинентальной баллистической ракеты?

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

> Рассказ. По мотивам спора выше.

Какие ещё кристаллы? Какой круг?

Ладно. Вы мне хотя бы дайте определение понятия типа.

> В Haskell, например, есть совершенно обычные пространства имён.

Блин, ну что я и говорил. - Мальчик потер сначала свой кристалл, теперь начала плевать на него, и тоже не говорит.

Ну вот что доказывает Ваша фраза?

> Дженериками пользуетесь?

Пользуются презервативами.

Вы все таблицу Менделеева собираетесь перебирать, в Ваших вопросах?

>> А почему не ждете от меня описания межконтинентальной баллистической ракеты?

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

Блин, ну как это сложно. Возьмем C#, казалось бы первоначально который подразумевал использование в основном ООП-парадигмы, и в который в последних версиях его, добавили элементы функционального программирования.

У Питона есть реализация под .NET, там уже им пользоваться более удобно.

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

И я Вас переспорил.

Попробуйте остальные, кажущиеся вам, спорные моменты - сами обдумайте.

Ну не такое невесть что я написал непонятное то...

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

;)

> Мальчик потер сначала свой кристалл, теперь начала плевать на него, и тоже не говорит.

Мальчик потер сначала свой кристалл, теперь начаЛ плевать на него, и тоже не гОРит.

Пардон за опечатки.

> Ладно. Вы мне хотя бы дайте определение понятия типа.

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

:D

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

Заодно подскажите, в какой более-менее известной у нас книге по ООП (она давно переведена на русский язык и у нее не одно издание) - это описано.

Антигугл к Вам применяю.

>> В Haskell, например, есть совершенно обычные пространства имён.

> Блин, ну что я и говорил. - Мальчик потер сначала свой кристалл, теперь начала плевать на него, и тоже не говорит.

> Ну вот что доказывает Ваша фраза?

Не доказывает, а сообщает. В ответ на:

> Видите, до чего плоский (2D) путь функционального мышления доводит - путаетесь в конкретных фактах, по привычке даже и не пытаясь связать их воедино. Мозг где-то вверху стопорится, там в одном неймспейсе - 10.000 функций, придуманных другими.

>> Дженериками пользуетесь?

> Пользуются презервативами.

Пользуются много чем. Ну так всё-таки, пользуетесь дженериками при написании кода? (используете/применяете/whatever)

> Блин, ну как это сложно. Возьмем C#, казалось бы первоначально который подразумевал использование в основном ООП-парадигмы, и в который в последних версиях его, добавили элементы функционального программирования.

> У Питона есть реализация под .NET, там уже им пользоваться более удобно.

> Вот Вы спорили сейчас, по какому-то, выбранному Вами факту, что моя концепция не описывает всего и Питон, мол, к ней не применим.

> И я Вас переспорил.

Ну и чем таким принципиальным IronPython отличается от CPython (кроме доступа к .Net-объектам)? А даже если бы и отличался, CPython никуда не изчез.

> Вот Вы спорили сейчас, по какому-то, выбранному Вами факту, что моя концепция не описывает всего и Питон, мол, к ней не применим.

Как в Python определяются типы переменных? Во время выполнения, то есть динамически. Отсюда и динамическая типизация.

def f(x, y): return x+y

При a = 1, b = 2 --- f(a, b) вернёт 3. При a = "foo", b = "bar" --- f(a, b) вернёт "foobar". При a = 1, b = "bar" --- f(a, b) бросит TypeError.

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

Конечно, это упрощённо, но показывает главное :)

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

Да, открывал, в браузере. На чтение до конца ушло около недели. А что?

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

Может, раннего связывания? Такое есть. Про остальное не знаю, буду рад узнать от вас.

Ну что это такое-то? Просто определение, что такое тип в программировании? Лучше своими словами. Это же основы основ.

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

> Заодно подскажите, в какой более-менее известной у нас книге по ООП (она давно переведена на русский язык и у нее не одно издание) - это описано.

А при чём тут ООП? Теория типов охватывает не только (и не столько) ООП.

> При статической типизации (статическом контроле типов) в сигнатуре, конечно, надо было указать типы параметров и другие типы бы не прошли, но функцию пришлось бы писать n раз для n типов.

При отсутствии типизации переменных в языке - переменной не то что можно присвоить любой тип, а и присвоить ей и альяс на функцию.

Т.е. в например виртуальной машине флеша 1-ой версии - все переменные и все функции - линкуются альясами или непорседственно к объекту _global, или к одному из его детей, например _global.anySpace.anyObject.anyVariable

Мы можем назначить этой anyVariable или какую-то переменную, или какую-то функцию, и циклом foreach с включенными флагами сканирования всего - найти эту переменную в ее родителе.

ЧТО ВЫ МНЕ ХОТИТЕ ОБЪЯСНИТЬ?

Те извраты формулировок, к которым прибегают сторонники функционального программирования?

Или что-то еще? Вот это _что-то еще_, полезности от этого что-то - я до сих пор не уловил.

Все надумано и избыточно.

> При отсутствии типизации переменных в языке - переменной не то что можно присвоить любой тип, а и присвоить ей и альяс на функцию.

Вы так и не поняли. Типизация там есть, типы есть, но типы во время старта программы неизвестны, только когда x получает значение 1, тип x становится IntType, когда x получает значение "foobar", тип x становится StringType. Нельзя провести, например, операцию + над этими двумя типами.

> ЧТО ВЫ МНЕ ХОТИТЕ ОБЪЯСНИТЬ?

> Те извраты формулировок, к которым прибегают сторонники функционального программирования?

> Или что-то еще? Вот это _что-то еще_, полезности от этого что-то - я до сих пор не уловил.

Хочу объяснить, что такое динамическая типизация. И я не "сторонник ФП", но мне очень нравится.

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

> Может, раннего связывания? Такое есть. Про остальное не знаю, буду рад узнать от вас.

> Ну что это такое-то? Просто определение, что такое тип в программировании? Лучше своими словами. Это же основы основ.

Нет, Вы не знаете. Спасибо за честность.

Описывать сейчас лень, что такое низкое связывание и высокое зацепление кода.

Это основы-основ понимания _правильного_ программирования.

Может быть Вы купите книгу Крэга Лармана, в которой это хорошо описано? Сейчас актуально 3-ее издание, 2-ое не берите (ну, раз есть более новое).

Заодно там описаны паттерны проектирования GRASP - именно на них, на их принципах - работают небезизвестные паттерны GoF.

Рекомендую без всяких споров - просто купить эту книгу. Это как ассемблер изучить, чтобы хорошо понимать все самые базовые принципы, из чего стоится 50%-70% остального, а если говорить ИСПОЛЬЗУЕТСЯ - то вообще под 100% всех остальных паттернов проектирования.

http://www.books.ru/shop/books/25832

- тут, к сожалению, только 2-ое издание, да и того нет в продаже. На Озоне должно быть, но там традиционно на процентов 20 дороже, чем на books.ru

> Спасибо за честность.

Да пожалуйста. Как говорил мой преподаватель, "тот, кто думает, что знает всё --- плохой программист" :-)

> Это основы-основ понимания _правильного_ программирования.

Не бывает такого. Просто есть ряд хороших практик. Нет единственно правильного пути ;-)

> Заодно там описаны паттерны проектирования GRASP - именно на них, на их принципах - работают небезизвестные паттерны GoF.

Я их знаю, правда поверхностно.

Я просто что хочу сказать. Computing science --- это не только ООП и паттерны проектирования. Выгляните в окно: там ещё столько всего интересного! :-)

>> При отсутствии типизации переменных в языке - переменной не то что можно присвоить любой тип, а и присвоить ей и альяс на функцию.

> Вы так и не поняли. Типизация там есть, типы есть, но типы во время старта программы неизвестны, только когда x получает значение 1, тип x становится IntType, когда x получает значение "foobar", тип x становится StringType. Нельзя провести, например, операцию + над этими двумя типами.

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

То что я описывал - там можно любой переменной назначить тип - после компиляции. Это плохо, или это хорошо? Или как это соотносится с тем, что Вы говорите?

> Нельзя провести, например, операцию + над этими двумя типами.

Это плохо, или это хорошо? Во многих учебниках по ЯП - в первой сотне страниц этого учебника (примерно там) - описываются правила, по которым ЯП будет в некоторых случаях делать автоприведение типа.

Это плохо? Или это хорошо? Плохи учебники? Или ЯП-ния-?

Что это все доказывает, я тчо-то не пойму?

> Не понял, что именно я должен был понять из этого, к какому прийти выводу, в результате.

> То что я описывал - там можно любой переменной назначить тип - после компиляции. Это плохо, или это хорошо? Или как это соотносится с тем, что Вы говорите?

Ну, строго говоря в динамических ЯП переменные создаются "на лету", и связываются с определённым значением. Плохо или хорошо? Зависит от ситуации и цели.

>> Нельзя провести, например, операцию + над этими двумя типами.

> Это плохо, или это хорошо? Во многих учебниках по ЯП - в первой сотне страниц этого учебника (примерно там) - описываются правила, по которым ЯП будет в некоторых случаях делать автоприведение типа.

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

> Плохи учебники? Или ЯП-ния-?

Я не знаю, какие конкретно учебники, но подозреваю, что там просто это не упоминалось. Нельзя же сразу рассказывать обо всём на свете.

> Что это все доказывает, я тчо-то не пойму?

Скорее показывает, что такое динамическая типизация и ЯП с ней.

>Мальчик, принесший всем по кристаллу - это я.

Мальчик-кристаллоносец, я восторгаюсь твоими ЧСВ с ФГМ на пару, равно как и терпению твоего оппонента :D

> А Вы дайте мне определение низкого связывания и высокого зацепления кода

Всё, понял, когда подсмотрел в Википедии.

Но зачем так переводить? Тогда уж слабое сцепление и сильная связь.

>> Мальчик, принесший всем по кристаллу - это я.

> Мальчик-кристаллоносец, я восторгаюсь твоими ЧСВ с ФГМ на пару, равно как и терпению твоего оппонента :D

Упрек принят, обоснован. Извиняюсь перед оппонентом.

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

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

2D-программирование, в виде построения "черепахи" (воен.), которую "проталкивают" вперед (функцию) в функциональном программировании - вместо свободы 3D-пространства?

;)

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

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

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

"О, здесь нужна Фабрика (Factory method)"

"О, здесь нужно по паттерну Шаблон (Template method)"

"О, здесь, в этом узле, нужно по паттерну Strategy"

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

Польза очевидная и колоссальная!

Конечно имеет смысл - что-то такое поизучать, раз такая польза потом.

Будет польза от другого - тоже будет иметь смысл изучать. Нужны характерные примеры, явно и однозначно доказывающие пользу того или того!

:)

> Но зачем так переводить? Тогда уж слабое сцепление и сильная связь.

Есть устоявшаяся терминология, довольно устоявшаяся.

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

Мальчик с кристаллами, а не потрудишься ли перечислить свои достижения, или хотя бы список удачно завершенных сложных проектов с твоим участиям и твою роль в них? А то пока что ты больше похож на обчитанного ООП-макулатурой начинающего теоретика-архитектора веб-морд к базам данных и других "крутых бизнес-приложений".

> Образно говоря - зачем нужны дополнительные перекрестные ссылки-альясы на часть объектов в программе, все это связывает всю конструкцию. Это как программировать с использование преимущественно Singleton-ов и потом удивляться, что код связан жесткими узлами и его очень сложно модернизировать и поддерживать, так как дернешь только одну ветвь - сразу же посыпется и все остальное.

Ну, в Python, например, "утиная типизация", то есть объект ещё и представляет интерфейс. Скажем, есть объект, реализующий метод __dict__, значит, его можно использовать в качестве ассоциативного массива. Это позволяет избавиться от небоскрёбов наследования классов и гибко подстраиваться под существующий код. Конечно, есть и недостатки.

А вообще я не понял, что за перекрёстные ссылки на алиасы.

> 2D-программирование, в виде построения "черепахи" (воен.), которую "проталкивают" вперед (функцию) в функциональном программировании - вместо свободы 3D-пространства?

Ммм... а вы точно знаете про функции в ФП? Например, там функция может принимать в качестве параметра другую функцию и возвращать третью. Например, обычная map f list берёт функцию f, список list и возвращает список элементов, к каждому из которых применена f. Это почти тривиально. Так вот, определив несколько таких функций, можно легко "разбирать на кусочки" множество других операций, а способность возвращать функцию позволяет генерировать операции для "частных нужд". Это трудно понять, если никогда не видел HOF в действии, знаю по себе.

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

Затем, в чистых ЯП возвращаемое значение зависит _только_ от входных параметров. Программу можно очень легко тестировать по частям.

А вообще есть и ФП с ОО-возможностями. Пока не изучал, так что о них не знаю. Но ОО там, конечно, другая.

...

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

Просто попробуйте почитать о ФП. Я думаю, что вам понравится (только нужно на время забыть про объекты :-) . Кроме того, опыт и практика, полученные там, можно перенести и на императивные и ОО-языки (например, в журнале "Практика ФП" была статья, там автор переносил идеи из ФП в Java).

А эти ваши игровые PHP скрипты повышенной сложности умеют грабить корованы?

> Есть устоявшаяся терминология, довольно устоявшаяся.

Если устоявшаяся, то _очень_ плохо...

> Вопрос на сколько "сильная связь" лучше "высокого зацепления" и лучше ли - тема отдельного форума.

Что выше чего? Что за что зацепляется?

Идея этого паттерна в том, что (надеюсь, правильно :-) системы, выполняющие одну задачу, должны "быть вместе" и делать свою задачу и ничего более, они сильно связаны. Даже лучше, плотно связаны.

> Мальчик с кристаллами, а не потрудишься ли перечислить свои достижения, или хотя бы список удачно завершенных сложных проектов с твоим участиям и твою роль в них? А то пока что ты больше похож на обчитанного ООП-макулатурой начинающего теоретика-архитектора веб-морд к базам данных и других "крутых бизнес-приложений".

Это скорее про меня, только без веб-морд :)

> Мальчик с кристаллами, а не потрудишься ли перечислить свои достижения, или хотя бы список удачно завершенных сложных проектов с твоим участиям и твою роль в них? А то пока что ты больше похож на обчитанного ООП-макулатурой начинающего теоретика-архитектора веб-морд к базам данных и других "крутых бизнес-приложений".

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

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

>есть объект, реализующий метод __dict__, значит, его можно использовать в качестве ассоциативного массива

Бррр, ну 4.2 же.

Почему вы заведомо считаете что подход ООП лучше подхода функционального программирования? Вы смотрели как в языке Haskell вводятся классы?

Это ООП тащит из функциональных языков все полезное: полиморфизм, замыкания, продолжения, дженерики, функциональные типы, вместо того чтобы понять концепцию ФП целиком.

>> есть объект, реализующий метод __dict__, значит, его можно использовать в качестве ассоциативного массива

> Бррр, ну 4.2 же.

Ой. Это же словарь с атрибутами. Прошу прощения...

> Ну, в Python, например, "утиная типизация", то есть объект ещё и представляет интерфейс. Скажем, есть объект, реализующий метод __dict__, значит, его можно использовать в качестве ассоциативного массива. Это позволяет избавиться от небоскрёбов наследования классов и гибко подстраиваться под существующий код. Конечно, есть и недостатки.

Возьмем Java (например). Объект может являться экземпляром класса, который (класс) - имплементирует в себе один (или более, если нужно) интерфейсов.

И точно так же можно реализовать метод dict() или любой другой и точно так же использовать его в качестве ассоциативного массива, и точно так же не использовать небоскребы классов, и точно так же так же гибко подстроиться под существующий код.

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

Никакого нагромождения. Вообще никакого. Private-переменная, с методами доступа к ней.

Хочется интерфейс? - Пожалуйста!

Хочется рассылку событий при добавлении или удалений из этого ассоциативного массива? - Пожалуйста!

- Любой каприз!

Кстати, что за языки программирования ты "профессионально" выучил? С++, Delphi, Java?

>> Мальчик с кристаллами, а не потрудишься ли перечислить свои достижения, или хотя бы список удачно завершенных сложных проектов с твоим участиям и твою роль в них? А то пока что ты больше похож на обчитанного ООП-макулатурой начинающего теоретика-архитектора веб-морд к базам данных и других "крутых бизнес-приложений".

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

Ну так я и спрашиваю, в чем заключалась эта практика?

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

Фу как некрасиво.

Просто ты чуток мне меня напоминаешь в начале моей профессиональной программистской карьеры. Я первые 2 года писал на J2EE "крутые энтерпрайз приложения", считал ООП пупом земли и зачитывался GoF-ом и Фаулером.

> Мальчик, принесший всем по кристаллу - это я.

Только ЧСВ у меня такого не было. :-D

Да. В целом с твоим описанием утипизации согласен, а в качестве примера с "кряканием" как ассоциативный массив можно было привести методы __getitem__ и __setitem__ :)

> И точно так же можно реализовать метод dict() или любой другой и точно так же использовать его в качестве ассоциативного массива, и точно так же не использовать небоскребы классов, и точно так же так же гибко подстроиться под существующий код.

Но нужно всякий раз описывать интерфейсы. А тут весь объект --- уже интерфейс. Python широко используется для быстрого написания программ. "Если что-то ходит, как утка, и крякает, как утка, то это, должно быть, утка". Это на самом деле быстрее и гибче, чем интерфейсы, но и опаснее, конечно.

>> Образно говоря - зачем нужны дополнительные перекрестные ссылки-альясы на часть объектов в программе ...

> А вообще я не понял, что за перекрёстные ссылки на алиасы.

Не перекрестные ссылки на альясы, а перекрестные ссылки-альясы.

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

Например мы хотим удалить из общей конструкции - один такой объект. У нас 20 ссылок на него, из разных мест кода.

Удалить этот объект нужно - например потому, что изменились бизнес-требования.

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

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

Вы начали изменять.

Изменили одно место.

Второе.

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

17-ое и 18-ое - тоже сложно изменить, отказаться там от использования этого объекта.

А если Вы изменили первые 10 мест, то окажется, эти изменения - влияют на еще 100 мест в Вашем коде.

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

> Просто попробуйте почитать о ФП. Я думаю, что вам понравится (только нужно на время забыть про объекты :-)

У меня большой опыт по программированию в стиле ФП. Так же большой опыт по разбору такого кода от других. Так же большой опыт - как обходить сложность в ФП и оперировать десятками тысяч строк кода в нем.

И так же большой опыт, как оперировать С ЛЕГКОСТЬЮ - сотнями тысч строк кода!!!

:)

Вы меня не переубедите, но спасибо за интересное описание. :)

На самом деле!

> Кстати, что за языки программирования ты "профессионально" выучил? С++, Delphi, Java?

Кстати? Кстати к чему? Еще один половой гигант?

> И так же большой опыт, как оперировать С ЛЕГКОСТЬЮ - сотнями тысч строк кода!!!

> :)

Если нет ФП. :)

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

Ну так динамическая типизация не подразумевает спагетти-код. В принципе, всё так же обособлено. Кстати, там заменить объект, afaiu, проще, т.к. динамика. Хотя всё-таки это догадка.

> У меня большой опыт по программированию в стиле ФП. Так же большой опыт по разбору такого кода от других. Так же большой опыт - как обходить сложность в ФП и оперировать десятками тысяч строк кода в нем.

Может, тогда объясните мне, каким образом в ФП функции пытаются эмулировать объекты. Это не укладывается у меня в голове.

И да, это какие были языки? А то я видел только Scheme и Haskell (Python всё-таки мимо, хотя именно там я узнал о HOF :-)

> Я первые 2 года писал на J2EE "крутые энтерпрайз приложения"

Странная фраза. Есть просто приложения. Почему должен быть крутым С-код или J2EE-код - ?

Обычно продавцы на рынке, продающие на ветру и под дождем диски, говорят примерно такое же -- Знаем мы эту вашу Яву! [с оттенком презрения]

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

Вы не на Савеловском рынке стоите, нет?

> Мальчик с кристаллами, а не потрудишься ли перечислить свои достижения, или хотя бы список удачно завершенных сложных проектов с твоим участиям и твою роль в них?

Я просто это к чему спрашиваю:

Джон Бакус, лауреат премии Тьюринга, которому мы обязаны Фортраном и BNF, ещё в 1977 году выпустил знаменитую лекцию "Can Programming be Liberated from the von Neumann Style?" http://www.stanford.edu/class/cs242/readings/backus.pdf и занимался остаток карьеры функциональным программированием.

Мартин Одерский, автор дженериков в Java, сейчас занимается разработкой Scala.

Кому верить, им или тебе?

> Может, тогда объясните мне, каким образом в ФП функции пытаются эмулировать объекты. Это не укладывается у меня в голове.

Вопросы один за одним, но мы обсуждаем не сам первоначальный вопрос.

Давайте когда будет у Вас хороший пример (в каком именно контексте без вашей терминологии просто не обойтись, кроме как обсужденого здесь ФП) - тогда и продолжим.

>И вот, например вот эта задача - нужно удалить такой объект, который существует во время выполнения. И на него ссылаются/используют - десятки других объектов.
>- Для того, чтобы удалить этот объект из всей программно-архитектурной конструкции - придется изменять и 20 других мест, из которых используют этот объект.
>Вы начали изменять.
>Изменили одно место.
>Второе.
>Третье и четверное - так просто не получается изменить, там, тогда, придется перерабатывать алгоритмы их работы, по новому.
>17-ое и 18-ое - тоже сложно изменить, отказаться там от использования этого объекта.
>А если Вы изменили первые 10 мест, то окажется, эти изменения - влияют на еще 100 мест в Вашем коде.

Трудно поверить, но все эти проблемы касаются ООП едва ли не в первую очередь. Умение программиста делать грамотную декомпозицию кода и вообще применять принцип D&Q мало зависит от того, какую парадигму он в данный момент использует. И хорошо, когда программист владеет разными парадигмами. И плохо (иной раз фатально), когда он зациклен на одной.

И вообще, как не сдох театр с появлением кино, как не сдохли ручные коробки передач с появлением автоматических так и ФП из-за ООП не сдохнет.

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

Будут хорошие примеры, _нужности_ - тогда и поговорим. :)

Не будет - значит их нет. ;)

> Вопросы один за одним, но мы обсуждаем не сам первоначальный вопрос.

Ну это же 3-4 предложения. Проявите уважение.

> Давайте когда будет у Вас хороший пример (в каком именно контексте без вашей терминологии просто не обойтись, кроме как обсужденого здесь ФП) - тогда и продолжим.

Я же уже выше приводил пример динамической типизации:

http://www.linux.org.ru/view-message.jsp?msgid=3953708&lastmod=1250281711...

И обоснованность сильной/слабой типизации: напр. ADA ~ BASIC

> Будут хорошие примеры, _нужности_ - тогда и поговорим. :)

Generics. Я не поверю, что кто-то ими не пользуется для программ выше самых простых.

А уж про BNF и говорить нечего...

> И вообще, как не сдох театр с появлением кино, как не сдохли ручные коробки передач с появлением автоматических так и ФП из-за ООП не сдохнет.

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

Все остальное ("Умение программиста делать грамотную декомпозицию кода и вообще применять принцип D&Q мало зависит от того, какую парадигму он в данный момент использует. И хорошо, когда программист владеет разными парадигмами. И плохо (иной раз фатально), когда он зациклен на одной.") - "просто слова". :) :P

> Обычно продавцы на рынке, продающие на ветру и под дождем диски, говорят примерно такое же -- Знаем мы эту вашу Яву! [с оттенком презрения]

> У меня всегда в таких случаях возникает вопрос - что ж ты тогда стоишь здесь на ветру и мокнешь под дождем, если ты "знаешь эту яву", почему не сидишь в чистом-уютном офисе и зарабатываешь хорошие деньги при этом?

> Вы не на Савеловском рынке стоите, нет?

Бурная фантазия, однако. :) Боюсь даже представить, что ты увидишь на тестах Роршаха.

Нет, как раз таки сижу в чистом-уютном офисе и зарабатываю хорошие деньги при этом.

Ты вот тут выше вопил, что я тебе про книжку не так ответил. А на наши вопросы отвечать собираешься? И не вопросом на вопрос. ;) Тебя тут ещё про знание языков программирования спросили.

> Ну это же 3-4 предложения. Проявите уважение.

Гм. По моему давно уже был перебор с вопросами на самые разнообразные темы.