А аннотации или тайп хинтинг вы не используете? А то у меня есть подозрение, что IDE вам не подсвечивает типы, и при попытке это исправить, вы вернетесь к циклическим импортам. Но я могу ошибаться. Можете рассказать об этом?
Какие же например в пайтоне использовать циклы для получения индекса?
А зачем вообще другой цикл использовать, если благодаря наличию универсальных механизмов enumerate, range, zip, slice и т. д., можно гибче, и при этом не сложнее, получить больше комбинаций применения?
Речь о том, что тот же zip или slice можно использовать не только в циклах. Так зачем запоминать семантику двух разных подходов (for и foreach), когда и циклы, и остальное, можно положить поверх одного for, применяя вспомогательные простые универсальные механизмы, которые касаются не только циклов?
Type hints — всё-таки совсем не статическая типизация
Я и не говорил, что это статическая типизация, я сказал, что хинтинг решает описанные вами проблемы, попутно избавляя от проблем статической типизации (бойлерплейт в ненужных местах)
Когда начинаются вещи вроде «список кортежей, в которых лежат инты со словарями», поведение объектов при применении вроде бы простых операций становится неочевидным. Да, это расплата за попытку сделать «удобно» вместо «строго». Поведение списков, объявленных как []*x, — пожалуй, Ниагарский водопад в этом мире текущих абстракций.
Это проблемы не в динамической типизации, а в сложных структурах и сигнатурах методов. Покажите пример таких структур, которые элегантно описываются в статической типизации, и невозможно было бы описать хинтингом (и как часто у вас такая ситуация возникает?).
Но в целом Python со своей основной задачей (заменить шелл-скрипты) прекрасно справляется
Так можно было сказать о самых первых примитивных версиях питона. Сейчас же он слишком далеко ушел, чтобы даже упоминать о шелл скриптах.
Можно потратить в 5 раз меньше времени на разработку на языке с динамической типизацией, а потом в 10 раз дольше дебажить результат, чем на статически типизированном языке.
А можно потратить в 10 раз меньше времени на разработку на языке с динамической типизацией, а потом в 5 раз дольше дебажить результат, чем на статически типизированном языке.
Смотрите, я тоже могу цифры выдумывать.
На динамической типизации я могу использовать хинтинг там, где требуется, и не использовать там, где не требуется (например в локальных переменных метода или в каком-нибудь JSON-ответе с сотней полей от кривого стороннего API, из которого мне нужно только одно поле, мне вообще не нужна типизация). Хинтинг решит, описанные вами проблемы и избавит меня от бойлерплейта. При этом упрощается любая динамическая магия и метакод.
Короче в чистом виде и динамическая, и статическая типизация — это для меня неудобно. В идеале, я хочу, чтоб у меня был выбор.
Python, в котором форматирование кода влияет на выполнение программы.
Слишком громкая фраза.
1. Не любое форматирование, а только отступы.
2. Не любые отступы, а только отступы блоков кода (сюда не входят всякие многострочные перечисления и тексты).
3. Отступы там гибкие, поэтому ничто не мешает использовать 1 пробел, и ваша программа точно так же не будет визуально читаться.
Короче питон — не исключение, там тоже можно напачкать.
Срочно отправьте в SEC ваш коммент и статью графомана-Илюши, а то там пацаны из SEC в интернете слухов нахватались, и теперь к Дурову зачем-то пристают, в суды тащат, финансовые отчеты требуют. Прям так и скажите им: «товарищи из SEC, оставьте Павлика в покое, он не при делах, в интернете всё врут!»
Про TCP прочитал ваш текст несколько раз, так и не увидел проблему. Таблица состояний протокола известна и весьма понятна. Автомат — штука простая и легковесная.
Обозначьте проблему.
Про регулярки тоже не понял. Я говорил про классические регулярки, которыми все пользуются для типовых задач. Про экзотические случаи я ничего не говорил.
Если вы видите в игре персонажа, который упорно идёт в стену — вот это конечный автомат.
Не, это поломанный поиск пути, он не имеет к автоматам никакого отношения.
Если нужно получить минимальное реагирование на более чем один раздражитель — конечный автомат отправляется на свалку.
Автомат должен только определять, в каком режиме находится моб: патрулирует, отдыхает, преследует, бой с одним игроком, бой с несколькими игроками, бой на пороге смерти. Сами алгоритмы автомат же не реализует, скриптование в любом случае нужно.
Нейросети очень перехайпованы — они не настолько хороши, насколько про них говорят.
От задачи зависит. С какими-то задачами они справляются блестяще, лучше любого алгоритма и человека.
Ну это я так же могу сказать: грамотно обученная нейросеть переплюнет любой алгоритм.
В том же OpenAI
OpenAI — это тот, который всех в доту нагибал? Как только логика ИИ выходит за рамки «спрячься за стеной, брось дымовуху, атакуй», и появляется нужда в гибкой адаптивной тактике, алгоритмы отправляются на свалку. Такие алгоритмы не масштабируемы, на каждую тактику писать новый алгоритм.
Но в целом согласен, что пререхайпованы. И это кстати прекрасный пример золотого молотка, когда неуместное применение с плохим результатом ставит под сомнение всю технологию в глазах обывателей, а иногда и инвесторов.
Сетевой протокол было бы удобно описывать описывать автоматом, если бы в нем только менялись режимы, но не передавались никакие данные
А почему вы смешиваете два не связанных механизма? Переключение состояний пиров удобно делать именно на автоматах.
Взять банальный IP
А почему мы берем IP, где нет нужды в конечных автоматах, и на основе этого аргумента пытаемся объяснить неприменимость конечных автоматов для любых протоколов? Просто в очередной раз забиваем гвозди микроскопом, утверждая, что микроскоп говно.
Отсюда проистекает невозможность реализации TCP/IP на конечном автомате
А причем тут модель TCP/IP, если я говорил про протокол TCP, где как раз небольшой и детерминированный набор режимов?
По какой-то такой причине, например, yacc использует стэковую машину, являющуюся бесконечным автоматом, а последняя реализована на конечном автомате + стэк.
Я говорил про использование конечных автоматов, они тут используются. Все верно.
Полновесные регулярки perl способны разбирать нерегулярные языки и не могут быть реализованы на конечном автомате.
Можно поподробнее, что за полновесные регулярки perl? А то не знаю, как загуглить. А если ссылку дадите, буду вообще вдвойне благодарен.
Только очень тупой ИИ можно реализовать на конечных автоматах.
А что, в любой игре, любой NPC-моб или бот обязан быть неотличим от игрока? В большинстве случаев поведение большинства мобов можно строить на автомате, учитывая, что игрок не должен сильно задерживаться на каждом мобе. И даже поведение боссов можно строить на автоматах. Опять таки, не нужно пытаться применять микроскоп везде. Если нам требуется детерминированное поведение босса, чтобы дать игрокам возможность разработать против него тактику, то используйте автомат. Если требуется хитрый обучаемый ИИ с непредсказуемыми действиями, используйте что-то другое, хоть нейросети.
Программисту не нужны неизменяемые значения — он хочет иметь возможность их менять. Может быть, он и не будет ею пользоваться, но он хочет ее иметь. Программист обычно не хочет работать со ссылками — его интересуют только значения.
Опять вы за всех программистов решили, чего они хотят?
И опять привели какой-то говнокод в качестве примера плохого дизайна языка.
Конечные автоматы нынче всерьез применяют разве что в промышленных контроллерах, где исполняемые устройства представляют собой естественные автоматы [...]
О, святой компилятор!
Соглашусь.
Многие сетевые протоколы удобно делать на конечных автоматах. BGP DHCP-Server TCP
Да и вообще любые протоколы, которые переключаются между состояниями (типа ESTABLISHED, LISTENING, HANDSHAKING), очень удобно делать на автоматах.
Вот я засунул указатель на итератор в долгоживущее поле, и пошел по своим делам. А генератор, тем временем, живет и держит какой-то важный или большой ресурс — но я-то думаю, что просто держу один фрейм генератора, и больше ничего.
Я могу сделать на Це fopen(«filename», «w») и пойти по своим делам, занимая важный ресурс, и не имеет значение, функция это, генератор или объект. Очевидно потому, что дело не в генераторах. Предоставляя кому-то тяжелые ресурсы, вы должны хотя бы в докстринге написать «Обережно! Не занимайте долго ресурс». Если программист бесконтрольно открывает (на любом языке) файлы, сокеты, пайпы и не закрывает их, виноваты конечно же генераторы, а не то, что кто-то в этой цепочке дурачок.
Проблема заключается не в сопрограммах, а в том, что совместное выполнение алгоритмов резко повышает сложность их написания и понимания, как человеком, так и машиной.
Эм, нет, проблема заключается в неуместном применении инструментов, что с любым инструментом ведет к беде. Вообще с любым. У некоторых инструментов есть очень узкое но эффективное применение, и когда его делают золотым молотком, инструмент превращается в антипаттерн. Если вы предлагаете такие инструменты в принципе убирать, то можете их не использовать, а другим не мешайте. Я генераторы использую редко, но эффективно, где они действительно упрощают понимание алгоритма.
Вообще, все ваши кейсы с генераторами касаются проблем чего угодно, только не генераторов, но ваше рвение впечатляет.
Речь о том, что тот же zip или slice можно использовать не только в циклах. Так зачем запоминать семантику двух разных подходов (for и foreach), когда и циклы, и остальное, можно положить поверх одного for, применяя вспомогательные простые универсальные механизмы, которые касаются не только циклов?
Это проблемы не в динамической типизации, а в сложных структурах и сигнатурах методов. Покажите пример таких структур, которые элегантно описываются в статической типизации, и невозможно было бы описать хинтингом (и как часто у вас такая ситуация возникает?).
Так можно было сказать о самых первых примитивных версиях питона. Сейчас же он слишком далеко ушел, чтобы даже упоминать о шелл скриптах.
Смотрите, я тоже могу цифры выдумывать.
На динамической типизации я могу использовать хинтинг там, где требуется, и не использовать там, где не требуется (например в локальных переменных метода или в каком-нибудь JSON-ответе с сотней полей от кривого стороннего API, из которого мне нужно только одно поле, мне вообще не нужна типизация). Хинтинг решит, описанные вами проблемы и избавит меня от бойлерплейта. При этом упрощается любая динамическая магия и метакод.
Короче в чистом виде и динамическая, и статическая типизация — это для меня неудобно. В идеале, я хочу, чтоб у меня был выбор.
Из-за кэмелкейса в вашем нике, создается ложное впечатление, что Бог важнее путина
[/оффтоп]
извините
Слишком громкая фраза.
1. Не любое форматирование, а только отступы.
2. Не любые отступы, а только отступы блоков кода (сюда не входят всякие многострочные перечисления и тексты).
3. Отступы там гибкие, поэтому ничто не мешает использовать 1 пробел, и ваша программа точно так же не будет визуально читаться.
Короче питон — не исключение, там тоже можно напачкать.
Да. И инвесторы тоже верующие, и SEC. Как же хорошо, что вы свет пролили на положение дел.
Срочно отправьте в SEC ваш коммент и статью графомана-Илюши, а то там пацаны из SEC в интернете слухов нахватались, и теперь к Дурову зачем-то пристают, в суды тащат, финансовые отчеты требуют. Прям так и скажите им: «товарищи из SEC, оставьте Павлика в покое, он не при делах, в интернете всё врут!»
1. что за язык?
2. почему соседи выбрали плюсы для DSL?
3. чем дело кончилось?
Обозначьте проблему.
Про регулярки тоже не понял. Я говорил про классические регулярки, которыми все пользуются для типовых задач. Про экзотические случаи я ничего не говорил.
Не, это поломанный поиск пути, он не имеет к автоматам никакого отношения.
Автомат должен только определять, в каком режиме находится моб: патрулирует, отдыхает, преследует, бой с одним игроком, бой с несколькими игроками, бой на пороге смерти. Сами алгоритмы автомат же не реализует, скриптование в любом случае нужно.
От задачи зависит. С какими-то задачами они справляются блестяще, лучше любого алгоритма и человека.
Ну это я так же могу сказать: грамотно обученная нейросеть переплюнет любой алгоритм.
OpenAI — это тот, который всех в доту нагибал? Как только логика ИИ выходит за рамки «спрячься за стеной, брось дымовуху, атакуй», и появляется нужда в гибкой адаптивной тактике, алгоритмы отправляются на свалку. Такие алгоритмы не масштабируемы, на каждую тактику писать новый алгоритм.
Но в целом согласен, что пререхайпованы. И это кстати прекрасный пример золотого молотка, когда неуместное применение с плохим результатом ставит под сомнение всю технологию в глазах обывателей, а иногда и инвесторов.
А почему мы берем IP, где нет нужды в конечных автоматах, и на основе этого аргумента пытаемся объяснить неприменимость конечных автоматов для любых протоколов? Просто в очередной раз забиваем гвозди микроскопом, утверждая, что микроскоп говно.
А причем тут модель TCP/IP, если я говорил про протокол TCP, где как раз небольшой и детерминированный набор режимов?
Я говорил про использование конечных автоматов, они тут используются. Все верно.
Можно поподробнее, что за полновесные регулярки perl? А то не знаю, как загуглить. А если ссылку дадите, буду вообще вдвойне благодарен.
А что, в любой игре, любой NPC-моб или бот обязан быть неотличим от игрока? В большинстве случаев поведение большинства мобов можно строить на автомате, учитывая, что игрок не должен сильно задерживаться на каждом мобе. И даже поведение боссов можно строить на автоматах. Опять таки, не нужно пытаться применять микроскоп везде. Если нам требуется детерминированное поведение босса, чтобы дать игрокам возможность разработать против него тактику, то используйте автомат. Если требуется хитрый обучаемый ИИ с непредсказуемыми действиями, используйте что-то другое, хоть нейросети.
Опять вы за всех программистов решили, чего они хотят?
И опять привели какой-то говнокод в качестве примера плохого дизайна языка.
Соглашусь.
Многие сетевые протоколы удобно делать на конечных автоматах.
BGP
DHCP-Server
TCP
Да и вообще любые протоколы, которые переключаются между состояниями (типа ESTABLISHED, LISTENING, HANDSHAKING), очень удобно делать на автоматах.
Регулярные выражения под капотом имеют автомат, да и вообще лексеры и парсеры делают на конечных автоматах.
В геймдев-анимации автоматами описывают переходы между состояниями «юнит бежит», «юнит в прыжке», «юнит танцует»
Так же в геймдеве можно описывать логику ИИ с помощью автоматов.
Это только то, с чем я лично работал или сталкивался. На деле же, думаю, применение автоматов шире.
Ну вот я и считал так diff(«Python», «Perl») == «ython» (5 букв)
Эм, нет, проблема заключается в неуместном применении инструментов, что с любым инструментом ведет к беде. Вообще с любым. У некоторых инструментов есть очень узкое но эффективное применение, и когда его делают золотым молотком, инструмент превращается в антипаттерн. Если вы предлагаете такие инструменты в принципе убирать, то можете их не использовать, а другим не мешайте. Я генераторы использую редко, но эффективно, где они действительно упрощают понимание алгоритма.
Вообще, все ваши кейсы с генераторами касаются проблем чего угодно, только не генераторов, но ваше рвение впечатляет.