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») и пойти по своим делам, занимая важный ресурс, и не имеет значение, функция это, генератор или объект. Очевидно потому, что дело не в генераторах. Предоставляя кому-то тяжелые ресурсы, вы должны хотя бы в докстринге написать «Обережно! Не занимайте долго ресурс». Если программист бесконтрольно открывает (на любом языке) файлы, сокеты, пайпы и не закрывает их, виноваты конечно же генераторы, а не то, что кто-то в этой цепочке дурачок.
Проблема заключается не в сопрограммах, а в том, что совместное выполнение алгоритмов резко повышает сложность их написания и понимания, как человеком, так и машиной.
Эм, нет, проблема заключается в неуместном применении инструментов, что с любым инструментом ведет к беде. Вообще с любым. У некоторых инструментов есть очень узкое но эффективное применение, и когда его делают золотым молотком, инструмент превращается в антипаттерн. Если вы предлагаете такие инструменты в принципе убирать, то можете их не использовать, а другим не мешайте. Я генераторы использую редко, но эффективно, где они действительно упрощают понимание алгоритма.
Вообще, все ваши кейсы с генераторами касаются проблем чего угодно, только не генераторов, но ваше рвение впечатляет.
Безусловно. Только системы типов бывают разные, и более сильные позволяют выражать больше вещей на уровне типов, и сводить больше вещей к проверкам типов.
Тут не могу не согласиться. Но факторов много, и сложно их всех объективно проанализировать.
А можно примеры каких-то деталей языков программирования, по которым существует мировой консенсус?
Так вот я о том и толкую. Если бы существовали какие-то серебряные пули по большинству вопросов, не было бы в мире столько языков.
Мне конечно на ум приходит «goto это плохо», но даже тут я не уверен, что консенсус достигнут, хоть перевес и очевиден. Кроме того, если рассматривать этот вопрос с точки зрения сферы применения, то я думаю для разных языков и разных людей goto в разной степени уместен или неуместен.
Если взять мое мнение, то я считаю статическую типизацию более правильной. Кроме того, я с нее начинал. Но так вышло, что на практике даже в динамическом языке я редко сталкиваюсь с проблемами типизации, и получается, что статическая типизация будет только вносить в мою работу дополнительные ограничения и бойлерплейт, ограждая меня от ошибок, которые я допускаю весьма редко, и которые до продакшена обычно не доходят. Плюс возможно влияет сфера деятельности.
Поэтому моя любовь к статической типизации плавно перетекла в платоническую.
По этой причине порядочный создатель движка должен придумать свой скриптовый язык, как Bethesda сделала свой Papyrus, как Blizzard свою модификацию Lua со строгой типизацией.
Может в Lua от Blizzard типизация и строгая (я не проверял), но точно динамическая. Ну и в питоне в принципе тоже: строгая и динамическая.
Lua любят не за типизацию, а за простое и эффективное встраивание. Если бы питоновская виртуальная машина могла потягаться с Lua, то скорее всего везде бы пихали питон.
У PHP не было классов вообще: ни динамических, ни статических — и, тем не менее, он был популярнее питона. Как так?
Могу поделиться сокральной тайной. Язык программирования любят/ненавидят не за один-два критерия, а за совокупность и согласованность целого множества критериев разного веса и за их комбинации.
Иначе получится картина:
— Алёша, за что ты любишь Машу?
— У нее платье красивое
Из-за кэмелкейса в вашем нике, создается ложное впечатление, что Бог важнее путина
[/оффтоп]
извините
Слишком громкая фраза.
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 букв)
Эм, нет, проблема заключается в неуместном применении инструментов, что с любым инструментом ведет к беде. Вообще с любым. У некоторых инструментов есть очень узкое но эффективное применение, и когда его делают золотым молотком, инструмент превращается в антипаттерн. Если вы предлагаете такие инструменты в принципе убирать, то можете их не использовать, а другим не мешайте. Я генераторы использую редко, но эффективно, где они действительно упрощают понимание алгоритма.
Вообще, все ваши кейсы с генераторами касаются проблем чего угодно, только не генераторов, но ваше рвение впечатляет.
Тут не могу не согласиться. Но факторов много, и сложно их всех объективно проанализировать.
Мне конечно на ум приходит «goto это плохо», но даже тут я не уверен, что консенсус достигнут, хоть перевес и очевиден. Кроме того, если рассматривать этот вопрос с точки зрения сферы применения, то я думаю для разных языков и разных людей goto в разной степени уместен или неуместен.
Если взять мое мнение, то я считаю статическую типизацию более правильной. Кроме того, я с нее начинал. Но так вышло, что на практике даже в динамическом языке я редко сталкиваюсь с проблемами типизации, и получается, что статическая типизация будет только вносить в мою работу дополнительные ограничения и бойлерплейт, ограждая меня от ошибок, которые я допускаю весьма редко, и которые до продакшена обычно не доходят. Плюс возможно влияет сфера деятельности.
Поэтому моя любовь к статической типизации плавно перетекла в платоническую.
Может в Lua от Blizzard типизация и строгая (я не проверял), но точно динамическая. Ну и в питоне в принципе тоже: строгая и динамическая.
Lua любят не за типизацию, а за простое и эффективное встраивание. Если бы питоновская виртуальная машина могла потягаться с Lua, то скорее всего везде бы пихали питон.
Иначе получится картина:
— Алёша, за что ты любишь Машу?
— У нее платье красивое