Нвеяно очередным постом про «революционный Дарт» на хабре.
В комментариях пошло стандартное нытье про JS:
Мы с пеленок мыслим классами, нам сложно принять прототипы. Почти все библиотеки так или иначе эмулируют классы. К чему бы это?
Парадигму Класс принять в разы проще(она есть во всех языках), чем Делегирующий прототип.
Лично мне бы хотелось использовать унифицированный подход к классовому ООП
На что возник у меня резонный вопрос:
Почему-то, когда люди переходят на другой язык, от них ожидается, что они выучат какую-то новую для себя парадигму или другой способ работы — функциональные подходы, генераторы, метапрограммирвоание, паттерн матчинги, разные подходы к типам и типизации, разные подходы к наследованию и т.п. Это из первого, что взбрело в голову. Причем вне зависимости от языка — Питон, Руби, Скала, и даже «старички» типа Java (как!!!111 в Java нет множественного наследования? Что такое интерфейсы? )
И только с JS ситуация прямо противоположная. Почему-то не программист должен подстраиваться под язык (в частности, понять, что такое функциональное программирование и прототипное ООП), а JS должен подстраиваться под программиста.
Я лично считаю, что в конесерватории надо что-то срочно менять. Причем не JS, а восприятие оного программистами.
Здравствуйте, Mamut, Вы писали:
M>Нвеяно очередным постом про «революционный Дарт» на хабре.
M>В комментариях пошло стандартное нытье про JS: M>Парадигму Класс принять в разы проще(она есть во всех языках), чем Делегирующий прототип. M>Лично мне бы хотелось использовать унифицированный подход к классовому ООП
скажу о себе. лет десять назад ооп пытался учить дважды. сначала на турбо-паскале (с либой турбо-вижин), затем на плюсах. совершенно не вкурил, что такое классы, зачем они нужны и каким образом они помогут мне писать лучше, быстрее, разборчивее.
так ведь и не осилил ооп и на долгие годы забросил. а тут пару лет назад по долгу службы пришлось зарыться в js. и стало приходить понимание, что такое объекты и почему с использованием объектов программа получается намного более изящная, чем с традиционным процедурным подходом. делегирующий прототип у меня вызывает вселенский кайф и для моих задач он очень хорошо подходит.
сейчас начал курить java и уже кое-что понимаю в этом вышем ооп. раньше не понимал. вот такой он жаба-скрипт!
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, Mamut, Вы писали:
M>И только с JS ситуация прямо противоположная. Почему-то не программист должен подстраиваться под язык (в частности, понять, что такое функциональное программирование и прототипное ООП), а JS должен подстраиваться под программиста.
Потому что язык — это инструмент. Если инструмент неудобен — нахрен он вообще нужен?
Причём неудобен по любым причинам. Слишком сложен в освоении входит в список. Слишком отличается от првычного — тоже.
Да, заявление в стиле Кэпа, но ведь и вброс так себе...
Здравствуйте, мыщъх, Вы писали:
М>сейчас начал курить java и уже кое-что понимаю в этом вышем ооп. раньше не понимал. вот такой он жаба-скрипт!
А сможете объяснить преимущество ООП кратко? Причем так, чтобы это было понятно ненавистникам ООП.
Принято считать, что если кратко объяснить не можете -- то и сами до конца не понимаете. Я лет 8 назад заспорил с ненавистником ООП, но ничего не смог ему доказать о полезности классов. Теперь, оглядываясь назад, понимаю, что и сам не все понимал.
Здравствуйте, yoriсk.kiev.ua, Вы писали:
YKU>Здравствуйте, Mamut, Вы писали:
M>>И только с JS ситуация прямо противоположная. Почему-то не программист должен подстраиваться под язык (в частности, понять, что такое функциональное программирование и прототипное ООП), а JS должен подстраиваться под программиста.
YKU>Потому что язык — это инструмент. Если инструмент неудобен — нахрен он вообще нужен? YKU>Причём неудобен по любым причинам. Слишком сложен в освоении входит в список. Слишком отличается от првычного — тоже.
Хех. Что значит «привычный»? Там в комментариях есть вообще гениальное. Появился Хаскеллист (!) и возник следующий разговор:
siasia
Ну тогда вы просто обязательно должны выучить Haskell до того же уровня, что знаю его я.
А иначе, как там вы сказали… Ах да, вон из профессии.
Если я пишу 3 строчки кода на JavaScript'е в месяц, я всё равно должен вникать в это жуткое прототипное Perl-наследование?
dmitriid
> Ну тогда вы просто обязательно должны выучить Haskell до того же уровня, что знаю его я.
С какого перепугу? Я с ним не работаю. Если я с ним буду работать, я не буду ныть по поводу отсутсвия в нем классов, например.
> я всё равно должен вникать в это жуткое прототипное Perl-наследование
Если вы работаете с языком, от вас ожидается, что вы понимаете этот язык, не? И да, наследование там даже близко не из Perl'а.
siasia
Вы не ответили на мой вопрос
dmitriid
Я ответил на оба вопроса — и про Haskell и про наследование.
Если вам непонятно, то отвечу понятнее: да, вы должны понимать, хотя бы в общих чертах, что такое прототипное ООП. Потому что вы будете ожидать понимая хотя бы базовых принципов Haskell'а от человека, который пишет три строчки в месяц на Haskell'е.
siasia
В общих чертах я понимаю, что такое прототипное наследование, но оно мне не нравиться т.к. я не понимаю какие приемущества оно мне даёт в сравнении с ванильным наследованием.
dmitriid
Я не понимаю, что такое монады, и какие преимущества они мне дают по сравнению с любыми другими ванильными средствами.
Повторю
«
Почему-то, когда люди переходят на другой язык, от них ожидается, что они выучат какую-то новую для себя парадигму или другой способ работы…
И только с JS ситуация прямо противоположная. Почему-то не программист должен подстраиваться под язык (в частности, понять, что такое функциональное программирование и прототипное ООП), а JS должен подстраиваться под программиста.
»
siasia
Объясните мне, чем прототипное наследование лучше обычного и я с удовольствием расскажу вам про назначение монад.
dmitriid
> Объясните мне, чем прототипное наследование лучше обычного
Что значит «обычное»?
Оно не лучше, не хуже. Он просто другое. В любом виде в любой реализации у любого ООП есть свои преимущества и свои недостатки.
Про назначение монад мне рассказывать не надо, потому что я могу точно так же ответить: «мне надо три строчки на Хаскеле написать, мне что, андо разбираться в сугубо матемотической хрени под названием монады?»
То есть, иными словами: почему вы считаете, что для работы с Хаскелем вам нао учить Хаскеллевские подходы и используемые парадигмы, а для работы с JS — «мне это непонятно, дайте мне то, что удобно»?
В последнем абзаце — ключевое. То есть Хаскель с его далеко не сразу понятными монадами учить можно и надо, а в JS — не, нифига, дайте, чтобы было понятно
М>>сейчас начал курить java и уже кое-что понимаю в этом вышем ооп. раньше не понимал. вот такой он жаба-скрипт!
0K>А сможете объяснить преимущество ООП кратко? Причем так, чтобы это было понятно ненавистникам ООП.
0K>Принято считать, что если кратко объяснить не можете -- то и сами до конца не понимаете. Я лет 8 назад заспорил с ненавистником ООП, но ничего не смог ему доказать о полезности классов. Теперь, оглядываясь назад, понимаю, что и сам не все понимал.
С ненавистниками чего-либо разговаривать бесполезно. В подавляющем большинстве они не воспринимают никакой аргументации. Поэтому надо просто подождать, пока человека сам дорастет.
Здравствуйте, 0K, Вы писали:
0K>Здравствуйте, мыщъх, Вы писали:
М>>сейчас начал курить java и уже кое-что понимаю в этом вышем ооп. раньше не понимал. вот такой он жаба-скрипт! 0K>А сможете объяснить преимущество ООП кратко? Причем так, чтобы это было понятно ненавистникам ООП.
объяснить можно на примерах. оракл показывает как в лучших традициях ооп реализовать простой сервер и knock-knock протокол. выглядит сексуально. вот тут класс экземляра сервера, вот тут класс протокола, а вот тут клиент... и все бы ничего, да вот вздумалось мне слегка потренироваться в жабе и незначительно (подчеркиваю _незначительно_) модифицировать протокол.
меняю реализаю класса протокола и тут же синхронно правлю сервера и клиента. и так каждый раз когда трогаю протокол. плюнул и воткул класс протокола проямо в сервер. клиента переписал на свой лад. в резльутате дальшейшая доработка кода сильно упростилась.
будем считать, что у нас протокол построен по следующей схеме.
1A: клиент -запрос-> сервер
1B: сервер -ответ-> клиент
1, 2 и 3 контенкстно независимы. т.е. в очень грубом приближении все выглядит так response == foo(request). совершенно очевидно, что при таком раскладе логика проткола всецело реализуются внутри класса "протокол", а остальные классы лишь обеспечивают прозрачный прием и доставку данных структуры которых они не понимают.
вопрос -- на фига оракл в наглядно-агитационных пособиях написать какую-то чухню? вот за это я и не люблю этот ваш ооп, ибо очень редко удается увидеть программу, где ооп не препятствовал бы модифиации, а, наоборот, помогал.
0K>Принято считать, что если кратко объяснить не можете -- то и сами до конца не понимаете. Я лет 8 назад заспорил с ненавистником ООП, но ничего не смог ему доказать о полезности классов. Теперь, оглядываясь назад, понимаю, что и сам не все понимал.
классы это ИМХО очень неудачный термин. объекты лучше. объект это некая сущность. типа массив, список... я уже писал, что раньше считал нормальным создать класс "сортировка" и сложить под одну крышу все методы сортировки которые только знаю. теперь понимаю, что это ошибка, ибо сущности "сортировка" не существует. и все возможные сортировки должны быть методами объектов, образующих некие сущности (массив, список...)
если посмотреть на классический си, то функции типа поиска принимают в качестве аргументов размер элемента и функцию сравнения. при этом накладывается ограничение, что все элементы лежат в непрерываном массиве, что не всегда так (они могут быть и в файле на диске, а файл 4 ТБ). поэтому, нужно еще добавить и функцию взятия элемнтов по индексу или взять_следующий_элемент, если индексов нет.
как легко видеть, тут мы близко подходим к эмуляции ооп продедурными методами. в ооп эта же задача решается проще. у объекта есть метод взятия элементов (по индексу и/или следующего) и есть метод сравнения. и как оно работает -- никому знать не надо. может это массив, а может это геораспределенный кластер. главное, что нужные методы есть. и они юзаются.
получается очень интересная штука. если у объекта нет нативного метода взятия элемента по индексу, то часть алгосов поиска и сортировки работать не будет (или потребует промежуточной индексации всех объектов) и потому можно автоматически выбирать алгос сортировки для данного объекта исходя из его публичных методов. причем, функции сортировки и имплементация объетов пишутся раздельно.
можно ли это реализовать на чистом си? да, конечно. передавать функции сортировки/поиска указатели на функции взятия элемента и сравнения. чем это хуже, чем в ООП? ответ -- слишком много аргументов получается. вместо того, чтобы писать x.sort() мы пишем sort(x, x_type_get_el_by_idx, x_type_cmp). это не только некрасиво, но и компилятору очень сложно заинлайнить такие функции (и их никто не инлайнит), а в ооп их инлайнит практически любой компилер. ну или вызывает прямой адресацией, а не косвенной (что быстрее).
противникам ооп можно посоветовать написать в не ооп стиле функцию двочного поиска, работающую с произвольными типами (в том числе и пользовательскими), а затем переписать это в ооп стиле. и сравнить размер кода и скорость. в ооп оба показателя лучше в разы.
впрочем, тут есть хитрый хак. на чистом си можно сделать proxy-objector, пихающий все типы в структуры. в результате получится ооп, сделанный на коленках. ну то есть объявляем структуру _OBJECT_ и кладем туда указатели на функции взятия элемента и сравнения, а заодно и указатель на функцию сортировки. получается x.sort() на чистом си. точнее, на чистом си-компиляторе. но по сути это ооп.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, мыщъх, Вы писали:
М>Здравствуйте, Mamut, Вы писали:
M>>Нвеяно очередным постом про «революционный Дарт» на хабре.
M>>В комментариях пошло стандартное нытье про JS: M>>Парадигму Класс принять в разы проще(она есть во всех языках), чем Делегирующий прототип. M>>Лично мне бы хотелось использовать унифицированный подход к классовому ООП М>скажу о себе. лет десять назад ооп пытался учить дважды. сначала на турбо-паскале (с либой турбо-вижин), затем на плюсах. совершенно не вкурил, что такое классы, зачем они нужны и каким образом они помогут мне писать лучше, быстрее, разборчивее.
М>так ведь и не осилил ооп и на долгие годы забросил. а тут пару лет назад по долгу службы пришлось зарыться в js. и стало приходить понимание, что такое объекты и почему с использованием объектов программа получается намного более изящная, чем с традиционным процедурным подходом. делегирующий прототип у меня вызывает вселенский кайф и для моих задач он очень хорошо подходит.
М>сейчас начал курить java и уже кое-что понимаю в этом вышем ооп. раньше не понимал. вот такой он жаба-скрипт!
По факту как в ООП языке можно к примеру использовать процедурный или функциональный подход, так обычно и обратно. Вопрос удобства Но жабаскрипт меня, например, забавляет давно (при чем принципиально для своего удовольствия использую его в областях не связанных с WEB). А учитывая что его можно выполнить практически на любой голой машине....
Здравствуйте, Ведмедь, Вы писали:
В>Здравствуйте, мыщъх, Вы писали:
М>>сейчас начал курить java и уже кое-что понимаю в этом вышем ооп. раньше не понимал. вот такой он жаба-скрипт!
В>По факту как в ООП языке можно к примеру использовать процедурный или функциональный подход, так обычно и обратно. Вопрос удобства Но жабаскрипт меня, например, забавляет давно (при чем принципиально для своего удовольствия использую его в областях не связанных с WEB). А учитывая что его можно выполнить практически на любой голой машине....
в скрипте меня от прототипов реально прет. когда писал в целях диагности логгер объектов, сохраняющий их в текстовом представлении с форматированием в файл, то сначала у меня была одна функция dump, принимающая объект в качестве арумента. внтри огромный switch для всех типов объектов. ужос.
а потом понял, что к каждому объекту можно добавить прототип в виде метода dump, который дампит его с учетом специфики данного объекта. делаем walk всем объектом и зовем dump для каждого из них. хоть рекурисивно, хоть не рекурсивно. главное, что все красиво и вообще зашибись.
причем функция, внутри которой делается walk и вызывается dump может иметь свои настройки. например, для слишком длинных строк можно при желании дампить только начало и конец. можно смотреть содержимое строки и решать как дампить ее -- как есть или в виде hex-дампа.
короче, получается три совершенно незавсимых абстрактных слоя.
1) dump для каждого объекта. пишется независимо. например, дамп объета my_obj, состоящий из строки и пары функций, делает dump строкам и функциям, а dump строк и функций пишется независимо от всего остального, хотя дамп функции вызывает дамп строки. короче, получается, что у нас есть только дамп строки. а остальное получается путем преобразования объекта к строке с последующим ее дампом.
2) walker объектов. см. выше. объеты от корня обходятся так же как члены объекта my_obj.
3) дампер объектов -- в соответствии с настройками логгера ограничивает макс. длину строк для дампа, задает бинарный или hex-формат представления, а так же при необходимости киляет дубликаты.
и это возможно только потому, что у каждого объекта есть поддержка for x in obj, есть toString (перекрываемый мной при необходимости) и dump (мой собственный).
именно это и послужило толчком к переосмыслению моего отношения к ооп, ибо в процедурном стиле такая задача красиво не решается в принципе. ну нельзя присобачить к int'у метод toString и dump.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, Mamut, Вы писали:
M>На что возник у меня резонный вопрос: M> M>Почему-то, когда люди переходят на другой язык, от них ожидается, что они выучат какую-то новую для себя парадигму или другой способ работы — функциональные подходы, генераторы, метапрограммирвоание, паттерн матчинги, разные подходы к типам и типизации, разные подходы к наследованию и т.п. Это из первого, что взбрело в голову. Причем вне зависимости от языка — Питон, Руби, Скала, и даже «старички» типа Java (как!!!111 в Java нет множественного наследования? Что такое интерфейсы? )
А не приходило в голову, что неудобно молотком(JS) шурупы закручивать? Поэтому при переходе с отверстки(C++) на шуроповерт(Java), большинство с удовольствием изучает новый инструмент — и хотя конечно иногда приходится возвращаться к отвертке, все-таки переход оправдан. Сам по себе молоток(JS) ничем не плох и просто замечательно забивает гвозди, но подавляющее большинство программистов в индустрии занимается закручиванием шурупов (разработкой тяжелых корпоративных приложений, которые надо долго поддерживать). И вот когда дают молоток (и говорят, что это единственный и самый правильный инcтрумент, другого у нас в браузере нету), приходится либо эти шурупы забивать, либо придумывать, как эмулировать с помощью молотка отвертку.
M>И только с JS ситуация прямо противоположная. Почему-то не программист должен подстраиваться под язык (в частности, понять, что такое функциональное программирование и прототипное ООП), а JS должен подстраиваться под программиста.
Странно другое, мало кто пытается закручивать шурупы например пилой(Prolog) или рубанком(Smaltalk) или пилочкой для ноктей(Fort). А вот молоток нам все время пытаются впихнуть как унивесальный инструмент.
M>Я лично считаю, что в конесерватории надо что-то срочно менять. Причем не JS, а восприятие оного программистами. M>
M>Ась?
Здравствуйте, Mamut, Вы писали:
M>И только с JS ситуация прямо противоположная. Почему-то не программист должен подстраиваться под язык ... M>Я лично считаю, что в конесерватории надо что-то срочно менять. Причем не JS, а восприятие оного программистами. M>Ась?
Ну дык, это же очевидно! На жабаскрипте пишут, в основном, не программисты =)
Здравствуйте, 0K, Вы писали:
0K>А сможете объяснить преимущество ООП кратко? Причем так, чтобы это было понятно ненавистникам ООП.
Программирования в концепции SOLID? Иначе говоря, преимущество ООП в удобстве написания живучего кода.
Однако надо понимать, что SOLID хоть и родился из ООП, языка с оным особенно не требует. Это же концепция проектирования, а не кодирования. В С я прекрасно его пользую, хотя там никакого ООП формально и нет.
А хвостатый задвинул ... я аж смутился от глубины его познаний и широты кругозора. =)))
Здравствуйте, Mamut, Вы писали:
M>И только с JS ситуация прямо противоположная. Почему-то не программист должен подстраиваться под язык (в частности, понять, что такое функциональное программирование и прототипное ООП), а JS должен подстраиваться под программиста.
M>Я лично считаю, что в конесерватории надо что-то срочно менять. Причем не JS, а восприятие оного программистами. M>[/q]
Я почти уверен, что причин две:
1. Синтаксис
2. Название.
Все С-подобные языки вызывают ломку при переходе на них. Про Java основные бои отгремели 10 лет назад; с .Net до сих пор происходят — приходят опытные С-программисты и начинается отжиг, потому что семантика не та, к которой привыкли.
Если бы язык с самого начала назывался ECMAScript, то было бы меньше ожиданий найти там полную ява-машину, а так же классы, интерфейсы, и прочие отсутствующие by design вещи. Подсознательно новички это воспринимают так "взяли Яву, убрали полезные вещи, добавили какую-то хрень".
Это всё равно как выпустить "портативный телевизор", не оборудованный экраном, а потом годами объяснять "это совсем другой прибор, у него общего с телевизором — только кнопка включения"
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, мыщъх, Вы писали:
М>Здравствуйте, 0K, Вы писали:
0K>>Здравствуйте, мыщъх, Вы писали:
М>классы это ИМХО очень неудачный термин. объекты лучше. объект это некая сущность. типа массив, список...
Класс это правильный термин,определяет множество элементов обладающих некоторыми свойствами. А объект это уже какой то конкретный элемент этого множества. Я думаю, что на выбор термина повлиял тот факт, что во времена создания теории ООП программист думающий что ему математика нафик не сдалась был явлением абстрактным, примерно как материальная точка или идеальный газ.
M>>Все скипнуто. Почему именно С++ и Java — это шуруповерты и отвертки, а JS — молоток, а не наоборот?
ЕА>Да ради бога, пусть будет наоборот
ЕА>Суть в том, что это разные инструменты, заточенные под разные задачи.
Ключевое выделено. Поэтому повторю, используя твои же аналогии: почему все согласны пользоваться шуруповертами и отвертками в случае других языков, но получая в руки, скажем дрель или молоток (JS), начинают ныть и пытаться превратить его в шуруповерт?
)
