Pascal, Object Pascal, Delphi

Это не у меня, это твой код, я привёл то как он по идее должен выглядеть для вызова процедуры. На мой взгляд.

В быдлопендосских говновузах ни хера не учат, нет смысла на них равняться. Хорошие вузы только у нас, и в хороших вузах только Паскаль!

Ты продемонстрировал технику обращения к СУБД (часть бизнес-логики) смешанную с обращениям к виджетам. Я показал то же, но в схематичном виде. Суть в том, что ни твоего val0 ни моего edit1 не должно вообще быть в бизнес-логике.

худей

Бизнес-логика в случае использования хранимых процедур должна быть реализована средствами сервера БД. Гуй - и есть гуй, другое дело что обращения к БД должны быть накрыты ещё одним слоем абстракции, и вызываться в духе my_func(edit1.text). Хотя вроде выше ты сказал примерно тоже самое.

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

Вали с Русского сайта, подпендосник. Предателям тут не место.

Тем не менее - неумение пользоваться инструментом, не есть вина инструмента

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

Вали с Русского сайта, подпендосник. Предателям тут не место.

Лучше выгони, толстенький ты наш.

Учи с#. Он современный наследник дельфей, не концептуальный, но культурный.

Фу. Негуманойдное мелкософтовское поделие. На винфак.

TP это посути быстрый REPL и компилируемый язык и пошаговый отладчик(к подкраской строки выполнения)

TP - это Turbo Pascal? Тогда не понял про REPL.

Я бы сказал, что это культура использования такая

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

конечно в общеупотрибимом смысле от репла ожидается интроспекция среды и инкрементальность вносимых добавлений.

и всётаки я хвалю TurboPascal и даже называю его возможности REPL ибо вмомент появления tp1.0 - это был редкий инструмент который предоставлял интерактивное программирование(даже без отладчика) на домашних/персональных компах .

я незнаю какое конкретно сочетание причин не позволило на тех машинах на которых как огонь распространился TP1.0 (мин требования 32кб(вроде) из них 24 занимала сама система )- использовать вкачестве быстрой петли разработки EDLIN(либо ed)+(выход в шелл и запуск cc + запуск полученого бинаря)

но в том окружении TP давал сочетание интерактивности и скорости исполнения машиного кода(ибо однопроходно генерил в память и запускал) т.е пользователю Turbo Pascal имел те черты которыми так ценятся repl'ы - диалоговый режим работы(инкрементальность,добавление маленькими частями)

называние TP repl'ом некоторая релаксация - но не появись tp может чё нить и с настоящим(полноценым) repl'ом взлетело бы - продовайся оно так же дешево и компилируй свой код в машиный.

а так наличие TP показало , что даже компилируемый язык - при удобном окружении (редактор,«мгновенная» компиляция,«мгновенный» запуск )- достаточен - при офигеном бонусе - исполняемый машиный код на выходе.

Уффф, я уж испугался, что что-то пролистнул в своей жизни :)

ну если чисто адвокатитдьявола.

можно придумать короткий паскальный код который после своего исполнения из под TP1.0(как иде-почтиREPL) оставляет в памяти что то наподобии tsr(впервые - а затем апдейтится) - т.е эдакий менеджер динамических структур живущий одновременно со средой ( т.е как нить память так порезать что - бы операционка(недо) не трогала этот менеджер) - короче очень короткий путь до наличия repla - но в том и ирония - что наличия быстрой и интегрированой среды снизило остроту нехватки repl.

REPL для Delphi существует и называется PascalScript.

да, при современных мощях , для всех массовых языков repl'ы есть

а вот раньше только для asm(полуасма - без мнемонических имён , только мнемокоманды) был общедоступный repl:

debug.com

даже дебугскрипты были http://en.wikipedia.org/wiki/Debug_(command)#cite_ref-Using_Debug_3-1

Я знаю 3 случая, когда смешение оправдано:
1) продемонстрировать работу тех или иных аспектов работы среды. При этом обе стороны должны четко понимать что речь идет исключительно об демонстрации аспектов, а не о продакшене.
2) сделать одноразовую программку. В этом случае оправданы любые средства ускоряющие разработку.
3) сделать прототип. Аналогично предыдущему, но с четким пониманием, что придется переписывать.

Так ли плохо смешение, если оно позволяет избавиться от некоторых слоёв?

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

1. Переносимость нужна далеко не всегда. Требование переносимости обычно кастрирует конкретную среду, не позволяя использовать «вкусности», которые обычно и делают труд производительным. Например, если речь идёт об SQL, вкусностью являются хранимые процедуры. Без них производительность бизнес-логики падает примерно на порядок. Таким образом, вместо того, чтобы сразу делать работу, применяя имеющийся набор инструментов, разработчик предаётся аскезам ради загробной жизни.

2. Термин «расширяемость» некорректен без указания куда планируется эта расширяемость. По природе вещей расширяемость в одну сторону затрудняет расширяемость в другую. Поскольку направления расширения заранее предугадать нельзя, расширяемость тоже можно назвать разновидностью готовности к загробной жизни.

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

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

Если, вдруг, не совсем аминь:
по 1 и 2
Рано или поздно понадобится куда-то расширяться. Сегодня я делаю для винды, а завтра тот же функционал понадобится под web, mac, linux или еще что-то. С другой стороны, в бизнес-логике проще разобраться когда она минимизирована предметной областью. Так что аскеза, в разумных пределах, полезна уже в этой жизни.

От наличия слоёв логика работы приложения не упрощается.

Зато расширяется сфера применимости слоев системы. При этом важно, чтобы количество слоев было не слишком большим и не слишком маленьким.

Например, если обработка происходит на клиенте, это может быть просто вызов функции.

А если завтра клиент поменяется?

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

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