Но вообще интересно, в каком языке нормальное ООП есть?
ООП на базе классов — 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 Вы по-прежнему не хотите формулировать… а значит для Вас это остаётся вопросом веры.
Приходится расписывать счас.
От того, что Вы расписали, ничего не поменялось… Вы по-прежнему путаете цели разработки и средства их достижения. Цель Вы хоть частично можете выразить в виде интеграционного теста, но никак не в виде юнит-теста.
Ага, всего лишь переключиться с объектного подхода на функциональный и использовать замыкание вместо метода.
Если это считать минимальными усилиями для поддержки сокрытия данных, то можно и чистый С назвать объектно-ориентированным :-)
Утверждение утрированно конечно, но я лично видел людей, которые пытаются устроиться на нормальную должность и даже где-то работали вроде как программистами более 5 лет, но по уровню знаний находятся где-то в районе плинтуса. Т.е. в следствии дефицита кадров их куда-то берут от безысходности, но у них нет стимула развиваться.
Ну Вас не поймёшь, то Вы говорите, что для детей важно как можно скорее видеть результат, то предлагаете дать им голый OpenGL, где на рисование простенького треугольника можно пару дней угробить, если Вы через плечо диктовать не будете.
P.S. Современным детям нравится Minecraft, достаточно дать им удобную возможность автоматизировать тыкание в экран, чтобы привить тягу к программированию.
А дикие скачки с JS-фреймворками, которые растут как грибы после дождя и так же быстро выходят из моды, я развитием не считаю, простите.
С этим я полностью согласен. Но есть ещё и бекэнд и там есть не только Java :-)
В целом идёт неторопливая адаптация мейнстримом концепций из менее популярных ЯП.
Очевидная для кого? Для людей, которые годами этой метафорой пользуются — да.
Но даже мы используем слово "конкатенация", а не "сложение", дабы не вносить путаницу. Если отбросить привычки, Вам не кажется странным, что понятия разные, а оператор — один?
Это была ответная шутка :-)
ООП на базе классов — 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 Вы по-прежнему не хотите формулировать… а значит для Вас это остаётся вопросом веры.
От того, что Вы расписали, ничего не поменялось… Вы по-прежнему путаете цели разработки и средства их достижения. Цель Вы хоть частично можете выразить в виде интеграционного теста, но никак не в виде юнит-теста.
Не знаю, не застал эту версию… но думаю, что варианты были даже там.
Ну как же нет… Вы даже не замечаете, что замыкание использовали?
А в каком нельзя?
Ага, всего лишь переключиться с объектного подхода на функциональный и использовать замыкание вместо метода.
Если это считать минимальными усилиями для поддержки сокрытия данных, то можно и чистый С назвать объектно-ориентированным :-)
Утверждение утрированно конечно, но я лично видел людей, которые пытаются устроиться на нормальную должность и даже где-то работали вроде как программистами более 5 лет, но по уровню знаний находятся где-то в районе плинтуса. Т.е. в следствии дефицита кадров их куда-то берут от безысходности, но у них нет стимула развиваться.
Ну Вас не поймёшь, то Вы говорите, что для детей важно как можно скорее видеть результат, то предлагаете дать им голый OpenGL, где на рисование простенького треугольника можно пару дней угробить, если Вы через плечо диктовать не будете.
P.S. Современным детям нравится Minecraft, достаточно дать им удобную возможность автоматизировать тыкание в экран, чтобы привить тягу к программированию.
Это вопрос привычек. В принципе, чем меньше базовых концепций, тем проще язык.
В концепции единообразия типа:
довольно легко въехать и легко ими пользоваться (если язык сам не нарушает свою концепцию на каждом шагу)
С этим я полностью согласен. Но есть ещё и бекэнд и там есть не только Java :-)
В целом идёт неторопливая адаптация мейнстримом концепций из менее популярных ЯП.
Очевидная для кого? Для людей, которые годами этой метафорой пользуются — да.
Но даже мы используем слово "конкатенация", а не "сложение", дабы не вносить путаницу. Если отбросить привычки, Вам не кажется странным, что понятия разные, а оператор — один?