Случай который Вы описываете это пример места где типы в смысле TS сильно мешают. Условный User с которым хочется работать это не коробочка с отсеками id, nickname, email — это запись у которой есть аттрибуты id, nickname, email и что угодно еще. В TS и его собратьях если вы хотите положить рядом с почтой что то еще — вы обязаны заводить новый класс. Мало того они еще предлагают отвратительный выбор как это делать — текстовое копирование / наследование / композиция.
Хочешь иконку? Новая коробочка — UserProfile. У вас появился компонент смены пароля? Будь добр напиши нувою коробочку… UserAccount, с полем под хэш. У тебя только UserProfile а Account делается из сырых User, давай-ка дружок писать адаптер или делать заплыв в API за правильной коробочкой. Это нарушает основной посыл типизированных языков — решать тривиальные проблемы силами машины.
Классы в TS равно как Java и даже популярные в Haskell data — неадекватные способы моделировать внешние данные. Особенно в UI приложениях. Особенно построенных вокруг реляционных БД с их JOINами. Можно посмотреть вот этот доклад с более развернутым списком претензий: https://www.youtube.com/watch?v=YR5WdGrpoug
Нет, а вот если один грает на модеме 56к из 90х а другой на оптике недалеко от магистрали то явно нечестной.
У бота совсем другая скорость интерфейса ввода/вывода с игрой. Там и зумхак (вроде как признаный а вроде и довольно тихо) и произвольное выделение юнитов (без контролок и не «квадратом») и выделение строений на которые вообще ни разу не смотрел экран.
Исходные данные не картинка на экране а координаты всех видимых объектов на карте. Для человека физически невозможно их одновременно воспринять, конец истории.
Ну тогда я вообще не вижу прорыва равно как и цели его разоблачения. Сделали бота без явных слабых мест. При радикально других физических возможностях он выигрывает, ну ок. Ждём футбольного турнира сборной гугла со сборной людей без ног.
Я не могу найти инфу. А AlphaStar вход модель карты или картинка на экране? Иными словами он распознаёт изображение или видит всю цифровую модель поля боя?
> 2-я за свою позицию за «крысинное управление» разработчиками
Я посмотрел историю коментариев. Ваша позиция из них не понятна. Если Вы и пытались её выразить то она утонула в оборотах, эпитетах и отсутствии абзацев. Так как они занимают довольно много места то глубокое минусование было необходимой реакцией сообщества.
Фатальная комбинация технологии и предметной области. Убирай вообще опыт из резюме, гооври что переучился из аналитика (всё-равно никто не знает кто это и что должны уметь).
Чуть чуть поработаю капитаном. Автор коментария выше намекал на то что вопрос «что лучше?» совершенно бессмысленнен без уточнения для кого собственно лучше.
Есть вариант сделать :23-24 рабочими?
У вас в профиле тоже нет иконки и еще куча полей не заполнена. Кнопка «Отправить» явно не должна работать.
Случай который Вы описываете это пример места где типы в смысле TS сильно мешают. Условный User с которым хочется работать это не коробочка с отсеками id, nickname, email — это запись у которой есть аттрибуты id, nickname, email и что угодно еще. В TS и его собратьях если вы хотите положить рядом с почтой что то еще — вы обязаны заводить новый класс. Мало того они еще предлагают отвратительный выбор как это делать — текстовое копирование / наследование / композиция.
Хочешь иконку? Новая коробочка — UserProfile. У вас появился компонент смены пароля? Будь добр напиши нувою коробочку… UserAccount, с полем под хэш. У тебя только UserProfile а Account делается из сырых User, давай-ка дружок писать адаптер или делать заплыв в API за правильной коробочкой. Это нарушает основной посыл типизированных языков — решать тривиальные проблемы силами машины.
Классы в TS равно как Java и даже популярные в Haskell data — неадекватные способы моделировать внешние данные. Особенно в UI приложениях. Особенно построенных вокруг реляционных БД с их JOINами. Можно посмотреть вот этот доклад с более развернутым списком претензий: https://www.youtube.com/watch?v=YR5WdGrpoug
Эта проблема отчати осознаётся сообществом типизированных ЯП, но внимания ей уделяется на фоне всяких зависимых типов и гетерогенных списков непропорционально мало. Я знаю только эту работу, в основном рализованную в Elm: https://www.microsoft.com/en-us/research/publication/extensible-records-with-scoped-labels/
Это не какое-то глобальное оправдание динамической типизации, это одна из причин почему статическая малоприменима в ряде проектов.
Не вижу проблемы. Дырка usb, дырка d-port, спеки чёто стоят но не космически.
У бота совсем другая скорость интерфейса ввода/вывода с игрой. Там и зумхак (вроде как признаный а вроде и довольно тихо) и произвольное выделение юнитов (без контролок и не «квадратом») и выделение строений на которые вообще ни разу не смотрел экран.
Вы не хотите не голословных утверждений, аргументированные предложения требуют данных. Вот я и спрашиваю где Вы их публикуете?
Я посмотрел историю коментариев. Ваша позиция из них не понятна. Если Вы и пытались её выразить то она утонула в оборотах, эпитетах и отсутствии абзацев. Так как они занимают довольно много места то глубокое минусование было необходимой реакцией сообщества.
Там ютутб еще пяток нормльных отчётов в рекомендациях выкатит точно.
Тем что 3 уже не поддерживается?)