Как раз для вкатышей он лучше подходит, потому что следит, чтобы несмышленыш себе ногу не отстрелил. Если разработчик понимает, что делает, это только мешает. По поводу C# аргумент так себе, но вы это похоже и сами понимаете ))
Проблема TS в том, что он убивает производительность разработчика. Далеко не всегда для корректного кода на JS тип выводится автоматом. Приходится вместо разработки функционала еще тратить кучу нервов чтобы уговорить TS, что тут все нормально с типами.
У меня был такой случай, давно правда - водитель уехал в другом направлении, а потом телепортировался к месту подачи и стал на меня наезжать, что я не там стою, чтобы отменял заказ. Отменять не стал - жалоба в СП решила вопрос.
Поводом для ревизии данного вопроса стало то, что я по сей день слышу от специалистов (в том числе позиционирующих себя как senior), что современный JavaScript является однопоточным.
Эти понятия - "однопоточный"/"многопоточный" вообще неприменимы к языкам программирования. Так что, из-за чего вообще весь сыр-бор? Что кто-то интуитивно, и неправильно, пользуется терминами?
Услышите в следующий раз что кто-то так говорит, попросите привести пример многопоточного ЯП. Будет интересно )))
На мой взгляд, лучшее, что может сделать потребитель - это найти оптимальное предложение на рынке. НО! В задачу оптимизации должна входить не только цена товара, а еще и качество сервиса, гарантии и т.д. (весовые коэффициенты расставить по вкусу). Про себя могу сказать, что зачастую покупаю технику не там, где самое дешевое предложение, но там, где был опыт комфортного решения вопросов с гарантией/возвратом товара. Если вам не нравится опыт в взаимодействия с бизнесом и у него не уникальных предложений - просто там больше не покупайте. Если нет опыта взаимодействия - изучите отзывы, открытые источники до покупки.
ps. После вашей статьи ничего в МВидео больше покупать не буду, даже если там будет цена ниже.
Ни в какой другой отрасли столько внимания контролю и минимизации воздействия на окружающую среду, персонал и население, как в атомной, не уделяют. Я много лет работаю на предприятии ЯТЦ, так что знаю не понаслышке.
Тут уже предлагали выше решить такую задачу на микросервисах. Я предлагаю пойти дальше. Чтобы по-настоящему хайпануть на трендах, надо взять какую-нибудь LLM архитектуру где-нибудь на 40B параметров и обучить исключительно на эту задачу. Считаю что это будет гораздо эпичнее.
Интересно конечно получилось, задача по снижению потребления энергоресурса трансформировалась в задачу управления вентиляторами. Не удивлен, что бизнес такое не купил.
Мутации дают шанс выскочить из локального минимума. Еще можно поставить силу мутаций в зависимость от разнообразия генома популяции - чем ближе скрещиваемые геномы, тем больше коэффициент мутаций. В результате царицы конешно будут рожать в основном неведомых нежизнеспособных зверушек, но, если повезет, может и апельсинка от осинки получиться
Как раз для вкатышей он лучше подходит, потому что следит, чтобы несмышленыш себе ногу не отстрелил. Если разработчик понимает, что делает, это только мешает.
По поводу C# аргумент так себе, но вы это похоже и сами понимаете ))
Проблема TS в том, что он убивает производительность разработчика. Далеко не всегда для корректного кода на JS тип выводится автоматом. Приходится вместо разработки функционала еще тратить кучу нервов чтобы уговорить TS, что тут все нормально с типами.
Вы мне напомнили одного персонажа, который для изучения JavaScript рекомендует изучать исключительно спецификацию ECMAScript
Меня с собой возьмите ))
У меня был такой случай, давно правда - водитель уехал в другом направлении, а потом телепортировался к месту подачи и стал на меня наезжать, что я не там стою, чтобы отменял заказ. Отменять не стал - жалоба в СП решила вопрос.
Эти понятия - "однопоточный"/"многопоточный" вообще неприменимы к языкам программирования. Так что, из-за чего вообще весь сыр-бор? Что кто-то интуитивно, и неправильно, пользуется терминами?
Услышите в следующий раз что кто-то так говорит, попросите привести пример многопоточного ЯП. Будет интересно )))
Посоветуйте, что можно почитать/посмотреть для прокачки скилов по bash?
Да, но нужно учитывать, что он в первую очередь Т, а потом уже Э
Хотелось бы конечно, чтобы сеть сама рисовала руки правильно, а не костылями.
А есть надежда, что когда-нибудь руки сразу будут генерироваться как надо?
На мой взгляд, лучшее, что может сделать потребитель - это найти оптимальное предложение на рынке. НО! В задачу оптимизации должна входить не только цена товара, а еще и качество сервиса, гарантии и т.д. (весовые коэффициенты расставить по вкусу). Про себя могу сказать, что зачастую покупаю технику не там, где самое дешевое предложение, но там, где был опыт комфортного решения вопросов с гарантией/возвратом товара. Если вам не нравится опыт в взаимодействия с бизнесом и у него не уникальных предложений - просто там больше не покупайте. Если нет опыта взаимодействия - изучите отзывы, открытые источники до покупки.
ps. После вашей статьи ничего в МВидео больше покупать не буду, даже если там будет цена ниже.
О да, выдвижные полочки для клавы и мыши, это зло.
Ни в какой другой отрасли столько внимания контролю и минимизации воздействия на окружающую среду, персонал и население, как в атомной, не уделяют. Я много лет работаю на предприятии ЯТЦ, так что знаю не понаслышке.
С таким подходом можно уже и на 64 бит замахнуться
Тут уже предлагали выше решить такую задачу на микросервисах. Я предлагаю пойти дальше. Чтобы по-настоящему хайпануть на трендах, надо взять какую-нибудь LLM архитектуру где-нибудь на 40B параметров и обучить исключительно на эту задачу. Считаю что это будет гораздо эпичнее.
Кажется вы изобрели temporal table )
https://github.com/arkhipov/temporal_tables
Смекалка. Это называется смекалка.
Гигачат выкупает задачи с подвохом:
Интересно конечно получилось, задача по снижению потребления энергоресурса трансформировалась в задачу управления вентиляторами. Не удивлен, что бизнес такое не купил.
Мутации дают шанс выскочить из локального минимума. Еще можно поставить силу мутаций в зависимость от разнообразия генома популяции - чем ближе скрещиваемые геномы, тем больше коэффициент мутаций. В результате царицы конешно будут рожать в основном неведомых нежизнеспособных зверушек, но, если повезет, может и апельсинка от осинки получиться