Тут сорян. В мои задачи не входило рекламировать F# среди неинфицированных. Данный цикл для тех, кто ощущает личную предрасположенность к F#, но сталкивается с трудностями в виде необходимости откатываться к более "классическим" подходам из-за неопытности и/или неверно заданных максим. В некотором смысле это реакция на вал повторяющихся в F# Weekly текстов, которые раздают одни и те же советы и игнорируют одни и те же проблемы.
Что касается моего личного выбора, то он продиктован хорошим знанием языка и навыками, которые позволяют скомпенсировать любые недостатки интеграции с движком. Плюс я знаю, где раздобыть или подготовить людей с необходимыми мне компетенциями, так что проблем с масштабированием у меня не будет.
Что касается интеграции C#+F#, то она, что называется, "зависит". Что-то хавается бесшовно, что-то надо подкручивать. Тут надо смотреть конкретные случаи, но в целом я предпочитаю вовсе не использовать C#-проекты (не либы) в солюшене, так как в большинстве случаев они работают тормозом для всего солюшена. В Godot это формально невозможно, но на практике за C#-ом остаётся всего несколько единоразово добавляемых файлов. Я б сделал из них библиотеку, если бы до конца понимал механизм подхвата Godot, но сейчас мне проще закинуть пачку файлов руками.
По вакансиям ничего не скажу. Я как-то пришёл к выводу, что лучше всего наниматься к конкретному проверенному инженеру, иначе высок риск наткнуться на тотальный невменоз, а это предполагает несколько иной подход к поиску проектов. Плюс здесь идёт речь про геймдев, причём исключительно индигеймдев, так что я ориентируюсь на людей, которые пилят (ну или запилят в будущем) что-то своё.
Большинство их них оказываются перед угрозой не вывезти свой проект из-за его объёмов, и здесь F# может помочь за счёт большей скорости и меньшего количества архаики. За это придётся заплатить на старте, но есть люди, которые любят и (главное) умеют играть в долгую. Сим текстом я пытался им помочь.
---
Будет глава с подзаголовком "С# не нужен" (скорее всего №10), попробую заглянуть тогда. Если я ничего не перекину на потом, к тому моменту станет ясно, в каком ключе я веду разработку на Godot, и ты быть может поймёшь "зачем F#".
Ну и в целом, можешь с техническими вопросами в тележную личку писать. Пока что через Хабр идиотов ко мне не приходило будьте первыми!, так что я пусть и не сразу, но с интересом гляну, с чем возникли проблемы.
Да в целом норм. Если нет задачи интеропиться именно с API андроида, то разницы почти никакой. Отработал на компе, собрал, закинул на андроид, потыкал, быть может сделал пару поправок на другой экран и управление, идёшь дальше.
Правда, у мя нет и в ближайшее время не будет массовых приложений, так что я могу себе позволить не доделывать некоторые фичи. Я их просто не ковырял, но ввиду того, что движок не даёт доступа к Android-проекту, подводные камни определённо должны быть.
Я не думаю, что проблема в кодировке происходит от оси. Latin1 - не дефолтная. Автор пакета сохранил на неё указатель, так что скорее всего переключение было сознательным. Предположу, что он упёрся в корнер кейс при разборе консольного вывода и обошёл его данным хаком. То есть ситуация аналогично тому, как девопсы лочат локаль на en, чтобы не парсить сообщения об ошибках на других языках. Ход грязный, но достаточно надёжный.
Добавить могу лишь то, что в абстрактной ситуации между скриптами на ОС и на F#, я выберу F#, ибо последний является моим основным инструментом. Весь свой девопс (отличный от готовых задач из маркета) держу в .fsx. Потребностей перейти на что-то другое как-то не возникало.
Что касается специального софта. то в его сторону даже не смотрел. С областью не знаком, так что раскуривать её мне придётся дольше, чем я решил свою проблему.
Аргументация верная, но в скрипт я полез из-за того, что у меня бомбило от несовершенства софта. Кроме того флешку не так-то просто вынуть и физически, и программно (там приложения стоят). По хронометражу может и быстрее, но точно не удобнее.
Не, конфликт кодировок на содержимое файлов не распространяется. Так что если бы я шарил в adb больше, я бы может так и сделал. Однако я иначе представлял себе её назначение, поэтому даже не предполагал наличие такой команды.
К тому же я не знал точный путь к директории. Я был уверен, что меня ждёт отдельный диск D, а не подпапка. Благодаря SharpAdbClient и SyncService у меня была готовая структура данных, которой я мог оперировать в привычной мне манере, так что поиск не занял много времени.
Кроме того, структура папок моего фото-архива устроена сложнее, чем исходная папка на телефоне. На F# я могу легко написать предикат, который установит наличие копии в фото-архиве, но сделать это через консольный скрипт я сходу не смогу. Соответственно надо копировать либо всё, либо дёргать файлы по одному, а мне это проще делать через скрипт.
И наконец, мне надо было удалить файлы на телефоне, но не все. Некоторые моменты мне хотелось иметь и там, и там. Это подразумевает поштучное удаление, а в моём случае ещё и перенос файлов с внутреннего хранилища телефона на sd-карту.
Если бы я столкнулся с непреодолимым препятствием, я быть может допёр до adb pull, но всё удавалось слишком быстро и легко, чтобы я успел остановиться и подумать об альтернативах. Правда и сейчас я не вижу в этом смысла, так как мои скрипты проворачивают все необходимые мне операции с предельной точностью. Причём они могут делать это в автоматическом режиме, просто обнаруживая телефон в своей зоне действия.
Чистые функции хорошо взаимодействуют с пайпами, но всё же я акцентировал внимание на отсутствии шума от промежуточных переменных и т.п. Это разные плюшки, хоть они зачастую и идут пакетом. Существуют DSL, адаптированные под пайпы, где каждая строка обладает неслабым сайд-эффектом. В Godot без этого не обойтись из-за устройства API некоторых сервисов.
Да, функции тоже можно. Так работает кодоген по Swagger и т.п. Однако по моему опыту в F# на основе внешнего источника данных чаще генерируются структуры данных, а не функции. Для последних характерно использование рефлексии по существующим библиотекам, то есть источник данных скорее внутренний.
Лет 6-7 назад в C# уже был рослин, которые позволял ворочить AST непосредственно в VS. Я практически не пробовал вытаскивать его наружу, но не думаю, что это вызовит серьёзные сложности. Кроме того в C# есть сорсгены, но они обычно подразумевают более общие задачи без серьёзной кастомизации.
partial в неумелых руках может превратить проект в кашу, но в случае с Godot разрабы накидали своих фишек.
В Godot всё описывается через ноды, которые могут вкладываться друг в друга без ограничений, за счёт чего получаются очень раскидистые деревья. Это напоминает UI-фреймворки, но в качестве ноды может быть объект, который отвечает только за логику и вообще никак не взаимодействует с UI. У этих нод есть свойства и события, но они полностью не закрывают всех фич, часть из которых доступна только через переопределение методов. Проблема в том, что просто переопределить метод недостаточно, ещё важно сделать это в нужном месте проекта.
Для того, чтобы Godot узнал о override в типе, этот тип должен лежать в C#-проекте и быть partial. Если я просто закину анонимную ноду в глубине сцены:
{ new Node() with
override this._Process delta =
if Input.IsKeyPressed Key.Shift then
GD.print "Shift pressed!!!"
}
То Godot никогда не вызовет метод _Process, потому что будет считать, что он не был изменён. Я пока не понял, почему они сделали именно так, но проблему приходится решать через создание прослойки вида:
public partial class InCSharp : InFSharp
{
public override void _Process(double delta) => base._Process(delta);
}
На каждый тип вида:
type InFSharp () =
override this._Process delta =
()
Получается, что я:
Не могу избавиться от C#-проекта.
Вынужден дублировать все ключевые типы с переопределениями.
Вынужден создавать их через фабрики, так как вместо InFSharp() мне надо неявно вызвать InCSharp().
Кроме того есть проблемы с экспортируемыми свойстваи и сигналами, которые также надо протаскивать через C#.
Я постепенно закатываю весь этот шум в асфальт и уже явно вышел в плюс, но мне не понятно, зачем этот комплекс проблем вообще был создан. В 3 версии Godot такой проблемы не было.
В оригинале данное словосочетание также закавычено. Я уверен, что оно было применено в контексте ложного тезиса "dotnet = C#". Например указанный раздел документации находится в главе "Сборка и управление зависимостями функции на С#"..
У меня не сформировался условно стартовый пакет статей для ввода новичков в Hopac. Ибо это происходит всё реже, и мне с практической точки зрения проще показать несколько конкретных примеров из существующих репозиториев, чем отправлять человека за выработкой решения в интернет.
Документация из начала статьи хороша, но её желательно каким-то образом употребить сразу в больших количествах. В этом случае она приближается к идеалу.
Если нужен поэтапный ввод, то можно попробовать цикл на Demystify (https://www.demystifyfp.com/tags/hopac/). Сам я учился иначе и знаком с ним поверхностно, но знакомые находили его самостоятельно и пробовали что-то писать на основе него. Потом приходилось латать некоторые прорехи, но в целом внятное представление о Hopac цикл даёт.
Ещё есть попсовые (в хорошем смысле) доклады от Худайгулова (https://youtu.be/G1L5YdUm_gU и https://www.youtube.com/watch?v=cSOnmVqOwBs). Из первого я когда-то узнал о Hopac. Было это во времена синхронные записи доклада, и тогда меня всё это дело очень впечатлило. Однако полноценно писать на Hopac я начал лишь спустя полтора года. В первую очередь под давлением возрастающей сложности и объёмов бизнес-логики, а не пиара.
Тут сорян. В мои задачи не входило рекламировать F# среди неинфицированных. Данный цикл для тех, кто ощущает личную предрасположенность к F#, но сталкивается с трудностями в виде необходимости откатываться к более "классическим" подходам из-за неопытности и/или неверно заданных максим. В некотором смысле это реакция на вал повторяющихся в F# Weekly текстов, которые раздают одни и те же советы и игнорируют одни и те же проблемы.
Что касается моего личного выбора, то он продиктован хорошим знанием языка и навыками, которые позволяют скомпенсировать любые недостатки интеграции с движком. Плюс я знаю, где раздобыть или подготовить людей с необходимыми мне компетенциями, так что проблем с масштабированием у меня не будет.
Что касается интеграции C#+F#, то она, что называется, "зависит". Что-то хавается бесшовно, что-то надо подкручивать. Тут надо смотреть конкретные случаи, но в целом я предпочитаю вовсе не использовать C#-проекты (не либы) в солюшене, так как в большинстве случаев они работают тормозом для всего солюшена. В Godot это формально невозможно, но на практике за C#-ом остаётся всего несколько единоразово добавляемых файлов. Я б сделал из них библиотеку, если бы до конца понимал механизм подхвата Godot, но сейчас мне проще закинуть пачку файлов руками.
По вакансиям ничего не скажу. Я как-то пришёл к выводу, что лучше всего наниматься к конкретному проверенному инженеру, иначе высок риск наткнуться на тотальный невменоз, а это предполагает несколько иной подход к поиску проектов. Плюс здесь идёт речь про геймдев, причём исключительно индигеймдев, так что я ориентируюсь на людей, которые пилят (ну или запилят в будущем) что-то своё.
Большинство их них оказываются перед угрозой не вывезти свой проект из-за его объёмов, и здесь F# может помочь за счёт большей скорости и меньшего количества архаики. За это придётся заплатить на старте, но есть люди, которые любят и (главное) умеют играть в долгую. Сим текстом я пытался им помочь.
---
Будет глава с подзаголовком "С# не нужен" (скорее всего №10), попробую заглянуть тогда. Если я ничего не перекину на потом, к тому моменту станет ясно, в каком ключе я веду разработку на Godot, и ты быть может поймёшь "зачем F#".
Ну и в целом, можешь с техническими вопросами в тележную личку писать. Пока что через Хабр идиотов ко мне не приходило
будьте первыми!, так что я пусть и не сразу, но с интересом гляну, с чем возникли проблемы.Добавил.
Да в целом норм. Если нет задачи интеропиться именно с API андроида, то разницы почти никакой. Отработал на компе, собрал, закинул на андроид, потыкал, быть может сделал пару поправок на другой экран и управление, идёшь дальше.
Правда, у мя нет и в ближайшее время не будет массовых приложений, так что я могу себе позволить не доделывать некоторые фичи. Я их просто не ковырял, но ввиду того, что движок не даёт доступа к Android-проекту, подводные камни определённо должны быть.
Я не думаю, что проблема в кодировке происходит от оси.
Latin1- не дефолтная. Автор пакета сохранил на неё указатель, так что скорее всего переключение было сознательным. Предположу, что он упёрся в корнер кейс при разборе консольного вывода и обошёл его данным хаком. То есть ситуация аналогично тому, как девопсы лочат локаль наen, чтобы не парсить сообщения об ошибках на других языках. Ход грязный, но достаточно надёжный.// Промазал с ответом.
На похожий вопрос отвечал подробно выше https://habr.com/ru/companies/first/articles/865932/#comment_27667896
Добавить могу лишь то, что в абстрактной ситуации между скриптами на ОС и на F#, я выберу F#, ибо последний является моим основным инструментом. Весь свой девопс (отличный от готовых задач из маркета) держу в
.fsx. Потребностей перейти на что-то другое как-то не возникало.Что касается специального софта. то в его сторону даже не смотрел. С областью не знаком, так что раскуривать её мне придётся дольше, чем я решил свою проблему.
Аргументация верная, но в скрипт я полез из-за того, что у меня бомбило от несовершенства софта. Кроме того флешку не так-то просто вынуть и физически, и программно (там приложения стоят). По хронометражу может и быстрее, но точно не удобнее.
Не, конфликт кодировок на содержимое файлов не распространяется. Так что если бы я шарил в adb больше, я бы может так и сделал. Однако я иначе представлял себе её назначение, поэтому даже не предполагал наличие такой команды.
К тому же я не знал точный путь к директории. Я был уверен, что меня ждёт отдельный диск D, а не подпапка. Благодаря
SharpAdbClientиSyncServiceу меня была готовая структура данных, которой я мог оперировать в привычной мне манере, так что поиск не занял много времени.Кроме того, структура папок моего фото-архива устроена сложнее, чем исходная папка на телефоне. На F# я могу легко написать предикат, который установит наличие копии в фото-архиве, но сделать это через консольный скрипт я сходу не смогу. Соответственно надо копировать либо всё, либо дёргать файлы по одному, а мне это проще делать через скрипт.
И наконец, мне надо было удалить файлы на телефоне, но не все. Некоторые моменты мне хотелось иметь и там, и там. Это подразумевает поштучное удаление, а в моём случае ещё и перенос файлов с внутреннего хранилища телефона на sd-карту.
Если бы я столкнулся с непреодолимым препятствием, я быть может допёр до
adb pull, но всё удавалось слишком быстро и легко, чтобы я успел остановиться и подумать об альтернативах. Правда и сейчас я не вижу в этом смысла, так как мои скрипты проворачивают все необходимые мне операции с предельной точностью. Причём они могут делать это в автоматическом режиме, просто обнаруживая телефон в своей зоне действия.Чистые функции хорошо взаимодействуют с пайпами, но всё же я акцентировал внимание на отсутствии шума от промежуточных переменных и т.п. Это разные плюшки, хоть они зачастую и идут пакетом. Существуют DSL, адаптированные под пайпы, где каждая строка обладает неслабым сайд-эффектом. В Godot без этого не обойтись из-за устройства API некоторых сервисов.
Да, функции тоже можно. Так работает кодоген по Swagger и т.п. Однако по моему опыту в F# на основе внешнего источника данных чаще генерируются структуры данных, а не функции. Для последних характерно использование рефлексии по существующим библиотекам, то есть источник данных скорее внутренний.
Лет 6-7 назад в C# уже был рослин, которые позволял ворочить AST непосредственно в VS. Я практически не пробовал вытаскивать его наружу, но не думаю, что это вызовит серьёзные сложности. Кроме того в C# есть сорсгены, но они обычно подразумевают более общие задачи без серьёзной кастомизации.
partialв неумелых руках может превратить проект в кашу, но в случае с Godot разрабы накидали своих фишек.В Godot всё описывается через ноды, которые могут вкладываться друг в друга без ограничений, за счёт чего получаются очень раскидистые деревья. Это напоминает UI-фреймворки, но в качестве ноды может быть объект, который отвечает только за логику и вообще никак не взаимодействует с UI. У этих нод есть свойства и события, но они полностью не закрывают всех фич, часть из которых доступна только через переопределение методов. Проблема в том, что просто переопределить метод недостаточно, ещё важно сделать это в нужном месте проекта.
Для того, чтобы Godot узнал о
overrideв типе, этот тип должен лежать в C#-проекте и бытьpartial. Если я просто закину анонимную ноду в глубине сцены:То Godot никогда не вызовет метод
_Process, потому что будет считать, что он не был изменён. Я пока не понял, почему они сделали именно так, но проблему приходится решать через создание прослойки вида:На каждый тип вида:
Получается, что я:
Не могу избавиться от C#-проекта.
Вынужден дублировать все ключевые типы с переопределениями.
Вынужден создавать их через фабрики, так как вместо
InFSharp()мне надо неявно вызватьInCSharp().Кроме того есть проблемы с экспортируемыми свойстваи и сигналами, которые также надо протаскивать через C#.
Я постепенно закатываю весь этот шум в асфальт и уже явно вышел в плюс, но мне не понятно, зачем этот комплекс проблем вообще был создан. В 3 версии Godot такой проблемы не было.
В оригинале данное словосочетание также закавычено. Я уверен, что оно было применено в контексте ложного тезиса "dotnet = C#". Например указанный раздел документации находится в главе "Сборка и управление зависимостями функции на С#"..
У меня не сформировался условно стартовый пакет статей для ввода новичков в
Hopac. Ибо это происходит всё реже, и мне с практической точки зрения проще показать несколько конкретных примеров из существующих репозиториев, чем отправлять человека за выработкой решения в интернет.Документация из начала статьи хороша, но её желательно каким-то образом употребить сразу в больших количествах. В этом случае она приближается к идеалу.
Если нужен поэтапный ввод, то можно попробовать цикл на Demystify (https://www.demystifyfp.com/tags/hopac/). Сам я учился иначе и знаком с ним поверхностно, но знакомые находили его самостоятельно и пробовали что-то писать на основе него. Потом приходилось латать некоторые прорехи, но в целом внятное представление о
Hopacцикл даёт.Ещё есть попсовые (в хорошем смысле) доклады от Худайгулова (https://youtu.be/G1L5YdUm_gU и https://www.youtube.com/watch?v=cSOnmVqOwBs). Из первого я когда-то узнал о
Hopac. Было это во времена синхронные записи доклада, и тогда меня всё это дело очень впечатлило. Однако полноценно писать наHopacя начал лишь спустя полтора года. В первую очередь под давлением возрастающей сложности и объёмов бизнес-логики, а не пиара.