Здравствуйте, AlexGin, Вы писали:

I>>А зачем? Твои юзеры сидят на этом линуксе?
AG>+100500
AG>Да, бывает и такое — что люди ставят условие — работа на OS Linux.
AG>Отмечу, что я занимаюсь в основном техническими и расчётными приложениями на C++

Какая доля луноходов в общей массе?

I>>Точнее — ничего. Кросс-платформенный фремворк избавит тебя от написания процентов 80% платформенно-зависимого кода.
I>>Это окупится только в том случае, если юзеры требуют разных платформ. В противном случае это будет медленнее — нативная разработка под конкретную платформу будет быстрее.
AG>Нативная то идёт быстрее, но это если перед тобой — прямая дорога. Проторенная тысячами путников.

Именно! Но судя по тому, что ниже, ты не понимаешь экономику кроссплатформенного проекта.
Экономишь время исключительно за счет:
1 бизнес-логики — никаких сложностей нет, т.к. от платформы не зависит.
2 базовых функций нативных платформ, типа открыть-прочитать файл

Исключительно эта часть у тебя будет в одном экземпляре. Всё остальное — по числу платформ.

AG>Если будет шаг влево/вправо — то придется искать обходные пути (и зачастую довольно длинные)

Именно это тебя ждет и в кроссплатформенной версии.
Например, ты выяснил, что тебе нужен X, который в Маке иначе как стоя раком не запустишь.
Ты наверное ждешь, что кроссплатформенный фремворк весь из себя идеальный, и в ём магическим образом сделали X
А всё совсем не так — этот X скорее всего вообще поддерживаться не будет, вообще нигде. И тебе придется писать его везде самому.
Гы-гы.
Вот пример — писали прогу на 4 платформы. Использовали сторадж, который работал везде хорошо, кроме одной из платформ.
Как побороть? Нативныйм кодом. А теперь выясняется, что этот же сторадж, кроме как раком завести не получается.
Что делать ? Нашли другую реализацию. Теперь дело за малым — во всех платформах реалализовать новый вариант.
Оказалось, что во всех платформах для нового движка структура АПИ отличается — файловое апи, стримы, база данных и хрен знает что.
Теперь кроме адаптации, надо написать слой, который дает универсальное АПИ, что бы BL была действительно кроссплатформенной.

Итого — по скромной оценке в 4 раза больше работы, чем для нативных вариантов. 3 раза сделали ненужную работу, 1 раз нужную + слой для кроссплатформенности. А в теории надо бы добавить недостающую платформу. Снова гы-гы.


I>>Кроссплатформенность это никакая не фича. Как только появится веб-решение, про твою кроссплатформенную рисовалку дружно забудут.
AG>
AG>В том стеке, на котором работаю я, веб-решения совсем не просматриваются как даже "хоть_какие" решения (sorry за каламбур).

Что это за стек такой?

Здравствуйте, AlexGin, Вы писали:

I>>А зачем? Твои юзеры сидят на этом линуксе?
AG>+100500
AG>Да, бывает и такое — что люди ставят условие — работа на OS Linux.
AG>Отмечу, что я занимаюсь в основном техническими и расчётными приложениями на C++

Какая доля луноходов в общей массе?

I>>Точнее — ничего. Кросс-платформенный фремворк избавит тебя от написания процентов 80% платформенно-зависимого кода.
I>>Это окупится только в том случае, если юзеры требуют разных платформ. В противном случае это будет медленнее — нативная разработка под конкретную платформу будет быстрее.
AG>Нативная то идёт быстрее, но это если перед тобой — прямая дорога. Проторенная тысячами путников.

Именно! Но судя по тому, что ниже, ты не понимаешь экономику кроссплатформенного проекта.
Экономишь время исключительно за счет:
1 бизнес-логики — никаких сложностей нет, т.к. от платформы не зависит.
2 базовых функций нативных платформ, типа открыть-прочитать файл

Исключительно эта часть у тебя будет в одном экземпляре. Всё остальное — по числу платформ и это в лучшем случае, т.к. могут быть нюансы, по нескольку версий в зависимости от возможностей какого нибудь иос.

AG>Если будет шаг влево/вправо — то придется искать обходные пути (и зачастую довольно длинные)

Именно это тебя ждет и в кроссплатформенной версии.
Например, ты выяснил, что тебе нужен X, который в Маке иначе как стоя раком не запустишь.
Ты наверное ждешь, что кроссплатформенный фремворк весь из себя идеальный, и в ём магическим образом сделали X
А всё совсем не так — этот X скорее всего вообще поддерживаться не будет, вообще нигде. И тебе придется писать его везде самому.
Гы-гы.
Вот пример — писали прогу на 4 платформы. Использовали сторадж, который работал везде хорошо, кроме одной из платформ.
Как побороть? Нативныйм кодом. А теперь выясняется, что этот же сторадж, кроме как раком завести не получается.
Что делать ? Нашли другую реализацию. Теперь дело за малым — во всех платформах реалализовать новый вариант.
Оказалось, что во всех платформах для нового движка структура АПИ отличается — файловое апи, стримы, база данных и хрен знает что.
Теперь кроме адаптации, надо написать слой, который дает универсальное АПИ, что бы BL была действительно кроссплатформенной.

Итого — по скромной оценке в 4 раза больше работы, чем для нативных вариантов. 3 раза сделали ненужную работу, 1 раз нужную + слой для кроссплатформенности. А в теории надо бы добавить недостающую платформу. Снова гы-гы.


I>>Кроссплатформенность это никакая не фича. Как только появится веб-решение, про твою кроссплатформенную рисовалку дружно забудут.
AG>
AG>В том стеке, на котором работаю я, веб-решения совсем не просматриваются как даже "хоть_какие" решения (sorry за каламбур).

Что это за стек такой?