У Вас какое-то странное сравнение. Компилируемые языки сравниваете с интерпретируемыми, имея прекрасное понимание того, какие задачи решаются обычно этими языками.
На C++ не пишут сайты и блоги, это инструмент для абсолютно других задач, и в этом смысле, если говорить о веб-приложениях, то без разницы на чем писать — на Python, PHP, Perl, JavaScript и т.д.
В этом плане разницы между этими языками практически нет, они все императивные (с примесью функциональщины). И паттерны с SOLID'ом везде одинаковые.
Если человек хорошо ориентируется во всяких ActiveRecord, DataMapper, DAO, Front Controller и т.д., то это означает что он без проблем освоит любой из перечисленных языков (опять же в рамках веб-программирования), потому что он с этими принципами уже работал в другом языке.
И если завтра компания вместо React.js захочет взять Vue.js, значит ли это что нужно судорожно начинать искать специалистов по Vue, потому что программисты в компании пишут на React?
Либо наоборот, искать людей с опытом работы с фреймворком от двух лет, в то время как фреймворк вышел только полгода назад (были кажется такие приколы)?
Думаю что автор тут как раз пытается сказать что существует непонимание многими работодателями (и возможно даже самими программистами) принципов разработки ПО, и если человек, например, не работал с Vue, но работал с React, это не означает что его кандидатуру нужно немедленно режектить минуя оценку общих знаний и опыта кандидата.
Рекурсия хорошо описывается математически и не надо быть гением, чтобы это понять.
Рекурсия как явление в целом, бесспорно. Но автор затрагивает такое понятие как "стек вызовов", которое не очень-то старается объяснить. Также замалчивает что рекурсивная функция не может выполняться бесконечно (в отличие от цикла), потому что произойдет переполнение стека у исполняющего потока.
Возможно такое объяснение подойдет для совсем новичков, но тогда возможно и не стоило приплетать сюда низкоуровневые понятия. То есть, на мой взгляд, получилось "ни рыба ни мясо".
ИМХО, проще понять и объяснить рекурсию на уровне ассемблера, чем на уровне какой-то "стопки коробок".
Кроме того, автор немного недоговаривает, когда говорит что
рекурсивные функции используют так называемый «Стек вызовов»
в реальности же практически все функции используют "стек вызовов", и рекурсивных функций, как какого-то особого явления, не существует (по крайней мере на низком уровне).
Различают рекурсивные функции в основном только языки высокого уровня, и то, исключительно для возможных оптимизаций или предотвращения бесконечных вызовов (например в Python глубина рекурсии ограничена интерпретатором) .
Так что в данном случае действительно проще было нарисовать гифку, где было бы показано как процессор выполняет инструкции, чем графоманить и снимать бессмысленное видео.
Не знаю причем тут магия, но то что Вы видите в строке 7, называется Uniform Function Call Syntax, который позволяет писать функции не по-отдельности, а через точку, в таком случае первый аргумент функции будет являться тем объектом, к которому Вы эту функцию присовокупили (иными словами foo(a); это аналог a.foo();): https://tour.dlang.org/tour/ru/gems/uniform-function-call-syntax-ufcs
И эта особенность как раз сильно сокращает время на чтение и понимание кода. А также дает некоторые интересные возможности.
В качестве "некстгена плюсов" однозначно D, но к сожалению в текущей реализации на 100% плюсы он заменить не может, если конечно не писать без использования сборщика мусора. Хоть это и возможно, но все равно без GC теряются дефолтные фишки языка такие ассоциативные массивы, делегаты и т.д. (в будущем возможно будут какие-то изменения касательно отвязки библиотеки от GC). В принципе и для этих примитивов есть замена без GC, если понадобится.
Сейчас D напоминает скорее нечто среднее между C# и Java, но только не требующее никаких виртуальных машин и рантаймов, т.к. исполняемый файл можно статически слинковать со всеми необходимыми библиотеками.
Для большинства прикладных задач сборщик мусора ничем не мешает и даже очень сильно помогает.
Ну и плюс если хочется совсем низкий уровень или откат к C, есть режим Better-C.
Так что если не пишите какие-то супербыстрые сетевые сервисы, то из этих двух однозначно D (хотя для сетевых сервисов в D есть фреймворк vibe.d)
Апогей конкуренции — оружие массового поражения. Химическое, ядерное, биологическое. Действительно ли оно необходимо для выживания? И такое ли разнообразие Вы имеете в виду?
Идея в том, чтобы наглядно показать людям что есть другой путь развития, который позволит им существовать в гармонии друг с другом и с природой, поскольку согласно одной из концепций проекта (в основе которой лежит бихевиоризм), человеку невозможно выйти за пределы той среды, в которой он существует, не обладая знаниями, т.к. среда и определяет его поведение. Или словами исторического материализма: «бытие определяет сознание».
Проблему автоматизации рутины совсем необязательно решать в рамках стандартов текущего времени.
Вполне реально посмотреть на эти задачи под другим углом, закладывая возможность автоматизации еще на этапе создания инфраструктуры.
1. Мышление в пределах самой проблемы скорее всего не сможет дать ответы на вопрос о том как автоматизировать работу сантехника, т.к. сама конструкция помещений (в том числе жилых) не предусматривает обслуживание ключевых узлов при помощи робототехники.
Иными словами, чтобы решить проблему, необходимо выйти за ее рамки.
Кроме того, концепт 3D печати, вероятно, открывает достаточно интересные горизонты по автоматизации.
2. Насколько мне известно, «офисным планктоном» обычно называют офисных работников низшего звена, к которым невозможно отнести инженеров.
Конечно существуют разные трактовки, но здесь я отталкиваюсь от этих: Lurkmore Cyclowiki
В рамках упомянутого проекта «Венера», автоматизация инженеров и ученых не предполагается вовсе, т.к. робототехника не обладает сознанием.
Как уже было упомянуто выше, цель автоматизации — освобождение человека от рутины (продавцы, кассиры, секретари, бухгалтеры, водители такси, сборщики в цехах и т.д.), для выделения времени на решение более сложных, творческих задач.
В условиях капиталистической экономики автоматизация является вполне логичным шагом по удешевлению стоимости производства и обслуживания, но этот вид экономики не отвечает на вопрос что делать с технологической безработицей.
Становятся более актуальными концепции базового безусловного дохода, но это скорее «костыль» к капитализму, чем реальное решение.
Соглашаясь с Вами по части того, что не всю рутину можно автоматизировать, все же дополнил бы фразу таким образом: «не всю рутину можно автоматизировать в рамках текущей экономической системы».
Решение этих проблем лежит за рамками существующей общественной формации, но тем не менее текущие и грядущие научные открытия и технологии создают серьезный базис для качественного перехода на следующий этап развития начиная уже с сегодняшнего дня.
Вся проблема лишь в консолидации труда инженеров и ученых.
В условиях же общих ресурсов (ресурсно-ориентированной экономики) и повсеместной автоматизации, старикам не придется работать до 80 лет, как говорится в этой статье. Они смогут заниматься более интересными вещами, принося при этом гораздо большую пользу обществу из-за накопленного ими жизненного опыта.
Кто выгодоприобретатель? Идеолог, который, если дело выгорит, станет самым крутым паханом на планете. А если не выгорит, можно остаток жизни продавать книги, гастролировать с семинарами и прочими атрибутами жизни Остапа Бендера.
Жаку Фреско (главному идеологу проекта) 13 марта исполнился 101 год. Если смотреть реалистично, то при всем желании он уже не сможет стать «выгодоприобретателем».
Кроме того, сам вопрос в такой его формулировке, похоже, не имеет смысла, если имеется в виду выгода конкретного человека-организатора.
Контрпример: «Кто выгодоприобретатель марксизма?», либо «Кто выгодоприобретатель ресурсно-ориентированной экономики?»
На вольных хлебах, разумеется, специалисты скажут: «Нам не интересно пилить костыли и решать проблему сейчас, лучше мы проведём исследование, сделаем новый дизайн архитектуры, и представим новую совершенную версию, лет через 10… Если интерес не пропадёт».
Исчезновение экономического принуждения (которое является основой капитализма) не означает исчезновение научно-технического прогресса.
Принцип «эксплуатации человека человеком» теряет смысл с появлением и развитием робототехники. Само понятие трансформируется в «эксплуатацию робота человеком».
Но т.к. роботы не обладают сознанием, они способны решать лишь те проблемы, для которых их создал человек.
Остальные же проблемы никуда не исчезают. Автоматизация стремится высвободить человеческое время и ресурсы для решения других, более сложных задач, которые требуют созидательной (творческой) силы, которой машины не имеют.
Касательно Ваших утверждений это означает что дисциплина управления проектами также никуда не исчезает, т.к. остается задача оптимального распределения времени (она же задача оптимизации). Поскольку жизнь человека ограничена на фундаментальном уровне, время может считаться точно таким же ресурсом, как и все остальные.
Вообще любой ключевой специалист (тот же главный архитектор CPU) в странах развитого капитализма в принципе уже не подвержен такому экономического гнету, как люди, трудящиеся на нетворческих работах.
Очевидно что такой специалист уже не может быть простимулирован премиальными. Следовательно характер его стимула качественно отличается от стимула человека, работающего, к примеру, кассиром в магазине, поскольку многие базовые потребности архитектора CPU уже решены за счет компании.
И конкуренция, к примеру, Intel и AMD (если условно принять что они работают в одном сегменте, хотя это не так) влияет скорее на цену товаров (или же доступность для массового потребителя), чем на их технологические возможности, поскольку мощность процессоров растет, но также усложняются и задачи ими решаемые.
Иными словами, при смене парадигмы, вероятность того, что главный архитектор CPU уйдет «раскрашивать морды котиков в стиле Ван-Гога» на полный рабочий день, очень мала, поскольку задачи стоящие перед архитектором (и не только) никуда не исчезнут.
Рекомендую ознакомиться с тем, что именно предлагает «Проект Венера» (например на YouTube).
Также речь идет в частности и об отсутствии всякой конкуренции.
Производство и распределение товаров предлагается не на основе стандартной схемы товарообмена (типа «Товар-Деньги-Товар»), а на основе разумного распределения имеющихся ресурсов (признание их общими) и использования технологий, которые должны быть «расшарены» между всеми примерно как Public Domain.
Относительно Вашего примера это означает, что Intel с Huawei'ем как производили, так и производят. Просто продукция признана общей и распределяется в соответствии с потребностями.
Может, конечно, не совсем в тему я об этом написал, т.к. в этом проекте речь уже не идет о капитализме, по крайней мере в том виде, в котором мы его знаем сегодня.
Но сама идея построения городов, в которых предусмотрены автоматизированные транспортные сети, плантации для выращивания сельхоз.культур и прочее, решили бы проблемы с пенсионерами (и не только), т.к. роботам не надо ни есть, ни спать, ни получать зарплату, чтобы производить продукты, по крайней мере первично необходимые (еда, лекарства и т.д.).
И самое интересное здесь то, что большинство этих проблем уже возможно решить технологиями сегодняшнего дня. Вся проблема именно в консолидации труда ученых/инженеров.
Странно, что никто не упоминает про Project Venus, ведь проект как раз об этом.
На сегодняшний день технологии достигли уже такого уровня, на котором вполне реально строить автономные города-поселения, обеспечивающие людей всем необходимым (а базовые потребности это еда/вода и жилье, в общем-то).
Проблема только одна — как раз заставить множество людей «начать специально мощно напрягать булки» ради этой цели =)
1) Никто и не скрывает, что Eloquent реализует шаблон ActiveRecord.
Это и есть объединение слоя бизнес-логики и слоя работы с БД. Применяется такой шаблон преимущественно в целях RAD.
Doctrine же реализует шаблон DataMapper, UnitOfWork и многое другое, что очень полезно для Domain Driven Development. Но, думаю, Вы согласитесь что для проектов малого и среднего уровня это просто из пушки по воробьям.
2) Я сталкивался с некоторыми проблемами в Blade (в Laravel 4), связанными в основном с наследованием и подключением файлов. Но в целом он достаточно удобен.
Цель — сделать синтаксис шаблонов более читаемым по сравнению со стандартным PHP (по-сути синтаксический сахар).
Кроме того, в Blade вы можете сразу вызывать любой PHP код используя тот же самый синтаксис, в отличие от Twig, который заставляет добавлять собственные функции/конструкции, если требуется что-то новое.
Причина такого подхода, опять же, указана в первом пункте (RAD).
3) То что Laravel базируется на некоторых компонентах Symfony, говорит лишь о том, что эти компоненты написаны хорошо и грех их не использовать, для того чтобы написать более простую и удобную обертку.
4) Фасады в Laravel — точно такой же синтаксический сахар для разработчика, как и шаблонизатор Blade. Исторически в PHP разработчики привыкли использовать статические классы, потому что этот подход был реализован во многих фреймворках, но используя этот подход приложение тяжело тестировать.
Таким образом, фасады — это просто "палочка выручалочка", когда хочется статических классов и при этом нужно писать тесты. Количество кода при использовании таких фасадов немного сокращается.
Кроме того, никто не заставляет использовать фасады — все можно решить через контейнер сервисов. Например в Lumen фасады по-умолчанию отключены.
В заключении можно сказать что Laravel — это developer-centric фреймворк (именно так) в котором огромное внимание уделяется красоте и лаконичности кода, удобству использования, а также скорости написания приложений.
Поэтому, ИМХО, Laravel'у быть, и никакой это не "хайп", в отличие, например, от Angular 1, который Google поматросил и бросил.
Собственно, даже само описание фреймворка очень емко и лаконично описывает его суть:
Laravel — The PHP framework for web artisans
Поэтому рекомендую Вам поближе ознакомиться с этими принципами и использовать их по назначению.
Подтверждаю. Для того чтобы сделать нормально, потребуется как минимум подключать дизассемблер длин инструкций, чтобы не сломать оригинальную логику своими JMP.
Конечно большинство функций из Windows библиотек имеют в своем теле некий stub, как раз для таких вещей, но все же остается ненулевая вероятность "порвать" опкоды оригинальной функции.
Ну и неплохо было бы упомянуть про Microsoft Detours, раз уж диалог идет об inline hooking'е.
Самое главное забыли написать про Vue — их подход к компонентам.
Вы можете создавать и поставлять отдельные компоненты с расширением *.vue (подмножество XML). Внутри этого файла могут лежать шаблоны, скрипты и стили.
Кроме того, если не хочется все складывать в один *.vue файл, компонент можно разнести отдельно на .css, .js, а в *.vue просто подключить эти файлы через атрибут src:
Я имею в виду слой бизнес-логики, реализующий предметную область, а также отвечающий за персистентность, например как Model в Backbone — описал модель, накидал туда логики (например валидация) и вызвал model->save().
Если, например, нужно смоделировать связи между объектами и т.д.
Какой у AngularJS стандартный способ решения таких задач?
У Вас какое-то странное сравнение. Компилируемые языки сравниваете с интерпретируемыми, имея прекрасное понимание того, какие задачи решаются обычно этими языками.
На C++ не пишут сайты и блоги, это инструмент для абсолютно других задач, и в этом смысле, если говорить о веб-приложениях, то без разницы на чем писать — на Python, PHP, Perl, JavaScript и т.д.
В этом плане разницы между этими языками практически нет, они все императивные (с примесью функциональщины). И паттерны с SOLID'ом везде одинаковые.
Если человек хорошо ориентируется во всяких ActiveRecord, DataMapper, DAO, Front Controller и т.д., то это означает что он без проблем освоит любой из перечисленных языков (опять же в рамках веб-программирования), потому что он с этими принципами уже работал в другом языке.
И если завтра компания вместо React.js захочет взять Vue.js, значит ли это что нужно судорожно начинать искать специалистов по Vue, потому что программисты в компании пишут на React?
Либо наоборот, искать людей с опытом работы с фреймворком от двух лет, в то время как фреймворк вышел только полгода назад (были кажется такие приколы)?
Думаю что автор тут как раз пытается сказать что существует непонимание многими работодателями (и возможно даже самими программистами) принципов разработки ПО, и если человек, например, не работал с Vue, но работал с React, это не означает что его кандидатуру нужно немедленно режектить минуя оценку общих знаний и опыта кандидата.
Рекурсия как явление в целом, бесспорно. Но автор затрагивает такое понятие как "стек вызовов", которое не очень-то старается объяснить. Также замалчивает что рекурсивная функция не может выполняться бесконечно (в отличие от цикла), потому что произойдет переполнение стека у исполняющего потока.
Возможно такое объяснение подойдет для совсем новичков, но тогда возможно и не стоило приплетать сюда низкоуровневые понятия. То есть, на мой взгляд, получилось "ни рыба ни мясо".
ИМХО, проще понять и объяснить рекурсию на уровне ассемблера, чем на уровне какой-то "стопки коробок".
Кроме того, автор немного недоговаривает, когда говорит что
в реальности же практически все функции используют "стек вызовов", и рекурсивных функций, как какого-то особого явления, не существует (по крайней мере на низком уровне).
Различают рекурсивные функции в основном только языки высокого уровня, и то, исключительно для возможных оптимизаций или предотвращения бесконечных вызовов (например в Python глубина рекурсии ограничена интерпретатором) .
Так что в данном случае действительно проще было нарисовать гифку, где было бы показано как процессор выполняет инструкции, чем графоманить и снимать бессмысленное видео.
Не знаю причем тут магия, но то что Вы видите в строке 7, называется Uniform Function Call Syntax, который позволяет писать функции не по-отдельности, а через точку, в таком случае первый аргумент функции будет являться тем объектом, к которому Вы эту функцию присовокупили (иными словами foo(a); это аналог a.foo();): https://tour.dlang.org/tour/ru/gems/uniform-function-call-syntax-ufcs
И эта особенность как раз сильно сокращает время на чтение и понимание кода. А также дает некоторые интересные возможности.
В качестве "некстгена плюсов" однозначно D, но к сожалению в текущей реализации на 100% плюсы он заменить не может, если конечно не писать без использования сборщика мусора. Хоть это и возможно, но все равно без GC теряются дефолтные фишки языка такие ассоциативные массивы, делегаты и т.д. (в будущем возможно будут какие-то изменения касательно отвязки библиотеки от GC). В принципе и для этих примитивов есть замена без GC, если понадобится.
Сейчас D напоминает скорее нечто среднее между C# и Java, но только не требующее никаких виртуальных машин и рантаймов, т.к. исполняемый файл можно статически слинковать со всеми необходимыми библиотеками.
Для большинства прикладных задач сборщик мусора ничем не мешает и даже очень сильно помогает.
Ну и плюс если хочется совсем низкий уровень или откат к C, есть режим Better-C.
Так что если не пишите какие-то супербыстрые сетевые сервисы, то из этих двух однозначно D (хотя для сетевых сервисов в D есть фреймворк vibe.d)
Зачет! Бизнес по-русски xD
Вполне реально посмотреть на эти задачи под другим углом, закладывая возможность автоматизации еще на этапе создания инфраструктуры.
1. Мышление в пределах самой проблемы скорее всего не сможет дать ответы на вопрос о том как автоматизировать работу сантехника, т.к. сама конструкция помещений (в том числе жилых) не предусматривает обслуживание ключевых узлов при помощи робототехники.
Иными словами, чтобы решить проблему, необходимо выйти за ее рамки.
Не могу привести никаких аргументов относительно асфальтоукладки, но в поисковике нашел несколько упоминаний и концептов:
http://plantingacorns.com/construction-trends/robotics-in-construction/
https://www.youtube.com/watch?v=nFgUERMndtQ
https://www.youtube.com/watch?v=Fjwozd3ZFiI
Кроме того, концепт 3D печати, вероятно, открывает достаточно интересные горизонты по автоматизации.
2. Насколько мне известно, «офисным планктоном» обычно называют офисных работников низшего звена, к которым невозможно отнести инженеров.
Конечно существуют разные трактовки, но здесь я отталкиваюсь от этих:
Lurkmore
Cyclowiki
В рамках упомянутого проекта «Венера», автоматизация инженеров и ученых не предполагается вовсе, т.к. робототехника не обладает сознанием.
Как уже было упомянуто выше, цель автоматизации — освобождение человека от рутины (продавцы, кассиры, секретари, бухгалтеры, водители такси, сборщики в цехах и т.д.), для выделения времени на решение более сложных, творческих задач.
В условиях капиталистической экономики автоматизация является вполне логичным шагом по удешевлению стоимости производства и обслуживания, но этот вид экономики не отвечает на вопрос что делать с технологической безработицей.
Становятся более актуальными концепции базового безусловного дохода, но это скорее «костыль» к капитализму, чем реальное решение.
Соглашаясь с Вами по части того, что не всю рутину можно автоматизировать, все же дополнил бы фразу таким образом: «не всю рутину можно автоматизировать в рамках текущей экономической системы».
Решение этих проблем лежит за рамками существующей общественной формации, но тем не менее текущие и грядущие научные открытия и технологии создают серьезный базис для качественного перехода на следующий этап развития начиная уже с сегодняшнего дня.
Вся проблема лишь в консолидации труда инженеров и ученых.
В условиях же общих ресурсов (ресурсно-ориентированной экономики) и повсеместной автоматизации, старикам не придется работать до 80 лет, как говорится в этой статье. Они смогут заниматься более интересными вещами, принося при этом гораздо большую пользу обществу из-за накопленного ими жизненного опыта.
Жаку Фреско (главному идеологу проекта) 13 марта исполнился 101 год. Если смотреть реалистично, то при всем желании он уже не сможет стать «выгодоприобретателем».
Кроме того, сам вопрос в такой его формулировке, похоже, не имеет смысла, если имеется в виду выгода конкретного человека-организатора.
Контрпример: «Кто выгодоприобретатель марксизма?», либо «Кто выгодоприобретатель ресурсно-ориентированной экономики?»
Исчезновение экономического принуждения (которое является основой капитализма) не означает исчезновение научно-технического прогресса.
Принцип «эксплуатации человека человеком» теряет смысл с появлением и развитием робототехники. Само понятие трансформируется в «эксплуатацию робота человеком».
Но т.к. роботы не обладают сознанием, они способны решать лишь те проблемы, для которых их создал человек.
Остальные же проблемы никуда не исчезают. Автоматизация стремится высвободить человеческое время и ресурсы для решения других, более сложных задач, которые требуют созидательной (творческой) силы, которой машины не имеют.
Касательно Ваших утверждений это означает что дисциплина управления проектами также никуда не исчезает, т.к. остается задача оптимального распределения времени (она же задача оптимизации). Поскольку жизнь человека ограничена на фундаментальном уровне, время может считаться точно таким же ресурсом, как и все остальные.
Вообще любой ключевой специалист (тот же главный архитектор CPU) в странах развитого капитализма в принципе уже не подвержен такому экономического гнету, как люди, трудящиеся на нетворческих работах.
Очевидно что такой специалист уже не может быть простимулирован премиальными. Следовательно характер его стимула качественно отличается от стимула человека, работающего, к примеру, кассиром в магазине, поскольку многие базовые потребности архитектора CPU уже решены за счет компании.
И конкуренция, к примеру, Intel и AMD (если условно принять что они работают в одном сегменте, хотя это не так) влияет скорее на цену товаров (или же доступность для массового потребителя), чем на их технологические возможности, поскольку мощность процессоров растет, но также усложняются и задачи ими решаемые.
Иными словами, при смене парадигмы, вероятность того, что главный архитектор CPU уйдет «раскрашивать морды котиков в стиле Ван-Гога» на полный рабочий день, очень мала, поскольку задачи стоящие перед архитектором (и не только) никуда не исчезнут.
Также речь идет в частности и об отсутствии всякой конкуренции.
Производство и распределение товаров предлагается не на основе стандартной схемы товарообмена (типа «Товар-Деньги-Товар»), а на основе разумного распределения имеющихся ресурсов (признание их общими) и использования технологий, которые должны быть «расшарены» между всеми примерно как Public Domain.
Относительно Вашего примера это означает, что Intel с Huawei'ем как производили, так и производят. Просто продукция признана общей и распределяется в соответствии с потребностями.
Может, конечно, не совсем в тему я об этом написал, т.к. в этом проекте речь уже не идет о капитализме, по крайней мере в том виде, в котором мы его знаем сегодня.
Но сама идея построения городов, в которых предусмотрены автоматизированные транспортные сети, плантации для выращивания сельхоз.культур и прочее, решили бы проблемы с пенсионерами (и не только), т.к. роботам не надо ни есть, ни спать, ни получать зарплату, чтобы производить продукты, по крайней мере первично необходимые (еда, лекарства и т.д.).
И самое интересное здесь то, что большинство этих проблем уже возможно решить технологиями сегодняшнего дня. Вся проблема именно в консолидации труда ученых/инженеров.
На сегодняшний день технологии достигли уже такого уровня, на котором вполне реально строить автономные города-поселения, обеспечивающие людей всем необходимым (а базовые потребности это еда/вода и жилье, в общем-то).
Проблема только одна — как раз заставить множество людей «начать специально мощно напрягать булки» ради этой цели =)
1) Никто и не скрывает, что Eloquent реализует шаблон ActiveRecord.
Это и есть объединение слоя бизнес-логики и слоя работы с БД. Применяется такой шаблон преимущественно в целях RAD.
Doctrine же реализует шаблон DataMapper, UnitOfWork и многое другое, что очень полезно для Domain Driven Development. Но, думаю, Вы согласитесь что для проектов малого и среднего уровня это просто из пушки по воробьям.
2) Я сталкивался с некоторыми проблемами в Blade (в Laravel 4), связанными в основном с наследованием и подключением файлов. Но в целом он достаточно удобен.
Цель — сделать синтаксис шаблонов более читаемым по сравнению со стандартным PHP (по-сути синтаксический сахар).
Кроме того, в Blade вы можете сразу вызывать любой PHP код используя тот же самый синтаксис, в отличие от Twig, который заставляет добавлять собственные функции/конструкции, если требуется что-то новое.
Причина такого подхода, опять же, указана в первом пункте (RAD).
3) То что Laravel базируется на некоторых компонентах Symfony, говорит лишь о том, что эти компоненты написаны хорошо и грех их не использовать, для того чтобы написать более простую и удобную обертку.
4) Фасады в Laravel — точно такой же синтаксический сахар для разработчика, как и шаблонизатор Blade. Исторически в PHP разработчики привыкли использовать статические классы, потому что этот подход был реализован во многих фреймворках, но используя этот подход приложение тяжело тестировать.
Таким образом, фасады — это просто "палочка выручалочка", когда хочется статических классов и при этом нужно писать тесты. Количество кода при использовании таких фасадов немного сокращается.
Кроме того, никто не заставляет использовать фасады — все можно решить через контейнер сервисов. Например в Lumen фасады по-умолчанию отключены.
В заключении можно сказать что Laravel — это developer-centric фреймворк (именно так) в котором огромное внимание уделяется красоте и лаконичности кода, удобству использования, а также скорости написания приложений.
Поэтому, ИМХО, Laravel'у быть, и никакой это не "хайп", в отличие, например, от Angular 1, который Google поматросил и бросил.
Собственно, даже само описание фреймворка очень емко и лаконично описывает его суть:
Поэтому рекомендую Вам поближе ознакомиться с этими принципами и использовать их по назначению.
Подтверждаю. Для того чтобы сделать нормально, потребуется как минимум подключать дизассемблер длин инструкций, чтобы не сломать оригинальную логику своими JMP.
Конечно большинство функций из Windows библиотек имеют в своем теле некий stub, как раз для таких вещей, но все же остается ненулевая вероятность "порвать" опкоды оригинальной функции.
Ну и неплохо было бы упомянуть про Microsoft Detours, раз уж диалог идет об inline hooking'е.
Согласен =D
К сожалению с бумажным вариантом комбинации Ctrl+F и Ctrl+C / Ctrl+V не работают :)
Интересно как много человек участвовало в этом процессе. Production-ready приложение быстрее чем за два месяца — звучит вызывающе.
Самое главное забыли написать про Vue — их подход к компонентам.
Вы можете создавать и поставлять отдельные компоненты с расширением *.vue (подмножество XML). Внутри этого файла могут лежать шаблоны, скрипты и стили.
Кроме того, если не хочется все складывать в один
*.vueфайл, компонент можно разнести отдельно на .css, .js, а в *.vue просто подключить эти файлы через атрибутsrc:Все это потом прекрасно собирается либо browserify (через vueify), либо webpack.
Получается такой себе Яндекс БЭМ из коробки, плюс разделение скриптов и шаблонов.
Я имею в виду слой бизнес-логики, реализующий предметную область, а также отвечающий за персистентность, например как Model в Backbone — описал модель, накидал туда логики (например валидация) и вызвал model->save().
Если, например, нужно смоделировать связи между объектами и т.д.
Какой у AngularJS стандартный способ решения таких задач?