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

MR>У меня есть отличный пример того, как тормозное говнище может получиться независимо от выбранной технологии при почти одинаковых вводных. Под винду есть магазины-запускаторы игр от компаний Activision Blizzard и Electronic Arts — battle.net и origin. Обе они написаны с использованием Qt. Первый прекрасно работает и вообще не тормозит, второй — почти неюзабилное говно, проще сразу на сайт идти.

Правильный выбор технологии — условие необходимое, но не достаточное. Вот смотрите — собрал я проект AvaloniaApplication пустой без кода — уже весит 66 Мб. Как-то многовато, имхо. Если при прочих равных прога конкурента будет весить 2 Мб. и запускаться быстрее — то будут любить ее.

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

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

S>Правильный выбор технологии — условие необходимое, но не достаточное. Вот смотрите — собрал я проект AvaloniaApplication пустой без кода — уже весит 66 Мб. Как-то многовато, имхо. Если при прочих равных прога конкурента будет весить 2 Мб. и запускаться быстрее — то будут любить ее.

Это всё демагогия, конечно, но я могу на это ответить так. Пока ваш конкурент будет упариватсья паковкой проекта в 2 мега, вы сможете выкатить продукт и начать продавать. А потом уже подумать об уменьшении размера, если понадобится (вряд ли).

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

S>Правильный выбор технологии — условие необходимое, но не достаточное. Вот смотрите — собрал я проект AvaloniaApplication пустой без кода — уже весит 66 Мб. Как-то многовато, имхо. Если при прочих равных прога конкурента будет весить 2 Мб. и запускаться быстрее — то будут любить ее.

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

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

S>Должен быть мета-специалист.

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

Более реальный вариант — советоваться с несколькими людьми — с "глубокими" специалистами, знающими 1-2 технологию, и с менее "глубокими", но "широкими" мета-специалистами, которые знают 5-6 технологий, но менее глубоко. Но даже группа не может знать все.

В конечном итоге все равно кто-то должен принять окончательное решение в условиях неопределенности, взять на себя ответственность за это решение. Такой мета-мета-мета-специалист — менеджер (тимлид, архитектор, PM, CTO, CEO)

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

K>Свобода, которую предоставляет Линукс
Это не свобода, это бардак.

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

S>У каждого спеца опыт в 1-2 технологиях. Обычно в одной. И он всегда будет склонять на свою технологию, в итоге может просто из-за неверного выбора технологии/спеца получиться У.Г., которое сильно тормозит и пользоваться которым не приятно.

S>Должен быть мета-специалист.


На сегодняшний день, грамотно используя любую технологию программирования — можно сделать приложение-конфетку.
И при этом совсем не обязательно быть супер-специалистом.
Просто весьма важно придерживаться best-practices для выбранного стека. Ну и общих рекомендаций по разработке архитектуры.
На сегодня выбор технологии — это скорее дело вкуса, нежели принцыпа.
Конечно же, всегда важно понимать — где может оказаться "бутылочное_горлышко" проектируемой программной системы...

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

S>На чем бы вы писали десктопную прогу для Linux?

На Windows.

S>Если есть возможность кросс-платформы, скажем так, то почему нет?

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

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

S>>На чем бы вы писали десктопную прогу для Linux?

A>На Windows.
+100500
Да, это один из вариантов кроссплатформенной разработки

S>>Если есть возможность кросс-платформы, скажем так, то почему нет?

A>Если бы была такая беспроблемная возможность, то и вопроса бы не было. А так, начальная ценность фичи отрицательная и её надо чем-то отправдать, чтобы хотя бы выйти в ноль.

Не понятно, в чём же вопрос?
ИМХО кросс-платформенная разработка всегда важна и ценна.
Отчего же "ценность фичи отрицательная"?
Если можно — поясните, плиз.

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

S>>>Если есть возможность кросс-платформы, скажем так, то почему нет?

A>>Если бы была такая беспроблемная возможность, то и вопроса бы не было. А так, начальная ценность фичи отрицательная и её надо чем-то отправдать, чтобы хотя бы выйти в ноль.
AG>
AG>Не понятно, в чём же вопрос?
AG>ИМХО кросс-платформенная разработка всегда важна и ценна.

Неочевидно. Кросс-платформенность важна и ценна, когда реально нужна.

1. Если пишешь для себя, а ты на Windows, то кросс-платформенность не нужна.
2. Если пишешь для конкретно кого-то, а он/она на Windows, то кросс-платформенность не нужна.
3. Если пишешь для некоей целевой аудитории, и есть понимание, что они все на Windows, то кросс-платформенность не нужна.
4. Если пишешь неизвестно для кого, то зачем?

AG>Отчего же "ценность фичи отрицательная"?
AG>Если можно — поясните, плиз.

"Начальная ценность"
Это про любую фичу вообще. Вот пришла тебе в голову идея новой классной фичи — отлично, но теперь её надо будет как минимум
а) продумать/задизайнить,
б) реализовать,
в) протестировать,
г) до бесконечности поддерживать, чтоб не поломалась.

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

Т.е. вопрос надо ставить не как "если есть возможность, то почему нет?", а как "кому-то это вообще надо?"

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

AG>ИМХО кросс-платформенная разработка всегда важна и ценна.
На самом деле нет.
На каждой ОС юзеры хотят чтоб софт выглядел и вёл себя по guidelines для этой ОС. Если только этот софт уже настолько популярен что имеет свои общепринятые стандарты.

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

Чисто теоретически Qt 4.8.7.

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

V>Чисто теоретически Qt 4.8.7.

Почему же такой древний?
Сейчас Qt 5.14.2 уже идёт.

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

V>>Чисто теоретически Qt 4.8.7.
AG>
AG>Почему же такой древний?
AG>Сейчас Qt 5.14.2 уже идёт.

Потому и чисто теоретически, но в любом случае для графического интерфейса это был бы Qt.

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

S>Если есть возможность кросс-платформы, скажем так, то почему нет? Прога типа простого графического редактора узкой направленности (т.е. заточен под определенную область). Как я понимаю, из кроссплатформы осталось:

S>1. Java.

Тебе ж графика нужна? Если "да" то где графика и где Java?

S>2. QT.

Starting with Qt 5.15, long term support (LTS) will only be available to commercial customers.

Ну и коментарии

S>3. Electron?

Графический редактор предполагает т.н. immediate mode graphic. Т.е. что-то типа этого

function onPaint(graphics) {
  graphics.moveTo(...)
          .lineTo{...};
}

в Electron такого нет.

S>Еще варианты есть?

Всегда.

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

S>>1. Java.
CS>Тебе ж графика нужна? Если "да" то где графика и где Java?

Не того уровня графика, о которой вы подумали.

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

c> S>1. Java.

c> Тебе ж графика нужна? Если "да" то где графика и где Java?

JavaFX, например.

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

A>Неочевидно. Кросс-платформенность важна и ценна, когда реально нужна.

A>1. Если пишешь для себя, а ты на Windows, то кросс-платформенность не нужна.
Если завтра я на Linux — то тогда возможно два пути:
a) — всё на кросс-платформенной базе (тот же Qt) — можно сделать версию под Linux с относительно небольшими трудозатратами;
b) — всё "гвоздями_прибито" к Windows, тогда (вангую) окажется всё проще переписать с нуля

A>2. Если пишешь для конкретно кого-то, а он/она на Windows, то кросс-платформенность не нужна.
Если есть какие-либо сторонние требования Заказчика по части GUI — тогда (возможно) придётся выбрать тот же WPF,
но при этом — согласовать с Заказчиком, что всё Windows-only.
Иначе — смотри выше.

A>3. Если пишешь для некоей целевой аудитории, и есть понимание, что они все на Windows, то кросс-платформенность не нужна.
+100500
Если есть однозначное понимание требований Windows-only — тогда совсем другое дело.

A>"Начальная ценность"
A>Это про любую фичу вообще. Вот пришла тебе в голову идея новой классной фичи — отлично, но теперь её надо будет как минимум
A>а) продумать/задизайнить,
A>б) реализовать,
A>в) протестировать,
A>г) до бесконечности поддерживать, чтоб не поломалась.

Вот в том и ценность кросс-платформенного фреймворка, что всё это (ну почти всё) будет прямо из коробки
Конечно же, я понимаю что (например) вызова WinApi напрямую не пройдут, придётся найти их POSIX аналоги.
Файловая система и пути к файлам — также возможно придётся подправить напильником.
Но это не так трудозатратно, как переделывать все с самого начала.

A>Т.е. вопрос надо ставить не как "если есть возможность, то почему нет?", а как "кому-то это вообще надо?"

Кому надо?
Сегодня — почти никому, завтра — практически всем...

S>почему нет?
Нет, потому что разработка усложняется сильно, но даст ли это сопоставимый профит?

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

AG>Сегодня — почти никому, завтра — практически всем...

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

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

S>Если есть возможность кросс-платформы, скажем так, то почему нет? Прога типа простого графического редактора узкой направленности (т.е. заточен под определенную область). Как я понимаю, из кроссплатформы осталось:

S>1. Java.
S>2. QT.
S>3. Electron?

S>Еще варианты есть?

draw.io, lucidchart.com не устраивают?

Есть много вариантов. Но если редактор действительно простой, то можно и на электроне, со временем выйти в веб.