Еда из Карнеги-Меллоуна: у первокурсников ООП-капец

>Нет.

Лаконичный ответ ;)

>А в чем, по-твоему, там должна быть проблема?
Ну есть набор из 20 видов виджетов, у каждого из которого есть 30 функций для изменения состояния. Плюс есть еще свои структуры, для которых характерны свои наборы функций.
Как это связать так, чтобы не было дублирования кода и без сотен глобальных переменных.

А без примера другой ответ и невозможен.

Кстати, все так заспорились, что не обратили внимание :)

>с этой осени первокурсникам больше не будут читать курс объектно-ориентированного программирования

>А без примера другой ответ и невозможен.

А какой пример нужен? Вопрос элементарный. Есть некая структура А и нужно написать структуру Б, которая должна быть расширенной версией структуры А. Какие тут есть варианты?

1. Переписать отлаженный код;

2. Продублировать часть кода (и, потенциально, багов) в структуру Б;

3. Отразить в структуре Б только недостающие элементы и дальше работать с этим разложившимися фракциями :)

4.....

5. В чем профит?

СУБДшники обычно так и мучаются))

> > > Зачем цепляешься к языкам? Так, потроллить что-ли?

А догадайся. Можешь даже подумать, если умеешь.

К чему этот хамски-надменный пост? Неужели это действительно всё ради троллинга?

сделать в структуре Б поле «указатель на А»

сделать в структуре Б первым полем структуру А

Оба решения лучше, чем дублирование кода. Сама проблема не имеет никакого отношения к «отсуствию ограничения доступа к объектам», что бы не называлось этими словами.

Зачем цепляешься к языкам? Так, потроллить что-ли?

А догадайся. Можешь даже подумать, если умеешь.

К чему этот хамски-надменный пост?

Хорошо, отвечу прямо: твой вопрос глуп. Я не цеплялся к языкам.

Неужели это действительно всё ради троллинга?

Подумай и составь свое мнение.

>Оба решения лучше, чем дублирование кода.

Это лучше, чем 1-2 и мало отличается от варианта 3.

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

Во-втором случае, внутри Б всё равно придется реализовывать функции для работы с А. С таким же успехом можно написать и внешнюю функцию для работы с обеими структурами.

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

Я тожь не умный, но ФП парадигма предполагает, что абсолютно все операции суть математические и могут быть упрощены как уровнения, т.е. мыслить объектами - примитив для индусов (ага одел каску). Т.е. в результате работы ФП программиста из 10к строк абстракций получается 1к строк математическая модель которая работает оптимальней. Но тут есть большое, не, охеренно большое НО «настоящих функциональных программеров единицы и они настолько умны что аж дурные» и их работа и по временным и по стоимостным затратам практически неоправданна.

первокурсникам

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

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

>ФП парадигма предполагает, что абсолютно все операции суть математические и могут быть упрощены как уровнения, т.е. мыслить объектами - примитив для индусов (ага одел каску)

Тогда уж сразу надо ассемблер учить.

>Т.е. в результате работы ФП программиста из 10к строк абстракций получается 1к строк математическая модель которая работает оптимальней.

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

>Но тут есть большое, не, охеренно большое НО «настоящих функциональных программеров единицы и они настолько умны что аж дурные» и их работа и по временным и по стоимостным затратам практически неоправданна.

Ревнители чистоты языка часто нападают на С++. Они полагают, что высшее достижение современной цивилизации — язык, построенный исключительно из атомов и скобок. По мнению этих террористов от синтаксиса, если простую переменную с первого взгляда невозможно отличить от вызова функции или макроса — это вообще не язык, а шарлатанство для развлечения праздной толпы. К сожалению, теория расходится с практикой. В реальной жизни толпа платит лишь за то, чтобы видеть языки, в которых разные идеи выглядят по-разному. «Простые и последовательные» языки никогда не пользовались особым успехом за стенками академий, а языки с блочной структурой овладели массами. Стоит ли этому удивляться? Ведь компьютерные языки приходится изучать и запоминать, а для этого используется то же серое вещество, с помощью которого мы изучаем и запоминаем естественные языки. Попробуйте-ка назвать хотя бы один естественный язык без существительных, глаголов и скобок! Я бы не рискнул. Все наши познания в лингвистике говорят о том, что эти «плохие» особенности только ускоряют изучение компьютерного языка и делают его более понятным. i++ во всех отношениях действительно понятнее, чем i:=i+1, а x=17+29 читается лучше, нежели (setq x(+17, 29)). Речь идет не о строении компьютерного языка, а скорее о нашем собственном строении. Все уродства С++ — это в основном наши уродства. Когда вы научитесь понимать и любить его странности, когда перестанете беспокоиться о математической стройности, будет сделан ваш первый шаг к достижению элегантности в С++.

(c) Элджер

>классическое (smalltalk, ruby, python, io) или прототипное (js, lua, self)?

Io емнип тоже прототипный

>Вот и дожил я до времени, когда C++ кодеров в открытую быдлом стали называть. *Скупая мужская слеза скатилась по неблитой щеке*

На С++ пишут и гении, и идиоты. Вторых, к сожалению, много больше

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

Ты говорил о дублировании кода - никто в своем уме не будет его дублировать. Про «небезопасность» - смешно.

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

Для логики ООП избыточно. Классическое структурное программирование тут рулит и педалит.

>Для логики ООП избыточно. Классическое структурное программирование тут рулит и педалит.

Орли

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

Херовый же у вас однако универ был

А чего удивительного? Единственная область где ООП незаменимо это визуальное программирование причем во всех смыслах. Без Visual Studio и Delphi ООП бы вообще никому нафиг не упало. А так красота - перетащил мышкой формочку, перетащил кнопочку, кликнул на объекте.. прелесть!

Кстати, для логики веб-приложений возможно хорошо бы подошел Пролог

Единственная область где ООП незаменимо это визуальное программирование причем во всех смыслах. Без Visual Studio и Delphi ООП бы вообще никому нафиг не упало. А так красота - перетащил мышкой формочку, перетащил кнопочку, кликнул на объекте.. прелесть!

от ООП там, как правило, одно название, точно такое же процедурное программированное, только засунутое в один класс-обёртку, но многие «мышевозниче» и вовсе над этим не задумываются

//Вы пытаетесь сравнивать язык программирования и среду разработки - Вам надо быть внимательнее

Кстати, для логики веб-приложений возможно хорошо бы подошел Пролог

Erlang?

ООП есть в ядре (file_operations, VFS и иже с ними) и его использование там вполне оправдано

Эрланг функциональный а Пролог - язык логического программирования, фактически скрещивание любого языка с sql-базой это имитация логического программирования на коленке

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

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

И это очень проблематично упросить

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

Тогда уж сразу надо ассемблер учить.

Я вообще не к этому.

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

Цитата применима только к новомодному экстремальному программированию (точнее эксрементальном бракгромированию). Во всех остальных случаях при её применимости пора одевать парадный мундир и идти делать самострел.

[quote]Ревнители чистоты языка часто нападают на ФЯП. Они полагают, что высшее достижение современной цивилизации — язык, построенный исключительно из объектов. По мнению этих террористов от синтаксиса, если простую переменную с первого взгляда можно отличить от вызова функции или макроса — это вообще не язык, а шарлатанство для развлечения праздной толпы. К сожалению, теория расходится с практикой. В реальной жизни толпа платит лишь за то, чтобы видеть языки, в которых разные идеи выглядят по-разному. «Простые и последовательные» языки всегда пользовались особым успехом за стенками академий, а языки с блочной структурой овладели чем попало. Стоит ли этому удивляться? Ведь компьютерные языки приходится изучать и запоминать, а для этого используется то же серое вещество, с помощью которого мы изучаем и запоминаем естественные языки. Попробуйте-ка назвать хотя бы один естественный язык без скобок! Я бы не рискнул. Все наши познания в лингвистике говорят о том, что эти «плохие» особенности только ускоряют изучение компьютерного языка и делают его более понятным. i++ во всех отношениях действительно непонятнее, чем i:=i+1, а x=17+29 читается хуже, нежели (setq x(+17, 29)). Речь идет не о строении компьютерного языка, а скорее о нашем собственном строении. Все уродства ФЯП — это в основном наши уродства. Когда вы научитесь понимать и любить его странности, когда начнёте беспокоиться о математической стройности, будет сделан ваш первый шаг к достижению элегантности в ФЯП.[/quote]

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

Цитата применима только к новомодному экстремальному программированию (точнее эксрементальном бракгромированию).

Цитата появилась в 1974 году, когда об экстремальном программировании не слышал и не думал никто. Если у тебя программа работает еще неправильно, но у тебя свербит, чтобы она _не_ работала быстро, в консерватории надо что-то менять.

фактически скрещивание любого языка с sql-базой это имитация логического программирования на коленке

это сильное утверждение, но не думаю что корректное - какие Ваши аргументы?

новомодному экстремальному программированию (точнее эксрементальном бракгромированию)

отчего такой баттхёрт, не осилили вполне себе простые и логичные подходы или пытались микроскоп применять к гвоздям?

> не осилили вполне себе простые и логичные подходы

Не баттхёрт, а неприязнь.

или пытались микроскоп применять к гвоздям?

И не пытался. Часто видел к чему это приводит. Могу обосновать ненужность как с точки зрения разработчика так и с организациоонной точки зрения.

Могу обосновать ненужность как с точки зрения разработчика так и с организациоонной точки зрения.

please proceed

>какие Ваши аргументы?

http://ru.wikipedia.org/wiki/Web_Ontology_Language

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

>какие Ваши аргументы?

http://ru.wikipedia.org/wiki/Web_Ontology_Language

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

не, про логическое программирование я понял, я не понял как это обосновывает:

фактически скрещивание любого языка с sql-базой это имитация логического программирования на коленке

также непонятно что значит скрещивание языка с базой - PL/SQL, TransactSQL?

С точки зрения разработки: 1. Нацеленность на результат «чтобы работало», минует этап комплексной проектировки и в 90% случаев получается «эльфийский код» к реальной эксплуатации не имеющий никакого отношения.

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

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

С организационной точки зрения: 1. Работа с клиентом «нагорячую» приводит к порочной практике «сайт всего из трёх страниц, блог,форум и веб-магазин».

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

3. Исходя из 2 пункта предыдущего мнения, обезьяны съедают большее время проекта и исчёрпывают кредит доверия клиента и для спасения тонущих проектов приходится привлекать весьма нетривиальных и дорогостоящих специалистов способных заканчивать проекты, а не ссаться кипятком от парадигм и подходов.

ЗЫ: Только, прошу тебя, если ты хочешь сказать, что «не те программисты попались», просто скажи что ты со мной не согласен. Не хотелось бы в сотый раз вступать в полемику о «тех программистах», вероятность существования которых вроде ненулевая, но их никто никогда не видел.

>не, про логическое программирование я понял, я не понял как это обосновывает:

Логическое программирование сводится к запросам и ответам от базы, фактически этим логика веб-сайтов и занимается

Т.е. в результате работы ФП программиста из 10к строк абстракций получается 1к строк математическая модель которая работает оптимальней.

Скорее миф, чем правда. Получается не математическая модель в широком смысле этого слова. Только такая модель, где главными концептуальными компонентами являются математические функции. С точки зрения моделирования это ничуть не лучше процедурного прогарммирования. Уменьшением 10к в 1к строк и не пахнет. Процедурное программирование так же предоставляет возможности по моделированию математическими функциями.

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

1. Нацеленность на результат «чтобы работало», минует этап комплексной проектировки и в 90% случаев получается «эльфийский код» к реальной эксплуатации не имеющий никакого отношения.

хехе, узнаю old school style :)

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

теоретические требования - это представления руководителей проекта о представлениях заказчика о том чего он хочет :)

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

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

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

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

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

стоп, Вы показали клиенту промежуточный результат (!), если он его устраивает - нафига Вам дополнительный рефакторинг и оптимизация, с какой целью?

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

не пойму к чему тут подход к проектированию?

ЗЫ: Только, прошу тебя, если ты хочешь сказать, что «не те программисты попались», просто скажи что ты со мной не согласен.

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

Логическое программирование сводится к запросам и ответам от базы,

4.2

> У кого-то ЯП, у кого-то используемая ОС, у кого-то сексуальная ориентация, хехе.

а у кого то длинна 8====> на любимом форуме

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

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

> А тут сразу идет облом в виде незнания основ ООП. Да и крупные конторки ООП любят.

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

Как пример см. видео-лекцию lecture-5b из sicp.

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

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

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

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

Гибкие методлологии не могут быть применены с бухты барахты.

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

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

1. естественно нужен контролируемый процесс, а то, если обеспечить заказчику соответствующую возможность, рефакторинг будет каждые полчаса, или ещё чаще :)

2. не только получение фидбека есть цель, но также оценка скорости продвижения команды в реализации фич, попытка нащупать подводные камни и т.д.

> (уж не знаю какой смысл Вы вкладываете в этот термин, но возьмём классическую проработку архитектуры - до последнего гвоздя)

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

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

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

стоп, Вы показали клиенту промежуточный результат (!), если он его устраивает - нафига Вам дополнительный рефакторинг и оптимизация, с какой целью?

Чтобы после демонстрационного показа на тему «Вы наверно это хотели?», надо ещё и двигаться к следующему этапу, но без общего планирования, велика вероятность (точнее почти постоянно) выясняется что результат достигнут быстро, но на фундамент уже отдели крышу, т.е. следующий этап делать труднее.

не пойму к чему тут подход к проектированию?

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

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

Целиком и полностью согласен.