О различных направлениях в разработке и в частности о web

Для кого как, а для меня было интересно послушать мнение Software Engineer - Soer о нынешнем состоянии web-разработки и других направления разработки Почему я считаю, что веб это просто

3 лайка

Предпосылки верны, выводы - неоднозначны.

Что верно. Клиент действительно прост если смотреть на него как набор css, html, js. Сложности появляются когда требования к клиенту выходит за рамки “лендинг пейдж с галереей”. Для решения новых задач недостаточно примитивов, предоставляемые браузерами. И тогда начинает расти сложность, не связанная с предметной областью, а связанная с организацией кода и координации действий программы (например в realtime приложениях).

Верно что порождается большое количество инструментов и что фиг их все выучишь. С другой стороны и не надо знать их все. Как он верно говорит - так как эти инструменты решают общие проблемы, то, разобравшись с парой инструментов, со следующими разбираться проще. И нет единого инструмента ибо никто до сих пор не выяснил как делать интерфейсы. Если задачи (которые он противопоставляет вебу) обучения нейронных сетей, криптография имеют общие подходы и сложны с точки зрения предметной области (знание математики и понимание формул), то с точки зрения применения формул это простые, легко выражаемые в виде кода задачи.

В случае с криптографией и нейронными сетями сложность в изучении начального набора знаний и теории, которая хорошо проработана, в отличии от интерфейсов. Так как порождается строгими науками, которые проще выразить в виде кода. При этом применение намного проще.

Место где он неточен - это в подходе к сравнени. Он сравнивает сложность знаний, которые нужны чтобы начать решать задачи в фронте и сравниваемых отраслях, оставляя организационную сложность за рамками сравнения (хоть и упоминает ее).

Демонстрация такого же подхода к аргументации как у него: я утверждаю что криптография намного проще интерфейсов, ибо, разобравшись в формулах остается переложить их 1 в 1 в код. А для распределенных вычислений есть набор известных устоявшихся решений, сложность работы с которыми сводится к настройке и дерганию API.

Это не ложное но и не до конца верное утверждение. Таким же я считаю мнение автора.

3 лайка

Как я понял, он в различных направлениях рабо (тает / тал): и с data science, R-lang, Angular…
Поэтому не исключено, что front-end он мог копнуть немного (немного проектов), и выводы соответсвующие.

Он ответил на
Клиент действительно прост если смотреть на него как набор css, html, js. Сложности появляются когда требования к клиенту выходит за рамки “лендинг пейдж с галереей”. Для решения новых задач недостаточно примитивов, предоставляемые браузерами. И тогда начинает расти сложность, не связанная с предметной областью, а связанная с организацией кода и координации действий программы (например в realtime приложениях).

  1. Сложность скорее возникает в момент, когда мы хотим делать приложение модульным (состоящим из набора компонентов), с возможностью межкомпонентного взаимодействия. При этом трудозатраты на добавление нового компонента должны быть небольшими. Т.е. такое приложение, которое макисмально открыто к расширению и изменению.
  2. Инструмент должен соответствовать цели. Сегодня очень часто это не так, отсюда и много лишней “боли”.
  3. Во многом принципы разработки десктопных приложений и SPA совпадают, поэтому говорить об организационной сложности именно веба не очень правильно, так как эта сложность присуща самому процессу разработки ПО независимо от платформы.
  4. В вебе действительно есть проекты, которые в организационной и арихитектурной части очень сложны, но таких проектов мало.

… Если же все таки хотели сравнить изучение и использование мат. аппарата, то использование, естественно, проще чем изучение.

Полностью согласен.

Утверждение верное. Вопрос - как так получается и что делать.

Главный вопрос - может ли концептуально быть иначе - можно ли создать такой инструмент, который будет соответствовать цели. Если этого невозможно концептуально, то это ограничение следует принять как фактор самой разработки.

В целом ребята стараются сделать инструмент, соотвтствудющий цели. Потом они выпускают его на рынок и оказывается что то, что им казалось хорошим решением проблемы, совсем не подходит под похожую проблему или проблему в масштабе. Получается инструмент не соответствующий некоторым целям, и другие ребята выпускают другое решение, которое вроде подходит под их цели, но цикл повторяется снова. Количество боли зависит чисто от удачи на какой инструмент попасть сегодня и сейчас и на его фактическое соответствие текущей задаче.

Я выбрал для себя путь расслабиться и наблюдать как проплывают трупы фреймверков и концепций. И концентрироваться на концептуальных знаниях, которые переносимы между областями и фреймверками.

Отличия есть и они определяют как сложность веба так и его преимущество.

Строительные блоки веба примитивны в отличие от десктопа где библиотеки компонент с готовыми паттернами предоставляются системой в рамках которой создается десктопное приложение. Примитивность позволяет создавать кроссплатформенные интерфейсы. И она же мешает созданию сложных интерфейсов, порождая волны фреймверков (про это будет ниже). Примитивность еще позволяет поддерживать обратную совместимость и невозможность обновить все клиенты одновременно.

Плюс веб по определению разлелен на минимум 2 программы с необходимостью координации состояния между обеими - если речь о минимально нетривиальном интерфейсе. Это коцептуально сложнее чем синхронизация между потоками (ибо отсутствет внешний супервайзер выполнения). Если на десктопе можно все данные закинуть в память, фигачить код в 1 потоке, то в вебе никак не избавиться от необходимости асинхронной координации.

Оба утверджения верны. Выходит различие между вебом и невебом - требование к математической подготовке.

Автор ролика определял сложность направлений через требования к знанию некоторого аппарата (математического аппарата или принципам из computer science). Мой тезис в том что сравниваемый фактор - обязательное но недостаточное условие для создания продукта как в вебе как и в сравниваемых отраслях. Поэтому и мнение о том что веб это просто остается мнением, сфокусированным на зауженной части картины создания ПО.

В целом рекомендую парня слушать. Он говорит дельные вещи. Но для полноты картины обращать внимание и на альтернативную аргументацию.

1 лайк

Я предполагаю, что эта тактика взращивания в умах публики идеи “золотого data science в сравнении со шлаковым web”, которая наблюдается во многих видеороликах, может иметь цель группирования аудитории для открытия платного обучающего ресурса по data science.

Навряд это осмысленные шаги. Исходя из моего представления о человеческой природе - это попытка выглядить хорошо в своих глазах. “Всяк кулик свое болото хвалит”.

Кстати ровно то же можно сказать о моем ответе. Поэтому важно обсуждать конкретные аспекты, на которые опирается мнение, а не только само мнение. Тогда можно и лучше узнать реальность (из описания аспектов) а говорящий получит шанс улучшить свою модель мира когда основания его выводов будут оспорены.

Человек объяснил тем, что он долго работал с web и ему он надоел, стал тесен, а в data science похоже, что он себя нашел.