LINUX.ORG.RU
ФорумTalks

Почему разработка для *nix остаётся неудобной?


0

2

Давно мучает мысль, что разработка десктопного ПО под линукс очень неудобна и имеет слишком высокий порог вхождения. Про разработку для веб пока умолчим, это отдельный адъ и израиль. Собственно, почему до сих пор не существует хотя бы несложной IDE где можно было бы: набросать мышом контролов на окошко, выставить им свойства и написать только свой код внутрь автоматически сгенерированной обвязки? Выбрать какой нибудь несложный язык, с нетрудным синтаксисом и несложными базовыми понятиями (тут каждый может подставить свой вариант, я бы конечно был не против руби/питона)

Да, есть MonoDevelop, но оно требует моно и тормозит. Да и C# не самый лучший в мире язык. Да, есть QtCreator, но С++ это не вариант.

Да, можно писать код в отдельном файлика, а окошки делать в Qt Designer'e или Glade и скручивать это вместе вручную. Это уныло и лень.

Может собратся всем ЛОРом и запилить небольшую, но годную IDE для создания гуёвых приложений под линукс?

Перемещено tazhate из development

★★★★★

всё познаётся в сравнении. вот попробуйте под макось написать софтину, тогда я вас послушаю...

по теме - с трудностью разработки под линукс совсем не согласен. много IDE, много языков, много фреймворков, выбор имхо получше чем в какой бы то ни было другой операционке. а что ещё, кроме хорошего набора инструментов, надобно программисту ?

Voviandr
()

тред не читал.

QtCreator - отличная штука. Если мусье не осилил кресты в пределах простеньких окошечек, то до написания софта его лучше не допускать.

P.S. Специально для немощных финская компания нокия напилила QML, где все на жабоскрипте и даже «закругления на окошечках» можно мышкой настраивать прямо на окошечке.

trex6 ★★★★★
()
Ответ на: комментарий от vurdalak

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

Тогда ты просто лепил какую-то хрень для сдадено и забыто. Потому что если кинуть с десяток элементов на форму, то нужно для каждого сделать привязку по осям X и Y, задать размеры элементов, расположение, расстояния до соседей и прочие свойства, выбрать из списка нужные события и прописать действия в обработчики. При этом тебе не нужно помнить до буквочки написание каждой хреновины - ты можешь просто посмотреть и выбрать нужное из списка. А когда будешь писать всю эту груду логики ручками, то придётся постоянно лазить по шпоргалкам, писать имена с ошибками, компилить, читать выхлоп компилятора, исправлять, снова компилить, снова находить Ашипки АрфАграфии в гинекологическом древе классов. Ты можешь сказать что память нужно тренировать, зубрить всего побольше, но там и так нужно помнить слишком много. То что дельфисты по умолчанию не используют проверку на диапазон {$R+}, это на их личной совести и к качеству дельфи/лазаруса отношения не имеет. Мышь в данном случае быстрее клавиатуры ещё и потому что часть кода генерируется автоматически в ресурсный файл, ты его не видишь, но редактор его использует.

Napilnik ★★★★★
()
Ответ на: комментарий от Alve

Ну почему же. Был и turbo basic. И exe компилял. От борланда.

hbars ★★★★★
()
Ответ на: комментарий от f1xmAn

> С++ это не вариант

А что вариант? Писать приложения на питоне, чтобы пользователь не расстраивался из-за того, что программа думает быстрее него?

Реквестирую в квотезы.

KennyMinigun ★★★★★
()
Ответ на: Сплошное 4.2. от schizoid

Да, можно писать код в отдельном файлика, а окошки делать в Qt Designer'e или Glade и скручивать это вместе вручную. Это уныло и лень.

А вот и нет.

Можно написать код на FPC и запускать из него поток с гуёвиной написанной на лазарусе, компилятор такое позволяет потому что всякие make и cmake для сборки ненужны.

Napilnik ★★★★★
()
Ответ на: комментарий от note173

Я вижу другие проблемы при разработке под линукс. Главную я уже описывал — нет общепринятого, работающего везде способа упаковки приложений. Вручную можно и статически все слинковать, и генератор .run-файла написать, и даже песочницу поднять, а вот на уровне стандарта ничего такого нет.

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

Napilnik ★★★★★
()
Ответ на: комментарий от CrossFire

Это является следствием популярности венды, но никак не следствием наличия вижуалбейсика.

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

Napilnik ★★★★★
()
Ответ на: комментарий от AiFiLTr0

C++ для десктопных апликух лучшее, что было придумано.

Тото виджеты пишут поверх плюсов на зоопарке скриптоты. Чем больше интерпритаторов одновременно надрывается тем круче и благодарить за это надо удобные плюсы.

Napilnik ★★★★★
()
Ответ на: комментарий от note173

Самая большая проблема линукса — слишком много софта.

Я бы даже сказал однообразного софта. В категориях где навалом годного софта - появляются всё новые и новые (не нужные) сущности. А где приходится подставлять Wine - годами не появляется годных аналогов.

KennyMinigun ★★★★★
()
Ответ на: комментарий от Alve

Так и другие языки раньше были примитивными. И что с того?

Quasar ★★★★★
()
Ответ на: комментарий от f1xmAn

Python как раз таки турбореактивный, если использовать правильный стиль написания программ на нём.

Quasar ★★★★★
()

Для wxPython вроде есть мышевозный дизайнер интерфейса с автогенерацией кода.

strangeman ★★★★
()

Да, есть QtCreator, но С++ это не вариант.

Иди назад в венду и пиши на визуал бейсике. Для школо-ло лучший вариант, чо.

erfea ★★★★★
()
Ответ на: комментарий от pekmop1024

быдлокодеров-школьников, которые порождают тонны говна.

Это же хорошо :) Надо к ним откомандировать хорошего руководителя, а уж он задаст направление - куда двигаться и как.

Munhgauzen
()

Может собратся всем ЛОРом...

Угу, счас.

drSchur ★★★
()
Ответ на: комментарий от f1xmAn

А что вариант? Писать приложения на питоне, чтобы пользователь не расстраивался из-за того, что программа думает быстрее него?

Питон, конечно, тормозит, если писать на нем в сишном стиле или переводить сишные программы 1 в 1. Нужно оговориться, что если писать на сях в стиле брейнфака или PHP, то тормозить будут и программист, и программа. По-моему, это очевидно.

shimon ★★★★★
()
Ответ на: комментарий от Napilnik

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

Почему-то мне редко требуется лазить по шпоргалкам, и никаких ошибок у меня не бывает. И скорость написания кода получается выше, чем перетаскивания на форму и задания параметров на панельке. ЧЯДНТ?

vurdalak ★★★★★
()
Ответ на: комментарий от Napilnik

Это на любителя. Можно писать и на плюсах. Для любителей скриптоты же сделано.

AiFiLTr0 ★★★★★
()

Почему разработка для *nix остаётся неудобной?

Какое наглое 4.2!

Eddy_Em ☆☆☆☆☆
()

запилить небольшую, но годную IDE для создания гуёвых приложений под линукс?

Зачем?

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Napilnik

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

вы теперь тут в троём веселите?

TERRANZ ★★★★
()
Ответ на: комментарий от Quasar

Это касается почти любого языка, но я в жизни не поверю, что он будет быстрее с++. Хотя, с++ тоже можно испоганить своей неграмотностью. В общем, я просто не вижу причин не использовать с++ для десктопных приложений, кроме упоротого фанатизма, конечно же.

f1xmAn ★★★★★
()
Ответ на: комментарий от shimon

Тот комментарий был написан в пылу работы с yum после перехода с pacman`а.

f1xmAn ★★★★★
()
Ответ на: комментарий от WatchCat

Да куда уж проще?

Мак — десять раз уже писал, как просто в нем собрать, передать, запустить и установить приложение. В windows еще проще, но менее безопасно и гибко.

note173 ★★★★★
()

Про разработку для веб пока умолчим, это отдельный адъ и израиль.

То-то под виндой преимущественно похапешники кодят. Сатанисты, наверное.

spyro
()
Ответ на: комментарий от note173

Мне что бы собрать установочный пакет для моего софта достаточно написать cpack -G <чего хочу> и cmake сам всё соберёт.
Так что я ещё раз спрошу, куда уж проще?

WatchCat ★★★★★
()
Ответ на: комментарий от Munhgauzen

Это же хорошо :) Надо к ним откомандировать хорошего руководителя, а уж он задаст направление - куда двигаться и как.

Так рождается ынтерпрайз-говно типа украинского бест-звита. Спасибо, не нужно.

pekmop1024 ★★★★★
()
Ответ на: комментарий от pekmop1024

ТС хочет больше быдлодельфокодеров в линукс. Я думаю, это будет что-то нецензурное на выходе.

а я думаю, что это _будет_

drBatty ★★
()

Да, есть MonoDevelop, но оно требует моно и тормозит. Да и C# не самый лучший в мире язык. Да, есть QtCreator, но С++ это не вариант.

Эм, товарищ, ты слишком капризен. Я тоже не люблю разработку в никсах, но ты просто придира. Что тогда остается для гуя?

Dudraug ★★★★★
()
Ответ на: комментарий от pekmop1024

ТС хочет больше быдлодельфокодеров в линукс. Я думаю, это будет что-то нецензурное на выходе.

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

Dudraug ★★★★★
()
Ответ на: комментарий от f1xmAn

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

Есть как минимум две причины:

1. Языки, которые в чём-то лучше C++, например предоставляющие удобные структуры данных, типы, сборщики мусора, завариватели кофе etc.

2. Когда целевая программа должна делать нечто, для чего в некоем ЯП есть хорошая либа. Я не буду писать на Си текстовый редактор, я буду писать его его руби, т.к. см. пункт 1 и руби имеет множество удобных средств работы со строками. Точно так же, я на будут писать на руби матан, если фортран имеет намного больше либ для матана.

Вот примеры.

Alve ★★★★★
() автор топика
Ответ на: комментарий от Alve

1. Языки, которые в чём-то лучше C++, например предоставляющие удобные структуры данных, типы, сборщики мусора, завариватели кофе etc.

В си++ есть qt и boost (в поледнем есть shared_ptr, не полноценный сборщик мусора, но уже и не так и плохо).

2. Когда целевая программа должна делать нечто, для чего в некоем ЯП есть хорошая либа. Я не буду писать на Си текстовый редактор, я буду писать его его руби, т.к. см. пункт 1 и руби имеет множество удобных средств работы со строками. Точно так же, я на будут писать на руби матан, если фортран имеет намного больше либ для матана.

Смотри буст же! Вообще си++ имеет преимущество - производительность. Но за это приходится подчас жестоко расплачиваться.

Dudraug ★★★★★
()
Ответ на: комментарий от Alve

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

Реальные проблемы - всегда явное управление памятью, все эти -> . :: вместо точки, препроцессор вместо импорта. Это хорошие вещи сами по себе, но они плохи в контексте быстрой разработки и накидывания прототипов. Год назад писал программку - вычисляет плотность распределения по заданным статистическим данным и вычисляет параметры соответствующего распределения Вейбулла. Разрешил алгоритмические проблемы, уже готовясь сдавать, решил скомпилить под виндой... и на те, конфликт макросов. Макрос max из windows.h (убил бы за такие имена макросов) и макрос max из valarray. Решение стандартное - сделать #undef. Но что, если проблема возникает в сгенерированном qmake'ом коде?

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

Я не буду писать на Си текстовый редактор, я буду писать его его руби

А я бы предложил QScintilla, хоть даже и через биндинги на том же руби. Ещё раз: C++ крайне дружелюбен к сторонним библиотекам, не в этом его проблемы.

quiet_readonly ★★★★
()
Ответ на: комментарий от vurdalak

Почему-то мне редко требуется лазить по шпоргалкам, и никаких ошибок у меня не бывает. И скорость написания кода получается выше, чем перетаскивания на форму и задания параметров на панельке. ЧЯДНТ?

1) Поменяй убитую мышь на нормальную.

2) Ты сравниваешь индивидуально настроенные гуёвины и слепленные в текстовом редакторе по умолчанию, где про какие-то настройки тебе и знать не надо - куда и как кнопка прилепится, там ей и место.

3) Скорость редактирования этого кода через пару лет другим программистом тебе неинтересна.

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

Napilnik ★★★★★
()

Это ты под iPhone/iPad в Xcode не писал

black7
()
Ответ на: комментарий от note173

Не знал про этот инструмент.

Ну так доки-то на что?
Или ты про cmake не знал? O_o

WatchCat ★★★★★
()
Ответ на: комментарий от note173

Да, кстати.

Но все еще «куда уж проще» — xcode.

xcode - это IDE, причём насколько я понимаю завязанное на одну платформу.
Cmake же система сборки, а IDE ты можешь использовать любое, я вот, например, люблю KDevelop, к тому же он хорошо интегрируется с cmake'ом.
А тем же cmake'ом я собирал один и тот-же проект и под Винду и под Линукс.
Под Винду он может и инталятор сгенерировать.

WatchCat ★★★★★
()
Ответ на: комментарий от WatchCat

xcode - это IDE, причём насколько я понимаю завязанное на одну платформу.

Не только, все функции доступны через консоль. CMake, кстати, тоже xcode использует (может и не использовать) при сборке под osx и ios.

note173 ★★★★★
()
Ответ на: комментарий от Napilnik

1) У меня отличная игровая мышь, просто позиционировать курсор для мозга сложнее, чем набирать на привычной клавиатуре. Поэтому скорость реакции выше.

4) Я не против шпоргалок и окошка предпросмотра написанных гуёв. Но писать гуй сложнее хелловорлда двиганием компонентов - это убийство.

3) А при чем тут дизайнеры? Если ты говнокод пишешь, что ты и из компонентов сложишь говнокод.

vurdalak ★★★★★
()
Ответ на: комментарий от Napilnik

прибивание полей ввода и отображения к X и Y экрана это уже прошлый век, в делфи практиковался, кстати.

посмотри, хоть, для смеху, как в андроиде описывается ui

TERRANZ ★★★★
()
Ответ на: комментарий от vurdalak

4) Я не против шпоргалок и окошка предпросмотра написанных гуёв. Но писать гуй сложнее хелловорлда двиганием компонентов - это убийство.

В лазарусе нормально. Хочешь привязывай кнопку к нижнему краю предыдущей картинки и тогда при её расширении кнопка синхронно поедет вместе с ней, а можешь привязать к краю формы, или привяжи к чему-то каждый край кнопки и тогда её можно будет растягивать вместе с окном. Почти тот же пазл только с цифрами. Дети играют в более сложные пазлы и ничего, справляются если те не глючат.

3) А при чем тут дизайнеры? Если ты говнокод пишешь, что ты и из компонентов сложишь говнокод.

Действительно, причём. В некоторых утилитах кед, написанных давно, нехватает пары кнопочек - заранее всё не предусмотришь. И надо бы поправить, да изучать всю их кухню ради такой мелочи решительно в лом и нецелесообразно. По твоему там говнокод?

Napilnik ★★★★★
()
Ответ на: комментарий от TERRANZ

прибивание полей ввода и отображения к X и Y экрана это уже прошлый век, в делфи практиковался, кстати.

Насчёт X и Y _экрана_ это твои личные эротические фантазии.

посмотри, хоть, для смеху, как в андроиде описывается ui

Там изобрели круглые, треугольные, пяти и шестигранные кнопки? Лично мне и этого хватает, со временем допилят тулкит на OpenGL и для ведроида, только мне эта железяка пока нафиг не нужна со всем её софтом.

Napilnik ★★★★★
()
Ответ на: комментарий от Napilnik

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

Если создание кнопок разбросано по классам так, что ты не можешь его найти - да.

vurdalak ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.