Если я правильно понял, то вы видите негативные последствия от использования TailwindCSS в долгоживущих проектах с большой дизайн-системой. Но я не понял, как использование TailwindCSS приводит к этим негативным последствиям и какие это последствия.
TailwindCSS - это фреймворк для CSS, который разбивает приложение на слои, заполняет слои base и utilities базовыми классами, а потом позволяет упаковывать utility классы при сборке. Упаковка утилит - это killer feature этого фреймворка: авто-подстановка размеров экрана (`sm`, `md` и т.д.), переменных (`grid-cols-[5]`, `px-[2rem]` и т.д.). Я не представляю себе вёрстку, особенно связанную с блоками (колонки, отступы, выравнивание) без TailwindCSS. Каждый раз, как я работаю над старыми проектами без TailwindCSS, где для каждого чиха нужно прописывать свой класс - я банально мучаюсь.
Тот пример, который вы рассматривали в статье - это создание компонента. Но ведь это не имеет отношение к TailwindCSS. Вы сами решаете, как вы будете выстраивать код внутри компонентов, и какой у этого компонента будет интерфейс.
Я сейчас работаю над небольшим проектом, в котором делаю дизайн систему для программ на Vue.js в стилистике первых Macintosh. Я использую в нём TailwindCSS. Но когда я пишу компонент, большая часть CSS, не связанная с позиционированием, у меня находится в обычных `<style scoped>`. И это не мешает мне использовать сброс стилей из коробки, создавать утилиты и класть их в подготовленный слой, использовать генерацию классов для позиционирования.
В общем и целом TailwindCSS значительно облегчает жизнь. И почему его использование должно приводить к негармоничной дизайн-системе - мне не понятно. Потому что он этому никак не мешает
Этот пример подтверждает мою теорию о моделях в интерфейсах. Я пытался понять, какой минимальный набор моделей (элементов) достаточен, чтобы создать интерфейс любой сложности. И пришёл к выводу, что чек-бокс как модель не является необходимой.
Если мы даём пользователю сделать выбор, то его можно отобразить как select "1-из-многих" или "много-из-многих". Как следствие в коде и БД вместо Boolean будет Enum. Так мы не только сокращаем количество моделей (уйдут чекбоксы, радио-кнопки, переключатели), но и позволим себе расширять список вариантов, когда это потребуется
Отказаться от контроля качества? Не имеет ценности для общества? Это вообще не то, о чём я говорил! Контроль качества необходим и это не обсуждается.
Но как проходит этот контроль сейчас? Лично я не удовлетворён качеством ПО, которым я пользуюсь. И то, что я хочу - это внести качество внутрь языка. Чтобы проверка качества была не "по желанию", а чтобы на языке было сложно случайно написать баг.
Цель не в том, чтобы не писать тесты. А чтобы создать язык, в котором контроль качества был бы обязательным, а сам язык упрощал создание качественной системы. Если сейчас качество проверяется только автоматическими и ручными тестами, то их можно пропустить. Если проверка качества вшита в язык, то она и обязательна и делается легче. Вот о чём я думаю
Суть вопроса в том, сможем ли мы создать язык, отличающийся от существующих, который позволит нам полностью сосредоточиться на ценности для общества: "Решать задачи пользователей через развитие цифровых систем", вместо того, чтобы тратить время на архитектуру, тесты, рефакторинг и подобные "побочные квесты"
Вот как будто да, тоже думаю в эту сторону. Нужно что-то, что позволит декларативно описывать правила, по которым программа сама будет "придумывать" последовательность выполняемых действий. Как SQL и СУБД
Как опытный лектор я могу с уверенностью сказать - никогда не начинайте занятие с названия темы. Худший способ начать лекцию - это сказать "Сегодняшняя тема урока N. N - это..."
Я советую начинать с "обоснования необходимости". Дать ответы на вопросы "Что" мы сейчас будем делать и "Зачем". Такое начало мотивирует студентов проявлять интерес к материалу и углубляет доверие к теме лекции.
Именно поэтому я бы начал с акторной модели. Сначала показал бы распределённые системы. Потом задался вопросом "Как лучше всего с ними работать". Это бы привело нас к акторной модели. И когда естественным станет вопрос "Как реализовать акторную модель на практике", только тогда на сцену вышло бы ООП
"Статья о том, как мы (инженеры) забыли, почему популярные идеи стали популярными, почему они работали изначально, как мы потеряли их суть и что с этим делать"
Предлагаю такое название. Будет как тайтл любого аниме 2025 года XD
Как вы считаете, можно ли... в объектной парадигме смоделировать функциональную?
Первое, что приходит в голову - это "Элегантные объекты " Егора Бугаенко. Так что да, можно, и не дай бог так делать XD. Чисто технически это возможно, но очень не удобно.
Почему мы вынуждены идти на компромисс...?
Потому что мы ещё не нашли истинное предположение, от которого логически выводятся все парадигмы. Я приверженец идеи, что "Реальность проста и непротиворечива". Это значит, что если очень хорошо подумать, то в основании любых причина-следственных связей будет лежать ТОЛЬКО ОДНО предположение / факт. Если мы меряем высоту здания 2-мя разными способами и получаем 2 разных ответа, мы ведь не идём на компромисс и не говорим "Вы оба правы, давайте не будем ссориться, скажем, что высота здания - это среднее между вашими ответами". Мы знаем, что высота здания - это конкретное число. Так же и с логикой.
Ну и вопрос "Существует ли единая парадигма", конечно, фундаментален. Ответ на этот вопрос я не знаю. Предполагаю, что для этого, как вы и написали, сначала необходимо ответить на вопрос "Как мыслит человек". Если у нас будет единый и полный ответ на этот вопрос, тогда и с парадигмой разберёмся.
А пока что у нас есть 3 парадигмы, которыми приходится жонглировать для выполнения реальных задач. А по вечерам, после работы, надевать халат учёного и выводить единую парадигму. У меня есть мысли на счёт парадигм и DSL, но это выходит за рамки текущего обсуждения
Парадигма - это "очки", через которые мы смотрим на какую-либо систему. Некоторые очки нам нужны, чтобы корректировать зрение. Другие - чтобы защититься от солнца. Поэтому они и "инструменты".
В идеальном мире всё пишется на DSL. Но в реальности мы вынуждены идти на компромисс. С одной стороны у нас несколько парадигм, которые мы применяем в разных частях приложения. Да, их 3 штуки, и это по определению сложно. С другой стороны мы можем выбрать одну парадигму, но тогда некоторые части приложения будут невыразительными.
Пока этот компромисс не будет решён - мы будем занимать какую-то сторону (1 парадигма vs 3 парадигмы). И я и вы правы, потому что мы оба указываем на 2 необходимых условия: выразительность и простота. Когда IT-индустрия дорастёт до DSL - оба этих условия будут соблюдены и все будут довольны
Мы с вами смотрим на это в разных временных промежутках.
Вы применяете это утверждение к каждому конкретному человеку. То есть, если человек родился с отклонениями - то это противоречит тому, что "природа не создаёт ненужных людей".
Я смотрю на это с точки зрения всей эволюции человечества, сглаживая выборку. То есть, если много людей обладают одной и той же особенностью мышления / поведения / нервной системой, и эта черта всё ещё существует, значит она прошла отбор и, по каким то причинам, для человечества полезна.
Это мысль из разряда "Не оценивайте рыбу, по её способности лазать по деревьям"
1) Хотел назвать "Идеи потерявшие суть", но не звучало. В ретроспективе понимаю что да, следовало бы назвать по другому
2) Не приписывайте мне слов, которых я не писал. Я не имею мнения относительно Scrum-мастеров, гарантий эффективности и "деятельности по методичке". Я лишь показываю причина-следственную связь: если вы выкидываете или изменяете в методологии места, которые являются её основой (оставляя всё остальное без изменений) - то она 100% не будет работать
3) В моём утверждении не было модальности (все; большинство; меньше половины и т.п."
На самом деле я всё это сейчас пишу, а оно ведь не важно. Вас же волнует, почему статья с "заезженными" и "дилетантскими" (по вашему мнению) мыслями набрала много плюсов. Кажется у меня есть предположение. Проблемы с управлением проектами и подходами к разработке настолько огромные и повсеместные, что сообщество положительно реагирует на любые статьи, посты и мысли, которые пытаются что-то исправить. И будут так реагировать, пока ситуация не улучшится
На счёт интеллекта вы правы, и его требует любая деятельность XD. Но моё мнение: главная проблема с Agile не в гибкости / свободе реализации.
Agile СЛОЖНЫЙ. Его манифест состоит из 4 компромиссов и 12 принципов. Это выходит за любые пределы когнитивной нагрузки. Не говоря уже о том, что строить всю модель на компромиссах - это самоубийство. Что мы и видим на практике: Agile закономерно превратился в "Fragile"
Agile нужно упрощать, если мы хотим изменить ситуацию
Прекрасно в этом то, что программисты могут использовать и используют подходящие инструменты для своих задач. Не нужно пытаться скрывать данные в объектах, когда они нужны в UseCase'е - используйте FP. Не надо разделять сервис на 10 функций и замыкать в каждой из них аутентификационные данные для этого сервиса - используйте OOP
Я вас понимаю. Сам люблю творческий подход к своей деятельности. Что-нибудь изучить, усомниться в предположениях авторов, создать новую модель, поэкспериментировать.
Природа не создаёт ненужных людей. Я уверен: при должной рефлексии, вы, с владельцами компании, смогли бы найти деятельность, которая была бы как полезна для компании, так и удовлетворительна для вас.
Агрессивное упорядочивание всего вокруг (предсказуемость, ответственность) - это иногда нужная вещь. Но в такой среде не будет места творчеству и экспериментам. А без них компания не сможет развиваться и проиграет в конкурентной борьбе. Это большая тема, но я бы копал в том направлении.
Мы все разные и все в чём то хороши и полезны. Я бы не сдавался так просто
И тут я должен посмотреть хитрым взглядов и сказать, что оно и не растёт. Потом указать на то, что в определении Алана Кея нет ни слова про наследование...
Но вы же понимаете, какой холивар из этого начнётся?
Забавно, потому что я тоже об этом думал. И эта ситуация лишь подтверждает, что упрощение рождает лучшие идеи.
Математики не принимали 5, потому что 5 - это много. И они приложили огромное кол-во усилий, чтобы сократить 5 до 4. А когда им это удалось - миру открылись 2 новых типа геометрии.
Если бы не желание учёных всё упрощать и уменьшать кол-во элементов, то может они и не открыли бы эти 2 новые геометрии
А вот тут прям по больному (дальше будет негодование). У меня горит, как сообщество ФП считает себя элитарным кружком и любой рассказ об ФП начинает с математики и теории категорий. А, и ещё нужно не забыть вначале 10 минут порассказывать, какой ООП плохой и неправильный.
Единственная книга по ФП, которая нормально объяснила мне, что такое ФП и в чём его преимущества - эта так, которую я упомянул в статье.
ФП'шники сами виноваты, что их инструмент не получает должного развития
Да, достигается, но не выводится. Иначе мы могли бы взять только что-то одно (например "Инкапсуляцию") и не упоминать всё остальное, потому что всё остальное было бы неизбежным следствием. Но мы так сделать не можем, потому что "наследование" никак не является неизбежным следствием "инкапсуляции".
Если в основе любой системы не лежит 1-2 принципа, из которых выводится всё остальное, то такая система сложна. И если подумать подольше, то её можно упростить. Это не легко, но так рождаются лучшие идеи
Если я правильно понял, то вы видите негативные последствия от использования TailwindCSS в долгоживущих проектах с большой дизайн-системой. Но я не понял, как использование TailwindCSS приводит к этим негативным последствиям и какие это последствия.
TailwindCSS - это фреймворк для CSS, который разбивает приложение на слои, заполняет слои base и utilities базовыми классами, а потом позволяет упаковывать utility классы при сборке. Упаковка утилит - это killer feature этого фреймворка: авто-подстановка размеров экрана (`sm`, `md` и т.д.), переменных (`grid-cols-[5]`, `px-[2rem]` и т.д.). Я не представляю себе вёрстку, особенно связанную с блоками (колонки, отступы, выравнивание) без TailwindCSS. Каждый раз, как я работаю над старыми проектами без TailwindCSS, где для каждого чиха нужно прописывать свой класс - я банально мучаюсь.
Тот пример, который вы рассматривали в статье - это создание компонента. Но ведь это не имеет отношение к TailwindCSS. Вы сами решаете, как вы будете выстраивать код внутри компонентов, и какой у этого компонента будет интерфейс.
Я сейчас работаю над небольшим проектом, в котором делаю дизайн систему для программ на Vue.js в стилистике первых Macintosh. Я использую в нём TailwindCSS. Но когда я пишу компонент, большая часть CSS, не связанная с позиционированием, у меня находится в обычных `<style scoped>`. И это не мешает мне использовать сброс стилей из коробки, создавать утилиты и класть их в подготовленный слой, использовать генерацию классов для позиционирования.
В общем и целом TailwindCSS значительно облегчает жизнь. И почему его использование должно приводить к негармоничной дизайн-системе - мне не понятно. Потому что он этому никак не мешает
Этот пример подтверждает мою теорию о моделях в интерфейсах. Я пытался понять, какой минимальный набор моделей (элементов) достаточен, чтобы создать интерфейс любой сложности. И пришёл к выводу, что чек-бокс как модель не является необходимой.
Если мы даём пользователю сделать выбор, то его можно отобразить как select "1-из-многих" или "много-из-многих". Как следствие в коде и БД вместо Boolean будет Enum. Так мы не только сокращаем количество моделей (уйдут чекбоксы, радио-кнопки, переключатели), но и позволим себе расширять список вариантов, когда это потребуется
Отказаться от контроля качества? Не имеет ценности для общества? Это вообще не то, о чём я говорил! Контроль качества необходим и это не обсуждается.
Но как проходит этот контроль сейчас? Лично я не удовлетворён качеством ПО, которым я пользуюсь. И то, что я хочу - это внести качество внутрь языка. Чтобы проверка качества была не "по желанию", а чтобы на языке было сложно случайно написать баг.
Цель не в том, чтобы не писать тесты. А чтобы создать язык, в котором контроль качества был бы обязательным, а сам язык упрощал создание качественной системы. Если сейчас качество проверяется только автоматическими и ручными тестами, то их можно пропустить. Если проверка качества вшита в язык, то она и обязательна и делается легче. Вот о чём я думаю
Суть вопроса в том, сможем ли мы создать язык, отличающийся от существующих, который позволит нам полностью сосредоточиться на ценности для общества: "Решать задачи пользователей через развитие цифровых систем", вместо того, чтобы тратить время на архитектуру, тесты, рефакторинг и подобные "побочные квесты"
Вот как будто да, тоже думаю в эту сторону. Нужно что-то, что позволит декларативно описывать правила, по которым программа сама будет "придумывать" последовательность выполняемых действий. Как SQL и СУБД
Как опытный лектор я могу с уверенностью сказать - никогда не начинайте занятие с названия темы. Худший способ начать лекцию - это сказать "Сегодняшняя тема урока N. N - это..."
Я советую начинать с "обоснования необходимости". Дать ответы на вопросы "Что" мы сейчас будем делать и "Зачем". Такое начало мотивирует студентов проявлять интерес к материалу и углубляет доверие к теме лекции.
Именно поэтому я бы начал с акторной модели. Сначала показал бы распределённые системы. Потом задался вопросом "Как лучше всего с ними работать". Это бы привело нас к акторной модели. И когда естественным станет вопрос "Как реализовать акторную модель на практике", только тогда на сцену вышло бы ООП
Предлагаю такое название. Будет как тайтл любого аниме 2025 года XD
Первое, что приходит в голову - это "Элегантные объекты " Егора Бугаенко. Так что да, можно, и не дай бог так делать XD. Чисто технически это возможно, но очень не удобно.
Потому что мы ещё не нашли истинное предположение, от которого логически выводятся все парадигмы. Я приверженец идеи, что "Реальность проста и непротиворечива". Это значит, что если очень хорошо подумать, то в основании любых причина-следственных связей будет лежать ТОЛЬКО ОДНО предположение / факт. Если мы меряем высоту здания 2-мя разными способами и получаем 2 разных ответа, мы ведь не идём на компромисс и не говорим "Вы оба правы, давайте не будем ссориться, скажем, что высота здания - это среднее между вашими ответами". Мы знаем, что высота здания - это конкретное число. Так же и с логикой.
Ну и вопрос "Существует ли единая парадигма", конечно, фундаментален. Ответ на этот вопрос я не знаю. Предполагаю, что для этого, как вы и написали, сначала необходимо ответить на вопрос "Как мыслит человек". Если у нас будет единый и полный ответ на этот вопрос, тогда и с парадигмой разберёмся.
А пока что у нас есть 3 парадигмы, которыми приходится жонглировать для выполнения реальных задач. А по вечерам, после работы, надевать халат учёного и выводить единую парадигму. У меня есть мысли на счёт парадигм и DSL, но это выходит за рамки текущего обсуждения
Я согласен с вашей позицией. Если и вы согласны с моей, то мы оба правы. В таком случае да, спорить не о чем
Парадигма - это "очки", через которые мы смотрим на какую-либо систему. Некоторые очки нам нужны, чтобы корректировать зрение. Другие - чтобы защититься от солнца. Поэтому они и "инструменты".
В идеальном мире всё пишется на DSL. Но в реальности мы вынуждены идти на компромисс. С одной стороны у нас несколько парадигм, которые мы применяем в разных частях приложения. Да, их 3 штуки, и это по определению сложно. С другой стороны мы можем выбрать одну парадигму, но тогда некоторые части приложения будут невыразительными.
Пока этот компромисс не будет решён - мы будем занимать какую-то сторону (1 парадигма vs 3 парадигмы). И я и вы правы, потому что мы оба указываем на 2 необходимых условия: выразительность и простота. Когда IT-индустрия дорастёт до DSL - оба этих условия будут соблюдены и все будут довольны
Мы с вами смотрим на это в разных временных промежутках.
Вы применяете это утверждение к каждому конкретному человеку. То есть, если человек родился с отклонениями - то это противоречит тому, что "природа не создаёт ненужных людей".
Я смотрю на это с точки зрения всей эволюции человечества, сглаживая выборку. То есть, если много людей обладают одной и той же особенностью мышления / поведения / нервной системой, и эта черта всё ещё существует, значит она прошла отбор и, по каким то причинам, для человечества полезна.
Это мысль из разряда "Не оценивайте рыбу, по её способности лазать по деревьям"
1) Хотел назвать "Идеи потерявшие суть", но не звучало. В ретроспективе понимаю что да, следовало бы назвать по другому
2) Не приписывайте мне слов, которых я не писал. Я не имею мнения относительно Scrum-мастеров, гарантий эффективности и "деятельности по методичке". Я лишь показываю причина-следственную связь: если вы выкидываете или изменяете в методологии места, которые являются её основой (оставляя всё остальное без изменений) - то она 100% не будет работать
3) В моём утверждении не было модальности (все; большинство; меньше половины и т.п."
На самом деле я всё это сейчас пишу, а оно ведь не важно. Вас же волнует, почему статья с "заезженными" и "дилетантскими" (по вашему мнению) мыслями набрала много плюсов. Кажется у меня есть предположение. Проблемы с управлением проектами и подходами к разработке настолько огромные и повсеместные, что сообщество положительно реагирует на любые статьи, посты и мысли, которые пытаются что-то исправить. И будут так реагировать, пока ситуация не улучшится
На счёт интеллекта вы правы, и его требует любая деятельность XD. Но моё мнение: главная проблема с Agile не в гибкости / свободе реализации.
Agile СЛОЖНЫЙ. Его манифест состоит из 4 компромиссов и 12 принципов. Это выходит за любые пределы когнитивной нагрузки. Не говоря уже о том, что строить всю модель на компромиссах - это самоубийство. Что мы и видим на практике: Agile закономерно превратился в "Fragile"
Agile нужно упрощать, если мы хотим изменить ситуацию
Прекрасно в этом то, что программисты могут использовать и используют подходящие инструменты для своих задач. Не нужно пытаться скрывать данные в объектах, когда они нужны в UseCase'е - используйте FP. Не надо разделять сервис на 10 функций и замыкать в каждой из них аутентификационные данные для этого сервиса - используйте OOP
Я вас понимаю. Сам люблю творческий подход к своей деятельности. Что-нибудь изучить, усомниться в предположениях авторов, создать новую модель, поэкспериментировать.
Природа не создаёт ненужных людей. Я уверен: при должной рефлексии, вы, с владельцами компании, смогли бы найти деятельность, которая была бы как полезна для компании, так и удовлетворительна для вас.
Агрессивное упорядочивание всего вокруг (предсказуемость, ответственность) - это иногда нужная вещь. Но в такой среде не будет места творчеству и экспериментам. А без них компания не сможет развиваться и проиграет в конкурентной борьбе. Это большая тема, но я бы копал в том направлении.
Мы все разные и все в чём то хороши и полезны. Я бы не сдавался так просто
И тут я должен посмотреть хитрым взглядов и сказать, что оно и не растёт. Потом указать на то, что в определении Алана Кея нет ни слова про наследование...
Но вы же понимаете, какой холивар из этого начнётся?
Забавно, потому что я тоже об этом думал. И эта ситуация лишь подтверждает, что упрощение рождает лучшие идеи.
Математики не принимали 5, потому что 5 - это много. И они приложили огромное кол-во усилий, чтобы сократить 5 до 4. А когда им это удалось - миру открылись 2 новых типа геометрии.
Если бы не желание учёных всё упрощать и уменьшать кол-во элементов, то может они и не открыли бы эти 2 новые геометрии
А вот тут прям по больному (дальше будет негодование). У меня горит, как сообщество ФП считает себя элитарным кружком и любой рассказ об ФП начинает с математики и теории категорий. А, и ещё нужно не забыть вначале 10 минут порассказывать, какой ООП плохой и неправильный.
Единственная книга по ФП, которая нормально объяснила мне, что такое ФП и в чём его преимущества - эта так, которую я упомянул в статье.
ФП'шники сами виноваты, что их инструмент не получает должного развития
Я специально не стал упоминать акторную модель, потому что она была разработана позже. Не хотел скакать между временными промежутками.
Сейчас, если бы я учил кого-то парадигмам программирования, и мне нужно было объяснять ООП с нуля, то я начинал бы рассказ именно с акторной модели.
Да, достигается, но не выводится. Иначе мы могли бы взять только что-то одно (например "Инкапсуляцию") и не упоминать всё остальное, потому что всё остальное было бы неизбежным следствием. Но мы так сделать не можем, потому что "наследование" никак не является неизбежным следствием "инкапсуляции".
Если в основе любой системы не лежит 1-2 принципа, из которых выводится всё остальное, то такая система сложна. И если подумать подольше, то её можно упростить. Это не легко, но так рождаются лучшие идеи