Вышел Lazarus 0.9.26

> С чего вы взяли, что ГУЙ должен существовать отдельно от логики?

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

>Какие на фиг "обычные параметры", дебилятко?

Злишься, значит не прав.

>Эта быдловская функция же полезет ещё и значение текстового поля считывать

Функция установки значения текстового поля,такая же функция, что и...

ЗЫ. Не забудь слюни с клавиатуры протереть.

> 1) Логика должна быть оформлена так, что легко подвергается модульному тестированию.

Логика никому ничего не "должна" :) Если у меня программа состоит из одного модуля в 100 строк, который тесно завязан с ГУИ, который никогда не будет портироваться, и который нужно написать в течение 2-х дней, мне не надо думать о модульном тестировании - достаточно хорошо поработать удобным интегрированным отладчиком, который есть в Делфи.

> 2) подлежит использованию из разных мест программы (грубо говоря, накладную может вбить оператор, а может она и автоматически создаваться)

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

> 3) Одна и та же логика может дергаться из 1) гуя 2) вуя 3) в пакетном режиме, например при импорте.

Опять же, а если не нужен пакетный режим или экспорт? Понимаете, ваш аргумент строится на том, что вы ставите КОНКРЕТНУЮ задачу ("должен то-то, должен се-то") и доказываете, что для этой конкретной задачи обработка Button1.Click в одном модуле с логикой не подходит. Но вы доказываете этим только что Делфи не подходит для ДАННОЙ КОНКРЕТНОЙ задачи. Задачи бывают разные и РАДы прежде всего ориентированы на БЫСТРУЮ разработку. Признаю, что быстрая разработка часто идет в ущерб качеству.

> Button1.Click не может быть автоматически протестирована и не скриптуется. Это по мелочи.

Почему это? Кто мешает послать кнопке сообщение WM_LBUTTONDOWN из другого приложения или треда? И кто, в конце концов, мешает положить обработчик события в другой модуль и вызывать его из Button1.Click? Все равно при отладке бряк будешь ставить скорее всего именно на Button1.Click :)

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

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

> Когда захочется, тогда функциональность вынесут в "DLL/static lib", а консольное убожество с ключами пусть гики сами себе оставят.

1) всегда проще посмотреть на ключи, которые указаны в usage, чем перечитывать исходник.

2) Есть прорва случаев, когда это невозможно.

> А так же рождает уверенность, что я зря тут бросаю бисер, лучше я его на студентов приберегу. Всего наилучшего. Накодите в Дельфях магабайта два-три сурсов -- надеюсь, поумнеете. Лично мне помгло.

Вот как? Ну что ж, и вам того же. Жаль, что успел ответить, не прочитав этот пост. Рад, что не мог быть вашим студентом.

> Функция установки значения текстового поля,такая же функция, что и...

Ты говно. Тупое быдлячье говно.

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

> Если с программой всегда будет работать только оператор, и автоматическое создание до смерти не будет нужно?

Когда быдлокодеришка делает такое предположение о способах употребленя своей поделки, то в 90% случаев он глубоко заблуждается. Лучше не делать лишних ограничивающих предположений, особенно если у тебя весьма низкий уровень интеллекта и узенький кругозор (а у быдлокодера высокого интеллекта быть не может по определению - иначе он не был бы быдлокодером).

> Задачи бывают разные и РАДы прежде всего ориентированы на БЫСТРУЮ разработку.

Дельфя - не РАД, так как быстрой разработки не предполагает. Более адекватными средствами прототип лепится гораздо быстрее.

> Признаю, что быстрая разработка часто идет в ущерб качеству.

В приличных RADах скорость разработки качества не ухудшает.

> Пользователь не будет заниматься адаптацией под непредсказуемые применения...

А не сучке-быдлокодеришке это решать за юзера.

> он тупой и ничего в этом не понимает

В большинстве случаев как минимум не тупее чем быдлокодеришка.

> проблема вернется к создателю программы

Ага, лет через 5, когда создатель, возможно, уже давно в земле гниёт.

> которому легче добавить новую функциональность изнутри

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

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

> Функция установки значения текстового поля,такая же функция, что и...

А не задолбаешся программно устанавливать значение текстового поля во время _тестирования_?

>> С чего вы взяли, что ГУЙ должен существовать отдельно от логики?

>Затем, что логике монопенисуально откуда брать информацию для расчетов - от гуя, от туя, от веб-морды или от другой программы. Тоесть мы не отрываем интерфейс, а расширяем его.

Ну вот опять, как и предыдущий мой оппонент, вы придумываете конкретную задачу и доказываете, что для ЭТОЙ КОНКРЕТНОЙ задачи такой подход не работает. А если нет никаких "расчетов"? Если есть окошко с кнопкой, которое периодически показывает какое-то сообщение от устройства? Зачем ради этого огород городить вместо того, чтобы написать за 2 минуты? И потом, Делфи НЕ ОБЯЗЫВАЕТ вас держать все в одном модуле! Разнесите все по разным юнитам и отлаживайте как вам угодно.

>> Если с программой всегда будет работать только оператор, и автоматическое создание до смерти не будет нужно?

>Когда быдлокодеришка делает такое предположение о способах употребленя своей поделки, то в 90% случаев он глубоко заблуждается.

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

>Дельфя - не РАД, так как быстрой разработки не предполагает. Более адекватными средствами прототип лепится гораздо быстрее.

Очень интересно. И что же это за "более адекватные" средства, которыми можно разрабатывать быстрее, чем в Делфи? С удовольствием бы перешел на них, особенно если они свободные. :)

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

Заказчик тоже не гений. Может не знать, что ему через месяц потребуется. Потому будет локти себе кусать, но будет уже поздно.

> Насколько я понимаю, у вас пока еще не очень большой опыт работы в промышленности? :)

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

> И что же это за "более адекватные" средства, которыми можно разрабатывать быстрее, чем в Делфи?

Сложно найти более неадекватное средство, чем говнодельфи. Java даже, при всём убожестве, на порядки RADовее. Tcl/Tk вообще в сравнении с дельфёй идеален. Python с любым из тулкитов гораздо проще и быстрее разрабатывать прототипы позволяет. Ruby с его метапрограммированием вообще сила.

> С удовольствием бы перешел на них, особенно если они свободные. :)

Всё вышеперечисленно свободно.

Попробовал поставить.

ОБЪЯСНИТЕ ПОЖАЛУЙСТА!

Как собрать fpc с поддержкой отладчика для 64-битной системы? Генту.

> Ну вот опять, как и предыдущий мой оппонент, вы придумываете конкретную задачу и доказываете, что для ЭТОЙ КОНКРЕТНОЙ задачи такой подход не работает.

> Если есть окошко с кнопкой, которое периодически показывает какое-то сообщение от устройства?

1) Намек поняли?

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

> Очень интересно. И что же это за "более адекватные" средства, которыми можно разрабатывать быстрее, чем в Делфи? С удовольствием бы перешел на них, особенно если они свободные. :)

В этом треде уже много раз называли более достойные средства разработки. Перечитайте его еще раз. Даже книжки умные по ним советовали, на русском языке, причем.

Вот, о таких, как вы, написали http://lisp.tomsk.ru/wordpress/2007/06/07/we-hate-to-fly/#more-40

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

> Фанатичные ООПщики

Тссс... А то еще узнают, что ООП имеет относительно узкую область применения, а в их любимом ГУИ вообще за спасибо не надо. Что тогда будет? Задолбаюсь отвечать ;).

> 1) Намек поняли?

Намек в том, что не существует одного православного метода решения всех задач.

> Еще лучше сделать консольную аппликуху, которую периодически дергать откуда хошь и результат пихать куда хошь - хоть дальше в трубопровод, хоть в гуевину.

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

> В вашем случае возможность быстро "набросать кнопок" провоцирует на то, чтобы каждый раз делать это заново, игнорируя возможность дальнейшего использования вне рамок, определённых первоначально.

А если задача не предполагает выхода за эти рамки, и, более того, устанавливает жесткие сроки?

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

Правильно - если предполагается, что программу кто-то будет поддерживать и развивать. Но ведь Делфи НЕ ТРЕБУЕТ чтобы вы пихали все в один модуль. "Правила хорошего тона" она не отменяет.

> Вот, о таких, как вы

Вот за это я люблю ЛОР! :D

> Намек в том, что не существует одного православного метода решения всех задач.

Намёк в том, что если общее решение не намного дороже частного, то надо пользоваться общим, поскольку тогда многократно снижается стоимость дальнейшей поддержки и повышается code reuse (что снижает стоимость последующих разработок). Это - общее правило, из которого нет исключений.

> Зачем искусственно усложнять простую задачу?

Усложнения тут на один процент (а чаще этот вариант и намного проще чем ad hoc), а преимуществ - на сотни.

> По-моему, я сейчас наблюдаю пагубное влияние "юникс вея", доведенного до абсурда... :) С чего вы взяли, что ГУЙ должен существовать отдельно от логики? Может, и опции командной строки от логики отделим? ГУЙ, как и командная строка, как и файл конфига - это интерфейс с пользователем, и он не может существовать отдельно от логики программы ПО ОПРЕДЕЛЕНИЮ. "Юникс вей" предполагает разделение программ по задачам, но не отделение программ от их интерфейсов.

У вас неправильное представление. Допустим вы пишете какой-нибудь почтовый клиент (и не только вы, таких дебилов и ущлёпков дофига) неотделимым от гуя. Что получается в результате? Вы реализовали функциона для доступа к почтовым ящикам и скачивания/отправки почты, поддержки множественных аккаунтов и архивов переписки на стороне клиента и т.д. и т.п. А потом вдруг обнаружили, что удалённый доступ к вашему компьютеру намного удобнее и надёжнее осуществлять через терминал. И что делать? Будете писать вторую программу имплементирующую всё это под консольный интерфейс?

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

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

> Намек в том, что не существует одного православного метода решения всех задач.

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

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

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

> А если задача не предполагает выхода за эти рамки, и, более того, устанавливает жесткие сроки?

Вы телепат и можете гарантировать, что эти рамки не потребуется расширить ч-з некоторое время? В сжатые сроки. Тем более, что прикручивание гуевины к логике много времени не занимает.

> Но ведь Делфи НЕ ТРЕБУЕТ чтобы вы пихали все в один модуль.

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

>И вдруг юзеру захотелось делать это всё по крону. Действия дельфошлёпщиков в такой ситуации?

Ну признайся, что ты дельфи после 2ой версии в глаза не видел. Все эвенты выносятся на внешний интерфейс и управляй хоть приложением хоть с марса. Работы на 15 минут от силы. Да я на 400% уверен, что твоих скилов в программинге не хватит даже на то, чтобы написать скрипт из 5 строчек на питоне, для пакетной перекодировки wav -> ogg. А еще туда-же лезет в системные аналитики. Пельмень, бивесобатхедообразный.

Нормальные пацаны юзают графические терминалы.

Уже 10 лет.

> Нормальные пацаны юзают графические терминалы. > Уже 10 лет.

Они не с нашего сраёна.

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

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

> Потом оформляет его, если надо в виде разделяемой библиотеки, использует из консольной программы, рисует гуй к нему - всё это отдельные приложения. Логика работы собственно гуя сидит в гуе, функционал же шарится между всеми приложениями.

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

> И, поскольку, рисование морд в Дельфях упрощено до предела

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

> всяких приплюснутых маньяков, вечно мешающих всё в одну кучу и в результате получающих Х-овые поделки не имеющие нормального консольного аналога - некогда им, они мля окошки рисуют.

Вы так хорошо кодера, независимо от ЯП описали...

> "Дельфошлёпщик" просто пишет нужный функционал в виде обж.паскалевских юнитов.

Ложь. 99% этой мрази суёт логику в обработчики гуйни, об чём собственно и спич.

> рисование морд в Дельфях упрощено до предела

4.2, изощрённое и с особым цинизмом.

> то разработчик может позволить себе сосредоточиться именно на качестве той функциональности, ради которой и создаётся софт

Ути-пути. Фигли ж вся эта дельфосрущая мразь НЕ СОСРЕДОТАЧИВАЕТСЯ на функциональности?

> Ложь. 99% этой мрази суёт логику в обработчики гуйни, об чём собственно и спич.

Ну так напиши просто: "я поддерживаю шаблон MVC", чо тут пургу нести. Идиотов-разработчиков хватает под любой средой, просто в Делфи проще писать код нормально.

>> рисование морд в Дельфях упрощено до предела
> 4.2, изощрённое и с особым цинизмом.

Судя по аргументированности, складывается впечатление, что ты там просто чего-то ниасилил.

> Ути-пути. Фигли ж вся эта дельфосрущая мразь НЕ СОСРЕДОТАЧИВАЕТСЯ на функциональности?

С чего ты взял? Мне кажется причину твоего неприятия Делфи следует искать не в самом Делфи, а у тебя в голове.. Может тебя просто в детстве изнасиловал программист на Дельфи?

> Идиотов-разработчиков хватает под любой средой, просто в Делфи проще писать код нормально.

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

> Судя по аргументированности, складывается впечатление, что ты там просто чего-то ниасилил.

Сравни с Tcl/Tk, дебил, тогда узнаешь, что такое "предельно просто".

> просто в Делфи проще писать код нормально.

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

>Ну, надо же.. Оно ещё и развивается.. Завидное упорство, однако.. Не совсем понятно, правда, чем оно могло бы быть обусловлено.

А что, кроме сабжа и Gambas'а под Linux есть, где можно в IDE поставить кнопку на форму, ткнуться в неё, вписать код и запустить результат?

> чем писать парсер опций коммандной строк

getopt и gengetopt давно отменили?

По идее Mono-developer, как форк SharpDeveloper-а, который это умеет, плагины для Eclipse, BoaConstructor для Python. Плюс какой-то коммерческий бейсик. Это из того, что вроде как живое. Но я не видел, чтобы оно пользовалсь большой популярностью.

>По идее Mono-developer, как форк SharpDeveloper-а, который это умеет, плагины для Eclipse, BoaConstructor для Python.

Посмотрю. Хотя тот же monodeveloper щупал - раньше не попадалось.

>Но я не видел, чтобы оно пользовалсь большой популярностью.

Потому что такие фишки полезны для домашнего применения, «за 5 минут слепить расчётную херню для жены» :) Чтобы не тратить 90% времени разработки на описание интерфейса.

Что-то посерьёзнее, понятно, уже и делается иначе.

Вот мне бы не помешало для дома что-то типа сабжа на том же Питоне или C#/Моно. Пойду щупать глубже Монодевелоп :) ...

Для расчетов можно заюзать и ОО - морды там делаются на жабе, питоне, бейсике. Для питона можно заюзать и Глейд, или КуТе-дизайнер, хоуту в нете полно.

>1) Это нормальная практика в любом ЯП. Но, вслучае Делфи далеко не всегда. Ибо она провоцирует на написание логики по двойному щелчку на компоненте. И масса такого кода - тому подтверждение. И провоцирует не только на это.

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

>Для расчетов можно заюзать и ОО - морды там делаются на жабе, питоне, бейсике. Для питона можно заюзать и Глейд, или КуТе-дизайнер, хоуту в нете полно.

Микроскопом можно забивать гвозди, а кухонным ножом производить хирургические операции. Не спорю :)

>ничего она не провоцирует.

Провоцирует и еще как. Я разного кода на делфи повидал.

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

Можно. Но смысла тогда гонять делфи тоже нет. Хватит там баша, awk или еще чего по мелочи.

>Можно. Но смысла тогда гонять делфи тоже нет. Хватит там баша, awk или еще чего по мелочи.

Можно и на bash + zenity. Часто так делаю. Но лобзиком предпочитаю выпиливать, а не дрова пилить :)

Все можно. В свете малопонятности задачи я посоветовал то, что тоже работает по принципу Буттон1Клик. А решать вам.

что ж. Дело вкуса :-). Тем более, что домашние нужды - не производственные.

Всем дельфилазарусоненавистникам! Срочно за клаву!
Задача - написать калькулятор.
Управление калькулятором должно быть:
1. С использованием ГУИ
2. С использованием командной строки
3. С использованием UDP/IP
4. C использованием каналов
5. C использованием разделяемой памяти
7. C использованием локальных сокетов UNIX
8. C использованием HTTP протокола

Кто первый сделает того язык и лучше.
Функции: поддержка битовых операций, 2-й,8-й,10-й,16-й систем.
Поддержка тригонометрических функций.
Испольование RAD обязательно!
Кто быстрее напишет у того RAD лучше!

>Можно. Но смысла тогда гонять делфи тоже нет. Хватит там баша, awk или еще чего по мелочи.

имеет смысл. так как для того и предназначено - быстро наваять морду. А для чего ее делать - это другой вопрос.

>Провоцирует и еще как. Я разного кода на делфи повидал.

То, что ты повидал ни о чем не говорит. Я и на C++ гавна всякого повидал. И что? Язык из-за этого тоже гавно?

>По идее Mono-developer

Посмотрел - нет, и близко не то. Кодом всем всё равно вручную манипулировать надо.

Да, чуть не забыл.
Необходимо также, руководство написать, по использованию калькулятора.
(Включая все способы автоматизации вычислений)
Объем руководства не более 100 стр.
Примеры программирования калькулятора - обязательны.

>Задача - написать калькулятор.

Бедный. Ты до сих пор на бумажке считаешь в столбик?

Лови: http://freshmeat.net/search/?q=calculator&section=projects&Go.x=0&...