Но ведь правда же. Я уже писал в девелопменте, помню, ТСу, но оттуда удалили якобы за разжигание флейма. Но по тому треду выяснилось, что так считаю не только я :).
Все правильно сделал. Писать гуй на не ООП языке в 21 веке крайне глупо, ящитаю.
Си можно оставить только в критичных байтоё*ских местах. Типа там ядро например.
Вменяемые разработчики не пишут прикладные задачи на чистом C.
Об этом думать надо было лет 6 назад. А учитывая, из какого проекта растут ноги у lxpanel, то и вовсе лет этак 10 назад. Сейчас же имеем ситуацию: ядро панели написано, оттестировано, работает. И поэтому абсолютно похрен, на чем оно написано.
Гм. Ты осознаешь, что миграция на другой язык == переписывание всей программы с нуля?
Они потратят год на то, чтобы довести этот проект до более-менее работоспособного состояния, потеряв по пути половину возможностей изначального продукта. Т.е. на протяжении многих месяцев у них будет картина, когда на развитие старой версии сил уже нет, а новая еще не готова. Это абсолютно не сопоставимо с ничтожными затратами на развитие и поддержку нескольких *.c файлов. Заметь, мы говорим об ядре панели, а не о апплетах. Апплеты вполне можно было бы один за другим переписать на vala, и это ничуть не сказалось бы продукте — он в любой момент оставался бы целостным и работоспособным.
...потеряв по пути половину возможностей изначального продукта
Это с чего бы?
Т.е. на протяжении многих месяцев у них будет картина, когда на развитие старой версии сил уже нет, а новая еще не готова
Ты только что сказал что ядро оттестировано и работает, кто тебе мешает пользоваться старой версией? Или от того что разработчики начнут заниматься новой версией, старая сразу перестанет работать?
Это абсолютно не сопоставимо с ничтожными затратами на развитие и поддержку нескольких *.c файлов
Если речь о «нескольких *.c файлах», то их переписывание займет мало времени, зато куча проблем отпадет.
В самом деле, не вижу проблемы. Если переписывание программы положительно скажется на скорости и лёгкости дальнейшего её развития, то почему нет? И потом, вы же всё равно её форкнули и развиваете самостоятельно. Вы теперь сам себе апстрим, и можете решить проблему просто не делая того, что считаете неправильным.
В силе остаётся первое предложение. В последнее время развитие lxpanel стагнировало, переход на более подходящий язык с более низким порогом вхождения вполне может быть оправдан в этих условиях, если в достаточной мере простимулирует дальнейшую разработку.
Это справедливо относительно почти всех компонент lxde.
переход на более подходящий язык с более низким порогом вхождения вполне может быть оправдан в этих условиях, если в достаточной мере простимулирует дальнейшую разработку.
Девелоперов нет не потому, что сишечка. Их просто нет. Не думаю, что vala на что-то может повлиять.
Я думаю, что в этом пока ничего страшного нет, посмотрим, как помню это уже не первый раз, когда разработчики lxde выбрасывают весь написанный код и начинают все с нуля(вроде pcmanfm).
Оу, умельцы умудряются и на чистом Си писать редкостный говнокод. В Gtk время появления (не создания! создание-то относительно не тормозит) всплывающего меню есть не меньше O(N) от количества элементов в нём. Наткнулся сейчас на эти замечательные грабли при отладке апплета «Дерево каталогов».
А теперь умножаем кривость тулкита на кривость реализации прикладного ЯП и на кривость программиста конкретной софтины... oh, shi~
Понятное дело, что криворукость программиста тоже большой показатель.
Что изменилось? Почему те же браузеры отжирают ОЗУ сотнями мбайт? Почему плеер в лучшем случае весит 50-100 мбайт? Что такого эксклюзивного добавилось в современные плееры, по сравнению с тем же древним xmms кажется (livecd knoppix 2005 года), что плееры жрут в десятки раз больше?
Или я зря истерю, и это всего лишь криворукость современных программистов приводит к этому?
Где-то 50 на 50. Половина причин пожирнения софта вытекает из реальных требований, половина — из криворукости, нехватки времени или пофигизма.
Такие проекты как tiny core linux и connochaetos показывают, что современная gnu/linux система с низкими системными требованиями вполне возможна даже на существующем массиве софта, без переписываний.