По моему мнение, именно архитектор должен разбираться в системе больше любого другого программиста. В противном случае - его архитектура будет представлять из себя мир розовых пони производящих радугу, который эффективно реализовать в рамках поставленной задачи не будет представляться сколько-нибудь возможным. Даже не смотря на то, что мир розовых пони офигенен. Наглядным примером тому служит язык Haskel. Где мир розовых пони реализован во всей красе с точки зрения архитектуры конечно. Но есть очень большие проблемы с его практической - системной реализацией. Не потому что это было сделать нельзя, но потому, что специалистов строящих мир розовых пони, много больше чем специалистов которые могут это оформить в эффективный код.
00:55:00 О том же. вот тут лектор повторяет слово в слово озвученную мной мысль. Проблем только в том, что все что делает лектор дальше - это нарушение этого тезиса. Строгая фиксация на архитектуре как на мире розовых пони.
00:58:45 *Первые статьи о архитектуре появились только в 90-тых* Этот тезис лектора требует с его стороны серьезного пояснения. Хотябы потому, что даже не типизированное лямбда исчисление это пример эффективной архитектуры описанной еще в начале 20 века. А не в конце как заявляет лектор.
01:00:00 *ООП вошло в моду с развитием графических интерфейсов* Как сказал лектор, само ООП, как концепция возникло в 60тых годах. Далее лектор, пытается навязать мысль, что непопулярность ООП было вызвано отсутствием графических интерфейсов. То есть именно этот фактор был основным, мешающим развитию этой концепции. В академической среде существует более обоснованная версия этого процесса. Которая связана с тем, что ООП это наиболее простой механизм, где подготовка специалиста занимает пол года. И именно 90тые годы - как бум развития вычислительных мощностей требовал массу программистов. Парадигма функционального программирования, требовало многолетней подготовки специалистов. Что не мог позволить себе рынок в то время. Как следствие ООП расцветает буйным цветом будучи откровенно ущербной концепцией, что доказывалось на протяжении 30 лет до, НО ИМЕЮЩЕЙ НЕОСПОРИМОЕ преимущество - специалист в ООП готовится пол года. Специалист в ФП 5 лет.
Важно различать архитектуру и архитектурное описание. Архитектура есть всегда у всего искусственного: у стула, у машины, у ПП. Архитектурного описания может и не быть вовсе
Автор ноль полный, балабольство в стиле UML "архитекторов", уже должно любого у кого все ОК с логикой насторожить понятие - плохая/хорошая архитектура. Что такое плохая, что такой хорошая? Критерий оценки не задан, и как я понимаю этот персонаж даже не не осознает что исспользовать такие термины не имеет смысла. Далее всё в таком же стиле.
24:00 содержательная часть
Содержательная часть: 24:00
Не знаю зачем, но я опустился сюда в надежде на это
Классный курс, крайне рекомендую!
Спасибо, очень редкая и нужна информация.
По моему мнение, именно архитектор должен разбираться в системе больше любого другого программиста. В противном случае - его архитектура будет представлять из себя мир розовых пони производящих радугу, который эффективно реализовать в рамках поставленной задачи не будет представляться сколько-нибудь возможным.
Даже не смотря на то, что мир розовых пони офигенен.
Наглядным примером тому служит язык Haskel. Где мир розовых пони реализован во всей красе с точки зрения архитектуры конечно. Но есть очень большие проблемы с его практической - системной реализацией. Не потому что это было сделать нельзя, но потому, что специалистов строящих мир розовых пони, много больше чем специалистов которые могут это оформить в эффективный код.
00:55:00 О том же.
вот тут лектор повторяет слово в слово озвученную мной мысль. Проблем только в том, что все что делает лектор дальше - это нарушение этого тезиса. Строгая фиксация на архитектуре как на мире розовых пони.
00:58:45 *Первые статьи о архитектуре появились только в 90-тых*
Этот тезис лектора требует с его стороны серьезного пояснения. Хотябы потому, что даже не типизированное лямбда исчисление это пример эффективной архитектуры описанной еще в начале 20 века. А не в конце как заявляет лектор.
01:00:00 *ООП вошло в моду с развитием графических интерфейсов*
Как сказал лектор, само ООП, как концепция возникло в 60тых годах.
Далее лектор, пытается навязать мысль, что непопулярность ООП было вызвано отсутствием графических интерфейсов. То есть именно этот фактор был основным, мешающим развитию этой концепции.
В академической среде существует более обоснованная версия этого процесса. Которая связана с тем, что ООП это наиболее простой механизм, где подготовка специалиста занимает пол года. И именно 90тые годы - как бум развития вычислительных мощностей требовал массу программистов.
Парадигма функционального программирования, требовало многолетней подготовки специалистов. Что не мог позволить себе рынок в то время. Как следствие ООП расцветает буйным цветом будучи откровенно ущербной концепцией, что доказывалось на протяжении 30 лет до, НО ИМЕЮЩЕЙ НЕОСПОРИМОЕ преимущество - специалист в ООП готовится пол года. Специалист в ФП 5 лет.
@@demimurych1лучшее враг хорошего. Специалисты в фп потом и наваяли Haskell.
Важно различать архитектуру и архитектурное описание. Архитектура есть всегда у всего искусственного: у стула, у машины, у ПП. Архитектурного описания может и не быть вовсе
Очень крутой преподаватель, респект
Как же я это все осилю?
Ну, сейчас в современной коммерческой разработке и для разраба софт-скиллы, в т.ч. способность к эффективной коммуникации и эмпатия, также важны.
Я подумал речь о строительной архитектуре... Смотрю и думаю - ничего не понимаю, неужели я такой тупой!? XD
У кого есть домашки по курсу?
НАКАНЕЦТА!
Автор ноль полный, балабольство в стиле UML "архитекторов", уже должно любого у кого все ОК с логикой насторожить понятие - плохая/хорошая архитектура. Что такое плохая, что такой хорошая? Критерий оценки не задан, и как я понимаю этот персонаж даже не не осознает что исспользовать такие термины не имеет смысла. Далее всё в таком же стиле.