Приветствую!
Кто нибудь есть, кто делает и успешно продает shareware используя для разработки Delphi
Поделитесь успешными историями, доходами, "подводными камнями", какого рода программы, используемые технологии VCL,FMX...
Нужно для мотивации!
Здравствуйте, rean, Вы писали:
W>>Поделитесь успешными историями, доходами, "подводными камнями", какого рода программы, используемые технологии VCL,FMX...
R>1. После того, как надо было более 20 контролов визульно перенести с одной формы на другую, сохранив логику работы, я понял всю ущербность визуального программирования. Потом, в течении пары лет глюки отлавливал. То там не работало, то там что-то забыл, то там что-то забыл убрать. Большая часть всех багов, какие я внес сам в программу — это баги ввода новых фич путем изменения форм.
R>2. Стиль 1 форма = 1 исходник = 1 модуль бизнес логики не совместим с продуманным ООП, но совместим с Тяп-Ляп-Ориентированным программированием. В шареваре это особенно актуально, поскольку программа пишется не на один раз. Это придется годами поддерживать и со всеми таким мелочами придется бодаться.
R>3. У меня дельфа периодически вешала систему при отладке. Спасает только кнопка Reset.
R>4. Особо-извращенная эстетика — это когда сидишь и делаешь вручную хидеры из нужного тебе API, и надеешься, что твой перенос не будет содержать никаких ошибок.
R>5. Быстрый наброс кнопок на форму не дает никаких ощутимых преимуществ, потому как это разовая работа. Но если надо быстро прототип сделать — тут по скорости ничто с дельфой не сравнится. Сам язык — так себе. Это какой садист придумал переменные отделять от кода?
W>>Нужно для мотивации!
R>Смысла никакого нет. Если квалификация высокая, то есть C++. Если низкая, то можно и C# попробовать. Но это ИМХО тот же Delphi, только со стероидами, да и еще бесплатно.
Здравствуйте, wamaco, Вы писали:
W>>>Нужно для мотивации!
R>>Смысла никакого нет. Если квалификация высокая, то есть C++. Если низкая, то можно и C# попробовать. Но это ИМХО тот же Delphi, только со стероидами, да и еще бесплатно.
W>да уж! замотивировал, так замотивировал!
В смысле? Баблишка не подкинул, доходом не поделился?
Инструменты вторичны, клиенту плевать на чем сделан продукт, главное чтобы выполнял задачу. Если клиенту нужен меч из валирийской стали, то ему плевать каким молотом он выкован.
QC>Инструменты вторичны, клиенту плевать на чем сделан продукт, главное чтобы выполнял задачу. Если клиенту нужен меч из валирийской стали, то ему плевать каким молотом он выкован.
"из валирийской стали" — это как раз аналог, что продукт написан на Delphi. А молот — это конфигурация использованного компьютера.
Ну и хотелось бы увидеть примеры неглюкавых продуктов, сделанных одним человекам на С* и содержащих несколько десятков используемых форм.
Здравствуйте, wamaco, Вы писали:
W>Приветствую! W>Кто нибудь есть, кто делает и успешно продает shareware используя для разработки Delphi W>Поделитесь успешными историями, доходами, "подводными камнями", какого рода программы, используемые технологии VCL,FMX... W>Нужно для мотивации!
Мы пишем на Delphi уже 17 лет. Успешный профессиональный продукт для домашних пользователей.
Delphi нравится за очень удобный структурированный язык программирования с концепцией юнитов. Очень быстрый компилятор. Не нужно ставить всякие фреймворки для работы программы.
Но мы пишем не используя визуальный редактор. Скоро планируем перейти на Lazarus, т.к. к сожалению новый Delphi и очень дорогой и много глюков (особенно в FMX).
Наш крупный конкурент из Германии создал 5 лет назад свой новый профессиональный продукт на Delphi / FMX. Вроде успешно продают и развивают.
Я считаю, что Delphi / Pascal / Lazarus до сих пор актуальный язык программирования и очень удобный. Если Вы его знаете, то почему бы не продолжать его использование.
Здравствуйте, marcopolo, Вы писали:
M>"из валирийской стали" — это как раз аналог, что продукт написан на Delphi. А молот — это конфигурация использованного компьютера.
Да, неудачный пример, но согласись никто же не ищет "Генератор инвойсов на Дельфи". Ищу просто генератор инвойсов, а на чем он написан дело десятое.
Здравствуйте, Qt-Coder, Вы писали:
QC>Здравствуйте, marcopolo, Вы писали:
M>>"из валирийской стали" — это как раз аналог, что продукт написан на Delphi. А молот — это конфигурация использованного компьютера.
QC>Да, неудачный пример, но согласись никто же не ищет "Генератор инвойсов на Дельфи". Ищу просто генератор инвойсов, а на чем он написан дело десятое.
Ну кто разбирается, тот поймет, что софт не из валирийской стали.
Для каждого софта есть наиболее удачное решение в плане написания, что-то, например, дрова пишутся на С, что-то с вебом на яве.. и т.д. GUI десктоп лучшее Delphi имхо.
Delphi как раз выигрывает тем,что язык с кучей небуквенных символов в операторах потенциально глюкавее.. Как пример, "=", "==", в общем описаться легко, а отладить проблематично.
Здравствуйте, rean, Вы писали:
W>>Поделитесь успешными историями, доходами, "подводными камнями", какого рода программы, используемые технологии VCL,FMX...
R>1. После того, как надо было более 20 контролов визульно перенести с одной формы на другую, сохранив логику работы, я понял всю ущербность визуального программирования. Потом, в течении пары лет глюки отлавливал. То там не работало, то там что-то забыл, то там что-то забыл убрать. Большая часть всех багов, какие я внес сам в программу — это баги ввода новых фич путем изменения форм.
Согласен, но частично. Беда в том, что Delphi не мотивирует использовать разделяющие архитектуры (MVP, MVC, MVVM), и пока кода мало, это не припекает, но затем...
R>2. Стиль 1 форма = 1 исходник = 1 модуль бизнес логики не совместим с продуманным ООП, но совместим с Тяп-Ляп-Ориентированным программированием. В шареваре это особенно актуально, поскольку программа пишется не на один раз. Это придется годами поддерживать и со всеми таким мелочами придется бодаться.
R>3. У меня дельфа периодически вешала систему при отладке. Спасает только кнопка Reset.
R>4. Особо-извращенная эстетика — это когда сидишь и делаешь вручную хидеры из нужного тебе API, и надеешься, что твой перенос не будет содержать никаких ошибок.
Согласен по всем пунктам.
R>5. Быстрый наброс кнопок на форму не дает никаких ощутимых преимуществ, потому как это разовая работа. Но если надо быстро прототип сделать — тут по скорости ничто с дельфой не сравнится. Сам язык — так себе. Это какой садист придумал переменные отделять от кода?
Согласен, но частично. Чистый C (безплюсовый) тоже требует "сначала переменные, затем код". Так что, это лишь исторические корни.
R>Смысла никакого нет. Если квалификация высокая, то есть C++. Если низкая, то можно и C# попробовать. Но это ИМХО тот же Delphi, только со стероидами, да и еще бесплатно.
C# никак не коррелирует с квалификацией: можно говнокодить, можно делать по уму.
Далее, "тот же Delphi, только со стероидами" — это C# WinForms. Сейчас начинать что-то на нём — ну, примерно как если на C++ выбрать MFC. Более актуально — C# WPF, всё очень гибко (визуальные стили а-ля CSS, вёрстка по принципу HTML tables/divs, локализация на разные языки, MVVM и биндинги данных, автоматические конвертеры/форматтеры и т.п.).
Насчёт бесплатности: для дома оно точно бесплатно, а вот для извлечения прибыли — надо проверить условия лицензии. Ну и часть фич в бесплатной версии отсутствует.
Здравствуйте, Mr.Delphist, Вы писали:
MD>Согласен, но частично. Чистый C (безплюсовый) тоже требует "сначала переменные, затем код". Так что, это лишь исторические корни.
В чистом Си переменные можно объявлять в начале блока кода, и сразу же инициализировать. Блок кода — это не только тело функции, это любые {}
Жить можно, вообщем. А в паскале — это долбаное уродство
W>Кто нибудь есть, кто делает и успешно продает shareware используя для разработки Delphi
У меня небольшой проект на Delphi 7 + UniDAC + EurekaLog.
Специализированный софт, работа с железом немного, многопоточность, форм не много.
Никаких пока проблем нет, уже давно перешел на Windows 10 и тоже пока все нормально.
Но о будущем конечно мысли возникают, не без этого
Пока переходить на более новые версии Delphi лень и смысла большого нет.
Потом если уже прижмет задумаюсь или закрою проект.
А вообще у клиентов полно еще Windows XP.
Здравствуйте, Qt-Coder, Вы писали:
QC>Инструменты вторичны, клиенту плевать на чем сделан продукт, главное чтобы выполнял задачу.
Мне не плевать.
При прочих равных я предпочту Билдеру/Дельфям C#, а Шарпу С++. (А джаву предпочту вообще обойти стороной.) Пусть даже продукт будет менее фичастым. Только из-за того что говнокодеров на этих технологиях больше.
R>2. Стиль 1 форма = 1 исходник = 1 модуль бизнес логики не совместим с продуманным ООП, но совместим с Тяп-Ляп-Ориентированным программированием. В шареваре это особенно актуально, поскольку программа пишется не на один раз. Это придется годами поддерживать и со всеми таким мелочами придется бодаться.
Такой подход скорее не инструментарием определяется, а самим разработчиком.
Если сразу сделать правильную базовую библиотеку классов для будущей системы, то все будет ок.
R>5. Быстрый наброс кнопок на форму не дает никаких ощутимых преимуществ, потому как это разовая работа. Но если надо быстро прототип сделать — тут по скорости ничто с дельфой не сравнится. Сам язык — так себе. Это какой садист придумал переменные отделять от кода?
Не вижу в этом проблем, это скорее дело привычки.
Пишу немного на javascript, все так легко и просто, но если ты где то ошибся, это просто ад какой то найти потом ошибку.
R>>>Это какой садист придумал переменные отделять от кода? I>>Не вижу в этом проблем, это скорее дело привычки.
R>Когда программируешь десятки лет на принципиально разных языках, эта особенность раздражает. Напоминает фортран на перфокартах.
Просто не надо делать код методов и процедур слишком большим. Это — не делать большим — полезно, как одна из мер уменьшения вероятности ошибок. А если он небольшой, то переменные получаются близко к коду. Можно также применять вложенные процедуры — вот вам и аналог блоков кода со своими объявлениями переменных. Заодно разобьешь процедуру на подзадачи.
Здравствуйте, rean, Вы писали:
R>Это само собой. Но я имею ввиду 1 форма = 1 исходник — это означает необходимость для всей формы целиком в рамках одного файла писать обработчики для всех контролов. В случае рефакторинга самой формы это выливается в кучу работы, посколько надо выдирать код и переносить по каждому обработчику. Еще есть неприятная особенность сортировки функций по алфавиту, что мешает группировать функции. Если бы можно было делать обработчик на логическую часть формы в своем классе, проблем бы не было.
Здравствуйте, wamaco, Вы писали:
W>Приветствую! W>Кто нибудь есть, кто делает и успешно продает shareware используя для разработки Delphi W>Поделитесь успешными историями, доходами, "подводными камнями", какого рода программы, используемые технологии VCL,FMX... W>Нужно для мотивации!
Ну что я вам скажу про Сахалин, ой Object Pascal.
Это прекраснейший чётко типизированный язык программирования.
Да там нет как-бы таких штук как шаблоны(в чистом виде языка каким я его запомнил),метапрограммирования,всяческого.
Да выражать на нём многие мысли не так удобно как на C++(возможно просто к C++ я привык 20 лет почти как никак кодю ,
а от Делфи отвык на нём отсилы годика два кодил.) VCL присутствует не только в Delphy но и в C++ Borland Builder.
По сути, конечно удобней было в те стародавние времена MSVC + QT, ибо фич больше , код приятней,и много других няшек.
Отладочные символы не отваливаются во время отладки(а это то чем запомнилась отладка и в Delphi и в Builder).
Успешные проекты?Мне похвастаться на делфе совершенно нечем. Хотя попадались в руки поделки в начале 2000-ых,
типа Essential Net Tools, Но интерфейс там был настолько ущербным, что выкинуть их хотелось обычно сразу.
Delphi это язык зоданный для того, что-бы за него можно было посадить кого угодно, но квалифицированные люди рано
или поздно уходили на тот-же С++ Игшдвук к примеру(хотя особой разницы то и нет,кроме одной наличие всех вкусняшек C++).
R>Это само собой. Но я имею ввиду 1 форма = 1 исходник — это означает необходимость для всей формы целиком в рамках одного файла писать обработчики для всех контролов. В случае рефакторинга самой формы это выливается в кучу работы, посколько надо выдирать код и переносить по каждому обработчику.
Чего? Это если писать код прямо в обработчике события (да, да, я тоже этим грешил в былые времена).
По уму в обработчике только вызов функции/метода из модуля с логикой.
Здравствуйте, wamaco, Вы писали:
W>Приветствую! W>Кто нибудь есть, кто делает и успешно продает shareware используя для разработки Delphi W>Поделитесь успешными историями, доходами, "подводными камнями", какого рода программы, используемые технологии VCL,FMX... W>Нужно для мотивации!
Ну вот мой проект тут описывают http://www.manhunter.ru/underground/568_programmi_dlya_zamorozki_vremeni_i_obhoda_trialnih_zaschit.html
Единственное что сделал на Delphi это форму с ListBox-ом , Combobox-ом, драйвера, сервис и библиотеку заморозки естественно
делал на C++. Поскольку это была курсовая когда-то, на интерфейс просто не хотелось тратить время.
Собсно вот интерфейсная часть моего тайм-фрозера HallOfTheMontainKing который.
Проект покачто закрыт. Некогда заниматься такой ерундой. Проблем слишком много.
Здравствуйте, extazy42, Вы писали:
E>Здравствуйте, alfa78x, Вы писали:
A>>Ну кто разбирается, тот поймет, что софт не из валирийской стали.
E>Да, лучше бы подошел пример с твердостью и прочностью металла
Здравствуйте, TMU_1, Вы писали:
TMU>Чего? Это если писать код прямо в обработчике события (да, да, я тоже этим грешил в былые времена). TMU>По уму в обработчике только вызов функции/метода из модуля с логикой.
Плюс наследование форм, плюс фреймы. Архитектура может быть любой. Все средства для этого есть.
Здравствуйте, wamaco, Вы писали:
W>Кто нибудь есть, кто делает и успешно продает shareware используя для разработки Delphi
Делаем и успешно продаём. Начиная с 2003 года. За это время Delphi успели несколько раз похоронить, но это не смущает, если честно, потому как лучшего средства для разработки софта, работающего с СУБД, в мире просто ещё не придумали.
Можно, конечно, и на Java и на .NET рисовать формы к БД, но трудозатраты просто не сравнимы, особенно на Java.
Также успешно пишутся всякие DLL для запуска в качестве веб-сервиса через тот же IIS. Все стабильно работает и не требует 20 человек для кодинга.
Как-то так
И ещё небольшое уточнение.
Недавно Эмба выпустила компилятор для Линукса. Народ на скуле активно плюётся, типа фигня какая-то, asm не красивый генерится. Это же так важно, у нас все заказчики и покупатели софта первым делом проверяют оптимальность сгенерированного компилятором кода, а не функции софта.
Но вот на буржуйских форумах ситуация иная. Внезапно всплыл Крюков (автор FMX) со своим shareware проектом http://www.fmxlinux.com/
Выглядит интересно. Так что Delphi живет и, думаю, будет жить ещё очень долго.
Во всяком случае мы никуда мигрировать не планируем. Всё работает.
Здравствуйте, rkcsoft, Вы писали: R>Но вот на буржуйских форумах ситуация иная. Внезапно всплыл Крюков (автор FMX) со своим shareware проектом http://www.fmxlinux.com/ R>Выглядит интересно. Так что Delphi живет и, думаю, будет жить ещё очень долго. R>Во всяком случае мы никуда мигрировать не планируем. Всё работает.
Ну дык правильно, FMX он же продал несколько лет назад, вот новый проект — EMB потом купит! :D
Ну а по теме, у нас на сайте все на Delphi и Lazarus, драйвера на Си. Менять на что-то другое смысла нет.
Здравствуйте, rean, Вы писали:
R>Это вам не формы 70-х годов на мейнфреймах, когда ввел кучу данных, даже не общаясь с самим ЭВМ, и лишь после нажатия на финальную кнопку понеслось взаимодействие с хостом. Сейчас формы таковы, что любое нажатие на кнопку или перемещение мыши что-то меняет на форме.
И что это меняет? Говнокод можно на любом языке создавать.
Если ты не представляешь как отделить GUI от логики, то видимо квалификация хромает.
Здравствуйте, rean, Вы писали:
R>Перечитайте еще раз, о чем идет речь. А речь идет не о разделении бизнес логики от представления, а о том, что большая часть кода пишется в одном юните. И если представление активно взаимодействует с контролами, то получаем гиганский по размеру исходник.
в одном юните только методы для изменения и отображения состояния бизнес логики
десятки и сотни контролов на одной форме — плохо спроектированный интерфейс
R>А теперь представьте, что на форме десятки контролов, изменение которых в реальном времени должно что-то поменять в бизнес-логике и одновременно еще что-то рисуется и все контролы должны обновить свое актуальное значение.
я примерно лет пять назад так и рассуждал, пока клиент не попросил переделать приложение на системную службу.
это здорово прочистило мозги, теперь вся логика лежит отдельно и работает с тремя фронтендами — служба, вебсервис и десктопное приложение на VCL
при этом возможны варианты — можно запустить как десктопное приложение, а можно как службу, с которой десктопное приложение общается.
интерактивности хоть отбавляй, все работает в реальном времени с потоком данных
Здравствуйте, rean, Вы писали:
R>Именно! Я как раз про это и говорил: дельфа вынуждает держать все контролы в одном юните. Используя невизуальное программирование, я могу разделить интерфейс на четко-ограниченные блоки интерфейса и программировать и отлаживать их отдельно, а в случае необходимости и вовсе заменить на другие.
ну почему же, наследование форм хорошо работает, фреймы есть
да и никто не заставляет ограничиваться визуальным программированием, можно динамически GUI генерировать и на Delphi
R>Это узко-спецализированная область, когда можно четко разделить службу от интерфейса, да и вообще интерфейс выкинуть. В реальной жизни различные архитектурные решения, изобретенные вокруг программирования, очень в редком случае можно применить чисто. Везде вылезают побочные эффекты.
в том то и дело, что это чисто GUI приложение с кучей контролов, графиков, базой данных
сперва казалось что ничего не выйдет, а в результате получилось изящное решение
с юнитами, кстати, возможны интересные решения.
я когда делил софт на платную и бесплатную версии, то сделал так, что функционал платной версии лежит в отдельном юните
и чтобы его добавить нужно просто прописать юнит в uses, после этого появляются новые пункты меню
Здравствуйте, rean, Вы писали:
R>Похоже, что кто-то зациклился ставить оценки другим людям, не вникая в то что он говорит, и считая, что по-умолчанию тот не разбирается в том, что говорит.
я просто говорю тебе, что надо менять подход, а ты все про обработчики
Здравствуйте, rean, Вы писали:
R>Ветка темы посвящена плюсам/минусам. Поэтому и обработчики. Для меня вопрос дельфы решенный. Она меня кормила все эти годы. Но пришло время и больше она мне не нужна. Подходы к программированию тоже вторичны, т.к. шаревара перестала кормить.
Зачем тогда пенять на Делфи, если проблема в шароваре?
Delphi отличный инструмент, не хуже других. Но если кто-то молотком гладит брюки, а утюгом забивает гвозди — разве проблема в молотке и утюге?
Больше 15 лет пишу на Delphi, в основном на заказ. Все довольны, всё работает.
Здравствуйте, rean, Вы писали:
I>>в одном юните только методы для изменения и отображения состояния бизнес логики I>>десятки и сотни контролов на одной форме — плохо спроектированный интерфейс
R>Именно!
Не именно.
Плохо спроектированный интерфейс — проблема не языка, а разработчиков конкретной программы (дизайнера, программера, начальства).
R>Я как раз про это и говорил: дельфа вынуждает держать все контролы в одном юните.
Не вынуждает.
Если тебе IDE первым делом на экране показывают форму и обработчики событий, то это совершенно не означает, что теперь туда нужно запихать всю твою логику.
R>Используя невизуальное программирование, я могу разделить интерфейс на четко-ограниченные блоки интерфейса и программировать и отлаживать их отдельно, а в случае необходимости и вовсе заменить на другие.
Дельфи позволяла неопытным прогерам заниматься формошлепством, особо не изучая матчасть.
Это не означает, что она создавала какую-то искусственную преграду для, как ты выразился, "невизуального программирования". Наоборот, можно разумно комбинировать оба подхода и быстро получать хорошие результаты.
R>>>А теперь представьте, что на форме десятки контролов, изменение которых в реальном времени должно что-то поменять в бизнес-логике и одновременно еще что-то рисуется и все контролы должны обновить свое актуальное значение.
Изучай современные тендеции в UI-строительстве, и будет тебе счастье. Сейчас наоборот всё стремятся упрощать.
Окно с десятками контролов , которые в реальном времени что-то где-то меняют — это как минимум издевательство над юзером.
I>>я примерно лет пять назад так и рассуждал, пока клиент не попросил переделать приложение на системную службу.
Здравствуйте, temnik, Вы писали:
T>Delphi отличный инструмент, не хуже других. Но если кто-то молотком гладит брюки, а утюгом забивает гвозди — разве проблема в молотке и утюге? T>Больше 15 лет пишу на Delphi, в основном на заказ. Все довольны, всё работает.
Скажи, а тебя Дельфи все это время заставляет держать весь код в одном месте с формой? Устал ли ты бороться с непродуманным дизайном Дельфи?
LB>Скажи, а тебя Дельфи все это время заставляет держать весь код в одном месте с формой? Устал ли ты бороться с непродуманным дизайном Дельфи?
Я про другое, вообще-то говорил. У меня весь код в одном месте не лежал никогда. Код гуи отдельно и движок программы отдельно. Между ними минимальная связанность. Но есть и сложные программы, где движок очень маленький, но зато большая часть кода — это возня с контролами. Потому что программа представляет из себя контроллер.
Попробуйте с парочку лет попрограммировать на чем-то, кроме дельфы, и ее недостатки начнете видеть. Я ж тоже подобным образом фанател от нее, пока не познакомился с самыми разными инструментами для разных сред и языков. Программирую я на дельфе примерно с 1997 года. Это еще когда Windows 3.11 был.
Здравствуйте, rean, Вы писали:
R>Попробуйте с парочку лет попрограммировать на чем-то, кроме дельфы, и ее недостатки начнете видеть. Я ж тоже подобным образом фанател от нее, пока не познакомился с самыми разными инструментами для разных сред и языков. Программирую я на дельфе примерно с 1997 года. Это еще когда Windows 3.11 был.
Имхо 95-й у меня был уже в 1996 и работал на 4 Мб памяти со скрипом, и Delphi соответственно.
Здравствуйте, Lazy Bear, Вы писали:
LB>Дельфи позволяла неопытным прогерам заниматься формошлепством, особо не изучая матчасть. LB>Это не означает, что она создавала какую-то искусственную преграду для, как ты выразился, "невизуального программирования". Наоборот, можно разумно комбинировать оба подхода и быстро получать хорошие результаты.
Фи, ничто не мешает создавать контролы динамически, создавать псевдо-контролы (как на картах, где миллионы объектов).
Здравствуйте, rean, Вы писали:
LB>>Окно с десятками контролов , которые в реальном времени что-то где-то меняют — это как минимум издевательство над юзером.
R>Это надо додуматься придумывать всякую чушь про меня ))
Это ты сказал про форму с десятками контролов, я ничего не придумывал даже
Здравствуйте, rean, Вы писали:
LB>>Скажи, а тебя Дельфи все это время заставляет держать весь код в одном месте с формой? Устал ли ты бороться с непродуманным дизайном Дельфи?
R>Я про другое, вообще-то говорил. У меня весь код в одном месте не лежал никогда. Код гуи отдельно и движок программы отдельно. Между ними минимальная связанность. Но есть и сложные программы, где движок очень маленький, но зато большая часть кода — это возня с контролами. Потому что программа представляет из себя контроллер.
Да хоть что она пусть из себя представляет! На любом языке можно написать и хорошо и отстойно. Как с приготовлением еды. Нужно просто уметь готовить.
R>Попробуйте с парочку лет попрограммировать на чем-то, кроме дельфы, и ее недостатки начнете видеть. Я ж тоже подобным образом фанател от нее, пока не познакомился с самыми разными инструментами для разных сред и языков. Программирую я на дельфе примерно с 1997 года. Это еще когда Windows 3.11 был.
Дорогой вдруг! Я программирую примерно с 1989 года, это когда Win 3.0 еще только наклевывался. С Delphi начал как только она появилась в 1995-м, а закончил примерно в 2008-м. Так что и разные платформы и языки имею возможность сравнивать.
Здравствуйте, rean, Вы писали:
LB>>Дорогой вдруг! Я программирую примерно с 1989 года, это когда Win 3.0 еще только наклевывался. С Delphi начал как только она появилась в 1995-м, а закончил примерно в 2008-м. Так что и разные платформы и языки имею возможность сравнивать.
R>И с таким опытом не видите, дорогой дружбан, недостатков? И ни разу не видели сто контролов в рамках одного окна?
Если голову не включать, то можно и тысячу контроллов тупо в визуальном дизайнере на форму накидать. Но программисты обычно склонны как-то структурировать свою работу.
Здравствуйте, Kerk, Вы писали:
K>Если голову не включать, то можно и тысячу контроллов тупо в визуальном дизайнере на форму накидать. Но программисты обычно склонны как-то структурировать свою работу.
Да просто мужчина похоже делал интерфейс для какой-то большой железки — станка или автоматизированной химлаборатории, такие задачи встречаются одна на сто тысяч, что тут спорить.
Здравствуйте, telavi, Вы писали:
T>Здравствуйте, Lazy Bear, Вы писали:
LB>>Дельфи позволяла неопытным прогерам заниматься формошлепством, особо не изучая матчасть. LB>>Это не означает, что она создавала какую-то искусственную преграду для, как ты выразился, "невизуального программирования". Наоборот, можно разумно комбинировать оба подхода и быстро получать хорошие результаты.
T>Фи, ничто не мешает создавать контролы динамически, создавать псевдо-контролы (как на картах, где миллионы объектов).
Здравствуйте, rean, Вы писали:
LB>>Дорогой вдруг! Я программирую примерно с 1989 года, это когда Win 3.0 еще только наклевывался. С Delphi начал как только она появилась в 1995-м, а закончил примерно в 2008-м. Так что и разные платформы и языки имею возможность сравнивать.
R>И с таким опытом не видите, дорогой дружбан, недостатков?
Недостаток у Дельфи есть один, но фатальный — она всегда в роли догоняющей новые технологии. Например, MS выпускает новую библиотеку, хоть визуальную, хоть не визуальную. Одновременно появляется VS, где это все есть "из коробки". А с Дельфи сиди и жди год-другой, пока они разродятся. Ну и так далее.
А так система сама по себе была замечательная.
Разработка компонентов, например, очень хорошо позволяла прочистить мозги и понять, как надо и как не надо проектировать библиотеки.
R>И ни разу не видели сто контролов в рамках одного окна?
Да видел когда-то, уродство то еще.
Если авторы продукта не умеют пользоваться инструментом, то это проблемы авторов, а не инструмента.
R>Братуха, продолжайте программировать под DOS.
Хорошая шутеечка, братан. Живот от смеха лопается.
Кстати, под DOS был замечательный Turbo Pascal с не менее замечательным Turbo Vision.
Здравствуйте, rean, Вы писали:
K>>Если голову не включать, то можно и тысячу контроллов тупо в визуальном дизайнере на форму накидать. Но программисты обычно склонны как-то структурировать свою работу.
R>Посчитайте количество контролов в этом браузере. Удивитесь. Не забудьте сюда приплюсовать пункты меню, всевозможные надписи. Все это само собой не появляется в дельфе.
Это все должно быть культурно распределено по разным классам и файлам. Хоть в дельфевом проекте, хоть в каком другом. Иначе замучаешься поддерживать такое поделие.
R>И это должно содержаться в рамках одного dfm файла. Откройте окно настройки для несложных программ. И там посчитайте. И это также должно содержаться в одном dfm файле.
Нет, не должно. Если ты был вынужден так делать, то это не значит, что такой способ — единственный и тем более правильный.
Никто не запрещает создать сколь угодно навернутый визуальный контрол с нужной функциональностью и держать его в отдельном классе (или классах), а в рантайме добавлять его на форму. И в dfm ни слова о нем не будет!
Кстати, сюрприз — в VCL компоненты разбиты на классы. TForm, TButton, TPanel и т.д. Странно, почему же Дельфи весь их исходный код не кладет в твой dfm и его юнит. Ведь все же "должно содержаться в одном dfm файле", да?
R>Случаи, когда мы можем обойти это средствами системы не рассматриваем (в Win32 любое окно можно подцепить к любому другому) — это не заслуга дельфы, и это еще надо запрограммировать.
Delphi не запрещает делать то же самое. Можно писать на чистом Win32 API.
Здравствуйте, rean, Вы писали:
LB>>Это все должно быть культурно распределено по разным классам и файлам. Хоть в дельфевом проекте, хоть в каком другом. Иначе замучаешься поддерживать такое поделие.
R>Я про это и говорил и с этим я столкнулся на своем опыте — именно сложность поддержки визуального монолита. Наконец вы меня услышали.
Я вообще-то ни разу не возражал по поводу того, что если все напихать в один файл, то получится ужас.
Проект нужно разбивать на самостоятельные компоненты. Дельфи это дело очень поощряет.
R>Теперь вы можете видеть то, что препятствует этому — архитектура VCL — 1 форма = 1 dfm файл. А дальше в вашем сообщении методы, как это обойти, строя себе дополнительные трудности.
Из того, что при создании новой формы через IDE Delphi создается и сопутствующий ей dfm, совершенно не следует, что теперь все обязаны весь свой код писать в классе этой формы.
Вообще-то форма может и не иметь dfm. Не хотите dfm — делайте все ручками, невизуально, как вы это любите, никто не запрещает. Просто IDE для вашего же удобства автоматически создает вам один из строительных блоков для вашей программы. Один из, Карл! Дельфи не может отвечать за то, насколько рационально этот блок (или любой другой) будет использован программистом.
R>Формально, любой недостаток в любой архитектуре можно преодолеть теми или иными способами. Но сам факт, что это надо обходить, говорит о неприспособленности архитектуры.
Ничего не надо обходить. Архитектура Дельфи предоставляет огромную гибкость в выборе подхода. Грубо говоря, можно легко комбинировать Win32, пресловутое формошлепство и модульность в любых пропорциях. Нежелание кого-либо это понять, принять и использовать на практике никак не повлияет на то, что такая замечательная возможность у инструмента все равно есть.
R>Так что не надо мне писать в духе «я вирутоз и могу извратиться, а дельфа мне не мешает в этом. Я даже на ассемблере в ней могу программировать и в потенциале могу сделать из нее все что угодно. А ты все делаешь неверно и вообще не разбираешься в дельфе».
Судя по вашим заявлениям, вы, к сожалению, не разбираетесь не только в Дельфи, но и в других инструментах тоже...
Здравствуйте, rean, Вы писали:
K>>Если голову не включать, то можно и тысячу контроллов тупо в визуальном дизайнере на форму накидать. Но программисты обычно склонны как-то структурировать свою работу.
R>Откройте окно настройки для несложных программ. И там посчитайте. И это также должно содержаться в одном dfm файле.
Хм, у меня окна настроек кода практически не содержат
Здравствуйте, rean, Вы писали:
R>Я про это и говорил и с этим я столкнулся на своем опыте — именно сложность поддержки визуального монолита. Наконец вы меня услышали. Теперь вы можете видеть то, что препятствует этому — архитектура VCL — 1 форма = 1 dfm файл.
Визуальные компоненты, наследование форм, фреймы, создание контроллов в рантайме — это уже не архитектура VCL?
Здравствуйте, Kerk, Вы писали:
K>Здравствуйте, rean, Вы писали:
R>>Я про это и говорил и с этим я столкнулся на своем опыте — именно сложность поддержки визуального монолита. Наконец вы меня услышали. Теперь вы можете видеть то, что препятствует этому — архитектура VCL — 1 форма = 1 dfm файл.
K>Визуальные компоненты, наследование форм, фреймы, создание контроллов в рантайме — это уже не архитектура VCL?
Нет же ж! Архитектура VCL — это когда все должно быть в одном dfm, ибо Дельфи заставляет!!!111
Здравствуйте, wamaco, Вы писали:
W>Приветствую! W>Кто нибудь есть, кто делает и успешно продает shareware используя для разработки Delphi W>Поделитесь успешными историями, доходами, "подводными камнями", какого рода программы, используемые технологии VCL,FMX... W>Нужно для мотивации!
Привет
Считаю что Дельфи — отличный язык/среда для быстрого прототипирования. Как раз то что нужно для шаревары.
Самое главное здесь — быстро проверить идею. Плюс приложение получается легковесное, обычно из одного экзешника, без всяких .net-фреймворков, которые надо тянуть с собой и интерпретаторов.
Потом, когда и если идея "выстрелит", можно переписать на чем-то более удобном для дальнейшей поддержки.
Вам уже будут знакомы все подводные камни разработки вашего продукта, поэтому это не займет времени.
Здравствуйте, Михaил, Вы писали:
М>Потом, когда и если идея "выстрелит", можно переписать на чем-то более удобном для дальнейшей поддержки. М>Вам уже будут знакомы все подводные камни разработки вашего продукта, поэтому это не займет времени.
Задлянафига?!?
Если идея выстрелила на Delphi, за неё УЖЕ платят, зачем что-то переписывать, что за вечная российско-мелкомягкая идея фикс NIH? Вглубь нужно копать, инвалиды (с), а не на ещё одном framework переписывать то, что уже приносит деньги.
Здравствуйте, rkcsoft, Вы писали:
R>Здравствуйте, Михaил, Вы писали:
М>>Потом, когда и если идея "выстрелит", можно переписать на чем-то более удобном для дальнейшей поддержки. М>>Вам уже будут знакомы все подводные камни разработки вашего продукта, поэтому это не займет времени.
R>Задлянафига?!? R>Если идея выстрелила на Delphi, за неё УЖЕ платят, зачем что-то переписывать, что за вечная российско-мелкомягкая идея фикс NIH? Вглубь нужно копать, инвалиды (с), а не на ещё одном framework переписывать то, что уже приносит деньги.
В двух случаях: или когда столкнетесь с какими то фрейворками, которые из делфи использовать очень проблематично или Если будете путаться в написанном г**не в процессе улучшения-развития.
А так, разумеется, переписывание ради внутренней красоты — глупое занятие. Месседж был что в случае необходимости заменить фреймворк не будет проблемой.
Здравствуйте, Михaил, Вы писали:
М>В двух случаях: или когда столкнетесь с какими то фрейворками, которые из делфи использовать очень проблематично или Если будете путаться в написанном г**не в процессе улучшения-развития.
Это какие такие фреимворки из Делфи использовать проблематично? Я не стебусь, мне правда интересно. И, я надеюсь, вы не будете всякое Java/.Net наследие пытаться заюзать в Дельфи из коробки? Ну а уж если вы про смену десктопа на веб, то тут я просто промолчу
Ну а по поводу г..на: просто не пишите так с самого начала, и проблем станет значительно меньше
Здравствуйте, rkcsoft, Вы писали:
R>Здравствуйте, Михaил, Вы писали:
М>>В двух случаях: или когда столкнетесь с какими то фрейворками, которые из делфи использовать очень проблематично или Если будете путаться в написанном г**не в процессе улучшения-развития.
R>Это какие такие фреимворки из Делфи использовать проблематично? Я не стебусь, мне правда интересно. И, я надеюсь, вы не будете всякое Java/.Net наследие пытаться заюзать в Дельфи из коробки? Ну а уж если вы про смену десктопа на веб, то тут я просто промолчу
codejock, sciter, всякие красивые графики и контролы в стиле ribbon?
R>Ну а по поводу г..на: просто не пишите так с самого начала, и проблем станет значительно меньше
ну пишите, кто ж вам мешает
прототипы делаются на скорую руку, а дельфи не очень способствует качеству кода.
Михаил, перестаньте, вы делаете мне смешно.
Codejock — это последнее, что стоило бы упоминать как недостаток дельфи. Откройте для себя devexperess.
По поводу качества кода: если у вас (ваших коллег) кривые руки, отсутствие знаний о книгах банды четырёх, Фаулера, Макконела и всех их собутыльников, то тут ни я, ни кто либо другой вам не в силах помочь.
Здравствуйте, rkcsoft, Вы писали:
R>Михаил, перестаньте, вы делаете мне смешно. R>Codejock — это последнее, что стоило бы упоминать как недостаток дельфи. Откройте для себя devexperess.
R>По поводу качества кода: если у вас (ваших коллег) кривые руки, отсутствие знаний о книгах банды четырёх, Фаулера, Макконела и всех их собутыльников, то тут ни я, ни кто либо другой вам не в силах помочь.
Здравствуйте, Lazy Bear, Вы писали:
LB>Недостаток у Дельфи есть один, но фатальный — она всегда в роли догоняющей новые технологии. Например, MS выпускает новую библиотеку, хоть визуальную, хоть не визуальную. Одновременно появляется VS, где это все есть "из коробки". А с Дельфи сиди и жди год-другой, пока они разродятся. Ну и так далее.
Большой вопрос в необходимости этих новомодных библиотек. Что-то нужное было выпущено после 2000 года?
У нас отличный продукт на Delphi, сейчас мигрируем на Lazarus.
Я совершенно не понимаю критику языка Delphi (Object Pascal). Прекрасный язык, строгая иерархия модулей помогает правильно структурировать код. Компилятор работает быстрее C компиляторов в 10-100 раз (без преувеличения). У меня получается хороший, не так много ошибок, я не трачу время ожидая компиляции.
Здравствуйте, PeterOfLight, Вы писали:
POL>Я совершенно не понимаю критику языка Delphi (Object Pascal).
Абсолютно согласен. Язык просто отличный. Нарекания только к исполнению в виде Delphi от Embarcadero. Лазаря, если честно, глубоко не копал. Дальше HelloWorld не пошло, не требовалось. Те два пользователя из нескольких сотен/тысяч, которые хотят под Linux, могут и под Wine запустить приложение. Им все равно делать нечего, судя по моему опыту.
Здравствуйте, Marty, Вы писали:
M>Здравствуйте, Mr.Delphist, Вы писали:
MD>>Согласен, но частично. Чистый C (безплюсовый) тоже требует "сначала переменные, затем код". Так что, это лишь исторические корни.
M>В чистом Си переменные можно объявлять в начале блока кода, и сразу же инициализировать. Блок кода — это не только тело функции, это любые {}
Откуда ж вы такие беретёсь...
Где угодно можно переменные объявлять, т.к. C99 появился 20 лет назад
R>По поводу качества кода: если у вас (ваших коллег) кривые руки, отсутствие знаний о книгах
А с Generic там нет проблем ?
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
M>>В чистом Си переменные можно объявлять в начале блока кода, и сразу же инициализировать. Блок кода — это не только тело функции, это любые {}
IID>Откуда ж вы такие беретёсь... IID>Где угодно можно переменные объявлять, т.к. C99 появился 20 лет назад
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
, которые в реальном времени что-то где-то меняют — это как минимум издевательство над юзером.
