Какие ЯП потребляют меньше всего ресурсов при разработке?

Автор питон с бейсиком перепутал.

FreeBasic, например, компилируемый и это ты, похоже, ошибаешься :)

Нет. Он же пишет «process is REPEATED for every line of the program EVERY time it is executed». Т.е. в первый раз он, конечно, будет много и сильно парсить, но все последующие запуски будут быстрее и проще.

Разве питон это не делает перед этим самым «компилированием»?)

Перед компилированием и Си это делает.

Но компилирование != выполнение, а bytecode compiling не равно компилированию сишного кода в двоичный. Ну ты это и сам знаешь.

Это не делает его таким же быстрым как компилируемый. Это же просто как бы кэш.

Но компилирование != выполнение

Так я про это и пишу. Питон не выполняет компиляцию при каждом выполнении, а только при изменении исходника.

а bytecode compiling не равно компилированию сишного кода в двоичный

Выполнение байткода медленнее, чем выполнение двоичного кода, но значительно быстрее, чем «check that each statement makes sense according to the rules of the Python language, allocate memory for storage of the variables, strain out program comments and blank spaces, and many other tasks».

А компиляция в двоичный код или в байткод существенно не отличается. В обоих случаях алгоритм почти идентичен.

picolisp

какой ПК подойдет

Raspberry Pi, >=386

все что ли не читаете ТС внимательно?

Таки да, ты прав оба раза.

Ага, щас, а бывает и так

У Lua есть luarocks - чем вам не куча библиотек

Я бы мог освоить Lua, но зачем мне изучать еще один скриптовый? К моей задаче он не подходит (Движок позволяет писать код либо на питоне, либо на крестах).

У питона их тоже много, а с ним я уже относительно знаком.

Для асинхрона как раз прекрасно подходит, скорость тут не важна. Но не суть.

Лёгкий рефакторинг — враньё, он априори не возможен в языках с динамикой.

Лёгкий рефакторинг — враньё, он априори не возможен в языках с динамикой.

Я не согласен. В языках со статической типизацией и «ручным» управлением памятью дебаг будет намного труднее. В динамических с этим проще, даже легче т.к. большинством абстракций управляет интерпретатор, а программист не заботится о типах и выделении памяти.

Мне кажется, ты просто не умеешь работать с языком динамической типизации.

При чём здесь рефакторинг-то?

Десять лет работаю и всё не умею, печаль.

Тот, кто привык к сишке, будет тупить в питоне, и наоборот

Вот я еще только читаю по С++, а уже уверен, что игровой код (логику) на нём мне будет очень больно писать после питона.

Количество времени тут вообще не показатель, лол. Из той же «оперы» что и возраст.

Лёгкий рефакторинг — враньё, он априори не возможен в языках с динамикой

Тесты писать не пробовал? %)

Количество времени выражается в количестве написанного кода и проектов.

Ответ на самом деле прост, ты не понимаешь, что такое рефакторинг.

Непосредственно сам рефакторинг тесты не облегчают. А вот автоматические инструменты очень даже.

Мимо кассы вообще, параллельные вещи.

Forth, наверное.

Ответ на самом деле прост, ты не понимаешь, что такое рефакторинг.

И что же это такое?)

Рефакторинг – это обычная правка кода, завуалированная под некое умное слово.

Очень даже причем. В том же С++ он будет сложнее в виду строгости самого языка.

Строгий в смысле требовательный к программисту, вынуждающий освоить большее количество норм, понятий и абстракций.

Рефакторинг – это обычная правка кода, завуалированная под некое умное слово.

Некоторые западные мудрецы, да удлинятся бесконечно их бороды, говорят, что это изменение структуры кода без изменения поведения.

За этим, собственно, и нужны тесты — чтобы иметь возможность в любой момент убедиться, что поведение на самом деле не изменилось. Потому что именно это — нужное поведение — нас интересует в первую очередь.

А средства, облегчающие конкретные изменения структуры — в лучшем случае во вторую. Потомушо основные усилия все равно уйдут не на топтание клавы, а на продумывание этой самой структуры.

Некоторые западные мудрецы, да удлинятся бесконечно их бороды, говорят, что это изменение структуры кода без изменения поведения.

Это и есть обычная правка. Ведь, в любом случае, я изменяю содержимое метода без изменения его поведения (т.е. он вернет те же (прежние) данные, но его структура и способ обработки этих данных будут другими).

На самом деле не факт, где-то убудет, а где-то прибудет, так например если делать две одинаковые игры(на разных языках), то написание логики и на плюсах возможно будет дольше, но зато будет экономия на этапе оптимизации, отладка по иронии в среднем будет одинаковая, т.к. отладка больше опирается на опыт разработчика, язык тут второстепенен

За этим, собственно, и нужны тесты — чтобы иметь возможность в любой момент убедиться, что поведение на самом деле не изменилось. Потому что именно это — нужное поведение — нас интересует в первую очередь.

Это вопрос человеческой лени и размеров проекта. Если это хобби-проект, то врядли кто-то заморачивается написанием тестов, которые тоже надо проверять на корректность.

Это и есть обычная правка.

Обычная правка может менять и поведение тоже. Впрочем, тесты все равно нужны — иначе как ты узнаешь, что твоя новая фича действительно работает? А также убедишься, что она случайно не перестала работать в результате дальнейших изменений (будь то рефакторинг™ или другая обычная правка)?

например если делать две одинаковые игры(на разных языках), то написание логики и на плюсах возможно будет дольше

Возможно. Но в случае с C++, можно опираться на опыт и ошибки, полученные в процессе написания логики на питоне.

Если это хобби-проект, то врядли кто-то заморачивается написанием тестов

Если это ПО уровня write and forget — возможно. Если же его нужно постоянно изменять и дорабатывать, да еще и не в одно лицо…

иначе как ты узнаешь, что твоя новая фича действительно работает?

Обычно проверяю запуском игры из IDE (и проверкой всего что изменил/добавил за последний раз) либо детально с помощью pdb в нём же.

У меня юзкейс другой и намного проще.

Покрывать всю игровую логику тестами (в одиночку)… Это потеря времени, имхо.

Обычно проверяю запуском

То есть все равно тестируешь, только вручную. А значит, редко, медленно и с никакущим покрытием.

Да, ибо: Какие ЯП потребляют меньше всего ресурсов при разработке? (комментарий)

Покрывать всю игровую логику тестами (в одиночку)… Это потеря времени, имхо.

Отчего-то вспомнилась поговорка про дурака и стеклянный хер.

Мне писать логику, создавать ассеты, писать шейдеры и возможно даже музыку, настраивать рендер. А ты тут еще тесты предлагаешь создавать :)

Ты либо сверхзадрот, если клепаешь тесты к простыне кода, либо только в вебне занят, бгг.

Тесты – это тоже код и могут выполняться неправильно :) Так уж лучше мне отладить код вручную, так даже надежнее, хотя и дольше.

И ещё, если бы я изменил что-то в своем методе, то мне пришлось бы ещё и тест для этого метода править, пусть хоть в этом тесте всего пару строк. А если изменений будет много, только и успевай тесты под свой код править, бгг.

если бы я изменил что-то в своем методе, то мне пришлось бы ещё и тест для этого метода править

Ты же не просто так начал его править — ты хочешь, чтобы метод делал что-то такое, чего раньше не делал. Поэтому нужно сначала написать еще один тест, проверяющий это новое поведение, а потом уже писать код, пока тест не станет проходить.

Тесты, которые проверяют поведение, которого больше нет, нужно выкинуть.

С рефакторингом еще проще — тесты трогать вообще не нужно.

Я прекрасно понемаю, что это все лень, недосуг и непривычно. Что тут скажешь — нужно привыкать! %)

Ты на Java в качестве эталона смотри, а не на плюсы. Разница с Питоном радикальная. Благодаря статике и вылизанным инструментам, ты всегда знаешь, что влечёт за собой любое изменение.

Врядли в этом методе нужны какие-то тесты, всё уже достаточно проверяется.

Можно же в самом коде проверки делать, да побольше. Или взрослые питонисты таким не занимаются?)

Обычная да необычная, если ты древнее упоротое легаси правишь.

Вот я тебе и говорю, что ты не заешь (в переносном смысле слова, конечно) что такое рефакторинг. Ты просто не прошел путь граблей и не почувствовал это на своей шкуре.

Поэтому нужно сначала написать еще один тест, проверяющий это новое поведение, а потом уже писать код, пока тест не станет проходить.

Тесты, которые проверяют поведение, которого больше нет, нужно выкинуть.

Значит количество тестов равно количество измененного поведения. А поведение обязательно изменится. И каждое написание теста потребует некоторое время.

Потомушо основные усилия все равно уйдут не на топтание клавы

Зато на отладку легко могут утечь реки времени. Задолбаешься правка за правкой тесты запускать, если в тупую, либо вычитывать, если по-хорошему, что впрочем никто не делает. В джаве ты заранее про большую часть косяков узнаешь не потратив ни мыслетоплива, ни времени.

Можно же в самом коде проверки делать, да побольше

Люблю посреди игры полюбоваться на AssertionError, ага. Или что там у вас в петонах на этот случай предусмотрено.