Здравствуйте, wamaco, Вы писали: C>>Нет смысла. В современных веб приложениях основная часть кода UI выполняется в браузере. C>>Возможность накидывания контролов на формы тут не панацея.
W>Так финальное приложение и выполняется в браузере. Просто делать такое приложение на UniGUI на порядок быстрее.
Быстрее, до тех пор пока не понадобится изменить клиентский код. Вообще забавная штука, для простых проектов пойдет.
C>Быстрее, до тех пор пока не понадобится изменить клиентский код. Вообще забавная штука, для простых проектов пойдет.
Можно тут по-подробнее... Зачем менять клиентский код?
Для этого есть специалист, который за денежку все поменяет на сервере.
Мы же тут деньги зарабатываем, а не предоставляем клиентский код менять!
Насчет "забавной штуки"... знаю проект, который тянет 600 одновременно работающих клиентов, пишущих и читающих БД.
Нет, т.к. Дельфи то что компилит в нэйтив и потому быстрее явы на андроид например.
Кроме того Дельфи и сам кросс-платформа и потому в одну кросс платформу вставлять другую
это какой-то театр абсурда.
Паскаль плохой — то из 1970 года что ли изречение? какая-то чушь, дельфийская версия просто, мощно, удобно, быстро.
Не понятно о каких таких сложных задачах речь идет, БПФ и DSP и 3D на нем все Ок... компилятор на нем еще 7 летиями
назад как курсовик написан.. что за такие сложны езадачи никак ни в какую не пишушщиеся ну прям ни в какую на Паскале...
Их просто нет, потому тот оратор и не назвал имен, а ограничился обезличенными обвинениями в адрес великого Паскаля
Здравствуйте, Marty, Вы писали:
M>А связь простая. Паскаль не предназначен и не приспособлен для написания чего-то сложного. В юз-кейсе — создать обработчик события контрола и в нем одной строчкой изменить состояние другого контрола — можно и на Паскале писать. Это, собственно, и есть формошлепство.
А что не так-то с Паскалем?
Ну кроме того, что пальцам больно набирать begin/end и когнитивного искажения "если МНЕ неудобно смотреть на begin/end, то всем неудобно".
Здравствуйте, wamaco, Вы писали: C>>Быстрее, до тех пор пока не понадобится изменить клиентский код. Вообще забавная штука, для простых проектов пойдет. W>Можно тут по-подробнее... Зачем менять клиентский код?
Вот пример. Только что нашел у них баг: в окне которое открывается на Show Source Files , после перехода по табам отваливается прокрутка текста колесом мыши. Это в Сафари, а в Хроме все норм. Сколько времени займет поиск и исправление?
Скорее всего намного больше, чем время сэкономленное на "накидывании контролов".
W>Насчет "забавной штуки"... знаю проект, который тянет 600 одновременно работающих клиентов, пишущих и читающих БД.
Интересно, насколько команда Delphi программистов обходится дешевле в сравнении с .NET командой?
M>Что-то более сложное писать на Паскале — это адЪ. Не, если C++ не знаешь, то норм. Но если ты что-то писал на плюсах, а потом нуждажизнь заставила сесть за Дельфи — вот тут и понимаешь глубину своего падения
Угу, почему-то сишные программы тащут мегатонны всяких DLL и фреймворков за собой, в отличие от нативного кода, генерируемого в Delphi.
Здравствуйте, T4r4sB, Вы писали:
M>>А связь простая. Паскаль не предназначен и не приспособлен для написания чего-то сложного. В юз-кейсе — создать обработчик события контрола и в нем одной строчкой изменить состояние другого контрола — можно и на Паскале писать. Это, собственно, и есть формошлепство.
TB>А что не так-то с Паскалем? TB>Ну кроме того, что пальцам больно набирать begin/end и когнитивного искажения "если МНЕ неудобно смотреть на begin/end, то всем неудобно".
Ты еще then/else забыл
Еще я никак не могу запмнить, где там надо ставить ';', а где не надо.
Здравствуйте, T4r4sB, Вы писали:
M>>Ну и вообще, языковые средства крайне убоги
TB>Да что не так-то?
Никогда не пойму почему Delphi вызывает у некоторых такую попоболь. Не нравится, не пользуйся. Но нет, обязательно при каждом упоминании Delphi вылезет кто-то со своим ценным мнением.
Здравствуйте, Kerk, Вы писали:
K>Никогда не пойму почему Delphi вызывает у некоторых такую попоболь. Не нравится, не пользуйся. Но нет, обязательно при каждом упоминании Delphi вылезет кто-то со своим ценным мнением.
Да это с тех времён, когда на Дельфи за 5 минут делали программы с интерфейсом без утечек памяти, в то время, как сишно-крестовое сообщество представляло собой сборище кульных мамкиных какиров с пубертатной психологией, среди которых было круто как можно сильнее задолбать себя вознёй с АПИ, вознёй с управлением памятью. При этом эти какиры были уверены, что Дельфи всей этой возни не умеет.
А уж про то, что на С++ можно использовать деструкторы, не делать грубые касты, и тоже уберечь себя от кучи проблем, те какиры не знали и знать не желали, это же "путь неосилятора".
Здравствуйте, Marty, Вы писали:
M>Хотя сам язык бы давно надо на помоечку. Зря они C++ Builder довеском сделали, был бы основным — имхо летело бы лучше. А Pascal — можно вторым, для формошлепшиков, которые C++ не осилили. Да и расширение — property — довольно удобно, им надо было напрячься и протащить его в стандарт C++
Да не в языке дело. Какая разница, какой пиджак оденет дедушка-пенсионер: вельветовый или парусиновый? Он всё равно останется дедушкой-пенсионером. Так и формошлёпить — можно хоть на Visual Basic, но удобнее-то от этого не становится. Пока проект мал — разницы не чувствуешь, а затем начинается сбор граблей, некоторым из которых лет эдак десять, а то и пятнадцать... Ключевая проблема, что после ухода Хейлсберга никому этот Delphi уже не нужен был в менеджменте компании. Поэтому и не было развития, поэтому и стал он дедушкой. Хоть и подтянули его малость в Эмбаркадеро ребята, но тоже кончился у них интерес.
Здравствуйте, marcopolo, Вы писали:
M>Угу, почему-то сишные программы тащут мегатонны всяких DLL и фреймворков за собой, в отличие от нативного кода, генерируемого в Delphi.
А не приходилось ли многоуважаемому дону жонглировать с порядком установки компонент в палитру Delphi, чтобы открыть проект без ошибок в DFM? Или обращаться с двумя разными проектами, которые ожидали две разные версии одного и того же компонента (и с другим работать не могли)? Ну и рантайм-пакеты — суть те же DLL, их можно статически втянуть, раздувая EXE, либо точно так же тащить за собой, как те самые сишечки
В общем, у Delphi все те же проблемы, что у сишечки, только в профиль.
Здравствуйте, Mr.Delphist, Вы писали:
MD>А не приходилось ли многоуважаемому дону жонглировать с порядком установки компонент в палитру Delphi, чтобы открыть проект без ошибок в DFM?
Было что-то подобное. Но к конечному продукут это не имеет отношения.
\\Или обращаться с двумя разными проектами, которые ожидали две разные версии одного и того же компонента (и с другим работать не могли)?
Проблему с левыми компонентами я иногда решал созданием их в рунтайме.
Ну и рантайм-пакеты — суть те же DLL, их можно статически втянуть, раздувая EXE, либо точно так же тащить за собой, как те самые сишечки
MD>Хоть и подтянули его малость в Эмбаркадеро ребята, но тоже кончился у них интерес.
Главная их ошибка в том что они начали городить какой то там костыльный и бажный FireMonkey параллельно к VCL, вместо того что бы отвязать VCL от WinAPI и сделать ему кроссплатформенный рендеринг.
И получился бы такой себе продвинутый и приятный в использовании аналог QT но на базе VCL.
Здравствуйте, rean, Вы писали:
R>Но не проще ли эти промежуточные стадии выкинуть и сразу использовать HTML и Ajax?
Нет. Для более-менее серьёзной системы любое переписывание это адские затраты. Не только на саму разработку/тестирование, но и на внедрение в первую очередь. Так что финансово это интересный вариант.
Здравствуйте, turbocode, Вы писали:
T>Главная их ошибка в том что они начали городить какой то там костыльный и бажный FireMonkey параллельно к VCL, вместо того что бы отвязать VCL от WinAPI и сделать ему кроссплатформенный рендеринг.
FireMonkey был изначально 3rd-party, как тот же Indy, так что — чему удивляться
Насчёт костыльности — согласен полностью. Этим страдают все "всемогуторы", и даже бережно пестуемый сейчас Xamarin — не исключение.
T>И получился бы такой себе продвинутый и приятный в использовании аналог QT но на базе VCL.
Не получился бы. Там слишком сильно на Win32 API всё завязано, проще всё с нуля.
