Тренд до середины 2009 года можно использовать для нормировки текущего… Неважно что ещё ищут по такому запросу, но это явно надо вычесть, если хотите увидеть тренд именно по Node.JS
Это всё MS виновата… переиспользуют названия, а потом приходится новичкам по 10 раз рассказывать чем отличается VB от VB.NET, ASP от ASP.NET, ASP.NET от ASP.NET MVC и т.д.
Итак, парадимга ООП не требует наличия запрета доступа к полям или методам
Вы опять потеряли мысль… Доступ к полям через посылку сообщений и прямой доступ к полям — это принципиально разные вещи. И прямого доступа к полям в рамках ООП быть не может.
Возможно, посылая сообщение "получить значение поля такого-то"?
Именно. Фишка в том, что механизм посылки/приёмки сообщений должен быть един в рамках конкретного языка (иначе это уже будет N разных понятий, а не одно — сообщения). Как Вы правильно заметили, это необязательно вызов метода и для полной поддержки ООП наличие методов не требуется. Но в большинстве мейнстрим-языков отправка сообщения — это именно вызов метода.
У нас с вами получается, что ООП это одно, а поддержка ООП это другое, что в общем, логично.
В целом да. Нет ничего плохого в частичной поддержке какой бы то ни было парадигмы в языке. Плохо, что сами парадигмы замыливаются и начинают неверно пониматься. Так мы и скатываемся до понимания в стиле "если есть классы — то это ООП". Гораздо лучше, когда программист осознаёт где границы конкретной парадигмы и какие фичи его любимого языка выходят за эти границы.
Rails действительно теряет популярность, но никак не в пользу Node.JS или Go. Первый привлекает много новичков, а второй используется только в узких местах и то для Rails-проектов скоро будет гораздо естественнее узкие места закрывать с помощью Crystal/Kemal, а не Go.
Ну а переход от Rails идёт в основном в пользу Ruby/Hanami и Elixir/Phoenix.
Из третьего пункта следует, что у объектов есть состояние. Из первого пункта — что кроме объектов в программе ничего нет, а из второго — что объекты общаются только через сообщения.
А теперь вопрос: как можно получить доступ к состоянию одного объекта из другого объекта, если они могут взаимодействовать исключительно через сообщения?
Но вообще интересно, в каком языке нормальное ООП есть?
ООП на базе классов — Smalltalk
ООП на базе прототипов — Self
А вообще дело, конечно, не в "нормальности"… а в чистоте парадигмы.
Концепция обязана быть сформулирована предельно конкретно и настолько коротко, насколько возможно… иначе Вы просто будете растекаться мыслью по древу на каждом шагу, подгоняя под неё что угодно.
Двумя комментариями ниже я привёл определение ООП в 3-х коротких предложениях. А теперь попробуйте сформулировать определение ООП так, чтобы оно в полной мере описывало то, что понимается в C++, Java, C# под этой аббревиатурой. Скорее всего, Вы с удивлением поймаете себя на использовании терминов, которые относятся к программированию в целом, а не конкретно к ООП, типа абстракция, полиморфизм и т.д..
Понятно, что финансы конвертируются в ресурсы, выделяемые разработке, и это собственно основной фактор. Но насчёт пятикратного превосходства в реальных задачах хотелось бы узнать поподробнее… Какого рода задачи? И не имело ли место сравнение одного ядра CPU против всех?
Вы видите то, что хотите видеть… Node.JS сейчас там же, где и все остальные интерпретаторы с JIT, будь то PyPy, LuaJIT или Hack. Кроме того JIT это не свойство языка, т.е. ничто не мешает добавить его в любой интерпретатор, были бы финансы.
Ну и самое главное: везде, где нужна скорость при использовании интерпретируемого языка, как использовали биндинги к C-либам, так и будут использовать. Поэтому к реальным задачам все эти бенчмарки относятся весьма косвенно.
Ладно, я не вижу смысла продолжать прения… А то может сложиться впечатление, что я имею что-то против TDD )))
Единственное с чем я не согласен, что это серебряная пуля, которая подходит абсолютно всем.
Что касается Selenium, его можно использовать при BDD, но при TDD. Лично я считаю, что BDD лучше подходит для бизнес-целей. Но навязывать не буду :-)
Покажите, какая конкретно часть парадигмы ООП вообще требует возможность скрывать поля?
Ну смотрите, объект по определению может иметь состояние и может отвечать на сообщения и всё, больше ничего он не может.
An object can do exactly three things:
Hold state (references to other objects).
Receive a message from itself or another object.
In the course of processing a message, send messages to itself or another object.
Соответственно, доступ к состоянию возможен исключительно через посылку сообщения.
Если мы вводим какой-то иной способ доступа к состоянию мимо сообщений, то это что-то что к ООП уже не относится.
Нет, личного опыта на эту тему пока нет. Но из всех production-ready языков я только у Racket видел такую заботу о детях… Она по-моему красной нитью проходит через все обучающие материалы… Например, "How to Design Programs" начинается с написания программы управления ракетой, да и в целом просто замечальные библиотеки Teachpacks идут в составе стандартного дистрибутива. Помимо этого в него включен набор классических игр и руководство как написать свою.
Ну и "Realm of Racket" тоже конечно отличное дополнение.
Не думаю, что я буду заниматься археологическими исследованиями PHP )))
Просто ещё раз подчеркну, на мой взгляд, принципиальный момент — чтобы назвать язык объектно-ориентированным мало иметь возможность обеспечить сокрытие данных в объекте, нужна невозможность создания объекта без такого сокрытия.
Ну а подход, его можно и в чисто функциональных языках спокойно применять, но там хоть есть чёткое осознание что и зачем. В JS же такая смесь парадигм, которая не позволяет их как-то разграничить.
И как же Вы предлагаете их называть, если их самоопределение Вас не устраивает?
Если есть код — значит его возможно тестировать.
Кто спорит… его возможно тестировать и без TDD :-)
Для веба есть selenium и Ко.
Вы лично используете selenium для TDD?
И TDD этому крепко способствует. Или Вы считаете иначе?
Да, я считаю иначе. TDD является одним из методов написания качественного кода, но преимущество от его применения доказать не смогли, хотя исследования проводили… Оказалось, что качество кода зависит от уровня программиста, а не от применяемых им методик.
Из всего этого можно сделать вывод, с которого я и начал, TDD подходит тем, кому нравится конкретно эта методика. Остальным она будет скорее во вред. Другими словами, это всё чисто субъективизм.
В остальном по TDD cм. книги или видео Дяди Боба.
Спасибо. Вы лучше Бека почитайте, про XP в целом много интересного узнаете ;-)
так ещё и противопоставляете науку вероучению
Где это? Вы слово "подход" видимо пропустили )
Хорошая смена темы, но границы применимости TDD Вы по-прежнему не хотите формулировать… а значит для Вас это остаётся вопросом веры.
Приходится расписывать счас.
От того, что Вы расписали, ничего не поменялось… Вы по-прежнему путаете цели разработки и средства их достижения. Цель Вы хоть частично можете выразить в виде интеграционного теста, но никак не в виде юнит-теста.
Тренд до середины 2009 года можно использовать для нормировки текущего… Неважно что ещё ищут по такому запросу, но это явно надо вычесть, если хотите увидеть тренд именно по Node.JS
Это всё MS виновата… переиспользуют названия, а потом приходится новичкам по 10 раз рассказывать чем отличается VB от VB.NET, ASP от ASP.NET, ASP.NET от ASP.NET MVC и т.д.
Вы опять потеряли мысль… Доступ к полям через посылку сообщений и прямой доступ к полям — это принципиально разные вещи. И прямого доступа к полям в рамках ООП быть не может.
Именно. Фишка в том, что механизм посылки/приёмки сообщений должен быть един в рамках конкретного языка (иначе это уже будет N разных понятий, а не одно — сообщения). Как Вы правильно заметили, это необязательно вызов метода и для полной поддержки ООП наличие методов не требуется. Но в большинстве мейнстрим-языков отправка сообщения — это именно вызов метода.
В целом да. Нет ничего плохого в частичной поддержке какой бы то ни было парадигмы в языке. Плохо, что сами парадигмы замыливаются и начинают неверно пониматься. Так мы и скатываемся до понимания в стиле "если есть классы — то это ООП". Гораздо лучше, когда программист осознаёт где границы конкретной парадигмы и какие фичи его любимого языка выходят за эти границы.
Rails действительно теряет популярность, но никак не в пользу Node.JS или Go. Первый привлекает много новичков, а второй используется только в узких местах и то для Rails-проектов скоро будет гораздо естественнее узкие места закрывать с помощью Crystal/Kemal, а не Go.
Ну а переход от Rails идёт в основном в пользу Ruby/Hanami и Elixir/Phoenix.
Из третьего пункта следует, что у объектов есть состояние. Из первого пункта — что кроме объектов в программе ничего нет, а из второго — что объекты общаются только через сообщения.
А теперь вопрос: как можно получить доступ к состоянию одного объекта из другого объекта, если они могут взаимодействовать исключительно через сообщения?
Это была ответная шутка :-)
ООП на базе классов — Smalltalk
ООП на базе прототипов — Self
А вообще дело, конечно, не в "нормальности"… а в чистоте парадигмы.
Концепция обязана быть сформулирована предельно конкретно и настолько коротко, насколько возможно… иначе Вы просто будете растекаться мыслью по древу на каждом шагу, подгоняя под неё что угодно.
Двумя комментариями ниже я привёл определение ООП в 3-х коротких предложениях. А теперь попробуйте сформулировать определение ООП так, чтобы оно в полной мере описывало то, что понимается в C++, Java, C# под этой аббревиатурой. Скорее всего, Вы с удивлением поймаете себя на использовании терминов, которые относятся к программированию в целом, а не конкретно к ООП, типа абстракция, полиморфизм и т.д..
Понятно, что финансы конвертируются в ресурсы, выделяемые разработке, и это собственно основной фактор. Но насчёт пятикратного превосходства в реальных задачах хотелось бы узнать поподробнее… Какого рода задачи? И не имело ли место сравнение одного ядра CPU против всех?
Хорошо, что теперь и Вам понятно, что в Java нет нормального ООП :-)
Приведите определение ООП, из которого не следует такой запрет.
Из классического определения он явно вытекает:
Вы видите то, что хотите видеть… Node.JS сейчас там же, где и все остальные интерпретаторы с JIT, будь то PyPy, LuaJIT или Hack. Кроме того JIT это не свойство языка, т.е. ничто не мешает добавить его в любой интерпретатор, были бы финансы.
Ну и самое главное: везде, где нужна скорость при использовании интерпретируемого языка, как использовали биндинги к C-либам, так и будут использовать. Поэтому к реальным задачам все эти бенчмарки относятся весьма косвенно.
Посмотрите Racket. Там есть и заготовки графики для игр, возможность вставить картинку в код и работать с ней как с константой, и рисование графическими примитивами.
А когда с рисованием наиграется, можно будет и примеры из SICP поразбирать.
всё гораздо проще
Ладно, я не вижу смысла продолжать прения… А то может сложиться впечатление, что я имею что-то против TDD )))
Единственное с чем я не согласен, что это серебряная пуля, которая подходит абсолютно всем.
Что касается Selenium, его можно использовать при BDD, но при TDD. Лично я считаю, что BDD лучше подходит для бизнес-целей. Но навязывать не буду :-)
Да это давно уже не новость. Большая часть мейнстрима — процедурные языки с элементами ООП.
Ну смотрите, объект по определению может иметь состояние и может отвечать на сообщения и всё, больше ничего он не может.
Соответственно, доступ к состоянию возможен исключительно через посылку сообщения.
Если мы вводим какой-то иной способ доступа к состоянию мимо сообщений, то это что-то что к ООП уже не относится.
Нет, личного опыта на эту тему пока нет. Но из всех production-ready языков я только у Racket видел такую заботу о детях… Она по-моему красной нитью проходит через все обучающие материалы… Например, "How to Design Programs" начинается с написания программы управления ракетой, да и в целом просто замечальные библиотеки Teachpacks идут в составе стандартного дистрибутива. Помимо этого в него включен набор классических игр и руководство как написать свою.
Ну и "Realm of Racket" тоже конечно отличное дополнение.
Не думаю, что я буду заниматься археологическими исследованиями PHP )))
Просто ещё раз подчеркну, на мой взгляд, принципиальный момент — чтобы назвать язык объектно-ориентированным мало иметь возможность обеспечить сокрытие данных в объекте, нужна невозможность создания объекта без такого сокрытия.
Ну а подход, его можно и в чисто функциональных языках спокойно применять, но там хоть есть чёткое осознание что и зачем. В JS же такая смесь парадигм, которая не позволяет их как-то разграничить.
И как же Вы предлагаете их называть, если их самоопределение Вас не устраивает?
Кто спорит… его возможно тестировать и без TDD :-)
Вы лично используете selenium для TDD?
Да, я считаю иначе. TDD является одним из методов написания качественного кода, но преимущество от его применения доказать не смогли, хотя исследования проводили… Оказалось, что качество кода зависит от уровня программиста, а не от применяемых им методик.
Из всего этого можно сделать вывод, с которого я и начал, TDD подходит тем, кому нравится конкретно эта методика. Остальным она будет скорее во вред. Другими словами, это всё чисто субъективизм.
Спасибо. Вы лучше Бека почитайте, про XP в целом много интересного узнаете ;-)
Где это? Вы слово "подход" видимо пропустили )
Хорошая смена темы, но границы применимости TDD Вы по-прежнему не хотите формулировать… а значит для Вас это остаётся вопросом веры.
От того, что Вы расписали, ничего не поменялось… Вы по-прежнему путаете цели разработки и средства их достижения. Цель Вы хоть частично можете выразить в виде интеграционного теста, но никак не в виде юнит-теста.