Здравствуйте, Pzz, Вы писали:
Pzz>Но в общем, готового out of box и без геморроя решения, похоже, нет. Присутствующие на форуме шароварщики могут при желании этим заняться.
Здравствуйте, Kolesiki, Вы писали:
Pzz>>Практический интерес представляет другая задача: писать под андроид и макакос, чтобы из одного кода под обе системы получалось
K>Интерес как раз сугубо мечтательско-теоретический. На практике "один код для двух платформ" — маниловщина.
Здравствуйте, Quadri, Вы писали:
Q>Кстати, вот недавно объявили кроссплатформенную (пока десктоп и андроид) UI библиотеки: Jetpack Compose Desktop на Kotlin подробнее https://habr.com/ru/post/527586/
Ну интереснее, конечно, андроид и иос. Полагаю граждане, занимающиеся программами для мобильных устройств, изрядно подзадолбались параллельно две версии таких програм вести.
Андроид/дектоп менее интересно. Под дектоп, все же, пользовательский интерфейс сильно по-другому строится, чем под телефон.
Здравствуйте, Qbit86, Вы писали:
Q>Здравствуйте, Serginio1, Вы писали:
S>>Кстати а, что в котлине интереснее по сравнению с C#9 ?
Q>Там есть много хороших фич, конечно, и я назову не главные. Но меня прёт от синтаксиса лямбд для некоторых частых частных случаев.
Q>
Q>it: implicit name of a single parameter
Q>It's very common that a lambda expression has only one parameter.
Q>If the compiler can figure the signature out itself, it is allowed not to declare the only parameter and omit ->. The parameter will be implicitly declared under the name it:
Q>
Q>ints.filter { it > 0 } // this literal is of type '(it: Int) -> Boolean'
Q>
Q>Passing trailing lambdas
Q>In Kotlin, there is a convention: if the last parameter of a function is a function, then a lambda expression passed as the corresponding argument can be placed outside the parentheses:
Q>
Q>val product = items.fold(1) { acc, e -> acc * e }
Q>
Q>Such syntax is also known as trailing lambda.
Q>If the lambda is the only argument to that call, the parentheses can be omitted entirely:
Q>
Здравствуйте, Pzz, Вы писали:
Pzz>Можно притащить с собой какой-нибудь Qt, весить, правда, будет не сильно меньше, чем если притащить с собой броузер.
Насколько я понимаю, это потому, что Qt поддерживает все в одном флаконе, и никак иначе. Его разработчики принципиально не делают так, чтобы можно было подключать только необходимую функциональность, без излишеств? Или делают, но всем лень выбирать, и суют в дистрибутивы стандартные полнофункциональные оболочки?
Здравствуйте, Евгений Музыченко, Вы писали:
Pzz>>Можно притащить с собой какой-нибудь Qt, весить, правда, будет не сильно меньше, чем если притащить с собой броузер.
ЕМ>Насколько я понимаю, это потому, что Qt поддерживает все в одном флаконе, и никак иначе. Его разработчики принципиально не делают так, чтобы можно было подключать только необходимую функциональность, без излишеств? Или делают, но всем лень выбирать, и суют в дистрибутивы стандартные полнофункциональные оболочки?
С мобильным Qt я дела не имел, а дектопный вендовый/линуховый разрезан на какое-то количество DLL-ек, так что теоретически можно притаскивать только нужные (или слинковаться статически, если более традиционных форм секса в жизни не хватает).
Но там все на все завязано, так что если даже лишнего (не используемого) не тащить, все равно много чего притащится.
Fire and Water are our state of the art development environments for programmers using the Elements compiler on the Mac and on Windows, respectively.
— https://docs.elementscompiler.com/Fire/
Чуваки пилят компилятор своего диалекта C# и — внимание — свои IDE. State of the art, ага.
Здравствуйте, Qbit86, Вы писали:
Q> Чуваки пилят компилятор своего диалекта C#
На счет собственного диалекта:
The RemObjects C# compiler will evolve as the official C# language evolves, but our goal is not to drive the C# language forward (and diverge from the standard) ourselves, but rather to provide a compiler and language for .NET, Cocoa and Java that will feel like "true C#" to everyone familiar with the language.
That said, RemObjects C# does adds a few features to the standard C# language to make it fit better on all the platforms it supports. These are covered under Language Extensions.
Не такой уж он и собственный. Platform specific расширениями пользоваться никто не заставляет.
Q> и — внимание — свои IDE. State of the art, ага.
Здравствуйте, Kolesiki, Вы писали:
K>]Я — проф.разработчик K> мой главный и единственный язык — C#. Он же и "язык мышления".
Противоречие detected.
K> Прыгать с языка на язык я мог себе позволить в бестолковом студенчестве, да и то требовалась "перестройка сознания". Сейчас, когда в "рабочем сознании" я "сишарплю", у меня просто нет возможности и желания ещё и продираться сквозь дебри мусора от второго языка: "А можно ли завести виртуальный статический метод?".
Возможности есть — желания нет.
K>Сейчас язык — один и я знаю практически все ответы на любой архитектурный вопрос. Ломать голову на два языка — увы, непозволительная для профессионала роскошь.
У меня в коробке с шуруповёртом лежат биты Pz, Ph, простые и с ограничителем для гипрока, обычные шлицевые, Torx-звёздочки, на внутренний и внешний шестигранник в ассортименте, конусное сверло, всякие шарошки... И это не говоря уж про угловую башку и несколько удлиннителей биты разного калибра. Потому что надо. Ходить с одной отвёрткой и быть "Senior Pz Screwdriver" — увы, непозволительная для профессионала роскошь.
K>"Изучать язык" — это не методичку лектору пересказать! Это долгий, глубокий процесс, изучение ньюансов, отличий от "ООП-классики", всякие сахарки и приколы.
Само собой. Но это не повод отказаться.
K>Если выбирать язык, то один и "пока смерть не разлучит вас".
Эти споры были актуальны у нас "во студенчестве". В итоге, изучив в универе Паскаль и Си, я вышел на первую работу по FoxPro, проведя перед этим несколько дней с книгой по языку. Интернета тогда ещё не было.
K>Да у меня самые "фичастые" WPF-ки (где много декларашек перелопачивается в C# код) канпеляются от силы секунд 5! Как так-то??
Значит, они маленькие. MVVM с бихейворами, конвертерами и прочей требухой в пять секунд уже не уложится.
K> И дело не в котлине — с жабой ровно та же тормозня.
Так Котлин — это перелицованная жаба и есть. Возможно, когда-то JetBrains смогут выделить это как самодостаточный язык, но пока что имеем что имеем.
K>Сюда же "организованная гиперпомойка исходников", из которой состоит ЛЮБОЙ проект для Ведроида. 8 каталогов для простейшего приложения? Серьёзно??
То ли дело у нас в шарпе, связка проектов — модели, сервисы, инфраструктура, везде папки для группировки по дочерним namespace...
K>Ведроид — это живой труп, могила здравого смысла — самое безобразное, что можно было придумать для простейших "мобилок".
На Windows Phone тоже не без приколов — пришлось хлебнуть полную лопату. А уж про свой опыт Симбиан — давайте не буду вспоминать
Здравствуйте, Qbit86, Вы писали:
Q> R>Не такой уж он и собственный.
Q> Как выглядит работа со структурами в таком C# на JVM (Dalvik, ART), которая значимые типы не поддерживает AFAIK?
Здравствуйте, Kolesiki, Вы писали:
K>Причём тут экран?? Неужели со всего поста непонятна главная задача: писать под ведроид, но на C#? Тут вообще никакой речи про совместимость. Просто считай ты вчера родился, а сегодня захотел написать ведроид-приложение, а в школе ты изучал C#.
Ява после Шарпа осваевается с пол пинга. Имел недавно опыт. Хватило пары недель в процессе работы над проектом. Но до этого как раз на Кзамарине где-то пол года под Ведроид по-программировал.
У Кзамарина, кстати, есть неоспаримые преимущества, когда речь идет о разработке ГУЯ. Все же MVVM рулит. Андроид сильно отстает в этом плане. Плюс у Кзамарина переносимость гуя на iOs.
К сожалению, АПИ телефонов очень разные и Кзамарин тут ничего не может предложить в принципе. Но если приложение — это в основном ГУЙ, то Кзамарин рулит и идея топикостартера не такая уж глупая, потому как в Кзамарие действительно самый гнилой момент — это его VM.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Kolesiki, Вы писали:
K>Следующий этап — "WPF на мобильный лад": делаем декларативную ГУЙню, которая 1:1 мэпится в контролы Ведроида (даже с теми же именами). Синтаксис будет XAML'овый. Опять же, невелика работа — сконвертировать теги в контролы мобилы и инициализировать свойства.
Только в этом и есть смысл. Кзамарин зря использует промежеточную VM. Действительно было бы лучше не ставить свою ВМ, а конвертить код в Яву и андройдные примитивы. Но ты недооцениваешь сложности задачи. Задача не простая. Но решаемая.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, kov_serg, Вы писали:
_>Просто попробуйте писать под ведро на kotlin и вы на C# будете смотреть иначе.
Не будете. В Кзамарине важен не даже не сам Шарп, хотя и он на сегодня более продвинуты чем Котлин, а MVVM. А этого в Ведройде нет в принципе. Там довольно убогий АПИ в базе.
Ну, и кайф Кзамарина в том, что он позволяет писать ГУЙ не только для Ведройда, но и для iOs. А это дорогого стоит.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Qbit86, Вы писали:
Q>Здравствуйте, Serginio1, Вы писали:
S>> А чем это лучше Linq? Там еще есть и IQuriable на Expression Tree
Q>Я вообще не про Linq, при чём здесь Linq? Это про синтаксис лямбд.
Ну синтаксис содран с TypeScript
в C# есть куча Func<T,...T64> и Action это по моему проще.
Единственно что проблемы с var и out параметрами приходится писать через delegate
Кстати в примерах нет лямбд с out и var параметрами
и солнце б утром не вставало, когда бы не было меня
