Есть очень распространённое явление, когда географические пункты называются иначе в других странах. Китай, Германия, Грузия - типичные примеры. С островом Ява произошло примерно то же самое.
В отличие от географических пунктов, айтишные термины не принято переводить или транскрибировать. У нас нет языка "простой", или эс-диез. Вся айтишка пользуется англоязычными терминами, поэтому и в русском языке язык Java читается по-английски.
Собственно, он и пишется по-английски. Нет правильного написания названия Java на русском, он просто не должен переводиться.
Ну а зеркалить на него перевод географической точки совсем некорректно.
Теперь Copilot, интегрированный в Visual Studio, способен автоматически создавать комментарии к функциям.
Сомнительная функция. Обычно комментарий нужен там, где по коду не ясно, почему так сделано. А если по коду понятно, что метод делает, то комментарий не нужен. Особенно, от электронного болвана.
А я не могу понять, как люди пользуются низкопрофильной клавиатурой. У меня три ноутбука и я так и не смог привыкнуть и почувствовать удовольствие ни от одной ноутбучной (и далее по тексту).
Но я не упрекаю никого и не агитирую пересаживаться на механику.
Я привык набирать именно на механике, когда кнопка срабатывает на половине нажатия и не надо со всей силы по ней лупить. Половина нажатия на низкопрофильных клавиатурах... ну её нет. Ход клавиш - это скорее вопрос привычки. На что натренирована вспомогательная нейросеть спинного мозга, то объективно и удобнее. А ещё да, антропометрические данные тоже могут играть свою роль. У меня длинные пальцы, мне с механикой очень удобно.
Только бешусь, когда в очередной раз не попадаю по кнопке "ё". В современных клавиатурах за каким-то хреном ряд функциональных клавиш подвинули чуть ближе к верхнему ряду. Напомню, у меня длинные пальцы, и вместе с "ё" у меня нажимается угадайте что?
Вы сейчас передёргиваете. Я говорил, что код пишется для человека, а не для машины. Обоснование я тоже дал - код читается гораздо чаще, чем пишется.
С чем вы хотите поспорить? С тем что код чаще читается, чем пишется? Ну удачи.
Что значит "для бизнеса"? Не для бизнеса.
Я так тоже могу упростить до крайностей, смотрите: Бизнесу нет дела до кода, бизнес делает деньги. И всё, что ему нужно - это деньги. Код ему не нужен. Код - это вообще-то затраты на поддержку, а бизнес затраты не любит. Вывод: бизнес должен избегать написание кода.
Нет метрик этой читаемости, увы.
Да всмысле? Вот же сами пишете:
Что вот можно взять нового сотрудника и он разберется, что в этих строчках происходит? Или за несколько минут/часов сможет найти баг в незнакомо проекте?
Именно так. Вот тот самый пресловутый wtf/min. Есть ещё kloc, глубина наследования, связность классов.
Если вы не можете применить метрики прямо сейчас к проекту, это не значит, что их нет. Они есть. Но в силу уникальности каждого решения очень сложно делать общие метрики, которые уже где-то на таком же решении обкатаны.
Если вам нужно взять тысячу джунов и проверить время вкатывания на одном проекте и на другом, но с разной архитектурой, то не говорите, что это невозможно сделать. У вас просто денег нет на такие исследования.
Вы можете сказать
Не надо за меня говорить, что я могу сказать. Пожалуйста.
И тем более, приравнивать читаемость к каким-то абстрактным практикам. Я выбрал термин "читаемость" и я на нём настаиваю. Я не имел в виду религиозное соблюдение солида или что-то в этом роде. Я говорил про читаемость. Про понятность.
Нет. Написать работающий код любой дурак может. Машина простит любой хаос в оформлении и любые названия переменных.
Код пишется людьми и для людей, и первая задача кода - быть понятным. Потому что код гораздо чаще читается, чем пишется.
Читаемость кода - это не лирика и не демагогия, как вам показалось. Технический долг - это не страшилки программеров. Он реально существует и способен похоронить под своей тяжестью любой проект.
Понятный код способен ускорить на порядок разработку и снизить на порядок стоимость поддержки проекта. Чем больше проект - тем сильнее влияние читаемости.
Работа программиста - это не написание кода. Это управление сложностью конструкции. И ООП - это один из главных инструментов в этом деле. Как любой инструмент, у него есть некий порог полезности, ниже которого накладные расходы на внедрение инструмента не дают выгоды, для себя я оцениваю этот порог в 300-500 строк, то есть дальше крохотного скрипта ООП почти всегда упрощает восприятие кода и сокращает расходы на поддержку.
Я сейчас наговорил кучу банальных вещей, простите.
Не понимаю, как рейки могли придать этой конструкции устойчивость. В моём понимании у этой конструкции поперечный разброд и шатание никуда не делись, тут из вариантов только слева к стенке прислонять и прижимать шкафом справа.
Для устранения такого шатания необходима поперечина вдоль всей задней стенки высотой сантиметров 20 хотя бы. И не с самого верха, а с отступом тоже см 20.
Меня в этой конструкции очень, нет ОЧЕНЬ смущает плечо рычага по горизонтали - расстояние между центрами двух крайних креплений и центральным. Автор на этом же плясать собрался? Вот когда нагрузка направлена строго вниз - всё хорошо. Как только усилие получает сколь-нибудь значительное отклонение влево и вправо, то сразу усиливается этим рычагом. Мультипликатор - высота ножки. То есть, этот саморез вырывает с мясом, стол складывается как карточный домик, автор получает ЧМТ и больше не пляшет.
Я ожидал, что в примерах будет что-то вроде Raft, Valheim или даже Project Zomboid. Принц персии и борда - это зашейдеренные аутлайном довольно сложные модели.
Я сегодня пробовал нагопотить сайт-одностраничку. Сам я в современную вёрстку не умею, а древнюю забыл, поэтому решил отдать на аутсорс. Сначала всё шло хорошо, гопота собрала годный шаблон. Но по мере правок её сознание уплывало всё дальше куда-то в туманную даль. Вот я третий раз попросил вернуть прайс как было, убрать стописят баксов и вернуть зачёркнутые 100:
Она врёт. Нагло, беззастенчиво, в глаза. Но это не самое важное. Самое важное, что начинает терять контекст и переписывать то, о чём давно в нескольких итерациях договорились. Она не может удержать контекст даже маленькой странички. Она не может настроить блоки, чтобы был читаемый текст с достаточной контрастностью. И это простой веб.
В программирование я LLM даже близко не подпущу, там сложность на несколько порядков больше. А последствия бардака на порядок больнее.
Насчет поддержки актуальности, да, проще всего вносить изменения только в модель, остальное перегенерировать
А по-другому никак... Потому что всегда нужно хранить дополнительные параметры модели, которых нет ни в БД, ни в коде. Притом разрабы работают в разных окружениях (тест, дев, прод) и могут менять модель под свою задачу, а потом это всё надо мержить вместе с кодом, чтобы и тот и тот PR заработал в другом окружении.
И да, всё правильно, нужно делать не пересоздание структуры БД, а изменение. У меня этот механизм называется DDL diff. Состояние БД сравнивается с моделью и генерируется DDL, который приводит БД к состоянию модели. Не напрямую, конечно, с выбором и вычиткой DDL. Это всё довольно сложные механизмы, требующие знаний в механике баз данных.
Тут ещё есть один краеугольный камень - удобство. Это уже больше из области психологии, но всё же. Если разрабам неудобно напрямую в таком редакторе менять структуру - хоть что делай, они будут работать в другом инструменте, и иногда синхронизировать модель. Наверное. Но это не точно.
Обратная задача (reverse engineering — создание или обновление модели по коду) может быть уже немного сложнее, хотя в принципе тоже имеет право на существование. Особенно если есть legacy‑проект, где просто база данных, код и нет никаких моделей
Как раз такой проблемы нет. В случае, если приложение уже умеет генерировать DDL diff. Если есть база данных, то можно прочитать её структуру и создать модель. Механизм всё тот же самый. Конечно, с кодом нужно будет повозиться, особенно если запросы раскиданы по всей кодобазе и особенно, если не использовался ORM. Но это в любом случае надо делать, чтобы понимать, какие части модели действительно используются в коде.
Первая проблема при создании такого рода инструмента - это поддержка актуальности. Поэтому я рассматривал подход model-first, когда модель данных создаётся и редактируется в отдельном приложении, и затем уже синхронизируется с БД и кодом.
Собственно, я такое приложение и разрабатываю. Это что-то вроде dbSchema, но есть возможность передавать всю структуру данных в python-скрипт, который уже в нужном языке сгенерирует нужный код. У каждого свои потребности, поэтому я решил именно так сделать.
При растущей мировой экономике другим странам нужно всё больше и больше долларов, чтобы расплачиваться друг с другом. Эта эмиссия может запросто перекрыть (и перекрывает) дисбаланс и делать с этим ничего не нужно. Уж точно не так, как делает Трамп. Он просто угробит сложившиеся отрасли и если у него что-то получится, то это откат экономики США к индустриальной модели.
Да, США получается бенифициар растущей экономики. За счёт стабильности своей валюты, за счёт глобальности экономики и устойчивости государственных бумаг. Они могут просто "напечатать" новые доллары для покрытия дефицита и всем будет хорошо. "Напечатать" я взял в кавычки, потому что фрс так просто не даст денег государству потому что "надо". Там довольно сложная система.
Хорошо, согласен, не очень корректно. Изначально моя мысль была о том, что для постиндустриальной экономики некорректно считать дефицит только по товарному обороту. Цифр у меня нет, цифры для этого утверждения не нужны. ТС давал какие-то цифры в комментарии ниже
Это некорректная цифра, если говорить про торговый баланс. Как я уже сказал, часть товаров экспорта были только что импортированы из фабрик Китая/Тайваня. Очень важно учитывать долю импорта в экспорте, потому что Трамп наложил пошлины именно на импорт, который является частью экспорта.
Так C# и есть java с нуля без десятка лет легаси. С теми вон самыми.
В чём? В том, что они совершенно случайно потратили 15 лет ресёрча в области нейросетей?
Есть очень распространённое явление, когда географические пункты называются иначе в других странах. Китай, Германия, Грузия - типичные примеры. С островом Ява произошло примерно то же самое.
В отличие от географических пунктов, айтишные термины не принято переводить или транскрибировать. У нас нет языка "простой", или эс-диез. Вся айтишка пользуется англоязычными терминами, поэтому и в русском языке язык Java читается по-английски.
Собственно, он и пишется по-английски. Нет правильного написания названия Java на русском, он просто не должен переводиться.
Ну а зеркалить на него перевод географической точки совсем некорректно.
Язык программирования - Джава. Ява - это русскоязычное название острова Java. А язык взял название именно от англоязычного варианта.
Так старфилд и не провалился - они просто и не задумывали делать игру. Денег собрали? Собрали.
Сомнительная функция. Обычно комментарий нужен там, где по коду не ясно, почему так сделано. А если по коду понятно, что метод делает, то комментарий не нужен. Особенно, от электронного болвана.
А я не могу понять, как люди пользуются низкопрофильной клавиатурой. У меня три ноутбука и я так и не смог привыкнуть и почувствовать удовольствие ни от одной ноутбучной (и далее по тексту).
Но я не упрекаю никого и не агитирую пересаживаться на механику.
Я привык набирать именно на механике, когда кнопка срабатывает на половине нажатия и не надо со всей силы по ней лупить. Половина нажатия на низкопрофильных клавиатурах... ну её нет. Ход клавиш - это скорее вопрос привычки. На что натренирована вспомогательная нейросеть спинного мозга, то объективно и удобнее. А ещё да, антропометрические данные тоже могут играть свою роль. У меня длинные пальцы, мне с механикой очень удобно.
Только бешусь, когда в очередной раз не попадаю по кнопке "ё". В современных клавиатурах за каким-то хреном ряд функциональных клавиш подвинули чуть ближе к верхнему ряду. Напомню, у меня длинные пальцы, и вместе с "ё" у меня нажимается угадайте что?
Вы сейчас передёргиваете. Я говорил, что код пишется для человека, а не для машины. Обоснование я тоже дал - код читается гораздо чаще, чем пишется.
С чем вы хотите поспорить? С тем что код чаще читается, чем пишется? Ну удачи.
Что значит "для бизнеса"? Не для бизнеса.
Я так тоже могу упростить до крайностей, смотрите: Бизнесу нет дела до кода, бизнес делает деньги. И всё, что ему нужно - это деньги. Код ему не нужен. Код - это вообще-то затраты на поддержку, а бизнес затраты не любит. Вывод: бизнес должен избегать написание кода.
Да всмысле? Вот же сами пишете:
Именно так. Вот тот самый пресловутый wtf/min. Есть ещё kloc, глубина наследования, связность классов.
Если вы не можете применить метрики прямо сейчас к проекту, это не значит, что их нет. Они есть. Но в силу уникальности каждого решения очень сложно делать общие метрики, которые уже где-то на таком же решении обкатаны.
Если вам нужно взять тысячу джунов и проверить время вкатывания на одном проекте и на другом, но с разной архитектурой, то не говорите, что это невозможно сделать. У вас просто денег нет на такие исследования.
Не надо за меня говорить, что я могу сказать. Пожалуйста.
И тем более, приравнивать читаемость к каким-то абстрактным практикам. Я выбрал термин "читаемость" и я на нём настаиваю. Я не имел в виду религиозное соблюдение солида или что-то в этом роде. Я говорил про читаемость. Про понятность.
Нет. Написать работающий код любой дурак может. Машина простит любой хаос в оформлении и любые названия переменных.
Код пишется людьми и для людей, и первая задача кода - быть понятным. Потому что код гораздо чаще читается, чем пишется.
Читаемость кода - это не лирика и не демагогия, как вам показалось. Технический долг - это не страшилки программеров. Он реально существует и способен похоронить под своей тяжестью любой проект.
Понятный код способен ускорить на порядок разработку и снизить на порядок стоимость поддержки проекта. Чем больше проект - тем сильнее влияние читаемости.
Работа программиста - это не написание кода. Это управление сложностью конструкции. И ООП - это один из главных инструментов в этом деле. Как любой инструмент, у него есть некий порог полезности, ниже которого накладные расходы на внедрение инструмента не дают выгоды, для себя я оцениваю этот порог в 300-500 строк, то есть дальше крохотного скрипта ООП почти всегда упрощает восприятие кода и сокращает расходы на поддержку.
Я сейчас наговорил кучу банальных вещей, простите.
А что ещё он мог сказать? Ему лопаты продавать надо.
ЧатГПТ нагло и беззастенчиво врёт. И остальные тоже. У них отличается процент и порог вранья, но принципиальной разницы нет.
5 тб вавки при 44кГц/16 бит это 8662 часа. Это год непрерывного воспроизведения, если слушать 24/7. Вы это действительно слушаете?
Не понимаю, как рейки могли придать этой конструкции устойчивость. В моём понимании у этой конструкции поперечный разброд и шатание никуда не делись, тут из вариантов только слева к стенке прислонять и прижимать шкафом справа.
Для устранения такого шатания необходима поперечина вдоль всей задней стенки высотой сантиметров 20 хотя бы. И не с самого верха, а с отступом тоже см 20.
Меня в этой конструкции очень, нет ОЧЕНЬ смущает плечо рычага по горизонтали - расстояние между центрами двух крайних креплений и центральным. Автор на этом же плясать собрался? Вот когда нагрузка направлена строго вниз - всё хорошо. Как только усилие получает сколь-нибудь значительное отклонение влево и вправо, то сразу усиливается этим рычагом. Мультипликатор - высота ножки. То есть, этот саморез вырывает с мясом, стол складывается как карточный домик, автор получает ЧМТ и больше не пляшет.
Я ожидал, что в примерах будет что-то вроде Raft, Valheim или даже Project Zomboid. Принц персии и борда - это зашейдеренные аутлайном довольно сложные модели.
Я сегодня пробовал нагопотить сайт-одностраничку. Сам я в современную вёрстку не умею, а древнюю забыл, поэтому решил отдать на аутсорс. Сначала всё шло хорошо, гопота собрала годный шаблон. Но по мере правок её сознание уплывало всё дальше куда-то в туманную даль. Вот я третий раз попросил вернуть прайс как было, убрать стописят баксов и вернуть зачёркнутые 100:
Она врёт. Нагло, беззастенчиво, в глаза. Но это не самое важное. Самое важное, что начинает терять контекст и переписывать то, о чём давно в нескольких итерациях договорились. Она не может удержать контекст даже маленькой странички. Она не может настроить блоки, чтобы был читаемый текст с достаточной контрастностью. И это простой веб.
В программирование я LLM даже близко не подпущу, там сложность на несколько порядков больше. А последствия бардака на порядок больнее.
А по-другому никак... Потому что всегда нужно хранить дополнительные параметры модели, которых нет ни в БД, ни в коде. Притом разрабы работают в разных окружениях (тест, дев, прод) и могут менять модель под свою задачу, а потом это всё надо мержить вместе с кодом, чтобы и тот и тот PR заработал в другом окружении.
И да, всё правильно, нужно делать не пересоздание структуры БД, а изменение. У меня этот механизм называется DDL diff. Состояние БД сравнивается с моделью и генерируется DDL, который приводит БД к состоянию модели. Не напрямую, конечно, с выбором и вычиткой DDL. Это всё довольно сложные механизмы, требующие знаний в механике баз данных.
Тут ещё есть один краеугольный камень - удобство. Это уже больше из области психологии, но всё же. Если разрабам неудобно напрямую в таком редакторе менять структуру - хоть что делай, они будут работать в другом инструменте, и иногда синхронизировать модель. Наверное. Но это не точно.
Как раз такой проблемы нет. В случае, если приложение уже умеет генерировать DDL diff. Если есть база данных, то можно прочитать её структуру и создать модель. Механизм всё тот же самый. Конечно, с кодом нужно будет повозиться, особенно если запросы раскиданы по всей кодобазе и особенно, если не использовался ORM. Но это в любом случае надо делать, чтобы понимать, какие части модели действительно используются в коде.
Первая проблема при создании такого рода инструмента - это поддержка актуальности. Поэтому я рассматривал подход model-first, когда модель данных создаётся и редактируется в отдельном приложении, и затем уже синхронизируется с БД и кодом.
Собственно, я такое приложение и разрабатываю. Это что-то вроде dbSchema, но есть возможность передавать всю структуру данных в python-скрипт, который уже в нужном языке сгенерирует нужный код. У каждого свои потребности, поэтому я решил именно так сделать.
При растущей мировой экономике другим странам нужно всё больше и больше долларов, чтобы расплачиваться друг с другом. Эта эмиссия может запросто перекрыть (и перекрывает) дисбаланс и делать с этим ничего не нужно. Уж точно не так, как делает Трамп. Он просто угробит сложившиеся отрасли и если у него что-то получится, то это откат экономики США к индустриальной модели.
Да, США получается бенифициар растущей экономики. За счёт стабильности своей валюты, за счёт глобальности экономики и устойчивости государственных бумаг. Они могут просто "напечатать" новые доллары для покрытия дефицита и всем будет хорошо. "Напечатать" я взял в кавычки, потому что фрс так просто не даст денег государству потому что "надо". Там довольно сложная система.
Хорошо, согласен, не очень корректно. Изначально моя мысль была о том, что для постиндустриальной экономики некорректно считать дефицит только по товарному обороту. Цифр у меня нет, цифры для этого утверждения не нужны. ТС давал какие-то цифры в комментарии ниже
А могут и не сломать. Я про это. Торговый дисбаланс может жить счастливо вечно, если будет дальнейшее смещение США в сторону услуг.
Это некорректная цифра, если говорить про торговый баланс. Как я уже сказал, часть товаров экспорта были только что импортированы из фабрик Китая/Тайваня. Очень важно учитывать долю импорта в экспорте, потому что Трамп наложил пошлины именно на импорт, который является частью экспорта.