[LOR] Роб Пайк дал оценку Java и C++

[sciko]

чорд, неужели есть люди действительно верящие в ООП как в что-то особое?

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

[watashiwa_daredeska]

А вот это всё не нужно. Функциональное программирование рулит!

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

люди действительно верящие в ООП как в что-то особое?

Ну, во-первых, верить совсем не обязательно. Ты веришь в теорему Пифагора? А тензорное исчисление -- оно особое? Ты в него веришь?

[diesel]

люди действительно верящие в ООП как в что-то особое?

Ну, во-первых, верить совсем не обязательно. Ты веришь в теорему Пифагора? А тензорное исчисление -- оно особое? Ты в него веришь?

хм. "Министерство образования рекомендует новый учебник Геометрии для 6-11 класса, теперь с теоремой Пифагора"? было бы интересно комменты к такой новости почитать (: а с ООП прокатывает

[watashiwa_daredeska]

было бы интересно комменты к такой новости почитать (:

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

[sciko]

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

Аргумент "сперва добейся"? Вот это действительно не смешно, а грустно.

Ты веришь в теорему Пифагора?

Теорему можно доказать. А целесообразность ООД нельзя. Именно целесообразность, а не возможность. Остаётся только верить.

Замечу что я не против ООП: иногда она полезно (например, при проектировании GUI). Но это очень редкие случаи. В остальных случаях его целесообразность весьма сомнительна.

[watashiwa_daredeska]

Аргумент "сперва добейся"?

Нет, аргумент "знай, о чем говоришь".

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

Сборка мусора не нужна? И это говорит тот, кто заявляет "ФП рулит"? Покажите мне язык ФП без GC, посмотрю хоть на один.

[watashiwa_daredeska]

Теорему можно доказать. А целесообразность ООД нельзя.

ООД или ООП? О чем мы сейчас говорим?
Целесообразность -- вообще штука, зависящая от времени и условий. ДВС целесообразны, пока есть химическое топливо и их количество позволяет нормально существовать, а не травиться выхлопными газами. Да, есть трамваи, троллейбусы, самолеты на солнечных батарейках, но это всё капля в море ДВС. Лет через 50, наверное, будет по другому. С ООП примерно то же самое. На данный момент это целесообразно, ибо ничего другого, что показало бОльшую целесообразность нет.

[sash-kan]

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

в ядре (которое на kernel.org хостится) ооп применяется?

[watashiwa_daredeska]

в ядре (которое на kernel.org хостится) ооп применяется?

Да.

[diesel]

было бы интересно комменты к такой новости почитать (:

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

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

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

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

вместо:

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

[watashiwa_daredeska]

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

Не спорю. Но ведь это не проблема ООП, правда? Это проблема "разговора".

[sciko]

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

Названия Darcs и Xmonad о чём-то говорят?

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

А вот как это сделать, я представления не имею. Даже мыслей нет

Покажите мне язык ФП без GC, посмотрю хоть на один.

LISP?

ООД или ООП? О чем мы сейчас говорим?

Давайте определимся, т.к. вы-таки прыгаете от ООП к ООД и обратно.

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

Тысячи хомячков не могут ошибаться! Тогда единственно хорошей ОС надо признавать винду.

в ядре (которое на kernel.org хостится) ооп применяется?

Да.

И где, кроме интерфейсов для ООЯП?

ООП рассматривается как нечто спущенное с небес на землю, а не как продолжение разговора. поэтому часто и применяется "ООП ради ООП".

+1.

[Nazyvaemykh]

sciko,
если мне не изменяет память, LISP — первый язык со сборкой мусора, и один из первых — с ООП.

А управление окошками вряд ли можно считать достаточно сложной задачей.

[watashiwa_daredeska]

ну то есть говоря про ООП мы слышим:

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

вместо:

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

А вот тут есть большая разница. Вторая цитата относится к относительно маломасштабному коду. А ООП начинает играть существенную роль на больших масштабах.

[deadhead]

И где, кроме интерфейсов для ООЯП?

VFS, например... если мне память не изменяет :-)

[watashiwa_daredeska]

Названия Darcs и Xmonad о чём-то говорят?

Это мелочи, ни о каких миллионах строк речь не идет даже близко. На C Торвальдс за неделю "аналог" Darcs накорябал, когда приспичило -- Git называется.

А вот как это сделать, я представления не имею. Даже мыслей нет

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

Мне известен один такой случай, достаточно известный: платформа для создания интернет-магазинов, проданная в итоге Yahoo, который, по слухам, переписал-таки ее на C++ в итоге. Исходную систему писал Пол Грэхем (среди прочих) на LISP, и по его словам, ключевым было не ФП, а метапрограммирование. Не знаю (не помню), кстати, как там насчет ООП было. Думаю, CLOS они таки использовали, хотя это не обязательно ООП.

Покажите мне язык ФП без GC, посмотрю хоть на один.

LISP?

На этом я, думаю, могу закончить дискуссию. Вы никогда в глаза не видели LISP, а если и пользовались ФП, то как-то очень странно.

Давайте определимся, т.к. вы-таки прыгаете от ООП к ООД и обратно.

Лично я говорю об ООП, а не ООД. Если где-то это не так, поправьте.

Тысячи хомячков не могут ошибаться!

По губам: целе сообразность. Какова цель?

И где, кроме интерфейсов для ООЯП?

А в ядре есть интерфейсы для ООЯП? Это int 80h что-ли? А примером ОО, например, являются файловые дескрипторы разных видов, вместе с ioctl'ами.

[sciko]

если мне не изменяет память, LISP — первый язык со сборкой мусора, и один из первых — с ООП.

Он вообще один из самых первых. Бейсик появился позже его.
Но за это время понаделали массу его вариантов. Есть, например, вариант с region inference (RI) вместо классического GC. И, да, я знаю, что RI лучше подошёл бы к чисто функциональному языку типа Haskell.
Ещё упомяну такие страшные слова как escape analysis и static reference counting.

[watashiwa_daredeska]

VFS, например... если мне память не изменяет :-)

Чёрт, я опоздал :)

Есть, например, вариант с region inference (RI) вместо классического GC.

Ok, уговорили. Признаю неточность в своих формулировках. Я имел в виду automatic memory management, а не конкретно GC.

[sciko]

Это мелочи, ни о каких миллионах строк речь не идет даже близко.

Ну, может миллионов и не будет, но тысяч 20-50 строк будет. А это довольно много. Особенно для ФП. Кроме того, проект вполне себе живёт, имеет фичи, которых тот же git не имеет и пока даже не планирует, и умирать не собирается.

На C Торвальдс за неделю "аналог" Darcs накорябал, когда приспичило -- Git называется.

То-то я смотрю, что его до сих пор доделывают ^_^

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

О! Расскажите как по ним можно оценить хотя бы

возможности повторного использования

А примером ОО, например, являются файловые дескрипторы разных видов, вместе с ioctl'ами.

Вот это как раз пример ООД. И совсем не обязательно, что его реализовали с помощью ООП.

По губам: целе сообразность. Какова цель?

В том-то и дело, что целесообразность и распространённость совсем разные вещи.
Целесообразность вообще может быть применена только к определённой задаче.

Я имел в виду automatic memory management, а не конкретно GC.

А я и не имею ничего против automatic memory management в целом. Я против GC.

[deadhead]

Вот это как раз пример ООД. И совсем не обязательно, что его реализовали с помощью ООП.

В силу

Object-oriented design is the process of planning a system of interacting objects for the purpose of solving a software problem. It is one approach to software design.

Источник

Object-oriented programming (OOP) is a programming paradigm that uses "objects" – data structures consisting of data fields and methods together with their interactions – to design applications and computer programs

Источник
Не очень понятно в чем именно заключается пример ООД и каким образом это можно реализовать не с помощью ООП?

[sciko]

Не очень понятно в чем именно заключается пример ООД и каким образом это можно реализовать не с помощью ООП?

Приведу пример. Есть такая библиотека GTK+. Она написана на C. С весьма не ООЯП. Но сама библиотека является объектно-ориентированной. Т.е. есть ООД, но нет ООП. Надеюсь понятно.

[deadhead]

Приведу пример. Есть такая библиотека GTK+. Она написана на C. С весьма не ООЯП. Но сама библиотека является объектно-ориентированной. Т.е. есть ООД, но нет ООП. Надеюсь понятно.

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

P.S.

Функциона́льное программи́рование — раздел дискретной математики и парадигма программирования, ...

Источник

Объе́ктно-ориенти́рованное программи́рование (ООП) — парадигма программирования, в которой ...

Источник

Или вы оперируете этими понятиями в каком-то ином смысле?

[sciko]

то что в языке нет поддержки ООП не означает, что эту парадигму программирования нельзя реализовать

ZOMG! Тогда любой структурный ЯП одновременно является и ООП. Потому, что на нём можно реализовать эту парадигму и ещё массу других. Но это откровенно глупое и бесперспективное занятие.

[deadhead]

ZOMG! Тогда любой структурный ЯП одновременно является и ООП. Потому, что на нём можно реализовать эту парадигму и ещё массу других. Но это откровенно глупое и бесперспективное занятие.

ага.
Обратный эффект, видимо, тоже имеет место быть...

[watashiwa_daredeska]

Ну, может миллионов и не будет, но тысяч 20-50 строк будет. А это довольно много. Особенно для ФП.

Вот Вы всё противопоставляете ФП и ООП, однако это совершенно перпендикулярные вещи. Абсолютно pure functional программа может быть в то же время вполне себе object oriented (в Haskell есть классы и все причиндалы для ООП, например). ФП основывается на lambda calculus, которое, фактически, есть альтернативная основа для описания вычислений, как машина Тьюринга. ООП не является такой основой.

Итак, 20-50 тыс. строк — много для ФП. Это много и для процедурного подхода. Для ОО подхода — это мелочь. К тому же, один инструментик (Darcs, Xmonad, ...) — недостаточно сложная система. Вот POSIX-compliant OS — уже более-менее сложная, особенно если применима для решения каких-либо реальных потребностей, кроме игры и обучения (вроде Minix).

Есть такая библиотека GTK+. Она написана на C. С весьма не ООЯП. Но сама библиотека является объектно-ориентированной. Т.е. есть ООД, но нет ООП.

ООП в GTK+ тоже есть, к слову. Для ООП не обязательна языковая поддержка, хотя она и помогает.

[watashiwa_daredeska]

Не очень понятно в чем именно заключается пример ООД и каким образом это можно реализовать не с помощью ООП?

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

STL. Если почитать справку по STL, то там фигурирует такое понятие, как «concept», и все сущности отнесены какой-нибудь «концепции», будь то Forward Iterator, Unary Function, Reversible Container или еще что. Однако, в реализациях (до последнего времени, во всяком случае) эти «concept» никак не фигурировали вообще.

Вот это как раз пример ООД. И совсем не обязательно, что его реализовали с помощью ООП.

Пусть так. Однако, наличие некоего ПО «ядро Linux», пусть даже написанного абсолютно без использования ООП, абсолютно не говорит в пользу точки зрения «ООП не нужен, ФП рулит». Хотя бы потому, что:
1. Отсутствие X в Y[i] не говорит о ненужности X, особенно, если X есть в Y[0..i-1,i+1..100500].
2. Отсутствие X в Y[i] не говорит о том, что Z рулит, особенно, если этого Z в Y[i] ещё меньше, чем X, которого нет :)

Целесообразность вообще может быть применена только к определённой задаче.

Поправьте меня, если я не прав:
1. Вы утверждаете, что ООП не нужен.
2. Т.е. ООП нецелесообразен во всех задачах, где он используется.
3. Т.е. вокруг одни сплошные безграмотные уроды, один Вы — белый, пушистый и Эйнштейн.

А я и не имею ничего против automatic memory management в целом. Я против GC.

Уф, ну хоть на этом почти сошлись. Однако, опять же, я не согласен с ненужностью GC. Хотя бы потому, что альтернативные способы AMM не покрывают все потребности во всех сферах, где работает GC, лучше GC.

Тогда любой структурный ЯП одновременно является и ООП.

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

[t.t]

это плохо стыкуется с тем, что Dalvic

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

Я несколько не о том. Понятно, что Dalvic — виртуальная машина, а не язык. Вопрос в другом. По отзывам очевидцев, код, нормально выполнявшийся как в Sun JRE, так и в bochs, Dalvic выполнять отказывался; и наоборот: после доработки «для Dalvic» код перестаёт выполняться в первых двух. Другими словами, Dalvic это не совсем виртуальная машина Java; а скорее виртуальная машина для «языка, похожего на Java». Вот об этой несовместимости я и говорил — о несовместимости языков. Возможно, меня ввели в заблуждение; в таком случае буду благодарен за обоснованное опровержение.

[t.t]

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

Object Oriented Design != Object Oriented Programming.

Я и не ставил между ними знака равенства. Но разве это неравенство опровергает сказанное?

[t.t]

было бы интересно комменты к такой новости почитать (:

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

И какое отношение «ненужность в школе» имеет к «ненужности в принципе»?

[watashiwa_daredeska]

Вот об этой несовместимости я и говорил — о несовместимости языков.

Ну, что поделать, бывают косяки. Сделали компилятор, который компилит не совсем Java в совсем не Java :) Тут еще вопрос, является ли это нарушением спецификации языка, или это какая-нибудь хрень в стиле C-шного f(i,++i) или a[i++]=b[i++]. Ведь у Java есть спецификация, которой нужно следовать, а не reference implementation, как у Python, скажем.

И какое отношение «ненужность в школе» имеет к «ненужности в принципе»?

Это имеет отношение к тому, что холивар о нужности/ненужности можно раздуть вокруг чего угодно, хоть ООП, хоть интегрального исчисления, а буде образование и дальше в ту же сторону будет двигаться, то и до теоремы Пифагора дело дойдет :)