вообще-то проблема интернациональная. АП влияет на отношения между государствами и отменить копирайт только в одной стране в наше время — это создать прецендент и скандал.
Думаю что хоть какой-то прогресс в этой области может сделать международная группа, которая будет воевать с АП повсеместно доказывая ее неконституционность.
Ну, есть те кто делает хобби профессией, а есть те кто нет.
Если ты требуешь за свою работу денег, то наверно ожидать что к ней будут применяться определенные требования.
С другой стороны история знает кучу примеров, когда любители делали лучше чем профи.
А насчет абсурда — это именно так, ну почти, если забыть что «exe» файл делает компилятор, которому программист подсовывает программу, которую надо бы еще и написать, перед чем неплохо бы понять зачем.
С точки зрения того что такое программирование — это несущественные мелочи.
Важно не то как и на чем и сколько данный индивид решал данную задачу. Важно что он увидел в этом задачу, свог ее формализовать и придумать как решить и реализовал. Все! Пусть хоть пирамиду для этого строит, важен результат — если пирамида может решить проблему, значить ее создатель — программист.
Разнообразные фреймоврки, билдеры и конструкторы просто позволяют большему количеству народа вкусить прелести, прежде доступные лишь посвященным. Это не ставит разные системы на одну доску, но человек, который взял и воплотил свою задумку в реальность — программист и не важно сделал он это в вижуал билдере или на ассемблере. Так же как и не важно знает ли он какой-нить пузырек или поиск подстроки, если результат на лице.
Да, качество может быть разным — профи сделает быстрее и лучше, а любитель — хуже, но оба будут при этом программистами.
Ну давайте по приколу перенесемся лет на 10 в будущее. Вам сильно поможет знание конкретных детерменированных алгоритмов в системе с вероятностными механизмами? Фреймворки правда идут тем же лесом.
Программист — это в последнюю очередь конкретный инструмент, ЯП или недайбоже фреймворк, система с плагинами или что там еще используется для решения конкретной задачи.
В первую очередь — это способность формализовать задачу, во вторую — довести формализованную задачу до какого-то алгоритма, в третью — реализовать этот алгоритм на чем-нить. Знание конкретных алгоритмов полностью равно знанию конкретных инструментов — для какого-то круга задач это имеет смысл, для другого достаточно лишь знание параметров, а для всех остальных это знание академическое.
Вот например для того что бы отсортировать массив я использую «order by» и уж поверьте, для любой практической цели конкретный алгоритм, который при этом используется, мне важен в последнюю очередь.
я думаю чувствительность людей будет понижаться с массовым появлением таких устройств, но могут появиться уникумы, которые так будут питаться или научаться быстро находить свои мобильники :)
А вообще плитки и микроволновки достаточно давно в быту и ни к чему серьезному пока не привели. А тем у кого есть чувствительность — не привыкать, потому как точно такое же по мощности поле наблюдается в куче девайсов
• Почти каждый день после 5 вечера — пиво за счёт компании
• Раз в неделю (или после сдачи проекта) после 6 вечера — текила/коньяк/самогон, иногда всё вперемешку
имхо так и спиться недолго.
А еще пиво чаще чем раз в неделю как-то делает мир проще и понятней, но это ближе к маразму, чем к мудрости.
Имхо, C# таже как и Java предназначены совсем для другого класса решений нежели JS или куча других скриптоков языков, которые могут это. И другая сторона такой легкости — ужасный спагетти из nested фунькций, которую очен сложно поддерживать.
в таких случаях надо ставить проблему по другому. Не человек выделяется на проект на 30% а проекту требуется определенная работа, в данном случае экспертиза. И это может быть как свой специалист, так и приглашенный или вообще внешняя фирма, которая как-то там распределяет свои ресурсы что бы выполнить задачу.
Для своего специалиста в этом случае нужно просто ставить задачи в очередь. И как их планировать — надо решать вместе со специалистом — то как он видит свой time management. Некоторые умеют решать эффективно задачи параллельно, выполняя этапы и переключаясь между ними, некоторые так не умеют и должны полностью погрузиться в задачу пока не выполнят.
В любом случае для проекта такие задачи — внешние, то есть аутсорс или субподряд, если по-русски. Как с ними работать — отдельная песня :)
Модели намного лучше для восприятия. Схематичную модель улицы вспомнить проще, если она конечно близка к правде и некая шаблонность убирает кучу ненужных деталей облегчая работу мозгу.
В общем, после некоторого размышления, увлечение OOП приводит к неэффективному коду. Немножно — очень хорошо для сокрытия кишок, но если весь фреймворк или продукт пронизан идеологией ООП то по приходящим мне в голову примерам получается не очень.
Это как в БД — нормализовывать можно до упора, но городить потом джойны задалбывает, да и при оптимизации вся эта шелуха слетает.
Не, закон определяется интересами законотворцев, которые как-то опосредовано связаны с моральными императивами какой-то части общества. Но вообще-то закон тут ни при чем — например воровать по закону наказуемо, но воруют, причем цинично, разве что не рискуют об это публично заявить.
лично мне интересно то что мне интересно :) что-то новое, о чем я имел только общее представление и мало опыта.
В целом я вижу что это не вписывается в стандартные бизнес выражения.
Да, поставь сработавшуюся группу умных людей в жесткие условия и они родят что-нить гениальное. Как тут не вспомнить тенденцию последних времен ублажать разработчиков мощностью компов и лабораторных систем. :))))))
Хотелось бы также услышать про дальнейшую историю развития. BSD SystemV и так далее до появления существующих форков, также попутные истории про X11, про заимствования, GNU…
Если говорит об информации то стоит сразу думат о бекапе — это любой админ вам скажет. А 10 или 100 скрижалей по сравнению с миллионом лет — фигня и недостаточно. Надо думать о миллионах копий, которые по идее должны делать себя сами. Очевидно что мы приходим к записи в ДНК. Думаю стоит вывести какую породу лишайников или может быть неколько видов в разных царствах с неиспользуемым в ДНК куском в котором зашифровать нужную инфу.
Понятно что защита от ошибок требует проработки
Понятно что инфа для потомков должна быть самопрочитываемой. Хотелось бы конечно получить вируса, который пройдя гематоэнцифалический барьер быстренько состряпает картинку со звуков прямо в сознание, но это фантастика :)
А еще можно сделать саморазвивающуюся машину, которой дать задание — отвечать на некоторые вопросы и строить себе замену и копию на случай повреждения. Потомкам помимо знаний о могильнике наверняка пригодятся оракулы и прочие идолы после очередного апокалипсиса.
Когда что-то делаешь то сначала конечный результат должен быть сделан в воображении и только потом в реальности.
Ремесленник имеет некий набор известных результатов и сразу может приступать к реализации, как только поймет что из этого надо. Есть другая профессия — дизайнер, которые придумывает новые вещи. Конечно очень хороший ремесленник может быть дизайнером но это нечто дополняющее ремесло, а не присущее ему изначально.
Программирование же включает в себя дизайн и только очень хорошие и опытные могут работать как ремесленники и выдавать стабильный результат. Могут но не должны ограничиваться.
Человек писавший статью явно отрицает творческую составляющую профессии и тем самым ограничивает себя. Отсюда и весь тот бред про архитектуру и прочее в последних пунктах. Хотя с отдельными вещами можно согласиться.
Думаю что хоть какой-то прогресс в этой области может сделать международная группа, которая будет воевать с АП повсеместно доказывая ее неконституционность.
Если ты требуешь за свою работу денег, то наверно ожидать что к ней будут применяться определенные требования.
С другой стороны история знает кучу примеров, когда любители делали лучше чем профи.
А насчет абсурда — это именно так, ну почти, если забыть что «exe» файл делает компилятор, которому программист подсовывает программу, которую надо бы еще и написать, перед чем неплохо бы понять зачем.
Важно не то как и на чем и сколько данный индивид решал данную задачу. Важно что он увидел в этом задачу, свог ее формализовать и придумать как решить и реализовал. Все! Пусть хоть пирамиду для этого строит, важен результат — если пирамида может решить проблему, значить ее создатель — программист.
Разнообразные фреймоврки, билдеры и конструкторы просто позволяют большему количеству народа вкусить прелести, прежде доступные лишь посвященным. Это не ставит разные системы на одну доску, но человек, который взял и воплотил свою задумку в реальность — программист и не важно сделал он это в вижуал билдере или на ассемблере. Так же как и не важно знает ли он какой-нить пузырек или поиск подстроки, если результат на лице.
Да, качество может быть разным — профи сделает быстрее и лучше, а любитель — хуже, но оба будут при этом программистами.
Программист — это в последнюю очередь конкретный инструмент, ЯП или недайбоже фреймворк, система с плагинами или что там еще используется для решения конкретной задачи.
В первую очередь — это способность формализовать задачу, во вторую — довести формализованную задачу до какого-то алгоритма, в третью — реализовать этот алгоритм на чем-нить. Знание конкретных алгоритмов полностью равно знанию конкретных инструментов — для какого-то круга задач это имеет смысл, для другого достаточно лишь знание параметров, а для всех остальных это знание академическое.
Вот например для того что бы отсортировать массив я использую «order by» и уж поверьте, для любой практической цели конкретный алгоритм, который при этом используется, мне важен в последнюю очередь.
А вообще плитки и микроволновки достаточно давно в быту и ни к чему серьезному пока не привели. А тем у кого есть чувствительность — не привыкать, потому как точно такое же по мощности поле наблюдается в куче девайсов
имхо так и спиться недолго.
А еще пиво чаще чем раз в неделю как-то делает мир проще и понятней, но это ближе к маразму, чем к мудрости.
Так что это не плюс для С# а минус :)
Для своего специалиста в этом случае нужно просто ставить задачи в очередь. И как их планировать — надо решать вместе со специалистом — то как он видит свой time management. Некоторые умеют решать эффективно задачи параллельно, выполняя этапы и переключаясь между ними, некоторые так не умеют и должны полностью погрузиться в задачу пока не выполнят.
В любом случае для проекта такие задачи — внешние, то есть аутсорс или субподряд, если по-русски. Как с ними работать — отдельная песня :)
Это как в БД — нормализовывать можно до упора, но городить потом джойны задалбывает, да и при оптимизации вся эта шелуха слетает.
В результате от ООП остаются только интерфейсы :)
В смысле проблемы Сбера не в плоскости IT, а в людях, которые работают с этими системами.
В целом я вижу что это не вписывается в стандартные бизнес выражения.
Хотелось бы также услышать про дальнейшую историю развития. BSD SystemV и так далее до появления существующих форков, также попутные истории про X11, про заимствования, GNU…
Понятно что защита от ошибок требует проработки
Понятно что инфа для потомков должна быть самопрочитываемой. Хотелось бы конечно получить вируса, который пройдя гематоэнцифалический барьер быстренько состряпает картинку со звуков прямо в сознание, но это фантастика :)
А еще можно сделать саморазвивающуюся машину, которой дать задание — отвечать на некоторые вопросы и строить себе замену и копию на случай повреждения. Потомкам помимо знаний о могильнике наверняка пригодятся оракулы и прочие идолы после очередного апокалипсиса.
Ремесленник имеет некий набор известных результатов и сразу может приступать к реализации, как только поймет что из этого надо. Есть другая профессия — дизайнер, которые придумывает новые вещи. Конечно очень хороший ремесленник может быть дизайнером но это нечто дополняющее ремесло, а не присущее ему изначально.
Программирование же включает в себя дизайн и только очень хорошие и опытные могут работать как ремесленники и выдавать стабильный результат. Могут но не должны ограничиваться.
Человек писавший статью явно отрицает творческую составляющую профессии и тем самым ограничивает себя. Отсюда и весь тот бред про архитектуру и прочее в последних пунктах. Хотя с отдельными вещами можно согласиться.