Текущая риторика как 200 лет тому назад «если раба кормить и не бить, он же не будет работать».
Деньги служат мотиватором к труду лишь в каком-то диапазоне. Когда их нет совсем, они добываются иными способами. Когда их становится «достаточно», мотивируют уже совсем другие вещи. Думаю корни проблемы нужно искать не в плоскости паталогической тяги к туниядству, а в нежелание терять инструмент влияния.
В догонку. Тут можно рассмотреть еще и языковые особенности. Так, в английском языке порядок слов в предложении фиксирован: подлежащее, сказуемое и т.п. При этом сказуемое не может быть без подлежащего. В процедурных языках роль подлежащего выполняют слова «модуль» или «программа», которые содержат действия.
program Example;
begin
Write('Hello, ');
WriteLn('World!');
end.
Здесь оба глагола Write() и WriteLn() связаны с подлежащим program Example (читаются как program Example Write('Hello '), program Example WriteLn('World!')), а не существуют сами по себе.
В отличие от английского, в русском языке, можно опускать разные части предложения (программу можно читать в безличной форме как «написать(»Hello "); написать(«World! „)). Это создает новые семантические контексты в понимании “естественности». Не думаю, что это хорошо, скорее просто выносит мозг, поскольку приводит к неправильным выводам.
С самого начала, семантика «метода» в ООП обозначала отправку сообщения объекту, а не действие над объектом. Т.е. объект здесь является получателем сообщения, а не исполнителем. Субъект, который отправляет сообщение — это собственно сама программа. Поэтому запись file.close() читается как [я отправляю]file[сообщение]close().
Понимание метода как действия, приводит обычно к скатыванию в «процедурщину»: модулям, библиотекам функций и т.п. (это не в смысле «хорошо» или «плохо», а в смысле «не-ООП»). Это, кстати, хорошо видно в вашем примере, где появляется дополнительная инструментина для выполнения действий над файлами «fileSystem.close()», а сам file автоматически превращается тупо в данные.
Хороший дизайн способствует снижению издержек на модификацию и поддержку кода.
Если на пальцах. Абстрактный проект в вакууме живет 3-5 лет. Время на разработку составляет 3-5 месяцев (т.е. всего лишь 10% срока жизни, Карл!). Остальные 90 приходятся на этапы внедрения и эксплуатации. 3 года в современном мире это большой строк, за который бизнес-ситуация может поменяться несколько раз. Соответственно, команде разработки неизбежно приходится сталкиваться с задачами модификации кода. В определенном смысле, код переходит в состояние эксплуатации сразу как только закрывается задача в трекере на его разработку. Необходимость в модификациях может выявится уже на самых ранних этапах — тестирования, внедрения, и т.д. Модификации влекут за собой риски возникновения дополнительных ошибок и регрессий в ранее отлаженном приложении и соответствующих издержек на их устранение (включая упущенную прибыль, финансовые риски по взаимоотношениям с клиентами, следующими из SLA, и т.п.). Учитывая масштабы, решение вопросов минимизации регрессий и снижения затрат на эксплуатацию становится, как минимум, интересным.
Какие варианты могут быть предложены в инженерном плане? Из очевидного: если два компонента между собой ни как не связаны, то изменения в одном компоненте не приведут к ошибкам в другом. Поэтому большие штуки есть смысл разделять на отдельные и независимые. В случае чего чинить придется меньше, вникать — проще, а все вместе — дешевле.
Отсюда следуют выводы о необходимости модульности (в широком смысле), компонентов и т.п. Но все эти навороты являются отдельными архитекрутными штуковинами, которые привносят в код дополнительную сложность и свои издержки.
Искусство хорошего дизайна здесь состоит в том, чтобы правильно определить границы модулей. Чтобы издержки, связанные с модульностью, оставались ниже соответствующих издержек на модификацию кода в отсутствии этой самой модульности.
Плохой дизайн не уменьшает количество связей, соответственно не сужает границ распространения ошибок, но лишь увеличивает количество сущностей, что приведет лишь еще большему к повышению сложности и затрат, без какого-либо профита. Здесь же ошибки, связанные с чрезмерной и неправильной декомпозицией, когда затраты на разработку и поддержку модульности начинаю превышать профит от её использования.
Шаблоны проектирования описывают типовые приемы декомпозиции в типовых случаях. Система описания шаблонов достаточно универсальна, она не связана с ООД, хотя основная масса литературы выпускается именно про них.
Проблемы выразительной подачи материала здесь, как мне кажется, появляются именно из-за того, что при знакомстве с паттернами, студент неявно ставится в роль кодера на этапе разразработки, а модульность сама по себе привносит в разработку сложность. Отсюда и вопрос «А зачем так усложнять?». Но профит от модульности становится очевиден лишь на этапе эксплуатации, когда возникает задача модификации. Причем, чем больше контекст, тем ярче ощущения от резолюции «да тут надо лишь одну строчку поменять» и сильнее инсайт от понимания «и при этом я уверен, что больше ни где ни чего не сломается».
Поживем-увидим) Microsoft уже давно обещают опенсорсят. Напомните какой-нибудь их софт, который под линуксами работает классно?
Встраивая ChakraCore в Node.js они решают вполне конкретную бизнес-задачу с продвижением Azure — там для Chakra (у которого CharkaCore лишь маленький кусочек) куча своих фишек, но проблемы с отсутствием конечных js-библиотек и фреймворков, которые в массе своей точатся под ноду, что снижает привлекательность платформы. Неспешно портировав базовые куски интерпретора на линуксы, они получат дополнительные возможности в плане регрессионного тестирования, и, вероятно, пересаживания разработчиков. Это все понятно. Но JIT это сильно более хитрое колдунство, как для технарей, так и для бизнесов, чем просто интерпретатор (посмотрите на Java, и историю развития альтернативных JVM). JIT для линуксов если и появится, то будет не настолько бесплатным, чтобы оставался смысл не пользоваться Azure. Тут вам не Googe))
Цифры понятны. Они продают аналитику, юр. поддержку и софт для правоторговцев, поэтому стремление закошмарить масштабами их убытков в РФ и прибылей «пиратов», понятно. Это вроде даже как законно, ведь «пираты» не пойду с исками в суд за клевету. Имидж стране портит, да. Но кого это волнует?
Из софта есть еще опенсорсный thumbor.org — там REST API, умный кроп детекторами фич и физиономий через OpenCV, хранение на s3, дружелюбие к CDN и масштабируемость, опционально аплоад. Есть несколько рецептов для docker-compose, с помощью которых можно развернуть подходящую конфигурацию в облаке за полчаса.
Интересность вашего решения как сервиса зависит от SLA.
Блокировки это одно, а рерайт — другое. Терминология в энциклопедических статьях должна быть предельно конкретной, чтобы максимально точно отражать смысл. Занимаясь рерайтом, и снижая уровень информационной нагрузки, чиновники загоняют русский язык в весьма нишевую область. Полезную информацию в wiki и так лучше читать на английском. На русском лишь то, что продается и покупается, либо очень специфическое.
Замечательное название, учитывая, что у Булычева на "Астре" летали правильные ребята, которые спасали планеты от экологических катастроф и тоталитарных режимов. :)
спокойствие, не воспринимайте все буквально. это традиция у топов Сбера, такая: в начале каждого года набрасывать в духе «перестроить процессы, уволить 10% сотрудников, повысить эффективность, бла-бла-бла». где-то между «профукали X ярдов» и «увеличили выручку в Y раз».
Напротив, мне кажется, что он весьма последователен, говоря о будущем отечественных программистов в широком смысле слова.
Осталось развалить систему образования, поднять уровень коррупции, ограничить доступ в интернет, снизить уровень доходов и полная глобальная интеграция с коллегами будет обеспечена (если что БРИКС это Brazil, Russia, India, China, South Africa).
Возможно имелась ввиду та часть индустрии, которая отвечает непосредственно за покупку железа и софта для разработчиков. Там все как описывает Дмитрий — денег нет, отдают последние штаны. :)
Тоже отметил, что IDE компании JetBrains способствуют появлению на рабочих программистов нормального железа, планок по 16GB памяти, SSD дисков, топовых процессоров, многомониторных конфигураций и тому подобных прикольных вещей. Несомненно, системные требования этого софта вынуждают бизнес делиться капиталлом с обслуживающей его отраслью и даёт толчки развитию IT-индустрии в целом. Видимо, индустрия должна быть благодарна за это настолько, что с недавнего времени эта «адвокатская контора» повысила стоимость своих услуг в разы, перейдя с разовых лмцензионных отчислений на повремянку. Следующим шагом станет процент с выручки, за крышевание? ;)
Деньги служат мотиватором к труду лишь в каком-то диапазоне. Когда их нет совсем, они добываются иными способами. Когда их становится «достаточно», мотивируют уже совсем другие вещи. Думаю корни проблемы нужно искать не в плоскости паталогической тяги к туниядству, а в нежелание терять инструмент влияния.
TLA+ от майкрософт это гениально :)
Здесь оба глагола Write() и WriteLn() связаны с подлежащим program Example (читаются как program Example Write('Hello '), program Example WriteLn('World!')), а не существуют сами по себе.
В отличие от английского, в русском языке, можно опускать разные части предложения (программу можно читать в безличной форме как «написать(»Hello "); написать(«World! „)). Это создает новые семантические контексты в понимании “естественности». Не думаю, что это хорошо, скорее просто выносит мозг, поскольку приводит к неправильным выводам.
Понимание метода как действия, приводит обычно к скатыванию в «процедурщину»: модулям, библиотекам функций и т.п. (это не в смысле «хорошо» или «плохо», а в смысле «не-ООП»). Это, кстати, хорошо видно в вашем примере, где появляется дополнительная инструментина для выполнения действий над файлами «fileSystem.close()», а сам file автоматически превращается тупо в данные.
Если на пальцах. Абстрактный проект в вакууме живет 3-5 лет. Время на разработку составляет 3-5 месяцев (т.е. всего лишь 10% срока жизни, Карл!). Остальные 90 приходятся на этапы внедрения и эксплуатации. 3 года в современном мире это большой строк, за который бизнес-ситуация может поменяться несколько раз. Соответственно, команде разработки неизбежно приходится сталкиваться с задачами модификации кода. В определенном смысле, код переходит в состояние эксплуатации сразу как только закрывается задача в трекере на его разработку. Необходимость в модификациях может выявится уже на самых ранних этапах — тестирования, внедрения, и т.д. Модификации влекут за собой риски возникновения дополнительных ошибок и регрессий в ранее отлаженном приложении и соответствующих издержек на их устранение (включая упущенную прибыль, финансовые риски по взаимоотношениям с клиентами, следующими из SLA, и т.п.). Учитывая масштабы, решение вопросов минимизации регрессий и снижения затрат на эксплуатацию становится, как минимум, интересным.
Какие варианты могут быть предложены в инженерном плане? Из очевидного: если два компонента между собой ни как не связаны, то изменения в одном компоненте не приведут к ошибкам в другом. Поэтому большие штуки есть смысл разделять на отдельные и независимые. В случае чего чинить придется меньше, вникать — проще, а все вместе — дешевле.
Отсюда следуют выводы о необходимости модульности (в широком смысле), компонентов и т.п. Но все эти навороты являются отдельными архитекрутными штуковинами, которые привносят в код дополнительную сложность и свои издержки.
Искусство хорошего дизайна здесь состоит в том, чтобы правильно определить границы модулей. Чтобы издержки, связанные с модульностью, оставались ниже соответствующих издержек на модификацию кода в отсутствии этой самой модульности.
Плохой дизайн не уменьшает количество связей, соответственно не сужает границ распространения ошибок, но лишь увеличивает количество сущностей, что приведет лишь еще большему к повышению сложности и затрат, без какого-либо профита. Здесь же ошибки, связанные с чрезмерной и неправильной декомпозицией, когда затраты на разработку и поддержку модульности начинаю превышать профит от её использования.
Шаблоны проектирования описывают типовые приемы декомпозиции в типовых случаях. Система описания шаблонов достаточно универсальна, она не связана с ООД, хотя основная масса литературы выпускается именно про них.
Проблемы выразительной подачи материала здесь, как мне кажется, появляются именно из-за того, что при знакомстве с паттернами, студент неявно ставится в роль кодера на этапе разразработки, а модульность сама по себе привносит в разработку сложность. Отсюда и вопрос «А зачем так усложнять?». Но профит от модульности становится очевиден лишь на этапе эксплуатации, когда возникает задача модификации. Причем, чем больше контекст, тем ярче ощущения от резолюции «да тут надо лишь одну строчку поменять» и сильнее инсайт от понимания «и при этом я уверен, что больше ни где ни чего не сломается».
обещаютопенсорсят. Напомните какой-нибудь их софт, который под линуксами работает классно?Встраивая ChakraCore в Node.js они решают вполне конкретную бизнес-задачу с продвижением Azure — там для Chakra (у которого CharkaCore лишь маленький кусочек) куча своих фишек, но проблемы с отсутствием конечных js-библиотек и фреймворков, которые в массе своей точатся под ноду, что снижает привлекательность платформы. Неспешно портировав базовые куски интерпретора на линуксы, они получат дополнительные возможности в плане регрессионного тестирования, и, вероятно, пересаживания разработчиков. Это все понятно. Но JIT это сильно более хитрое колдунство, как для технарей, так и для бизнесов, чем просто интерпретатор (посмотрите на Java, и историю развития альтернативных JVM). JIT для линуксов если и появится, то будет не настолько бесплатным, чтобы оставался смысл не пользоваться Azure. Тут вам не Googe))
без JIT не нужно
Интересность вашего решения как сервиса зависит от SLA.
Осталось развалить систему образования, поднять уровень коррупции, ограничить доступ в интернет, снизить уровень доходов и полная глобальная интеграция с коллегами будет обеспечена (если что БРИКС это Brazil, Russia, India, China, South Africa).
Иногда складывается впечатление, что они меняют расположение звёзд на небе, или фазу Луны. ;)