LINUX.ORG.RU

[вброс]Почему объектно-ориентированное программирование провалилось?


2

7

http://citforum.ru/gazeta/165/

по линку многабукаф, немного для Ъ:

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

Другой крупный критик ООП – это известный специалист по программированию Александр Степанов, который, работая в Bell Labs, участвовал в создании C++ вместе c Бьерном Страуструпом (Bjarne Stroustrup), а впоследствии, уже после приглашения в HP Labs, написал Standard Template Library (STL). Александр Александрович полностью разочаровался в парадигме ООП; в частности, он пишет: “Я уверен, что парадигма ООП методологически неверна. Она начинает с построения классов. Это как если бы математики начинали бы с аксиом. Но реально никто не начинает с аксиом, все начинают с доказательств. Только когда найден набор подходящих доказательств, только тогда на этой основе выводится аксиома. Т.е. в математике вы заканчиваете аксиомой. Тоже самое и с программированием: сначала вы должны начинать развивать алгоритмы, и только в конце этой работы вы приходите к тому, что оказываетесь в состоянии сформулировать четкие и непротиворечивые интерфейсы. Именно из-за этой неразберихи в ООП так популярен рефакторинг – из-за ущербности парадигмы вы просто обречены на переписывание программы, уже в тот самый момент, когда только задумали её спроектировать в ООП-стиле”.

Ричард Столлман (Richard Stallman) также известен своим критическим отношением к ООП, особенно он любит шутить насчет того мифа объектников, что ООП “ускоряет разработку программ”: “Как только ты сказал слово «объект», можешь сразу забыть о модульности”.

Ричард Гэбриел неожиданно сравнивает нынешнюю ситуацию с ООП с провалом эфиродинамики в физике начала 20 века, когда, в сущности, произошла “тихая революция”.

Ответ на: комментарий от www_linux_org_ru

> отношение «меньше» на field_to_order задано как «одно число делит другое»?

кстати, какой смысл имеет такая сортировка?
там же все праймы будут в куче, многие числа будут просто равны друг-другу итд.
Гораздо более осмысленно будет считать какую-нибудь зета-функцию Римана в комплексной плоскости - если интересуют праймы. И проверять (если у вас суперкомпьютер и хотите проверить гипотезу). А если нужны просто праймы - заполучите уже посчитанный список (там уже неслабо насчитали ), положите его в индекс и сравнивайте ваши числа с тем списком.

siberean ()
Ответ на: комментарий от DNA_Seq

> а слабо абстрагироваться от конкретной архитектуры?

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

siberean ()
Ответ на: комментарий от DNA_Seq

Да, по поводу софтверных генераторов ещё идеи. Я б наверное начал наблюдать эволюцию какого-нибудь Double pendulum во времени, где аналитически уже доказана хаотичность, и считал бы интеграл движения каким-нибудь методом Симпсона или Рунге-Кутта. Может даже эффективно получится.
Или наоборот - какой-нибудь фрактал, или тот хаотичный Вольфрамовский клеточный автомат и зачитывать значение цвета пикселя (ячейки экранной памяти). Вольфрам уверен, что 30 правило - настоящий рандомальный генератор. Судя по простоте правила - должно быть вычислительно-эффективным.

siberean ()
Ответ на: комментарий от siberean

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

Существование зависимости p(i) принадлежит P, где i принадлежит N, никак не влияет на случайность распределения простых чисел в множестве натуральных. Т.е. «какой-то закон» есть, но он не аналитический :) А теоретико-числовой.

quasimoto ★★★★ ()

> под смех зала даже запуталась в своих же концепциях.

Ричард Гэбриел неожиданно сравнивает нынешнюю ситуацию с ООП с провалом эфиродинамики в физике начала 20 века, когда, в сущности, произошла “тихая революция”.

Только мне кажется, что зал смеялся с лисперов?

kyz ()
Ответ на: комментарий от quasimoto

>В смысле - можно ли в CL иметь внутри пакета символ который ну никак недоступен извне?
В принципе, можно.
Через gensym и немного извращений.

Love5an ()
Ответ на: комментарий от siberean

>Выскажусь пожалуй. Я быдлокодю почти 20 лет.

Ээээ... А просто кодишь сколько лет?

А всё Минский со своими фреймами в 74ом[далее длинный и непонятный текст]

Я вижу ты профессиональный писатель отчетов для заказчиков и начальства.

Нельзя ли отдельные мысли выразить в виде более доступном для пролетариев.

Эффективное же и красивое решение может (по моему опыту) быть сделано только снизу-вверх

ИМХО неважно сверху-вниз или снизу-вверх. Главное вовремя делать рефакторинг. Не надо забывать что есть проблема «изменившихся требований» или «изменившегося масштаба». Ну это когда выяснилось, что писали программу которая делает одно, а теперь надо чтобы она делала немного другое. От этого никакой «снизу-вверх» не спасет. Единственный нормальный подход к разработке софта это «эволюционный».

pathfinder ★★★ ()
Ответ на: комментарий от pathfinder

Так посыл стартового поста топика и заключается в том что «если вам приходится делать рефакторинг то писали вы с самого начала неправильно»

DNA_Seq ★★☆☆☆ ()
Ответ на: комментарий от quasimoto

Это уже проблема компилятора. Еще чуть-чуть и изобретем неявное преобразование типов и динамическую типизацию =))) И вообще на приведенных тобой графиках Перл и Руби отстают серьезно только в числодробилках а на обработке текста могут быть и быстрее чем Си

DNA_Seq ★★☆☆☆ ()
Ответ на: комментарий от siberean

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

DNA_Seq ★★☆☆☆ ()
Ответ на: комментарий от DNA_Seq

Кстати, знатокам Си/С++, объясните дураку, одну штуку я до сих пор понять не могу. Нафига заголовки писать в отдельном файле? Вроде уже оперативки на компах немного поболее чем 64 килобайта

DNA_Seq ★★☆☆☆ ()
Ответ на: комментарий от pathfinder

>> Выскажусь пожалуй. Я быдлокодю почти 20 лет.

Ээээ... А просто кодишь сколько лет?

За 20 лет вырабатывается слегка ироничное отношение к себе и работе :)

Нельзя ли отдельные мысли выразить в виде более доступном для пролетариев.

Из-за Мински и прочих развитие технологий программирования пошло в сторону махровых эвристик (aka ООП), вместо развития математически обоснованных методов.

Эффективное же и красивое решение может (по моему опыту) быть сделано только снизу-вверх

ИМХО неважно сверху-вниз или снизу-вверх. Главное вовремя делать рефакторинг.

Все эти «рефакторинги» и «agile development» - это старая добрая итеративная разработка. И, конечно, она нужна.

tailgunner ★★★★★ ()
Ответ на: комментарий от Love5an

>> В смысле - можно ли в CL иметь внутри пакета символ который ну никак недоступен извне?

В принципе, можно. Через gensym и немного извращений.

а лексические замыкания, не?

korvin_ ★★★★★ ()

> template<class T> T min(T,T)

(T,T)

Это что-то анимешное?

SSZB ()
Ответ на: комментарий от pathfinder

> Ээээ... А просто кодишь сколько лет?

20 лет, не считая васика и фортрана в универе на физике в конце 80х. С си столнкнулся в 90м, где надо было интерфейс с томографом делать. Быдлокодю на жабе - с 95го (версии 1.0), на SQLe - с 97го. До этого - си, пару проектов на плюсах (до темплейтов), паскаль немного, но всё забыл. В универе в начале 90х было много языков, включая аду (83, не ОО, так как было до 95), ассемблеры, прологи, немного лисп.

Я вижу ты профессиональный писатель отчетов для заказчиков и начальства.

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

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

Это маркетологи навязали вирусную и неправильную идею, что первоначальные этапы - это базис.
Это мне напоминает ситуацию - если бы говорили что первоначальные этапы жизни ребёнка - это базис. И если он в 3 года сказал что хочет быть принцессой/пожарником - то это уже финально, нужно купить форму пожарника навырост итд, и ничего не будет меняться. Типа всё, решение сделано, пройдена ступень определения специальности. Фундамент же уже построен!
Или напоминает художника, который сделав вначале несколько пробных мазков - потом любой свой замысел будет приспосабливать под эти старые мазки - кляксы. И легко ли будет такому художнику сотворить шедевр?
Нет, пока даже такие компании как гугл, яху, фейсбук - меняют свои интерфейсы, экспериментируют, а мы тестируем и не знаем - подойдёт ли скорость для нашего проекта - ни о каких обязательствах и дедлайнах не может быть речи. Это всё большой ресёрч как в универе, типа: «понедельник: пришёл, думал. Вторник: обдумывал эксперимент. ... Пятница: эксперимент не удался.» И никакого давления что мол дедлайн.

siberean ()
Ответ на: комментарий от DNA_Seq

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

сорри, Double pendulum - линейка болтающаяся на гвоздике на другой, подвешенной на гвоздике линейке.
http://en.wikipedia.org/wiki/Double_pendulum
При достаточной начальной энергии - поведение конца - абсолютно хаотично. Т.е. наблюдая точки пересечения с окружностью - мог бы, думаю, получиться рандомальный генератор.
Уравнение (интеграл) движения можно посчитать итеративно, неаналитически, довольно быстро (метод Рунге-Кутты). Наблюдать - когда точки пересекают огибающюю окружность.

siberean ()
Ответ на: комментарий от DNA_Seq

> Кстати, знатокам Си/С++, объясните дураку, одну штуку я до сих пор понять не могу. Нафига заголовки писать в отдельном файле? Вроде уже оперативки на компах немного поболее чем 64 килобайта

для удобства же.
Когда один файл - никто не мешает декларации писать в том же файле. А когда более одного файла в программе - это же удобно иметь в отдельном файле только декларации (ну и макросы, константы), интерфейс какбэ.

siberean ()
Ответ на: комментарий от pathfinder

> Нельзя ли отдельные мысли выразить в виде более доступном для пролетариев.

Минский ввёл понятие/структуру фрейма для задач искусственного интеллекта. Фреймы - это слоты для данных, типа массива. Так-же есть специальные слоты для поведения, скриптов, приаттаченные функции, работающие над этой локальной датой. Этакая вложенная структура, дерево. Все заразились типа, и классы в ООП повторяют фреймы, а методы - те скрипты. И Вирт тоже говорил о структурах вначале, вещизм какой-то.
Проблема в том - что локальные методы могут эффективно работать только с локальной датой, но должен существовать (самое главное!) глобальные алгорит, который свяжет поведение всей системы. да ещё эффективно. Из-за этого второстепенной роли функций (когда на самом деле алгоритм - первостепенен) в ООП, которому обычно учат, - люди начинают с объектов и имеют гигантское количество неэффективных вызовов отдельных методов из-за первоначального неправильного разделения на объекты. Хотя, может гораздо более эффективно задачу решить начав с алгоритма, с одной функции и оперировать пайплайнами (передавать контекст «по трубе»), либо иметь _императивный_ цикл игры и «надевать» функциональность по мере надобности, или думать алгеброй предикатов (как в sql или прологе). Т.е. не структуры главное, а таки алгоритм.
Первоначальный выбор объектов, базиса до осознания всей задачи - не может быть сделан эффективно.

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

siberean ()
Ответ на: комментарий от siberean

> Минский ввёл понятие/структуру фрейма для задач искусственного интеллекта. [...] Все заразились типа, и классы в ООП повторяют фреймы

Вообще-то нет. Насколько я помню, фреймы появились в середине 70-х, а Симула67 - в 1967 :) так что Мински виновен, конечно, но не он это начал. Всё пошло из задач имитационного моделирования.

И Вирт тоже говорил о структурах вначале, вещизм какой-то.

«Show me your flowcharts, and I'll continue to be mystified; show me your tables, and I won't need your flowcharts» Брукс

:)

Вот у меня есть книги по численным вычислениям. Там ни одного класса. Каждый алгоритм элегантно выражен в виде процедуры.

Численные методы такие численные.

tailgunner ★★★★★ ()
Ответ на: комментарий от siberean

На самом деле, я выступаю не против ООП, а против перекоса в сторону объектов и структур.
(я, зачастую, часто на жабе пишу как на си, как минимум вначале проекта. И часто это более красиво и компактно. А наследование вообще жуткая для поддержания вещь: всегда можно обойтись делегацией и контейнментом. Пуристы ООП идут лесом. Главный показатель для меня - простота кода).

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

anonymous ()
Ответ на: комментарий от tailgunner

> Численные методы такие численные.

Дык с чем работаем - с числами же!

посмотрите на любой алгоритм в Кормэне - ему нужны объекты? (Студентам нужен код, где будет одна фунция, а не тучи вызовов геттеров/сеттеров и создания ненужных сущностей). Или любое описание какой нибудь чисто CS функции: хэша, например http://en.wikipedia.org/wiki/MD5. Функция или оператор - это главное. А данные - хоть в массивах. Главное - поведение, потому что мы программируем _поведение_, а не составляем отчёты, где может и важно плодить сущности.

anonymous ()

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

alphex_kaanoken ★★★ ()
Ответ на: комментарий от anonymous

> не тучи вызовов геттеров/сеттеров и создания ненужных сущностей

Геттеры с сеттерами не нужны. Ненужные сущности... ээ.. тоже не нужны %)

Функция или оператор - это главное. А данные - хоть в массивах.

Ну а теперь скажи, какова область определения функции :) Ну и область значений тоже.

Главное - поведение, потому что мы программируем _поведение_

Прикинь, ООП-пропаганда тоже говорит о том, что они программируют поведение %)

tailgunner ★★★★★ ()

да, ещё такой аргумент.

Чем абсолютна математика? Тем, что она абстрактна вне зависимости от объектов, которыми она оперирует. В другой галактике будет другая политика, другая философия, так как и история и объекты будут совершенно другими. Но будет та же математика, потому что она - об операциях и оперирует абстрактными переменными, в виде которых может выступать любой объект. Т.е. математика работает с отношениями объектов, а не объектами (конкретным окружением). Т.е. она функциональна, а прикладная - процедуральна, и никак не ОО.

Базис объектов может быть выбран бесконечным числом раз, это зависит от ассоциаций программиста. А функция - имеет единственную наиболее компактную форму записи http://en.wikipedia.org/wiki/Kolmogorov_complexity, и можно показать, что разбиение на объекты (даже если брать ООП) будет единственным для того минимума (самое компактное), а скорее всего - с объектами будет длиннее и менее наглядно чем со структурами.

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

anonymous ()
Ответ на: комментарий от tailgunner

> Ну а теперь скажи, какова область определения функции :) Ну и область значений тоже.

сорри, что не сказал сразу (я уже подумал - что не будет понятно). Конечно я не гружу бизнес-аналитиков понятиями домейна^Wобласти определения, области значения.

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

anonymous ()
Ответ на: комментарий от tailgunner

> Прикинь, ООП-пропаганда тоже говорит о том, что они программируют поведение %)

дык это же как религия.

Любой пастор вам скажет: у нас та добродетель, о которой вы говорите тоже есть, всё чик-чак.

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

anonymous ()
Ответ на: комментарий от siberean

>> Я вижу ты профессиональный писатель отчетов для заказчиков и начальства.

и где ты это видишь?

В реальности - как раз наоборот. Отчёты писать никогда не умел и не хотел из-за их бессмысленности

Признаю что был не прав. Просто ты так непонятно выразился. Вот я и подумал что это обычная пудра для мозгов.

pathfinder ★★★ ()
Ответ на: комментарий от siberean

>рефакторинг не так просто делать в си или ассемблере - как в жабе (в каком-нибудь эклипсе).

А почему сишный код рефакторить тяжело? Может мы по разному смысл слова «рефактринг»? Для меня это просто переделка кода с целью перейти от мене удачных архитектурных решений к более удачным. Необязательно для этого пользоваться какими-то возможностями IDE или языка.

На С++ я часто что-то переделываю у себя в коде. На С это так же легко делать.

По поводу «сверху вниз».

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

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

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

pathfinder ★★★ ()
Ответ на: комментарий от pathfinder

Я имею в виду ситуацию - когда сотни файлов. И то когда это жаба написана по жабски, со всеми private, геттерами итд. Жабу очень легко рефакторить благодаря поддержке IDE. сишный даже тот-же эклипс (CDE, когда я делал последний проект на нём) не имел рефакторинга, не говоря про поиски/замещения по файлам в vi. Т.е. приходилось смотреть на ошибки и последовательно перекомпилировать. При больших переделках - как бы немного больший головняк, чем для жабы. Хотя да, и там и там надо иметь и запускать юнит тесты и это облегчит. Я не говорю про ассемблер (на котором не писал 15 лет). Там просто переписывать придётся. Типа ниже уровень - больше артифактов менять при рефакторинге.

разве подход к разработке «сверху-вниз» требует, чтобы обязательно к пройденным этапам никогда не возвращались и нельзя было переосмыслять архитектурные решения, сделанные на раннем этапе разработки?

а зачем он нужен вообще - если его всё равно надо переделывать? Это же себе на голову такая лишняя сущность.

Всё равно я на каждом этапе хочу иметь работоспособную систему, начиная с пустого main, потом юнит тестов, и кончая сотнями файлов. Я расширяю тот main как фрактал. Зачем мне надо планировать, кроме как прикидка в голове - как всё примерно будет устроено, какие фреймвоки будут использованы? Под сверху-вниз обычно пнимают «распилочные» тяжёлые методологии типа SDLC, waterfall, где дизайн каким-то образом делается вперёд имплементации и даже пилота.

anonymous ()
Ответ на: комментарий от siberean

>Проблема в том - что локальные методы могут эффективно работать только с локальной датой

ЩИТО?

люди начинают с объектов и имеют гигантское количество неэффективных вызовов отдельных методов из-за первоначального неправильного разделения на объекты

Первоначальный выбор объектов, базиса до осознания всей задачи - не может быть сделан эффективно.

Пускай переделают. В чем проблема? Это нормальное явление. Надо уметь постепенно приводить код в порядок по мере осознания всех деталей задачи.

Вот у меня есть книги по численным вычислениям. Там ни одного класса. Каждый алгоритм элегантно выражен в виде процедуры.

ВОПРОС: О чем это говорит?

ОТВЕТ: Ни о чем.

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

Открою большой секрет. ООП ничему не учит. ИМХО называть ООП парадигмой слишком громкое заявление. По сути ООП позволяет удобно структурировать код. И это главная его задача с которой он хорошо справляется. Конечно у него есть другие полезные вещи, но это качество главное.

pathfinder ★★★ ()
Ответ на: комментарий от anonymous

>а зачем он нужен вообще - если его всё равно надо переделывать? Это же себе на голову такая лишняя сущность.

Можно сделать почти пустой каркас для того, чтобы просто оценить как это будет выглядеть «в целом». А то когда решаешь локальную задачу то «за деревьями не видно леса».

pathfinder ★★★ ()
Ответ на: комментарий от pathfinder

надо двигаться от простого к сложному, на каждом этапе имея работоспособную систему (Agile девелопмент, в пределе - экстремальное программирование). В каждую минуту можно тчитаться перед заказчиком, показать ему систему, дать потыркать, спросить: то-ли что ему нужно. Никаких рисков. Поддержание юнит тестов параллельно. Так и растём и вырастаем в большую систему. А начиная с архитекторских программ - получаем жуткую сложность уже вначале, когда ещё алгоритм не работает, и данные не реальные. Такие архитекты обычно линяют в мэнеджмент или нанимают кодеров, и те разгребают всё дерьмо. О, этого я накушался за 15 лет контрактов в больших конторах. Технологии ради технологий - вот почему всё сейчас в такой заднице и сложно.

anonymous ()
Ответ на: комментарий от anonymous

>надо двигаться от простого к сложному, на каждом этапе имея работоспособную систему

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

pathfinder ★★★ ()
Ответ на: комментарий от pathfinder

> >Проблема в том - что локальные методы могут эффективно работать только с локальной датой

ЩИТО?

_эффективно_

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

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

создаётся впечатление - что наследование, полиморфизм, энкапсуляция, а также EJB, xml, фреймвоки, MVC, ОРМы - это панацея, серебрянная пуля, хотя это всё совсем не о программировании и не о числах.

MVC они пихают всюду, где надо или не надо (это религия), а деньги хранят в IEEE754. Лучше бы последнему учили и алгебре, ей богу.

anonymous ()
Ответ на: комментарий от pathfinder

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

значит мы говорим об одном и том-же. Твой каркас с заглушками - это «снизу-вверх», с начала (Agile). «сверху-вниз» - это то чему учат на курсах и даже в университетах (SDLC), я сам даже учил. Это когда год люди не имеют работающую систему, и занимаются дизайном, а потом за 3 месяца перед релизом - надо сделать систему из их нерабтающего дерьма. Потом появляются «неожиданные» проблемы с перформансом и concurrency, на многих процессорах, при реальной нагрузке. Потом всё локают и получают мегатормоза. Плавали, знаем. Это всё SDLC, «сверху-вниз».

anonymous ()
Ответ на: комментарий от anonymous

>> Ну а теперь скажи, какова область определения функции :) Ну и область значений тоже.

сорри, что не сказал сразу (я уже подумал - что не будет понятно).

Было вполне понятно.

Конечно я не гружу бизнес-аналитиков понятиями домейна^Wобласти определения, области значения.

Я не бизнес-аналитик.

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

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

tailgunner ★★★★★ ()
Ответ на: комментарий от anonymous

>из общения с ООП программистами - я понял что сегодняшнее преподавание ООП скорее калечит. (я учился когда ООП не было)

Ничего не могу сказать о современном преподавании ООП, как впрочем о преподавании ООП в ВУЗах вообще.

Меня программированию никто не учил. Все знания которыми я обладаю получены из книг/мануалов/статей в интернете/от других людей. Могу с уверенностью сказать что во многих книгах про ООП написано нормально. Придраться особо не к чему.

Зато эти туманные наукообразные разговоры о абстрактных абстракциях действительно настораживают. Откуда у людей тяга говорить о простых вещах в стиле сложного матана? Может это такая то болезнь - математизация головного мозга.

pathfinder ★★★ ()
Ответ на: комментарий от tailgunner

массива, списка и ассоциативного массива - хватит для 99% задач. Где-то появится стек, LRU кэш. Это элементарные кирпичики, которые выбираются по-ходу.

Иногда выясняется, что в конце надо прикрутить сортировку. Можно как сортировать, так и индексировать при наполнении данных, всё должно быть контролируемо, если это ваш «чёрный ящик». Можно и массивами обойтись и за пару дней, если надо, реализовать и свой хэш и свой Set, и циклический список. Та же очередь - легко делается и в таблице базы и из динамического списка. Так что я против того чтобы молиться на АТД. Их тем более не надо дизайнить. Это имплементация, котрая должна легко меняться в процессе, и скорее всего она таки поменяется. Это должно быть под контролем программиста.

anonymous ()
Ответ на: комментарий от pathfinder

может мы в разных галлактиках живём. Я вот недавно на курсы вэб-сервисов сходил. До сих пор плююсь и негодую. Чуть не закидал вещателя ботинками. И эти люди учат нас программировать. А ведь один из архитекторов не скажу какой компании. С гордостью грит, что в жабе - с 2000го (до этого видимо - ни в чём).

Одни заявления о том, что «веб-сервисы стали ещё более эффективными включив для аттачментов кусков протокола MIME» и он переспросил второго лектора - так ли это произносится, заметив, что это _какой-то_ протокол.

И это при том, что я с появления вебсервисов ругаюсь и привожу в пример десятки лет существующий MIME, REST (существующий с начала вэба), который не в пример компактный, без новоявленных змлей - как аргумент против вебсервисов. Теперь пионеры выучили наконец MIME (не выучили , а узнали что это есть) и начали добавлять. Так же и в новой жабе - где сложность web.xml пытаются решить костылями аннотаций. А как мы спорили против web.xml в конце 90х! Когда ещё был JRun, Jserv. Теперь люди, пришедшие в программирование уже на костыли, сделанные предыдущими пионерами - делают «открытие» и убирают web.xml, представляя это инновацией. А если бы первых пионеров не было в начале 2000х - то и проблем бы не было!

Да задлбали, так же во всём! EJB с каждой версией меняется, до них «доходит», они выучивают что-то, всем много лет известное, что-то упрощают, а другое ещё более усложняют. А ведь всегда говорили о импедансе и несовместимости реляционной алгебры с объектной моделью итд. Нет, не слушают. Хочется сказать: идите в школу, в универ. Выучите наконец как работает машина, выучите протоколы, си, другие языки, и перестаньте кошмарить IT. Сегодня чтобы открыть файл - народ кучей фреймвоков пользуется.

Теперь этот засранец с трибуны говорит, «да, мол, есть тормоза и недостатки но ведь уже стандард же». Поубивав бы. И стандартом уже успели протащить.

anonymous ()
Ответ на: комментарий от anonymous

ладно, не обращайте внимания. midlife crisis, наверное. Ворчу много.

anonymous ()
Ответ на: комментарий от anonymous

> массива, списка и ассоциативного массива - хватит для 99% задач.

Массивов/списков/хэшей _чего_? Элементы какого типа в них содержатся?

Так что я против того чтобы молиться на АТД. Их тем более не надо дизайнить.

Кобол и Фортран, да?

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

того, к чему будем динамически кастить, в чём проблема? Выше уже сказал, что в базе уже один тип. Либо в начале проверить тип - не проблема и если очень хочется безопасности - прверить/почистить данные. Проблема надумана. Я не понимаю, чё вы вцепились в runtime каст. Вон, сегодня вообще модна тотальная динамическая типизация, и ничего. Программы вылетают и не работают совсем по другим причинам. Можно и на си и ассемблере надёжные программы писать, а на бейсиках - иметь бесконечные лупы через сеть и заморозку экрана из-за какой-нибудь херни. Есть юнит тесты потом.

Кобол и Фортран, да?

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

anonymous ()
Ответ на: комментарий от tailgunner

>Массивов/списков/хэшей _чего_? Элементы какого типа в них содержатся?

Пофиг. man perl

DNA_Seq ★★☆☆☆ ()
Ответ на: комментарий от anonymous

другими словами - в абстрактном хеше - void * или Object. Реально же будет передано то - к чему и будет кастится.

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

> того, к чему будем динамически кастить,

ну так к чему ты будешь кастить?

в чём проблема?

Как минимум. в динамической типизации.

Проблема надумана.

Какая проблема? Я пытаюсь выяснить, что является областью определения.

Я не понимаю, чё вы вцепились в runtime каст

Я о нем только что прочитал.

tailgunner ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.