LINUX.ORG.RU

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

 


2

7

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

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

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

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

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

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

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

>Интересно, можно ли (маленькую) прогу на форте затолкать в 64 байта оперативки и 1024 байт ПЗУ?

Вполне. Я видел полноценную Форт-систему в 512байтах ПЗУ. Правда, оперативки там было 2к, но Форт мало совсем использовал.

Грамотно спроектированная Форт-система начиная с какого-то размера компактнее машкодовой выходит.

жцц может занять 2ГБ оперативы, инлайня и оптимизуя


Может. Но это сегодня. Когда я использовал компактные Форт-системы, даже 64кбайт оперативки было роскошью :)

А сегодня, с другой стороны, нет никакого смысла в 512 байт или 1к ПЗУ утыкаться. Самые голимые копеечные однокристаллки могут на порядок больше иметь.

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

форт еще как-то можно спасти, если тэги хранить где-то параллельно...

Если посмотреть на Factor, который и динамически типизирован и имеет статические типы с кое-киким выводом (прям стэковый CL какой-то) то можно замететь, что автор действительно испытал сильное влияние SBCL ;) там такие же tagged pointers - в принципе это тот же подход что и структуры с полем типа, только более гибкий - тегируются («толстые») указатели на данные а не сами данные, при этом integers тоже 29 битные как и в SBCL ;D

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

>прикольно наблюдать, как фортеры пыхтят и реализуют тривиальный (общеизвестный) механизм :-)

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

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

> Двадцать лет назад пионэры страдали похожей фигней. Можно ли сделать рекурсию на бейсике (классическом, который с номерами строк и GOSUB)? Пионэры радовались как пионэры, когда им удавалось рекурсивно слепить какую-нибудь «ханойскую башню». На вопрос: «А фигли толку с вашей рекурсии в бейсике?» - вот точно также радостно лыбились: «Но ведь можно же!» и доказывали, что в бейсике рекурсия самая правильная: «ведь реализована средствами языка, и всё-всё подконтрольно программисту».

Двадцать лет назад выпускали книги, как написать систему управления базами данных на raw-devices (без файловой системы) на Бейсике. Жаль, не помню названия.

Ключевые слова: Бейсик, База данных, raw-device, печатная книга

P.S. «Вы слишком много кушать! В смысле: зажрались.»//

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

>Двадцать лет назад выпускали книги, как написать систему управления базами данных на raw-devices (без файловой системы) на Бейсике.

C рекурсией? Потому как бейсик без рекурсии, всеравно что форт без ООП. :)

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

Вот только все больше и больше работодатели требуют ООП.

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

> Двадцать лет назад пионэры страдали похожей фигней. Можно ли сделать рекурсию на бейсике (классическом, который с номерами строк и GOSUB)? Пионэры радовались как пионэры, когда им удавалось рекурсивно слепить какую-нибудь «ханойскую башню».

самые крутые пионэры жили 30 лет назад.
Билл Джой, например.
Те, кто хакал машинное время, просиживал сутки в машинном зале, вбив char 'K', вместо int, и кому прошло в голову начать писать Shared систему - Юникс, для параллельной работы. А им мужики в пиджаках говорили: пионэры, пионэры. А они таки создали Юникс. И даже воспитали следующих пионэров 20 лет назад (не тех, которые Бейсик мучали, а тех кто решил Линуксы и БСД поднимать за счёт своего времени, свободные, без венчурного капиталла).

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

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

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

капиталисты понабежали значительно позже.
Не было бы базы, стабильной системы, созданной в свободное время - не было бы вообще о чём разговаривать.
Если и забашляли - то универы (я учился в 93-96 годах и преподавание шло на Линуксе с первым ядром).

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

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

Массовые инвестиции в линукс - имхо пошли уже после Большого Голубого, и уже в этом веке, когда ядро 2.4 под конец стало более масштабируемое и смогло конкурировать с коммерческими юниксами (в 2.6 те фичи стали из коробки). В 20 веке максимумы на количество файл-дескрипторов (сокетов например), перформанс, код надо было подкручивать и пр. - были смешными по сравнению с теми же санками.

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

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

справедливости ради, надо сказать - это было уже в конце 90х, не середине (в середине - я ещё учился и не пользовался линуксом на работе, на той работе же был dos5-6 и винда 3.0-3.11. Стыдно даже. Вот жена под новеллевской сетью и OS/2 сидела).

siberean
()

Что-то заглох тред.
Поддержим следующим.

Прочитал кучу статей и книг по нейропластичности, типа:
http://www.nature.com/nature/journal/v431/n7010/abs/431757a.html

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

Т.е. предыдущие умения, существующие ассоциации «стречатся», предыдущий код патчится и дополняется, а не пишется заново.
Прочитайте хотя бы Abstract по ссылке выше.

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

Какого нас учили создавать сначала структуры, и только потом - функции в ОО, когда даже мозг (т.е. то как мы естественно думаем и учимся) сначала делает функцию, и расширяет её по надобности (ajile, если не еxtreme программистсткий подход, с юнит тестами по ходу)? У эволюции надо учиться а не у Бучей.

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

> предыдущий код патчится и дополняется, а не пишется заново.

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

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

>ооп предполагает переписывание кода?
Кеды пишутся заново, гном патчится(хотя при чём тут функциональщина?). ^)

P.S Лор это супер торт, такого кол-ва идеологов нет нигде. ^)

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

>Какого нас учили создавать сначала структуры, и только потом - функции в ОО, когда даже мозг (т.е. то как мы естественно думаем и учимся) сначала делает функцию, и расширяет её по надобности
Сколько не пытаюсь, но не могу понять что вы хотели сказать. Можно примеры в студию?

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

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

Чтобы понять - надо прочитать топик, Степанова итд.

Где говорится о том, что разбивание на объекты и лишь потом дописывание функций/методов - это плохо (и именно этому нас учат ОО от книг Буча до курсов и универов последние 20 лет ООП-сумасшествия).
А гораздо лучше - начинать с функции и только по ходу создавать объекты (да какая разница - структуры тоже сойдут), когда надо.
Пайплайн обработки, машина состояний - самое главное, а не разбитие на частные ассоциации конкретного человека. Объекты - это частное разбиение, которое сильно поменяется пре рефакторинге, особенно если интенсивно применяется наследование итд. Читайте топик. Я лишь добавил, что сама природа не любит создавать структуры, а стречит существующие _функции_ и отношения.

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

> ооп предполагает переписывание кода?

с ним код (основного алгоритма) сложнее, файлов несравнимо больше, а переписки - болезненней.

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

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

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

>Чтобы понять - надо прочитать топик, Степанова итд.
Читал.

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

Так и надо было писать про объекты, а не структуры - понятия разные.

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

Не согласен, топик читал. :) ООП применять надо, но разумно. Так или иначе принципы ООП используются во всех языках/проектах. Там где есть явная абстракция данных незачем обходить ООП.

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

>Я когда разбираюсь/дебаггирую чужой код с малым количеством объектов и большими функциями - мне значительно легче.

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

К ООП это не имеет никакого отношения.

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

> Так и надо было писать про объекты, а не структуры - понятия разные.

объект - это структура (не вдаваясь в детали).

ООП применять надо, но разумно.


если его слишком часто применяют неразумно - то что-то в консерватории надо менять

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

> К ООП это не имеет никакого отношения.

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

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



В натуре надоело одно и то же повторять.

Пример был дан выше: логическая и физическая схемы в реляционном дизайне.
Каждый дизайнер БД или ДБА знает - что это разные вещи. ОО программисты - не знают, считая что это одно и тоже, переводя логическую схему на первых этапах ихнего «дизайна» в объекты/таблицы (сам сколько раз наблюдал). Чем думать языком джойнов, юнионов, селектов и проекций (т.е. рел.алгебры). И только после фиксации логической схемы (замапленной на предметную область) - озаботится наиболее эффективной реализацией физической схемы, где диапазон может быть от последней нормальной формы (для OLTP) - и до одной денормализованной таблицы (для OLAP). Мы думаем - как дата будет вытаскиваться, a не как нам хочется заассоциировать ящички-коробочки-объектики!). И объёмах данных, прокачивающихся через IO, т.е. в терминах эффективного исполнения. Где будет видно (при функциональном подходе, если его можно так назвать) - как процессит база, не копируем ли мы ненужную дату и не делаем ли других глупостей.
ООПшники дошли до того - что даже ОРМы придумали. Которые при изменении физической схемы по объективным причинам - все рушатся, так как объекты становятся совершенно другими.

Думаю, аналогия с реляционками понятна.

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

У вас какие-то проблемы. Дело не в применении какого-либо подхода, а в том как его применять. Тот же Степанов, сколько-бы он не трыньдел, применяет ООП принципы и использует встроенные ООП возможности компиляторов. Всё более менее сложное использует принципы ООП(инкапсуляция(скрытие), наследование(реиспользование), полиморфизм). И не надо приводить никаких примеров, дело совсем не в кривости ООП.

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

>самое прямое.

Основная работа программиста - сидеть с дебаггером.

Одно дело - когда я иду по одной функции, и понимаю её.


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

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

> У вас какие-то проблемы. Дело не в применении какого-либо подхода, а в том как его применять. Тот же Степанов, сколько-бы он не трыньдел, применяет ООП принципы и использует встроенные ООП возможности компиляторов. Всё более менее сложное использует принципы ООП(инкапсуляция(скрытие), наследование(реиспользование), полиморфизм). И не надо приводить никаких примеров, дело совсем не в кривости ОО

Я использую ООП, нет проблем.

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

Меня ещё в 95 году какой-то пионер на интервью поучал: «нет, нам нужны люди не старой закалки, а мыслящие „по-новому“, прогрессивно, в терминах объектов.» С уверенной в успехе и полной наивности рожей. А я ему про алгоритмы, минимаксы, языки, подходы до этого втирал, можно было не метать бисер. И если я в 95 году ещё гордо мог в резюме написать ООП, то сейчас не хочу ассоциировать себя с этим быдлом, и заезженным пионерами термином.
Но конечно же я использую классы, полиморфизм, наследование и инкапсуляцию, куда же без них. Но очень по-минимуму, если совсем уж нельзя обойтись без этой гадости.

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

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

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

> Вы пишите бред.

Считайте так. Жизнь научит (если не спрыгните в менеджмент)

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

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

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

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

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

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

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

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

Лень писать примеры, можно было-бы показать на примере что фанаты ООП творят с геттерами и ejb. Да всё это в топике выше уже есть. Надоело. ПО-моему, всё ясно.

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

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

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

пошёл я.

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

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

> Просто люди, которые съели собаку на нём - видят,

как непропорционально вознесены объекты


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

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

вскользь, акцентируя внимание на алгоритмах и функциональном подходе



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

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

«Стране нужны рабочие» (С)

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

А то приходят, лиспов и хаскелей нахватались, а главного индустриального языка никто не знает и долго медитируют на closures и не понимают как писать модульно. Ну правильно, Аде их _уже_ давно не учат, а жабаскриптам - ещё пока не учат. Зато панацея: объекты, объекты, объекты накопируем из реального мира, и всё само заработает. Нетушки.

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

> Я пытался убедить мекоторых профессоров - что в качестве как минимум

одного функционального языка - надо давать джава-скрипт


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

А то приходят, лиспов и хаскелей нахватались


Много таких знаете?

Зато панацея: объекты, объекты, объекты накопируем из реального мира,

и всё само заработает. Нетушки.



Объекты и ООП это ведь не одно и тоже, правда? А объектов то в JavaScript хватает (всё нах объекты). И ООП там хватает.

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

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

Помню один CIO меня учил, я тогда не понимал (позже понял): «он конечно PhD с CS, даже в каких-то там грамматиках, но обычно все сразу из академии (без большого опыта в индустрии) - слишком далеки от практики, идеалисты. Могут быть проблемы - когда у них не получатся их модели».

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

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

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

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


Так в реале - именно сложные задачи.
Вот пример которым мне пришлось заниматься: имплементировать эксель один к одному с формулами, редактировании через веб, десятками тысяч строк и десятками табов, и чтобы не тормозило.
И через веб.

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

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

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

> Много таких знаете?

да, видел.

Торонтовский универ имеет достаточно сильный курс «Функциональные языки». Там схема, лисп, хаскель и ещё что-то.

Университет Ватерлоо даёт сильный лисп.

Берут обычно хороших студентов CS.

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

> Объекты и ООП это ведь не одно и тоже, правда? А объектов то в JavaScript хватает (всё нах объекты). И ООП там хватает.

Выше видно, что я - против перекоса и вознесения, но - не против ООП фич как одних из (не самых главных).

И на джаве можно писать в статических функциях и без геттеров, как на си.
А ява-скрипт - вообще конфетка. Object-based - кажется это называется. Я Аду учил в 95 году, когда она только-только оbject-based стала. Конфетка. То чему стали учить позже - и привело к такому мессу в индустрии имхо.

Ладно, не буду больше брюзжать.

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

> То чему стали учить позже - и привело к такому

мессу в индустрии имхо.


Меня в университете физике учили, так что я х.з. чему учат и имеет ли это какое-либо реальное значение ;)

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

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

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

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

сорри, correction: В отношении JS обычно применяют prototype-based (я уже забыл терминологию), а не object-based.

Ада в сегодняшней википедии тоже зовётся ОО, хотя нам говорили, как я помню, что она всё-же object-based.

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

> языки с нестрогой типизацией не нужны

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

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

> тролли не нужны

согласен, уйди из треда

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

> Гы, скажите это сторонникам динамических языков или тем кто пишет на Перле.

динамическая типизация != нестрогая типизация, миллион раз это повторяли.

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

> динамическая типизация != нестрогая типизация, миллион

раз это повторяли.


Ты кажется перепутал JavaScript и VB.

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