Интелигентные люди завидуют молча   

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

Угу, что же они отказались от паскаля?.. =)

Там код написан на Apple Pascal который к дельфи никаким боком не относится.



Вслед за генеральной линией партии (Эпл прекратила разработку этой поделки).

Вообще к паскалям у меня положительное отношение. Мне не нравится семейство Delphi (+lazarus, есть ещё аналоги и не только на паскале), его идеология.

Всплыл в уме такой вопрос. Понятное дело, что когда Delphi серьезных конкурентов по бросанию на форму не имела и массово преподавалась в вузах (у меня в начале 2000-ых была D2, потом в 2004/2005 уже семерка), то число быдлокодеров было велико, спрашивали на форумах, как курсовую сделать и т. п. Ну вот вышла .NET со своим C#, на который "крутые сишники" тут же побежали стадом, младший брат в институте уже этот самый шарп изучал, Борланд же зверски тупила, в общем имеем, что имеем, сейчас C# в лидерах, но я вот никогда не слышал, чтобы кодящих на шарпе называли быдлокодерами. Почему так? Надоело всем холиварить? Меньше стало программеров, или просто барьер вхождения все равно слишком высок, чтобы появлялись перцы спрашивающие про компонент (с этим, как я понимаю в .NET не фонтан) для написания операционной системы?

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

Это сообщение отредактировал(а) Zloxa - 5.4.2013, 13:13

 А вообще есть ктото кто нигде, ничего не позаимствовал? Ну кроме Асемблера   Да и то неуверен.
 Помоему в дотнете "бросание на форму" уже давно не главное. Все новые технологии WPF, MVC и так дальше, уже от этого не особо торчат. Да и в старых WinForm, WebForm просто так бросанием можно было сделать только тривиальное унылое г.

Просто так получилось что те которые делают дело, довольны собой и своей технологией. А остальные на настоящий холивар не способны.   

Вот это и не навижу. Считаю - в том виде, что есть в delphi - тупиковый быдло-код!
Ну не серьёзно, умный дядька "натыкивает" формочки! А не ГУИ компоненты, так, простите, пипец!..   

Я вот о Delphi холиварить вообще никак не могу. Мой жизненый путь C -> C++ -> C#+Web   
Так же о чём ничего не знаю, молчу.

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


Прочитал статью и вспомнил реальный случай... Был у нас в Ашхабадском армейском корпусе офицер при больших звездах, вся изначальная служба которого до академии проходила исключительно в НИИ. Как-то командир, генерал-лейтенант Шеин, поручил ему "исполнение" обычной войсковой дороги на полигоне. Через неделю приехал... под ворохом расчетов и завалами теодолитов чуть-чуть торчала одухотворенная макушка "прораба". Ни метра дороги и не килограмма перекинутого грунта. Рёв Борис Петровича заставил отбросить хвосты даже варанам, - Субачев!!! Подскочил крепенький майор с "бычьим глазом" на груди (для непосвященных- знак об окончании не высшего, а просто военного училища)...- Даю сутки! На что последовала рука к козырьку и слово "Есть!" А далее Володя сам сел за рычаги инженерной техники и отвалом за несколько часов "пробил" в песках требуемую дорогу. Вот и все. Это к тому, что расчеты и прочие теоретические изыски- вещь, конечно, необходимая. Но суровая правда жизни говорит о том, что последнее слово должно быть за практиками. Кстати, тот же Субачев, подойдя к четырем минным тралам, притащенным к нам на испытание опять же из какого-то там НИИ, ткнул пальцем в один из них и сказал,- Ребята, этот работать не будет! За что и был послан разработчиками в известном направлении.Первый же подрыв разнес вдребезги то, на что обратил внимание Вова.Как, почему, откуда знал? Просто что был практиком с большой буквы.Как-то так.


Примем к сведению следующие факторы:
1) Нам надо не следовать парадигме, а написать работающую программу и потом сопровождать ее.
2) Чем правильнее мы все делаем, тем больше времени нам на это надо.
3) Мы не можем предусмотреть всего заранее.
4) Цена ошибок в проектировании разная.

ИМХО решение твоей проблемы ###кода подсказано еще в 70-ые. Называется структурное программирование и основной его прием - декомпозиция. Сама по себе постановка вопроса в виде отделения GUI от логики как раз и означает провести декомпозицию. Вопрос только как ее проводить. Вот, например, в одной из моих программ имеется метод под кнопкой:



Что я делаю? Просто получаю объект из списка, если ошибка, то выдаю сообщение, беру с других контролов время, ставлю нужную вкладку пейдж-контролу, последним методом загружаю данные.
Сам по себе этот метод весьма здоровый, так что приведу без комментариев, и пояснений, что там делается:



Можно не сомневаться, что тут можно еще до черта улучшить, например, вытащить из него все интерфейсные сообщения и пусть возвращает только коды ошибки, если есть. Разделить собственно нашпиговывание диаграммы данными и разного рода пересчеты контролов, обе ветки от if not KeepParam можно вынести, как отдельные процедурки. Текстовые сообщения вынести в константы, вот только один вопрос, нафига? Если я уберу сообщения об ошибках из метода, то придется после каждого вызова вызывать еще одну функцию, которая будет анализировать эти ошибки, т. е. вместо одного метода с которым еще вполне можно работать, я получу кучу маленьких, работать с которыми ничуть не легче. И самый главный вопрос, а причем тут кнопки-то? Под кнопкой 6-7 строчек кода, зато вызывается функция длиной в 30 строк. Нет, что-нибудь я с ней сделаю, конечно, да и проверку F=nil из кода кнопки можно смело убирать, но в целом это не так критично, и для меня код остается понятным. А раз код понятный, то нафига тратить время на формальности, которые, скорее всего, никогда не понадобятся? При необходимости всегда можно потом прибраться. Реальные же проблемы намного сложнее возможности/невозможности бросить на форму кнопку и начать фигачить под ней код. 

Гениальная фраза... Таки Вы серьезно думаете, что на Delphi можно написать что либо "тупым бросанием на форму"?


а от чего они торчат, позвольте поинтересоваться? От LifeBuilding?



serger, поясните, а то не понятно в чем именно тупиковость?

Beltar, главное не забывать о том, что рабочую программу можно сделать быстрой (или правильной ;)), а вот быструю рабочей сделать гораздо сложнее ;)

В Delphi декомпозиция выполнена на уровне VCL, так как разработчику не требуется "ручками" писать GUI и обслуживать конвеер сообщений. 
К приведенному Вами коду применить декомпозицию наверное нельзя, так как этот код занимается непосредственно визуализацией и является неотъемлемой частью GUI.
Если же говорить о декомпозиции, то в идеале нужно создавать дополнительный поток (для проведения выборок и расчетов абстрактно от интерфейса). Поток висит на ожидании Event.WaitFor. В OnClick находится один метод Event.SetEvent (по сути спусковой крючек). После нажатия на кнопку стартует выборка и подготовка данных и в конце синхронно вызывается метод заполнения GUI даннами. Таким образом GUI может получить некий типизированный набор данных не вникая в их происхождение (база ли это или фаил, инет). А вспомогательный поток не ведает как и где данные отображаются. 

При написании программы в C(C++) данный подход более очевиден, так как изначально приходится отделять обслуживание GUI от работы с данными. Как правило заводят несколько нитей.
В Delphi половина работы уже сделана (поток GUI уже есть) и остается написать функциональный поток(и). А вот здесь начинается методологическая проблема. Потокам и их синхронизации практически не уделяют внимания ни в книгах ни при обучении. Отсюда и множество посредственных кодеров. Конечно можно писать и одно поточные приложения, но это должны быть простые диалоговые приложения, в частности работа с базами данных, синхронная работа по сети и тд. Основной риск это заморозка интерфейса и как следствие неудобство использования.
Но это совершенно не означает, что на СИ пишут "правильные" приложения. Пишут точно такие же, и еще хуже, так как бока внедряют и на уровень обработчиков сообщений GUI, в добавок взаимные блокировки потоков и смежные проблемы. 

А теперь  о том почему же все таки не любят.
Кратко: Для написания одно поточного приложения с GUI некой сложности на Delphi потребуется на два-три порядка меньше времени, чем на C++. Причина VCL (событийный движек). Лично у меня сишник который кодит GUI вызывает глубочайшее умиление, а у него (сишника) при этом этом зреет черная зависть к этим "недокодерам" которым этого делать не надо. Потом сишнику все это надоело и стал он явистом, но ненависть к "недокодерам" осталась, хотя никакой декомпозиций он уже не занимается, не говоря уже о соблюдении стандартов ;)
Причем данная концепция закрепилась очень давно и если брать современный срез технологий, то различия между средами разработки достаточно смазаны.

Наткнулся на код жавита...
Это к вопросу о правильно построении алгоритмов и тд.

Их и сейчас хватает :(



Никто не мешает писать код ручками и создавать компоненты ручками. Но delphi - это RAD   




Зависть?