про ООП

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

> типа ради принт хелло ворлд в десятке пограмм надо написать пару классов и т.п. и т.д. и это в перле...

зачем городить иерархию классов ради хеловорда? :) для каждой задачи нужно выбирать соотв. инструментарий. такое мое мнение.

> его ограничения на свободу действия

Они чуствуются когда ты применяеш его нетуда. Как пример, дорога будет "ограничивать" тебя если ведёт не туда, куда те нужно.

> типа ради принт хелло ворлд в десятке пограмм надо написать пару классов и т.п. и т.д. и это в перле... не говорю уж о Сях++

Посмотри ucw например. Там с использованием _готового_ фреймворка нужно намного менше действий для написания уеб как хеловорд так и большой аапликухи, нежели без оного.

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

helloworld на классах так же безумен, как программа под миллион строк в одну функцию.

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

Зачем делить и так обозримый кусок кода a la helloworld - непонятно.

Вобщем почитай что-нить про психологию (7+-2 всякие).

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

> Там с использованием _готового_ фреймворка нужно намного менше действий для написания уеб как хеловорд так и большой аапликухи, нежели без оного

ну тут яб скорее согласился...

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

Ну так и я не в лоб. До какого-то момента можно делать одним куском.

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

Свобода в программе на миллион строк - это хаос.

> это компенсируется хоть какой-то обозримостью и управляемостью.

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

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

ООП - это инструмент. Знаешь инструмент хорошо - используешь его хорошо. Знаешь инструмент плохо - используешь его плохи. Не знаешь - не используешь. Или используешь через зад. От названия инструмента это зависит мало.

> ООП оно в москах.

О чём это?

> ООП - это инструмент. Знаешь инструмент хорошо - используешь его хорошо. Знаешь инструмент плохо - используешь его плохи. Не знаешь - не используешь. Или используешь через зад. От названия инструмента это зависит мало.

Бугога!

> О чём это?

О москах

ООП - это не инструмент, это концепция. На C можно в ООП стиле, как это сделано в GTK.

> ООП - это не инструмент, это концепция. На C можно в ООП стиле, как это сделано в GTK.

В программировании концепции - это и есть инструменты, если это концепции организации программы. Что ООП, что accumulator passing style, что дорогие сердцу любого хаскеллиста монады - это инструменты, с помощбю которых можно решать те или иные задачи, относящиеся к предметной области. И для разных задач лучше подходят разные инструменты, ООП же, пожалуй, наиболее универсальный из существующих.

А автор темы, судя по всему, совершенно не умеет программировать. Ни на перле, ни вообще.

> А автор темы, судя по всему, совершенно не умеет программировать. Ни на перле, ни вообще.

долго я этого ждал однако =)

загвоздка в том, что у каждого метод свой, вот и был задан вопрос, а зачем?

http://c2.com/cgi/wiki?YouJustDontGetIt

http://c2.com/cgi/wiki?BondageAndDisciplineLanguage

> в самом ООП не понравились его ограничения на свободу действия. типа ради принт хелло ворлд в десятке пограмм надо написать пару классов и т.п. и т.д. и это в перле...

по дорогам ты тоже поперек ездишь?

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

ООП - один из самых плохих способов борьбы со сложностью.

>А потом приходится делить. При этом появляется overhead за счёт затрат на всякие ООП, но это компенсируется хоть какой-то обозримостью и управляемостью.

Именно это сейчас я на своей шкуре и испытываю, хотя и до этого проект был достаточно неплохо поделен на модули. Но заметил, что дальше двигаться вперед становится слишком сложно. Сейчас разбиваю в _жестком_ оо-стиле. Не смотря на то, что производительность критична, я все же C->C++, ибо

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

важнее.

>ООП оно в москах.

Согласен, но, думаю, ты понимаешь различия c-ооп и c++-ооп.

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