Игорь Савчук подготовил заметку (http://blogerator.ru/page/oop_why-objects-have-failed), резюмирующую основные доводы противников объектно-ориентированного программирования. Статья написана на основе публикации Ричарда Гэбриела и родившихся после ее выхода обсуждений, в которых приняли участие целый ряд известных программистов, от редакции американского журнала Др.Добс, до таких ученых как Энди Танненбаум.URL: http://blogerator.ru/page/oop_why-objects-have-failed
Новость: http://www.opennet.ru/opennews/art.shtml?num=28148
Больше похоже на вопрос веры. Старики больше верят в процедурное программирование, а кто помоложе - в ООП.
Хороше ведь, что есть разные парадигмы.
ООП провалилось по одной единственной причине:
отсутствия в своей парадигме, в качестве ОСНОВНОЙ(!),
САМОЙ ПЕРВОЙ(!) и НЕПЕРЕСТУПАЕМОЙ(!!!) такой очевидной вещи,
как ГРАМОТНЫЙ ЗАХВАТ КОНТЕКСТА!Эта часть ваще должна быть покрыта строжайшим препроцессором и тулз
просто нахер обязан посылать программиста, не расписавшего
в UML-подобной надстройке над "Хелло, мама!" суровый план пространства имен.Те кИшки, с которыми приходится иметь дело в большинстве
сырца, на 99% оказываются непригодными.
Получить доступ к "полям" "объекта" получается иух, поскольку
все к маме черта "перегружается" в самых неожиданных местах.Этой красоты (когда в переменной цена на дрова в бухте Тикси)
можно и стандартными средствами добиться, но в ООП эта ваще круто выходит :)
провалилось???
кривыми мозгами можно испортить любой концепт.
Не кривые мозги, а быстрые руки.Вот прямо сейчас роюсь в исходниках.
Придется платить аутсорсному автору, который все это наваял когда-то,
чтобы развел всю эту обфускацию, переименовав объекты и включив в имена
префиксы, определяющие контекст всех полей и ПОРЯДОК ИСПОЛНЕНИЯ методов.С DOM-моделью ХТМЛ объекта дружите?
Проблем нет? Расхождений с документированными границами контекста не имеете?
Вот основная иллюстрация дефектов ООП - ЖаваСкрипт, язви его и его доки, язви их.
мне тоже приходится разбирать много таких "шедевральных" поделий. обычно скопипейстили с небольшими корректировками, не особо понимая, что и зачем. причем, еще хуже: когда автор копипейстит свои же исходники, множа свои же собственные ошибки. завтра мне с таким творением дальше разбираться. никакой универсальности, почти никакой. тихий ужас. у меня просто волосы на спине шевелятся от мысли, если бы он писал на функциональном языке.
> мне тоже приходится разбирать много таких "шедевральных" поделий. обычно скопипейстили с небольшими корректировками, не особо понимая, что и зачем. причем, еще хуже: когда автор копипейстит свои же исходники, множа свои же собственные ошибки. завтра мне с таким творением дальше разбираться. никакой универсальности, почти никакой. тихий ужас. у меня просто волосы на спине шевелятся от мысли, если бы он писал на функциональном языке.Если бы вы хотя бы отдаленно знали, что такое функциональные языки, вам было бы известно, что на них гораздо "труднее" сделать ошибки, при условии, что вы способны переложить задачу на функциональную модель.
И вообще, если вы что-то не поняли, это еще не значит, что просто с "скопипейстили". А если даже и "скопипейстили", то как видимо источник для вас значит больше, чем смысл. А это в свою очередь означает, что без понимания смысла, вы сами способны только "копипейстить" то, что способны понять. Так же как в средние века католические фанатики "копипейстили" Аристотеля с его пониманием законов механики.
Более подробный ответ здесь http://www.opennet.ru/openforum/vsluhforumID3/71184.html#21
А вообще, если вы долго-долго изучали ООП, и вам трудно переучиваться, вам действительно лучше продолжать спокойно спать, думая, что "в Багдаде все спокойно".
спасибо, капитан очевидность!
все бы хорошо, да ни разу не попал пальцем в небо - всё мимо. такая уж твоя карма: по своим умственным ограничениям судить о других.
> спасибо, капитан очевидность!
> все бы хорошо, да ни разу не попал пальцем в небо -всё мимо. такая уж твоя карма: по своим умственным ограничениям судить о других.Я уже написал, что вы являетесь представителем тех, кто пытаются только _оценивать_ по источнику, но не способны _анализировать_ по смыслу и содержанию.
Камень падает быстрее перышка, - рассуждали последователи Аристотеля, - значит чем тело тяжелее, тем быстрее летит.
Раз с ООП получается быстрее, - рассуждают быдлокодеры, - значит оно лучше и надежнее.
Все остальные, типа, "капитаны очевидность".P.S. При всем уважении к Аристотелю и создателям ООП. Хоть они и делали ошибки, как все люди, однако умели мыслить самостоятельно. В отличии от их последователей, которые мыслить и не пытались.
>Вот основная иллюстрация дефектов ООП - ЖаваСкрипт, язви его и его доки, язви их.А он разве объектный?
Ну можно юзать и как объектный при желании :)
> Ну можно юзать и как объектный при желании :)Без желания тоже можно.
Как вы только что проделали, разместив тут комментарий.
Изучите js файло этого сайта.
DOM-объект, к свойствам которого предоставлен интерфейс средствами Жавы Скрипта, является, вообразите себе, именно ОБЪЕКТОМ. В лучших традициях ООП.jQery и ЙахуУй, вообразите себе, тоже ООП.
"Разве" давайте говорить о том, что вы знаете и не станем обсуждать вспышки вашего не обремененного образованием сознания?
По англецки "вопрос" пишется как "Query". Соответственно jQuery. ООП ни при чём, вы просто не умеете его готовить. А судя по тому что софт для вас аутсорсеры пишут, вы вообще имеете только мнение аля "бабка на лавочке сказала, что ООП ацтой"
> По англецки "вопрос" пишется как "Query". Соответственно jQuery. ООП ни при чём,
> вы просто не умеете его готовить. А судя по тому что
> софт для вас аутсорсеры пишут, вы вообще имеете только мнение аля
> "бабка на лавочке сказала, что ООП ацтой"jQuery я привожу как раз как пример хорошего и надежного пакета.
А вы самостоятельно пишете 300 человеко-часов в сутки?
Или имеете возможность платить 100-150 т.р. незагруженным людям из числа постоянного персонала? За ловлю мух и питьё кофе? Пока проект в стадии внедрения и программеры сушат ласты?Тогда вам аутсорсеры не нужны. Завидую вам.
JavaScript это язык, который позволяет "программировать через объекты", но не объектно-ориентированный. Почитайте хорошенько чем отличается объектно-ориентированный язык программирования от остальных.
> просто нахер обязан посылать программиста,
> не расписавшего в UML-подобной надстройке над "Хелло, мама!"
> суровый план пространства имен.Э-э-ээээ, типа
$ echo "Хелло, мама!"
не айс?!ООП для других масштабов!
Именно нахер.
> Именно нахер.
> http://habrahabr.ru/blogs/nix_coding/75971/Хе... :)
Каждая Труъ Юних программулина, должна иметь свой обработчик ошибок,
проверять и обрабатывать возвращаемые значения ВСЕХ используемых функций!!!
Желательно прикрутить проверку на права доступа к внешним объектам.
Выводить информацию и, или ошибки в syslog.
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <errno.h>
#include <signal.h>#include <sched.h>
#include <sys/resource.h>typedef void (*sighandler_t)(int);
sighandler_t sighdlr(int);
/* Signal handler */
sighandler_t sighdlr(int sig) {if ( sig == EINTR ) // It's just a signal, try again
return NULL;
exit(sig);
}static const char * const msg = "Hello World!\n";
int main() {
int s;
int max_prio;
size_t lenstr;
size_t remaining;
ssize_t res;
const char *begin;
const char *end;struct sched_param shd;
/* set prio */
max_prio = sched_get_priority_max(SCHED_OTHER);
shd.sched_priority = max_prio;if (sched_setscheduler(0, SCHED_OTHER, &shd) != 0)
exit(0);errno = 0;
lenstr = strlen(msg);
if (errno != 0) {
switch (errno) {
case EINVAL:
case EFAULT:
case EFBIG: /* Too big */
case EAGAIN:
default:
return (errno);
}
}/* Unbuffered out */
errno = 0;
s = setvbuf(stdout, (char *) NULL, _IOLBF, 0);
if (s != 0 || errno != 0)
return (errno);/* Run signal handler */
for (s = 1; s < (_NSIG / 2); s++) {
if (s != SIGKILL || s != SIGSTOP) {
errno = 0;
signal(s, (sighandler_t) sighdlr);
if (errno != 0 && errno == EINVAL) {
continue; /* signul is invalid */
}
} else
continue;
}begin = msg;
end = begin + lenstr;while (begin < end) {
remaining = end - begin;
errno = 0;
res = write(STDOUT_FILENO, begin, remaining);if (errno != 0) {
switch (errno) {
case EBADF:
case EINVAL:
case EFAULT:
case EFBIG:
case EPIPE:
case EAGAIN:
case ENOSPC:
case EIO:
default:
return (errno);
}
}
if (res >= 0) {
begin += res;
continue; // Let's send the remaining part of this message
} else {
return (EXIT_FAILURE); // It's a real error
}
}
return (EXIT_SUCCESS); // OK! Let's celebrate and drink some beer!
}
> Каждая Труъ Юних программулина, должна иметь свой обработчик ошибок,
> проверять и обрабатывать возвращаемые значения ВСЕХ используемых функций!!!И это правильно, блин! Как же задрал *говнокод* который тихо издыхает забыв сообщить причину или того хуже - взглюкивает и дальше криво работает, а может подыхает но через сутки мучений. Так что потом даже концов не найдешь от чего оно там по факту сдохло. Это тот случай когда сэкономив 20 секунд на кодинге можно прое...ть многие часы на дебагинг, вашумать. И потом обломаться обнаружив что все было просто и тривиально, просто не проверили что-то а оно имело право сломаться. Да, мля. Память может закончиться. Файлов можно открывать не бесконечно много. И даже, мля, файл в общем то не обязан гарантированно прочитаться. И это еще не повод упасть или дико взглючить не выдав вменяемого сообщения. Тех кто не проверяет ошибки - надо вешать путем расстрела с особой жестокостью. Другим меньше мучений будет.
>... можно прое...ть многие ...
> Да, мля. ....
> ... И даже, мляКакой-то злой ты сегодня. :)
Злой, но справедливый. Я его понимаю.
> Тех кто не проверяет ошибки - надо вешать путем расстрела с особой жестокостью. Другим меньше мучений будет."проверяет ошибки" - это как? Как капканы что ли?
А вы проверяете, что сами говорите? Или вас тоже в расход?
> "проверяет ошибки" - это как?Не кривляйтесь, пожалуйста.
"Два" тебе, Павлин.
Нужно проверять тип Юникса, под которым это всё пытается собраться (кое-где EAGAIN называется EWOULDBLOCK).
> "Два" тебе, Павлин.
> Нужно проверять тип Юникса, под которым это всё пытается собраться (кое-где EAGAIN
> называется EWOULDBLOCK).Проблемы переносимости, это вторая часть концерта.
>> "Два" тебе, Павлин.
>> Нужно проверять тип Юникса, под которым это всё пытается собраться (кое-где EAGAIN
>> называется EWOULDBLOCK).
> Проблемы переносимости, это вторая часть концерта.Без переносимости не стоит и огород городить с кучей проверок там, где они не нужны, эдак можете дойти до изобретения дотнетовского велосипеда на базе С.
>>> "Два" тебе, Павлин.
>>> Нужно проверять тип Юникса, под которым это всё пытается собраться (кое-где EAGAIN
>>> называется EWOULDBLOCK).
>> Проблемы переносимости, это вторая часть концерта.
> Без переносимости не стоит и огород городить с кучей проверок там, где
> они не нужны, эдак можете дойти до изобретения дотнетовского велосипеда на
> базе С.А это ты Andrew Kolchoogin скажи, он придрался к портабельности, а POSIX говорит:
[EAGAIN]
Resource unavailable, try again (may be the same value as [EWOULDBLOCK]).http://www.opengroup.org/onlinepubs/009695399/basedefs/errno...
[EWOULDBLOCK]
Operation would block. An operation on a socket marked as non-blocking has encountered a situation such as no data available that otherwise would have caused the function to suspend execution.A conforming implementation may assign the same values for [EWOULDBLOCK] and [EAGAIN].
http://www.opengroup.org/onlinepubs/009695399/functions/xsh_...У МЕНЯ НЕТ ТУТ СОКЕТОВ !!!
> А это ты Andrew Kolchoogin скажи, он придрался к портабельности, а POSIX
> говорит:Вот только проблема переносимости не заканчивается на ПОСИКС системах, иногда требуется перенести код и на совсем нечто. А иногда вообще нужно написать код, который через две недели уже никому не будет нужен, но вот сейчас он нужен что ой просто. Всегда надо соблюдать баланс между академичностью и практичностью.
>> А это ты Andrew Kolchoogin скажи, он придрался к портабельности, а POSIX
>> говорит:
> Вот только проблема переносимости не заканчивается на ПОСИКС системах, иногда требуется
> перенести код и на совсем нечто. А иногда вообще нужно написать
> код, который через две недели уже никому не будет нужен, но
> вот сейчас он нужен что ой просто.ООП явно не для этого :)
>>> А это ты Andrew Kolchoogin скажи, он придрался к портабельности, а POSIX
>>> говорит:
>> Вот только проблема переносимости не заканчивается на ПОСИКС системах, иногда требуется
>> перенести код и на совсем нечто. А иногда вообще нужно написать
>> код, который через две недели уже никому не будет нужен, но
>> вот сейчас он нужен что ой просто.
> ООП явно не для этого :)ООП инструмент, в С++ одна из задач ООП была повышение управляемости кодовой базы, но всегда можно инструмент применить для новых задач. Так что косвенно ООП можно и для этого применить, а явного в жизни очень мало.
не нужно путать C++ и ООП, человеческому (не математическому) мозгу всегда легче отталкиваться от объектов со свойствами, чем от функций с параметрами. Любой кто пишет что-то сложное, с несколькими состояниями, это осознает. Язык не имеет значение:Thing *thing = CFGetThing(&obj);
CFSetThing(&obj, &thing);
А почему же тогда филолог Ларри Уолл создал не объектный язык?
Потому что он филолог :-D
> А почему же тогда филолог Ларри Уолл создал не объектный язык?devel/p5-Moose
Это уже надстройка.
А саму объектность в перле прилепили только уже после выхода 5й версии.Вот в 6й она встроена изначально.
> Вот в 6й она встроена изначально.Ага, 6-го перла нет, а объектность в нём есть
А Вы попробуйте
yum install/apt-get rakudoПочему-то во все основных дистрибутивах есть то, чего по Вашему ещё нет.
Это не релиз, его ещё не допилили, и вряд ли уже когда-нибудь допилят.
Я общался с одним из разработчиков на YAPC2010 в Киеве, они считают что скоро рабочая версия rakudo будет, а финальная версия parrot-а уже вышла.
> Я общался с одним из разработчиков на YAPC2010 в Киеве, они считают
> что скоро рабочая версия rakudo будет, а финальная версия parrot-а уже
> вышла.Я 5 лет назад купил книжку по Perl6, там было написано, что выйдет он чуть ли не на днях, и все должны быть к этому уже готовы.
Я сомневаюсь что тот автор был одним из разработчиков.А 5 лет назад ещё не было окончательного синтаксиса языка, оформился только parrot, так что автор выдавал желаемое за действительное.
Хотя и сами разработчики говорят что времени у них ушло больше чем они думали, т.к. захотели сразу реализовать очень многое.
> Вот в 6й она встроена изначально.Именно. И это, кстати, ещё один показатель, что ООП никуда не проваливалось, а наоборот проникает в недры исконно процедурных языков.
> Именно. И это, кстати, ещё один показатель, что ООП никуда не проваливалось, а наоборот проникает в недры исконно процедурных языков.Еще один. Типа, или ООП, или процедуры. Другого якобы не дано.
> Еще один. Типа, или ООП, или процедуры. Другого якобы не дано.Ты ли это, мой любезный друг-сектант? Печально, но нашу дискуссию выше потёрли. Можем продолжить здесь.
>еловеческому (не математическому) мозгу всегда легче отталкиваться от объектов со свойствами, чем от функций с параметрамиТо есть ООП это типа для тех кто не осилил ФП? Вы уж не упрощайте так, пожалуйста.
ООП - это то что люди видят вокруг себя в реальной жизни, ФП - это мат. абстракция не имеющая аналогов в реальности.
> ООП - это то что люди видят вокруг себя в реальной жизни,
> ФП - это мат. абстракция не имеющая аналогов в реальности.Значит, по-вашему, ООП - это не абстракция.
Теперь вам осталось только определить эту самую реальность. Смотрите только не запутайтесь.А пока что вы лишь подтвердили, что в ООП легче тем, у кого плохо с мат. абстракциями. Если вам удасться даказать, что ООП более "реально", чем ФП возможно это можно будет считать еще одним преимуществомм, но только если вы это докажете.
Зато о преимуществах ФП (за вычетом того, что для владения им требуются хотя бы элементарные математические способности) вы судя по всему вообще ничего не знаете.
> Значит, по-вашему, ООП - это не абстракция.Я такого не говорил, не приписывайте мне свои мысли. ООП это такая же абстракция, только она основана на восприятии реального мира, мы оперируем сущностями, наделяем их свойствами и возможными действиями.
> Зато о преимуществах ФП (за вычетом того, что для владения им требуются
> хотя бы элементарные математические способности) вы судя по всему вообще ничего
> не знаете.Вот и расскажите нам, а мы послушаем.
>> Значит, по-вашему, ООП - это не абстракция.
> Я такого не говорил, не приписывайте мне свои мысли. ООП это такая же абстракция, только она основана на восприятии реального мира, мы оперируем сущностями, наделяем их свойствами и возможными действиями.То есть ваши мысли и понятия в вашем сознании, как и само ваше сознание, вы реальностью не считате. И вы не считате, что ФП (как и математика), которое все это обобщает и придает понятиям в сознании строгость и упорядоченность, вы не считате, что эти абстракции связаны с реальностью.
А границы "реальности" вы, значит, проводите строго по своему "восприятию". С чем вас и поздравляю.
>> Зато о преимуществах ФП (за вычетом того, что для владения им требуются
>> хотя бы элементарные математические способности) вы судя по всему вообще ничего
>> не знаете.
> Вот и расскажите нам, а мы послушаем.Вот и попробуйте разобраться сами, если вас это действительно заинтересовало, или продолжайте спокойно спать.
> То есть ваши мысли и понятия в вашем сознании, как и само
> ваше сознание, вы реальностью не считате. И вы не считате, что
> ФП (как и математика), которое все это обобщает и придает понятиям
> в сознании строгость и упорядоченность, вы не считате, что эти абстракции
> связаны с реальностью.Вот и расскажите нам как ФП и математика придаёт понятиям в сознании строгость и упорядоченность, а я пока за попкорном схожу.
> Вот и попробуйте разобраться сами, если вас это действительно заинтересовало, или продолжайте
> спокойно спать.Слив засчитан.
Если вы уверены, что это был именно слив, и что с пониманием поставленных вопросов у вас все в порядке, тогда вам не о чем беспокоиться.
>> То есть ваши мысли и понятия в вашем сознании, как и само
>> ваше сознание, вы реальностью не считате. И вы не считате, что
>> ФП (как и математика), которое все это обобщает и придает понятиям
>> в сознании строгость и упорядоченность, вы не считате, что эти абстракции
>> связаны с реальностью.
> Вот и расскажите нам как ФП и математика придаёт понятиям в сознании
> строгость и упорядоченность, а я пока за попкорном схожу.
>> Вот и попробуйте разобраться сами, если вас это действительно заинтересовало, или продолжайте
>> спокойно спать.
> Слив засчитан.несомненно. тебе
> мозгу всегда легче отталкиваться от объектов со свойствами, чем от функций с параметрами.А чем отличается объект со свойствами, от функций с параметрами? ;)
Объект - это свойства, методы и _состояние_, а функция это всего лишь функция.
> Объект - это свойства, методы и _состояние_,Да ну? А разве свойства, методы и _состояния_ - это не объекты?
> а функция это всего лишь функция.
а объект это всего лишь объект.
Учите матчасть.
> Объект - это свойства, методы и _состояние_, а функция это всего лишь
> функция.А из чего состоят свойства, методы и состояние? :)
P.S. Ниже ассемблера не опускаемся.
>> Объект - это свойства, методы и _состояние_, а функция это всего лишь
>> функция.
> А из чего состоят свойства, методы и состояние? :)Из зубного порошка :)
> P.S. Ниже ассемблера не опускаемся.
Причём тут ассемблер если разговор о парадигме. Или вы хотите поговорить о реализации?
> Из зубного порошка :)Ну вот, а еще других в сливе обвиняете.
> Причём тут ассемблер если разговор о парадигме. Или вы хотите поговорить о реализации?
До этого вы утверждали, что архитектура по-вашему в область ООП не входит.
На этот раз выясняется, что вы уверены, что и "реализация" к проблематике ООП не относится.Все веселее и веселее раз от раза.
Такие вот обычно "защитники" у парадигмы ООП. Что и следовало ожидать.
Метод это действие, применимое к определенному типу объектов (в реальной жизни, обычно, описывается глаголом: встать, ехать, лететь, открыть...). свойство объекта - это какая-то из его характеристик (в реальной жизни, обычно, описывается прилагательным: высокий, красный, сильный, горячий...). состояние объекта, это определенный набор значений всех свойств объекта.
А теперь попробуй объяснить, как ты себе представляешь выражение свойств функцией?
> А теперь попробуй объяснить, как ты себе представляешь выражение свойств функцией?Легче чем ты думаешь :) Просто создаём новую функцию реализующую не обходимые свойства.
Функция - аналог глагола в естественном языке, а через фиктивные глаголы можно выразить что угодно. В языке может не быть существительных, прилагательных и всего остального, но служебные слова (аналог кейвордов и конструкций) и глаголы быть обязаны.
> Функция - аналог глагола в естественном языке, а через фиктивные глаголы можно
> выразить что угодно. В языке может не быть существительных, прилагательных и
> всего остального, но служебные слова (аналог кейвордов и конструкций) и глаголы
> быть обязаны.Главное меру соблюсти, а то через "на *" и "в *" тоже можно выразить чего угодно, но в целом и другие слова русского языка используются:)
> Функция - аналог глагола в естественном языке, а через фиктивные глаголы можно выразить что угодно. В языке может не быть существительных, прилагательных и всего остального, но служебные слова (аналог кейвордов и конструкций) и глаголы быть обязаны.У вас типичное мышление на уровне действий, мышление исполнителя. Поэтому вам и кажутся глаголы первичными. Мышление на уровне "Что делать?". Как впрочем и у большинства.
Да, можно положить в основу именно действия и процессы, а не объекты, связи и структуры.
Только в подавляющем большинстве случаев, описание практичеки любой системы (за редкими исключениями) на уровне действий и процессов - практически всегда получается во много раз более громоздким, а сложность очень быстро накапливается.Именно поэтому при прочих равных условиях код на декларативных и функциональных языка получается во много компактнее.
Правда, поскольку большинство людей в своем мышлении не могут выйти за рамки стереотипов действий и исполнения, именно императивные языки получили большую популярность. Что в прочем не мешает владеющим декларативными парадигмами контролировать ситуацию в виду большей эффективности и возможности смотреть на императивные системы с высоты "птичьего полета".
>[оверквотинг удален]
> у большинства.
>
> Да, можно положить в основу именно действия и процессы, а не объекты,
> связи и структуры.
> Только в подавляющем большинстве случаев, описание практичеки любой системы (за редкими
> исключениями) на уровне действий и процессов - практически всегда получается во
> много раз более громоздким, а сложность очень быстро накапливается.
>
> Именно поэтому при прочих равных условиях код на декларативных и функциональных языка
> получается во много компактнее.Еще гораздо более громоздким оно получается, если описывать его существительными - вот как в Java, например. А декларативные /функциональные языки как раз именно этим - чрезмерным упором на объекты-существительные - не страдают.
См. http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom... для полного раскрытия темы.
> человеческому (не математическому) мозгу всегда легче отталкиваться от объектов со свойствами, чем от функций с параметрами.Извините, но Вы не правы. В чём? В одном скользком слове - "всегда". В реальном (не математическом) мире нет никаких "всегда", "все", итп. Пуризм-максимализм вреден. IMHO самый сок - это современные гибридные языки, являющиеся полноценными функциональными, полноценными объектно-ориентированными и полноценными алгоритмическими языками одновреенно. Например Scala. "человеческому (не математическому) мозгу" может быть некомфортно только с непривычки (которая длится очень недолго), потом уже взяв чисто-ОО, чисто-функциональный или чисто-процедурный язык, чувствуешь себя в усмирительной рубашке.
Существует гипотеза, что математики - вообще не люди.
А Перельмана вообще не существует.
> человеческому (не математическому) мозгу всегда легче
> отталкиваться от объектов со свойствами, чем от функций с параметрами.Да? Скажите, а Вы в обычном, человеческом языке как разговариваете?
"ручка.писать(бумажка, текст)" или "бумажка.написать(текст, ручка)"?
Или, может, даже "текст.написаться(бумажка, ручка)" ?
>> человеческому (не математическому) мозгу всегда легче
>> отталкиваться от объектов со свойствами, чем от функций с параметрами.
> Да? Скажите, а Вы в обычном, человеческом языке как разговариваете?
> "ручка.писать(бумажка, текст)" или "бумажка.написать(текст, ручка)"?
> Или, может, даже "текст.написаться(бумажка, ручка)" ?В обычном нет, а на пиджине так и говорится примерно.
"моя твоя не понимать маса" :)
> резюмирующую основные доводы противников объектно-ориентированного программирования.В каком месте она там их резюмирует? Сплошная вода и никакой конкретики. Статья ни о чем, в буквальном смысле. А комменты там - ржач, круче чем на опен^ Ютубе.
>> резюмирующую основные доводы противников объектно-ориентированного программирования.
> В каком месте она там их резюмирует? Сплошная вода и никакой конкретики.
> Статья ни о чем, в буквальном смысле. А комменты там -
> ржач, круче чем на опен^ Ютубе.Поддерживаю. И вся эта дискуссия мне напоминает троллинг на быдлолоре.
Это где оно провалилось ?
питону\руби\яве\ и тд теперь каюк ?
> Это где оно провалилось ?
> питону\руби\яве\ и тд теперь каюк ?Речь не о тулзе, а о качестве мидлвера,
наработанного этим тулзом в ощущениях объективной реальности.
Всё же я хотел бы понять, в чём заключается провальность ООП? Его вроде же как часто и везде используют.
> Всё же я хотел бы понять, в чём заключается провальность ООП? Его
> вроде же как часто и везде используют.Используют для чего?
Используют для написания биб и определения апей.
А вот при подключении биб и использовании апей и возникает
ощущение провальности :)
>> Всё же я хотел бы понять, в чём заключается провальность ООП? Его
>> вроде же как часто и везде используют.
> Используют для чего?
> Используют для написания биб и определения апей.
> А вот при подключении биб и использовании апей и возникает
> ощущение провальности :)Проблема, в общем-то, в том, что предоставленные ООП средства НЕ используются
надлежащим образом.
Rational Rose - наше усё! :)
Лично у меня, в том, за что я плачу, реализация - ПОСЛЕДНЕЕ место проекта.
Качество продукта определяется исключительно UML-схемой.
ВСЯ работа ТОЛЬКО над ней.
А дальше тупая "компиляция" схемы - кодинг, создание C++ текста.
По мне так после генерации кода из УМЛ, всё равно приходиться его просматривать и переделывать вручную :)
> По мне так после генерации кода из УМЛ, всё равно приходиться его
> просматривать и переделывать вручную :)Только вручную. Вообще не опираясь на сгенерированный код.
> Лично у меня, в том, за что я плачу, реализация - ПОСЛЕДНЕЕ место проекта.Вот оно наше будущие!!!
Ладно, так уж и быть... будем нормально делать библиотеки и ядро, чтоб у Вас не глючило! :)
------
> А дальше тупая "компиляция" схемы - кодинг, создание C++ текста.
А это где такая халява?
Я тоже хачу нарисовать схему, отдать генератору кода и получить бабло!!!
А где халява?
Зделал схему - ты же и кодируй ручками.
"Генераторы кода" - жмых, отброс производства.
Схемы формата А0 развешаны по стенам, для пометок фломастерами.
Я (сюрприз-сюрприз!) плачу за бинарь, а не за схемы.
А бинарь можно предоставить для оплаты только после проверки сырца на соответствие спецификациям.
>Зделал схему - ты же и кодируй ручками.чем же у вас делаются схемы? какими-то другими выступами на теле?
>Схемы формата А0 развешаны по стенам, для пометок фломастерами.
это где такая жесть?
>>Зделал схему - ты же и кодируй ручками.
> чем же у вас делаются схемы? какими-то другими выступами на теле?
>>Схемы формата А0 развешаны по стенам, для пометок фломастерами.
> это где такая жесть?:)
Это новый язык, аналоговый Markup Language - UML/A0 Flo Master
>>Схемы формата А0 развешаны по стенам, для пометок фломастерами.
> это где такая жесть?В моем мелком частном бизнесе.
И это дисциплинирует всех участников прОжекта.
А вы чем аудиторную грифельную доску заменяете?
Плазменным тачскрином диагональю три метра?
на белой доске - разрабатываются общие концепты построения проекта, во время разработки. самый большой проект, который был при мне пока что - примерно в 4 человекогода. да и то, 25% из которых касается другого проекта. примерно планируется еще 1-2 человекогода на расширение функционала, зависит от будущих заказов. пилят всё три человека, между которыми оговариваются правила интерфейсов, без горождения огородов. после этого софт должен будет пройти сертификацию. примерно так. это не значит, конечно же, что так у всех должно быть. зависит от многих факторов.
при большем количестве девелоперов, скорее всего, пришлось бы применять больше конкретики (UML) и дополнительные инструменты.
> на белой доске - разрабатываются общие концепты построения проекта, во время разработки......
> (UML) и дополнительные инструменты.В RR разрабатывается UML схема проекта.
На плоттере А0 распечатываются диаграммы.
Бумажные листы развешиваются по стенам.
Участники приписывают фломастерами: "Ван Ваныч! Я утром не буду, доделаю эту часть кода дома. Отошлю вам и Пете на мыло числа 5-го - 7-го".Или: "Ван Ваныч! Обведенное красным взял я. Управлюсь за три-четыре недели. Вася"
"Ван Ваныч! Недо вернуться к тому спору, я считаю сжатие не нужно выделять наверх, пусть каждый формат-плагин содержит в себе весь функционал. А то увязнем"
И т.д.
А Ван Ваныч, т.е. я, насосавшись пива, ночами и утрами мутным глазом хорошо вижу, где мы и за что я людям деньги плачу, будь это постоянные или "аккордные" работники
Очень удобно.
Далее коррекция, распечатка и снова разрисовка фломастерами.
> Rational Rose - наше усё! :)
> Лично у меня, в том, за что я плачу, реализация - ПОСЛЕДНЕЕ место проекта.
> Качество продукта определяется исключительно UML-схемой.
> UML
> U M LДальше дискуссия бессмысленна, все понятно
> Всё же я хотел бы понять, в чём заключается провальность ООП? Его вроде же как часто и везде используют.Не можете понять, потому что не можете видеть. Смотрите, но не видите, слушаете, но не слышите, читаете, но не понимаете.
Читата в той же статье высказывания самого Александра Степанова, создателя библиотеки шаблонов STL для C++. Т.е. человек в ООП более чем не случайный.
Цитата из статьи: "Именно из-за этой неразберихи в ООП так популярен рефакторинг - из-за ущербности парадигмы вы просто обречены на переписывание программы, уже в тот самый момент, когда только задумали её спроектировать в ООП-стиле."
Хотя Степанов в своих высказываниях концентрируется на алгоритмах (чтобы было понятно большинству), точно такие же рассуждения можно построить, отталкиваясь от функциональной парадигмы. Ведь его STL основывается скорее на функциональной парадигме, чем на алгоритмической, хотя это большинству хуже понятно. Вот он и переводит "для масс".
Можно еще по другому сказать. ООП просто провоцирует создавать плохомасштабируемые неортогональные (сильноосвязанные) решения. Т.е. кажущаяся легкая модульность, на самом деле порождает быстронарастающую сложность при компоновке.
В этом и заключается "провал". Бысторое нарастание сложности.
Хотя для быдлокодерства ООП самое то.
Рефакторинг это реация на изменчивость условия, и это вполне естественный процес независимый от используемой парадигмы. Вас, например, тоже когда-то давно отрефакторили - хвост отобрали, хотя отросток оставили.
> Рефакторинг это реация на изменчивость условия, и это вполне естественный процес независимый
> от используемой парадигмы. Вас, например, тоже когда-то давно отрефакторили - хвост
> отобрали, хотя отросток оставили.Ага. И мне ещё понравился вброс Степанова про аксиомы. Человек явно далёк от математики и пытается рассуждать о том, чего сам не понимает.
> Ага. И мне ещё понравился вброс Степанова про аксиомы. Человек явно далёк от математики и пытается рассуждать о том, чего сам не понимает.Нет, он просто знает самые передовые достижения в математике. Рекомендую вам почитать, что такое секвенции и натуральный вывод. Аксиомы на практике вторичны по отношению к процессу натурального вывода.
Он прямо пишет, что не нужно путать теорию и практику. Теория рождается из практики, и практику направляет. В том числе и в математике.
> Рефакторинг это реация на изменчивость условия, и это вполне естественный процес независимый от используемой парадигмы. Вас, например, тоже когда-то давно отрефакторили - хвост отобрали, хотя отросток оставили.Ну, допустим, так тоже можно сказать. Только вы за что выступаете?
Вопрос то ведь именно в цене рефакторинга. И как скоро необходимость в нем возникнет.
И вообще - в сдерживании роста связности, сложности и т.п. Сколько уже об этом говорится.Похоже вы до понимания этих вопросов просто еще не дошли, и просто не замечаете, о чем написано в статье.
> Только вы за что выступаете?я за безопасный секс, всё остальное мелочь не стоящая какого-либо внимания.
> Вопрос то ведь именно в цене рефакторинга. И как скоро необходимость в
> нем возникнет.
> И вообще - в сдерживании роста связности, сложности и т.п. Сколько уже
> об этом говорится.Это всё проблемы с архитектором. Если он это предусмотрел, значит и проблем особых нет, если же нет - значит мотыгу в руки и вперёд.
>> Вопрос то ведь именно в цене рефакторинга. И как скоро необходимость в нем возникнет.
>> И вообще - в сдерживании роста связности, сложности и т.п. Сколько уже об этом говорится.
> Это всё проблемы с архитектором. Если он это предусмотрел, значит и проблем особых нет, если же нет - значит мотыгу в руки и вперёд.Понятно. То есть вы это относите строго к "архитектуре". Ну допустим.
Однако саму архитектуру вы к проблематике ООП не относите. Замечательно.Тем не менее из ваших же слов, вопрос остался тем же, только в другой формулировке.
Ну и как часто вам придется "брать мотыгу в руки" в обоих случаях?
И каковы в обоих случаях у этого самого "архитектора", которого вы даже в ООП посвящать не намерены, каковы у него шансы "все предусмотреть"?И уж вы наверняка точно уверены, что с помощью ФП "архитектуру" никак нельзя описать, и никак нельзя решать задачи связанные с "архитектурой" еще на ранних стадиях.
> Можно еще по другому сказать. ООП просто провоцирует создавать плохомасштабируемые неортогональные
> (сильноосвязанные) решения. Т.е. кажущаяся легкая модульность, на самом деле порождает
> быстронарастающую сложность при компоновке.а как же IoC? модульность получается еще и слабосвязанной ибо компоновка происходит по требованию того, кто скомпоновал, а не изначального прогера.
> а как же IoC? модульность получается еще и слабосвязанной ибо компоновка происходит по требованию того, кто скомпоновал, а не изначального прогера.Как? Да очень просто.
Кто вам сказал, что "инверсия управления" имеет непосредственное отношение к ООП. Просто где так прочитали?Тогда уж и процедурное, и структурное, и вообще императивное программирование - это все по-вашему следует считать ООП. Ведь и процедуры, и структуры, и даже состояния с командами - это ведь все тоже объекты. Смотрите, не запутайтесь.
И еще. Попробуйте на "инверсию контроля" посмотреть с точки зрения функциональной парадигмы, или с точки зрения других декларативных парадигм. Может все окажется гораздо проще?
Только чтобы так "посмотреть", вам придется по-настоящему изучить функциональную парадигму, сопутствующие теории и практики. А вовсе не с той точки зрения, какой вам все это представляется сейчас.
>> а как же IoC? модульность получается еще и слабосвязанной ибо компоновка происходит по требованию того, кто скомпоновал, а не изначального прогера.
> Как? Да очень просто.
> Кто вам сказал, что "инверсия управления" имеет непосредственное отношение к ООП. Просто
> где так прочитали?
> И еще. Попробуйте на "инверсию контроля" посмотреть с точки зрения функциональной парадигмы,
> или с точки зрения других декларативных парадигм. Может все окажется гораздо
> проще?
> Только чтобы так "посмотреть", вам придется по-настоящему изучить функциональную парадигму,
> сопутствующие теории и практики. А вовсе не с той точки зрения,
> какой вам все это представляется сейчас.Стоящих проектов на функциональной парадигме не вижу вокруг, потому изучаю подопытных кроликов, т.е. ООП. IoC позволяет добиться слабой связанности - это ответ на сильную связанность ООП приложений.
> Стоящих проектов на функциональной парадигме не вижу вокруг, потому изучаю подопытных кроликов, т.е. ООП.Я тоже не видел "стоящих на парадигме", знаю только что существуют методы наСТОйки проектов на всяких там березовых брульках и ореховых перегородках.
Хотя каждый выбирает в меру своего понимания, что на чем будет стоять, и чего оно будет стоить.> IoC позволяет добиться слабой связанности - это ответ на сильную связанность ООП приложений.
Любой может прочитать на Википедии, что "инверсия управления" применяется для снижения связности.
Однако суть вы так и не поняли. "Инверсия управления" в общем случае к ООП не относится. "Инверсия управления" нужна потому, что сама императивная парадигма способствует быстрому росту связности. В то время как функциональная и декларативная парадигмы такими проблемами наделены гораздо в меньшей степени изначально.
Кроме того, как "инверсия управления", так и само ООП, легко выражаются в функциональном виде в случае необходимости.
> Читата в той же статье высказывания самого Александра Степанова, создателя библиотеки шаблонов
> STL для C++. Т.е. человек в ООП более чем не случайный.В STL ООП нет или почти нет. Чтобы в этом убедиться, достаточно пересчитать количество виртуальных функций. Они там только в локалях и исключениях :-).
И позиция Степанова в общем-то такая уже лет 20-ть как.
>> Читата в той же статье высказывания самого Александра Степанова, создателя библиотеки шаблонов
>> STL для C++. Т.е. человек в ООП более чем не случайный.
> В STL ООП нет или почти нет. Чтобы в этом убедиться, достаточно
> пересчитать количество виртуальных функций. Они там только в локалях и исключениях
> :-).
> И позиция Степанова в общем-то такая уже лет 20-ть как.Чуть ниже в цитируемом вами посте так и сказано, что STL скорее функциональная, нежели ОО. Учитывая еще, что сама функциональная парадигма может сама по себе натуральным образом трактоваться, как система объектов высокого порядка.
Об этом и речь, что с помощью ФП можно легко создавать библиотеки для ОО-языков, и сами ОО-языки в том числе.
> Об этом и речь, что с помощью ФП можно легко создавать библиотеки
> для ОО-языков, и сами ОО-языки в том числе.Вы будете смеяться, но с помощью практически любого языка можно создать компилятор/интерпретатор любого языка. :-) И библиотеки тоже. В конце-концов, это просто тексты.
> Можно еще по другому сказать. ООП просто провоцирует создавать плохомасштабируемые неортогональные (сильноосвязанные) решения.Если мозг заражён идеями "четырёх идиотов" с их "паттернами" - тогда да. А так слабую связанность проектирует мозг, а не парадигма. Скажем, можно написать ядро + плагин, а можно тупо вбить ещё одну из сотни подфункций прямо в модуль. Как вы понимаете, "плагины" не относятся ни к одной парадигме.
ООП _в_сипиписной_реализации_ - да, полный фэйл. В Смоллтоке ООП доведено до идеала, но похоронено рынком. Но как теоретическая база ООП вполне хорош.
> Если мозг заражён идеями "четырёх идиотов" с их "паттернами" - тогда да.
> А так слабую связанность проектирует мозг, а не парадигма.В том-то и дело, что слабую связность в императивной модели приходится очень тщательно проектировать. В то время как в декларативных языках это получается естественным образом.
И если сильно запроектироваться, в итоге и получится деларативный подход, придете к тому же, только более длинным, сложным и окольным путем с большим количеством кода, хоть даже и менее связанного. Проще весь этот код сразу внести в декларативный транслятор и не мучаться.
>Скажем, можно написать ядро + плагин, а можно тупо вбить ещё одну из сотни подфункций прямо в модуль. Как вы понимаете, "плагины" не относятся ни к одной парадигме.
Вы явно валите в одну кучу совершенно разные теории, методики и технологии.
> ООП _в_сипиписной_реализации_ - да, полный фэйл. В Смоллтоке ООП доведено до идеала,
> но похоронено рынком. Но как теоретическая база ООП вполне хорош.Теоретической базой ООП являются те же теории, которые лежат в основе функциональной парадигмы.
А для особо упертых в императивную модель, команды и состояния - это будет та же теория автоматов (не путать с первым случаем выше).
Так что никакой новой теории в ООП нет. Она была придумана специально для людей, подсевших на императивные и процедурные стереотипы, и вадана за некоторую невиданную теорию. В то время как ООП само по себе просто является смесью императивных и декларативных подходов. Просто промежуточной формой.
Статья "ниочём". Ни выводов, ни конкретики. И жёлтый заголовок. Позор.
> Статья "ниочём". Ни выводов, ни конкретики. И жёлтый заголовок. Позор.Будете поддерживать большую систему в исходниках - потрещим на эту тему.
А пока читайте статьи, определяя качество критики обсуждаемых парадигм
дефинициями гайзеты спидинфо.
>Будете поддерживать большую систему в исходниках - потрещим на эту тему.А "большая" это какая? Просто интересно узнать это у "корифеев".
>А пока читайте статьи, определяя качество критики обсуждаемых парадигмдефинициями гайзеты спидинфо.
Глупенький, речь шла про заголовок.
http://lurkmore.ru/%D0%A1%D0%BF%D0&...
В заметке констатируются факты, что многие программисты сомневаются в ООП, однако почему то все им пользуются. Статья не отвечает не на один вопрос.Мне кажется падение эффективности программирования связано не с ООП, а особенностями языков С и С++. Это низкоуровневые языки. Язык С изначально был придуман для ядра. Потом зачемто его стали дотягивать до приложений пользователя, получился С++.
Благодаря сложности С и С++ имели статус языков для продвинутых программистов. Была мода на эти языки, однако понятно, что эти языки не приемлемы для разработки приложений. Вообще можно спокойно обходиться вариациями паскаля и ассемблером. А идея ООП тут вообще не при чём.
С статье умные люди ищут чёрную кошку в тёмной комнате, где её нет.
Надо просто признать, что программирование на С и С++ не может быть эффективным и практичным. Потому что компиляторы требуют слишком больших процессорных ресурсов, эти языки выгодны Интелу и АМД, чтобы программисты и юзеры не ленились обновлять процы.
Если хотим свободы, демократии, не зависимости, то необходимо уходить от неэффективных языков программирования С и С++ в пользу паскаля. В противном случае такие статьи будут появляться постоянно, а толку будет ноль.
>Надо просто признать, что программирование на С и С++ не может быть эффективным и практичнымобъясни профессиональным программистам, программирующим на этих языках, создающих не какие-то там поделия, а софт, бесперебойно и эффективно работающий годами.
>Потому что компиляторы требуют слишком больших процессорных ресурсов
не позорьтесь такими ляпами
>в пользу паскаля
приплыли. ваш опус был тонкой шуткой?
Про процессорные ресурсы и компиляторы - это конечно номер. Но и вы тоже "в долгу не остались".> объясни профессиональным программистам, программирующим на этих языках, создающих не какие-то там поделия, а софт, бесперебойно и эффективно работающий годами.
Велосипед тоже способен работать "годами, эффективно и бесперебойно", однако он так и остается велосипедом.
То что некоторая биомасса, считающая себя сферическими "профессионалами" в вакууме долго-долго, профессионально-профессионально отлаживает код, чтобы добиться "бесперебойной работы годами" - это еще не значит, что они изобрели "серебряную пулю".
Кроме "бесперебойной работы годами" есть еще такие факторы, как масштабируемость, цена модификации "без перебоев", связность, сложность и т.д. и т.п.
А так конечно каждый - научился мышкой в IDE объекты компоновать - и уже "профессионал".
> Про процессорные ресурсы и компиляторы - это конечно номер. Но и вы
> тоже "в долгу не остались".Есть простой факт:
1. паскаль простой и понятный язык - это обеспечивает читабельность и понимание кода
2. любой проект на паскале и тем более большой и сложный проект, компилируется быстрее, чем С и С++, это идёт из свойств языка и компялятора
3. на паскале значительно проще отлаживать софт
4. у паскаля несколько большая трудоёмкость, но в целом код более понятен и содержит меньше ошибок
5. С и С++ даёт иллюзию быстрой разработки кода, на самом деле они тратят много времени программиста
6. ещё ни кто здесь не доказал, что программирорвание на паскале менее эффективно, чем на СИ и С++, прошу привести примеры задач, которые на С и С++ будут написаны, отлажены быстрее и с меньшим количеством ошитбок, чем на паскале
Интересный момент, поменяйте местами "С и С++" и "Паскаль", верность ваших утверждений не изменится.
ты снова выдаешь желаемое за действительное. качество кода зависит не от языка программирования. ты даже таких простых вещей понять не можешь, что тут скажешь?
> Есть простой факт:Ваши представления это еще далеко не факты. Я гарантирую!
> 2. любой проект на паскале и тем более большой и сложный проект, компилируется быстрее, чем С и С++, это идёт из свойств языка и компялятора
> 5. С и С++ даёт иллюзию быстрой разработки кода, на самом деле они тратят много времени программистаВы просто смешиваете в одну кучу проблемы трансляции и кодогенерации. В паскале используется шитый байт-код. Который можно точно так же генерировать и для C/C++.
Учите матчасть!> 1. паскаль простой и понятный язык - это обеспечивает читабельность и понимание кода
> 3. на паскале значительно проще отлаживать софт
> 4. у паскаля несколько большая трудоёмкость, но в целом код более понятен и содержит меньше ошибок
> 6. ещё ни кто здесь не доказал, что программирорвание на паскале менее эффективно, чем на СИ и С++, прошу привести примеры задач, которые на С и С++ будут написаны, отлажены быстрее и с меньшим количеством ошитбок, чем на паскалеАмерику открыли! Ясно-понятно что эффективнее будет на том языке, который вам более понятен.
Однако скажите мне, какой язык вам более понятен, и я скажу, кто вы (и почему)!
> Вы просто смешиваете в одну кучу проблемы трансляции и кодогенерации. В паскале
> используется шитый байт-код. Который можно точно так же генерировать и для
> C/C++.
> Учите матчасть!Шитый байткод ? В паскале ? Да бог с вами. Байткод (отнюдь не шитый) был в канонiчном виртовском паскале, и собсно оттэдова в оберон плавно и съехал. Ну модель вызова да, другая. По вполне обьективным причинам, просто код компактнее и надежнее получается когда стек в исходное состояние возвращает вызываемая функция. Меньше возможностей ошибиться.
Я очень долго писал на turbo/object pascal, и достаточно долго писал на крестах. Могу утверждать что любой паскалевский компилятор достаточно больно бьет палкой по рукам за всякие сомнительные вольности, которые потом вызывают у программистов с "сипипишным" складом мозгов плач Ярославны навроде "ООП уже больше никуда не годится".
ООП годится, и чуть более чем полностью. Просто если у вас есть микроскоп и молоток, и вы умеете пользоваться и первым и вторым, то гвозди надо забивать молотком, а не микроскопом, а не ныть что микроскоп никуда не годится.
А если компилятор вам в руки дает некоторую фичу, то не надо возводить ее в абсолют, а потом собирать геморрой навроде "да я хер его знает ваще в каком нэймспейсе и каким образом перегружен этот метод".
Весь геморрой возникает от того что недисциплинированным программистам дали в руки большие возможности, но не обьяснили чем это чревато.
>> 2. любой проект на паскале и тем более большой и сложный проект, компилируется быстрее, чем С и С++, это идёт из свойств языка и компялятора
>> 5. С и С++ даёт иллюзию быстрой разработки кода, на самом деле они тратят много времени программиста
>
> Вы просто смешиваете в одну кучу проблемы трансляции и кодогенерации. В паскале
> используется шитый байт-код. Который можно точно так же генерировать и для
> C/C++.Вы проблему кодогенерации сюда сами приплели (и кстати, сто лет уже как не байт-код). Компилируется он действительно быстрее, но потому, что грамматика у С/С++ не LL(1) и не LR(1).
> Учите матчасть!
Действительно, учите.
> объясни профессиональным программистам, программирующим на этих языках, создающих не
> какие-то там поделия, а софт, бесперебойно и эффективно работающий годами.они со мной согласны
> не позорьтесь такими ляпамилюбой софт на паскале компилируется быстрее, чем на С и С++, тем более большие проекты
> приплыли. ваш опус был тонкой шуткой?это правда жизни
>любой софт на паскале компилируется быстрее, чем на С и С++, тем более большие проектыу вас, что есть проекты, примерно равные по объёму на сях и паскале, чтобы делать такого рода громкие выводы? в конечном итоге, меня всегда интересовала эффективность сгенерированного кода и его устойчивость, нежели время его компиляции. хотя да, у каждого свои мерки. нужно много раз компилировать? используем дополнительно ccache. нужно компилировать что-то покрупнее и распределенно, используем distcc.
вы, наверняка знаете об этом. да даже и не в этом дело. просто как-то не очень интенсивно развивается паскаль в последнее время, после слива конторы дядьки Нортона дельфей. хорошо хоть fp подтягивают понемногу. и хорошо, хоть энтузиасты его дальше развивают.
хотя да, можно и на ms basic писать программы, а потом их компилировать. и это тоже будет своего рода правдой жизни.
> Надо просто признать, что программирование на С и С++ не может быть
> эффективным и практичным. Потому что компиляторы требуют слишком больших процессорных
> ресурсов, эти языки выгодны Интелу и АМД, чтобы программисты и юзеры
> не ленились обновлять процы.
> Если хотим свободы, демократии, не зависимости, то необходимо уходить от неэффективных
> языков программирования С и С++ в пользу паскаля. В противном случае
> такие статьи будут появляться постоянно, а толку будет ноль.Это что, стеб?
По сабжу, ооп это индустриальный стандарт. Также можно и сказать о том, что винда провалилась на десктопах.
> программирование на С и С++ не может быть эффективным и практичным.ой! :)
>> программирование на С и С++ не может быть эффективным и практичным.
> ой! :)Ну что вы накинулись на человека, все правильно. например я люблю перл, но читая чужие исходники постоянно наталкиваюсь то на всякую "грязь", то на структуры которые заставляют задумываться. Читая тот же пхп, даже не умея на нем писать, я не помню когда приходил в ступор, все понятно и ребенку. Так же и сями, когда одно и тоже можно написать десятью способами, и есть профессор защитившей докторскую на том, что доказал, что 8-ой способ самый правильный - ну это просто бред и конятина в вакууме. паскаль намного проще, однообразнее и понятнее, на нем приятно и писать и читать. Но тут есть проблема, что возникает куча быдлокодеров, из-за легкого вхождения в язык, и думать нужно, на мой взгляд, именно над этим.
>> программирование на С и С++ не может быть эффективным и практичным.
> ой! :)ну дак приведите примеры задач, программирование которых на паскале буду менее эффективным, чем на С и С++
>>> программирование на С и С++ не может быть эффективным и практичным.
>> ой! :)
> ну дак приведите примеры задач, программирование которых на паскале буду менее эффективным,
> чем на С и С++А вы пример задачи для которой С менее эффективно чем Паскаль.
Задача - да любая! компилятор на С и С++ всегда будет более тормозным, чем паскалевский из-за устройства языка. Мой пример:int func1(){
printf("hello world!\n");
int f=6;
printf("f1=%d\n",f);
f=f+1;
printf("f2=%d\n",f);return(d);
}Такой код код компилятор на С и С++ будет компилить дольше, чем если сделать аналогичнеый алгоритм на паскале. Потому что в паскале раздел объявления переменных вынесен за код исполнения, раздел обявления подключаемых модулец тоже отделён от исполняемого кода в отличии от С и С++.
Прошу привести ваши пример задачи, кода, агоритма, которую компилятор на С и С++ откомпилит быстрее, чем паскаль.
>[оверквотинг удален]
> int f=6;
> printf("f1=%d\n",f);
> f=f+1;
> printf("f2=%d\n",f);
> return(d);
> }
> Такой код код компилятор на С и С++ будет компилить дольше, чем
> если сделать аналогичнеый алгоритм на паскале. Потому что в паскале раздел
> объявления переменных вынесен за код исполнения, раздел обявления подключаемых модулец
> тоже отделён от исполняемого кода в отличии от С и С++.Не вижу разницы, на таком примере разница времени компиляции в пределах ошибки измерения, а вот время выполнения зависит не от языка, а от компилятора, то есть конкретной реализации. но в целом разницы нет.
> Прошу привести ваши пример задачи, кода, агоритма, которую компилятор на С и
> С++ откомпилит быстрее, чем паскаль.Хм, а я разве пытаюсь доказать, что С быстрее? Как по мне разницы меж ними нет.
> А вы пример задачи для которой С менее эффективно чем Паскаль.Обучение детей.
>> А вы пример задачи для которой С менее эффективно чем Паскаль.
> Обучение детей.Вот как раз для обучения детей разницы нет вообще. Проверено на опыте, одно время преподавал программирование на С и ОбжектПаскале. С С было даже попроще.
> Надо просто признать, что программирование на С и С++ не может быть
> эффективным и практичным. Потому что компиляторы требуют слишком больших процессорных
> ресурсов, эти языки выгодны Интелу и АМД, чтобы программисты и юзеры
> не ленились обновлять процы.Да.
Надо переходить на интерпретируемые языки - вот где самая оптимальная компиляция)
> Да.
> Надо переходить на интерпретируемые языки - вот где самая оптимальная компиляция)каждому языку - свои задачу, кесарю кесарево
>> Да.
>> Надо переходить на интерпретируемые языки - вот где самая оптимальная компиляция)
> каждому языку - свои задачу, кесарю кесаревоВот только основная масса "опологетов" одного языка на кесарей не тянет, максимум на слесарей:)
>> Да.
>> Надо переходить на интерпретируемые языки - вот где самая оптимальная компиляция)
> каждому языку - свои задачу, кесарю кесаревоЭто было cat /dev/sarcasm =)
Потому что говорить про С, что "компиляторы требуют слишком больших процессорных ресурсов", это только 2 варианта:
1. Человек вообще не в теме и не сравнивал с другими языками.
2. Человек думает, что Visual Studio 2010 - это компилятор.
>"Я уверен, что ООП методологически неверна. Она начинает с построения классов. Это как если бы математики начинали бы с аксиом. Но реально никто не начинает с аксиом, все начинают с доказательств. Только когда найден набор подходящих доказательств, лишь тогда на этой основе выводится аксиома. Тоже самое и с программированием: сначала вы должны начинать развивать алгоритмы, и только в конце этой работы приходите к тому, что вы в состоянии сформулировать четкие и непротиворечивые интерфейсы.Сдается мне у этих ООП-фобов имеются нарушения мышления. В математике всегда начианли с гипотез, а в программировании с ТЗ.
Этого и следовало ожидать, исходя из нездоровой пресуппозиции в заголовке статьи.
> Сдается мне у этих ООП-фобов имеются нарушения мышления. В математике всегда начианли
> с гипотез, а в программировании с ТЗ.
> Этого и следовало ожидать, исходя из нездоровой пресуппозиции в заголовке статьи.Не только в математике. Взять, например, того же Эйнштейна, которого они обсирают в статье. Всё началось с аксиомы, что скорость света - это максимально возможная. И из этого уже пошли все выводы.
>> Сдается мне у этих ООП-фобов имеются нарушения мышления. В математике всегда начианли
>> с гипотез, а в программировании с ТЗ.
>> Этого и следовало ожидать, исходя из нездоровой пресуппозиции в заголовке статьи.
> Не только в математике. Взять, например, того же Эйнштейна, которого они обсирают
> в статье. Всё началось с аксиомы, что скорость света - это
> максимально возможная. И из этого уже пошли все выводы.Ответ неверный. Всё началось с опытных данных. Искались различные им объясненя, одним из вариантов оказалось предложение двух аксиом, из которых выведена СТО (кстати, там ничего не говорилось о скорости именно света, а просто о максимальной скорости c).
С заявлениями же Габриела насчет эфиродинамики на самом деле странно. В оригинальных английских документах про это ничего нет. Вот про "нормальную науку" Куна - есть, вполне адекватно. Возможно, что опять журналисты чего-то переврали.
>Ответ неверный. Всё началось с опытных данных.С данных да, но не с доказательств. Если нет гипотезы, то что доказывать то? =)
А если по такому принципы вы еще и программируете - возьмем какие-то данные и будем над ними всячески надругаться и смотреть что получится и куда это нас приведет, то я бы вас на работу не взял.
По такой методологии можно реверсингом заниматься, и то далеко не самый эффективный метод.
>>Ответ неверный. Всё началось с опытных данных.
> С данных да, но не с доказательств. Если нет гипотезы, то что
> доказывать то? =)А здесь Вы путаете математику и науку. В науке опытные данные - есть, в математике - нет. Голая абстракция. Степанов, говоря о доказательствах, не зря пишет, что именно в математике - см. http://www.opennet.ru/openforum/vsluhforumID3/71184.html#106 для более полного объяснения.
> А если по такому принципы вы еще и программируете - возьмем какие-то
> данные и будем над ними всячески надругаться и смотреть что получится
> и куда это нас приведет, то я бы вас на работу
> не взял.
> По такой методологии можно реверсингом заниматься, и то далеко не самый эффективный
> метод.А здесь Вы не только передергиваете (рассматриваемый подход совсем не есть "возьмем, надругаемся и посмотрим че будет"), но еще и на личности переходите, приписав собеседнику несуразицу. Нормальные аргументы кончились, что ли?
> А здесь Вы путаете математику и науку.Отлично! :-) Сразу вспоминаются слова Нильса Бора о том, что все науки делятся на физику и коллекционирование марок :-)
Тем не менее, что касается математики, мне гораздо ближе позиция Арнольда, в соответствии с которой математику следует рассматривать в неразрывной связи и как часть физики.
>> А здесь Вы путаете математику и науку.
> Отлично! :-) Сразу вспоминаются слова Нильса Бора о том, что все науки
> делятся на физику и коллекционирование марок :-)
> Тем не менее, что касается математики, мне гораздо ближе позиция Арнольда, в
> соответствии с которой математику следует рассматривать в неразрывной связи и как
> часть физики.Да не нужно её ни с кем рассматривать. И даже выражение "Математика - это язык" давно известно. Мне больше нравится цитата из незабвенного Виталия Светослововича:
"37. На языке математики можно легко расписать сколь угодно бредовые и парадоксальные утверждения. Математика вообще не содержит никакого критерия истинности - у неё есть только лишь критерий внутренней непротиворечивости - то есть, всего лишь грамматика языка."
>Всё началось с опытных данных. Искались различные им объясненя, одним из вариантов оказалось предложение двух аксиом, из которых выведена СТОРазвитие теории началось с аксиом. А аксиомы логично строить на основе полученных фактов. Так в геометрии мы можем взять за аксиому, что прямая - это окружность бесконечного радисуса и развить на этом теорию. Но на практике результаты её развития будут ... скажем бесполезны.
>>Всё началось с опытных данных. Искались различные им объясненя, одним из вариантов оказалось предложение двух аксиом, из которых выведена СТО
>
> Развитие теории началось с аксиом. А аксиомы логично строить
> на основе полученных фактов.Ну и чем это отличается от того, что я сказал? И от http://www.opennet.ru/openforum/vsluhforumID3/71184.html#106 ? :)
> Так в геометрии мы можем взять за аксиому, что прямая
> - это окружность бесконечного радисуса и развить на этом теорию. Но
> на практике результаты её развития будут ... скажем бесполезны.Нда? А Вы пробовали? :)) Такая аксиома очень смахивает именно на ту единственную отличавшуюся от евклидовой, что Лобачевский положил в основу своей геометрии. И которая вполне себе применяется на практике =))
>> Так в геометрии мы можем взять за аксиому, что прямая
>> - это окружность бесконечного радисуса и развить на этом теорию. Но
>> на практике результаты её развития будут ... скажем бесполезны.
> Нда? А Вы пробовали? :)) Такая аксиома очень смахивает именно на ту
> единственную отличавшуюся от евклидовой, что Лобачевский положил в основу своей геометрии.
> И которая вполне себе применяется на практике =))Ничего, что Лобачевский не вводил новых аксиом, а отказался от одной евклидовой, о параллельности прямых, и таки доказал весь набор теорем? Так что вводя новые аксиомы вы ни пользы не добьетесь, ни Лобачевскому не уподобитесь.
>>> Так в геометрии мы можем взять за аксиому, что прямая
>>> - это окружность бесконечного радисуса и развить на этом теорию. Но
>>> на практике результаты её развития будут ... скажем бесполезны.
>> Нда? А Вы пробовали? :)) Такая аксиома очень смахивает именно на ту
>> единственную отличавшуюся от евклидовой, что Лобачевский положил в основу своей геометрии.
>> И которая вполне себе применяется на практике =))
>
> Ничего, что Лобачевский не вводил новых аксиом, а отказался от одной
> евклидовой, о параллельности прямых, и таки доказал весь набор теорем?А врать зачем? Он не просто отказался, а именно заменил на свою ("...по крайней мере две прямые").
> Так что вводя новые аксиомы вы ни пользы не добьетесь, ни Лобачевскому
> не уподобитесь.А домыслы о том, чего я вводил или хотел, меня не интересуют.
> Взять, например, того же Эйнштейна, которого они обсирают
> в статье. Всё началось с аксиомы, что скорость света - это
> максимально возможная. И из этого уже пошли все выводы.Началось все, если мне не изменяет память, с того, что вычисления орбиты Меркурия не сходились с его наблюдаемой орбитой.
>>"Я уверен, что ООП методологически неверна. Она начинает с построения классов. Это как если бы математики начинали бы с аксиом. Но реально никто не начинает с аксиом, все начинают с доказательств. Только когда найден набор подходящих доказательств, лишь тогда на этой основе выводится аксиома. Тоже самое и с программированием: сначала вы должны начинать развивать алгоритмы, и только в конце этой работы приходите к тому, что вы в состоянии сформулировать четкие и непротиворечивые интерфейсы.
> Сдается мне у этих ООП-фобов имеются нарушения мышления. В математике всегда начианли
> с гипотез, а в программировании с ТЗ.
> Этого и следовало ожидать, исходя из нездоровой пресуппозиции в заголовке статьи.Это кривое переложение оригинала, вызванное журналистским стилем статьи, плюс незнание большинством основ научной методологии. Отключения мышления скорее случаются у ООП-фанатов, которые просто повторяют мантры своей религии, не думая. Даже ведь не увидели, что автор цитаты Степанов - второй создатель самого что ни на есть ООП Си++.
А Степанов математик, и знает, о чем говорит. То же самое происходит в любой науке: сначала есть только опытные данные, потом из них путем индукции формируются гипотезы и теории, затем эти теории дают какие-то дополнительные предсказания, которые можно проверить и подтвердить (уже польза) или опровергнуть.
Даже математика, которая не есть наука (а её язык), сам развивалась точно таким же образом - никто не начинал сразу с готовых гипотез. Простейший пример: арифметика известна тысячелетия, но аксиомы Пеано, формализовавшие её, были выведены только в XIX веке. И тогда уже стали возможны доказательства многих свойств натуральных и целых чисел, а также использование целых чисел для построения формальных теорий рациональных и вещественных чисел.
P.S. Да, кстати, постановка ТЗ не есть постановка гипотез, здесь неверная аналогия. Вот у Степанова верная - построение классов.
>Это кривое переложение оригинала, вызванное журналистским стилем статьиВообще-то это цитата, она в кавычках написана. Так что возражение не принимается.
>А Степанов математик, и знает, о чем говорит. То же самое происходит в любой науке: сначала есть только опытные данные, потом из них путем индукции формируются гипотезы и теории, затем эти теории дают какие-то дополнительные предсказания, которые можно проверить и подтвердить (уже польза) или опровергнуть.Здесь все верно, только надо уточнить: Сначала данные, потом гипотезы, потом доказательства, прогнозы, предсказания и т.д., потом выводы.
А теперь цитата Степанова:
>"Но реально никто не начинает с аксиом, все начинают с доказательств."Уже не буду говорить, что аксиомы никто не доказывает, иначе бы они
>P.S. Да, кстати, постановка ТЗ не есть постановка гипотез, здесь неверная аналогия.
где у меня написано, что это аналогия?
>Вот у Степанова верная - построение классов.Подозреваю, что у человека, занимающегося доказательствами аксиом все верно по определению, но с точностью до наоборот.
>>Это кривое переложение оригинала, вызванное журналистским стилем статьи
>
> Вообще-то это цитата, она в кавычках написана. Так что возражение не принимается.Вы забыли, что это хоть и цитата, но всё же не оригинал, а перевод.
>>А Степанов математик, и знает, о чем говорит. То же самое происходит в любой науке: сначала есть только опытные данные, потом из них путем индукции формируются гипотезы и теории, затем эти теории дают какие-то дополнительные предсказания, которые можно проверить и подтвердить (уже польза) или опровергнуть.
>
> Здесь все верно, только надо уточнить: Сначала данные, потом гипотезы, потом доказательства,
> прогнозы, предсказания и т.д., потом выводы.
> А теперь цитата Степанова:
>"Но реально никто не начинает с аксиом, все начинают с доказательств."А теперь вспомните о том, что математика - не наука. В науке опытные данные - есть, в математике - нет. И Степанов описывает, как делают в _математике_. Кстати, Вы еще и забыли о разнице гипотезы и теории, а также разнице аксиомы и постулата. В _науке_ теория именно что доказывается математически, исходя из постулатов, и только потом - идёт её верификация или фальсификация практикой. Это два разных процесса.
> Уже не буду говорить, что аксиомы никто не доказывает, иначе бы они
А кто-то где-то говорил, что _аксиомы доказывают_ ? Чушь редкостную придумываете.
>>P.S. Да, кстати, постановка ТЗ не есть постановка гипотез, здесь неверная аналогия.
>
> где у меня написано, что это аналогия?Цитирую Ваше #24: "В математике всегда начианли с гипотез, а в программировании с ТЗ". Если (в контексте начинания с аксиом и доказательств) это не аналогия, то что? :)
>>Вот у Степанова верная - построение классов.
> Подозреваю, что у человека, занимающегося доказательствами аксиом все верно по определению,
> но с точностью до наоборот.Поищите лучше нормальные аргументы, вместо приписывания собеседнику чуши.
> увидели, что автор цитаты Степанов - второй создатель самого что ни
> на есть ООП Си++.Степанов не создатель С++, а создатель STL. Язык С++ - не просто ООП, а мультипарадигменный. И STL использует не ООП парадигму, а т.н. "обобщённое программирование" - шаблоны С++. Где-то Страуструп упоминал, что из-за STL пришлось расширять механизм шаблонов. Это "обобщённое программирование" ближе не к ООП, а к функциональщине.
В частности, библиотека boost::lambda, реализующая на С++ самые, что ни на есть функциональные лямбды, хороша именно в соединении с STL/<algorithm>.
Эти незамысловатые факты и объясняют позицию Степанова, которая всегда была не ООП позицией. И никакого "сейчас он прозрел!!!" тут нет.
>> увидели, что автор цитаты Степанов - второй создатель
>> самого что ни на есть ООП Си++.
> Степанов не создатель С++, а создатель STL. Язык С++ - не просто
> ООП, а мультипарадигменный. И STL использует не ООП парадигму, а т.н.
> "обобщённое программирование" - шаблоны С++. Где-то Страуструп упоминал, что из-за STL
> пришлось расширять механизм шаблонов.Я процитирую еще раз, "второй создатель". Сами же подвтерждаете, что со Страуструпом они вместе работали. Придирка к словам, короче.
>>> увидели, что автор цитаты Степанов - второй создатель
>>> самого что ни на есть ООП Си++.
>> Степанов не создатель С++, а создатель STL. Язык С++ - не просто
>> ООП, а мультипарадигменный. И STL использует не ООП парадигму, а т.н.
>> "обобщённое программирование" - шаблоны С++. Где-то Страуструп упоминал, что из-за STL
>> пришлось расширять механизм шаблонов.
> Я процитирую еще раз, "второй создатель". Сами же подвтерждаете, что со Страуструпом
> они вместе работали. Придирка к словам, короче.Пан Страуструп говорил, что библиотека формирует язык, так может авторов буста в третьи создатели С++ отнесем? Степанов создатель STL и все, и уж никак не второй, так как STL не самая большая часть С++ но самая модная нынче.
>> Я процитирую еще раз, "второй создатель". Сами же подвтерждаете, что со Страуструпом
>> они вместе работали. Придирка к словам, короче.
>
> Пан Страуструп говорил, что библиотека формирует язык, так может авторов буста в
> третьи создатели С++ отнесем? Степанов создатель STL и все, и уж
> никак не второй, так как STL не самая большая часть С++
> но самая модная нынче.А зачем Вы продолжаете придираться к словам в нерелевантном контексте (в треде важно ли, что Степанов - человек неслучайный)? Что Вам это дает?
> А зачем Вы продолжаете придираться к словам в нерелевантном контексте (в треде
> важно ли, что Степанов - человек неслучайный)? Что Вам это дает?Я не продолжаю, я только встрял и счас пойду дальше пить чай, "особый, для родственников покойного"(С).
И ничего не дает, только скилл занудства немного повысится, а уровень желчи понизится.
Сорри что влез в интимную беседу, ухожу "а то по шее получу и подвиг свой не совершу"(С)
Проблемы здесь, мне кажется в сложности:
1) синтаксис с и с++ ужасен. нужно соблюдать стиль, не нагружать отдельные строки. поэтому разобраться в программе бывает сложно
нужен язык в котором программист обязан писать разборчиво. (например взять синтаксис питона, паскаля...)
2) в языках много лишнего, устаревшего, оставшегося для совместимости - что опять же позволяет писать кривые, глючные, не читаемые программы
3) куча терминов и понятий практически не позволяет объять все возможности языка одному человекуТ.е. уже сам язык, синтаксис, набор возможностей - должны способствовать тому, чтобы любой дурак мог в этом разобраться и компилятор тыкал его носом, если что.
Но при этом это должен быть язык не на виртуальной машине (нативный), и без автоматической сборки мусораКто-нибудь знает такой? (может shred skin до такого дорастет...)
> Проблемы здесь, мне кажется в сложности:
> 1) синтаксис с и с++ ужасен. нужно соблюдать стиль, не нагружать отдельные
> строки. поэтому разобраться в программе бывает сложно
> нужен язык в котором программист обязан писать разборчиво. (например взять синтаксис питона,
> паскаля...)
> 2) в языках много лишнего, устаревшего, оставшегося для совместимости - что опять
> же позволяет писать кривые, глючные, не читаемые программы
> 3) куча терминов и понятий практически не позволяет объять все возможности языка
> одному человекуДавайте перефразируем - ниасилил)
> Т.е. уже сам язык, синтаксис, набор возможностей - должны способствовать тому, чтобы
> любой дурак мог в этом разобраться и компилятор тыкал его носом,
> если что.Т.е. чтобы программировать мог любой дурак?
А вы хотите использовать программы, написаныне дураками?)> Но при этом это должен быть язык не на виртуальной машине (нативный),
> и без автоматической сборки мусораТак на то и есть C и, может быть, паскаль.
А будет код читаемым, или не читаемым - зависит от того, как вы его напишите.
>> Т.е. уже сам язык, синтаксис, набор возможностей - должны способствовать тому, чтобы
>> любой дурак мог в этом разобраться и компилятор тыкал его носом,
>> если что.
>
> Т.е. чтобы программировать мог любой дурак?
> А вы хотите использовать программы, написаныне дураками?)1. С каких пор лёгкость использования языка программирования -- да и вообще чего бы то ни было -- стали рассматривать как опасность?
2. Если программа работает, то пофигу, кто именно её написал. Если дурак сможет написать хорошо работающую программу, я буду хвалить и создателя языка (позволившего дураку этот язык использовать), и самогО дурака (за то, что пользовался хорошим языком). А вообще, последний вопрос, конечно, некорректен.
> 1. С каких пор лёгкость использования языка программирования -- да и вообще
> чего бы то ни было -- стали рассматривать как опасность?
> 2. Если программа работает, то пофигу, кто именно её написал. Если дурак
> сможет написать хорошо работающую программу, я буду хвалить и создателя языка
> (позволившего дураку этот язык использовать), и самогО дурака (за то, что
> пользовался хорошим языком). А вообще, последний вопрос, конечно, некорректен.знаете, буквально на днях я видел код который делает:
select * from table;
а потом в цикле начинает выбирать нужные значения (аля 1С, ага :) и при вопросе программисту: "что это за нафиг?", он говорит: "я хотел избавиться от эскуэль энжекшен", хватаешься за голову. Причем я такого ни разу не видел ни у перловых программеров, ни в сях, только у пхп-шников. да этот код делает, то, что в итоге требуется, но как...
паскаль, пхп, языки простые, вхождение в них легкое, читаются хорошо, все это замечательно и здорово, но как сделать так, что бы вот таких быдлкодеров там не было? т.е. быдлокодеры, это перво-наперво, проблема легких языков, где прочитал 10 страниц текста и ты уже программист.
>[оверквотинг удален]
> а потом в цикле начинает выбирать нужные значения (аля 1С, ага :)
> и при вопросе программисту: "что это за нафиг?", он говорит: "я
> хотел избавиться от эскуэль энжекшен", хватаешься за голову. Причем я такого
> ни разу не видел ни у перловых программеров, ни в сях,
> только у пхп-шников. да этот код делает, то, что в итоге
> требуется, но как...
> паскаль, пхп, языки простые, вхождение в них легкое, читаются хорошо, все это
> замечательно и здорово, но как сделать так, что бы вот таких
> быдлкодеров там не было? т.е. быдлокодеры, это перво-наперво, проблема легких языков,
> где прочитал 10 страниц текста и ты уже программист.Ага, видимо чтото личное :-)
>>но как сделать так, что бы вот таких там не былоНе нанимать их на работу?
А если вы не наниматель или не лицо, имеющее голос при найме - не лезть в чужое дело?
Вам что за забота, если где-то когда-то у кого-то "плохие кодеры" 1С/2С/3С/4А?
Это полностью дело владельца бизнеса. И даже если у него в офисе кофе не в тех стаканчиках подают, тоже не ваше, в общем-то дело.
Заведите свой бизнес, свой кофе, свои стаканчики и своих программистов.
И тогда вот уже задавайтесь гамлетовскими вопросами.
>>>но как сделать так, что бы вот таких там не было
> Не нанимать их на работу?
> А если вы не наниматель или не лицо, имеющее голос при найме
> - не лезть в чужое дело?
> Вам что за забота, если где-то когда-то у кого-то "плохие кодеры" 1С/2С/3С/4А?
> Это полностью дело владельца бизнеса. И даже если у него в офисе
> кофе не в тех стаканчиках подают, тоже не ваше, в общем-то
> дело.
> Заведите свой бизнес, свой кофе, свои стаканчики и своих программистов.
> И тогда вот уже задавайтесь гамлетовскими вопросами.Большое мне дело, у меня эти кодеры серваки грузят своим кодом.
> 1) синтаксис с и с++ ужасен. нужно соблюдать стиль, не нагружать отдельныеУ Си нету "стиля" и "симпатсиспса" или что вы там имели ввиду.
На свете, вообще, есть одна-единственная вещь: РЕАЛЬНАЯ СРЕДА ИСПОЛНЕНИЯ.
И Си, и неси должны исходить из ее реалий и больше не из чего.
ЧТО там на уровне сырца - всем до фонаря.
"Стиль" нужен только для того, чтобы твой код можно было безболезненно для глаз и рассудка интегрировать в сторонний проект. Это дело совести каждого отдельного персонажа, а не качества бинаря или всей пачки сырцов вообще.ЧИТАТЬ ВСЕМ ТРИСТА РАЗ. Там, глядишь, научитесь жить без корок и со взаимодействием написанных с разрывом в пять лет модулей.
"Hello World! как ему СЛЕДУЕТ быть на C в Linux"
http://habrahabr.ru/blogs/nix_coding/75971/
> "Стиль" нужен только для того, чтобы твой код можно было безболезненно для
> глаз и рассудка интегрировать в сторонний проект. Это дело совести каждого
> отдельного персонажа, а не качества бинаря или всей пачки сырцов вообще.да нет же, как твое ваяние будут модифицировать и исправлять ошибки, если у тебя все в одну строчку написано?, да проще забить и не использовать такой быдло код, чем разбираться в нем.
АДА подойдет?
=)
Черт, заголовок не показывается:
Ну ка, быстро, все взяли и переписали Qt в процедурном стиле!
> Черт, заголовок не показывается:
> Ну ка, быстро, все взяли и переписали Qt в процедурном стиле!Из того, что Роллс Ройс провалился на рынке не следует, что каждый отдельный экземпляр Роллс Ройса - никудышный.
Парадигма ООП требует директивного переосмысления, причем средствами и силами идеологов ООП.
ООП в существующем виде не предлагает конструктивной идеологии и руководства к смене стиля планирования проекта.ООП должна быть снабжена надстройкой, полностью отвязанной от кода вообще и оперирующей правилами построения пространств имен и директивными правилами построения очередей инициализации методов.
ООП провалился? Цыфры? Факты? Я наблюдаю, что он успешен как никогда.Ну да, ну да, у нас в стране школие и дальше будут учить писать пузырька и исключительно функциям. От того все такие темные и никудышные программисты.
Любой большой проект, просто ну никак не обходится без ООП, даже когда его пишут на не-ООП языке, то все равно пытаются изобретать некие подобия объектов, и следовать определенным методикам, похожим на ООП. В большом программировании без ООП никуда, ну а пузырьки и дальше функциями делать никто не запрещает.
> Любой большой проект, просто ну никак не обходится без ООП, даже когда его пишут на не-ООП языке, то все равно пытаются изобретать некие подобия объектов, и следовать определенным методикам, похожим на ООП. В большом программировании без ООП никуда, ну а пузырьки и дальше функциями делать никто не запрещает.Если размер проекта определяется количеством "леммингов", его окучивающих, то безусловно без ООП никак не обойтись.
А "толпа леммингов", как известно, не может ошибаться. И другие аргументы, кроме "размеров" и "количества", "леммингам" не понятны и не нужны.
> Любой большой проект, просто ну никак не обходится без ООП, даже когда
> его пишут на не-ООП языке, то все равно пытаются изобретать
> некие подобия объектов, и следовать определенным методикам, похожим на ООП. В
> большом программировании без ООП никудаСогласен, ведь glib-стить - это тоже по сути ООП, но на чистых сях. Так что ООП как подход для проектирования действительно уже стал стандартом. А вот конкретные реализации его - дело скорее личных предпочтений.
>Любой большой проект, просто ну никак не обходится без ООП, даже когда его пишут на не-
>ООП языке, то все равно пытаются изобретать некие подобия объектов, и следовать
>определенным методикам, похожим на ООПРасскажите нам о внутренностях компиляторов - где там объекты, полиморфизм, наследование. В инкапсуляцию я еще могу поверить. Можете еще рассказать о ядрах *nix-подобных ОС и показать, где там ООП ( только про VFS не надо - так и быть - будем это считать за ООП ). Можете еще рассказать о внутренностях РСУБД - где и как ООП применяется, к примеру, в разборе SQL или оптимизаторе.
>В большом программировании без ООП никуда, ну а пузырьки и дальше функциями делать никто
>не запрещает.Когда в руках молоток, любая задача кажется гвоздем (с) народ. От себя добавлю: как бы я хотел, чтобы шурупы стали наконец-то закручивать, а не забивать!
Быдлокодеры не понимают, что такое "планирование проекта". Для них план - это некое соответствие видимой для них части физического мира (в лучшем случае). Отсюда объекты для них предсталяются аналогами физческих контейнеров для свойств и процедур. Ой пардон, не процедур, а даже методов! Самые продвинутые даже мыслят на уровне абстракции передаваемых сообщений, опять таки по аналогии с физическим миром, более для них понятным.> Ну ка, быстро, все взяли и переписали Qt в процедурном стиле!
А поскольку дальше процедур они в своем понимании так и не продвинулись, хоть и думают, что они понимают, что такое объекты и сообщения, поэтому они считают, что если не ООП, то процедурное, другого по их мнению не дано.
>Отсюда объекты для них предсталяются аналогами физческих контейнеров для свойств и процедур.А для вас они чем представляются?
>>Отсюда объекты для них предсталяются аналогами физческих контейнеров для свойств и процедур.
> А для вас они чем представляются?Базовые понятия ничем не представляются, поскольку сами служат для представления чего-то.
Почувствуйте разницу.Хотя у некоторых, и даже у большинства, они чем-нибудь да представляются. Так как "база" у них центрируется вокруг "физико-бытовых" понятий.
>Базовые понятия ничем не представляются, поскольку сами служат для представления чего-то.Первое утверждение ни каким боком не следует из второго.
Даже наоборот. Как можно представить некое понятие при помощи неких элементарных понятий, которые не имеют никакого представления? =)
>>Базовые понятия ничем не представляются, поскольку сами служат для представления чего-то.
> Первое утверждение ни каким боком не следует из второго.Согласен.
Даже следует признать, что второе утверждение было вообще неверным.> Даже наоборот. Как можно представить некое понятие при помощи неких элементарных понятий, которые не имеют никакого представления? =)
Во всех случаях следовало бы сказать, что "представление" и "понимание" - совсем разные вещи.
По крайней мере, возвращаясь к исходному вопросу, если представлять базовые понятия контейнерами, получится очень узкий взгляд на мир, очень частная теория, и очень ограниченные реализации соответствующих этому языков. Даже ООП идет гораздо дальше, не говоря уже о других альтернативах.
>>>возвращаясь к исходному вопросуЕще раз для всех.
Развёрнутый "холивар" НИКАКОГО отношения НИ К КАКОЙ страничке сырца НИКАКОГО компилятора/претатора НЕ ИМЕЕТ.Чего все вперлись в "процедуры" и обсуждения "объектности" или "необъектности" каких-либо диалектов чего бы то ни было вообще???
"Провал ООП" состоит в следующем - однажды персонажи, работающие над энд-юзер сервисом чего бы то ни было начинают вопить: "Какого иуха в сраном виджете вашего сраного фреймворка от вашего сраного АПИ мы не можем получить значений свойства ХХХ??? Мля!!!"
Вот он, "провал".
И суть в том, что "ООП" средства и ООП парадигма не всегда дают преимущества в разработке внятного мидлвера, с которым не будет плясок с бубнами. Более того, они их просто не имеют.Вот и вся суть.
То есть, много лет подряд, АПИ к чему-либо большому и красивому - ВСЕГДА ОБЪЕКТНЫЙ!
Это требование жизни. По другому принципиально не выходит. АПИ иначе превращается в восемь тонн перепутанных макарон.А вот ПРЕИМУЩЕСТВ в реализации фреймворка/мидлвера, этот красивый АПИ предоставляющего, "ООП инструментарий" ну, не имеет :) Хоть на ассемблере рисуй, лишь бы АПЯ работала в соответствии с собственными же заявками и спецификациями.
Об этом и заметка.
По теме очень рекомендую лекцию Рича Хики:
видео: http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey
слайды: http://clojure.googlegroups.com/web/AreWeThereYet.pdf
В ООП несильная инкапсуляция (в процедурах и функциях она гораздо сильнее).
В ООП красивая идея полиморфизма (позднего связывания кода) прикрыта от глаз программиста костыльными техническими деталями (для процедурного кода нужно думать о реальной таблице виртуальных методов, если нужно позднее связывание кода).
Но самое ужасное в ООП это наследование: оно неочевидно и разрушает инкапсуляцию.
)) хех если бы все начинали изучать ООП с прородительских языков то 100 пудов он никому не нужен был быпс: изучайте асм
> )) хех если бы все начинали изучать ООП с прородительских языков то
> 100 пудов он никому не нужен был бы
> пс: изучайте асм)) хех если бы прородители чаще общались с детьми, пока родители на работе, то дети 100 пудов лучше бы знали "чисто человечий язык", и не пытались бы его плохое знание скомпенсировать плохим знанием "компов", думая что они еще и "проги" умеют писать
пс: не сидите много за компом
> )) хех если бы все начинали изучать ООП с прородительских языков то
> 100 пудов он никому не нужен был бы
> пс: изучайте асмПо крайней мере у борландовского турбо-ассемблера есть настоящее ООП расширение. Искаропке. Охеренно удобная и полезная штука. Я пользовался и был в полном восторге.
У, какая холиварная тема. Сейчас програмеры все копья сломают. Вброс эпичен! :-)
Эпично, что копья будут ломать об автора вброса главным образом.
> У, какая холиварная тема. Сейчас програмеры все копья сломают. Вброс эпичен! :-)Тема то ладно. А сама заметка то какова. В такой маленький объем запихать столько бреда не только про программирование, а еще и про кучу вещей. Даже по нашим бредовым временам это достижение.
В общем лишний раз убедился что программисты полные придурки, отсюда и столько проблем с программированием. Ибо все проблемы мы создаем себе сами.
Там в комментах автор отписался. Если кто не читал (не видел, по ссылкам не ходил), вот:На самом деле, эта статья – чисто исторический обзор двух известных выступлений “Почему ООП провалилась“ и “Почему ООП не провалилась“ – здесь не даётся анализ самих парадигм и собственно программирования, и такая цель даже близко не ставилась. Просто забытая история… которую порой, по моему мнению, очень полезно напомнить современникам. Что касается самой сути дефектов ООП и альтернатив – в статье огромное количество ссылок на так называемую конкретику, и желающие (реально ЖЕЛАЮЩИЕ разобраться) найти альтернативу могут попытаться это сделать вмести с этими известными людьми, все эти работы написавшими.
И, наконец, статья писалась для печатного издания (и она, думаю, выйдет в печать уже в октябре), поэтому был очень жесткий лимит по размеру – не более 8-9 тысячи знаков с пробелами. Поэтому пришлось вот так вот всё жестко втиснуть в эти пределы, пожертвовав глубиной погружения в суть программистского вопроса, в пользу просто исторического обзора события. Но опять же: желающему копнуть – ссылок умышленно насеяно немеряно :-)
Единственная действительно нерешаемая средствами ООП проблема это желание "опологетов" все решать средствами ООП и стремление засунуть ООП куда надо и куда не надо. Впрочем это к любой парадигме программирования относится.
> Единственная действительно нерешаемая средствами ООП проблема это желание "опологетов" все решать средствами ООП и стремление засунуть ООП куда надо и куда не надо. Впрочем это к любой парадигме программирования относится.И не говорите! Да что там парадигмы! Эти программисты вообще стремятся везде засунуть эти ужасные языки программирования.
А потом людей, которые привыкли много и тяжело работать увольняют толпами за ненадобностью, не смотря на их стаж и трудовые книжки!
Безобразие!
>> Единственная действительно нерешаемая средствами ООП проблема это желание "опологетов" все решать средствами ООП и стремление засунуть ООП куда надо и куда не надо. Впрочем это к любой парадигме программирования относится.
> И не говорите! Да что там парадигмы! Эти программисты вообще стремятся везде
> засунуть эти ужасные языки программирования.А еще серебряную пулю и Красную Кнопку!
> А потом людей, которые привыкли много и тяжело работать увольняют толпами за
> ненадобностью, не смотря на их стаж и трудовые книжки!
> Безобразие!Ага. А иногда ООПисты пытаются вообще все решать с ООП. Вот где жесть.
Мне на полном серьезе рассказывали, что жить надо по ООП...
гыгы. давайте еще поговорим о вреде с, с++, компилятора g++ как оплота ревизионистов ;-D
Объектно-ориентированому программированию должен предшествовать объектно-ориентированый анализ и объектно-ориентированое проектирование программного комплекса. В противном случае объектно-ориентированое программирование малоэффективно!
> Объектно-ориентированому программированию должен предшествовать объектно-ориентированый
> анализ и объектно-ориентированое проектирование программного комплекса. В противном
> случае объектно-ориентированое программирование малоэффективно!Для некоторых задач оно в принципе неэффективно. Пихать направо и налево ООП это все равно что пытаться все на свете задачи реализовать на канонiчном бейсике. Есть задачи, есть инструменты с помощью которых эти задачи эффективно и правильно решаются.
Базару нет, хелловорлд можно накодерасить "правильно" и на ООП как приведено по ссылке выше. Но если стоит задача вывести на консоль хелловорлд, то не проще вообще файл c таким именем создать и сказать ls ?
ООП -- это здорово, но не надо от него "отталкиваться".Вот, например, появилась у манагера задача.
Он разбил ее на несколько модулей и распределил разработчикам.
Тут всё разумно (сверху вниз).Один разработчик, начинает кодить как-то работающий прототип.
Потом код будет по ходу дела застывать и сам проситься его обобщить:
вынести повторы в функцию
или "if-esif-elsif-elsif" заменить вызовом виртуального метода.А другой разработчик увидел, как всё классно на объектах закручено.
Загорелся, решил круто замутить, классов сразу десяток сделал, а потом код распихивать начал. А обстановка то по ходу меньется.Думаю, что у первого в итоге код будет ясней, короче, эффективней, надёжней и т. п. И элементы ООП там по необходимости будут.
А язык -- это инструмент.
Он должен не навязывать какую-то одну парадигму (как ООП),
а давать возможности (лёгкость эволюции, поддержки).Хотя с позиции "генерального пастуха" всё может выглядеть совсем по-другому.
По моему все таки самое важное не парадигма, а уровень программиста. Невдумчивый при любой парадигме напишет криво работающую и нечитабельную программу. Для хорошего программиста же важно лишь чтобы в языке были нужные для задачи возможности. Хотя и синтаксис имеет значение... Сейчас начинаю все больше ценить читабельность языка - дольше просматриваю С++ и Perl код по сравнению с чистым С или с Паскалем. Паскаль хоть и читабельный, но по мне так слишком многосимвольный, все эти словесные begin/end надоедает набирать. Чистый С неплох, но часто ниже уровнем чем мне надо. Так и сижу на С++, стараясь писать читабельнее, больше комментировать, делить программу на малосвязанные блоки, очень редко использовать наследование, не переопределять стандартные типы, контролировать исключения в конструкторах и т.п.
В тему:
http://cs.mipt.ru/docs/comp/rus/develop/other/stroustrup_int...
> В тему:
> http://cs.mipt.ru/docs/comp/rus/develop/other/stroustrup_int...Ну бред же...