Gambas 2.6.0

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

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

мой бог... Тут, конечно, не видно что должно делаться, но на дельфе/lazarus'e такое накидывается минут за 5 ^_^

>Тут, конечно, не видно что должно делаться, но на дельфе/lazarus'e такое накидывается минут за 5

Бугага. Тройное.

>>Тут, конечно, не видно что должно делаться, но на дельфе/lazarus'e такое накидывается минут за 5

>Бугага. Тройное.

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

> убога пишется раздельно

1) Что тебе не понятно? Из запроса (select который) на основе данных формируется гуй - не только то, что тут, а и все диалоги. И чтоб описать то, что мне нужно уходит минут 5-7. А на делфи гораздо сложнее все делается - опыт у меня есть, так что могу сравнить.

2)

> дельфе/lazarus'e такое накидывается минут за 5

Не поверю. Если простелькая мордашка, то да, табы с сеткой накидать много ума не надо. А потом присобачь соединение с СУБД, сделай формы, чтоб данные забивать - что-то такое, что показано на моем старом скрине - http://www.linux.org.ru/view-message.jsp?msgid=1864318. Не забудь, что прога на разных разрешениях работать должна - тут делфи с лазарем в большой жопе были (есть???) - из-за отсуствия менеджеров геометрии. А теперь представь, что тебя срочно поросили добавить новое поле или поменять порядок существующих полей. Через декларативное описание я это сделаю за несколько секунд, пользователю даже выходить из проги не нужно - все автоматически поменяется. А теперь сделай это на делфи. И не забудь таб ордеры переправить ;)

Чем убога?

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

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

4.2

>А теперь представь, что тебя срочно поросили добавить новое поле или поменять порядок существующих полей. Через декларативное описание я это сделаю за несколько секунд, пользователю даже выходить из проги не нужно - все автоматически поменяется. А теперь сделай это на делфи. И не забудь таб ордеры переправить ;)

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

> 4.2

В 7-ке их не было. Якоря не в счет.

> Я уверен что ты создал в 10 раз больше проблем чем решил.

А я уверен, что решил 95% типовых проблем, которые в делфи решаются обычной рутиной. Для решения остальных 5% можно и ручками сделать. Система уже больше года работает и проблем особых не возникает. На делфи хуже было.

>Я уверен что ты создал в 10 раз больше проблем чем решил.

А я нет. И?

>>Я уверен что ты создал в 10 раз больше проблем чем решил.

>А я нет. И?

Если заказчик спускает свой самописанный фреймворк для динамической генерации формочек из xml файлов это верная примета что надо сваливать из проекта. Не разу не был неправ.

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

>Угу, когда тебя ткнули носов с вобственную какашку, так и сходил на википедию

Ткнули носом в какашку тебя.

> Интересно, есть ли само по себе разница, каким методом они взаимодействуют?И прошу, четкие определения, почему wrapper - это костыль. anonymous (*) (12.05.2008 11:18:43)

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

Мдя:) Вот и результат быдлокодерства:)

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

зы: но для небольшого "живого" фронтенда глейды рулят (в qt тоже чето подобное есть, но я там нуб)

бррр... Повторюсь - работа с СУБД - самая сильная сторона Delphi/Lazarus'a... Переопределить поля - так их можно заставить выставляться автоматически (тот же DBGrid + DataSource + DataSet) и рисовать, скажем, checkbox'ы для булевых полей... Соединение с БД - 0.o Компонент на форму и готово... Или у вас там поддержка кучи БД? Да тоже легко реализуемо - просто несколько компонент ^_^ Разрешения - 800*480 на EeePC и 1024*768 на основной машине - никаких проблем не вижу что при развёрнутых, так и обычных окнах... Создания форм для заполнения БД - ну блин, ведь халява же!
В общем, ИМХО, Вы просто не работали с БД в Delphi... Это просто и приятно ^_^ ГУЙ навроде того что на скрине - действительно дело пяти минут... Функционал - неделю свободными вечерами, а то и меньше... Хотя точно не знаю, что там у Вас делается ^_^

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

> Список языков со ссылочной моделью и автоматической сборкой мусора:

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

>Ссылка - не просто указатель, который нельзя вычитать и преобразовывать к числу.

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

> Переопределить поля - так их можно заставить выставляться автоматически

У меня тоже можно. В том числе и в рантайм. А теперь перераспредели их в диалогах. Да когда их с два десятка.

> 1024*768 на основной машине - никаких проблем не вижу что при развёрнутых, так и обычных окнах

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

> Создания форм для заполнения БД - ну блин, ведь халява же!

Какая халява?

> В общем, ИМХО, Вы просто не работали с БД в Delphi.

Года 4 на нее потратил.

Впрочем, плыли если просто накидать на формочку. Если с якорями начинать играться - то плыли редко. Но якорей мало.

>Ссылок в D вообще нет и из-за этого появляется несколько проблем.

Из-за этого *решается* несколько проблем.

> А оно надо? Любой вменяемый "скриптовый" (по Вашему определению) язык обладает уймой расширений, прописанных на....си, как ни странно. Если расширение существует - оно заккчивается и используется. Ежели расширения нет и оно сильно надо -

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

>пишется самостоятельно, согласно прилагаемой документации (опять жеж на си).

Тогда вообще смысла нет-тот кто знает си будет писать на с.

>ЗЫ Вызывать из васька, по определению не имеющего указателей, системные функции, или переписывать на васек сишные хидеры - то еще удовольствие. ИМХО само умрет.

Речь шла о паскале, там есть указатели.

> ГУЙ навроде того что на скрине - действительно дело пяти минут...

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

И за 4 года в Delphi не смогли реализовать то, что получилось в Питоне за месяц? Или не пытались? ^_^ Динамически создавать и размещать виджеты на форме можно и в Delphi, и в Lazarus'e ^_^ Если Вам нужна динамическое "интеллектуальное" размещение виджетов, когда изначально неизвестно сколько их, то *подсказка* создание формы в design-time не подходит ^_^ Но это не значит, что оно (design-time) вредно, или что требуемая задача не решаема в Delphi... И более чем уверен, что времени бы ушло ничуть не больше (хотя за неделю бы с таким действительно вряд ли управились ^_^ Но я и говорил что точно не знаю что там у вас делается). По поводу шрифтов - изначально 10, поставил 18 - никаких проблем... На 48 - всё разъехалось ^_^ Тут да, действительно, подкачал Lazarus... Но, ИМХО, это не та проблема, из-за которой нужно отказываться от разработки в Design-time ^_^ Справедливости ради - центр настроек KDE тоже стал не особо удобочитаемым ^_^ Да и решается это дело банальной пробежкой по компонентам на FormCreate...

А вообще, как я уже сказал, в освновном я дизайнер форм использую для задания главного меню и toolbar'a... Плюс, основные формы раскидываю, ну и прочее по мелочи, если форма диалоговая и заранее известно, сколько полей заполнять нужно... Можно всё это сделать и в run-time в Lazarus'e, но зачем? Пока только шрифты увидел в аргументах ^_^

> И за 4 года в Delphi не смогли реализовать то, что получилось в Питоне за месяц?

Смог бы. Но со значительно большими затратами времени и нервов.

> Если Вам нужна динамическое "интеллектуальное" размещение виджетов, когда изначально неизвестно сколько их,

Именно.

> то *подсказка* создание формы в design-time не подходит Но это не значит, что оно (design-time) вредно, или что требуемая задача не решаема в Delphi...

1) Решаема, конечно. Но на питоне намного проще. 2) И design-time я тоже пользуюсь - glade там всяким. Но для чего-то, что не требует автоматической генерации из заранее неизвестных данных.

> По поводу шрифтов

96 точек на дюйм не едет. 120 - сразу едет. Но я уже писал, что если использовать якоря то проблема остро не стоит.

ну вот и славно ^_^ На питоне действительно, вполне возможно что и проще подобное реализовывать - всё-таки поновее язык (а они всё время на упрощение идут), но ведь и быстродействие, и ресурсоёмкость разная... Так что - выбор не очевиден ^_^ А речь изначальна шла, что гуепостроители - вселенское зло и что любой программист должен описывать GUI _исключительно_ из кода (цитаты точные влом искать, но смысл примерно такой)... Я так не считаю, и Вы, раз пользуетесь, тоже ^_^ Значит договорились ^_^

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

> А речь изначальна шла, что гуепостроители - вселенское зло и что любой программист должен описывать GUI _исключительно_ из кода

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

> но ведь и быстродействие, и ресурсоёмкость разная...

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

> На питоне действительно, вполне возможно что и проще подобное реализовывать - всё-таки поновее язык (а они всё время на упрощение идут),

Кстати, в питон для этой задачи есть два больших недостатка - динамическая типизация и отсуствие макросов, как в лиспе. В следующий раз на лиспе или f#/ocaml подобную задачу решать буду.

да удавись, базы данных это самая слабая сторона делфей, а в лазаре их вообще нет.

>О... быдлокрасноглазие так и хлещет. Выйди из 30-летнего анабиоза иоткрой для себя визуальное программирование. anonymous (*) (12.05.2008 14:29:50)

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

> да удавись, базы данных это самая слабая сторона делфей, а в лазаре их вообще нет.

+1. Кроме фаст репорта.

>да удавись, базы данных это самая слабая сторона делфей, а в лазаре их вообще нет. anonymous (*) (12.05.2008 17:48:35)

Есть.

>Я не говорю даже про быдлоделфи/паскакал - там вроде бы ссылки есть, а сборку мусора нельзя сделать ПРИНЦИПИАЛЬНО.

anonymous (*) (12.05.2008 15:19:26)

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

>>Я не говорю даже про быдлоделфи/паскакал - там вроде бы ссылки есть, а сборку мусора нельзя сделать ПРИНЦИПИАЛЬНО.

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

А в Джаве автоматический вызов деструктора стало быть есть?

>А в Джаве автоматический вызов деструктора стало быть есть? Absurd * (*) (12.05.2008 18:18:00)

Да, и в джаве и дотнете есть - метод virtual void finalize()- кстати и называется одинаково:).

>>А в Джаве автоматический вызов деструктора стало быть есть? Absurd * (*) (12.05.2008 18:18:00)

>Да, и в джаве и дотнете есть - метод virtual void finalize()- кстати и называется одинаково:).

В Джаве это полу-deprecated фича. Да и не деструктор это совсем - его только для диагностики можно использовать.

вы бы еще делфи 5 вспомнили. сейчас 11-я версия, скоро 12-я выйдет. а добавилось там ОЙ как много чего хорошего

> Ткнули носом в какашку тебя.

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

> Ты что, даже не понимаешь как происходит вызов функции из библиотеки в низкоуровневых языках? Срочно учи матчасть.

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

> Мдя:) Вот и результат быдлокодерства:)

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

Принципиальное отличие: ссылка - псевдоним переменной. Нельзя производить операции напрямую со ссылками (кроме присваивания). Все операции перенаправляются переменной, включая операцию определения ссылки. Поэтому (в предполагаемом синтаксисе D2): typeof(ref ref ref ref ref ref ref x) == typeof(ref x)

Указатель - такая же переменная, как и все остальные и к ней применимы (почти) все обычные операции по обычным правилам.

>бррр... Повторюсь - работа с СУБД - самая сильная сторона Delphi/Lazarus'a...

В это в 1998 году ещё можно было поверить - сегодня - нет ! :)
Да ты просто слаще морковки ничего не пробовал. Очень рекомендую поробовать Hibernate к примеру - у тебя будет шок. Поймешь что потратил свои лучшие годы пожирая унылое дерьмо :) Правда придется Java подучить - под дЁльфиЫ современных нехнологий не бывает :)

Это различия в синтаксисе языка С/С++, скажем. Тут ты прав полностью. Мы же говорили про принципиальное отличие "ссылок" в Java от указателей в С++. Я утверждаю, что, окромя синтаксических различий, на низком уровне разницы нет - один фиг адрес нужно хранить.

> Я утверждаю, что, окромя синтаксических различий, на низком уровне разницы нет

Да. После компиляции указатель и ссылка - одно и то же.

>Я утверждаю, что, окромя синтаксических различий, на низком уровне разницы нет - один фиг адрес нужно хранить.

В Java GC умеет перемещать объекты. Как он это делает - не углублялся, но при С и С++ моделях пямяти где "адрес" - это индекс в огромном массиве байт это тяжело наверно сделать.

>> Ты что, даже не понимаешь как происходит вызов функции из библиотеки в низкоуровневых языках? Срочно учи матчасть.

> Ты, малолетнее быдло. Да, ты. Я в какомто месте написал хоть строку про вызовы из незкоуровневых языков? Или ты грибов объелся и тебе что-то мерещится?

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

>> Мдя:) Вот и результат быдлокодерства:) > Иди вон, подрочи на книжку по паскалю.

Запущенный случай быдлокодерства:-))

В Java всё просто. Виртуальный адрес обьекта никогда не меняется. А физический адрес может изменяться при работе GC. При этом нужно только обновить одно значение в таблице адресов.

В C++/D теоретически можно сделать compacting GC и без виртуальных адресов, но с некоторыми ограничениями. Тогда придётся следить за всеми ссылками и обновлять их все. А за указателями ввиду, например, pointer arithmetic следить невозможно.

>Иди вон, подрочи на книжку по паскалю. А потом не забудь поплакаться в жилетку тому пидору, который тебе рассказал всякие глупости, быдлятинка. anonymous (*) (12.05.2008 19:55:10)

Онанист-даун, 6лин. А ты иди дрочи на своего питона, пионэр несчастный:-))

Визуальное программирование c генерацией вспомогательных файлов данных-каменный век:) Это было в начале 90-х очень модно. Cовременные тендеции противоположные.

Объясните, чем плоха свобода выбора? Ну пусть кто-то рисует кнопочки в Дельфе, вам-то что? Эти люди в любом ЯП, любом инструменте УГ сотворят.

Я вообще в С++ new и delete использую и не жалуюсь, мне GC не нужен - это же не повод орать "жаба тормозное говно!"...

ЗЫ naryl, назови хоть один КРУПНЫЙ проект на D. Зачем вообще он, в наш век C# + Mono || Java || C++ + QT?

> В это в 1998 году ещё можно было поверить - сегодня - нет ! :)

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