bluefish и PHP

Bluefish однозначно рулит, сам им пользуюсь и доволен! Единственное огорчает не очень хорошая окраска кода, особенно в include файлах, где кусками html код, и в нем php, там вообще не окрасит ничего. В настройки подсветки ситаксиса не лазил, может можно это исправить руками.

А так, за скрин - 3 ! За KDE и за /var/www/localhost особенно!

После этого говорите что GNOME девелоперы умом тронулись (HIG, спор из-за кождой кнопки, чекбокса ...) пока сами не задолбаетесь в кдешных дебрях нужную галку искать, не поймете ...

По-моему, удел не самых умных людей не найти эту настройку, ведь _во_всех_ KDE-приложениях с редактированием текста эта настройка находится в одном месте. Где? Настройка->Настроить редактор->Открытие/Сохранение->Создавать резервную копию при сохранении.

Еще бы написал, что настройку fluxbox'а не осилил.

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

>Столько опций, что ноги все переломать можно.

Хых. Вся философия KDE и иже с ним. А в Bluefish все по HIG'у, наверное :) Блин, неужели девелоперам DE так тяжело найти золотую середину? KDE-шников хлебом не корми, дай лишних менюшек и галочек наделать - до абсурда. Зато GNOME-овцы сутками только и делают, что выкорчевывают все "лишние" настройки, которые могут запутать 2-3 пользователей из 10 с вероятностью 37-43%...

за что так KDE испоганил то? Мало того, что без антиальясинг шрифты смотрятся просто капец как, так еще и от вида панелей плакать хочется. :)

А bluefish как bluefish. я на php в vim'е пишу и очень даже даволен.

а про галочку -- shame on you. :) Что-то линуксойды совсем разленились. То лопалили километры текстовых конфигов и кричали, что рулезз, а теперь уже и пару закладок визуально "асилить" не могут.

За скрин 2, а за гтк - убожество ваще убить надо. Кеды рулят. :)

> То лопалили километры текстовых конфигов и кричали, что рулезз, а теперь уже и пару закладок визуально "асилить" не могут.

Так веть в текстовом конфиге все просто - less some_config.cfg -> /backup<Enter> :-)

> а за гтк - убожество ваще убить надо

Тогда убею Adobe Reader, VmWare, новый сановский JRE и много чего еще.

Ниче из них не юзаю :) qt 4ever! Реально, ну сделали бы один набор библиотек и от него танцевали, а то таскать эту кучу напрягает. Или gtk убили бы окончательно, что ИМХО лучше.

да ладно тебе. Все не от либ зависит. А от того, откуда руки растут у разработчиков. А либы ты что, каждый день таскаешь туда сюда?

ну почему же сразу убожество, вполне симпатично смотрится

>ну почему же сразу убожество, вполне симпатично смотрится

Нормально смотриться это у анонимов весеннее обострение просто ... По сабж - у тебя разрешение низкое, да ещё и всякими извратами сократил полезную область т.е. для работы не годится поэтому за скрин два :).

Согласен на все сто!

посмотрел - понравится редактор. поставил:) а чего у меня php-синтаксис не подсвечивается? все просто черным.... в настроках в Подсветке синтаксиса лажа какая то

все, понял:) тэг начала пхп-документа поменял на <?

Чем PHP всегда рулил - это смесью application logic, persistence layer и presenation layer на одном уровне архитектуры;)

А какой смысл использовать bluefish для пхп? Он автокомплит умеет делать или что?

Ну разделять конечно можно.... но геморно :)

Из этого можно сделать два вывода:

1. Разделение нафиг

2. Средство нафиг

Каждый выбирает тот вывод, который ему ближе;)

дадад. предпочитаю 2й вариант ;)

Да ладно Вам, svu, это не PHP виноват. При желании такую же смесь можно на любом языке сделать.

В этом редакторе отладчик имеется?

> Заставили на PHP писать блог.

Били? Пытали?

> При желании такую же смесь можно на любом языке сделать.

Согласен. Вопрос в том, что каждая технология явно или неявно пропагандирует тот или иной архитектурный стиль... И если в одной технологии такая смесь является резким отступлением от общепринятого стиля (и уже одним этим фактом вызовет настороженность начальства-разработчиков-пользователей-...) - то в другой технологии будет искреннее детское удивление: "А разве можно/нужно иначе?"

> Попробовал quanta - тормозит с 256RAM и гадит (извините) бакапами файлов, оканчивающихся на ~. Не нашёл где отключить...

странно у меня в свое время на 128 не тормозило(разве что вечно экспериментальный и нестабильный WYSIWYG), создание временных файлов отрубается в опциях сохранения вроде. Нет гном с его HIG и выкидыванием всего таки нужен, нужен для тех кто способен потеряться в ~10 вкладках диалога настройки

Когда я пробовал кванту на PIII-800/512Ram, оно на мелких файлах не тормозило, на больших тормоза были весьма заметны. Версию кванты не помню. Помню только, когда стал с другой машины, значительно более мощной, из-под цигвина с поднятым X сервером, транслируя на неё X сессию заходить, смог нормально работать. Потом осилил емакс и выкинул нафиг всякие кванты и прочую лабуду.

>Ниче из них не юзаю :) qt 4ever! Реально, ну сделали бы один набор библиотек и от него танцевали, а то таскать эту кучу напрягает. Или gtk убили бы окончательно, что ИМХО лучше.

Ё-маё, ещё один звездатый ламер. Надоели уже.

Ты хоть пробовал запускать проги на qt/kdelibs не из-под kde ? Пробовал ли программить на qt и gtk?

Если б пробовал, то не говорил всякую ерунду.

Чем пхп всегда рулил -- это тем, что на нем садишься и пишешь. И проект на php заканчивается тогда, когда гуру(?) программисты закачивают "строить бизнес логигу в UML".

есть такая народная поговорка: "плохому танцору ...". Так вот и с программистами. Нормальному программисту все равно на чем писать и все равно, какой стиль там что-то пропагандирует. Нормальный программист всегда подумает головой.

Извините меня, но для сайта, в котором все сводится к "select a,b,c from d where x=y" и "update d set x=y" использовать что-то кроме php, я назову только маразмом.

>Нормальному программисту все равно на чем писать и все равно, какой стиль там что-то пропагандирует.

Нормальному, реальному программисту вообще все равно.

Вот тут у нас и пример есть (см. http://www.linux.org.ru/jump-message.jsp?msgid=1313075 ) --- мальчик, девочка, какая в @@@@ разница? :-]

Ох, набежали защитники php...:) ИМХО:

1. Если сайт маленький и очевидно, что всегда будет таковым (веб-страничка детсада) - проще взять готовую CMS и доточить напильником. Все-таки приличные CMS дают хотя бы минимальное отделение представления от наполнения.

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

Пусть, конечно, цветут 100 цветов...

> Чем пхп всегда рулил -- это тем, что на нем садишься и пишешь.

Дадзыбао из серии "чего тут думать, тут программировать надо".

> Java developer/architect.

Все ясно. :) Не было б работы, если б связанные с php были бы. Я ява программисты они да, все умные, все делают только серьезные проекты, которые непремерно умрут без масштабирования и рефакторинга.

Ладно, flame off.

Дык. Если рефакторинг не отмасштабируешь как следует - день зря прошел!;)

Это я в порядке завершения флейма;)

можно в цитатник? :)

be my guest :)

Советую попробовать kdevelop Самая мощнаю штука после vim'а :-)

А через год человек, который будет вносить 101 патч в код, налабанный 10 людьми в таком стиле за прошедший год, будет ругаться матом. PHP -- зло и должно умереть. Оно очень быстро дает очень плохой результат. Если проект не прийдется сопровождать -- да, PHP лучший вариант. Если проект будет сопровождать враг -- PHP мегалучший вариант.

Кстати, безотносительно пхп - про масштабируемость проектов, уровни и "думать". Лучшее, что я видел - это интранет-проект на Java/SilverStream (был такой ОЧЕНЬ специальный app server, еще до J2EE), в котором класс User появился лет через 5 после начала проекта. А чо - намана.. В стиле этого appserver (и его сугубо проприетарной RAD тулзы) было нормой и обычным делом прямичком в базенку из UI лазать... Спасибо сантехникам, изобрели J2EE.

>Чем PHP всегда рулил - это смесью application logic, persistence layer и presenation layer на одном уровне архитектуры;)

Ничего не понял, но попробую догадаться. Лично я на PHP на шаблонах пишу.

>Когда я пробовал кванту на PIII-800/512Ram, оно на мелких файлах не тормозило, на больших тормоза были весьма заметны.

Ага. На большом файле с подсцветкой была ужаная скорость при печати с клавиатуры(!)

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

> PHP -- зло и должно умереть. Оно очень быстро дает очень плохой результат.

Perl даёт ещё более худший результат, ещё более быстро. Он тоже должен умереть? ;-)

> Perl даёт ещё более худший результат, ещё более быстро. Он тоже должен умереть? ;-)

Должен, но у него даже это не получается!;)

объясни пожалуйста, а какой тайный смысл в расстановке semicolon в конце каждого запроса?

ИМХО - гамму стоит поменять на более темную. Чистый белый фон для кодера - это зло.

напрямую пихать значения из $_POST в параметры функции несколько некошерно :)

> qt 4ever! Реально, ну сделали бы один набор библиотек и от него танцевали, а то таскать эту кучу напрягает. Или gtk убили бы окончательно, что ИМХО лучше.

А у меня Qt нету. Просто потому что нафиг не нужен. Весь мой софт -- под GTK. Короче, желающим что-то убить советую начать с себя.

> напрямую пихать значения из $_POST в параметры функции несколько некошерно :)

Так обычно бывает, когда в архитектуре приложения один уровень;)

> Perl даёт ещё более худший результат, ещё более быстро. Он тоже должен умереть? ;-)

Любой язык, который поощряет грязные хаки, а не good practices, несомненно должен умереть. Об этом svu уже сказал. На таком языке очень трудно писать масштабируемые, легко поддерживаемые приложения. Слишком велик соблазн сделать всё быстро и грязно. <цитата>Чем пхп всегда рулил -- это тем, что на нем садишься и пишешь</цитата>. Вот такие же примерно аргументы и у любителей Perl. Причём Perl ещё и отличается синтаксическими извратами, которыми любят щеголять многие Perl гуру.

Кстати, ведь проект Perl6 неспроста затеяли. Ларри Уолл сотоварищи понимают, что в современном виде Perl пригоден только как удобный заменитель *sh, не более. Только вот опоздали они с этим хорошим делом лет на 7. Да и движется оно очень уж медленно, первый апокалипсис Ларри ещё в 2001 написал... Уж лучше бы бросили они это неблагодарное дело, да помогли Матцу писать Rites (в первую очередь к разработчикам Parrot это относится). Всяко полезнее было бы.