Справедливость — это субъективная оценка соответствия наблюдаемых результатов взаимодействий ожиданиям субъекта, где ожидания формируются реальной практикой (не декларациями), и где наблюдение включает как собственный опыт, так и опыт других в рамках известной субъекту системы.
Давайте проверим: несправедливо, когда одни рождаются с золотой ложкой во рту, а другие вынуждены работать с самого детсва. Подходит под ваше определение?
Например, Core Ultra 9 285K использует тайловую компоновку: вычислительный блок производится на TSMC N3B, GPU — на N5P, а блоки SoC и IO — на N6. Зачем такая мозаика?
SoC ? Я бы предположил, что NoC - но было бы странное делать ядро системы не на ведущем техпроцессе.
Самообразование в больших количествах (все слова важны) - это социально одобряемая лень.
Можете провести эксперимент на себе: 1. Прочитать про какую-нибудь фундаментальную, относительно далёкую от вас технологию прям учебник или фундаментальную книгу. 2. Заняться на практике этой технологией. Вы будете удивлены насколько "самообразование" отличается от реальной деятельности.
Ну и в целом плачевные последствия "самообразования в больших количествах" - можно увидеть у разных блоггеров формата "обо всём и ни о чём умными словами". Особенно когда они про твою область начинают.
Потому, для чего существуют устоявшиеся термины: что само-придуманные названия будут хуже гуглится, чем устоявшиеся (после того, как человек прочитав статью начнёт что-то ещё и искать).
Но вообще я так со стороны проходил посмотреть, фронтэндом не знанимаюсь.
8*200 = 1600 (часов 1-на-1 с квалифицированным преподавателем).
Это +/- бьётся с цифрами, CEFR для изучения английского на С2 (исходя из ряда разумных предположений типа изучение пары языков в любом направлении одинаково трудоёмко, ....).
У меня ровно наоборот. Правильно заговорить не мог пока не начал правильно слышать все английские гласные (включая дифтонги). До тех пор - просто не мог-таки понять что от меня нужно.
Параллельно с пассивным слушанием (подкасты \ фэнтезятина в метро на\с работы) - послушал разбор английской фонетики на phonetic fanatic - рекомендую всем изучающим. Понял что надо слышать (как ловить обратную связь) от постановки звуков по IPA.
Бегло пробежался, но не нашёл ответа на главный вопрос - для которого "архитектура как код" лично мне могло бы быть полезно - предусмотрены ли разные представления для "подробной" и "общей" схемы подсистемы?
Поясню что именно по моему мнению необходимо: Есть подсистема XXX. В ней есть 2 представления (за них отвечает 1 человек): XXX.API, XXX,implementation
XXX.implementatiln - собственно описание подсистемы XXX.API - как будет выглядеть (как по сути встраивается в виде кода) подсистема XXX на всех диаграммах где она используется. А дальше уже всё как вы описали: при изменении XXX.API - прогоняется CI/CD: меняются все диаграммы включающие XXX, делается проверка правил (подключения).....
Очень странное ощущение. Успешные проекты которые я видел (я правда в системном программировании) - это забег на порядка 3 лет на максимально возможной скорости крайне профессиональной команды.
Что можно сделать "по вечерам, нерегулярно, без бюджета и привлечения сильной команды" (с шансом выше, чем выиграть в лотерею) - даже близко не представляю.
Сколько из 400+ млн репозиториев на github начали приносить деньги через год после создания на отметке 30KLoC?
А лексера в nom (и rust-peg) никакого специально не выделяется, поиск идёт по диапазону байтов, в отличие от CFG парсера (lalrpop), где лексер выдаёт более крупные токены.
Да это же библиотека парсинга общего назначения, а не парсинга языков программирования. Т.е сами выделяете два слоя:
Про деньги - все правильно. Даже если вы работаете в "продуктовой" компании (я так понимаю, имеется в виду софтверный продукт), ваш продукт покупают компании, которые или сами что-то производят, или дальше продают свой продукт кому-то, кто производит. Софт в вакууме не имеет никакой ценности. В итоге все равно все сводится или к производству, или к экономии времени. Все остальное - ложь. :)
Вот конкретно по этому возражение. Есть фирма - с которой у работника отношение. И для большинства работников, тем более линейных "боль и вознаграждение" работника заканчиваются внутри фирмы. Продаёт фирма продукт твоей деятельности - одно отношение. Продаёт фирма продукт, а ты одно из десятков саппорт подразделений - другое.
Это как на годовом собрании: мы за этот год заработали $Х-llions, продавая Y-офис, спасибо нашим программистам они добавили Z-новых фич. Ну и тем, кто столы носил туалеты мыл и теплом офис обеспечивал тоже спасибо.
На просьбы бюджеты и запросы тех, кто Y-офис пишет - реагируют НАМНОГО быстрее чем тех, кто столы носит.
Качественно - то же. Деньги вам приносит не IT, а продукт, который поддерживается в том числе благодаря IT. Количественно - разница да большая.
Но если "вдруг" решения какого-нибудь условно 2031года станет на 100% хватать для бизнеса - они без промедлений уволят весь департамент разработки, оставив только поддержку (я допускаю ситуацию, когда IT в целом прогрессирует, но для целей маркетплейса прогресс дальше технологий года Х(=2031 в нашем примере) прогресс избыточен).
В отличии от компаний представляющих непосредственно IT (хоть продукт хоть услугу). При любом хорошем отношении и "кофемашине смузи и релакс-комнате с Х5" - ты приносишь деньги \ ты тратишь деньги для поддержки основного продукта ощущается.
Спасибо за ответ. Будет интересно почитать другие статьи - именно в упор на другие модели механики \ оптимизации существующих (насколько я понимаю перед этим надо задать ограничения).
> А нужно single float? C меня коньяк если найдёте где я это предлагал ;) Я как раз скорее про увеличение точности в вычислениях (принимая решение в зависимости от аппаратной поддержки).
> со слабыми ключевыми словами? Тут вроде боле-менее стандартно: - в пределах того же уровня (лексер \ парсер ) - откат при обнаруженной ошибке делается из коробки (*) сколько угодно раз - формально это экспонента, на практике при любом разумном коде никакой экспоненты и близко нет. - в пределах разных уровней - вроде из коробки в nom этого нет - придётся учить (делать дополнительные обёртки, которые умеют пробрасывать в лексер ошибки парсера)
*) для этого лексер должен выдавать вам "имя", а уже парсер представлять это (разрешая до семантического анализа все непределённости) как "keyword(string) | ident(string)"
Интересна содержательная часть работы, а особенно постановка задачи: что представляют собой физические движки, какие типы бывают (вы же наверняка один из существующих типов реализовали - но почему выбрали этот тип). К чему ведёт выбор того или иного типа движка: "мощность" (что может \ не может симулировать) vs сложность реализации. Наличие специфических (кажется нет) оптимизаций..... Что с точностью? Есть ли анализ точности? Как делается? (глаз зацепился, что вы в примерах не задумываясь double пишите).
Могу ли я (кажется нет - но поправьте) нарисовать "рельеф" и запустить по нему кататься шарик? Чем закончится? Накапливаемая ошибка?
П.С. Личное мнение: кажется в 2025 году (за пределами студенческих курсовых или специальных экспоненциальных случаев разбора или содержательных сообщений об ошибках) - задачи лексинга \ парсинга не являются актуальными, они просто делаются и всё. Сам бы взял парсер-комбинатор. ИМХО это оптимальный по соотношению "всё ещё грамматика \ долго писать \ сложно отлаживать \ подставить костыль в любое место 'если что' ". В Rust это nom. Nom8 сам не пробовал, т.к. пробовал на Rust 3-4 года назад.
Так а в чём возражение\нестыковка-то?
Давайте проверим:
несправедливо, когда одни рождаются с золотой ложкой во рту, а другие вынуждены работать с самого детсва.
Подходит под ваше определение?
SoC ?
Я бы предположил, что NoC - но было бы странное делать ядро системы не на ведущем техпроцессе.
Самообразование в больших количествах (все слова важны) - это социально одобряемая лень.
Можете провести эксперимент на себе:
1. Прочитать про какую-нибудь фундаментальную, относительно далёкую от вас технологию прям учебник или фундаментальную книгу.
2. Заняться на практике этой технологией.
Вы будете удивлены насколько "самообразование" отличается от реальной деятельности.
Ну и в целом плачевные последствия "самообразования в больших количествах" - можно увидеть у разных блоггеров формата "обо всём и ни о чём умными словами".
Особенно когда они про твою область начинают.
Потому, для чего существуют устоявшиеся термины: что само-придуманные названия будут хуже гуглится, чем устоявшиеся (после того, как человек прочитав статью начнёт что-то ещё и искать).
Но вообще я так со стороны проходил посмотреть, фронтэндом не знанимаюсь.
8*200 = 1600 (часов 1-на-1 с квалифицированным преподавателем).
Это +/- бьётся с цифрами, CEFR для изучения английского на С2 (исходя из ряда разумных предположений типа изучение пары языков в любом направлении одинаково трудоёмко, ....).
У меня ровно наоборот.
Правильно заговорить не мог пока не начал правильно слышать все английские гласные (включая дифтонги).
До тех пор - просто не мог-таки понять что от меня нужно.
Параллельно с пассивным слушанием (подкасты \ фэнтезятина в метро на\с работы) - послушал разбор английской фонетики на phonetic fanatic - рекомендую всем изучающим. Понял что надо слышать (как ловить обратную связь) от постановки звуков по IPA.
После этого дело пошло.
Бегло пробежался, но не нашёл ответа на главный вопрос - для которого "архитектура как код" лично мне могло бы быть полезно - предусмотрены ли разные представления для "подробной" и "общей" схемы подсистемы?
Поясню что именно по моему мнению необходимо:
Есть подсистема XXX. В ней есть 2 представления (за них отвечает 1 человек): XXX.API, XXX,implementation
XXX.implementatiln - собственно описание подсистемы
XXX.API - как будет выглядеть (как по сути встраивается в виде кода) подсистема XXX на всех диаграммах где она используется.
А дальше уже всё как вы описали: при изменении XXX.API - прогоняется CI/CD: меняются все диаграммы включающие XXX, делается проверка правил (подключения).....
https://ifstudies.org/in-the-news/liberal-women-are-the-least-happy-and-loneliest-in-america
Ну вообще "в американском общественном дискурсе" - довольно известная точка зрения.
"Надо наростить плотность вычислений" - ага, а мужики-то не знают.
https://www.amd.com/en/products/processors/technologies/3d-v-cache.html
Очень странное ощущение.
Успешные проекты которые я видел (я правда в системном программировании) - это забег на порядка 3 лет на максимально возможной скорости крайне профессиональной команды.
Что можно сделать "по вечерам, нерегулярно, без бюджета и привлечения сильной команды" (с шансом выше, чем выиграть в лотерею) - даже близко не представляю.
Сколько из 400+ млн репозиториев на github начали приносить деньги через год после создания на отметке 30KLoC?
Да это же библиотека парсинга общего назначения, а не парсинга языков программирования. Т.е сами выделяете два слоя:
Да будет многословнее - но управление вы держите в своих руках (помню "замечательный" опыт отладки lexx + yacc кода).
За ссылку ниже спасибо.
Вот конкретно по этому возражение.
Есть фирма - с которой у работника отношение. И для большинства работников, тем более линейных "боль и вознаграждение" работника заканчиваются внутри фирмы.
Продаёт фирма продукт твоей деятельности - одно отношение. Продаёт фирма продукт, а ты одно из десятков саппорт подразделений - другое.
Это как на годовом собрании: мы за этот год заработали $Х-llions, продавая Y-офис, спасибо нашим программистам они добавили Z-новых фич. Ну и тем, кто столы носил туалеты мыл и теплом офис обеспечивал тоже спасибо.
На просьбы бюджеты и запросы тех, кто Y-офис пишет - реагируют НАМНОГО быстрее чем тех, кто столы носит.
Качественно - то же. Деньги вам приносит не IT, а продукт, который поддерживается в том числе благодаря IT.
Количественно - разница да большая.
Но если "вдруг" решения какого-нибудь условно 2031года станет на 100% хватать для бизнеса - они без промедлений уволят весь департамент разработки, оставив только поддержку (я допускаю ситуацию, когда IT в целом прогрессирует, но для целей маркетплейса прогресс дальше технологий года Х(=2031 в нашем примере) прогресс избыточен).
В отличии от компаний представляющих непосредственно IT (хоть продукт хоть услугу). При любом хорошем отношении и "кофемашине смузи и релакс-комнате с Х5" - ты приносишь деньги \ ты тратишь деньги для поддержки основного продукта ощущается.
Я просто хочу дополнить, что IT в банке или условном Озоне-Авито-X5 -- имеет тот же статус обслуживающего основной бизнес подразделения.
Спасибо за ответ.
Будет интересно почитать другие статьи - именно в упор на другие модели механики \ оптимизации существующих (насколько я понимаю перед этим надо задать ограничения).
> А нужно single float?
C меня коньяк если найдёте где я это предлагал ;)
Я как раз скорее про увеличение точности в вычислениях (принимая решение в зависимости от аппаратной поддержки).
> со слабыми ключевыми словами?
Тут вроде боле-менее стандартно:
- в пределах того же уровня (лексер \ парсер ) - откат при обнаруженной ошибке делается из коробки (*) сколько угодно раз - формально это экспонента, на практике при любом разумном коде никакой экспоненты и близко нет.
- в пределах разных уровней - вроде из коробки в nom этого нет - придётся учить (делать дополнительные обёртки, которые умеют пробрасывать в лексер ошибки парсера)
*) для этого лексер должен выдавать вам "имя", а уже парсер представлять это (разрешая до семантического анализа все непределённости) как "keyword(string) | ident(string)"
Интересна содержательная часть работы, а особенно постановка задачи: что представляют собой физические движки, какие типы бывают (вы же наверняка один из существующих типов реализовали - но почему выбрали этот тип).
К чему ведёт выбор того или иного типа движка: "мощность" (что может \ не может симулировать) vs сложность реализации.
Наличие специфических (кажется нет) оптимизаций.....
Что с точностью? Есть ли анализ точности? Как делается?
(глаз зацепился, что вы в примерах не задумываясь double пишите).
Могу ли я (кажется нет - но поправьте) нарисовать "рельеф" и запустить по нему кататься шарик? Чем закончится? Накапливаемая ошибка?
П.С.
Личное мнение: кажется в 2025 году (за пределами студенческих курсовых или специальных экспоненциальных случаев разбора или содержательных сообщений об ошибках) - задачи лексинга \ парсинга не являются актуальными, они просто делаются и всё.
Сам бы взял парсер-комбинатор. ИМХО это оптимальный по соотношению "всё ещё грамматика \ долго писать \ сложно отлаживать \ подставить костыль в любое место 'если что' ". В Rust это nom. Nom8 сам не пробовал, т.к. пробовал на Rust 3-4 года назад.
Ну да потому, что условно с 95 по 2010й за микроэлектронику не платили вообще ничего.
Денежнее было идти пылесосы \ телевизоры ремонтировать.
Кажется мы видим пример, когда работают по схеме: "время на обдумывание задач в нашем рабочем процессе не предусмотрено".
Если это не эпатаж-провокация, то вероятно с соответствующими результатами.
пожалуйста пример публичного выступления русскоговорящего на английском.
Тем более вы про академию (а не своих знакомых) - примеров должно быть полно.