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 ★★★
()
Вы не можете добавлять комментарии в эту тему: топик перемещен в архив.